Google C++ Style Guide

asdf

That's why throw() is deprecated.

Kian

I don't think they got the definition wrong, but they did get the way to signal it wrong. And as mentioned, that part is deprecated. The only specification supported now is "noexcept".

It works a bit like throw(), but not quite. You can, for example, make the specification conditional. Meaning, the specification can say "this function is noexcept of this expression is true".

It doesn't mean that the function won't throw, it means that if the function does, ~~it's undefined (in implementation,~~ it calls terminate.

asdf

@Kian said:

it means that if the function does, it's undefined

I'm pretty sure the standard guarantees that std::terminate is called in that case. At least that's what I read everywhere. It also makes sense: If a function that promises the calling code not to throw throws an exception, there is no sensible thing you can do other than terminate the application.

Kian

You are right, I was on mobile and didn't check to make sure.

dse

I joined here to like all your excellent moments with Tizen, do please enlighten us more :) anything Samsung, Tizen, ... please

Kian

@dkf said:

For a long time, their implementation was so nasty as to make that statement true.

That's why I said it was misguided, not outright wrong. If your reasoning is "I don't want to use this because it's not good enough yet", then once it does become good enough, you'll be stuck with an inferior alternative unless you were careful enough to make switching back easy.

tar

Actually, one of the nice things about cpplint.py is that you can turn all the wacky shit off, and get some decent static analysis of your codebase just for the cost of installing Python. I ran it on a codebase of mine with the following warnings disabled:

build/header_guard \
build/include \
build/include_what_you_use \
build/include_order \
legal/copyright \
readability/function \
readability/todo \
runtime/references \
whitespace \
 \
build/namespaces \
readability/braces \
readability/namespace \
runtime/explicit \

I was/am planning to try to enable the last four at some point in the future, because making purely stylistic changes to a 55,000 line codebase is a productive use of my free time. (I already build with -Wall -Werror -Wextra.)

another_sam

@asdf said:

For Java programmers, maybe, who shouldn't even be near a C++ code base in the first place. I mean, I get their argument that too much template magic is hard to understand. But namespaces? Or exceptions?

