7 ms·

C++14

44 points by AndreyKarpov 14y ago

kibwen 14y ago
"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.
- jordibunster 14y ago
  Not sure about the origin, but Ruby has them too.
  - jlarocco 14y ago
    Not sure of the origin either, but Ada has had that since 1983.
    - _delirium 14y ago
      Aha, interesting. I was doing some quick scanning on Google-Books and other places to try to find the earliest usage, using variants of "numeric literal" and "underscore" as search terms, and couldn't find anything pre-1990s. Now I find the Ada stuff, and it wasn't coming up because all the '80s Ada documentation/discussion refers to them as underline characters, rather than underscore. (Incidentally, one of the perils of trying to draw historical conclusions from text searches, or data sets like Google Ngrams: you could get completely wrong results if you miss a shift in spelling or word usage.)
- mpyne 14y ago
  Perl has had it for awhile, although there were probably languages that had it beforehand (awk or ADA maybe?)
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
- ksherlock 14y ago
  That was in use in some assemblers back in the 80s and probably earlier.
- mahmud 14y ago
  It's very common in ML languages: SML and Ocaml both support it.
- elrzn 14y ago
  I think I saw it first in Perl.
- JoeAltmaier 14y ago
  But not much more readable than, say Hex e.g. 0x12204.
  - kibwen 14y ago
    Indeed, but it's also useful in order to detect at a glance the order of magnitude of a literal. For instance, if I come across 10_000_000 in some code, I don't need to interrupt my train of thought to meticulously count the zeroes; I instantly know that's ten million. I couldn't say the same if it was instead written as 100000000.
    - easytiger 14y ago
      puny human
  - tptacek 14y ago
    It is if you're representing a flag word.
- positr0n 14y ago
  Verilog has that feature too
- chmike 14y ago
  I saw it first in D. Doesn't mean it was invented there ;)
- kps 14y ago
  There's a Boost header with macros that provide this for C and C++. int i = BOOST_BINARY( 1 0010 0010 0000 1000 );
  - ruggeri 14y ago
    Upvoted, but I cry at the thought of all that extra typing.
- alex-g 14y ago
  This seems to me to be far more useful than user-defined literals (the conflicting feature). At least, I can think of many programs where digit separators would be nice - but for user-defined literals, I don't see them as providing much. We could already make invocations like "pixels(200)" and being able to say "200_pixels" doesn't add much to that, except complicating the parser.
  - anonymouz 14y ago
    The problem with this argument is that user-defined literals already exist in C++11, and use of the underscore character for a different purpose in a future standard has to be in such a way that it can be unambiguously distinguished from the user-defined literal usage. Backward-compatibility to the current standard has to be preserved.
    - alex-g 14y ago
      Oh, absolutely, I just think it's a shame.
- rootbear 14y ago
  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 14y ago
    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.
  - evincarofautumn 14y ago
    Digit separation might make long numbers more readable, but now they’re also more locale-dependent. Same goes for commas versus periods. Regardless, I think the grave accent is a poor choice here. Whitespace would be better, much like adjacent string literals in C. A compiler could warn by default about numeric literals crossing line boundaries in free-form languages, to catch missing punctuation. This also has the advantage of precedent in scientific literature. Unfortunately it doesn’t work in languages without some redundancy, like many in the vector family. Is this a four-vector of one-digit numbers or a one-vector of a four-digit number? [1 2 3 4]
- zem 14y ago
  ruby was the first place i saw it used, but it's probably older than that.
- fauigerzigerk 14y ago
  Java has it.
  - kibwen 14y ago
    Whoa, you're right. Looks like it's a new feature in Java 7. http://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html http://docs.oracle.com/javase/7/docs/technotes/guides/langua...
idank 14y ago
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 14y ago
  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.
  - dllthomas 14y ago
    Your first two paragraphs here seem contradictory. If the feature can already be implemented, and the cost is merely some syntactic messiness, then there is no change necessary to the runtimes - all you need is a little syntactic sugar. As an aside, there is a grand history of array notation being nothing more than syntax. Try building the following in gcc: int main() { int foo[] = {1, 2, 3}; return 1[foo]; } The expression a[b] is simply translated into a + b, which commutes. There's some constraint applied that something there be a pointer (so 1[2] is rejected) but it's weaker than it "should" be...
