Rob Stewart wrote:
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
>From: boost-bounces@lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando >Cacciola
The library can just as easily expect a Boost.Optional.
But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life.
If you can change the library to use an adaptor for an optional, why can't you change the library to use the optional directly?
But I never gave any indication that we can change the library at all! Not even to use the adapter. The adapter is a function object that returns exactly what the library function expects.
Huh? Your first example showed code using Boost.Optional and the conditional operator. Then you changed it to use an adapter.
What unchangeable library code can use an adapter that couldn't have used Boost.Optional in the first place? That is, the library code would have been written to take a value initially. To account for the optional/default behavior, the library must change to take an adapter or a boost::optional.
Since your adapter doesn't have value semantics, but rather function call semantics, a library written to expect a value cannot work *without change* with an adapter.
What have I missed?
The unchangeable library code is tr object and its loadPoint() method in particular. Adapter is outside the library, not inside it. The example doesn't contain library code at all. The code that cannot be changed is loadPoint() method itself. The example is just a glue between 2 libraries - boost::optional and tr. Andrey