Boost logo

Boost :

Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-08-11 15:39:30


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());

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.

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

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk