- Boost - lists.preview.boost.org

version 0.2.1 of Mirror available
by Matus Chochlik 15 Jul '08

15 Jul '08

Hi there, a new version of the Mirror reflection library is available in both the vault and the sandbox. This version includes multiple important changes and many things were rewritten from scratch. Just to mention some of them: - nearly all of the registering and reflection macros have (hopefully ;) ) become more user friendly and some more universal. - more complex types like multi-dimensional arrays and functions/ pointers-to-function/references-to-functions are now supported by the typename returning functions base_name() and full_name(), which were also completely rewritten. And are now returning C++ strings. - registering of typedefined types - support for registering attributes with types derived from typedef-ined types some of the examples have been cleaned up (the rest are to follow). the examples were successfully compiled with msvc-9.0 EE on Vista g++ 4.2.1/4.3.0 on OpenSuSE 10.3 Linux g++ 4.2.1. on FreeBSD 7.0 Any comments are welcome Best regards, -- ________________ ::matus_chochlik

2 3

SOCI 3.0.0 - The Database Access Library
by Maciej Sobczak 15 Jul '08

15 Jul '08

Hi, After more than one year and a half from the last release I'm pleased to announce the availability of the next major SOCI release (3.0.0). The SOCI library is a C++ database access library that during the last years was recognized for its innovative interface, ease of use and high quality. The main project website is: http://soci.sourceforge.net/ The 3.0.0 release brings many improvements and new features. Some of them were suggested here during previous discussions on database interfaces. Some of them will be explained in more detail below. The most important of the new library features include: * Naming and coding convention compliant with Boost. * Integration with Boost types: optional, tuple, fusion and gregorian::date. Please see <http://soci.sourceforge.net/doc/boost.html> for details. * Dynamic backend loading. The advantages and potential uses of this feature have been discussed here previously. An example code establishing the new connection to the database might look like: soci::session sql("postgresql://dbname=my_database"); As a result, the SOCI library will try to locate the dynamically loadable plugin (called backend) for PostgreSQL and handle all further database-related activity. This feature exists not instead, but in addition to the statically-bound interface that was available in previous releases. * Multithreaded connection pool. * Improved integration and conversion system for user-defined datatypes. Actually, integration with Boost types has been implemented with the help of this conversion system. It is non-intrusive and based on traits, which means that neither SOCI nor user-defined types need to be modified to integrate them. This system is also composable, which means that user-defined datatypes can wrap one another without special arrangements. For example, boost::tuple can contain boost::optional<Employee> even though all three conversion traits can be defined separately. * Extended the set of basic datatypes with long long. * Additional simplified interface (of the extern "C" type) for integration with other programming languages. It is expected that bindings for other languages will be created as external projects with the potential advantage of reducing the total number of libraries used in multi-language projects and increasing conceptual coherency of database-related operations. Boost.Python and similar solutions can be helpful here. The 3.0.0 release includes the following backends: * Oracle * PostgreSQL * MySQL They were tested on a variety of platforms, please see the documentation pages devoted to each backend for details. Other backends (ODBC, SQLite, Firebird) exist in the CVS repository and are provided "as is" for those who are willing to experiment with them and accept the cost of using less-tested and unsupported code. It is very likely that future releases of the library will officially include some of these additional backends. It is also possible that other database servers will be targeted with dedicated backends. An extensive HTML documentation is available both on the project website and as part of the distribution. In particular, the doc/structure.html page explains the structure of the library and provides instructions how to build it. ------ This release is also a good motivation for reviving the discussion on the future Boost database library. As you have seen during the last couple of years, SOCI is one of the very few (should I say "the only one"?) projects that actually move forward and that are now culturally consistent with Boost. The extensive out-of-the-box integration with the Boost datatypes, Boost license and compliant naming conventions, already make SOCI the natural choice in those projects that use Boost libraries. As a natural consequence of this, the following question has to be asked: What is the future of database interfacing from the Boost community point of view? Proposing SOCI as a candidate library for Boost might be a possible answer to this question, but it is not obvious in a wider perspective. Some of the SOCI users do not use Boost for various reasons and this justifies retaining SOCI as a separate entity (note: even though SOCI offers extensive integration with Boost, it does not mandate it and SOCI can be compiled without any reference to Boost). Most likely solution is to keep SOCI orbiting around Boost in terms of coding conventions and seamless interfacing, as it does today, so that benefits for all interested parties can be retained. Your comments and suggestions considering the above are very welcome. Final note: SOCI does not use bjam. If this is considered as missing from the Boost point of view, contributions from experienced bjam users would be needed. Cheers, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

