[Q] Impact of Unseen Types

[Garvin, Michael [CAR:C28G:EXCH]]

Hi I'm working on some impact analysis stuff for C++. I was wondering if
anyone has seen an example of a type (lets say type "A") change impacting
the storage/layout another type (lets say type "B"), but B does not include
the header/src file where A is defined.
Also B is using type A by more than just a pointer, that is B needs to know
the size/layout of A.

For most (all?) complex types, I presume that the compiler must see the full
declaration of the type its using, in order to know the size, alignment,
layout etc. Is there any sneaky way around this, that I might have to
account for when trying to find the impact of a changed type?

Another way to ask this question; if I know exactly which header file type A
is defined in, and I know that type A has changed in size/layout, can I
assume that only the files which include type A's header are candidate
users? ...the places where some other type might possibly use type A

It sounds like a reasonable assumption, but there are lots of sneaky things
that can be done in C++. Maybe there is a way around this assumption?

Thanks in advance for any tips or examples that you've encountered...

(^_^)/
mike.

(e-mail address removed)

 

[Bob Hairgrove]

Hi I'm working on some impact analysis stuff for C++. I was wondering if
anyone has seen an example of a type (lets say type "A") change impacting
the storage/layout another type (lets say type "B"), but B does not include
the header/src file where A is defined.
Also B is using type A by more than just a pointer, that is B needs to know
the size/layout of A.

For most (all?) complex types, I presume that the compiler must see the full
declaration of the type its using, in order to know the size, alignment,
layout etc. Is there any sneaky way around this, that I might have to
account for when trying to find the impact of a changed type?

Another way to ask this question; if I know exactly which header file type A
is defined in, and I know that type A has changed in size/layout, can I
assume that only the files which include type A's header are candidate
users? ...the places where some other type might possibly use type A

It's a good starting point.

It sounds like a reasonable assumption, but there are lots of sneaky things
that can be done in C++. Maybe there is a way around this assumption?

If inclusion of headers is "well-behaved", i.e. you don't change
alignment or struct packing somewhere with #pragma's before including
it, this should be sufficient.

 

[Garvin, Michael [CAR:C28G:EXCH]]

Cool, thanks for the tip!

I've been hunting through the literature on impact analysis. The research
seems to be more abstract though, at a level where they assume you have the
abstract grammar graph for the entire system. Such analysis is valuable,
but unfortunately, I have to work on things incrementally. The bodies of
code I work on have 10s of millions of lines code I simply can't
construct the whole graph at once, I have to walk from a given starting
(changed!) type outwards. Hence my focus on trying to narrow down the
candidate places to look for impacts

Thanks again for the info,

(^_^)/
mike.

 

[Garvin, Michael [CAR:C28G:EXCH]]

Hey, found some "incomplete" type examples on the net, they seem to back up
the assumption that the compiler has to see the type, where it actually
tries to use it.

Example 1:

class E;

template <int> struct Z1 {
E e;
};

int main(int argc, char **argv) {
//struct Z1 a;
}

The compiler (at least gcc 2.95.x) fails out if you uncomment out the line
in main(). If 'E' was defined in header "A.h", then A.h would have to have
been included for it to work.

Example 2:

#include <list>

class TermArg;

class Term {

std::list<TermArg> args_;
};

int main(int argc, char **argv) {

//Term t;

return 0;
}

Again, the copmiler (gcc 2.95.x) allows the incomplete type to be used,
until the point where you actually try to use it.

Example 3:

class T;

T* CreateT();

int main() {
//delete CreateT();
}

Again the compiler (gcc 2.95.x) allows the incomplete type to be used. It
seems at least for the compiler I'm using, that types have to be complete,
or the compiler will bail. Since I'm working on code that I know has
already compiled, I think my assumption about type users including the type
definining header is pretty safe.

However, I wonder if other compilers, or even other versions of gcc will let
incomplete types through? I guess I'll have to search through the C++
standard specification (if I can find it), for indication of what the
expected behaviour is.

(^_^)/
mike.

Cool, thanks for the tip!

I've been hunting through the literature on impact analysis. The research
seems to be more abstract though, at a level where they assume you have the
abstract grammar graph for the entire system. Such analysis is valuable,
but unfortunately, I have to work on things incrementally. The bodies of
code I work on have 10s of millions of lines code I simply can't
construct the whole graph at once, I have to walk from a given starting
(changed!) type outwards. Hence my focus on trying to narrow down the
candidate places to look for impacts

Thanks again for the info,

(^_^)/
mike.