Any word on the return-type const syntax?
Stewart Gordon
smjg_1998 at yahoo.com
Sat Dec 8 18:16:50 PST 2007
"Janice Caron" <caron800 at googlemail.com> wrote in message
news:mailman.263.1197106829.2338.digitalmars-d at puremagic.com...
> On 12/8/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>> Janice Caron wrote:
>>> Here's a typical problem.
>>>
>>> class MyArray(T)
>>> {
>>> T[] a;
>>>
>>> T* ptr() { return a.ptr; }
>>> const(T)* ptr() const { return a.ptr; }
>>> invariant(T)* ptr() invariant { return a.ptr; }
>>> }
This doesn't work for me. Add any one (or more) of
MyArray!(int) a;
const(MyArray!(int)) c;
invariant(MyArray!(int)) i;
and I get (DMD 2.008)
transfer_const.d(7): Error: cannot implicitly convert expression
(cast(int*)(this.a)) of type int* to invariant(int)*
>> > A template helps how, exactly?
>>
>> TransferConst!(U,T) ptr(this U)() { return a.ptr; }
>
> There are several things I don't understand about this example. You
> seem to be suggesting that
>
> TransferConst!(U,T)
It doesn't seem to exist, according to a search through the DMD and Phobos
code.
<snip>
> The next thing I don't understand is the notation
>
> ptr(this U)()
http://www.digitalmars.com/d/template.html#TemplateThisParameter
However, it crashes DMD when I try to use it in a class member function.
Need to investigate....
> How does that even parse? I'm not familiar with this means of
> specifying template parameters. What does it mean?
>
> The third thing I don't understand is, I see no specication of the
> constancy of the member function itself. I expect to see either
> const-at-the-end, or const-at-the-start, but I see neither. Where is
> it?
In the aforementioned (this U), I think.
<snip>
> K(this) K(T)* ptr() { return a.ptr }
>
> I think my way looks most readable, but you tell me. I don't actually
> care what the replacement symbol is. Obviously, "K" is an unwise
> choice, but you could use any reserved word (I believe "return" was
> suggested in your document), or even some combination of reserved
> words like "const in" and "const out", or whatever. (And I'd also like
> the symbol to be available within the body of the function).
"return" doesn't seem to make any sense. I think constness template
parameters (defined as a special case that generates only one instantiation)
would be a good way to go - this would also make it possible to parameterize
something on the constness of more than one entity. How about
K(T)* ptr(constness K : this)() { return a.ptr }
> One really important point to consider is that you need EXACTLY ONE
> instantiation of the function. That is, the bytes of machine code
> which comprise the function would be identical in all three cases, and
> therefore need to exist only once. I suspect that your template idea,
> in addition to robbing me of virtuality, would also instantiate the
> function three times.
I've a vague recollection of reading somewhere that templates that differ
only in constness are already defined to reduce to a single instance, but I
can't seem to find it at the moment.
But really, because of the possibility of bits of code being conditional on
constness, we need to have both options available somehow.
Stewart.
--
My e-mail address is valid but not my primary mailbox. Please keep replies
on the 'group where everybody may benefit.
More information about the Digitalmars-d
mailing list