Christian Schladetsch wrote:

Paul A. Bristow wrote:

...

This would mean that when libraries are reviewed for full acceptance, they should have received much more use, feedback and refinement, and be really ready for use by those who want a 'release quality' stable product - including decent documentation.

+1 for making it harder to add a new library to boost.

There are already too many libraries.

These two questions are actually related. A decent documentation should clearly state the problem (or types of problems) the library is solving, so that the user can quickly find out whether he should look at the library in more detail. This significantly reduces the problem of having "too many" libraries. The library name is probably not very important, but the "Categories" tags are, and can also help to reduce the problem of "too many" libraries. But just to make the main point very clear again. A good documentation is really important, and a good documentation should not only help the actual user of the library, but also the user that still has to find out whether he should really become a user of the library. Regards, Thomas

On Tue, Nov 24, 2009 at 10:08 AM, Robert Ramey <ramey@rrsd.com> wrote:

Christian Schladetsch wrote:

...

+1 for making it harder to add a new library to boost.

There are already too many libraries.

-1 for making it even harder to add a new library to boost.

Boost and C++ doesn't have anywhere near enough libraries.

-1 too. Other languages are more popular just *because* they have libraries that do everything, we need such things in C++ too, with the speed that C++ provides us. You can never have too many libraries, as long as they are well documented and categorized.

Jeffrey Bosboom wrote:

OvermindDL1 wrote:

...

On Tue, Nov 24, 2009 at 10:08 AM, Robert Ramey <ramey@rrsd.com> wrote:

...

Christian Schladetsch wrote:

...

+1 for making it harder to add a new library to boost.

There are already too many libraries.

-1 for making it even harder to add a new library to boost.

Boost and C++ doesn't have anywhere near enough libraries.

-1 too.

Other languages are more popular just *because* they have libraries that do everything, we need such things in C++ too, with the speed that C++ provides us. You can never have too many libraries, as long as they are well documented and categorized.

I believe Christian's response may have more to do with Boost's monolithic nature. It isn't currently possible to say "I need shared_ptr and Boost.Unordered and any necessary dependencies" -- the user must install all of Boost, which is daunting if not as difficult as it first seems. This goes against the C++ philosophy of "you only pay for what you use". This problem will only get worse as Boost accumulates more libraries.

I also want more libraries (so here's my -1), and I've used Java largely on the strength of its standard library (especially Swing). In fact, I want them even if it makes Boost large and unwieldy. But I think making Boost modular would do a great deal to assuage the fears of those who would rather be more selective.

--Jeffrey Bosboom _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I think what has to be done is that boost needs to be able to be seen as the STL/MFC/ATL/etc by its potential users. If you look at the complexity of the libraries shipped w/ visual studio, I think you might see similar complexities as to what boost has, the difference is that the user has to do absolutely nothing but install visual studio to gain access to everything. Linux distros have similar painless installations of C++ standard libraries too. I'll give an example of how things shouldn't be. I consider myself a pretty advanced windows user, I have a couple of scripts and a standard setup for configuring boost the way I want on windows. However, when I moved to linux (where i have 0 experience) I tried to set up the same configurations for boost there, however, whenever I built the debug version of the library and installed it, it overwrote the optimized versions. So I gave up pretty quickly and moved on to other more important things.

On 11/25/2009 08:28 AM, Christian Schladetsch wrote:

My base point is about complexity. Boost is complex, and it has some complex inter-dependencies. A lot of those are around the parser and lexer (spirit etc).

There are some boost libraries like boost::pool which are basically unsupported.

Lastly, there are some boost libraries that use a large set of other boost libraries and hence are fragile to external changes. Boost::container is one of these.

Now, to my comment about "+1 to make it harder to add a boost library". I stand by it, even as I agree that there should be more C++ libraries.

But, there should not be more boost libraries. If anything, there should be less boost libraries. Every one added, adds non-linearly to the overall complexity of boost.

I agree to all of this. We have talked quite a bit about boost's monolithic nature and the technical complexities this incurs. But I think the issues run deeper. If we would stop thinking of boost as one entity, it would be easier to see how different libraries (now 'boost components') are in different shape as far as maintenance is concerned. Some are well supported, widely used, or still being developed. Others were dropped into boost and never touched again. (Some just work and don't need any fixups, others less so, but the author(s) disappeared, and now the library has become a legacy, for the rest of boost.) In short: There is a great variability in technical and non-technical aspects of boost components, which IMO suggest that running them as individual projects would be beneficial to everybody. I believe this could all be done within the Boost.org umbrella, but with more autonomy to sub-projects. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Coming from a game-dev background I think I have something to add here. It may be surprising, but traditional game development, rather than being all glamorous and using the latest technology, is quite the opposite. Sure, we use the latest hardware and API's, but those API's are often written in C, or, lately, very conservative C++. No game middleware that I am aware of uses even STL let alone boost. I worked at EA for a while, and they had their own version of STL called EASTL. Why? Because it is all about the known versus the unknown. C is known. Basic C++ (without vtbls and templates) is known. You can get any super-smart kid off the street with a C background and he'll be very comfortable with the latest and greatest game software. No meta required (or desired). Again; Why is that? Why is it that the game development community, lauded for being on the bleeding edge, rejects what we would call modern C++? How can we build all this quite obviously complicated software without the latest and greatest methodologies? Thanks for bearing with me to my punchline: the gamedev community only cares about results and deadlines. They don't have time to risk new things until and unless they have become ubiquitous. As an aside, back in 94 when I started, I remember having an argument with my seniors about the use of C in gamedev. Apparently, C was too high-level; it used the stack too much for 'every single function call'. Later I had a similar argument about using C++ virtual methods; and later still and far more recently I've had arguments about RTTI and exceptions. Sometimes I've been swayed. Back to my point and this thread. Adding new things has a cost. This cost is not always obvious. Boost has suffered from the opposite of the game-dev scenario: rather than being too conservative, boost has been too liberal and academic. Where gamedev eschews fancy meta-programming for a basic bison or ANTLR script or fast and accurate and specific solutions, and while it does actually care for cross-platform support[1], boost is necessarily confined to the pure C++ model and genericity. Again, it seems plausible for boost to introduce a formal staging namespace such as boost::stage or boost::sandbox. Everything in boost:: would be known and correct across all tested configurations. boost::stage would be known to contain experimental or less-than-two-releases-old source. Call it boost::t_minus_2 or something; the main point is that change is costly, and it is good practice to stage it. Regards, Christian [1] This may be a surprising sentiment; but game-dev is not really concerned with cross-platform development in general. Rather, we either make a platform that you use or more likely just #idef the two platforms supported. Yes, it gets ugly. But it's uglier to try to create a synthesised platform that tries to expose the properties of both without compromising either. On Thu, Nov 26, 2009 at 2:56 AM, Raymond Wan <r.wan@aist.go.jp> wrote:

