September 2005 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Scons users?
by David Abrahams 20 Sep '05

20 Sep '05

"Reece Dunn" <msclrhd(a)hotmail.com> writes: > David Abrahams wrote: >>Kevin Wheatley <hxpro(a)cinesite.co.uk> writes: >> > David Abrahams wrote: >> >> On the Boost.Build list we were just discussing the fact that some >> >> people otherwise inclined towards Boost have chosen Scons over >> >> Boost.Build. It would be useful for us to understand some of the >> >> reasons why, if some of you wouldn't mind letting us know. No flames, >> >> please! >> > >> > not a flame, but some test results (Noel Llopis' Blog) shows a few >> > interesting results: >> > >> > http://tinyurl.com/7fdns (www.gamesfromwithin.com) >> > >> > These are updated from previously. >> >>Wow, harsh. The numbers aside, I think his commentary is rather >>flame-ish. > > I thought it was harsh as well. Here are a few comments: > > Ant/Rant outperform Jam on full builds even though he claims Jam is the > fastest performing build system. > > BBv2 and SCons are aimed at being truely platform independant, i.e. one > script will work for everything, whereas the others need work on your part > to get that or only support one target. I didn't think Scons was trying to achieve that. IIUC you still deal with many platform specifics when writing Sconscripts... no? > I agree with him that there is a learning curve when learning Jam/BBv2, but > you get this with learning any new language. Yes, but we ought to be doing more to make it shallow. I am about to start posting editorial review commentary on our documentation. I hope that many on this list will participate, so we can make BBv2 much more usable. > He says to avoid BBv2/SCons because of performance, but performance > is only one factor. Well, yes. The other factor for most people is "how easy is it for me to get it to do what I want?" If the system is complex and hard-to-understand, it won't be easy to use, so we may be failing on both counts. > [As a note, how much of a performance penalty is there from BBv2 and > SCons being built on top of and run from a scripting engine?] Some, but I think for BBv2 that only hurts to the extent that we're trying to do something smarter and more abstract than what people do with the other systems. Gnu Make, too, has a kind of scripting engine in it. However, some of its primitives are more closely directed at the problem domain. > What I like about BBv2 is that I can create a hello world > application in 1 minute! The jam file: > > exe hello : hello.cpp ; > install . : hello ; # copy hello.exe to this directory > > hello.cpp: > > #include <iostream> > int main() > { > std::cout << "Hello World!" << std::endl; > return 0; > } > > and most of that is writing hello.cpp! Heh, with make I think you might not even need a makefile for this one ;-) $ cat > foo.cpp #include <iostream> int main() { std::cout << "hello, world!" << std::endl; return 0; } dave@i9300 /tmp $ make foo g++ foo.cpp -o foo dave@i9300 /tmp $ ls *ake* ls: *ake*: No such file or directory See? > With this, I can now build debug and release versions - and build on > any supported C++ compiler/platform - as easily as changing the > command line, BBv2 takes care of the rest. Make and Jam don't give > you this out of the box. Now you're talking... but: "changing the command line" isn't easy unless you can come to grips with the system, and we've made that a bit too difficult. > I have lost count of the number of times I have run into problems with > incorrect project settings for MSVC projects, most of which are due to the > IDE defaulting to the current configuration (debug or release) instead of > editing all configurations. > > BBv2 (and I assume SCons has this as well) allows you to set project wide > settings (e.g. include paths) that are inherited by all targets in this > directory and below. You can't do this with the other build tools as far as > I am aware, or doing so is complex and unmaintainable. That's also true. > Also, BBv2 (and SCons?) works out the build dependancies for you based on > how targets are associated, so if you add another dependancy on one of the > targets, you don't need to change the build order as you would in *Ant. > (MSVC does dependancy analysis, but only for the current solution and you > can't nest solution files). > > It would be interesting to have more data from large build projects and > timing/profile data for these. Q: Is it possible to get profiling data for > bjam and BBv2 to see what parts of bjam and BBv2 are taking the most time. Yes, pass -d+10 on the command line. > Also, I don't believe that BBv2 has incremental build support. I > wonder what this and pre-compiled header support would do to the > timing data. What do you mean by "incremental build support?" -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Scons users?
by David Abrahams 20 Sep '05

20 Sep '05

Hi, On the Boost.Build list we were just discussing the fact that some people otherwise inclined towards Boost have chosen Scons over Boost.Build. It would be useful for us to understand some of the reasons why, if some of you wouldn't mind letting us know. No flames, please! -- Dave Abrahams Boost Consulting www.boost-consulting.com

8 10

Re: [Boost-users] Scons users?
by Vladimir Prus 20 Sep '05

20 Sep '05

Arkadiy Vertleyb wrote: > "Reece Dunn" <msclrhd(a)hotmail.com> wrote > >> Also, I don't believe that BBv2 has incremental build support. > > Do you mean it always rebuilds everything?! Any reason why it is > acceptable? Ehm... do you really think that Boost.Build rebuilds every target on every invocation? Reece most likely meant various "incremental rebuild" options in windows compilers. - Volodya

