Boost logo

Boost :

Subject: [boost] boost::log review (printf style api)
From: Tom Brinkman (reportbase2007_at_[hidden])
Date: 2010-03-14 18:59:13


>> 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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk