- Boost-users - lists.boost.org

[flyweight] Review period extended to February 3
by Ion Gaztañaga 29 Jan '08

29 Jan '08

Hi to all, We've received 4 positive reviews and several comments, but we still want more ;-) Some people expressed interested in the pre-review period and I want to give some time (weekend is the right time to review a Boost library...) to those who are interested in the library and have not found time to review it. The last review day is February 3. Common, the library is very lightweight ;-) to review, it's pretty well documented, it's certainly small and very general purpose. Here is the information. Last call to passengers! *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Ion Gaztañaga - Review Manager -

1 0

[thread_safe_signals] multi_threaded.hpp uses same #ifdef as auto_threaded.hpp - no inclusion possible
by raimar wagner 29 Jan '08

29 Jan '08

Hi! yet another thread_safe_signals problem :-) : auto_threaded.hpp: > #ifndef BOOST_SIGNALS_MULTI_THREADED_MODEL_HEADER > #define BOOST_SIGNALS_MULTI_THREADED_MODEL_HEADER multi_threaded.hpp: > #ifndef BOOST_SIGNALS_MULTI_THREADED_MODEL_HEADER > #define BOOST_SIGNALS_MULTI_THREADED_MODEL_HEADER For using multi-thread support the documentations says: "Thus boost/signals/multi_threaded.hpp is not automatically included when you include boost/signal.hpp, and must be included separately if you wish to use multi_threaded." but this can't work because "auto_threaded.hpp" is included in "thread_safe_signal.hpp", thus every (later) include of "multi_threaded.hpp" does nothing. My workaround was just changing multi_threaded.hpp to > #ifndef BOOST_SIGNALS_MULTI_THREADED_MODEL_HEADER_MULTI > #define BOOST_SIGNALS_MULTI_THREADED_MODEL_HEADER_MULTI but this should also be changed in the downloadable archives. Kindest regards Raimar Wagner

2 1

[thread_safe_signals] Qt/MOC Linker problem with header-only thread_safe_signals-library
by raimar wagner 29 Jan '08

29 Jan '08

Hi! I'm using the "thread_safe_signals"-library in a Qt-Context. I have a file "foo.cpp" containing Qt-stuff which is processed by the moc before it compiles. foo.cpp: > #include "foo.h" > > ... Qt-stuff ... > foo.h: > #include "bar.h" > > ... Qt-declarations .. > bar.h: > #include <boost/thread_safe_signal.hpp> > #include <boost/thread_safe_signals/multi_threaded.hpp> > #include <boost/bind.hpp> > > ... > Now the following happens: 1.) The Qt moc creates moc_foo.cpp based on foo.cpp 2.) everything compiles fine ("g++ (GCC) 4.1.0 (SUSE Linux)" using SCons on SUSE 10.1) 3.) The linking process fails with: > build/release/src/foo.os: In function `boost::signalslib::null_deleter(void const*)': > /path_to_boost/include/boost/thread_safe_signals/connection.hpp:42: multiple definition of ` > boost::signalslib::null_deleter(void const*)' > build/release/src/bar.os:/path_to_boost/include/boost/thread_safe_signals/connection.hpp:42: first > defined here > build/release/src/foo_moc.os: In function `boost::signalslib::null_deleter(void const*)': > /path_to_boost/include/boost/thread_safe_signals/connection.hpp:42: multiple definition of > `boost::signalslib::null_deleter(void const*)' > build/release/src/bar.os:/path_to_boost/include/boost/thread_safe_signals/connection.hpp:42: first > defined here > collect2: ld returned 1 exit status Our workaround was to edit connection.hpp from: 42: > void null_deleter(const void*) {} to 42: > void null_deleter(const void*); and add to bar.cpp: > namespace boost > { > namespace signalslib > { > void null_deleter(const void*) {} > } > } This works, but maybe there is a better solution to cope with this problem. Any ideas? Kindest regards Raimar Wagner

2 1

Building 64-bit Boost Libraries on Windows
by Trueman, Christopher 29 Jan '08

29 Jan '08

I'm continuing to have trouble compiling 64-bit versions of the Boost libraries on Windows using VS2008. I've used a number of the tips posted online including: bjam --toolset=msvc-9.0 address-space=64 but watching the Task Manager I see that it always launches the 32-bit version of the compiler. Does someone have the correct BJAM command line to make this work? I'm using Boost 1.34.1 which I patched in a couple of places to have it recognize the 9.0 (internally version 15) VS 2008 toolset. Any help much appreciated. Thanks. Chris. _______________________________________________________ The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify the sender immediately, and then destroy it.

3 2

[Filesystem] Crashes with global const path
by Hughes, James 29 Jan '08

29 Jan '08

Hello all, We have had problems with boost::path when used as a const global variable, using gcc on ARM Linux. Example code (typed in the the email so probably missing code, but this is the basic premise) #include <boost/filesystem/path.hhp> const boost::path test = "/usr/bin/whatever"; main() { //something } This crashes prior to getting to main, obviously whilst the path is being set up during initialisation. Is this a known problem? Is there a way round it? Have we misunderstood something important? Path works fine elsewhere, its only when some sort of initialisation code is called that it goes pear shaped. James This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

2 2

Serialization of pointers to PODs
by Joseph Fradley 29 Jan '08

29 Jan '08

Is it possible using the boost serialization libraries to serialize pointers to PODs, such as integers? I have tested successfully with pointers to classes but have not been able to get pointers to non-polymorphic serialized. Is this a known issue? Joe

2 3

[review] Fast track review of Boost.Utility/Singleton - rejected for now
by John Torjo 29 Jan '08

