February 2005 - Boost - lists.preview.boost.org

[inspection]
by Jonathan Turkanis 17 Feb '05

17 Feb '05

Hi, A high percentage of the html documents in the iostreams library are listed by the inspection tool as unlinked. These documents are not really unlinked, however, and I am having trouble figuring out what is triggering the erroneous report. Among the documents listed as unlinked are menu.html and home.html, which are the entry points into the iostreams documentation. Any help would be appreciated. Jonathan

4 7

inherited operators
by Jason Hise 17 Feb '05

17 Feb '05

Sometimes I like to play around with obscure code, just to see what it does. The following really surprised me: #include <iostream> struct A { public: bool operator == ( const A & rhs ) { std::cout << "A\n"; return true; } }; struct B { public: bool operator == ( const B & rhs ) { std::cout << "B\n"; return false; } }; struct C : public A, public B { }; int main ( ) { C c1, c2; if ( c1 == c2 ) std::cout << "Equal\n"; return 0; } Compiled on MSVC 7.1, this outputs: A Equal I would have expected this code not to compile at all, because the == overload seems ambiguous. Is this result standards conforming? If not, what would the standards conforming result be? Does this fall into the realm of undefined behavior? -Jason

3 3

Re: [boost] Re: [indirect container] RFC on naming of libraryandclasses
by JOAQUIN LOPEZ MU?Z 17 Feb '05

17 Feb '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Jueves, Febrero 17, 2005 8:12 pm Asunto: [boost] Re: [indirect container] RFC on naming of library andclasses [...] > | If indirection is not really the unifying theme, perhaps you > should use the > name > | Boost.ManagedContainer, which I think was suggested at some point. > | ('ManagingContainer' might be more correct, but doesn't sound good.) > > Managed container is a good name. To recap, I think these are good > condidates: > Boost. Managed Container > Boost. Managed Pointer Container > Boost. Pointer Container > Boost. Clonable Container > Boost. Clonable Pointer Container > Boost. Cloned Container > > My personal favourite would be Boost.Cloned Container > with class names like this: > > cloned_vector<T> > cloned_map<Key,T> > > When I think about it, I see cloning as the most central concept; > in fact, the > only new policy of the containers is the CloneAllocator. > IMHO, "cloned/clonable container" hardly suggests what the lib is about: a clonable object has a rather well defined meaning, and so a clonable container seems to mean a container with some sort of clone() memfun. "Clonable objects container" (better than "clonable pointer container") is 100% accurate, but too verbose. A possibility without ambiguities is "clone container", i.e. a container of clones. As for the "managed" line, I think it resonates with some issues none of which has to do with the subject at hand: * "managed" as bounds checked. * "managed" as belonging to the world of C++/CLI (ugh!) So, if we rule out "indirect" for the reasons you explained, we're left with "pointer container". I think this is good: * std::set is a value container (elements have value semantics), so it is natural to extend the idea to ptr_set being a pointer container. * The term has some tradition. * It doesn't sugest anything different to what the lib is about. Actually ptr_containers do more than just holding pointers, but well. * When you augment the lib to support shared_ptrs, the name still holds. To sum it up, I vote for "pointer container", "clone container" being my close-second choice. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

[indirect container] RFC on naming of library and classes
by Thorsten Ottosen 17 Feb '05

17 Feb '05

Dear all, I will soon start to write some more documentation for the indirect container library (formerly called the smart container library). Before I start on that I would like to get a vote on the preferred naming of 1. the library itself 2. library classes Ad 1: library name: -------------------- Boost.Indirect Cotainer was suggested by Joaquin. It sounds reasonable to me. I don't have any alternatives, but suggestions are welcome. Ad 2: library classes: --------------------- The library currently consists of the following major classes in namespace boost: ptr_array ptr_vector ptr_list ptr_deque ptr_set ptr_multiset ptr_map ptr_multimap ptr_sequence_adapter ptr_set_adapter ptr_multiset_adapter ptr_map_adapter ptr_multimap_adapter Should these names persist? Or should we go for something like indirect_array, indirect_vector etc? br -Thorsten

4 18

Re: bald singleton pointers
by Dave Handley 17 Feb '05

17 Feb '05

