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

71–80 of 86 posts

Re: What will C++17 be?

#71

Post by Someone »

GFK_of_xmaspast wrote: post #53
slowmovintarget wrote: post #43

Earlier quoted context omitted.

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…

I'm obliged to make my c++ code work on a variety of platforms, and on windows this means visual studio.

But Visual studio doesn't imply Microsoft's C++. There's clang-cl (http://clang.llvm.org/docs/UsersManual.html#clang-cl), which aims to be a drop-in replacement for Microsoft's compiler (haven't used it, so I don't know its quality)

Also, Visual Studio 2015 will ship with clang (http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-stu...). Yes, that's for Android (and, in the future, iOS) only, but it would not surprise me if that it is a sign of things to come: either Microsoft starts following developments faster, or people will move to clang for development. And I doubt the current Microsoft would be bothered if their customers moved to use clang, as long as they kept using Microsoft technologies (even if that's limited to running on Azure)

Re: What will C++17 be?

#72

Post by krick »

tomp wrote: post #32
ris wrote: post #19

Earlier quoted context omitted.

Ugh. Language-based package managers are one of the biggest misfeatures of the millenium. They're all well and good* until they have to interact with the world outside their language universe. * I'm being very generous here.

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

I would double your question except pip is a really bad example. There are many problems with it, pretty well known inside the python community and discussed many times, so I won't repeat all that can be found on the internet quite easily. In fact, package managers in python are pretty ugly story in general, every new generation of them being long and painful attempt to fix problems of the previous one, but unfortunately introducing the new ones.

npm would be a much better example, however not perfect as well. Actually, I would say all package managers we have are quite imperfect, but it's more of a existing implementations problem, not a package manager problem in general.

I mean, yeah, it would be nice if we all just started using guix or something, and wouldn't need language-specific package managers anymore, but it's not happening yet, right? And we have to live somehow until it does. And if I need to use language-specific package manager to be able to install a library that has a new version with crucial fixes on github since yesterday, and the version apt-get suggests is two years old — well, I'd better be using language-specific package manager. Still better than compiling it manually collecting dependencies all over the world over the next few hours.

Re: What will C++17 be?

#73

Post by bkjelden »

I wish 'better compiler messages' could be a language feature.

I understand that that's pretty much outside of the scope of the language designers, but I've been playing with rust lately and it's so refreshing to actually get help from the compiler, rather than just looking for the line where it failed and trying to figure out what's wrong on my own.

Re: What will C++17 be?

#74

Post by tomjakubowski »

ris wrote: post #19
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.

Ugh. Language-based package managers are one of the biggest misfeatures of the millenium. They're all well and good* until they have to interact with the world outside their language universe. * I'm being very generous here.

There is an important distinction to make between package managers and project managers.

In Ruby, for example, Bundler is what I would call a project manager. It installs packages to a place only it knows (or it should know) about, and Bundler or tools that integrate with Bundler wrangle the Gem loader path to control what modules are available to load.

This way the dependencies of any number of project live in complete isolation from one another, including several different versions of the same dependency which is often impossible to achieve using a system package manager like apt or pacman. The end result is similar to something like virtualenv, but with (in my opinion) a friendlier user experience.

These project managers also often include project scaffolding tools and subcommands to run tests, generate documentation, etc. Examples in other languages include Leiningen or Boot for Clojure, Maven for Java, and Cargo[1] for Rust. When used properly and when the creators of a project manager understand its role, they can work in concert with a system-level package manager. Cargo, for example, interoperates beautifully with system packages with great support for linking with system libraries[2].

[1]: http://crates.io/

[2]: http://doc.crates.io/build-script.html#case-study:-linking-t...

Re: What will C++17 be?

#75

Post by SamReidHughes »

bkjelden wrote: post #73

I wish 'better compiler messages' could be a language feature. I understand that that's pretty much outside of the scope of the language designers, but I've been playing with rust lately and it's so refreshing to actually get help from the compiler, rather than just looking for the line where it failed and trying to figure out what's wrong on my own.

That's part of the reason people want 'concepts'.

Re: What will C++17 be?

#76

Post by ksherlock »

a13xb wrote: post #13
mike-cardwell wrote: post #4

Earlier quoted context omitted.

c++11 came in 2011. c++14 came in 2014. Seeing a pattern yet?

C++11 was originally known as C++0x, so C++17 may yet become C++19.

c++17 is currently known as c++1z.

You can use Clang in C++1z mode with the -std=c++1z option.

Re: What will C++17 be?

#77

Post by ris »

tomp wrote: post #32
ris wrote: post #19

Earlier quoted context omitted.

Ugh. Language-based package managers are one of the biggest misfeatures of the millenium. They're all well and good* until they have to interact with the world outside their language universe. * I'm being very generous here.

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

Try installing numpy and scipy.

Re: What will C++17 be?

#78

Post by dfan »

banachtarski wrote: post #69
dfan wrote: post #62

Earlier quoted context omitted.

Ranges are the killer feature for me. They'll actively improve my everyday code.

You mean the ranges that already exist?

Assuming that the ranges that already exist are the ones that get incorporated into the C++17 standard, yes.

Re: What will C++17 be?

#80

Post by getsat »

joliss wrote: post #46

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

Why is uniform call syntax a good addition? What is the benefit?

I only ever remember hearing of one programming language supporting it, and I can't even remember what it is. Maybe it was Nim?

Post reply on HN