- Boost - lists.boost.org

[thread] lockable traits and concepts classes adding proposal
by vicente.botet 14 Jul '08

14 Jul '08

Hello boosters , While writtig a generic library I have needed some lockable traits and concepts to be chacked with BCCL. If you think that these classes are of general use it will be a pleasure for me, if Anthony accepts, to included them on the Boost.Thread library. Otherwise I will left them in my Sync library. For the moment all is defined in a sync (as synchronization) namespace and directory but this is without importance. Attached a short introduction (in quickbook format- sorry I can not attach the html file) as well as the header files (which should with gcc 3.4 on cygwin) Of course all this is subject to discusion, naming and file structure changes, ... For each one of the mutex in the thread library, we need to * make the mutex inherit from the helper lock_traits_base or * have nested typedefs or * specialize each one of the traits templates As an external library I have do this in a non-intrusive way as for example: template<> struct timed_interface_tag<boost::mutex> { typedef hasnt_timed_interface_tag type; }; template<> struct reentrancy_tag<boost::mutex> { typedef non_recursive_tag type; }; template<> struct category_tag<boost::mutex> { typedef exclusive_lock_tag type; }; template<> struct scope_tag<boost::mutex> { typedef multi_threaded_tag type; }; But if included in the Thread library it will be better to use one of the intrusive methods. I have also defined other classes that could be of general interest. * A make_lockable class will make Lockable/ShareLocakble/UpgradeLocable the derived class depending on the Lock parameter. This class could be the base of a monitor class. It can be used as follows: class X : public make_lockable<boost::mutex> { } X x; unique_lock<X> lock(x); * a ..._synchronization_family set of classes that can be used as follows: template <class SyncFamily> message_queue; typedef message_queue<thread_synchonization_family> my_mt_message_queue; typedef message_queue<null_synchonization_family> my_st_message_queue; The null_synchonization_family needs a null_mutex and a null_condition classes. There is already something similar in Boost::Interprocess. * To finish, I'm working on a filter_matching_lockables meta-function which take as parameter a vector of lockables types and will filter the lockables types not satisfying a list of traits. The use shoul be somthing like typedef filter_matching_lockables<vector<boost::mutex, boost::recursive_mutex, ...>, mpl::and_<is_exclusive_lock<_>, mpl::not_<is_recursive_lock<_> > >::type candidates. and a find_best_lock which choose between the lockables given as parameter the best one following a given criteria. Of course, there is yet a lot of work to do, add lock concepts, lockable and lock concept traits, document, tests, document, tests ... between others. As you see there is nothing new, neither complex, only some helper classes making easier the construction of higher abstraction levels, and that currently are missing in boost. Have a good code reading and please let me know what do you think. _____________________ Vicente Juan Botet Escriba

3 6

Re: [boost] Newbie Trying to Build Boost Libraries on 64-bit MS WindowsVista
by Beverly Pope 14 Jul '08

14 Jul '08

>From what I've been reading, the -sTools option is an older way of doing things and I've had a lot of trouble building with 64-bit. I'll try using --address-model=64. I'll try ignoring the warnings, per your suggestion. I searched on the web and found that for Python 2.5, and found that: int ilow = 0, ihigh = INT_MAX; should be changed to: Py_ssize_t ilow = 0, ihigh = PY_SSIZE_T_MAX; It compiled after that change. I now have a problem with it finding a library, but I'll look at it some more before posting about that. Thanks very much for your help. Bev Date: Tue, 8 Jul 2008 13:56:57 -0500 From: "Stephen Nuchia" <snuchia(a)statsoft.com> Subject: Re: [boost] Newbie Trying to Build Boost Libraries on 64-bit MS WindowsVista To: <boost(a)lists.boost.org> Message-ID: <E763352EB1BA7547BBBC18A6980EBCB20171B05F(a)crm.tulsa.statsoft.com> Content-Type: text/plain; charset="iso-8859-1" > From: Beverly Pope [mailto:countryone77@yahoo.com] ??? I'm not familiar with the -sTools trick, I use --address-model=64 to get 64-bit builds. I've not built with Python so I can't address those errors in detail but I am familiar with the error message from other source codes. ? ? > 1) I see numerous (21360) warnings I have not investigated but I suspect it is impossible to suppress this warning in the header that is responsible for it without leaving it suppressed outside that header. I recommend ignoring it. > 2) When building the libraries, I get the following errors [...] > error C2664: '_PyEval_SliceIndex' : cannot convert parameter > 2 from 'int *' to 'Py_ssize_t *' >??????? Types pointed to are unrelated; conversion requires > reinterpret_cast, C-style cast or function-style cast [...] This error message is triggered by a code flaw that is at least potentially very dangerous. ... -swn

