- Boost - lists.boost.org

Ok to commit?
by Gennaro Prota 13 Apr '04

13 Apr '04

Sort of administrative question :) I'm going to commit an improved version of dynamic_bitset, in the next days. The version, which is in the sandbox, has finally had Jeremy's approval. My question is: to implement find_first and find_next, two new functions I have added, I use a simple lowest_bit<T> template, which in turn requires integer_log2<T>; so there are two new header files: a) http://tinyurl.com/36zsj b) http://tinyurl.com/2lb26 I think they provide two useful facilities in themselves. Would it be ok to commit them in the boost/ folder? Or should they belong to boost/detail/? Or maybe boost/pending/? -- Genny.

4 5

Serialization #16-18
by Alexey Nikitin 13 Apr '04

13 Apr '04

In file boost/archive/add_facet.hpp from line 23: // does STLport uses native STL for locales? #if (defined _STLPORT_VERSION) && !(defined _STLP_USE_NO_IOSTREAMS) // and this native STL lib is old Dinkumware (has not defined _CPPLIB_VER) # if (defined _YVALS) && !(defined __IBMCPP__) # define BOOST_ARCHIVE_OLD_DINKUMWARE_BENEATH_STLPORT # endif #endif IMHO, this incorrect because in new dinkumware library defined _YVALS and not defined __IBMCPP__. Result of that is error when compile with VC7.1 and STLPort with iostreams. Removing negation before "(defined __IBMCPP__)" is eliminate this problem. Regards, Alexey.

2 1

RE: [boost] regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 13 Apr '04

13 Apr '04

> > Actually, now that I look at the code, should it simply be > > > > < if(((m_match_flags & match_not_null) == 0) && (m_presult->length() == 0)) > > --- > > > if(((m_match_flags & match_not_null) == 0) && (m_result.length() == 0)) > > > > just below the original patch? That _seems_ to work. > > I've no time now, but I'll look into it, thanks, > > John. Thanks. BTW, meanwhile I noticed that it's not as simple as that. Above change helps with consecutive matches, but breaks empty matches, i.e. grepping "a*" over "---" gets stuck in an infinite loop. Ralph

2 3

RTL enhancements
by Arkadiy Vertleyb 13 Apr '04

13 Apr '04

