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

231–240 of 353 posts

Re: We have C++14

#231

Post by tfinniga »

Guthur wrote: post #220
claudius wrote: post #199

Earlier quoted context omitted.

> What is modern about any of features that have been added? Nothing. On the other hand, which features of a “modern” language are missing in C++ by now? Type deduction is still a bit less powerful than in Haskell, yes, but apart from that I can’t really think of anything that may or may not be missing. This in turn implies that C++ allows essentially any style of coding you may wish for at the moment while at the sa…

C++ is no faster than any other language, it's the code that is written which is measurable. The real wins in performance for real world applications are in terms of algorithmic complexity. A poorly implemented solution in C++ will still be slow, the language does not make it fast. Any micro optimization you can make with C++ will be an order magnitude less significant than O(log n) vs O(n). The likes of Janestreet w…

Is it possible to write C++ programs that are slower than their counterparts in other programming languages? Yes.

Is it possible to write programs in other languages that are just as fast as good C++ implementations? Often it is not.

That performance comes at a cost, it really depends on what your application is. Horses for courses.

Re: We have C++14

#232

Post by Zardoz84 »

microtonal wrote: post #182
CountSessine wrote: post #175

Earlier quoted context omitted.

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…

There are important differences: D threw away one of the most important features of C/C++ (for the target audience): usability of the language without a garbage collector. Also, Mozilla has much deeper pockets than Digital Mars. Still I agree with you that it is very likely that Rust will follow a parabolic trajectory. The advantages as perceived by the industry compared with C++11/14 will be too few. At the same tim…

Facebook have deep pockets ... Yep, Facebook is using D for some stuff.

Re: We have C++14

#233

Post by antimagic »

zanny wrote: post #47
pjungwir wrote: post #36

OT question: I was playing with some C over the weekend (not C++), trying to figure out how to handle Unicode in a way that would work on Mac, Linux, and Windows. Despite a couple hours googling and reading, I couldn't answer really basic stuff, like: - Do I use char* for strings? It sounds like wchar_t is 16 bits on some systems and 32 on others, so I should avoid it? - If I want to read & write UTF-8 files, how do…

Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the features you want. In C++ unicode is as simple as: string s = u8"This is always a utf8 string.";

Weeellll, your position is defensible if you're writing an application. If you're writing a library though, let me just let you know that every time I encounter a package with a C++ API, I want to drive stakes into the author's eyes, as compensation for the pain I'm about to experience.

Like it or not, C is the lingua franca of the programming world. Pretty much every other language out there provides C bindings, not C++ bindings. Which means that when your function exports something wonderful like smart pointers, my world just becomes painful.

Furthermore, in embedded environments, it can be challenging (to use a euphemism) to get source code debugging up and running. If your code is written in C, it's not so bad, non-optimised machine code generated from C tends to match the actual C code fairly closely, to the point that you can very nearly read it as easily as the original source. This is not true for C++, which means that every time something goes wrong in C++ code, I'm probably going to lose a week of my life inserting trace into the code, compiling, deploying to target, and running the test, ad infinitum. Not fun.

Even in the case where you're writing an application, I'm personally dubious about the benefits of C++. Write the application in a higher-level language, personally I like Javascript (JavaScriptCore) for this, but I've had good success with Ruby and lua as well. When you hit a performance bottleneck, push the performance sensitive code into C, and create bindings. As a bonus, your C code is now easily available to be used as a library from any other language, without inducing homicidal tendencies in the user.

Re: We have C++14

#234

Post by _pmf_ »

phkahler wrote: post #46

I'm a little afraid the language will go down hill from here. Too many versions - a committee dedicated to creating new versions of the language standard is going to do exactly that. Much like has happened with OpenGL.

> Too many versions - a committee dedicated to creating new versions of the language standard is going to do exactly that. Much like has happened with OpenGL.

The problem with OpenGL was that they tried to retrofit an API that assumed a certain underlying hardware model to modern (i.e. less than 15 year old) GPUs. It was impossible to do in any sane manner.

Re: We have C++14

#235

Post by cheery »

72deluxe wrote: post #207
enraged_camel wrote: post #160

Earlier quoted context omitted.

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.

Why do you need to be fashionable to be productive? Do people really ask what your finished software product is written in?

