recent sigc++ and Objective C/Cocoa/Carbon

[Paul Davis]

looks like one or more of Objective C/Cocoa/Carbon has taken the
hairbrained step of #define-ing "nil". this makes this construction:

   struct nil ....

in functors/functor_trait.h a little dubious.

in fact, all these headers on OS X 10.4 include "#define nil" ...

/Developer/SDKs/MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/CarbonCore/MacTypes.h
/Developer/SDKs/MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/MacTypes.h
/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/MacTypes.h
/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObjCRuntime.h
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/objc/objc.h
/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/CFMCarbon/CarbonCore/MacTypes.h
/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/CFMCarbon/MacTypes.h
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/MacTypes.h
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObjCRuntime.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/objc/objc.h
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/MacTypes.h
/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObjCRuntime.h

clearly, ObjC/Cocoa/Carbon are in the wrong, but would it be wise to
protect sigc++ from this stupidity?

--p


_______________________________________________
libsigc-list mailing list
libsigc-list@...
http://mail.gnome.org/mailman/listinfo/libsigc-list

[James Lin-2]

Paul Davis wrote:
>
> looks like one or more of Objective C/Cocoa/Carbon has taken the
> hairbrained step of #define-ing "nil". this makes this construction:
>
>    struct nil ....
>
> in functors/functor_trait.h a little dubious.

You might want to check out this earlier thread:

http://mail.gnome.org/archives/libsigc-list/2006-June/msg00003.html

=/

- James
_______________________________________________
libsigc-list mailing list
libsigc-list@...
http://mail.gnome.org/mailman/listinfo/libsigc-list

[Paul Davis]

On Thu, 2008-05-29 at 13:33 -0700, James Lin (MTS) wrote:

> Paul Davis wrote:
> >
> > looks like one or more of Objective C/Cocoa/Carbon has taken the
> > hairbrained step of #define-ing "nil". this makes this construction:
> >
> >    struct nil ....
> >
> > in functors/functor_trait.h a little dubious.
>
> You might want to check out this earlier thread:
>
> http://mail.gnome.org/archives/libsigc-list/2006-June/msg00003.html
>

so, the problem wasn't solved.

i took the gordian knot approach:

#ifdef nil
#undef nil
#endif

in functor_trait.h, and that fixed all the problems that I encountered.

its a bit heavy handed, and not really appropriate.

the problem that murray discovered was that somewhat inadvertently,
sigc::nil is used by almost every slot<> template. this means that it is
impossible to rename sigc::nil without breaking the gtkmm ABI.
therefore, fixing this means either:

        * break the gtkmm ABI (not nice, since this is supposed to be a sigc
fix)
        * use dastardly macro stuff
        * use heavy handed macro stuff and tell people that they can't
mix-n-match Cocoa/Carbon/ObjC with sigc++ without very, very careful use
of header inclusion order

i don't see any other solutions. anyone else?

--p
 


_______________________________________________
libsigc-list mailing list
libsigc-list@...
http://mail.gnome.org/mailman/listinfo/libsigc-list