

C++11 user-defined literals and some constructions - perone
http://pyevolve.sourceforge.net/wordpress/?p=2104

======
Game_Ender
As a programmer who has seen bad C++ code this just seems scary, an already
complicated language gaining more complexity. Although I am sure it can be
used to come up with some cool syntax for various different kinds of
operations, hopefully it's not too opaque in the end.

------
albertzeyer
Some interesting examples / possible use cases / discussion about user-defined
literals in C++11: [http://stackoverflow.com/questions/237804/user-defined-
liter...](http://stackoverflow.com/questions/237804/user-defined-literals-
in-c11-a-much-needed-addition-or-making-c-even-more-b)

------
prophetjohn
This seems to be much in the same vein as operator overloading. As long as the
programmer defines these with intuitive names, I think they'll serve to make
C++ a more expressive and readable language.

------
geoffhill
I think the primary disadvantage of an addition like this is the extra
complexity is shifted almost completely into parsing. This means that
accidental suffixes on the end of literals always have to be treated as custom
literals by the parser, until they can be confirmed as invalid by a much later
stage in the compiler.

In essence, an enormous class of syntactically invalid code is now
syntactically valid and now just semantically invalid. A much harder bug to
classify.

------
makecheck
Like many language features, it can and will be abused; and like overloaded
operators it may be very difficult to determine where a custom suffix is even
defined.

It will definitely be nice in a few places. For instance I can imagine that
writing 01011011_b (after defining "_b") would be very handy.

I think examples that attach units instead of just metric prefixes are missing
the point because the result is always a _number_ (or a string), not a
particular kind of object. If you say "assert(1_kg == 2.2_lb)" that is
_completely_ misguided because you haven't specified the context; again, these
are _just numbers_ so what do you end up with, kilograms or pounds or
something else? Far better to name suffixes only in terms of scaling factors,
e.g. "_kilo" or "_K" defined as 1000x would be applicable in more situations.

~~~
SamReidHughes
Adding units is quite reasonable, but of course the 1_kg == 2.2_lb assertion
can fail simply because if you multiply 2.2 by 1 / 2.2, you're not gonna get
1.

And when adding units you certainly should _not_ get numbers. 1_kg should not
be a double. It should be a unit<double, mass> or something. And 1_kg * 1_kg
should be a unit<double, mul<mass, mass>>? Presumably it's possible to make
something like that work in the C++ type system.

You have to be careful about 01011011_b. I'd guess that gets parsed as an
octal constant. But if you write 11011010_b, that'll get parsed as a decimal
constant.

~~~
makecheck
I didn't have that right, it seems the result certainly can be a class. And
that would avoid the units problem. Though in the examples I've seen it wasn't
clear if they were returning a class.

With raw numerical values the results are definitely unpredictable. For
example maybe the program considers numerical values to be measured in ounces,
in which case "2.2_lb" becomes the _number_ "35.2"; or maybe it thinks
everything is metric, measured in grams. There is not just one reasonable way
to pick a number to represent an expression.

I am fairly sure that a leading zero cannot be a problem with custom literals;
I'd expect the compiler to parse the whole thing and see the suffix before
deciding what type of literal it is (i.e. the "_b" handler would get to read
everything raw, including the leading zero).

