- Boost - lists.boost.org

Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

> > While having pass-by-value > > may be more convenient and occur more often, the counter-intuitiveness > > of the semantics will lead to subtle bugs in people's code who > > misunderstand or forget bind's behavior in this area. > > A bold prediction in the face of contradictory evidence. Can you elaborate? You may have no problems understanding the library, but the first time I tried to bind with a reference, I ran into the same confusion. I am speaking from my own limited experience with the library. I've read the documentation: // Start of docs The arguments that bind takes are copied and held internally by the returned function object. For example, in the following code: int i = 5; bind(f, i, _1); a copy of the value of i is stored into the function object. boost::ref and boost::cref can be used to make the function object store a reference to an object, rather than a copy: int i = 5; bind(f, ref(i), _1); // End of docs I know this makes it explicit that you need a ref or cref to have bind store a reference to an object, but there is no reasoning behind this design decision in the documentation, or that I can find in the implementation and I've not stumbled across it in the mail archives. Best, John

4 3

[serialization] register_type and dll/so module
by Li Lirong 16 Apr '04

16 Apr '04

Hi, In the serialization library, when classes are never serialized directly but rather through a pointer to the base class, the user need to call register_type so that the archive contains information about the derived classes. However, sometimes those derived classes are implemented in another dynamic loaded (dll/so) module. The type of the derived classes will not be known at compile time. How can cope with this? Does the library provide any facilities to help the user in this situation? Best regards, Lirong

2 3

[serialization] + [boost.python] serialization of python object
by Li Lirong 16 Apr '04

16 Apr '04

Dear All, According to the documentation of boost.python, one can derive from c++ base class in Python and override the virtual functions in Python. However, is it possible to serialize the objects of the python class using the serialization library? Thanks and best regards, Lirong

1 0

library for managing a large number of FILE objects
by Jody Hagins 16 Apr '04

16 Apr '04

I know that C++ IOStreams are supposed to take over the world, and cstdio with FILE is considered taboo by some C++ efficionados. However, due to many reasons, lots of code still uses cstdio FILE I/O. One issue that comes up from time to time is the need to manage more files than the OS will allow a single process to have open simultaneously. I process tons of data, and this is an issue for me. I have developed a small library that provides on-demand caching of FILE pointers, so that an application can "open" as many FILEs as necessary, and use them as normal. A simple LRU eviction algorithm is used to reclaim FILEs when "all" have been used. I was discussing this library with another developer, and he said he has seen several questions recently about a similar issue, and he advised me to ask if there was interest here. This library, however, does not seem "on the edge" enough though... A very simple example of how you can use the library (of course there are better ways to do the following, but it is meant to be a small easy to use example). // Open 10,000 FILEs wjh::file_cache file_cache; std::vector<wjh::cached_fptr> fp; for (int i = 0; i < 10000; ++i) { std::stringstream strm; strm << "FILE_" << i; wjh::cached_fptr fptr = file_cache.open(strm.str().c_str(), "w"); if (!fptr) { std::cerr << strm.str() << ": " << strerror(errno) << std::endl; break; } fp.push_back(fptr); } // Randomly write to a particular file. for (int i = 0; i < 200000; ++i) { int x = rand() % fp.size(); fprintf(fp[x], "file %d, iteration %d\n", x, i); } Is it something useful for more than just me (and the pitiful souls who work for me and must use it) on this list? Is it something worth posting here?

2 2

Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

> Hello John, > > There's a big technical reason: > > If bind would have reference semantics, you could not do this: > > bind(f, 1, _1) > > Bind would have to take its arguments as > > template <class F, class A, class B, ...> > bind( F, A&, B&, ...) > > 1 is a non-const rvalue, which cannot be bound to non-const reference. I think I almost got it now, but I'm still a little confused about bind_template.hpp where the list template parameters are A1&, A2&, A3&, ... list1 for example stores a template parameter A1 as "A1 a1;". So this ends up not actually being a reference to a normal type T, but to the value<T> wrapper class? If not, what type is actually A1& in the listN declarations in bind_template.hpp? Thanks, John

2 1

Error in token_functions.hpp
by Joe Gottman 16 Apr '04

16 Apr '04

I am getting errors including the new version of token_functions.hpp without first including tokenizer.hpp. When I do, I get the following error (my compiler is VC++ 6.0): rror C2065: 'is_pointer' : undeclared identifier Including tokenizer.hpp first gets rid of the problem. I think you just need to add the line #include <boost/type_traits/is_pointer.hpp> to token_functions.hpp. Joe Gottman

1 0

Desired libraries - n-ary trees, hashing and arbitrary-precision ints
by Dave 16 Apr '04