Hi all, I just uploaded an enhanced version of RTL (the relational template library). First addition is a simple indexed set-based table implementation (I am using the old name, and our code is based on the reviewed version of the library. Once Joaquin comes up with the post-review version, we'll modify and upload our code). So far this implementation does not fully utilize all the indexed set capabilities that RTL can benefit from, but we will continue working on this subject. To use the indexed set implementation BY DEFAULT one can define the BOOST_RTL_USE_SET macro. Or the implementation type can be supplied explicitly, as a 4th parameter to the table_info class template, like: #define BOOST_RTL_USE_SET table<table_info< mpl::vector<id, name>, mpl::vector<id> > > t1; // indexed set based table table<table_info< mpl::vector<id, name>, mpl::vector<id>, mpl::vector<mpl::vector<id> >, sorted_strategy> > t2; // sorted vector based table The other additions are mainly based on our discussions with Pavel Vozenilek, and include: Fully redesigned/reimplemented join. ------------------------------------ We decided to get rid of our generic join, and replaced it with a simpler, range join, operator which can be used to join each outer tuple with a range in the inner relation, something like this: equal_join<mpl::vector<c1> >(t1, t2); range_join(t1, t2, lower_bound<mpl::vector<c1> >(), end()); Lambda enabled for the selection operator. ------------------------------------------- Something like this can be specified: selection(t, _1[c1()]==5 && _1[c2()] >=20);// SELECT * FROM t1 WHERE c1=5 AND c2>=20 A couple of things were renamed: BOOST_RTL_COLUMN(name, type); became BOOST_RTL_DEFINE_COLUMN(type, name); // looks more like C++ and rel::tuple became rel::row to avoid collisions with the Boost.Tuple library, that showed up once we started using the indexed set :( (now I am even more against the idea of putting stuff under the boost namespace) The other enhancements to the library and to the documentation to follow. These will include better assertions, serialization, performance estimates, etc. Here is the link: http://groups.yahoo.com/group/boost/files/tables.zip As always, any feedback is most welcome. Best regards, Arkadiy

1 0

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

12 Apr '04

Hi Rob, ----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 12, 2004 8:58 pm Asunto: Re: [boost] Re: Re: [indexed_set] revised naming proposal > > > Why not just "index::list?" > > > > "list" seems too terse to me. It could lead the reader > > to think it is some sort of container (which is not). Take into > > account the namespace can be populated in the future > > with other containers derived from the main one. > > I suppose in a given use case, a "using boost::index" (or "using > boost::multi_index") may be in force, so it would boil down to > just "list." > > However, neither "index_list" nor "list" really says the right > thing. How about turning it around: list_index? I don't get how list_index is more meaningful than index_list. I mean, index_list is a list (a typelist, actually) of indices (index specifiers, actually). Would you care to ellaborate? (thanx!) [...] > I agree with Thorsten's proposal. "multi_index_container" is > much clearer. I'm recording your opinion (and Thorsten's) My intention is to reach a final decision during this week. > > > from my part here. There's still the pending issue of whether > > to move into boost::container. > > I think the argument that "a" container library has to be the > first one is valid, but was there sufficient consensus that such > a namespace was warranted? If there is consensus, your library > is a perfect candidate. If there isn't, it would be painful to > put your library in the "container" namespace only to rip it out > later. If you don't do it and folks agree it is worthwhile, then > yours would be just one more library to move into the namespace > at that time. > Well, it's all about not wasting effort. Hopefully, some other boosters (and the authors of container libraries in Boost) will jump in and express themselves for a tie-break. Jeff thinks more or less how you do about not going down that road if no one else will follow. On a more philosophical level, I don't quite like the idea of 1st level namespaces per se. IMHO, these are the most plausible justifications for this kind of namespaces: 1. Help avoid pollution of boost namespace. 2. Group libraries semantically affine. 3. Group libraries that will be likely used in cooperation in many programs. As for 1, I don't see any danger of namespace pollution in Boost since libraries are accepted one by one and these things are carefully checked before. As for 3, I don't really think that a program using an indexed_set will get a greater chance of using also multi_array, for instance (on the contraty, I guess the probability will be actually less.) 2 is an aesthetical issue. I don't see any practical benefit from having this kind of grouping. One does not discover new libraries by way of exploring the "sourrounding" namespaces, so to say. If anything, the categorized lib index in Boost serves this purpose well. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Lunes, Abril 12, 2004 9:13 pm Asunto: Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection > Joaqumn M Lspez Muqoz wrote: > > > push_back() can also throw from the allocator if it runs out of > memory,> so you really need some proper clenaup regardless of the > guarantees> made by copying ops. Dave's suggestion of using RAII > is probably the > > most elegant way to deal with the situation: in my experience, > however,> this sort of scope guards perform worse than a > try{}catch(...){}. Your > > mileage may vary. > > Anything wrong with the following? > [code rewritten using new stack_construct facility] It looks fine to me. Also, please ignore my previous statement about the relative merits of try{}catch(...){} wrt to RAII. The performance gain of the former shows only, it seems to me, when using scope guards. In your case, in which destruction *always* takes place, I doubt anything can beat what you've just written. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection
by Robert Ramey 12 Apr '04

12 Apr '04

Joaqumn M Lspez Muqoz wrote: > push_back() can also throw from the allocator if it runs out of memory, > so you really need some proper clenaup regardless of the guarantees > made by copying ops. Dave's suggestion of using RAII is probably the > most elegant way to deal with the situation: in my experience, however, > this sort of scope guards perform worse than a try{}catch(...){}. Your > mileage may vary. Anything wrong with the following? // reserve space on stack for an object of type T without actually // construction such an object template< typename T > struct stack_allocate { T * address() { return static_cast<T*>(storage_.address()); } T & reference() { return * address(); } private: aligned_storage< sizeof(T), alignment_of<T>::value > storage_; }; // construct element on the stack template<class Archive, class T> struct stack_construct : public stack_allocate<T> { stack_construct(Archive & ar){ load_construct_data(ar, address(), 0U); } ~stack_construct(){ address()->~T(); // undo load_construct_data above } }; // sequential container input template<class Archive, class Container> struct archive_input_seq { // archive_input_seq(){} inline void operator()(Archive &ar, Container &s) { typedef BOOST_DEDUCED_TYPENAME Container::value_type type; stack_construct<Archive, type> t(ar); ar >> make_nvp("item", t.reference()); s.push_back(t.reference()); } };

