We have C++14 • Hacker News Board

Re: We have C++14

#281

Post by p0nce » Tue, Aug 19, 2014, 2:14 PM UTC

yongjik wrote: post #180

Silhouette wrote: post #131

Earlier quoted context omitted.

Not that I disagree with your real point about writing maintainable code rather than "clever" code, but if you have a single codebase that is maintained by thousands of engineers then I would argue that you're probably doing something horribly wrong already, and using exceptions is hardly exclusive to so-called rockstars. I don't really understand organisations that still use C++ in 2014 but then knock out such funda…

I agree that using exception is hardly noteworthy these days, but consider that in the context of a codebase that has evolved for more than a decade. I guess, ten years ago, "let's not use exceptions; they aren't worth it" was more justifiable. In any case, the decision was made, and we have millions of LOC where every single API is built with the assumption "No exceptions here." In that context, introducing exceptio…

Perhaps you would have less millions of LOC if you could reuse third-party libraries which happen to use exceptions?

Also no exceptions implies no failing constructors which is plain ugly as a constraint.

Re: We have C++14

#282

Post by exDM69 » Tue, Aug 19, 2014, 2:18 PM UTC

wfunction wrote: post #162

shmerl wrote: post #136

Earlier quoted context omitted.

You don't need to use the compiler from the distro to release for that distro. There is such thing as cross compilation after all. Most do it out of habit and because distros don't offer such services out of the box. But if you build the cross compiler, you can use the newest one even if the distro ships the older. For example I had a building machine running RHEL 5 which was building for both RHEL 5 and RHEL 6 while…

You say "if you build the cross-compiler" as though it's as simple as "if you cross the street". Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

> Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

I've hand-built GCC for half a dozen of different target architectures over the years and it's perhaps one of the most stable pieces of software when it comes to building it. I've only had one build failure over the years and that was unstable from git (even that usually works no problem).

To build GCC, follow the simple steps on the GCC manual. With a modern fast computer, it's all done in an hour or two (of mostly waiting).

Re: We have C++14

#283

Post by tfinniga » Tue, Aug 19, 2014, 2:38 PM UTC

pkolaczk wrote: post #274

tfinniga wrote: post #262

Earlier quoted context omitted.

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

Fair enough. But the number of resource-constrained systems is pretty low these times. A phone, watch, dishwasher or xero machine are no longer resource-constrained. Also, C++ is not really shining IMHO in very-constrained environments - at least not "modern C++" dialect. Template-heavy libraries can blow up code-sizes pretty severely and dynamic memory allocation happening behind-the-scenes in the standard library i…

Yeah, I realize my view on this is a bit skewed. A lot of the examples people give where C++ is still justified are things that I have done in my career - image processing, video editing, rendering software, CAD software, solving large sparse matrix systems, etc.

On the other hand, there is a reason why native apps are popular on the iPhone. Likewise, some games are programmed in high-level languages, but the performance advantage of C++ keeps it dominant in games. Between games and mobile devices, I'd say C++ isn't going anywhere any time soon.

C++ can indeed be very bloated, like you say. On the other hand templates do allow for code reuse without the function call overhead.. I believe std::sort is faster than qsort. For me, if there was another language that was as well supported as C++ but allowed higher-level structures and programming methods, I'd be very much in favor of it. For now it looks like new versions of C++ are the closest there is. Nobody really likes C++ for its elegance, it's just a very practical choice.

Re: We have C++14

#284

Post by masklinn » Tue, Aug 19, 2014, 2:52 PM UTC

maxlybbert wrote: post #265

masklinn wrote: post #246

Earlier quoted context omitted.

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

> Being careful is not enough.

UTF32 will not help you much with that, save that you've got a separate type for "strings" and "bunch of bytes"

Which you can have anyway, so do that, it's a good idea which doesn't require using UTF32.

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

As if other in-memory encodings had a better track record.

Re: We have C++14

#285

Post by blt » Tue, Aug 19, 2014, 3:15 PM UTC

Nursie wrote: post #93

tdees40 wrote: post #19

Earlier quoted context omitted.

This is totally true. The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to write that sort of code. I like way more of C++11 than I liked of the prior version, but there's just so much that's accumulated over the years. I wonder if breaking backwards compatibility is the key, but then I look at Python 3 and think, well, probably not.

The main downside I can see with it is how much implicit behaviour there is. Sometimes it's very hard to figure out what's actually going to happen with a line of code. That said it's quite expressive now, you can do a lot with a little code, which is always nice.

