- Boost - lists.boost.org

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

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