- Boost - lists.boost.org

boost filesystem path as utf-8 revisited
by Rush Manbert 15 Nov '12

15 Nov '12

In the original thread, I found this reply by Beman: ----------------- > > > How exactly do I imbue UTF-8 codecvt in a path? I Googled around and > couldn't find anything. There are two approaches: * If you always want all class path arguments and returned values with a value type of char to be treated as being UTF-8 encoded, and aren't worried about changing a potentially dangerous global, then do this: #include <boost/filesystem/detail/utf8_codecvt_facet.hpp> ... std::locale global_loc = std::locale(); std::locale loc(global_loc, new boost::filesystem::detail::utf8_codecvt_facet); boost::filesystem::path::imbue(loc); ----------------- I do want what is described and would like to use this approach, but we use boost::filesystem all over the place and in our code we never do any sort of "global initialization", so I'm trying to figure out how to get the code snippet executed. I can see two ways to approach this: 1) Add this code snippet to the boost::filesystem::path constructor. But is it too late then? 2) Define a class whose only purpose is to execute this code when it is constructed and arrange to have a static singleton instance of the class defined. In one of our libraries we need to be very careful about static class construction order, so this may be difficult. I haven't dealt with this sort of issue in quite a while and I may be a little rusty. Any suggestions? Are there new goodies in C++ that might help me? Thanks, Rush

3 3

program_options::store() interface extension
by ST 15 Nov '12

15 Nov '12

Hi, I need to supply to my app a config file with following entries: item1 = 123 item2 = 435 item3 = 345 ... itemN = 562 where N is not known in advance, so there is no way to register such options. The only way to deal with them is to pass them as unregistered options and then use collect_unrecognized(). But then dealing with a vector<string> is not quit convenient. My suggestion is to add an a storeUnregistered flag to the store() function which will be false by default, but if set to true, will store all unregistered options with their values as strings. It will be possible then to check whether an item was provided like this: vm.count("item1") and cast its value like this: vm["item1"].as<int>() . Or is there already a good way to do what I need? Thank you in advance, ST

2 1

Re: [boost] [container] container_detail::pair piecewise constructor
by László Szécsi 15 Nov '12

15 Nov '12

I did some more research and it turns out std-style piecewise construction fails with VS2012 Nov CTP compiler, just like my attempt at adding piecewise construction to boost::container_detail::pair. In particular, the following dummy code compiles under g++ 4.7.1 but not under VS2012 Nov CTP. class Foo { public: template <class... Args1, class... Args2> Foo( const ::std::piecewise_construct_t, ::std::tuple<Args1...> first_args, ::std::tuple<Args2...> second_args) { } }; int main(){ Foo s( std::piecewise_construct, std::move( std::make_tuple(30) ), std::move( std::make_tuple(50) )); } I guess the time is not ripe for the container implementation to use true variadic templates yet. Is there ongoing effort to implement container_detail::pair's piecewise constructor in the same way as it was implemented in boost::unordered? Best regards, Laszlo Szecsi

1 0

[optional] Support for moving values
by Adam Badura 14 Nov '12

14 Nov '12

Are there any plans to add support for move constructors and assignment operators? I noticed that many Boost libraries miss that support. And it is especially "visible" in case of such utilities like boost::optional or boost::variant. Adam Badura

2 1

Boost 1.52.0 released!
by Marshall Clow 14 Nov '12

14 Nov '12

Release 1.52.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_52_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.52.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

9 11

[optional] Types without assignment operator
by Adam Badura 14 Nov '12

14 Nov '12

