- Boost - lists.boost.org

[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

BoostCon/C++Now! Talk: How I Code and Why
by Gottlob Frege 13 Feb '12

13 Feb '12

I talked about this last year, and this year I've submitted the proposal, so If you volunteered last year (and are still interested) and/or are interested in helping with a particular/peculiar talk at BoostCon/C++Now this year, then read on, and contact me offline: I'm planning on giving a talk, entitled "How I Code and Why". It is not meant to be presumptuous and tell you how *you* should code, but instead just explains how I code - day-to-day - and how I came to these patterns/conclusions. But who cares just about how *I* code, people want to hear how other members of the Boost community - people they've come to know and respect via the boost lists - code. So I'm hoping to have a few co-conspirators on stage with me, and have each explain a fundamental guiding principle that they follow in their every day code, how they came to adopt this principle and why they find it valuable. For example, I will tell the simple story ('epiphany') of why my favourite comment word is 'otherwise', and how this relates to advice you may have heard or read before. I like the flavour of [ simple, real world, specific ] ---> [ general principle ] The goal is to bring a more real world down to earth picture to the sometimes lofty fundamentals found in books and lectures. Instead of a book explaining how a guiding principle makes sense *in theory*, it would be great (I think) to hear how respected members of the community apply these principles in real life. So, if you want to participate, email me, and we will see what we can figure out. (And/or I might just have to track you down based on promises made last year!) Not sure how many people we need. I'm thinking 5-15 mins per 'principle', and I think you only need to present one (I think the weight of picking *just one* principle makes it all the more interesting). Anyhow, we can work out the details as we go along. Tony PS. this is not (yet?!) an accepted talk, but I have a bit of chicken/egg thing here: ie it would help to have a few people on board to show that the talk is viable, and thus be accepted.

1 0

PCL - Portable C++ Library
by Fernando Pelliccioni 12 Feb '12

12 Feb '12

Hi all, ( Maybe it's an OFF-TOPIC (Sorry) ) At the GoingNative2012 conference, Herb Sutter said that the main disadvantage of C++ today is the lack of a standard library (like dotNet or Java frameworks) He called people to propose additions, like REST Webservices, Async I/O, XML/JSON, ... On the other hand, a member of the public claimed for a desired feature for C++. The answer (can't remember if it was Herb or Bjarne) was to send the paper to WG21 and attend committee meetings to defend his proposal. This is what almost everyone already know about the way WG21 works. I'm not a member of the Committee, or of any company/organization that has an interest in it (Boost, Google, Microsoft, Apple,...) The question is, how I can do to attend meetings? I have no time available or money to pay me the trip myself. Consequently, I see no possibility to attend meetings, then, I have no possibility to defend an idea. Am I wrong? Perhaps this question is for the Committee members (Beman, Dave, Andrew ...) Is there a way to send a proposal and defend it without having to attend meetings? On the other hand, I would like to have access to the discussions (mailing list). or... Is it just for members? Thanks and best regards, Fernando Pelliccioni.

10 24

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

12 Feb '12

> I see your point but, IMHO, optional<T&> is too different from normal > references to attempt to draw this association. After all, > optional<T&> is an object in the sense it has internal state and you > can take its address while T& is not (one may call it an alias of an > object). It is therefore logical that optional<T&>::operator= operates > on the object (i.e. on the optional contents) and hypothetical > T&::operator= operates on the referred object. > > Note that if you store a normal reference to int as class member, you > > already have to write your assignment yourself. changing a normal reference > > to an optional reference should not come as something irregular. > > Again, I tend to see optional<T&> as an object, with no apparent > reason why it cannot be assigned to. I understand (I think) your point of view. Let me clarify one thing. 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". With your view of optional reference (if I got it right it is a pointer with a somewhat different syntax) your expectation of rebinding assignment comes as natural. With a different model of optional reference a non-rebinding assignment comes as more natural. I believe that optional<reference_wrapper<T>> would serve your purpose best. Or would it also introduce the lack of uniformity?

3 3

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

12 Feb '12

When decompiling my code I noticed a bunch of unnessesary code caused by boost::optional. 1) deconstruction typedef boost::optional<int> optional_int; void deconstruct_boost_optional(optional_int& o){ o.~optional_int(); } One would expect this to do nothing. Instead gcc 4.6.0 with O3 generates: if(m_initialized){ // do nothing m_initialized = false; } 00000000 <deconstruct_boost_optional(boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 80 38 00 cmpb $0x0,(%eax) 7: 74 03 je c <deconstruct_boost_optional(boost::optional<int>&)+0xc> 9: c6 00 00 movb $0x0,(%eax) c: f3 c3 repz ret This one could be easily fixed by removing the bit that sets m_initialized to false, since we're deconstructing anyway. 2) assignment also generates these problems: void assign_boost_optional(optional_int& o){ o=13; } Here there's a semantic issue: we have to decide to use the copy constructor or operator=. This is also wasteful for POD types or any type which has_trivial_copy<>. 3) Even more expensive is if we want to copy an optional<int> void assign_boost_optional(optional_int& a,optional_int& b){ a=b; } 00000000 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 8b 54 24 08 mov 0x8(%esp),%edx 8: 80 38 00 cmpb $0x0,(%eax) b: 74 0b je 18 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x18> d: 80 3a 00 cmpb $0x0,(%edx) 10: 75 16 jne 28 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x28> 12: c6 00 00 movb $0x0,(%eax) 15: c3 ret 16: 66 90 xchg %ax,%ax 18: 80 3a 00 cmpb $0x0,(%edx) 1b: 74 09 je 26 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x26> 1d: 8b 52 04 mov 0x4(%edx),%edx 20: c6 00 01 movb $0x1,(%eax) 23: 89 50 04 mov %edx,0x4(%eax) 26: f3 c3 repz ret 28: 8b 52 04 mov 0x4(%edx),%edx 2b: 89 50 04 mov %edx,0x4(%eax) 2e: c3 ret Three possible branches! Theoretically single 64 bit copy do the job. I'm tempted to say: it would be best if for any T has_trivial_copy< optional<T> > iff has_trivial_copy<T>. It might make a sense to make an exception for huge T, where the copying an unused T is more expensive than the branching. 4) has_trivial_destructor<T> should impl has_trivial_destructor< optional<T> > , but this is hard to implement without specialization of optional. Checking has_trivial_destructor might take care of the complexity of optional<T&> since has_trivial_destructor< T& >. I'd be willing to fix #1. The other issues need some discussion. Chris

14 39