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

261–270 of 353 posts

Re: We have C++14

#261

Post by ksk »

Guthur wrote: post #216
mmaldacker wrote: post #210

Earlier quoted context omitted.

C++ is 35 years old and predates Haskell and many other "modern" languages like Java, C#, Python, ... So yes, compared to what C++ was originally, it has become modern.

My point is that none of the features are modern. Comparing a later version of language to an earlier one to measure modernism seems rather pointless.

>Comparing a later version of language to an earlier one to measure modernism seems rather pointless.

C++ is a production ready systems language, not a theoretical CS research paper. How do you propose we define modern in this context then? As I'm sure you're aware, it takes years to vet design features, debate whether they can be implemented, whether they affect performance, whether they have unintended side-effects, whether they break existing code, etc. 'Modern' concepts are already old by then. Also, sometimes features can't be added to a language because of practical real-world issues that have nothing to do with the language itself. (e.g. longer compile times).

I don't see anything particularly wrong with calling a language modern as it adopts features. Certainly, I would agree that one should not then claim the language to be modern in the sense of cutting edge research.

Re: We have C++14

#262

Post by tfinniga »

pkolaczk wrote: post #245
claudius wrote: post #224

Earlier quoted context omitted.

> 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. Yet a well written implementation in C++ will still be faster than an equally well-written implementation in, say, Python or Haskell or whatever. Not in an asymptotic sense, but easily by a factor ranging between two and 200. Fo…

Comparing to Python or Haskell, maybe you're right, but not to CLR-based or JVM-based statically typed languages. Very often the differences between Java/C# and C++ are the same order of magnitude as differences between various C++ compilers. The mythological C++ performance is often overstated (there are some performance advantages in C++ but they are rarely big enough to justify language choice).

I think C++ is justified when you're constrained by CPU, RAM, or other resources. That is, if the limiting factor is development speed, or network traffic, or waiting for user input, then C++ probably isn't going to be worth it.

But if in your problem area you can get a competitive advantage by being faster, using less memory, or tightly controlling other resources, then C++ is probably the right choice. If you really need it, you can use some inline assembly too.

For example, look at a VM's JIT compiler: it needs to capture a profile from a running application, analyze hotspots in that profile, recompile those on the fly to native code, and coordinate with the VM to swap that out on the fly. The more time and memory that is used to do all this, the slower every application on the VM will run. Since there's a very constrained environment, C++ is a good choice for JIT compilers.

And if you look at the CLR/VES or JVM, they are indeed written in C++.

Re: We have C++14

#263

Post by deong »

vidarh wrote: post #212
72deluxe wrote: post #205

Earlier quoted context omitted.

Eh? How do you mean that?

Presumably that it's nothing new . The term RAII dates to the mid to late 80's sometime, and you could hardly find any book about C++ from the 90's onwards that wouldn't be espousing RAII as the One True Way. RAII has been with C++ almost from the beginning.

Yes, but "modern" doesn't imply that no feature is older than Twitter. "Modern C++" refers to the way that C++ is written today, and some of that is new additions to the language, some has been there for ages.

Re: We have C++14

#264

Post by bstamour »

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.

Very few people care about any kind of computing - they care about the end result. Between embedded systems, servers and systems programs, and infrastructure, the modern world basically runs on C and C++.

Re: We have C++14

#265

Post by maxlybbert »

masklinn wrote: post #246
maxlybbert wrote: post #188

Earlier quoted context omitted.

UTF-32 means each code point takes up one char32_t. There are no surrogate pairs. However, it is true that you still have to deal with combining characters, normalization, etc. So it doesn't solve all of your problems, but it does avoid simple goofiness ( http://blog.coverity.com/2014/04/09/why-utf-16/ ). You still have to use libraries to do anything non-trivial.

Right. So while UTF-16 is a terrible encoding and there is very little reason to use it, UTF-32 is little better. Use UTF-8.

