- Boost - lists.boost.org

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

Formal Review: Assignment Library
by Tom Brinkman 11 Apr '04

11 Apr '04

The review of Assignment Library library, written by Thorsten Ottosen 2003 (nesotto(a)cs.auc.dk) starts today(April 1, 2004)and runs for 10 days. Latest version of the library is available at: http://groups.yahoo.com/group/boost/files/assignment/ (204 kB) or in the sandbox. What it is? The purpose of this library is to make it easy to fill containers with data by overloading operator the comma, () and operator()(). Example: To fill a vector with values you write: #include <boost/assign/stl.hpp// for operator+=() #include <vector> using namespace std; using namespace boost::assignment; vector<intvalues; values += 1,2,3,4,5,6,7,8,9; values += foo1(), foo2(), foo3(); History of the project: The idea for an initialization library is not new . The functionality of this library resembles Leor Zolman's STL Container Initialization Library a great deal, but it does not rely on string passing to achieve its goals. The library is non-intrusive and puts only a minimum of requirements on its supported classes. (change classes to types) The Initialization Library overloads the comma operator in a safe manner by letting free standing functions return an object that is responsible for the initialization. Therefore it takes explicit action from the programmer to begin using the overloaded operator,(). The operator comma is never overloaded for user-defined types. Portability: Library has been successfully compiled and tested with MVC++ 6.0, MVC++ 7.0, MVC++ 7.1, GCC 3.2 (under Cygwin) Comeau 4.3.0.1, Intel ICC 7.1 and Intel ICC 8.0. There are known limitation on platforms not supporting partial template specialization. Review Comments: Your review comments are welcomed. Found problems and suggestions for documentation are highly sought. Requests for new features requests will shape the way this library will evolve in future. 1. Where should the main libraries header files be placed. This is header only library and should be fairly easy to manage.Should it be placed in the utilty folder or its own folder? 2. Should the headers be broken up? This library has extensions to boost::array, boost::ublas and boost::graph. Should those headers be placed in their respective folder or kept together with the headers associated with the main Assignment library headers. Or, should the boost library extensions remain just as examples of how to extend the library. 3. Should the fixed_size_asssigner only throw on out_of_bounds exception or should it default initialize the remainning elements? Two classes can throw an exception in their destructor. This is done when detecting eg. a boost::array has not been initialized with enough elements. Should this be replaced by default initializing the remaining elements? 4. This library needs to use the boost test framework. Review Manager Tom Brinkman reportbase(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

8 21

BOOST_PP_IDENTITY
by David Abrahams 11 Apr '04

11 Apr '04

How come I can't find it in the documentation index? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

BCC weirdness
by Andreas Huber 11 Apr '04

11 Apr '04

Hi there While trying to port my fsm proposal to BCC5.6.4, I encountered the following compiler error: "simple_state.hpp": E2188 Expression syntax at line 389 The error is in the following code: // ... typedef typename context_type::outermost_context_type outermost_context_type; typedef typename context_type::inner_context_ptr_type context_ptr_type; typedef typename context_type::state_list_type state_list_type; // *** error on the following line *** typedef intrusive_ptr< inner_context_type > inner_context_ptr_type; typedef typename detail::make_list< InnerInitial >::type inner_initial_list; BOOST_STATIC_CONSTANT( detail::orthogonal_position_type, no_of_orthogonal_regions = mpl::size< inner_initial_list >::value ); typedef typename mpl::push_front< typename context_type::context_type_list, context_type >::type context_type_list; // ... I don't have a clue what BCC's problem is here, for the following reasons: - This code compiles just fine on MSVC7.1, GCC3.2 and Intel8.0 - The line on which the error is reported looks completely harmless to me - No amount of commenting out code following the problem line changes anything in BCC's diagnosis Does anyone have any hints on how to resolve this? Thanks & Regards, Andreas P.S. The full code can be found at http://boost-sandbox.sf.net/fsm.zip or in the sandbox CVS. The error appears while trying to compile the StopWatch example.

2 2