- Boost-users - lists.boost.org

boost::mpl::plus changes type
by Peter Foelsche 10 Apr '11

10 Apr '11

It is a major annoyance that these arrithmetic operations return a different type than the input! I mean I input boost::mpl::long_ and I get a boost::mpl::integral_c Peter

3 5

boost::mpl::abs missing
by Peter Foelsche 10 Apr '11

10 Apr '11

There is no boost::mpl::abs Peter

4 4

[network] cpp-netlib v0.9-beta out now!
by Dean Michael Berris 09 Apr '11

09 Apr '11

Hi Everyone, Apologies for the cross-post, but I just want to announce that after a couple months delay because of some outstanding bugs and TODO items that needed to get dealt with, I am now ready to package a 0.9 release and with that in mind I've just uploaded the 0.9-beta release of cpp-netlib. When the beta period (1 week) is over and all outstanding bugs are addressed, the 0.9 release will be the basis for submission for review to the Boost C++ Library. You can get the beta from: https://github.com/cpp-netlib/cpp-netlib/downloads What's New in 0.9 (taken from the documentation): - IMPORTANT BREAKING CHANGE: By default all compile-time heavy parser implementations are now compiled to external static libraries. In order to use cpp-netlib in header-only mode, users must define the preprocessor macro BOOST_NETWORK_NO_LIB before including any cpp-netlib header. This breaks code that relied on the version 0.8.x line where the library is strictly header-only. - More consistent message API for client and server messages (request and response objects). - Refactoring of internal implementations to allow better separation of concerns and more manageable coding/documentation. - Client and Server constructors that support Boost.Parameter named parameters. - Client and Server cosntructors now take in an optional reference to a Boost.Asio io_service to use internally. - Documentation updates to reflect new APIs. This Beta has been tested mainly on Linux (GCC 4.4, 4.5) and Mac OS X (10.6.7, Xcode 3.2.x w/ GCC 4.2.1) builds against Boost trunk and Boost 1.45. Note that cpp-netlib does NOT work with Boost 1.46.1 because of some breaking changes in the Boost.Spirit customization points have caused cpp-netlib to cease to play well with it. That said, the issues have been addressed in Boost trunk and should be fixed in Boost.147. Thanks to everyone who contributed to making this Beta possible, namely Emre Turkay, Oleg Malashenko, and other users that filed issues on the Github issue tracker. Have a good day everyone and I do look forward to feedback! -- Dean Michael Berris http://about.me/deanberris

1 0

[Interprocess] shared_ptr in a non-throwing mode
by Pietro Versari 09 Apr '11

09 Apr '11

Hi Ion (and everyone else), I'm a newbye and I have only one simple question: how can I construct a shared_ptr in a non-throwing mode? This example throw if there is enough space for MyType but isn't enough for my_shared_ptr: typedef managed_shared_ptr<MyType,managed_shared_memory>::type my_shared_ptr; my_shared_ptr sh_ptr = make_managed_shared_ptr( segment.construct<MyType>("object to share", std::nothrow)(), segment); Thanks, Pietro Versari

2 3

enable_if and multiple partial specializations
by Gennadiy Rozental 09 Apr '11

09 Apr '11

Hi, It's late and I might be missing something, but I can't figure out how can I use enable_if to disambiguate 2 partial specializations where one is subcase of another one: #include <boost/utility/enable_if.hpp> #include <boost/type_traits/is_enum.hpp> #include <boost/type_traits/is_scalar.hpp> #include <iostream> template<typename T, typename Enabler=void> struct M { static void foo() { std::cout << "generic" << std::endl; } }; template<typename T> struct M<T, typename boost::enable_if<boost::is_scalar<T> >::type> { static void foo() { std::cout << "scalar" << std::endl; } }; template<typename T> struct M<T,typename boost::enable_if<boost::is_enum<T> >::type> { static void foo() { std::cout << "enum" << std::endl; } }; struct S {}; enum FOO { FOO1, FOO2 }; int main() { M<S>::foo(); M<int>::foo(); M<FOO>::foo(); } --------------- M<FOO>::foo() fails to compile due to ambiguity. Any pointers? Or How to get what I want? Gennadiy

4 7

[multi_array] Is there interest for an [index_list] library?
by Pierre-Andre Noel 08 Apr '11

08 Apr '11

