Re: Announcing Xrtti - Extended Runtime Type Information for C++
On May 4, 10:57 am, Hyman Rosen <hyro...@mail.com> wrote:
Rather than shortsighted, say short-staffed. Defining a library
as part of a standard is hard work, and there aren't enough people
available to do it. If you want more things to be covered by the
standard, I suggest you get to work. Find an area in which you have
expertise and you feel is lacking in the standard, write a
specification, prepare a library for submission to Boost, and it may
become part of the standard.
When I look at STL, I often wonder if insufficient manpower was the
problem. After all, there are young programmers today who crank out
their own libraries that have almost as many components as STL. Of
course, the quality and technical depth of these components are
sometimes not as great as that of STL, but the quantity is there.
Additionally, if one were to take the current top open-source
libraries across multiple domains, the quantity of components would
swamp STL, but the number of people involved in their creation would
be less. So the problem is not so much as manpower, it is coherency
of vision. If 20 C++ experts get in a room and try to decide on a
socket class, for example, there will be many different opinions about
how it should be done, and it will take a long time for agreement.
And moreover, a socket class is not like a relatively trivial class,
like set<>. In fact, a well-done socket class would most likely
depend upon a set<> class in its implementation, so there would have
to be agreement on what set<> should look like. Also, there is no
tree<> class in STL, but it would be impossible to do my research
without such a class. And I am certain that the model for the tree<>
class that I currently use could not conform to the STL container
model (as someone here once pointed out). I think this was a big
impediment - those hell bent on universality of the iterator model
realized that it did not apply to tree<> and decide to ignore tree<>
so they could keep it for "real" containers.
Finally, I do not believe it is necessary for one person to actually
design all the different classes in details. The goal should be
homogeneity in form, a certain spirit that permeates the design of
every class that might be conceived, beyond those in STL. IMO, that
is what is missing. The standards committee attacked containers,
stings, stream I/O, but punted on tree<>, dates times, etc., but
neglected the big picture. I do believe that it is possible for
someone who has deep experience in C++ to at least paint a mosaic of
the "big picture". Then, experts could flesh out the elements. For
example, Ben Pfaff could reduce the coding time for various containers
from years to weeks.
But, the "super architect" mode of systems design rarely succeeds
through deliberate, preemptive, agreement. Typically, a super
architect makes his thing by fiat, and before any serious opposition
can be effective, others have already accepted and attested to its
virtue...unfortunately, with the defects that inevitably arise when a
single individual assumes such a large task. Nevertheless, I would
argue that coherency of design is more readily achieved by a single
person than by a committee.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]