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
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, I was wrong, since you are correct on how those types work. You are wrong in thinking I don't know about storage classes, of course. (Also, we're not going to get anywhere with claims of C++ expertise. I assumed your expertise was on a par with the accuracy of your claims.)
Because I'm annoyed, I'm going to point out that function arguments can also be moved, not copied, in some cases, and that your use of "auto" is not only obsolete (in C++) but also highly idiosyncratic. The committee decided "auto" could be repurposed because approximately nobody ever used it as a keyword, based on a very large survey of source code.
And where did you get that thing about putting "static" on function arguments? "static" can be used on member variables and functions (meaning they're class-based and not tied to any object), non-class variables (giving them static storage duration), or it can be used to specify internal linkage. It's not something that goes on function arguments.
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: (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:new and delete; viral disposability (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, I was wrong, since you are correct on how those types work. You are wrong in thinking I don't know about storage classes, of course. (Also, we're not going to get anywhere with claims of C++ expertise. I assumed your expertise was on a par with the accuracy of your claims.)
Because I'm annoyed, I'm going to point out that function arguments can also be moved, not copied, in some cases, and that your use of "auto" is not only obsolete (in C++) but also highly idiosyncratic. The committee decided "auto" could be repurposed because approximately nobody ever used it as a keyword, based on a very large survey of source code.
And where did you get that thing about putting "static" on function arguments? "static" can be used on member variables and functions (meaning they're class-based and not tied to any object), non-class variables (giving them static storage duration), or it can be used to specify internal linkage. It's not something that goes on function arguments.