- Boost - lists.preview.boost.org

Re:[boost] Re: Re:Re: serialization library #17
by Robert Ramey 13 Mar '04

13 Mar '04

Jeff Flinn wrote: >Any thoughts on future serialization of boost::function even being >possible? >My use case is that I've a std::map of std::string/boost::function's that >provide user configurable filters that detemine what gets displayed in a >Table/List View. These currently are not being saved between sessions. It'd >be great to do mFilterMap & ar; Why would this not be possible, I don't see reason why it would be any kind of special case? Robert Ramey

1 0

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

13 Mar '04

John Maddock wrote: >> Robert Ramey wrote: >> 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? >Here's the problem: those headers were only supplied as a workaround for >compilers that don't supply new style headers at all, they all use the >following workaround: >#include <string.h> >namespace std{ using ::memcpy; } //etc >However for conforming compilers this is defective for two reasons: >It needlessly introduces C functions into the global namespace (including ><cstring> should not do that). >It shouldn't compile at all: memcpy is already declared in std, the version >in the global namespace is an alias introduced with a using declaration,and >importing it back into std *should fail*. >Now the interesting thing is, I know of only two vendors who are shipping >std conforming C headers: Borland and Metrowerks. Since you don't mention >the latter my guess is you're not testing with it ;-) >The normal workaround that Boost libs have been using is: >#include <cstring> >#include <boost/config.hpp> >#ifdef BOOST_NO_STDC_NAMESPACE >namespace std{ using ::memcpy; } >#endif OK, I can live with this. But if cpp_c_headers has conditioned on the compiler then what is the point of having it all? What use can it have? Robert Ramey

2 1

filesystem doc nit
by David Abrahams 13 Mar '04

13 Mar '04

"The Filesystem Library's fstream.hpp header simply uses the <fstream> standard library components as base classes, and then overrides the members requiring argument types of path." Technically, I don't think this is overriding, and the base classes don't require path arguments. Maybe you mean: "The Filesystem Library's fstream.hpp header simply uses the <fstream> standard library components as base classes, and then adds constructors, and overloads of the base interfaces, that accept path arguments instead of strings" -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Formal Review: Circular Buffer
by Pavel Vozenilek 12 Mar '04

12 Mar '04

The review of Jan Gaspar's Circular Buffer library starts today (March 5th) and runs for 10 days. Latest version of the library is available at: http://groups.yahoo.com/group/boost/files/circular_buffer_v3.6.zip What it is: Circular buffer (also known as ring or cyclic buffer) is container with fixed upper limit on number of elements inside. When capacity gets exhausted newly inserted elements will cause oldest elements to get dropped out. What makes the library Boost candidate: - it provides often used functionality, - it is STL compliant generic solution, - it is designed for CPU/memory efficiency, - it is fully documented and tested, - it contains extensive debug support, - it has been informally reviewed for long time. Discovered problems in code or in documentation, missing features, portability issues and finally opinion whether the library belongs to Boost is welcomed. /Pavel

13 59

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