- Boost - lists.boost.org

[interprocess][flat_map/flat_set] provide read access to underlying container
by Thorsten Ottosen 29 Apr '08

29 Apr '08

Hi Ion, Sometimes I need to go through all elements in such a container. However, it is know that the number of elements is low, so I unroll the loop manually. In that case I would like to be able to do the following: const T& t1 = flat_set[0u]; const T& t2 = flat_set[1u]; Alternatively, provide a base() function that directly give read access to the underlying container: const T& t1 = flat_set.base()[0u]; Comments? -Thorsten

2 2

Need feature branch for compile in-place static linking
by Ulrich Eckhardt 29 Apr '08

29 Apr '08

Hi! I have in the past sometimes[1] described another alternative way to linking and quite a few people also seemed interested. Basically, it works by including the whole library code into the application that links to it. However, as opposed to a header-only library, the code is only included once in a translation unit of the linking program instead of inline via the header files. Example: --------- // lib.hpp: void foo(); // lib.cpp: void foo() { frobnicate(bar); } // program1.cpp: #include <lib.hpp> // program2.cpp: #include <lib.hpp> // program_main.cpp: #include <lib.hpp> #include <lib.cpp> int main() { foo(); } As you see, lib.cpp is included into exactly one translation unit of the final executable (it's up to the user to make sure that it's exactly done once). Why bother? ------------ The very simple reason is simplicity. * Even on a system where I don't have admin access, I can easily download and compile against Boost, without having to first compile shared/static libs or having to modify paths in order for the runtime linker to find DLLs. * Even if I had admin access, I would still be reluctant to installing Boost's trunk. * When I'm testing different compiler settings trying to get another few percent of performance, I don't have to compile another Boost version for each compiler setting. * I don't have to know which library to link to, which lowers entry barriers for new Boost users. * I can easily compile and distribute programs without having to worry about required shared libraries. * I have a guarantee that the library's ABI actually conforms to the ABI that my program expects, simply because I compiled it with the exact same compiler settings. Drawbacks: ----------- The main drawback is that you can't guarantee that library implementation code is compiled with e.g. NOMINMAX defined. If an incompatible environment is detected, I would simply use #error to alert the user. Further, 'private' symbols (static functions or functions in anonymous namespaces) can't be reused by different sourcefiles because they are all compiled into the same translation units. If this happens, I would simply try to rename things until the clash is resolved or maybe move them to a separate namespace. Tasks to completion: --------------------- * Add one central file compile_inplace.cpp for each library. This would mean that for Boost.Thread we then include "boost/thread/compile_inplace.cpp" from exactly one translation unit in order to get it to work. * Fix some code that doesn't lend itself to inclusion in user code. One particular example is in Boost.Thread, where two sourcefiles include another file that contains utility functions in an anonymous namespace. If both sourcefiles are compiled by the same TU, the anonymous namespace is also compiled twice leading to multiple definitions. Just adding an include guard helps. * Prepare import/export code. This is mainly a win32 task which means programming the macros that control __declspec(dllexport) or __declspec(dllimport). Basically this means switching to static linking (where neither of the above are generated) but also turning off autolinking (because there is no according library that the linker should link to). * Add error checking. In particular, you must not e.g. include compile_inplace.cpp if you are doing other kinds linking. * Documentation updates. This mostly means adding this way of linking to the pages that describe which library to link against as an alternative way. I would even use this form in examples for the various libs exactly because it is the easiest way to link against a library. What do I need: ---------------- What I need is a folder on SVN for the branch and according write permissions so I can actually work on it. Of course, I could also create a repository somewhere and just branch Boost there, but this has the disadvantage that it makes it harder to merge the changes back (SVN isn't particularly good on inter-repository merges) and also it would make it easier for people to test the branch (you could 'svn switch' to it and it would only transfer the changes). Lastly, I do need access from two locations, one at work where I could test win32 versions and one at home where I have a Linux/PPC for testing. thanks Uli [1] http://lists.boost.org/Archives/boost/2006/03/102525.php http://lists.boost.org/Archives/boost/2007/04/119622.php

3 2

[log] Problem with Unicode and linker error
by Boris 29 Apr '08

29 Apr '08

I downloaded Boost.Log from http://www.torjo.com/code/log2.zip to give it a try but ran into two problems immediately (with VC++ 9.0 on Windows XP): * In the (old?) documentation at http://www.torjo.com/log2/doc/html/miscelaneous.html#misc_unicode a macro called BOOST_LOG_DONOT_USE_WCHAR_T is mentioned which can be defined on Windows to use char-based classes instead of wchar_t-based classes. This macro doesn't seem to work though. I couldn't find any other macro I might be able to define to use char-based classes if UNICODE is defined? * The linker is trying to find a library called boost_log-vc90-mt-gd-1_34_1.lib while the filename is really libboost_log-vc90-mt-gd-1_34_1.lib. I renamed the file but got then a linker error (unresolved external symbol "... boost::logging::find_log_by_name(...)"). My code consists only of BOOST_DECLARE_LOG and BOOST_DEFINE_LOG though (thus I would expect I can't make much wrong here :)? Anyone can help? Or is the zip archive I downloaded actually the latest code? Boris

2 6

[math] use of long long causes errors on gcc.
by Steven Watanabe 29 Apr '08

29 Apr '08

