toString vs. toUtf8

Steven Schveighoffer schveiguy at yahoo.com
Mon Nov 19 14:53:01 PST 2007


"Sean Kelly" wrote
> Steven Schveighoffer wrote:
>> "Sean Kelly" wrote
>>> What I discovered during a test conversion of Tango was that converting 
>>> all uses of toUtf8 to toString /except/ those intended to perfom UTF 
>>> conversions reduced code clarity, and left me unsure as to which name I 
>>> would actually use in a given situation.  For example, there is quite a 
>>> bit of code in the text and io packages which convert an arbitrary type 
>>> to a char[] for output, etc.  So by making this change I was left with 
>>> some conversions using toString and others using toUtf8, toUtf16, and 
>>> toUtf32, not to mention the fromXxx versions of these same functions. As 
>>> this is template code, the choice between toString and toUtf8 in a given 
>>> situation was unclear.
>>
>> Can you give an example file for this problem?  It would be easier to 
>> understand your problem if I knew exactly what you were talking about. 
>> An actual example is fine, it doesn't need to be minimized (i.e. "take a 
>> look at tango/io/X.d")
>
> tango.text.convert.Layout

I can't say I see a problem.

I'd say use toUtf8 when doing a conversion from one type of encoded string 
to another (i.e. utf-16 to utf-8), and use toString when overriding Object's 
toString, OR when converting a native type (i.e. int, float, etc).  For 
example tango.text.convert.Integer.toUtf8 should be toString.

In the case of tango.text.convert.Layout, I don't see any overriding of 
Object.toUtf8?  The Unicode.toUtf8 should be left alone since it is a 
conversion between utf encodings.  In any case, Unicode.toUtf8 is a global 
function, and is not overriding Object.toUtf8, so there is no conflict 
there.

-Steve 





More information about the Digitalmars-d mailing list