Like I said, I'm very lonely. My only consolation is that every project I've seen that says "use UTF-8 and be careful not to do goofy things (like running a string through the encoder twice, or passing a string to old C string functions that aren't Unicode aware, or assuming each character takes one byte), without exception, constantly finds those goofy mistakes in their code. Being careful is not enough.

UTF-8 for strings on disk, yes. But UTF-8 for in-memory strings has a long track record of being much harder to actually do correctly.

Re: We have C++14

#266

Post by eropple »

stinos wrote: post #194
eropple wrote: post #152

Earlier quoted context omitted.

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

While a bit harsh sounding, this is actually spot on. What I write nowadays vs 5 years ago: hard to believe it is the same laguage.

Exactly. I only write greenfield C++ and I dig it a whole bunch.

Re: We have C++14

#267

Post by maxlybbert »

tomp wrote: post #222
pjmlp wrote: post #198

Earlier quoted context omitted.

The way all those languages are used together. Not writing modern C++ means: - writing C++ as if it was plain C - doing OO programming with big object graphs - manual memory management - not using the standard containers and algorithms - writing functor objects

How can you not use manual memory management in C++? Say you're writing a compiler, which uses a quite complex, possibly circular, graph structure of objects for its AST representation. You can't use SharedPtrs (cycles), can't use UniquePtrs (sharing of graph nodes), can't use RAII (unpredictable lifetime). I see no better solution than a GC.

Even Stroustrup says that there are times garbage collection is the right solution. But, some people are surprised that there are times it isn't needed, and that garbage collection always brings the burden on unordered finalization (e.g., it's possible for an object's members to be finalized before the object, so finalizes must be written in a way that assumes very little about what is valid regarding data members).

Re: We have C++14

#268

Post by deong »

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…

I would also say that D did itself irreparable harm with the whole v1-v2 standard library debacle. Right when it was receiving the most attention, it came right out and said to anyone who might have considered it, "we have two incompatible versions of the standard library: one which we don't support anymore and one you can't use yet."

Re: We have C++14

#269

Post by loup-vaillant »

jnbiche wrote: post #240
PaulFreund wrote: post #217

Earlier quoted context omitted.

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.

Ordinary C++ with good old RAII do use something akin to garbage collection: many classes, when constructed, allocate memory on the heap, then free that memory when they fall out of scope.

Malloc() and free() aren't exactly predictable. If you really want guarantees, you need to write your own custom allocator, and if you don't need those guarantees, garbage collection is probably enough for your purposes.

Basically, if you're using C++ without real manual management, with custom allocators, pools, and all, you probably didn't need C++ in the first place.

Re: We have C++14

#270

Post by deong »

pkolaczk wrote: post #245
claudius wrote: post #224

Earlier quoted context omitted.

> 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. Yet a well written implementation in C++ will still be faster than an equally well-written implementation in, say, Python or Haskell or whatever. Not in an asymptotic sense, but easily by a factor ranging between two and 200. Fo…

Comparing to Python or Haskell, maybe you're right, but not to CLR-based or JVM-based statically typed languages. Very often the differences between Java/C# and C++ are the same order of magnitude as differences between various C++ compilers. The mythological C++ performance is often overstated (there are some performance advantages in C++ but they are rarely big enough to justify language choice).

An order of magnitude is a hell of a lot. I did some extensive comparisons of C++, Java, and C# back when I was working on my dissertation. Admittedly, this was about 10 years ago now, but at the time, the best I could get with Java was about a factor of 2.5 slower than C++. C# was similar, but I don't recall the specifics now.

When you read a language shootout, a lot of times a factor of 2-2.5 times slower than C or C++ is considered to be "good enough". If you get your Clojure code that fast, everyone calls it a day. For me, a typical run of my experiments took about 3 weeks on (I think) a Core 2 Quad using all four cores. So in the best optimized Java I could find, that would have been about 5 extra weeks spent waiting around for results, and I had several cycles like that. All told, I imagine it would have added a year to my work.

I'm not necessarily picking on you here. You did say "rarely", not "never". But I don't think a lot of people are aware of how common it is for a factor of two to be a complete deal-breaker.

Post reply on HN