I agree that if we could develop a version of optional that could be
typedefed to C++17 optional in the future that could be an interesting win.
I still hesitate to do this as the general use API though since it promotes
the idea of null strings still. My current leaning is to only provide
option 1
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
On Tue, Dec 19, 2017 at 1:52 PM Michael William Dodge
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 = ?
>
I am absolutely opposed to sentinel values just from the
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 = ?
Sarge
> On 19 Dec, 2017, at 13:34, Jacob Barrett wrote:
>
> Java String is an object and as such a member of type String ca
Java String is an object and as such a member of type String can be null or
allocated in the heap. In C++ std::string is a value and as such a member
of type std::string can never be null and is (usually) stack allocated with
the contents allocated (usually) on the heap. In C/C++ char* is a decayed
