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

31–40 of 353 posts

Re: We have C++14

#31

Post by ixtli »

ajuc wrote: post #24
wfunction wrote: post #23

Earlier quoted context omitted.

Uh, no, "virtual" should absolutely NOT be the default. I don't know where you got that idea from (Java?) but it's absolutely horrible.

Why would it be bad? You could always add non-virtual (inline maybe? it's already useless keyword) if you need the performance, and most of the code doesn't. And it's a source of errors.

Because if the compiler can not figure out how to de-virtualize your usage of a structure then you're going to necessitate that a vtable be created at compile time and used at runtime.

The reason the previous commenter asked if you're from the java world is because in many highly important areas, the effect on memory and speed this would cause would be unacceptable. These areas _tend_ to be left to people who understand languages like c, though, so a lot of newer languages make decisions ignoring these good use cases.

Re: We have C++14

#32

Post by dfan »

bnejad wrote: post #25

Can anyone recommend a book on modern C++?

Scott Meyers' Effective Modern C++ will be required reading once it's released in October.

Until then (and even after), Stroustrup's The C++ Programming Language (4th edition) is the canonical resource. It's a reference but is also intended to be read.

Re: We have C++14

#33

Post by jjoonathan »

SamReidHughes wrote: post #18
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.

> In languages like C++ "verbose" means "specific and obvious" Whoa, no it doesn't. C++ is far more verbose than necessary for things like creating algebraic datatypes or really creating any types.

Or looping through for loops. I remember the jaw-hitting-floor moment when my C++ book tried to pass off

    std::vector::iterator it;
    for (it=arr.begin(); it!=arr.end(); it++) {
        ...
    }
as an improvement over

    for (int i=0; i
Not entirely unrelated: I'm currently busy verbosifying a large chunk of C++11 code into C++90 code because Reasons (or so the maintainers assure me).

Re: We have C++14

#34

Post by sdegutis »

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.

Meh, breaking backwards compatibility isn't all that bad. It will be a bit rough for a few years, but it's worth it to clean things up for a brighter future.

Re: We have C++14

#35

Post by bnejad »

dfan wrote: post #32
bnejad wrote: post #25

Can anyone recommend a book on modern C++?

Scott Meyers' Effective Modern C++ will be required reading once it's released in October. Until then (and even after), Stroustrup's The C++ Programming Language (4th edition) is the canonical resource. It's a reference but is also intended to be read.

Thank you, looking forward to Meyers' release.

Re: We have C++14

#36

Post by pjungwir »

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 I turn the bytes into 32-bit wide Unicode strings?

- Are there special functions I should use for handling Unicode strings?

More generally, where do you go to discover C libraries you can use?

I am (was) reasonably proficient in C, but I haven't used it much for over ten years. I'm surprised how many things I just don't know how to do!

Sorry this is not a C++ question. I'd like to get back into that also, but I'm trying to work my way up from the basics. :-)

Re: We have C++14

#37

Post by tedunangst »

tormeh wrote: post #27
cdelsolar wrote: post #21

Earlier quoted context omitted.

um, C++ is the most widely used language in the world.

Okay, that's incorrect. It's a bit hard to say whether it is Java, Javascript or C, but it's certainly not C++.

It's really neither here nor there, but every java or JavaScript engine in widespread use is written in c++, so c++ code "in use" subsumes both of them.

Re: We have C++14

#38

Post by tormeh »

tedunangst wrote: post #37
tormeh wrote: post #27

Earlier quoted context omitted.

Okay, that's incorrect. It's a bit hard to say whether it is Java, Javascript or C, but it's certainly not C++.

It's really neither here nor there, but every java or JavaScript engine in widespread use is written in c++, so c++ code "in use" subsumes both of them.

No language exists but x86 binary code!

Re: We have C++14

#39

Post by ajuc »

ixtli wrote: post #31
ajuc wrote: post #24

Earlier quoted context omitted.

Why would it be bad? You could always add non-virtual (inline maybe? it's already useless keyword) if you need the performance, and most of the code doesn't. And it's a source of errors.

Because if the compiler can not figure out how to de-virtualize your usage of a structure then you're going to necessitate that a vtable be created at compile time and used at runtime. The reason the previous commenter asked if you're from the java world is because in many highly important areas, the effect on memory and speed this would cause would be unacceptable. These areas _tend_ to be left to people who underst…

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 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. I don't see how it's any better than having to delete "virtual" from every method it implements or derives. Just a question of defaults, and I'd say most of modern C++ code isn't written with the performance goals that justify nonvirtual as default. You can and should profile after writing something anyway if you care about performance.

And anyway if you have derived classes it's almost always the case that you want at least some of your methods virtual, otherways what's the point?

Re: We have C++14

#40

Post by untog »

sdegutis wrote: post #34
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.

Meh, breaking backwards compatibility isn't all that bad. It will be a bit rough for a few years, but it's worth it to clean things up for a brighter future.

The example of Python 3 is a good one. "A bit rough for a few years" might be an underestimation.
Post reply on HN