It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library?
My point is that Boost is a C++ library and should not care at all about the impact on C developers, or people who happen to be used to that "glue language," even for their C++ development. I still think it is a valid discussion to have.
Well said. Good summary, although as noted, I disagree with your conclusion. The larger question is -- what has gone wrong with boost? Why do so many libraries languish in the review queue. Why has the the C++ standard taken so long to get enough momentum to pass through committee. In my view, C++ is tired. Boost is an experiment of a particular style of development, that being functional, generic, orthogonal and "non-hieararchical". Boost through its heavily template ladden libraries offered this style of development, and it had great appeal to those who had grown tired of object oriented style of development. The experience of those of us that have developed with this style over the years has been mixed. Like anything, somethings are nice, somethings are more trouble than there worth. Fortunately, for those of us that have an appreciation for functional programming will still be highly relevent in the future. The reason has primarily has to do with parralel programming which lends its self very nicely to functional programming, which is what boost is all about. The way I explain it, functional programming is just a variation of procedural programming with a different way of passing around state. Unfortunately, this advanced programming style is often abused in hideous ways. Particularly, when they are used in small utilty libraries which should be simple and general purpose, and not push a particular style of development. I've already made this point, but I'll make it again. Utility libraries should be agnositic and usable across the widest variety of programming styles, that being procedural, objected orienteated or functional. This boost::log library should not be approved without a simple "C" friendly api. That being a printf style api. Failure to include a "printf" style api will only continue to marginalize boost further to small subset of c++ developers. Most develpers will look at the api without a printf and go, HUH?