Prev: Is there any standard/guarantees for exception safety in STL operations?
Next: problem with partial ordering of classes
From: Mathias Gaunard on 26 Jul 2010 07:18
On Jul 26, 3:07 pm, "Thiago A." <thiago.ad...(a)gmail.com> wrote:

> void f4()
> {
> unique int* p1 = new unique int();
> unique int* p2 = new unique int();
>
> p1 = p2 ;// error: p1 was not deleted
>
> delete p1;
> p1 = std::move(p2); // ok
>
> delete p1;
> p1 = new unique int(); //ok
>
> delete p1; //ok
> delete p2; //ok
>
> }

The point is to automate resource management in an exception-safe way.
Your proposal doesn't address the point at all, as the memory
management is manual. The code I am quoting is definitely not
exception-safe.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Hakusa on 26 Jul 2010 13:36
On Jul 24, 9:55 am, "Thiago A." <thiago.ad...(a)gmail.com> wrote:
> It Would be better if unique_ptr were a type modifier?

Your proposal is for a type modifier, but a const int is still an int.
It would seem a unique int is not an int anymore.

> positive points:

> - no includes

What's wrong with includes? What if projects out there already use the
"unique" or "unique_ptr" identifier for their own type or variable?
Actually, i don't doubt there are countless people who have
implemented (or tried to) their own unique pointer class and this
change would invalidate their code.

> - Better error message generated by compiler

Can you show a plausible compiling error with std::unique_ptr that
would be improved with your suggestion?

> I guess that the shared_ptr is also a candidate for a type modifier
> but with much more details and implications.

That's another thing: unequal treatment. If unique_ptr was made a
keyword, wouldn't shared_ptr have to be as well, and every smart
pointer?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andy Venikov on 26 Jul 2010 13:40
>> (let's say that "unique" is a modifier)
>
> I fail to see the very advantage of a new key word
> (with all it's implications - can I/need I specialize
> templates for it?) compared to the current library
> solution. Or shorter: What is the advantage of
>
> unique* T
>
> over
>
> std::unique_ptr<T>
>
> Could you enlighten us?
>
> Greetings from Bremen,
>
> Daniel Kr�gler

I guess the OP means that even if one is using unique_ptr it's possible
to shoot yourself in the foot. I.e.:

unique_ptr<int> p = new int;
f(std::move(p)); //transferred the ownership. But a later developer
//didn't notice it

cout << *p; //boom!

And that if "unique" was part of the compiler, the compiler would've
been able to issue a warning.

This has been discussed on Bartosz Milewski's blog:
http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/

Andy.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dragan Milenkovic on 26 Jul 2010 14:31
On 07/26/2010 07:45 PM, Daniel Kr�gler wrote:
> On 25 Jul., 16:27, Dragan Milenkovic<dra...(a)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 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).

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.

And about treating Foo<Derived> as Foo<Base>; it can
somewhat be solved by a conversion operator, right?
It's just that I sometimes wish that some conversions
were transitive (can be chained automagically)... :-)
and I don't necessarily speak about templates.

--
Dragan


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Thiago A. on 26 Jul 2010 23:48
On 26 jul, 19:18, Mathias Gaunard <loufo...(a)gmail.com> wrote:
> On Jul 26, 3:07 pm, "Thiago A." <thiago.ad...(a)gmail.com> wrote:
>
>
>
>
>
> > void f4()
> > {
> > unique int* p1 = new unique int();
> > unique int* p2 = new unique int();
>
> > p1 = p2 ;// error: p1 was not deleted
>
> > delete p1;
> > p1 = std::move(p2); // ok
>
> > delete p1;
> > p1 = new unique int(); //ok
>
> > delete p1; //ok
> > delete p2; //ok
>
> > }


> The point is to automate resource management in an exception-safe way.
> Your proposal doesn't address the point at all, as the memory
> management is manual. The code I am quoting is definitely not
> exception-safe.
>

Any path who calls the destructor must be checked by the compiler to
see if the pointer is null, including exceptions, returns, goto etc...
One problem is that compilers could differ how smart they are do
detect this and them the code would be different in each compiler. The
delete before destructor should be very straightforward to have
agreement of all compilers, and the smart pointers would be used as
well to call this delete and tell the compiler that the code is safe.
At this point it seems that the solution returns to smart pointers
again, or the "deleter" should be part of the modifier.




--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Is there any standard/guarantees for exception safety in STL operations?
Next: problem with partial ordering of classes