Eric Niebler wrote:

Thomas Witt wrote:

...

the xpressive review is now officially closed. That being said I know it's not a small library so if anybody(John?) feels like he can provide a review in the next few days I'll be happy to accept it.

Thanks Thomas Review Manager xpressive

Rather than leaving it open-ended, would it be better to say the review

You have a point in open ended being bad :-)

period is extended and set a new end date?

I somehow was under the impression that there is another review following closely. Tom? Thomas

Cromwell Enage wrote:

What's the latest version of g++ for MinGW? Is it 3.4.4 release candidate? Or is there a 4.0.0 alpha? One of these compilers should treat xpressive better than the one I got now.

I have had good luck with the g++ 3.4.4 that comes with cygwin. However, someone else reported problems with MinGW which I have not been able to reproduce. -- Eric Niebler Boost Consulting www.boost-consulting.com

Joel de Guzman wrote:

The question some people ask is why have an alternative library that overlaps over existing libraries in boost (i.e. Boost.Regex and Spirit). I'd say that we should always welcome alternative libraries. I do not see anything from our Boost Library Requirements and Guidelines that prohibits alternative designs and implementations.

FWIW I do agree with this view. Thomas

Goran Mitrovic wrote:

Joel de Guzman <joel <at> boost-consulting.com> writes:

...

FWIW, I'd vote my support for xpressive. I'd vote that it be added to the boost libraries. The question some people ask is why have an alternative library that overlaps over existing libraries in boost (i.e. Boost.Regex and Spirit). I'd say that we should always welcome alternative libraries. I do not

Not really always. Don't you think that Boost can be (or even already is) overcrowded? I cannot really define this with words; it's a feeling that I get from its everyday use. And there is a lot of conformation of my feeling I see in my smalltalk with friends/coworkers.

Are you saying that we should not accept a library to avoid over-crowding boost? Hmmm, doesn't sound right to me.

P.S. I know this is not a very valuable comment, but, you guys seem to often think too much as a "boost let's-prove-c++-is-almighty developers", not "boost users". :|

I don't know how this comment is related in any way to the topic. I can't seem to see the connection. Anyway..., I don't think I ever gave the impression that I, as a boost developer, am trying to prove that "c++-is-almighty". I'm very well aware of C++'s weeknesses. This is in fact one of reasons why we're here in the first place: to develop libraries to make C++ better. A lot of the libraries here (e.g. lambda, variant, tuples) are already available in other languages (e.g. Haskell, ML, Lisp). C++ is not almighty superior. In fact, in many cases, we're catching up. So, I'm going to dismiss that and strike it off to see if your comment will make sense without the baseless phrase. Let's see... "you guys seem to often think too much as a 'boost developers', not 'boost users'". Hmmmm... I give up. I'll never understand why you think so unless you list the /whys/. Is your impression in any way connected to your feeling that Boost is getting over crowded and hence more unfriendly to the Boost user? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Andy Little wrote:

"Joel de Guzman" wrote

...

Is your impression in any way connected to your feeling that Boost is getting over crowded and hence more unfriendly to the Boost user?

Has there been any progress in making each library available separately?. That would surely answer the criticism that boost is too big. Watching the downloads would also give useful feedback as to which libraries are most used. That must be essential information to the standards committees Finally making each library separately available would give more prominence to the libraries themselves rather than the boost brand. (I dont know whether that is good or bad).

Good point. For example, from the beginning, Spirit has its own site and has a separate download. We even package a "miniboost"--just enough to get things going. http://spirit.sf.net It might be a good idea to give library authors their own web space under boost where they can put stuff like separate downloads. That shouldn't be too hard to do. For example, since 2 years ago, we've separated the application repository from the spirit distribution to take off the excess "fat" from Boost. We placed examples and full Spirit applications outside the distro into a slot in the website: http://tinyurl.com/29mcn Soon, I'm planning to collect stuff like tutorials and place them in the site as well. I'm even considering removing things outside the "core" Spirit from the distro into a separate download to further streamline the library. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Darren Cook wrote:

Each new library adds to testing load, thins out the available maintainers, and increases the overwhelming feeling you get when you look at the boost library list.

So a new library should not be added just because it is clever, or slightly better at solving some problem than the existing ways. In my opinion, it has to be significantly better.

