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]?

 

[Victor Bazarov]

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]

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.

 

[Ioannis Vranos]

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.

 

[Dietmar Kuehl]

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...

 

[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

 

[Ioannis Vranos]

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.

 

[Pete Becker]

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.

 

[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]

...
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.

 

[Andrey Tarasevich]

...


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.

 

[Greg Comeau]

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]

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]

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]

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.

 

[Ioannis Vranos]

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.

 

[Default User]

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]

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?

 

[Andrey Tarasevich]

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