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

We have C++14

isocpp.org

Post reply on HN
Print view View original

151–160 of 353 posts

Re: We have C++14

#151

Post by eropple »

sillysaurus3 wrote: post #118
dicroce wrote: post #112

Earlier quoted context omitted.

Me too. RAII ftw!

Good luck making your RAII class exception safe. It's extremely difficult, to the point that writing a simple class becomes an hours-long exercise in reasoning about exceptions. And of course, if you admit that exceptions aren't worth worrying about, then you'll start to question the entire "C++ way," which usually ends in disillusionment. Alternatively, instead of disillusionment, you may still kind of enjoy C++. Bu…

> Good luck making your RAII class exception safe. It's extremely difficult, to the point that writing a simple class becomes an hours-long exercise in reasoning about exceptions.

In my experience, this is literally backwards. RAII is the only way to make exception-safe classes that aren't a gigantic mess.

> It doesn't seem like C++ solves the right problems, even with the new dialects. Programming languages should be convenient to think in.

No, some progrmaming languages should be convenient to think in. Some need to be uncompromisingly fast. C++ is in the latter set and nothing more convenient to think in is faster.

Re: We have C++14

#152

Post by eropple »

PopsiclePete wrote: post #98
daenz wrote: post #12

When I started writing C++ around 5 years ago, I had a perception that it was a language that is "on its way out". As I learned more and more of it, I've been super impressed at how modern it is becoming, and how it is adapting to overcome its perceived flaws. It is becoming a killer language to me: blazing fast, modern, ubiquitous, stable, and expressive.

Too bad it's a mirage. No, really. "Modern C++" doesn't exist outside of blog posts, books, and tutorials. Real-world C++ is an array of sometimes mututally-exclusive dialects, patterns, rules, sub-dialects. Reading MFC is nothing like reading Qt which is nothing like WxWidgets which is nothing like Boost which is something (but not quite like) the STL which is way different from Apache C++ libs which is way differen…

> "Modern C++" doesn't exist outside of blog posts, books, and tutorials.

That you aren't used to doing greenfield development doesn't mean others are likewise impaired.

Re: We have C++14

#153

Post by StephanTLavavej »

spott wrote: post #7
jastanton wrote: post #2

I apologize if this is ignorant, but how is C++ versioned?

