On Mon, 3 Sep 2012, Jürgen Hunold wrote: (snip)

...

Given these numbers, I think I have to abandon any thoughts of using Boost within my current company. There's no way I'm going to get approval to bring so much code into our work just to get a SmartPtr or FIleSystem library. This is unfortunate, because due to Boost's existence there doesn't seem to be much work going on out there to offer lighter weight alternatives.

Well, SmartPtr is in c++11. But this is out of reach for most people, I guess.

It is also in TR1, which might be more accessible. -- Jeremiah Willcock

From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jeffrey Lee Hellrung, Jr. Sent: Monday, September 03, 2012 10:58 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?

On Sun, Sep 2, 2012 at 10:43 PM, steve@parisgroup.net <steve@parisgroup.net> wrote: Greetings, As a veteran C++ programmer, I've been an admirer of the Boost library for many years.  I've > used it at a number of companies I've worked for, especially the SmartPtr library. Right now I'm working for a company that worries a lot about negative exposure to Open Source software issues such as questions that might arise about authorship, copyright or > > even patent issues.  The company does allow the use of Open Source software, but it requires >that each piece of code that is brought in first be justified and vetted.  Unfortunately, I'm >finding this to be a nearly impossible task when I look at the amount of code that must be >compiled to use the Boost modules I'm interested in.

I don't think that you can avoid using all-of-Boost or none-of-Boost. There are very good reasons for the co-dependency. Concentrate your arguments on the massive benefits you are getting? Boost has put a lot of effort into making sure that all files (including documentation and graphics) contain an authors' copyright claim notice (and that it is a correct claim - and have rejected items for which this was not possible). (There is a 'sinners list' at http://boost.cowic.de/rc/inspect-trunk.html - so you can check the few libraries and files that do not conform. Don't panic at the number of items missing - few are actual C++ code - most are in documentation and examples). Although it is unlikely that any code contains patentable concepts, it is not possible to be sure until this is tested in the courts. Boost would not knowingly provide software that is patented without marking it as such clearly. Because Boost is a leader in software development, that a library is accepted for Boost makes it very much less likely that it is already patented, and the code being placed in the public domain may provide evidence of 'prior art' to thwart future attempts to obtain a patent. Finally, there are very many companies using Boost and none, to my knowledge, have reported getting into trouble so far. You will need to work to get a blanket acceptance of the all Boost libraries? HTH Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

On Sep 5, 2012, at 2:29 PM, Jens Müller <blog@tessarakt.de> wrote:

Am 04.09.2012 18:16, schrieb Paul A. Bristow:

...

Because Boost is a leader in software development, that a library is accepted for Boost makes it very much less likely that it is already patented, and the code being placed in the public domain may provide evidence of 'prior art' to thwart future attempts to obtain a patent.

Do you have formal escrow procedures for that?

To proof mere existence in a legally sustainable way, it would be sufficient to apply cryptographically signed timestamps.

German law provides for "qualified timestamps" (§ 9 Signaturgesetz). I think they are based on European directives. What I don't know is whether there are similar concepts in other important jurisdictions such as the US.

No, Boost does not. We've got svn history (and before that, cvs), and a whole slew of mailing list archives. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

I have not been through the Boost source but I have gone through other open source code in this kind of process. It is amazing how much code exists that still has comments like “Property of ...” or “Copyright ....” regardless of the general say GPL license for the project source. The person providing the code means well but may not understand the legal ramifications. Algorithms may be patented (such as some crypto ones) so unless the open source project provides a method of ensuring such code is not included when it is built you might have to get a license to use the project. The copyright registration in the US at least requires the names of all contributors and their involvement. If you contribute it needs to be clear that you have the right to contribute as some companies may assert rights through employment agreements even if it is not directly in your job scope. If a company uses open source code without due diligence to the origin of code the results could be patent infringement litigation, substantial licensing fees, a required change to a company’s product to remove functionality related to the open source code, and/or other similarly unpalatable options. Larry From: Sebastian Redl Sent: Tuesday, September 04, 2012 3:15 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it? On 03.09.2012 07:43, steve@parisgroup.net wrote: Greetings, Right now I'm working for a company that worries a lot about negative exposure to Open Source software issues such as questions that might arise about authorship, copyright or even patent issues. The company does allow the use of Open Source software, but it requires that each piece of code that is brought in first be justified and vetted. Leaving the issue of Boost's structure aside, how does this vetting process even work? I can maybe see someone looking over the code to look for well-known patented software patterns (Does anyone know such? I can't think of any outside of lockfree programming.), but how on earth would you verify authorship or copyright, beyond what the file says? Do you scan the commit history of the files? Also, what's the point? The code is released by everyone who contributed to it under the liberal Boost license. You won't find any comments or commit messages to the point of "oh, by the way, this isn't under the BSL". Or maybe someone who looks it over is expected to find similarities to other software, which isn't under the BSL? This is, in my opinion, completely impossible - there's just way too much code out there to compare to to make any significant difference. How would that look in court? "Yeah, these people claim that Boost contains some of their GPL code, but when we decided to use Boost, we compared its code to 0.0001% of the GPL code in existence (a generous estimate) and didn't find similarities, so we shouldn't be liable!" Maybe you can find a way to convince your boss that the policy just doesn't make sense. Sebastian -------------------------------------------------------------------------------- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Am 04.09.2012 20:29, schrieb Robert Ramey:

a) don't use "convenience headers" which suck in all the headers in a library rather than just the one's used.

I've read an advice on the mailing list that boost libraries should provide a 'all.hpp' (containing all headers of the library). Is it not recommended any more?

Lars Viklund wrote:

On Tue, Sep 04, 2012 at 07:38:41PM +0200, Oliver Kowalke wrote:

...

Am 04.09.2012 20:29, schrieb Robert Ramey:

...

a) don't use "convenience headers" which suck in all the headers in a library rather than just the one's used.

