offsetof / non-POD structs

Hello all,

I would like to use offsetof on a non-POD struct, but of course this is
undefined. How else may I get the same effect?

Thanks,
Dave

re: offsetof / non-POD structs

Dave wrote:[color=blue]
> I would like to use offsetof on a non-POD struct, but of course this is
> undefined. How else may I get the same effect?[/color]

You cannot.

re: offsetof / non-POD structs

On Tue, 13 Dec 2005 15:51:12 -0700, "Dave" <better_cs_now@yahoo.com>
wrote:
[color=blue]
>Hello all,
>
>I would like to use offsetof on a non-POD struct, but of course this is
>undefined. How else may I get the same effect?
>
>Thanks,
>Dave
>[/color]

What is the "same effect" ... and WHY do you need to do this? Maybe
there is a C++ way of doing what you need to do...

If you understand why it is "undefined", you will understand why it is
a bad thing to do (like that, that is).

--
Bob Hairgrove
NoSpamPlease@Home.com

re: offsetof / non-POD structs

On Tue, 13 Dec 2005 15:51:12 -0700 in comp.lang.c++, "Dave"
<better_cs_now@yahoo.com> wrote,[color=blue]
>I would like to use offsetof on a non-POD struct, but of course this is
>undefined. How else may I get the same effect?[/color]

Use pointer-to-member (pretty esoteric.)
See Stroustrup section 15.5

re: offsetof / non-POD structs

"David Harmon" <source@netcom.com> wrote in message
news:44746420.793115609@news.west.earthlink.net...[color=blue]
> On Tue, 13 Dec 2005 15:51:12 -0700 in comp.lang.c++, "Dave"
> <better_cs_now@yahoo.com> wrote,[color=green]
> >I would like to use offsetof on a non-POD struct, but of course this is
> >undefined. How else may I get the same effect?[/color]
>
> Use pointer-to-member (pretty esoteric.)
> See Stroustrup section 15.5
>[/color]

I have no guarantee that a pointer-to-member is implemented as a simple
offset. It can be anything at all at the discretion of the compiler
implementor!

re: offsetof / non-POD structs

Dave wrote:[color=blue]
> "David Harmon" <source@netcom.com> wrote in message
> news:44746420.793115609@news.west.earthlink.net...
>[color=green]
>>On Tue, 13 Dec 2005 15:51:12 -0700 in comp.lang.c++, "Dave"
>><better_cs_now@yahoo.com> wrote,
>>[color=darkred]
>>>I would like to use offsetof on a non-POD struct, but of course this is
>>>undefined. How else may I get the same effect?[/color]
>>
>>Use pointer-to-member (pretty esoteric.)
>>See Stroustrup section 15.5[/color]
>
> I have no guarantee that a pointer-to-member is implemented as a simple
> offset. It can be anything at all at the discretion of the compiler
> implementor![/color]

Of course. But if you use it as it was designed to be used, then there
is no problem.

Put this another way: what is it that you desperately need an 'offset'
for? Whatever it is, there is sure to be a better way to achieve it.

--
Simon.

re: offsetof / non-POD structs

On Tue, 13 Dec 2005 17:24:21 -0700 in comp.lang.c++, "Dave"
<better_cs_now@yahoo.com> wrote,[color=blue]
>
>I have no guarantee that a pointer-to-member is implemented as a simple
>offset. It can be anything at all at the discretion of the compiler
>implementor![/color]

Indeed it is (probably) not a simple offset, and cannot be in order
to do everything in the presence of non-POD object features. But it
does have "the same effect" for many of the purposes where you might
legitimately use an offset in old C.

I am sure you do not want to violate object encapsulation, type
safety, or anything like that. So, what are you trying to
accomplish?

re: offsetof / non-POD structs

I don't know what the poster really wants this for, but the main use I
can see for something like this is doing introspection/runtime binding.
There are many times when it would be REAL handy to be able to have
offsets into a class so you could pull out member data and display it
(debugger style). It would also be very useful for doing run time
binding between classes, scripts...etc.

Yes, you could embedd the information in a class, decorate the members
with some reflection template or other such things, but this is very
invasive. There are a lot of times when you would like to have
unrelated class A and B and you would like to (at runtime) create a
small binding object that copies some member(s) of A into B
periodically. Of course, if you generated the offsets for A and B you
could remember the member types also, and not bind incompatible types.

I haven't seen a good approach for doing this.

re: offsetof / non-POD structs

