Subject: Re: [boost] [Interprocess] Named pipe interface proposal
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2013-08-11 20:53:53
On Aug 11, 2013, at 5: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 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;
>> read(&v, v.capacity());
> I don't know what "read(&v, 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
I can't see it doing that - because it would need a reference to the vector to do the push_back.
> 2) will copy some number of bytes already read into the vector.
If it did this, v.size() would still == 1.
> In either case your above code does not make sense to me, and seems unnecessary.
I don't know about "unnecessary", but I agree this call does not make sense to me.
Maybe there's some more information here that I'm missing.
> 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 ?
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Marshall Clow Idio Software <mailto:mclow.lists_at_[hidden]>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
-- Yu Suzuki
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk