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.
shared_ptrs pretty much solve all the crazy exception-case memory leaks. Move semantics fixes other edge cases by letting use detect temporaries.
I *only* produce code that has 0 "definitely" and 0 "possibly" output from Valgrind. A single commit that adds a leak is not allowed.
I'm talking about a huge code base that takes over 5 minutes to compile on a decent machine with well over 100,000 lines. Yet my code is 100% leak free and will remain so.
Plus when you deal with big data like I do, manual
Try to work with Delegates on C#, or their equivalent in Java (listeners and anonymous classes) and you'll see it is easy to have an object registered somewhere, and then never collected, despite you having forgotten all about it.
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.
That isn't much different from a third-party C# library improperly using your IDisposable object in a using-block[1], thereby unexpectedly calling its Dispose method. In Java, a third-party library could erroneously free one or more objects of an object array passed to it, or (as of Java 7) problems could arise from multiple calls to AutoClosable.Close, which is not guaranteed to be idempotent.
In short, buggy third-party libraries in any language can impact even pristine code.
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.
OK, so you have to call the destructors and finalizer instead of explicitly freeing. So in essence the garbage collector doesn't work and you still have to keep track of your resources and free them accordingly. Great, you get all the bad things from both paradigms.
The great benefit you get from garbage collection is that the actual freeing of the memory can be postponed to when the program execution ends with the added penalty of needing about three times more memory to not get random performance penalties
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.
after reading thru this thread and many others. I've come to the conclusion that angel is a huge asshole. he is conceded, big headed, ignorant, and a fucking wArt on this->industry. he always downs other people and trashes everything he is not a fanboi of. instead of talking to people politely and working with them, he mocks them and criticizes their train of thought because it doesn't resemble his. it's a shame to because angel you really are a smart person, we get that. you could add so much to this ind
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,
Sorry I wasn't clear in my OP; what I meant to ask was: "Why doesn't C++ have in language support for allocating and deallocating variables automatically on the heap." C++ handles allocating and deallocating variables automatically on the stack, why not the heap? Having to use RAII for heap memory allocation is a language FAIL. GCs are also a FAIL; at the minimum they screw up predictability.
What I meant to ask in my OP was: "Why doesn't C++ have language support for allocation and deallocation of variables on the heap. C++ manages the lifetimes of stack variables, why not heap variables?"
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.
Re: (Score:0)
Re: (Score:0)
No... just NO.
shared_ptrs pretty much solve all the crazy exception-case memory leaks.
Move semantics fixes other edge cases by letting use detect temporaries.
I *only* produce code that has 0 "definitely" and 0 "possibly" output from Valgrind. A single commit that adds a leak is not allowed.
I'm talking about a huge code base that takes over 5 minutes to compile on a decent machine with well over 100,000 lines. Yet my code is 100% leak free and will remain so.
Plus when you deal with big data like I do, manual
Re: (Score:0)
Try to work with Delegates on C#, or their equivalent in Java (listeners and anonymous classes) and you'll see it is easy to have an object registered somewhere, and then never collected, despite you having forgotten all about it.
That's a leak.
With a GC.
Suck it up.
Re: (Score:0)
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.
That isn't much different from a third-party C# library improperly using your IDisposable object in a using-block[1], thereby unexpectedly calling its Dispose method. In Java, a third-party library could erroneously free one or more objects of an object array passed to it, or (as of Java 7) problems could arise from multiple calls to AutoClosable.Close, which is not guaranteed to be idempotent.
In short, buggy third-party libraries in any language can impact even pristine code.
- T
[1] I encountered this 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:0)
OK, so you have to call the destructors and finalizer instead of explicitly freeing.
So in essence the garbage collector doesn't work and you still have to keep track of your resources and free them accordingly. Great, you get all the bad things from both paradigms.
The great benefit you get from garbage collection is that the actual freeing of the memory can be postponed to when the program execution ends with the added penalty of needing about three times more memory to not get random performance penalties
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: new and delete; viral disposability (Score:0)
after reading thru this thread and many others. I've come to the conclusion that angel is a huge asshole. he is conceded,
big headed, ignorant, and a fucking wArt on this->industry. he always downs other people and trashes everything he is not a fanboi of. instead of talking to people politely and working with them, he mocks them and criticizes their train of thought because it doesn't resemble his. it's a shame to because angel you really are a smart person, we get that. you could add so much to this ind
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:0)
Sorry I wasn't clear in my OP; what I meant to ask was:
"Why doesn't C++ have in language support for allocating and deallocating variables automatically on the heap."
C++ handles allocating and deallocating variables automatically on the stack, why not the heap?
Having to use RAII for heap memory allocation is a language FAIL.
GCs are also a FAIL; at the minimum they screw up predictability.
Re: (Score:2)
Re: (Score:2)
OP AC is a moron. He's not gonna get it.
Heap Variable lifetime management. (Score:0)
What I meant to ask in my OP was:
"Why doesn't C++ have language support for allocation and deallocation of variables on the heap. C++ manages the lifetimes of stack variables, why not heap variables?"