On Monday 08 July 2013 07:22:53 you wrote:
On Sunday 07 July 2013 21:38:08 Sid Sacek wrote:
Peter Dimov wrote:
Once C++14 becomes an official standard, it'd become possible for N3640 to be discussed and, hopefully, accepted;
I then tried to get the buffer length (in code) but hit a brick wall.
int len = buffer.length; // doesn't exist int len = buffer.length(); // doesn't exist int len = buffer.capacity; // doesn't exist int len = buffer.capacity(); // doesn't exist int len = buffer.size; // doesn't exist int len = buffer.size(); // doesn't exist
I thought about it a little, and I guess I could write a wrapper class around shared_ptr<> to provide buffering features.
class shared_buffer : public shared_ptr< unsigned char [] > {
size_t capacity; ...
}
I can't stop thinking about this. What would be the harm in providing a 'capacity()' member ?
buffer = boost::make_shared< unsigned char[] >( 1234 );
int capacity = buffer.capacity();
It can be designed such that that no matter how the new 'shared_ptr
' object is instantiated, the size of the array is always known, and hence the capacity should always be available. I don't know how big of a change this is to the existing classes, but it could be made into a requirement. And even if it could not be made a requirement, buffers with unknown sizes would simply return -1. That means that coders who care about the capacity() would supply it in their code, and those who don't care would use the classes in the old fashioned way.
Why not simply use vector or shared_ptr< vector<...> >?
...or even shared_ptr< array<...> >?