[pdal] questions about iterator and buffer semantics

[Mateusz Loskot]

On 4 July 2013 02:21, Chris Foster <chris.foster at roames.com.au> wrote:
> On 4 July 2013 00:06, Howard Butler <hobu.inc at gmail.com> wrote:
>> On Jul 3, 2013, at 4:21 AM, Mateusz Loskot <mateusz at loskot.net> wrote:
>>> On 3 July 2013 04:15, Chris Foster <chris.foster at roames.com.au> wrote:
>>>> On 3 July 2013 00:55, Howard Butler <hobu.inc at gmail.com> wrote:
>>>
>>> The use of a pointer is idiomatic, indeed, but it is not equivalent to
>>> exceptions,
>>> same with boost::optional - it's just syntactic sugar for nullptr in this case.
>>> It is equivalent to the following:
>>
>> That is very much the intention -- sugar for nullptr. It is also a case of
>> Python infecting the C++. Looking through things now, it doesn't appear to
>> be even that good of sugar. I will try to create a branch that removes
>> getDimensionOptional...
>
> 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; }

Then, uesr can explicitly state which one she prefers:

try {
   getDimension();
} catch (...) {}

if (!getDimension(std::nothrow))
   ...

Extension of this technique is used by Boost.Asio, compare these two
overloadeds of resolve function:

http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/ip__basic_resolver/resolve/overload1.html
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/ip__basic_resolver/resolve/overload2.html

The Asio's way allow to be more details about reasons of failure.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net