Adress of a struct vs address of its first field

[Grumble]

Hello everybody,

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?

What if the type of bar is unsigned char[16]?

--
Regards, Grumble

[Victor Bazarov]

Grumble wrote:

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?

What if the type of bar is unsigned char[16]?

You shouldn't assume that. However, for POD you can use 'offsetof'
macro to find out what the actual offset is. You're very likely to
get 0, but it's not guaranteed by the language, IIRC. Of course it
is possible that I don't RC.

V

[Pete Becker]

Grumble wrote:

Hello everybody,

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?

What if the type of bar is unsigned char[16]?

Yes to both. That's the rule in C, and for C-like structs (which the C++
standard calls PODs) the same rule applies.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Dietmar Kuehl]

Pete Becker wrote:

Grumble wrote:

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?
What if the type of bar is unsigned char[16]?

Yes to both. That's the rule in C, and for C-like structs (which the

C++ standard calls PODs) the same rule applies.

Actually, I don't think that the above code is supposed to compile
without a diagnostic (which will cause the compilation to fail on
many systems): You cannot compare 'foo*' to 'int*'. However, the
following should compile and yield true for POD types:

static_cast<void*>(&s) == static_cast<void*>(&s.bar)

Of course, this is just nitpicking...
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Ioannis Vranos]

Pete Becker wrote:

Grumble wrote:

Hello everybody,

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?

What if the type of bar is unsigned char[16]?

Yes to both. That's the rule in C, and for C-like structs (which the C++
standard calls PODs) the same rule applies.

Are you sure? As far as I know this only applies to unions. A struct may
contain padding bits. That is, the above is not portable.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[eddy_ruslim]

Won't say too much theory but why not just try it on a compiler or ide.
You can even see the assembler results.personally the premis is true
for all truely ansi complience C++
Edernity
---------
if it help
please help me provide better school supplies for childrenof indonesia.
it may be a donation but I merely ask you to letme send email to you
from one of the product of I'm affiliated and please register there on
mechant account free. If you even want you refund back on your dollar
of i-kard, its ok, I'll send you just use regular delivery on shipping
please. Please note this is very safe since this is a bonafid company.
remember your credit card company will confirm you on your purchase.
Still have doubts, sign on a personal account and let me contact you
again on it. just 1 email
also
I'm also affiliated to this site:
www.getaportal.com/portals/edd y_ruslim

[eddy_ruslim]

Won't say too much theory but why not just try it on a compiler or ide.
You can even see the assembler results.personally the premis is true
for all truely ansi complience C++
well bits all the best of days that god may grant! (and not grand :-D).
standards can't live with it can't live without it
Edernity
---------
if it help
please help me provide better school supplies for childrenof indonesia.
it may be a donation but I merely ask you to letme send email to you
from one of the product of I'm affiliated and please register there on
mechant account free. If you even want you refund back on your dollar
of i-kard, its ok, I'll send you just use regular delivery on shipping
please. Please note this is very safe since this is a bonafid company.
remember your credit card company will confirm you on your purchase.
Still have doubts, sign on a personal account and let me contact you
again on it. just 1 email
also
I'm also affiliated to this site:
www.getaportal.com/portals/edd y_ruslim

[Pete Becker]

Ioannis Vranos wrote:

Are you sure? As far as I know this only applies to unions. A struct may
contain padding bits. That is, the above is not portable.

Yes, I'm sure. A POD struct cannot contain padding bits before the first
field.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Ioannis Vranos]

ed*********@telkom.net wrote:

Won't say too much theory but why not just try it on a compiler or ide.
You can even see the assembler results.personally the premis is true
for all truely ansi complience C++

I would prefer to see a reference to the standard, than check some
particular compiler's output.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[eddy_ruslim]

like I said "standards can't live with it can't live without it" sorry
for the broken posts. My ADHD/dyslexia get ahead of me if u know what i
mean.
Guys what about the donation pls 1 email could help a child for 1 month

[Andrey Tarasevich]

Grumble wrote:

...
Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?
Yes, for POD structs. You just have to convert the pointer types
accordingly (using 'reinterpret_cast').
What if the type of bar is unsigned char[16]?

Doesn't matter.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Ioannis Vranos wrote:

...

Won't say too much theory but why not just try it on a compiler or ide.
You can even see the assembler results.personally the premis is true
for all truely ansi complience C++

