On 04/10/13 at 07:34pm, Rob Landley wrote: snip > > I think that some function parameters should be made const and that > > the code could be made less repetitive. > > I specify "static" because it allows the compiler to produce better > code, but I've never found "const" to actually produce better code. The > compiler's optimizer does liveness analysis, it can tell when you don't > actually change a value after it's assigned to. In theory const lets > the compiler do some of this across translation units, but that's what > link time optimization is for these days. > > In addition, const's syntax is unfortunately subtle when pointers are > involved. Is the pointer what's const, is what it points to that's > const (it binds left except at the left edge...), how about a pointer > to a pointer, or pointer to an array... > > I also haven't seen it interface well with the actual read-only > sections ELF can produce. There's an -mebedded-data compiler flag that > says to put data in the .rodata section. The main use of .rodata is to > strings constants in there by default. Yet those strings aren't > "const", you can assign a string constant to a regular char * without > the compiler ever complaining. (And not being able to do so would > pretty fundamentally break C.) > > What const really seems like to me is a leakage from C++'s "public, > private, protected" into C. It's a language facility that assumes > programmers can't trust themselves or their successors to get it right.
I'd thought telling the compiler stuff can't hurt. Thanks for the detailed explainations. > So I tend to remove "const" from the code when I can. It doesn't > justify its existence: if we're not supposed to modify the value from > here, then don't do it. I trust the programmer to not suck, and I trust > reviewers to catch it when they screw up. I'll keep that in mind. > Rob Felix _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
