const is an overrated concept that is a source of extra typing and maintenance
in [C++]
|
Prev: Customizing compare in bsearch()
Next: const is an overrated concept that is a source of extra typing and maintenance
From: GMan on 24 Mar 2010 15:17 On Mar 24, 12:24 pm, mattb <matthew.b...(a)l-3com.com> wrote: > I have recently heard the above, along with a further statement along > the lines of - > > 'const is there to stop amateur slip ups. Professionals should know > what a function is expecting and should use that.' > > Could I please have some comments on these statements. > > Cheers, > Matt. > Seat-belts are there to protect inexperienced drivers from dying in a crash. Professional drivers do not need seat-belts, they should know their environment and drive accordingly. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Goran on 25 Mar 2010 02:11 On Mar 24, 8:24 pm, mattb <matthew.b...(a)l-3com.com> wrote: > I have recently heard the above, along with a further statement along > the lines of - > > 'const is there to stop amateur slip ups. Professionals should know > what a function is expecting and should use that.' > > Could I please have some comments on these statements. It would be funny if it wasn't sad, because the person who said that is likely considering him/herself a "professional". I hope he/she reads this. He/she essentially said is: given a random function rettype f(paramtype& p), a "professional" KNOWS whether f will, or will not, modify p. Reality is: no he doesn't, not every single time. When code is const-correct, then this fact is known up front, at compile time, and that information is easily available: just look at the signature of f! Here's what is the likely reality regarding "the professional": he/she is unable to come up with a cleaner, more correct design, and hence he thinks that const is bad. Another likely reality: there's a prior code that is not const-correct, and it's difficult to work with good const- correctness without changing it. Goran. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Goran on 25 Mar 2010 02:12 On Mar 24, 8:24 pm, mattb <matthew.b...(a)l-3com.com> wrote: > I have recently heard the above, along with a further statement along > the lines of - > > 'const is there to stop amateur slip ups. Professionals should know > what a function is expecting and should use that.' > > Could I please have some comments on these statements. (I know I wrote another post, but I am finding it hard to sustain myself). OK, here's a proposition: ask your "professional" to come up with a piece of code that shows const in a poor light in any way, and I'll show how it should be changed so that it's not the case. I claim that the difference between the two will be that changed code will require some more up-front thinking, but will be harder to break inadvertently. Goran. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Carl Seleborg on 25 Mar 2010 04:06 My own take at this is as follows: - Whoever complains about extra typing (for 5 characters) completely misses the point: it's about readability! Whenever I see "const", I stop worrying about what happens to that local variable or argument, it doesn't change and that makes it easier for me to reason about the code. Frankly, I don't think any seasoned programmer would agree that "writability" is more important that readability. - Maintenance only gets worse at the interface between code that is const-correct and code that is not. The rest of the time, "const" makes the life of the maintainer easier because it improves readability (see above). - const in C++ is too granular I think. This is where all the pain comes from (e.g. with templates, because it changes the signature and you often have to support two versions of a same method, etc). I think I would much rather have it a class level instead of function level (and keep it at local var level), just like the Java people do with idioms (like Tonni points out). In fact, I would even revert the concept: make a class immutable by default, unless it is declared as mutable. I think that would encourage correct programming much more efficiently, but that's just a hunch. Cheers, const Carl; -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter C. Chapin on 29 Mar 2010 20:03
Nick Hounsome wrote: > This is just wrong. > > You should never change a declaration to suit the implementation > (Unless is required to allow any sort of implementation - which isn't > the case here) Declarations are supposed to be about what a function > is going to do not how it is going to do it. > > In a big project you realy don't want to trigger a massive recompile > for something that has no semantic effect on callers. I'm talking about const local variables. Adding and removing const isn't any more disruptive to the program or the design as adding or removing other local variables entirely. The goal is to use const as a machine checked way of encoding certain data flow behaviors in the function being implemented. Later maintenence of the function that violates those data flow assumptions then stands a chance of being detected by the compiler. I realize using const like this is only partially effective. That's why I'm not sure how much of a difference it really makes. Peter P.S. Keep in mind that declarating a parameter const in a function's definition does not impact the declaration of that function: void f(int x); // In header file. Never changed. void f(const int x); // In implementation file. Add/remove const at will. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |