- Boost - lists.boost.org

Typeof: Formal Review period ended
by Andy Little 30 May '05

30 May '05

Hi, The Typeof formal review period is closed. Thanks to all those that participated in the review. Thanks also to Tom Brinkman, the review Wizard. I hope to provide a more detailed summary of the review shortly, meanwhile I am happy to say that the Typeof library has been accepted into boost. regards Andy Little

1 0

Yet another quickbook question
by Arkadiy Vertleyb 29 May '05

29 May '05

Hi all, How do I generate the document-level index in the quickbook? Right now it generates indexes for those sections that contain subsections, but not the top-level index. Regards, Arkadiy

3 4

[parameter] Comments and concerns
by Cromwell Enage 29 May '05

29 May '05

1. For type extraction, the name "binding" is *much* better than the name "index_result". 2. With regard to the rvalue issue recently tackled by Dave Abrahams and Daniel Wallin: 2.1. In my projects, I seldom assign a possible rvalue to a const reference; I almost always use a const variable. The functions for which I require named parameters are initializer functions; that is, they build containers, graphs, mazes, etc. The cost of making even several copies of mostly primitive objects is negligible in comparison. 2.2. The handful of times I do bind an rvalue to a const reference, I don't even need the object; I just want its type, and the static functions associated with it. All in all, no problems here. 3. By default, most of the property maps used by the BGL are created in the following manner: make_iterator_property_map( std::vector<ValueType>( num_vertices(graph) ).begin() , index_map , ValueType() ); Assuming such a call is expensive enough that it should be a lazy default, the corresponding code (if I'm not mistaken) would be: typedef typename property_map<Graph,vertex_index_t>::type VertexIndexMap; ... typedef std::vector<ValueType> ValueVector; ... VertexIndexMap index_map = get(vertex_index_t(), graph); ... function_impl( graph , p[ some_named_parameter || bind( &make_iterator_property_map< typename ValueVector::iterator , ValueType , VertexIndexMap > , ValueVector(num_vertices(g)).begin() , index_map , ValueType() ); ] , ... ); 3.1. A new user may easily neglect to specify the template parameter types by naively expecting Boost.Bind to accept function templates just as it does ordinary functions. (I sure did.) This is not a Boost.Parameter issue per se, but if one expects to commonly use Boost.Bind to produce lazy defaults, perhaps a gentle warning would be in order. 3.2. BTW, according to <http://www.boost.org/libs/property_map/iterator_property_map.html>, ValueType and IndexMap should be the third and second template parameters, respectively. Should <boost/property_map.hpp> be fixed to match its documentation? 3.3. These are minor issues for me, but they may be major concerns for Doug Gregor, Jeremy Siek, et al. if they're revamping the BGL to use Boost.Parameter. 4. Ah, the joys of GUI programming... 4.1. Even the simplest WxWidgets program grinds to a halt when calling a function that uses the Boost.Parameter mechanism. The same goes for FLTK and FOX. 4.2. OTOH, Irrlicht <http://irrlicht.sourceforge.net/> gives full cooperation. The only apparent difference between this library and the others (aside from the fact that it is mainly a 3D library) is that it opens up a DOS box in the background. IIRC a similar concern was posted a while back, I think wrt Boost.Test + GUIs. 4.3. I haven't had the time to produce simple test cases. If you want them, let me know. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 3

Synchronize Pointer (thread safe wrapper)
by Axter 29 May '05

29 May '05

Is there any interest in adding to the boost library a synchronized pointer class which is a thread safe wrapper class for an object instance. If so, please examine the following source code, and please post feedback. http://code.axter.com/sync_ptr.h http://code.axter.com/sync_ctrl.h Or you can download it from the boost sandbox. It's listed as sync_ptr.zip The following link has the source code for a test case application: http://code.axter.com/TestCaseAppforThreadSafeObject_sourcecode.zip

2 2

RE: [boost] Re: Collecting Users/Usage of Boost (was A more confrontingBoost (long))
by Brian Braatz 29 May '05

29 May '05

> -----Original Message----- > On Behalf Of Loïc Joly > David Abrahams a écrit : > > > I don't think we need to do that kind of diligence. If we have heard > > from someone who we have reasonable confidence works for the company, > > that should be enough. If a company asks us to, we can always remove > > mention from the site. I do think it would be wrong to use a logo > > without special permission from someone in authority, but companies > > don't have any special right to control information about their use of > > Boost. > > Well, I'm not sure, but I think that many companies have some very > strict policies about how their names are used, and even more their logos. > > I use boost at work in my company. But I guess that if I told you to use > this company name, without checking with the company lawers and the > communication department, I would get into trouble. > > What might happen is that many small companies would agree easily, but > very few big companies, where administrative stuff is more > "brazil-like". I'm not sure wether seing many name I've never heard of > and no known name would be good or bad advertising. So I suggest that > before getting such a page online, it would be good to wait until there > are enough names, with some well knows ones. > [Brian Braatz Writes:] Yes. Some will have this problem. I sympathize. Allow me to offer up that the because Adobe has released a framework that sits on top of boost that this would help the issues you raise. Only the people who watch this list will KNOW that though. So if we had a products page, and we had a link to the adobe framework in addition to others, it might help speak to the problem of people not seeing boost as a viable path. Btw- I found the python link fascinating. An additional suggestion would be to have SITE MAP on boost.org. I keep seeing boost pages in these mails I never knew existed (the phyton projects page is one)