1 0

boost::iterator_range header surgery
by MaximYanchenko 14 Jul '08

14 Jul '08

Hello, I found that the input/output and comparison functions for iterator_range are inside the header boost/range/iterator_range.hpp. Actually, this causes problems, as I can't provide custom printing and custom comparison: I have my own container printing engine and it worked perfectly well with all standard containers, but failed to compile with iterator_range due to operator<< ambiguity. (Of course, I can just disable instantiation of my printing stuff for iterator_range, but this is definitely not what I want to have.) And, I have no such problems with, say, boost::tuple, as it has separate headers for printing and comparison: #include "boost/tuple/tuple_comparison.hpp" #include "boost/tuple/tuple_io.hpp" There are also other boost libraries that provide a separate "XXX_io.hpp" header. So my proposal is: 1. Move operator<< to a separate header "boost/range/iterator_range_io.hpp" 2. Move comparison operators to a separate header "boost/range/iterator_range_comparison.hpp" This will also serve for boost unification, which is the Right Thing that greatly simplifies usage of any library collection. However, two problems arise here: 1. Backward compatibility. Current programs expect that everything is automatically included. I see two solutions: - Include "boost/range/iterator_range_io.hpp" and "boost/range/iterator_range_comparison.hpp" into "boost/range/iterator_range.hpp" under a define like BOOST_RANGE_1_34_COMPATIBILITY_MODE. This will give the same layout as we have in Boost.Tuple, but I don't want to introduce extra macros if they can be easily avioded. - Make one extra header "boost/range/iterator_range_core.hpp", and have "boost/range/iterator_range.hpp" just including everything. This will the hierarchical layout similar to other libraries like Boost.Spirit. In this case, maybe it worth moving all three new headers to a subdirectory. 2. Again, backward compatibility, but from another point of view. Boost.Range has the unspecified_bool_type() conversion operator. I personally don't see a strong need in it, as it's just a negation of empty(). Also, no standard containers (which are ranges) offer this kind of conversion. So I don't expect wide use of it, and maybe it's worth removing it from the class at all and leave empty() only. Anyway, for now it's here, so if you move operator<< away, iterator_range will continue to be printed, but now, due to this conversion, it will be just "0" or "1", depending on the range emptiness. This is the problem not only for Boost.Range, but also for other types that offer this kind of conversion and separate printing, for example, consider this simple program with Boost.Optional: #include <boost/optional/optional.hpp> boost::optional<char> o('o'); #include <iostream> void without_io() { std::cout << "without_io: " << o << '\n'; } #include <boost/optional/optional_io.hpp> void with_io() { std::cout << "with_io: " << o << '\n'; } int main() { without_io(); with_io(); } So, whether we change Boost.Range header leayout or not, this unspecified_bool_type() problem should be solved anyway, for several boost classes. I discussed this with Alex Nasonov, and he proposed a patch for boost::optional: https://svn.boost.org/trac/boost/ticket/2103 But this is not the only use of unspecified_bool_type, so most probably we will need a common solution. Thanks, Maxim P.S. Please write personal e-mails to gmail.com.

4 4

[swap] unbreak tests
by Vladimir Prus 14 Jul '08

14 Jul '08

I've checked in the below. The libs/utility/swap/Jamfile.v2 has the same content present twice (complete with copyright notices). This is not good, because if you ask Boost.Build to built two targets with the same name, the same set of sources, and otherwise identical, Boost.Build asks "wazzup?". I suspect this duplicate content is a consequence of how the "patch" program handles file addition, but anyway, it's nice idea to actually run library's test before touching the library. - Volodya

2 1

Specifying symbols, that have to be exported from shared library
by Alexander Arhipenko 14 Jul '08

14 Jul '08