1 0

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

12 Apr '04

Hi Pavel, ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Sábado, Abril 10, 2004 11:50 pm Asunto: [boost] Re: [indexed_set] revised naming proposal > > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> wrote > > > This is my 2nd proprosal for naming of the library > > formerly known as Boost.IndexedSet. > > > It may be helpful to add examples for each > suggested name, for easier orientation. > With pleasure: NAMESPACE+CONTAINER NAME Current: namespace boost{ namespace indexed_sets{ template<...> class indexed_set; } using indexed_sets::indexed_set; } Proposed: namespace boost{ namespace multi_index{ template<...> class indexed_container; } using multi_index::indexed_container; } INDEX NAMING Current: typedef indexed_set< employee, index_list< unique<identity<employee> >, non_unique<member<employee,int,&employee:age> >, sequenced<> > > employee_set; Proposed: typedef indexed_container< employee, index_list< ordered_unique<identity<employee> >, ordered_non_unique<member<employee,int,&employee:age> >, sequenced<> > > employee_set; NTH_INDEX_TYPE AND FAMILIY Current: typedef index_type<indexed_t,some_tag>::type index_t; typedef nth_index_type<indexed_t,n>::type index_t2; typedef indexed_t::index_type<some_tag>::type index_t3; typedef indexed_t::nth_index_type<n>::type index_t4; typedef iterator_type<indexed_t,some_tag>::type iterator_t; typedef nth_iterator_type<indexed_t,n>::type iterator_t2; etc. Proposed: typedef index<indexed_t,some_tag>::type index_t; typedef nth_index<indexed_t,n>::type index_t2; typedef indexed_t::index<some_tag>::type index_t3; typedef indexed_t::nth_index<n>::type index_t4; typedef index_iterator<indexed_t,some_tag>::type iterator_t; typedef nth_index_iterator<indexed_t,n>::type iterator_t2; etc. UPDATE MEMFUN Current: employee_set es; es.update(it,new_value); Proposed: employee_set es; es.replace(it,new_value); Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5

Re:[boost] Re: Seriialzation library draft # 18 uploaded to files section
by Robert Ramey 12 Apr '04

12 Apr '04

Joaquin Munoz wrote: > I think I detected a minor bug in collections_load_imp.hpp. > The operator() code for archive_input_seq reads: > inline void operator()(Archive &ar, Container &s) > { > typedef BOOST_DEDUCED_TYPENAME Container::value_type type; > stack_allocate<type> t; > load_construct_data(ar, t.address(), 0U); > ar >> make_nvp("item", t.reference()); > s.push_back(t.reference()); > t.address()->~type(); // undo load_construct_data above > } > This is AFAICS not exception-safe: if say s.push_back() > throws, the dtor for the stack-allocated variable t won't > be called. The same problem in similar code snippets > through this file. Apologies if my perception is wrong. Hmmm - An interesting point I never considered. Push_back from the standard library has a strong guarantee so the problem should boil down to one of the constructors (copy or inplace) throwing. Try/catch block could be added but it could be a little expensive for large collections and would be unnecessary in the most common case where inplace and copy constructors don't throw. I would like to use has_nothrow_constructor and has_trhow copy to address this but the language in the type_traits document suggests that this wouldn't be effective. Anyone is free to chime in here. Robert Ramey

3 3

Different kinds of line endings in CVS?
by Daryle Walker 12 Apr '04

12 Apr '04

I saw this in <http://boost.org/more/getting_started.html>: //========================================================================= Text file line endings in the .zip file are as supplied by each library developer. This works fine for Windows, but not for Unix/Linux. The tar.gz and .tar.bz2 files supply Unix/Linux friendly line endings. //========================================================================= I'm challenging the assertion that text-file line-endings should be developer-chosen. The archives are generated from a CVS export, right? I thought that CVS regulates all text files to have Unix-style line endings, and a CVS client will change a text file's line-endings upon check-in or -out from/to the appropriate character(s) for the client's platform. The developer would not have a choice. The only way around that would be if a text file was accidentally added to CVS in binary mode. However, storing a text file in binary mode unnecessarily has a large storage penalty. Check-outs and -ins also get messed up if a text file is in binary mode but the text editor is "smart" enough to clean up the difference (i.e. add extra line-break characters). If we have messed up text files like this, shouldn't we fix them up in the CVS repository? (Is that even possible?) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 3