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

181–190 of 353 posts

Re: We have C++14

#181

Post by Havvy »

adamnemecek wrote: post #65
_delirium wrote: post #50

Earlier quoted context omitted.

Fairly common programming language convention as well. I believe FORTRAN 66 and ALGOL 68 were the first standards widely referred to with a revision year. More recent examples include Fortran 90 (no more caps!) and C99.

I agree but it seems like newer languages adopted the 1.0, 2.0 versioning scheme so it might throw some people off.

Not just new languages. Java is also versioned from Java 1.0 to 1.1 to 1.2 ... 1.8, with recent versions dropping the "1." because they never will have a true "2.0" release.

Re: We have C++14

#182

Post by microtonal »

CountSessine wrote: post #175
zxcdw wrote: post #159

Earlier quoted context omitted.

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

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 time it does not have the ecosystem.

Go succeeded because of Google's deep pockets and, perhaps more importantly, because it filled a large niche that even the authors did not anticipate: a faster language for Python and Ruby aficionados.

Re: We have C++14

#183

Post by microtonal »

Mister_Snuggles wrote: post #148
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…

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

* Nearly functional, STL-driven C++. In this code you see nearly no loops at all, is the control structure.

* Template-driven programming, with policy classes, dozens of specializations, only header files.

Etc. Java does not have the legacy to 'embed' another language. Java does not do multiple inheritance, avoiding heavy-inheritance-based projects, Java does not claim to be a semi-functional language (though Java 8 brings Java closer in that direction), and Java does not provide a turing-complete template language that is a world on its own.

Re: We have C++14

#184

Post by bad_user »

deathanatos wrote: post #125
cletus wrote: post #91

I've started getting back into C++ after many years away and it's all coming back to me. Now of course it's C++11, which does have some nice features, but really I think we've reached the point where we need to start again (downvote away). Let me give you an example: I recently came across some code that was written years ago that has two size types: one 32/64 bit signed and the other 32 bit unsigned. This creates a…

> code that was written years ago that has two size types: one 32/64 bit signed and the other 32 bit unsigned. This creates a bunch of issues when compiled on 32 and 64 bit architectures and there is a substantial amount of effort to clean it up. Such things happen whenever an invalid assumption that is commonly true becomes not so commonly true, such as the 32-bit to 64-bit migration. That said, C/C++ provides you t…

There's no such thing as a well defined locking order - a statement that should scream the fact that locks are not composable. Good luck documenting it in the API or in making other developers pay attention.

The problems are even worse than with manual memory management, since there you often get away with RAII. Say a function call is returning some sort of list, or some other data structure. Was the producer operating on another thread? Was that data structure signaled to other consumers as well? Can you modify it without locking?

To make matters worse, locking is extremely inefficient, it limits the possible parallelism, throughput and vertical scalability and suddenly you start thinking of not protecting reads, since shared reads should be parallelizable, right? And so you need to look at alternative means of synchronization and then suddenly you end up reasoning about happens-before relationship arising from usage of memory fences, non-blocking algorithms and single producer / multiple consumers scenarios. And then you discover that C++ doesn't have a strong memory model to speak about and that at least before C++11 it was all platform dependent.

Of course, I like this state of things, since my favorite platform (not C++) has a better memory model and plenty of higher level abstractions built on top, like actors, CSP, ring buffers, futures, Rx, iteratees, immutable data-structures, etc... but yeah, people able to reason about concurrency are also avoiding it like the plague.

Re: We have C++14

#185

Post by microtonal »

pmelendez wrote: post #66
ajuc wrote: post #39

Earlier quoted context omitted.

I don't know which world I'm from. I mostly program (for money) in java nowadays, but I also did C++ for money for like 6 years, and I knew C years before. And mostly I've learnt programming on turbo basic and turbo pascal. But never had to do system programming. Also I don't think it's that big of an achievement to understand C. Despite its flaws it's very simple language, very different from C++. To the point - you…

>"To the point - you could ensure that compiler can de-virtualize your usage of structure (or class if you will) by adding "nonvirtual" to every method it implements or derives." Think it in this way. Many respectable people has been making a case to avoid inheritance[1][2]. What you are proposing would actually be an incentive to them. I don't know about you but the amount of functions that I actually override in my…

Many respectable people has been making a case to avoid inheritance[1][2].

Unfortunately, class inheritance is the only way to create the equivalent of an interface or (Scala-type) trait in C++. So, even if you avoid class inheritance in general (which is a good thing IMO), you still end up doing inheritance if you want run-time polymorphism in the form of abstract classes or abstract base classes.

Re: We have C++14

#186

Post by masklinn »

maxlybbert wrote: post #150
nly wrote: post #99

Earlier quoted context omitted.

UTF-16 has surrogate pairs as well. It's the worst of both worlds.

I prefer UTF-32, but I'm very lonely. The benefit with UTF-16 is that you can't accidentally pass a string to, say, strlen(). But, yes, people will forget that not all Unicode code points fit in 16 bits, and won't test with the right kind of input to find out that they've done it wrong. So errors can still creep in; but I will continue to argue that those errors are less common because the fact that you're dealing wi…

> I prefer UTF-32, but I'm very lonely.

I'm not sure why you'd prefer UTF-32, it doesn't make correct text manipulations any easier, but — much like UTF-16 — it does make incorrect assumptions and text manipulations much easier.

Re: We have C++14

#187

Post by jonstewart »

sillysaurus3 wrote: post #164
eropple wrote: post #151

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

Yes, RAII is the only way to make an exception-safe class. Good luck doing it. It's not easy. I know; I've tried. There are all kinds of corner cases and special considerations that you have to take into account. People have written huge tomes about that exact topic detailing exactly why it's a hard problem and why you're probably not going to solve it correctly by accident. You're far more likely to introduce a memo…

What were these corner cases and special considerations you ran into?

I wouldn't call Herb Sutter's _Exceptional C++_ a huge tome and it seems to be the standard treatment of exception safety.

Re: We have C++14

#188

Post by maxlybbert »

masklinn wrote: post #186
maxlybbert wrote: post #150

Earlier quoted context omitted.

I prefer UTF-32, but I'm very lonely. The benefit with UTF-16 is that you can't accidentally pass a string to, say, strlen(). But, yes, people will forget that not all Unicode code points fit in 16 bits, and won't test with the right kind of input to find out that they've done it wrong. So errors can still creep in; but I will continue to argue that those errors are less common because the fact that you're dealing wi…

> I prefer UTF-32, but I'm very lonely. I'm not sure why you'd prefer UTF-32, it doesn't make correct text manipulations any easier, but — much like UTF-16 — it does make incorrect assumptions and text manipulations much easier.

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.

Re: We have C++14

#189

Post by pjmlp »

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…

Given the Mesa/Cedar system a Xerox PARC, Oberon at Swiss Federal Institute of Technology and Modula-3/SPIN at Olivetti, doing OS work in GC enabled systems programming languages is quite possible.

The problem is how to move OS vendors away from C's influence.

Re: We have C++14

#190

Post by pjmlp »

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…

> Rust, Go, and others will be there to fill in the gap in a much better, saner, safer, maintainable

For business applications? Sure.

For system programming?

Only if they get an OS vendor godfather that pushes the language into their SDK, like any other systems programming language that got widespread use.

Post reply on HN