geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Kimura <dkim...@pivotal.io>
Subject Re: Discussion: Native PDX Reader/Writer std::string
Date Wed, 20 Dec 2017 17:01:23 GMT
Given that C++17 is feature-complete, it seems prudent to adopt those
patterns as much as possible.

My fear with #4 is that we're introducing a special case API that users
become accustomed to and then unwilling to later switch to std::optional.
And then we'd end up supporting multiple ways to do the same thing.  And
even if we can delete the special case API after C++17, there's still API
churn for our users.  Because of that, I favor using optional even if we
have to roll our own.  And then after C++17 we change our implementation to
alias std::optional and there shouldn't be any code changes required from
user point of view.

Thanks,
David

On Tue, Dec 19, 2017 at 2:30 PM, Jacob Barrett <jbarrett@pivotal.io> wrote:

> On Tue, Dec 19, 2017 at 1:52 PM Michael William Dodge <mdodge@pivotal.io>
> wrote:
>
> > Of those, #1 seems better than #2 and #3. Is there an elegant way to use
> a
> > sentinel value of std::string to represent null, e.g., static const
> > PdxReader::NULL_STRING = <magic happens here>?
> >
>
> I am absolutely opposed to sentinel values just from the standpoint that
> once you pick a value someone will want that value.
>
> The C++17 solution to this problem is std::optional<std::string>, but
> unfortunately C++11 is our minimum. We could embrace boost::optional (for
> which C++17 std::optional derives), but this will cause clients to also
> depend on boost, which isn't ideal. We could roll our own optional...
>
> -Jake
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message