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

91–100 of 353 posts

Re: We have C++14

#91

Post by cletus »

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 bunch of issues when compiled on 32 and 64 bit architectures and there is a substantial amount of effort to clean it up.

I point out things like this to colleagues who are very pro-C++ and I inevitably get the same response: "well that's just bad API design".

Thing is, if you look at the history of this example it's a series of incremental changes, all well-meaning and reasoned, some of which are done by people who I could only call luminaries, and even they make significant and far-reaching mistakes.

So what hope do the rest of us have?

But my biggest problem with the C-dialects is pointers. Namely if you return or receive a pointer, it's not necessarily clear who owns it. The way this is handled is comments like "DO NOT delete this" or "you MUST delete this".

I like that a language like Rust is trying to formalize the concept of object ownership. I'd really like to see that idea mature and take hold.

Until now there hasn't really been a competitive alternative to C/C++. It's not Go (as much I love Go). Maybe it's Rust. We can but hope.

My other big problem (and this applies to Java too) is directly dealing with low-level multithreading primitives like threads, thread groups and mutexes. I really like that Go has taken a different approach here.

What I find with particularly young programmers is they don't have the appropriate fear of writing multithreaded code. It's really, really hard to write correct multithreaded code with low-level primitives. It's why (excellent) books like Java Concurrency in Practice exist.

As for the feature list of C++14 [1], I wonder what all these "auto" declarations will do to the significant work required for static analysis tools, that are an essential part of modern, large-scale C++ codebases.

The literal types (like "s" for std::string or seconds) are cute but at some point the STL was optional. I'm a little leery of embedding it directly in the language but hey I'm no expert.

[1]: http://en.wikipedia.org/wiki/C%2B%2B14

Re: We have C++14

#92

Post by maxlybbert »

syncsynchalt wrote: post #77
maxlybbert wrote: post #71

Earlier quoted context omitted.

C11 has the uchar.h header (say, http://www.cplusplus.com/reference/cuchar/ ), but it wasn't in Visual Studio last I checked. Most programmers will tell you to use UTF-8 for in-memory strings. But it's not easy to figure out if a particular char* is already encoded as UTF-8, and it's common for people to forget that Unicode characters can take up to 6 bytes in UTF-8. I know I'm in the minority, but I prefer to use UT…

Unicode code points can only take 4 bytes in UTF-8, this has been true ever since the planes were capped at U+10FFFF. Or did you mean UTF-8 encoded surrogate pairs?

Thanks for the correction. I don't know where I originally got the "up top six bytes" number from, but I've been using it for a while. Apparently, it's out of date (looking at the original proposal, https://en.wikipedia.org/wiki/UTF-8#Description , some code points were expected to need 6 bytes, but as you say, that's no longer true).

Re: We have C++14

#93

Post by Nursie »

tdees40 wrote: post #19
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.

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.

Re: We have C++14

#94

Post by Nursie »

wisty wrote: post #43
pjungwir wrote: post #36

OT question: I was playing with some C over the weekend (not C++), trying to figure out how to handle Unicode in a way that would work on Mac, Linux, and Windows. Despite a couple hours googling and reading, I couldn't answer really basic stuff, like: - Do I use char* for strings? It sounds like wchar_t is 16 bits on some systems and 32 on others, so I should avoid it? - If I want to read & write UTF-8 files, how do…

Look here: http://userguide.icu-project.org You really need a library when dealing with unicode, if you are doing anything advanced. How do you split a sentence into words? Spaces, right? Oh, Chinese doesn't have spaces. How about sentences? Paragraphs? Even characters are a pain to iterate over.

Agreed, ICU is a good place to start looking at this stuff, used it in a few large-scale commercial projects now.

Re: We have C++14

#95

Post by guiomie »

voltagex_ wrote: post #89
jsmeaton wrote: post #59

Earlier quoted context omitted.

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

* Don't use LINQ * Don't use var * Don't use dynamic or even better, "You've only got .NET 2/3 installed"

I can't look at code without var's anymore.

Re: We have C++14

#96

Post by adrusi »

Guvante wrote: post #75
wfunction wrote: post #29

Earlier quoted context omitted.

