- Boost - lists.boost.org

Build boost on VC 8.0 and with STLport 5.0.2
by Wang Weiwei 10 Jun '06

10 Jun '06

Hello, I'm using boost 1.33.1. Currently I'm using it on VC 7.1 with STL port 5.0. I'm planning to use it on VC 8.0 and still with STLport (but the latest release, 5.0.2). But I could not found a relevant jam file for this configuration. Would it be OK to edit the jam file for VC 7.1? Or can I find an existing jam file from anywhere else? Thanks. min2max

1 0

[endian] Empty Base Class trouble implementing endian wrappers.
by me22 10 Jun '06

10 Jun '06

I've been working on Yuval's suggestion of (little|big|native)_endian wrappers, but ran into a problem. On fundamental types, the wrapper works fine, and Beman's integer_cover_operators made it easy to add support for integer operations. ( However, why does integer_cover_operators use operators<T> and not operators2<T,IntegerType> ? I needed to change that to solve an ambiguity error. ) The problem comes when wrapping my (newly reimplemented) exact type. In that case, deriving the wrapper from integer_cover_operators adds 1 byte : sizeof( long ) = 0x4 sizeof( boost::big_endian< long > ) = 0x4 sizeof( boost::exact<24> ) = 0x3 sizeof( boost::big_endian< boost::exact<24> > ) = 0x4 I could just have a get member function in the wrappers, but that loses much of the elegance. Any suggestions for solving this? ~ Scott McMurray P.S. exact came out quite nicely, imho: CHAR_BIT*sizeof( boost::exact<24>[2] ) = 48 CHAR_BIT*sizeof( boost::exact<24,signed,16>[2] ) = 64 CHAR_BIT*sizeof( boost::exact<32,unsigned>[2] ) = 64 CHAR_BIT*sizeof( boost::exact<8,unsigned,16>[2] ) = 32 ( std::numeric_limits< boost::exact<24> >::min() ) = -8388608 ( std::numeric_limits< boost::exact<24> >::min()-1 ) = 8388607 ( std::numeric_limits< boost::exact<24> >::max() ) = 8388607 ( std::numeric_limits< boost::exact<24> >::max()+1 ) = -8388608 ( std::numeric_limits< boost::exact<24,unsigned> >::min() ) = 0 ( std::numeric_limits< boost::exact<24,unsigned> >::max() ) = 16777215

2 3

regex linking error
by Serhiy Blazhiyevskyy 10 Jun '06

10 Jun '06

Hi, I have linking error while trying to build app with regex. Anybody cam help? thanks --------------------Configuration: TelephonyController - Win32 Release-------------------- Linking... msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual __thiscall std::logic_error::~logic_error(void)" (??1logic_error@std@@UAE@XZ) already defined in ActASRMediaSignalEvent.obj msvcprt.lib(MSVCP60.dll) : warning LNK4006: "public: virtual __thiscall std::logic_error::~logic_error(void)" (??1logic_error@std@@UAE@XZ) already defined in ActASRMediaSignalEvent.obj; second definition ignored Creating library ../../../binaries/Release/TelephonyController.lib and object ../../../binaries/Release/TelephonyController.exp ../../../binaries/Release/TelephonyController.dll : fatal error LNK1169: one or more multiply defined symbols found Error executing link.exe. TelephonyController.dll - 2 error(s), 1 warning(s) Serge blazhiev(a)yahoo.com

2 1

[review] PQS
by Oleg Abrosimov 10 Jun '06

10 Jun '06

I believe that in current state PQS can not be accepted to boost. Reasons: 1) It is almost useless for scientists. (of cause, it is very useful for engineers, though). It lacks or makes it really hard to plug-in different systems, such as C.G.S.E. (centimeter, gramme, second, and intensity of electric field from one electron is given by formula: E = e/r^2. Note, no k coefficient, as in SI), standard model in theoretical physics (velocity of light is 1, plank constant is 1, etc.), relativistic model, where only velocity of light is 1 (it means that dimensions of time and length are equal. length is time and time is length). This list can be expanded dramatically (almost every physical problem can benefit from some sort of special dimensions usage). 2) In PQS concept of dimensional analysis is tightly coupled with concept of units. I believe that they _must_ be uncoupled and implemented independently. Dimensional analysis has its own value even without any units at all. I hope that tomorrow I’ll find time to provide more ideas of what Boost.Dimensions and Boost.Units should be to meet my expectations from such a library. Best regards, Oleg Abrosimov.

