- Boost - lists.boost.org

DLL linking with Como
by Jeff Garland 20 Jul '04

20 Jul '04

date-time has a number of regession test failures when it is built in the dll mode on windows. They look like this: C:\Progra~1\Comeau\4_3_3\bin\como --vc7 -c -e5 --no_version --no_prelink_verbose --display_error_number --long_long --diag_suppress=9,21,161,748,940,962 -D__STL_LONG_LONG -DBOOST_DATE_TIME_POSIX_TIME_STD_CONFIG -DBOOST_ALL_DYN_LINK=1 --a --no_inlining /Zi /Od -D_WIN32 --exceptions -DBOOST_DISABLE_WIN32 --wchar_t -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\date_time\build" -I"C:\Users\Administrator\boost\main\boost" -I"C:\Progra~1\Comeau\4_3_3\libcomo" -I"C:\Progra~1\Comeau\4_3_3\libcomo\cnames" -o "C:\Users\Administrator\boost\main\results\bin\boost\libs\date_time\build\boost_date_time.dll\meta-como-win32-4.3.3-vc7\debug\greg_month.obj" "C:\Users\Administrator\boost\main\boost\libs\date_time\build\../src/gregorian/greg_month.cpp" "C:\Users\Administrator\boost\main\boost\boost/date_time/gregorian/greg_month.hpp", line 55: error #70: incomplete type is not allowed class BOOST_DATE_TIME_DECL greg_month : public greg_month_rep { ^ Which looks like it is complaining about the BOOST_DATE_TIME_DECL macro. I'm wondering if in config/platform/win32.hpp we need to at como to this little macro that controls the definition of BOOST_HAS_DECLSPEC. #if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) # define BOOST_HAS_DECLSPEC #endif I've never used this compiler -- anyone out there know how it handles dll symbol export on win32? Jeff

4 5

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 20 Jul '04

20 Jul '04

> >>Ok... more Boost.Test (minor) problems: > >> > >>http://tinyurl.com/72awd > > > > > > And what is the problem here? > > It's giving a "fail" flag on Comeau. See the MetaCom test > results for Boost.Test. See your basic_cstring_test at > http://tinyurl.com/55xg6 for example. Well. I do not have an access to this compiler. And this test pass on most Windows compilers I have access to. Could somebody give me explanation on what this compiler complains about? Gennadiy.

2 2

Multiple files utf8_codecvt_facet.cpp
by Matthias Troyer 20 Jul '04

20 Jul '04

Hi, is there a reason why both program_options and serialization contain very similar files utf8_codecvt_facet.cpp? Matthias

4 9

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 20 Jul '04

20 Jul '04

> The workaround should make use of the BOOST_NO_CWCHAR macro, > which is set if _GLIBCPP_USE_WCHAR_T / _GLIBCXX_USE_WCHAR_T > is not set (see > boost/config/stdlib/libstdcpp3.hpp) > > Maybe something like this (but using BOOST_WORKAROUND): > > #if defined( __GNUC__ ) && defined( BOOST_NO_CWCHAR ) > namespace std { using ::wcscmp; } > #endif Why do I need to test for gcc here in a first place? > Although this isn't quite right, as it only tests for GCC, > but it's the stdlib that affects the availablity of > std::wcscmp (i.e. GCC with STLPort wouldn't be affected AFAICT) > > jon Thanks for analysis, I will apply this fix. Gennadiy.

2 1

Re: Bjam won't build thread static library VC .NET
by Tonko Juricic 20 Jul '04

20 Jul '04

Michael Glassford wrote: > The upcoming 1.32.0 has some support for building > as a static library (i.e. you can build it that > way, but you must call functions at appropriate > times-- not an easy thing to do--to prevent the > memory leaks if you use thread_specific_ptr). > Hopefully the next release after 1.32.0 will do > cleanup for you automatically. Mike, I'm still reading group archives to catch up with the past issues so the following may be a dumb question: Assuming that motivation is to provide cross-platform support for thread_specific_ptr (that is my current understanding), is it worthy of complications with thread exit cleanup? I tend to think that only people familiar with threading issues would use thread_specific_ptr, therefore 'generic' thread code should not be responsible for tss cleanup. Tony __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[threads] Compilation problems on CW and others...
by Rene Rivera 20 Jul '04

20 Jul '04

Michael, I believe one of the last remaining problems with the compilation of threads in Win32 platforms, maybe others, is that the line-endings on the files are totally incorrect. When I look at the files I see double spaced lines with line-endings of the CR-CR-LF variety. This causes all kinds of problems when the CW preprocessor tries to parse multi-line macros as it only parses the first line and error on the rest, for example: ### mwcc Compiler: # File: ..\src\exceptions.cpp # ------------------------------ # 49: || defined(__CYGWIN__) # Error: ^^ # declaration syntax error Which is the second line of: # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) \ || defined(__CYGWIN__) It will likely be easier for me to fix this directly than have you try and get the line endings just right, as the editor I use has functionality to fix those problems. Would it be OK for me to fix those at this time? I don't want to collide with anything you might be changing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

6 35

RE: [boost] This afternoon's test run
by Victor A. Wagner Jr. 20 Jul '04

