- Boost - lists.boost.org

VC++7.1 problem with swallow_assign multiple definitions
by Maciej Sobczak 12 Mar '04

12 Mar '04

Hi, I'm trying to port some code from VC++6.0 to VC++7.1. It is a DLL library that uses Boost.Python (from 1.30.2) to expose its interface for Python. It compiled without problems on VC++6.0, now I get during linking: file2.obj : error LNK2005: "struct swallow_assign::boost::detail::swallow_assign boost::tuples::`anonymous namespace'::ignore" (?ignore@?A0x3ab6eb85@tuples@boost@@3Uswallow_assign@detail@23@A) already defined in file1.obj and later: file2.obj : warning LNK4006: "struct swallow_assign::boost::detail::swallow_assign boost::tuples::`anonymous namespace'::ignore" (?ignore@?A0x3ab6eb85@tuples@boost@@3Uswallow_assign@detail@23@A) already defined in file1.obj; second definition ignored I found here: http://mail.python.org/pipermail/c++-sig/2002-November/002693.html the suggestion to use the latest tuple_basic_no_partial_spec.hpp file. No luck. I understand that it is the last line in this file that is a cause of problems. We would like to avoid upgrading to 1.31 if 1.30.2 can make it. Any suggestion for workaround will be highly appreciated. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

2 2

[serialization] serializable objects implemented in dlls
by David Tonge 12 Mar '04

12 Mar '04

Robert, I've made a small project which replicates the problems I was having yesterday. I think that part of the problem was that my solution for exporting the guids for shared_ptrs was like this... typedef boost::detail::sp_counted_base_impl<T*, ....> T_shared_ptr; BOOST_CLASS_EXPORT(T_shared_ptr); ...and if the typedef wasn't in scope where the streaming occurred then the streaming system didn't recognize that the sp_counted_base_impl<T*,...> was a T_shared_ptr. Anyway, I've resolved that by making a more complicated macro for exporting the guids, which doesn't use any typedefs. That's included in the attached archive as hack_shared_ptr.h. It isn't possible simply to do... BOOST_CLASS_EXPORT(boost::detail::sp_counted_base_impl<T*, ....>) ...because that contains a comma, and the preprocessor thinks you're passing two parameters to a macro which expects only one. Anyway, I think the new macro (HACK_SP_BOOST_CLASS_EXPORT(T)) avoids that problem. Now to my other problem. I wanted to investigate the serialization tools in the context of a larger project. My habit is to define my class interfaces in header files, like base_class.h, and provide their implementations in source files like base_class.cpp. I like my headers to be lightweight and include the minimum number of other header files in order that compilation times don't get out of hand. I had been including the BOOST_CLASS_EXPORT(T) commands in the headers but that means I have to include all of the archive headers, and export.hpp in every header, and that makes for slow compilations. My hope is that I can include all of those only in the implementation .cpp and put the BOOST_CLASS_EXPORT(T) there. I was also worried that if I included the BOOST_CLASS_EXPORT(T) in the header then every other .cpp which included that header would also try to register the guid for T - surely an unnecessary replication of effort. Having done all of this I found that my program would work fine if everything existed in a single EXE. However, if I implement them as a DLL containing my base_class and derived_class implementations and an EXE, which uses these classes, then things fail. In the attached .ZIP there is a VC7.1 solution which builds three different projects: single_project Contains all of my example source code, and builds a single .EXE which streams two shared_ptr<base_class> to file and then loads them back. One of the pointers contains a derived_class. dll_implemetation Contains implementations of base_class and derived_class. It also contains the BOOST_CLASS_EXPORT commands for those classes. This project builds a DLL which exports these classes. exe_using_dll Contains just the main() function. It should do the same as single_project does as the main() is the same. Single_project works fine. exe_using_dll fails when it tries to save the pointer to the derived_class. The failure is an unregistered_class exception. I've stepped through the code for exe_using_dll and I can see that the failure occurs when it tries to get extended type information for the derived_class (at line 297 of oserializer.hpp). However, I know that the class has been registered by the guid_initializer (at line 130 of export.hpp) because I put a breakpoint there, and saw initialization happen for base_class, derived_class and the shared_ptr versions of both. My suspicion is that the problem is caused by the serialization library using a static library, rather than a DLL. If the BOOST_CLASS_EXPORT commands updated a list contained in the static library then there would be one instance of this list statically linked into my DLL, and another in my EXE. Thus, the registration occurring in the DLL wouldn't affect the list used in the EXE. If this is the case then it's going to be quite inconvenient. It would mean one would have to BOOST_CLASS_EXPORT every class in every DLL where an instance of it (or a shared_pointer which might contain it) might be saved. If that were the case then I'd advocate making boost_serialization into a DLL, rather than a static library. I'd be grateful if you could take a look at my example, and let me know if there is something I can do to resolve my problems. Regards, David Tonge

2 2

RE: IO Formatters and lexical_cast
by Reece Dunn 12 Mar '04

12 Mar '04

Roland Richter wrote: >Reece, > I just checked out outfmt from the sandbox CVS and did some > tests to see whether it works together with lexical_cast. > The general idea is this: > Since lexical_cast internally uses a stringstream and its > associated operators>> and <<, it should be possible to > cast each type for which these operators are defined; > and since outfmt defines <</>> for STL container types, > I tried to combine them in order to convert between strings > and STL containers. > After some hassle, it works (under MS VC++ 7.0); see the > attachment. Issues: > 1) For reasons I don't completely understand, the compiler > could not find operator<< from stl_io_basic.hpp when > compiling lexical_cast.hpp. I had to hack detail/stl_io_basic.hpp > and put everything in namespace boost::detail (where > lexical_stream lives). > BTW, I'm not happy that stl_io.hpp includes everything from > vector to slist, and that so much code is put into the global > namespace. I am aware of this and am working on splitting the code into files like <boost/outfmt/stl/vector.hpp>, etc. There are three main areas that need to be split: [1] The STL I/O code [2] The type identification code [3] The get/put helpers for pair-like objects I have got a version of this to work with MS VC 7.x, but I have a compilation problem on borland and GCC 2.95.3-5 is generating a "signal 13" message on the regression tests (I think this is my cygwin setup, but haven't verified this). I have since been busy and haven't had a chance to look into these. I shall move the inserters and extractors to the boost::detail namespace and will look into the lexical_cast problem. > 2) The output operator puts spaces after '[', before ']', > and after each ','; whereas the input operator expects > no spaces at all; if spaces were present, a bad_lexical_cast > exception was thrown. I think it is really important that > operator>> can deal with an output which was generated by <<; > stated in terms of lexical_cast, > > lexical_cast<T>( lexical_cast<string>( t ) ) == t > > should hold for any T t. I stripped and skipped the spaces during the read operation to allow for the read operation to accommodate input variations, e.g. [ a, b ]; [a, b] and [ a,b ] would be read by the same formatter, making it easier to interoperate with data generated from other sources. I could make this a configurable option that does not strip the spaces by default. This should work. If you have examples where it doesn't, please let me know and I can add it into the regression tests. NOTE: There is a known defect when handling string data. This may be generating the problem you are encountering. If you run my regression tests (libs/outfmt/test/generate.sh) you should see it as a fail. I am aware of the problem and am looking into it. (This is made more difficult because the solution I implemented doesn't work with Borland :() > I intend to do some further tests, and to give more feedback during > the IO Formatters formal review (no date is fixed yet, or is it?) Thanks. I appreciate the feedback. I would like to get the string >// Copyright Roland Richter 2004. >// Distributed under the Boost Software License, Version 1.0. >// (See accompanying file LICENSE_1_0.txt >// or copy at http://www.boost.org/LICENSE_1_0.txt) > >#include <boost/test/minimal.hpp> > >#include <vector> >#include <string> > >#include <iostream> > >#include <boost/lexical_cast.hpp> >#include <boost/outfmt/stl_io.hpp> > >// 1) Namespace problem: >// e:\lib\boost_1_31_0\boost\lexical_cast.hpp(144): error C2679: binary >'<<' : >// no operator found which takes a right-hand operand of type 'const >_STL::vector<_Tp,_Alloc>' (or there is no acceptable conversion) >// with >// [ >// _Tp=double, >// _Alloc=_STL::allocator<double> >// ] >// >// => move everything in boost/outfmt/detail/stl_io_basic.hpp into >namespace boost::detail > >// 2) operator<< puts spaces after '[' and ',', whereas operator>> expects >// no spaces at all (otherwise, bad_lexical_cast is thrown). > > >void lexical_cast_and_outfmt_test() >{ > double foos[] = {0.7016, 0.9943, 1.3441, 1.1637, 0.5994, 0.0000, >0.0000}; > std::vector<double> fooVec( foos, foos + 7 ); > > std::string fooStr( "[ 0.7016, 0.9943, 1.3441, 1.1637, 0.5994, 0, 0 ]" >); > > // Output > std::string castedStr = boost::lexical_cast<std::string>( fooVec ); > BOOST_CHECK( castedStr == fooStr ); > > std::string fooStr_WithoutSpaces( >"[0.7016,0.9943,1.3441,1.1637,0.5994,0,0]" ); > > // Input > std::vector<double> castedVec > = boost::lexical_cast< std::vector<double> >( fooStr_WithoutSpaces ); > BOOST_CHECK( castedVec == fooVec ); >} > > >int test_main( int, char *[] ) >{ > lexical_cast_and_outfmt_test(); > > return 0; >} _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

2 1

metrowerks & vacpp
by Pavol Droba 12 Mar '04

12 Mar '04

Hi, I need somebody, that can help me out with a problem with codewarior and/or vacpp. Regressions are failing on these compilers due to incorrect classification of std::string and std::list. It seems, that the template signature for classes differs from standatard ( std::list<T,Alloct> ) and so, the sequence_traits are not recognizing these classes. Please, if somebody have an access to these compilers, check the singnature of them, and send it on the list. There might be another porblem as well, but I cannot figure it out right now. Regards, Pavol

3 4

BOOST_TRY like macros: time to add them?
by Pavel Vozenilek 12 Mar '04

12 Mar '04

Disabling try/catch through preprocessor when compiling without exception support was suggested e.g by Robert Ramey in: http://aspn.activestate.com/ASPN/Mail/Message/boost/1799735 Right now there are 3 libraries near review, each using their own set of similar macros: - circular_buffer - indexed_set - serialization The reasons to use macros instead of RAII is convenience and performance. Some compilers (BCB) do not allow try/catch with exceptions disabled so some solution is needed. It would be better to have and use standardized macros in Boost. Example: macros used in indexed_set: #if !defined(BOOST_NO_EXCEPTIONS) # define BOOST_INDEXED_SET_TRY try # define BOOST_INDEXED_SET_CATCH(x) catch(x) # define BOOST_INDEXED_SET_RETHROW throw #else # define BOOST_INDEXED_SET_TRY # define BOOST_INDEXED_SET_CATCH(x) if(0) # define BOOST_INDEXED_SET_RETHROW #endif Compiles w/o warnings on VC6+, BCB gives unreachable code warning (but I'll try to find workaround). /Pavel

12 32

Thread usage ?
by raja 12 Mar '04

12 Mar '04

Hi, I am trying out boost thread libraries with VC 7.1 Here are my includes : #define _MSC_VER 1310 #define BOOST_LIB_NAME "boost_thread" #define BOOST_LIB_DIAGNOSTIC "on"// Show library file details. #include <boost/config/auto_link.hpp> #include <boost/thread/thread.hpp> #include <iostream> I am getting the following error : c:\Boost\include\boost-1_31\boost\config\auto_link.hpp(269) : fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." Looks like I am missing some #define. Would appreciate if someone can let me know about this. Raja

2 1

Re: [boost] small addition to functional
by Fredrik 12 Mar '04

12 Mar '04

John Torjo wrote: >Hi all, >I think since member functions can be wrapped up as >functors, why not >same for member data? >Therefore, I think this could be a useful addition to >functional: <<snip>> >What do you think? I think Peter Dimov has already thought about this ;) Read the current mem_fn docs carefully and you'll find a data-case also. I agree it's very useful functionality. It was added fairly "silently" though (mid 2002 IIRC) which might have made people miss it(?). // Fredrik Blomqvist

4 7

function_equal and function::contains committed
by Douglas Gregor 12 Mar '04

12 Mar '04

Based on the discussion with Peter Dimov and Brian McNamara, I've checked in boost/function_equal.hpp with the new function_equal function. Overload boost::detail::function_equal_impl with a final argument of "int" in libraries that need to be compatible with older compilers. function_equal is documented as part of Boost.Function (because it needed a home somewhere inside BoostBook). function<> now has a contains() member function and uses function_equal instead of operator ==. Doug

1 0

Boost 2 - development in long term
by Pavel Vozenilek 12 Mar '04

12 Mar '04

Described is an idea how Boost can move on in the future. By future I mean 2-5 years, definitely not tomorrow or next month. Support for sub-standard compilers is taking away lot of time and energy of library writers. It also makes result code quite hard to understand and modify. Shouldn't only so many people be stuck with old equipment... What could be done: - create branch or fork of Boost in CVS, say Boost 2. - this project will have exactly the same structure as current Boost (directories/libraries/tests). - the project will be initially empty. - one by one, libraries will be removed of kludges, and workarounds (all of them, w/o exceptions) and copied into Boost 2. This includes: - fixes for nonconforming compilers (#ifdef BOOST_MSVC ...) - fixes for substandard STL (e.g. old Dinkumware) - fixes to deal with missing exception support - the converted libraries will be tested only with very recent compilers which are supposed to be conformant (GCC 3.4, VC8, Intel C++ 8, Metrowerks 9.2, Comeau). Why this may work: - all existing infrastructure (the tests) could be reused w/o change. - no need to deal with non-standard systems makes the cleanup less time consuming. - with no need to deal with non-standard systems it may be interesting work and fun for library writers, again. - compiler vendors may take it as incentive to improve their system, rather to rely on people will find workarounds. This effect can be already seen today. What would it require: - some site with latest compilers which would continually and automatically run all the tests. Not all people have access to newest tools. - the cleanup could be done by original library author or by someone who feels knowledgeable with it. - core libraries need to be identified and ported first. What to do with current Boost 1.XX: - the development will continue as it is now, as long as needed and feasible (my guess are few years more). - new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'. Problems: - how to keep both branches up to date with fixes and changes? This is real problem and should be solved by requiring every change in Boost 1.XX be considered for Boost 2. Backporting from Boost 2 to Boost 1.XX would be optional but rare. Hopefully most libraries are rather mature and don't go through major rewrites. Even if so, making clean version should be relatively painless. - should there be two sets of documentation? No, the documentation should not change except removing information about old systems support. This should be reasonably easy. - woudln't people with old compilers feel abandoned? Yes, but development for 1.XX should continue as long as needed/feasible. In few years hopefully support for VC6 and Borland will dimish. - there's no time to do yet more work: this should be long term project. Individual libraries can be ported at individual pace and independently. - code without kludges may not compile on ANY existing compiler: so be it. Next version of compiler will be hopefully better. Workarounds should be forbidden or very, very rare. Who will benefit of this all: - library writers who do not want to support old systems (less pressure on them) may spend more time with design. This gets more important if more powerfull/complex libraries will emerge. - users with new compilers (they can be more sure the library remains maintainable and may even be able to understand its inner, too). Their existing code using Boost should compile without changes. - compiler vendors will be able catch more errors. - standard comittee may be more interested in clean code. - if/when the world moves to C++0x it will be easier to move Boost there (this is beyond horizont of this idea though). What it it all fails: - Boost 1.XX should be unaffected by branching and could continue as if nothing had happened. I remind again this idea is about long term development of Boost. I think it has biggest effect for the effort spent. /Pavel

8 10

On bind::operator==, again
by Peter Dimov 12 Mar '04

12 Mar '04

What do you think this expression should do: bind(f, _1) == bind(g, _1) Currently, boost::bind returns f == g when f and g are of the same type, and fails at compile type otherwise (this is the equality comparison feature Doug requested). lambda::bind returns lambda(x) { return f(x) == g(x) }. It is clear that a future boost::bind that has limited lambda support would be even more problematic (as would be a future equality comparable boost.lambda). In that case, the expression will always compile, but do something different depending on whether f and g are of the same type. -- Peter Dimov http://www.pdimov.com

5 28