9 20

[filesystem] Following symlinks
by Scott McMurray 15 Jul '08

15 Jul '08

Suppose I want to add to simple_ls so it tells me the target of a symlink like ls -l does. else if ( fs::is_symlink( dir_itr->status() ) ) { ++other_count; std::cout << dir_itr->leaf() << " -> " << symlink_path(*dir_itr) << "\n"; } I haven't found any function to put in place of symlink_path. Is there one? It can't be a path decomposition, and the only other functions that return paths are current_path, initial_path, and the complete functions, so I don't think there is. ~ Scott

1 0

[filesystem] Resolving a path ?
by Loïc Joly 15 Jul '08

15 Jul '08

Hello, I'd like to know if there is in boost::filesystem a way to "resolve" a path. For instance, I have a path that is built from : "c:\foo1\foo2\..\bar1\bar2" And I'd like to obtain: "c:\foo1\bar1\bar2" Best regards, -- Loïc

4 5

[extension] Suggestion: Loading shared libraries from memory
by Robert Dailey 15 Jul '08

15 Jul '08

Hi, I'm not a huge expert on shared libraries, however I was wondering if there's a portable way to support loading libraries from a memory buffer instead of from the file system. If this is possible, could it be added as a feature to Boost.Extension? Thanks for reading!

3 3

[rfc] dual-mode regression testing
by joaquin＠tid.es 15 Jul '08

15 Jul '08

Hello, As it stands now, most testing force goes to the trunk of SVN, which is good. The problem is that there are few regression runners running against the release branch, and I think we have a trade off: a regression runner volunteer will choose to work on either the trunk or the release branch, but taking care of both is possibly too much of a hassle. It is assumed that the release branch is much cleaner and thus needs less attention, but it's better to be safe than sorry wrt this. My proposal is then: why not modify the regression tool code so that it operates by default in *dual mode*, i.e. it automatically downloads two tarballs (trunk & release) to different folders, test them separately and upload the results to the appropriate destinations? From the point of view of a volunteer, setting this to work is as simple as having it running only against one branch, and the only drawback is that resource consumption doubles, but this might be acceptable to a fair number of people. Comments? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[parameter][accumulators] test failures on release branch
by Richard Webb 15 Jul '08

15 Jul '08

(reposting this in it's own thread, to make sure it doesnt get lost). The release branch parameter/accumulator tests are showing a large number of failures due to a missing #include <boost/type_traits/is_convertible.hpp> in boost/parameter/aux_/tagged_argument.hpp e.g. http://tinyurl.com/642sgq Thanks, Richard Webb

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by joaquin＠tid.es 15 Jul '08

15 Jul '08

Chris Newbold escribió: >> From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] >> On Behalf Of JOAQUIN M. LOPEZ MUÑOZ >> Sent: Friday, July 11, 2008 11:35 AM >> >> BTW, have you tried the fix I was proposing? >> > > Not yet. I'm on vacation this week, but I will try it as soon as possible. My only concern is whether referencing singleton_default from the constructor for fast_pool_singleton will guarantee proper initialization ordering. > > 3.6.2 doesn't really shed any light on how ordered and unordered initialization may be coupled. There isn't, for example, any expressed guarantee that non-locals will be initialized prior to first reference. > There is no such guarantee indeed, but the fix does NOT rely on initialization rules for non-local objects, but on the initialization rules for *local* objects with static storage duration (6.7/4): the singleton is a local static object inside the function singleton_default<T>::instance(), which is explicitly invoked inside fast_pool_allocator ctors via singleton_pool<...>is_from() (if you apply the fix, that is). The non-local object involved in singleton_default<T>, namely singleton_default<T>::create_object is there to guarantee that singleton_default<T>::instance() is invoked, and thus the singleton created in dynamic initialization time *if no one has done it before*. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

a new release of Join - asynchronous concurrency library
by Yigong Liu 15 Jul '08

15 Jul '08