20 Jul '04

At Monday 2004-07-19 12:47, you wrote: > > ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in > > "test_default_delimeter": test it != utf::ifstream_line_iterator() failed > >I do not understand something in Boost.Build system. This test should pass. >Are you sure you did update -d ? cvs -z9 update -dPA >> update.log and it ran at 0300 -0700 (PDT) >Gennadiy. >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

dynamic_bitset question & compiler warning
by Terence Wilson 20 Jul '04

20 Jul '04

I have an unsigned char array which I would like to represent as an array of bits in order to perform bit shift operations. My code is as follows: // rotate bits as one large bitset typedef unsigned char octet; void Normalize(boost::shared_array<octet> RawHash, int RawHashLength) { int ShiftLength=7; boost::dynamic_bitset<octet> HashBits; for (int i=0; i<RawHashLength; ++i) { HashBits.append(RawHash[i]); } boost::dynamic_bitset<octet> ShiftedBits=HashBits << ShiftLength; } A couple of issues: 1) How do I get bits out as unsigned chars after the shift operation? 2) I get a compiler warning, it doesn't seem to like me using unsigned char. I am using Visual Studio 2003- c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(655) : warning C4267: 'initializing' : conversion from 'size_t' to 'const boost::dynamic_bitset<Block>::block_type', possible loss of data with [ Block=octet ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(115) : while compiling class-template member function 'boost::dynamic_bitset<Block> &boost::dynamic_bitset<Block>::operator <<=(boost::dynamic_bitset<Block>::size_type)' with [ Block=octet ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(156) : while compiling class-template member function 'boost::dynamic_bitset<Block>::dynamic_bitset(const Allocator &)' with [ Block=octet, Allocator=std::allocator<octet> ] c:\PROJECTS\vcpp\PasswordGenerator\Normalizer.cpp(46) : see reference to class template instantiation 'boost::dynamic_bitset<Block>' being compiled with [ Block=octet ] c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(658) : warning C4267: '=' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(660) : warning C4267: '=' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\detail\dynamic_bitset.hpp(88) : warning C4267: 'return' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\detail\dynamic_bitset.hpp(88) : while compiling class-template member function 'octet boost::detail::dynamic_bitset_base<Block,Allocator>::mask1(boost::detail::dy namic_bitset_base<Block,Allocator>::size_type)' with [ Block=octet, Allocator=std::allocator<octet> ] c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(76) : see reference to class template instantiation 'boost::detail::dynamic_bitset_base<Block,Allocator>' being compiled with [ Block=octet, Allocator=std::allocator<octet> ]

2 1

Re:[boost] Re: [serialization] CW problems...
by Robert Ramey 20 Jul '04

20 Jul '04

> Yes. But did anyone try other non intrusive approaches? Here are some > possibilities: Yesterday I studied this question carefully in light of the experience gained from testing with my own compilers and reviewing the test results. I altered the utf8_codecvt_facet.cpp to make it more correct and more obvious as to the issues it addresses with regard to each compiler. I tested on all the compilers I have (borland 5.51, borland 5.60, msvc 6.0, msvc-stlport, msvc 7.1 and gcc 3.3/cygwin and was satisfied with the results. I am awaiting test results for other compilers. I'm hopeful that this will achieve results satisfactory to all concerned. Vladimir's point is a interesting one: The is code module doesn't really belong to either package - the question arises as to where it should be placed. If I leave in the serialization package or Vladimir leaves it in the program options package its unsatisfactory as we either have to more or less identical packages or a non-sensical cross dependency. There is currently not neutral place for *.cpp code, docs and tests for unreviewed code of this nature. As to the particular case of this code module, there was an open invitation to review/scrutinize it and several people did comment it should be moved to boost directory/namespace, Vladimir found it sufficiently useful to copy it into the program options project. No one has found any major fault with its design, interface or implementation. The only problem has is that it depends upon libraries whose implementation is inconsistent in this area and this is being addressed and resolved by testing. My only regret is that Vladimir didn't communicate to me the changes he saw fit to make. I certainly would have been very happy to either incorporate the changes he included for CW (as I did the changes submitted by Pavel Vozenilek). Actually I would have been happy to hand this off to Vladimir or anyone else who would like to take responsibility for it as it's really peripheral to the serialization library in any case. Robert Ramey

2 1

Some SFINAE for vc6
by David Abrahams 20 Jul '04

20 Jul '04

Tip for those insane persons who are trying to nurse vc6 along: Some kinds of SFINAE are possible. Forming a pointer to a reference, for example, will remove a function signature from the overload set. Here's something I did in Boost.Python just now. In this case it was only needed for VC6, but it should work for any SFINAE-ish compiler: template <class T> explicit object( T const& x # if BOOST_WORKAROUND(BOOST_MSVC, == 1200) // use some SFINAE to un-confuse MSVC about its // copy-initialization ambiguity claim. , typename mpl::if_<is_proxy<T>,int&,int>::type* = 0 # endif ) Ron Garcia reminded me that I had done this for the multi_array library a while ago, and I realized I had forgotten all about it. I thought y'all should know. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0