2 1

boost::typeof, MSVC7.1 & 8.0, and precompiled headers
by Bertrand Augereau 10 Jun '06

10 Jun '06

Hello to all, I just wanted to let you know that boost::typeof doesn't work (in today CVS) when included in a precompiled header with recent MSVC, because of a (seemingly common in other boost libs) anonymous-namespace error. I'm waiting for boost::typeof to work like a charm in MSVC8 so that I can ditch the evil-hack MSVC7 typeof implementation and migrate to MSVC8 :) Thanks, Bertrand PS : Arkadiy, I took the liberty to CC you because you were the one who pointed me to boost::typeof on clc++m and you seem to be in charge for this :)

4 14

[serialization] BCB2006 support
by Nicola Musatti 09 Jun '06

09 Jun '06

Hallo, Robert. I eventually setup a test environment where I can run tests from both BCB6 and BCB2006, and I'm currently looking into test_delete_pointer's failure. I still see the problem I mentioned a while ago where boost::archive::version_type is being written out as a bool, even though this is not the main problem. What causes the test to fail is bpis_ptr being NULL at line 485 in basic_iarchive.cpp: if(! tracking){ bpis_ptr->load_object_ptr(ar, t, co.file_version); This call obviously generates an access violation. I've yet to figure out why. Any suggestion is welcome :-) Cheers, Nicola Musatti

2 16

Re: [boost] [endian] Refresh based on comments received
by Martin Bonner 09 Jun '06

09 Jun '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of me22 Sent: 09 June 2006 14:51 To: boost(a)lists.boost.org Subject: Re: [boost] [endian] Refresh based on comments received > On 6/9/06, Martin Bonner <martin.bonner(a)pitechnology.com> wrote: >> No. They all have AT LEAST 8 bits, but there are certainly C >> implementations with 9-bit char and 32-bit char. I don't know if >> any of these have C++ compilers (but the standard certainly permits >> it). (You might of course decide to explicitly limit your library >> to 8-bit char platforms only.) >> > How do those C implementations handle I/O? Does fgetc actually give > the next 9 or 32 bits of the file? Well, some of them (DSPs) are freestanding implementations and don't /have/ fgetc. But in general, yes. Of course, on such systems the file will be divided into 9 or 32 bit sized chunks. (Which makes file transfer interesting). > If, for example, the sockets implementation actually filled all 9 bits > in a byte on a recv, I could see that being a portability nightmare... The sockets implementation receive octets down the wire (and they are called octets not bytes because the designers were aware of non-8-bit bytes). recv will store each octet into a byte (which C and C++ guarantees is big enough). send might just transmit the low eight bits of each byte as the octet, or it might fail if higher bits are non-zero. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

Re: [boost] [endian] Refresh based on comments received
by Martin Bonner 09 Jun '06

09 Jun '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 08 June 2006 17:51 To: boost(a)lists.boost.org Subject: Re: [boost] [endian] Refresh based on comments received > Gennaro Prota wrote: > >> * there is no guarantee that an unsigned char has 8 bits... > > The C and C++ standards specify char, signed char, and unsigned char > all have exactly 8 bits, AFAIK. No. They all have AT LEAST 8 bits, but there are certainly C implementations with 9-bit char and 32-bit char. I don't know if any of these have C++ compilers (but the standard certainly permits it). (You might of course decide to explicitly limit your library to 8-bit char platforms only.) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 2

[optional][1.34] Recent changes broke Borland support
by Nicola Musatti 09 Jun '06

09 Jun '06

Hallo, Fernando. Your recent change to optional.hpp was apparently too much for the Borland compilers. The enclosed patch should set things straight. Cheers, Nicola Musatti ******Index: optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.9.2.1 diff -d -u -r1.9.2.1 optional.hpp --- optional.hpp 8 Jun 2006 01:39:40 -0000 1.9.2.1 +++ optional.hpp 8 Jun 2006 07:53:42 -0000 @@ -133,7 +133,11 @@ { private : +#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) + typedef BOOST_DEDUCED_TYPENAME boost::detail::make_reference_content<T>::type internal_type ; +#else typedef BOOST_DEDUCED_TYPENAME ::boost::detail::make_reference_content<T>::type internal_type ; +#endif typedef aligned_storage<internal_type> storage_type ;

2 1

Re: [boost] [Review][PQS] Physical Quantities System review (May 31through June 9)
by Peter C B Henderson 09 Jun '06

09 Jun '06

I only learned about this review on Wednesday June 7, so I hope this gets in on time. Also, I have not had time to thoroughly review the design. However one aspect of the design was brought to my attention by a colleague, and it is on this I will comment. The aspect that I wish to comment on is the definition of the comparison operations. These are described as being controlled by a parameter BOOST_PQS_COMPARISON_EPSILON, which controls slop in the comparison. I will refer to this as epsilon comparison, as opposed to standard comparison. Looking at the reviews so far, I haven't seen reference to this issue. First the presence of this feature leads me to vote against the inclusion of this library in boost. My reasons follow. This behaviour violates the first principles of the use of operator overloading: the overloaded operators should have comparable semantics to the original operators and should satisfy similar relations, e.g. ++x should behave as x+1. In the context of a physical dimension library, this means the overarching design goal is that operations produce exactly the same results as would be obtained using the underlying numerical types, with the sole exception that the dimension checking prevents invalid combinations of dimensions. With respect to statically typed objects, whether statically defined or created by new and assigned to statically typed pointers, another goal is that there should be negligible increase in running time and the use of memory. Violating these dictums w.r.t. comparison leads to numerous problems. First, important relations no longer apply. For example trichotomy, i.e. exactly one of x<y, x==y or x>y is true, can no longer be guaranteed. This property is relied on for sorting and hence for the proper operation of maps. Second, programmers will invariably read the comparison operators as being comparisons of floats in there usual sense. (For definiteness, I will refer to floats throughout, however these comments apply to any numeric type.) They will expect that they can copy a floating point routine verbatim and obtain the same results But if the value of BOOST_PQS_COMPARISON_EPSILON is changed anywhere in the program, this will no longer be the case and extremely hard to find bugs will occur. In addition, the programmer can no longer be sure what any comparison actually does, and so will have to invest time in checking that the epsilon control variable has not been changed while attempting to determine the cause of a bug. At worst, this will lead to defensive programming practice where every function will save and set this variable on entry and restore it on exit. Even worse, since no one can be sure a function doesn't change this variable, every function will have to save this variable and restore it before and after every function call. Third, the idea that this variable can be set to a single useful value is ill-conceived. When this type of comparison is required, the value of epsilon must be determined for each particular point in the program. It must be large enough to account for the anticipated rounding error at that point, but not too large so as to overly degrade the accuracy of the final result. Often, in fact, entirely different tests may be used, for example instead of x < y+eps, the test may be x < y*(1+ups)+eps. In many cases it may be fabs(x) < eps. Fourth, the use of epsilon comparisons can have a severe impact on performance as the compiler always has to issue operations to perform the full test, even when BOOST_PQS_COMPARISON_EPSILON is set to zero. Finally, it violates the purity of purpose the physical dimensions library. Its sole purpose should be to ensure programmers don't make mistakes which can be caught by dimensional analysis or due to inadvertent mixing of different units. The epsilon comparison proposed has nothing to do with this aim, rather it is attempting to protect inexperienced programmers from certain easily made mistakes. If this functionality is desired, a special template class, entirely separate from the dimensions library should be created and these special types passed as template arguments to the dimensions library. I hope I have not seemed too harsh in my criticism. Fortunately, this problem can be fixed with no impairment to the purpose or functionality of the proposed library.

2 1