(ref.doc)bs 190593

From: [email protected] (Bjarne Stroustrup)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Standard component library
Summary: namespaces and international strings
Date: 19 May 93 02:02:00 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ



[email protected] (Eric Johnson @ CAMAX Systems, Inc.) writes

 > 1. Name-space protection. All class and type names should have some
 > standard prefix to prevent name-space conflicts with component software
 > (e.g., X Window System, Motif, etc.). The one that first comes to mind
 > is that very nasty X data type "String". Now, I don't like the fact that
 > the X folks decided to take over String for all time. I just ask that
 > ANSI doesn't follow suit. Let's learn from the mistake. More and more
 > software developers are using software components in our products,
 > so name-space collisions are becoming more and more of a problem.

This is top of the extensions working group's priority list. The proposal
on the table looks like this:

	namespace X {
		class String { ... };	// library X's string
		// ...
	}

	namespace Y {
		class String { ... };	// library y's string
		// ...
	}

	void f()
	{
		X::String s = "asdf"; // using X's string
		// ...
	}

	void g()
	{
		using Y::String;	// String refers to Y::String
					// in this scope

		String s = "asdf";	// using Y's string
		// ...
	}

I hope to see this accepted at the July meeting (in Munich) and have
some reason to hope that will happen. There is a longish discussion of
the proposal in the latest ANSI/ISO mailing so people who are interested
enough to do some work should contact their ANSI or ISO rep. People who
are just curious can look at a brief description in next month's issue
of the C++ Report.

 > 2. We market our software worldwide. I suspect a number of other
 > companies do as well. Hence, an ANSI C++ string class should allow
 > for internationalized text. Using multibyte text may be the easiest
 > (since you can still use char*) although I still hope something
 > like Unicode will be adopted worldwide. In any case, member functions
 > on a string class to get a particular character, to compare two
 > strings, to get the string length (in characters insteda of bytes--
 > although both functions will be needed), numeric, date and time
 > formatting, etc., will need to be internationalized.

A String class that can cope with extended character sets is being
considerd, and so are the modifications to iostreams to deal with
initernationalization issues.

	- Bjarne

(22 Jul 93: accepted at the ANSI/ISO meeting in Munich last week)