«

Does a compiler guarantee that the variable w below is placed on an
eight-byte aligned address?


void myFunction( long iFreq )
{
const double w = two_pi * iFreq;
...
...
}

wrote:
> Does a compiler guarantee that the variable w below is placed on an
> eight-byte aligned address?

No. There are no requirement in C++ Standard WRT specific alignment
for any objects.

You will find that every compiler/platform is different in that sense
and that many compilers (if not all) have a way for you to control the
alignment boundary.

> void myFunction( long iFreq )
> {
> const double w = two_pi * iFreq;
> ...
> ...
> }

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Re: This code, similar to yours, GLChin:
“ main() { const double w = 0 ; } �,

The address of “ w � is 8-byte-aligned.
Using VC++ 8, you can check for yourself, like this:

#pragma warning( disable: 4007 4189 4430 4508 )
WinMain( int, int, int, int ) {
const __int32 Int32 = 0 ; const __int64 Int64 = 0 ;

int Implicit_Size_of_Int32 = int( & Int64 ) - int( & Int32 );
// Breaking here, “ Implicit_Size_of_Int32 == 8 �.
}

<> wrote in message
news:6d36462e-28fe-4db8-83a5-...
> Does a compiler guarantee that the variable w below is placed on an
> eight-byte aligned address?
>
>
> void myFunction( long iFreq )
> {
> const double w = two_pi * iFreq;
> ...
> ...
> }

Yes, the compiler always guarantees that variables are by default aligned
correctly for their type. Since this is a double, it will be 8-byte
aligned. Since this is a const double, there's no requirement that the
compiler allocate any memory for it at all - it could be enregistered or
re-calculated wherever used. In practice, the compiler probably assigns
memory for it, which would be 8-byte aligned.

The only time memory won't be aligned is when you've used #pragma pack, one
of the memory alignment command-line options, or done pointer arithmetic
yourself that doesn't honor the type's alignment.

-cd

I'm not sure that in 32-bit environment there is a stack frame alignment
guarantee, other than 4 bytes, of course. Thus, any doubles might be
unaligned.

"Carl Daniel [VC++ MVP]" < >
wrote in message news:...
> <> wrote in message
> news:6d36462e-28fe-4db8-83a5-...
>> Does a compiler guarantee that the variable w below is placed on an
>> eight-byte aligned address?
>>
>>
>> void myFunction( long iFreq )
>> {
>> const double w = two_pi * iFreq;
>> ...
>> ...
>> }
>
> Yes, the compiler always guarantees that variables are by default aligned
> correctly for their type. Since this is a double, it will be 8-byte
> aligned. Since this is a const double, there's no requirement that the
> compiler allocate any memory for it at all - it could be enregistered or
> re-calculated wherever used. In practice, the compiler probably assigns
> memory for it, which would be 8-byte aligned.
>
> The only time memory won't be aligned is when you've used #pragma pack,
> one of the memory alignment command-line options, or done pointer
> arithmetic yourself that doesn't honor the type's alignment.
>
> -cd
>
>

On Dec 3, 6:22 pm, glc...@hotmail.com wrote:
> Does a compiler guarantee that the variable w below is
> placed on an eight-byte aligned address?

> void myFunction( long iFreq )
> {
> const double w = two_pi * iFreq;
> ...
> ...
> }

A compiler does, but I don't know if your using that compiler.
Certainly not all compilers do---it wouldn't make sense on a
machine where sizeof(double) is 6, for example, nor on a 16 bit
machine. Depending on the hardware, it might not even make
sense on a 32 bit machine (nor a 36 bit machine, for that
matter).

The real question is why do you care? The compiler will
guarantee that w meets whatever requirements the hardware makes
for effective access. And that's really all you care about.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Dec 3, 7:43 pm, "Carl Daniel [VC++ MVP]"
<cpdaniel_remove_this_and_nos...@mvps.org.nospam > wrote:
> <glc...@hotmail.com> wrote in message

> news:6d36462e-28fe-4db8-83a5-...

> > Does a compiler guarantee that the variable w below is
> > placed on an eight-byte aligned address?

> > void myFunction( long iFreq )
> > {
> > const double w = two_pi * iFreq;
> > ...
> > ...
> > }

