- Boost - lists.boost.org

[lexical_cast] locale dependent result? (was: [lexical_cast] locale dependent result?)
by Alexander Lamaison 02 Mar '11

02 Mar '11

No response on the boost.user list so I'm trying here in case the devs know: Is the result of lexical_cast<std::string> locale-dependent? One of my contributors has submitted a fix for a problem he says is caused by lexical_cast adding commas to a port number, e.g.: 65535 becomes "65,535". I'm unable to reproduce this but it may be something specific to his locale. If this is the case, what would be the correct way to get a canonical, locale-independent string from an integer? Thanks. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

3 5

GSoC SIMD project
by Mathias Gaunard 02 Mar '11

02 Mar '11

Joel Falcou and I have a SIMD library in the works that we plan to submit to Boost by May; we've also submitted a boostcon talk on the subject. Would it be acceptable to propose a GSoC project within Boost which could involve porting the library to new architectures, writing more tests, documentation, and examples, playing with it to implement fast vectorized functions for common tasks, etc.?

8 17

Re: [boost] Boost and pkg-config support
by Steve M. Robbins 02 Mar '11

02 Mar '11

Boosters, please see the following for background: [1] https://svn.boost.org/trac/boost/ticket/1094 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593876 On Sun, Feb 27, 2011 at 08:08:42PM +0000, Roger Leigh wrote: > https://svn.boost.org/trac/boost/ticket/1094 > is the upstream ticket for adding pkg-config support. I've already > done the bulk of the work, the patches are all there. Do you have > any knowledge of bjam? Vladimir is the bjam expert ;-) > boost-pkg-config-gen.cc is the program to acquire the information > and generate the .pc file. It just needs building with these defines: > TEST_HEADER - the header to include for a given boost library > PREFIX - the bjam prefix (however you get at it) > LIBDIR - the bjam libdir (however you get at it) I have spent some time trying to patch bjam and have no inclination to spend any more time with that code. For Debian purposes, could we obtain PREFIX and LIBDIR directly from debian/rules? (In fact, they would be constants, of course). What about TEST_HEADER? > So the program just needs building and running once for each Boost > library (bjam must have a list of libraries, or at least provide some > means for us to get at the information). Bjam has a list of the libraries that are *compiled* to a so/dll. Is that enough? The root of the problem [3] is inlined code and there's no guarantee that a header-only library won't similarly inline something that requires, say, -lboost_system. Boost Developers: is there a machine readable list of libraries somewhere in the boost source tree? Thanks, -Steve

3 3

[Review] Phoenix V3: Mini-review ends March 2nd
by Hartmut Kaiser 02 Mar '11

02 Mar '11

This is just a friendly reminder that the mini-review of Phoenix V3 (written and submitted by Thomas Heller) ends tomorrow, March 2nd 2011. If you are planning to submit a review, please do so asap. If you need more time for your review, please get in direct contact with me. Regards Hartmut Review Manager --------------- http://boost-spirit.com

1 0

[enums] Interest in an alternative emulation of scoped enums classes
by Vicente Botet 01 Mar '11

01 Mar '11

Hi, I have been working in an alternative implementation of the Beman's Scoped enums macros (http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=new_topic…) Daniel James proposed. The macros are very similar BOOST_ENUM_CLASS_START(algae, uint8) { green, red, cyan } BOOST_ENUM_CLASS_END(algae, uint8) algae sample( algae::red ); void func(algae); The major advantages are: * No need to use a macro to name the type in most of the cases * The type is not implicitly convertible to the underlying type neither to bool and so it is closer the intended goal of strongly enums. * Allows to state explicitly the underlying type The major liabilities are: * In some context we can not use the enum class. This is the case of switch statements and template parameters. In order to get the native enum value a free function enums::get_value allows to workaround that in a portable way. algae v; ... switch (boost::enums::get_value(v)) { case algae ::green: return("EnumClass::Default"); case algae ::red: return("EnumClass::Enum1"); case algae ::cyan : } * the emulation is not an enum, that is is_enum(algae)::value is false The user can use is_enum<enum_type<EC>::type> or the library could provide an is_enum nested on the enums namespace. enums::is_enum<EC> or we can specialize boost::is_enum<EC> For template parameters the meta-function enum_type gives the type of the native enum used by the emulation. template <enums::enum_type<algae>::type V> struct ex; * Use in union The emulation providing constructors (which is optional) can not be used in unions if the compiler doesn't allows class with constructors in unions. * default value There is no portable way to manage with standard *implicit* default values if the enum class emulation can not define constructors. I have found an explicit way that allows to assign the default value. Use default_value<EC>(). This function will be equivalent to EC() if enum class is supported by the compiler. algae e(enums::default_value<algae>()); * Explicit conversion from int There is no portable way to manage with standard *explicit* conversion of ints if the enum class emulation can not define constructors. I have found an explicit way that allows to manage with explicit conversion using a function convert_to<EC>(v) instead of the Constructor. This function will be equivalent to EC(v) if enum class is supported algae e(convert_to<algae>(1)); There is not too much documentation yet. You can find the code and some test in the sandbox https://svn.boost.org/svn/boost/sandbox/enums I could provide alternative macros for users considering a better approach necessary * PP Sequence Syntax BOOST_ENUM_CLASS(EnumClass, Underlying, ( (Enum0) (0) ) ( (Enum1) ) ( (Enum2) ) ); PP Variadic Syntax BOOST_ENUM_CLASS(EnumClass, Underlying, (Enum0) (0), Enum1, Enum2 ); With the macros the meta-functions and the functions we can write portable code using strongly scoped enums. Is there any interest for this in Boost? Comments or suggestions appreciated, Vicente P.S. the convert_to function is the one of Boost.Conversion. -- View this message in context: http://boost.2283326.n4.nabble.com/enums-Interest-in-an-alternative-emulati… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

