Iostream may be preferable for purely academic reasons, but for practical
reason, "printf" is the api style that is universally adopted.
Iostream stry is safe. I have worked on a lot of projects having a lot of bug in printf like functions on site. I prefer the compiler give me these kind of errors for safety purposes.
Its not about what you and i prefer. Its all about what is the prevailing standard. Popular techniques are developed over many years. Printf is a popular technique that C++ libraries should continue to support. No reason to abandon it.
I think that your or your leader are following a wrong reasoning. You can forbid the direct use if you have good reason, but I dont see why forbid the use of products that use this Boost library. I don't know which libraries you dont want any member of your project to use and why, could you tell us more?
More than a few boost libraries are considered junk. I wont name names. In any event, it may disconcerting to some to include any of these "junk" libraries into their project. As boost lacks a way to remove those projects, some project leads my deceide to just not use boost at all.
4) Many boost libraries seem more like they research projects. The
prevailing view is that boost libraries push the envelope of what is possible.
Could you give some examples of research projects?
I'm not going to identify individual projects. But there are many that could accurately be described as "academic".
However, many developers question the value of a cutting-edge template library that is full of macros.
For most of the cases the use of PP is to emulate variadic templates. So this is temporary until all the compilers will support variadic templates. Let me say, for 2015.
Good point.
What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath?
What is the practical value of a library that can only be maintained by the original developer(s)?
I don't think this is true. Any Boost library can be maintained by some other than the author.
Sorry, not true in practice. Would be nice if that was true.
I expect to have an idea of what a library is doing by reading its documentation, not examining its code. If a library is not enough documented we shoudl make requests to the documentation.
Most developers know that the only real documentation if the source code. Tom Brinkman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost