- Boost - lists.boost.org

filesystem hard link question
by Neal D. Becker 12 Mar '04

12 Mar '04

I am using the following common idiom: link (name, name.old) rename (name.new, name) To update a file atomically I'm interested in using boost::filesystem instead of libc, but I didn't find any equivalent of link in filesystem. Did I miss it? Should it be added?

6 15

Re: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
by Peter Dimov 12 Mar '04

12 Mar '04

(resend) > Greg Clayton wrote: >> >> Yes, shared pointers can't be created and handed off from DLL to DLL >> the way they are currently implemented. If DLL A has an STL container >> of shared pointers, and DLL B gets _dynamically_ loaded and adds an >> item to DLL A's container (creates a shared pointer to an object, and >> DLL B adds that shared pointer through an interface it to DLL A's STL >> container of shared pointers), DLL B can not be unloaded. If DLL B >> does get unloaded you will crash when your STL container goes out of >> scope (when it tries to delete the owned pointer). > > Isn't it possible for the DLL C that contains the definition of > SomeClass to export > > shared_ptr<SomeClass> createSomeClass(); > > which DLL B can now call when it needs a SomeClass? > > Since ~SomeClass lives in C, it must be available when the last > shared_ptr<SomeClass> is destroyed.

1 0

Numeric Conversion Library?
by David Abrahams 12 Mar '04

12 Mar '04

http://article.gmane.org/gmane.comp.lib.boost.announce/37 It was accepted, right? When will it be added to CVS? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

RE: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 12 Mar '04

12 Mar '04

> -----Original Message----- > From: Peter Dimov [mailto:pdimov@mmltd.net] > Sent: Thursday, March 11, 2004 4:48 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Explicit instantiation of > boost::shared_ptr<SomeClasss> > > > Greg Clayton wrote: > > I am trying to do explicitly instantiate specific shared_ptr class > > for export from a Win32 DLL (currently with MSVC6, and eventually in > > VS2003). > > First things first. Why do you need to do that? Have you > tried not exporting it, have you encountered any problems? Yes, shared pointers can't be created and handed off from DLL to DLL the way they are currently implemented. If DLL A has an STL container of shared pointers, and DLL B gets _dynamically_ loaded and adds an item to DLL A's container (creates a shared pointer to an object, and DLL B adds that shared pointer through an interface it to DLL A's STL container of shared pointers), DLL B can not be unloaded. If DLL B does get unloaded you will crash when your STL container goes out of scope (when it tries to delete the owned pointer). The virtual function table for the shared pointer lives in the DLL that creates it if you just use something like: typedef boost::shared_ptr<SomeClass> SomeClassSP; in a header file that comes from DLL A (for other DLLs to link to). So I need to instantiate and export everything for that shared pointer from DLL A (since it is the DLL that owns the STL containers of objects) so that the vtable stays valid for the lifetime of the shared pointer object. > [...] > > > When I look through the exports, some needed class functions seem to > > be missing from the DLL, and linking fails. Most notable are: > > > > void boost::shared_ptr<SomeClass>::reset(SomeClass*) > > > > This function is declared in the shared_ptr header file as: > > template<class Y> void reset(Y * p); > > This is a function template. A template can't be exported, only an > instantiation. > > template void boost::shared_ptr<SomeClass>::reset(SomeClass*); > > should instantiate reset with Y=SomeClass. After I sent the original email to this list I tried something similar, but it didn't seem to work (didn't see it in my export list). I will try it with VS2003 and see if I have better luck.

3 2

Re:[boost] [serialization] serializable objects implemented in
by Robert Ramey 12 Mar '04

12 Mar '04

David Tonge wrote: > Anyway, I've resolved that by making a more complicated macro for > exporting the guids, which doesn't use any typedefs. Although the shared_ptr serialization does work in the demos and tests, I've conceded that its probably going to need another pass to address such situations such as mult-threading, exception safety, polymorphic pointers and now perhaps instanciation issues. I think this will require access to the class header which I don't have (or want). I think for now it's OK to handle situations on an ad-hoc basis as you have done. In the long run I hope someone gets around to making the shared_ptr serialization complete and bullet-proof. > 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); In general, the macros don't really handle template arguments. Maybe they should. (Is there a pre-processor macro IS_TEMPLATE(x) ? ) > 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. The export/registration mechanism is used to relate a key/class_id stored in the archive with the appropriate de-serialization function. With the case of polymorphic pointers, the issue of instantiation of de-serialization code also has to be addressed. As things get more ambitious, the situation has to be explicitly considerd. I think the key example here is demo_pimpl. I couldn't get this to link properly with VC 6.0 and VC 7.0. With gcc it always worked. With VC 7.1 it started to work for Microsoft compilers. To make it work I had to explicitly instantiate the templates used for exported classes. I believe that you're situation will also require a little extra help - I'm not sure yet, but I'll look into it. 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. As Vladimir pointed out (I think) , a DLL version of the library is easily generated by a simple enhancement to the jamfile in the build directory. I haven't done this nor have I tested it. I see no reason why it shouldn't work without problem. (hmm - I don't know if this automatically generates an export lib). Adding auto_lib functionality to the serialization library would cleanly handle all issues related to build and usage of DLL versions. I've not done so as I think it's premature given that the library has not been accepted into boost. I suspect your suspicion is more or less on the right track. The library uses a little bit of trickery to be sure that extended_type_info information is generated and stored in a global table for each exported class at pre-compile time. When called from a DLL, most likely it's a separate table in the DLL so it wouldn't be found when doing the lookup from the main exe. I suspect this is addressable though I haven't yet considered it. > 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. > 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. I think a better solution would be to build you implementation classes as static libraries. (see the demo_pimpl). This addresses the issue of long compile times nicely. I believe will get you what you want. You won't have a separate DLL which may or may not be an issue depending upon your taste and situation. Also, I believe that the DLL situation will probably work now if ALL the code that invokes serialization for a particular class is found in the same DLL. An interesting experiment would be to see what would happen if the demo_pimpl is reformlated to use a (1) static library and (2) a DLL. In the longer run we'll look at this more carefully. Its conceivable that just the extended_type_instantion might be in a static lib while the rest is in a DLL or maybe the export process can be tweaked to be sure that DLLS, use the same table. At this point I really can't say. Another option (also mentioned by Vladimir and also in the documentation) is the creation of a "virtual_archive" interface. This is similar to the way the package that was reviewed over a year ago handled the issue. I have looked into this a little and have concluded that it will be quite easy to implement - though I've deferred it for now. > If that were the case then I'd advocate making > boost_serialization into a DLL, rather than a static library. I don't think that would help > 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. I'll look at it. Robert Ramey

1 0

Re:Re: [boost] [compatibility headers] fixes for Borland
by Robert Ramey 12 Mar '04

12 Mar '04

John Maddock wrote: >> Compatibility headers (in boost\compatibility\cpp_c_headers) >> don't compile with BCB 6.4. >I'm confused why you would be using those - Borland supplies the new style >headers with everything in namespace std already doesn't it? Here's our problem, In the serialization library there are 14 files that use functions from the std namespace. In order to compile these under VC 6.0 ( and perhaps other platforms ) we specify: #include <boost/compatibility/cpp_c_headers/cstring> // memcpy This resolves the issue with vc 6.0 ( and who knows who else ? maybe STLPort ? ). Conformant compilers don't seem to be affected adversely by this. The code itself uses a standard "std::memcpy" and everything is pretty clean. Now comes along Borland - the files ccp_c_headers won't compiler here. So now we're in a quandary. a) Sprinkle #ifdef BORLAND in those 14 files b) Tweak cpp_c_headers files c) Or ? what? What is the least worst way to handle this? If I have to use a) what is the point of even having cpp_c_headers? Robert Ramey

3 2

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