using a typedefed variable with library classes
Charles Hixson
charleshixsn at earthlink.net
Wed Jan 14 16:37:49 PST 2009
Sergey Gromov wrote:
> Sun, 11 Jan 2009 18:09:15 -0800, Charles Hixson wrote:
>
>> Well, my use case just involves being able to use library function with
>> the proper base type. (I.e., int instead of long or byte when I do
>> typedef int LocalType;
>> LocalType t;
>> File f;
>> f.write(t);
>>
>> I'll grant that I *can* use alias for such a purpose, but that doesn't
>> distinguish between LocalType and ArrayIndex in routines defined for
>> those types. E.g.:
>> typedef int ArrayIndex;
>> void zeroIndex(out ArrayIndex ai) { ai = 0; }
>> zeroIndex(t);
>>
>> Should throw an error. If I'm using alias it doesn't (and shouldn't);
>
> Well, I presume File.write() has many overloads, including one for int
> but none for LocalType. When aliasing, the LocalType *is* an int, it
> matches exactly File.write(int) and the compiler is happy.
>
> However, with a typedef, LocalType is a distinct type. Yes it casts to
> int implicitly, but likewise it casts implicitly to char, short and
> long. So compiler gets a whole load of File.write() functions matching
> with conversions, and fails because of the ambiguity.
>
> That's how the language works, and it's pretty consistent IMO. What you
> can do is:
>
> f.write(cast(int)t);
>
> or use templates to generalize:
>
> auto fileWrite(T : LocalType)(File f, T v)
> {
> return f.write(cast(int)v);
> }
> auto fileWrite(T)(File f, T v)
> {
> return f.write(v);
> }
> fileWrite(f, t); // OK
> fileWrite(f, 15); // OK
>
> When we get generic function calls you'd be even able to write:
>
> void write(File f, LocalType l)
> {
> f.write(cast(int)l);
> }
> f.write(t); // OK, write(f, t) is called
A) Yes, it works the way that you say. This damages it's utility.
B) I'm replying to a question as to how typedef could reasonably be
extended.
More information about the Digitalmars-d-learn
mailing list