- Boost - lists.boost.org

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 20 Mar '05

20 Mar '05

In-Reply-To: <d19tal$32u$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > We can't tell if it was correct, because you didn't specify the > equality function for the type. Err, I wasn't asking you whether it was correct. I'm not asking for assistance with that old code; I found and fixed the problems long ago. I mentioned this stuff only because it is part of my background and experience, which the formal review guidelines say should be included in the review. > But the point is, if the types are right, then Peter's > proposal is ideal in this situation. As I said, the main problem was that my primitive hash_values often produced zero, and my combine function combined zeroes into zeroes. Combining a bool doesn't help when the bool itself hashes to zero. Another problem is that in some places I was using a version of hash_combine that wasn't order-dependant. The original boost proposal was better in that respect. Even fixing those issues, you really only get one additional bit of entropy by including the bool. You get slightly more entropy if you include the types as well. Sometimes every little helps. Especially if the hash_combine function isn't of cryptographic strength. > And it wasn't actually correct (with the current interface) It wasn't using the current interface - it wasn't using boost at all. The actual function wasn't even called hash_value. I translated my functions into the proposed terminology rather than explain my terminology. -- Dave Harris, Nottingham, UK

2 1

[shmem] New version uploaded to boost vault
by Ion Gaztañaga 20 Mar '05

20 Mar '05

Hi to all, I've just uploaded a new version of Shmem. Changes and new features: New feature: -> Apart from shared memory, all Shmem classes (containers, allocators, utilities) can be used to allocate all resources in a user defined fixed size buffer. This way, all resources will be allocated in a single buffer that could be easily serialized (Thanks to Martin Adrian for the idea). Changes: -> Bug fixes in code, comments and documentation -> Passed all tests in linux (suse 9.2-gcc 3.4.1) (except for shared_read_write_mutex that fails) -> Changed allocator swapping to the recommended solution in the paper "Issue 431: Swapping containers with unequal allocators" -> Some corrections for exception-safe constructors in containers (not that I think they are perfect but much better than before). -> Some EBO optimization in templatized mutexes when using null_mutex. Thanks to Pavel for his comments and advices. Regards, /Ion

1 0

MPL TODO list goes public
by Aleksey Gurtovoy 20 Mar '05

20 Mar '05

For everyone's benefit, the MPL TODO list is now publicly accessible at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?MPL_TODO_List. If you recently (or not so recently) reported a problem with a library, requested a feature, or otherwise commented on something that you think ought to be on this list and it's not, please let me know, and I'll put it in. Of course any other comments/suggestions are welcome, too. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [boost] shared_ptr doubts
by Don G 20 Mar '05

20 Mar '05

It is likely that we will simply just disagree on this, but I will at make a stab at responding to your points. > For some specific smart pointer applications, it is possible to > design a smart pointer that is more optimal than shared_ptr. > That's what a policy-based smart pointer is all about, and > hopefully we will soon have one in Boost. In the meantime, look > at the Loki policy-based smart pointer. I'm familiar with Alexandresu's book (even if I can't always remember how to spell his name<g>), but... > But sometimes a single general-purpose smart pointer is needed. Yes! Although I am focused purely on reference counting smart pointers. But... > For example, as a standard type to communicate between libraries, > including third-party libraries. Or to recommend generally to a > wide-range of programmers, including those who might be confused > by a plethora of choices. Exactly. > Or in cases where various efficiency concerns are nowhere near as > important as using a well-known, well-understood, and soon > standardized smart pointer. Why can't we have both? I would suggest that a major reason STL is so popular is that it paid careful attention to efficiency from its inception. If std::vector had allocated several or nearly a dozen extra machine words per object as shared_ptr does at times, I believe things would have turned out differently. The std containers offer what is needed to accomplish a well focused task, allocating only the data necessary for that job and no more. For example std::list need only allocate 2 pointers per object. If Stepanov had gone on to add feature after feature that made this number on par with shared_ptr, again, it likely would not have been well received. > The Colvin-Dimov shared_ptr design solves a far-broader range of > smart pointer problems than any other proposed design. That's > why it is the most commonly recommenced C++ smart pointer type > in the world. That's why the C++ committee is standardizing it. Please don't take my doubts the wrong way; I am not trying to "dis" their fine work. If folks want to use it, that's fine. They should be warned, but caveat emptor. I am focused on the last statement above. As it sits, shared_ptr simply goes too far and in so doing one must always ask "is shared_ptr suitable in this case?" As a library author, this is often an impossible question to answer, because it could depend on the use to which the library is put. In other words, by adding all the frills, shared_ptr actually reduces its scope of applicability. > It isn't intended to replace all other smart pointers. No single > smart pointer type can do that. So appreciate it for the many > problems it solves, rather than worrying about the problems > where another smart point would be more optimal. Where is the standard smart pointer to which you refer? I can keep writing my own (have been for many years, and kinda like it<g>), but what I would really love to see is a pair of simple ones provided by the standard library that accomplish just two jobs: delete it; and delete it when the count drops to 0 (with some means for the count to be internal to the object). If more smart pointers are added beyond that, that would be great. So far, both auto_ptr and soon shared_ptr fail at the K.I.S.S. test. They set out to solve these two "simple" problems and got lost along the way. A standard facility should not offer such surprises to unsuspecting users. With auto_ptr we got "surprise! you thought I was the owner, but it was that other guy that just left scope". With shared_ptr we will have "surprise! here's that bad_alloc you've always wanted". If the current design is the way it will be (probably), can't we at least have a warning label: "WARNING: shared_ptr may allocate 40+ bytes per object (fine print: depending on platform and multithread considerations, your mileage may vary, etc.)" Well, I'm no lawyer I guess... <g> > All IMO, of course! Likewise! Best, Don ===== __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