1 0

Re: [Boost-users] [boost] Scons users?
by Martin Bonner 20 Sep '05

20 Sep '05

----Original Message---- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: 20 September 2005 12:59 To: boost(a)lists.boost.org Cc: jamboost(a)yahoogroups.com; boost-users(a)lists.boost.org Subject: Re: [boost] Scons users? > Kevin Wheatley <hxpro(a)cinesite.co.uk> writes: > >> David Abrahams wrote: >>> On the Boost.Build list we were just discussing the fact that some >>> people otherwise inclined towards Boost have chosen Scons over >>> Boost.Build. It would be useful for us to understand some of the >>> reasons why, if some of you wouldn't mind letting us know. No >>> flames, please! >> >> not a flame, but some test results (Noel Llopis' Blog) shows a few >> interesting results: >> >> http://tinyurl.com/7fdns (www.gamesfromwithin.com) >> >> These are updated from previously. > > Wow, harsh. The numbers aside, I think his commentary is rather > flame-ish. Well, without the numbers, I agree. But the numbers do rather back him up (except that BoostBuild does seem to be marginally quicker than Scons on three out of four tests, whereas he describes it as "Slower even than Scons!"). Are there any known optimization oportunities in BoostBuild? Are the results an artifact of his test set up? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

[iostreams] experience with automatically decompressing with gzip or bzip2
by Marcus Alanen 19 Sep '05

19 Sep '05

Hello, I've recently used iostreams for easier gziping and bzip2ing of output streams. However, I'd also like to be able to read any file compressed with either gzip or bzip2, by analyzing the input stream and deducing which decompressor to use. I don't want to open the file twice or to seek in the stream, as this might not be possible due to e.g. reading from the network. My solution is to create a custom streambuf, which is told to read and retain the first few bytes to determine which decompressor to push onto the boost::iostreams::filtering_streambuf. Then the actual reading can take place, and the custom streambuf first returns the retained bytes, then just streams the rest of the actual input streambuf. As far as I can tell, this works nicely. I wonder if anybody else has better solutions for this? Perhaps there is come capability of iostreams that I've overlooked? Below is the code, feel free to use as you wish. I don't know if I need to override xsgetc(), underflow() and uflow(), so they are currently just non-working stubs. So far nothing seems to have triggered any of them: only xsgetn seems to be used. I haven't found any actual errors, though. Both gzip and bzip2 files seem to decompress. Otherwise the code can be improved a lot, e.g. by registering separate compression detectors instead of hard-coding them in the streambuf. I think I'm also lost a bit where and when to use streambufs instead of streams, e.g. m_input. Apologies if the code is too long for your mailing-list, I didn't find any guidelines for this. Regards, Marcus #include <boost/iostreams/filtering_streambuf.hpp> #include <boost/iostreams/copy.hpp> #include <boost/iostreams/filter/bzip2.hpp> #include <boost/iostreams/filter/gzip.hpp> #include <iostream> #include <boost/noncopyable.hpp> class general_decompressor_streambuf : public std::basic_streambuf<char, std::char_traits<char> >, public boost::noncopyable { private: std::streambuf& m_input; static const int BUFFER_SIZE = 5; unsigned char m_read[BUFFER_SIZE]; std::streamsize m_readpos; std::string m_compression_type; public: general_decompressor_streambuf(std::streambuf& i) : m_input(i), m_readpos(0) { ; } ~general_decompressor_streambuf() throw () { ; } std::string get_compression_type() const { return m_compression_type; } void resolve_compressor (boost::iostreams::filtering_streambuf<boost::iostreams::input>& sb) { int pos = 0; while (pos < BUFFER_SIZE) { int c = m_input.sbumpc(); if (c == EOF) return; m_read[pos++] = c; } if (m_read[0] == 037 && m_read[1] == 0213) { m_compression_type = "GZIP"; sb.push( boost::iostreams::gzip_decompressor() ); } else if (m_read[0] == 'B' && m_read[1] == 'Z' && m_read[2] == 'h') { m_compression_type = "BZIP2"; sb.push( boost::iostreams::bzip2_decompressor() ); } else { ; } } std::streamsize xsgetn(char* s, std::streamsize n) { std::streamsize cnt = 0; if (m_readpos < BUFFER_SIZE) { while (m_readpos < BUFFER_SIZE && n > 0) { unsigned char ch = m_read[m_readpos++]; *s++ = ch; ++cnt; } if (cnt == n) return cnt; } std::streamsize ss = m_input.sgetn(s, n - cnt); ss += cnt; return ss; } int xsgetc() { std::cerr << "xsgetc" << std::endl; return m_input.sgetc(); } int underflow ( ) { std::cerr << "underflow" << std::endl; return m_input.sgetc(); } int uflow ( ) { std::cerr << "uflow" << std::endl; return m_input.sgetc(); } }; int main() { general_decompressor_streambuf buffering_in_streambuf(*std::cin.rdbuf()); boost::iostreams::filtering_streambuf<boost::iostreams::input> cmpr; buffering_in_streambuf.resolve_compressor(cmpr); cmpr.push(buffering_in_streambuf); std::istream i(&cmpr); boost::iostreams::copy(i, std::cout); return 0; }