I actually agree with this. But I think something is getting lost in this discussion: xpressive solves a different problem than Boost.Regex. Or rather, xpressive aims to solve a larger set of problems. It scales from regex all the way to context free grammars. Did anybody read the message today entitled "[tools][bcp] using boost internally in other libraries" ? http://article.gmane.org/gmane.comp.lib.boost.devel/131511 At the end, he says, "I have yet to complete support for replacing boost with nested namespaces since it is trickier to do the replacement of the ending braces of the namespace scope. I believe other tools than the Regexp library may be more appropriate for this task." The problem is that bcp uses Boost.Regex, except the poster wants to make a tweak that requires brace-matching. But Boost.Regex can't do that. Instead of a small tweak, the poster would have to throw bcp out and rewrite it using Spirit or some such. Had bcp been written using xpressive instead, no rewrite would be necessary. xpressive would scale to solve this problem. -- Eric Niebler Boost Consulting www.boost-consulting.com

Darren Cook wrote:

...

...

Goran Mitrovic wrote: Not really always. Don't you think that Boost can be (or even already is) overcrowded? I cannot really define this with words; it's a feeling that I get

...

from its everyday use. And there is a lot of conformation of my feeling I see in

...

my smalltalk with friends/coworkers.

Joel de Guzman wrote: Are you saying that we should not accept a library to avoid over-crowding boost? Hmmm, doesn't sound right to me.

I think this is exactly right. Each new library adds to testing load, thins out the available maintainers, and increases the overwhelming feeling you get when you look at the boost library list.

I never get that "overwhelming feeling" when I see the library list. OTOH, I get a secure feeling thinking that I have all these tools at my disposal and all are solid, peer-reviewed code. The Boost libraries is nothing compared to the list that Source Forge provides, yet no one complains about being overwhelmed by SF's immensity. It's actually an ingredient to its success! As to the testing load, I think a lot needs to be done to streamline the tests (as Rene Rivera noted). For example, Serialization already takes too much time in its "carpet bombing" approach to regression testing. It's not a problem of too many libraries. It's a problem of inefficient testing. Serialization, for example takes the A x B x C x D approach which is certainly a lot more taxing than X + N (whenever N new libraries are added). Really, this is just a matter of "growing up pains". I'm very positive that Boost will get past these problems, but certainly not at the expense of prohibiting exciting new libraries, just because of the perceived overload! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Eric Niebler wrote:

No releases. No quality assurance. No reviews. Survival of the fittest. Here's a wacky thought: can we turn boost-sandbox into CBAN (the Comprehensive Boost Archive Network), and cherry-pick the best libraries from CBAN for inclusion in boost? If anybody could make something like this fly, it's boost. We'd need to look closely at the CPAN model to find out why it's successful.

I would think that to make the 'survival of the fittest' model work, there would need to be some built in mechanism where (registered?) users could numerically rate the quality of a library, and change that rating if the library changes. Without a basis like this to sort the libraries by, it would be too easy for the best submissions to get buried by the rest of the random code. Applying this sorting mechanism would allow the best and most popular libraries to float to the top. Then perhaps every month or so the top rated library could be scheduled for formal review. Just an idea. -Jason

On Wed, 21 Sep 2005 22:41:32 -0700, Eric Niebler wrote

Joel de Guzman wrote:

...

The Boost libraries is nothing compared to the list that Source Forge provides, yet no one complains about being overwhelmed by SF's immensity. It's actually an ingredient to its success!

But would you feel the same way if you had to download everything on SourceForge in order to use any part of it? :-) As boost grows (and grow it must), it is inevitable that it move to a more modular distribution mechanism. If boost had something like a cygwin installer which let you install individual libraries (and the libs they depend on!) the OMG-boost-is-sooo-big-and-scary arguments will simply go away, and we will have removed one more (perceived) barrier to adoption.

I think better installers is certainly an important part of this puzzle. Still, I suspect there will be folks that are intimidated anyway. There's lots of reasons for this attitude -- most of which I think we cannot solve...

Also, I had the good fortune to have dinner with Scott Meyers this evening, and he asked why C++ didn't have the equivalent of Perl's CPAN -- that is, a huge repository of useful code to which anybody can submit. No releases. No quality assurance. No reviews. Survival of the fittest. Here's a wacky thought: can we turn boost-sandbox into CBAN (the Comprehensive Boost Archive Network), and cherry-pick the best libraries from CBAN for inclusion in boost? If anybody could make something like this fly, it's boost. We'd need to look closely at the CPAN model to find out why it's successful.

This was actually one of the examples I used in our OOPSLA gathering last year. The CPAN model is very different than Boost in the ways you cite. On the other hand, CPAN submissions are all structured the same: documentation structure, directory structure, install structure, license, etc. This is, of course, a prerequisite to smooth support of incremental installation and basic library usability. Of course, Boost has similar standards that can be leveraged for C++, so I think it's obvious to see how the current Boost infrastructure enables such a concept. My experience with CPAN is that alot of its usefulnesss is in grazing for ideas. That is, often you can't find what you want but you can find something close that gives you a jump on what you want to do. Anyway, I'm generally in favor of evolving Boost to enable a broader contribution base -- done in a way that allows users the information to evaluate the suitability of a library for a task.