> 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 do the same thing. Not because I can't write C++11, but because I still encounter systems with older compilers that I want to run programs on. What, is this surprising? Let's face reality: it's a little unreasonable to expect every system you work on to have…

> Let's face reality: it's a little unreasonable to expect every system you work on to have a compiler less than 3 years old. If you are running Linux, this is one thing that Windows gets right. (Although as you say VC++ has some catching up to do still).

Linux is on all parts of the spectrum here. Ubuntu LTS and Slackware are going to remain outdated by design. Arch Linux almost always have the most recent stable releases of GCC and clang, and you can even build development snapshots from AUR

Re: We have C++14

#97

Post by Nursie »

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…

On pointers -

Like a lot of things with C, you need to handle ownership by convention. I generally try to make the actor that created the heap pointer the owner of it and responsible for its destruction - i.e. instead of allocating buffers and handing them back up the chain full of data, pass them down from the requester where possible. If the length is not known at that point, create another routine to calculate it. Using techniques like this, ownership can become easier.

You can do anything with it, but that's half the problem!

And personally I like threads :)

Re: We have C++14

#98

Post by PopsiclePete »

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 different from what Google's C++ libraries are...

This is what happens when a language is "un-opinionated", throws everything including the kitchen sink at the language, tries to compile C and legacy C++ while introducing new features oh and also can't break existing code.

It's on its way out, no doubt about it. And we'll be better off as an industry for it, I'm sure of it.

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

Re: We have C++14

#99

Post by nly »

maxlybbert wrote: post #71
pjungwir wrote: post #36

OT question: I was playing with some C over the weekend (not C++), trying to figure out how to handle Unicode in a way that would work on Mac, Linux, and Windows. Despite a couple hours googling and reading, I couldn't answer really basic stuff, like: - Do I use char* for strings? It sounds like wchar_t is 16 bits on some systems and 32 on others, so I should avoid it? - If I want to read & write UTF-8 files, how do…

C11 has the uchar.h header (say, http://www.cplusplus.com/reference/cuchar/ ), but it wasn't in Visual Studio last I checked. Most programmers will tell you to use UTF-8 for in-memory strings. But it's not easy to figure out if a particular char* is already encoded as UTF-8, and it's common for people to forget that Unicode characters can take up to 6 bytes in UTF-8. I know I'm in the minority, but I prefer to use UT…

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

Re: We have C++14

#100

Post by nly »

ajuc wrote: post #20
astrodust wrote: post #14

Earlier quoted context omitted.

In languages like C++ "verbose" means "specific and obvious" which is something you want to have when writing certain kinds of code. It's annoying, it's a drag on productivity, but in the long run it's arguably necessary. Some other languages which reduce verbosity by making more things implicit make it harder to understand what's actually going on behind the scenes. You lose a lot of information.

A lot of C++ verbosity comes simply from bad defaults. Const and virtual should be the default for example, not the other way around. Would stop the virtual destructor ommision problem, and if you need efficiency you could make destructors non-virtual. Also in the "hiding stuff behind the scenes" department C++ is quite bad. SomeClass someMethod(SomeClass a, SomeClass b) { ... } is doing a lot behind the scenes. Code…

It's a lot easier to reason about your first version of 'someMethod', which passes by value, than the second. It can actually be more performant than the second as well, since the code inside the body of the function (which may have been compiled during another invocation of the compiler on a seperate file) now knows the dynamic type of the object it's dealing with, meaning all interior virtual calls can be made direct.

The first form of 'someMethod' will also accept all 4 combinations of moves and copy operations on 'SomeClass': (copy a, copy b), (copy a, move b), (move a, copy b), (move a, move b). Your second, less convenient, function results in moves degrading to copies, leaving performance on the table if 'someMethod' performs mutation.

Your 'y = f(x)' ambiguity isn't a problem in practice, since most code styles use different naming conventions for classes/structs and function names.

Conversions, construction, copy, move, and assignment semantics etc, are one of the most important, and one of the most difficult things to get right, when it comes to class design. If you make sane choices though, and put thought in to it, automatic conversions etc shouldn't be bothersome.

Post reply on HN