- Boost - lists.boost.org

[sandbox.move] coexistence issues with boost.interprocess + small suggestion
by Jeffrey Hellrung 09 Jul '09

09 Jul '09

Hi, I suppose this is mostly addressed to Ion. It appears that containers in the move library in the boost sandbox can't coexist with containers from the boost.interprocess library. This isn't a problem for me currently (I can just use the containers from the move library), but it may be an indication of a larger problem with either or both libraries, so I figured it'd be worth sharing. I wasn't sure if this would be an appropriate trac ticket to file under boost.interprocess, as it involves technically non-boost code, but I can certainly do that if desired. So to be specific, the following program fails to compile (MSVC 2009, boost 1.39, include paths are boost root and $(BOOST_SVN)/boost-sandbox/move): -------- #include <boost/interprocess/containers/vector.hpp> #include <boost/container/vector.hpp> int main(int argc, char* argv[]) { boost::interprocess::vector< int > v1; // line 6 boost::container::vector< int > v2; // line 7 return 0; } -------- The compiler output is: -------- 1>.\main.cpp(7) : error C3083: 'container': the symbol to the left of a '::' must be a type 1>.\main.cpp(7) : error C2039: 'vector' : is not a member of 'boost' 1>.\main.cpp(7) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(7) : error C2062: type 'int' unexpected -------- Removing either the interprocess vector (include directive, variable declaration) pair or the move vector (include directive, variable declaration) pair produces a compilable program. Reversing the order of the include directives gives a different compiler error: -------- 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C3083: 'interprocess_container': the symbol to the left of a '::' must be a type 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2039: 'vector' : is not a member of 'boost' 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2873: 'vector' : symbol cannot be used in a using-declaration 1>.\main.cpp(6) : error C2039: 'vector' : is not a member of 'boost::interprocess' 1>.\main.cpp(6) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(6) : error C2062: type 'int' unexpected -------- Any idea what's going on here? Am I just doing something really boneheaded, e.g., with the include paths? Additionally, I have a small suggestion for the move library. It would be somewhat more convenient if boost::is_movable<T> had a nested type typedef, e.g., if it inherited from mpl::bool_<...> or integral_constant< bool, ...>. As it stands, I don't think it can be used directly in MPL expressions such as mpl::and_. Thanks in advance, - Jeff

2 1

[Tuple] Addressing by named tag?
by Robert Jones 09 Jul '09

09 Jul '09

Am I correct in believing that tuples have to be accessed by element index, as in tuple.get<0>() Multi-Index container has a really nice facility to use named (well typed really) tags in these kind of expressions, but it seems tuples do not. Anyone fancy adding it to tuple? - Rob.

2 1

[convert] coversion between strings with different locales
by vicente.botet 09 Jul '09

09 Jul '09

Hi, I wanted to see how we can convert a double from a locale to another locale? Should I write double d =convert<string>::from(convert<double>::from(str)(_locale=f))(_locale=t); or I need double d = convert<double>::from(str)(_locale=f); convert<string>::from(d)(_locale=d); Or it si a better way? Best, _____________________ Vicente Juan Botet Escribá

2 3

[multi_array] Can only disable range checking by defining BOOST_DISABLE_ASSERTS macro
by John Reid 08 Jul '09

08 Jul '09

Defining BOOST_DISABLE_ASSERTS disables boost asserts over the entire compilation. It would be nice to have finer grained control over the range checking in multi_array via a boost.multi_array specific macro.

1 1

[Graph] component_index crash on big graph
by Sandeep Gupta 08 Jul '09

08 Jul '09

Hi, I am using the incremental connected component + component_index to find connected components in an undirected graph. However the program works fine on small small dataset but segfaults on large input. I tried to do some debugging and the best I could come up was that it fails on array_push_front cal at the boost/graph/detail/incremental_component.hpp:78. I have attached the source code and the accompanying small files that contain edgelist. The TrivialEdges.txt works fine but on ManyEdges.txt* the program segfaults. To the best of my understanding the input is sane. Would appreciate any help. * ManyEdges.txt is 320K so please download it from (* http://tinyurl.com/m9blyy) * THis is the dataset I stumbled upon. I apologies for not being able to trim down to smaller size. thanks sandeep

3 7

Universal user interface based only on C++ standard libraries
by Jonathan Enders 07 Jul '09

07 Jul '09

One feature I am always missing when programming in a non-interpreted language like C is the ability to interactively execute the program without writing an entire mechanism for that. This "interpreted when typed"-feature proves itself very useful in python for instance. Although it might be too hard if not impossible to make a "compiled and executed when typed"-feature for C it is possible to just give the user the ability to access a huge amount of the functionality of let's say an object. It's just a lot of work to make all the properties accessible and you might blemish the looks of your actually ui-independent class. A workaround can be applied to lessen the damage. It would consist of just a single function that the class has to implement. That function exports all the functionality (options) to a ui-system which takes care of the command handling and user interaction. This works to the point that it can actually completely replace the ui-design-process (well the ui-system still has to be initialized, 3 lines of code). The work to make the C++ standard library ui-accessible could be taken from the user in advance. As I don't know if any of that is of any relevance to the boost community I will leave it at that. It just seems like a big lack to me that the boost-libraries still have no means of user interaction. If there is any interest in the above I have a working sample which demonstrates what words can only poorly describe. Thanks

8 7

[config] polygon library long long, long double portability
by Simonson, Lucanus J 07 Jul '09

07 Jul '09

I use long long and long double in the configuration of my integer arithmetic traits. I'd like to guard those usages with boost macros to allow the code to compile on platforms that don't support long long and long double (replace with long and double respectively) but I can only find a BOOST_HAS_LONG_LONG macro (which is apparently not documented) and not a corresponding BOOST_HAS_LONG_DOUBLE. Is there some other macro I can use to detect BOOST_HAS_LONG_DOUBLE or a typedef I can use that is already set to long double if available and double otherwise? Thanks, Luke

9 31

[Config] Boost config, long long in xlc 10.1
by Ioannis Papadopoulos 07 Jul '09

07 Jul '09

Hi, 1. I see in config/compiler/vacpp.hpp that versions over 6 are not supported when BOOST_ASSERT_CONFIG is defined: #if (__IBMCPP_ > 600) # if defined(BOOST_ASSERT_CONFIG) # error "Unknown compiler version - please run the configure tests and report the results" # endif #endif Still Boost compiles fine with 10.1, so maybe the number should be changed to 1010, unless there is some other reason that I'm missing. 2. long long is supported through a flag, -qlonglong which also defines _LONG_LONG to be 1. As far as I understand this is not taken into account. Thanks!

2 2

[algorithm] - defect due to accidental ADL
by Neil Groves 07 Jul '09

07 Jul '09

Hello, I have been investigating an issue reported by a user of the RangeEx library proposal. The conclusion was that boost/algorithm/find.hpp suffers from accidental ADL. This was confirmed by protecting against accidental ADL in this file and the user confirming that this solved their problem. Would it be useful to the current maintainer if I went through the source code and fixed similar issues? I would be happy to provide the files for the maintainer to commit. Alternatively is it possible to have agreement and then write access to the repository to fix this problem? Thank you in anticipation, Neil Groves

2 1

[Boost-serialization] Missing file
by K. Noel Belcourt 07 Jul '09

07 Jul '09

Hi, It looks like trunk tests are failing with this error. error: Unable to find file or target named error: 'test_shared_ptr_multi_base.cpp' error: referred from project at error: '../libs/serialization/test' -- Noel

1 0