Re: BoostCon 2009 Early Registration Extended to April 26th
on Thu Apr 09 2009, woodbrian77-AT-gmail.com wrote:
Would you agree that recoding that takes advantage of C++ 1998
should be higher priority than C++0x?
In general, maybe. For BoostCon, no.
For example, Boost Serialization doesn't use hinted inserts with
(mulit)set or (multi)map.
Have you submitted a ticket for that at http://svn.boost.org?
I believe Boost Multi Index does. In the
performance section here --
http://webEbenezer.net/comparison.html -- there's a subsection
on Load/Receive tests that mentions this. I also mentioned
this subject twice in this thread:
If anyone cared or even noticed wasn't clear as there was
no response to that particular point.
Different library maintainers take different approaches to responding to
reports on the Boost list. Specific Trac tickets (especially with
patches attached, as you seem to be able to provide) are a little harder
to leave dangling because to make them go away you have to explicitly
close them, so I suggest you try that approach with one ticket per
For some reason I doubt the author or anyone else bothered to improve
the library in this way and the 1.39 version of the Serialization
library will have the same weak performance in this area.
Additionally and more importantly, now the C++ Middleware
Writer has support for several boost::intrusive containers.
Neither Boost Intrusive nor Boost Serialization have
serialization support for any of the intrusive containers.
The Boost Instrusive containers are superior to the
standard containers in a number of ways, so this gap is
While working to update parts of Boost to be able to
take advantage of C++ 2010 (or 20110), makes sense to
me, I think the items I mentioned should be higher
priority than the C++0x work.
A Boost bugfixing sprint sounds like a great idea, but that can happen
in cyberspace (the way Ubuntu does it). I invite you to come to the
Boost developers' list and kick one off. I would certainly be grateful
for an excuse to focus on closing Boost Trac tickets. In fact, it
sounds like a good thing to mull over at BoostCon
At BoostCon I want to take advantage of the face-to-face time to do
things that are a bit more educational, less critical-path, and that can
really benefit from having a bunch of people in the same room. I think
exploring how C++0x features interact in real C++ libraries is one of
It's not as cool or sexy though.
That's an issue, too. To make it worthwhile for people to travel across
the country to BoostCon, you need to put "cool" things on the program
The first item should be relatively easy to address, which makes it
all the more surprising that as the releases go by it doesn't get
Remember that addressing any given issue in a Boost library is basically
up to one person: whoever is maintaining that library. Maintainers are
volunteers, and each one arranges his priorities differently. But in
the case of something posted on the -users mailing list whose thread
sorta trailed off, I wouldn't be surprised if the issue has fallen off
the maintainer's radar. I suggest getting it into the tracking system.
The second item, though is a different story. Anyway,
even if you are only able to address the first item by the time
BoostCon is over, I'll be impressed.
Well, it's not really up to me, and I don't /think/ Robert Ramey is
planning to come to BoostCon this year.
And since I'm able to point out two weaknesses like this with one
library, there may be other problem areas in other libraries.
Looks like we have 766 open issues right now :-(
This could be incorporated into the pricing of the conference: $499
gets you into the C++98 "fixer" and $599 gets you into the C++0x
Yeah, not very practical. Those sessions are just two 3-hour segments
out of a whole week of material. We're not making the conference itself
into one big sprint. Take a look at the program:
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:firstname.lastname@example.org]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]