Boost for new compiler
Hi, I apologize if this is a FAQ - I couldn't find much on other compilers I am interested in using boost with a compiler for a DSP - The compiler is somewhat archaic - I'm not using RTTI or exceptions (the compiler supports them but it is currently broken) - the STL has old iostreams and no doubt I will find some other musty corners. I don't have any illusions about getting the whole of boost to compile but I'm sure there are some large pieces that will work OK. I have no problem doing the port myself. I have successfully got shared_ptr and shared_array to work but I needed to make 3 fairly trivial changes to the code to get it to compile. Are boosters interested in folding these changes back into the main source in the interests of making boost more portable or am I on my own here since I am working with an unsupported compiler? I can post the problems I ran into if anyone is interested. Andrew
Eames, Andrew: ...
I have successfully got shared_ptr and shared_array to work but I needed to make 3 fairly trivial changes to the code to get it to compile. Are boosters interested in folding these changes back into the main source in the interests of making boost more portable or am I on my own here since I am working with an unsupported compiler? I can post the problems I ran into if anyone is interested.
If you post the changes you had to do, I'll consider incorporating them into the main source.
I'm using boost 1.34.1. These are the 3 changes I have needed to make so far - I haven't looked at the trunk to see if they are still needed Andrew 1) In shared_ptr.hpp
#if defined(__GNUC__) && (__GNUC__ < 3)
template<class Y> std::ostream & operator<< (std::ostream & os, shared_ptr<Y> const & p) { os << p.get(); return os; }
The #if clause should be something more generic as to whether old-style streams are being used - I didn't see a suitable macro for this 2) In shared_ptr.hpp //My compiler doesn't support inline functions with varargs Replace <<inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) <<{ <<} With
inline void sp_enable_shared_from_this( shared_count const & /*pn*/) { } template <class T> void sp_enable_shared_from_this( shared_count const & /*pn*/,T arg1, ... ) { }
I have successfully got shared_ptr and shared_array to work but I needed to make 3 fairly trivial changes to the code to get it to compile. Are boosters interested in folding these changes back into the main source in the interests of making boost more portable or am I on my own here since I am working with an unsupported compiler? I can post the
3) In sp_counted_impl.hpp,typeid is used. I gather from other posts that this will be addressed in 1.35 :) FWIW, I put this in my copy (there is probably something more elegant) virtual void * get_deleter( std::type_info const & ti ) { #if !defined(BOOST_NO_TYPEID) return ti == typeid(D)? &del: 0; #else assert(0); return 0; #endif } -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Saturday, December 15, 2007 11:27 AM To: boost@lists.boost.org Subject: Re: [boost] Boost for new compiler Eames, Andrew: ... problems
I ran into if anyone is interested.
If you post the changes you had to do, I'll consider incorporating them into the main source. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. Teach CanIt if this mail (ID 10387259) is spam: Spam: http://mail-gw.cognex.com/canit/b.php?c=s&i=10387259&m=cf9697a07d34 Not spam: http://mail-gw.cognex.com/canit/b.php?c=n&i=10387259&m=cf9697a07d34 Forget vote: http://mail-gw.cognex.com/canit/b.php?c=f&i=10387259&m=cf9697a07d34 ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
Hello, On 18/12/2007, Eames, Andrew <andrew@cognex.com> wrote:
2)
In shared_ptr.hpp
//My compiler doesn't support inline functions with varargs
Replace
<<inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) <<{ <<}
With
inline void sp_enable_shared_from_this( shared_count const & /*pn*/) { } template <class T> void sp_enable_shared_from_this( shared_count const & /*pn*/,T arg1, ... ) { }
Inline should only be used as a hint, so this would qualify as a compiler error, and a pretty odd one at that. Maybe it is a good idea not to use the inline keyword in that compiler (possibly as harsh as #define inline <nothing>) or to request that the compiler writers find out what's causing this? If that is not possible, you might be able to use SFINAE to remove the overload or to make a define for removing it on compilers which have that bug. My first inclination is to fix the compiler as it handles a hint wrongly (and can just ignore it). Regards, Peter
I'll file a bug report with the compiler vendor but whether it gets fixed or not is not within my control :) Andrew -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Bindels Sent: Tuesday, December 18, 2007 10:39 AM To: boost@lists.boost.org Subject: Re: [boost] Boost for new compiler Hello, On 18/12/2007, Eames, Andrew <andrew@cognex.com> wrote:
2)
In shared_ptr.hpp
//My compiler doesn't support inline functions with varargs
Replace
<<inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) <<{ <<}
With
inline void sp_enable_shared_from_this( shared_count const & /*pn*/) { } template <class T> void sp_enable_shared_from_this( shared_count const & /*pn*/,T arg1, ... ) { }
Inline should only be used as a hint, so this would qualify as a compiler error, and a pretty odd one at that. Maybe it is a good idea not to use the inline keyword in that compiler (possibly as harsh as #define inline <nothing>) or to request that the compiler writers find out what's causing this? If that is not possible, you might be able to use SFINAE to remove the overload or to make a define for removing it on compilers which have that bug. My first inclination is to fix the compiler as it handles a hint wrongly (and can just ignore it). Regards, Peter _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. Teach CanIt if this mail (ID 10405522) is spam: Spam: http://mail-gw.cognex.com/canit/b.php?c=s&i=10405522&m=a1734039d3ba Not spam: http://mail-gw.cognex.com/canit/b.php?c=n&i=10405522&m=a1734039d3ba Forget vote: http://mail-gw.cognex.com/canit/b.php?c=f&i=10405522&m=a1734039d3ba ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
Eames, Andrew wrote:
Hi,
I apologize if this is a FAQ - I couldn't find much on other compilers
I am interested in using boost with a compiler for a DSP - The compiler is somewhat archaic - I'm not using RTTI or exceptions (the compiler supports them but it is currently broken) - the STL has old iostreams and no doubt I will find some other musty corners. I don't have any illusions about getting the whole of boost to compile but I'm sure there are some large pieces that will work OK. I have no problem doing the port myself.
RTTI is pretty useful, and I think quite a few libraries rely on dynamic_cast at least once. For instance Boost Logging Lib ( http://torjo.com/log2/ ) relies on it once - I guess you could get 'round it. I guess the 1M$ question is : why do you need that specific compiler? Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
John Torjo wrote:
Eames, Andrew wrote:
Hi,
I apologize if this is a FAQ - I couldn't find much on other compilers
I am interested in using boost with a compiler for a DSP - The compiler is somewhat archaic - I'm not using RTTI or exceptions (the compiler supports them but it is currently broken) - the STL has old iostreams and no doubt I will find some other musty corners. I don't have any illusions about getting the whole of boost to compile but I'm sure there are some large pieces that will work OK. I have no problem doing the port myself.
RTTI is pretty useful, and I think quite a few libraries rely on dynamic_cast at least once.
For instance Boost Logging Lib ( http://torjo.com/log2/ ) relies on it once - I guess you could get 'round it.
I guess the 1M$ question is : why do you need that specific compiler?
I'm in a similar situation where I have to use a specific compiler because it's the only compiler supported by the closed SDK for the platform we're developing for. Right now I, unfortunately, can only use the Torjo logging library for a windows port of the application because the target platform doesn't support RTTI (exceptions are fine). This is annoying because the debuggers for these embedded devices are sometimes flaky and logging on device is sometimes the only way to fix bugs. So we have to have another simple homegrown logging library for on device logging. There are many other Boost libraries that we can't use, at least out of the box, because they use RTTI in one or two places where they probably don't have to. For instance lexical_cast uses it to provide extra information to the bad_lexical_cast exception but functions just fine without it. I didn't dig enough into the implementation but it looks like Boost.Function and Boost.Variant may be in a similar boat. I think shared_ptr used to have this issue but got changed after 1.34. I wish more libraries would follow its lead if possible. - Michael Marcin
Michael Marcin wrote:
John Torjo wrote:
Eames, Andrew wrote:
Hi,
I apologize if this is a FAQ - I couldn't find much on other compilers
I am interested in using boost with a compiler for a DSP - The compiler is somewhat archaic - I'm not using RTTI or exceptions (the compiler supports them but it is currently broken) - the STL has old iostreams and no doubt I will find some other musty corners. I don't have any illusions about getting the whole of boost to compile but I'm sure there are some large pieces that will work OK. I have no problem doing the port myself.
RTTI is pretty useful, and I think quite a few libraries rely on dynamic_cast at least once.
For instance Boost Logging Lib ( http://torjo.com/log2/ ) relies on it once - I guess you could get 'round it.
I guess the 1M$ question is : why do you need that specific compiler?
I'm in a similar situation where I have to use a specific compiler because it's the only compiler supported by the closed SDK for the platform we're developing for.
Right now I, unfortunately, can only use the Torjo logging library for a windows port of the application because the target platform doesn't support RTTI (exceptions are fine). This is annoying because the debuggers for these embedded devices are sometimes flaky and logging on device is sometimes the only way to fix bugs. So we have to have another simple homegrown logging library for on device logging.
There are many other Boost libraries that we can't use, at least out of the box, because they use RTTI in one or two places where they probably don't have to. For instance lexical_cast uses it to provide extra information to the bad_lexical_cast exception but functions just fine without it. I didn't dig enough into the implementation but it looks like Boost.Function and Boost.Variant may be in a similar boat.
I think shared_ptr used to have this issue but got changed after 1.34. I wish more libraries would follow its lead if possible.
You can raise the viability of the issue by submitting patches. Where RTTI is useful, but not essential, I'd personally rather not remove it entirely. Instead, the code could respond to a macro (BOOST_NO_RTTI perhaps) and avoid usage when present. But the default would be to user RTTI on the theory it is usually available. --Beman
Beman Dawes:
Where RTTI is useful, but not essential, I'd personally rather not remove it entirely. Instead, the code could respond to a macro (BOOST_NO_RTTI perhaps) and avoid usage when present.
In non-essential scenarios, often the proper macro to test is BOOST_NO_TYPEID: http://svn.boost.org/trac/boost/ticket/1104 since typeid(T) does not require the R in RTTI and may be supported even when RTTI is off (under MSVC for example).
Peter Dimov wrote:
Beman Dawes:
Where RTTI is useful, but not essential, I'd personally rather not remove it entirely. Instead, the code could respond to a macro (BOOST_NO_RTTI perhaps) and avoid usage when present.
In non-essential scenarios, often the proper macro to test is BOOST_NO_TYPEID:
http://svn.boost.org/trac/boost/ticket/1104
since typeid(T) does not require the R in RTTI and may be supported even when RTTI is off (under MSVC for example).
Good point. --Beman
typeid() doesn't require RTTI on MSVC? That's news to me. What about GCC and other popular [cross-platform] compilers? On Dec 16, 2007 1:50 PM, Beman Dawes <bdawes@acm.org> wrote:
Peter Dimov wrote:
Beman Dawes:
Where RTTI is useful, but not essential, I'd personally rather not remove it entirely. Instead, the code could respond to a macro (BOOST_NO_RTTI perhaps) and avoid usage when present.
In non-essential scenarios, often the proper macro to test is BOOST_NO_TYPEID:
http://svn.boost.org/trac/boost/ticket/1104
since typeid(T) does not require the R in RTTI and may be supported even when RTTI is off (under MSVC for example).
Good point.
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm in a similar situation where I have to use a specific compiler because it's the only compiler supported by the closed SDK for the platform we're developing for.
Right now I, unfortunately, can only use the Torjo logging library for a windows port of the application because the target platform doesn't support RTTI (exceptions are fine). This is annoying because the
So lets assume I make it run when no RTTI is available. Does your compiler allow partial specialization? Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
John Torjo wrote:
I'm in a similar situation where I have to use a specific compiler because it's the only compiler supported by the closed SDK for the platform we're developing for.
Right now I, unfortunately, can only use the Torjo logging library for a windows port of the application because the target platform doesn't support RTTI (exceptions are fine). This is annoying because the
So lets assume I make it run when no RTTI is available. Does your compiler allow partial specialization?
Yes partial specialization works just fine AFAICT. I use MPL and Fusion in several places so it seems to cope pretty well with template trickery.
participants (7)
-
Beman Dawes -
Eames, Andrew -
John Torjo -
Michael Marcin -
Peter Bindels -
Peter Dimov -
Robert Dailey