Increasing usage of C++ references?

[Markus Elfring]

I have taken another look at a class like SymbolDatabase. Can the interface design be improved a bit by replacing the usage of pointers with references?

[Daniel Marjamäki]

If you just replace some pointers with references... what is the improvement? I am not against that pointers are used.

[Markus Elfring]

what is the improvement?

• You do not need to be concerned for null pointers because references must be connected with something. It can become possible to omit sanity checks then.
• The source code can become a bit shorter when you write single dots instead of the “arrow” (two characters) for member accesses.

Would you like to consider any more software design constraints?

[Daniel Marjamäki]

If we compare this code:

#include <iostream>
#include <string>

void f(std::string &s) { s = "abc"; }

int main() {
    std::string *s = 0;
    f(*s);
    return 0;
}

And this code:

#include <iostream>
#include <string>

void f(std::string *s) { *s = "abc"; }

int main() {
    std::string *s = 0;
    f(s);
    return 0;
}

Both codes will crash at runtime. I can compile both code examples and I don't even get a warning (g++ version 6.3).

With static analysis code #1 gives me this warning:

[1.cpp:9]: (error) Null pointer dereference: s

With static analysis code #2 gives me this warning:

[2.cpp:4]: (warning) Possible null pointer dereference: s

So the runtime behaviour / compiler behaviour / static analysis results are equivalent.

[Markus Elfring]

I can compile both code examples and I don't even get a warning

Will any other compiler versions (besides additional analysis tools) provide better diagnostics for such questionable source code?

Do the function parameter types indicate a different usage intention at least?

[Daniel Marjamäki]

Will any other compiler versions (besides additional analysis tools) provide better diagnostics for such questionable source code?

In my opinion, probably.

Do the function parameter types indicate a different usage intention at least?

yes it does. I agree with that. But no I still don't want to have references everywhere.

[Markus Elfring]

I agree with that.

Thanks for such a feedback.

But no I still don't want to have references everywhere.

I do also not want to use them “everywhere”. But I am still trying to achieve that they will be used at more source code places where it makes sense.

[Markus Elfring]

If we compare this code:

• Would you like to clarify software development consequences any more around “null references”?
• How will source code checks evolve further for undefined behaviour?

[Markus Elfring]

I am not against that pointers are used.

• You have got also a special software development view on this design aspect. Can it be that this kind of wording expresses change resistance for an evolving code base?
• I would appreciate if the software situation can be improved further there. How do you think about to increase source code safety in any related ways?

[versat]

What i find very interesting related to the question if pointers or references should be used is the Google style guide and their decision:
https://google.github.io/styleguide/cppguide.html#Reference_Arguments
Only const references are allowed as function parameters, otherwise a pointer has to be used.
As far as i understand they do not allow non-const references because it is sometimes not obvious that the parameter is not passed by value because of the different syntax. That can lead to harder readable code and maybe more errors.

I really like references and use them myself very much but i can understand Googles decision here. They surely have so much experience with software development that they do not create such rules without a reason. The guide aims at avoiding errors and help for better readability, which is important especially when many people work on a project (like it is also the case with Cppcheck).

And like Alex Allain writes in the article you linked, references are not absolutely safe too. And he also writes that references to dynamically allocated memory are not really a good idea.

So IMHO it has nothing to do with change resistance or something like that when one says that pointers still have their place for specific tasks in C++ software development.

[Markus Elfring]

They surely have so much experience with software development that they do not create such rules without a reason.

We hope so.

I wonder if the presented wording is really sufficient in this guide.

…
Cons:
References can be confusing, …

But I have got the impression that an other general software development concern is more relevant here:
Data immutability

… input arguments are values or const references while output arguments are pointers. …

And like Alex Allain writes in the article you linked, references are not absolutely safe too.

One safety concern is triggered by undefined behaviour because of a null pointer access which could have happened somehow before.

And he also writes that references to dynamically allocated memory are not really a good idea.

There are the usual constraints to consider for object lifetimes. The C++ programming language provides also some support to adjust software failure probabilities around resource management.

So IMHO it has nothing to do with change resistance or something like that

There can be more behind the raw information. It might be given because of further concerns around programming interface stability.

when one says that pointers still have their place for specific tasks in C++ software development.

Pointers are useful and can be still required at some source code places. I would find it nicer when further function parameters will indicate that a null pointer should not be tolerated there just by the usage of a reference data type.

[Daniel Marjamäki]

(sorry for the late reply)