The Old Joel on Software Forum: Part 4 (of 5)

const--use it?

Hi.

How many of you here are careful to always to declare the function parameters you don't modify as "const?" Is there any significant preformance/readability improvement for doing so? Or do you think it's just a waste of time and space?

live four ever.
Monday, March 15, 2004

In some languages they will save compile time constants in different places and make optimizations to ensure quick look ups. The routines you use to access constants may also operate faster by bypassing some of the necessary flexibility (inefficiencies) required for mutable strings.

Li-fan Chen
Monday, March 15, 2004

I always try to keep an eye on const-correctness. It's really nice to know that the method you're calling will not modify the object you're passing in. This is particularly important in threaded environments where I might have to synchronise access to the object if the method were going to change it.

Jeff Watkins
Monday, March 15, 2004

Not using const is just sloppy programming.

By using const you eliminate the possibilities of a dependency, and when thinking through the logic, you know that data won't change. Just one less thing to worry about so you can concentrate on the things you need to worry about.

hoser
Monday, March 15, 2004

I can't tell; there are a lot of things like const correctness that strike me as the result of the fact that you have to be massively obsessive-compulsive to write code that stands a reasonable chance of working, and language features like const correctness feed off of programmer's incredible temptation to yield to new opportunities to be obsessive compulsive about things.

Joel Spolsky
Fog Creek Software
Monday, March 15, 2004

I like 'const' (mostly for readability and correctness reasons, not run-time performance).

Once you start to use 'const' at all then you find you need to use it consistently: because for example if you have a reference-to-const-object, then you can't call any method of that object except methods that you've bothered to declare as being const methods.

I'm noticing that C# doesn't support const objects or const methods.

Christopher Wells
Monday, March 15, 2004

I read what Joel said twice and still have no idea what he meant.

I always use constants, and take care to never hardcode a string or integer etc. I just like it and think it makes things a whole lot easier on me.

Aussie Chick
Monday, March 15, 2004

"you have to be massively obsessive-compulsive to write code that stands a reasonable chance of working"

Agreed.

"opportunities to be obsessive compulsive about things"

So that would be a good thing, right?

hoser
Monday, March 15, 2004

"I'm noticing that C# doesn't support const objects or const methods."

There's really two reasons for this.

1. Not every language on the platform will have a concept of "const".

2. Not everybody is anal retentive about using const, which means you end up needing to cast it away, which eliminates almost all the value.

I noticed the lack of it, and it did seem a little odd at first (coming from a C++ background), but I don't miss it.

Latent typed generics I DO miss, and it seems we won't really be getting those in C#... so I'll continue to have to use code generation tools to get around their absence.

Brad Wilson (dotnetguy.techieswithcats.com)
Monday, March 15, 2004

"Latent typed generics I DO miss, and it seems we won't really be getting those in C#... so I'll continue to have to use code generation tools to get around their absence."

