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

241–250 of 353 posts

Re: We have C++14

#241

Post by jnbiche »

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…

>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 in learning Rust (and it's a significant investment).

0. http://www.rust-ci.org/projects/

Re: We have C++14

#242

Post by jnbiche »

LeonidasXIV wrote: post #239
pcwalton wrote: post #193

Earlier quoted context omitted.

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

Rust error messages are perhaps the best thing about the compiler. For me, it's a new experience altogether. Instead of having to Google obscure error messages, Rust error messages actually tell me how to solve the problem!

Re: We have C++14

#243

Post by lmm »

chetanahuja wrote: post #203
sillysaurus3 wrote: post #164

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…

> you can refuse to catch or throw exceptions for 99% of your (millions of lines) of code and still end up with a very large, stable code base running a large portion of the internet.

The point is that these features are infectious. If you don't want to throw exceptions, how do you handle a failure in a constructor? And then if you abandon constructors, other C++ features are unusable without them. And so on.

Re: We have C++14

#244

Post by lmm »

Vaskivo wrote: post #237
microtonal wrote: post #183

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…

I thought much like that (and was a huge Python fan) until I found Scala. There are cases people cite as "more than one way to do it", but they're usually superficial syntax differences. You do have to choose between passing around objects and passing around functions, but that's a choice you make in Python as well. It can handle high-performance calculation or high-level scripting, but it never feels like these are separate languages; it has a bunch of orthogonal features but any two of them combine in exactly the way you would expect (and often that combination forms something very useful).

Re: We have C++14

#245

Post by pkolaczk »

claudius wrote: post #224
Guthur wrote: post #220

Earlier quoted context omitted.

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

Re: We have C++14

#246

Post by masklinn »

maxlybbert wrote: post #188
masklinn wrote: post #186

Earlier quoted context omitted.

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

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.

Re: We have C++14

#247

Post by pkolaczk »

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.

I think we should start using the term "modern Java" for writing Java with lambdas, or "modern PHP" to write PHP with OOP and exceptions. :D

Re: We have C++14

#248

Post by Pacabel »

jnbiche wrote: post #241
microtonal wrote: post #182

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…

>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 again with a newer version of the language/implementation, perhaps a very short time after the code was initially written.

2. The Rust compiler or other tooling is crashing or failing in some way while compiling these projects.

3. The projects themselves aren't being maintained on an ongoing basis.

4. The projects themselves were never building properly in the first place.

5. The projects' developers are targeting different versions of Rust (which probably means there will be interoperability problems for anyone trying to use them in a larger projects, especially when it comes to libraries).

And while there may be a lot of these projects, I've never found the quality to be very good. 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.

Those factors are disconcerting, especially for somebody who wants to use Rust for serious product development. It does no good if there are hundreds of libraries available for use, but half of them don't even build, and the ones that do are very incomplete.

Re: We have C++14

#249

Post by kelvin0 »

72deluxe wrote: post #206
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 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.

Re: We have C++14

#250

Post by pkolaczk »

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…

"but apart from that I can’t really think of anything that may or may not be missing"

* Hygienic macro system. * Pattern matching. * Strong generic type system. * Persistent containers. * Lockless data structures. * Memory-safety. * Null-safety. * Reflection. * Dynamic/variant types. * Modules. * ...

Post reply on HN