[scope_exit] MSVC error C2355: 'this' : can only be referenced inside non-static member functions
by Lorenzo Caminiti 01 Mar '11

01 Mar '11

Hello all, I am trying to use Boost.ScopeExit parameter binding mechanism to implement Boost.LocalFunction. To do so, I need to use some internal ScopeExit code to detect the type of `this` and bind its value to the local function declaration. The following code works on GCC but not on MSVC... This appears to be a MSVC 2008 bug: http://connect.microsoft.com/VisualStudio/feedback/details/331418/erroneous… 1) Can anyone please try this code on MSVC versions later than 2008 to see if it was fixed? 2) Do you know of a workaround for this problem? // File: lf03.cpp #include <boost/scope_exit.hpp> struct c { void f() { typedef void (*this_t)(int this_ ); #if defined(BOOST_MSVC) // for MSVC typedef boost::type_of::msvc_typeid_wrapper< sizeof(*boost::type_of::encode_start( #else // for GCC typedef __typeof__( boost::type_of::ensure_obj( #endif boost::scope_exit::aux::wrap( boost::scope_exit::aux::deref( this, (this_t)0 ) ) ) #if defined(BOOST_MSVC) // for MSVC )>::type #else // for GCC ) #endif this_w; } }; int main() { c cc; cc.f(); return 0; } I get this error on MSVC 2008 but the code compiles just fine on GCC: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. lf03.cpp using native typeof lf03.cpp(17) : error C2355: 'this' : can only be referenced inside non-static member functions lf03.cpp(22) : error C2955: 'boost::type_of::msvc_typeid_wrapper' : use of class template requires template argument list C:\Program Files\boost\boost_1_42\boost/typeof/msvc/typeof_impl.hpp(212) : see declaration of 'boost::type_of::msvc_typeid_wrapper' Thank you very much. -- Lorenzo

5 8

[filesystem] patch for PGI and largefiles
by Belcourt, K. Noel 01 Mar '11

01 Mar '11

Hi Beman, The attached patch enables large file support with the PGI compiler on 64 bit systems. It's been lightly tested and I'd like to commit this to trunk (as I'd really like to get this into the upcoming 1.46 patch release if possible). Okay to commit? -- Noel

2 1

Re: [boost] Boost and pkg-config support
by Vladimir Prus 01 Mar '11

01 Mar '11

On Tuesday, March 01, 2011 14:21:54 Roger Leigh wrote: > On Tue, Mar 01, 2011 at 11:08:14AM +0300, Vladimir Prus wrote: > > On Tuesday, March 01, 2011 10:52:35 Steve M. Robbins wrote: > > > On Tue, Mar 01, 2011 at 10:17:36AM +0300, Vladimir Prus wrote: > > > > Could you brief me on what's --as-needed, why is it needed, and why > > > > does it break a perfect model of "I link to shared library foo, and > > > > whatever dependecies are used automatically". > > > > > > The rationale (from http://wiki.debian.org/ToolChain/DSOLinking) > > > is to detect situations where > > > > > > your executable links against a library A which links against > > > library B, but your executable needs symbols in library B. This is > > > problematic in the situation where library A removes its > > > dependency to library B. The next time the executable gets rebuild > > > it will break and cannot be linked. > > > > <sarcasm>Oh, welcome to this new world where linking on Unix works just > > line in Windows</sarcasm> > > > > Seriously, though: > > > > 1. It appears --as-needed has nothing to do with this issue. It is > > --no-copy-dt-needed-entries that breaks things. > > Yes. This is the crux of the problem: in the absence of implicit > indirect linking, we are forced to explicitly link with every library > we need and we need some mechanism to inform us which ones to link > with. This is annoying, but as the link above details, there are good > reasons for doing this. > > > 2. I agree that pkg-config is the only possible solution. > > > > 3. I am not much of pkg-config expert; and Boost.Build's interpreted > > language is really not much harder than any of other languages present > > on Unix. So, the fastest way for this to be fixed is for me to sketch up > > Boost.Build code and then have somebody fill in the blanks and actually > > test it. > > If Boost.Build can be used to get the information to generate the > pkg-config .pc files, that would be great. If this can all be done > during the boost build, that would be even better. Out of interest, > where does Boost.Build get the information from, if not from > auto-link information? Is the information duplicated elsewhere? Well, gcc has no autolink, so for static linking to work, Boost.Build has to know that boost.filesystem depends on boost.system, and this information is directly present in boost.filesystem's Jamfile. > For the patch I mentioned in my initial mail, this just needs building > and running in a loop, such as (pseudocode) > > for (header+library name in each of boost's libraries) { > compile with PREFIX=prefix LIBDIR=libdir TEST_HEADER=header > TEST_LIBRARY=library link with all boost libraries > run to autogenerate header > library.pc (e.g. boost_program_options.pc) > } As you've mentioned yourself, this approach won't work very well for cross-compilation. Also -- we still get the question from the original issue -- what shall we do if building multiple variants together with decorated names? Use the same decoration for .pc files as we do for library files? - Volodya