Hello, I just uploaded a new version of Join library to Vault under Concurrent Programming. Based on the feedback from list, the following changes are made: . add schedulers as actor's template policy class . add timed synchronous calls . add doc and samples for port based API . add more doc about Join internals. For people who are not familiar with the librayr. Here is a simple description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. website and download: http://channel.sourceforge.net Any comments and suggestions are highly appreciated. Thanks Yigong

1 0

Streaming Lambda functions
by Robert Jones 14 Jul '08

14 Jul '08

Is it possible to invoke user defined streaming operators within boost lambda functions? In this style #include <iostream> #include <map> #include "boost/lambda/lambda.hpp" using namespace std; ostream & operator << ( ostream & ostrm, pair<string, string> const & input ); ostream & operator << ( ostream & ostrm, map<string, string> & inputs ) { using namespace boost :: lambda; for_each ( inputs.begin( ), inputs.end( ), ostrm << _1 << '\n' ); return ostrm; } Is this basically undoable, or am I doing it wrong? Also, does the online Comeau compiler understand the boost include directives? Thanks, Rob.

5 14

z/OS supported
by Dr. Franz Fehringer 14 Jul '08

14 Jul '08

Hello all, Is z/OS (recent version assumed) with USS (Unix System Services) a supported configuration with respect to the boost library components? Cheers Franz

2 1

Re: [boost] Bind question, is there any way to implicitly go through a reference_wrapper?
by Michael Goldshteyn 14 Jul '08

14 Jul '08

Sorry, post got garbled, here it is again: #include <boost/bind.hpp> #include <boost/ref.hpp> #include <string> // Define a simple class for our example class Crayon { public: explicit Crayon(const std::string &color=std::string()):m_color(color) {} const std::string &GetColor() const {return m_color;} private: std::string m_color; }; int main(int argc, char *argv[]) { using namespace std; using namespace boost; Crayon cr("blue"); boost::reference_wrapper<const Crayon> crefCr(cr); // This compiles std::string color(boost::bind(&Crayon::GetColor,_1)(cr)); // This also compiles, using an explicit get on crefCr std::string colorFromConstRef(boost::bind(&Crayon::GetColor,boost::bind(&boost::referenc e_wrapper<const Crayon>::get,_1))(crefCr)); // This doesn't compile, however, even though the reference_wrapper class template has // an overloaded operator T& () const function std::string colorFromConstRef2(boost::bind(&Crayon::GetColor,_1)(crefCr)); }

1 0

unmerged changes in boost function
by Emil Dotchevski 14 Jul '08

14 Jul '08

I can see that the new allocator semantics in boost::function have not been merged into the release branch. I would volunteer to do the merge but it seems like there are some other changes that I'm not familiar with. Doug, how should this be handled? I would hate 1.36 to go out without the new allocator support for boost::function as I already have code that depends on it. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[function][release] outdated boost/function/detail/prologue.hpp header causing regressions in MSVC++ 9.0
by joaquin＠tid.es 14 Jul '08

14 Jul '08

Hello, Just in case this is going unnoticed: Boost.Function is having regressions at the release branch for MSVC++ 9.0, see for instance: http://tinyurl.com/5h2wl5 Seems the problem is simply that function_template.hpp was last merged to the branch release later than boost/function/detail/prologue.hpp (merged at 41356) so that the release does not have revisions 44030 and 44056 of this last header, resulting in the lack of a necessary inclusion of <boost/type_traits/is_void.hpp>. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

base64 filter works incorrect if sorce string length % 3 != 0
by Игорь Палагута 14 Jul '08

14 Jul '08

