- Boost - lists.boost.org

Passing parameters to container constructor
by pdoucyml＠free.fr 05 May '04

05 May '04

I'm in the process of writing my bdb container, and have used the container_gen template to tell boost which container to use. Now what I would like is to be able to pass some parameters to this container's constructor (e.g., the database's file name). After some time googling and reading the bgl book, I haven't been able to figure out how to achieve this. Any ideas ? Thanks in advance. Pierre.

1 0

[multi_index] ANN: Post-review version available
by Joaquín Mª López Muñoz 05 May '04

05 May '04

I'm glad to announce that the post-review version of The Boost Multi-index Containers Library or Boos.MultiIndex (formerly known as Boost.IndexedSet) is available at: http://groups.yahoo.com/group/boost/files/multi_index.zip The most noticeable change is the new name for the library, which I hope will please most and bug none. Also, a new powerful feature called composite_key has been added. The complete list of changes after requests from the reviewers can be consulted at: http://groups.yahoo.com/group/boost/files/multi_index_postreview_notes.html I'd be grateful if the people interested could do the following: 1. make sure that all requests have been met. Those that haven't are justified at the post-review notes. 2. try to compile the library with different compilers. I don't think I've broken anything, but one never knows. This version has been tested with MSVC 6.5, GCC 3.3.1 and ICC 7.1 for Windows. Of special interest are MSVC 7.1, ICC 8.0, GCC 4.0 and CW 9.2. If no one raises any objection, in a week's time I'll commit the library to the main CVS, hopefully in time for Boost 1.32. Thanks everybody, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 6

Re:[boost] Re: Re: Using Serialization for binary marshalling
by Robert Ramey 05 May '04

05 May '04

Ian McCulloch wrote: > Does something like this structure make sense for the boost serialization > library? FWIW, my views on this subject are pretty much on display in the demo_portable_binary example shipped with draft #18 of the boost serialization library. If I have time, I may add support for floating point and move some code to templates to speed it up. But basically its very simple and addresses all known portability issues as far as I know. Robert Ramey

1 0

Re: [boost] Re: Spirit and typeof [was typeof]
by Reece Dunn 05 May '04

05 May '04

Joel de Guzman wrote: >Arkadiy Vertleyb wrote: >>"Joel de Guzman" wrote >>>I'd like >>>to start a new CVS branch for typeof/auto experimentations. This would >>>involve not only Spirit but Phoenix as well. I have a feeling that this >>>will take more than a week or two. Yet, I'm sure that the results would >>>be gratifying, at the very least. >> >> >>Actually, I do think that this should be done fast, since it is intended >>to >>close the gap (maybe a year or two) until the real typeof becomes >>available. > >Agreed. Let's do it! I would also like to help, as I think that Spirit is an awesome library/tool and would benefit greatly with auto/typeof support. One question though: I have a parser where I have created several external grammars to help modularize the grammar and employ the trick suggested in the techniques section (c.f. sub-grammar): using namespace boost::spirit; struct identifier_parser: public sub_grammar< identifier_parser > { public: typedef sequence_t < alternative< alpha_parser, chlit<> >, kleene_alternative_t< alnum_parser, chlit<> >::type >::type start_t; public: start_t start; public: inline identifier_parser(): start ( ( alpha_p | '_' ) >> *( alnum_p | '_' ) ) { } } identifier; NOTE: This is using various type construction helpers. Once you have a (sub-)rule like this, you can use it like: rule_t<ScannerT> tagName = !( identifier >> ':' ) >> identifier; I was wondering if this would cause any major problems when implemented with the typeof/auto hack (since it could then be implemented as a grammar). Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

RE: [boost] [Formal review] Collection Traits library
by Randy Bowen 05 May '04

05 May '04

> why would you want to view it in 80 columns? > IMO 80 cols per line is quite a thing of the past. > Nowadays, 100 or even more is more appropriate. On my 21" > monitor :) I have my IDE set to 110 cols/line. > I believe that 80 columns is part of the current Boost requirements/guidelines. (Debating the value of this is obviously another matter.) Randy Bowen Stamps.com

1 0

Re:Re:[boost] boost::serialization Remarks
by Robert Ramey 05 May '04

05 May '04

Martin Ecker wrote: > > > Is there work under way to fix this and have working DLL builds of > > > boost::serialization (just as there are DLL builds for, say, > > > boost::regex)? > > > > I have interest in addressing this. I do believe it is addressable > without > > too much difficulty but will require some extra care. There also might > be > > some restrictions on usage - I don't know yet. > > I looked into this some more and I believe to have found somewhat of > a solution (albeit a "hacky" one) for the template classes derived from > extended_type_info. If you don't mind I will send you my current > boost::serialization code base via private e-mail and you could maybe > have a look at it. As I wrote above, I do not yet know enough about > the internal structure of the library, so I can't say for sure if > my changes broke anything major. In the limited tests I did with the > demo samples that come with the library everything seemed to work fine > though. > OK > One thing that I have not yet addressed though is the need for > extended type info objects to unregister themselves from the > global registry. This is important when DLLs are loaded, unloaded, > and then loaded again. I believe this should be quite easy to > implement. Simply make a call to some unregister function in > the extended_type_info destructor, similar to the self_register > call in the constructor. I have yet to consider the issues related to dynamic loading/unloading of DLLS. The current system registers things at pre-execution time. I'm not sure what that means when the object to be registered via construction of a static object located in a DLL loaded at a subsequent time. > This actually brings me to another > question: Why is the self_register call not directly in the > base class constructor, i.e. in extended_type_info::extended_type_info, > but rather in the deriving classes? No particular reason as far as I can see. > > > My intention was the BOOST_CLASS_EXPORT be included in the header file. > > I don't quite understand how this can work reliably. Say, I have two DLLs. > In one DLL I have class A. A's header file also contains the > BOOST_CLASS_EXPORT(A) macro. Now a second DLL also needs to use this > class. Therefore it will include A's header file. This will result > in a static guid_initializer instance to be created in both DLLs, which > is unnecessary. Note that a new static variable instance should created for each archive included. If no archives are included, then the header with BOOST_CLASS_EXPORT can be included anywhere any number of times. The actual restriction should be that it be included only once for a given archive class. Looking at the code now, I see that its also creating an extended_type_info instance as well and this will lead to problems with multiply defined static instances. I believe this can be enhanced to skip this step of no archives are being included. That doesn't quite do it but it points the way to improving this. > Also with the current code it will cause the class' > extended type info to be registered twice, once in each DLL with a > different extended type info object each time. I believe my code > modifications will remedy this though, so it wouldn't matter if > the registration happened multiple times, but it is still unnecessary. > The only "proper" way I know of to avoid this is to always use the > export macros in .cpp files. I'm coming to this conclusion as well. > > This would mean code modules would be organized > > similar to the demo_pimpl example where the implementation of class > > serialization (invocations of ar << my_class_instance) are in separate > > modules from the headers rather than inline functions. > > I've looked at that sample, but since we are trying to integrate > boost::serialization into an existing project, reorganizing all of > our code is pretty much out of the question. > We tend to have the serialization code inlined in the header files > of the class it belongs to. This has so far proven to be good > for maintenance of the code as well (e.g. when a new member variable > is added to a class it is harder to forget to also change > the serialization code, if necessary). I think it's a mistake to dismiss this idea. I appreciate the ease of maintenance but in the type of project your working with I think it would be best to: a) refrain from defining serialize inline in the header file. b) implement serialize() in the my_class.cpp file for each class. c) include BOOST_CLASS_EXPORT in each my_class.cpp file d) instanciate the templates in the class *.cpp file for archive classes you expect to support. Only the my_class.cpp will included archive class headers. I believe it is common practice is to have an *.hpp file and a *.cpp file for each non-trivial class. So I would be surprised to find that much code reorganization would be required to implement this. I also believe that to reliably support libraries and DLLs of exported classes, such an organization will be required. It will also result in much smaller code with almost no loss of speed. If the code is compiled to a static library, the executable won't contain any "dead" code. If compiled to a DLL, the code won't have to be loaded unless it is actually used. Note that this organization will be required only for those class types which are serialized through pointers to derived classes. So it may not be as much as a burden as it might seem. Robert Ramey

1 0

Re:[boost] boost::serialization Remarks
by Robert Ramey 05 May '04

05 May '04

Martin Ecker wrote: > Is there work under way to improve the serialization of > shared_ptr/weak_ptr? Some kind of generic mechanism to serialize other > smart pointer types, such as boost::shared_array or boost::intrusive_ptr, > would be very nice. Indeed it would. I want to review the implementation of boost::shared_ptr in light of recent observations. The other ones will have to be done by someone else. Since you have a need/interest in this, perhaps you would like to do this and send it too me? > Our system consists of a number of DLLs and we need boost::serialization > to be built as DLL as well. > ... > I might have missed some > others. > Is there work under way to fix this and have working DLL builds of > boost::serialization (just as there are DLL builds for, say, > boost::regex)? I have interest in addressing this. I do believe it is addressable without too much difficulty but will require some extra care. There also might be some restrictions on usage - I don't know yet. > In the documentation I would like to see a remark in the section on Export > Keys, i.e. the BOOST_CLASS_EXPORT macro, that the export macros must not > be used in header files, at least not in header files included by multiple > clients, because they implement global variables that must exist only > once. My intention was the BOOST_CLASS_EXPORT be included in the header file. I believe that new static variables are created only when the header file is used together with an archive header file. So this multiple instances problem would be avoided by organizing modules so that the combination of headers only occurs once. This would mean code modules would be organized similar to the demo_pimpl example where the implementation of class serialization (invocations of ar << my_class_instance) are in separate modules from the headers rather than inline functions. Note that this will result in smaller and easier to maintain code. > One thing I also find unfortunate is that the BOOST_CLASS_EXPORT macro has > to be used at global scope and cannot be used inside namespaces. Is there > a way to fix this? The same goes for BOOST_SERIALIZATION_SPLIT_FREE. A number of people have noted this - I haven't yet found a satisfactory fix for this. > On MSVC 7.1 serialization of a std::vector<bool> doesn't work with the > default implementation of the boost::serialization library. Thanks, I'll look into this. Robert Ramey

3 2

[Boost-bugs] [ boost-Bugs-948514 ] lambda doesn't overload deref op correctly
by SourceForge.net 05 May '04

05 May '04

Bugs item #948514, was opened at 2004-05-05 07:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948514&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lambda doesn't overload deref op correctly Initial Comment: The dereference operator overload for lambda fn params seems to assume that the argument is an iterator. This precludes easy dereference of UDTs and smart ptrs. Thanks Bill Somerville bill(a)classdesign.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=948514&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: Re: [Thread] Perennial rw_mutex question
by Hurd, Matthew 05 May '04

05 May '04

> On Behalf Of Michael Glassford > * Rename to improve consistency and eliminate abbreviations: > Use "read" and "write" instead of "shared" and "exclusive". Just a quick note from the bike shop. I've always had an issue with rw/read/write as this is a common use case rather than shared/exclusive which is the real deal. Going along these lines I think rw_mutex is a bad name, though I grant it is commonly understood. The oxymoron shareable_mutex or something other shorter name would make me happier. 0.000000000000002 lira, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

Re: [Boost] Big integer library
by Richard Peters 05 May '04

05 May '04

"Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message news:c6quof$dtl$1@sea.gmane.org... > I have some questions. Will it be possible to say > > 1. typedef boost::rational< big_integer > big_rational. Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used. > 2. Why is faculty() a part of the interface. I have a generic version of > faculty in some prob&stat code I'm doing that I hope would work > with big_integer. Your generic version will most probably work. There is one difference, my version returns an expression instead of a value, which saves the creation of one temporary value. In this case, the gained performance is probably minimal. I'm happy to refactor this function out of the library, throw it away, or come up with a hybrid solution where the expression-returning version is included when both big_integer and your library is included. > 3. Are you planning big_float? I would be happy with focus on interface > specs and then better implementation later. Unfortunately not. I can see that big_float would have its uses, but I rarely even use float. My interests ly in algebraic computations such as cryptology. > The C++ standard could really use a "big" library and it's always nice > with a version in boost first. > > br > > Thorsten Thanks for the response, Richard Peters

10 18