Re: Reasons for not standardizing policy based smart pointers
On Jun 3, 11:21 pm, Lance Diduck <lancedid...@nyc.rr.com> wrote:
On Jun 3, 12:56 am, bda...@acm.org (Beman Dawes) wrote:> Gennaro Prota wrote:
In a blog entry I read recently, Herb Sutter states:
One of the primary reasons (but not the only one) why policy-based
smart pointers didn't make it into C++09 was usability:...
I wonder: what were the other reasons Herb hints at? Though he says
that they are not "primary" I hope they are still very serious for
"falling back" to a supposedly inferior alternative in a standard
which will set the shape of what we'll use for the next 20 years.
One of the objectives for a standard library shared pointer is that it
be useful for communicating between third-party libraries. That means it
must have a single agreed upon type.
I wonder just how many people who are actually make their living
intergrating third party libraries (or similar principle with in house
cross department libraries) will attest to this?
I will. We use a lot of third party libraries in our code, and
write others ourself for in-house use. From experience,
std::string and std::vector pose no problems.
Given that we cannot even reliably use std::string and such as a
common interface between libraries should give one pause.
They don't pose any problems for us. They're part of the
standard, and every compiler we use implements them.
There are
far more stringent requirements for using a C++ type as a common
demominator between libraries than "it doesnt change its type."
I have heard repeated often times, that one should be able to use
std::container and string ,and now shared_ptr, or other std:: types as
common "library vocabulary types." What happens in practice is that
designers actually start doing this without thinking it through --
even for in house code just shared amongst departments -- and suddenly
there are wars about an implementation of std::string or whatever.
How can their be wars about this? You don't implement
std::string; the compiler does. So you get what the compiler
gives, and live with it.
For
example, one guys library works best with COW strings, and another
with Copy Always strings.
Which means that one guy's library works best with compiler A,
and the other guy's with compiler B. But both work with both
compilers.
Now there is an ensuing battle over just
whose std library implementation are you going to use for the
integration of the two?
You don't have a choice? The library is part of the compiler,
and only an idiot would try to change it.
Which build settings? which vendor? Are these
build and vendor mixes suitable to meet the vendor warranty i.e. Can I
use Iona Orbix , RogueWave SourcePro, and Dinkumware shared_ptr all
together and meet each of the vendor guarantees? Ha!
That's perhaps a problem today, because shared_ptr is not
standard, and not part of the compiler. The whole point of
making it standard is to eliminate this problem. (I can't think
of a case where shared_ptr makes sense in an interface, but
that's a different problem.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]