[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On January 11, 2009, Elias Pschernig wrote:
> On Sat, 2009-01-10 at 16:03 -0700, Thomas Fjellstrom wrote:
> > What I _really_ want to do here is have allegro convert whatever it gets
> > from the OS into the "current" allegro format. Yes, it might break path
> > names, but then just set the allegro format to what you need (UTF8 aught
> > to cover everything for the foreseeable future).
> >
> > Or possibly somehow detect the OS format, and always set the allegro
> > format to it? (at least within reason, ASCII, UTF8 and UCS16 or whatever)
> >
> > I _really_ don't want to have to force the user to convert every little
> > string they get from allegro into allegro's own default format. It seems
> > rather redundant.
>
> Indeed. I think the best approach is if allegro always provides and
> accepts only UTF8 strings, so the user never would convert anything.
This I have no problems with.
> > Now, imo, a more "proper" solution would be to provide our own
> > ALLEGRO_STRING type, and store the encoding and a nice vtable with it.
> > But I'll bet most people aren't too interested in that.
>
> That really would be overkill. UTF8 is sometimes not the ideal encoding,
> but it's 100% backwards compatible with ASCII and very widely used. And
> if we assume that all strings ever passed to or returned from allegro
> functions are UTF8, we can keep our code simpler.
Yup. Consistency is nice.
> --
> Elias Pschernig <elias@xxxxxxxxxx>
>
>
> ---------------------------------------------------------------------------
>--- Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx