Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > memory offset of member variable within class

Reply
Thread Tools

memory offset of member variable within class

 
 
John Goche
Guest
Posts: n/a
 
      11-06-2006
Hello,

Consider the following macro to get the
memory offset of a class data member:

#define OFFSET(CLASSNAME, MEMBER) ((int) (&((CLASSNAME *) 0)->MEMBER))

Given that 0 may not be the address of
an instance of CLASSNAME, will this
code be legal in standard C++?

Thanks,

JG

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      11-06-2006
John Goche wrote:
> Consider the following macro to get the
> memory offset of a class data member:
>
> #define OFFSET(CLASSNAME, MEMBER) ((int) (&((CLASSNAME *) 0)->MEMBER))
>
> Given that 0 may not be the address of
> an instance of CLASSNAME, will this
> code be legal in standard C++?


Nit: the code is just a definition. It's ignored unless you actually
use the macro. You didn't use the macro.

Now, if the macro is used, then yes, but only if a POD struct is the
first argument.

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


 
Reply With Quote
 
 
 
 
Frederick Gotham
Guest
Posts: n/a
 
      11-06-2006
John Goche:

> Consider the following macro to get the
> memory offset of a class data member:
>
> #define OFFSET(CLASSNAME, MEMBER) ((int) (&((CLASSNAME *) 0)->MEMBER))
>
> Given that 0 may not be the address of
> an instance of CLASSNAME, will this
> code be legal in standard C++?



The C++ Standard does not define the behaviour of the deferencing of a null
pointer.

In your example:

((T*)0)->field

is equal to:

(*(T*)0).field

As you can see, a null pointer is dereferenced.

--

Frederick Gotham
 
Reply With Quote
 
Gianni Mariani
Guest
Posts: n/a
 
      11-06-2006
John Goche wrote:
> Hello,
>
> Consider the following macro to get the
> memory offset of a class data member:
>
> #define OFFSET(CLASSNAME, MEMBER) ((int) (&((CLASSNAME *) 0)->MEMBER))
>
> Given that 0 may not be the address of
> an instance of CLASSNAME, will this
> code be legal in standard C++?



This kind of "address of" operator is replaced with "address of member".
i.e.

struct A { int b; int c; };

int A::* x = & A::b;

x = & A::c;

See if your code can be changed to use this C++ construct.
 
Reply With Quote
 
Kavya
Guest
Posts: n/a
 
      11-06-2006

Frederick Gotham wrote:
>
> The C++ Standard does not define the behaviour of the deferencing of a null
> pointer.
>
> In your example:
>
> ((T*)0)->field
>
> is equal to:
>
> (*(T*)0).field
>
> As you can see, a null pointer is dereferenced.
>


Derefrencing a null pointer in not undefined behavior. Using the
resulting value is undefined behavior.

 
Reply With Quote
 
Gianni Mariani
Guest
Posts: n/a
 
      11-06-2006
Kavya wrote:
> Frederick Gotham wrote:
>> The C++ Standard does not define the behaviour of the deferencing of a null
>> pointer.
>>
>> In your example:
>>
>> ((T*)0)->field
>>
>> is equal to:
>>
>> (*(T*)0).field
>>
>> As you can see, a null pointer is dereferenced.
>>

>
> Derefrencing a null pointer in not undefined behavior. Using the
> resulting value is undefined behavior.
>


Actually, it is undefined. Practically every compiler I know does not
do anything "unexpected", that's a different story. I do think that the
standard should allow it though. Member addresses (T S::*) IMHO is a
much better alternative.
 
Reply With Quote
 
Frederick Gotham
Guest
Posts: n/a
 
      11-06-2006

Just to clarify the misinformation posted in this thread.

(1) The behaviour produced as a result of dereferencing a null pointer is
not defined by the C++ Standard.
(2) The behaviour of pointer arithmetic upon a null pointer is not defined
by the C++ Standard.
(3) The nature of pointer arithmetic is entirely up to the implementor, and
the C++ Standard does not necessitate that it operate in the same fashion
as integer arithmetic.

Therefore, the behaviour of the following expression upon its evaluation is
undefined:

*(T*)0

Furthermore, the behaviour of the following expression upon its evaluation
is undefined:

(*(T*)0).field

As is:

((T*)0)->field

