July 2009 - Boost - lists.preview.boost.org

AlRangeExandrescu?
by Neil Groves 23 Jul '09

23 Jul '09

On Thu, Jul 23, 2009 at 3:03 PM, Thorsten Ottosen < thorsten.ottosen(a)dezide.com> wrote: > David Abrahams skrev: > >> Hi Neil, >> >> I'm sure someone already spoke to you about this, but just in case: Andrei >> Alexandrescu gave a very interesting presentation at BoostCon that was based >> on a "ranges only" approach that should eliminate issues like this one: >> >> 2: return type specification for find() etc >> =========================================== >> There where no major objection to the mechanism, but some found >> the syntax ugly. I believe the suggested syntax (e.g.) >> >> boost::find[_f,_e]( range, x ) >> >> boost::find[_f+1,_e]( range, x ) >> >> >> He says he's implemented a superset of the STL algorithms with it so we >> know the expressive power is fairly complete. >> > > If I remember correctly, he claims that his return of find() is the > "correct" one. I think that is plain wrong, as the syntax above shows that > there are many useful return ranges, perhaps with an obvious default. > > So the above is not an "issue" IMO, but a usable feature. > Yes, that is what I was trying to describe earlier. If we want a parameterisable return range, we need a parameter and an addition to the syntax, Perhaps the assumption that a parameterisable return range is desirable is at fault in which case Andrei's answer is the right one. I agree with Thorsten that the current RangeEx solution is superior because, the parameterisable return is optimally efficient whereas adapters applied to a more general range return type incurs overhead in space and time. I do fully intend to look at Andrei's work in more depth. My previous comment about studying the work briefly was not intended to indicate satisfaction with this state, merely that I am currently ignorant of the full ramifications of the proposed Range Concepts. > > -Thorsten > Neil Groves

1 0

RFC: interest in Unicode codecs?
by Cory Nelson 23 Jul '09

23 Jul '09

Is there interest in having a Unicode codec library submitted to Boost? Here is what I have (only tested with GCC 4.3 on Debian, and VC++ 2008): http://svn.int64.org/viewvc/int64/snips/unicode.hpp Right now it is pretty simple to use: transcode<utf8, utf16le>(forwarditerator, forwarditeratorend, outputiterator, traits [, maximum]); transcode<wchar_encoding, utf32be>(inputrange, outputrange, traits [, maximum]); There is also a codecvt facet which supports any-to-any. Supports UTF-8, UTF-16, and UTF-32, in little or big endian. Has a special wchar_encoding that maps to UTF-16 or UTF-32 depending on your platform. A traits class controls error handling. -- Cory Nelson

11 30

slightly off topic- using GDB on cygwin to debug a DLL
by Robert Ramey 23 Jul '09

23 Jul '09

In the past I've used GDB under cygwin to debug serialization test failures for the gcc compiler. This has worked pretty well. However, now I have a couple of tests test_dll_simple and test_dll_exported that I want to debug. When I try this I get the following error message: gdb: unknown target exception 0xc0000135 at 0x7c964ed1 I'm thinking that this might be an indicator that "it" can't find the dlls which are part of the test as they are in a different place in the directory hierarchy than the test executable. Does anyone with experience with this have any suggestions as to what to do? Robert Ramey

2 1

Boost.Function comparison, again
by David Abrahams 23 Jul '09

23 Jul '09

The docs say: When comparing against an instance of reference_wrapper, the address of the object in the reference_wrapper is compared against the address of the object stored by the function object wrapper: a_stateful_object so1, so2; f = boost::ref(so1); assert(f == boost::ref(so1)); assert(f == so1); // Only if a_stateful_object is EqualityComparable assert(f != boost::ref(so2)); I take it from the above that so1 == so2 implies f == so2 function_equal(so1,so2) implies f == so2 ? Neither one of those is made entirely clear from the above. It appears that the library assumes a function object may be _stored_ by ref f = boost::ref(so1); for efficiency reasons, but will only be _compared_ by ref assert(f == boost::ref(so1)); because so1 is stateful. What is the rationale for this asymmetry? Is there a role for the is_stateless type trait in smoothing over these bumps? Seems to me that if you know the type is stateless, comparing addresses isn't very useful. TIA, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[uuid] proposed fix for windows_generator.hpp
by Christian Leutloff 22 Jul '09

22 Jul '09

