Re: [boost] [Interprocess] Named pipe interface proposal

Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-08-11 20:45:53

On 8/11/2013 3:39 PM, Rob Stewart wrote:
> On Aug 11, 2013, at 9:50 AM, Edward Diener <eldiener_at_[hidden]> wrote:
>
>> On 8/10/2013 8:59 PM, Rob Stewart wrote:
>>> On Aug 10, 2013, at 8:25 AM, Edward Diener <eldiener_at_[hidden]> wrote:
>>>>
>>>> std::vector<TYPE> is the C++ way of specifying arrays.
>>>
>>> If you do that, don't use resize() and size(). Use reserve() and capacity(), and don't forget to push_back() one element to make &v[0] valid.
>>
>> I do not follow this. Especially the bit about pushing back an element. Vectors can be empty as I am sure you know and there are still valid.
>
> Accessing an element of an empty vector is undefined behavior. Calling resize() to reserve space also causes elements to be initialized, which is often not needed when calling an API that indicates the number of bytes written.
>
> What I often do is the following:
>
> std::vector<char> v;
> v.reserve(1024);
> v.push_back(0);
> read(&v[0], v.capacity());

I don't know what "read(&v[0], v.capacity())" is doing here. is this 
supposed to be a named pipe 'read'-like function ? Whatever it is either 
the 'read' will:

1)  read a byte at a time and add it to the end of the vector via a 
push_back

or

2) will copy some number of bytes already read into the vector.

In either case your above code does not make sense to me, and seems 
unnecessary. If I am doing 1) there is no need for it. If I am doing 2) 
I better resize the vector to the number of bytes I need or use an 
inserter. if my 'read' function isn't smart enough to just take a vector 
and fill it with what's read, I have programmed the wrong function.

>
> That can be simplified by a wrapper class.
>
>>> Having said all that, it really should be wrapped in a buffer class to prevent mistakes. Perhaps that has the makings of a useful Boost addition in its own right.
>>
>> Do you actually do this in your programming ? To "prevent mistakes" ?
>
> I've been doing that enough lately that I should. Indeed, I intend to do that this week because I've thought over the number of times I've managed that by hand over the years. It's past time for me to wrap that logic.

I don't think you like std::vector. For some reason you want something 
else, but I don't know what that is or why.

>
>>> There's also std::array and boost::array.
>>
>> Sure, but why not use the normal C++ construct.
>
> How are those array classes not "normal C++ construct[s]"? They are appropriate for local allocations of modest sizes, though they can be used in free store allocated objects with much larger sizes. (My 1024-byte example, for example, would do well with array rather than vector.)

Because when you already have a dynamically allocated array in 
std::vector you need some reason for giving it up and doing something 
else. Why re-invent the wheel for no reason ?