Hello, I have the following code: #include <boost/archive/iterators/binary_from_base64.hpp> #include <boost/archive/iterators/base64_from_binary.hpp> #include <boost/archive/iterators/insert_linebreaks.hpp> #include <boost/archive/iterators/remove_whitespace.hpp> #include <boost/archive/iterators/transform_width.hpp> #include <string> #include <exception> #include <iostream> int main() { using namespace boost::archive::iterators; typedef insert_linebreaks< base64_from_binary< transform_width< std::string::const_iterator, 6, sizeof( char ) * 8 > > ,72 > to_base64_type; typedef transform_width< binary_from_base64< remove_whitespace< std::string::const_iterator > >, sizeof( char ) * 8, 6 > to_binary_type; std::string hello_ = "hello"; std::string base64_hello_( to_base64_type( hello_.begin() ) , to_base64_type( hello_.end() ) ); std::cout << base64_hello_ << std::endl; try { std::string hello_recovered_( to_binary_type( base64_hello_.begin() ) , to_binary_type( base64_hello_.end() ) ); std::cout << hello_recovered_ << std::endl; } catch ( const std::exception& e_ ) { std::cerr << e_.what() << std::endl; } return 0; } During base64 decode we have following exception: "attempt to decode a value not in base64 char set". We have the problem because source string hello_ = "hello", has length % 3 != 0, otherwise we don't have this exception. As I know in this case we should add appropriate number of special symbol like '='. I can add '=' manually, but boost base64 decode can't process them, and we also have exception If we have insert_linebreaks/remove_whitespace filter perhaps we also should have some symmetric filter for text padding? Do we have padding filter in boost? Or perhaps it will be in future? Thanks

2 1

detecting ODR violations
by Steven Watanabe 14 Jul '08

14 Jul '08

AMDG I've been trying to work out a way to cause an explicit error if configuration macros are defined differently in different translation units. I really wish I could cause a link error, but the best I've been able to come up with so far is a runtime error // test_odr.hpp #ifndef TEST_ODR_HPP_INCLUDED #define TEST_ODR_HPP_INCLUDED #include <iostream> #include <cstdlib> #ifndef SOME_MACRO #define SOME_MACRO true #endif template<bool> struct test_odr { static bool value; }; template<bool b> bool test_odr<b>::value = SOME_MACRO; namespace { struct test_odr_impl_t { test_odr_impl_t() { if(test_odr<true>::value != SOME_MACRO) { std::cerr << "Error: SOME_MACRO defined differently in two translation units.\n"; std::abort(); } } }; test_odr_impl_t test_odr_impl; } #endif // test_odr1.cpp #include "test_odr.hpp" int main() {} // test_odr2.cpp #define SOME_MACRO false #include "test_odr.hpp" Comments? Any better ideas? In Christ, Steven Watanabe

3 3

[intrusive] Problem with EDG base compilers in strict Ansi mode.
by Markus Schöpflin 14 Jul '08

14 Jul '08

Hello, currently any_test and doc_any_hook fail on Tru64/CXX with the following errors: cxx: Error: ../boost/intrusive/detail/any_node_and_algorithms.hpp, line 276: class template "boost::intrusive::any_algorithms<VoidPointer>" has no member "unlink_not_available_for_any_hooks" (notmember) any_algorithms<VoidPointer>::unlink_not_available_for_any_hooks(); -----------------------------------^ cxx: Error: ../boost/intrusive/detail/any_node_and_algorithms.hpp, line 283: class template "boost::intrusive::any_algorithms<VoidPointer>" has no member "swap_nodes_not_available_for_any_hooks" (notmember) any_algorithms<VoidPointer>::swap_nodes_not_available_for_any_hooks(); -----------------------------------^ AFAICT this is the only EDG based compiler which tests in strict Ansi mode, adding -strict_ansi to the other EDG based compilers (acc for example) would probably lead to the same error. Attached patch contains a proposed fix for this. It checks for __EDG__ and __STD_STRICT_ANSI to enable the fix and works for me locally. The patch should replace the compile error by a link error, because in strict Ansi mode EDG doesn't allow you to refer to non-existing names. OK to apply? Regards, Markus Index: detail/any_node_and_algorithms.hpp =================================================================== --- detail/any_node_and_algorithms.hpp (revision 46676) +++ detail/any_node_and_algorithms.hpp (working copy) @@ -269,6 +269,11 @@ static bool unique(const_node_ptr node) { return 0 == node->node_ptr_1; } + +#if defined(__EDG__) && defined(__STD_STRICT_ANSI) + static void unlink(node_ptr); + static void swap_nodes(node_ptr l, node_ptr r); +#else static void unlink(node_ptr) { //Auto-unlink hooks and unlink() call for safe hooks are not @@ -282,6 +287,7 @@ //what algorithm they must use from unlink them from the container any_algorithms<VoidPointer>::swap_nodes_not_available_for_any_hooks(); } +#endif }; } //namespace intrusive

2 8

[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