News for hackers. Stuff that matters.
Re:A brief introduction to C++'s model for type- and resourc... by 72deluxe on Friday January 15, 2016 @09:28AM (#10909467)
I would have thought that non-const references was better? It is clear that a non-const reference can be modified. If I just wanted to let them read a value, a const reference would be clear.

Do Google enforce const pointers for arguments that define where to store results? If not, you could delete the pointer they pass you. A pointer does not always indicate who owns the data clearly.

Far better would be to return the values from the function (or std::move them out if you must) instead of using a parameter as a "dump your results here" flag.

Stroustrup encourages this (see 5.3.3 of C++ 4th edition where he says "I don’t consider returning results through arguments particularly elegant"). IMHO, it would be better to return a std::pair<bool, std::vector<myWonderfulType>> where bool indicates the success/failure of the function, with pair.second item being the results.

Re:A brief introduction to C++'s model for type- and resourc... by zarkov99 on Friday January 15, 2016 @12:28PM (#10910704)
Pointers have the advantage of signaling a return value at the call site without having to look up the function prototype.
Re:A brief introduction to C++'s model for type- and resourc... by pjmlp on Friday January 15, 2016 @01:35PM (#10911128)
Which I don't agree with, given the amount of pointers that fly around in C codebases.

You cannot ever known what a pointer is used for.

If the prototype has const, maybe just maybe, assuming the function doesn't cast it away, it is a read only.

So I never bought into this argument.