Re: [boost] program_options wchar_t support

From: Pavol Droba (droba_at_[hidden])
Date: 2004-02-15 11:18:59

On Sat, Feb 14, 2004 at 10:21:06PM +0300, Vladimir Prus wrote:
> Hi Pavol,
> 
> > On Sat, Feb 14, 2004 at 07:29:00PM +0300, Vladimir Prus wrote:
> > > > It could be templatized so that it can be based on any kind of
> > > > std::basic_string.
> > >
> > > Alas, that would break ability to put all sources in a library -- thereby
> > > increasing compile time for users who don't need wchar_t support.
> >
> > AFAIR, there were several solutions for this problem.
> >
> > I don't see many other reasonable options besides char and wchar_t.
> > So why don't just allow these specializations. Then you can put them into
> > cpp files.
> >
> > std::string in STL is handled in very similar way.
> 
> There's other very attactive option. If most of the time when user wants 
> wchar_t he also need to specify 8bit encoding -> unicode convertion,
> it's possible to *always* use wchar_t and convert it to char only on interface 
> boundaries.
> 
> That's similiar to QT approach -- where there's single string class. 

I can't judge rigthfuly, if this is a feasible approach. 

 From my experience, I use to work with wchar_t on windows in gui 
applications, while linux based console program ususaly use only char 
(non-unicode) encoding. 

So it seems, that both char and wchar_t usage is equaly important. Your approach
would penalize "char" approach in the means of additional conversions and memory 
requiremnts.

Maybe it does not matter too much, but you should take this argument into consideration.

Regards,

Pavol