Boost logo

Boost :

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


On Aug 12, 2013, at 12:49 AM, Edward Diener <eldiener_at_[hidden]> wrote:

> In my prefereed interface it is passing a reference to a vector which is being filled in with the data read. Gee, that's too simple. Must be something seriously wrong with it.

That's restrictive. An interface that takes a pointer plus length, packaged how you like, leaves the caller free to allocate the buffer however it makes most sense in the calling context.

Using vector like that also forces the container choice on the caller. Either way, the caller must copy the data elsewhere, but what if there are only a few hundred bytes to be read? Your interface requires a free store allocation. For larger lengths, unless your API first calls reserve(), the vector may reallocate a time or two.

Finally, note that your scheme requires allocating a buffer to use when calling a low level OS or runtime API, and then copying those bytes to the vector in order to transfer them to the caller. Why not have the caller provide the buffer in the first place and avoid that overhead?

> I acknowledge it might also be advantage to pass some limit as a second parameter, so only that number of elements gets filled in at the max. But in either case it does not make sense to me to prime the data with some mythical first element, or worry about what has been reserved.

A wrapper would hide these irksome implementation details.

> I don't design with C-style pointers, to some possible array of some possible size, of elements. I thought everyone had given up on that sort of unnecessary complication a long time ago when std::vector became the defacto standard in C++ for dynamic arrays.

Many of us care about performance.

> I am not against fixed size arrays if that is what some interface calls for, but if we are talking about dynamic arrays of elements then std::vector seems to me to be the way to do it.

Perhaps you're beginning to rethink your position a little.

___
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