January 2005 - Boost - lists.boost.org

Re: Singleton
by Dave Handley 20 Jan '05

20 Jan '05

<snip on alignment> Jonathan Wakely wrote: > > memory is alignment with the type being allocated. Malloc and New are > > guaranteed to return memory that is aligned for an object of that size > > Guaranteed to be aligned for _any_ type, isn't it ? Any type that is not bigger than the memory size allocated. I'm pretty sure that the ANSI requirement for malloc and new does not require alignment to 8/16 byte blocks for memory allocations of a single byte (for example). This means that, to be pedantic, a 1 byte allocation is not guaranteed to be aligned for a double (for example). However, since this is a silly example, for all practical purposes you are correct. Also, some implementation may well guarantee alignment for small allocations. Nevertheless, my rather terse comment about being guaranteed to return memory aligned for an object of that size was probably a bit too terse, so thanks for the quotes and clarification. Dave

2 1

RE: [boost] Re: Published books on Boost
by Bjorn.Karlsson＠readsoft.com 20 Jan '05

20 Jan '05

> From: Jonathan Turkanis [mailto:technews@kangaroologic.com] > Dave wrote: > > Dear Boost Community, > > > > I am aware of the books on the graph and template metaprogramming > > libraries. Are any other books available, or in the works, on Boost > > libraries? > > Bjorn Karlsson has written a book on some of the core boost > libraries. I think > it is mostly done, but I'm not sure when it will be > available, or exactly what > it covers. > You're absolutely right that it's mostly done (finally!), and it will be available from July. The book (Beyond the C++ Standard Library -- An Introduction to Boost) covers these libraries: * Smart_ptr * Conversion * Utility * Operators * Regex * Any * Variant * Tuple * Bind * Lambda * Function * Signals Bjorn

2 1

[test] Why doesn't BOOST_REQUIRE_THROW exist?
by Andreas Huber 20 Jan '05

20 Jan '05

Hi there I have a test where it doesn't make any sense to continue if a certain function does not throw. BOOST_CHECK_THROW works but IMHO expresses the wrong thing. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 5

Re: Singleton
by Dave Handley 20 Jan '05

20 Jan '05

> Dave Handley wrote: > > > My recommendations for things to look at include: > > > > 1) Allocate using malloc as another creation policy > > I'm looking at Loki's library and thinking that it has a major bug. > Doesn't his implementation have the same alignment problems that my > original static allocator did? Wouldn't it be impossible to ensure that > memory allocated by malloc was aligned properly? > > -Jason Jason, Other posters have dealt with the fact that malloc and new don't have alignment issues, but haven't explained why. Clearly alignment issues exist when you have to have a particular variable (like an int) sitting on a word boundary. This is an architecture limitation - it usually depends on the bus size, since on a 32 bit bus, you would want to get an int in a single fetch operation. An issue happens when you don't know the type being allocated when you are actually doing the allocation. Static memory is allocated by the linker, and the standard does not guarantee any form of alignment, except that the memory is alignment with the type being allocated. Malloc and New are guaranteed to return memory that is aligned for an object of that size (according to the standard). You can also have similar alignment problems if you allocate memory on the stack. Vandervoorde and Josuttis argue in their templates book that the standard should be expanded to include an alignof operator that is similar to the sizeof operator, but returns the aligned requirement. Dave

2 1

Program_options workarounds?
by John Maddock 20 Jan '05

20 Jan '05

The following section of code in utf8_codecvt_factet.hpp seems to be rather mixed up: #if BOOST_WORKAROUND(__BORLANDC__,BOOST_TESTED_AT(0x551)) #ifndef _RWSTD_NO_NAMESPACE using std::codecvt; using std::min; #ifdef _RWSTD_NO_MBSTATE_T using std::mbstate_t; #endif #endif This section imports codecvt, min and mbstate_t into the *global namespace*, why? Isn't this a "bad thing" in general? I can't see why it would be necessary anyway. #elif defined(__COMO__) || defined(_MSC_VER) && _MSC_VER <= 1300 typedef ::mbstate_t mbstate_t; Surely this has no effect at best, or is illegal at worst? Remember we're in the global namespace here. Commenting this out has no effect on VC7 BTW (and VC6 doesn't build the lib anyway), can't comment on Commeau though. #elif defined(BOOST_NO_STDC_NAMESPACE) typedef std::mbstate_t mbstate_t; namespace std{ using ::codecvt; Again why import mbstate_t into the global namespace, especially as this does not happen for std conforming compilers? Finally importing codecvt into namespace std:: is almost always likely to be an error: BOOST_NO_STDC_NAMESPACE refers to C library code, I don't know of any std lib that has codecvt, but doesn't put it in namespace std already. In any case it doesn't build as is with gcc-2.95 (with or without STLport), but changing that to: #elif defined(BOOST_NO_STDC_NAMESPACE) namespace std{ using ::mbstate_t; } // namespace std and likewise changing the similar workaround convert.hpp to: #if BOOST_WORKAROUND(__ICL, <= 700) || defined(BOOST_NO_STDC_NAMESPACE) #include <wchar.h> namespace std { using ::mbstate_t; } #endif Gets it compiling with gcc-2.95 + STLport. Hope this helps, John.

