March 2012 - Boost - lists.preview.boost.org

Re: [boost] Boost.ntree_container (bi_tree, quad_tree, oct_tree, etc ptr containers) Is there any interest in this?
by pavel 11 Mar '12

11 Mar '12

Daniel wrote on Sunday, March 11, 2012 at 0:04:28: > That's not exactly a generic implementation, nor one that is STL-friendly > (e.g., no iterators). you are perfectly right but i believe that this implementation can be almost trivially integrated with a generic (read: template) interface besides, i hardly see a kd tree or an octree as a (associative) container -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out

1 0

[filesystem.v3] v1.49 Path constructor issue in VS Debug configuration
by Fraser Hutchison 11 Mar '12

11 Mar '12

Hello, The changes made to filesystem/v3/src/path.cpp between v1.48 and v1.49 seem to be causing a crash if I initialise a path as e.g. a global variable or as a static class member, but only for a Debug build. (I'm using VS10 on 64-bit Win 7). The following program exhibits this behaviour: |#include "boost/filesystem/v3/path.hpp" boost::filesystem::path p("p"); int main() { return 0; } | In Debug, I can see that the third path constructor calls |codecvt()|, which calls |wchar_t_codecvt_facet()|, which returns |codecvt_facet|. However, |codecvt_facet| hasn't been initialised at this point. This appears to only be the case for Debug builds though. I'm unclear as to whether this is an MSVC bug though. I thought that the Standard required |codecvt_facet| to have been initialised before |wchar_t_codecvt_facet()| since it comes earlier in the same translation unit. Could someone please clarify whether I should file a bug report with boost please? Thanks, Fraser.

2 2

[range] MFC/ATL select_first / select_second specializations for map_keys and map_values adaptors
by Adam Walling 11 Mar '12

11 Mar '12

I enjoy using the range library, and also foreach. When dealing with legacy code, the MFC / ATL range adaptors are wonderful. Unfortunately, the CMap and CMapStringToString iterators return CPair objects rather than std::pair, hence causing the select_first / select_second_mutable / select_second_const metafunctions to fail. I added these specializations to allow them to work with the map_keys and map_values adaptors. Hopefully they will be of use to someone in the future or adapted to be included with the other MFC / ATL code. Would it be worthwhile to format this as a patch to the library? namespace boost { namespace range_detail { // CMap and CMapStringToString range iterators return CPair, // which has a key and value member. Other MFC range iterators // already return adapted std::pair objects. This allows usage // of the map_keys and map_values range adaptors with CMap // and CMapStringToString // specialization for CMap template<class KEY, class ARG_KEY, class VALUE, class ARG_VALUE> struct select_first<CMap<KEY, ARG_KEY, VALUE, ARG_VALUE>> { typedef BOOST_DEDUCED_TYPENAME CMap<KEY, ARG_KEY, VALUE, ARG_VALUE> map_type; typedef BOOST_DEDUCED_TYPENAME range_reference<const map_type>::type argument_type; typedef BOOST_DEDUCED_TYPENAME const KEY& result_type; result_type operator()( argument_type r ) const { return r.key; } }; template<class KEY, class ARG_KEY, class VALUE, class ARG_VALUE> struct select_second_mutable<CMap<KEY, ARG_KEY, VALUE, ARG_VALUE>> { typedef BOOST_DEDUCED_TYPENAME CMap<KEY, ARG_KEY, VALUE, ARG_VALUE> map_type; typedef BOOST_DEDUCED_TYPENAME range_reference<map_type>::type argument_type; typedef BOOST_DEDUCED_TYPENAME VALUE& result_type; result_type operator()( argument_type r ) const { return r.value; } }; template<class KEY, class ARG_KEY, class VALUE, class ARG_VALUE> struct select_second_const<CMap<KEY, ARG_KEY, VALUE, ARG_VALUE>> { typedef BOOST_DEDUCED_TYPENAME CMap<KEY, ARG_KEY, VALUE, ARG_VALUE> map_type; typedef BOOST_DEDUCED_TYPENAME range_reference<const map_type>::type argument_type; typedef BOOST_DEDUCED_TYPENAME const VALUE& result_type; result_type operator()( argument_type r ) const { return r.value; } }; // specialization for CMapStringToString template<> struct select_first<CMapStringToString> { typedef range_reference<const CMapStringToString>::type argument_type; typedef const CString& result_type; result_type operator()( argument_type r ) const { return r.key; } }; template<> struct select_second_mutable<CMapStringToString> { typedef range_reference<CMapStringToString>::type argument_type; typedef CString& result_type; result_type operator()( argument_type r ) const { return r.value; } }; template<> struct select_second_const<CMapStringToString> { typedef range_reference<const CMapStringToString>::type argument_type; typedef const CString& result_type; result_type operator()( argument_type r ) const { return r.value; } }; } } -- - Adam D. Walling

1 0

[Config] Meaning of BOOST_NO_CXX11_HDR_INITIALIZER_LIST
by Michel Morin 10 Mar '12

10 Mar '12

I noticed that BOOST_NO_INITIALIZER_LISTS was replaced by BOOST_NO_CXX11_HDR_INITIALIZER_LIST recently. I have a question related to this change: Does BOOST_NO_CXX11_HDR_INITIALIZER_LIST imply that initializer lists are supported by the compiler? (I guess that the compiler support is checked in a compiler config and the existence of <initializer_list> is checked in a std lib config.) If so, shouldn't the documentation be updated? Regards, Michel

4 17

Boost trunk on Solaris 10 sparc
by Maciej (Matchek) Bliziński 09 Mar '12

09 Mar '12

Hello, I've made an attempt to build Boost from subversion trunk on Solaris 10 on sparc, with gcc-4.6.2. The build didn't succeed, and I'll be looking into ways to make it pass. I've recorded the build in log file which includes all the setup: http://buildfarm.opencsw.org/~maciej/boost-2012-02-29-09-51.log Some highlights: error: No best alternative for libs/context/build/asm_context_sources var/tmp//ccU7e2QF.s: Assembler messages: /var/tmp//ccU7e2QF.s:401: Error: Architecture mismatch on "cas". /var/tmp//ccU7e2QF.s:401: (Requires v9|v9a|v9b; requested architecture is v8.) /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/include-fixed/sys/feature_tests.h:341:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" In file included from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/bits/postypes.h:42:0, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/iosfwd:42, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/ios:39, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/ostream:40, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/iterator:64, from ./boost/next_prior.hpp:15, from ./boost/utility.hpp:17, from ./boost/python/instance_holder.hpp:10, from ./boost/python/object/pointer_holder.hpp:14, from ./boost/python/to_python_indirect.hpp:10, from ./boost/python/converter/arg_to_python.hpp:10, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object/enum_base.hpp:8, from libs/python/src/object/enum.cpp:6: There were a couple of other errors, they are in the log file. What the current status of Solaris builds? Is there anyone else building Boost on Solaris 10? Are any of the problems that are in the log file know and possible to work around? Maciej

5 10

Re: [boost] Is there interest in a reusable stream-based console?
by Michael Hava 09 Mar '12

09 Mar '12

> I am interested in your library and seeing it become a part of Boost, > however I agree that history, search, auto-complete, etc being integrated > into the library would be key to making it a more useful addition. I'll look into that… > I can understand the header-only motivation, but have you considered > using SWIG (http://www.swig.org/) to wrap you C++ in your favorite > scripting language and then simply re-using the interactive shell > provided by that language? Honestly not, as providing a way to interop with a scripting language was not part of the original idea… (I'm not even that much a fan of scripting languages…) > (example: http://www.youtube.com/watch?v=VHFu6q1twtE ) Looks nice, but it seems you focused far more on the "programming language aspect" than my original design was. You see I developed my first design based on experience in a product I'm working on in my job, where we offer a console in addition to the GUI for faster input. That console is deeply integrated into the program and was never really designed from the ground up to be reusable… > About the interface, I'm not sure if a command should be defined only by a > simple std::function. I've tried it before but I > wasn't able to make it work as more information were required. Maybe I should have explained that a bit more: the command-class uses a std::function internally to store the callback that's to be executed, it's not a std::function.

2 1

Re: [boost] Is there interest in a reusable stream-based console?
by Michael Hava 09 Mar '12

09 Mar '12

@Julien: I haven't looked into boost::program_options yet, though I don't see a problem in integrating the current design in anything as it's merely a class that reads from a std::basic_istream and writes to a std::basic_ostream whilst calling registered callbacks based on the input… The parameters are currently instances of std::basic_string which are passed to the callback which can than operate on these parameters. On the list of commands thing: I thought about that for a while now and would say that something like Lua would be a perfect solution to be combined with the current design to allow that flexible scripting… @Artyom: I've never before heard about GNU Readline; does that mean that consoles like bash don't offer such a functionality to programs automatically (something that even cmd.exe does)? "Help" is meant to be a short help text on the command, similar to a man-page…

5 5

Is there interest in a reusable stream-based console?
by Michael Hava 09 Mar '12

09 Mar '12

I’ve recently started to design a header-only reusable console-class that’s based on std::iostream. It can be customized by adding a variable amount of “commands”. The implementation is currently based on std::stream and may support any compatible stream as input and output. A typical example of usage would be (excluding namespaces): console c(console::case_sensitive);//create case-sensitive console, that reads commands from std::cin and outputs to std::cout and std::cerr c += command(“Name of command”, “Description of command”, “Extended information on parameters of command”, function);//add command to console, whereas function is a std::function c();//execute console; console is executed until function to stop is called Is there any interest in adding such a library to boost? greetz Michael

4 3

[Config] Patch: clang implemented N3276 decltype
by Michel Morin 08 Mar '12

08 Mar '12

Clang implemented N3276 decltype (which does not require type-completeness of a function call expression) Attached a patch for boost/config/compiler/clang.hpp. BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name? Regards, Michel

5 13

workarounf for missing uintptr_t on PGI?
by Oliver Kowalke 08 Mar '12

08 Mar '12

Hi, the PGI compiler (pgi- 11.9) seams not to support intptr_t and uninptr_t. Does boost provide a workaround I'm not aware of? Is the PGI compiler relevant (== does it matter if unit-test fails for PGI but pass GCC, MSVC, INTEL)? Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

2 4