Hi all,

Stefan Seefeld wrote:

...

In short: There is a great variability in technical and non-technical aspects of boost components, which IMO suggest that running them as individual projects would be beneficial to everybody. I believe this could all be done within the Boost.org umbrella, but with more autonomy to sub-projects.

Perhaps just stating the obvious, but in response to earlier comments by others about how other languages have many libraries, Perl's CPAN has the modules all separated and can handle dependencies well so that only they are downloaded. I've actually heard people say that they do not want to use boost because "it is so large" and "I don't want to download it all just to use one part of it". Actually, the more likely comment is "I don't want to use it so that my users will have to download all of it"

Personally, there are many boost libraries that I know I will never use but I don't mind installing them since the space they occupy is nothing compared to my core files :-P . But for many others, I wonder if this monolithic nature of boost could hurt it as it gets larger and larger...

Of course, this is hard to do...but maybe in the short run, it would be nice to:

* indicate for each library what other library it depends on or recommends

* assign a status to each library indicating how well it is maintained or its stability and if it needs help

Is there some kind of "gantt chart" on boost.org that has the version numbers along the x-axis and each library on the y-axis and a dots showing when it was updated [perhaps colored to show if the updates are minor or major -- could break software that uses it]. Might be an interesting first step?

Ray

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2009/11/26 Christian Schladetsch <christian.schladetsch@gmail.com>

Coming from a game-dev background I think I have something to add here.

It may be surprising, but traditional game development, rather than being all glamorous and using the latest technology, is quite the opposite. Sure, we use the latest hardware and API's, but those API's are often written in C, or, lately, very conservative C++.

No game middleware that I am aware of uses even STL let alone boost. I worked at EA for a while, and they had their own version of STL called EASTL.

