March 2006 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-1461533 ] Non-basic-source-character-set characters conflict with MSVC
by SourceForge.net 30 Mar '06

30 Mar '06

Bugs item #1461533, was opened at 2006-03-30 09:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1461533&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Non-basic-source-character-set characters conflict with MSVC Initial Comment: There exist high-ascii characters in the Boost sources that cannot be converted to the local region for a given computer because the context of the originating region of the source is not known. Thus, these high-ascii characters may not have a proper mapping, and a warning will be emitted by MSVC 2003 and 2005. This should be considered a failure case because, though low, it is still emitting an alert. Thus, without the correct region set on your system, the Boost sources fail to build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1461533&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

[Pragram Options in particular]std::basic_string usage
by Sean Huang 30 Mar '06

30 Mar '06

I noticed that a few boost libraries use std::basic_string differently. For example, boost::program_options uses it like this: template<class T, class charT> void validate(boost::any& v, const std::vector< std::basic_string<charT> >& xs, T*, long); And string_algorithm uses the following instead: template< typename SequenceT, typename CharT, typename RegexTraitsT, typename FormatStringTraitsT, typename FormatStringAllocatorT > inline void replace_all_regex( SequenceT& Input, const basic_regex<CharT, RegexTraitsT>& Rx, const std::basic_string<CharT, FormatStringTraitsT, FormatStringAllocatorT>& Format, match_flag_type Flags=match_default | format_default ); The standard says std::basic_string has 3 template parameters (two have defaults). Usages like std::basic_string<charT> would prevent the matching of non-standard traits or allocators. And in the case of program_options, my overload with 3 template parameters actually caused an ambiguity with one defined in program_options: My overload: template< class CharType, class Traits, class Alloc > void validate( boost::any& v, const std::vector< std::basic_string< CharType, Traits, Alloc > >& xs, unsigned long*, long ) Defined in program_options: template<class T, class charT> void validate(boost::any& v, const std::vector< std::basic_string<charT> >& xs, T*, long) My question is if the differences in usage is justified or just an oversight and what the recommendation is? Thanks, Sean

1 0

[unit] Bug in the get() function?
by Paul Giaccone 30 Mar '06

30 Mar '06

