This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ coding conventions: namespaces, references and getters (was Re: [PATCH 2/2] Introduce beginnings of a pipeline class.)

On Mon, Aug 5, 2013 at 6:24 AM, Martin Jambor <> wrote:
>> > Note that as per
>> >
>> > 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

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]