Re: Garbage collection in C++

From:

Pete Becker <pete@versatilecoding.com>

Newsgroups:

comp.lang.c++

Date:

Sun, 23 Nov 2008 09:45:50 -0500

Message-ID:

<2008112309455016807-pete@versatilecodingcom>

On 2008-11-22 09:19:31 -0500, Sam <sam@email-scan.com> said:

Pete Becker writes:

On 2008-11-21 23:08:57 -0500, Sam <sam@email-scan.com> said:

If an implementation's wchar_t is not big enough to support all Unicode
values, then it's an implementation problem.

Despite your assertion that it "supports [Unicode] very well"?

It does. Just because one implementation is broken does not mean that
wchar_t is broken.

Hmm, "one implementation" is broken.

I'm not sure I understand this logic. Ok, so the C++ language's definition
of wchar_t is too vague, and implementations claim to be in compliance
without using a wchar_t that's wide enough to support the full Unicode
range.

Whatever. The point is that wchar_t isn't required to do the things
that are needed to suppport Unicode. Hell, Unicode didn't exist at the
time that wchar_t was invented.

Then fix the definition of wchar_t, instead of inventing an entire new class
hierarchy.

Hmm, "the definition" needs to be fixed.

Well, then obvious solution is to define wchar_t to explicitly be
wide enough for the full Unicode range.

Thus breaking existing implementations and applications that use it.

The only existing implementations that would be broken are the ones that are
already broken, right now.

Hmm, some implementations are broken.

Why introduce string types that
explicitly use 16 or 32 bit characters?

Because they do what people need.

But I gather from all this noise that you no longer belive that wchar_t
"supports [Unicode] very well".

No, you gather wrong.

Okay, it supports Unicode very well if we ignore "broken"
implementations that meet the requriements that need to be fixed.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)