- Boost - lists.boost.org

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