I wouldn't have expected this statement in context of C++. In my eyes, C++, java, C#, D are all object-oriented fashion statements.

Re: We have C++14

#236

Post by jmpeax »

Guthur wrote: post #220
claudius wrote: post #199

Earlier quoted context omitted.

> What is modern about any of features that have been added? Nothing. On the other hand, which features of a “modern” language are missing in C++ by now? Type deduction is still a bit less powerful than in Haskell, yes, but apart from that I can’t really think of anything that may or may not be missing. This in turn implies that C++ allows essentially any style of coding you may wish for at the moment while at the sa…

C++ is no faster than any other language, it's the code that is written which is measurable. The real wins in performance for real world applications are in terms of algorithmic complexity. A poorly implemented solution in C++ will still be slow, the language does not make it fast. Any micro optimization you can make with C++ will be an order magnitude less significant than O(log n) vs O(n). The likes of Janestreet w…

> Any micro optimization you can make with C++ will be an order magnitude less significant than O(log n) vs O(n)

Wrong. See (from about 46min): http://channel9.msdn.com/Events/Build/2014/2-661

Re: We have C++14

#237

Post by Vaskivo »

microtonal wrote: post #183
Mister_Snuggles wrote: post #148

Earlier quoted context omitted.

I think you could say the same thing about any language where there are big frameworks and libraries that handle a lot for you. In the Java world, a Java EE CRUD application is a LOT different than a Swing application that does the same thing. Likewise, a Python Django application is a completely different beast than a console application.

But there is less variation: Java provides only one paradigm (OO) and frameworks use different flavors of that: beans, POJOs, heavy classes, etc. In C++ you can have such variations, plus all the other paradigms, including: * C with classes (people programming in this style often still use C strings, do deletes and frees in destructors). * C++ as the full-blown OOP language, with extensive multiple inheritance hierar…

That's the problem I have with C++. It is a mish-mash of paradigms, features and techniques. It is not consistent in use-cases and philosophy (unless you count "all and everything" as use cases and philosophy).

As much as I try to find "my" general purpose language of choice, and forr all of my inertia in learning yet another programming language, I believe languages should have narrower scopes. And there should be more languages. Specialized for specific use-cases.

And, as a pythonista, the "you can do/use it in many different ways" just irks me.

Re: We have C++14

#238

Post by octopus »

72deluxe wrote: post #209
octopus wrote: post #166

Earlier quoted context omitted.

Try "A Tour of C++" by Bjarne Stroustroup it has less than 200 pages.

Or just get Stroustrup's "The C++ Programming Language" and read the intro bit - it covers the language in fleeting detail but then you still have the rest of the book to look at if you are having a hard time understanding the section at the beginning.

I have both, "The C++ Programming Language" as a physical book and "A Tour of C++" as an ebook. "A Tour of C++" is self contained.

Re: We have C++14

#239

Post by LeonidasXIV »

pcwalton wrote: post #193
CountSessine wrote: post #175

Earlier quoted context omitted.

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…

> Both have had compiler and standard library issues. What are the compiler/standard library issues with Rust? Sure, it's taken time to get to a high level of quality, but no language compiler and library is going to spring out of thin air fully complete. In particular, I'm confident that the Rust compiler is of high quality for its age, especially in the quality of the generated code.

> In particular, I'm confident that the Rust compiler is of high quality for its age

I'd like to concur. I've used the Rust 0.10 compiler and the only bug I encountered was that generating debug binaries was somehow broken. Apart from that, it was one of the smoothest experiences ever and the error messages are amazing.

Re: We have C++14

#240

Post by jnbiche »

PaulFreund wrote: post #217
stormbrew wrote: post #195

Earlier quoted context omitted.

Rust is really the only language that's actually targeting the same niche as C++ primarily occupies, system level programming where reasoning about memory management and performance is part of the actual work being done. Go, let alone others, simply do not allow you to do this. It shows a distinct lack of understanding of why people still use C or C++ to raise languages/environments like Go as viable alternatives.

Don't forget D

D is fine language and a pleasure to program in, but with it's required garbage collector, it's not really in the same niche as C/C++/Rust. I think the hallmark of this niche is the ability to run without a garbage collector penalty and the accompanying lack of determinism.
Post reply on HN