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: Although
    Loki::SmartPtr can express shared_ptr easily as just one of its
    configurations, the user has to type lots of weird stuff for the
    policy parameters that is hard to completely hide behind a simple
    typedef, and so the user would be less inclined to use the
    feature:

        shared_ptr<int>::type p;
        shared_ptr<int> p;

    Too bad we didn't have template aliases then, because now we could
    have our cake and eat it too:

        // Legal in C++09
        //
        template<typename T>
        using shared_ptr =
            Loki::SmartPtr<
              T,
              RefCounted, NoChecking, false, PointsToOneObject,
              SingleThreaded, SimplePointer<T>
            >;

    shared_ptr<int> p;   // using the alias lets us
                         // have a completely natural syntax

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.

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/

---
[ 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                      ]

On Jun 1, 7:27 pm, gennaro.pr...@yahoo.com (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: Although
>     Loki::SmartPtr can express shared_ptr easily as just one of its
>     configurations, the user has to type lots of weird stuff for the
>     policy parameters that is hard to completely hide behind a simple
>     typedef, and so the user would be less inclined to use the
>     feature:
>
>         shared_ptr<int>::type p;
>         shared_ptr<int> p;
>
>     Too bad we didn't have template aliases then, because now we could
>     have our cake and eat it too:
>
>         // Legal in C++09
>         //
>         template<typename T>
>         using shared_ptr =
>             Loki::SmartPtr<
>               T,
>               RefCounted, NoChecking, false, PointsToOneObject,
>               SingleThreaded, SimplePointer<T>
>             >;
>
>     shared_ptr<int> p;   // using the alias lets us
>                          // have a completely natural syntax
>
> 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.
>
> --
> Gennaro Prota -- C++ Developer, For Hirehttps://sourceforge.net/projects/breeze/
This is assuming that the only way to have a policy based smart
pointer is to have tons of template arguments that an app developer
need to deal with every time they want to use it. Or that the only way
to make new kinds of templates is by template aliases.
Rather, a better way to look at policy based smart pointers is a way
for an app programmer to easily specify a family for use in her
program. For example:
namespace lib{
template<class T,class PolicyBlob>
struct basic_shared_ptr{
//get policies out of PolicyBlob, i.e. checking, threading etc
//implememnt all shared_ptr functions, minus constructors in terms of
PolicyBlob
};
}
now define end user template
namespace user{
struct  detail{
  typedef   RefCounted countpolicy;
  typedef   NoChecking checkpolicy;
  bool const noninstrusive=false
  //....
};
template <class T>
struct shared_ptr:lib::basic_shared_ptr<T,detail>{

   //implement all constructors

};
}//namespace
Of course, the "implement all constructors" part is a hassle. What I
do in practice is to use some helper macros. It looks like this:
namespace foo{
#define POLICY_CLASS \
      refcounted_detail::shared_count<
T,detail::shared_countPointerMgr >

MYLIB_SHARED_PTR_DEFINITION_HELPER_BEGIN(shared_ptr,POLICY_CLASS)
MYLIB_SHARED_PTR_DEFINITION_HELPER_END(shared_ptr)
MYLIB_WEAK_PTR_DEFINITION_HELPER_BEGIN( weak_ptr , shared_ptr)
MYLIB_WEAK_PTR_DEFINITION_HELPER_END(weak_ptr)
MYLIB_SHARED_PTR_ENABLE_SHARED_FROM_THIS_HELPER(shared_ptr)
MYLIB_SHARED_PTR_CAST_FUNCTION_HELPERS(shared_ptr)
}
And now I have
foo::shared_ptr,foo::enable_shared_from_this,foo::weak_ptr, etc, all
parameterized from the POLICY_CLASS used to make the shared_ptr.
Furthermore, I can do this:
MYLIB_SHARED_PTR_DEFINITION_HELPER_BEGIN(shared_ptr,POLICY_CLASS)
bool operator==(shared_ptr const&)const;//do something different?

MYLIB_SHARED_PTR_DEFINITION_HELPER_END(shared_ptr)
if I so wanted.
template aliases would make this easier, but I have to use what I
have, not what I wish for.

I can use the library like this
foo::shared_ptr<int> fooint(new int); // special for foo
bar::weak_ptr<int> barwint;           // special for bar
//barwint=fooint;//wont compile
template<class T>
struct alias{
   operator()(void*)const{}
   alias(T const&_a):t(_a){}
   private: T t;
};
bar::shared_ptr<int> barint(fooint.get(),alias(fooint));
barwint=barint;
//now fooint will live as long as barint does
but I have found in practice that this alias technique is not usually
required.Familiies of shared pointers stay together.


So now I have one code base (on Sun WS6U2, IBM xlc8, gnu, and MSVC
7.1./8) that does intrusive pointers, nonintrusive pointers using
shared memory allocators,nonintrusive pointers identical to the boost
distribution, etc. And they are all 100% standard compatible.

Lance




---
[ 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                      ]

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.

Thus the std::shared_ptr technique (invented by Peter Dimov) of
adjusting the feature set via the particular constructor used to
instantiate a shared_ptr it a considerable advantage over a policy-based
  shared pointer because the std::shared_ptr type remains unchanged.
Each flavor of a policy-based shared pointer is a different type.

By the time the C++0x specs freeze later this year, std::shared_ptr will
probably have gained further features, including intrusive construction,
   still without changing the type. That further raises the barrier that
a policy-based smart pointer has to overcome to displace shared_ptr.

Maybe someday a policy-based smart pointer proposal will come before the
committee that we feel comfortable with in terms of proposed wording,
existing practice, and all the other things that the committee looks at
in a library proposal. But that hasn't happened yet, and it is simply
too late for C++0x, baring a near miracle.

--Beman Dawes



---
[ 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                      ]

Beman Dawes <bdawes@acm.org> wrote:

> By the time the C++0x specs freeze later this year, std::shared_ptr will
> probably have gained further features, including intrusive construction,
>    still without changing the type. That further raises the barrier that
> a policy-based smart pointer has to overcome to displace shared_ptr.
 Very interesting, is there some working version of this intrusive ptr
implementation with std::shared_ptr<T>?

---
[ 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                      ]

On Sun,  3 Jun 2007 04:56:38 GMT, 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.
>
>Thus the std::shared_ptr technique (invented by Peter Dimov) of
>adjusting the feature set via the particular constructor used to
>instantiate a shared_ptr it a considerable advantage over a policy-based
>  shared pointer because the std::shared_ptr type remains unchanged.
>Each flavor of a policy-based shared pointer is a different type.

Then *this* is the primary reason! Thanks, Herb Sutter article was
pretty inaccurate, then; which doesn't happen often.

BTW: any chance to have a C++09 rationale, even if as an informal
document?

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/

---
[ 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                      ]

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?

Given that we cannot even reliably use std::string and such as a
common interface between libraries should give one pause. 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. For
example, one guys library works best with COW strings, and another
with Copy Always strings. Now there is an ensuing battle over just
whose  std library implementation are you going to use for the
integration of the two? 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!
I have even seen it degenerate to the point of developers "fixing"
std::string or some other std artifact and actually replace with their
own in-house std library. Like THAT solved anything -- it actually
makes it worse, since no reputable vendor will certify that their
product will work with your proprietary std library.

I have gotten to the point or refusing to use ANY std type in my
library interfaces. And guess what? My reliablity, performance, and
portability increased significantly.

So I am wondering if this rationale was actually ever tested this idea
with actual third party libraries and integrations? I in fact HAVE
actually tried doing this, and I now swear by policy based
shared_ptrs.

---
[ 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                      ]

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                      ]

