Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What will C++17 be?

docs.google.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: What will C++17 be?

#41

Post by microtonal »

jeremyjh wrote: post #30
plq wrote: post #9

Earlier quoted context omitted.

From where I'm standing, C++ package management is already quite nicely solved by what we call package managers in the linux world. You know, portage, aptitude, etc.

That's all well and good up to a point - but large production systems need repeatable builds that do not depend on the developers OS version or patch level. Eventually you have to vendor every dependency.

This is what is called API and ABI stability. Most well-known C and C++ libraries have been API and ABI stable for years.

In practice, this hasn't been a problem for my C++ projects for years, except on OS X where there have been too many changes in a couple of years (gcc -> gcc-llvm -> clang, libstdc++ -> libc++).

Re: What will C++17 be?

#42

Post by nawitus »

plq wrote: post #9
fishnchips wrote: post #3

How about making the language more accessible to newcomers by providing a sane default way of doing package management and builds. Go is a great example of both things done reasonably well out of the box.

From where I'm standing, C++ package management is already quite nicely solved by what we call package managers in the linux world. You know, portage, aptitude, etc.

There's a few problems with this:

* It only works in Linux, not Windows or Mac OS X.

* You need additional work to have it work in more distributions

* Linux package file formats are not distribution neutral, there's no "package.json" which is understood by every package manager

I think C++ needs an OS neutral package management system.

Re: What will C++17 be?

#43

Post by slowmovintarget »

zerr wrote: post #16
Someone wrote: post #11

Earlier quoted context omitted.

http://cpprocks.com/c1114-compiler-and-library-shootout/ disagrees: "First, let’s look at the C++11 language features. Clang 3.3 and above, and GCC 4.8 and later have complete support, so there was no point including them in the table." Also note that, on the C++14 front, clang supported all language features and most library features. And that is a year ago.

Yes, but I was talking about MSVC - MicroSoft Visual C++ compiler.

That's kind of like saying "You haven't read Shakespeare until you read him in the original Klingon."

Waiting for Microsoft to make a compiler seems like it ought to be orthogonal to moving the language forward, especially when non-Microsoft tool chains are already doing better with that particular language.

Microsoft has enough on their plate bringing C# and .Net to Linux and Unix, and I'd much rather they get that right than compete with GCC and CLANG. (That and Docker for HyperV and Windows Server.)

Re: What will C++17 be?

#44

Post by tomp »

riffraff wrote: post #37
tomp wrote: post #32

Earlier quoted context omitted.

Hm... Can you elaborate? I have nothing but good things to say about PIP (the only package manager I've used extensively).

the world outside would be, e.g. system libraries. Python package X depend on libxml-foo or libmagick-bar-6.6.7..

Either I've never used Python libraries that would need external libraries, or PIP installs those as well. I definitely know that it can compile code as well, e.g. for installing Numpy/Pandas.

Re: What will C++17 be?

#46

Post by joliss »

Some of these proposals are really intriguing. More details:

Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29

Modules: http://clang.llvm.org/docs/Modules.html

Coroutines: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n370...

operator. (for proxies): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417...

Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417...

Re: What will C++17 be?

#47

Post by krastanov »

tomp wrote: post #44
riffraff wrote: post #37

Earlier quoted context omitted.

the world outside would be, e.g. system libraries. Python package X depend on libxml-foo or libmagick-bar-6.6.7..

Either I've never used Python libraries that would need external libraries, or PIP installs those as well. I definitely know that it can compile code as well, e.g. for installing Numpy/Pandas.

It does not. To keep to the scientific python examples you mentioned: It is a pain to install `matplotlib` with pip if you do not have the C libraries for image compression. (Still, I like pip+virtualenv quite a bit, but they are definitely insufficient when C modules are involved).

Re: What will C++17 be?

#48

Post by Timmmmmm »

plq wrote: post #9
fishnchips wrote: post #3

How about making the language more accessible to newcomers by providing a sane default way of doing package management and builds. Go is a great example of both things done reasonably well out of the box.

From where I'm standing, C++ package management is already quite nicely solved by what we call package managers in the linux world. You know, portage, aptitude, etc.

They are hacks that paper over the lack of good package management. Plus they are too much extra work, and OS-specific. No build system integrates with them as far as I know.

I think what people want is something like go, where you add a single line to your code and it magically downloads and compiles the referenced library. C++ doesn't have anything like that (and I doubt it ever will to be honest).

Re: What will C++17 be?

#49

Post by vitaut »

fishnchips wrote: post #3

How about making the language more accessible to newcomers by providing a sane default way of doing package management and builds. Go is a great example of both things done reasonably well out of the box.

There is a package manager for C++ called Biicode: https://www.biicode.com/

Re: What will C++17 be?

#50

Post by stingraycharles »

humanrebar wrote: post #40

I like that feature list a lot. It's going to be very hard to get those features ready, implemented, and stable by the end of 2017, though. Even assuming no issues with politics or the rest of the standardization process. Concepts alone is looking like a very complex feature. And I was and under the impression that modules were even less ready. But both are very much needed. I do know that the committee is planning o…

Correct me if I'm wrong, but isn't the whole infrastructure for concepts already there using TMP? The c++ std library even uses some of them already (for example, when using a set it requires an type with operatorTo me it feels as if c++17 is just making the compiler more aware of them, and as a result likely produce better error messages (and the code to write them to be more pleasant).
Post reply on HN