2 1

quickbook formatting problem
by Arkadiy Vertleyb 29 May '05

29 May '05

Hi all, I am now having a problem formatting the source code in the quickbook. As documentation suggests, I put tab in front of the source code, and it appears preformatted in the browser, however there is no syntax hilighting nor gray backround. What could be wrong? Thanks, Arkadiy

7 16

Regression gone
by Victor A. Wagner Jr. 29 May '05

29 May '05

The regression page is missing "page not found" and has been for a while. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

lexical_cast with default value
by Dave Dribin 29 May '05

29 May '05

Hi all, I recently discovered lexical_cast, and it's very nice and elegant. I'd like to put in a feature request, though: the ability to use a default value rather than throwing an exception on conversion failure. Basically, it would take a second argument that would be the value returned if the conversion fails. This could be used directly in the example, like: std::vector<short> args; while(*++argv) { args.push_back(lexical_cast<short>(*argv, 0)); } This eliminates the throwing and catching of an exception for cases where conversion failure is not an exceptional. I've attached a patch to lexical_cast.hpp found in Boost 1.32.0 -Dave

6 18

Documentation error?
by Raz 28 May '05

28 May '05

I was looking in the Boost Assignment library and I noticed this code under the "Function operator+=()" heading: [CODE] #include <boost/assign/std/vector.hpp> // for 'operator+=()' #include <boost/assert.hpp>; using namespace std; using namespace boost::assign; // bring 'operator+=()' into scope { vector<int> values; values += 1,2,3,4,5,6,7,8,9; // insert values at the end of the container BOOST_ASSERT( values.size() == 9 ); BOOST_ASSERT( values[0] == 1 ); BOOST_ASSERT( values[9] == 9 ); } [CODE] Shouldn't the last assertion be BOOST_ASSERT(values[8]==9)? Unless my brain is tricking me, the last element in the container should be at the 8th slot. -- ------------------------------------------- Dan Day http://razzerblog.blogspot.com

3 2

Re: [boost] serializatation const change (was Re: Problem withserialization mersenne_twister with cvs)
by JOAQUIN LOPEZ MU?Z 28 May '05

28 May '05

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Sábado, Mayo 28, 2005 8:06 pm Asunto: Re: [boost] serializatation const change (was Re: Problem withserialization mersenne_twister with cvs) > On Sat, 28 May 2005 10:05:15 -0700, Robert Ramey wrote [...] > > I don't see this change as "breaking code" but rather detecting > code > > that is very likely already broken. > > > > So, as I said, its not that I'm unsympathetic to your point of > view, > > I just don't think everyone is sympathetic to mine. > > Well, I'd say that 'no one' is sympathetic to yours, yet ;-) I > don't think > that Vladimir, myself, or the others that have posted on this > topic are > convinced that this change is really going to prevent people from > making the > error you are concerned about. For the record, not that I'm in love with the stricter const rules either, but I must confess that, when hit by them the first time, they actually uncovered a (potential) problem in my test code. So... I've been thinking about this issue, and my impression is that regular code won't be hit as much as one might think. Typically, serialization is used like this in a program: class my_class { // add serialziation capabilities }; void save(const my class&) { // some file-opening work prior to actual saving ... } void load(my_class&) { // some file-opening work prior to actual loading ... } A typical program will have a centralized point of usage of serialization, and the usual const-abiding rules won't collide with Boost.Serialization. Now, a test program like the ones we've been writing to check the serialization capabilities of our libs is more likely to follow this pattern: std::ofstream ofs(..); archive::text_oarchive oa(ofs); my_class_1 c1; ... my_class_n cn; ... oa<<c1; ... oa<<cn; std::ifstream ifs(..); archive::text_iarchive ia(ofs); my_class_1 cc1; ... my_class_n ccn; ... ia>>cc1; ... ia>>ccn; BOOST_CHECK(c1==cc1); ... BOOST_CHECK(cn==ccn); and here we *do* run into the const problem. The key difference is that, in the latter pattern of usage, we are creating local classes just to check whether they're properly archived and restored. In a real program, the serialization code is typically provided a class to archive from the outside, as serializating classes created on the fly doesn't make much sense after all. Get my point? So, to sum it up, although I think stricter const rules won't prevent as many problems as desired, I think most users won't notice anyway. We lib testers belong to a different flock. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3