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

111–120 of 353 posts

Re: We have C++14

#111

Post by jonstewart »

zak_mc_kracken wrote: post #104
ThatOtherPerson wrote: post #48

Earlier quoted context omitted.

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 }

It basically is this easy these days, thankfully. It is nice to have iterators, though, because it allows you some flexibility for swapping out the underlying data structures on existing algorithmic code. This has proved quite useful when I've written graph code.

Re: We have C++14

#112

Post by dicroce »

jonstewart wrote: post #106
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…

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…

Me too. RAII ftw!

Re: We have C++14

#113

Post by Iftheshoefits »

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…

People have been saying this about C and C++ for decades. Not to say C++ will always be "on top", or even that it currently is, but your comment isn't really substantive or persuasive that "it's on its way out."

I'm also not convinced that Rust or Go are better or saner.

Re: We have C++14

#114

Post by jonstewart »

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…

The convention I use in my own code is that passing a raw pointer around, or returning one, confers ownership. Mostly I do not schlep raw pointers around between functions, though. I use shared_ptr or scoped_ptr or unique_ptr or a reference. When I have to use raw pointers with some given library, then I immediately wrap their usage in my own facade types. Sticking to these oft-repeated best practices means that crashes are rare and memory leaks are rarer still.

Re: We have C++14

#115

Post by jeorgun »

zak_mc_kracken wrote: post #104
ThatOtherPerson wrote: post #48

Earlier quoted context omitted.

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 }

You can do that. That's part of C++11 and is supported by basically every major compiler.

The advantage of iterators is that they're incredibly flexible. You can use them for sub-ranges, reversed ranges, non-ranges like input and output iterators, etc, etc. This is vastly more powerful than something like, say, Objective C's NSFastEnumeration, which just allows for the trivial case handled by the range-based for-loop.

Re: We have C++14

#116

Post by mpyne »

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…

Beyond the issue noted with UTF-16 permitting surrogate pairs, it's also important to understand that UTF-16 does not free you from normalization form concerns.

For instance, even within the 16-bit Basic Multilingual Plane, it is not safe to reverse a UTF-16 string by simply reversing each block of 2 bytes, as a Unicode glyph (e.g. á) can be composed of a pre-combined code point which only takes 16-bits, or a base character (a) followed by a combiner (´).

The pre-combined variant would reverse just fine, but the renderer-combined á would reverse to ´a, which is probably not what was intended.

If you're dealing with Unicode you need to be dealing with a good library and you need to be understanding what you're doing, once you go away from simply reading/displaying/serializing bags-o-bits.

But if the latter is all you're doing, UTF-8 is just fine, and less susceptible to mistakes with code that works correctly on C strings.

Re: We have C++14

#118

Post by sillysaurus3 »

dicroce wrote: post #112
jonstewart wrote: post #106

Earlier quoted context omitted.

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…

Me too. RAII ftw!

Good luck making your RAII class exception safe. It's extremely difficult, to the point that writing a simple class becomes an hours-long exercise in reasoning about exceptions.

And of course, if you admit that exceptions aren't worth worrying about, then you'll start to question the entire "C++ way," which usually ends in disillusionment.

Alternatively, instead of disillusionment, you may still kind of enjoy C++. But suddenly you find that it's been three years since you've worked with C++, and on reflection, you haven't really been missing out on much of anything at all by not using C++.

It doesn't seem like C++ solves the right problems, even with the new dialects. Programming languages should be convenient to think in. By immersing yourself in the C++ mental model, it becomes difficult to keep a large-scale architecture entirely in your head.

Re: We have C++14

#119

Post by mpyne »

akira2501 wrote: post #61
zanny wrote: post #47

Earlier quoted context omitted.

Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the features you want. In C++ unicode is as simple as: string s = u8"This is always a utf8 string.";

Is 'extern "C"' still a thing to avoid name mangling? Some C++ features are easier not to use than others.

Yes, extern "C" is still a thing to interoperate with the C FFI. It is required if for nothing else than to use C headers.

Re: We have C++14

#120

Post by jeorgun »

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…

The literal types are optional— they're user-defined literals, which can be written like (say):

    QString operator""_qs(const char* c_str, size_t len)
    {
        return c_str;
    }

    void foo()
    {
         auto iama_non_stl_type_ama = "foo"_qs;
    }
Post reply on HN