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

51–60 of 353 posts

Re: We have C++14

#51

Post by tdees40 »

dfan wrote: post #28
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.

Also, how many companies are afraid of the new features and deprecate them internally (fearing compiler bugs, lack of portability, and/or unmaintainability). I still haven't had a chance to use full C++11 in a professional context.

Oh my goodness, yes. The HN crowd probably doesn't appreciate the extent to which people who sling C++ at BigCorp are limited by the rules the company sets.

Re: We have C++14

#52

Post by tormeh »

AnimalMuppet wrote: post #49
tormeh wrote: post #38

Earlier quoted context omitted.

No language exists but x86 binary code!

Um, ever hear of ARM? (Also 680X0, IBM mainframes, 8051, Itanium, Sparc...) But then I presume the parent was sarcasm.

Yeah, it was sarcasm on my part, at least. Point being that only binary is it's own language all the way down (which is of course not long at all).

Re: We have C++14

#53

Post by azoth_ »

jjoonathan wrote: post #33
SamReidHughes wrote: post #18

Earlier quoted context omitted.

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

In modern C++ these loops could alternatively be written as:

  std::vector myVec;
  for( auto it = myVec.begin(); it != myVec.end(); ++it );
or if you prefer the external begin/end syntax:

  for( auto it = std::begin(myVec); it != std::end(myVec); ++it );
or the most succinct (replace && by & if writing):

  for( auto && item : myVec );

Re: We have C++14

#54

Post by pmelendez »

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

Well there are people who really hates C++[1] and to be honest C++03 had some flaws an inconveniences that made the language a bit awkward. Right now it feels like it is going in the right direction.

[1]http://article.gmane.org/gmane.comp.version-control.git/5791...

Re: We have C++14

#55

Post by pmelendez »

sdegutis wrote: post #42
untog wrote: post #40

Earlier quoted context omitted.

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

I don't think Python 3 is a good example. Unlike other cases where languages broke backwards compatibility, the Python community actively discouraged upgrading for years, constantly saying "don't use Python 3" for years, and Python 2 was actively maintained in parallel to Python 3, with features constantly being back-ported. It would have been much smoother overall if they'd just dropped Python 2 altogether, even if…

I believe he was being sarcastic. And breaking backwards compatibility can be really bad. Imagine if the next version of C would break the previous one. How many operating systems and critical software would have to be rewritten in order to be maintained.

Re: We have C++14

#56

Post by jevinskie »

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…

When LLVM started to require C++11 (which we use as a library), my team decided to statically link libstdc++ into our product on Linux. Now we just depend on glibc (and we use symbol versioning to keep the required version to a minimum). It sounds like you ship source though, so it may not be an option for you.

Re: We have C++14

#57

Post by jjoonathan »

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…

Oh yes, and I'm hella thankful for those containers. I just wish "auto" had come along a little sooner :)

Re: We have C++14

#58

Post by jjoonathan »

azoth_ wrote: post #53
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).

In modern C++ these loops could alternatively be written as: std::vector myVec; for( auto it = myVec.begin(); it != myVec.end(); ++it ); or if you prefer the external begin/end syntax: for( auto it = std::begin(myVec); it != std::end(myVec); ++it ); or the most succinct (replace && by & if writing): for( auto && item : myVec );

Yes, and it's probably good to note that the issue has been fixed so as to not unduly scare away any newcomers to C++. Thanks for doing it for me :) Still, at the time the

    for(auto& item : vec)
syntax was merely a talking point being tossed around C++0x meetings. And to this day the project I'm working on still hasn't officially dropped support for C++90 so I'm stuck with the old syntax anyway :/

Re: We have C++14

#59

Post by jsmeaton »

tdees40 wrote: post #51
dfan wrote: post #28

Earlier quoted context omitted.

Also, how many companies are afraid of the new features and deprecate them internally (fearing compiler bugs, lack of portability, and/or unmaintainability). I still haven't had a chance to use full C++11 in a professional context.

Oh my goodness, yes. The HN crowd probably doesn't appreciate the extent to which people who sling C++ at BigCorp are limited by the rules the company sets.

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

Re: We have C++14

#60

Post by cwyers »

pmelendez wrote: post #55
sdegutis wrote: post #42

Earlier quoted context omitted.

I don't think Python 3 is a good example. Unlike other cases where languages broke backwards compatibility, the Python community actively discouraged upgrading for years, constantly saying "don't use Python 3" for years, and Python 2 was actively maintained in parallel to Python 3, with features constantly being back-ported. It would have been much smoother overall if they'd just dropped Python 2 altogether, even if…

I believe he was being sarcastic. And breaking backwards compatibility can be really bad. Imagine if the next version of C would break the previous one. How many operating systems and critical software would have to be rewritten in order to be maintained.

Python is in a different boat than C++. If the Python language leaders decides to make a version that breaks backwards compatibility... well, they also make the most popular Python interpreter. The group responsible for the C++ standard isn't in the same position at all, they have to convince the different compiler groups (GCC,LLVM,Intel,Microsoft,etc.) to implement it for them.
Post reply on HN