[pdal] questions about iterator and buffer semantics

[Mateusz Loskot]

On 4 July 2013 09:44, Mateusz Loskot <mateusz at loskot.net> wrote:
> 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.

I forgot to mention, PDAL could utilise
std::error_code/std::error_category machinery too.

The std::error_code and friends come from <sytem_error> or <boost/system/*>
IMHO, the name may seem misleading, as it's not exclusively for sytem errors,
but errors from other levels too:

"The class error_code describes an object used to hold error code
values, such as those originating from the
operating system or other low-level application program interfaces"

Here is good not-too-long example of custom error codes:
https://github.com/spesmilo/libbitcoin/blob/master/include/bitcoin/error.hpp
https://github.com/spesmilo/libbitcoin/blob/master/src/error.cpp

Here is good overview of those utilities in 5 parties article:
http://blog.think-async.com/2010/04/system-error-support-in-c0x-part-1.html

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