Current Proposals for C++17 | Hacker News Reader

Current Proposals for C++17

meetingcpp.com

66 pointsmeetingcpp36 comments

With Concepts, we will also have "auto" in function arguments. It avoids "template <typename ...>" for simple functions.

I already use it as a "catch all" over specialized functions (gcc -std=c++17).

Why prefer

    int foo(auto a, auto &&b);

    int foo(a, &&b);

? Too big a change? Too much magic? Maybe more difficult to read or parse. The argument "It's not clear that the function is a template" isn't there any more, though, so it seems reasonable to me.

You actually hit on the exact reason; your change is significantly harder to parse. C++ allows you to alias typenames and variable names, so you wouldn't know if `int foo(T);` was a declaration of a function that take a type `T` or a function that has an implicitly typed parameter called `T` until much later in the parse. Adding auto makes it clear this is a declaration of a variable. That kind of ambiguity already exists in C++[1], but is widely regarded as one of the things that makes parsing C++ extremely hairy.

Interestingly, I remember hearing about this exact problem in the context of Swift's closures; if you want type inference, you need to leave off the parens around the parameters. This is mainly done (IIRC) because it's easier for the parser.

[1] http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...

Do you mean?

    template <typename T1,typename T2>
    int foo(T1 a, T2 &&b);

"auto" is shorter.

I have been away from C++ for a while. Has there been any progress in making it easier to link different libraries together? In C# it's so nice that you can just reference another library and you are all done.

When I used C++ last time this was always a huge ordeal.

Do you mean link as in "linker"? Or are you asking if it's possible to do "using LibX" like in C#?

You can already do "using ClassX", but yeah, the package management story in C++ isn't great.

There's a proposal for modules in C++[1], which should help, but as far as I know that's not going to be in C++17. Clang already has a (different) version implemented as well[2].

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n446... [2] http://clang.llvm.org/docs/Modules.html

I meant compiling C++ code into a shared library like a DLL on Windows and be able to use the classes in that DLL from other code. The same way you can easily call C code in different libraries.

Well, that has been done for decades. You just need to link your code with the correct libraries.

Its probably a bit easier with C as it has a common ABI, and C# as it only has one tool chain, and not multiple toolchains from multiple vendors like C++.

Modules will help here further.

I believe maxxxxx is asking about the ability to import and use classes from a DLL directly, without needing a class definition. As far as I know, in standard C++ this isn't possible.

Yes, that is correct. That is not possible, modules might offer things in this direction.

Yes, that's it. Thank you!

This is the one thing I really like about .NET. C++ would be so much more accessible to beginners if it was easier to integrate other libraries. Even integrating something as common as boost is quite hard with Visual Studio on Windows.

C++ doesn't define any object format, period.

A C++ implementation could provide translated units which encapsulate not only compiled code, but also contain compiled class declarations, such that these units can just be used without any preprocessing, tokenizing or parsing. That would be outside the language.

The C++ language as it stands is defined in terms of a textual representation: everything proceeds from translation units being scanned into preprocessing tokens and so forth.

To use a compiled class declaration, you would still need to see the source code somewhere, in some form, in some documentation. Otherwise, how would you know that the frobozz class has a freakout method which accepts two int parameters.

About the last bit, a long time ago I would use the ctypes library in Python to inspect, list, and call functions defined in .DLLs. All the symbol exports are right there in the object file, so for non-C++ callers you don't exactly need the source code to call functions. It doesn't seem like a large stretch to ask whether the same thing can be done with classes, or to expect that this particular aspect would have changed sometime in three iterations of the standard.

Ah, I understand. Currently in C++ you cannot inspect class members or call methods without a class definition (i.e. the class header file). For the most part, the C++ standard doesn't really consider the object layout "in scope" so it's unlikely we'll see something like this standardized in the near future. This could change (maybe if/when reflection is added?) but nothing like it is being talked about AFAIK.

I assume performance is one of the main reasons that C/C++ are still relevant today, and the reason why modern languages like Swift and Go can't be as fast is because of their "runtime" software layer which makes their fancy features possible.

My honest if somewhat noobish question is: Why isn't support for features like type safety and so on being incorporated into CPUs themselves, like they did with SIMD instruction sets?

I mean, if so many languages require "runtimes" now, why haven't the features that are common across those runtimes, been factored out into hardware already?

That's not a fair characterization of Swift's runtime. Swift is similar to C++ in that it compiles down a lot of stuff so it doesn't need to make runtime decisions.

Swift could theoretically be as fast or faster than C/C++, but C/C++ have decades compiler optimizations that are going to be hard to beat. I say Swift has the potential to be faster because of the pointer aliasing problems of C/C++, which Swift can potentially optimize (like why Fortran still can beat C).

But your question about runtimes and performance are kind of a red herring. High performance means utilizing the underlying hardware well. A lot of the popular modern languages were designed for convenience over speed and were designed in an era of ever-increasing single processor CPU speeds. Very few languages map to how hardware actually works so they give up speed. Few mainstream languages automatically vectorize _well_ and _reliably_ to automatically exploit SIMD (C/C++ don't really do this...we generally have to write the intrinsics ourselves if we care). Few mainstream languages do a good job exploiting the multiple cores/CPUs available to us (don't say threads...they are pretty poor. This is one interesting feature of Go). Cache locality is now extremely important to high performance and most languages don't let us really control this. (C/C++ give us some say on our memory layouts.)

