Live data from Hacker News

We have C++14

isocpp.org

251–260 of 353 posts

Re: We have C++14

#251

Earlier quoted context omitted.

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.

A large or well-known company merely using a programming language, and maybe even contributing back to it and its community, isn't the same as the company truly supporting or championing it.

What you describe is very different from, say, how Sun pushed Java, or Microsoft pushed C#, or how Apple will likely push Swift, or how a huge portion of the entire software industry pushed C and C++.

Facebook's Hack language is probably a much better example than D is of a language that they're actively supporting. It's a creation of theirs, rather than just a creation of somebody else's that they find useful in some limited cases.

Re: We have C++14

#252

Earlier quoted context omitted.

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

One core part of C++'s philosophy where it's very consistent is that you only pay for what you use and the performance guarantees (e.g., STL) are explicit.

Another consistent part of C++ is that it gives you absolute control over memory, both allocation and layout. It's really this control that makes C++ unbeatable in performance. The good VMs can JIT their languages to match CPU performance on small routines, but they can't match C++ when it comes to manipulating big, complicated data structures.

Re: We have C++14

#253

Earlier quoted context omitted.

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…

"Good luck doing it. It's not easy. I know; I've tried" Completely unsupported assertion (no pun) without evidence. Other people have tried it, and have succeeded. I could start listing all the software written in C++ that you use in your everyday life, perhaps 100's of times a day... but that'll quickly exhaust my word limit for this post. "That's why C++ is overly cumbersome unless you ignore most of its capabiliti…

> Exceptions are not "most of C++ capabilities".

To add to this point: There are C++ frameworks such as Qt who don't use exceptions at all! And what impressed most: When writing a Qt application, you don't even miss exceptions. You don't have to resort to C-style return value checking all over your code. How is that? It took me some time to figure this out, but I believe it is because Qt applies the "Null Object" pattern consequently - down to the deepest depth of their framework,

Re: We have C++14

#254

Earlier quoted context omitted.

I have furniture at home made of wood. Oddly, my table looks nothing like my broom handle, so does this mean that wood is a terrible choice for both items? "The industry would be better off without wood!!" Surely libraries in other languages have the same problem? They don't look anything like each other. wxWidgets and Qt look nothing like each other but it isn't a problem at all. The signalling mechanism / event han…

It`s the down vote pigeon, hitting randomly and savagely.

Sure is a vicious beast! Must have got into a bit of a flap. Pigeons have tiny brains don't they?

Re: We have C++14

#256

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.

Oh not again the GC argument.

D is the one true C++ without pretending being a superset of C. Rust is more modern than C++ and better in programming in the large. But D is really for low level programming and a good target for code generation. For me it is a good replacement for C++ and Delphi. It is even a good fit for areas touched by Java and C# like desktop and scientific apps. But it is not there yet because of lack of serious tooling and lack of bytecode but for the second disadvantage you earn performance. Nimrod for example could address this (with D as a code generation target).

Re: We have C++14

#257
post #189

Earlier quoted context omitted.

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.

Use micro-kernels.

Re: We have C++14

#258
C++ is suitable for development of cross mobile applications , since both iOS and Android tool chain has support for C++.

Re: We have C++14

#259

Earlier quoted context omitted.

>At the same time it [Rust] does not have the ecosystem Try watching new projects pop up at Rust CI [0] for a few days. With the possible exception of Node (which is not even a PL), I've never seen a language ecosystem grow this vast, and I'm a PL afficionado. I think in a year's time, the question of Rust's stability and ecosystem will be entirely moot. It's a tough wait meanwhile, but I'm still investing the time i…

Is Rust CI really the best evidence to use in this case? When I last looked at it, probably 40% to 50% of the projects listed had builds that were in the "failing" or "error" statuses. That indicates that one or more of at least a few things are happening: 1. The Rust language and its standard libraries are changing at a pace that results in previously-compiling code needing to be modified before it will compile agai…

>Many of them are extremely limited or incomplete. Many of them are little more than casual experimentation. Many of them are only developed by a single person, who often has appeared to have lost interest.

Yes, I completely agree, and this is an entirely normal part of the language ecosystem development cycle. Rust is at the tail end of the experimentation stage, and as it converges on 1.0, more people will undertake serious projects.

I'm not at all worried about the quality of Rust projects. I'm just happy to see so much enthusiasm. I have no doubt that all this enthusiasm will transfer into some powerful libraries as Rust continues to stabilize and reaches 1.0.

But yes, it's still to early to use Rust for production unless you're willing and able to write your own libraries.

Then again, the "batteries included" approach of Rust's standard library leaves not much to be desired outside of domain-specific libraries.

Re: We have C++14

#260
post #149

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…

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.

How much time/money did it take to be implemented? What is the maintenance cost? Which version of C++? What percentage was written from scratch? Does it run in a networked environment? These are the real questions.

Pharao Inc. built pyramids in ancient Egypt. It cost many lives of slaves but it was cheap them. Nowadays we make big buildings without slaves.

Post reply on HN