I would prefer to see a reference to the standard, than check some
particular compiler's output.
...

9.2/17

A pointer to a POD-struct object, suitably converted using a
reinterpret_cast, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides) and vice versa.

--
Best regards,
Andrey Tarasevich

[Greg Comeau]

In article <d1**********@news-rocq.inria.fr>,
Grumble <de*****@kma.eu.org> wrote:

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?
In this case, yes.
What if the type of bar is unsigned char[16]?

Still yes.

When and if possible, you should favor more portable techniques though.
For instance, since you're referring to PODs only, consider maybe
offsetof, or even just use the &'s as you've shown above.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <11**********************@o13g2000cwo.googlegroups .com>,
Dietmar Kuehl <di***********@yahoo.com> wrote:

Pete Becker wrote:

Grumble wrote:

> struct foo s;
>
> Will &s == &(s.bar) always be true regardless of the type of bar?
> What if the type of bar is unsigned char[16]?
>

Yes to both. That's the rule in C, and for C-like structs (which the

C++

standard calls PODs) the same rule applies.

Actually, I don't think that the above code is supposed to compile
without a diagnostic (which will cause the compilation to fail on
many systems): You cannot compare 'foo*' to 'int*'. However, the
following should compile and yield true for POD types:

static_cast<void*>(&s) == static_cast<void*>(&s.bar)

Of course, this is just nitpicking...

Indeed, IOWs, the addrs are the same but the types are different,
so metablizing them would be necessary.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <1110824562.415403@athnrd02>,
Ioannis Vranos <iv*@remove.this.grad.com> wrote:

Pete Becker wrote:

Grumble wrote:

Hello everybody,

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?

What if the type of bar is unsigned char[16]?

Yes to both. That's the rule in C, and for C-like structs (which the C++
standard calls PODs) the same rule applies.

Are you sure? As far as I know this only applies to unions. A struct may
contain padding bits. That is, the above is not portable.

But for POD structs, not in the very beginning.
Let's see...9.2p17
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <11**********************@f14g2000cwb.googlegroups .com>,
<ed*********@telkom.net> wrote:

Won't say too much theory but why not just try it on a compiler or ide.

Because if it were not true, if may work for some compilers,
but not others, and Murphy's Law says he wouldn't have one of the latter.
So he would not know for certain.

That said, generally speaking, there is something to be said for folks
trying things out.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Ioannis Vranos]

Greg Comeau wrote:

But for POD structs, not in the very beginning.
Let's see...9.2p17

OK but the wording is a bit "foggy". It says in square brackets that
there may be no padding bits in the beginning, however it mentions
reinterpret_cast, so to "pointers not suitably converted with
reinterpret_cast" but to void * directly, isn't that true? I guess it
is, it is a "rhetorical" question. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Default User]

ed*********@telkom.net wrote:

like I said "standards can't live with it can't live without it" sorry for the broken posts. My ADHD/dyslexia get ahead of me if u know what i mean.
Guys what about the donation pls 1 email could help a child for 1

month

Please quote a relevant portion of the previous message when you reply.
To do so from Google, click "show options" and use the Reply in the
expanded message header.

Brian

[Grumble]

Andrey Tarasevich wrote:

Grumble wrote:

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field
is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?

Yes, for POD structs. You just have to convert the pointer types
accordingly (using 'reinterpret_cast').

I was under the impression that "reinterpret_cast" should be used to
examine, for example, the actual bits that make up a pointer. Wouldn't
"static_cast" be more appropriate here?

How are they different in this situation?

--
Regards, Grumble

[Andrey Tarasevich]

Grumble wrote:

Andrey Tarasevich wrote:

Grumble wrote:

Assume I have a plain, old, boring struct foo (i.e. no virtual
functions, no methods, just data fields). Assume the first field
is bar.

struct foo s;

Will &s == &(s.bar) always be true regardless of the type of bar?

Yes, for POD structs. You just have to convert the pointer types
accordingly (using 'reinterpret_cast').

I was under the impression that "reinterpret_cast" should be used to
examine, for example, the actual bits that make up a pointer. Wouldn't
"static_cast" be more appropriate here?

How are they different in this situation?

'static_cast' cannot be used here at all. 'static_cast' cannot convert
between completely unrelated types (and completely unrelated types is
what we have here). This conversion is performed specifically by
'reinterpret_cast', as described in 9.2/17

--
Best regards,
Andrey Tarasevich