- Boost - lists.boost.org

Discovering C++11 lambda argument and result types to construct boost::function
by Frank Birbacher 14 Feb '12

14 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On comp.lang.c++.moderated I talked to Daniel Krügler about how to discover argument and result types from C++11 lambdas in a template context. The thread has the title "How to discover argument and result types from lambda for constructing std::function?" https://groups.google.com/d/topic/comp.lang.c++.moderated/qaMECIUlJp0/discu… The task is to provide a function template "make_function" that takes a C++11 lambda expression and returns a boost::function with the correct signature to call the lambda. This may be extended to accept any other callable type. Is there such a thing already in Boost? I'd like to add it. Would it go to Boost.Function alone? Or would parts fit into TypeTraits? Does Doug still maintain Boost.Function? Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk80RsMACgkQhAOUmAZhnmr5gACdGI6q9Xi1SbtpHs23GlAhU9uu Y3kAnjCpiZFGJp+IpnFVS3gmtZOqZp42 =GGdI -----END PGP SIGNATURE-----

6 8

Re: [boost] [optional] generates unnessesary code for trivial types
by Andrzej Krzemienski 13 Feb '12

13 Feb '12

> I use optional references in my code, in cases like the following: > I have an operation, which processes some elements, and some of the > elements constitute special cases. The caller of the operation may or may > not want to know about the special cases that arose, so they can optionally > pass in a container which will be populated with the special cases: > void some_operation(inputs, optional<vector<case>&> special_cases = none) > { > for (...) > { > ... > if (special_case) > { > ... > if (special_cases) > special_cases->push_back(current_case); > } > } > } > Before I discovered optional, I used a plain reference, but that was annoying > because I had to create a dummy vector to be used as the default argument. > (The other alternative would have been to use a pointer, but then the caller > has to use the uglier syntax of passing in "&special_cases" rather than > "special_cases"). Nathan, going back to the same question I asked Andrey ( http://groups.google.com/group/boost-developers-archive/msg/704971a1eb63b3d2) it looks like your use case would still work if we disabled any sort of assignment for optional references (even the assignment from boost::none for resetting). Am I correct? Regards, &rzej

2 1

Re: [boost] [optional] generates unnessesary code for trivial types
by Brian Wood 13 Feb '12

13 Feb '12

Andrzej Krzemienski: > But even that appears like a non-obvious thing to me. Would other people > here in the list, and also developers in general agree that it is ok that > you have output operation but no input operation? I think that in the > standard library they always go in pairs. (I am not sure, though). I haven't followed this closely, but don't see a problem with not being symmetrical here. The C++ Middleware Writer (CMW) has asymmetric support for Boost Range types: @out (boost::sub_range<std::vector<int32_t> >) If you omit the @out or write @in on that line, the CMW gives you an error message that ranges don't support receive (input) functionality. It only made sense to me to output via a range so that's all that's supported for now. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net I'm happy Adele won all those Grammys. She deserves them them I think.

1 0

Re: [boost] [optional] generates unnessesary code for trivial types
by Andrzej Krzemienski 13 Feb '12

13 Feb '12

> >> Side question: is streamablity going to be in your proposal? > > It is not currently. The reason for that is that there is no clear way how > > it should be implemented (a similar issue applies to pairs, tuples, > > variant, any, etc...) See > > http://lists.boost.org/Archives/boost/2005/03/81619.php<http://www.google.com/url?sa=D&q=http://lists.boost.org/Archives/boost/2005…>for discussion. I > > believe that the problem is with the streaming itself. For instance, should > > streaming out and then streaming the result back in produce the same value? > > Some people expect that, but even std::string could not provide this > > behavior. > > I'd do only << and forget about >> But even that appears like a non-obvious thing to me. Would other people here in the list, and also developers in general agree that it is ok that you have output operation but no input operation? I think that in the standard library they always go in pairs. (I am not sure, though). Also, how would you implement it? what should an uninitialized optional print? Nothing? but how is having printed an uninitialized optional<int> different that not having printed anything? A question mark? but how would the following two be different: optional<string> o1; // uninitialized optional<string> o2 = "?"; cout << o1; cout << o2; If you propose to provide only output operation, then it looks like you want this for some sort of logging. But perhaps it is better to have some overloaded function toString() that converts all the types to strings. Usually the string format that works for one program does not work for the other. And there appears to be no natural/intuitive way of representing any type (like optional) as text. Regards, &rzej

3 2

[1.48.0] Trouble building boost with debug-store=database option (Visual C++ 2010 SP1 64-bit)
by Michael Goldshteyn 13 Feb '12

13 Feb '12

I have always built boost (up to 1.47.0) using the following command line: bjam -j 8 --without-mpi --without-python --build-dir=vc100-bld-64-bit --build-type=complete --toolset=msvc-10.0 architecture=x86 address-model=64 --stagedir=64-bit-vc100 debug-symbols=on debug-store=database stage Now, when I specify the debug-store=database option in the command line above, the build fails and gives me errors as can be seen at the bottom of the following build output excerpt: ----------------------------------------------------------------------------------------------------------------- ...patience... ...patience... ...patience... ...patience... ...found 9190 targets... ...updating 3251 targets... common.mkdir 64-bit-vc100 common.mkdir 64-bit-vc100\lib common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0 common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64 common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86 common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database\link-static common.mkdir vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database\link-static\runtime-link-static compile-c-c++-pch vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database\link-static\runtime-link-static\pch.pch pch.pch.cpp compile-c-c++ vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database\link-static\runtime-link-static\assoc_laguerre.obj assoc_laguerre.cpp libs\math\build\..\src\tr1\assoc_laguerre.cpp(6) : error C2858: command-line option 'program database name (/Fde:\dev\devel\libs\boost\boost_1_48_0\vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store -database\link-static\runtime-link-static\libboost_math_tr1-vc100-sgd-1_48.pdb)' inconsistent with precompiled header, which used '/Fde:\dev\devel\libs\boost\boost_1_48_0\vc100.pdb' libs\math\build\..\src\tr1\assoc_laguerre.cpp(6) : error C2859: e:\dev\devel\libs\boost\boost_1_48_0\vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database\link-static\runtime-link-static\libbo ost_math_tr1-vc100-sgd-1_48.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header. call "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" amd64 >nul cl /Zm800 -nologo @"vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database\link-static\runtime-link-static\assoc_laguerre.obj.rsp" ...failed compile-c-c++ vc100-bld-64-bit\boost\bin.v2\libs\math\build\msvc-10.0\debug\address-model-64\architecture-x86\debug-store-database\link-static\runtime-link-static\assoc_laguerre.obj... ----------------------------------------------------------------------------------------------------------------- Is the debug-store=database option no longer supported? Is something else wrong with my build command?

1 1

copy a graph (adjacency_list) to another one
by ShNaYkHs ShNaYkHs 13 Feb '12

13 Feb '12

How can I copy a graph of type adjacency_list to another one graph of type adjacency_list ? Look at the flowing code example: typedef adjacency_list<setS, setS, undirectedS, NodeDataStruct, EdgeDataStruct> MyGraph; MyGraph g1, g2; // processing g1: adding vertices and edges ... // processing g2: adding some vertices and edges ... g1.clear(); g1 = g2 // this gives an execution error (exception) g1 = MyGraph(g2); // this also gives an execution error g2.clear(); Note that to use of copy_graph(...) it is said that the graph type must be a model of VertexListGraph. In my case it is an adjacency_list ... Thanks,

1 0

Re: [boost] [optional] generates unnessesary code for trivial types
by Hite, Christopher 13 Feb '12

13 Feb '12

> On 1.2.2012. 17:53, Hite, Christopher wrote: > > As for the debugger the new C++ allows for a union to contain a > > class. So if a placeholder implemention using such a union would show the data in debug. > But the pointer approach would also work with "real world" compilers > ;) This isn't for science fiction. Gcc says they support n2544 since 4.6. http://gcc.gnu.org/projects/cxx0x.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf I just tried it out: template<typename T> union placeholder{ T v; placeholder() {} ~placeholder (){} }; ... placeholder<std::string> ps; std::string s("hi"); new(&ps.v) std::string(s); < Uninited happens to contain null. > (gdb) print ps $2 = {v = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}}} < Initied: > (gdb) print ps $3 = {v = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x602028 "hi"}}} I don't know what platform you're using, but it seems completely reasonable to #ifdef a version of the placeholder in that does this so people can debug easily. Does that remove the main reason you wanted a pointer? BTW I did look at your code some. The deconstructor mixin, it's the same technique I used! For the ctor I just define a intermediate class with either default copy and operator= or impled ones. Chris