Lance Diduck wrote:
> For
> example, one guys library works best with COW strings, and another
> with Copy Always strings. Now there is an ensuing battle over just
> whose  std library implementation are you going to use for the
> integration of the two?

You use the one that comes with your compiler. It's part of the
"implementation", and that's what the standards document specifies. If
you replace it, any standard-conformance problems are your responsibility.

> Which build settings?

That's not a standard library issue, but an integration issue.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ 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                      ]

James Kanze ha scritto:
> (I can't think
> of a case where shared_ptr makes sense in an interface, but
> that's a different problem.)

I think it makes a lot of sense! In fact I already used shared_ptr in
the interface of a couple of libraries. You can use it for PIMPL and
factories. In particular, the custom deleter feature is very useful,
because it allows the library to hide the details about how to release a
resource, which is always a good thing.

Ganesh

---
[ 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                      ]

On Jun 4, 11:33 am, James Kanze <james.ka...@gmail.com> wrote:
> 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:
> > 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.
The most popular yet least sexy way of "policy based programming" is
by build options. In all compilers I know of, I can swap out
std::library implementations. And the only thing specified by the
standard is certain minimum behaviors and the interface. Which it
should be. But everything other feature is a dreaded "build option"
So we have this scenario:
namespace JiffyXMLDOMParser {
   class IDom;
   std::tr1::shared_ptr<IDom> parse(std::string const&);

}
and the implementer guarantees jiffyness for certain platforms, say
Sun Ws6U2 using XYZ build options
namespace LightningCalc {
   typedef std::deque<std::pair<std::string,double> > tickdata;//stock
ticker info
   typedef std::deque<double> result;
   result calc(tickdata const&);
}
and the implementor guarantees lighting results for certain platforms,
say Sun Ws6U2 using ABC build options
Now we have the poor integrator, who is NOT a C++ guru and shouldn't
have to be, facing  this scenario:
namespace App //gets tick data from XML feed, and does a calculation
{
   void doit(){
     using namesapce JiffyXMLDOMParser;
     using namespace LightningCalc
     std::string datastr=getTONSofdata();
     std:tr1::shared_ptr<IDom> p_res=parse(datastr);
     tickdata tdata=ConvertDOMtotickdata(p_res);
     result calc_res=calc( tdata);
}
}
Now the writer of App
a) has to find the magic mix of XYZ and ABC that would get this to
compile and link in the first place (and that may not even be
possible)
b) this mix does not satisfy either library requirement, so the
guarantees are off
c) the library writers, themselves not C++ build masters, just chose
interface types (std::deque, std::tr1::shared_ptr, etc) and build
options that made their individual benchmark suites go fast. In other
words, the implementation is exposed in the interface.
d) the library writers, using the logic that std::foobar is standard
and comes with the compiler --therefore it must be applicable for all
cases -- cannot foresee case where std::foobar would not be
appropriate. For example, each library writer wants std::string: DOMs
are usually large and read only, so COW implementation of std::string
is a good choice. For tick data, SSO implementations of std::string
are your best choice. COW and SSO are part of those build options.

