- Boost - lists.boost.org

[mpl] RFE: accessing ith tail of [reverse_]fold
by Larry Evans 21 Jan '05

21 Jan '05

I just uploaded to boost vault: inherit_tail_type.zip which contains inherit_tail_type.hpp and a test. It allows easy access to ith tail in fold<types, empty_base, inherit2<_2,_1> >. It has specializations for the tail being on the left or right side of inherit2, and for using reverse_fold also. I'm proposing this as an enhancement to mpl.

1 1

Singleton
by Jason Hise 21 Jan '05

21 Jan '05

Regarding the static creation policy... would it be dangerous to use such a policy if there were static dependencies in use? I am worried that the static storage might be released before the said dependency and then when this last dependency dies it would try to destruct an object living in now inaccessible memory. Is this concern well founded? -Jason

2 2

Singleton
by Jason Hise 21 Jan '05

21 Jan '05

Alrighty, I think I've taken care of a large number of the concerns. I have locking, multiple allocator types, and even a fancy longevity lifetime policy. Everything is in the Singleton directory at "http://boost-sandbox.sourceforge.net/vault/". Please let me know what remains to be added, or if there is anything remaining that needs to be fixed. -Jason

1 0

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