From: Robert Ramey (ramey_at_[hidden])
Date: 2006-10-08 12:32:33
Maybe someone could clarify something for me.
My understanding of the C++ standard for libraries is that
the interface and semantics are defined by the standard
but that actual implementation is purposely left undefined.
Hence, adding say regex to the standard doesn't add any
code to the standard. It just certifies that anything that
claims to be compatible with the C++ regex standard
works as the standard says it does.
So, acceptance of anything into the standard in no way
makes the current boost (or any other) obsolete.
As a current example, we see standard collections
in the standard (vector, list, etc...) but we see a number
of (complementary, competing?) implementations like
dinkumware, STLPort, etc.
Apparently this is source of some confusion - there was
a post recently from a user whose legal department was
concerned about the copyright issues related to using
code not in the library standard. I believe this is due
to a mis-understanding of this difference and that this
mis-understanding is common.
Now all this raises the key point that has been bothering
me for some time.
What is the point of having a library standard anyway?
Suppose we have a library - take regex for example. The
library is developed and is suitable for wide usage and hence
there is an interest that it "be included in the standard". I'm
not sure but I suspect that the motivation is that this code
should be "universally available" accross all C++ environments.
But the regex library has a boost license. This license is
specifically designed minimize (to zero if possible) any
restrictions on its usage. It is also designed to be be
compatible with the widest number of C++ environments
and specifically with any conforming C++ compiler
(which is a different standard). Hence, its already
To summarize, regex implementation is compatable with
any standard conforming C++ compiler. Hence it is
available with any such compiler. Including or excluding
it from any C++ LIBRARY standard will in no way
affect it's utility.
Finally, given the fact that there is a free implementation
already available, what is the point and/or incentive to
make another one that conforms with the standard. This
is especially true now that the library standard is much
influenced by the current implementations of the proposals.
Originally, the concept of a "standard library" was to permit
portability accross operating systems and cpus by providing
a common layer which would hide the differing implementation
detail requred by the differeing underlying environment. This
rationale doesn't apply in the case of something like regex
whose implementation doesn't depend on the os or cpu
but rather on the standard conformance of the C++
All this leads me to conclude that the current focus on
the "standard C++ library" leads to a mis-direction of
resources and efforts. I think such efforts would be
better directed to other areas. I would like to see
C++ be made more portable. This means addressing
some things which are currently undefined and/or
ambiguous like handling of DLLS, order of initalization
of static instances, template instantiation in the presence
of code optimization, results of undefined operations, etc.
Also there are a number of C++ features which seem to
be very hard to implement correctly - judging from the
variations of compiler behavior in certain areas. These
should be looked at as well.
I would like to see things get to the point where
a) I could know that if I compiler and test my program
in one environment I can be "sure" that it will run
the same when I re-compile it and re-run it in another.
b) Any "library code" implemenation will be portable
as in a) above.
I see things like the addition of concepts to C++
moving away from the direction I think C++ has to go.
I do realize the benefits and the appeal of these
kinds of additions - and specifically of the addition
of concepts into the language - but I fear that the
net effect adding even more complexity to C++ will
result in a language which is overall harder to use
rather than easier.
Douglas Gregor wrote:
> On Oct 8, 2006, at 1:25 AM, Shams wrote:
>> Are these libraries then going to be deprecated/disappear from
>> boost thus everyone uses the
>> one available in the standard or will boost authors "still" keep
>> developing and improving/enhancing the
>> them as part of boost (which actually IMHO will be a good thing
>> because boosters can then retain,
>> introduce and enhance features that the standard might not want to
>> accept). What do you think?
> None of the Boost libraries will be going away any time soon, for
> sure. For my own libraries, I would like to start forwarding to the C+
> +0x equivalents when they become available, and phase out the Boost
> versions over time. The Boost versions need to stick around for a
> while to maintain backward compatibility, but we should be
> encouraging users to use the standardized versions. The last thing we
> want is to be competing against the standard, because that's not our
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk