New bool class... Question

This is a discussion on New bool class... Question within the C++ Programming forums, part of the General Programming Boards category; In that case I may have misunderstood some comments, and I apologize sincerely for that. edit: On that note, why ...

  1. #16
    Registered User
    Join Date
    Nov 2005
    Posts
    673
    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.
    Last edited by Raigne; 04-04-2008 at 01:31 PM.

  2. #17
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,269
    Quote Originally Posted by Raigne View Post
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  3. #18
    Registered User
    Join Date
    Nov 2005
    Posts
    673
    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.
    Last edited by Raigne; 04-04-2008 at 01:42 PM. Reason: typo

  4. #19
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,269
    Quote Originally Posted by Raigne View Post
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  5. #20
    Registered User
    Join Date
    Nov 2005
    Posts
    673
    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?

  6. #21
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,269
    Quote Originally Posted by Raigne View Post
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  7. #22
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Raigne View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #23
    Registered User
    Join Date
    Nov 2005
    Posts
    673
    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";
    Last edited by Raigne; 04-04-2008 at 02:04 PM.

  9. #24
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,981
    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.
    Last edited by laserlight; 04-04-2008 at 02:19 PM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #25
    Registered User
    Join Date
    Nov 2005
    Posts
    673
    Oh ok. Thank you all for the assistance. I apologize for my misunderstanding.

  11. #26
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    There's no point in taking primitive types by const reference, by the way.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #27
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by CornedBee View Post
    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?

  13. #28
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    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.

  14. #29
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #30
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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...

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Newbie class question
    By vastgoten in forum C++ Programming
    Replies: 4
    Last Post: 07-31-2008, 01:43 AM
  2. C++ to C Conversion
    By dicon in forum C Programming
    Replies: 7
    Last Post: 06-11-2007, 08:38 PM
  3. Conversion From C++ To C
    By dicon in forum C++ Programming
    Replies: 2
    Last Post: 06-10-2007, 02:54 PM
  4. Headers that use each other
    By nickname_changed in forum C++ Programming
    Replies: 7
    Last Post: 10-03-2003, 04:25 AM
  5. Simple Short Class Question
    By Travis Dane in forum C++ Programming
    Replies: 2
    Last Post: 12-24-2002, 06:12 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21