On Jul 8, 2013, at 11:54 AM, "Peter Dimov"
Rob Stewart wrote: ...
That's error-prone. Why not provide (non-zero) capacity when using make_shared(), and leave the non-make_shared() usage with a zero capacity?
That's not very convenient. Suppose you get a T* from some place and need to pass shared_ptr
to another that requires a known size. You know the size, but you won't be able to pass it.
Agreed. I wasn't suggesting it was a perfect solution.
It's also error prone. If you have an interface that takes shared_ptr
and size_t, you can tell that the code is passing a size by mere visual inspection.
Of course, but that also leads to errors common in C that we would do well to improve.
But if the function only takes a shared_ptr
, and if shared_ptr might or might not have a size, it's not immediately obvious whether you are passing a size or not. Maybe you are, maybe you aren't; we'll have to wait until runtime and see.
I would prefer that the extent always be known, and omitting it if only sometimes known is probably the wisest course. Nevertheless, you surely agree that one cannot read or write anything without knowing the extent, so finding a means to do that would be good.
Finally, zero is technically a legitimate value for the size, signifying an empty array, so overloading it to denote "unknown" may not be the best option.
It means one cannot read or write any elements, just as now, and isn't used by the deleter, so it is a step in the right direction. ___ Rob (Sent from my portable computation engine)