You can grab and compile the very latest draft from the committees Github page:
https://github.com/cplusplus/draft
The current version is a slender 1365 pages, including the standard library.
We have C++14
81–90 of 353 posts
Re: We have C++14
#82OT question: I was playing with some C over the weekend (not C++), trying to figure out how to handle Unicode in a way that would work on Mac, Linux, and Windows. Despite a couple hours googling and reading, I couldn't answer really basic stuff, like: - Do I use char* for strings? It sounds like wchar_t is 16 bits on some systems and 32 on others, so I should avoid it? - If I want to read & write UTF-8 files, how do…
Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the features you want. In C++ unicode is as simple as: string s = u8"This is always a utf8 string.";
Unicode is much more complex than that. For example, how would you then convert that string to uppercase, or truncate it?
For Unicode strings in C++, you can either limp along with the wchar_t support, or leverage something like ICU. Neither is especially easy.
Re: We have C++14
#83Earlier quoted context omitted.
In languages like C++ "verbose" means "specific and obvious" which is something you want to have when writing certain kinds of code. It's annoying, it's a drag on productivity, but in the long run it's arguably necessary. Some other languages which reduce verbosity by making more things implicit make it harder to understand what's actually going on behind the scenes. You lose a lot of information.
Stroustrup doesn't think so. I don't have a link - it was in some recent conference. He stated that every time he added a new feature everyone would be up in arms and demand a really verbose implementation, which he added reluctantly. Now that everyone is used to the features they complain about how ridiculously verbose it all is. There isn't any reason for the craziness of template void foo(T a) vs void foo(auto a)…
The reason for your particular example is path dependency — templates came long before (the redefinition of) auto.
Re: We have C++14
#84Earlier quoted context omitted.
In languages like C++ "verbose" means "specific and obvious" which is something you want to have when writing certain kinds of code. It's annoying, it's a drag on productivity, but in the long run it's arguably necessary. Some other languages which reduce verbosity by making more things implicit make it harder to understand what's actually going on behind the scenes. You lose a lot of information.
Stroustrup doesn't think so. I don't have a link - it was in some recent conference. He stated that every time he added a new feature everyone would be up in arms and demand a really verbose implementation, which he added reluctantly. Now that everyone is used to the features they complain about how ridiculously verbose it all is. There isn't any reason for the craziness of template void foo(T a) vs void foo(auto a)…
But the expanded form does provide you with more flexibility. Even if the latter is a synonym for the former, there is a difference between:
template
void foo(T a, T b)
void foo(auto a, auto b)Re: We have C++14
#85Earlier quoted context omitted.
In languages like C++ "verbose" means "specific and obvious" which is something you want to have when writing certain kinds of code. It's annoying, it's a drag on productivity, but in the long run it's arguably necessary. Some other languages which reduce verbosity by making more things implicit make it harder to understand what's actually going on behind the scenes. You lose a lot of information.
Stroustrup doesn't think so. I don't have a link - it was in some recent conference. He stated that every time he added a new feature everyone would be up in arms and demand a really verbose implementation, which he added reluctantly. Now that everyone is used to the features they complain about how ridiculously verbose it all is. There isn't any reason for the craziness of template void foo(T a) vs void foo(auto a)…
[deleted]
Re: We have C++14
#86Earlier quoted context omitted.
This is totally true. The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to write that sort of code. I like way more of C++11 than I liked of the prior version, but there's just so much that's accumulated over the years. I wonder if breaking backwards compatibility is the key, but then I look at Python 3 and think, well, probably not.
Also, how many companies are afraid of the new features and deprecate them internally (fearing compiler bugs, lack of portability, and/or unmaintainability). I still haven't had a chance to use full C++11 in a professional context.
Like Google for example? Their C++ style guide is pretty restrictive, here's an expert C++ programmer's takedown of it:
https://www.linkedin.com/today/post/article/20140503193653-3...
Re: We have C++14
#87Earlier quoted context omitted.
In languages like C++ "verbose" means "specific and obvious" which is something you want to have when writing certain kinds of code. It's annoying, it's a drag on productivity, but in the long run it's arguably necessary. Some other languages which reduce verbosity by making more things implicit make it harder to understand what's actually going on behind the scenes. You lose a lot of information.
> In languages like C++ "verbose" means "specific and obvious" Whoa, no it doesn't. C++ is far more verbose than necessary for things like creating algebraic datatypes or really creating any types.
Indeed!
Just to write a class in C++ with a constructor and destructor which are not inlined, you have to repeat the class name about seven times: three times in the class declaration. Then four more times in the definitions of those two functions:
class verbose {
public:
verbose();
~verbose();
};
verbose::verbose()
{
}
verbose::~verbose()
{
}Re: We have C++14
#88Earlier quoted context omitted.
Stroustrup doesn't think so. I don't have a link - it was in some recent conference. He stated that every time he added a new feature everyone would be up in arms and demand a really verbose implementation, which he added reluctantly. Now that everyone is used to the features they complain about how ridiculously verbose it all is. There isn't any reason for the craziness of template void foo(T a) vs void foo(auto a)…
But the expanded form does provide you with more flexibility. Even if the latter is a synonym for the former, there is a difference between: template void foo(T a, T b) vs void foo(auto a, auto b)
It seems like in the second `foo`, the types of `a` and `b` are not hinged together. So to do it with the template syntax you actually need:
template
void foo(T a, U b)
Re: We have C++14
#89Earlier quoted context omitted.
Oh my goodness, yes. The HN crowd probably doesn't appreciate the extent to which people who sling C++ at BigCorp are limited by the rules the company sets.
It's not just C++ either. "What do you mean you want to use LINQ (in C#) ? No one understands that rubbish".
* Don't use LINQ
* Don't use var
* Don't use dynamic
or even better,
"You've only got .NET 2/3 installed"
Re: We have C++14
#90Earlier quoted context omitted.
This is totally true. The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to write that sort of code. I like way more of C++11 than I liked of the prior version, but there's just so much that's accumulated over the years. I wonder if breaking backwards compatibility is the key, but then I look at Python 3 and think, well, probably not.
> The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to write that sort of code. I do the same thing. Not because I can't write C++11, but because I still encounter systems with older compilers that I want to run programs on. What, is this surprising? Let's face reality: it's a little unreasonable to expect every system you work on to have…
> upgrade the existing compiler in a package-manager-friendly way
This is your problem.
Build a new compiler using the old compiler and install the entire new toolchain in /opt/my-gcc-4.9-0xfoof . rsync this new compiler to any machine you want. The package managers (people and code) a here for our suffering.