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

101–110 of 353 posts

Re: We have C++14

#101

Post by kristiandupont »

ajuc wrote: post #39
ixtli wrote: post #31

Earlier quoted context omitted.

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…

>I'd say most of modern C++ code isn't written with the performance goals that justify nonvirtual as default

I am using C++ right now for embedded code but otherwise I write mostly Javascript. There was a time when C++ was the standard choice of language for desktop apps etc., but that's hardly the case any more. You choose C++ if you need performance and control. And I think the "default means the least overhead" concept makes a lot of sense there.

Also, inheritance is a very central part of mostly all Java code whereas it's much less idiomatic (modern) C++. In C++, classes serve to give you RAII and you specialize with templates.

Re: We have C++14

#102

Post by zak_mc_kracken »

wfunction wrote: post #23
ajuc wrote: post #20

Earlier quoted context omitted.

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…

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.

It was the right default twenty years ago for performance reasons.

These days, the economy of a vtable pointer is not really a good reason, and all languages that have the opposite default (such as Java, as you point out) are doing quite fine.

Because of this default, I can't count the number of times where I've seen "#define private public" and other horrors that developers used to be able to extend classes that their creators were too short sighted to design properly.

Re: We have C++14

#103

Post by zak_mc_kracken »

wfunction wrote: post #44
ajuc wrote: post #39

Earlier quoted context omitted.

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…

Performance is only one side of it. The bigger reason is http://stackoverflow.com/a/814939

Over 20+ years of development, I've found this objection to be vastly theoretical and with no practical consequences.

In practice, most classes are designed without inheritance in mind and yet, being able to extend and override them has proven infinitely more valuable than the occasional case where such an overriding breaks the parent class.

The practical reality is that even if a class is not designed for inheritance, inheriting from it is unlikely to break it but very likely to make its user's life much, much easier.

Re: We have C++14

#104

Post by zak_mc_kracken »

ThatOtherPerson wrote: post #48
jjoonathan wrote: post #33

Earlier quoted context omitted.

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

It's an improvement in the sense that it's more general; you can loop through any container that implements that protocol, which most (if not all) of the STL containers do. For example, template void foo(T arr) { for (auto it = arr.begin(); it != arr.end(); ++it) { std::cout You could pass a `std::map ` to `foo`, or a `std::list `, or a `std::vector `. You could even create your own classes and give them to `foo`, as…

I've never understood the STL's infatuation with iterators. Why do I even need to know about them when all I want is walk through the collection?

Ideally, it should be something like:

    for (auto it : arr) {
      // do something with *it
    }

Re: We have C++14

#105

Post by nly »

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…

C++'s support for unicode is minimal. There are unicode string literals for UTF-8, UTF-16 and UTF-32, and conversion facilities between those encodings and the host platforms native 'wide char' format.

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

In general you should use std::string and UTF-8, since UTF-8 is a relatively safe encoding for sub-string search and replace, and (locale insensitive) lexical comparison/ordering. Windows uses a 16 bit wchar_t (UTF-16). Mostly everyone else uses 32 bit (UTF-32)

> - If I want to read & write UTF-8 files, how do I turn the bytes into 32-bit wide Unicode strings?

http://en.cppreference.com/w/cpp/locale/wstring_convert

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

Nope. You need a library for that. Manipulating natural language is a tricky business anyway, beyond single mortals, and you will likely get it wrong.

Re: We have C++14

#106

Post by jonstewart »

PopsiclePete wrote: post #98
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 differen…

As a counterpoint, I write "Modern C++" for my job. I know several others who do, too. I'm overjoyed at how much the C++11 features have improved my code (and I'm still learning how to deploy them effectively), as well as how good the compiler support is.

MFC was the vilest, most horrible abuse of C++ from the day it was released. Anything that involves MFC should just be rewritten with C# or turned into a webapp. I wouldn't take a job that involved programming MFC.

Re: We have C++14

#107

Post by [deleted] »

ChuckMcM wrote: post #67
sdegutis wrote: post #34

Earlier quoted context omitted.

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 weird thing is, why not just call it something new? I've always wondered if they called Perl 6 "Smeebly" or something would it get a better reception? C+++ ? My personal taste is that if you break backwards compatibility that is when you have a 'new' language and you just just name it as such.

[deleted]

Re: We have C++14

#108

Post by jonstewart »

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.

It really is abominable how bad the standard support for Unicode is. ICU is great, though the C API is somewhat limited compared to the full C++ API. ICU's build process, OTOH, leaves something to be desired, especially if you want to build it with a cross-compiler.

Re: We have C++14

#109

Post by tbrock »

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.

There is an digital unedited pre-release version that available now if you pre-order:

http://shop.oreilly.com/product/0636920033707.do

I'm reading the PDF and it's quite good.

Re: We have C++14

#110

Post by jonstewart »

zak_mc_kracken wrote: post #102
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.

It was the right default twenty years ago for performance reasons. These days, the economy of a vtable pointer is not really a good reason, and all languages that have the opposite default (such as Java, as you point out) are doing quite fine. Because of this default, I can't count the number of times where I've seen "#define private public" and other horrors that developers used to be able to extend classes that the…

I'm very glad that virtual is not the default. Most of the classes I write are simply value classes and do not use inheritance at all. Once you start using virtual, you really have to embrace traditional inheritance idioms whole hog, and then you've got std::vector> instead of std::vector.

If anything, the performance difference between std::vector> and std::vector is even greater today than it was twenty years ago.

Post reply on HN