Suppose I have the a Complex class -

class Complex {
public:
   // A whole raft of useful member functions, none virtual...
private:
  float real;
  float imag;
};

Complex *cp = new Complex [1000];
...
float *fp = (float *)cp;

Is *(fp + an_even_number) guaranteed to point to a "real" part and
*(fp +an_odd_number) to an "imaginary" part? Does the answer change if
instead we have:

struct Complex { // i.e. public
  float real;
  float imag;
};


Brian
--
       Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu          Charlottesville Va.           (804) 296-0286

According to section r.9.2 (page 545 Stroustrup 2nd ed):
Nonstatic data members of a class declared without an intervening access-
specifier are allocated so that later members have higher addresses within a
class object.  The order of allocation of nonstatic data members separated by
an access-specifier is implementation dependent (r.11.1).


Is the following statement true?
>> all non-static values associated with an object "at address p" reside in
>> (byte) addresses between p and p+sizeof(object)-1
[this is supposed to include virtual table pointers and any other "hidden"
 value of which every member of that class has its own copy].
Is it stated somewhere that this holds?

I believe the following question is related too:
if p is a (correctly aligned) pointer to an object of type
union { long double x;  void *y;  long int z; }
then is p correctly aligned for all possible objects?
[the example on page 466 of Stroustrup 2nd ed implies something akin to this].
If so, where is this assurance given?

If the above statements are not guaranteed in all implementations, is there
some similar guarantee?

Thanks,
John.

In article <1993Apr16.165817.9961@gdr.bath.ac.uk>
 mapjaa@gdr.bath.ac.uk (J A Abbott) writes:

>if p is a (correctly aligned) pointer to an object of type
>union { long double x;  void *y;  long int z; }
>then is p correctly aligned for all possible objects?

I don't see why it's useful to create a maximally aligned pointer type,
but regardless I don't think that example creates one.

K&R I required conversion to a pointer to a smaller object and back to
leave the pointer unchanged.  ANSI C changed the reference to the size
of an object to refer to the alignment of an object instead.

I can think of a plausible reason the make "long double" less strictly
aligned than "double".  Suppose "long double" is a 96 bit type and
"double" is a 64 bit type.  One might require that doubles be aligned on
64 bit boundaries but not impose such a requirement on long doubles (not
wanting to waste 32 bits per object).

I just checked my copy of the ANSI C standard and found that it does say
alignment is a restriction that an address be a multiple of a certain
value.  Was there a change from the draft standard wording?  I remember
reading somewhere a more general definition of alignment in C.

--
    John Carr (jfc@athena.mit.edu)

>>>>> On 16 Apr 93 16:58:17 GMT, mapjaa@gdr.bath.ac.uk (J A Abbott) said:
> I believe the following question is related too:
> if p is a (correctly aligned) pointer to an object of type
> union { long double x;  void *y;  long int z; }
> then is p correctly aligned for all possible objects?

For what it's worth, "aggregates are aligned on the strictest boundary
required by any of their constituents" (ARM p.68), so if you make a
structure consisting of the largest representative of each scalar
type, you can be reasonably assured that the structure will have the
"strictest possible alignment".

However, I don't see any way you can portably determine the alignment
of a pointer type, so it wouldn't seem to make much sense for a C++
standard to make any guarantees about alignment.  In fact, the very
notion of alignment assumes a linear memory model indexed by integers,
which is neither mandated by the ARM nor necessary for implementing
C++.

> [the example on page 466 of Stroustrup 2nd ed implies something akin to this].

The example on p.466 also does arithmetic on a pointer of type
"void*", which is not legal C++.  I think that example should be
considered "pseudocode".

     Thomas.