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 what I call "viral disposability" [pineight.com]: a conventional name for an explicit destructor method that an object's owner must remember to call, and anything holding a disposable object must also be disposable.
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.
Garbage collection solves many memory allocation bugs by introducing new bugs, and other issues like massive memory bloat. It's just another magic solution to poor programming which allows poor programmers to screw things up in new and creative ways.
If you think so, you are likely a poor programmer yourself. I have never seen a C/C++ application with no memory errors. Even I had once one, a third party library deleted the pointer I handed to it... pretty bizarre. Your conceptions/perceptions about GC are simply wrong, I suggest you work with a GCed language once.
A GC works on pointers/references, and works seamlessly together with RIAA, constructors/destructors.
Assuming you meant RAII and not the record industry, popular GC environments don't even guarantee that an object's destructor or finalizer will ever get called. So in a fully GC environment, without using the dispose pattern [wikipedia.org], how can you ensure that the non-memory resource that an object owns will get released?
When I combine a RAII and a GC I ofc, program the GC in calling the destructor AND the finalizer, a no brainer. Or likely I let the finalizer decides if it needs to call the destructor (because it might already have been called).
If you are interested in this, look how.Net managed C++ does it, they have GC, RAII and destructors as well as finalizers.
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 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 what I call "viral disposability" [pineight.com]: a conventional name for an explicit destructor method that an object's owner must remember to call, and anything holding a disposable object must also be disposable.
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)
Garbage collection solves many memory allocation bugs by introducing new bugs, and other issues like massive memory bloat. It's just another magic solution to poor programming which allows poor programmers to screw things up in new and creative ways.
Re: (Score:2)
If you think so, you are likely a poor programmer yourself. ... pretty bizarre.
I have never seen a C/C++ application with no memory errors. Even I had once one, a third party library deleted the pointer I handed to it
Your conceptions/perceptions about GC are simply wrong, I suggest you work with a GCed language once.
GC won't always call destructors (Score:2)
A GC works on pointers/references, and works seamlessly together with RIAA, constructors/destructors.
Assuming you meant RAII and not the record industry, popular GC environments don't even guarantee that an object's destructor or finalizer will ever get called. So in a fully GC environment, without using the dispose pattern [wikipedia.org], how can you ensure that the non-memory resource that an object owns will get released?
Re: (Score:2)
When I combine a RAII and a GC I ofc, program the GC in calling the destructor AND the finalizer, a no brainer. Or likely I let the finalizer decides if it needs to call the destructor (because it might already have been called).
If you are interested in this, look how .Net managed C++ does it, they have GC, RAII and destructors as well as finalizers.
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: (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,
Re: (Score:2)
Re: (Score:2)
OP AC is a moron. He's not gonna get it.