March 2010 - Boost - lists.boost.org

Should Boost adopt pimpl/d-pointer as much as it can?
by Artyom 26 Mar '10

26 Mar '10

Hello, There are recently lots of discussions about current development issues. I would like to point to one small but extremely important issue (from user point of view). Boost has too many logic in header part of library, by meaning too much I mean painfully too much. I think that Boost should adopt as policy: 1) All implementation related code **should** be put in sources. 2) Any non-template based class should have opaque/d/pimpl pointer in its body. Why? I give you a simple example: one of the pearls of Boost: Boost.Asio is one of most painful libraries to use. I created a simple example of echo server written with Boost.Asio and written with a small pimpl-wrapped Boost.Asio (I had written myself as proof of concept - that uses boost.asio in implementation): http://art-blog.no-ip.info/files/asio_pimpl.tar.gz These are results of compilation times with gcc-4.3 (seconds): -O0 -O2 -O3 -O2+link asio 2.56 4.65 4.96 4.75 pimpl 0.59 0.85 0.89 0.94 diff *4.3 *5.5 *5.6 *5.05 And this is trivial echo server. When the code gets larger and bigger it becomes even more painful. For me, compilation of components based on Asio is total nightmare because of unacceptable compilation times. Another issue is executable size. I had took same echo sever placed in 10 object compiled under different namespaces once I did it with Boost.Asio and then I did it with pimpl-ed Asio. Result (liked executable size with gcc-4.3): Build Size (-Os stripped) Asio: 245K Pimpl: 190K ---------------------------- Conclusions: ============ There are too many good libraries (Asio as good example) that use headers too much or headers only, this terribly increases compilation times and makes executable sizes much bigger (this is especially relevant for embedded systems). Should Boost wellcome pimpled libraries more? I think yes. It would solve two problems: 1. It would give faster compilation times. 2. It would allow to provide changes easily without breaking compatibility (even would allow to provide backward ABI compatibility) Dear Boosters. What do you think about? Artyom

17 36

Re: [boost] GSOC query for Heaps and Que
by Andrew Sutton 26 Mar '10

26 Mar '10

Hi Chirag, 1) Relaxed Fibbonacci Heaps by Chandrasekhar Boyapati C. Pandu Rangan > 2) Relaxed Weak Que by Amr Elmasry Claus Jensen Jyrki Katajainen > 3) Soft Heap by Bernand Chazelle > > Please tell can I add these datastuctures to my proposal for GSOC . > I think those data structures are in the spirit of the proposal. It would not be a bad idea. > I also want to add radix tree and generalized version of union find > datastructure into my proposal. > Will it be a good proposal ? > That might be a little ambitious for a 3 month project. I would try to keep your proposal a little more focused. Andrew Sutton andrew.n.sutton(a)gmail.com

1 0

Re: [boost] [gil] Can not open test.jpg
by Mariusz Kwiczala 26 Mar '10

26 Mar '10

Christian, >>This file needs to be swapped out. Will do that next week. >Done. Thank you. >Marius, do you wanna try out it the new gil::io? It's located here: >http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension / Will it be available in 1.43? >Let me know if you have questions, problems, etc. I have one suggestion: Gil::Io extensions do not work without required libjpeg libpng, libtiff ... There is no way to run examples from "boost_1_42_0\libs\gil\example" without required libs. There are problems to match boost::gil and "external graphlibs" i.e. http://stackoverflow.com/questions/2442335/libpng-boostgil-png-infopp-null-n ot-found I think that libjpeg libpng, libtiff libs should be included into boost and compiled with use bjam. Regards, Mariusz

8 34

Re: [boost] [transact] code in sandbox
by vicente.botet 26 Mar '10

26 Mar '10

