Overload the..bool operator..?

This is a discussion on Overload the..bool operator..? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by phantomotap I intended to imply "disallow an additional conversion possibility separate from other implicit conversions in a ...

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,264
    Quote Originally Posted by phantomotap
    I intended to imply "disallow an additional conversion possibility separate from other implicit conversions in a given context". (Consider what happens when the explicit form from one type gets cozy with a non-explicit conversion from the other.)
    I think that you should just change "additional" to "implicit". There is nothing "additional" about the conversion that you are talking about.

    Quote Originally Posted by phantomotap
    The point is, for this exact use case, users will still have to deal with implicit conversion operators because they, the explicit conversion operators, don't really solve many problems. They just make the problems appear to vanish because they require the programmer to tell the compiler exactly what to do. If I don't mind doing 'if(bool(some_instance))' the explicit operators are fine, but if I need 'if(some_instance)' I still have to do the work because I can't use the explicit operators. (I chose this example because it was what the OP asked. This is really one of the least useful and least obtrusive cases.)
    Actually, no, the if(some_instance) syntax would work with an explicit conversion function to bool. CornedBee just changed the Wikipedia C++0x article to clarify that point, and it appears that I did not read carefully enough into the proposed wording in N2437.
    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

  2. #17
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,405
    There is nothing "additional" about the conversion that you are talking about.
    O_o

    What? If you have two possibilities and add another... that's an additional possibility.

    Actually, no, the if(some_instance) syntax [...] wording in N2437.
    Or you are over-reading. It is as simple as that. Still, the wording has changed drastically between revisions and I get how one might interpret the current wording as allowing for this special case of 'operator bool' ignoring 'explicit' in certain contexts. (Though I interpret this revision as intentionally disallowing this special case while prevent implicit conversions to unrelated types in certain contexts.) This doesn't change much; the explicit conversion operators still only helps to solve one real problem--a naming issue. (The special case for 'bool', if it exists, actually does solve a few problems.)

    As for CornedBee and Wikipedia... unless CornedBee is one of the authors or has directly spoken to one of them he is no more able of knowing the intent than you or I. That said, if he is one: further alter the wording to disassociate the "boolean conversion" from a normal "implicit conversion".

    Soma

  3. #18
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,264
    Quote Originally Posted by phantomotap
    What? If you have two possibilities and add another... that's an additional possibility.
    That's true. Now, stop being so vague and detail what exactly are these "two possibilities" and "another". I suspect we are in general agreement but disagreeing because we see the same thing differently.

    Quote Originally Posted by phantomotap
    Though I interpret this revision as intentionally disallowing this special case while prevent implicit conversions to unrelated types in certain contexts.
    Yes, I think that your interpretation is viable, especially since the proposed amendment to section 12.3.2 did not include any such example even though the existing text demonstrates an implicit conversion with if (a). Initially, I was convinced that this was an example of precisely the kind of special case permitted, but overlooked the fact that the existing text has a class named X whose conversion function is (obviously) non-explicit and converts to an int.

    Quote Originally Posted by phantomotap
    As for CornedBee and Wikipedia... unless CornedBee is one of the authors or has directly spoken to one of them he is no more able of knowing the intent than you or I.
    Indeed, hence I notified you of the change in the Wikipedia text for you to read CornedBee's opinion and dispute it if you wish to.
    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

  4. #19
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,405
    That's true. Now, stop being [...] same thing differently.
    Funny. I think we are in complete agreement. I'm just adding a little more than what you are saying. See the source below for a simple and maybe surprising characteristic of marking a particularly problematic conversion explicit. (For full effect remove the explicit keyword and try again. Most programmers are still surprised by it. This is just the most obvious example.) What we both say: marking a single conversion explicit means that it isn't an option in implied circumstances. (I'm ignoring the possibility of a special 'bool' case.) I'm just saying that, like constructors, the compiler may find a way to make the implied conversion through other means even if the relevant source or target is marked as being an explicit conversion. (This was actually the intended consequence even if it does cause problems.) Or, in other words, marking a certain conversion with explicit prevents it from causing problems related to overload resolution in the face of... secondary--^_^--unrelated conversions.

    Yes, I think that your [...] conversion with if (a).
    I hope my interpretation is correct. It lays the groundwork for a stronger type system in the future.

    Initially, I was convinced [...] and converts to an int.
    This is what I was talking about in "Anyway, they, the [...] those same examples.".

    Indeed, hence I notified [...] you wish to.
    When you alerted me to the current wording allowing for the possibility of the intended special 'bool' behavior I reread CornedBee's comments. I've just assumed he was under the same impression as you. In the context of such special behavior his comments make a lot more sense.

    Soma

    Code:
    #include <iostream>
    
    struct test
    {
      explicit test(int)
      {
        std::cout << "EXPLICIT!\n";
      }
      test(double)
      {
        std::cout << "IMPLIED!\n";
      }
    };
    
    void tester(const test&)
    {
      std::cout << "TEST!\n";
    }
    
    int main()
    {
      tester(1);
    }

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. passing params between managed c++ and unmanaged c++
    By cechen in forum C++ Programming
    Replies: 11
    Last Post: 02-03-2009, 08:46 AM
  2. Drawing Program
    By Max_Payne in forum C++ Programming
    Replies: 21
    Last Post: 12-21-2007, 05:34 PM
  3. Smart pointer class
    By Elysia in forum C++ Programming
    Replies: 63
    Last Post: 11-03-2007, 08:05 AM
  4. operator overloading and dynamic memory program
    By jlmac2001 in forum C++ Programming
    Replies: 3
    Last Post: 04-07-2003, 12:51 AM
  5. Need Help With an RPG Style Game
    By JayDog in forum Game Programming
    Replies: 6
    Last Post: 03-30-2003, 08:43 PM

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