16 Apr '04

Hello all, I just want to mention three libraries I have a need for which, I believe, are not currently in Boost. My purpose is to see if they are under development and what alternatives I have in the meantime. 1. A dictionary implemented in terms of a user-supplied hashing policy 2. A generic n-ary tree library parameterized by a vertex's user-defined satellite data; to be used in a generic state space search library I am writing and in storing a parse tree for an expression interpreter. Perhaps BGL could be used here????? Not sure of its appropriateness... 3. The frequently-requested arbitrary precision integer library Thanks, Dave

3 2

[serialization] Archives for binary marshalling
by mvogt＠juptech.com 16 Apr '04

16 Apr '04

For anyone interested in extending Robert Ramey's serialization library with derived archive types, the attached archives may be interesting. Included are an archive template for ordered binary marshalling output (big- or little-endian), and rudimentary specialisations for CDR and XDR formats. These aren't really new archives, since they derive from Robert's basic_binary archive classes, but they do demonstrate to some extent what needs to be done to modify the archive output. Issues I've had in extending the archives: - The difference between overriding 'save', 'save_override', 'vsave' and operator<< is not immediately obvious... - Controlling access to individual save/load overloads still has me stumped - There's something weird with initializing wchar_t's going on... Questions or comments welcome. Matt ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify mail.administrator(a)jupiters.com.au **********************************************************************

3 2

Re: [boost] Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 15 Apr '04

15 Apr '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Jueves, Abril 15, 2004 6:21 pm Asunto: [boost] Re: [indexed_set] revised naming proposal > Joaquín Mª López Muñoz <joaquin(a)tid.es> writes: > > >> > If I decided to rename index_list as indices: what > >> > would be your proposal for mpl_index_list? > >> > >> 'indexed_by_list<>' ? > >> > > > > Well, this is less satisfying, I'd rather "mpl" appear in the > name. What > > about "mpl_indexed_by"? > > Oof. What does this MPL stand for?? > Apart from index_list, there is an alternative construct called mpl_index_list such that, for example: mpl_index_list<mpl::vector<K1,...,Kn> > is equivalent to index_list<K1,...,Kn> mpl_index_list is provided as a convenience for MPL metaprograms synthezising instantiations of indexed_set. "mpl_indexed_by" is a possible renaming for "mpl_index_list" should we decide to rename "index_list" as "indexed_by". Suggestions for better names? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] suggestion on Serialization Library
by Robert Ramey 15 Apr '04

15 Apr '04

Allen Yao wrote: > It is not very convenient for me to use macros like > BOOST_SERIALIZATION_SPLIT_FREE, BOOST_SERIALIZATION_SPLIT_MEMBER to deal > with splitted load/save functions. Permit me to re-state your suggestion in order to test my understanding of it. Similar to the manner which we have created other serialization traits such as boost::serialization::version<T> create another one such as boost::serialization::split<T> Whose default implementation would return false. Please correct me if I've misunderstood this. It's a worthy idea. I'm not saying I'm convinced it's a good idea but certainly worthy of consideration. Here is my assessment. Currently to split serialize member function into save/load one uses template<class Archive> void serialize( Archive & ar, const unsigned int file_version ){ boost::serialization::split_member(ar, *this, file_version); } Or equivalently: BOOST_SERIALIZATION_SPLIT_MEMBER() With your suggestion this would change to: namespace boost { namespace serialization { struct split<my_class> { typedef mpl::false_ type; BOOST_STATIC_CONSTANT(bool, value = split::type::value); }; } // namespace serialization } // namespace boost Or in line with the other serialization traits: BOOST_SERIALIZATION_SPLIT (my_class So a) I don't see what would be gained as far as convenience, utility, and transparency compared to the current system. b) It would entail significant effort to implement and make the internals of the serialization library even more elaborate than they already are. c) It would require more documentation than the current system. > Additionally, when dealing with load/save functions of template class, > these macros help little. Users also have to read and understand what > these macros actually do and write their own serialize function to call > split_free or split_member accordingly. I don't think this change would help that situation. > I suggest that these implementation details on how the serialization > library determine to use single serialize function or splitted load/save > functions should be totally encapsulated and hidden behind the scene. This is widely held point of view that I don't always agree with. Sometimes hiding too much gives the illusion of ease of use but in fact introduces modal behavior which makes the operation hard to understand. In the worst cases it introduces a compile time global variable with compile time side-effects that are hard to trace back to the trait setting. So, I'm more wary about using traits than other people seem to be. > Am I missing something? I don't think you're missing anything. It would be possible to implement such an additional trait. We just disagree on whether it's a good idea. That's all. Robert Ramey

1 0