----- Original Message ----- From: <strasser(a)uni-bremen.de> To: "vicente.botet" <vicente.botet(a)wanadoo.fr> Sent: Friday, February 12, 2010 2:00 AM Subject: Re: Re:[boost] [transact] code in sandbox > Zitat von "vicente.botet" <vicente.botet(a)wanadoo.fr>: >> IMO the transaction must be accesible during the handling of the exceptions. > > why? I see one reason in your examples (although I don't understand > force_to_abort, maybe that's another one, see below), and that is > committing on exception: > >>>> #define BOOST_TRANSACT_BASIC_RETHROW(TXMGR, TX, E) \\ >>>> catch (E&) {(TX).commit(); throw;} > > why can't the user create his own try/catch block for that?: > (using your syntax) > BOOST_TRANSACT_ATOMIC(_) { > try{ > ... > }catch(my_exc &){ > _.commit(); > } > }BOOST_TRANSACT_COMMIT(); Yes this is always possible. However, transactions and exception handling are used for the same goal, recover from errors. Thus it is interesting to handle them in the same way and in a single try-cactch block. >> _.force_to_abort(); > > what does this do? retry the transaction but make sure it fails? why? > why don't you just go ahead and throw an exception that is not caught > inside the transaction scope? When the user wants to undo whatever the transacton block did, the simple way is to abort the transaction. Don't forget that transactions can be used in a single-threaded application to make exception-safe code. >>> at some point I think the macros loose their benefit and you might >>> just as well write the loop yourself. e.g. if you need to execute >>> custom code on retry. >> >> You are right. The specific macros are not important. What is >> important is that the provided macros can be extended naturaly. > > that's what I'm not so sure of. if you need to control the number of > retries or execute custom code on retry, why don't you just write this > instead of using macros: > > for(int c=0;c<10;++c){ > try{ > transaction tx; > ... > tx.commit(); > break; > }catch(isolation_exceotion &e){ > e.unwind(); > std::cerr << "my custom retry code\n"; > } > } > > doesn't seem a whole lot more verbose to me. > but I'm not against adding more macros for convenience. the one thing > I would like is not complicating the simplest use case. the user > shouldn't have to to add something like "(_)" if he doesn't need it > and has no idea what it is there for. the default use case should be > as simple as possible. I would like also to don't need to add a transaction variable name. I need the name of the transaction variables to implement break and continue in a language-like. From my side, the inclusion of the macros is to be close to what the user will write if the language provided some specific transaction constructs. The user is always free to use directly the class interface. The question is what is the simple case. for an INNER transaction Boost.STM provides a macro #define BOOST_STM_USE_ATOMIC(TX) \ for (boost::stm::transaction TX; \ ! TX.committed() \ && TX.restart(); \ TX.commit()) that the user ca use like BOOST_STM_USE_ATOMIC(_) { // transaction statement } In this case every exception scape the transaction block, and will be managed by the outer transaction block. This is simple, recall a possible language statement transaction { // transaction statements } The parameter is needed only if we want to return from the transaction block. If needed we can add a simple #define BOOST_STM_INNER_TRANSACTION \ for (boost::stm::transaction __TX; \ ! __TX.committed() \ && __TX.restart(); \ __TX.commit()) use as follows BOOST_STM_INNER_TRANSACTION { // transaction statement } As I said in a preceding post, we can provide initialy both sets of macros and see which set the users use more often. Best, Vicente

7 48

About adding XML API in the boost.
by Qingli Ma 26 Mar '10

26 Mar '10

Hello,everyone! I am from china and want to take part in the boost commnnity. Support for XML is limited in boost, so I want to do something about this. Also I see some information at https://svn.boost.org/trac/boost/wiki/SoC2010. I wish to take part in the Google Summer of Code(http://socghop.appspot.com/). Can you give me some ideas about that?Who should I contact with? Thank you for your sugguestion!

2 1

GSOC - Boost.XML
by Shrinidhi Hudli 26 Mar '10

26 Mar '10

Hello, I am interested to send a proposal to work on Boost.XML for GSOC 2010. I have a couple of questions: 1. Would it make sense to provide C++ binding for XML using XSD? This would make it much more convenient that using parsers explicitly. 2. Is the project mostly to develop an abstraction for the backend parsers so that different parsers can be "plugged-in"? Thanks for the clarification. -- Shrinidhi Hudli

2 1

Re: [boost] [lexical_cast] A non-throwing lexical cast? [Was: 5Observations - My experience with the boost libraries]
by pete＠pcbartlett.com 26 Mar '10

26 Mar '10

