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.
Especially in C++ where you could simply require that all GCed classes implement the new() operator in a specific way.
I'm definitely not interested in cases where I'd have to change anything outside the class definition if I add a std::vector to the class. If you had GC, what would you need to change? Nothing ofc... (* facepalm *)
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 ne
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,
Oh, I oversaw this: Are you more familiar with languages like C# or Java? In those languages, there's a distinction between stack data types and heap data types, which is completely lacking in C++
Wrong in all cases, most importantly it is not a data type, except in C#, but a storage class: Java does not distinguish, as it can't. You can only create objects on the heap, even loaded classes are objects on the heap. The exception are primitive data types that are "defined" inside methods and parameters passed t
Interesting post. First you claim that I'm wrong in saying that, in Java, some data types are stack-only and some are heap-only. Then you claim that object types are heap-only and primitive types are stack-only.
Basically, I'm trying to figure out what sort of reasoning got you to think that RAII objects are stack-based only. One common confusion for people who write Java and C# is that C++ has no concept of stack- and heap-based data types, and I was wondering if you were confused by that. Evidently,
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:new and delete; viral disposability (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++ where you could simply require that all GCed classes implement the new() operator in a specific way.
I'm definitely not interested in cases where I'd have to change anything outside the class definition if I add a std::vector to the class. If you had GC, what would you need to change? Nothing ofc ... (* facepalm *)
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: (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 ne
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,
Re: (Score:2)
Oh, I oversaw this:
Are you more familiar with languages like C# or Java? In those languages, there's a distinction between stack data types and heap data types, which is completely lacking in C++
Wrong in all cases, most importantly it is not a data type, except in C#, but a storage class:
Java does not distinguish, as it can't. You can only create objects on the heap, even loaded classes are objects on the heap. The exception are primitive data types that are "defined" inside methods and parameters passed t
Re: (Score:2)
Interesting post. First you claim that I'm wrong in saying that, in Java, some data types are stack-only and some are heap-only. Then you claim that object types are heap-only and primitive types are stack-only.
Basically, I'm trying to figure out what sort of reasoning got you to think that RAII objects are stack-based only. One common confusion for people who write Java and C# is that C++ has no concept of stack- and heap-based data types, and I was wondering if you were confused by that. Evidently,