What's wrong with just a runtime-checked const?
Reiner Pope
reiner.pope at gmail.com
Tue Jul 18 13:20:30 PDT 2006
Bruno Medeiros wrote:
>> Can you suggest another solution other than avoiding const-checking
>> entirely? By the way, a dedicated string class is actually an
>> implementation of runtime const checking.
>>> but, it's certainly not a pretty solution... and there's a related
>>> question - how can tolower know whether to .dup or not.. there are
>>> certainly cases where it isn't necessary.
>> This is just another issue that static checking can't solve but
>> runtime checking can (providing we have a modification of the
>> libraries to support a CoW and a in-place version).
>
> I'm not following you. That code example shows how a static const
> checking should work, so what is the problem with that?
> And in:
> char[] name_m = tolower(name);
> // Can we modify name_m? Better dup it, just to make sure
> You ask if we can modify name_m, the answer is yes if the return type of
> tolower is non-const, no if it const, so what's the issue here?
You seem to have ignored my more recent example. The problem is that
static checking *forces* the return value to be const, which in turn
forces you to dup it. You don't always need to do that:
>> char[] tolower(const char[] input) /* the input must be const,
because we agree with CoW, so we won't change it */
>> {
>> // do some stuff
>> if ( a write is necessary )
>> { /* copy it into another variable, since we can't change input
it's const)*/
>> }
>> return something; /* This something could possibly be input, so it
also needs to be declared const. So we go back and make the return value
of the function also a const. */
>> }
>>
>> // Now, since the return value is const, we *must* dup it.
>>
More information about the Digitalmars-d-learn
mailing list