AMDG gcc.compile.c++ bin\quaternion.test\gcc-4.3.0\debug\quaternion.o In file included from c:\Documents and Settings\Steven\My Documents\boost/boost/math/tools/config.hpp:24, from c:\Documents and Settings\Steven\My Documents\boost/boost/math/special_functions/sinc.hpp:18, from c:\Documents and Settings\Steven\My Documents\boost/boost/math/quaternion.hpp:28, from quaternion.cpp:47: c:\Documents and Settings\Steven\My Documents\boost/boost/math/special_functions/detail/round_fwd.hpp:36: error: ISO C++ 1998 does not support 'long long' c:\Documents and Settings\Steven\My Documents\boost/boost/math/special_functions/detail/round_fwd.hpp:38: error: ISO C++ 1998 does not support 'long long' c:\Documents and Settings\Steven\My Documents\boost/boost/math/special_functions/detail/round_fwd.hpp:54: error: ISO C++ 1998 does not support 'long long' c:\Documents and Settings\Steven\My Documents\boost/boost/math/special_functions/detail/round_fwd.hpp:56: error: ISO C++ 1998 does not support 'long long' c:\Documents and Settings\Steven\My Documents\boost/boost/math/special_functions/detail/round_fwd.hpp:72: error: ISO C++ 1998 does not support 'long long' c:\Documents and Settings\Steven\My Documents\boost/boost/math/special_functions/detail/round_fwd.hpp:74: error: ISO C++ 1998 does not support 'long long' "g++-4.3.0" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB -I"..\..\.." -I"c:\Documents and Settings\Steven\My Documents\boost" -c -o "bin\quaternion.test\gcc-4.3.0\debug\quaternion.o" "quaternion.cpp" In Christ, Steven Watanabe

3 6

[exception] enable_exception_cloning.hpp should include <new>
by Boris Gubenko 29 Apr '08

29 Apr '08

boost/exception/enable_exception_cloning.hpp uses std::bad_alloc without #include'ing <new>. Because of this, some exception library tests fail to compile on HP-UX. Thanks, Boris

3 2

[mpl] mpl::iterator_range transform problem
by Slavomir Kaslev 29 Apr '08

29 Apr '08

Can someone explain why this simple snippet fails to compile? Am I doing something wrong or is this iterator_range problem? I've tested it on msvc 2005 and g++ 4.2.3 against boost trunk. #include <boost/static_assert.hpp> #include <boost/mpl/int.hpp> #include <boost/mpl/equal.hpp> #include <boost/mpl/vector_c.hpp> #include <boost/mpl/transform.hpp> #include <boost/mpl/iterator_range.hpp> int main() { using namespace boost::mpl; using namespace boost::mpl::placeholders; typedef vector_c<int, 1, 2, 3, 4> test_t; typedef begin<test_t>::type first; typedef advance<first, int_<2> >::type last; typedef iterator_range<first, last>::type range; BOOST_STATIC_ASSERT(( equal<range, vector_c<int, 1, 2> >::value )); typedef transform<range, identity<_> >::type transformed_range; } Thank you in advance. -- Slavomir Kaslev

2 1

But it would Re: [gil] [announcement] New IO lib
by Tom Brinkman 29 Apr '08

29 Apr '08

>> But it would introduce the dependency to boost::filesystem That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only.

5 5

[shared_ptr] aliasing constructor mischief
by Frank Mori Hess 29 Apr '08

29 Apr '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've noticed it is possible to construct a half-empty shared_ptr that has an empty shared_count but a non-null pointer (brief example program attached). Perhaps the aliasing constructor, and similarly the shared_count constructor should do some argument checking? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIFxx05vihyNWuA4URApYiAJwMZIi0qKWDubA60c9yWyP8S5An2QCeK+es LAW09je97rpq4qxqTRqVuks= =h5d6 -----END PGP SIGNATURE-----

3 3

[smart_ptr] questions about some regression test cases
by Daniel Frey 29 Apr '08

29 Apr '08

My questions result from the observation that in the virtual dtor of enable_shared_from_this, I tried BOOST_ASSERT( _shared_count.empty() ), but this makes 3 tests fail. Looking at these tests, I don't see why they should be legal: In esft_constructor_test.cpp, line 143, X initializes early_px by calling shared_from_this, but X is never passed to a shared_ptr which then owns it. From what I understand, this should be illegal. The next problem is esft_constructor_test.cpp, line 160. y.shared_from_this() returns a shared_ptr, but again, no shared_ptr takes ownership of Y later. While shared_from_this() is not called from the ctor, I wonder if this is yet another use case or just an accident. The test case in shared_from_this_test.cpp, line 135 is similar. Regards, Daniel

4 11

Re: [boost] [1.35.1] Plans for 1.35.1?
by brass goowy 29 Apr '08

29 Apr '08

JOAQUIN M. LOPEZ MUÑOZ writes: >Hello, > >Are there any plans to release a 1.35.1 version? I'm interested in this also. If there isn't going to be a 1.35.1, I'll start downloading and building 1.35.0 now. I figured there was going to be a 1.35.1 a few weeks ago, but haven't heard anything definite. Also on this page, http://www.boost.org/community/, it says: "If you are looking for more lievely interaction with the Boost community there are also some internet relay chat channels that users and developers like to hang out in." I suggest changing that to: If you are looking for more lively interaction with the Boost community, there are some internet relay chat channels where users and developers like to hang out. Brian Wood Ebenezer Enterprises www.webEbenezer.net

1 0