Hi, In boost/uuid/windows_generator.hpp a conversion routine is used that does return a UUID but it is not the same as the one that was generated through the call to UuidCreate(). I have attached a test case that is showing the difference of the choosen implementationen and the expected one. The expected one was validated using the VS debugger, too. I would like that the provided convertion routines from the windows specific GUID/UUID structure to boost::uid and vice versa will be included in boost::uuid, too. I'm using the v13 version from the vault. Should I open a bug report for this issue? Bye Christian -- Christian Leutloff, Aachen, Germany ______________________________________________________ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de

2 1

Static Libraries / Multiply Defined Symbols
by Audino, Jeremy 22 Jul '09

22 Jul '09

Using Visual Studio 2005, I have two independent static libraries making use of boost. When linking both into an executable I'm getting some multiply defined symbols. I suspect that since most of boost's implementation is header-only, symbols for the boost library functions are appearing in both libraries. I can get around this by specifying /FORCE:MULTIPLE when linking, but this isn't ideal. Is there a better way to get around this? Best Regards, Jeremy libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::get_file_name_from_handle_function(void *,wchar_t *,unsigned int,unsigned int &)'::`7'::library_unloader::library_unloader(void *)" (??0library_unloader@?6??get_file_name_from_handle_function@winapi@interprocess@boost@@YA_NPAXPA_WIAAI@Z@QAE@0@Z) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::get_file_name_from_handle_function(void *,wchar_t *,unsigned int,unsigned int &)'::`7'::library_unloader::~library_unloader(void)" (??1library_unloader@?6??get_file_name_from_handle_function@winapi@interprocess@boost@@YA_NPAXPA_WIAAI@Z@QAE@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`9'::handle_closer::handle_closer(void *)" (??0handle_closer@?8??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@PAX@Z) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`9'::handle_closer::~handle_closer(void)" (??1handle_closer@?8??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::auto_ptr(union `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`10'::mem_t *)" (??0auto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@PATmem_t@?9??1234@YA_N0@Z@@Z) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::~auto_ptr(void)" (??1auto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: union `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`10'::mem_t * __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::get(void)const " (?get@auto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QBEPATmem_t@?9??2345@YA_N0@Z@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: union `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`10'::mem_t * __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::operator->(void)const " (??Cauto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QBEPATmem_t@?9??1234@YA_N0@Z@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) C:\home\jaudino\src\prs-removal\bin\translatorD.exe : fatal error LNK1169: one or more multiply defined symbols found Jeremy F. Audino Senior Software Development Engineer Philips Healthcare -- Nuclear Medicine Tel: 440-483-7444 E-mail: jeremy.audino(a)philips.com ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

3 3

FreeBSD regression testing
by Bruce Simpson 22 Jul '09

22 Jul '09

Hi all, Thanks to whomever cleaned up the old runs on this page: http://www.boost.org/development/tests/release/developer/summary.html I just wanted to ask: * what's the procedure here, are old runs cleaned up automatically? * Is there a preferred naming convention for the runs? We're aware of some issues with Boost.Build on 64-bit FreeBSD platforms at the moment. I'll be starting another run shortly, but will be performing it on i386, so as to avoid the FAILs we're seeing. I just merged a fix to FreeBSD's system gcc to deal with some issues in global 'using' declarations, that should bring FreeBSD-STABLE/i386 closer to the other platforms in terms of Boost stability. I would like to get a slice of FreeBSD cluster resources to run the Boost regression tests periodically, so I'll have a chat with the cluster admins about it. thanks, BMS

2 1

[threadpool] renmaed to task
by k-oli＠gmx.de 22 Jul '09

22 Jul '09

Hello, boost.threadpool is renamed to boost.task - the review schdule list should be updated soon. Oliver

1 0

[1.40.0] Release plans
by Beman Dawes 22 Jul '09

22 Jul '09

I've been missing in action for most of the month, working on C++ committee stuff. Sigh. Rather than set a new release schedule for 1.40.0 right now, I'm planning to spend the next week or so looking at the state of the release branch, and pestering folks as needed. As that process proceeds I'll get a better sense of what a reasonable schedule would be to finish the release. In the meantime, the release branch is still open for merges as long as they are stable on trunk tests. --Beman

1 0

[introspection] Status
by Richard Hazlewood 22 Jul '09

22 Jul '09

I see the vault contains some introspection helpers (for checking for member function existence). AFAICT these utilities are not currently in boost nor scheduled for review. Are there any plans to bring them forward? (There appears to be an overlap with some of the introspection utils in mpl - though only for member variables there.)

5 6