Thread: New bool class... Question

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.

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.

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.

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.

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.

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:

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.

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

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.