As is:

&((T*)0)->field

Even it the dereferencing of a null pointer did not invoke undefined
behaviour, the evaluation to false of the following expression would still
not be guaranteed.

(T*)0 + 1 - 1

--

Frederick Gotham
 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      11-07-2006
On 6 Nov 2006 13:55:31 -0800, "Kavya" <(E-Mail Removed)> wrote in
comp.lang.c++:

>
> Frederick Gotham wrote:
> >
> > The C++ Standard does not define the behaviour of the deferencing of a null
> > pointer.
> >
> > In your example:
> >
> > ((T*)0)->field
> >
> > is equal to:
> >
> > (*(T*)0).field
> >
> > As you can see, a null pointer is dereferenced.
> >

>
> Derefrencing a null pointer in not undefined behavior. Using the
> resulting value is undefined behavior.


Just plain old flat out wrong. Literally contradicted in so many
words by the C++ standard, no subtle interpretations needed.

Paragraph 4 of 1.9:

"Certain other operations are described in this International Standard
as undefined (for example, the effect of dereferencing the null
pointer). [Note: this International Standard imposes no requirements
on the behavior of programs that contain undefined behavior.]"

Has nothing at all to do with what you do or do not try to do with the
resulting value. In fact, there is no "resulting value". Since the
C++ standard also states (paragraph 1 of 4.10:

"A null pointer constant is an integral constant expression (5.19)
rvalue of integer type that evaluates to zero. A null pointer constant
can be converted to a pointer type; the result is the null pointer
value of that type and is distinguishable from every other value of
pointer to object or pointer to function type."

....a null pointer does not point to any object or function, there
since it points to nothing there is no value to be had.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
Reply With Quote
 
Kavya
Guest
Posts: n/a
 
      11-07-2006

Jack Klein wrote:
> On 6 Nov 2006 13:55:31 -0800, "Kavya" <(E-Mail Removed)> wrote in
> comp.lang.c++:
>
> >
> > Frederick Gotham wrote:
> > >
> > > The C++ Standard does not define the behaviour of the deferencing of a null
> > > pointer.
> > >
> > > In your example:
> > >
> > > ((T*)0)->field
> > >
> > > is equal to:
> > >
> > > (*(T*)0).field
> > >
> > > As you can see, a null pointer is dereferenced.
> > >

> >
> > Derefrencing a null pointer in not undefined behavior. Using the
> > resulting value is undefined behavior.

>
> Just plain old flat out wrong. Literally contradicted in so many
> words by the C++ standard, no subtle interpretations needed.
>
> Paragraph 4 of 1.9:
>
> "Certain other operations are described in this International Standard
> as undefined (for example, the effect of dereferencing the null
> pointer). [Note: this International Standard imposes no requirements
> on the behavior of programs that contain undefined behavior.]"
>
> Has nothing at all to do with what you do or do not try to do with the
> resulting value. In fact, there is no "resulting value". Since the
> C++ standard also states (paragraph 1 of 4.10:
>
> "A null pointer constant is an integral constant expression (5.19)
> rvalue of integer type that evaluates to zero. A null pointer constant
> can be converted to a pointer type; the result is the null pointer
> value of that type and is distinguishable from every other value of
> pointer to object or pointer to function type."
>
> ...a null pointer does not point to any object or function, there
> since it points to nothing there is no value to be had.
>


Sir, can you please look at this
http://www.open-std.org/jtc1/sc22/wg...ctive.html#232

 
Reply With Quote
 
Steve Pope
Guest
Posts: n/a
 
      11-07-2006
If I were an implementer, I would want my implementation to
be free to possibly seg-fault if address zero, or an address one past
and array, were dereferenced.

Unless you'all are using a different definition of "dereference"
than I am...

S.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Comparing offset-aware and offset-naive datetimes? Roy Smith Python 4 01-27-2013 03:17 PM
finding offset of a class member at compile time Rahul C++ 19 11-15-2006 04:56 PM
Nested Class, Member Class, Inner Class, Local Class, Anonymous Class E11 Java 1 10-12-2005 03:34 PM
Cannot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class. DJ Dev ASP .Net 3 02-08-2004 04:19 PM
Translated Offset to Source Offset Lance Riedel XML 2 10-15-2003 03:04 PM



Advertisments