C++ links

Bjarne Stroustrup and Herb Sutter are putting together a set of C++ core guidelines. The main document is here, and it’s worth looking round the rest of the repository for more links, and slides of talks.

I haven’t read all of the guidelines yet (it’s a big document), but what I have looked at so far is good.

There’s a discussion about the core guidelines on Hacker News. Sadly, one of the comments argues that:

drawline(int,int,int,int);

is superior to:

drawline(Point,Point);

I despair of this industry on a regular basis. We certainly don’t know everything about programming (and I hope in 20 years we’ll be looking back and laughing at our naivete), but we don’t know nothing either. Grouping data values into bundles is not a new idea, it has many demonstrated benefits and yet people still argue against it. Writing good code is hard, and we just make it harder by ignoring even the most basic of guidelines.

I laughed at another of the comments:

I agree, these are too opinionated to be unconditionally useful.

It’s a document by Bjarne Stroustrup and Herb Sutter. I’d be disappointed if it wasn’t opinionated.

Videos from the 2015 CppCon are starting to appear on the CppCon YouTube channel. There are also plenty of videos from previous years.

Notes from Herb Sutter’s talk Writing good C++14… by default are here

4 thoughts on “C++ links

  1. Adam M. says:

    Hi Bob,

    I’m curious to know what you think about the advice about when to use a parameter of type T& (where T is not necessarily a template, e.g. func(int a, int b, int &c, int &d). They say it should be used for out and in-out parameters. But personally, I greatly dislike parameters of type T& and I never use them.

    The reason is that you can’t tell at the call site whether your variables may be modified or not. So in func(a, b, c, d) it’s not at all obvious that a and b are being passed by value (and won’t be modified) and c and d are being passed by reference (and might be modified). In C and in C# and in many other languages, arguments are passed by value, and you must make it clear at the call site when you want to deviate from that, e.g. func(a, b, &c, &d) or func(a, b, ref c, ref d). Otherwise, you have to know how the callees work in order to understand what’s happening with the variables in the current function, and if a function is later changed to modify an argument when it didn’t previously the callers may be none the wiser, and this is a source of error.

    Does it also bother you that T& obscures the difference between pass-by-value and pass-by-reference?

    — Adam

    • Bob says:

      Short answer

      I agree with you, but the rest of the world doesn’t.

      Long answer:

      I’m with you on this one, the guideline to use a pointer for out parameters makes perfect sense to me. We used to be in good company, on his webpage, Stroustrup writes:

      I do want to change the argument, should I use a pointer or should I use a reference? I don’t know a strong logical reason. If passing “not an object” (e.g. a null pointer) is acceptable, using a pointer makes sense. My personal style is to use a pointer when I want to modify an object because in some contexts that makes it easier to spot that a modification is possible.

      http://www.stroustrup.com/bs_faq2.html#call-by-reference

      and in The C++ Programming Language 4e (section 12.2.1) he writes:

      passing pointers is often a less obscure mechanism for dealing with objects that need modification than using references.

      However, I say “used to be in good company” because if you look at the more recent C++ guidelines from Stroustrup and Sutter they state very clearly:

      For an “in-out” parameter: Pass by non-const reference. This makes it clear to callers that the object is assumed to be modified.

      https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-conventional

      To be fair, Stroustrup and Sutter do not advocate out parameters at all, instead they argue:

      Prefer return values to output parameters … If you have multiple values to return, use a tuple or similar multi-member type.

      Between the new tie functionality for accessing individual elements of a tuple, and move operations this is a much more palatable solution than it used to be pre C++11.

      One additional data point, the Google style guide states:

      In fact it is a very strong convention in Google code that input arguments are values or const references while output arguments are pointers

      I think I first read about the “pass by pointer” rule in an Allen Holub book and it made perfect sense to me. I remember going into work the next day and trying to convince the rest of my team that they should follow this rule. The rule made absolutely no sense to them, and their arguments against it made absolutely no sense to me.

      In practice, I have rarely seen this rule followed (except in my personal code), but I have also seen very few problems caused by using non-const references. In my experience it doesn’t seem to trip anyone up.

      > Does it also bother you that T& obscures the difference between pass-by-value and pass-by-reference?

      In a theoretical sense yes it does, but as I said above, practically it hasn’t been a problem. Of course I am drawing on my own experience – just because I haven’t seen it blow up doesn’t mean that it has never blown up.

      * There are things such as operator << where you have to use a non-const reference. They are, of course, exempt from this rule.

  2. John Payson says:

    One concern I have about the “pass-by-pointer” concept is that given:

    int x;
    foo(&x);
    x++;
    bar();
    x++;

    If foo() receives &x as a “int const *”, that would suggest that bar() won’t modify x, but it won’t give any indication as to whether it might read the value of x. By contrast, if foo() had received x as an “int&” there would be a strong implication that foo() should not persist any kind of pointer to it, and thus bar() should have no way of accessing it at all.

Leave a Reply

Your email address will not be published.