Re: Trouble with offsetof

From: Jack Klein (jackklein_at_spamcop.net)
Date: 01/09/05


Date: Sun, 09 Jan 2005 11:52:10 -0600

On Sat, 08 Jan 2005 12:06:24 -0500, Exits Funnel
<exitsNOfunnelSPAM@yahoo.com> wrote in comp.lang.c++:

> Consider this code which is a very trimmed down version of some I've
> inherited and am trying to port from windows to g++:
>
> //Begin test1.cpp
> class foo { int i; int j; };
>
> class bar
> {
> bar (int foo::* dataMember)
> :offsetof (foo, *dataMember) //Call this Line (A)
> {
> // int i = offsetof (foo, *dataMember); //Call this Line (B)
> }
> };
> //End test1.cpp
>
> when I try to compile test1.cpp with g++, the compiler has this to say:
>
> test2.cpp: In constructor `bar::bar(int foo::*)':
> test2.cpp:6: syntax error before `;' token
>
> A couple of questions then:
>
> (1) Should the compiler complain? I don't have much experience with
> using the 'pointer to data member' stuff, but based on the research I've
> just done on the net, the code seems reasonable.
>
> (2) If I move the call from the initializer list to the ctor body by
> commenting out line (A) and uncommenting line (B), the compiler error
> becomes:
>
> test2.cpp: In constructor `bar::bar(int foo::*)':
> test2.cpp:8: syntax error before `;' token
> test2.cpp:8: declaration of `dataMember' shadows a parameter
> test2.cpp:8: syntax error before `;' token
>
> So, it seems the original problem persists which is reasonable but now
> there's this additional shadowing issue. It's not clear to me what
> parameer 'dataMember' is shadowing here? If anyone could explain this
> to me it would be great.
>
> Thanks in advance for any feedback!
>
> -exits

offsetof, defined in <stdlib.h> and <cstdlib>, is a macro, not a
function. It does not work on objects at all, but on compile-time
symbols.

The offsetof() macro requires two arguments, the NAME of a structure
(or in C++, POD class) type, and the NAME of a member of that
structure or class. The macro generates, _at compile time_ a value of
type size_t that represents the difference in bytes between the
address of any valid object of that type, and the address of the
specified member within that object.

It is evaluated completely at compile time based on names, never at
run time and can never involve a pointer. The concept of pointers,
let alone dereferencing pointers, does not exist at the early phase of
compilation where macros are expanded.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html


Relevant Pages

  • Re: apparently undefined function called by macro
    ... However, as almost always in Common Lisp;), there are exceptions to this rules: Some top-level forms do indeed have effects at compile time. ... The reason is that you typically want to base subsequent code on your macro definitions, and the compiler must be able to completely macro-expand away these macro definitions as well. ... A system definition allows you to declare that one file of lisp code depends on some other file of lisp code. ...
    (comp.lang.lisp)
  • Re: macro functionality in embedded languages.
    ... One advantage of the macro style is efficiency - the call expands at ... compile time and can be compiled with full optimization. ...
    (comp.lang.lisp)
  • Re: Idea
    ... This is not a method pointer. ... the *value* of ecx at compile time, so cannot set that part of the constant. ... >> original array would not be valid, in the sense that it would not ... >> have any instance data in the method pointers. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Draft standards OK for new compiler and libc?
    ... You said explicitly and incorrectly that moving ... have re-written it so that it would no longer compile with a K&R ... There is a much broader concept, that of a null pointer constant; ...
    (comp.std.c)
  • Re: Please review macro
    ... >>compile time about into what code the particular macro invocation should ... Mind you, at the repl I guess you get both ... dramatic results unless you compile the macro first. ...
    (comp.lang.lisp)