- Boost - lists.preview.boost.org

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

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

12 Apr '04

Hi Jeff, ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 11, 2004 8:31 pm Asunto: Re: [boost] Re: [indexed_set] revised naming proposal > On Sun, 11 Apr 2004 19:38:29 +0200, JOAQUIN LOPEZ MU?Z wrote > > I'm good with everything in the proposal, except I think the > library should > still be called multi-index containers. I think if you leave that > out people > are likely to miss the fact that the library provides replacement > containers. > You've got a valid point here. But I cannot turn your suggestion into a reasonably short name in the spirit of Boost.MultiIndex. Boost Multi-index Containers Library? This is too long to be scattered through the docs the way Boost.IndexedSet appears now. Shortened for easier reference to BMCL or BMICL? Maybe we should retain Boost.MultiIndex and use the fuller "Boost Multi-index Containers Library" at the header and preliminary paragraphs? I'm really lost here, naming issues are so nasty. Looking fwd to knowing your ideas. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

Boost socket library
by Shridhar Daithankar 12 Apr '04

12 Apr '04

Hello All, While browsing various boost resources, I ran into http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket Can anybody point me to latest updates? I am very interested in such a library. Regards Shridhar

2 1

Seriialzation library draft # 18 uploaded to files section
by Robert Ramey 12 Apr '04

12 Apr '04

Fellow boosters, I just uploaded version #18 of the proposed boost serialization library to the files section. It can also be downloaded at www.rrsd.com It contains improvements in code/file/namespace organization, better documentation on how its implemented, and a number of arcane bug fixes. This is the version I will refer to during the upcoming review. Robert Ramey

5 4

[BGL] property default constructor
by Vladimir Prus 12 Apr '04

12 Apr '04

The default constructor of boost::property is defined as: template <class Tag, class T, class Base = no_property> struct property : public Base { .... property() { } So, for the case where T = builtin type or a pointer, it's simply not initialized, per rules in 12.6.2/4. Is this desired behaviour? I was bitted by this twice, because I have: typedef boost::property< semantics_tag, Semantic*, boost::property< boost::edge_weight_t, unsigned > > EdgeProperties; and neither of properties is initialized when I do: add_edge(v1, v2, g); Maybe, the ctor should be: property() : m_value() {} ? - Volodya

1 0

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

12 Apr '04

Hi, This is my 2nd proprosal for naming of the library formerly known as Boost.IndexedSet. I've changed my mind with respect to some of the decisions stated at my first proposal (rationale is given.) There is also a minor clashing issue that I'd want to publicize before the final commit. I list here only the points that have changed with respect to my first proposal, that you can find at: http://lists.boost.org/MailArchives/boost/msg62611.php If no one complains about this 2nd proposal I'll apply the necessary changes by the end of the following week. NAMESPACE * Proposal: boost::multi_index. This differs from the previous proposal in which boost::container is not used; rationale: resulting qualified ids would be too long, which would force most users to use namespace aliases (not a good thing, this has been discused before in connection with Boost.Filesystem) or apply using directives. Another reason is that a good deal of preexisting Boost containers don't live in boost::container and it does not seem such a migration will ever take place. CONTAINER NAME Proposal: indexed_container. Rationale: composite_container sounded too vague; indexed_container is reminiscent of the previous name indexed_set, so in a sense it won't break the (admittedly shallow) familiarity with the library that boosters might have built up so far. LIBRARY NAME: Proposal: Boost.MultiIndex. Rationale: In sync with the namespace. REST OF NAMING ISSUES: Like in the 1st proposal. NAME CLASHING ISSUE: The renaming of nth_index_type & familiy to nth_index etc. uncovered a name clashing issue in GCC (and only in this compiler AFAIK): using namespace boost::multiindex; typedef index<indexed_t,some_tag>::type index_t; //clash! The index<> class template clashes with the non-standard C-runtime function index() living in <string.h>. Unfortunately, most std headers (even C++ ones) seem to implicitly include <string.h> as well, so the clash is likely to occur. In my opinion, this clash is not important enough, for the following reason. index<...> is provided mainly as a workaround for MSVC 6.5, which has well-known problems with nested templates. In GCC one can write instead: using namespace boost::multiindex; typedef indexed_t::index<some_tag>::type index_t; using the nested index<...> variant. This is always preferrable, and does not clash in any manner with global index() in <string.h>. Of course, there are other obvious resolutions to this clashing issue. For this reason, my proposal is to effectively change index_type<...> to index<...>, and similarly with the other related template classes as previously proposed, even in the presence of this clashing issue. If someone thinks differently, please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

cref(_1)
by David Abrahams 12 Apr '04

12 Apr '04

Hi, I have this code that isn't compiling because of the "forwarding problem" limitation of boost::bind: std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, _1)); The problem is that an implicit conversion is required between the reference type of the difference_iterator and the argument type of writeVInt. It seems to me that, since I know that binding to an rvalue is required, we ought to have a way to say "force this to be a const ref". I thought of something like std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, boost::cref(_1))); ^^^^^^^^^^^^ ^ I know it's not pretty, but it sorta does what we want. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 7

Signals documentation error
by Edward Diener 12 Apr '04

12 Apr '04

The documentation for the Signals library shows an Allocator type as the second template parameter to the signal template class when one looks in the Reference section. In the header file and in other references to the usage of the signal template class, no such template parameter exists, and the second parameter is the Combiner. I believe the Allocator type may have been in an early version of the signal template class and the doc was never corrected to take it out.

2 1