I have an MP3 player with a 40G hard drive, which puts your concerns about a
2.4G library into perspective. That's got to be a secondary issue, compared
with the requirements for convenience and functionality, when designing a
library.
Regarding the overhead of narrow to wide conversion, that's what any Windows
app suffers, every time it calls a Win32 API with a narrow string parameter.
Inside the kernel, everything is in Unicode (ignoring Win9x/ME).
- Keith MacDonald
"Vladimir Prus"
Edward Diener wrote:
1. Make the library interface templated. 2. Use narrow classes: e.g. string 3. Use wide classes: e.g. wstring 4. Have some class which works with ascii and unicode.
The first approach is bad for code size reasons. If the library does substantial work (e.g. HTTP library), it better be dynamic library, so that applications don't have include all the code. Of course, you might want static linking, but dynamic linking should be possible too.
One could quite easily provide separate libraries for different character types, if a library was necessary in the first place.
Yea, but whether as two separate file or one file, the size is still twice as large. E.g. if on a typical Linux system, just one application uses wide version, you have to install both wide and narrow version. Here on my box, the size of /usr/lib in 1.2G. Making it into 2.4G does not seem right ;-)
- Volodya