Re: C++ question about auto_ptr
Le 09/05/2015 09:18, Abdelrazak Younes a écrit : On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote: With C++11, auto_ptr is deprecated and we get warnings. I am trying to see how we can get rid of it. unique_ptr is new to C++11, so I'd rather avoid that. Why that? unique_ptr is supported since gcc 4.4 released in 2009: We just have to check that this does not require to be in C++11 mode. Or we could decide to make C++11 the default. But quite frankly C++11 is very nice and moving to gcc 4.7 would enable almost full C++11...; auto for example would improve the readability of the code significantly. C++11 thread are quite nice as well if you want to get rid of Qt thread in the core. I agree that C++11 is very desirable. But releasing 2.2 soon is even more desirable. JMarc
Re: C++ question about auto_ptr
On 09/05/2015 11:37, Jean-Marc Lasgouttes wrote: Le 09/05/2015 09:18, Abdelrazak Younes a écrit : On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote: With C++11, auto_ptr is deprecated and we get warnings. I am trying to see how we can get rid of it. unique_ptr is new to C++11, so I'd rather avoid that. Why that? unique_ptr is supported since gcc 4.4 released in 2009: We just have to check that this does not require to be in C++11 mode. I guess it does. Or we could decide to make C++11 the default. Exactly my point ;-) But quite frankly C++11 is very nice and moving to gcc 4.7 would enable almost full C++11...; auto for example would improve the readability of the code significantly. C++11 thread are quite nice as well if you want to get rid of Qt thread in the core. I agree that C++11 is very desirable. But releasing 2.2 soon is even more desirable. Sure. Abdel.
Re: C++ question about auto_ptr
Le 08/05/2015 23:10, Georg Baum a écrit : I have many places like in the patch below. Is there a reason why I should keep the auto_ptr instead of a naked pointer? What is it good for? Usually it is used for exception safety: If you use a raw pointer, you need to delete it in the catch clause, else you get a memory leak. This would be easy to do in this particular example, but impossible if the catch happens somewhere completely different. OK, I read some FAQs now. The issue is not the memory of the object itself, but the fact the the destructor is not tun, which means that the memory it may have allocated (string, ...) is not released. So we need yet another special header, as I see it. JMarc
Re: C++ question about auto_ptr
On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote: With C++11, auto_ptr is deprecated and we get warnings. I am trying to see how we can get rid of it. unique_ptr is new to C++11, so I'd rather avoid that. Why that? unique_ptr is supported since gcc 4.4 released in 2009: https://gcc.gnu.org/gcc-4.4/changes.html I guess this is old enough... But quite frankly C++11 is very nice and moving to gcc 4.7 would enable almost full C++11...; auto for example would improve the readability of the code significantly. C++11 thread are quite nice as well if you want to get rid of Qt thread in the core. I have many places like in the patch below. Is there a reason why I should keep the auto_ptr instead of a naked pointer? In this particular example no real advantage IMO. What is it good for? Mainly avoid memory leak for incautious programmers :-) Abdel.
Re: C++ question about auto_ptr
On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote: With C++11, auto_ptr is deprecated and we get warnings. I am trying to see how we can get rid of it. unique_ptr is new to C++11, so I'd rather avoid that. Why that? unique_ptr is supported since gcc 4.4 released in 2009: https://gcc.gnu.org/gcc-4.4/changes.html I guess this is old enough... But quite frankly C++11 is very nice and moving to gcc 4.7 would enable almost full C++11...; "auto" for example would improve the readability of the code significantly. C++11 thread are quite nice as well if you want to get rid of Qt thread in the core. I have many places like in the patch below. Is there a reason why I should keep the auto_ptr instead of a naked pointer? In this particular example no real advantage IMO. What is it good for? Mainly avoid memory leak for incautious programmers :-) Abdel.
Re: C++ question about auto_ptr
Le 09/05/2015 09:18, Abdelrazak Younes a écrit : On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote: With C++11, auto_ptr is deprecated and we get warnings. I am trying to see how we can get rid of it. unique_ptr is new to C++11, so I'd rather avoid that. Why that? unique_ptr is supported since gcc 4.4 released in 2009: We just have to check that this does not require to be in C++11 mode. Or we could decide to make C++11 the default. But quite frankly C++11 is very nice and moving to gcc 4.7 would enable almost full C++11...; "auto" for example would improve the readability of the code significantly. C++11 thread are quite nice as well if you want to get rid of Qt thread in the core. I agree that C++11 is very desirable. But releasing 2.2 soon is even more desirable. JMarc
Re: C++ question about auto_ptr
On 09/05/2015 11:37, Jean-Marc Lasgouttes wrote: Le 09/05/2015 09:18, Abdelrazak Younes a écrit : On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote: With C++11, auto_ptr is deprecated and we get warnings. I am trying to see how we can get rid of it. unique_ptr is new to C++11, so I'd rather avoid that. Why that? unique_ptr is supported since gcc 4.4 released in 2009: We just have to check that this does not require to be in C++11 mode. I guess it does. Or we could decide to make C++11 the default. Exactly my point ;-) But quite frankly C++11 is very nice and moving to gcc 4.7 would enable almost full C++11...; "auto" for example would improve the readability of the code significantly. C++11 thread are quite nice as well if you want to get rid of Qt thread in the core. I agree that C++11 is very desirable. But releasing 2.2 soon is even more desirable. Sure. Abdel.
Re: C++ question about auto_ptr
Le 08/05/2015 23:10, Georg Baum a écrit : I have many places like in the patch below. Is there a reason why I should keep the auto_ptr instead of a naked pointer? What is it good for? Usually it is used for exception safety: If you use a raw pointer, you need to delete it in the catch clause, else you get a memory leak. This would be easy to do in this particular example, but impossible if the catch happens somewhere completely different. OK, I read some FAQs now. The issue is not the memory of the object itself, but the fact the the destructor is not tun, which means that the memory it may have allocated (string, ...) is not released. So we need yet another special header, as I see it. JMarc
C++ question about auto_ptr
With C++11, auto_ptr is deprecated and we get warnings.
I am trying to see how we can get rid of it. unique_ptr is new to C++11,
so I'd rather avoid that.
I have many places like in the patch below. Is there a reason why I
should keep the auto_ptr instead of a naked pointer? What is it good for?
JMarc
diff --git a/src/BufferList.cpp b/src/BufferList.cpp
index 68a1e80..724c7dd 100644
--- a/src/BufferList.cpp
+++ b/src/BufferList.cpp
@@ -130,9 +130,9 @@ Buffer * BufferList::newBuffer(string const s)
Buffer * BufferList::createNewBuffer(string const s)
{
- auto_ptrBuffer tmpbuf;
+ Buffer * tmpbuf;
try {
- tmpbuf.reset(new Buffer(s));
+ tmpbuf = new Buffer(s);
} catch (ExceptionMessage const message) {
if (message.type_ == ErrorException) {
Alert::error(message.title_, message.details_);
@@ -143,7 +143,7 @@ Buffer * BufferList::createNewBuffer(string const s)
}
}
tmpbuf-params().useClassDefaults();
- return tmpbuf.release();
+ return tmpbuf;
}
Re: C++ question about auto_ptr
Jean-Marc Lasgouttes wrote: With C++11, auto_ptr is deprecated and we get warnings. I am trying to see how we can get rid of it. unique_ptr is new to C++11, so I'd rather avoid that. Why not use unique_ptr fpr C++11 and auto_ptr else? The difference is in the copying semantics, which does not matter for the current use cases. The only challenge would be to find a good name fo the typedef. I have many places like in the patch below. Is there a reason why I should keep the auto_ptr instead of a naked pointer? What is it good for? Usually it is used for exception safety: If you use a raw pointer, you need to delete it in the catch clause, else you get a memory leak. This would be easy to do in this particular example, but impossible if the catch happens somewhere completely different. Georg
C++ question about auto_ptr
With C++11, auto_ptr is deprecated and we get warnings.
I am trying to see how we can get rid of it. unique_ptr is new to C++11,
so I'd rather avoid that.
I have many places like in the patch below. Is there a reason why I
should keep the auto_ptr instead of a naked pointer? What is it good for?
JMarc
diff --git a/src/BufferList.cpp b/src/BufferList.cpp
index 68a1e80..724c7dd 100644
--- a/src/BufferList.cpp
+++ b/src/BufferList.cpp
@@ -130,9 +130,9 @@ Buffer * BufferList::newBuffer(string const & s)
Buffer * BufferList::createNewBuffer(string const & s)
{
- auto_ptr tmpbuf;
+ Buffer * tmpbuf;
try {
- tmpbuf.reset(new Buffer(s));
+ tmpbuf = new Buffer(s);
} catch (ExceptionMessage const & message) {
if (message.type_ == ErrorException) {
Alert::error(message.title_, message.details_);
@@ -143,7 +143,7 @@ Buffer * BufferList::createNewBuffer(string const & s)
}
}
tmpbuf->params().useClassDefaults();
- return tmpbuf.release();
+ return tmpbuf;
}
Re: C++ question about auto_ptr
Jean-Marc Lasgouttes wrote: > With C++11, auto_ptr is deprecated and we get warnings. > > I am trying to see how we can get rid of it. unique_ptr is new to C++11, > so I'd rather avoid that. Why not use unique_ptr fpr C++11 and auto_ptr else? The difference is in the copying semantics, which does not matter for the current use cases. The only challenge would be to find a good name fo the typedef. > I have many places like in the patch below. Is there a reason why I > should keep the auto_ptr instead of a naked pointer? What is it good for? Usually it is used for exception safety: If you use a raw pointer, you need to delete it in the catch clause, else you get a memory leak. This would be easy to do in this particular example, but impossible if the catch happens somewhere completely different. Georg
