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