New bool class... Question

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.

Code:

---

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.

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.

Quote:

---

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

---

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

Quote:

---

'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:

Code:

---

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

---

Quote:

---

Originally Posted by laserlight

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:

Code:

---

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.

Quote:

---

Originally Posted by Raigne

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.

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

Code:

---

        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.

Code:

---

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

---

--
Mats

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

Code:

---

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;
};

---

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:

Code:

---

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

---

--
Mats

Quote:

---

Originally Posted by matsp

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

--
Mats

---

Oops, I didn't even see that. :p

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

*ba dum ching*

Quote:

---

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.

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

Code:

---

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.

Quote:

---

I really see no work to that.

---

Everything beyond if(Test) is a lot.

>> 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?

Quote:

---

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.

In that case I may have misunderstood some comments, and I apologize sincerely for that.

edit: On that note, why is dynamic memory ludicrous? Seems kind of like built-in support for helping prevent stack overflow. Although I may be mistaken.

edit2: I also don't really like standard types. I am weird I know. If all my code can have a class oriented feel to it then I can understand it much easier.

Quote:

---

Originally Posted by Raigne

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

Code:

---

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.

---

My appologies if I upset you in any way. It's just one of those words I've gotten into the habbit of using. I should work on that.

All it really shows is that you perhaps come from a .NET background where you typically new up all sorts of things willy-nilly without a care in the world because that's just often how it's done. Unfortunately in C++ "how it's done" is to only use dynamic memory allocation when you need to.

There's no need to stop asking questions, it's a good way to learn. However, posts in the spirit of "Look what I made!" will always attract criticisms of varying degree, that's just how it goes.

Actually I have never used .NET in my life. I have been playing with C++ since about 2004.

I seem to think if you use dynamic memory prior to having to you can prevent problems later on that may be more difficult to find. Clearly on any modern hardware massive dynamic memory allocation isn't really going to make a difference.

Like I said I have a tendency to try to make things complicated for no reason. Also, prior to this thread I had never heard of operator bool(). I was going based on things that I knew.

Quote:

---

Originally Posted by Raigne

edit: On that note, why is dynamic memory ludicrous? Seems kind of like built-in support for helping prevent stack overflow. Although I may be mistaken.

---

A bool can take up just 1 byte. However a pointer to one takes up 4 or 8 bytes depending on the target machine. Then there's the dynamically allocated bit of memory, which takes up a minimum of 8 bytes iirc on windows. So it's a matter of 1 byte (possibly padded to 4 bytes) vs at least 12 bytes, plus the overhead in the extra time taken to deal with dynamic memory allocation.

Quote:

---

edit2: I also don't really like standard types. I am weird I know. If all my code can have a class oriented feel to it then I can understand it much easier.

---

No that's actually quite understandable. Built-in types really are pretty bland. They lack things like automatic initialisation to zero etc. wrapping raw types in a class that provides things such as initialisation, is not necessarily such a bad idea.

Though with the dynamically allocated variable ( even with allocation overhead ) you will gain access time if you are say accessing thousands or so variables of this type per cycle or frame (whatever the case may be ). Am I correct in this thinking?

Quote:

---

Originally Posted by Raigne

I seem to think if you use dynamic memory prior to having to you can prevent problems later on that may be more difficult to find. Clearly on any modern hardware massive dynamic memory allocation isn't really going to make a difference.

---

Actually a lot of mistakes can be avoided by avoiding dynamic memory allocation. Dynamic memory allocation should always be thought of as a burden.
Also, compared to values on the stack that will always tend to be in the cache, small dynamically allocated memory chunks from random locations all over the place will tend to be quite a bit slower as they do not play well with the cache. Having a thousand or so of these, compared to bools, would really slow a program down.

Quote:

---

Originally Posted by Raigne

Though with the dynamically allocated variable ( even with allocation overhead ) you will gain access time if you are say accessing thousands or so variables of this type per cycle or frame (whatever the case may be ). Am I correct in this thinking?