I've worked in the game industry for past ten years, and even if I have a background in the assembler swamp I can't argue today that it's productive. We're using boost libraries everywhere, from shared_ptr, function, bind,algorithms, regex, filesystem,multiindex, etc, etc. These are easy libraries, but we also use a bunch of traits usage, mpl, asio (our main network backend is all asio, who can say it's efficient to write network code without it) and the past few years fusion has become a life-safer. I hate to see that our middle end engine have reinvent the same broken wheels over and over that we need fixing with modern c++, and having trivial tasks solved in an extremely complex and often inefficient way. Still it's one of the few 'giants', with a giant price tag to it.

Again; Why is that? Why is it that the game development community, lauded for being on the bleeding edge, rejects what we would call modern C++? How can we build all this quite obviously complicated software without the latest and greatest methodologies?

It's a mystery, I agree. Because people are working overtime too much I guess. Personally I don't think it's bleeding edge, except from the graphics side which is being pushed by numbers of transistors and the somewhat organized effort of nVidia and Microsoft (on PC, at least).

Thanks for bearing with me to my punchline: the gamedev community only cares about results and deadlines. They don't have time to risk new things until and unless they have become ubiquitous.

As a result the gamedev community has horrible code, at best, and therefor development time isn't exactly short and thirdparty libraries very expensive. I was surprised first time I read about EASTL, it seemed like the only sane effort in years (solving typical gamedev related concerns in a reusable generic way). I truly dislike the game industry's general approach to software development, it's inefficient, expensive, and doesn't lead anywhere. Whenever we integrate a new third party library we need to wrap it to become usable. How many IFile have I wrapped in my life, just because companies can't read up on how to implement streambuf? They save time but waste mine. Their pricetag reflects the amount of work as well, since everything is nicely 'handcrafted' (i.e. expensive and likely buggy).

Boost has suffered from the opposite of the game-dev scenario: rather than being too conservative, boost has been too liberal and academic. Where gamedev eschews fancy meta-programming for a basic bison or ANTLR script or fast and accurate and specific solutions, and while it does actually care for cross-platform support[1], boost is necessarily confined to the pure C++ model and genericity.

You can never be too liberal. The more techniques added to the mix the

greater chance of finding ones typical problem already solved, and one can move on improving things instead. I think every game company out there, after having put their product out on the shelf, feels like: "ah, finally, this mess is out the door. Now let's start the next one from scratch and this time do it 'right'. " Except maybe for companies who need to maintain their code because they iterate their product titles over the years. Like EA, who probably figured they needed something like STL but with some additional requirements (they mostly reworked the allocators, I think?). My 2 gamedev cents, Christian

On 25 Nov 2009, at 13:28, Christian Schladetsch wrote:

Perhaps boost needs a practical, staged boost::ex:: or boost::sandbox namespace. I do not think such would really help in the long term, but it may help over the next decade. But we also know that such would probably cause far more troubles than it could solve. Which is sad.

I wonder if the solution could be more of a presentation issue. One problem with the boost sandbox is that it is extremely non-user friendly, it is basically just a directory dump with various packages, with little description of what is going on with them. I suspect very users would dig around in there to find packages. Perhaps a better design would be to introduce a more organised sandbox, which provides a web page and on-line documentation for each package. This would (in my opinion) make sandbox libraries much more accessible and useable, making it (hopefully) easier for them to grow and encourage them to become finished libraries, in particular with full boost-style documentation. Chris

2009/11/25 Thomas Klimpel <Thomas.Klimpel@synopsys.com>:

Christopher Jefferson wrote:

...

Perhaps a better design would be to introduce a more organised sandbox, which provides a web page and on-line documentation for each package. This would (in my opinion) make sandbox libraries much more accessible and useable, making it (hopefully) easier for them to grow and encourage them to become finished libraries, in particular with full boost-style documentation.

To me, this sounds like https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction

Any page that requires I add an SSL exception to my browser is not "accessible and usable".

2009/11/25 Thomas Klimpel <Thomas.Klimpel@synopsys.com>:

Is this the only complaint you have with respect to this side, or will you come up with the next complaint after somebody spend some days work to solve this SSL issue?

After all, this was a discussion about content, not about a specific technical problem that man be important or not, but seems to distract from the main points of the discussion at the moment. Could we just assume that it may be possible to solve this specific technical issue, if it is really important?

Sorry, you're right, that was overly curt of me. I suppose my real issue is that so long as there's a "real" boost website, anything on the trac wiki feels like an implementation detail, and the SSL issue reinforces that view. I do, like I expect most others on the list, have an exception for it already. But then, where the page is hosted is again a technical issue, and not what you're asking about. As a user, I'm used to http://boost.org/libs/ having everything, and anything that's not easily findable from there I doubt I'd see. The page does help a bit, but doesn't give me much confidence that most of the libraries would be usable. For instance, what's the difference between "quite stable" and "stable"? Looking at the Submission Process, perhaps the "Preliminary Submission" could be made official in some way? Allow a sort of straw poll on usefulness of some sort (but not design or implementation) to get library ABC into boost/proposed/ABC, and add them into the main boost system, with *PROPOSED* warning tags where appropriate. While there, anyone interested could submit a review, with the formal review -- to remove remove the preliminary tag -- starting once a sufficient surplus of positive reviews were received. That would give people a concrete way to contribute to getting a proposed library into main even without a manager or scheduled date. The library would also have been out in the wild for a release cycle, and that copy -- that everyone has installed and had the opportunity to use -- would be the one reviewed. It would also reduce the pressure on the formal review manager, as a "no" is less severe, since it's still out there for those interested to use. It feels like the results are often "yes, but you have to address [2 pages of requested changes]" recently that would be clearer as a "no, but we're interested" if not for the negative connotations. I also like the idea of a core set of some sort, granted through interface and implementation stability and by other libraries. That's enough musings for now, I guess.

On Nov 24, 2009, at 11:40 AM, Michael Caisse wrote:

Robert Ramey wrote:

...

Christian Schladetsch wrote:

...

+1 for making it harder to add a new library to boost.

There are already too many libraries.

-1 for making it even harder to add a new library to boost.

Boost and C++ doesn't have anywhere near enough libraries.

Robert Ramey

+1 to Robert's -1 (o;

I've got to go with Robert here. I just wrote a bunch of python code and used libraries to parse URLs, generate HTML, talk to MySQL, write CGI handlers, handle exceptions, parse MIME messages, generate XML (off the top of my head). Where are the modern C++ versions (good generic interfaces, well tested, source code available) of libraries to perform these tasks? More libraries, please. -- Marshall