Tony said:
Did you read all the implementations of the libraries you used?
The implementation can vary also, while APIs are usually stable.
Been there. Done that. I wanted architecture/design documentation on the
memory management.
There is no need to be a guru to understand how containers handle memory.
std::vector, for example, asks for a contiguous segment of memory of T's
through the standard allocator (or another one if you provide it), then
uses placement new to construct the objects.
Of course, to provide the complexity the standard requires, it needs to
allocate more than it needs. The "more" is implementation dependent and
is at least sqrt(n) where n is the number of elements.
What may be bothering you is that they often do not give the memory back
to the system when shrinking, and may not even do so when freeing. The
standard doesn't really put constraints on how vector manages its
capacity to amortize operations.
There is no such problem with node based containers though, that can
allocate memory as needed without performance issues.
Performance is overrated, these days.
Well, if you store pointers instead of objects, you're basically stuck
with "everything is a pointer".
That's a huge performance hit. You might as well use Java, which
actually will be more efficient since it has GC, which are basically
needed to make "everything is a pointer" efficient.
Readability improves, usage improves
safety need not be compromised.
What you don't seem to understand is that with void* you lose
readability, easy usage and safety.
std::vector<void*> v;
v.push_back(new int(5));
v.push_back(new double(6.));
std::cout << *((int*)v[1]) << std::endl;
1) You need to cast to get back to the original type, which is verbose.
This is still needed if want heterogenous containers though.
2) While casting you may do things wrong and produce undefined behaviour
3) How should memory be handled here?
But I don't want to get into the details:
just go find another well-implemented library and look at it.
Again, who cares about how a library is implemented?
What's important is that it does what it does in the most efficient way.
The code of your compiler is not supposed to be easy to read so that
beginners can understand how a compiler works. It's supposed to analyse
correctly your code and produce the most efficient assembler.
To understand how it works, read the documentation.
No, it's a fact.
And it doesn't even allow specialization.
Hehe. OK, if you say so then surely it must be so.
You have made numerous posts criticizing C++ while you obviously don't
have much knowledge about it, and even less usage.
Again, performance is overrated in many many cases. In many many cases,
it doesn't even matter what container you use. You'd have to be doing things
with thousands of objects before performance concerns became important.
Sure, O(1) and O(n) are the same things.
What kind of algorithmic course did you follow? The one for dummies?
Or maybe you just never worked with applications that had to scale.
