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

Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-08-12 05:01:26

On Aug 11, 2013, at 8:45 PM, Edward Diener <eldiener_at_[hidden]> wrote:

> 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

You need the container for push_back().

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

That's not a read function.

> In either case your above code does not make sense to me, and seems unnecessary.

reserve() allocates uninitialized, contiguous memory, which is ideal for a read buffer. In order to use that memory, you need a pointer to it. v[0] is the first element in that allocation, so &v[0] is the start of that allocation, but referencing that element is UB without first adding it

> 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

As I noted previously, resize() initializes each element, which is often unneeded.

> 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.

...or missed the point.

>> That can be simplified by a wrapper class.

Does a wrapper class make more sense now?

>>>> 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.

std::vector manages memory for me quite nicely, thank you. It can even be used in a loop that dynamically determines the needed allocation.

>>>> 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 ?

Allocating from the free store is costlier than off the stack. For local allocations, within reason, stack is much better. A vector data member in an object allocated on the free store means a second free store allocation plus an indirection. The array classes are better in these cases.

HTH

___
Rob

(Sent from my portable computation engine)