on Wed Mar 19 2008, "Phil Bouchard" <philippe-AT-fornux.com> wrote:
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:47DFF458.7010409@providere-consulting.com...
[...]
Which compilers? IMO, you shouldn't make the code even more obscure until it's known for certain to be a problem.
Well 0 is considered to be a null pointer, not a pointer to 0x0000. This can potentially be replaced by "nullptr" in the next revision, which shouldn't be assumed to be a pointer to 0x0000. Having a non-null constant removes this nullness ambiguity.
I see there is a BOOST_PYTHON_OFFSETOF macro that exists and which uses this technique. It is unfortunate offsetof() doesn't take a real pointer-to-member address.
That's only there because one old compiler's "standard" offsetof macro was incorrectly generating errors, even for POD types. It's not a justification for anything; just a workaround for a broken compiler. -- Dave Abrahams Boost Consulting http://boost-consulting.com