Dave wrote:[color=blue]
> "David Harmon" <source@netcom.com> wrote in message
> news:44746420.793115609@news.west.earthlink.net...[color=green]
> > On Tue, 13 Dec 2005 15:51:12 -0700 in comp.lang.c++, "Dave"
> > <better_cs_now@yahoo.com> wrote,[color=darkred]
> > >I would like to use offsetof on a non-POD struct, but of course this is
> > >undefined. How else may I get the same effect?[/color]
> >
> > Use pointer-to-member (pretty esoteric.)
> > See Stroustrup section 15.5[/color]
>
> I have no guarantee that a pointer-to-member is implemented as a simple
> offset. It can be anything at all at the discretion of the compiler
> implementor![/color]

You don't have any guarantee that the relation between an object
pointer and
a member inside that object is even representable as a simple offset.
In those
cases, a compiler implementor simply has no choice, nor do you.

HTH,
Michiel Salters

re: offsetof / non-POD structs

On 13 Dec 2005 18:46:45 -0800, greg.corson@gmail.com wrote:
[color=blue]
>I don't know what the poster really wants this for, but the main use I
>can see for something like this is doing introspection/runtime binding.
> There are many times when it would be REAL handy to be able to have
>offsets into a class so you could pull out member data and display it
>(debugger style). It would also be very useful for doing run time
>binding between classes, scripts...etc.
>
>Yes, you could embedd the information in a class, decorate the members
>with some reflection template or other such things, but this is very
>invasive. There are a lot of times when you would like to have
>unrelated class A and B and you would like to (at runtime) create a
>small binding object that copies some member(s) of A into B
>periodically. Of course, if you generated the offsets for A and B you
>could remember the member types also, and not bind incompatible types.
>
>I haven't seen a good approach for doing this.[/color]

What's wrong with having a special class which is only declared and
defined for debug builds, and which is a friend of all classes which
need it? Then you can access whatever needs to be accessed.

--
Bob Hairgrove
NoSpamPlease@Home.com

re: offsetof / non-POD structs

David Harmon wrote:[color=blue]
> On Tue, 13 Dec 2005 17:24:21 -0700 in comp.lang.c++, "Dave"
> <better_cs_now@yahoo.com> wrote,[color=green]
> >
> >I have no guarantee that a pointer-to-member is implemented as a simple
> >offset. It can be anything at all at the discretion of the compiler
> >implementor![/color]
>
> Indeed it is (probably) not a simple offset, and cannot be in order
> to do everything in the presence of non-POD object features. But it
> does have "the same effect" for many of the purposes where you might
> legitimately use an offset in old C.
>
> I am sure you do not want to violate object encapsulation, type
> safety, or anything like that. So, what are you trying to
> accomplish?[/color]

I had a problem the other day where I thought I was going to need the
old offset macro. The problem was that I had a struct that had several
structs representing different types of devices and inside of these
structs where different fields for each struct. I wanted to have a
variable store a pointer to one of those fields but I needed in
relation to the original struct. AFAICT there is no way to define a
pointer to a member of a member of a struct or class so I couldn't use
member pointers.

You can do:

int Outer::Inner::*x = & Outer::Inner::var

But how would you do:

int Outer::*x = &Outer::Inner::var

At any rate I was dealing with a POD so the whole address of member of
null macro would work.

However, instead of doing this I decided to refactor the structure of
the classes I needed to track. I ended up with a better and more
elegant sollution.

re: offsetof / non-POD structs

On 14 Dec 2005 09:12:58 -0800, roberts.noah@gmail.com wrote:
[color=blue]
>
>David Harmon wrote:[color=green]
>> On Tue, 13 Dec 2005 17:24:21 -0700 in comp.lang.c++, "Dave"
>> <better_cs_now@yahoo.com> wrote,[color=darkred]
>> >
>> >I have no guarantee that a pointer-to-member is implemented as a simple
>> >offset. It can be anything at all at the discretion of the compiler
>> >implementor![/color]
>>
>> Indeed it is (probably) not a simple offset, and cannot be in order
>> to do everything in the presence of non-POD object features. But it
>> does have "the same effect" for many of the purposes where you might
>> legitimately use an offset in old C.
>>
>> I am sure you do not want to violate object encapsulation, type
>> safety, or anything like that. So, what are you trying to
>> accomplish?[/color]
>
>I had a problem the other day where I thought I was going to need the
>old offset macro. The problem was that I had a struct that had several
>structs representing different types of devices and inside of these
>structs where different fields for each struct. I wanted to have a
>variable store a pointer to one of those fields but I needed in
>relation to the original struct. AFAICT there is no way to define a
>pointer to a member of a member of a struct or class so I couldn't use
>member pointers.
>
>You can do:
>
>int Outer::Inner::*x = & Outer::Inner::var
>
>But how would you do:
>
>int Outer::*x = &Outer::Inner::var
>
>At any rate I was dealing with a POD so the whole address of member of
>null macro would work.
>
>However, instead of doing this I decided to refactor the structure of
>the classes I needed to track. I ended up with a better and more
>elegant sollution.[/color]

