Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25582 > unrolled thread

Re: Why No Supplemental Characters In Character Literals?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why No Supplemental Characters In Character Literals? Roedy Green <see_website@mindprod.com.invalid> - 2011-02-04 10:36 -0800
    Re: Why No Supplemental Characters In Character Literals? Arne Vajhøj <arne@vajhoej.dk> - 2011-02-04 18:19 -0500
    Re: Why No Supplemental Characters In Character Literals? Roedy Green <see_website@mindprod.com.invalid> - 2011-02-04 15:02 -0800
    Re: Why No Supplemental Characters In Character Literals? Arne Vajhøj <arne@vajhoej.dk> - 2011-02-04 17:54 -0500
    Re: Why No Supplemental Characters In Character Literals? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-05 11:43 +1300
    Re: Why No Supplemental Characters In Character Literals? markspace <nospam@nowhere.com> - 2011-02-04 11:04 -0800

#25582 — Re: Why No Supplemental Characters In Character Literals?

On Fri, 04 Feb 2011 08:04:23 -0500, Joshua Cranmer
<Pidgeot18@verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

>The JLS clearly states that a char is an unsigned 16-bit value. 

Perhaps char will be redefined as 32 bits, or a new unsigned 32-bit
echar type will be invented. 

It is an intractable problem.  Consider the logic that uses indexOf
substring with character index arithmetic.  Most if it would go insane
if you threw a few 32-bit chars in there.  You need something that
simulates an array of 32-bit chars to the programmer.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
To err is human, but to really foul things up requires a computer.
~ Farmer's Almanac
It is breathtaking how a misplaced comma in a computer program can
shred megabytes of data in seconds.

[toc] | [next] | [standalone]

#25620

On 04-02-2011 13:36, Roedy Green wrote:
> On Fri, 04 Feb 2011 08:04:23 -0500, Joshua Cranmer
> <Pidgeot18@verizon.invalid>  wrote, quoted or indirectly quoted someone
> who said :
>> The JLS clearly states that a char is an unsigned 16-bit value.
>
> Perhaps char will be redefined as 32 bits, or a new unsigned 32-bit
> echar type will be invented.
>
> It is an intractable problem.  Consider the logic that uses indexOf
> substring with character index arithmetic.  Most if it would go insane
> if you threw a few 32-bit chars in there.  You need something that
> simulates an array of 32-bit chars to the programmer.

I don't think they can come up with a solution that both provides
good support for the high code points and will keep old code
running unchanges.

echar and EString would keep old stuff running, but would
completely blow up the entire API.

Arne

[toc] | [prev] | [next] | [standalone]

#25644

On Sat, 05 Feb 2011 11:43:18 +1300, Lawrence D'Oliveiro
<ldo@geek-central.gen.new_zealand> wrote, quoted or indirectly quoted
someone who said :

>
>Why was there even a need to spell out the size of a char? If you wanted 
>types with explicit sizes, there was already byte, short, int and long.

I think because Java's designers thought on the byte code level.
There, chars are unsigned 16-bit. That they are used for chars was not
really of interest to them.  Much of Java is just a thin wrapper
around byte code. It has no high level features of its own.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
To err is human, but to really foul things up requires a computer.
~ Farmer's Almanac
It is breathtaking how a misplaced comma in a computer program can
shred megabytes of data in seconds.

[toc] | [prev] | [next] | [standalone]

#25954

On 04-02-2011 17:43, Lawrence D'Oliveiro wrote:
> In message<iihikc$dpj$1@news.eternal-september.org>, markspace wrote:
>> <http://download.oracle.com/javase/6/docs/api/java/lang/Character.html>
>>
>> "The char data type (and therefore the value that a Character object
>> encapsulates) are based on the original Unicode specification, which
>> defined characters as fixed-width 16-bit entities.
>
> When did the unification with ISO-10646 happen? That was already talking
> about 32-bit characters.
>
>> "A char value, therefore, represents Basic Multilingual Plane (BMP) code
>> points, including the surrogate code points, or code units of the UTF-16
>> encoding. An int value represents all Unicode code points, including
>> supplementary code points.
>
> Why was there even a need to spell out the size of a char? If you wanted
> types with explicit sizes, there was already byte, short, int and long.

It provides well defined semantics.

Nobody wanted to repeat C89 undefined/implementation specific
behavior.

Arne

[toc] | [prev] | [next] | [standalone]

#26088

In message <iihikc$dpj$1@news.eternal-september.org>, markspace wrote:

> <http://download.oracle.com/javase/6/docs/api/java/lang/Character.html>
> 
> "The char data type (and therefore the value that a Character object
> encapsulates) are based on the original Unicode specification, which
> defined characters as fixed-width 16-bit entities.

When did the unification with ISO-10646 happen? That was already talking 
about 32-bit characters.

> "A char value, therefore, represents Basic Multilingual Plane (BMP) code
> points, including the surrogate code points, or code units of the UTF-16
> encoding. An int value represents all Unicode code points, including
> supplementary code points.

Why was there even a need to spell out the size of a char? If you wanted 
types with explicit sizes, there was already byte, short, int and long.

[toc] | [prev] | [next] | [standalone]

#26157

On 2/4/2011 10:36 AM, Roedy Green wrote:
> On Fri, 04 Feb 2011 08:04:23 -0500, Joshua Cranmer
> <Pidgeot18@verizon.invalid>  wrote, quoted or indirectly quoted someone
> who said :
>
>> The JLS clearly states that a char is an unsigned 16-bit value.
>
> Perhaps char will be redefined as 32 bits, or a new unsigned 32-bit
> echar type will be invented.


An int is currently used for this purpose.  For example, 
Character.codePointAt(CharSequence,int) returns an int.


<http://download.oracle.com/javase/6/docs/api/java/lang/Character.html>


Also, from that same page, this explains the whole story in one go:


"Unicode Character Representations

"The char data type (and therefore the value that a Character object 
encapsulates) are based on the original Unicode specification, which 
defined characters as fixed-width 16-bit entities. The Unicode standard 
has since been changed to allow for characters whose representation 
requires more than 16 bits. The range of legal code points is now U+0000 
to U+10FFFF, known as Unicode scalar value. (Refer to the definition of 
the U+n notation in the Unicode standard.)

"The set of characters from U+0000 to U+FFFF is sometimes referred to as 
the Basic Multilingual Plane (BMP). Characters whose code points are 
greater than U+FFFF are called supplementary characters. The Java 2 
platform uses the UTF-16 representation in char arrays and in the String 
and StringBuffer classes. In this representation, supplementary 
characters are represented as a pair of char values, the first from the 
high-surrogates range, (\uD800-\uDBFF), the second from the 
low-surrogates range (\uDC00-\uDFFF).

"A char value, therefore, represents Basic Multilingual Plane (BMP) code 
points, including the surrogate code points, or code units of the UTF-16 
encoding. An int value represents all Unicode code points, including 
supplementary code points. The lower (least significant) 21 bits of int 
are used to represent Unicode code points and the upper (most 
significant) 11 bits must be zero.


...etc....

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web