Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-05 03:20:57

"David B. Held" <dheld_at_[hidden]> wrote in message

> > [...]
> > AFAICT, one member function i eg. shared_ptr would let us get
> > by without any cast at all.
> But wouldn't the cast really hide inside this mem-fun?

no, it would be a const function returning the stored pointer without

> > [...]
> > AFAIR, the pointer was not allowed to be 0 inside foo().
> I don't remember anyone saying that, but you can still imagine
> the case where there is no such requirement.

It called another function on the stored object. A 0 would give undefined

> > [...]
> > If you need that, why don't you do it like this:
> >
> > void foo( T* t );
> > foo( &*p );

Sorry, foo( p.get() );

> > ?
> Because then you are saying that foo takes an unmanaged
> pointer, of course. And that is a different thing than taking
> a managed pointer, right (despite what we say about
> drop-in replacement ;)? Also, it seems very awkward to
> switch between trafficking in smart pointers to trafficking in
> raw pointers just to work around deep const.

yeah, a member function like in my_ptr.ptr()->nonConst();
would be better.

> It's this kind
> of tradeoff here and tradeoff there that makes it a not-so-
> obvious win to me.


> > [...]
> > I must have forgot. Isn't foo( T& ); and foo( T* ) enough?
> If you don't believe an interface should also be documentation,
> maybe.

This I don't get. With foo( T& ) I can call your function without
creating a smart ptr. The other way around is not as general. So
what would an interface that takes the smart pointer, and only a particular
smart ptr, document (besides that it only takes a particular type of smart

> > [...]
> > >Making the change you suggest would break
> > > thousands, possibly millions of lines of code. Is it worth it?
> >
> > That is not that relevant for the discussion. I would be if a change
> > was actually made.
> LOL!

Is it short for something ? :-)

> I propose that we add the keyword 'type' to the language
> to indicate a variant type. Now, when discussing the merits of
> this proposed change, disregard any potential name clash with
> existing uses of this name, because that would only be relevant
> *after* the proposal is accepted. ;>

True, but I thought that our discussion was about the semantics in general.
And your
upcomming smart pointer is not hardcoded in any way. Neither are yet to be
accepted standard ones.



Boost list run by bdawes at, gregod at, cpdaniel at, john at