And I have not even delved into whether the libraries ship in binary
form or not, or what the threading model is.

Had the implementers of JiffyXMLDOMParser  and LightningCalc chosen
types that do not depend on build options, then everybody is happy.
But they didn't, and we are left with a mess.

> > 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.
There are now compilers that ship with multiple versions on the
std::string available. But yes I agree with you. std::containers and
steams should be locked down by the compiler, and if you want
something different, you put that in a different namespace and deal
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.
This is a real world scenario:
Sun uses a implementation of the std library that they acquired from a
vendor. They modified it somewhat, and shipped it. It works great in
single threaded mode, and back then there were not too many users
either of std::string nor of MT mode.
Their std::string was a COW implementation, and used a SINGLE global
mutex for ALL std::string's  in your program.
Well you can imagine the trouble that some developers had, when they
did the supposed "right thing" and switched from their proprietary
strings to the std:: version, in all their MT programs. Spending 20%
time in contention dealing with strings was the numbers my teammates
dealt with.
Still believing that std:: was the "right thing" they instead switched
the std librarys itself to a version that worked better for this
scenario, typically STLport. Sun then added STLPort as a build option.
Some developers just switched back to their proprietary strings, and
cursed C++. Some, started using std::vector<char> for strings. Some
just insisted on their build options for all. I used a thing very
similar to Alexandreascu's FlexString.
But in the "idiot" case, I do know of a developer actually convinced
his company to switch to a weird version of the std:: libs, where all
policies (including allocators) are determined at runtime as
constructor args. I would take the "build option policies" over this
case -- at least with "build option policies" you have a ghost chance
of actually figuring out what the problem is.

What does this have to do with smart pointers? Policies are going to
be there somehow, someway, whether as hard coding, template
parameters, constructor args,  build options, or environment settings.
boost::shared_ptr policies are a combination of build options, hard
coding, and constructor args, but somehow insist it is not "policy
based." My personal version of shared pointer moved boost build option
and hard coding policies to template args, and then uses a form of
template aliasing to make it conform to the standard.

Lance

---
[ 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                      ]

