C++11 Makes Competitors Go Rusty • Hacker News Board

Re: C++11 Makes Competitors Go Rusty

#11

Post by scott_s » Wed, Feb 01, 2012, 9:22 PM UTC

I like and use C++. It fits my requirements of allowing high performance but still having rich abstractions. I also like most of the additions in C++11, and I look forward to using them.

But, there is a valid argument for using a newer language that has nothing to do with the language itself: the ancient include, compile and link process. Having to do the #ifndef/#define/#endif dance in every header file I write is a reminder of this fact. That hack exists because 40 years ago, there was no concept of package management. I feel the same way when I get linker errors that require me to unmangle my class names to figure out what's visible where.

Re: C++11 Makes Competitors Go Rusty

#12

Post by [deleted] » Wed, Feb 01, 2012, 9:22 PM UTC

[deleted]

Re: C++11 Makes Competitors Go Rusty

#13

Post by ComputerGuru » Wed, Feb 01, 2012, 9:30 PM UTC

A couple of nitpicks:

C++/Tr1 has also solved many of the same problems without needing a new compiler

Not true. While many of the boost/tr1/c++0x features are introduced via new headers, there are many compiler-level changes, and that's why you need to use the latest versions of clang/g++/msvc/icc to take advantage of them. Things like r-value references just can't be done without a "new" compiler.

My other nitpick is his code sample: I've been write C++ for years but I must say his code sample made my eyes bleed. It's rather far from being demonstrative proof that C++ is elegant and need not be replaced. He should have just imported all the namespaces and been done with it, for starters, in this trivial sample.

Re: C++11 Makes Competitors Go Rusty

#14

Post by strlen » Wed, Feb 01, 2012, 9:30 PM UTC

I (shrug) enjoy programming in C++11 and like many concepts in it.

However, there are concepts in Go and Rust that are salient and stand on their own: typeclasses in Go and Rust (concepts, unfortunately, were left out of C++11), rust making std::unique_ptr a language feature and support for pattern matching, etc...

While I like support for atomics, memory model, etc.. in C++11, concurrency is still a library in C++. Go and Rust take different approaches to concurrency, but they do make it a _language_ feature which is substantially different.

In short, I hate to bible-thump Paul Graham's article, but this article does remind me of the "blub paradox".

tl;dr I like C++11, but I am glad there are other options (most importantly, Go, and Rust) being developed for userland systems programming.

Re: C++11 Makes Competitors Go Rusty

#15

Post by SamReidHughes » Wed, Feb 01, 2012, 9:36 PM UTC

How many people here who complain about the language being too complicated have actually been harmed by the presence of features in the language? If you want an advanced programming language, it's going to be complicated. Without garbage collection, it will be even more complicated. Almost every feature that exists in C++ exists for a reason, and every one that was added or removed in C++11 was added or removed for good reasons.

If you want a less complicated language than C++11, other than some low-hanging white noise inherited from C, you'll probably have to give up safety, convenience, performance, or exceptions.

Re: C++11 Makes Competitors Go Rusty

#16

Post by drivebyacct2 » Wed, Feb 01, 2012, 9:41 PM UTC

SamReidHughes wrote: post #15

How many people here who complain about the language being too complicated have actually been harmed by the presence of features in the language? If you want an advanced programming language, it's going to be complicated. Without garbage collection, it will be even more complicated. Almost every feature that exists in C++ exists for a reason, and every one that was added or removed in C++11 was added or removed for g…

No offense, but have you spent much time with Go or Rust? In most cases Go's performance difference isn't extremely divergent from C++'s and it preserves safety and enhances convenience, exceptions and adds concurrency.

Re: C++11 Makes Competitors Go Rusty

#17

Post by ori_b » Wed, Feb 01, 2012, 9:46 PM UTC

As soon as he said "both Google and Mozilla have been playing the 'new object oriented native language' game recently", I stopped reading.

If you aren't sufficiently familiar with either language to know that neither of them is particularly object oriented, at least in the traditional sense, then you probably shouldn't be writing about them.

Re: C++11 Makes Competitors Go Rusty

#18

Post by munificent » Wed, Feb 01, 2012, 9:50 PM UTC

scott_s wrote: post #11

I like and use C++. It fits my requirements of allowing high performance but still having rich abstractions. I also like most of the additions in C++11, and I look forward to using them. But, there is a valid argument for using a newer language that has nothing to do with the language itself: the ancient include, compile and link process. Having to do the #ifndef/#define/#endif dance in every header file I write is a…

> Having to do the #ifndef/#define/#endif dance in every header file I write

I'm just using "#pragma once" in my current hobby C++ project. I understand pragmas are living in sin, but is there any reason I shouldn't use them?

Re: C++11 Makes Competitors Go Rusty

#19

Post by Arelius » Wed, Feb 01, 2012, 9:52 PM UTC

strlen wrote: post #14

I (shrug) enjoy programming in C++11 and like many concepts in it. However, there are concepts in Go and Rust that are salient and stand on their own: typeclasses in Go and Rust (concepts, unfortunately, were left out of C++11), rust making std::unique_ptr a language feature and support for pattern matching, etc... While I like support for atomics, memory model, etc.. in C++11, concurrency is still a library in C++.…

I'd like to note that rust does allow mutable shared state, but just in an "unsafe" context, since it is in fact, unsafe.

Re: C++11 Makes Competitors Go Rusty

#20

Post by scott_s » Wed, Feb 01, 2012, 10:00 PM UTC

munificent wrote: post #18

scott_s wrote: post #11

I like and use C++. It fits my requirements of allowing high performance but still having rich abstractions. I also like most of the additions in C++11, and I look forward to using them. But, there is a valid argument for using a newer language that has nothing to do with the language itself: the ancient include, compile and link process. Having to do the #ifndef/#define/#endif dance in every header file I write is a…

> Having to do the #ifndef/#define/#endif dance in every header file I write I'm just using "#pragma once" in my current hobby C++ project. I understand pragmas are living in sin, but is there any reason I shouldn't use them?

It's not part of the C++ standard, so you're relying on a compiler extension. In theory, your code could blowup if you tried a different compiler, but in practice, most compilers you would use implement it. In general, pragmas are for compiler extensions - that is, things not defined in the language spec.