2 4

trouble with boost::assign
by Lee Crabtree 19 Sep '05

19 Sep '05

Hi, I'm trying initialize a static map with map_list_of. Something along the lines of: map<int,int> blarg = map_list_of(1, 2); However, when I go to compile, I receive the following error: error C2440: 'initializing' : cannot convert from 'boost::assign_detail::generic_list<T>' to 'std::map<_Kty,_Ty,_Pr,_Alloc>' with [ T=std::pair<boost::assign_detail::assign_decay<int>::type,boost::assign_detail::assign_decay<int>::type> ] and [ _Kty=int, _Ty=int, _Pr=std::less<int>, _Alloc=std::allocator<std::pair<const int,int>> ] I have absolutely no idea what this means. Am I missing something obvious, or is there a more sinister problem afoot? Lee Crabtree

1 0

Re: [Boost-users] [RMI-like-lib] is there any interest in such?
by Foster Gareth 19 Sep '05

19 Sep '05

> Jarl Lindrud has done a lot of work on this already - see > > http://www.codeproject.com/threads/RMI_For_Cpp.asp > > While it uses boost and mpl techniques extensively it's not > quite boost style. > I'd be using it extensively but for the fact that it doesn't > integrate well with > our own code framework. > Looks interesting. Just out of interest, could you site any examples, or point me toward previous discussion that does so? Cheers, Gaz

1 0

Find all the shortest path from a graph
by Giulio Veronesi 19 Sep '05

19 Sep '05

Hi all, I'd like to extract all possible shortest path from a source to a destination... not only one path. Please, could you help me to resolve this problem? Thanks a lot in advance, Giulio

4 11

locate vertex
by Giulio Veronesi 19 Sep '05

19 Sep '05

Hi, I would like to locate an edge of a graph starting from the source and target vertex. For instance vertex(n, g) return the nth vertex of graph g. I would access the edge from vertex x to vertex y... something like this edge(x, y, g) Is there a fast way to do this? Thanks, Giulio

2 1

[RMI-like-lib] is there any interest in such?
by Slawomir Lisznianski 19 Sep '05

19 Sep '05

I've been thinking of a library that would bring RMI-like capabilities to C++ (RMI stands for Remote Method Invocation). Primary goal, and differentiating feature, of this library is not to rely on IDL-like compiler, hence no cross-language support either -- if you need that, check out CORBA (www.omg.org) or ICE (http://www.zeroc.com) As an example, I'm going to "implement" client and server sides of a trivial calculator using proposed library. Step 1. Define calculator interface ----------------------------------- // // Operations: add, subtract, multiply and divide // struct add { typedef function2<double, double, double> function_type; }; struct subtract { typedef function2<double, double, double> function_type; }; struct multiply { typedef function2<double, double, double> function_type; }; struct divide { typedef function2<double, double, double> function_type; }; // Calculator interface // typedef interface< operation<sum>, operation<subtract>, operation<multiply>, operation<divide> > calculator_i; Step 2. Client invocation ------------------------- // Construct a proxy to the remote calculator // instance. Arguments to the constructor // describe remote object's location (not shown). // proxy<calculator_i> calculator(...); // Call `subtract' on remote object (call // doesn't block). Returned object implements // Asynchronous Completion Token (or Future) // concept. // act<double> res = call<subtract>(calculator, 12, 43); // Retrieve actual result, or get an exception... // double result = res(); Step 3. Server implementation ----------------------------- // Implement actual calculator. // struct calculator_servant { double sum(double a, double b) { return a + b; } ... // other operations here }; // Instantiate calculator servant // calculator_servant servant; // Create a TCP listener. // tcp_listener listener(...) // Create a stub object that acts as an // adapter between transport and a servant. // stub<calculator_i> calculator(listener); // Install operation handlers. // calculator.register_function<add>(bind(&calculator_servant::sum, ref(servant), _1, _2)); ... // register remaining handlers // Start accepting calls. // calculator.activate(); // Block until exiting. // calculator.wait_for_shutdown(); ... -- end of example] I'm fairly satisfied with the client side, but I'm not so enthusiastic about the server side though. For one, it feels less safe. For example, what if a user forgets to register a "handler" for a particular operation? Any way to enforce this at compile time? Typically, say with CORBA, IDL compiler generates operations as pure virtual functions, so at compile time, the user knows what's left out in her servant. On the other side, it's quite powerful too (being able to "bind" functors to operations, that is). Would that be a problem for you or you'd see it as a good feature? Let me know what you think. Cheers, Slawomir Lisznianski

3 3