5 13

shared_ptr changes
by Peter Dimov 20 Mar '05

20 Mar '05

I've made some pretty extensive changes to the implementation of shared_ptr. It now uses a lock-free algorithm (originally invented by Alexander Terekhov) on Windows, and the old detail/shared_count.hpp has been refactored into a number of smaller headers. A per-count pthread_mutex is still being used on non-Windows platforms, but this is also going to change soon. Now is the time to test the new implementation; please report any errors you encounter. Some of you have posted patches against the old implementation; these will need to be reexamined, too. detail/lightweight_mutex will also change "soon"; it will just map into a CRITICAL_SECTION or a pthread_mutex depending on the platform. The spin locks will disappear. shared_ptr no longer uses lightweight_mutex. If you use some of the undocumented features of shared_ptr - BOOST_SP_USE_STD_ALLOCATOR, BOOST_SP_ENABLE_DEBUG_HOOKS, sp_collector.cpp - please say so. During the refactoring I may drop some of these features in order to simplify and streamline the implementation. Thanks, -- Peter Dimov http://www.pdimov.com

3 4

AnyUnit
by Alex Odinayev 19 Mar '05

19 Mar '05

AnyUnit C/C++ Edition add-in for Visual Studio 2003 .NET is available for download at http://www.anyunit.com. AnyUnit is a unit testing environment that allows developers to work with virtually any type of test frameworks, commercial and open source. It comes bundled with support for boost.test and CppUnit test layouts; please visit website for details. Thanks guys.

3 2

RE: [boost] thread safety in boost date time
by Yitzhak Sapir 19 Mar '05

19 Mar '05

Regarding the thread safety issue relating to getenv() in boost date_time, we have now identified the problem and it appears to be a call to putenv() elsewhere in log4cxx. putenv() is usually not bad, but here there is a call to putenv() with a string created on the stack. When the thread ends, the stack gets destroyed and further calls to getenv() cause an access violation. So the bug was not thread safety, but simply an ugly bug in log4cxx. However, the fact remains that the date_time library uses non-thread safe functions in a way that cannot be controlled by the user. boost date_time may not be the only one calling these functions, and so "wrap it in a mutex on your side" requires the user to know which calls to wrap in a mutex, and be sure that all third parties, not just boost but also log4cxx etc., using "localtime" are wrapped in the same mutex. And this assumes that all that is necessary to solve the thread safety in some implementation of "localtime" is to call "localtime" serially and never concurrently. This is operating system dependent and one of the reasons to use boost is to eliminate os-dependent code. log4cxx has fixed this already in its cvs due to a rewrite of the framework. When I mentioned it should be in a central place, this is because there are various libraries, such as spirit, that require (or required -- we're using 1.30.2) BOOST_SPIRIT_THREAD_SAFE to be defined, and so it would be nice if all "what you need to do to work in multi- threaded environments" was all in one central place, rather than forcing the user to collect bits of information on this issue from each of the various libraries. Yitzhak Sapir

5 9

Re: [boost] [review] hash functions
by brangdon＠cix.compulink.co.uk 19 Mar '05

19 Mar '05

In-Reply-To: <003a01c52a54$a90c6b30$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > > I do appreciate the benefits of stability. What isn't clear is > > whether it trumps hash quality. This is a judgement call, in that it > > partly depends on which issue is more important to you. > > Both issues are important to me. They conflict. There is a tradeoff between them. So we have to choose which is more important. I was concerned partly that the wrong choice might be made, but mostly because the tradeoff wasn't even being acknowledged. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 19 Mar '05

19 Mar '05

In-Reply-To: <004501c52a55$cf114750$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > Had you written your hash function following the guideline that every > member that is part of the state and affects the equivalence relation > needs to be hash_combined when computing the hash value, you'd not have > had collisions. That's good advice, but wouldn't have helped much with my code for other reasons, which I've explained in a parallel post. Remember I was not using the proposed boost functions. > In other words, making hash_value take into account the type of the > member is not necessary for writing good quality hash functions. It > will only "fix" some (questionably written) functions, but not all. I agree it's not necessary in that the same result can be achieved in a different way. And that's a powerful argument :-) Still, throwing away the type information will reduce the available entropy when the types are different. That it won't when the types are the same is no reason not to take advantage of that variation when it is available. -- Dave Harris, Nottingham, UK

1 0

[foreach] Multiple definition error when linking two foreach-using units
by Eelis van der Weegen 19 Mar '05

19 Mar '05

I've attached two (tiny) files: a.cpp and b.cpp . They compile fine, but attempting to link them causes the following error: b.o(.text+0x0):b.cpp: multiple definition of `boost::foreach_detail_::cheap_copy(...)' a.o(.text+0x0):a.cpp: first defined here I'm using gcc 3.4.2 with boost 1.32 and foreach.hpp revision 1.29 from the sandbox. Making the non-template cheap_copy() in foreach.hpp at line 322 inline solves the problem. Regards, Eelis #include <boost/foreach.hpp> int main () {} #include <boost/foreach.hpp>

2 1