Thread: Overload the..bool operator..?

I want to use a class like this:

Code:

Item item;

if(item)
{
....
}

Instead of this:

Code:

Item item;

if(item.IsValid())
{
...
}

Is there a way to do this? Maybe overload an operator?

Thank you.

Read about the safe bool idiom.

O_o

^_^

Thank goodness for explicit conversion operators in C++0x.

It only disallows an additional conversion in a given context. It will help, and no doubt, but it doesn't solve all the problems.

Soma

Originally Posted by brewbuck

If the Item was "invalid" in the first place, why was it allowed to be constructed? Maybe you should throw an exception when the item would be constructed in an invalid state, so that users don't have to perpetually wonder whether the objects they possess are valid or junk.

Well it's part of their inventory:

Code:

class Player:
  public Character
{
private:
...
Item items[9];
...
};

Item is a very basic class which pretty much looks like this:

Code:

class Item
{
private:
    const ItemClass* itemClass;
    int level;

public:
    Item(const ItemClass* itemClass, int level) {
        this->itemClass = itemClass;
        this->level = level;
    }
....
}

Where ItemClass* contains the behaviour and appearance loaded from an XML file. The player might not have any item in that position at all.

I suppose i could of done it like this and check if item is NULL:

Code:

class Player:
  public Character
{
private:
...
Item* items[9];
...
};

...but then again i could do it the way i have it now.

If i use a vector or list it's going to screw up the item placement. I want them to be able to choose which position to put the item. They can place the item in the 8th position even if they only have one item, so it needs to support gaps in between items.

Yeah i was just thinking about using a map.

It was designed primarily [...] needs to be revised.

Uh... conversion operators already existed. The addition of explicit conversion operators can't have been offered to provide for this use case since you could already do that.

Anyway, I seriously don't quite get what you are suggesting or asking. The explicit conversion operators naturally disallows this use case and any others similar to it.

If it doesn't solve all the technical problems, please tell me which it doesn't solve.

The ideal implicit conversion: conversion in the face of source strongly implying that the conversion should take place while disallowing conversions in the ambiguous or dangerous case. The addition and use of explicit conversion operators effectively denies that possibility entirely. (Of course, that was the intended purpose, and as far as it goes, it works.) They do so precisely because they require explicit source.

Seriously, the addition of the explicit conversion operators effectively renames the normally offered "best practice" of 'bool some_type::is_valid()' in use from 'some_type_instance.is_valid()' to 'static_cast<bool>(some_type_instance)' or 'bool(some_type_instance)'. Now, granted, this isn't the only application, and it does solve, after a fashion, the problem of what to name a given conversion function. In this the implicit conversion operators are beautiful and a nice blessing, but only if you can actually get old hats and newbies to use them as intended.

But can you overload the given explicit conversion operator for your ranged integer class and rely on the existing, natural operators to work while still prevent the bothersome implied conversion in other constructs? No.

Does it solve the problem that things like x < y might compile because of operator bool?

Absolutely. (Not that you couldn't already do that, but this certainly makes it simpler which is always nice.)

Or that you might accidentally pass the object to a function that accepts it because it expects bool?

Absolutely.

On the other hand, the [...] the N2437 working paper differently.

O_o

I intended to imply "disallow an additional conversion possibility separate from other implicit conversions in a given context". (Consider what happens when the explicit form from one type gets cozy with a non-explicit conversion from the other.) I'm not sure what you inferred but I think it was the wrong thing. *shrug*

Anyway, they, the examples, look absolutely transparent to me as well; nearly there is also the "inheritance" from the current standard of the given definition for 'class X' in those same examples.

The point is, for this exact use case, users will still have to deal with implicit conversion operators because they, the explicit conversion operators, don't really solve many problems. They just make the problems appear to vanish because they require the programmer to tell the compiler exactly what to do. If I don't mind doing 'if(bool(some_instance))' the explicit operators are fine, but if I need 'if(some_instance)' I still have to do the work because I can't use the explicit operators. (I chose this example because it was what the OP asked. This is really one of the least useful and least obtrusive cases.)

I actually don't mind 'static_cast<bool>(instance)'. No, that's not quite all of it; I prefer 'static_cast<bool>(instance)'. I like unambiguous statements. I also like the constructor form of assignment. (I use 'type name(arg);' instead of 'type name = arg;'.) The thing is... most programmers will not have it. We can't even get Elysia to use the C++ casts!

Soma