Myth of a Myth?
-
From CP newsletter The Myth of Smart Pointers – Logikal Blog[^] Basically complaining about what unique_ptr is defined as. Myself reading it and looking at the code it seems to me that the author does not understand the difference between the C++ specification and the C++ compiler/runtime. Which has always been a problem for some people using C/C++ pointers since C (before C++ existed.) The author seems to be suggesting that the specification is guaranteeing that the memory will be collected. But without even reading the spec I seriously doubt it says that. I suspect it is noting that the it might be collected so one should not rely on it. There are multiple other places where one can do similar things and it might or might not work depending on compiler, binary and even execution flow (which is really fun to debug.) Perhaps I am mistaken in what I am reading?
-
From CP newsletter The Myth of Smart Pointers – Logikal Blog[^] Basically complaining about what unique_ptr is defined as. Myself reading it and looking at the code it seems to me that the author does not understand the difference between the C++ specification and the C++ compiler/runtime. Which has always been a problem for some people using C/C++ pointers since C (before C++ existed.) The author seems to be suggesting that the specification is guaranteeing that the memory will be collected. But without even reading the spec I seriously doubt it says that. I suspect it is noting that the it might be collected so one should not rely on it. There are multiple other places where one can do similar things and it might or might not work depending on compiler, binary and even execution flow (which is really fun to debug.) Perhaps I am mistaken in what I am reading?
-
From CP newsletter The Myth of Smart Pointers – Logikal Blog[^] Basically complaining about what unique_ptr is defined as. Myself reading it and looking at the code it seems to me that the author does not understand the difference between the C++ specification and the C++ compiler/runtime. Which has always been a problem for some people using C/C++ pointers since C (before C++ existed.) The author seems to be suggesting that the specification is guaranteeing that the memory will be collected. But without even reading the spec I seriously doubt it says that. I suspect it is noting that the it might be collected so one should not rely on it. There are multiple other places where one can do similar things and it might or might not work depending on compiler, binary and even execution flow (which is really fun to debug.) Perhaps I am mistaken in what I am reading?
jschell wrote:
The author seems to be suggesting that the specification is guaranteeing that the memory will be collected. But without even reading the spec I seriously doubt it says that. I suspect it is noting that the it might be collected so one should not rely on it.
Of course it doesn't guarantee. Where the memory is coming from and where it is going to, is outside the scope of the language specification. From C++11 to C++23 there was some kind of support for garbage collection using
std::declare_reachabl
e, but it was deleted[^].Mircea
-
From CP newsletter The Myth of Smart Pointers – Logikal Blog[^] Basically complaining about what unique_ptr is defined as. Myself reading it and looking at the code it seems to me that the author does not understand the difference between the C++ specification and the C++ compiler/runtime. Which has always been a problem for some people using C/C++ pointers since C (before C++ existed.) The author seems to be suggesting that the specification is guaranteeing that the memory will be collected. But without even reading the spec I seriously doubt it says that. I suspect it is noting that the it might be collected so one should not rely on it. There are multiple other places where one can do similar things and it might or might not work depending on compiler, binary and even execution flow (which is really fun to debug.) Perhaps I am mistaken in what I am reading?
It was a silly article, going out of his way to create a bug and then blaming it on the thing he just intentionally broke. But doing things with C++ that rely on platform/compiler specific details is explicitly allowed, and frequently necessary. The C++ specification alone does not make enough guarantees to result in a useful system - intentionally, so that the details can differ.