[resend after 48 hrs]

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: Although
>     Loki::SmartPtr can express shared_ptr easily as just one of its
>     configurations, the user has to type lots of weird stuff for the
>     policy parameters that is hard to completely hide behind a simple
>     typedef, and so the user would be less inclined to use the
>     feature:
>
>         shared_ptr<int>::type p;
>         shared_ptr<int> p;
>
>     Too bad we didn't have template aliases then, because now we could
>     have our cake and eat it too:
>
>         // Legal in C++09
>         //
>         template<typename T>
>         using shared_ptr =
>             Loki::SmartPtr<
>               T,
>               RefCounted, NoChecking, false, PointsToOneObject,
>               SingleThreaded, SimplePointer<T>
>             >;
>
>     shared_ptr<int> p;   // using the alias lets us
>                          // have a completely natural syntax
>
> 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.

There were mostly technical reasons. There have been concerns related to
library interoperability, as Beman noted; I believe those could have
been assuaged by appropriate use of template typedefs and default
parameters. After all, all of the dynamic configurability that was
needed for a shared_ptr clone could have been taken care of in one set
of default policies; maybe it wasn't clearly communicated that the
option to did things statically (through type parameterization)
complements, and does not preclude, doing them dynamically as well.

But the basic problem was "simple": the PBSP project had two ambitions:
to 100% emulate shared_ptr and auto_ptr, in addition of course to
enabling an array of other designs. I have considered anything less as a
failure: After all, I couldn't come with a straight face and say, "hey,
here's this ultimate design - the only smart pointer you'll ever need -
um, except for auto_ptr, which I can't emulate."

And that's quite what happened: emulating auto_ptr in addition to
everything else turned out to be so onerous as to become a Pyrrhic
victory. Dave B. Held and myself fought valiantly to come up with a
compelling design, but we couldn't: the result had nothing of the
elegant simplicity of policy-based design, but instead was a mishmash of
heavy-handed tricks and essentially a swath of duplicated code to
support auto_ptr. There were too many bears to make dance out there. I
don't think the committee would have been impressed; I know we weren't,
and how could we sell something we didn't believe in? Also, the
semantics of typedef templates were actively being debated on so we
couldn't count on the semantics we needed.

Meanwhile, both Dave and myself were under significant time pressure and
we were more or less forced by circumstance to work on other projects. I
still believe it's possible to devise a PBSP that achieves our goals
within a clear, concise design; we just couldn't find that in time.


Andrei

---
[ 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                      ]

On Wed,  6 Jun 2007 19:57:33 GMT, "Andrei Alexandrescu (See Website
For Email)" wrote:

>[resend after 48 hrs]

Yes, I've lost several messages as well. Are the moderators somehow on
the track of the problem?

    [...]
>There were mostly technical reasons. There have been concerns related to
>library interoperability, as Beman noted; I believe those could have
>been assuaged by appropriate use of template typedefs and default
>parameters. After all, all of the dynamic configurability that was
>needed for a shared_ptr clone could have been taken care of in one set
>of default policies; maybe it wasn't clearly communicated that the
>option to did things statically (through type parameterization)
>complements, and does not preclude, doing them dynamically as well.
>
>But the basic problem was "simple": the PBSP project had two ambitions:
>to 100% emulate shared_ptr and auto_ptr, in addition of course to
>enabling an array of other designs. I have considered anything less as a
>failure: After all, I couldn't come with a straight face and say, "hey,
>here's this ultimate design - the only smart pointer you'll ever need -
>um, except for auto_ptr, which I can't emulate."

 :-) That doesn't seem so terrible to me, frankly. But if you weren't
satisfied with it in the first place, of course...

Anyway, thank you so much for the thorough reply!

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/

---
[ 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                      ]

On Jun 4, 8:26 am, p...@versatilecoding.com (Pete Becker) wrote:
> Lance Diduck wrote:
> > For
> > example, one guys library works best with COW strings, and another
> > with Copy Always strings. Now there is an ensuing battle over just
> > whose  std library implementation are you going to use for the
> > integration of the two?

> You use the one that comes with your compiler. It's part of the
> "implementation", and that's what the standards document specifies. If
> you replace it, any standard-conformance problems are your responsibility.

I submit, for your consideration, the "standard" library that comes
with Sun Studio.
Hence the "optional" STLPort alternative they also provide...

> > Which build settings?

> That's not a standard library issue, but an integration issue.

An often crucial one. As soon as you have two third party libraries,
you're hosed.

--

Nathan F. Yospe
Core libraries and cross platform development
MDM Core, SAP Labs, Los Angeles

---
[ 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                      ]