---

No, you got it back to front. Whenever you use a pointer (dynamic allocation) the processor will first read the pointer, then get the value from the address the pointer gave - and for quick access that's bad.

If you just have a plain member variable, all the processor needs to do is get the "this" pointer for your class - whcih is unavoidable.

And I do realize the purpose of avoiding standard types - at the very, very least, I'd recommend any larger project to typedef common types, so that it's possible to redefine your types later. Wrapping them in a class is another step further, and depending on the usage of the type, it may be warranted.

However, your implementation went a little bit too far, as described. Don't take that the wrong way - I think every programmer who has ever started object oriented programming has made that mistake a few times - you define a class that has all the bells, whistles, drums and kitchen sink - then realize that it's a bit clumsy and cumbersome to work with and have to redesign. It's a good thing to have a forum to ask, becasue there's usually someone who has been there, done that.

Classes should be "as simple as possible, whilst still able to do the work".

--
Mats

So this is plenty to do what I want, and doesn't really change standard syntax except for the capital 'B' right?

Code:

---

class Bool
{
public:
    Bool(const bool& initval=false):ThisBool(initval)
    {};
    Bool(const Bool& copy)
    {
        this->ThisBool = copy.ThisBool;
    };

    const Bool& operator=(const Bool& copy)
    {
        this->ThisBool = copy.ThisBool;
        return *this;
    };

    //For generic C++ access to the bool
    operator bool()
    {
        return ThisBool;
    };

private:
    bool ThisBool;
};

---

EDIT: stupid question. Just wondering why it will let me do this...

Code:

---

    Bool t1;
    Bool t2;
    Bool t3;
    bool t4 = true;//standard bool
    t1 = t2 = t3 = t4;
    if (t1)
        std::cout << "YEA\n";

---

The compiler provided copy constructor and copy assignment operator will work fine. In fact, your copy assignment operator is not correct since it takes a Bool& instead of a const Bool&. With a tweak for const correctness with my original example, I think you should just use:

Code:

---

class Bool
{
public:
    Bool(bool value = false) : value(value) {}

    operator bool() const
    {
        return value;
    }
private:
    bool value;
};

---

EDIT:

Quote:

---

Just wondering why it will let me do this...

---

That's normal operator chaining of the copy assignment operator. Because of the constructor that takes a bool, t4 is convertible to Bool.

Oh ok. Thank you all for the assistance. I apologize for my misunderstanding.

There's no point in taking primitive types by const reference, by the way.

Quote:

---

Originally Posted by CornedBee

There's no point in taking primitive types by const reference, by the way.

---

Although, I think taking larger types like float & double by reference is more efficient though, isn't it?

Not necessarily, because every time you access it the compiler may have to follow the reference to the actual data, which might cost more than the copy.

float is 32 bits on x86 or amd64. Hardly large. double is 64 bits, that's not large either - especially not on amd64.
In fact, the way the amd64 convention works, passing floats by value is considerably more efficient, because they're passed in registers. If you pass them by reference, then the pointer is passed in a register, but the float/double must be on the stack.

OK, I guess that makes sense. I always pass them by value anyways, just to be consistent with other primative types.
So how large would a type have to be before it would be more efficient to pass it by reference/pointer vs by value? I'll probably still pass all non-primatives by reference anyways, but it would be interesting to know...

Depends on the hardware. Depends on the access pattern inside the function. (For example, if all the function does it pass the thing on to other functions, this favors references.) Depends on the code the compiler generates. (Under heavy register pressure, the compiler might not be able to hold even an often-accessed part of the structure in a register, thus requiring more loads, which take longer for pass-by-ref.) But if I were to guess (but please note, this is really a pure guess), I'd say at about 4 times the machine word size passing a reference becomes more efficient. Of course, that depends also on the complexity of the copy constructor. Your average std::vector is 3 pointers large, but pass-by-ref is definitely more efficient.