Dear all, I would like to gauge the interest of the community in a library that can serve 1) as a complement to Boost.MultiArray and 2) as an alternative to Boost.MultiArray. For the first type of use, an example of the candidate library's capabilities is that it makes available a special iterator "it" that allows to browse all the elements of a MultiArray "m". This special iterator has an it.indices() members that returns a "list" Collection of indices (i.e. an IndexList) such that "m(list)" and "*it" are the same elements. This can be useful for functions whose effect on an element of "m" depends on where this element is situated in "m". The second way to use the candidate library is as an alternative to Boost.MultiArray of dynamically chosen (execution time) dimensionality. Moreover, the elements do not necessarily need to be arranged in a multi-dimensional "box", as is the case in a MultiArray. For example, a "simplex" organization of the elements is already implemented. If you are interested to know more, I strongly suggest you to take a look at the example file in sandbox/index_list/libs/index_list/examples.cpp . The library itself is in sandbox/index_list/boost and a readme file (with some details concerning concepts and "priorities") is in sandbox/index_list/libs/README . An automatically generated (Doxygen) documentation is located in sandbox/index_list/libs/index_list/doc/index.html . Sadly, there is no "real" documentation for now. Many thanks for your time. Sincerely, Pierre-André Noël

2 1

[BGL] Accelerating property value-retrieval
by Cedric Laczny 08 Apr '11

08 Apr '11

Hi, I would like to know if there is a way to accelerate the retrieval of properties of an edge or a vertex? Actually, I define a new vertex-property (vertex_properties) and this again uses a "struct VertexProperties { ... }" to specify the details of the properties. However, when I want to get the properties of say vertex v, I need to first get the properties-map from the graph and then get the property for v. This obviously suffers from the lookup in the property_map and I would like to know if there is a way to accelerate this? In particular, when using vecS as the vertex_container because the vertices could generally be used as indices... I would find this very convenient, especially in combination with filtered_graph when filtering only on vertices that have certain properties (e.g. a category) and one only wants to see those that have a specific character (e.g. color). Best, Cedric

2 3

[ filesystem ] 1.45 broken on gcc 4.5 on AIX 5.3
by Avi Bahra 08 Apr '11

08 Apr '11