I have a function in my program that uses BOOST_CHECK* macros but is not part of a test suite. This is not allowed, of course, and the program fails, but not as I might expect it do. It gives an access violation in framework.hpp: test_unit const& get( test_unit_id id, test_unit_type t ) { test_unit const* res = s_frk_impl().m_test_units[id]; if( (res->p_type & t) == 0 ) //<<<<<<<<<<<<< access violation here throw std::logic_error( "Invalid test unit type" ); return *res; } and the error message "Boost.Test internal framework error: unknown reason". Obviously, my code is wrong, but I'm wondering whether it indicates a bug in the Boost library. Should the library trap this and give a more meaningful error message? Perhaps assert(res != 0); or if (res != 0) ... else ... is required before the "if" in the get() function. Paul

2 1

[python] threading-related failures on Linux
by Vladimir Prus 30 Mar '06

30 Mar '06

The OSL2-V2 test results show a few link failiures for Python tests, for example the 'bases' test: http://tinyurl.com/nyqv7 Looks like Boost.Python library wants multi-threading for some reason. In V1, those tests are linked with -pthread, and in V2, they are not. The logic responsible for this in V1 is in python.jam: # Force statically-linked embedding applications to be multithreaded # on UNIX. rule python-static-multithread ( toolset variant : properties * ) { if ! $(PYTHON_WINDOWS) { local x = <define>BOOST_PYTHON_STATIC_LIB <threading>single ; if $(x) in $(properties) { properties = [ difference $(properties) : <threading>single ] <threading>multi ; } } return $(properties) ; } And I don't understand some things: 1. What's the point of this at all? The comment is not very clear, it seems it means static linking to Boost.Python, not statically linked application in the usual sense (no shared libs at all). The comment does not say why threading multi is needed. 2. In V2, shared linking to Boost.Python is used, and the application is fully shared. So, where does the link error come from? Is comment even more inaccurate? 3. On my system, the test works just fine. Why does it fail elsewhere/ 4. The test in question, bases.cpp, has nothing but static asserts. It's not clear to me why it should link to Boost.Python at all. Can somebody explain this to me? Thanks in advance, Volodya

5 19

Re: [boost] reference counted object?
by David Maisonave 29 Mar '06

29 Mar '06

"Neal Becker" <ndbecker2(a)gmail.com> wrote in message news:<e08kla$7p2$1(a)sea.gmane.org>... > I wonder if we boost has anything useful for implementing reference > counting (or other gc) for objects? I know we have shared_ptr, but I > was interested in objects rather than pointers. > I'm currently working on a smart pointer that has value semantics policy for comparison operators, and automatic cloning features. This gives the smart pointer features assoicated with an object. Check out the following link: http://axter.com/smartptr

1 0

another way to (not) build the libraries
by Ulrich Eckhardt 29 Mar '06

29 Mar '06

Greetings! I think it was with boost 1.30 where we started using the threads library and at that time build support was not yet at the stage where we could really use it the way we wanted it to so we mostly invented our own. The first thing we did was to copy the required sourcefiles into the project where we needed them, i.e. the most primitive form of static linking. Later on, we replaced that with #including the sourcefiles (<lib/thread/src/...>) into a single file - the same thing only done in a way that we could switch to the next Boost version without changing our code. Well, at least we thought so, some files moved between Boost versions inside the source folder, another problem is that e.g. timeconv.inl provides things in an anonymous namespace and gets included by more than one sourcefile but doesn't have include guards. Anyhow, what I wonder is whether this is not a way that should be supported actively. In our case, it significantly reduced the adoption barrier for the threading lib, it also makes bjam use unnecessary (which I, even though I did quite some things with it already, still find unwieldy and don't completely understand), it avoids the problem of different compiler ABIs due to different compiler versions or settings and it reduces the additional required size of the final executable (example-prog[1] with above static linking weighs 52kB, the thread lib alone would have been 92kB already otherwise). I personally would be interested in documenting how to use Boost libs this way and also make it an officially supported way to do so. cheers Uli [1]: The example program below has been compiled with GCC using Boost 1.33, the only patch necessary was to add include guards to timeconv.inl. #include <iostream> #include <ostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> // for 'static' linking #include <libs/thread/src/thread.cpp> #include <libs/thread/src/xtime.cpp> #include <libs/thread/src/mutex.cpp> #include <libs/thread/src/exceptions.cpp> #include <libs/thread/src/condition.cpp> void thread() { std::cout << "thread(): entering\n"; boost::xtime tm; boost::xtime_get(&tm, boost::TIME_UTC); tm.sec += 2; boost::thread::sleep(tm); std::cout << "thread(): leaving\n"; } int main() { std::cout << "main(): creating thread\n"; boost::thread th(&thread); std::cout << "main(): waiting\n"; th.join(); std::cout << "main(): done\n"; }

7 7

Re: [boost] no matching function for call to boost::algorithm::split
by Reece Dunn 29 Mar '06

29 Mar '06

Olaf van der Spek wrote: > > I'm not sure. The code snippet you sent seems fine, so maybe the problem > > is elsewhere. I would check includes and namespaces. > > I've now got: > #include <boost/algorithm/string.hpp> > #include <string> > #include <vector> > > std::string f() > { > return ""; > } > > int main() > { > std::vector<std::string> v; > boost::split(v, f(), boost::is_any_of(",")); > return 0; > } > > split_test.cpp: In function 'int main()': > split_test.cpp:13: error: invalid initialization of non-const > reference of type 'std::string&' from a temporary of type > 'std::string' This is because f() is returning a std::string and this is being passed to the RangeT & argument in the split function. Due to C++ rules, performing the T -> T & conversion is invalid. Try defining f() as: const std::string f() { return ""; } HTH, - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

3 9

in_place_factory0
by Vaclav Vesely 29 Mar '06

29 Mar '06

Hi, is there any reason for missing in_place_factory without arguments? I would like to write optional<my_class> mc(in_place()); I've wrote the code for this. But I can't modify the macro hell in "in_place_factory.hpp". Regards, Vaclav class in_place_factory0: public in_place_factory_base { public: in_place_factory0() {} template<class T> void apply(void* address) const { new(address) T(); } }; in_place_factory0 in_place() { return in_place_factory0(); }

2 2

[Boost-bugs] [ boost-Feature Requests-1460859 ] make timezone csv file C/C++ compatible
by SourceForge.net 29 Mar '06

29 Mar '06

Feature Requests item #1460859, was opened at 2006-03-29 10:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1460859&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: make timezone csv file C/C++ compatible Initial Comment: The timezone database file "date_time_zonespec.csv" is used for the boost date/time library, and is nominally intended to be read as a data file, by boost code, and possibly also by Excel or similar software. Because the file consists of quoted Ansi character strings, it could also be treated like an initialization value for a char *str[] string array, and used via an #include. However, since the data lines do not end with a comma, the last field of each line will get compile-time concatenated with the first field of the next line, thus thwarting this usage. I propose that either (1) the file be changed to add a comma at the end of each line, or (2) the file be changed to add an empty "" string as an extra (dummy) field at the end of each line. Method (2) has the advantage of remaining CSV file compatible, while still being a valid list of quoted strings for char *str[] string array. The dummy zero-length string at the end of each line would be compile-time concatenated with the first field of the next line, effectively eliminating it. Method (1) has the advantage of not adding an extra dummy field. As used by the boost code, the CSV parser would have to be modified to simply ignore the last (dummy) field or the trailing comma, whichever was implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1460859&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[asio] STLPort and std::vector<const Pod_Type>
by Felipe Magno de Almeida 29 Mar '06

29 Mar '06

Hi, STLPort doesnt seem to allow const-types as parameters to std::vector. It chokes in the std::allocator which define const_reference as const reference, making the two the same type. This creates multiple declarations for function-members: pointer address(reference __x) const { return &__x; } const_pointer address(const_reference __x) const { return &__x; } Is the STLPort right in this context or should something be done? This is making this code fails: std::vector<char> v(128); boost::asio::buffer(v); The problem is that even with non-const pod type boost::asio::buffer is instatiating std::vector<const char>. Thanks, -- Felipe Magno de Almeida

4 4