New bool class... Question

[Raigne]

Does this look like it will serve its purpose well. I just hate that the C++ bool can't be used in containers so I decided to write my own that is more C++ish, and that is safe for containers. Tell me if i am missing anything.

I realize most of you will think this is pointless if not all of you, but I don't #define for stuff like this, and I think this will work better for my purposes.

class Bool
{
public:
	//Default constructor
	Bool(unsigned char initVal=0)
	{
		if ( initVal == Bool::TRUE )
			ThisBool = new unsigned char(0);
		if ( initVal >= Bool::FALSE || initVal == Bool::FALSE)
			ThisBool = new unsigned char(1);
	};

	//Copy constructor
	Bool(const Bool& copy)
	{
		if ( copy.ThisBool )
		{
			this->ThisBool = new unsigned char(*copy.ThisBool);
			delete copy.ThisBool;
		}
		else
		{
			this->ThisBool = new unsigned char(Bool::TRUE);
		}
	};

	//default destructor
	~Bool ()
	{
		delete ThisBool;
	};

	//Enumeration for Bool values
	enum TYPE
	{
		TRUE = 0,
		FALSE = 1
	};

	//Duh?
	const bool True()
	{
		if ( *ThisBool == Bool::TRUE )
			return true;
		else
			return false;
	};

	//Duh?
	const bool False()
	{
		if ( *ThisBool == Bool::FALSE )
			return true;
		else
			return false;
	};

	//Get the value of the Bool without changing it
	const unsigned char& Get()
	{
		return *ThisBool;
	};

	//Get the value of the Bool without changing it
	const unsigned char& operator*()
	{
		return *ThisBool;
	};

	//Toggle the value of the Bool
	const unsigned char& Toggle()
	{
		if ( *ThisBool == Bool::TRUE )
		{
			*ThisBool = Bool::FALSE;
			return *ThisBool;
		}
		else
		{
			*ThisBool = Bool::TRUE;
			return *ThisBool;
		}
	};

	//Set the value of the Bool
	const unsigned char& Set(TYPE new_val)
	{
		*ThisBool = new_val;
		return *ThisBool;
	};
private:
	unsigned char* ThisBool;
};

EDIT: Added operator*() function. Little easier to type, little harder to read(understand). Oh well.

[iMalc]

Using dynamic memory allcation for this is downright ludicrous! It's not like you're ever shallow copying here.
If you simply want to avoid the vector<bool> specialisation, then wrapping a bool in a class where you only add a couple of operators, should be more than enough.
'bool' can be used in containers anyway, it's only the vector that does funky stuff with it that stops a couple of things from working.

The best thing you can do with the posted code is delete it.

[laserlight]

It's not like you're ever shallow copying here.

Or rather, it's not like you're ever deep copying here.

'bool' can be used in containers anyway, it's only the vector that does funky stuff with it that stops a couple of things from working.

I agree. It depends on what exactly you want, but something like this could suffice:

class Bool
{
public:
    Bool(bool value = false) : value(value) {}
    operator bool() { return value; }
private:
    bool value;
};

[iMalc]

Or rather, it's not like you're ever deep copying here.


I agree. It depends on what exactly you want, but something like this could suffice:

class Bool
{
public:
    Bool(bool value = false) : value(value) {}
    operator bool() { return value; }
private:
    bool value;
};

Oh yeah, heck it's neither shallow copying, nor deep copying. It's worse than I thought! The copy-constructor destroys the item being copied from, such that the destructor of the item being passed in will then throw, causing a fatal crash.

What you just posted is exactly what I had in mind.

[cpjust]

I just hate that the C++ bool can't be used in containers

Says who? The vector<bool> mistake is the only issue I know of with bools, but even that isn't really that bad. I haven't even had a need for a vector<bool> yet, so I doubt it's worth the time & effort to create a fix for it.

[matsp]

And if you must make your own class, at least when you perform construction like this:

	Bool(unsigned char initVal=0)
	{
		if ( initVal == Bool::TRUE )
			ThisBool = new unsigned char(1);
                else if ( initVal == Bool::FALSE)
			ThisBool = new unsigned char(0);
                else 
                         std::cerr << "Invalid truth value << " (int) initval << std::endl;
	};

Don't turn truth values upside down: standard is that TRUE is anything but zero, and FALSE is zero exactly.

	enum TYPE
	{
		TRUE = 0,
		FALSE = 1
	};

--
Mats

[cpjust]

If you really need a Bool class, wouldn't something like this be a lot better and simpler:

class Bool
{
public:
	Bool() : m_Bool( bool() ) {}

	Bool( bool  bVal ) : m_Bool( bVal ) {}

	operator bool() const
	{
		return m_Bool;
	}

	Bool& operator=( const Bool&  rhs )
	{
		m_Bool = rhs.m_Bool;
		return *this;
	}

private:
	bool	m_Bool;
};

[matsp]

Yes, and as laserlights post shows, you don't even need an assignment operator.

However, if you want to make sure that it actually returns a bool:

	operator bool() const
	{
		return !!m_Bool;
	}

--
Mats

[cpjust]

Yes, and as laserlights post shows, you don't even need an assignment operator.

--
Mats

Oops, I didn't even see that.

[indigo0086]

Takes a lot of work to get a truth statement from Raigne's class. Reminds me of my last relationship...

*ba dum ching*

[laserlight]

However, if you want to make sure that it actually returns a bool:

That seems unnecessary, since operator bool(), by definition, returns a bool. That said, I did neglect to make operator bool() const in my example, so that fix should be incorporated.

[Raigne]

How does it take a lot to get a truth statement from my class?

Bool Test(Bool::TRUE);
if ( Test.True() )

I really see no work to that.
Maybe I just like over complicating things. If that is the case I will just have to stop asking you guys for help. Since my ways are always "ludicrous". Have fun, and ty.

[CornedBee]

I really see no work to that.

Everything beyond if(Test) is a lot.

[Daved]

>> Since my ways are always "ludicrous".
You realize that only one person referred to anything as ludicrous, and that was just the use of dynamic memory allocation.

Your class was a nice attempt but there are many issues with it that have been pointed out. Is that not what you wanted?

[laserlight]

Maybe I just like over complicating things. If that is the case I will just have to stop asking you guys for help. Since my ways are always "ludicrous". Have fun, and ty.

Well, you wanted us to tell you if you were missing anything. We told you that you missed a more straightforward implementation, and that you missed a copying bug in your current implementation.