Extended use of nullptr

[Daniel]

Consider a class which has a number of states, including a "null" state, e.g.

class A
{
public:
bool is_null() const;
// Returns true if the object is in a null state
};

I notice a number of C++ libraries with such a thing are using nullptr to
initialize a null state, e.g.


class A
{
public:
enum class states {null_s,other_s};

A()
{
state_ = states::other_s;
}

A(std::nullptr_t)
{
state_ = states::null_s;
}

bool is_null() const
{
return state_ == states::null_s;
}
private:
states state_;
};

Is this sensible? Saves defining a null_type empty class? Or is it
inappropriate semantics?

Thanks,
Daniel

[Mr Flibble]

std::optional.

/Flibble

[Daniel]

On Saturday, August 13, 2016 at 10:08:55 PM UTC-4, Mr Flibble wrote:
> >
> > Is this sensible? Saves defining a null_type empty class? Or is it
> > inappropriate semantics?
>
> std::optional.
>

Different context, the context here is where "null" is a valid state of an
object.

Daniel

[Mr Flibble]

std::optional.

/Flibble

[Daniel]

Just relax, we're just having a nice discussion about whether for a class
that has the notion of "null" as a valid state (imagine for example a class
that encapsulates a json value), whether for such a class it is appropriate
to borrow nullptr to initialize it to that state, as some C++ libraries do.

Best regards,
Daniel

[Alain Ketterlin]

You could also use a null pointer to A to represent the null state, but
that would require the systematic use of pointers instead of instances
of A, i.e., dynamic allocation, which is better avoided when possible.
Instead, what you show above burries the null state inside the class,
which is not a bad idea.

Anyway, your example is way too abstract, especially because of the
default constructor, which is very unlikely for a class holding
meaningful "state". It may also be the case that a special pattern of
values adequately represents the null state, in which case you do not
need anything else. If you really need a special constructor, you can
use whatever type lets it be different from the others, and in this case
I would not choose nullptr_t, but rather define a specific, class-local,
enum/struct/class, used only for that particular ctor.

But this was all before std::optional. You may not like it, but this is
exactly what std::optional is for. Here is an SO discussion of its use:

http://stackoverflow.com/questions/16860960/how-should-one-use-stdoptional

I can't see why one should avoid it, except maybe when the storage
requirements are large enough and null values frequent enough to make a
difference. But then std::optional of a pointer is still a good idea.

-- Alain.

[Mr Flibble]

On 14/08/2016 12:42, Stefan Ram wrote:
> Daniel <daniel...@gmail.com> writes:
>> Is this sensible?
>
> Without proper documentation (Doxygen), it's hard to say
> what the semantics are supposed to be and then compare this
> with the actual semantics.

>
>> Saves defining a null_type empty class?
>

> I can't even parse this string as English!

>
>> Or is it inappropriate semantics?
>

> This also is hard to read. Can code /be semantics/?
>
> Without documentation (Doxygen) it's little semantics.
>
>> Extended use of nullptr
>
> It uses some type »std::nullptr_t«, which is not the same as
> »nullptr«, and may not be the same as »::std::nullptr_t«.
> »nullptr« is not used as far as I can see.

The type of std::nullptr is std::nullptr_t so his function prototype was
correct.

/Flibble

[Daniel]

On Sunday, August 14, 2016 at 7:11:22 AM UTC-4, Alain Ketterlin wrote:
>
> You could also use a null pointer to A to represent the null state ...
> But this was all before std::optional ...

Not really applicable, the context here is that a null value is a valid state,
for example, think of a class that encapsulates a json value, where a
to_string method on an instance in that state has to print "null".

> If you really need a special constructor, you can
> use whatever type lets it be different from the others, and in this case
> I would not choose nullptr_t, but rather define a specific, class-local,
> enum/struct/class, used only for that particular ctor.

That's my view too, but there are other C++ libraries that do use nullptr_t in
this context, saving themselves from having to define an additional class,
and I was interested in the thoughts of this community.

Best regards,
Daniel

[Öö Tiib]

On Sunday, 14 August 2016 04:50:13 UTC+3, Daniel wrote:
> Consider a class which has a number of states, including a "null" state, e.g.

I do not know what is null state but I assume it is "such value does not
exist" state about like silent NaN of floating point numbers.

>
> class A
> {
> public:
> bool is_null() const;
> // Returns true if the object is in a null state
> };
>
> I notice a number of C++ libraries with such a thing are using nullptr to
> initialize a null state, e.g.
>
>
> class A
> {
> public:
> enum class states {null_s,other_s};
>
> A()
> {
> state_ = states::other_s;
> }
>
> A(std::nullptr_t)
> {
> state_ = states::null_s;
> }
>
> bool is_null() const
> {
> return state_ == states::null_s;
> }
> private:
> states state_;
> };
>
> Is this sensible? Saves defining a null_type empty class? Or is it
> inappropriate semantics?

I would likely use 'boost::none_t' and 'boost::none'. The 'none' is
anyway missing from standard library. Initialization of C++ is so
screwed up and sloppy IMHO that adding to it is likely bad idea.