- Boost-users - lists.boost.org

compilation problems on spirit::karma
by Erik Thiele 24 Sep '12

24 Sep '12

Hello in the attachment there is a single c++ file. on debian squeeze with g++ (Debian 4.4.5-8) 4.4.5 it compiles. debian standard libboost1.42-dev is installed. if you run the program: erik@ludwig:~/allesfresser/karma_problem$ ./a.out ruleSetModal(subCall(projectMemberIdentifier(siemensAltNumber=100, fanucNumber=0, name=)) erik@ludwig:~/allesfresser/karma_problem$ that's the required behaviour. now on new system with g++ (Debian 4.7.1-7) 4.7.1, and libboost1.49-dev, it does not compile. a short excerpt of the enormously long chain of error message: problem.cpp:254:5: required from ‘astGenerate<OutputIterator>::astGenerate() [with OutputIterator = std::back_insert_iterator<std::basic_string<char> >]’ problem.cpp:307:56: required from here /usr/include/boost/spirit/home/support/attributes.hpp:519:28: error: cannot convert ‘const boost::variant<astProjectMemberIdentifier, astErikNcBohrPlanSenk>’ to ‘boost::spirit::traits::attribute_size<boost::optional<boost::variant<astProjectMemberIdentifier, astErikNcBohrPlanSenk> >, void>::type {aka unsigned int}’ in return if you remove the rule in line 254 (ruleSetModal = "ruleSetModal(" << -ruleSubCall << ')';), then the program will compile. but it will output nothing of course. i need this line. it worked all the times and now after update it does not work. honestly i do not understand the long chain of error message. i checked with boost 1_51_1 with the same not working result. also with clang++ compiler it does not work with the same error message. maybe someone on the list can enlighten me why this does not compile anymore. Thanks Erik

2 2

[graph][heap][coroutine] interruptable dijkstra shortest path function
by Alex Hagen-Zanker 23 Sep '12

23 Sep '12

