We have C++14 • Hacker News Board

Re: We have C++14

#171

Post by pbsd » Tue, Aug 19, 2014, 4:33 AM UTC

StephanTLavavej wrote: post #155

pbsd wrote: post #64

Earlier quoted context omitted.

> or the most succinct (replace && by & if writing): That is strictly not necessary. `auto&&` is what is now being called a universal reference: `item` resolves to `const int&` if `myVec` is const, and to `int&` if `myVec` is mutable. `auto&&` does the right thing in the majority of cases. In fact, the following extension [1] has been proposed for C++17 (and already implemented in recent clang builds): for( item : my…

Both auto& and auto&& produce const T& for a const vector , and T& for a modifiable vector . The difference between them is subtle: auto&& handles Humanity's Eternal Nemesis, vector .

Oops, you're right of course; I got reference collapsing rules confused with the regular binding rules. Proxy objects will only bind to auto const& or auto&&, though, since they're generally returned by value. I was surprised to see that this does not come up in std::bitset nor std::valarray, but only std::vector.

Re: We have C++14

#172

Post by CountSessine » Tue, Aug 19, 2014, 4:42 AM UTC

enraged_camel wrote: post #160

davvid wrote: post #149

Earlier quoted context omitted.

Too bad it's a mirage I hate to spoil your worldview, but modern C++ is very alive and well in the scientific computing communities. Disney Animation implemented a new renderer using it, and our next movie is currently being rendered using the new renderer, so I highly doubt it's on its way out in the these areas.

I don't see how that refutes the parent's comment. The areas you listed are very small niches. Frankly, very few people care about scientific computing or even animation rendering. Generally speaking, using C++ is like wearing jeans and white sneakers: popular in the 90s, but definitely out of fashion now.

Oh goodness - C++ is out of fashion? But I was so productive! And my code ran so fast! Well, I guess I should go read up on node.lang or er-rust, or whatever it is those kids are into...

Re: We have C++14

#173

Post by wfunction » Tue, Aug 19, 2014, 4:42 AM UTC

millstone wrote: post #141

MereInterest wrote: post #138

Earlier quoted context omitted.

It also completely forbids the use of exceptions. I can understand that for their stated purpose of working with non-exception-safe legacy code, but it shouldn't be extended to other circumstances.

Exceptions have a significant performance impact, and making code exception safe distorts your interfaces. Insisting on no exceptions is reasonable for these and other reasons, even for new code.

> Exceptions have a significant performance impact

Are you talking about enabling exceptions, or throwing them?

Re: We have C++14

#174

Post by helmut_hed » Tue, Aug 19, 2014, 4:48 AM UTC

millstone wrote: post #141

MereInterest wrote: post #138

Earlier quoted context omitted.

It also completely forbids the use of exceptions. I can understand that for their stated purpose of working with non-exception-safe legacy code, but it shouldn't be extended to other circumstances.

Exceptions have a significant performance impact, and making code exception safe distorts your interfaces. Insisting on no exceptions is reasonable for these and other reasons, even for new code.

Can you elaborate on the "significant performance impact"? If used properly, they should have no runtime overhead - they are predicted "not taken" in modern compilers.

Re: We have C++14

#175

Post by CountSessine » Tue, Aug 19, 2014, 4:50 AM UTC

zxcdw wrote: post #159

Pacabel wrote: post #142

Earlier quoted context omitted.

When it comes to Rust, there's no stable version of the language at this point. There's no stable version of the standard libraries. There's no reliable production-grade compiler available. As the Rust home page itself states, "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry." Maybe Rust will offer such stability in the future. But that's of no use to people and organiz…

But now you aren't talking about Rust the Language but Rust the Ecosystem . Not that I am disagreeing with your points, I am not. However, when people talk about C++'s problems, I immediately assume they talk about C++'s problems as a language rather than it's ecosysem. Rust isn't out there to tackle C++'s ecosystem, tooling, legacy code or professional workforce, but rather Rust aims somewhere near C++ and fixes man…

Ecosystem really is the whole problem, though. You can never make it big without having lots of friends.

Rust is a pretty cool language, but I can't help being reminded about another very well-designed but ultimately unsuccessful C++ challenger, D. The parallels are really hard to ignore.

D, like Rust, had great syntax and was a breath of fresh air after coding with C++98. Neither Rust not D has a sponsor with really deep pockets to encourage adoption. Neither came out of a standards process. Both have had compiler and standard library issues. The big difference between the two at this point seems to be momentum and where the two are in their parabolic trajectories.

Re: We have C++14

#176

Post by EpicEng » Tue, Aug 19, 2014, 4:50 AM UTC

zxcdw wrote: post #159

Pacabel wrote: post #142

Earlier quoted context omitted.

When it comes to Rust, there's no stable version of the language at this point. There's no stable version of the standard libraries. There's no reliable production-grade compiler available. As the Rust home page itself states, "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry." Maybe Rust will offer such stability in the future. But that's of no use to people and organiz…

But now you aren't talking about Rust the Language but Rust the Ecosystem . Not that I am disagreeing with your points, I am not. However, when people talk about C++'s problems, I immediately assume they talk about C++'s problems as a language rather than it's ecosysem. Rust isn't out there to tackle C++'s ecosystem, tooling, legacy code or professional workforce, but rather Rust aims somewhere near C++ and fixes man…

I don't think that the two can be separated in any meaningful way. Of course they're different things, and we can discuss each on their own, but when it comes to which language to use as a business decision then the line becomes blurred if not completely transparent.

Re: We have C++14

#177

Post by EpicEng » Tue, Aug 19, 2014, 4:52 AM UTC

enraged_camel wrote: post #160

davvid wrote: post #149

Earlier quoted context omitted.

Too bad it's a mirage I hate to spoil your worldview, but modern C++ is very alive and well in the scientific computing communities. Disney Animation implemented a new renderer using it, and our next movie is currently being rendered using the new renderer, so I highly doubt it's on its way out in the these areas.

I don't see how that refutes the parent's comment. The areas you listed are very small niches. Frankly, very few people care about scientific computing or even animation rendering. Generally speaking, using C++ is like wearing jeans and white sneakers: popular in the 90s, but definitely out of fashion now.

Exactly. It is out of fashion, but fashion is fleeting. Fashion is a twenty year old wearing skinny jeans; style is James Bond in a Tuxedo, and it's timeless. What's in fashion today may very well be out of fashion tomorrow. I will likely still be writing C++ to get shit done.

Re: We have C++14

#178

Post by shmerl » Tue, Aug 19, 2014, 4:55 AM UTC

wfunction wrote: post #162

shmerl wrote: post #136

Earlier quoted context omitted.

You don't need to use the compiler from the distro to release for that distro. There is such thing as cross compilation after all. Most do it out of habit and because distros don't offer such services out of the box. But if you build the cross compiler, you can use the newest one even if the distro ships the older. For example I had a building machine running RHEL 5 which was building for both RHEL 5 and RHEL 6 while…

You say "if you build the cross-compiler" as though it's as simple as "if you cross the street". Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

It is hard if you do it all manually. There are helpful tools like Crosstool-NG for example which make it easier.

Re: We have C++14

#179

Post by zak_mc_kracken » Tue, Aug 19, 2014, 4:56 AM UTC

wfunction wrote: post #163

zak_mc_kracken wrote: post #103

Earlier quoted context omitted.

Over 20+ years of development, I've found this objection to be vastly theoretical and with no practical consequences. In practice, most classes are designed without inheritance in mind and yet, being able to extend and override them has proven infinitely more valuable than the occasional case where such an overriding breaks the parent class. The practical reality is that even if a class is not designed for inheritanc…

Seemingly off-topic, but I'm curious -- what language has the majority of your 20+ years of development been in?

Professionally, Java for most of the time. Recreationally, Scala and Haskell. I did about 5 years of C++ overlapping with Java before that.

Re: We have C++14

#180

Post by yongjik » Tue, Aug 19, 2014, 5:04 AM UTC

Silhouette wrote: post #131

yongjik wrote: post #122

Earlier quoted context omitted.

FWIW, things like range-based for loops, "auto", and unique_ptr are pretty standard in Google these days. Still no exceptions, though. The thing is, when you have a single codebase that is maintained by thousands of engineers, you have to make concessions. There is no place for "rockstar programming": everything must be, in a sense, bland, so that it blends seamlessly into the work of thousands of others.

Not that I disagree with your real point about writing maintainable code rather than "clever" code, but if you have a single codebase that is maintained by thousands of engineers then I would argue that you're probably doing something horribly wrong already, and using exceptions is hardly exclusive to so-called rockstars. I don't really understand organisations that still use C++ in 2014 but then knock out such funda…

I agree that using exception is hardly noteworthy these days, but consider that in the context of a codebase that has evolved for more than a decade. I guess, ten years ago, "let's not use exceptions; they aren't worth it" was more justifiable.

In any case, the decision was made, and we have millions of LOC where every single API is built with the assumption "No exceptions here." In that context, introducing exceptions seems suddenly a lot more trouble than its worth. Well, YMMV, and in any case I'm not a decision maker so what do I know.

* BTW, I think "a single codebase maintained by thousands of engineers" is the single best thing I found in Google, as it opens up infinite possibility of learning new tricks, new APIs, and sometimes new projects. (Of course, everybody complains that every API is implemented at least three times, but imagine how worse it would have been if every project had its own codebase.)