
Current Proposals for C++17 - meetingcpp
http://meetingcpp.com/index.php/br/items/current-proposals-for-c17.html
======
vmorgulis
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).

~~~
repsilat
Why prefer

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

to

    
    
        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.

~~~
kevinnk
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...](http://blog.reverberate.org/2013/08/parsing-c-is-literally-
undecidable.html)

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

~~~
kevinnk
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...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2015/n4465.pdf) [2]
[http://clang.llvm.org/docs/Modules.html](http://clang.llvm.org/docs/Modules.html)

~~~
maxxxxx
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.

~~~
meetingcpp
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.

~~~
kevinnk
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.

~~~
maxxxxx
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.

~~~
kazinator
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.

~~~
Kliment
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.

------
Razengan
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?

~~~
dottrap
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.)

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

~~~
vmorgulis
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...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2015/n4492.pdf)

~~~
Rexxar
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 ?

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

~~~
vmorgulis
"... nor fear the competition"?

