[pdal] questions about iterator and buffer semantics

[Chris Foster]

On 4 July 2013 18:44, Mateusz Loskot <mateusz at loskot.net> wrote:
>> We do need some version getDimensionXXX() which signifies the absence of the
>> dimension in some other way than throwing.  Whether that's by returning
>> boost::optional, or by returning a pointer doesn't matter too much in the
>> grand scheme of things, I'm just picky when it comes to API design ;-)
>
> The getDimension could be simply overloaded:
>
> #include <new>
> #if (__cplusplus >= 201103L)
>     #define PDAL_NO_THROW nothrow
> #else
>     #define PDAL_NO_THROW throw()
> #endif
>
> void getDimension() { throw ""; }
> bool getDimension(std::nothrow_t const&) PDAL_NO_THROW { return false; }

Careful - the second getDimension can still throw (it is currently necessary
to call operator new behind the scenes for the dimension inheritance stuff).

Here's what I'm imagining:

The usual getDimension returns the dimension as a reference; naturally it
throws if the dimension isn't found.  In fact, this is just exactly the
existing getDimension which I think is absolutely fine.

The other getDimension just returns a pointer and you need to check whether
it's null.  I actually think getDimensionOptional() was a reasonable name for
this [or perhaps getOptionalDimension()?] but perhaps there's something
better.

The API is almost there already, I don't see a need for a big change here.

> Then, uesr can explicitly state which one she prefers:
>
> try {
>    getDimension();
> } catch (...) {}
>
> if (!getDimension(std::nothrow))
>    ...

IMO this is cute, but too cute ;-)  These functions have different return
types (different semantics on failure to find the dimension!), so it's
entirely appropriate to have different names.

I think this is a case where it's best to keep things simple, because the
simplest thing will work fine and be easy to understand when you come back to
read the code.  I've designed some really fancy APIs in the past, bristling
with neat user defined types and clever overloads... looking back on them they
are not APIs I would now like to use!

~Chris