- Boost - lists.boost.org

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

Suggestion: keep the trunk stable
by Daryle Walker 12 Jul '08

12 Jul '08

Based on reading the various posts on releasing Boost 1.36.... Maybe we should promote the idea that the trunk of our Subversion repository should be as stable as possible as an official policy. I think a lot of open source projects do this; because it brings a big benefit: fast turn-around times for releases. With a stable trunk, the release manager makes a branch for release from the trunk, has everyone help in testing and making sure the branch is otherwise fully stable, then ship out the final version of that branch. After that, the changes on that branch have to be merged into the trunk to make it more stable. (And the branch can be removed.) Realize that the release branch preparation is _only_ for stabilization (i.e. bugs); anyone who was late for adding a new OR revised feature has to wait for the next release cycle. I think we're trying to do releases every three months, here's a possible timeline: 1. For the first two months, we're just updating the trunk with bug- fixes, revised features, and new features/libraries. Bug-fix releases come out during this time as needed. Any fix has to be based on a commit on the trunk. The bug release manager just makes a branch off the last bug release tag (or the last major release tag if we're doing the first bug release) and applies the selected bug fix change-sets, then ships after the group's testing. (The branch is re- merged then removed.) The release team would (generally) do the bug- fix incorporation; the libraries' developers did their parts by adding the fixes in the trunk in distinct change-sets. Hopefully, this would take a week for branching and fix-merging, then another week or so for testing. 2. Work on the trunk has to be kept stable. Incorporate changes into the trunk in distinct steps that do not break the build. Huge changes, like ones that could cause merge & conflict hell, especially if done during release time, should be kept on a branch until ready to be incorporated. Branchers should keep their branch current with the trunk as far as unrelated files (and pieces of related files) are concerned. (Alternatively, if a big change can be broken into steps that individually don't break the build, then that should work too.) Note when a distinct step is committed, it's not just code; the corresponding documentation and tests for that step need to go in too. 3. For the last month, work on the next major release begins. If we follow the always-stable-trunk ideal, then this will be like case [1]. We pick a deadline. On the deadline day, the release manager branches off the trunk on the most stable revision around that time. There's a week-long period where incomplete big changes either need to be finished to an acceptable cut-off (which may be 100% if it was nearly done) or get back-tracked to a previous acceptable cut-off. The release team and the library developer discuss which focused revision the cut-off will be cherry-picked from (either backward or forward). The remainder of the procedure happens like [1], probably even to the point of the short completion times (1 to 2 weeks). 4. The branches here are transitory. They should be created as needed and removed when they're not necessary. The major release branch would be called "release" and the bug fix branch called "bug- release". They may be around simultaneously. There should be a special branch called "hotness" (or whatever) that is an alias to the "trunk" most of the time, but to "release" or "bug-release" when those branches exist. (If both exist, "bug-release" takes priority; but bug releases have to be quick so the release isn't bogged down.) Our test crew can just park on "hotness" and make sure to update and test regularly, preferably on automatic. The branch points will be tagged ("1_37_origin", "1_37_0", "1_37_1", "1_38_origin", etc.) so we don't forget them, of course. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1