Conversion to bool screwing up my + overloading

This is a discussion on Conversion to bool screwing up my + overloading within the C++ Programming forums, part of the General Programming Boards category; I know what rvalues and lvalues are, to a degree. Still, it is difficult since they've long surpassed their original ...

  1. #31
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    I know what rvalues and lvalues are, to a degree. Still, it is difficult since they've long surpassed their original definitions and there are rules here and there that defines the terms now.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #32
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,667
    I never really had difficulty with the difference, personally:

    Lvalues are location values.

    Rvalues are everything else, including lvalues being used for the data they contain in an expression. Primitive data are always rvalues.

    The only hang up is maybe functions which return references (because function calls are normally rvalues). To me, it makes sense when I consider how operator chaining is supposed to work.

    Well, wait... I thought of another one. The fact that array names are rvalues confuses people who are not aware of the difference between pointers and arrays but I do not believe you are one of them.

  3. #33
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Sebastiani View Post
    >> There's also the void* operator.

    Hey, that looks like a better solution altogether, actually.

    I'm wondering if it provides all the safety of the standard "safe bool idiom" while being quite efficient as well?
    No, because it still allows meaningless comparisons between objects that have operator void*():

    Code:
    class MyClass
    {
    public:
        operator void *();
    };
    
    MyClass a;
    std::ofstream b;
    a == b; // valid?!
    All these tricks IMHO are trying to be overly clever. Again, I don't see what's wrong with an explicit IsNull(). If the concern is interoperability with generic algorithms, well, those algorithms should not have been designed to require conversion in a boolean context in the first place. You can always raise to another level:

    Code:
    template < typename T >
    bool IsNull( const enable_if< SupportsIsNull< T >, T >::type &x )
    {
        return x.IsNull();
    }
    
    template < typename T >
    bool IsNull( const enable_if< SupportsBooleanConversion< T >, T >::type &x )
    {
        return x;
    }
    
    // etc...
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #34
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Again, I don't see what's wrong with an explicit IsNull().
    You can't do this:
    Code:
    if(boost::optional<stuff> o = func_that_returns_optional()) {
      // o is only visible here, where it's not empty
    }
    If you only have an isNull, you have to do it like this:
    Code:
    boost::optional<stuff> o = func_that_returns_optional();
    if(!o.isNull()) {
      // o is not empty here
    }
    // but it's visible and indefinite here
    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

  5. #35
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by CornedBee View Post
    You can't do this:
    Code:
    if(boost::optional<stuff> o = func_that_returns_optional()) {
      // o is only visible here, where it's not empty
    }
    If you only have an isNull, you have to do it like this:
    Code:
    boost::optional<stuff> o = func_that_returns_optional();
    if(!o.isNull()) {
      // o is not empty here
    }
    // but it's visible and indefinite here
    What about:

    Code:
    {
      boost::optional<stuff> o = func_that_returns_optional();
      if(!o.isNull()) {
        // o is not empty here
      }
    }
    The convenience of that syntax isn't particularly compelling to me.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #36
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    *shrug* Suit yourself. It is to me. I find blocks for the sake of scope to be one of the ugliest thing in the language.
    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

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

Similar Threads

  1. Code review
    By Elysia in forum C++ Programming
    Replies: 71
    Last Post: 05-13-2008, 09:42 PM
  2. Smart pointer class
    By Elysia in forum C++ Programming
    Replies: 63
    Last Post: 11-03-2007, 07:05 AM
  3. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  4. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 06:39 AM
  5. Headers that use each other
    By nickname_changed in forum C++ Programming
    Replies: 7
    Last Post: 10-03-2003, 04:25 AM

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