Hello,

This is a proposal for changing the behaviour of C++ in the field of selection of
user defined conversion functions.


1) Background:

In the standard section "13.3.3 Best Viable Function" contains the selection of
user defined conversion function. However due to the sorting of the 4 given rules
for selection of the best viable function, C++ shows a highly counter intuitive
behaviour. Example:

struct foo {
   double f;
   operator float() const { return float(f); }
   operator int() { return int(f);}
};

void f(float) { }
void f(int) {  }

main()
{
   foo bar={2.5};
   f(float(bar)); // uses `operator int()' !
}


In this example, C++ chooses operator int(), since for the first parameter (i.e.
the implicit 'this' parameter) the conversion sequence foo (identity) is better
than the conversion sequence foo->const foo. So although there is an explicit
cast to float and there is a user defined conversion operator, that yields float,
`operator int()' is used instead followed by a builtin conversion from int to
float. This is highly counter intuitive.



2) Relevance

The main impact of this behaviour is on conversion functions that return pointer
on internal reference counted objects. Example:

class String {

   struct shared {
      int refcnt;
      char *str;
   };

   shared *s;
public:

   operator char *() {
         if(s->refcnt>1) make_unique();
         return s->str;
      }
   operator const char *() const {
         return s->str;
      }
};

In this case the conversion to `char *' is much more expensive, since it has to
assure, that there is only a single reference to the internal object, than
the conversion to `const char *'.
The current C++ standard however chooses `operator char *' over `operator const char *'
for converting String -> const char *.


3) Proposed Modification

Making the 4th rule of 13.3.2 the first rule, would correct this non intuitive behaviour
of C++. Since this rule only affects the selection of user defined conversion functions,
the selection of other functions would not be affected by that change.



4) Example Implementation of a compiler

You can find a patch against egcs-20000320 at:

http://www.student.informatik.tu-darmstadt.de/~meixner/egcspatch

And there is also an additional example showing the differences:

http://www.student.informatik.tu-darmstadt.de/~meixner/example.cxx



5) Affected code

Only code should be affected that relies on this strange selection of user defined
conversion functions, which should be very rare. And in some cases you probably
could see some speedup as you would in the above String example.



6) Comments

This part is up to you. What do you think about that change? Do you know of any
code, that would be broken by that modification?


- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701









---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]