On Sun, Nov 6, 2011 at 2:19 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sunday, November 06, 2011 12:15:35 Olaf van der Spek wrote:
On Sat, Nov 5, 2011 at 6:53 PM, Andrey Semashev
It's not a xor. Supporting a (size_t) constructor does not mean you can't (also) implent make_ and allocate_ functions.
Why would we need the ambiguous constructor then? Just do "the right thing" from the start.
Because some people prefer the simpler syntax.
Isn't it kinda like a shared container (except it doesn't know it's size etc)? I'd also like to see a shared_array that knows it's size, this is a first step towards that.
I'd like to repeat that pointers are not containers. Their purpose and
It's about shared_array. Arrays are pointers are not synonyms.
Actually, they are. The only difference is the deallocation method. They stop being similar when you add advanced features I mentioned, then arrays become containers.
shared_ptr doesn't provide operator[], shared_array does. So your statement is clearly false. char a[128] char* p = a; Is sizeof(a) == sizeof(p)? Array and pointer were synonyms, right?
application are quite different, and hence there's no reason to follow containers interface. If you want things like size, iterators and built-in memory management, just use containers. And if you want a shared container, just use shared_ptr with a container.
Stop kidding me please. shared_ptr<vector> is totally unsuitable.
Why?
For example, I can't put a memory mapped file into a vector. I don't (always) want the memory to be initialized. I don't want two allocations. I do want sub arrays. -- Olaf