Hi, A few months ago I posted here to gauge interest for an interruptable and resumable version of the dijkstra_shortest_path algorithm. The initial response was positive, but Jeremiah considered the proposed solution lacking compared to an algorithm object model that inverts the control over the algorithm, Additional to my original solution, I now have two implementations of the algorithm object model. 1. Visitor based interruption. This is my original approach. It separates the algorithm into an init and main function. The main function asks the visitor if it should be halted afer each iteration. After halting, the main function can be used to resume the calculation. auto dijkstra = make_dijkstra_object(graph, named_parameters); dijkstra.init_from_sources(sources); dijkstra.expand( interruptor); dijkstra.expand( other_interruptor); auto distance_map = dijkstra.get<vertex_distance_t>(); auto color_map = dijkstra.get<vertex_color_t>(); 2. Algorithm object implementation. This was suggested by Jeremiah. The algorithm object iterates from control point to control point in the algorithm. Giving at each stop access to the intermediate results of the algorithm. The two implementations are a) Using the [Coroutine] library that is currently under review to step in and out of the function. b) Fragmenting the function into many subfunctions that are chained together and the other works by fragmenting the original algorithm into a number of small interlinked functions starting at one control point and returning at the next. The interface of a and b is exactly the same and it works like this: auto dijkstra = make_dijkstra_object(graph, sources, named_parameters); while(dijkstra.next() ) { control_point cp = dijkstra.get_control_point(); vertex u = dijkstra.get_u(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(cp == cp_finish_vertex && get(distance_map, u) > 42) { cout << "far enough" << endl; break; } } auto distance_map = dijkstra.get<vertex_distance_t>(); The algorithm object offers most flexibility for interweaving multiple searches. The visitor based solution on the other hand is more efficient. The latter has no loss in performance compared to the existing dijkstra functions. The coroutine algorithm object was extremely easy to implement but it is not very efficient. Does anybody have a suggestion how that can improve? Besides these interruptable and resumable shortest path searches, there are a few more advantages to the implementation. a. All dijkstra parameters are bundled in a light-weight dijkstra_state object that is returned by algorithms, giving direct access to all results of the algorithm, for instance: auto dijkstra_state = dijkstra_shortest_paths(graph, sources, no_named_parameters() ); auto distance_map = dijkstra_state.get<vertex_distance_t>(); b. Named parameters (old style) are also used for the priority queue and the color map c. Boost.Heap mutable queues can be used with Boost.Graph via the named parameter interface. It doesn't help performance now, but may be a good base for experimentation. d. Separation of the dijkstra shortest path algorithm in init and main function makes it easier to provide custom initialization. For instance: multiple sources or only re-initializing changed vertices Can anybody use this? The latest version is here: http://people.pwf.cam.ac.uk/ahh34/dijkstra.zip Kind regards, Alex p.s. below are timings for a large graph: bimba_6M.obj... 2090 ms. Boost Graph Library 2121 ms. With interruption visitor 5601 ms. With Coroutine(*) 2621 ms. With fragmented functions (*) 2840 ms. With Boost.Heap (*) halting at all control points of the dijkstra visitor

1 0

transform_iterator and c++11 lambda expression
by MM 22 Sep '12

22 Sep '12

hello it would be great to be pass transform_iterator( my_iterator, []( reference ) { return /// something } ); directly to STL algorithms. Currently, one needs to define separately the unarfy function as far as i could see MM

3 2

[Interprocess] Different shared memory locations in Windows
by Aaron_Wright＠selinc.com 21 Sep '12

21 Sep '12

I'm attempting to share memory between two services on a Windows Server 2008 Core box. One service is postgres running as a user created just for that purpose, and the other service is my application running as the Local System user. The issue I'm seeing is that it seems that the two services do not agree on the location of the shared memory files. The postgres service is looking at "C:\Users\<user>\AppData\Local\Temp\boost_interprocess", while my application is looking at "C:\Windows\TEMP". Diving into the code I found that it first tries to use the value of a registry key, "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData", however this key doesn't exist in Windows Server 2008 R2 Core, presumably because there is no explorer.exe running on the box, and thus, no shell folders under it. When that fails, the code attempts to use the TMP environment variable, however that is dependent upon the environment that the user has setup, so the TMP variable is not guaranteed to be the same across users. Indeed in my case the TMP variable for the Local System user was "C:\Windows\TEMP", while the TMP variable for the other user was in its user folder. I'm not sure what the correct answer here is, but I have some ideas: -- The "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Common AppData" registry key seems to exist for Windows XP, Windows Server 2008 R2 Core, and Windows 7. And according to TechNet, "The entries that appear in user User Shell Folders take precedence over those in Shell Folders." So maybe that registry key should be used instead. -- Use the ALLUSERESPROFILE variable, which is "C:\Documents and Settings\All Users" on Windows XP, and "C:\ProgramData" on Windows Server 2008 R2 Core and Windows 7. The TMP variable seems to be different for every user. -- Provide a way to tell the library what directory to use. (This doesn't exist does it?) Or hint at what library to use. -- Can/Should the code assert when the folder chosen contains a user name. Might be impracticable, but sure helpful. --- Aaron Wright

3 2

Re: [Boost-users] chaining functions input output
by MM 21 Sep '12

21 Sep '12

great, this is not blocking in my case, as I have written a 3rd function that merges the implementation of the 2 functions that are provided to me with matching results, and therefore avoiding the need for intermediate storage. I can move to your solution in a few months there are 10million entries so it's worth the trouble thanks

1 0

[Multi-Array] Coercion to multi_array_ref from array_view?
by Jason Sewall 21 Sep '12

21 Sep '12

I'd like to have functions that can be passed references to arrays of a given storage type and rank. Take a look at the following code: template <class A> void foo_duck(A ma) { ma[0][1] = 1.0; } typedef boost::multi_array_ref<double, 2> ref_array_2d; void foo_ref(ref_array_2d ma) { ma[0][1] = 1.0; } int main() { typedef boost::multi_array<double, 3> array_3d; typedef boost::multi_array_types::index_range range; array_3d A(boost::extents[3][4][4]); array_3d::array_view<2>::type slice = A[boost::indices[1][range()][range()]]; foo_duck(slice); foo_ref(slice); return 0; } foo_duck works fine, but foo_ref does not; I get a compiler error (gcc 4.6.3, boost 1.47) like so: "error: could not convert ‘slice’ from ‘boost::multi_array<double, 3ul>::array_view<2ul>::type {aka boost::detail::multi_array::multi_array_view<double, 2ul>}’ to ‘ref_array_2d {aka boost::multi_array_ref<double, 2ul>}’" I suspect, without having looked at the code itself, that multi_array_ref was never designed to be coerced from array_view, but I don't understand why. Is there a solution to my foo_ref problem that doesn't involve moving all such functions to headers and templating them? Cheers, Jason

3 2

[Context] Building 32-bit Context?
by Nat Linden 21 Sep '12

21 Sep '12

Our product uses many third-party libraries, all built for 32 bits. On a couple platforms we still support users with 32-bit systems. We build our Boost libraries with address-model=32, which has so far worked (for the subset of libraries we use) even on 64-bit build systems. Now we would like to introduce Boost.Context. However, address-model=32 --with-context causes the Boost build to break on Mac OS X. Indeed, the Requirements page [0] for Boost.Context says: "Please note that address-model=64 must be given to bjam command line on 64bit Windows (boost-build issue)." Does the same boost-build issue affect Mac OS X? Is there a workaround for this boost-build issue? I don't think we can integrate Boost.Context any time soon if it would require converting everything to 64 bits. [0] http://www.boost.org/doc/libs/1_51_0/libs/context/doc/html/context/requirem…

2 9

Xcode 4.5 and boost 1.51.0 semantic issues with implicit conversions long to int
by Graham Reitz 20 Sep '12

20 Sep '12

Recently upgraded to Xcode 4.5 and boost 1.51 and started getting a pile of: /Users/grahamreitz/Development/src/libs/boost_1_51_0/boost/asio/detail/impl/socket_ops.ipp:952:20: Implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' ...warnings I'm guessing this is a 64 bit/32 bit issue. Should I be seeing these warnings out of the box?

1 0

[boost.org] Getting Started list of built libraries
by Nat Linden 20 Sep '12

20 Sep '12

Both Getting Started pages [0], [1] list libraries that must be built separately. With Boost 1.51, Boost.Context should be added to those lists. [0] http://www.boost.org/doc/libs/1_51_0/more/getting_started/windows.html#head… [1] http://www.boost.org/doc/libs/1_51_0/more/getting_started/unix-variants.htm…

1 0

[filesystem] using locales on Solaris with GCC
by JonathonS 20 Sep '12

20 Sep '12

Hi, I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem. Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :( This is very unfortunate because after looking through the boost filesystem code (boost/libs/filesystem/src/path.cpp), I found out that it creates a default locale by invoking std::locale("") (boost/libs/filesystem/src/path.cpp @ line 911) . Therefore, if my client sets the locale to anything but "C" or "POSIX", when it tries to create the default locale object via std::locale(""), it throws a runtime exception which crashes my program. So, my question is whether anyone knows of a work-around for this? I came up with one idea, but it seems very hackish. I can try to construct a boost::filesystem::path object and try to catch the exception thrown by std::locale(""). If the exception is thrown, I can set the environment variable to "C" or "POSIX" and continue with the program. My other idea is to manually patch boost::filesystem::path to use the following code to create the default locale. (again line 911 in path.hpp) try { use std::locale("") as the default locale; } catch ( std::runtime_error& ) { // We were unable to construct a locale, now use the global locale. use std::locale() as the default locale; } using std::locale() as the default will *always* succeed since it will just use whatever the current global locale is. My concern with this, is that I'll have to manually patch boost for this. Thanks, J

3 4