In article <71rm5a$c02$1@nnrp1.dejanews.com>, rado42@my-dejanews.com
says...

[ ... Steve Clamage said: ]

> > Allocation functions (such as operator new or operator new[]) are
> > unconditionally constrained to return storage properly aligned for
> > any object that could be stored in the requested memory. Your
> > operator new[] above does not meet this requirement.

[ ... ]

> Does all that mean that in the following code (assuming 8 byte allignment,
> which also happens to be the sizeof double)
>
>   double *x = new double[1];
>   int ix = (int)x;
>   assert (x % 8 == 0);
>
> 'assert()' should not fail? It *does* under MSVC5.0. Is this a library bug?

No.  The requirement is that new return a an object aligned so it can
be used.  There's no portable way to detect what the alignment is.
The version of new that's built-in may know what the alignment
requirements (if any) are, and only use what it knows is needed.  In
the case of an Intel processor, there ARE no alignment requirements,
though up to a point (4 byte) alignment to larger boundaries can
increase speed.  However, such a difference in speed (rather than
capability) has no effect on the conformance of the implementation.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <71cvom$hfv$1@engnews1.eng.sun.com>,
  clamage@Eng.Sun.COM (Steve Clamage) wrote:

....stuff.......

> Recall that a new-expression results in a call on an allocation
> function, followed by construction of objects. The compiler might
> generate other bookkeeping code as well. For example, if an
> array-delete expression does not have compile-time access to the
> number of elements allocated, that information must be stored
> someplace at run time by the array-new expression.

> The quoted paragraph recognizes that the compiler might want to
> request some extra space beyond what is needed for the array
> being allocated. If so, the compiler-generated code must preserve
> alignment.

> Allocation functions (such as operator new or operator new[]) are
> unconditionally constrained to return storage properly aligned for
> any object that could be stored in the requested memory. Your
> operator new[] above does not meet this requirement.
>
.....stuff.....


Hi,all

Does all that mean that in the following code (assuming 8 byte allignment,
which also happens to be the sizeof double)

  double *x = new double[1];
  int ix = (int)x;
  assert (x % 8 == 0);

'assert()' should not fail? It *does* under MSVC5.0. Is this a library bug?

Rado


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

clamage@Eng.Sun.COM (Steve Clamage) wrote:
>> ...
>> Recall that a new-expression results in a call on an allocation
>> function, followed by construction of objects. The compiler might
>> generate other bookkeeping code as well. For example, if an
>> array-delete expression does not have compile-time access to the
>> number of elements allocated, that information must be stored
>> someplace at run time by the array-new expression.
>>
>> The quoted paragraph recognizes that the compiler might want to
>> request some extra space beyond what is needed for the array
>> being allocated. If so, the compiler-generated code must preserve
>> alignment.
>>
>> Allocation functions (such as operator new or operator new[]) are
>> unconditionally constrained to return storage properly aligned for
>> any object that could be stored in the requested memory. Your
>> operator new[] above does not meet this requirement.
>>
>> ...

rado42@my-dejanews.com wrote:
> Does all that mean that in the following code (assuming 8 byte
> alignment, which also happens to be the sizeof double)
>
>   double *x = new double[1];
>   int ix = (int)x;
>   assert (x % 8 == 0);
>
> 'assert()' should not fail? It *does* under MSVC5.0.
> Is this a library bug?

No.  Intel architectures use byte-aligned memory access, not
word-aligned.  So new() is not required to return memory
allocations on any particular boundary in order to work on Intel
CPUs.  In other words, any object can be located at any byte
boundary in memory; word alignment is not necessary for any data
type on iAPX86 family CPUs.  (The same can't be said for every
CPU architecture, of course.)

You will probably find, however, that new() probably does return
memory aligned on word (either 2-byte or 4-byte) boundaries, since
accesses to word-aligned objects is faster on Intel CPUs.  So
perhaps these will not fail:

    assert((unsigned long)x % 2 == 0);
    assert((unsigned long)x % 4 == 0);

But don't rely on it.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]