

C++14 - AndreyKarpov
http://root.cern.ch/drupal/content/c14

======
kibwen
_"digit separators to make for instance binary literals readable
0b1_0010_0010_0000_1000"_

Nice. I first saw this in Rust, and it seemed like such an obviously good idea
(allowing underscores in numeric literals) that I've wondered why more
languages don't do it. Now I'm curious where it originated.

~~~
rootbear
I am a big fan of adding digit separators where ever possible. I'm tired of
staring at ls listings of terabyte filesystems and trying to figure out what
order of magnitude the numbers are. And yes, I know about ls -lh.

I would like to see a universal format agreed on by everyone, so that numbers
with separators (call them punctuated numbers) output by one program could be
used as input for another, as is often done in Unix pipelines.

The languages that I know of that have punctuated numbers all use underscores.
However, having thought about it a lot, I don't think this is a good choice.
First, the underscore is often used, as in C, as an additional character in
identifiers, but the semantics are different. An underscore in an identifier
is significant, in a number it is not:

1_234_567 == 1234567, but

my_long_identifier != mylongidentifier

Also, the underscore is too "big". In a fixed width font, this is irrelevant,
but in a variable width font, I think it makes numbers look ugly. The
separator should be narrow. In some locales, the apostrophe is used:

1'234'567

I like the thinner character. I have at least one calculator that uses this
convention in the display. Alas, this is probably unworkable in computers,
since the apostrophe is used commonly for quoting. One option that might work
is the back quote:

1`234`567

The back quote isn't used as much as the apostrophe, but it still might cause
problems. On US keyboards, it's conveniently located right next to the 1.

Finally, I'd like to see both period and comma accepted as the decimal
separator

1`234`567.89 == 1`234`567,89

but there are some obvious problems with that.

My bottom line is that, before C++, or any other language, adds underscores as
thousands separators because that's what everyone else did, we should think
more deeply about what's needed in a universal format for punctuated numbers.

~~~
Symmetry
Far better to use a character that's supposed to be part of an identifier like
_ than a character that could have some other syntactical use in various
languages. The fact that a number begins with a numeric character lets you
distinguish it from other identifiers.

------
fafner
GCC 4.8 already adds support for return type deduction in normal functions.

> G++ now supports a -std=c++1y option for experimentation with features
> proposed for the next revision of the standard, expected around 2017.
> Currently the only difference from -std=c++11 is support for return type
> deduction in normal functions, as proposed in N3386.

<http://gcc.gnu.org/gcc-4.8/changes.html>

------
rvkennedy
" _There is now (thanks to CERN's presence :-) a working group on reflection
in C++._ "

A few years ago I built an entire framework for automatic reflection in C++ -
it worked by querying the export table of the executable or library.
Eventually I lost interest and let the project slide, but I think this
approach would be a good one to build on.

------
mseepgood
How much can be added to a programming language until it collapses?

------
pascal_cuoq
I wonder whether the hexadecimal floating-point syntax 0x1.23p45 referred to
in <http://stackoverflow.com/a/11840637/139746> will qualify as “bug fixes and
usability improvements”. This notation is very useful for the tiny fraction of
programmers who need it.

------
idank
One can only guess how the programming languages area will look like in 5
years, but C++ will get "runtime sized arrays" and "generic lambdas" in 2017
(add a year or two until it gets to mainstream compilers)? Makes you think
that the criticism the language gets is a little justified.

~~~
flebron
There is no real need for runtime sized arrays, as one could already use
vectors (which are more comfortable to use than C-style arrays anyway) and
allocate them on the stack (that's one of the template parameters of
std::vector, its allocator). If one were to be a masochist, one could also
alloca and then use placement new, with all the shortcomings of alloca.

Granted, it's syntactically shorter to say int x[n], but it's the same
behavior as above, and one would need to see what changes have to be made to
the runtimes and the standard to allow for this, and how to report errors such
as "There is no more space on the stack" (which is going to be much more
frequent than running out of heap space).

As for "generic lambdas", I don't find that typing the type of your parameter
is too annoying at the moment, though I haven't used the feature much. Perhaps
this is a baby step in a move to make C++ a bit more Haskell-like: Strong
typing, but also powerful type inference mechanism.

Other languages have more features, that's true. But C++ is still trying to
advocate a blazingly fast speed, and pay-for-what-you-use mentality. That the
language can still be the fastest, one of the most powerful, and achieve
feature parity with current dynamic languages, I think reflects well on the
language, not the opposite.

~~~
cygx
> There is no real need for runtime sized arrays, as one could already use
> vectors [...] and allocate them on the stack

And how exactly would you do that? _alloca()_ aside, there is no such thing as
a stack allocator.

~~~
flebron
There's several projects that have seen the need to allocate variable length
things on the stack, Chromium was one[1]. A quick googling sends me to [2] as
well.

I haven't ever found myself in a situation where I _needed_ my stuff to be
stack allocated, but then again I've never done really low level programming
or embedded code, and I guess it could happen there.

[1]
[http://src.chromium.org/viewvc/chrome/trunk/src/base/stack_c...](http://src.chromium.org/viewvc/chrome/trunk/src/base/stack_container.h)

[2] <http://home.roadrunner.com/~hinnant/stack_alloc.html>

~~~
cygx
These just allocate a fixed-sized stack buffer and overflow to the heap - no
variable-length stack allocation happens.

~~~
flebron
Right, because alloca is the only thing (as far as I know) that can resize the
stack. There is not going to be anything else that does the same thing. The
best one can do is those stack allocators which overflow to heap, or an
alloca-based stack allocator.

There's an interesting discussion[1] at comp.std.c++ about implementing VLAs
in C++0x, and the issues with dynamic stack resizing.

[1]
[https://groups.google.com/forum/?fromgroups=#!topic/comp.std...](https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/K_4lgA1JYeg)

------
arcatek
I really would like a 'real' dependencies system.

But not until at least 2017 ... :(

------
ExpiredLink
> Is there anything else you want to know?

Why are you doing this? C++ has no future, only past.

~~~
zxcdw
If only there were alternatives which give similar control.

~~~
xradionut
There's not. We are stuck in a C/C++ world for the time being. I had hopes for
something like Oberon or D a couple of decades ago, but no one wants to go
tilting at the windmills.

~~~
pcwalton
Shameless plug, but Rust is intended to be that. There's also Clay, etc.

