August 2008 - Boost - lists.preview.boost.org

Re: [boost] UTF-8 conversion etc. upper,lower case converting
by Graham 26 Aug '08

26 Aug '08

>Message: 8 >Date: Tue, 26 Aug 2008 12:49:36 +0200 >From: Martin Lutken <mlu(a)danware.dk> >Subject: Re: [boost] UTF-8 conversion etc. upper,lower case converting >To: boost(a)lists.boost.org >Message-ID: <200808261249.36750.mlu(a)danware.dk> >Content-Type: text/plain; charset="iso-8859-1" > >On Monday 07 April 2008 19:20:56 Sebastian Redl wrote: >> Graham wrote: >> As requested, I have posted a Unicode character support library in the >> boost vault as Unicode_lib.zip. >> >> Please feel free to use this under the boost license. >> >> It would be great if somebody had the time to develop the existing >> character support to ad the string wrappers that we had intended to - >> but ran out of time doing. >> >> It should be well documented, but if you want any questions answered, >> please feel free to ask and I'll try and help! > >I have been looking at your work. Would it be usefull for converting >upper,lower case for non ASCII charaters ? > > >I have been trying to use those functions in : ><boost/algorithm/string.hpp> >But they don't seem to work for my utf-8 strings. I tried with different >locales, but that doesn help. Seems I need a locale that defines all the >facets for converting between UTF-8 upper- and lowercase characters. >I was thinking, perhaps you library could be used for that somehow ? > >-Regards Martin L Martin, The standard upper to lower case conversion makes huge assumptions and is very Western character set targeted. For example ... many people and many simple functions assume that converting a character from upper to lower case will give you the same size of character [or same length of string] which is simply not true. The Unicode library I posted has full support for Unicode upper to lower and lower to upper case conversion and these features are easy to use. Yours, Graham

1 0

BOOST_MPL_ASSERT_MSG producing linking problems in MSVC++ 8.0
by JOAQUIN M. LOPEZ MUÑOZ 26 Aug '08

26 Aug '08

Hello, I found the following problem when using BOOST_MPL_ASSERT_MSG under Visual Studio 2005 Express Edition: * Create a basic console project * Include files foo1.cpp and foo2.cpp (files attached) * Build; the following error shows up at linking time: >Linking... >foo2.obj : error LNK2005: "public: static struct boost::mpl::failed * * * * * * * * * * * * (__thiscall `bool __cdecl f<int>(void)'::`2' ::ALWAYS_TRUE::** * * * * * * * * * * __cdecl `bool __cdecl f<int> (void)'::`2'::ALWAYS_TRUE0::assert_arg(void))(int)" (?assert_arg@ALWAYS_TRUE0@?1???$f@H@@YA_NXZ@SAPAPAPAPAPAPAPAPAPAPAPAP8<mailto:?assert_arg@ALWAYS_TRUE0@?1???$f@H@@YA_NXZ@SAPAPAPAPAPAPAPAPAPAPAPAP8> ALWAYS_TRUE@?1???$f@H@@YA_NXZ@AEPAPAPAPAPAPAPAPAPAPAPAPAUfailed@mpl@boost@@H@ZXZ<mailto:ALWAYS_TRUE@?1???$f@H@@YA_NXZ@AEPAPAPAPAPAPAPAPAPAPAPAPAUfailed@mpl@boost@@H@ZXZ>) already defined in foo1.obj This duplication problem happens only when BOOST_MPL_ASSERT_MSG is used at function or member function level. At class level everything works OK. Has anyone seen this before? I've created a ticket for this issue: http://svn.boost.org/trac/boost/ticket/2262 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarollo

1 0

[C++-sig] Python Binding woes for BGL with Intel Compiler
by Sandeep Gupta 26 Aug '08

26 Aug '08

Hi, I am unable to use python bindings for boost.graph. Python gives "undefined symbol" error signifying it cannot correctly load the shared libraries. I am clueless because the problem appears for intel compiler on linux but not with gcc compiler on linux. So in all likelihood I am not making rookie mistakes. So my larger question is Boost library supported for compilers other than gcc. I ask this question because few months back my concerns regarding intel compiler found no audience. Would appreciate some response. thanks, sandeep

4 8

[thread] Interrupt callback?
by Preston A. Elder 26 Aug '08

26 Aug '08

I want to be able to get an interruption callback (as, say a boost::function) for the current thread. Here is the deal - I have a boost::thread_group, now each thread is creating a series of messages. This message passed from thread to thread, and as it passes to a new thread, each thread needs to put into the message a callback function that can be used to interrupt the thread that owns said message. This is mainly so that if I want to do something with the message mid-'flight' (the request will come from a different thread processing the message), and it happens to be waiting on a condition, I can interrupt that thread and handle the change request on the message. Here is the problem - there is no way to get the callback function from within the thread itself, or indeed. The best I can do is create the thread then set the function in some kind of data structure AFTER the thread has been created, and use some kind of condition or something to 'hold' the new thread until this function has been set. This is kind of dodgy imho. It also requires me to keep a secondary structure pretaining to a thread outside the thread_group. At which point I may as well do the thread_group by hand (which, given the simplicity of thread_group is not a huge amount of code, but still). So, is there a solution that will satisfy the code poet in me? or do I just roll my own thread group? PreZ :)

1 0

[filesystem] Linux copy_file api with wpath
by Joshua Peterson 26 Aug '08

26 Aug '08