1 0

Re: [boost] [Boost-users] [boost-users][ICL] ICL Compilation errors. Ticket #5207
by Joachim Faulhaber 01 Mar '11

01 Mar '11

Hi John, thanks again for all the questions. I am breaking up the long posting into smaller portions. (1) Representation of single elements with statically bounded intervals: 2011/2/23 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > On 22/02/11 20:03, Joachim Faulhaber wrote: >> >> 2011/2/22 John Reid<j.reid(a)mail.cryst.bbk.ac.uk> >>> >>> I have started to use statically bounded intervals >>> and am finding more compilation issues. For example >>> with finding elements in a map: >>> >>> #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS >>> #include<boost/icl/interval_map.hpp> >>> >>> void f() { >>> namespace icl = ::boost::icl; >>> icl::interval_map< float, int>().find( 0 ); >>> } >>> >>> This compiles without the #define but fails on static intervals. >> >> This is on purpose. The reason is that we can not represent a single >> element x using a right-open interval [x,?) of continuous values. >> right_open_interval is the default for statically bounded intervals, >> if BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS is defined. In order to use >> find on an interval_map we have to construct an interval that >> represents a single element (internally). This is not possible in the >> logic of the ICL so this code won't compile. > > Nevertheless, users will expect to be able to locate elements in sets. How > should they do this? they could use dynamically bounded intervals for continuous interval element types :P Moreover, if we work with floating point numbers, the code float pi = 3.14159 ... ; icl::interval_set<float> icl_float_set = ... ; icl::contains( icl_float_set, pi ); would be problematic anyway since pi can not be represented precisely. right_open_interval<float> pi_itv = interval_around_pi(); icl::contains( icl_float_set, interval_around_pi() ); // better > Does > icl::contains( icl::interval_set< int >(), 0 ); > compile, but > icl::contains( icl::interval_set< float >(), 0. ); > does not for the same reason? yes. I have mentioned in the docs, that 'continuous_interval' is the only class template that allows to represent a singleton interval that contains only one element, an have provided a small example here: http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface.… Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 5

Re: [boost] [config] help with pathscale-4.x
by Belcourt, Kenneth 01 Mar '11

01 Mar '11

On Feb 28, 2011, at 11:30 AM, Belcourt, Kenneth wrote: > > On Feb 28, 2011, at 11:17 AM, John Maddock wrote: > >>> Here's the updated output. >>> >>> the following macros need to be defined >>> BOOST_NO_FENV_H >> >> Are you able to tell why that test is failing (should be in the >> configure >> log somewhere)? >> >> BTW the results online show Pathscale passing the config tests even >> without >> that one set... it should surely be available on Linux whatever the >> compiler? > > configure:2198: checking fenv.h (pass expected) > configure:2231: /home/kbelco/ekopath/4.0.8/bin/pathCC -o conftest - > I./../.. -I./../../libs/config/test -g -O2 conftest.cpp -lrt -lm - > lpthread >&5 > In file included from conftest.cpp:21: > ./../../libs/config/test/boost_no_fenv_h.ipp: In function 'int > boost_no_fenv_h::test()': > ./../../libs/config/test/boost_no_fenv_h.ipp:64: error: invalid > conversion from 'int (*)()throw ()' to 'int (*)(fexcept_t*, int)' It looks like this is currently unsupported in this release of the compiler. I think we can safely ignore this issue for now. -- Noel

2 1