Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I don't doubt that just duplicating macros and inlineable
> functions is a wash performance-wise (in fact, in principle it
> shouldn't change the generated code at all).
I had the impression that compilers these days could sometimes
better optimize across calls to functions with const parameters,
because previously-referenced elements of the structures could be
trusted to be unchanged across the call. I'm not talking about
calls to the inlineable function or macros themselves, but the
higher level functions which can then use const.
> My objection is the one Robert already noted: it takes extra brain
> cells to remember which function/macro to use, and I have seen not
> a shred of evidence that that extra development/maintenance effort
> will be repaid.
Well, for me at least, seeing a parameter flagged as const helps me
be sure that it will be use only for input to the function, and thus
more quickly grasp the semantics of the API. For someone who is
already familiar with an API, I doubt it helps much; and it may be
one of those cognitive differences that just exist between people.
As far as which to use when there is a const and a non-const version
-- how is that unclear? For me it seems intuitively obvious
(although perhaps my intuition is off-base) that I would use const
when I didn't want the called function to change what was pointed at
by the parameter. Maybe you're looking at the slippery slope more
than this one function and two macros, though.
> In C, the impedance match is a lot worse, so you have to pick and
> choose where const is worth the trouble.
Agreed. And I'm not sure how much of what Thomas is proposing is
worth it; it just seems prudent to consider it while the offer is
being made to do the work.
-Kevin