Hi, tow weeks ago I have attached a patch to https://svn.boost.org/trac/boost/ticket/5010 changing fusion::nil to fusion::nil_ for better compatibility with Obective-C and my case an ancient version of LEDA. Patch attached for convenience. The questions is how to proceed? May I commit the patch? Any documentation to change? Hoping for feedback, Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold@ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke
On 12/20/2011 10:12 PM, Jürgen Hunold wrote:
Hi,
tow weeks ago I have attached a patch to
https://svn.boost.org/trac/boost/ticket/5010
changing fusion::nil to fusion::nil_ for better compatibility with Obective-C and my case an ancient version of LEDA.
Patch attached for convenience.
The questions is how to proceed?
May I commit the patch? Any documentation to change?
Hoping for feedback,
There's also this related ticket: https://svn.boost.org/trac/boost/ticket/6133#comment:5 I was hesitant to have this fix because "nil" is actually part of the API. But, given how pervasive this problem is, it seems the best way to go is to accept the fix and break backward compatibility :( We might have to issue a warning in the docs. I'll apply the patches (change nil to nil_). Thomas, I'm CC'ing you for the heads up. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 12/21/2011 01:03 AM, Joel de Guzman wrote:
I was hesitant to have this fix because "nil" is actually part of the API. But, given how pervasive this problem is, it seems the best way to go is to accept the fix and break backward compatibility :( We might have to issue a warning in the docs.
I'll apply the patches (change nil to nil_). Thomas, I'm CC'ing you for the heads up.
You could add a typedef of nil_ to nil if you detect that you're not in Objective-C++ mode (i.e. check for __OBJC__ or similar)
On 12/21/2011 8:49 AM, Mathias Gaunard wrote:
On 12/21/2011 01:03 AM, Joel de Guzman wrote:
I was hesitant to have this fix because "nil" is actually part of the API. But, given how pervasive this problem is, it seems the best way to go is to accept the fix and break backward compatibility :( We might have to issue a warning in the docs.
I'll apply the patches (change nil to nil_). Thomas, I'm CC'ing you for the heads up.
You could add a typedef of nil_ to nil if you detect that you're not in Objective-C++ mode (i.e. check for __OBJC__ or similar)
That was my recommendation in the other (related) ticket. But it seems it's not a problem unique to Objective-C++. LEDA was also mentioned. Anything else? If it's just Objective-C++ and LEDA, then I might just have to ask for a patch with the appropriate #ifdefs for these problematic compilers/libraries. Let's hear from the OP. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
Hi Joel, On Wednesday, 21. December 2011 06:24:01 Joel de Guzman wrote:
On 12/21/2011 8:49 AM, Mathias Gaunard wrote:
On 12/21/2011 01:03 AM, Joel de Guzman wrote:
I was hesitant to have this fix because "nil" is actually part of the API. But, given how pervasive this problem is, it seems the best way to go is to accept the fix and break backward compatibility :( We might have to issue a warning in the docs.
I'll apply the patches (change nil to nil_). Thomas, I'm CC'ing you for the heads up.
You could add a typedef of nil_ to nil if you detect that you're not in Objective-C++ mode (i.e. check for __OBJC__ or similar)
That was my recommendation in the other (related) ticket. But it seems it's not a problem unique to Objective-C++. LEDA was also mentioned. Anything else? If it's just Objective-C++ and LEDA, then I might just have to ask for a patch with the appropriate #ifdefs for these problematic compilers/libraries.
Let's hear from the OP.
Well, I'm not the OP (at least for the trac tickets ;-)) but I've created a simple patch providing the typedef in boost/fusion/container/list/cons_fwd.hpp if neither LEDA nor Objective-C are used. I doubt if the place is correct, but the logic works works. And while were at it: I have noticed that a lot of headers simply forward "nil" with "struct nil;" instead of using "cons_fwd.hpp" And the typedef should somehow be marked as "deprecated" when used, if this is possible. Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold@ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke
participants (3)
-
Joel de Guzman -
Jürgen Hunold -
Mathias Gaunard