Hi guys! Without any doubt, any shared library should export as less symbols as possible. First, this will decrease loading time of dynamic shared object. Second, it could eliminate some binary compatibility issues in the future. Boost libraries that are built as shared libraries (e.g., filesystem, datetime) explicitly specify symbols that have to be exported, but only when BOOST_HAS_DECLSPEC defined. So, only when building with toolsets msvc and borland (correct me if I'm wrong), this 'export' functionality is used. As we know, gcc allows not to export any symbol from shared library (if compiler flag -fvisibility=hidden is used) except ones declared with __attribute__((visibility("default"))), e.g.: class __attribute__((visibility("default"))) exported_class {//... As for me, it will be nice to exploit explicit symbols export in boost (if compiler allows this). In our software team, we use following macroses: SFI_DSO_EXPORT, SFI_DSO_IMPORT that are defined as: #if defined SFI_CC_GNUC # define SFI_DSO_EXPORT __attribute__((visibility("default"))) # define SFI_DSO_HIDE __attribute__((visibility("hidden"))) # define SFI_DSO_IMPORT #endif #if defined SFI_CC_MSVC # define SFI_DSO_EXPORT __declspec(dllexport) # define SFI_DSO_HIDE # define SFI_DSO_IMPORT __declspec(dllimport) #endif //etc... And some library use only them: //config.hpp #if defined SFI_ALIB_BUILD_SHLIB # define SFI_ALIB_DECL SFI_DSO_EXPORT #elif defined SFI_ALIB_USE_SHLIB # define SFI_ALIB_DECL SFI_DSO_IMPORT #else # define SFI_ALIB_DECL #endif Finally, here's the question. What do you think about having something like BOOST_DSO_EXPORT/*IMPORT in boost? Regards

6 10

Where are the previous versions in the repository?
by Daryle Walker 13 Jul '08

13 Jul '08

When checking one of my tickets, I noticed that the <http:// svn.boost.org/trac/boost/browser/tags/Version_1_34_1/boost/boost/ typeof/int_encoding.hpp> link had gone bad. Looking at <http:// svn.boost.org/trac/boost/browser/tags>, I notice that _all_ of the tags for previous releases are gone. Why? (If they've been moved instead, let us know where they've gone.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[data_time, 1.36, fix-proposal] Compile-time error, gcc 4.3.1
by Ruediger Berlich 13 Jul '08

13 Jul '08

Hi there, when compiling my application with the current trunk version of Boost 1.36 (OpenSUSE 11, gcc 4.3.1, 64 bit), I get the following compiler error: /opt/boostinclude/boost/date_time/tz_db_base.hpp:161: error: declaration of ‘typedef class boost::date_time::dst_adjustment_offsets<typename time_zone_type::time_duration_type> boost::date_time::tz_db_base<time_zone_type, rule_type>::dst_adjustment_offsets’ /opt/boostinclude/boost/date_time/time_zone_base.hpp:76: error: changes meaning of ‘dst_adjustment_offsets’ from ‘class boost::date_time::dst_adjustment_offsets<typename time_zone_type::time_duration_type>’ This can be easily amended with a minimal change in boost/date_time/tz_db_base.hpp - see below for a change that works for me. As I cannot see that it can do any harm to other parts of Boost, I'm wondering whether it could still find its way into the upcoming Boost release. 161c161 < typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets_tdt; --- > typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets; 349c349 < dst_adjustment_offsets_tdt adjust(time_duration_type(0,0,0), --- > dst_adjustment_offsets adjust(time_duration_type(0,0,0), 356c356 < adjust = dst_adjustment_offsets_tdt( --- > adjust = dst_adjustment_offsets( Best, Ruediger

1 0

Autolinking when an autolinked function/class is never used
by Edward Diener 12 Jul '08

12 Jul '08

I think it is an error when an end-user uses a Boost library which may need a separate DLL built, never uses a function/class which is implemented in that separate DLL, and yet the Boost header files for that library bring in autolinking. Is this considered an error in the development of a Boost library ? What is invariably happening when this situation occurs is that a header file which has autolinking code ( #pragma comment(lib,"somelib") in VC++ for example ) is included for functions/classes which are not in the autolinked library at all. This is because the Boost developer has not placed all the autolinked functionality for a particular library in its own header file, preferring instead to place declarations in logically related header files. While the latter is understandable as far as organization of a library is concerned it destroys the ability of that library to enforce autolinking only when the end-user requires it. Despite the fact that library developers, of Boost libraries which are not completely header only, go for orthogonality when creating their header files I would like to see things changed so that using a library which does not require the built library to be linked in when using functionality of that library does not being in autolinking. I realize that there are macros of the BOOST_SOMELIB_NO_LIB around to turn off autolinking but this places a burden on the end user which should not be there. I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.

4 5

[preprocessor] #elif behaviour in gcc 4.4
by Daniel James 12 Jul '08

12 Jul '08

Hello, A recent change to the development version of the gcc preprocessor changes the way it processes '#elif' directives and breaks a common use of the preprocessor library. We've already had reports of this causing problems in MPL, and it might also affect: variant, function_types, python, fusion, xpressive and phoenix. Details of the change are at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320 With this change, the argument to an '#elif' directive is processed even if a previous '#if'/'#elif' directive was true. This causes the example use of BOOST_PP_ITERATION_DEPTH to break: http://www.boost.org/doc/libs/1_35_0/libs/preprocessor/doc/ref/iteration_de… In this example, the first time the header is included, BOOST_PP_ITERATION_DEPTH is not yet defined, so it causes the develoment gcc to fail when the #elif directives are evaluated (which are skipped with existing versions, because the first #if directive evaluates to true). Looking at the standard, I think their interpretation is correct (although I'm not familiar with it and could be missing something) but it isn't clear that this was the intent of the authors. Any opinions on this? I think it's quite easy to work around, we can replace: #if !BOOST_PP_IS_ITERATING // .... #elif BOOST_PP_ITERATION_DEPTH() == 1 // .... #elif BOOST_PP_ITERATION_DEPTH() == 2 // .... #endif with: #if !BOOST_PP_IS_ITERATING // .... #else # if BOOST_PP_ITERATION_DEPTH() == 1 // .... # elif BOOST_PP_ITERATION_DEPTH() == 2 // .... # endif #endif So that the calls to BOOST_PP_ITERATION_DEPTH are skipped - or we could just include the necessary header before including the file. But it does seem a pity that any code which uses this technique might need to be changed for gcc 4.4. We should probably write to them about this (it doesn't look like they realised this would be a problem), but I'm writing here first in case anyone has any ideas. Daniel

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by JOAQUIN M. LOPEZ MUÑOZ 12 Jul '08

12 Jul '08

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de JOAQUIN M. LOPEZ MUÑOZ [joaquin(a)tid.es] Enviado el: viernes, 11 de julio de 2008 17:35 Para: boost(a)lists.boost.org Asunto: Re: [boost] [pool] segfault (fun with static initialization ordering) _______________________________________ > The following is a case where the precende rule *cannot* be applied > for logical reasons: > > template<typename T> > struct foo{ > static int x; > }; > > template<typename T> > int foo<T>::x=T::x; > > struct bar > { > static int x; > }; > > int bar::x=666; > > static int x=foo<bar>::x; Please disregard this example, it is flawed because bar::x is statically initialized an because ultimately the compiler is not required to perform the dependency analysis suggested above. I've been playing with the following: #include <iostream> #if defined(CASE1) struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); #endif int main() { std::cout<<"bar::x: "<<bar::x<<std::endl; std::cout<<"foo<bar>::x: "<<foo<bar>::x<<std::endl; } Using GCC in Cygwin the output is the same for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 Using MSVC++ 8.0 I observed a light-shedding behavior: When compiling with a fresh project, the output is the same for CASE1 and CASE2 and coincides with GCC: bar::x: 666 foo<bar>::x: 666 But after that I changed the code to the following: #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int x=foo<bar>::x; // NEW LINE static int f(){return 666;} int bar::x=f(); #endif This forces foo<bar>::x evaluation to be done at a prior monent and the result is (for CASE2): bar::x: 666 foo<bar>::x: 0 Now, the funny thing is that if I revert to the original code (i.e. I delete the line comented as // NEW LINE) then MSVC++ 8.0 outputs the following both for CASE1 and CASE2 bar::x: 666 foo<bar>::x: 0 which is different than my early runs! The compiler seems to reuse some intermediate files from prior compilations that set a particular initialization order: confirming this hypothesis, if I clean the project and rebuild again then we're back at the original output for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 So, you see how one cannot actually rely on any particular initialization order for class template statis data. The standard explicitly leaves this initialization order unspecified (see the rest of 3.6.2). With respect to the rest of my previous post I maintain the explanation for the problem with pool you're having and contend that referring to singleton_pool<...> inside fast_pool_allocators ctors is the proper fix. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0