Re: unicode string

[Havoc Pennington <hp redhat com>]

Nathan Myers <ncm@nospam.cantrip.org> writes: 
> I would use it in implementation only.  Your interfaces should take 
> a wstring, or be overloaded to take either a string or wstring.
> 

I don't think I have any use for it in the implementation - remember
that all my implementations are simply chaining to a C function that
takes UTF8. So if I take a wstring as arg, it will look like this:

class Label 
{
public:
  void set_text (const std::wstring& wstr)
  {
    char *utf8 = wstring_to_utf8 (wstr);
    gtk_label_set_text (gtk_label (), utf8);
    delete [] utf8;
  }

  std::wstring text () const
  {
    char *utf8 = gtk_label_get_text (gtk_label ());
    std::wstring wstr = utf8_to_wstring (utf8);
    g_free (utf8);
    return wstr;
  }
};

Also I've been overloading methods like set_text() on both string and
char*, because the string version results in enormous user code size. 
For example:
 label->set_text  ("foo");
 
expands to a huge inline constructor, setting text on 10 labels easily
fills 2K of code... I get a huge code size reduction from overloading
to take char*.

Anyway, yet another overload with wstring, leaves me with three
versions of every function taking a string. :-( The one that takes
const string& can easily be an inline wrapper around the char* one,
but nonetheless.

For return values I need to simply make a decision one way or the
other, since overloading doesn't work, and so I have some inclination
to do the same for method arguments. Honestly though, set_text ("foo")
(with the string literal) _must_ work, so wstring is pretty hard to
choose in that case. It's unfortunate that L"foo" appears broken.
Maybe a wstring subclass that has a char* constructor?

> Havoc's observation that random access in strings is only rarely

FWIW I think it was Owen that pointed that out.

Havoc