On 1/2/17 1:48 PM, Vladimir Batov wrote:
On 2017-01-03 07:35, Robert Ramey wrote:
On 1/2/17 12:08 PM, Vladimir Batov wrote:
... The problem with the incubator IMO is that it does not provide any guarantee whatsoever that the library will be accepted/around/maintained in the future.
No one - not even boost - can make such a guarantee.
Oh, come on. Of course, nothing in life is guaranteed. I can't guarantee I wake up tomorrow morning. But surely we all understand what I was trying to say. Is there really anything to debate/discuss here?
Hmmm - actually there is. If you use a boost library, there's a real world chance that it may stop working in the future. This could occur because you upgrade your compiler or because someone "improves" the official version so that it doesn't work for you any longer. Of the course it's much more likely for something like this to occur on some other library - in the incubator or otherwise. You seem to suggest that this is not a problem with boost libraries while it is with others. My view is that it's a problem with all code and libraries. It just that due to a higher standard, it may be much less of a problem than it its with boost libraries. But my view is that this concern never goes away and this fact should be built in to the development procedures of any application which depends on boost or any other library. I don't think that depending on boost or on some component in the incubator or anywhere else is all that different. I trust no one.
I simply described the "real-world" project/product I am involved in. I've been doing it for quite some time and as far as I can remember all those "real-world" projects were using external libs and Boost has always been one of them. Forgive my saying but to say "I do not think a real world product can depend on anything outside it's own organization" seems very much out of touch with this very real-world... unless I misunderstood/misinterpreted it.
Let me clarify. Of course we rely on externally produced code. But if you ship it, you still have to be responsibility for it. The only way you can do this now is to run the tests yourself. I realize that people don't do this and I maintain that they are wrong not to do it. But if one accepts the view that he should run the tests on every library he includes in his own product, than the distinction between using a library review or in the incubator or anywhere else goes away.
It appears obvious to me that an external lib (local copy or not) is outside of my control...
Agreed.
unless I am prepared to take responsibility of maintaining the lib... which is not an option.
Unfortunately, you can't evade responsibility for the promises made for your final product. Hence you can't evade responsibility for the functioning of the libraries you use. Currently, the only way you can credibly claim you've fulfilled those responsibilities is to run tests on the libraries. Libraries in boost and in the incubator are required to have tests (unlike any other source code collections). So this is possible in either case.
With Boost that risk is minimal (practically non-existent); with incubator that risk is quite high. Others might disagree.
Certainly one would hope that libraries in boost have fewer bugs. But since I believe that all code should be tested by myself before I ship it as part of a product, I can't accept/reject libraries on a case by case basis. This is what I recommend that anybody do. Sort of off-topic.
unless I am prepared to take responsibility of maintaining the lib... which is not an option.
Actually it IS and option. Take a look at the Boost Library Official Maintainer (BLOM) program. If you really depend on some library which no longer has a maintainer, Your company can take on that responsibility and gain some benefits besides. The theory is that since you have to run tests anyway and perhaps apply bug fixes in the normal course of your work, you might as well take on the job officially and get and inside track in getting your fixes into the official version and maybe some free promotion/publicity for your organization. Robert Ramey