- Boost - lists.boost.org

pool_alloc with Pair Associative Container?
by Thomas 05 May '04

05 May '04

Can someone give me an example of how to use the boost pool_alloc allocator interface with a Pair Associative Container, like hash_map? I tried doing something like typedef hash_map<long long,double,longLongHasher,boost::pool_allocator< pair<const long long,double> > > tLongLongToDoubleHashMap; ,,,but I get errors when I try to compile code that actually uses tLongLongToDoubleHashMap. Thanks! Thomas -- Thomas <hazard(a)imsa.edu>

1 0

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

05 May '04

Bugs item #948785, was opened at 2004-05-05 13:44 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=948785&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=948785&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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

05 May '04

Arkadiy Vertleyb wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote > > > 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): > > > > [snip] > > 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). > >I think you would just have to register your identifier_parser class. The >typeof system then would treat it as an atom and not care what is behind >it. This was what I was thinking. But is there a way of handling the grammar template as a special case, e.g.: template< typename T > class deduce_type { typedef ... type; }; template< typename DerivedT > class deduce_type< boost::spirit::grammar< DerivedT > > { typedef DerivedT::type type; }; I am not saying that this is what it will look like as I am not up to speed with your typeof mechanism, but if something similar could be implemented, it would make custom grammars more powerful (may even reduce the number of types that need explicit registration). Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

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

05 May '04

Brian Braatz wrote: > Question- I was just looking for clarification. Does the boost > serialization library allow me to have objects on different platforms > stream to each other? Yes. However, the archive must be designed to be platform independent. This is a little bit more subtle than it would first appear. For example, consider the text archive. It stores all numbers as text delimited by spaces. That's portable. But suppose a machine which uses an 80 bit IEEE double stores a high precision value to an archive. Another machine that reads the archive might only have a 64 bit double. So, some of the original precision would be lost. Of course the original value would have been preserved to the extent possible on the new machine. Even here, moving to an ebcdic machine would require a custom codecvt facet which is not in library. Is this "portable"? You be the judge. Within the limitations of the above, text and xml archives can be considered portable. The binary archive is really "native binary" in that it doesn't make conversions for integer size or endianness. (It does check that the endianness and integer size are the same on the saving and loading machines so it might be portable between some pairs of machines). In general the binary archive should be considered non-portable and not suitable for archives meant to be transferred from non identical architectures. There has been lots of interest in making an XDR and CDR archives. I really haven't considered issues in using XDR or CDR. I don't know whether these are just standards for encoding low level types or describe a whole protocol. If it's the former, it would be pretty simple implement. Otherwise, we have the problem of matching the serial representation of some arbitrary C++ structure with some externally defined protocol. Though it might be possible in certain cases, this is not something that the serialization system has been designed to do. http://lists.boost.org/MailArchives/boost/msg63695.php The package includes a "portable" archive as a demo. It doesn't include code for floats and longs. The portable archive includes a lead byte for each integer indicating the number of bytes required to hold the value. If the integer doesn't "fit" in the loaded type, an exception is thrown. The usage of boost::uint_16 etc. doesn't have to be explicitly considered. I didn't have good method for handling floats and doubles across machine architectures. Now that I have suitable code for handling portable floats/doubles, (http://lists.boost.org/MailArchives/boost/msg63672.php) I might think of promoting portable_binary_?archive to a first class supported archive. It would be complete and general, but depend on the serialization library being implemented on the "other" machine. Not an unreasonable restriction in my view. For those who must have CDR/XDR I have no final answer. Robert Ramey

3 4

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