floating_point_promotion question
including the header file floating_point_promotion.hpp results in a compile error with the borland compilers. Is there any chance this could be enhanced to avoid this? This became apparent when building serialization library with borland compilers. This occurs because, the header is included via a the "convenience" header type_traits.hpp. Which in turn is used by spirit Note that this is an example where the usage of a "convenience" header turns out to be "inconvenient". In this case it makes the serialization libary and spirit dependent not only on the code existent when these libraries were written, but on future code as well. Robert Ramey
Robert Ramey wrote:
including the header file floating_point_promotion.hpp results in a compile error with the borland compilers.
Is there any chance this could be enhanced to avoid this?
I'll try and look into it, which Borland version were you targeting 5.6.4 or the new 5.8.2?
Note that this is an example where the usage of a "convenience" header turns out to be "inconvenient". In this case it makes the serialization libary and spirit dependent not only on the code existent when these libraries were written, but on future code as well.
:-( John.
John Maddock wrote:
Robert Ramey wrote:
including the header file floating_point_promotion.hpp results in a compile error with the borland compilers.
Is there any chance this could be enhanced to avoid this?
I'll try and look into it, which Borland version were you targeting 5.6.4 or the new 5.8.2?
Actually, my local tests still include 5.51 and 5.64 but not 5.82. The issue occurs with both of these compilers. It stems from the fact that the compiler doesn't really distinguish between template<class T> f(T &t) and template<class T> f(const T & t) As this is a well know problem already addressed in other libraries I had hoped that the original author would find it easy to fix. This is the way I set things up some time ago and I haven't been motivated to "upgrade" it.
Note that this is an example where the usage of a "convenience" header turns out to be "inconvenient". In this case it makes the serialization libary and spirit dependent not only on the code existent when these libraries were written, but on future code as well.
:-(
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Here is what the compiler says: C:\BoostHead\libs\serialization\build\../src/xml_grammar.cpp: Support for Borland compilers older than BCB2006 is deprecated in Boost 1.34 Error E2238 C:\BoostHead\boost/type_traits/floating_point_promotion.hpp 32: Multiple declaration for 'floating_point_promotion<float>' Error E2344 C:\BoostHead\boost/type_traits/floating_point_promotion.hpp 25: Earlier declaration of 'floating_point_promotion<float>' Error E2238 C:\BoostHead\boost/type_traits/floating_point_promotion.hpp 38: Multiple declaration for 'floating_point_promotion<float>' Error E2344 C:\BoostHead\boost/type_traits/floating_point_promotion.hpp 25: Earlier declaration of 'floating_point_promotion<float>' Error E2238 C:\BoostHead\boost/type_traits/floating_point_promotion.hpp 44: Multiple declaration for 'floating_point_promotion<float>' Error E2228 C:\BoostHead\boost/type_traits/floating_point_promotion.hpp 44: Too many error or warning messages *** 6 errors in Compile *** "bcc32" -j5 -g255 -q -c -P -w -Ve -Vx -a8 -b- -DBOOST_LIB_DIAGNOSTIC=1 -v -Od -vi- -tWC -tWR -tWC -WM- -DBOOST_ALL_NO_LIB=1 -w-8080 -w-8071 -w-8057 -w-8062 -w-8008 -w-0018 -w-8066 -w-8001 -I"c:\BoostHead\bin\boost\libs\serialization\build" -I"c:\spirit161" -I"C:\BoostHead" -o"c:\BoostHead\bin\boost\libs\serialization\build\libboost_serialization.lib\borland-5_5_1\debug\xml_grammar.obj" "C:\BoostHead\libs\serialization\build\../src/xml_grammar.cpp" I suspect that const and volitile versions have to be conditioned on BOOST_NO_CV_SPECIALIZATIONSas described in http://www.boost.org/libs/config/config.htm#defects Alexander Nasonov wrote:
Robert Ramey <ramey <at> rrsd.com> writes:
including the header file floating_point_promotion.hpp results in a compile error with the borland compilers.
What kind of error? CV specializations?
Robert Ramey wrote:
Here is what the compiler says:
Robert, I can only reproduce this with Borland 5.5.1, versions 5.6.4 and 5.8.2 are OK. I'll add a workaround to the header to disable inclusion of the promotion code with that compiler, but note that this is a really obsolete compiler now. John.
On my own system I made the following change perhaps I can just check it in? John Maddock wrote:
Robert Ramey wrote:
Here is what the compiler says:
Robert, I can only reproduce this with Borland 5.5.1, versions 5.6.4 and 5.8.2 are OK. I'll add a workaround to the header to disable inclusion of the promotion code with that compiler, but note that this is a really obsolete compiler now.
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
begin 666 floating_point_promotion.hpp M+R\@0V]P>7)I9VAT(#(P,#4@06QE>&%N9&5R($YA<V]N;W8N#0HO+R!$:7-T M<FEB=71E9"!U;F1E<B!T:&4@0F]O<W0@4V]F='=A<F4@3&EC96YS92P@5F5R M<VEO;B Q+C N("A3964-"B\O(&%C8V]M<&%N>6EN9R!F:6QE($Q)0T5.4T5? M,5\P+G1X="!O<B!C;W!Y(&%T#0HO+R!H='1P.B\O=W=W+F)O;W-T+F]R9R], M24-%3E-%7S%?,"YT>'0I#0H-"B-I9FYD968@1DE,15]B;V]S=%]T>7!E7W1R M86ET<U]F;&]A=&EN9U]P;VEN=%]P<F]M;W1I;VY?:'!P7TE.0TQ51$5$#0HC M9&5F:6YE($9)3$5?8F]O<W1?='EP95]T<F%I='-?9FQO871I;F=?<&]I;G1? M<')O;6]T:6]N7VAP<%])3D-,541%1 T*#0HC:6YC;'5D92 \8F]O<W0O8V]N M9FEG+FAP<#X-"@T*+R\@4VAO=6QD(&)E('1H92!L87-T("-I;F-L=61E#0HC M:6YC;'5D92 \8F]O<W0O='EP95]T<F%I=',O9&5T86EL+W1Y<&5?=')A:71? M9&5F+FAP<#X-"@T*;F%M97-P86-E(&)O;W-T('L-"@T*;F%M97-P86-E('1Y M<&5?=')A:71S('L@;F%M97-P86-E(&1E=&%I;"![#0H-"G1E;7!L871E/&-L M87-S(%0^#0IS=')U8W0@9FQO871I;F=?<&]I;G1?<')O;6]T:6]N#0I[#0H@ M(" @='EP961E9B!4('1Y<&4[#0I].PT*#0IT96UP;&%T93P^#0IS=')U8W0@ M9FQO871I;F=?<&]I;G1?<')O;6]T:6]N/&9L;V%T/@T*>PT*(" @('1Y<&5D M968@9&]U8FQE('1Y<&4[#0I].PT*#0HC:68@(2!D969I;F5D*$)/3U-47TY/ M7T-67U-014-)04Q)6D%424].4RD-"@T*=&5M<&QA=&4\/@T*<W1R=6-T(&9L M;V%T:6YG7W!O:6YT7W!R;VUO=&EO;CQF;&]A="!C;VYS=#X-"GL-"B @("!T M>7!E9&5F(&1O=6)L92!C;VYS="!T>7!E.PT*?3L-"@T*=&5M<&QA=&4\/@T* M<W1R=6-T(&9L;V%T:6YG7W!O:6YT7W!R;VUO=&EO;CQF;&]A="!V;VQA=&EL M93X-"GL-"B @("!T>7!E9&5F(&1O=6)L92!V;VQA=&EL92!T>7!E.PT*?3L- M"@T*=&5M<&QA=&4\/@T*<W1R=6-T(&9L;V%T:6YG7W!O:6YT7W!R;VUO=&EO M;CQF;&]A="!C;VYS="!V;VQA=&EL93X-"GL-"B @("!T>7!E9&5F(&1O=6)L M92!C;VYS="!V;VQA=&EL92!T>7!E.PT*?3L-"@T*(V5N9&EF("\O($)/3U-4 M7TY/7T-67U-014-)04Q)6D%424].4PT*#0I]('T-"@T*0D]/4U1?5%1?0558 M7U194$5?5%)!251?1$5&,2@-"B @(" @(&9L;V%T:6YG7W!O:6YT7W!R;VUO M=&EO;@T*(" @("P@5 T*(" @("P@0D]/4U1?1$5$54-%1%]465!%3D%-10T* M(" @(" @("!B;V]S=#HZ='EP95]T<F%I=',Z.F1E=&%I;#HZ9FQO871I;F=? M<&]I;G1?<')O;6]T:6]N/%0^.CIT>7!E#0H@(" @*0T*?0T*#0HC:6YC;'5D M92 \8F]O<W0O='EP95]T<F%I=',O9&5T86EL+W1Y<&5?=')A:71?=6YD968N M:'!P/@T*#0HC96YD:68@+R\@(VEF;F1E9B!&24Q%7V)O;W-T7W1Y<&5?=')A M:71S7V9L;V%T:6YG7W!O:6YT7W!R;VUO=&EO;E]H<'!?24Y#3%5$140-"@T* ` end
John Maddock wrote:
Robert Ramey wrote:
On my own system I made the following change perhaps I can just check it in?
I've no objections: but the impression I get is that lib is so broken with that old compliler that it's a lost cause: none of the tests pass anyway :-(
It seems that the this compiler is too far behind the test library to be tested. The only reason I did kept this up was that it was easy for me to do once I had it setup up. But now its too much so I'll drop it from my local testing - that will "fix" the problem. While we're on the subject - and I know I've mentioned this before - its really bugs me to have the message "compiler xxx - deprecated" show up from the config header. It seems to me that this is something that has to be determined on a library by library basis. Some very simple libraries - e.g. static_assert can just as well remain compatible forever whereas others e.g. lambda will always depend on the latest greatest features. The idea of putting this reality. It also encourages the idea that Boost is a "tightly coupled" group of libraries - an idea that will have to de-emphasized if Boost wants to keep growing. Robert Ramey
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
While we're on the subject - and I know I've mentioned this before - its really bugs me to have the message "compiler xxx - deprecated" show up from the config header. It seems to me that this is something that has to be determined on a library by library basis. Some very simple libraries - e.g. static_assert can just as well remain compatible forever whereas others e.g. lambda will always depend on the latest greatest features. The idea of putting this reality. It also encourages the idea that Boost is a "tightly coupled" group of libraries - an idea that will have to de-emphasized if Boost wants to keep growing.
Understood, although I'm normally the one to make changes to Boost.Config that wasn't one of mine. I guess I could either way on that decision :-/ The point being made I guess, is that we don't test with Borland prior to 5.8.2, certainly not with 5.5.1 anyway. John.
participants (3)
-
Alexander Nasonov -
John Maddock -
Robert Ramey