(And for the record, I don't find boost overwhelming either.)

I don't either. When I compare Boost to the available JAVA libraries the state of C++ is still disappointing. In my mind we have a lot of catching up to get C++ library support to the point where 'language choice' is driven by a 'lack of libraries'. Or put another way, people that have good reason to implement in C++ shouldn't need to 'suffer' from the lack of libraries. Jeff

On Sat, 24 Sep 2005 13:57:07 +0200, bjorn wrote

On Thursday 22 September 2005 16:24, Jeff Garland wrote:

...

On Wed, 21 Sep 2005 22:41:32 -0700, Eric Niebler wrote

...

(And for the record, I don't find boost overwhelming either.)

I don't either. When I compare Boost to the available JAVA libraries the state of C++ is still disappointing. In my mind we have a lot of catching up to get C++ library support to the point where 'language choice' is driven by a 'lack of libraries'. Or put another way, people that have good reason to implement in C++ shouldn't need to 'suffer' from the lack of libraries.

I agree with this, but to be fair I do not think it is as bad as it sometimes look. Remember that C++ has extreeme amounts of libraries of all sorts.

Numbers don't count -- it's focus. There are maybe 5 portable GUI libraries you could go evaluate for C++ -- in JAVA it's much simplier. And despite the large numbers of libraries, I think almost no-one can argue that one might use C++ to implement a web server backend these days. Sad because this is one of the places I would expect C++ to have an upper hand on JAVA.

The problem is availability. Most of them have licencences or platform dependencies that are generally unfriendly to the community. Also many are competitive, not complementary.

I agree these are barriers.

This is very different from the standard library, boost, ACE/TAO, Loki, and some others. So if we compare these with what you find in jdk or CSPAM, then there are two major differences. The C++ libraries are generally soving relatively low level tasks only not

Well we can debate what's low level. For example, consider getting stuff out of a database 'low level', but essential to applications of all sorts. Certainly there are several libraries out there, with varying degrees of standard library integration, portability, licensing, etc. Nothing even close to 'standard'. This is just standard stuff in JAVA, Perl, etc.

higher level application tasks, and you have to look in many different places to find them.

Yes.

So in my view, a good start would be a C++ focused site where everybody felt welcome to contribute portable solutions to the community, even if they prefered to have their own site, library brand, or whatever. Kind of like Source Forge, but more focused on streamlining C++ library information, quality and distribution like CPAN.

That could be useful. Like CPAN I think you would need to be able to run a few simple to understand commands to retrieve a new library into your library set. A kind of distributed bcp perhaps.

<vision> If your library did not have an entry in there, nobody would find it because that is where people would look. </vision>

That would only work only if it really feels like neutral ground, and all library developers felt like they really did a stupid thing if they did not make their entry, or somehow a third party could handle that. But it could also be made attractive by providing compiler and computer platform resources available for development and testing. Providing portable C++ sources is very hard without that, a situation that is very different in Perl and Java.

No question portability is more difficult...

Also this is a good way of pushing compiler vendors into staightening out their rincles. High visibility of cross platform regression test result like in Boost is a good thing.

Agree. Jeff

Eric Niebler <eric@boost-consulting.com> writes:

Here's a wacky thought: can we turn boost-sandbox into CBAN (the Comprehensive Boost Archive Network), and cherry-pick the best libraries from CBAN for inclusion in boost? If anybody could make something like this fly, it's boost. We'd need to look closely at the CPAN model to find out why it's successful.

I'd really like to see something like that. I think it would also help if Boost moderators (and maybe those with accepted libraries) could nominate or comment on libraries, separately from those comments from the general public. A simple note like "this is an important problem space where we need a good solution," or "code quality seems excellent; the documentation needs work before review" from someone perceived to have influence in the review process might serve as useful encouragement. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Darren Cook <darren@dcook.org>:

So a new library should not be added just because it is clever, or slightly better at solving some problem than the existing ways. In my opinion, it has to be significantly better.

I strongly disagree - my feeling is that one of motivations behind boost is to allow libraries to evolve and mature. This is best achieved when solutions and ideas are allowed to compete inside boost. Besides, large choice of libraries is also in iterest of boost users. I agree that we do have problems with testing, but limiting number of libraries is not the right solution. B.