OK I realise AIX/gcc is not really a supported platform? But in boost 1.45 the file system causes a crash. My understanding was that at 1.45 the file system v2 was the default ? However looking at the stack trace it appears that at start up file system v3 make use of a static object to set the locale(), see file path.cpp namespace boost { namespace filesystem3 { const path::codecvt_type *& path::wchar_t_codecvt_facet() { static const std::codecvt<wchar_t, char, std::mbstate_t> * facet( &std::use_facet<std::codecvt<wchar_t, char, std::mbstate_t> > (path_locale())); return facet; } ..... path_locale() ends up calling default_locale(), which call's std::locale("") In std::locale() for some reason the locale can not be created and an exception is thrown. This exception has no chance of being caught since it called before main(). See the totalview trace back below: The work around appears to be to set the environment variable LANG to an empty string. Have not tested this on boost 1.46, but I suspect the same problem. Best regards, Avi ================================================================ .pthread_kill, FP=2ff20380 ._p_raise, FP=2ff203f0 .raise, FP=2ff20440 .abort, FP=2ff20490 uw_init_context_1, FP=2ff204f0 _Unwind_RaiseException, FP=2ff20a10 .__cxa_throw, FP=2ff21600 ._ZSt21__throw_runtime_errorPKc, FP=2ff21640 ._ZNSt6locale5facet18_S_create_c_localeERPiPKcS1_, FP=2ff216a0 ._ZNSt6locale5_ImplC2EPKcm, FP=2ff216e0 ._ZNSt6localeC2EPKc, FP=2ff21770 _ZN60_GLOBAL__N_libs_filesystem_v3_src_path.cpp_00000000_60BE389714default_localeEv, FP=2ff21800 _ZN60_GLOBAL__N_libs_filesystem_v3_src_path.cpp_00000000_60BE389711path_localeEv, FP=2ff21840 _ZN5boost11filesystem34path21wchar_t_codecvt_facetEv, FP=2ff21890 _ZN5boost11filesystem34path7codecvtEv, FP=2ff218e0 ..._cEERKT_PNS_9enable_ifINS0_11path_traits11is_pathableINS_5decayIS4_E4typeEEEvE4typeE, FP=2ff21920 _Z41__static_initialization_and_destruction_0ii, FP=2ff21980 _GLOBAL__I_65535_0__ZN5boost11filesystem34pathdVERKS1_, FP=2ff219c0 ._GLOBAL__FI_coretest, FP=2ff21a00 .__modinit, FP=200cde4c **** Frame below previous frame ********** .__modinit, FP=2ff21c20 .__start, FP=2ff21cb0

1 0

Building Boost using OS X 10.4 deployment target with 10.6 base SDK
by Brad Anderson 08 Apr '11

08 Apr '11

I upgraded to XCode 4 recently which only includes/supports the 10.6 SDK. While trying to build Boost 1.46.1 with a deployment target (macosx-version-min) of 10.4 I get a bjam error about 10.4 not being a valid option for macosx-version-min (the only valid option listed is 10.6). Perhaps I'm confused about something but I was under the impression that you could build using a newer base SDK than your target version. With XCode 3 I just used 10.4 as the base SDK and deployment target as that SDK is included and had no issues. I built wxWidgets fine using a 10.4 deployment target and 10.6 base SDK. Does anyone have experience with doing this in Boost? Regards, Brad Anderson

1 0

compiler crash in signals2?
by Noah Roberts 08 Apr '11

08 Apr '11

I get this error: 1>------ Build started: Project: barf, Configuration: Debug Win32 ------ 1> main.cpp 1> using native typeof 1>d:\boost-1.42.0-msvc10\boost-1.42-msvc10\include\boost\smart_ptr\shared_ptr.hpp(231): fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'msc1.cpp', line 1420) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1> Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> d:\boost-1.42.0-msvc10\boost-1.42-msvc10\include\boost\signals2\detail\signal_template.hpp(699) : while compiling class template member function 'boost::shared_ptr<T> boost::signals2::signal1<R,T1,Combiner,Group,GroupCompare,SlotFunction,ExtendedSlotFunction,Mutex>::lock_pimpl(void) const' 1> with 1> [ 1> T=void, 1> R=void, 1> T1=const esi::units::unit_settings &, 1> Combiner=boost::signals2::optional_last_value<void>, 1> Group=int, 1> GroupCompare=std::less<int>, 1> SlotFunction=boost::function<void (const esi::units::unit_settings &)>, 1> ExtendedSlotFunction=boost::function<void (const boost::signals2::connection &,const esi::units::unit_settings &)>, 1> Mutex=boost::signals2::mutex 1> ] 1> d:\boost-1.42.0-msvc10\boost-1.42-msvc10\include\boost\signals2\preprocessed_signal.hpp(42) : see reference to class template instantiation 'boost::signals2::signal1<R,T1,Combiner,Group,GroupCompare,SlotFunction,ExtendedSlotFunction,Mutex>' being compiled 1> with 1> [ 1> R=void, 1> T1=const esi::units::unit_settings &, 1> Combiner=boost::signals2::optional_last_value<void>, 1> Group=int, 1> GroupCompare=std::less<int>, 1> SlotFunction=boost::function<void (const esi::units::unit_settings &)>, 1> ExtendedSlotFunction=boost::function<void (const boost::signals2::connection &,const esi::units::unit_settings &)>, 1> Mutex=boost::signals2::mutex 1> ] 1> d:\dev_workspace\pfp_qt\experiment\build\include\esi\units\unit_settings.hpp(284) : see reference to class template instantiation 'boost::signals2::signal<Signature>' being compiled 1> with 1> [ 1> Signature=void (const esi::units::unit_settings &) 1> ] ========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ========== The version of boost I'm using is 1.42. I'm wondering if this problem has turned up before and if its got a fix. I'm not entirely convinced that it actually has anything to do with what it's claiming the cause is. I'm working on a library that does a lot of recursive template instantiations and behaves in a similar manner to fusion in many respects. Previous directions I went with this library already cause compiler crashes on a regular basis (2010 apparently doesn't do well with recursive calls to auto->decltype template functions). My library code could certainly use some cleaning up, but it's all legal C++ as far as I can tell. Also, this crash only happens when I try to use in conjunction with said library and only happens when the construct containing the signal is in a particular header file. If I move it to another and go ahead and include that one...everything works just fine. Obviously, this is VS's fault, not mine or boost's...but if there's a workaround/fix that's been made for this problem (assuming it is related to signals2 and comes up for other people) I'd like to be aware of it.

1 0