Yes. As much as I love C++, I sometimes get very scared by the implicit behavior. This is why I don't understand the hate on exception-free, more C-like C++. You can still reap huge benefits from std::algorithm, iterators, classes, templates, while stepping back to a more manual approach for allocation and lifetime management.

Re: We have C++14

#286

Post by JoeAltmaier » Tue, Aug 19, 2014, 3:19 PM UTC

blt wrote: post #285

Nursie wrote: post #93

Earlier quoted context omitted.

The main downside I can see with it is how much implicit behaviour there is. Sometimes it's very hard to figure out what's actually going to happen with a line of code. That said it's quite expressive now, you can do a lot with a little code, which is always nice.

Yes. As much as I love C++, I sometimes get very scared by the implicit behavior. This is why I don't understand the hate on exception-free, more C-like C++. You can still reap huge benefits from std::algorithm, iterators, classes, templates, while stepping back to a more manual approach for allocation and lifetime management.

You definitely have to pick and choose from C++ based on environment, your staff's experience, what kind of problem you're solving. Allocation in particular is problematic in every language (even GC languages) especially when latency is an issue, so that's probably what I manage 'manually' most often.

Re: We have C++14

#287

Post by humanrebar » Tue, Aug 19, 2014, 3:27 PM UTC

eps wrote: post #204

shmerl wrote: post #135

Earlier quoted context omitted.

My recent project uses standard C++11. No dialects, no restrictions. Gcc 4.8.x. It's not a mirage, it's all up to those who want to use it or not.

You are missing the point. No project uses all features of C++ at once, only a subset, and this forms a dialect. It's not that infrequent to see the dialect change when going from one team to another even in the same organization. Some use multiple inheritance and exceptions, some don't. Some swear by STL, some won't touch it with a long pole. That's why internal coding guidelines exist and that's why they are partic…

> No project uses all features of C++ at once, only a subset

Many features of C++ are targeted at library authors. Even if a given project won't allow template metaprogramming, it probably uses vector, which certainly does. And for good reason.

Re: We have C++14

#288

Post by PeterisP » Tue, Aug 19, 2014, 3:30 PM UTC

DSingularity wrote: post #165

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…

And what exactly does that mean? So what if the libraries are all written differently? I hardly see how thats a negative thing. The language is flexible. I was very impressed with c++11 features and I am looking forward to c++14.

It means that the language as such - the codebases written in it - have a readability problem. If every project is written differently with opposing coding standards and practices, then it adds a significant switching cost when moving to a different project, debugging systems that includes libraries from various sources or reusing code.

For ecosystems where there is a "one way to do it", then picking up a random project or library from github and using or changing it is easy, as it is understandable in the same way as my own code; for C++ it is, well, different.

And this is directly caused by the language - the technical details of the language significantly influence the code ecosystem that grows around it. Lisps are another example of this - because it's simple to define commonly used stuff yourself, it results in every project doing the same things differently, adding a serious cost in readability and maintenance for anyone that's not the original author.

Re: We have C++14

#289

Post by shmerl » Tue, Aug 19, 2014, 3:54 PM UTC

eps wrote: post #204

shmerl wrote: post #135

Earlier quoted context omitted.

My recent project uses standard C++11. No dialects, no restrictions. Gcc 4.8.x. It's not a mirage, it's all up to those who want to use it or not.

You are missing the point. No project uses all features of C++ at once, only a subset, and this forms a dialect. It's not that infrequent to see the dialect change when going from one team to another even in the same organization. Some use multiple inheritance and exceptions, some don't. Some swear by STL, some won't touch it with a long pole. That's why internal coding guidelines exist and that's why they are partic…

The commenter above claimed that "modern C++ doesn't exist" because normally only a subset of the language is used. I disputed that, and I got his point clearly. No one is using all features of the language just for the sake of it. That doesn't make used C++ not modern.

Re: We have C++14

#290

Post by eropple » Tue, Aug 19, 2014, 3:54 PM UTC

p0nce wrote: post #275

eropple wrote: post #266

Earlier quoted context omitted.

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

Good for you. It would be harder to dig if you had to do some maintenance like less lucky lifeforms.

I hope you didn't take that to mean that I don't maintain my own code. But I can choose when to refactor and when to put up with it. C++ isn't a tool to use when you can't own the project.