- Boost - lists.boost.org

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

wave works on simple_fun fails in pp_enum_params
by Larry Evans 17 Feb '05

17 Feb '05

I got wave to work on this: <----------------- #define DOUBLE(X) X,X #pragma wave trace(enable) DOUBLE(aaa) #pragma wave trace(disable) >----------------- but it tops out the cpu and finally aborts when BOOST_PP_ENUM_PARAMS is used. Heres the output from make: <----------------- cd /home/evansl/prog_dev/boost-release/boost_1_32_0/wave/wave/tools/wave/build/ make wave cat pp_enum_params.cpp #include <boost/preprocessor/repetition/enum_params.hpp> #pragma wave trace(enable) BOOST_PP_ENUM_PARAMS(3, class T) #pragma wave trace(disable) date Wed Feb 16 19:19:41 MST 2005 wave --traceto pp_enum_params.trace.out --output pp_enum_params.pp.out -S /usr/include/c++/3.3 -S /usr/include/c++/3.3/i486-linux -S /usr/include -S /home/evansl/prog_dev/boost-release/boost_1_32_0 pp_enum_params.cpp make: *** [wave] Killed Compilation exited abnormally with code 2 at Wed Feb 16 19:23:55 >----------------- Has anyone had success on non-trivial cases?

2 1

singleton template template parameters
by Jason Hise 16 Feb '05

16 Feb '05

In my singleton code, I have been using a template template parameter in my lifetimes for the creator[1], so that client code does not need to duplicate writing the type when specifying the creation policy. The drawback to this is that the creators which provide additional policies need to use a nested struct to avoid breaking the template signature that creators are required to have. A perfect example is the bool_creator[2]: template < bool Value > struct bool_creator{ template < typename Type > class creator { // pass Value to Type's ctor in create method }; }; If I wanted to be consistent, I would be tempted to do the same with my lifetime policies, separating the Type template parameter from the rest and having the singleton use a template template parameter for the lifetime. However, I suspect this would just make client code really ugly when it tried to specify the lifetime it wanted to use. In addition, I am willing to bet that a lot of compilers choke on template template parameters. As an alternative, I am thinking of switching the creator policy to a non template template policy. Although this would make client code have to plug the name of their class into the base singleton template yet a third time, I am thinking that in the end it would be more portable and cleaner. Thoughts? -Jason [1] Yes, I made the name change from allocator to creator in my code. The change has not yet been uploaded though, so keep in mind that creators in this message refer to allocators in the current online code, and bool_creator is really bool_alloc at the moment. [2] I'm thinking of dropping bool_creator from the library. Instead of providing it directly, I'll develop it in the documentation as an example custom creator and go on to show how it can be used to implement a zombie singleton. Of course, if you think it should stay in the library let me know, I can be persuaded to keep it.

2 3

problem with boost::variant and borland
by Robert Ramey 16 Feb '05

16 Feb '05

I have a program which consists on one line: #include <boost/variant.hpp> If I try to compile this using the main CVS tree, I get the following with borland 5.51 and 5.64 compilers: Error E2401 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Invalid template argument list Error E2041 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Incorrect use of default Error E2040 C:\BoostMainCVS\boost/variant/detail/substitute_fwd.hpp 50: Declaration terminated incorrectly Error E2394 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Too few arguments passed to template 'substitute<T,Dest,Source,Arity>' Error E2040 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Declaration terminated incorrectly Error E2228 C:\BoostMainCVS\boost/variant/detail/substitute.hpp 101: Too many error or warning messages What can be done to fix this? Robert Ramey

2 2

[repost][multi_index][hash][rfc] Hashed indices preview + Boost.Hash
by Joaquín Mª López Muñoz 16 Feb '05

16 Feb '05

Allow me to repost this message from a couple of days ago, since nobody responded :( In another situation, I could proceed according to my own judgement, but point (6), in particular, necessitates a public discussion, IMHO. Thank you, Hello all, You can find a preview version of Boost.MultiIndex including hashed indices plus Daniel James' Boost.Hash library at the Sandbox Files area: multi_index_140205_plus_hash_part_1.zip multi_index_140205_plus_hash_part_2.zip (split in two for maximum size reasons.) There are a number of things we'd like to ask you feedback about: 1. Hashed indices are modeled according to the latest TR1 draft, with some significant diversions: 1.1. erase() does not throw ever, even it the user-provided Hash object throws. This is imposed by the general framework of Boost.MultiIndex. This goodie does not come for free: if the Hash object throws, erase() decays to a linear search. Not that there's any alternative, but I'd like to point it out. 1.2. insert() has strong exception safety (TR1 only requires basic.) Again, the way Boost.MultiIndex is designed forces this. 1.3. hash indices iterators are bidirectional. 1.4. Usual implementations use one pointer per bucket, whereas Boost.MultiIndex has two pointers per bucket. This addresses potential performance problems of insert() and erase() under low load conditions, as discussed in http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1756.pdf issue 6.14. Is this convenient? 2. The material is complete except for a section in the tutorial and possibly one more example (example 8 already exercises hashed indices.) Tests fully sport hashed indices. The reference is also updated. 3. All in all, I'd greatly appreciate your comments on this: suitability, documentation, performance, etc. I plan to commit this to the CVS if nobody objects in a reasonable amount of time (a couple of weeks.) I'm open to all kind of suggestions --I'm eager to recieve them, as it happens :) 4. As for Boost.Hash, this library by Daniel James' implements the ideas for std::tr1::hash (albeit in boost namespace) proposed by Peter Dimov in the aforementioned paper, issue 6.18. The idea is to provide a general purpose hash<> utility for use by * Boost.MultiIndex * TR1-based unordered containers (Daniel is working on this.) * Eventually, wrapping by Boost.TR1. 5. The library comes fully documented and tested, and in our view well prepared for uploading to the CVS. 6. Yet, this hasn't undergone any formal review, so some of you might (with reason) object to its being commited to the CVS. From our point of view, we have three valid alternatives: * Boost members agree to have it in CVS without more ado. * As this is used by Boost.MultiIndex, Boost.Hash is suitable for fasttrack review. * This is untolerable and the library should be push_back()'ed to the review queue. Meanwhile, Boost.Hash should live as an impl detail of Boost.MultiIndex. We hope you find the material useful and look forward to knowing your opinions about the issues brought forward. Best, Joaquín M López Muñoz Daniel James

4 4