April 2004 - Boost - lists.preview.boost.org

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

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

15 Apr '04

----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Miércoles, Abril 14, 2004 7:25 pm Asunto: Re: [boost] Re: Re: Re: [indexed_set] revised naming proposal [...] > > Don't forget "indices" or "indexes" in lieu of "index_list." > > multi_index_container > < > employee, > indices< > ordered_unique<member<employee,string,&employee::name> >, > ordered_non_unique<member<employee,int,&employee:age> >, > > > > If I decided to rename index_list as indices: what would be your proposal for mpl_index_list? Leave it like that? (check the MPL section on the advanced topics page, in case you don't know about this construct.) Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 5

Big integer library
by Richard Peters 15 Apr '04

15 Apr '04

Hello, A few months ago there was some discussion about an arbitrary magnitude integer library. I have now implemented such a library, which is located at http://groups.yahoo.com/group/boost/files/big_integer/. There are a few (incomplete) other libraries that provide the same kind of functionality. The main difference between this library and other libraries is that this library uses expression templates to avoid the creation of temporary values, which when the values become large provide an increase in performance. The library is not finished yet: most noticeably the test files are far from complete, but there are also a few others things like the documentation looks a bit ugly. Also a to-do is replacing the core operations like addition and multiplication by more efficient ones, and provide options to use external libraries like GNU MP. I am presenting you already with this library though, to see if it meets the desires for this kind of library, to see if there are things missing in this library, and maybe get some help from other members interested in further developing this library. best regards, Richard Peters

2 1

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

15 Apr '04

> So in summary, you weren't confused about how the library works; you > just were unhappy that you had no justification for how it works. > That lends no credence to your claim that "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." Alright. > P.S. if you want to understand the justification, see > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm Thanks, John

1 0