- Boost - lists.boost.org

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

19 Feb '05

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

2 1

Profiling Library suggestion
by christopher diggins 19 Feb '05

19 Feb '05

I was searching around boost for mention of a profiling library. A fellow by the name of Carl Daniels posted something about an invasive profiling library. I was wondering in anyone knows what happened to that project? Profiling seems lacking at Boost, is anyone else interested in such a thing? Would a trivial policy driven RAII type be sufficient to garner interest as a mini-library? e.g. struct ProfilerDefaultPolicy { OnElapsed(int msec) { cout << "time elapsed (msec): " << msec << endl; } }; template<typename Policy_T = ProfilerDefaultPolicy> class Profiler { public: Profiler() { mnStart = GetTickCount(); }; ~Profiler() { Policy_T::OnElapsed(GetMSecElapsed()); }; int GetMSecElapsed() { return GetTickCount() - mnStart; }; int GetTickCount() { return int(double(clock()) * 1000 / CLOCKS_PER_SEC); }; private: int mnStart; }; usage: void MyRoutine() { Profiler<> p; // do stuff } Pretty trivial (and probably not boost-worthy), but I find it very useful. Does anyone want to take this and run with it (i.e. boostify it)? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

14 67

Broken links to CVS information
by Julio M. Merino Vidal 19 Feb '05

19 Feb '05

Hi! first of all, I should say hi to everybody, since I'm new to the list. I hope this is the correct mailing list to send a patch against the website (according to the page about bug reporting, it should be). During the last past few days, I've been reading about Boost at the website because I'm interested in using it in one of my projects. I must say that the website is great. It has lots of information and is well organized. Anyway, while doing so, I've came across some broken links to the CVS access information. (As well as some typos, but I have to re-find them...) They point to the obsolete (according to the logs) download.html file, while they should be pointing to getting_started.html. I've attached a patch which corrects this. BTW, vim warned me saying that the files I changed in the patch do not have a newline at the end. It added one automatically, but I've removed that chunk from the patch. Is this behavior expected? IMHO, the newline should be there (otherwise, cat <file> looks ugly). Kind regards, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

3 3

New Logging Library
by John Eddy 19 Feb '05

19 Feb '05

I have continued working on a logging library as a possible contender for a new Boost library. I have made sweeping changes inspired by comments and requests from a number of people (all very helpful). Here are some of the properties of the library as it is now. All components are completely independent of one another and highly parameterized for flexibility. The primary components are: -Entries which can be anything at all (built-in or user-defined types). There are a number of custom entries that I have created that support for example ostream like formatting. -Logs which actually go about the job of storing/processing/whatevering entries. I have created a few logs for writing to files, ostreams, storing entries in a list, etc. -Log managers are intermediaries between users and logs. They can do whatever they wish prior to passing entries on to logs. I have implemented a few managers so far. 1 that does virtually nothing. 1 that discriminates based on logging levels (only entries of appropriate levels get logged) and one that discriminates on levels and supplies a callback mechanism for whatever levels desired. Many managers can be attached to the same log. -Level Policies are classes supplied to level log managers indicating what the different allowable levels are. The documentation is still in very rough shape but the code in its current state is available for simple download from www.eng.buffalo.edu/~johneddy. It is not well Boost-ified yet but the directory structure is in place and some example files are available. Everything is implemented in header files at this point so no library need be built. John

5 12

Constructor-proxy: Template parameter deduction, a question for template masters
by ION_G_M 19 Feb '05

19 Feb '05

Hello to all, while developing Boost Shmem, I wanted to create a constructor proxy to emulate c++ dynamic object allocation syntax when creating shared memory objects using a proxy object in the following way: T * ptr = shmem_segment.create<T>("ObjectName")[size] /*proxy returned here, calls operator() of the object*/ (arg1, arg2, ...argN); Shared memory is allocated and the object is constructed. I want the arguments to be deduced automatically in the proxy object function call to preserve this syntax. I also want to avoid _all_ parameter copying. I mean, if I can deduce that an argument can be passed by value or by referenced using this syntax, great. But, between copying _all_ arguments and passing a reference in _all_, I prefer the second. Trying to find a correct proxy for this, I had many problems when passing temporary arguments and hardcoded constants to the proxy. Right now I am using some ugly casts to avoid the copies, but this has some side-effects. I will explain the problem in the following code: #include <new> //Object to be constructed struct Ctor2Arg { Ctor2Arg(const int &const_ref, int &non_const_ref){} }; //"Clean" proxy template <class T> struct constructor_proxy_t { template<class T0, class T1> void operator()(T0 & t0, T1 & t1) const { char m_mem[sizeof(T)]; //Call constructor and destructor T *ptr = new(m_mem)T(t0, t1); ptr->~T(); } }; //Ugly cast proxy template <class T> struct ugly_constructor_proxy_t { template<class T0, class T1> void operator()(const T0 & t0, const T1 & t1) const { char m_mem[sizeof(T)]; //Convert all refs to non-const refs T0 & t0ref = const_cast<T0 &>(t0); T1 & t1ref = const_cast<T1 &>(t1); //Call constructor and destructor, non-const //refs can be converted to const refs T *ptr = new(m_mem)T(t0ref, t1ref); ptr->~T(); } }; //Main function int main() { //Construct normal and ugly proxies constructor_proxy_t<Ctor2Arg> proxy; ugly_constructor_proxy_t<Ctor2Arg> ugly_proxy; //One const int and one non-const int const int dummy_const = 0; int dummy_non_const = 0; //This is ok, calls: //constructor_proxy_t<Ctor2Arg>::operator() //<int const ,int>(const int & t0=0, int & t1=0) proxy(dummy_const, dummy_non_const); //Both of these calls do not compile in VC7.1 or gcc 3.4.3, //tries to call constructor_proxy_t<Ctor2Arg>::operator() //<int, int>(int & t0=5, int & t1=0) // // gcc 3.4.3 error // //error: no match for call to // `(constructor_proxy_t<Ctor2Arg>) (int, int&)' //candidates are: // void constructor_proxy_t<T>::operator()(T0&, T1&) // [with T0 = int, T1= int, T = Ctor2Arg] // //Obviously, compilers are right, but //it wouldn't be more logical to call //<int const, int> specialization since a //temporary is a constant object? // proxy(dummy_non_const+5, dummy_non_const); // proxy(dummy_const+5, dummy_non_const); //This is ok, calls: //ugly_constructor_proxy_t<Ctor2Arg>::operator() //<int,int>(const int & t0=0, const int & t1=0) ugly_proxy(dummy_const, dummy_non_const); //These are ok, call: //ugly_constructor_proxy_t<Ctor2Arg>::operator() //<int,int>(const int & t0=5, const int & t1=0) ugly_proxy(dummy_non_const+5, dummy_non_const); ugly_proxy(dummy_const+5, dummy_non_const); //This compiles but it should not, since //I am passing a const object as second parameter //so Ctor2Arg obj(dummy_const, dummy_const) //does not compile. This calls: //ugly_constructor_proxy_t<Ctor2Arg>::operator() //<int,int>(const int & t0=0, const int & t1=0) ugly_proxy(dummy_const, dummy_const); return 0; } My question is, has anyone a better way to write the proxy object without ugly casts, no side-effects (I mean, the proxy call should compile only if the constructor compiles), preserving a clean calling syntax, and _no_ object copies at all? And the second question is: when a temporary is passed to a template, why non-const argument is deduced in the function call? Thank you, regards, /Ion

3 2

singleton report (lifetimes)
by Jason Hise 19 Feb '05

19 Feb '05

Just thought I would release a progress report on the singleton. I have added a new lifetime policy called static_lifetime, which derives from the longevity lifetime and just hides the longevity part from client code, setting it to zero. The result: singletons using the static_lifetime policy are guaranteed to be destroyed in reverse order of creation, if they are created. I am thinking that this should be the default lifetime for the singleton, however I am open to suggestions. Here is a brief summary of each lifetime in the library. If there are any ideas for other lifetimes I would love to hear them. dependency_lifetime - Uses pointers to the singleton as reference counted dependencies. The singleton, if created, is destroyed upon the destruction of the last pointer. A static or global pointer must exist to ensure that the singleton doesn't get destroyed and recreated as the program executes. Singletons can own dependencies to other singletons to ensure proper order of creation and destruction. If a circular reference exists, the singletons owning pointers to each other will never be destroyed. This was my former choice for the default policy. longevity_lifetime - Upon first creation of a singleton using this policy, the singleton instance is registered with a hidden singleton, the longevity_registry. The longevity_registry has a static pointer to itself in its constructor, ensuring it lives at least until main exits. Upon destruction, it destroys the registered singletons in order. Singletons with lower longevities are destroyed first, and singletons with the same longevity are destroyed in reverse order of creation. static_lifetime - Deriving from the longevity_lifetime, this just hides the longevity template parameter and uses zero. As a result, singletons using this policy are destroyed in reverse order of creation, and are destroyed before any longevity based singletons using a longevity greater than one. As the longevity is an unsigned int, this means most of them. This is my current choice for a default. leaky_lifetime - This never destroys the singleton instance. Because of the extensive framework that it provides in terms of member functions and classes, all of the other lifetimes derive from it. This way the other lifetimes can add the specialized destruction behavior without duplicating all the little details, like creation behavior and member functions of the pointer class. The leaky lifetime is used internally by a hidden singleton used in the multiton implementation. This singleton stores multiton instance holders in a map (ideally this should be an assoc_vector if one is ever added to boost). It can never be destroyed because the singletons it stores instance holders to could potentially be destroyed later, or even be recreated by other singletons in the process of being destroyed. Fortunately the map only needs to be destroyed if it needs to free the memory, and this memory which will be automatically cleaned up by the OS anyway. I would like to point out that the method of creation is the same regardless of the lifetime used. An enumerated trait of each lifetime controls when automatic creation can occur. This can be set to create the singleton upon creation of a pointer, upon dereferencing a pointer, both, or neither. If this is set to not automatically create the singleton at all, client code can explicitly call a create member function from any singleton pointer. The leaky_lifetime implements all of these details so that the other lifetimes which derive from it do not have to worry about it. Phoenix re-creation ability works automatically for all of these. To achieve a non-phoenix lifetime, a one_time_creator can be specified which uses a real creator the first time, and a creator designed to fail the second time. Numerous failure creators are provided: null_creator - create simply returns null throw_creator - create throws an exception (which can optionally be specified) assert_creator - causes a boost assertion to fail, and then uses some other failure creator (defaults to throw_creator) if execution gets past the assertion The real creators provided include: create_using_new - client code can customize with a boolean trait whether to make it use no throw new create_using_malloc - client code can make this throw or no throw as well create_statically - uses a static aligned_storage buffer to hold the instance, cannot be used with a multiton create_using_std_allocator - allocates memory with a standard allocator (which can be customized) The one_time_creator can be chained to use a different creator for the first, second, and third creations, ad infinitum. It makes sure to destroy each instance with the internal creator used to create it. I am diligently working on the html documentation, which is going to be quite extensive. It seems like the more documentation I write, the more ideas I get for improving the library. When I get the documentation into a coherent state I will upload it. However, I have made so many changes now that I think an outside perspective would be a good thing before I start setting class and function names in stone. Thus, an up to date stable version has been uploaded to the sandbox. What would be really helpful is if someone could try to write a test program in a multi threaded context. My background in threading is very shaky, and I want to be sure that I am using the locking policy the right way. Is anyone willing to give this a try? -Jason

1 0

[Reminder] Mailing list and lists.boost.org outage Saturday
by Douglas Gregor 19 Feb '05

19 Feb '05

This is a reminder that the Boost mailing lists and lists.boost.org will go down at 12:00pm Saturday Eastern Standard Time. We expect that all will be running again by 8pm at the absolute latest. Doug

1 0

assert
by Jason Hise 19 Feb '05

19 Feb '05

My version of assert.hpp has the line: #include <assert.h> Shouldn't this be: #include <cassert> ? -Jason

6 6

[bug]: optional<T> fails on self-assignment
by Joe Gottman 18 Feb '05

18 Feb '05

I just discovered that optional<T> is not safe under self-assignment. Consider the following code fragment: boost::optional<long> x(1); //At this point x is initialized and *x == 1 x = x; //x should be unchanged, but instead x is now uninitialized Optional's assignment operator looks like optional& operator= ( optional const& rhs ) { this->assign( rhs ) ; return *this ; } and assign is defined by void assign ( argument_type val ) { destroy(); construct(val); } Thus, if (this == &rhs) in operator=(), any value held by rhs will be destroyed. I can see two possible fixes for this. the first is to put an "if (this != &rhs) " around the call to assign in operator=(). This is simplest, but it slows the code down in order to protect against a very rare situation. The other is to rewrite assign as follows: void assign(argument_type val) { if (m_initialized) { get() = val; // call assignment operator } else { construct(val); //call copy constructor } return *this; } This makes optional self-assignment safe. It has the added advantage that is T's assignment operator has the strong exception safety guarantee, so does optional<T>'s assignment operator. It has the disadvantage of making optional depend on both assignment operator and copy constructor to copy, but very few classes have a copy constructor but don't have an assignment operator. Joe Gottman

7 31

New profiling library update
by christopher diggins 18 Feb '05

18 Feb '05

I have updated the profiling library and written a few tests. I still need to rewrite the documentation. the latest version is at http://www.ootl.org/profiler/toc.htm . Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0