On Fri 26/03/10 01:25 , Gennadiy Rozental <rogeeff(a)gmail.com> wrote: > Rene Rivera writes: > > > > Tom Brinkman wrote: > > > boost::lexical_cast_no_throw() > > > > Or.. > > > > template > > T lexical_cast(const S & arg, const T & error_default_value); > > > I've implemented later in my own version of lexical cast. In 99% of > the time > this is exactly what I need: either convert string to number or take > this > default value. Another good consequence is that I do not need > template parameter > anymore. > Gennadiy Looking at the various threads it seems like three different behaviours in the event of conversion failure have been requested. - Default Value - boost::system::error_code - throw custom exception. So this would suggest an interface like template< typename T , typename S, typename FailureHandler > lexical_cast(S const& arg , FailureHandler fh) with specializations if FailureHandler = T or FailureHandler = boost::system::error_code&. You do lose your "good consequence" with this formulation though. As I said in another message, the original author of lexical_cast has said several times over the years that doing something like this is too far from the spirit of a *_cast, though, so if it gets into Boost I think it will have to be in the StringConvert library.

1 0

[lexical_cast] A non-throwing lexical cast? [Was: 5 Observations - My experience with the boost libraries]
by pete＠pcbartlett.com 26 Mar '10

26 Mar '10

On Wed 24/03/10 03:40 , Jonathan Franklin <franklin.jonathan(a)gmail.com> wrote: > On Tue, Mar 23, 2010 at 9:31 PM, Tom Brinkman wrote: > > ... All I'm saying is that in the real world, most > > projects are mixed C/C++ and that the needs of both communities > need > > to be addressed if boost is going to remain relevent. > For the sake of not arguing, let's assume that your assertion is > true. > Let's hear your *actionable* proposal for improving boost. E.g. > show > us the better interface for <insert Boost library here> Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice. If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse": - boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown.

7 10

Re: [boost] [lexical_cast] A non-throwing lexical cast? [Was: 5 Observations - My experience with the boost libraries]
by Pete Bartlett 25 Mar '10

25 Mar '10

Kim Barrett wrote: > On Mar 24, 2010, at 5:20 PM, Bruno Santos wrote: >>boost::bad_lexical_cast is not derived from >>my_project::invalid_user_input o or whatever. This happens a lot with >>boost::lexical_cast. >> >If the user data is data that comes from a file or user interface, I >agree in your assertion. > >However, if it's from someone using your library, it's an obvious >programming error, doing exception translation in this case is >pointless. Agreed, but the source of data in a text format that should be a numeric format is much more likely to be end-user systems and inputs rather than that created within a client application, IME. >Anyway, in my opinion, passing a boost::system::error_code as the second >parameter for a non throwing version would be the best solution. As Jeff points out, others have been here before us, and it looks like the proposed Boost.StringConvert is the result of prior discussions. Perhaps our energies would be best spent making sure that library meets our needs by being reviewers or even the review manager [one is still needed, according to the schedule]. Pete

1 0

GSOC 2010 Boost-Graph
by Chinmaya Poswalia 25 Mar '10

25 Mar '10

Hi Myself Chinmaya Poswalia Computer Science an Engineering B.Tech, Indian Institute of Technology, Guwahati I am finding all the graph topic(my favorite topic to work on) very interesting that's why i asked a lot of questions regarding all in one mail. - i want to work on semantic graph - how about maintaining an adjacency list, denote V as nodes and E as edges, so the space complexity will be O(V+E). - Also we can employ pointers of type void* to point to edges/vertices of different types so as to maintain the graph of different edge and vertex types. - rather than employing a vector in each node and edge either we should allocate space during insertion or we maintain the size of vector array by ourself. - Through generic programming, all the operations being implemented on graph up till now will be made applicable on these new members of the library. - various functions that can be induced on these graphs are 1. Distribution of node degree 2. finding clustering co-efficient of semantic graph 3. relevance of a link and node 4. scale on semantic graph 5. disparity of connected types/dispersion co-efficient. - Semantic graph are generating huge level of importance in networking (network semantics on web), video screening, statistical analysis of data,etc so it will be a great thing to work on it. Can you suggest some more links to read on for these I am working on my proposal about the graph and your help is crucial for me. With regards Chinmaya

2 1