Why doesn't C++ have in language support for memory allocation? And don't give me that baloney about it being a library feature: We all know that memory allocation of variables on the stack is not handled manually by the programmer. If you don't add it C# and Java with their GC awfulness will continue to eat C++'s lunch.
Why doesn't C++ have in language support for memory allocation?
C++ has the new and delete operators, whose low-level operation a class can customize. Could you clarify what you're asking for?
If you don't add it C# and Java with their GC awfulness will continue to eat C++'s lunch.
The problem with tracing garbage collection as implemented in Java, C#, and the like is that it tends to break the Resource Acquisition Is Initialization (RAII) idiom [wikipedia.org] seen in C++, where an object's destructor is responsible for freeing non-memory resources held by the object, and the language supports calling this destructor automatically in many cases. Instead, GC languages have w
That is nonsense. RAII concepts work on plain objects, which enter scope and leave scope, like in a function, and call the constructor on 'allocation' and the destructor when the scope is left. Either via an exception or a return.
A GC works on pointers/references, and works seamlessly together with RIAA, constructors/destructors.
Worst case is, a GC stumbles over some memory that is already flagged as being freed due to a 'delete' in a destructor.
With a smart pointer, RAII works just peachy on memory, as well as any other form of resource. std::shared_ptr is reference-count garbage collection - not the best, but I think it's worth it to have a uniform method of resource management.
GC does not work with destructors, since it's usually not even guaranteed that a destructor or equivalent will be called. Some languages have separate basic/primitive types and pointer/reference types, but that's not the case in C++.
Using a smart pointer in a function is something completely different than using a plain object for RAII.
GC does not work with destructors, since it's usually not even guaranteed that a destructor or equivalent will be called. That is either plain wrong or a misconception. Java or C# has mo destructors, but uses GC, so claiming anything about them is pointless. Managed C++ has destructors AND finalizers AND GC, and the destructor is called if needed...
Perhaps you mix up the fact that no one guarantees that
In C++, it would be dangerous to add differences between some sort of resource-controlling object on the stack vs. on the free store. They are the same object, allocated differently. They are not completely different.
The GC I'm familiar with doesn't work well with destructors. RAII depends heavily on destructors. I'll have to see what Managed C++ (or C++/CLI or whatever) does with them. If it just differentiates between stuff that will have destructors and stuff that will be garbage collected, it's
GCed objects are allocated with new. Standard allocated objects are managed with new/delete.
RAII objects are statically/automatically initialized, that means they 'are not on the heap'! That means the GC won't even see them and would definitely not interfere with them.
Even with a GC below your belt using smart pointers still would work.
You simply don't get that all this 'constructs' are not even orthogonal but parallel concepts that easy fit together.
RAII objects are constructed. This can very definitely be on the heap. If, for example, I want an RAII object for something shared in several places, I would probably put it into a shared_ptr, and that does mean on the heap. Consider "make_shared(new DatabaseConnection);". That would work just fine. Where did you learn C++?
You simply don't get that RAII practice in C++ isn't what you expect. Are you more familiar with languages like C# or Java? In those languages, there's a distinction between sta
RAII objects are constructed. This can very definitely be on the heap. If, for example, I want an RAII object for something shared in several places, I would probably put it into a shared_ptr, and that does mean on the heap. Consider "make_shared(new DatabaseConnection);". That would work just fine. Where did you learn C++?
Erm, where did you learn C++? The DatabaseConnection is not a RAII object... the shared_ptr is!
Everything you allocate with new is on the heap or wherever your self programmed operator new() puts it. Everything you allocate with new is not a RAII object.
To have RAII objects you have to allocate them statically or on the stack. A no brainer.
Wrapping pointers into any kind of helper template makes that helper template the RAII object. And ofc. that object can delete the pointer it is holding.
The idea of having GCable and non-GCable classes introduces more complexity, and offers a really Obscure way to get resource management wrong no it does not:D that is only your perception.
Where did I learn C++? Primarily on the job over fifteen years ago, supplemented by reading extensively. I'm not claiming to be a real expert, but I do have reasons behind what I say.
In what sense is a DatabaseConnection not an RAII object? Assuming the constructor allocates the connection, and the destructor gets rid of it, it's an RAII object. It's frequently true that the destructor is at the end of a block, but it could also be due to being owned by another object that deletes it on destruction,
Memory Allocation (Score:0)
Why doesn't C++ have in language support for memory allocation?
And don't give me that baloney about it being a library feature: We all know that memory allocation of variables on the stack is not handled manually by the programmer.
If you don't add it C# and Java with their GC awfulness will continue to eat C++'s lunch.
new and delete; viral disposability (Score:3)
Why doesn't C++ have in language support for memory allocation?
C++ has the new and delete operators, whose low-level operation a class can customize. Could you clarify what you're asking for?
If you don't add it C# and Java with their GC awfulness will continue to eat C++'s lunch.
The problem with tracing garbage collection as implemented in Java, C#, and the like is that it tends to break the Resource Acquisition Is Initialization (RAII) idiom [wikipedia.org] seen in C++, where an object's destructor is responsible for freeing non-memory resources held by the object, and the language supports calling this destructor automatically in many cases. Instead, GC languages have w
Re: (Score:2)
That is nonsense.
RAII concepts work on plain objects, which enter scope and leave scope, like in a function, and call the constructor on 'allocation' and the destructor when the scope is left. Either via an exception or a return.
A GC works on pointers/references, and works seamlessly together with RIAA, constructors/destructors.
Worst case is, a GC stumbles over some memory that is already flagged as being freed due to a 'delete' in a destructor.
Re: (Score:2)
With a smart pointer, RAII works just peachy on memory, as well as any other form of resource. std::shared_ptr is reference-count garbage collection - not the best, but I think it's worth it to have a uniform method of resource management.
GC does not work with destructors, since it's usually not even guaranteed that a destructor or equivalent will be called. Some languages have separate basic/primitive types and pointer/reference types, but that's not the case in C++.
Re: (Score:2)
Using a smart pointer in a function is something completely different than using a plain object for RAII.
GC does not work with destructors, since it's usually not even guaranteed that a destructor or equivalent will be called. That is either plain wrong or a misconception. Java or C# has mo destructors, but uses GC, so claiming anything about them is pointless. Managed C++ has destructors AND finalizers AND GC, and the destructor is called if needed ...
Perhaps you mix up the fact that no one guarantees that
Re: (Score:2)
In C++, it would be dangerous to add differences between some sort of resource-controlling object on the stack vs. on the free store. They are the same object, allocated differently. They are not completely different.
The GC I'm familiar with doesn't work well with destructors. RAII depends heavily on destructors. I'll have to see what Managed C++ (or C++/CLI or whatever) does with them. If it just differentiates between stuff that will have destructors and stuff that will be garbage collected, it's
Re: (Score:2)
Sigh ... you are half right and all wrong.
GCed objects are allocated with new. Standard allocated objects are managed with new/delete.
RAII objects are statically/automatically initialized, that means they 'are not on the heap'! That means the GC won't even see them and would definitely not interfere with them.
Even with a GC below your belt using smart pointers still would work.
You simply don't get that all this 'constructs' are not even orthogonal but parallel concepts that easy fit together.
Especially in C
Re: (Score:2)
RAII objects are constructed. This can very definitely be on the heap. If, for example, I want an RAII object for something shared in several places, I would probably put it into a shared_ptr, and that does mean on the heap. Consider "make_shared(new DatabaseConnection);". That would work just fine. Where did you learn C++?
You simply don't get that RAII practice in C++ isn't what you expect. Are you more familiar with languages like C# or Java? In those languages, there's a distinction between sta
Re:new and delete; viral disposability (Score:2)
RAII objects are constructed. This can very definitely be on the heap. If, for example, I want an RAII object for something shared in several places, I would probably put it into a shared_ptr, and that does mean on the heap. Consider "make_shared(new DatabaseConnection);". That would work just fine. Where did you learn C++?
Erm, where did you learn C++? ... the shared_ptr is!
The DatabaseConnection is not a RAII object
Everything you allocate with new is on the heap or wherever your self programmed operator new() puts it.
Everything you allocate with new is not a RAII object.
To have RAII objects you have to allocate them statically or on the stack. A no brainer.
Wrapping pointers into any kind of helper template makes that helper template the RAII object. And ofc. that object can delete the pointer it is holding.
The idea of having GCable and non-GCable classes introduces more complexity, and offers a really Obscure way to get resource management wrong no it does not :D that is only your perception.
Re: (Score:2)
Where did I learn C++? Primarily on the job over fifteen years ago, supplemented by reading extensively. I'm not claiming to be a real expert, but I do have reasons behind what I say.
In what sense is a DatabaseConnection not an RAII object? Assuming the constructor allocates the connection, and the destructor gets rid of it, it's an RAII object. It's frequently true that the destructor is at the end of a block, but it could also be due to being owned by another object that deletes it on destruction,