Re: Question about C++ and type aliasing

[Dan Nicolaescu <dann at godzilla dot ICS dot UCI dot EDU>]

Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:

  > I'm deciding whether to use C or C++ for a high performance simulation
  > project.  In many ways C++ is a better match for the problem, but I am
  > concerned about performance.
  > 
  > Specifically, last January there was a thread about C++ and the rules
  > for type alias analysis.

I assume you are thinking about the thread on enabling more alias
analysis for C++.  If yes then I can answer some of your concerns. 

  > I wasn't very clear on the outcome of that thread.  If I define a base
  > class and another that is derived from it, and I use some virtual
  > functions, will I get code that is as fast as doing the equivalent in C?

Is this related to aliasing? 

  >   2. If I implement this in C++, using a type Derived which is derived
  >      from another type, Base, I can implement exactly equivalent code,
  >      right down to the word layout of the data structures and the
  >      functions.  But will I get equivalently fast code (particularly
  >      with respect to type alias analysis),
  > 
  >          (a) if there are no virtual functions in Derived or Base.
  > 
  >          (b) if there are virtual functions in Derived and Base.

The status quo is:
In 3.1 alias analysis is disabled in C++ for all the aggregate types,
it is only enabled in mainline CVS. Virtual functions don't influence
alias analysis. Alias analysis is disabled for classes that have a
virtual base. Multiple inheritance is ok. 

There's still a missing feature when using inheritance. 

For example:
class first {  public:  double d;  int f1;}; 
class second : public first {  public:  int f2;  short a;}; 

void
foo (first *s1, second *s2)
{  
  s1->f1++;
  s2->f2++;
  s1->f1++;
  s2->f2++;
}  

s1->f1 and s2->f2 are considered to alias. If f1 and f2 are both
defined in "first" (or "second") then they are not considered to
alias. I submitted a patch to fix this about 2 weeks ago, but it has
not been reviewed yet (no wonder, everybody is too busy fixing 3.1).


        --dan