3 2

Race condition in boost::spirit?
by stas garifulin 20 Jan '05

20 Jan '05

I'm using vc71 with multi-threaded runtime. Sometimes then boost::spirit code is accessed from different threads simultaneously i have access violation at boost/spirit/core/non_terminal/impl/grammar.ipp (255): # ifdef BOOST_SPIRIT_THREADSAFE static boost::thread_specific_ptr<ptr_t> tld_helper; // <-- Here if (!tld_helper.get()) tld_helper.reset(new ptr_t); ptr_t &helper = *tld_helper; # else According to callstack "tss_data" from threads/src/tss.cpp is dereferenced then it still is not initialized.

8 21

BUG: filesystem remove_all [PATCH]
by Walter Landry 20 Jan '05

20 Jan '05

Greetings, I have discovered a bug in the implementation of remove_all. remove_all works by reading through a directory and deleting entries along the way. If it comes across a subdirectory, it immediately recurses into that subdirectory. However, boost::filesystem uses readdir, which on some platforms (including OS X, apparently) uses a static data area that can be overwritten on each call to readdir. This messes up the original directory iteration, ending up with some entries not being deleted. A solution is to not recurse the directory immediately, but to make a list of them. Once you have gone through all of the entries in a directory, then you recurse into the subdirectories. A patch is below, although it could probably be improved. Cheers, Walter Landry wlandry(a)ucsd.edu --- /home/boo/arx/arx/src/boost/_arx/++cache/wlandry@ucsd.edu--arx/boost/1/32/,4/libs/filesystem/src/operations_posix_windows.cpp 2005-01-04 14:11:44.000000000 -0500 +++ /home/boo/arx/arx/src/boost/libs/filesystem/src/operations_posix_windows.cpp 2005-01-18 21:16:49.000000000 -0500 @@ -28,6 +28,7 @@ #include <boost/throw_exception.hpp> #include <boost/detail/workaround.hpp> #include <cstring> +#include <list> #ifdef BOOST_NO_STDC_NAMESPACE namespace std { using ::strcmp; using ::remove; using ::rename; } @@ -191,11 +192,23 @@ if ( !fs::symbolic_link_exists( ph ) // don't recurse symbolic links && fs::is_directory( ph ) ) { + std::list<fs::path> dir_list; for ( fs::directory_iterator itr( ph ); itr != end_itr; ++itr ) { - count += remove_all_aux( *itr ); + if(!fs::symbolic_link_exists( ph ) // don't recurse symbolic links + && fs::is_directory( ph ) ) + { + dir_list.push_back(*itr); + } + else + { + count += remove( *itr ); + } } + for(std::list<fs::path>::iterator i=dir_list.begin(); + i!=dir_list.end(); ++i) + count+=remove_all_aux(*i); } fs::remove( ph ); return count;

3 5

Hash table implementation in the Files section
by Joaquín Mª López Muñoz 20 Jan '05

20 Jan '05

(I tried to contact the author, but maybe the email address I have is no longer valid.) What is the status of the hash table code at the Files section wrt to the specification for unordered containers in TR1? I am most interested in using this code as a starter for adding hashed indices to Boost.MultiIndex. For reference, the mentioned file is called jtc1-sc22-wg21-2003-n1456.tar.gz Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

Re: Singleton
by Dave Handley 19 Jan '05

19 Jan '05

<Jason Hise wrote> > Yay, I finally got the singleton working with allocation and lifetime > policies, in addition to being in CRTP form. I know that threading > policies still remain, however I would like an opinion on what I have so > far. A major difference from Loki is that my lifetime policy needs to > know about the allocation policy in order for dependencies to be > possible to implement. The code is available here: Jason, Great work - I've been away from the list for a couple of days so sorry I didn't get back sooner, but I think you have definitely gone the right way with what you've done up to now. My recommendations for things to look at include: 1) Allocate using malloc as another creation policy 2) Longevity lifetimes 3) Possibly include the ability to turn off phoenix singletons in the dependency lifetime policy. 4) Threading. With all of those, you've almost certainly exceed Loki - especially if you can do them without have to link to any external code. Dave Handley

5 7

RE: [boost] [Gauge for interest] Minimal perfect hashfunctiongenerator
by Hurd, Matthew 19 Jan '05

19 Jan '05

> Behalf Of Hartmut Kaiser <snip> > I've tried to get my hands on the cited papers, but was able to find only > one of them. Could you provide a concrete pointer where to get the Tong > paper from? > The University of Auckland does not have the Uzgalis, Todd technical report "Hashing Myths" online. An overview presentation that is enough to get going is here: http://www.iticse2002.dk/conference/sessionmat/algorithms/1.pdf >From the first slide: The work presented here is almost entirely due to Robert Uzgalas ("Buz"), who single handedly reinvented hashing in the early 1990s. For reasons unknown, Robert never disseminated his work to the wide audience that it deserved. His paper, "Hashing Myths" remains unpublished, and his results are virtually unknown. Here is a snippet related by one of the authors, R. Uzgalis http://www.serve.net/buz/hash.adt/java.000.html Hope that helps, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1