rvkennedy 14y ago
"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.
ExpiredLink 14y ago
> Is there anything else you want to know? Why are you doing this? C++ has no future, only past.
- nnq 14y ago
  I just wish/hope it's true... that we ll finally get out of this dark age of byzantine languages that grow like cancer (just rembered the good ol "C is to C++ as Lung is to Lung Cancer" :) )... congrats for saying it out loud anyway!
- zxcdw 14y ago
  If only there were alternatives which give similar control.
  - xradionut 14y ago
    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 14y ago
      Shameless plug, but Rust is intended to be that. There's also Clay, etc.
  - slowpoke 14y ago
    I do believe most new projects today would be better off with a combination of a high level language for the logic, like Python or Perl, and a low level language like C or maybe Go for the plumbing, with clean interfaces between them. There really is no need for a behemoth like C++, with two dozen ways to do any single thing, half of them conflicting with each other and the other half subject to vigorous religious debates.
    - zxcdw 14y ago
      I think the key for effective use of C++ is to know what to do and what to use to do it. It's certain that relying on multiple inheritance for example is probably a bad idea. After working with Ruby for some time, I realized that many co-developers don't have a slightest of a clue what they're doing with the language yet they do just about right with it - with C++ similar (careless) mindset and skill level would very soon end up in a terminated project. In the end it's the domain which matters more than the languages - as I implied in my earlier comment, I outright require as much control over the hardware as possible - there are no alternatives for me. Rust comes close(and it's nice, I like it thus far!), but let's see in a few years.
fafner 14y ago
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 http://gcc.gnu.org/gcc-4.8/changes.html
mseepgood 14y ago
How much can be added to a programming language until it collapses?
arcatek 14y ago
I really would like a 'real' dependencies system. But not until at least 2017 ... :(
pascal_cuoq 14y ago
I wonder whether the hexadecimal floating-point syntax 0x1.23p45 referred to in http://stackoverflow.com/a/11840637/139746 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.

44 points by AndreyKarpov 14y ago

"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.

jordibunster 14y ago
Not sure about the origin, but Ruby has them too.
- jlarocco 14y ago
  Not sure of the origin either, but Ada has had that since 1983.
  - _delirium 14y ago
    Aha, interesting. I was doing some quick scanning on Google-Books and other places to try to find the earliest usage, using variants of "numeric literal" and "underscore" as search terms, and couldn't find anything pre-1990s. Now I find the Ada stuff, and it wasn't coming up because all the '80s Ada documentation/discussion refers to them as underline characters, rather than underscore. (Incidentally, one of the perils of trying to draw historical conclusions from text searches, or data sets like Google Ngrams: you could get completely wrong results if you miss a shift in spelling or word usage.)
mpyne 14y ago
Perl has had it for awhile, although there were probably languages that had it beforehand (awk or ADA maybe?)
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
ksherlock 14y ago
That was in use in some assemblers back in the 80s and probably earlier.
mahmud 14y ago
It's very common in ML languages: SML and Ocaml both support it.
elrzn 14y ago
I think I saw it first in Perl.
JoeAltmaier 14y ago
But not much more readable than, say Hex e.g. 0x12204.
- kibwen 14y ago
  Indeed, but it's also useful in order to detect at a glance the order of magnitude of a literal. For instance, if I come across 10_000_000 in some code, I don't need to interrupt my train of thought to meticulously count the zeroes; I instantly know that's ten million. I couldn't say the same if it was instead written as 100000000.
  - easytiger 14y ago
    puny human
- tptacek 14y ago
  It is if you're representing a flag word.
positr0n 14y ago
Verilog has that feature too
chmike 14y ago
I saw it first in D. Doesn't mean it was invented there ;)
kps 14y ago
There's a Boost header with macros that provide this for C and C++. int i = BOOST_BINARY( 1 0010 0010 0000 1000 );
- ruggeri 14y ago
  Upvoted, but I cry at the thought of all that extra typing.
alex-g 14y ago
This seems to me to be far more useful than user-defined literals (the conflicting feature). At least, I can think of many programs where digit separators would be nice - but for user-defined literals, I don't see them as providing much. We could already make invocations like "pixels(200)" and being able to say "200_pixels" doesn't add much to that, except complicating the parser.
- anonymouz 14y ago
  The problem with this argument is that user-defined literals already exist in C++11, and use of the underscore character for a different purpose in a future standard has to be in such a way that it can be unambiguously distinguished from the user-defined literal usage. Backward-compatibility to the current standard has to be preserved.
  - alex-g 14y ago
    Oh, absolutely, I just think it's a shame.
rootbear 14y ago
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 14y ago
  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.
- evincarofautumn 14y ago
  Digit separation might make long numbers more readable, but now they’re also more locale-dependent. Same goes for commas versus periods. Regardless, I think the grave accent is a poor choice here. Whitespace would be better, much like adjacent string literals in C. A compiler could warn by default about numeric literals crossing line boundaries in free-form languages, to catch missing punctuation. This also has the advantage of precedent in scientific literature. Unfortunately it doesn’t work in languages without some redundancy, like many in the vector family. Is this a four-vector of one-digit numbers or a one-vector of a four-digit number? [1 2 3 4]
zem 14y ago
ruby was the first place i saw it used, but it's probably older than that.
fauigerzigerk 14y ago
Java has it.
- kibwen 14y ago
  Whoa, you're right. Looks like it's a new feature in Java 7. http://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html http://docs.oracle.com/javase/7/docs/technotes/guides/langua...

idank 14y ago

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 14y ago
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.
- dllthomas 14y ago
  Your first two paragraphs here seem contradictory. If the feature can already be implemented, and the cost is merely some syntactic messiness, then there is no change necessary to the runtimes - all you need is a little syntactic sugar. As an aside, there is a grand history of array notation being nothing more than syntax. Try building the following in gcc: int main() { int foo[] = {1, 2, 3}; return 1[foo]; } The expression a[b] is simply translated into a + b, which commutes. There's some constraint applied that something there be a pointer (so 1[2] is rejected) but it's weaker than it "should" be...

rvkennedy 14y ago

"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.

ExpiredLink 14y ago

> Is there anything else you want to know? Why are you doing this? C++ has no future, only past.

nnq 14y ago
I just wish/hope it's true... that we ll finally get out of this dark age of byzantine languages that grow like cancer (just rembered the good ol "C is to C++ as Lung is to Lung Cancer" :) )... congrats for saying it out loud anyway!
zxcdw 14y ago
If only there were alternatives which give similar control.
- xradionut 14y ago
  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 14y ago
    Shameless plug, but Rust is intended to be that. There's also Clay, etc.
- slowpoke 14y ago
  I do believe most new projects today would be better off with a combination of a high level language for the logic, like Python or Perl, and a low level language like C or maybe Go for the plumbing, with clean interfaces between them. There really is no need for a behemoth like C++, with two dozen ways to do any single thing, half of them conflicting with each other and the other half subject to vigorous religious debates.
  - zxcdw 14y ago
    I think the key for effective use of C++ is to know what to do and what to use to do it. It's certain that relying on multiple inheritance for example is probably a bad idea. After working with Ruby for some time, I realized that many co-developers don't have a slightest of a clue what they're doing with the language yet they do just about right with it - with C++ similar (careless) mindset and skill level would very soon end up in a terminated project. In the end it's the domain which matters more than the languages - as I implied in my earlier comment, I outright require as much control over the hardware as possible - there are no alternatives for me. Rust comes close(and it's nice, I like it thus far!), but let's see in a few years.

fafner 14y ago

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 http://gcc.gnu.org/gcc-4.8/changes.html

mseepgood 14y ago

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

arcatek 14y ago

I really would like a 'real' dependencies system. But not until at least 2017 ... :(

pascal_cuoq 14y ago

I wonder whether the hexadecimal floating-point syntax 0x1.23p45 referred to in http://stackoverflow.com/a/11840637/139746 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.