Java style heavily encourages clear namespaces (based on names acquired through a global registrar, not just made-up shit that's waiting to conflict with others) and use of exceptions. There are many valid criticisms of the language, but this comment you should direct elsewhere.

asdf

@another_sam said:

Java style heavily encourages clear namespaces (based on names acquired through a global registrar, not just made-up shit that's waiting to conflict with others) and use of exceptions. There are many valid criticisms of the language, but this comment you should direct elsewhere.

I was trying to say two different things here:

People with no C++ experience (for example, Java programmers) should not be anywhere near a C++ code base
Even if the Google Style Guide is supposed to make C++ code easier for newbies (and if we ignore the fact that that's stupid in the first place), some of the rules are still ridiculous.

I didn't mean to ridicule Java programmers or the Java programming language in any way. I write both Java and C++ for a living, and I definitely like Java more, despite its shortcomings.

another_sam

@asdf said:

People ~~with no C++ experience (for example, Java programmers)~~ should not be anywhere near a C++ code base

Snark'd TFY.

asdf

I really have to try Rust some time. I wonder whether it actually manages to be easier to use than C++ while being as flexible and powerful.

another_sam

@asdf said:

I really have to try Rust some time.

Every now and then I go read part of the web site and think "Hey, that's got some pretty interesting features." Then I remember I'm an apps programmer, not a system programmer, and my levels of caring get low enough that anything more difficult than "apt-get install rust" and I'm not going to try it out. Last time I tried, that didn't work, so I still haven't done much more than read the features list.

asdf

@another_sam said:

apt-get install rust

There's a PPA for that.

LB_

You could always make your own.

asdf

Nah, I'm a nerd, and I'm interested in a lot of things, but I'm not into designing programming languages. I'll let other people do that and go through the pain of creating a user base and ecosystem around their personal pet language while I either enjoy or bitch about the results.
Also, I'm way too lazy ;)

another_sam

@asdf said:

@another_sam said:
apt-get install rust

There's a PPA for that.

That doesn't make it over the "No more difficult" bar, which remains low because why would I subject myself to a systems programming language when I can use a higher level language? There's enough with neat features to choose from that I'll never run out of new languages to learn.

Kian

@asdf said:

while I ~~either~~ enjoy and/or bitch about the results.

Why not both? "There's only two kinds of programming languages. Those that people complain about, and those nobody uses".

dse

Interestingly I have seen people only praise Rust.

Kian

∴ It's either not a programming language, or no one uses it.

dse

For the folks who do not like C++ style guide: This is blessed by Stroustrup himself, seems like as official as it can get.

dkf

Are they going to do a version which isn't one gigantic long page? Yes, there's a lot to think about, but it shouldn't require discoinfiniscrolling to keep the amount of content in memory sensible…

LB_

I don't believe so, I think you're supposed to be able to Ctrl+F specific rule numbers.

dkf

Bah! Just make it easy for Google to index and the finding will take care of itself…

dse

My guess is it would not take long before someone forks it and serves it as HTML with chapters.

tar

Coincidentally, I just read most of that on the side during builds. It's actually not too bad, and got me kinda interested in the GSL library they keep mentioning. Mainly for array_view<>, which I'd be happier to steal than copy.

I also read the Google ones and was expecting to be annoyed by the lack of C++11 info, but they updated it a lot since I last read them. Overall I'd say I'm about 80% in agreement with both guides individually and about 90% in agreement with the bits where GSL and Google agree...

dse

Maybe it is time to raise your disagreement bits in the issue tracker. Soon compilers start spitting warnings, and I hope there would be an option to make them errors.

Bulb

@another_sam said:

apt-get install rust

rustc package exists, but until there is corresponding cargo package, it is mostly useless.

tar

Meh, nobody's going to listen to me, and C++ is still OK as-is, in the niche of cross-platform native work (and with so many ways to write the same thing, you can just simply ignore most of the misfeatures currently). If it starts to evolve into something unusable, I'll probably just freeze my codebase at C++11/14/17 or whichever, and start looking into Rust, or maybe even see where C is at these days...

LB_

It's looking like C++ will only become more usable over time.

tar

The elephant in the room being whether they'll finally admit that source-level [semi-]compatibility with C is causing far more problems than it solves. I'd actually love to see a version of C++ where outside of an extern "C" {} block, C-style casts are banned, for example. Sure, nobody is intentionally writing C-style casts these days anyway, but then again, nobody's intentionally writing vexing parses. Someone should take Bjane up on the "smaller, cleaner language struggling to get out", and actually write that language. Maybe even give it a sane grammar as well, so we can run refactoring tools against it, that kind of thing...

powerlord

@tar said:

The elephant in the room being whether they'll finally admit that source-level [semi-]compatibility with C is causing far more problems than it solves. I'd actually love to see a version of C++ where outside of an extern "C" {} block, C-style casts are banned, for example. Sure, nobody is intentionally writing C-style casts these days anyway, but then again, nobody's intentionally writing vexing parses. Someone should take Bjane up on the "smaller, cleaner language struggling to get out", and actually write that language. Maybe even give it a sane grammar as well, so we can run refactoring tools against it, that kind of thing...

Wasn't that the point of the D programming language or am I misremembering?

ScholRLEA

@tar said:

Someone should take Bjane up on the "smaller, cleaner language struggling to get out", and actually write that language.

Well, Java was supposed to be that, as was C#. Go figure.

I'm pretty sure that's what Digital Mars was trying to do, too, but I've never really looked at D so I can't say if they succeeded or not.

In any case, the idea of stripping down an over-sized language to get a smaller, cleaner one goes back at least to Algol-W in 1966, which Wirth created in part as a reaction to the protracted development of what would become Algol 68. The phrase about a smaller language struggling to get out actually comes from Tony Hoare's critique of Ada in 1984.

Kian

@ScholRLEA said:

Well, Java was supposed to be that, as was C#. Go figure.

How do you figure? The core concepts of C++ are multiparadigm, performance first, trust the programmer, RAII principle, and zero overhead abstractions. Neither Java nor C# follow all those core concepts. The "smaller language struggling to get out" would focus on that but providing a saner syntax.

C# and Java try to be replacements, not reincarnations.

blakeyrat

@ScholRLEA said:

Well, Java was supposed to be that, as was C#. Go figure.

?

C# definitely wasn't. And I highly doubt Java was.

They both just borrowed C syntax because it was popular. Heck, I don't even think C# borrows C++ syntax at all. You can't type Console << anInt << aString; in C#.

dkf

@tar said:

Maybe even give it a sane grammar as well

Woah there, Nelly! Let's not get too hasty…

dkf

@blakeyrat said:

And I highly doubt Java was.

That was one of the original design goals, though by adding managed memory and a single-rooted class hierarchy and removing operators and multiple inheritance, they diverged quite quickly. The differences over templates/generics are because the language split basically predated all that stuff (and C++ had to deal with the mess of having the type hierarchy be a forest).

tar

@powerlord said:

Wasn't that the point of the D programming language or am I misremembering?

I did look at D a few years back and didn't see anything compelling enough to switch at the time. My main objection was the "mixins" which were just a poor man's version of code generation with none of the actual features which make macros desirable.
Since than I hear the project has split into two incompatible standard libraries ()...

LB_

@Kian said:

The core concepts of C++ are multiparadigm, performance first, trust the programmer, RAII principle, and zero overhead abstractions.

@powerlord said:

Wasn't that the point of the D programming language or am I misremembering?

No, D uses garbage collection by default, so no trusting the programmer, no RAII (by default), and no zero overhead abstraction for memory.

@tar unfortunately the problem isn't compatibility with C any more (C has strict now, among other things), it's compatibility with older C++. They don't want to end up in a Python 2 vs Python 3 situation.

dse

@LB_ said:

They don't want to end up in a Python 2 vs Python 3 situation.

The situation could be a lot better if porting was as simple as:

with __soon_to_be_obsolete_ptyhon2_fixme_I_AM_LAZY_FIRE_ME__:
    print 'hello'

Similarly C++100 could drop C compatibility along with the ugly bits of older C++ ^[1] with a #pargma or something like this:

extern "unsafe" {
    char * pUgly = new char[5];
    ...
    delete[] pUgly;
}

_{[1] Why do you need ugly ass Functors when there are lambdas, ...}

Cursorkeys

@dse said:

with a #pargma

I've always wondered why the preprocessor directives are named "pragma". Never seen an explanation anywhere. Maybe some sort of contraction of preprocessor argument something something...

I asked a senior lecturer in University and got 'because they are'.

TwelveBaud

In an idealized world, all features supported by any compiler would be part of a standard, the same standard that all other compilers follow. There would never be interoperability concerns, because there'd be nothing out-of-standard to be concerned about.

We don't live in an idealized world. We can't afford to be a perfectionist. Sometimes we must suck it up and be pragmatic.

Bulb

@Cursorkeys said:

I've always wondered why the preprocessor directives are named "pragma". Never seen an explanation anywhere.

Have you tried wikipedia?

@Cursorkeys said:

Maybe some sort of contraction of preprocessor argument something something...

Given that most of them are not consumed by the preprocessor, but rather by the compiler, that does not make sense. Apparently it is abbreviation of pragmatic something (instruction?), for whatever the hell that was supposed to mean, and it predates C by many years.

@powerlord said:

Wasn't that the point of the D programming language or am I misremembering?

Yes, it was. It still is. They even had some important C++ experts take part in the design.

@tar said:

My main objection was the "mixins" which were just a poor man's version of code generation with none of the actual features which make macros desirable.

My biggest problem with them was that the template-like kind is non-hygienic.

@tar said:

Since than I hear the project has split into two incompatible standard libraries ()...

Yes, that set the project back a lot. I believe it was resolved by the version 2, in which the standard standard library took over the most useful bits of the other and the other died (or mostly so) by neglect. Still I am not sure how comprehensive the standard library is and whether there is a reasonable system of dependencies. Which, these days, is much more important for usability of programming language than merits of the language itself.

@LB_ said:

No, D uses garbage collection by default,

C++ can, now, use garbage collection too.

@LB_ said:

so no trusting the programmer

Garbage collection is only a default. It can be opted out of.

@LB_ said:

no RAII (by default)

Yes, RAII is there and used for value types.

@LB_ said:

no zero overhead abstraction for memory.

I am pretty sure raw pointers are available. The only built-in abstraction is the garbage collector for reference (class) types.

LB_

@Bulb said:

C++ can, now, use garbage collection too.

Thank god it isn't forced.

@Bulb said:

Garbage collection is only a default. It can be opted out of.

Some languages beg to differ. It's also a horrible default.

@Bulb said:

Yes, RAII is there and used for value types.

Good :)

@Bulb said:

I am pretty sure raw pointers are available. The only built-in abstraction is the garbage collector for reference (class) types.

I guess I should have mentioned, I hardly know anything about D. Sorry.

EDIT: But that's still not what zero-overhead means.

dkf

@LB_ said:

Thank god it isn't forced.

QFT. GC is nice, but only if you are in that managed domain. Outside the managed domain, it's awful to integrate with; explicitly-managed memory is hugely simpler in that respect.

Bulb

@LB_ said:

Some languages beg to differ. It's also a horrible default.

I agree.

Worse, D is defined so that precise collector is not really possible and efficient collector requires generational and copying and that in turn requires at least mostly precise.

@dkf said:

GC is nice, but only if you are in that managed domain. Outside the managed domain, it's awful to integrate with; explicitly-managed memory is hugely simpler in that respect.

You can usually treat pointers from a managed pool as reference counted; every kind of pool has some pin and unpin methods. However if you try to integrate several in one program space, it becomes a mess.

It would be nice if there was a standard collector library that all the runtimes could be built to use, but there is nothing sufficiently generic (something like immix with its opportunistic compaction would be needed to support both the precise cases that want it and the conservative ones that can't have it) exists.

dkf

@Bulb said:

It would be nice if there was a standard collector library that all the runtimes could be built to use

It would also be nice if I was paid a million bucks an hour in this job. Not happening though.

caffiend

@dkf said:

QFT. GC is nice, but only if you are in that managed domain. Outside the managed domain, it's awful to integrate with; explicitly-managed memory is hugely simpler in that respect.

People who diss managed memory only ever bring up the problem of "knowing" when your imperfect, manually written (not properly maintained) resource allocation / relinquishment code is run. If you have a reasonable (not even expert level) understanding of the native interfaces provided by any managed language, and are happy to not try and be "clever" and "trick" it into behaving like C / C++, it's not hard to interface with a managed domain. Whether it be .NET, Java, Python, they all have well documented and fairly sensible native interfaces.

But all that aside, I can't believe people are happy to develop new systems in vulnerability vector languages like C / C++ / anything that uses naked pointers, or a casting system that lets you accidentally corrupt or read random memory, for any application aside from the lowest-level embedded systems, or the most demanding performance critical tasks (and i mean those with a "hard real-time" requirement - not that i want my database query to take 200 milliseconds instead of 225 milliseconds).

It doesn't matter whether it's heart bleed, or that period from 2008 to 2012 where just about every x64 port of any C++ app on any platform was littered with buffer overflow exploits. This sh*t will keep happening if we keep using these stupid languages. Yes, you can validate, and check, and make it actually secure, but it's boring and humans don't generally do boring things well.

Even if you're a weirdo who enjoys checking the return value of every function then meticulously comparing it to your allocated buffer sizes, remembering to add and subtract 1 in the right place, making sure to update your copy constructor, assignment operator, and all those stupid rules about virtual destructors and think that it's OK to do this every time you add a new field to your class... Just so you know when your memory is deallocated. It only takes one maintenance programmer to forget one of these things, and you're system will be pwned by Russian hackers.

Bulb

@caffiend said:

But all that aside, I can't believe people are happy to develop new systems in vulnerability vector languages like C / C++ / anything that uses naked pointers

C uses naked pointers. However, modern C++ does not. I write C++ for living and I didn't have invalid pointer problem for ages. C++ gives you enough rope to hang yourself, but it also gives you enough rope to secure yourself properly if you know how to use it.

@caffiend said:

It doesn't matter whether it's heart bleed

Remember, OpenSSL is C, not C++. They are different languages. Very different languages.

@caffiend said:

Even if you're a weirdo who enjoys checking the return value of every function then meticulously comparing it to your allocated buffer sizes

No, I don't. I use functions that throw (which you can't in C; remember, C and C++ are different languages).

@caffiend said:

remembering to add and subtract 1 in the right place

The trick is being consistent and not having to add and subtract 1 anywhere, ever. Because the rules (in C++ with ranges; I don't care about the old C ways) are actually well designed.

@caffiend said:

making sure to update your copy constructor, assignment operator

That is especially problem in Java (java.io.Closeable) and C# (system.IDisposable) where you have to dispose the resources explicitly. In C++ you just follow the rule of zero, because with RAII the resource management automatically composes correctly.

@caffiend said:

and all those stupid rules about virtual destructors

In modern C++ most polymorphism is static and dynamic polymorphism is pretty rare. And cases where dynamically allocated polymorphic object is deleted via base pointer is even more rare. Yes, when you do them, you need virtual destructor. There is a quire reliable warning for it.

@caffiend said:

think that it's OK to do this every time you add a new field to your class...

It isn't. That's why I am using a language with proper RAII and not a joke like Java or C# where one has to compose the disposes manually.

Yes. C++ is dangerous. It does give you enough rope to shoot yourself in the foot. But the rope also allows you to build abstractions that are both efficient and easy to use in a way Java or C# can't even dream of.

@caffiend said:

aside from the lowest-level embedded systems

One more thing. C++ is still the only (ok, also C, but that is hard to work in) language portable across Windows CE, Android, iOS and Windows Phone in which you can process non-trivial amounts of data (the other option is JavaScript and that is confined to the browser).

LB_

@caffiend said:

I can't believe people are happy to develop new systems in vulnerability vector languages like C / C++ / anything that uses naked pointers

Raw pointers are almost never used in modern C++.

@caffiend said:

This sh*t will keep happening if we keep using these stupid languages.

Who watches the watchers?

@caffiend said:

Even if you're a weirdo who enjoys checking the return value of every function then meticulously comparing it to your allocated buffer sizes, remembering to add and subtract 1 in the right place, making sure to update your copy constructor, assignment operator, and all those stupid rules about virtual destructors and think that it's OK to do this every time you add a new field to your class... Just so you know when your memory is deallocated.

So glad I don't have to work in C.

caffiend

Wow, i wasn't expecting such a detailed response.

You're right, it is possible to use modern C++ to produce reliable and secure systems. However, my experience has been that it's not possible to use C++ to have a non-trivially sized team produce reliable and secure systems. If you're forced to have raw grads on your team, you DON'T want them working in C++, because they were taught from a 10 year old textbook, by someone who'd never written a line of commercially viable code in his life. It's equally un-viable if you need to have someone with 10 years commercial experience who isn't also a passionate hobbyist working on your team.

Again, this is just my opinion. I don't hate the language, just think it should be reserved for the niche environments where it adds value. Even then only in the hands of passionate and skillful developers such as yourself.

I'm genuinely surprised to hear that you've got cross-platform code that can be practically deployed across all the platforms you mentioned. Why you'd want to process non-trivial amounts of data using a phone is also beyond me, but how am i to know your domain.