> Yes, the compiler always guarantees that variables are by
> default aligned correctly for their type.

Which on most 32 bit machines is any multiple of 4. On the one
48 bit machine I'm aware of, it would be a multiple of 6. On
the various 36 bit machines I've seen or heard of, it would be a
multiple of 4 as well. On the earlier 16 bit machines I
worked on, it would be multiple of 2, and on the 8 bit machines,
there were no alignment restrictions.

> Since this is a double, it will be 8-byte aligned.

On a Sun Sparc, probably. On an Intel based 32 bit machine, I
doubt it, and on the older, 16 bit Intels, almost certainly not.

> Since this is a const double, there's no requirement that the
> compiler allocate any memory for it at all - it could be
> enregistered or re-calculated wherever used. In practice, the
> compiler probably assigns memory for it, which would be 8-byte
> aligned.

> The only time memory won't be aligned is when you've used
> #pragma pack,

Which is implementation defined. Maybe it starts a game of
packman.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Dec 3, 7:07 pm, Jeff?Relf <Jeff_R...@Yahoo.COM> wrote:
> Re: This code, similar to yours, GLChin:
> ? main() { const double w = 0 ; } ?,

> The address of ? w ? is 8-byte-aligned.
> Using VC++ 8, you can check for yourself,

You can check whether it is 8 byte aligned in one particular
case, after whatever calls preceded it.

> like this:

> #pragma warning( disable: 4007 4189 4430 4508 )
> WinMain( int, int, int, int ) {
> const __int32 Int32 = 0 ; const __int64 Int64 = 0 ;

> int Implicit_Size_of_Int32 = int( & Int64 ) - int( & Int32 );
> // Breaking here, ? Implicit_Size_of_Int32 == 8 ?.
> }

I'm not sure what that's supposed to check. It's not C++, so it
doesn't tell us anything about what C++ does. And I don't see
how it would be related to how VC++ would lay out a double.

FWIW: VC++ doesn't guarantee 8 byte alignment. All of my
compilers on Sparc do---perhaps because accessing a double at an
address which isn't 8 byte aligned will cause a core dump.
Curiously, g++ on both the Linux machine and the Windows
machines here (32 bit Intel) also seems to guarantee 8 byte
alignment.

You might try something like the following:


#include <iostream>

double two_pi = 6.28 ;

void
f( long ifreq )
{
double w = two_pi * ifreq ;
std::cout << &w << std::endl ;
}

void
g()
{
f( 20 ) ;
}

template< size_t N >
void
h()
{
char dummy[ N ] ;
f( 20 ) ;
}

template< size_t N >
void
i()
{
char dummy[ N ] ;
double w ;
std::cout << &w << std::endl ;
}

int
main()
{
f( 20 ) ;
g() ;
h< 1 >() ;
h< 2 >() ;
h< 3 >() ;
h< 4 >() ;
h< 5 >() ;
h< 6 >() ;
h< 7 >() ;
h< 8 >() ;
i< 1 >() ;
i< 2 >() ;
i< 3 >() ;
i< 4 >() ;
i< 5 >() ;
i< 6 >() ;
i< 7 >() ;
i< 8 >() ;
return 0 ;
}

If all of the addresses output are multiples of 8, it still
isn't guaranteed, but I'd guess that there is a very good chance
of it being true. If they aren't, of course, you know that it
isn't guaranteed.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

“ VC++ 8.0 � 8-byte-aligns a “ __int64 �, same as a “ double �.

The code I showed ( news: )
is most definately VC++ 8.0,
complied and debuged using Visual Studio 2005.

Had you tried it yourself, Mr. Kanze, you'd know that;
but, naturally, you couldn't do that.

"Jeff?Relf" <> wrote in message
news:...
>" VC++ 8.0 " 8-byte-aligns a " __int64 ", same as a " double ".
>
> The code I showed ( news: )
> is most definately VC++ 8.0,
> complied and debuged using Visual Studio 2005.
>
> Had you tried it yourself, Mr. Kanze, you'd know that;
> but, naturally, you couldn't do that.
>

Jeff, your code shows nothing at all, because it is in the main function.
Stack alignment is dependent on the caller to some degree, if the caller
left the stack 4-byte aligned, then you would not have 8-byte alignment.