Or just use a better language to start with (I know, I know, the programmer often doesn't get to choose his tools).

Sum Dum Gai
Tuesday, March 16, 2004

"Not everybody is anal retentive about using const, which means you end up needing to cast it away, which eliminates almost all the value"

I cannot see how somebody else not using const would force you to use const_cast<>.
Const correctness is part of good OO design, and understanding how the design maps to C++.

Craig
Tuesday, March 16, 2004

i am scrupulously const correct and yet in many years of doing so not once has it helped me find or avoid a bug. So it would seem to be absolutely useless. Yet I do it anyway, cluttering up my code with its verboseness.

Dennis Atkins
Tuesday, March 16, 2004

its had never helped you avoid a bug? Or to find a bug?

I find it helps me for that reason all the time.

Aussie Chick
Tuesday, March 16, 2004

"I cannot see how somebody else not using const would force you to use const_cast<>."

Because you want to mark something as const yourself. However, if someone else doesn't mark their method as taking a const parameter, or being a const method, you'll have to remove the constness from your object to allow it to be used with non-const correct code.

I find const correctness pretty useless myself. I think it's much like the idea of exception specifications: sounds really useful in theory, but in practice it doesn't really buy you anything, and it costs you time.

Then again, I prefer latently typed languages, so if you're an explicit typing person, YMMV.

Sum Dum Gai
Tuesday, March 16, 2004

its like always putting an immutable on the LHS of a condition to avoid accidently assigning instead of testing, or whatnot. Const helps spot compile-time bugs.

i like i
Tuesday, March 16, 2004

If you are serious about trying to understand how it works you may find those couple of articles useful.

http://www.gotw.ca/gotw/006.htm

http://www.gotw.ca/gotw/081.htm

Cheers,

doesn't_really_matter
Tuesday, March 16, 2004

"its like always putting an immutable on the LHS of a condition to avoid accidently assigning instead of testing, or whatnot. "

I don't do that because it decreases readability. The English language is read left to right, hence when you put the immutable on the LHS, you're usually making the English intention backward with respect to the code. I see no reason to make my code harder to read just to prevent a mistake a decent compiler will warn me about anyway.

You have to weigh up costs in any development choice. Rule like the "always put the immutable on the LHS" strike me as only seeing the positive and jumping in, without ever stopping to weigh up the pros and cons.

Sum Dum Gai
Tuesday, March 16, 2004

I agree, from a practical standpoint, since not everyone uses it, it is a headache. Trying to convert/interface code that is not const-correct with code that is is a pain. Also in C++ it is annoying because not everyone declares it the same way, e.g.

const int x;
int const x;

Roose
Tuesday, March 16, 2004

I use it whenever possible. Which is when some idiot clown manager hasn't decided it's "too hard" or "doesn't work" because they can't use it.

It's helped me avoid tons of grief, makes me think about object interfaces properly and allows me every once in a while to curse the people who haven't implemented "mutable" in their compilers yet for those "we do LOGICAL const, not BITWISE const" moments....

I think it's one of several techniques which when used correctly vastly improve the efficiency of development in C++.

Katie Lucas
Tuesday, March 16, 2004

> I read what Joel said twice and still have no idea what he meant

I think what Joel meant was that

a) You really have to try hard to do it properly;
b) Programmers like trying out new things; and
c) Programmers will spend a lot of their brain-time worrying about const correctness

Which to me implies
d) As a result programmers will take their eyes off the other dozen or so balls they are trying to juggle and everything will come crashing down around their ears

I still ike it, but I agree with Sum Dum Gai - a lot of code you try to use (libraries and so on) are not const correct and therefore you will end up losing some of the benefits to work around that.

Tuesday, March 16, 2004

And I have a practical use for const-correctness: transactions.

I have implemented a transactional in-core store. A transactional object is accessed using a transactional smart pointer. So:

typedef XactRef<Foo> FooRef;

FooRef f;
XactionRef xact;

f->method(); // dereference results in a const Foo *.
f(xact)->method(); // function call operator overload produces a non-const Foo *, which calls mutating method.

The function call overload makes a backup copy of the object pointed to by f. If the transaction is rolled back, the backup is restored. If the transaction is committed, then the backup is leaked. The Boehm-Demers-Weiser conservative garbage collector comes along and cleans up.

Works quite well in practice, and const-correctness is REQUIRED.

David Jones
Tuesday, March 16, 2004

> language features like const correctness feed off of
> programmer's incredible temptation to yield to new
> opportunities to be obsessive compulsive about things.

Ha! This from the guy who doesn't like to throw exceptions because it creates multiple exit points for a routine?! Sounds obsessive compulsive to me! ;P

Ian Olsen
Tuesday, March 16, 2004

"its like always putting an immutable on the LHS of a condition to avoid accidently assigning instead of testing, or whatnot."

It's not 1993 any more. Your compiler catches this.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, March 16, 2004