1 0

Re: [boost] [optional] generates unnessesary code for trivial types
by Andrzej Krzemienski 13 Feb '12

13 Feb '12

> > I am > > thinking of disabling the assignment not because I think it does not belong > > to references, but because there are two ways of implementing it, and > > implementing it either way would surprise a different group of > > programmers. > > And this would be a "run-time surprise". Instead my choice (not necessarily > > the best one) is to provide a "compile-time surprise". > > If value semantics are achievable for this kind of optional, I think > it's better to supply that and let the people who don't expect value > semantics be surprised at runtime. It is very difficult to provide a non-surprising/non-controversial behavior. While I am not happy with my solution, I would also have concerns about "run-time surprise" because: First, there are two ways of implementing optional reference assignment (rebinding or not rebinding) and it seams (from the past discussions in this group) that either is equally counter-intuitive, and it is not clear which one to choose. It would have to be an absolutely arbitrary choice. People are strongly convinced about their views and it is not possible to come up with a reasonable compromise. In fact it is the optional reference assignment that prevented the addition of Optional to ISO C++ the first time (http://lists.boost.org/Archives/boost/2005/10/95120.php) Second, it is difficult to say about value semantics here. References themselves are not really value semantic (at least according to my understanding of the term): they have shallow copy constructor and deep copy assignment. Even if it is disputable for native references, it is more so for optional references, which removes the "special" aspects of references, like extending the life-time of a temporary, reference semantics, or no-storage requirement. We would be building value semantics on a non-value-semantic type. Or in other words, I am concerned that we would only be providing "value-semantics syntax" but not "value-semantics semantics". But we would violate the axioms of value semantic types (like the "separation of the value"). Regards, &rzej

1 0

Boost.Application (Pre Alpha) Release 2 available
by Renato Tegon Forti 13 Feb '12

13 Feb '12

Hi All! There is a new version of "Boost.Application" available in SF (http://sourceforge.net/projects/boostapp/) >> Boost.Application_pre_alpha_2.zip (http://sourceforge.net/projects/boostapp/files/Boost.Application_pre_alpha_ 2.zip/download) This version is based on received comments ! Please, install it: 1) Copy: Boost.Application_pre_alpha_2\boost\application To: boost_1_48_0\boost and, Boost.Application_pre_alpha_2\libs\application To: boost_1_48_0\libs 2) Build (bjam link=shared) . 3) And, to see what has changed, please see the tutorial in help (doc): boost_1_48_0\libs\application\doc\html\application\tutorial.html I will wait for comments! Thanks Renato

2 2

[iostreams] output_filter works only once
by Steven Samuel Cole 13 Feb '12

13 Feb '12

i am trying to use an boost::iostreams output filter to add a string to the beginning and the end of whatever i stream out. my code below works, but only the first time; the second time, the output seems to get lost somewhere, the write method doesn't even seem to get called. i thought at first i'm sending something to the stream that triggers its fail bit, but the stream seems good. the same problem occurs on mac and linux, with latest boost release (1.48) and svn trunk, with cout and a file sink as device. is that a bug ? or am i doing something wrong in my code ? #include <iostream> #include <sstream> #include <boost/iostreams/concepts.hpp> #include <boost/iostreams/device/file.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/operations.hpp> using std::cout; using std::endl; using std::streamsize; using std::string; using std::stringstream; class add_string_output_filter : public boost::iostreams::multichar_output_filter { public: template<typename Sink> streamsize write(Sink& sink, const char* s, streamsize n) { string out_string = string(s); // remove trailing '\0' to prevent line break if (out_string[out_string.size()-1] = '\0') out_string = out_string.substr(0, out_string.size()-1); string pre_string("prepended string - "); string app_string(" - appended string"); stringstream sstrm; sstrm << pre_string << out_string << app_string << endl; // TODO: char* to string, back to char* ?!? return boost::iostreams::write(sink, sstrm.str().c_str(), sstrm.str().length()); } }; int main() { boost::iostreams::filtering_ostream out; out.push(add_string_output_filter()); out.push(cout); // string #01 is printed, // string #02 gets lost out << "string #01" << endl; out << "string #02" << endl; }

2 1