what do you mean? C++ is a language designed by committee. C++14 is meant as a "tock" release, fixing some of the things in the C++11 "tick" release. ("tick" releases are larger, and "tock releases fix some of the problems in the "tick" release). Compilers then attempt to implement the standard, and have their own versioning system.

Traditionally, "ticks" are small, and "tocks" are big. See https://en.wikipedia.org/wiki/Intel_Tick-Tock .

Re: We have C++14

#154

Post by maxlybbert »

ajuc wrote: post #20
astrodust wrote: post #14

Earlier quoted context omitted.

In languages like C++ "verbose" means "specific and obvious" which is something you want to have when writing certain kinds of code. It's annoying, it's a drag on productivity, but in the long run it's arguably necessary. Some other languages which reduce verbosity by making more things implicit make it harder to understand what's actually going on behind the scenes. You lose a lot of information.

A lot of C++ verbosity comes simply from bad defaults. Const and virtual should be the default for example, not the other way around. Would stop the virtual destructor ommision problem, and if you need efficiency you could make destructors non-virtual. Also in the "hiding stuff behind the scenes" department C++ is quite bad. SomeClass someMethod(SomeClass a, SomeClass b) { ... } is doing a lot behind the scenes. Code…

I find it amazing that people seem to believe it should be possible to understand a large code base by looking at single lines in isolation.

Re: We have C++14

#155

Post by StephanTLavavej »

pbsd wrote: post #64
azoth_ wrote: post #53

Earlier quoted context omitted.

In modern C++ these loops could alternatively be written as: std::vector myVec; for( auto it = myVec.begin(); it != myVec.end(); ++it ); or if you prefer the external begin/end syntax: for( auto it = std::begin(myVec); it != std::end(myVec); ++it ); or the most succinct (replace && by & if writing): for( auto && item : myVec );

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

Re: We have C++14

#156

Post by bodyfour »

millstone wrote: post #146
bodyfour wrote: post #144

Earlier quoted context omitted.

Depends on if you need to gracefully handle malloc failures or not. Otherwise any write operation on an STL type (like appending to a string) will potentially throw an exception that you need to care about. In the C world this is extremely arduous since need to bubble the allocation-failure down through every level of code, adding cleanup to just about every function call. If you're using C++ and RAII you can just ca…

Do you work on systems that handle this? I'd like to know if any still exist. In modern systems I'm familiar with, malloc only reports failure on bogus inputs like -1, or address space exhaustion. Your process is likely to be killed before exhausting your address space (think iOS OOM handling, or Linux overcommit), especially on 64 bit. So checking for allocation success just isn't that useful any more.

As @jjnoakes points out, you'll get malloc()==NULL if your ulimits are set. For a long-running program you definitely want to have a ulimit that will kick in before the OOM killer does.

Even in the absence of the OOM killer (i.e. the old days) you had to do this -- otherwise the machine might be swapping itself unresponsive for ages before you ever get malloc()==NULL

Re: We have C++14

#157

Post by Roboprog »

dfan wrote: post #32
bnejad wrote: post #25

Can anyone recommend a book on modern C++?

Scott Meyers' Effective Modern C++ will be required reading once it's released in October. Until then (and even after), Stroustrup's The C++ Programming Language (4th edition) is the canonical resource. It's a reference but is also intended to be read.

Ironically, it was (the first edition of, I believe) Meyer's "Effective C++" that made me question "WTF? Why does anybody use this???" (given that Turbo Pascal / Delphi, or Perl, actually were much easier to understand). Maybe C++ is usable now, but back in the late 90s, nobody that I respected used C++ - all the code I saw at work in C++ was by resume padding morons who wouldn't recognize polymorphism if it walked up and bit them in the ass. (the opinion being either use C, or a high level language, but not C++)

Not fair to judge the language by the fools that used it 15+ years ago, but I have no use for operator overloading, copy memory leaks and all the other C++ obfuscation.

C++ would probably benefit from a "lessons learned" do-over with a new name (as referenced elsewhere in the Perl 6 / Python 3 debacles)

Re: We have C++14

#158

Post by halfcat »

eropple wrote: post #151
sillysaurus3 wrote: post #118

Earlier quoted context omitted.

Good luck making your RAII class exception safe. It's extremely difficult, to the point that writing a simple class becomes an hours-long exercise in reasoning about exceptions. And of course, if you admit that exceptions aren't worth worrying about, then you'll start to question the entire "C++ way," which usually ends in disillusionment. Alternatively, instead of disillusionment, you may still kind of enjoy C++. Bu…

> Good luck making your RAII class exception safe. It's extremely difficult, to the point that writing a simple class becomes an hours-long exercise in reasoning about exceptions. In my experience, this is literally backwards. RAII is the only way to make exception-safe classes that aren't a gigantic mess. > It doesn't seem like C++ solves the right problems, even with the new dialects. Programming languages should b…

>Some need to be uncompromisingly fast. C++ is in the latter set and nothing more convenient to think in is faster.

Yes, and C++11/14 make significant strides toward being more convenient to think in as well, without compromising speed. In fact some improvements also improve speed in some cases.

Re: We have C++14

#159

Post by zxcdw »

Pacabel wrote: post #142
beefsack wrote: post #128

Earlier quoted context omitted.

I can understand the few controversial design choices in Go which limit it's use cases, but would be interested to hear why you claim Rust isn't saner than C++.

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 many of the language flaws which are inherent in C and C++, while still being competitive in performance and low-level control.

Re: We have C++14

#160

Post by enraged_camel »

davvid wrote: post #149
PopsiclePete wrote: post #98

Earlier quoted context omitted.

Too bad it's a mirage. No, really. "Modern C++" doesn't exist outside of blog posts, books, and tutorials. Real-world C++ is an array of sometimes mututally-exclusive dialects, patterns, rules, sub-dialects. Reading MFC is nothing like reading Qt which is nothing like WxWidgets which is nothing like Boost which is something (but not quite like) the STL which is way different from Apache C++ libs which is way differen…

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.
Post reply on HN