If the innermost member is a data member, just use a regular pointer.

--
Bob Hairgrove
NoSpamPlease@Home.com

re: offsetof / non-POD structs

Bob Hairgrove wrote:[color=blue]
> On 14 Dec 2005 09:12:58 -0800, roberts.noah@gmail.com wrote:
>[color=green]
> >
> >David Harmon wrote:[color=darkred]
> >> On Tue, 13 Dec 2005 17:24:21 -0700 in comp.lang.c++, "Dave"
> >> <better_cs_now@yahoo.com> wrote,
> >> >
> >> >I have no guarantee that a pointer-to-member is implemented as a simple
> >> >offset. It can be anything at all at the discretion of the compiler
> >> >implementor!
> >>
> >> Indeed it is (probably) not a simple offset, and cannot be in order
> >> to do everything in the presence of non-POD object features. But it
> >> does have "the same effect" for many of the purposes where you might
> >> legitimately use an offset in old C.
> >>
> >> I am sure you do not want to violate object encapsulation, type
> >> safety, or anything like that. So, what are you trying to
> >> accomplish?[/color]
> >
> >I had a problem the other day where I thought I was going to need the
> >old offset macro. The problem was that I had a struct that had several
> >structs representing different types of devices and inside of these
> >structs where different fields for each struct. I wanted to have a
> >variable store a pointer to one of those fields but I needed in
> >relation to the original struct. AFAICT there is no way to define a
> >pointer to a member of a member of a struct or class so I couldn't use
> >member pointers.
> >
> >You can do:
> >
> >int Outer::Inner::*x = & Outer::Inner::var
> >
> >But how would you do:
> >
> >int Outer::*x = &Outer::Inner::var
> >
> >At any rate I was dealing with a POD so the whole address of member of
> >null macro would work.
> >
> >However, instead of doing this I decided to refactor the structure of
> >the classes I needed to track. I ended up with a better and more
> >elegant sollution.[/color]
>
> If the innermost member is a data member, just use a regular pointer.[/color]

For some reason when I delete things and make new ones stuff tends to
get moved around and I haven't quite established why, but my pointers
become invalid at that point!! Sometimes when my pointers are created
there is no variable of type "Outer" and for some reason my program
blew up when I tried to get the direct addresses of its contents. Very
unsettling.

Question: Why is it that people assume your an idiot when you post to
usenet and don't spell out every obvious detail? Obviously if a simple
direct address to a variable would do there is no need to try wierd
shit like member pointers... I'm not a COMPLETE moron.

re: offsetof / non-POD structs

On 14 Dec 2005 12:25:44 -0800, roberts.noah@gmail.com wrote:
[color=blue]
>Question: Why is it that people assume your an idiot when you post to
>usenet and don't spell out every obvious detail? Obviously if a simple
>direct address to a variable would do there is no need to try wierd
>shit like member pointers... I'm not a COMPLETE moron.[/color]

I'm sure you aren't, and I was not implying anything like that. The
point is, you cannot use a pointer-to-member unless you have an object
upon which to call it. As someone else pointed out to me long ago,
that means that there is practically no situation where a PTM, if it's
pointing to a data member, cannot be replaced by a regular pointer.
This is IMHO not terribly obvious, but maybe you think it is.

Member pointers don't qualify as "wierd shit" in my book. Calculating
the offsets of class members does, though.

--
Bob Hairgrove
NoSpamPlease@Home.com

re: offsetof / non-POD structs

Bob Hairgrove wrote:[color=blue]
>... you cannot use a pointer-to-member unless you have an object
> upon which to call it. As someone else pointed out to me long ago,
> that means that there is practically no situation where a PTM, if it's
> pointing to a data member, cannot be replaced by a regular pointer.[/color]

Not entirely true. You can use a PTM without having an object of the
desired type. Say I have a person class. It's ctor takes a name and
age. It has methods SetBusinessAddress and SetHomeAddress.
Now I'm reading in an XML file with person records. It has a field
name, an address field (with an address-type) and an age. After
parsing the address, I'd store the address-type in a PTM named
SetAddress until I read the age and have constructed the person
object. I can then call SetAddress on the constructed object.

Sure, I could have used a bool, but that's limited. Outlook has
an address type "Other" - neither home nor business. The PTM
solution continues to work.

HTH,
Michiel Salters