[prev in list] [next in list] [prev in thread] [next in thread] 

List:       icu
Subject:    RE: ICU name locking for a given version (WAS: RE: not to be a pa
From:       Yves Arrouye <yves () realnames ! com>
Date:       2001-09-21 22:28:39
[Download RAW message or body]

> We will discuss namespaces.
> In general, ICU sticks to very basic C++ language features because of
> porting problems (no exceptions, no templates, only single
inheritance...).
> This means that if we were to use namespaces, then that would be an
> optional feature, and ICU would have to work without it.

I agree it's not perfect. But urename.h is not either. See below for what
could be done without namespaces. Same as my previous email, but a bit more
detailed and with an easy way for people to upgrade their applications.

> What would happen if on the same platform one compiler supports namespaces
> and the other doesn't?

Well, as we just learned again with KCC, one will need a separate set of
libraries because of name mangling etc. To be able to share the header
files, we could have a header that recognizes which compilers can do what
(assuming whatever default you prefer, presumably no namespaces support).

My personally preferred solution without namespaces would be to rename
classes so that their names start with ICU (or just U, except for the ones
whose name start w/ Unicode maybe, if just U doesn't conflict with the C
names). Then you can use urename.h. And to facilitate transition for other
people, you can add a unicode/upre20nm.h that has

	#define Format	UFormat
	#define Whatever	UWhatever

Since 2.0 is not compatible with 1.8, and maybe even has some incompatible
API changes (forcing people to change code; but I don't remember seeing that
for 2.0), asking people to add #include <unicode/upre20nm.h> if they just
want to recompile may not be too bad. You could even let them have that be
done automatically by compiling while defining U_USE_PRE_2_0_NAMES and
having that triggers the inclusion of upre20nm.h in umachine.h. Or build ICU
with that always defined.

Just an idea. I think it would be tolerable, and would get rid of your
problem with minimum pain (adding a define of U_USE_PRE_2_0_NAMES to
projects, worst case), while keeping compatibility with other libraries such
as MFC, which is important

> Still, I wonder why you could not #undef Format in a good place and get
> that to work - you just could not use ICU formatting, but you seem to use
> MFC formatting anyway?

The problem is when you include a header from another library which includes
the CString header, because it has inline functions that call CString
methods. Since it is a library that you don't control, it's hard to get rid
of that. Or do you suggest that people will also have to work around these
kind of issues?

YA


[prev in list] [next in list] [prev in thread] [next in thread]