I just received an update to a 3rd party (C language) library. In previous email I had requested that they use const in their interfaces whenever they don't intend to modify the pointers that I pass in.

Did they change? Hell no. Like the rest of their shit, its jsut plain sloppy, half baked crap. Cow pie extraordinaire. The stench is horrendous.

hoser
Tuesday, March 16, 2004

< you have to be massively obsessive-compulsive to write code that stands a reasonable chance of working >

Well, duh. The reason most code sucks is that most people *aren't* massively obsessive-compulsive. One of the differences between a big pile of sphagetti code and halfway maintainable code is that someone, somewhere was a complete anal retentive jerk, and did things like - GASP - enforce coding standards and - GASP - make the 20-somethings rewrite their crappy, off-the-hip, "eL33t" code.

If you're over 20 and no one has ever called you anal-retentive, please get out of the business now. Do us all a favor...

Grumpy Old-Timer
Tuesday, March 16, 2004

"The reason most code sucks is that most people *aren't* massively obsessive-compulsive."

One could argue that any language that requires massive obsession-compulsion is fundamentally broken for most people. Sure, experts can make C++ sing, but most people suck, so they shouldn't be using it.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, March 16, 2004

> Sure, experts can make C++ sing,
> but most people suck, so they
> shouldn't be using it.

Excellent. This is one of the best indictments of C++ I have ever seen.

Eric Sink
Tuesday, March 16, 2004

When you're writing your classes, do you really have no idea whether the function you're adding is a const one or not? Do you often have trouble working out whether you want a const variable or a const parameter? I'm genuinely confused as to why it's so hard to work out.

The plot may thicken a bit with virtual functions. But no more so than as is normal with virtual -- constness in C++ is just part of the contract, so it's no tricker than making sure you have the right parameters and return values.

I've been berated a bit in the past for using const in C++. I find it all a bit strange. People seem to be able to work out when to use float instead of unsigned char, and yet the idea of const is treated as some kind of mystery. Very odd.

Insert half smiley here.
Tuesday, March 16, 2004

I'm with Katie Lucas, Grumpy Old-Timer, "Insert half smiley here" and Brad Wilson on this one.

Const is well worth learning to use properly, it's easy to know if you need it at the time you're writing the code and most people who use C++ shouldn't be doing so...

The problem is, looking at code in C# and VB on some client sites leads me to the conclusion that most people who use those languages shouldn't be doing using them either... What young people today need is a bit more discipline ;) ...

Len Holgate (www.lenholgate.com)
Wednesday, March 17, 2004

Const is useful because it enforces what would otherwise simply be a convention in a comment.

Mr Jack
Wednesday, March 17, 2004

hafl smiley: It's not so much that *writing* const correct code is hard, so much as *transitioning* to const correct code is a pain, because interfacing between const and non-const requires extra casting and losing your const guarantee

There can also be ambiguities that make it difficult, in determining whether a method should be non-const, or whether it should be const and the data it operates on should be mutable

MikeMcNertney
Wednesday, March 17, 2004

> > Sure, experts can make C++ sing,
> > but most people suck, so they
> > shouldn't be using it.

> Excellent. This is one of the best indictments of C++
> I have ever seen

Sure, experts can make a laser scalpel sing, but most people suck, so they shouldn't be using it. This is one of the best indictments of laser scalpels I have ever seen. We should definitely make surgeons do their work with putty knives.

Grumpy Old-Timer
Wednesday, March 17, 2004

That would be apropos, if people believed that all tasks should be done with a laser scalpel.

Unfortunately, there are people who believe that of C++.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, March 17, 2004

>"you have to be massively obsessive-compulsive to write
>code that stands a reasonable chance of working"

It pays off in two situations

- writing libraries for use by other people
Now that's a situation where you want your intent to be clear to others. const is another guard against misuse.

- application code in very large projects.
People change, requirements change, the code that one writes today has to be readable in years.

Michael Moser
Thursday, March 18, 2004