I've read an advice on the mailing list that boost libraries should provide a 'all.hpp' (containing all headers of the library). Is it not recommended any more?

I'd say they serve two different types of crowds. There's the people that care about dependencies and build times, and there's the people that want to pull in everything for proof-of-concept or exploratory coding without looking up everything constantly in documentation.

It would be a major disservice to the latter kind if there was no boost/foo/kitchen_sink.hpp for library foo.

OK - we can compromise on this point. Authors can provide convenience headers for this type of user ...

There's an additional reason as to why some people include all-headers, and that's documentation that doesn't clearly mention in which headers different functionality exists.

while at the same time (re)organizing the documentation and code to support the inclusion of only necessary code.

There's some Boost libraries that are completely implicit about which headers contains what parts, which makes it some major guesswork to get the bits and pieces you want included, especially if you do not have #include-completion in your editor.

Which is a source of the problems that the original poster is noting. Let's update code/dcoument/review guidlines to include these considerations. Robert Ramey

On Wed, Sep 05, 2012 at 07:13:05AM +0200, Vicente J. Botet Escriba wrote:

Le 05/09/12 00:10, Lars Viklund a écrit :

...

There's some Boost libraries that are completely implicit about which headers contains what parts, which makes it some major guesswork to get the bits and pieces you want included, especially if you do not have #include-completion in your editor.

As for example ...

My statement was what I subjectively felt during hacking sprees when I know what I want, but can't readily find where it's located when reading about it in the main body of the documentation. Going through the libraries, it seems to be mostly a matter of lack of such detail in the prose non-reference sections, particularly around the sections that introduce a new concept and for the inline samples, like: * Bimap tutorial; * Chrono user's guide; * Concept; * Context only has "include all.hpp or the individual headers", with no reference listing of headers and types at all; * Filesystem v3 only documents top-level filesystem.hpp and filesystem/fstream.hpp; * Iterator - the only mention of headers at all is in the top-level bullet points for a few of the types; * Lambda has a brief listing in Installing, but nothing in-line; * Locale doesn't mention headers by name, but as it's Doxygenish, it links most names to the header page where they live. * MSM doesn't even mention any all-header, it just seems to assume you know exactly what headers to use, and the reference section is flat; * MPL tutorial; * NumericConversion's only mention of any headers is in examples for the sections; * Parameter has a decent set of cross-referenced docs, once you find it under section 7 - until that point no mention of the headers exists; * PointerContainer lacks header mentions in both the tutorial and the reference, with the latter surprising as the reference doesn't contain any header information at all, instead having to go to the non-common 'Library headers' section; * Polygon seems to be completely lacking any header information whatsoever; * ProgramOptions - no mention in the tutorial, overview or howto; * PropertyTree - reasonably straightforward based on the names of the headers in the reference; prose rarely links typenames to the right headers; * Range separates the reference and the header structure; confusing if you've finally gotten used to information being in the reference section; * Test only mentions headers occasionally in samples, I've yet to find anything standalone talking about includes at all, except for the unrecommended standalone header; * Thread lacks an overview of the headers, mentioning them occasionally in the reference - I just give up and use the all-header; * Wave has no top-level index, but the few sections mention all headers by name and synopsis and links to (disabled in Trac) trunk versions of the headers; The libraries that use qbk-style documentation tends to be pretty acceptable, as the common style means that you get a list of headers on the landing page for the library. While not optimal while reading, it's at least something. This might not be a major problem if you're willing to manually cross-reference the reference sections when reading the tutorial/guide/introduction sections in which is where the meat of the documentation usually is located, but it feels quite the wrong way around to dive into header listings to find the type/concept you want, when the main body of documentation around it is in the prose. On an unrelated note, the next time I have to use the expandos in the Iostreams or Serialization documentation, I'm going to cry. They're such fiddly and tiny targets, so unfriendly that I think more than once about using the library due to the inaccessibility of the documentation. Now that I've insulted practically every single Boost author, let me say "good job, everyone". The level of documentation in Boost is way better than what you usually see out in the wild, it's just that it's quite easy to feel disorientated. -- Lars Viklund | zao@acc.umu.se