This is moving fast, a moratorium for some time would be beneficial for community. Like the one that happened in Python sometime ago.

The last big change was c++11, and that was already five years ago.

Forgetting about C++14?

C++14 just cleaned up a couple of minor things from C++11. It was essentially intended to be a point release.

C++17 is the first "big" standard change since C++11. It will likely be followed by a small bug fix revision, analogous to C++14, a couple of years later.

Wasn't a lot of memory safety and thread safety introduced in c++14?

C++11 introduced threading and a memory model for C++.

C++14 had relaxed requirements on constexpr, initializers in lambda captures, using auto for return type deductions, and a few other small tweaks.

C++11 had unique_ptr and shared_ptr, but C++14 helped with adding make_unique. In my opinion, that makes a big difference because now making a special unique pointer is an atomic operation in your program.

If only make_unique (and make_shared) worked with uniform initialization...

  struct Foo {
    int i;
    float f;
    bool b;

    // No constructor
  };

  std::make_unique<Foo>(1, 2.3f, true);

Doesn't compile, since make_unique requires an appropriate constructor (see https://isocpp.org/files/papers/n3588.txt for the rationale).

It also doesn't work when Foo's constructor is private, even when called from a function that would have access to this private constructor.

And this is my beef with C++: Yes it's powerful, and I quite like it, but you sooner or later hit these speed bumps that unnecessarily complicate things.

I don't consider c++14 to be a big change.

Stroustup is pushing a lot forward:

"C++ use is on the increase. We need to improve C++ to sustain the momentum, not better serve the C++ programmers, not out of fear of competition."

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n449...

I'm not a native English speaker and I'm no sure I understand this part correctly : "..., not better serve the C++ programmers, ...". Does it means that improving c++ is not done to help c++ programmers ?

I am a native english speaker and that quote makes absolutely no sense

"... nor fear the competition"?

As a native English speaker, it doesn't make sense (it's ungrammatical, in fact), and I'd assume it is probably a typo.

It was probably intended to be "..., to better serve the C++ programmers, ...". That would provide a contrast for the final "not" to be operating on.

You're reading the sentence correctly, but I think it was a typo and was probably intended to say:

"We need to improve C++ to sustain the momentum and to better serve the C++ programmers, not out of fear of competition."

The accidental repetition of not is not an unusual mistake, and the original sentence doesn't match the tone of the previous paragraph given that he says "I deem something 'major' or 'minor' based on what it does for users"

I think this is rather unlike the Python 3 situation. My guess for the resistance to Python 3 adoption is that it was, by design, not backwards-compatible with Python 2. C++ versions are not completely backwards-compatible, but I think they are more than the Python 2 to 3 switch. What is certain is that lots of other languages release new versions a few times a decade. See, for example, version histories of:

https://en.wikipedia.org/wiki/Java_version_history

https://en.wikipedia.org/wiki/C_Sharp_(programming_language)...

https://en.wikipedia.org/wiki/ANSI_C

um, nope, not going to happen...

C++ did that in the 2000's, in that time there wasn't much news about standardization, because of this C++ was seen as legacy, people moved to other languages. The new languages such as Rust, Go etc. are also a result of this.

The C++ committee has now a process of ongoing standardization established, which will improve the language further, and make it easier and more efficient to write C++. Also, the standards are usually backward compatible for at least 2 standards. What gets removed is often obscure features like auto_ptr, random_shuffle etc. which are superseeded by better alternatives. Clang modernize can even get your code base automatically updated to a new standard.

I know, that some of you are left behind, as you are stuck with the traditional "almost never update the toolchain" model, but clang and other tools are such a leap forward, that this is not a model for the future anymore.

So, C++ ecosystem evolves to become better, and make you as a programmer more productive and lets you write easier and safer code.

While I appreciate the effort to make things easier, as someone who is trying to move from C++98 to C++11, I'm not sure the new features make the language easier to use so long as you still have to learn the old ways of doing things. Speaking for myself, at least, this just causes interference between competing habits. What would be better for me and maybe others, would be if some of the unsafe or deprecated features in C++ were disallowed or if there were a compiler option to disallow them. I know this would break C89 compatibility but so what if you know you only care about the newer and more efficient features of C++?

If you can, go for C++14 directly, it offers improvements over C++11.

Language features that ease your daily working with C++11/14:

- Lambdas, especially when working with <algorithm>

- ranged for loop

- auto instead of typing long types

- variadic templates increase compilation speed over the previous macro based simulation of this feature.

- the basic support for multithreading which std::thread & co offer.

And also, as always in C++: you only pay for what you use. You still can write code in old styles pretty well with C++14, same will be true for coming standards.

Agreed. Auto looks like a useless bit of syntatic sugar, but it can make working with the standard library (and its impenetrable iterator classes) a whole lot simpler. On top of that, boost has some nice features that make easy-but-annoying tasks like walking a file system and parsing program options easy.

If your last exposure to C++ featured nothing but raw pointers, you should really give it a second look.

Reply on news.ycombinator.com