Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder? http://scan.coverity.com/ Boost and Boost.Build are both listed in Rung 0, so it appears that the only step left is selecting a Boost/Coverity liaison. http://scan.coverity.com/newproj.html --Michael Fawcett
At 3:02 PM -0500 2/3/09, Michael Fawcett wrote:
Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder?
Boost and Boost.Build are both listed in Rung 0, so it appears that the only step left is selecting a Boost/Coverity liaison.
I don't have a problem signing up as a laison and helping people get stuff fixed, but I think that someone with a bit of legal training needs to look at the license that Coverity wants people to agree to before using the scan results. [ It looks pretty harmless to me, but IANAL ] <http://scan.coverity.com/policy.html#license> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
Marshall Clow wrote:
At 3:02 PM -0500 2/3/09, Michael Fawcett wrote:
Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder?
Boost and Boost.Build are both listed in Rung 0, so it appears that the only step left is selecting a Boost/Coverity liaison.
I don't have a problem signing up as a laison and helping people get stuff fixed, but I think that someone with a bit of legal training needs to look at the license that Coverity wants people to agree to before using the scan results. [ It looks pretty harmless to me, but IANAL ]
Well, since you brought up the issue... I'm not a lawyer either, but I'd *not* agree to anything like: Coverity may, in its sole discretion, modify or revise these terms and conditions and policies at any time, and you agree to be bound by such modifications or revisions. That's the fourth line of text, and I quitted reading. (Does this have a name? "You'll agree with me for the eternity, whatever I'll say"... Perhaps "The God Almighty Pact"?) -- Genny
Gennaro Prota wrote:
Well, since you brought up the issue... I'm not a lawyer either, but I'd *not* agree to anything like:
Coverity may, in its sole discretion, modify or revise these terms and conditions and policies at any time, and you agree to be bound by such modifications or revisions.
That's the fourth line of text, and I quitted reading. (Does this have a name? "You'll agree with me for the eternity, whatever I'll say"... Perhaps "The God Almighty Pact"?)
"Cheque Blanque" :-( Sebastian
on Tue Feb 03 2009, Gennaro Prota <gennaro.prota-AT-yahoo.com> wrote:
Well, since you brought up the issue... I'm not a lawyer either, but I'd *not* agree to anything like:
Coverity may, in its sole discretion, modify or revise these terms and conditions and policies at any time, and you agree to be bound by such modifications or revisions.
That's the fourth line of text, and I quitted reading. (Does this have a name? "You'll agree with me for the eternity, whatever I'll say"... Perhaps "The God Almighty Pact"?)
Wow, that's pretty draconian, I must say! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Tue Feb 03 2009, Gennaro Prota <gennaro.prota-AT-yahoo.com> wrote:
Well, since you brought up the issue... I'm not a lawyer either, but I'd *not* agree to anything like:
Coverity may, in its sole discretion, modify or revise these terms and conditions and policies at any time, and you agree to be bound by such modifications or revisions.
That's the fourth line of text, and I quitted reading. (Does this have a name? "You'll agree with me for the eternity, whatever I'll say"... Perhaps "The God Almighty Pact"?)
Wow, that's pretty draconian, I must say!
Their terms or my take on them? :-) -- Genny
Well, since you brought up the issue... I'm not a lawyer either, but I'd *not* agree to anything like:
Coverity may, in its sole discretion, modify or revise these terms and conditions and policies at any time, and you agree to be bound by such modifications or revisions.
That's the fourth line of text, and I quitted reading. (Does this have a name? "You'll agree with me for the eternity, whatever I'll say"... Perhaps "The God Almighty Pact"?)
Wow, that's pretty draconian, I must say!
None the less quite a number of very well known projects seem to have accepted it: perl, gcc, gdb, tcl etc etc. Personally I *would* rather like to see Boost put through a static analysis tool on a regular basis: so I'm wondering if we should bite the bullet and sign up for this? John.
On Wed, Feb 4, 2009 at 8:16 AM, John Maddock <john@johnmaddock.co.uk> wrote:
None the less quite a number of very well known projects seem to have accepted it: perl, gcc, gdb, tcl etc etc.
Personally I *would* rather like to see Boost put through a static analysis tool on a regular basis: so I'm wondering if we should bite the bullet and sign up for this?
John.
I've researched Coverity in the past (and taken a class from one of the founders), and was convinced enough of its usefulness that I had planned on proposing that Boost sign up. I believe it would help improve the correctness and security of the code, which would certainly increase usage of Boost at my place of employ. Jeremy Pack
Gennaro Prota wrote:
Marshall Clow wrote:
At 3:02 PM -0500 2/3/09, Michael Fawcett wrote:
Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder?
Boost and Boost.Build are both listed in Rung 0, so it appears that the only step left is selecting a Boost/Coverity liaison.
I don't have a problem signing up as a laison and helping people get stuff fixed, but I think that someone with a bit of legal training needs to look at the license that Coverity wants people to agree to before using the scan results. [ It looks pretty harmless to me, but IANAL ]
Well, since you brought up the issue... I'm not a lawyer either, but I'd *not* agree to anything like:
Coverity may, in its sole discretion, modify or revise these terms and conditions and policies at any time, and you agree to be bound by such modifications or revisions.
That's the fourth line of text, and I quitted reading.
That's not great, is it? But if you read on a bit further a more practical problem becomes apparent (if I have understood it correctly): the person who registers with them is allowed to see the analysis but they're not allowed to reveal it to anyone else (e.g. by posting to this list), except indirectly by posting the bug fixes. I can see that that might work for some projects, but for a collection of sub-projects like Boost where no-one has expert understanding of everything, it doesn't seem appropriate. For what it's worth, I do believe that their tool does useful things. For example I guess that it could have found the bug in interprocess::sp_counted_impl.hpp that was reported a few days ago. Phil.
That's not great, is it? But if you read on a bit further a more practical problem becomes apparent (if I have understood it correctly): the person who registers with them is allowed to see the analysis but they're not allowed to reveal it to anyone else (e.g. by posting to this list), except indirectly by posting the bug fixes. I can see that that might work for some projects, but for a collection of sub-projects like Boost where no-one has expert understanding of everything, it doesn't seem appropriate.
I guess we would need a team of people willing to triage issues flagged up and then make contact with the appropriate library author: I'm guessing that while they cannot reveal the exact information provided by coverity they could say "there appears to be a potential buffer overrun on line #, can you please look into it?". John.
On Wed, Feb 4, 2009 at 11:23 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I guess we would need a team of people willing to triage issues flagged up and then make contact with the appropriate library author: I'm guessing that while they cannot reveal the exact information provided by coverity they could say "there appears to be a potential buffer overrun on line #, can you please look into it?".
I didn't see a limit on the number of project members you could sign up, so potentially all library authors could be members.
From here: http://scan.coverity.com/faq.html#who
"Who can have access? Access to the detailed analysis results is permitted only to members of scanned projects, partially in order to ensure that potential security issues may be resolved before the general public sees them. Our approach is that of Responsible Disclosure. We provide the analysis results to project developers only, and do not reveal details to the public until an issue has been fixed. A portion of the defects discovered by the Scan could reveal exploitable security vulnerabilities." --Michael Fawcett
Michael Fawcett wrote:
Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder?
Because there's already enough nonsense to show off on the site's corners? :-) -- Genny
On Tue, Feb 3, 2009 at 5:15 PM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Because there's already enough nonsense to show off on the site's corners? :-)
Do you mean Coverity's or Boost's site? I'm not familiar with Coverity at all. If you meant Coverity, is it consensus that it's nonsense? --Michael Fawcett
Michael Fawcett wrote:
On Tue, Feb 3, 2009 at 5:15 PM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Because there's already enough nonsense to show off on the site's corners? :-)
Do you mean Coverity's or Boost's site?
Boost ("most expertly designed in the world", etc.)
I'm not familiar with Coverity at all.
First time I hear of it, too :-) From a quick (as in "uninterested") glance at their site, they seem yet another "provider of nothing" trying to make a name for itself (and go from there to make money). It may well be that adding a "Coverity certified" or anything like that to the Boost home page will convince more people to "buy"; it's likely in fact (I hate to say it, but a lot of the people who gravitate around OSS are amateurs, and are easily excited). Personally, I still dream of a world were software quality is quality, not labels or marks. FWIW, nobody in Boost does anything about unnamed namespaces in include files, for instance. In fact, nobody looks at the inspection report (it would have been the quickest way to notice the new CMake files :-)). Most (all?) of Boost relies on Boost Testing, which is one of the most complex sub-libraries, and one where I've seen some of the worst engineering practices applied. The "new" lexical_cast is a close friend, and there are simply authors who don't know where the house of simplicity is (looking at the source code of one of the tools I found boost::tuple used --which in turn meant type_traits, which in turn meant mpl, lambda and God knows what-- when std::pair would just do). I could continue for hours, really (but please don't ask). At the end of the day, nobody is going to complain to anyone, because everything is "volunteer contribution". That may be humanly understandable, but don't expect to have quality in this kind of ecosystem ("patches are welcome", "if you notice anything wrong you can fix it" are easy escapes: you don't produce solid software by trial and error, nor you can really fight the mentality of an overwhelming majority). If you like, you can put it this way: Boost is no better than Wikipedia. I find Wikipedia useful, but I also find errors (or completely insane entries) every time I read it. -- Genny
----- Original Message ----- From: "Gennaro Prota" <gennaro.prota@yahoo.com> To: <boost@lists.boost.org> Sent: Wednesday, February 04, 2009 10:38 AM Subject: Re: [boost] Coverity Static Code Analysis
Michael Fawcett wrote:
On Tue, Feb 3, 2009 at 5:15 PM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Because there's already enough nonsense to show off on the site's corners? :-)
Do you mean Coverity's or Boost's site?
Boost ("most expertly designed in the world", etc.)
It may well be that adding a "Coverity certified" or anything like that to the Boost home page will convince more people to "buy"; it's likely in fact (I hate to say it, but a lot of the people who gravitate around OSS are amateurs, and are easily excited). Personally, I still dream of a world were software quality is quality, not labels or marks.
What matters is not the "Coverity certified" but if the warnings signaled let you see you see a hidden bug.
FWIW, nobody in Boost does anything about unnamed namespaces in include files, for instance. In fact, nobody looks at the inspection report (it would have been the quickest way to notice the new CMake files :-)).
Well currently the inspection is much more for the form than the contents, so I understand that people is not interested. I look at on each release it. IMO tools such as coverity can be seen as test tools.
Most (all?) of Boost relies on Boost Testing, which is one of the most complex sub-libraries, and one where I've seen some of the worst engineering practices applied. The "new" lexical_cast is a close friend, and there are simply authors who don't know where the house of simplicity is (looking at the source code of one of the tools I found boost::tuple used --which in turn meant type_traits, which in turn meant mpl, lambda and God knows what-- when std::pair would just do). I could continue for hours, really (but please don't ask). At the end of the day, nobody is going to complain to anyone, because everything is "volunteer contribution". That may be humanly understandable, but don't expect to have quality in this kind of ecosystem ("patches are welcome", "if you notice anything wrong you can fix it" are easy escapes:
Hi, what about sending your std::pair patch for lexical_cats if you think that this can improve things? Best, Vicente
Gennaro Prota wrote:
Boost ("most expertly designed in the world", etc.)
It's a quote from someone which is quite known, it's not like it is being stated as being the truth. It's a bit catchy, still, but is nowhere near as bad as the Apple advertisements, for example.
The "new" lexical_cast is a close friend, and there are simply authors who don't know where the house of simplicity is (looking at the source code of one of the tools I found boost::tuple used --which in turn meant type_traits, which in turn meant mpl, lambda and God knows what-- when std::pair would just do). I could continue for hours, really (but please don't ask).
Is it that important than some libraries depend on basic building blocks, even when they could use less flexible building blocks with a simpler implementation? A pair is simply the tuple of the poor. Are you concerned with the time to compile the thing, or simply with dependencies?
At the end of the day, nobody is going to complain to anyone, because everything is "volunteer contribution". That may be humanly understandable, but don't expect to have quality in this kind of ecosystem ("patches are welcome", "if you notice anything wrong you can fix it" are easy escapes: you don't produce solid software by trial and error, nor you can really fight the mentality of an overwhelming majority).
What do you think the review system is for?
Mathias Gaunard wrote:
Gennaro Prota wrote:
Boost ("most expertly designed in the world", etc.)
It's a quote from someone which is quite known,
So?
it's not like it is being stated as being the truth.
Well, for it to be true it should make sense, first. What does "expertly designed" mean? Boost is a collection of components; there has been no "single design" anywhere (actually the only "design" choices affecting every component that come to my mind are terrible: e.g. those about the directory structure; or the usage of the same "detail" namespace for every library). And "expertly designed project" --as opposed e.g. to "expertly designed software"-- is simple nonsense to me.
It's a bit catchy, still, but is nowhere near as bad as the Apple advertisements, for example.
There's always someone who does worse :-) And everyone makes more or less ridicolous claims for quality (or conformity). In fact, the only quality I've seen is in projects where --by contract-- you pay money for defects and downtime (yes, let's stop calling it "bugs", as if they were pretty harmless annoyances making their occasional appearance here and there but with no substantial effect on a well working construction). What one would heartedly hope is for someone doing our job to be perfectly able to identify the false claims.
The "new" lexical_cast is a close friend, and there are simply authors who don't know where the house of simplicity is (looking at the source code of one of the tools I found boost::tuple used --which in turn meant type_traits, which in turn meant mpl, lambda and God knows what-- when std::pair would just do). I could continue for hours, really (but please don't ask).
Is it that important than some libraries depend on basic building blocks, even when they could use less flexible building blocks with a simpler implementation? A pair is simply the tuple of the poor.
I'm afraid that if I wanted to really reply to this I'd have to question your professional skills. Significantly. Which I don't want to do.
Are you concerned with the time to compile the thing, or simply with dependencies?
Are you aware of what dependencies imply?
At the end of the day, nobody is going to complain to anyone, because everything is "volunteer contribution". That may be humanly understandable, but don't expect to have quality in this kind of ecosystem ("patches are welcome", "if you notice anything wrong you can fix it" are easy escapes: you don't produce solid software by trial and error, nor you can really fight the mentality of an overwhelming majority).
What do you think the review system is for?
In Boost? Almost nothing. It depends on who happens to be around at the moment, who is interested in the library and how the review manager happens to judge all the feedback. And after something has been approved it can get completely changed without the slightest discussion (I'm speaking "against" myself here: I rewrote dynamic_bitset completely). And it isn't a review process; it's just an "if you have comments, please post". Many people will come up with good points but that's not the question. It remains that the whole thing is quasi-random. -- Genny
Perhaps you shouldbt use or follow boost since it appears so fraught with ill design and poor quality. I personally have found it otherwise. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Gennaro Prota <gennaro.prota@yahoo.com> Date: Wed, 04 Feb 2009 16:36:35 To: <boost@lists.boost.org> Subject: Re: [boost] Coverity Static Code Analysis Mathias Gaunard wrote:
Gennaro Prota wrote:
Boost ("most expertly designed in the world", etc.)
It's a quote from someone which is quite known,
So?
it's not like it is being stated as being the truth.
Well, for it to be true it should make sense, first. What does "expertly designed" mean? Boost is a collection of components; there has been no "single design" anywhere (actually the only "design" choices affecting every component that come to my mind are terrible: e.g. those about the directory structure; or the usage of the same "detail" namespace for every library). And "expertly designed project" --as opposed e.g. to "expertly designed software"-- is simple nonsense to me.
It's a bit catchy, still, but is nowhere near as bad as the Apple advertisements, for example.
There's always someone who does worse :-) And everyone makes more or less ridicolous claims for quality (or conformity). In fact, the only quality I've seen is in projects where --by contract-- you pay money for defects and downtime (yes, let's stop calling it "bugs", as if they were pretty harmless annoyances making their occasional appearance here and there but with no substantial effect on a well working construction). What one would heartedly hope is for someone doing our job to be perfectly able to identify the false claims.
The "new" lexical_cast is a close friend, and there are simply authors who don't know where the house of simplicity is (looking at the source code of one of the tools I found boost::tuple used --which in turn meant type_traits, which in turn meant mpl, lambda and God knows what-- when std::pair would just do). I could continue for hours, really (but please don't ask).
Is it that important than some libraries depend on basic building blocks, even when they could use less flexible building blocks with a simpler implementation? A pair is simply the tuple of the poor.
I'm afraid that if I wanted to really reply to this I'd have to question your professional skills. Significantly. Which I don't want to do.
Are you concerned with the time to compile the thing, or simply with dependencies?
Are you aware of what dependencies imply?
At the end of the day, nobody is going to complain to anyone, because everything is "volunteer contribution". That may be humanly understandable, but don't expect to have quality in this kind of ecosystem ("patches are welcome", "if you notice anything wrong you can fix it" are easy escapes: you don't produce solid software by trial and error, nor you can really fight the mentality of an overwhelming majority).
What do you think the review system is for?
In Boost? Almost nothing. It depends on who happens to be around at the moment, who is interested in the library and how the review manager happens to judge all the feedback. And after something has been approved it can get completely changed without the slightest discussion (I'm speaking "against" myself here: I rewrote dynamic_bitset completely). And it isn't a review process; it's just an "if you have comments, please post". Many people will come up with good points but that's not the question. It remains that the whole thing is quasi-random. -- Genny _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Perhaps you shouldbt use or follow boost since it appears so fraught with ill design and poor quality. I personally have found it otherwise.
I'm afraid that if I wanted to really reply to this I'd have to question your professional skills. Significantly. Which I don't want to do.
Guys, I'm not pointing any fingers, but please don't allow this to degenerate into a flame war. I'm sure there are many ways Boost can be improved, please focus on specific issues, and one would hope their solutions, rather than on blanket statements. Many thanks, John Maddock. (Boost Moderator)
{I posted this yesterday; apparently it got lost} John Maddock wrote:
Perhaps you shouldbt use or follow boost since it appears so fraught with ill design and poor quality. I personally have found it otherwise.
I'm afraid that if I wanted to really reply to this I'd have to question your professional skills. Significantly. Which I don't want to do.
Guys, I'm not pointing any fingers, but please don't allow this to degenerate into a flame war.
That's why I said "I don't want to".
I'm sure there are many ways Boost can be improved, please focus on specific issues, and one would hope their solutions
Which is the "patches are welcome", "if you notice anything wrong you can fix it" attitude I mentioned earlier. Don't fool yourself into believing that with enough time and contributions all problems will eventually get fixed. It never happens. (If nothing else: new stuff gets added much faster than existing things fixed). Believe me, I'm speaking in cognition of the facts: I'm not new to Boost and its code, and I find issues with it (ranging from minor to very sever ones, including undefined behavior) every time I look at anything. No strive. That's not very different from other free software. The peculiarity, actually, is elsewhere: if anything can be complicated, that's how Boost does it. If it can be overgeneralized, that's what boost does (never used a function with 15 arguments? doesn't matter... let's drag the whole pp-lib in, so that the user can choose to have up to 8589934592 of them). If it can be meta-programmed, or use conditional compilation... you got it. So, I'd bet that in addition to the obvious ones, a whole lot of very hard to spot issues lie in the Boost code. Hoare comes to mind: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. [...] Just to add a little example here, I grepped for the first thing that occurred to me: "LocalFree". Because because I remembered having seen many snippets of the kind <code which can throw an exception> ::LocalFree( p ) ; (would Coverity find that?). Well, I immediately ended up in a file named win32_api.hpp which has *a list of declarations of Windows API functions*, conditioned on BOOST_USE_WINDOWS_H. Terrific. A manner to have an undefined behavior, and condition it on a "user preference", I had never thought of. -- Genny
Gennaro Prota wrote:
I'm sure there are many ways Boost can be improved, please focus on specific issues, and one would hope their solutions
Which is the "patches are welcome", "if you notice anything wrong you can fix it" attitude I mentioned earlier. Don't fool yourself into believing that with enough time and contributions all problems will eventually get fixed. It never happens. (If nothing else: new stuff gets added much faster than existing things fixed).
Believe me, I'm speaking in cognition of the facts: I'm not new to Boost and its code, and I find issues with it (ranging from minor to very sever ones, including undefined behavior) every time I look at anything. No strive.
Things are not perfect, and Boost is no exception and noone said it is. And, I'm sure you know it, commercial software is no exception either. The only thing you can do about it is to make it better. Spreading depression won't make you any good. So, being a bit more constructive, IMO, is the right thing to be busy with. If you have a specific problem in mind, go ahead and create a Trac ticket. And yes, "patches are welcome", really.
That's not very different from other free software. The peculiarity, actually, is elsewhere: if anything can be complicated, that's how Boost does it. If it can be overgeneralized, that's what boost does (never used a function with 15 arguments? doesn't matter... let's drag the whole pp-lib in, so that the user can choose to have up to 8589934592 of them). If it can be meta-programmed, or use conditional compilation... you got it. So, I'd bet that in addition to the obvious ones, a whole lot of very hard to spot issues lie in the Boost code. Hoare comes to mind:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. [...]
Boost comprises generic solutions for a wide variety of problems, so it has to be flexible enough. This is the key feature that I personally like about Boost, and it proved to be essential for me many many times. But if you want a local solution for your particular task, which may be more optimal in some ways than what Boost provides, you are free to write one.
Just to add a little example here, I grepped for the first thing that occurred to me: "LocalFree". Because because I remembered having seen many snippets of the kind
<code which can throw an exception> ::LocalFree( p ) ;
(would Coverity find that?). Well, I immediately ended up in a file named win32_api.hpp which has *a list of declarations of Windows API functions*, conditioned on BOOST_USE_WINDOWS_H. Terrific. A manner to have an undefined behavior, and condition it on a "user preference", I had never thought of.
If you had also searched Trac tickets related to windows.h inclusion in headers, I'm sure you'd have found quite a few problems with it. So this particular twist in the header has a good ground. Same with many other twists that you may find in the code.
raindog@macrohmasheen.com wrote:
Perhaps you shouldbt use or follow boost since it appears so fraught with ill design and poor quality. I personally have found it otherwise.
I don't use it. And I only follow the mailing list in proximity of release dates, as I'm still (somehow :-)) a maintainer of dynamic_bitset. But that wasn't really the point. As I said in another post, Boost is no worse than a lot of software we use everyday. Which shows in what state of pre-history our field is. Just don't "join the crowd" and think that things *have* to go that way. You'd be fooling yourself and others. (I have yet to understand why people have come to be so tolerant of defects in software: if I visit a shop to buy a TV and the salesclerk tells me that the model I like is defective then I don't buy it. I'd bet most people do the same. Yet, for software...)
Sent from my Verizon Wireless BlackBerry
Nice to know :-) -- Genny
Gennaro Prota wrote:
I'm afraid that if I wanted to really reply to this I'd have to question your professional skills. Significantly. Which I don't want to do.
There is no need to question them: they are non-existant. I am not a professional developer, at least I haven't been yet.
[...]
Are you aware of what dependencies imply?
If low coupling is maintained, I don't see how having dependencies is such a problem. AFAIK, the interfaces of boost libraries have kept stable once they were accepted in release. Also, I wouldn't consider dependency over something as trivial as a tuple to be the same as a dependency over a full-fledged parser library, for example. A tuple is just an enhancement to the language to express your algorithms with. Some people even consider C++ with that kind of library addition to be a new language altogether, and that is why they use boost. Maybe all those "trivial" libraries should be grouped into a core library. But then the core would probably become way too big.
Mathias Gaunard wrote:
If low coupling is maintained, I don't see how having dependencies is such a problem. AFAIK, the interfaces of boost libraries have kept stable once they were accepted in release.
I don't think this is true. Sometimes interfaces have changed, which has caused quite some discussion on this list. I'm pointing this out because I believe it would be naive to assume that relying on external APIs comes at no cost. There is always a trade-off to make. Reuse of design and code is often a good thing, but not always. Add to that an additional conceptual complexity. If you can express the design of your software in simple terms, you win. However, if, in order to understand this design, users have to first grasp very generic concepts documented and coded elsewhere, it makes it already harder to understand. The idiosynchratic / proverbial 'AbstractModelImplementationFactoryProvider' from Java also exists (with different spelling) in modern C++.
A tuple is just an enhancement to the language to express your algorithms with. Some people even consider C++ with that kind of library addition to be a new language altogether, and that is why they use boost.
Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Wed, Feb 4, 2009 at 4:38 AM, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
Michael Fawcett wrote:
I'm not familiar with Coverity at all.
First time I hear of it, too :-) From a quick (as in "uninterested") glance at their site, they seem yet another "provider of nothing" trying to make a name for itself (and go from there to make money).
So I ended up reading up on them and browsing their site for a while. It seems that they are funded by the Department of Homeland Security (DHS) and lots of big name open source projects use their services. If you take a look at the Rung 1 ladder, projects such as Apache, Blender, emacs, Firefox, FreeBSD, gcc, GDB, glibc, Gnome, KDE, Linux 2.6, Mono, Wine, and wxWidgets are listed. Surely they read the license agreement first and found no problem with it? I admit, when I read it, it sounds scary, but IANAL. Frankly, anytime I read any license agreement it sounds scary to me. So I went ahead and read Google's Terms of Service, and they have a line that sounds exactly the same. 19. Changes to the Terms 19.1 Google may make changes to the Universal Terms or Additional Terms from time to time. When these changes are made, Google will make a new copy of the Universal Terms available at http://www.google.com/accounts/TOS?hl=en and any new Additional Terms will be made available to you from within, or through, the affected Services. 19.2 You understand and agree that if you use the Services after the date on which the Universal Terms or Additional Terms have changed, Google will treat your use as acceptance of the updated Universal Terms or Additional Terms. So you see, most of us accept that language in an agreement every day, we just might not know it ;) --Michael Fawcett
Michael Fawcett wrote:
Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder?
Boost and Boost.Build are both listed in Rung 0, so it appears that the only step left is selecting a Boost/Coverity liaison.
I have substantial doubts that they secretly implemented parser and analyser for Boost.Jam language, and therefore scanning Boost.Build is likely useless. - Volodya
participants (14)
-
Andrey Semashev -
David Abrahams -
Gennaro Prota -
Jeremy Pack -
John Maddock -
Marshall Clow -
Mathias Gaunard -
Michael Fawcett -
Phil Endecott -
raindog＠macrohmasheen.com -
Sebastian Redl -
Stefan Seefeld -
vicente.botet -
Vladimir Prus