On Wed, Sep 05, 2012 at 09:23:34AM -0800, Robert Ramey wrote:

Lars Viklund wrote:

...

On an unrelated note, the next time I have to use the expandos in the Iostreams or Serialization documentation, I'm going to cry. They're such fiddly and tiny targets, so unfriendly that I think more than once about using the library due to the inaccessibility of the documentation.

Hmmm - would just making these bigger address your concern here? That would be easy to fix - just add a track item.

I'm afraid that larger targets might space out the items too much.

Or is it the whole concept of using the navigator. Note that the serialization library has the index at the top of each page just as all the other libraries do. Maybe just supressing the navigator panel would be more to your taste. In Firefox at least. one can right click to open a frame in a new window at which point - as far as I can tell - it would be the same as every other boost library.

A few things that might make it slightly more accessible: * Have an "expand-all" button to expand everything, which would make the sidebar much more similiar to the typical Boost library landing page. For Serialization, expanding everything is at most two screenheights or so, which is quite manageable and scrollable. * If the sidebar becomes hideable, the documentation pages themselves would need some prev/up/next navigation doohickeys. * If the sidebar becomes hideable, there ought to be a top-level page that contains the ToC. Of these things, the "expand-all" and bigger twiddle targets would likely be among the easier, while the other two would require a lot more work.

I included the "expando" after the fact since I found it excedingly tedious to navigate complex documentation through the pages themselves

It's an interesting idea and helps a lot with having to go back-and-forth between the top-level page and any subpages of interest. The downside is that it's hard to open a part you're interested in a new tab/window and retain the sidebar frame. One of the bothersome things about S11n/Iostreams documentation is that it's impossible to link someone a subpage on IRC or on mail while retaining the sidebar. -- Lars Viklund | zao@acc.umu.se

...

Of these things, the "expand-all" and bigger twiddle targets would likely be among the easier, while the other two would require a lot more work.

These are in fact not too hard. I'll consider it.

It turns out that I've been sucked in to spending time learning about XSLT, XML editors, DocBooK, BoostBook. etc. So I've considered re-formating the serialization documentation in terms of BoostBook which would address all he the above and give the serialization library documentation a more up date look compatible with the other boost libraries.

BUT - I would lose the navigator - which I'm actually in love with.

What I would really like is an XSLT script which would build a free-floating BoostBook Navigator which would navigate all the boost book docs. Of course it's usage would be optional.

Nice idea. Robert: the HTML in your navigator pane looks rather similar to the HTML in generated for the Boostbook TOC page, could your scripts be injected in without too much change? If so we would just need to tweak HTML generation to produce an extra TOC page along with the frames etc? BTW I really don't like those tiny graphics either. Also just noted that docbook can output web help, which looks rather nice: http://docbook.sourceforge.net/release/xsl/current/webhelp/docs/content/ch01... but appears to require Java client side? John.

John Maddock wrote:

...

...

Of these things, the "expand-all" and bigger twiddle targets would likely be among the easier, while the other two would require a lot more work.

These are in fact not too hard. I'll consider it.

It turns out that I've been sucked in to spending time learning about XSLT, XML editors, DocBooK, BoostBook. etc. So I've considered re-formating the serialization documentation in terms of BoostBook which would address all he the above and give the serialization library documentation a more up date look compatible with the other boost libraries.