Jason Hise wrote: > > I would like to get general feedback on a feature that has been > requested. Some background: > > Right now, my singleton pointer classes serve a variety of purposes. In > the first place, they are the access mechanism for a singleton. Any > pointer constructed immediately points to the singleton instance (or > possibly null if the instance hasn't been created yet). If the > singleton uses instant_creation, the first pointer created creates the > singleton instance. When a member is accessed through a singleton > pointer, an intermediate pointer type performs locking, and if > lazy_creation is set it may also create the singleton instance. > Regardless of the lifetime mechanism used, when the singleton instance > gets destroyed all pointers instantly reflect this by becoming null. > > It has been suggested that I provide a mechanism to get a bald pointer > to the instance, such as an unsafe_ptr member function of either the > pointer class or the singleton itself. I feel that such a mechanism > would be very dangerous, because the bald pointer could not perform lazy > creation, it would not lock the operations, and it would not reflect > when the singleton is destroyed. > > Are there instances in which allowing bald pointers to exist is > necessary and/or useful? > The only instance that I can think of where you may want to do this is in a multi-threaded environment. And even then only in a very specific set of circumstances. Specifically, you may want to do this when you don't want the overhead of a lock, but, for some other reason, you can absolutely guarantee that concurrent access to the object (or parts of the object you are accessing) is valid. If I'm honest though, I'm having some difficulty convincing myself that something like this would actually genuinely be useful. Perhaps if you could get a "bald pointer" through a protected member, that was therefore only accessible to derived classes (hence the singletons themselves). This could be useful to build into a static access function that provided a safe pointer, but perhaps without the overhead of a lock? Personally, I would be quite reluctant to provide such a feature... Dave Handley

9 20

GMane Outage
by David Abrahams 17 Feb '05

17 Feb '05

GMane was apparently down for part of this morning, and it looks as though it may have dropped some Boost messages, such as http://lists.boost.org/MailArchives/boost/msg79129.php. If you care what you missed, you might want to go back and re-read. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Entire boost 1.32.0 source-code online
by christopher diggins 17 Feb '05

17 Feb '05

I have pretty-printed the entire source-code for boost 1.32.0 in html (along with my current version Jonathan Turkanis's BIL library) and placed it on the OOTL web site. The table of contents is at http://www.ootl.org/boost/toc.htm . The html formatted version is mirrored with the original source. For instance : http://www.ootl.org/boost/any.hpp.htm is a formatted html version while the raw text version is at http://www.ootl.org/boost/any.hpp . The formatting program used was built using the YARD parser version 2.0 beta ( http://www.ootl.org/yard/ ) which I mentioned previously on this list. The source for the formatter is at http://www.ootl.org/yard/toc.htm . Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org PS. Brian, I am still working on the next profiler release and test suite.

1 0

Dynamic Exception Handlers
by David Abrahams 17 Feb '05

17 Feb '05

Can it really be two years ago that I talked about refactoring the mechanism in Boost.Python? http://aspn.activestate.com/ASPN/Mail/Message/boost/1537162 Well, I had to do it for a talk I'm giving, so here it is. It could easily be boost::detail-ized. Is there still interest? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost.Test doc bug.
by Hubert Holin 17 Feb '05

17 Feb '05

Somewhere in the E.U., le 17/02/2005 Bonjour It looks as though the Boost.Test doc has a slight sync issue. The BOOST_CHECK_PREDICATE macro is described (in file boost/libs/test/doc/components/test_tools/reference/index.html) as having to be used thus: 8>< ------------------------------------------- ><8 int test.cpp( int, char* [] ) { int i = 17; BOOST_CHECK_PREDICATE( std::not_equal_to<int>(), 2, (i,17) ); // ^^^^^^^^^^ return 0; } 8>< ------------------------------------------- ><8 whereas Boost.Test's test uses (in file boost/libs/test/test/test_tools_test.cpp) the following form: 8>< ------------------------------------------- ><8 using std::not_equal_to; CHECK_TOOL_USAGE( BOOST_CHECK_PREDICATE( not_equal_to<int>(), (i)(17) ), // ^^^^^^^^^ output.is_equal( CHECK_PATTERN( "error in " TEST_CASE_NAME ": test not_equal_to<int>()( i, 17 ) failed for ( 17, 17 )\n", 2 ) ) 8>< ------------------------------------------- ><8 Of course the later compiles while the former does not. Merci Hubert Holin

2 1

multi_index_container issue
by David Gruener 17 Feb '05

17 Feb '05

Hello, i just started using the boost::multi_index_container and ran into some trouble. I'm using boost version 1.32. Well, i tried a slightly modified version of Example 6 ("complex searches and foreign keys"). This is the code: -------------------------------------------------------------------------- #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/mem_fun.hpp> #include <string> using namespace std; using namespace boost; using namespace boost::multi_index; template<class KeyExtractor1,class KeyExtractor2> struct key_from_key { public: typedef typename KeyExtractor1::result_type result_type; key_from_key( const KeyExtractor1& key1_=KeyExtractor1(), const KeyExtractor2& key2_=KeyExtractor2()): key1(key1_),key2(key2_) {} template<typename Arg> result_type operator()(Arg& arg)const { return key1(key2(arg)); } private: KeyExtractor1 key1; KeyExtractor2 key2; }; struct person { string get_name() const { return "GM"; } // XXX }; struct car_manufacturer : public person // XXX { }; struct car_model { string model; car_manufacturer* manufacturer; int price; }; multi_index_container< car_model, indexed_by< ordered_unique< key_from_key< const_mem_fun<person,std::string,&person::get_name>, member<car_model,car_manufacturer*,&car_model::manufacturer> > > > > mic; -------------------------------------------------------------------------- As one might see, the change i made is that the key get_name() of the car_manufacturer now comes from a base class called person. However, this code wont compile because the compiler argues that there is no '*' operator for car_manufactuerer. I found out that the problem is the handling with the so called chained pointers in the mem_fun structs. template<typename ChainedPtr> Type operator()(const ChainedPtr& x)const // [1] { return operator()(*x); } Type operator()(const Class& x)const // [2] { return (x.*PtrToMemberFunction)(); } In the example the compiler calls [1] for car_manufacturer*, which seems right. After that, it can chose (among other methods) between [1] and [2] (Class = person) with argument type car_manufacturer and choses the better matching [1] with the followed error. However, maybe things could be done better here. The mem_fun structs could be smart enogh to deal with classes derived from template argument Class. That means [2] should be called in the case of operator() with a "Class"-derived argument. I dont know much about metaprogramming, but the following diff for const_mem_fun (as an example) of file mem_fun.hpp seems to work with a compiler supporting full template specialisation at class scope. Unfortunately gcc up to 3.4 doesn't seem to support this, while icc 8.0 does. I'm pretty sure there is a better sollution than mine, assumed that a "problem" even exists, which is my question to you. :] ------------------------------------------------------------------------------- *************** *** 12,17 **** --- 12,18 ---- #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/mpl/if.hpp> #include <boost/type_traits/remove_reference.hpp> + #include <boost/type_traits/is_base_and_derived.hpp> namespace boost{ *************** *** 45,54 **** { typedef typename remove_reference<Type>::type result_type; ! template<typename ChainedPtr> ! Type operator()(const ChainedPtr& x)const { ! return operator()(*x); } Type operator()(const Class& x)const --- 46,58 ---- { typedef typename remove_reference<Type>::type result_type; ! template<typename MaybeChainedPtr> ! Type operator()(const MaybeChainedPtr& x)const { ! return dispatch_cptr< typename mpl::if_< ! is_base_and_derived<Class, MaybeChainedPtr>, ! Class, ! MaybeChainedPtr>::type > (x); } Type operator()(const Class& x)const *************** *** 65,70 **** --- 69,87 ---- { return operator()(x.get()); } + + private: + template<typename MaybeChainedPtr> + Type dispatch_cptr(const MaybeChainedPtr& x)const + { + return operator()(*x); + } + + template<> + Type dispatch_cptr<Class>(const Class& x)const + { + return operator()(x); + } }; ------------------------------------------------------------------------------ Would some type handling like this make sense? If not, whats the best way to use dervied member function of a (pointer)member of the container type as key? If yes, are there similar issues in other extractors like member extractor? --David

2 1