On Mon, Aug 5, 2013 at 6:24 AM, Martin Jambor <mjam...@suse.cz> wrote: […] >> > Note that as per >> > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01365.html >> > we'll use "pass_manager" rather than "pipeline", so this would look >> > like: >> > pass_manager &get_passes () { gcc_assert (passes_); return *passes_; } >> > >> > We were chatting about C++ references on IRC on Friday, and IIRC there >> > was a strong objection to passing *arguments* that are non-const >> > references, >> >> I hope nobody is objecting to std::swap for example. > > I'm not sure how I could object to std::swap or what good would that > be. Apart from being the standard, it is also rather exceptional due > to its nature and its name.
I suspect it is a mistake to think this situation is unique. I also think that we can keep going on and a long list of examples, and that might still be labelled special case. Reading into a variable is just another example. > Despite this special example, I think the > rule of not passing arguments as non-const references is a good one, > and it seems I am not alone. Where I may differ from others is that I > also think that getter functions should (generally) return pointers or > const references too, and for similar reasons - the caller may > unintentionally modify data that the programmers thought were on the > stack but were in fact elsewhere else and "belonged" to someplace > else. But the rule does not solve that problem -- 'const' does not mean this is on stack, and absence of const does not mean this is on free store. Being on stack does no necessarily mean don't change, and being on free store does not mean you can freely change. As a matter of fact, in the existing code base, we have many objects on the stack that are passed around by non-const pointer. That is just fine for the most part. The notion of const is largely orthogonal to the notion lifetime (stack of free store.) These are problems that depend on the specific algorithms being implemented. Legislating on const reference or not won't solve any problem there. -- Gaby