It seems that Boost.FileSystem does not implement some methods accepting wpath arguments when compiled with GCC 3.4.3 on Linux. This occurs because BOOST_FILESYSTEM_NARROW_ONLY is defined, which according to the comment in the code occurs for "badly broken compilers or libraries". Ideally, I would like to use the boost::filesystem::copy_file() method on both Windows and Linux, passing wpath arguments in both cases. Is the lack of wpath support simply a problem with GCC 3.4.3, or is wpath never supported for copy_file() with GCC? I can see from the implementation of boost::filesystem::detail::copy_file_api() that open(), read(), and write() are used to copy the file. Since open() accepts only a const char* this may be the limitation. If this is the case, has there been any discussion of providing a copy_file() method which accepts wpath arguments and converts from wchar_t to char before calling copy_file_api(). I do not have a lot of experience with locales and character encodings, so I may be missing something. If this has already been discussed on this mailing list or elsewhere, please point me to the correct discussion, as I have been unable to find it. Thanks. Josh -- Rejoice always. Pray without ceasing. In all circumstances give thanks, for this is the will of God for you in Christ Jesus. -- 1 Thes. 5:16-18 NAB -- I am the living bread that came down from heaven; whoever eats this bread will live forever; and the bread that I will give is my flesh for the life of the world. -- John 6:51 NAB

2 6

[function_types] member_ccs / GCC test annotations
by David Abrahams 25 Aug '08

25 Aug '08

With x86 linux gcc-4.0.1, I get this for the member_ccs test: member_ccs.cpp:17:5: error: #error "test not supported with this compiler/platform" and the test is annotated thusly: Not all compilers/platforms implement nonstandard calling conventions. With GCC/x86 this failure reflects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29328 . But the nonme the nonmember_ccs test *also* fails with the same error, and this annotation: Not all compilers/platforms implement nonstandard calling conventions. i.e. there is no reference to a GCC bug. Points: * The error message for member_ccs is inconsistent with the note about the gcc bug. * The function types library documentation barely mentions "calling conventions" and doesn't explain what "nonstandard" means in this context. For example, does extern "C" count? * Since I am running x86/GCC, the note about the GCC bug much more specific than the other part of the note, so I assumed that it applied. That would mean that my platform implements a nonstandard calling convention, but a compiler bug is causing the test to fail. * However, that interpretation would be inconsistent with the annotation for nonmember_ccs. * I suspect that my platform does not support nonstandard calling convention, and the bug only applies on platforms where GCC supports nonstandard calling conventions (e.g. Windows), and does not apply to me. If so, the annotation should be more specific about the platforms on which the note applies. * The error message should be better, e.g.: "this platform does not support nonstandard calling conventions; the test is irrelevant here" * A test that always succeeds when the platform doesn't support nonstandard calling conventions would yield far more reliable results than the overly general wildcard matching of failure annotations you have now, which makes a failure on any platform look as though it were expected in the testing chart. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

Problems with boost 1.36 and serialization library with VS2005 SP1
by Hansi 25 Aug '08

25 Aug '08

Hello, at the moment I wont to switch from boost 1.34.1 to 1.36. But now I have a compile error witch depends from the serialization error. I have a managed application and for that there is also a definition array in the cli namespace. The new version of boost seems to define somewhere the namespace boost globally and so it is not anymore possilbe to compile the application. I have searched where this problem exists but I don't have found the header... I have found only that the problem exists when this 2 headeres are included #include <boost/serialization/detail/shared_ptr_132.hpp> #include <boost/archive/basic_binary_iprimitive.hpp> Has anyone an idea how I can solve the problem? Best regards Hansjörg

3 5

Cannot compile the debug version.
by john chen 25 Aug '08

25 Aug '08

Dear All, I wouldn't be able to compile the debug version of boost_1.360 (cannot find *-gd* under boost/lib). I tried following bjam arguments: bjam ^ --prefix=c:\boost install ^ --build-dir=c:\boost ^ --sBUILD=debug ^ --toolset=msvc ^ --threading=multi ^ --link=static and bjam ^ --prefix=c:\boost install ^ --build-dir=c:\boost ^ --sBUILD=debug release ^ --toolset=msvc ^ and it still doesn't build the debug version. My environment: ms vista 32 ms vc9 sp1 boost 1.360 bjam 03.1.17 Can someone tell me how to get the debug version? Thanks very much. John

2 4

[math][libs] Header-only status wrong for Boost.Math
by Daryle Walker 25 Aug '08

25 Aug '08

Looking at <http://www.boost.org/doc/libs>, I see 14 entries using separate source, but I have 15 source directories still in my all- Boost library project. It seems that the Special Function section of the Math library has separate source for the (optional) C99 and TR1 math functions, but the library page doesn't list that. (The source files are mentioned in the Math-SpecFunc docs.) Can that be changed, please? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 4

[test] More on formatting log entries for XCode (by default when applicable)
by Daryle Walker 25 Aug '08

25 Aug '08

This is based on the <https://svn.boost.org/trac/boost/ticket/2059> ticket I entered a couple months ago. I just tried out the actual change needed and attached it to the ticket. (I just made a project that compiles all the mandatory Boost source code, like the unit-test framework, into various static libraries I can include in my other projects without repeating the compilation instructions [or wasting disk space]. Centralization is fun.) I still don't know if my __APPLE_CC__ preprocessor test is the official way to check for Xcode, or any compatible, setup. I heard that the current code is supposedly formatted for Visual C++'s error message handling. If so, and the class I changed is _not_ where the per-compiler-product changes are supposed to go, then move the code as needed. (I guess there would be parallel visual-c++ and xcode default formatting classes.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1