Re: It would be better if unique_ptr were a type modifier?
On 27 Jul., 07:31, Dragan Milenkovic <dra...@plusplus.rs> wrote:
On 07/26/2010 07:45 PM, Daniel Kr?gler wrote:
On 25 Jul., 16:27, Dragan Milenkovic<dra...@plusplus.rs> wrote:
[..]
I didn't give thought or searched for existing discussions
on this topic, but there is another, much more important item
that you forgot... The support for covariant return types...
Since you are already changing the subject: It might be
helpful, if you would be more specific in this point as
well, because covariant return types are supported in
C++. I assume you have something similar in mind
as discussed in the older thread "Treating Foo<T>* as
Foo<const T>*",[1] extended to "Treating Foo<Derived>* as
Foo<Base>*" or to "Treating Foo<Derived> as
Foo<Base>" but that is just guessing.
I assumed that OP meant to incorporate shared_ptr into
the language as opposed to being a library. He refers
to it as a modifier, although this would not be it's
nature. At least this is how I understood it...
I think you understand the OP pretty well, but I did
not understand your remark well ;-) - sorry for that!
I don't have any proposal and can live with the current
state of things. I was simply stating one additional
advantage so he can give more thought to his proposal
(I hope that came out right).
After rereading your message I agree that you were pretty
clear.
Disclaimer: I will now be plain silly:
std::shared_ptr<Foo> foo = std::make_shared<Foo>();
Foo $ foo = std::make_shared<Foo>();
... end of silliness.
I see, but I wonder which would be the compiler rules
in regard to "sharing"? It seems that uniqueness
constraints are easier to check than sharing constraints.
And about treating Foo<Derived> as Foo<Base>; it can
somewhat be solved by a conversion operator, right?
Typical implementations do this by providing a converting
constructor, yes. This is the way unique_ptr and shared_ptr
are specified. This does not allow for binding a *pointer*
or reference of type unique_ptr<Derived> to a corresponding
object of type unique_ptr<Base>, though.
While it is - with some efforts - possible to realize that
in regard to cv qualifications (as shown in the referenced
thread), this is not so easy to realize in a completely
general way in regard to inheritance relations (but I haven't
tried it yet).
It's just that I sometimes wish that some conversions
were transitive (can be chained automagically)... :-)
and I don't necessarily speak about templates.
I understand this, but I'm not sure that the resulting increase
of the complexity of the type system is worth the effort.
IMO it is similar or even more drastic than allowing to
overload the operator., see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1671.pdf
Alternative approaches are to allow for user-providing
conversion operators, as shown in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2200.pdf
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]