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

71–80 of 353 posts

Re: We have C++14

#71

Post by maxlybbert »

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 UTF-16 or UTF-32, because nobody makes the kind of mistakes with UTF-16/UTF-32 that they make with UTF-8. Plus, you can't accidentally pass a UTF-16-encoded string to a non-Unicode-aware function.

Re: We have C++14

#72

Post by maxlybbert »

adamnemecek wrote: post #65
_delirium wrote: post #50

Earlier quoted context omitted.

Fairly common programming language convention as well. I believe FORTRAN 66 and ALGOL 68 were the first standards widely referred to with a revision year. More recent examples include Fortran 90 (no more caps!) and C99.

I agree but it seems like newer languages adopted the 1.0, 2.0 versioning scheme so it might throw some people off.

Pre-standard C++ had that scheme as well! (well, CFront releases, http://www.softwarepreservation.org/projects/c_plus_plus#cfr... ).

Re: We have C++14

#73

Post by RogerL »

astrodust wrote: post #14
spott wrote: post #11

I really like the direction C++ is moving in. I just really don't like how incredibly VERBOSE it is (though `auto` helps).

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.

Stroustrup doesn't think so.

I don't have a link - it was in some recent conference. He stated that every time he added a new feature everyone would be up in arms and demand a really verbose implementation, which he added reluctantly. Now that everyone is used to the features they complain about how ridiculously verbose it all is.

There isn't any reason for the craziness of

    template 
    void foo(T a)
vs

    void foo(auto a)
Certainly things can become too implicit, but C++'s heritage of verboseness is due to the conservatism of the standards committee, not because anything less would be confusing.

Re: We have C++14

#74

Post by SupremumLimit »

ibebrett wrote: post #30
bnejad wrote: post #25

Can anyone recommend a book on modern C++?

Yeah, this would be a god send. As someone who is writing more and more C++ for computer vision type stuff, a modern overview would be great. I am stuck working off of things I learned over the years and don't feel quite like I'm writing modern idiomatic C++

If you just want to learn about the features introduced in C++11/14, I wrote compiler-specific books about those: http://cpprocks.com

Re: We have C++14

#75

Post by Guvante »

wfunction wrote: post #29
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 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).

Re: We have C++14

#76

Post by nly »

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…

You want to use 'T const&' as your argument type, not 'T', otherwise foo() will take a copy of anything you pass.

Re: We have C++14

#77

Post by syncsynchalt »

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…

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?

Re: We have C++14

#78

Post by bluetech »

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.

Maybe they can use something like javascript's and perl's "strict" annotations.

Re: We have C++14

#79

Post by ajuc »

pmelendez wrote: post #66
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…

>"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." Think it in this way. Many respectable people has been making a case to avoid inheritance[1][2]. What you are proposing would actually be an incentive to them. I don't know about you but the amount of functions that I actually override in my…

I agree with "composition over inheritance", but I disagree with "inheritance is evil". Composition over inheritance means you divide you classes into parts that ALSO use inheritance and virtual methods, you just don't make the hierarchy deep and don't mix many different subdivisions into one hierarchy. The problem isn't virtual methods, it's too many divisions and responsibilities in one class hierarchy.

And you do want to refactor your virtual methods and then extracted methods do usually need to be virtual, even if at first they don't they may need to become virtual in future, and IMHO it's better to just make them virtual from the start, if you don't REALLY need the performance.

You can mess up because of nonvirtual-by-default too, especially in C++ because of the difference between stack and heap objects.

    struct A {
       virtual int f(int x, int y) { return g(x,y); }
       int g(int x, int y) { return x+y; }
    };
    struct B : public A {
       int f(int x, int y) { return g(x,y)+1; }
       int g(int x, int y) { return x+y-1; }
    };
    B* b1 = new B();
    A* b2 = b;
    B b3;

    b1->f(2,2); // 4
    b2->f(2,2); // 5
    b3.f(2,2); // 4
This bite me a few times in C++.

Re: We have C++14

#80

Post by programmarchy »

zanny wrote: post #47
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…

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.";

Firmware development. For some microcontrollers, you'll be lucky to even have a C compiler let alone a C++ compiler. Even then, I'd rather use C than C++ for firmware. I often find myself running into odd compiler issues, having to inspect/modify assembly, deal with resource constraints, etc. and I imagine C++ would make that more difficult.
Post reply on HN