Pervasive non-constness of (read) accessor methods

[GoogleCodeExporter]

Widget, for instance, has a method with the signature

  const std::string& getId();

If this instead was

  const std::string& getId() const;

you would reap the following benefits:

1. Additional compiler optimizations.
2. get/set methods could be used directly by LuaBind.

This applies to most of these accessor methods on all platforms, etc.

While 2 is the reason I've had a go at the problem, general code quality
and 1 would seem to make this a no-brainer apply-check-forget patch. 

Non-constness to allow performing some mutating operation on objects might
seem to be in line with the principle of keeping options open, but in these
cases it would be very surprising. (and therefore wrong.)

Submitted patch file is against 0.8.1 and may be a bit stale and/or incomplete.

Original issue reported on code.google.com by c96...@gmail.com on 28 Oct 2008 at 12:04

Attachments:

• guichan-constness.diff

[GoogleCodeExporter]

I fully agree with this patch.

Original comment by b.lindeijer on 28 Oct 2008 at 9:36

[GoogleCodeExporter]

I agree as well. I've always strived for const correctness in Guichan.

Original comment by olof.nae...@gmail.com on 1 Dec 2008 at 3:51

[GoogleCodeExporter]

Original comment by olof.nae...@gmail.com on 1 Dec 2008 at 6:15

• Changed state: Fixed