- Boost - lists.boost.org

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

suggestion on Serialization Library
by Allen Yao 15 Apr '04

15 Apr '04

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. 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 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. I suggest that a traits class to be used by the user instead of macros like BOOST_SERIALIZATION_SPLIT_FREE. For example, the traits class can be named "serialization_traits", its default implementation is somthing as follows: template <typename T> struct serialization_traits { static const bool has_split_load_save = false; }; It can be (partially) specialized for types that has split load/save functions. Then, the serialization library can use this traits class to determine whether to call a single serialize function or splitted load/save functions for a specific type. Am I missing something? Best regards. Yao, Zhen

2 1

Re: Big integer library
by Richard Peters 15 Apr '04

15 Apr '04

One note on portability: the example and test file compile under Visual C++ 7.1 and gcc 3.2.2 best regards, Richard Peters ----- Original Message ----- From: "Richard Peters" <r.a.peters(a)student.tue.nl> > 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 >

1 0