Hallo, everybody. As you probably know Borland released their new C++ product, BCB 2006, right after Boost 1.33.1 came out. As a result users of this product are faced with a longish period of time without a version of Boost that supports it. Moreover, given that standard compliance doesn't seem to have increased all that much with the new compiler it remains to be seen how many of the libraries that currently are compatible with Borland compilers will continue to be as they evolve. As a stopgap measure I created the bcbboost project in SourceForge to collect patches against Boost 1.33.1 that make it possible to use Boost with BCB 2006. Right now there's only the minimum necessary to build the libraries to the same level as BCB6. I kind of hope that some of those interested will rather join forces than repeat the same steps over and over each on their own. I also hope to submit to Boost any newly discovered fix that is applicable to the main development line. For those interested: http://sourceforge.net/projects/bcbboost Comments, suggestions and bug reports are obviously welcome. Help is even more welcome :-) Cheers, Nicola Musatti
On 1/24/06 6:11 PM, "Nicola Musatti" <Nicola.Musatti@gmail.com> wrote:
As you probably know Borland released their new C++ product, BCB 2006, right after Boost 1.33.1 came out. As a result users of this product are faced with a longish period of time without a version of Boost that supports it.
Moreover, given that standard compliance doesn't seem to have increased all that much with the new compiler it remains to be seen how many of the libraries that currently are compatible with Borland compilers will continue to be as they evolve. [TRUNCATE]
Did you start by resetting all the Boost.Config macros then running the configuration tests? Check <http://www.boost.org/libs/config/config.htm> for details. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Sorry for the delay in answering. Daryle Walker wrote:
Did you start by resetting all the Boost.Config macros then running the configuration tests? Check <http://www.boost.org/libs/config/config.htm> for details.
Not really. Although I'm aware of how compilers are configured in Boost and of the config tests, this compiler appears to be too similar to the previous one to be worth such an effort. I tried tweaking boost\config\compiler\borland.hpp to see if any workaround could be removed, but I ended up almost just bumping up the release number. Cheers, Nicola Musatti
On Wed, 25 Jan 2006 00:11:25 +0100, Nicola Musatti <Nicola.Musatti@gmail.com> wrote: <snip>
As a stopgap measure I created the bcbboost project in SourceForge to collect patches against Boost 1.33.1 that make it possible to use Boost with BCB 2006. Right now there's only the minimum necessary to build the libraries to the same level as BCB6. I kind of hope that some of those interested will rather join forces than repeat the same steps over and over each on their own.
<snip>
Cheers, Nicola Musatti
Hi all, I am helping Niciola in his effort, and I have already compiled <libst/config/test/config_test.cpp>, by changing one line in <boost/config/user.hpp>, it now looks: #define BOOST_COMPILER_CONFIG <boost/config/compiler/borland_5_8_1_hpp> And the starting with an empty compiler configuration, I have been able to detect that the following defines are needed: BOOST_NO_FUNCTION_TEMPLATE_ORDERING BOOST_BCB_PARTIAL_SPECIALIZATION_BUG BOOST_NO_DEPENDENT_NESTED_DERIVATIONS BOOST_NO_IS_ABSTRACT BOOST_NO_MEMBER_TEMPLATE_FRIENDS BOOST_NO_PRIVATE_IN_AGGREGATE BOOST_NO_SFINAE BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYEPNAME_BASE BOOST_NO_USING_TEMPLATE The first interesting result is that BDS2006 contains both a conforming and a non-conforming swprintf. The non-conforming one is located in <stdio.h>, and it is the reason for previous versions of BCB to #define BOOST_NO_SWPRINTF. But with the inclusion of dinkumware library, ther is a conforming swprintf in <wchar.h>. But to get it to wotk, you must include <wchar.h> before <stdio.h>, so I have been forced to change <libs/config/test/boost_no_swprintf.ipp> to change the inclusion order. So I feel I must submit this improvement to BOOST, just in case this header ordering is important to be taken into account for future releases. Best regards, Zara
On 2/14/06, Zara <yozara@terra.es> wrote:
[...] I am helping Niciola in his effort, and I have already compiled <libst/config/test/config_test.cpp>, by changing one line in <boost/config/user.hpp>, it now looks: #define BOOST_COMPILER_CONFIG <boost/config/compiler/borland_5_8_1_hpp>
This will have to be integrated to the standard borland.hpp file, though. And the starting with an empty compiler configuration, I have been
able to detect that the following defines are needed: BOOST_NO_FUNCTION_TEMPLATE_ORDERING BOOST_BCB_PARTIAL_SPECIALIZATION_BUG BOOST_NO_DEPENDENT_NESTED_DERIVATIONS BOOST_NO_IS_ABSTRACT BOOST_NO_MEMBER_TEMPLATE_FRIENDS BOOST_NO_PRIVATE_IN_AGGREGATE BOOST_NO_SFINAE BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYEPNAME_BASE BOOST_NO_USING_TEMPLATE
Unfortunately this set of macros appears to break things that currently build and/or pass tests with bcbboost. I'm looking into it, but I'm not convinced that we'll end up changing the current configuration. The first interesting result is that BDS2006 contains both a
conforming and a non-conforming swprintf. The non-conforming one is located in <stdio.h>, and it is the reason for previous versions of BCB to #define BOOST_NO_SWPRINTF.
But with the inclusion of dinkumware library, ther is a conforming swprintf in <wchar.h>. But to get it to wotk, you must include <wchar.h> before <stdio.h>, so I have been forced to change <libs/config/test/boost_no_swprintf.ipp> to change the inclusion order.
But that's how it already is in the 1.33.1 distribution, isn't it? Cheers, Nicola Musatti
participants (4)
-
Daryle Walker -
Nicola Musatti -
Nicola Musatti
-
Zara