BUT - I would lose the navigator - which I'm actually in love with.

What I would really like is an XSLT script which would build a free-floating BoostBook Navigator which would navigate all the boost book docs. Of course it's usage would be optional.

Nice idea. Robert: the HTML in your navigator pane looks rather similar to the HTML in generated for the Boostbook TOC page, could your scripts be injected in without too much change? If so we would just need to tweak HTML generation to produce an extra TOC page along with the frames etc? BTW I really don't like those tiny graphics either.

Also just noted that docbook can output web help, which looks rather nice: http://docbook.sourceforge.net/release/xsl/current/webhelp/docs/content/ch01... but appears to require Java client side? John.

On 06 September 2012 18:54 Robert Ramey [mailto:ramey@rrsd.com] wrote :-

Hmm - worthy of investigation. Any such Navigator is goint to require Javascript. I don't see this is a downside.

a) Javascript is pretty ubiquitous b) The usage of the "navigator" is optional c) It doesn't take away anything we already have.

According to http://www.boost.org/development/requirements.html#Documentation " The format for documentation should be HTML, and should not require an advanced browser or server-side extensions. Style sheets are acceptable. ECMAScript/JavaScript is not acceptable." Not sure quite why such a explicit refusal of javascript but I imagine there were (at least) good reasons for this so may be worth some discussion to see if the reasons are still extant before doing any work. Alex

Hi. 2012/9/4 Oliver Kowalke <oliver.kowalke@gmx.de>:

I've read an advice on the mailing list that boost libraries should provide a 'all.hpp' (containing all headers of the library). Is it not recommended any more?

I think that the mere existence of all.hpp files is not the problem here. What should be avoided is to use these all.hpp files within boost itself as that would unnecessarily enlarge the dependency tree. But then, I do not know whether such include directives currently exist within boost. Ingolf

Neil Groves wrote:

This is a legitimate concern which IMO has not been taken seriously by the Boost community.

Why do you think this is not being taken seriously? I'm under the impression that there is disagreement as to the real priority of this concern. I think that is quite different.

I was specifically refering to the recent discussion of Boost Exception. I got "out voted" on that one which I characterized as having my "concerns not being taken seriously". If you prefer to say "disagreement as to real priority" I'm fine with that. I don't think we're disagreeing here.

To some extent it's unavoidable since it's more efficcient to have one "best" solution imported everywhere rather than replecating code.

But it doesn't have to be as bad as it currently is. And it's only getting worse as more libraries get added to Boost.

Again why is it 'Bad'? This is re-use in most examples I have seen. Coupling isn't inherently bad. Re-use is coupling.

OK - maybe 'bad' is the wrong word. As new libraries get added they depend on previous libraries. It's generally a good thing that code not be repeated. But it makes it more likely that a library user is importing stuff that might surprise him. This is unfortunate (bad) but unavoidable. It's "bad" when the library author includes surprising and or unnecessary dependencies. These bite the user with unexpected behavior like a) much bigger executables than expected b) new requirements like multi-threading c) breakage from updates of seemingly unrelated components.

Specific examples of poor coupling most probably exist. I suspect these would receive a good response from the Boost development community if these were specifically raised.

In many cases there is disagreement what "poor coupling" is.

Did you complain about them in trac tickets that have not been resolved?

This is not an issue regarding bugs. There are differences of opinion regarding library design and approriate functionality and requirements. This differences are reconciled as best we can through the review process.

b) Consider eliminating "convenience" headers.

I think the Boost library authors are good at choosing the right level of headers to include. Do you have some specific counter-examples?

I don't think that "convenience headers" all that bad. As a user, I'm free not to use them (and I don't). BUT - a) I think they encourage practices among users that I don't think are good ones. b) I don't think they are really necessary. The serialization library - a big library - has never had them and no one has ever asked for them. c) It's trivial for users to make their own if they want them.

I definitely took the approach of using convenience headers in examples. I did this because the header files were not the primary focus of the example code. The convenience header in my examples provides code that works while reducing clutter in my example.

d) I understand this. But I see it differently. If one has to use convenience headers to make the examples simple enough to understand, I would consider the possibility that the library might be made clearer and easier to use by refactoring the headers..

Perhaps instead we could provide additional guidance as to how to use the layers of header files.

I think that is one of the things I'm proposing here.

However this seems trivially obvious.

lol - then I guess it will be easy to agree on how to it Robert Ramey