29 Jan '08

Hi all, We've gotten a lot of feedback on the Boost.Utility/Singleton. It's clear that such an addition would be beneficial to Boost, but I've chosen to reject the library at this time. Summary: - 4 positive reviews - 4 negative reviews Phil Endecott - yes Nat Goodspeed - yes Dherring[@]ll[]mit[]edu - yes Ingolf Steinbach - yes Anthony Williams - no Gennady - no Pierre-Jules Tremblay - no Michael Marcin - no The main concern was that the library is not flexible enough, and that it imposes too many things on the users (like, if BOOST_HAS_THREADS is defined, the singleton is automatically thread-safe). I would like to see this into Boost, so I hope Tobias will update the library, given all this feedback, and I would suggest another review in 2-3 months. I'd like to be the review manager then as well, if Tobias will still want me. Suggestions: * Should use policies to specify creation/destruction, access to singleton, resurection For creation/destruction, one should be able to have singleton<single_thread<T> >, singleton< synchronized<T> >, singleton< thread_specific<T> > * example for DLL support * more detailed docs As for the next review of the library, I will talk to Tobias, and let the review wizard know. Thanks to Tobias, for the lib, and to all that participated to the review! Best, John - Review Manager - -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

2 3

MPL: Instantiating a template across permutations of types
by cp now 29 Jan '08

29 Jan '08

Hello. I am trying to instantiate a template taking two parameters across a series of types contained in mpl::vector's, and place the resulting types in an mpl::vector. template <class A, class B> class T {}; typedef mpl::vector<int, double, char> Atypes; typedef mpl::vector<double, std::string> Btypes; template <template <class, class> class TEMPLATE, class ATYPE, class BTYPES, class CLASSES> struct unary_fold_inner : mpl::fold< BTYPES, CLASSES, mpl::push_back<mpl::_1, TEMPLATE<ATYPE, mpl::_2> > > {}; template <template <class, class> class TEMPLATE, class ATYPES, class BTYPES> struct unary_fold : mpl::fold< ATYPES, mpl::vector<>, typename detail::unary_fold_inner<TEMPLATE, mpl::_2, BTYPES, mpl::_1>::type > {}; typedef unary_fold< T, Atypes, Btypes >::type CLASSES; I expect CLASSES will be an mpl::vector containing 2x3=6 types as follows: T<int, double> T<int, std::string> T<double, double> T<double, std::string> T<char, double> T<char, std::string> in other words, instantiating template T across all permutations of Atypes and Btypes. What I see instead is puzzling. Classes is indeed an mpl::vector, and indeed contains 6 types, but the types are simply: T<double, double> T<std::string, std::string> T<double, double> T<std::string, std::string> T<double, double> T<std::string, std::string> The iteration I'm trying to accomplish is all wrong. I think it has to do with how I'm creating my metafunctions. I'm still unclear about when the ::type suffix is needed (for the last parameter to mpl::fold<> for example) and whether I need an "apply" template somewhere in my struct's. Any help appreciated. v

2 2

boost::filesystem::rename - behavior/code vs. docs
by Andriy Gapon 29 Jan '08

29 Jan '08

[repost] This is what documentation on boost::filesystem::rename states: http://www.boost.org/libs/filesystem/doc/tr2_proposal.html template <class Path1, class Path2> void rename(const Path1& from_p, const Path2& to_p); Requires: Path1::external_string_type and Path2::external_string_type are the same type. Effects: Renames from_p to to_p, as if by POSIX rename(). Postconditions: !exists(from_p) && exists(to_p), and the contents and attributes of the file originally named from_p are otherwise unchanged. [Note: If from_p and to_p resolve to the same file, no action is taken. Otherwise, if to_p resolves to an existing file, it is removed. A symbolic link is itself renamed, rather than the file it resolves to being renamed. -- end note] Actual effect is that an exception is thrown when renaming a file to an existing file on the same fs. rename(2) performs an 'atomic' rename in this case without problems, but in the boost code there is a specila check against "too permissive" posix rename(): http://boost.cvs.sourceforge.net/boost/boost/libs/filesystem/src/operations… 1126 rename_api( const std::string & from, const std::string & to) 1127 { 1128 // POSIX is too permissive so must check 1129 fs::system_error_type dummy; 1130 if ( fs::exists( status_api( to, dummy ) ) ) 1131 return EEXIST; 1132 return std::rename( from.c_str(), to.c_str() ) != 0 1133 ? errno : 0; 1134 } And rename testing code also checks for the above behavior. I think that this is a huge difference between the docs and the code, and this is very counter-intuitive too. -- Andriy Gapon

1 0

[pre-processor ] help needed
by Ovanes Markarian 29 Jan '08

29 Jan '08

Hello *, I have some pre-processor sequence in form of: (X1) (X2) (X3) (X4) which is expanded by BOOST_PP_SEQ_FOR_EACH to template parameters: some_template<X1, X2, X3, X4> ... My problem now is that some of Xn parameters can be a template instantiation and that actually causes PP to think, that there are more parameters to the function applied by ..._SEQ_FOR_EACH. Example: some_other_template<T1, T2> cause preprocessor to think that there are 2 params some_other_template<T1 and T2>. Putting the parameter into additional braces like ((X4)) results in the template: some_template<X1, X2, X3, (X4)> and that results in a compiler error. I know this construct can switch off ADL, but I don't know why it result here in a compiler error, since I fully qualify the X4 (from which namespace it is). Is there any way to treat Xn as a single paramer but during the final pre-processing stage get rid of additional braces? Many thanks, Ovanes

2 4