I use boost::optional for deferred construction. Something similar to the idea described in "Bypassing expensive unnecessary default construction" in Boost.Optional documentation. Only in my case I do this because the mentioned construction requires virtual function calls and this cannot be done in owning object constructor and has to be postponed. So instead of accessing the object directly I always access it by a function. That function first checks if the object is already constructed (boost::optional is initialized) and if so just returns it. Otherwise it first constructs it. That approach requires only copy construction (or even move construction if boost::optional would support moving in the first place). Yet due to implementation details the embedded type has to be assignable as well. Even thou assignment operator will never be called (in this scenario). Is there a way to avoid this issue? If not then how about adding a function like "assign" (possibly named otherwise or with additional defaulting argument) which could assign by first destroying old object (if any) and then copy/move constructing a new one. This would obviously be bad from exception safety (guarantees) point of view, but well... don't call the function if you don't like that. And in scenarios like mine it would not be an issue since there would be no object to destroy anyway. (Also the function could assert/throw on that condition...) Now the Synopsis part of the Boost.Optional documentation does mention (Typed)InPlaceFactory assign operators which do look promising for solving this issue. But firstly they are not documented in following Detailed Semantics part. There is even no link in the Synopsis. (Is this docs bug? In which part? Missing docs or extra functions?) And secondly (Typed)InPlaceFactory support is "intrusive". I cannot add it to a class without changing the class itself. And in my case I cannot change the class (boost::program_options::options_description - why cannot it be copy assigned, that I don't know...). Maybe adding some extra wrapper would help but I don't think it would be a solution. Rather a somewhat ugly workaround. Adam Badura

3 8

Possible submission: Expanded std::bind compatible with std::move
by スマートアシュリー 14 Nov '12

14 Nov '12

I noticed that std::bind inst compatible with std::move.. I created a workaround for it in c++11 here. I would like to see it added to boost if thats ok. Please review my code... and let me know if its a viable candidate to be added to boost and what code changes are need before that. http://code-slim-jim.blogspot.jp/2012/11/perfect-forwarding-bind-compatable…

2 1

[type_erasure] issue when taking any<> by const ref
by Thomas Petit 13 Nov '12

13 Nov '12

Hi, I'm playing with the boost type erasure library (from the sandbox) and hit some issues. Imagine that I have an any accepting some concept : > typedef any<concept1<>, concept2<>> some_any_t; and a std::vector to put a few any in it : > std::vector<some_any_t> v; Then If I iterate over the vector by taking each element by reference >for(some_any_t& : v) >{ >} everything is fine and consistent with why I expect. However if I iterate by taking element by const ref >for(const some_any_t& : v) >{ >} then some issue appears. Here is an example showing the problems (with one any using a concept defined by BOOST_TYPE_ERASURE_FREE and one any using a concept defined by BOOST_TYPE_ERASURE_MEMBER) ................................................... #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/operators.hpp> #include <boost/type_erasure/free.hpp> #include <boost/type_erasure/member.hpp> namespace mpl = boost::mpl; namespace te = boost::type_erasure; template <typename T> void free(const T& t) { std::cout << typeid(t).name() << std::endl; std::cout << "default free\n"; } void free(const int& i) { std::cout << typeid(i).name() << std::endl; std::cout << "int\n"; } BOOST_TYPE_ERASURE_FREE((has_free), free, 1); template<class T = te::_self> struct free_concept : mpl::vector<has_free<void(const T&)> > {}; typedef te::any<mpl::vector<te::copy_constructible<>, free_concept<>>> any_free_t; struct Base { virtual void member() const { std::cout << "Base member\n"; } }; struct Derived : public Base { virtual void member() const { std::cout << "Derived member\n"; } }; BOOST_TYPE_ERASURE_MEMBER((has_member), member, 0) struct member_concept : mpl::vector<has_member<void()> > {}; typedef te::any<mpl::vector<te::copy_constructible<>, member_concept>> any_member_t; int main() { any_free_t af1(5); any_free_t af2(5.0); std::vector<any_free_t> v; v.push_back(af1); v.push_back(af2); for(any_free_t& af : v) { free(af); } Base b; Derived d; std::vector<any_member_t> v2; v2.push_back(b); v2.push_back(d); for(any_member_t& am : v2) { am .member(); } } ....................................................... In the previous code, if add a const here : for(const any_free_t& af : v) { free(af); } then instead of calling the int overload of the free function and the template overload with a double type, the templated free function is called both time but, unfortunately the type of T is always the same as the any. Another point, if I add a const here : for(const any_member_t& am : v2) { am .member(); } then I get a compile error. (with visual 2012 and gcc 4.7) I'm a bit puzzled by this behavior. Are any<> types never supposed to be taken by const ref ? How can we iterate over anys while preserving constness ? Thanks. Thomas.

2 2

boost threads and linking boost statically into a DLL
by Carlos Empujon 13 Nov '12

13 Nov '12

Recently I had some trouble to linking boost statically into a DLL. After searching around I found that there has been a discussion on http://boost.2283326.n4.nabble.com/Fwd-Thread-Solution-to-conflict-with-MFC… However it seems that the patch proposed there (see below) did not make it into the trunk. Has there been a special reason why this has not been included into the normal distribution? Cheers, Carlos /** * tss.cpp * * This file is intended to correctly build a dll using boost::thread * It is taken from * * http://boost.2283326.n4.nabble.com/Fwd-Thread-Solution-to-conflict-with-MFC… * * $Id$ */ #include <windows.h> #include <boost/thread/detail/tss_hooks.hpp> extern "C" BOOL WINAPI RawDllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID); namespace { BOOL WINAPI dll_callback(HANDLE h, DWORD dwReason, LPVOID p) { #ifdef _DLL if(!RawDllMain(static_cast<HINSTANCE>(h),dwReason,p)) return false; #endif // _DLL switch (dwReason) { case DLL_THREAD_DETACH: boost::on_thread_exit(); break; case DLL_PROCESS_DETACH: boost::on_process_exit(); break; } return true; } } extern "C" { extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback; } namespace boost { void tss_cleanup_implemented() {} }

1 0

Release branch now open for merging
by Marshall Clow 12 Nov '12

12 Nov '12

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

1 0