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

221–230 of 353 posts

Re: We have C++14

#221

Post by tomp »

claudius wrote: post #199
Guthur wrote: post #196

I see a lot of discussion around C++ becoming modern. I would like to know which features are actually modern? Is it lambdas? been around for literally decades. Is it type deduction? again been around for quite some time, far better type inference has been available in the likes of Haskell for quite some time. Is it addition of a particular threading model to the standard? this has always been available via some form…

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

Lightweight threads are missing, as are tail calls. Both (especially the second) prevent C/C++ from being a viable target for functional compilers.

Re: We have C++14

#222

Post by tomp »

pjmlp wrote: post #198
Guthur wrote: post #196

I see a lot of discussion around C++ becoming modern. I would like to know which features are actually modern? Is it lambdas? been around for literally decades. Is it type deduction? again been around for quite some time, far better type inference has been available in the likes of Haskell for quite some time. Is it addition of a particular threading model to the standard? this has always been available via some form…

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.

Re: We have C++14

#223

Post by yaantc »

helmut_hed wrote: post #174
millstone wrote: post #141

Earlier quoted context omitted.

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.

Early C++ implementations used setjmp/longjmp to support exceptions, and then each try block would lead to settting the setjmp context. So there definitely was a runtime overhead, even with no exceptions thrown.

I don't think it's very popular today. Modern implementation don't use this anymore and do not incur run-time overhead when no exception are thrown. However, they do incur some space overhead: the implementation need to maintain pretty large tables to know what needs to be unwound (which destructors to call, in which order) when an exception is thrown. In most environment this space overhead shouldn't be a problem (PC, server). But for embedded development it may be a problem. And then disabling exception to save space brings back the issues with error checking (or the lack of it...).

For more details, search for C++ exception implementation and you should find all the info you need. Or look into G++ documentation for example, this topic is covered somewhere.

Re: We have C++14

#224

Post by claudius »

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…

> 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. For me, this can be the difference between waiting a couple of weeks or half a year for some computation to complete :)

> Just saying C++ is fast does not make programs written in C++ actually fast.

Of course not, but C++ makes it possible for programs written in C++ to be fast.

Re: We have C++14

#225

Post by mhd »

jsmeaton wrote: post #59
tdees40 wrote: post #51

Earlier quoted context omitted.

Oh my goodness, yes. The HN crowd probably doesn't appreciate the extent to which people who sling C++ at BigCorp are limited by the rules the company sets.

It's not just C++ either. "What do you mean you want to use LINQ (in C#) ? No one understands that rubbish".

"We haven't vetted anything other than Java 1.4 on our BigAutoCorp PCs, so if you want to write a desktop app..."

Re: We have C++14

#226

Post by claudius »

tomp wrote: post #221
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…

Lightweight threads are missing, as are tail calls. Both (especially the second) prevent C/C++ from being a viable target for functional compilers.

Agreed on guaranteed tail call optimisation, but it seems[0] that it is at least possible to get it in some cases on some compilers. It seems that calling dtors after the return (somewhat obviously) makes it impossible to do it, although appropriate scoping might help. I however didn’t play around with it, merely rephrasing what [0] wrote.

I’m not sure about threads (and how light/heavy those currently in C++11 are).

[0] https://stackoverflow.com/questions/34125/which-if-any-c-com...

Re: We have C++14

#227

Post by stinos »

Guthur wrote: post #196

I see a lot of discussion around C++ becoming modern. I would like to know which features are actually modern? Is it lambdas? been around for literally decades. Is it type deduction? again been around for quite some time, far better type inference has been available in the likes of Haskell for quite some time. Is it addition of a particular threading model to the standard? this has always been available via some form…

I would like to know which features are actually modern?

Close to none of course, but that isn't the point AFAIK.

The point is all of them have now been added, hence the 'modern' connotation, and another part of the point is that C++ now even more is a language rather flawlessly combining all those paradigms.

Re: We have C++14

#228

Post by jokoon »

Are modules already kind of unofficially supported, or can they be enabled ? On what platforms ?

I'm trying to make a C++ game with fat libraries like Ogre3D and bullet3D, often on a laptop, and that would really be fantastic to not wait 10s or more each time I edit a header.

I've seen a presentation, basically modules would decrease compile time from M x N to M + N.

Re: We have C++14

#229

Post by pjmlp »

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.

Why can't you use them? Lots of compilers written in C++ use them.

Ever heard of weak_ptr?

Re: We have C++14

#230

Post by jahnu »

jsmeaton wrote: post #59
tdees40 wrote: post #51

Earlier quoted context omitted.

Oh my goodness, yes. The HN crowd probably doesn't appreciate the extent to which people who sling C++ at BigCorp are limited by the rules the company sets.

It's not just C++ either. "What do you mean you want to use LINQ (in C#) ? No one understands that rubbish".

And should Go or Rust achieve widespread adoption the same thing will happen to them. So the point is moot.
Post reply on HN