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

131–140 of 353 posts

Re: We have C++14

#131

Post by Silhouette »

yongjik wrote: post #122
kyllo wrote: post #86

Earlier quoted context omitted.

Like Google for example? Their C++ style guide is pretty restrictive, here's an expert C++ programmer's takedown of it: https://www.linkedin.com/today/post/article/20140503193653-3...

FWIW, things like range-based for loops, "auto", and unique_ptr are pretty standard in Google these days. Still no exceptions, though. The thing is, when you have a single codebase that is maintained by thousands of engineers, you have to make concessions. There is no place for "rockstar programming": everything must be, in a sense, bland, so that it blends seamlessly into the work of thousands of others.

Not that I disagree with your real point about writing maintainable code rather than "clever" code, but if you have a single codebase that is maintained by thousands of engineers then I would argue that you're probably doing something horribly wrong already, and using exceptions is hardly exclusive to so-called rockstars.

I don't really understand organisations that still use C++ in 2014 but then knock out such fundamental parts of its functionality, but then looking at the design priorities for Go, clearly at least some people at Google have very different preferences to my own, so YMMV etc.

Re: We have C++14

#132

Post by panzi »

colin_mccabe wrote: post #129
mariodiana wrote: post #126

Earlier quoted context omitted.

Could you name a book that focuses on Modern C++, that isn't one of these 1200 page tomes? I ask because sooner or later at my job I will probably have to code in C++. It will undoubtedly be a greenfield project, so I don't have to worry about anyone else's horror show (only my own).

I would use the Google Coding standard. The best book to read is Effective C++ (get the latest edition, since they have changed a lot.)

Doesn't the Google coding standard use uppercase function names (like Microsoft)? Brrr. Classes are nouns -> uppercase, functions are verbs -> lowercase. Well, alt least if you speak German that is the logical choice.

Re: We have C++14

#133

Post by Silhouette »

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.

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.

I don't think the idea is to force existing software to be rewritten. It's to provide a clean break so that new software isn't saddled with the baggage of the old. Over time, most of the older software is retired or replaced, and the industry migrates to use the better tools with more and more projects.

This seems a very reasonable strategy, as long as your ABI or equivalent interface specifications can remain compatible for the common subset of functionality, so that programs built using the new language can still use libraries written in the old one. (See also: Every successful general purpose programming language in decades has offered a FFI for C.)

It doesn't work so well if you don't have proper formal standards for your old and new languages. It's also much harder to achieve in practice if your code is effectively running on some sort of virtual machine so you can't have that clean break at the ABI level, which might be one reason why several languages have failed to make a convincing big jump in recent years (Perl 6, Python 3, etc.).

Re: We have C++14

#134

Post by steveklabnik »

deathanatos wrote: post #125
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…

> 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 bunch of issues when compiled on 32 and 64 bit architectures and there is a substantial amount of effort to clean it up. Such things happen whenever an invalid assumption that is commonly true becomes not so commonly true, such as the 32-bit to 64-bit migration. That said, C/C++ provides you t…

> I'm also interested to see how well Rust tackles this, as I agree it's a problem.

Is this a "see how well it actually works" or a "I don't know how this works and I'm interested?"

I'm curious because this is possibly Rust's most important, interesting feature, and I want to make sure we've got some reasonable messaging here.

Re: We have C++14

#135

Post by shmerl »

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…

My recent project uses standard C++11. No dialects, no restrictions. Gcc 4.8.x. It's not a mirage, it's all up to those who want to use it or not.

Re: We have C++14

#136

Post by shmerl »

adrusi wrote: post #96
Guvante wrote: post #75

Earlier quoted context omitted.

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

Linux is on all parts of the spectrum here. Ubuntu LTS and Slackware are going to remain outdated by design. Arch Linux almost always have the most recent stable releases of GCC and clang, and you can even build development snapshots from AUR

You don't need to use the compiler from the distro to release for that distro. There is such thing as cross compilation after all. Most do it out of habit and because distros don't offer such services out of the box. But if you build the cross compiler, you can use the newest one even if the distro ships the older.

For example I had a building machine running RHEL 5 which was building for both RHEL 5 and RHEL 6 while using gcc 4.8.2 for both (cross compilers).

Re: We have C++14

#137

Post by jonstewart »

sillysaurus3 wrote: post #118
dicroce wrote: post #112

Earlier quoted context omitted.

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++. Bu…

Huh? RAII is basically the only way to write exception-safe code in C++.

Re: We have C++14

#138

Post by MereInterest »

panzi wrote: post #132
colin_mccabe wrote: post #129

Earlier quoted context omitted.

I would use the Google Coding standard. The best book to read is Effective C++ (get the latest edition, since they have changed a lot.)

Doesn't the Google coding standard use uppercase function names (like Microsoft)? Brrr. Classes are nouns -> uppercase, functions are verbs -> lowercase. Well, alt least if you speak German that is the logical choice.

It also completely forbids the use of exceptions. I can understand that for their stated purpose of working with non-exception-safe legacy code, but it shouldn't be extended to other circumstances.

Re: We have C++14

#139

Post by cremno »

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…

>it wasn't in Visual Studio last I checked

The upcoming version has it.

Re: We have C++14

#140

Post by helmut_hed »

mariodiana wrote: post #126
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…

Could you name a book that focuses on Modern C++, that isn't one of these 1200 page tomes? I ask because sooner or later at my job I will probably have to code in C++. It will undoubtedly be a greenfield project, so I don't have to worry about anyone else's horror show (only my own).

There's no better place to start than Alexandrescu's eponymous Modern C++ Design http://www.amazon.com/Modern-Design-Generic-Programming-Patt.... Scott Meyers will soon come out with "Effective C++11" which from the table of contents looks like it will do a great job of covering the new language features.

As for coding standards, I suggest a book by the same author plus the current chair of the standard committee: http://www.amazon.com/Coding-Standards-Rules-Guidelines-Prac.... Another commenter has suggested the Google C++ Coding Standards, but despite their popularity they do not conform very well to "Modern C++" as I understand it.

Post reply on HN