offsetof / non-POD structs

[Dave]

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

 

[Victor Bazarov]

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?

You cannot.

 

[Bob Hairgrove]

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

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

 

[David Harmon]

On Tue, 13 Dec 2005 15:51:12 -0700 in comp.lang.c++, "Dave"

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?

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

 

[Dave]

On Tue, 13 Dec 2005 15:51:12 -0700 in comp.lang.c++, "Dave"


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

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!

 

[Simon Biber]

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!

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.

 

[David Harmon]

On Tue, 13 Dec 2005 17:24:21 -0700 in comp.lang.c++, "Dave"

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?

 

[greg.corson]

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.

 

[Michiel.Salters]

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!

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

 

[Bob Hairgrove]

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.

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.

 

[roberts.noah]

On Tue, 13 Dec 2005 17:24:21 -0700 in comp.lang.c++, "Dave"


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?

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.

 

[Bob Hairgrove]

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.

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

 

[roberts.noah]

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

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.

 

[Bob Hairgrove]

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.

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.

 

[Michiel.Salters]

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

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