| Topic: |
DEVELOP > c-Plus-Plus |
| User: |
"India" |
| Date: |
14 Jan 2008 05:23:27 AM |
| Object: |
next ISO C++ standard |
Current ISO C++ standard is ISO C++ 1998. Am I correct ?
When is the next standard expected ? What is the URL for knowing it ?
Will it contain libraries for network programming as part of the
standard library ?.(just as data structures and algorithms were
included as part ISO C++ 1998 standard library).
Kindly clarify.
Thanks
V.Subramanian
.
|
|
| User: "Victor Bazarov" |
|
| Title: Re: next ISO C++ standard |
14 Jan 2008 08:10:59 AM |
|
|
wrote:
Current ISO C++ standard is ISO C++ 1998. Am I correct ?
No, the latest standard is 2003.
When is the next standard expected ? What is the URL for knowing it ?
Committee home: http://www.open-std.org/jtc1/sc22/wg21/
Will it contain libraries for network programming as part of the
standard library ?
No.
.(just as data structures and algorithms were
included as part ISO C++ 1998 standard library).
Kindly clarify.
Kindly find out for yourself.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.
|
|
|
|
| User: "Jerry Coffin" |
|
| Title: Re: next ISO C++ standard |
14 Jan 2008 10:27:06 PM |
|
|
In article <05112d9b-f69e-4be4-a370-b0e8cfc2b616
@t1g2000pra.googlegroups.com>, says...
Current ISO C++ standard is ISO C++ 1998. Am I correct ?
No -- the current standard is dated 2003. Most of the differences
between the 1998 standard and the 2003 standard are fairly minor though
-- most simply change the wording to actually require what was intended
to start with. A few new requirements were added (e.g. std::vector must
use contiguous storage) but these were always true in practice anyway.
When is the next standard expected ? What is the URL for knowing it ?
The committee is trying for 2009. The committee home page is at:
http://www.open-std.org/jtc1/sc22/wg21/
Will it contain libraries for network programming as part of the
standard library ?.(just as data structures and algorithms were
included as part ISO C++ 1998 standard library).
I think it's quite unlikely. There isn't any network support in the
current draft, and the committee stopped accepting new features around a
year ago. In theory it could still happen, but only if it was forced to,
such as a country making it clear that they would only vote in favor of
the standard if this was added. Some such requirements have been known
for quite a while, and I doubt anybody would add such a thing at this
late date.
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 04:53:22 AM |
|
|
Jerry Coffin wrote:
Will it contain libraries for network programming as part of the
standard library ?.(just as data structures and algorithms were
included as part ISO C++ 1998 standard library).
I think it's quite unlikely. There isn't any network support in the
current draft, and the committee stopped accepting new features around a
year ago. In theory it could still happen, but only if it was forced to,
such as a country making it clear that they would only vote in favor of
the standard if this was added. Some such requirements have been known
for quite a while, and I doubt anybody would add such a thing at this
late date.
So what will be new in the current standard apart from some new algorithms?
Will some C99 junk abominations like built in _complex, long long, etc
make into the standard?
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 04:55:06 AM |
|
|
Corrected some text:
Ioannis Vranos wrote:
Jerry Coffin wrote:
Will it contain libraries for network programming as part of the
standard library ?.(just as data structures and algorithms were
included as part ISO C++ 1998 standard library).
I think it's quite unlikely. There isn't any network support in the
current draft, and the committee stopped accepting new features around
a year ago. In theory it could still happen, but only if it was forced
to, such as a country making it clear that they would only vote in
favor of the standard if this was added. Some such requirements have
been known for quite a while, and I doubt anybody would add such a
thing at this late date.
So what will be new in the current standard apart from some new algorithms?
Will some C99 junk like built in _complex, long long, etc make into the
standard?
.
|
|
|
| User: "Victor Bazarov" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 08:05:00 AM |
|
|
Ioannis Vranos wrote:
[..]
Will some C99 junk like built in _complex, long long, etc make into
the standard?
Are you *afraid* to get a copy and find out for yourself?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.
|
|
|
|
| User: "=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 11:39:59 AM |
|
|
On 2008-01-15 11:55, Ioannis Vranos wrote:
Corrected some text:
Ioannis Vranos wrote:
Jerry Coffin wrote:
Will it contain libraries for network programming as part of the
standard library ?.(just as data structures and algorithms were
included as part ISO C++ 1998 standard library).
I think it's quite unlikely. There isn't any network support in the
current draft, and the committee stopped accepting new features around
a year ago. In theory it could still happen, but only if it was forced
to, such as a country making it clear that they would only vote in
favor of the standard if this was added. Some such requirements have
been known for quite a while, and I doubt anybody would add such a
thing at this late date.
So what will be new in the current standard apart from some new algorithms?
Will some C99 junk like built in _complex, long long, etc make into the
standard?
C++ have std::comples so it does not need any other. What is wrong with
long long? For more information about what will be in the next standard
take a look at Wikipedia.
--
Erik Wikström
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 02:20:48 PM |
|
|
Erik Wikström wrote:
So what will be new in the current standard apart from some new algorithms?
Will some C99 junk like built in _complex, long long, etc make into the
standard?
C++ have std::comples so it does not need any other. What is wrong with
long long? For more information about what will be in the next standard
take a look at Wikipedia.
Yes I know C++ has std::complex and focuses on providing abstraction
facilities which can be used to define what we need. However so far C++
has also been "a better C".
C99 took the way of providing "exotic" built-in types (with exotic names
I would say, like "_complex") ignoring the abstraction aims and ideals
of C++.
Regarding long long well, the known stuff are bothering me, the type
system rules are broken in code considering that long is the larger
built-in type. Also long long is too long to type. I think that the
existing C++03 built in integer types are sufficient and we do not need
long long.
But as far as I can understand, long long will be included in C++0x/1x,
mainly because of a sense for C compatibility. But I think we must
realise that C and C++ have no common future, so I think long long
should be dropped since we do not need that.
.
|
|
|
|
|
|
| User: "Jerry Coffin" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 08:42:14 PM |
|
|
In article <fmi3b3$1m53$1@ulysses.noc.ntua.gr>, says...
[ ... ]
So what will be new in the current standard apart from some new algorithms?
In the preprocessor, most (all?) of the C99 additions are included.
In the language proper:
1) concepts and concept maps
2) variadic templates
3) new character/string types (e.g. UTF-8 strings)
4) new string literals (e.g. raw literals, Unicode literals)
5) auto and decltype
6) rvalue references
There's definitely more than this, but these are the ones that stick out
in my memory as meaning a lot. I won't try to describe any of these here
-- almost any one of them deserves a lot more than a single post.
In the library, the stuff originally in TR1 is now part of the standard.
This includes things like regular expressions, more smart pointers (e.g.
shared_pointer), unordered associative containers (normally hash-based),
function binders, random number generators, etc. Though I'm not sure the
definition is finished yet, threads and atomic operations are supposed
to be supported by the time all is said and done.
Will some C99 junk abominations like built in _complex, long long, etc
make into the standard?
long long is added, though I'm not sure what's particularly abominable
about it. C++ already had std::complex, so I don't think anybody cared
much about the C99 additions in that area.
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
|
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 02:28:59 PM |
|
|
Interesting link on C++0x indeed:
http://en.wikipedia.org/wiki/C%2B%2B0x
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 03:03:53 PM |
|
|
Ioannis Vranos wrote:
Interesting link on C++0x indeed:
http://en.wikipedia.org/wiki/C%2B%2B0x
However I am a bit troubled from this:
"Standard C++ offers two kinds of string literals. The first kind,
contained within double quotes, produces a null-terminated array of type
const char. The second kind, defined as, L"", produces a null-terminated
array of type const wchar_t, where wchar_t is a wide-character. Neither
literal type offers support for Unicode-encoded string literals".
AFAIK, wchar_t supports the largest character set provided by the
system. So AFAIK wchar_t is Unicode on systems supporting Unicode. Am I
wrong somewhere?
.
|
|
|
| User: "Victor Bazarov" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 03:25:17 PM |
|
|
Ioannis Vranos wrote:
Ioannis Vranos wrote:
Interesting link on C++0x indeed:
http://en.wikipedia.org/wiki/C%2B%2B0x
However I am a bit troubled from this:
"Standard C++ offers two kinds of string literals. The first kind,
contained within double quotes, produces a null-terminated array of
type const char. The second kind, defined as, L"", produces a
null-terminated array of type const wchar_t, where wchar_t is a
wide-character. Neither literal type offers support for
Unicode-encoded string literals".
AFAIK, wchar_t supports the largest character set provided by the
system. So AFAIK wchar_t is Unicode on systems supporting Unicode. Am
I wrong somewhere?
There are several _different_ Unicode mappings/encoding, not all
can be [conveniently] supported by 'wchar_t' or by 'char'. Please
see http://en.wikipedia.org/wiki/Unicode.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.
|
|
|
|
| User: "James Kanze" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 04:00:17 PM |
|
|
On Jan 15, 10:03 pm, Ioannis Vranos <j...@no.spam> wrote:
Ioannis Vranos wrote:
Interesting link on C++0x indeed:
http://en.wikipedia.org/wiki/C%2B%2B0x
However I am a bit troubled from this:
"Standard C++ offers two kinds of string literals. The first kind,
contained within double quotes, produces a null-terminated array of type
const char. The second kind, defined as, L"", produces a null-terminated
array of type const wchar_t, where wchar_t is a wide-character. Neither
literal type offers support for Unicode-encoded string literals".
AFAIK, wchar_t supports the largest character set provided by the
system. So AFAIK wchar_t is Unicode on systems supporting Unicode. Am I
wrong somewhere?
An implementation is certainly allowed to use some form of
Unicode in wchar_t, and from a quality of implementation point
of view, it's what I would expect if the platform supports
Unicode. But the standard certainly doesn't require it---it
doesn't even require wchar_t to be larger than a char.
The next version of the C++ standard will require char16_t and
char32_t, using UTF-16 and UTF-32, respectively. And there will
be no less than 10 different types of string literals.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
15 Jan 2008 05:40:51 PM |
|
|
James Kanze wrote:
An implementation is certainly allowed to use some form of
Unicode in wchar_t, and from a quality of implementation point
of view, it's what I would expect if the platform supports
Unicode. But the standard certainly doesn't require it---it
doesn't even require wchar_t to be larger than a char.
OK, the standard also does not require that sizeof(int)> sizeof(char)
always, but this doesn't mean we have to introduce new "specific" types
because of this.
But again, it specifically mentions:
"Standard C++ offers two kinds of string literals. The first kind,
contained within double quotes, produces a null-terminated array of type
const char. The second kind, defined as, L"", produces a null-terminated
array of type const wchar_t, where wchar_t is a wide-character.
==> Neither literal type offers support for Unicode-encoded string
literals". Isn't this wrong?
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 04:06:45 AM |
|
|
On Jan 16, 12:40 am, Ioannis Vranos <j...@no.spam> wrote:
James Kanze wrote:
An implementation is certainly allowed to use some form of
Unicode in wchar_t, and from a quality of implementation point
of view, it's what I would expect if the platform supports
Unicode. But the standard certainly doesn't require it---it
doesn't even require wchar_t to be larger than a char.
OK, the standard also does not require that sizeof(int)>
sizeof(char) always, but this doesn't mean we have to
introduce new "specific" types because of this.
I'm not sure what your point is. Even if int's and char's have
the same size, they're different types.
C handled wchar_t as a typedef. This doesn't work in C++
because of overload resolution: you want wchar_t to behave as a
character type, when outputting it, for example; if it were a
typedef for int, you have a problem.
But again, it specifically mentions:
"Standard C++ offers two kinds of string literals. The first kind,
contained within double quotes, produces a null-terminated array of type
const char. The second kind, defined as, L"", produces a null-terminated
array of type const wchar_t, where wchar_t is a wide-character.
=3D=3D> Neither literal type offers support for Unicode-encoded string
literals". Isn't this wrong?
What are you disagreeing with? Neither literal type is Unicode,
unless an implementation decides to make it Unicode. Most of
the ones I have access to don't.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 06:26:59 AM |
|
|
James Kanze wrote:
On Jan 16, 12:40 am, Ioannis Vranos <j...@no.spam> wrote:
James Kanze wrote:
An implementation is certainly allowed to use some form of
Unicode in wchar_t, and from a quality of implementation point
of view, it's what I would expect if the platform supports
Unicode. But the standard certainly doesn't require it---it
doesn't even require wchar_t to be larger than a char.
OK, the standard also does not require that sizeof(int)>
sizeof(char) always, but this doesn't mean we have to
introduce new "specific" types because of this.
I'm not sure what your point is. Even if int's and char's have
the same size, they're different types.
C handled wchar_t as a typedef. This doesn't work in C++
because of overload resolution: you want wchar_t to behave as a
character type, when outputting it, for example; if it were a
typedef for int, you have a problem.
I mean long long is merely introduced because C committee decided to
introduce it to C99, no other real reason. What will happen if they
decide in the future to add another such built-in type?
But again, it specifically mentions:
"Standard C++ offers two kinds of string literals. The first kind,
contained within double quotes, produces a null-terminated array of type
const char. The second kind, defined as, L"", produces a null-terminated
array of type const wchar_t, where wchar_t is a wide-character.
==> Neither literal type offers support for Unicode-encoded string
literals". Isn't this wrong?
What are you disagreeing with? Neither literal type is Unicode,
unless an implementation decides to make it Unicode. Most of
the ones I have access to don't.
Those implementations you are mentioning are compiling programs for OSes
that do provide Unicode?
Under Windows I suppose current VC++ implements wchar_t as Unicode, and
in my OS (Linux) I suppose wchar_t is Unicode (haven't verified the last
though).
So with these new character types will we get Unicodes under OSes that
do not support Unicode? With the introduction of these new types, what
will be the use of wchar_t?
Essentially I am talking about restricting the introduction of new
features in the new standard, only to the most essential ones. I have
the feeling that all these Unicodes will be messy. Why are all these
Unicode types needed? After a new version of Unicode, we will have it
introduced as a new built-in type in C++ standard? What will be the use
of the old ones? What I am saying is that we will be having an
continuous accumulation of older built-in character types.
We are repeating C's mistakes here, adding built in types instead of
providing them as libraries.
.
|
|
|
| User: "Rui Maciel" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 11:23:20 AM |
|
|
Ioannis Vranos wrote:
Essentially I am talking about restricting the introduction of new
features in the new standard, only to the most essential ones. I have
the feeling that all these Unicodes will be messy.
How, exactly?
Why are all these
Unicode types needed?
Please take a look at:
http://en.wikipedia.org/wiki/Unicode
After a new version of Unicode, we will have it
introduced as a new built-in type in C++ standard? What will be the use
of the old ones? What I am saying is that we will be having an
continuous accumulation of older built-in character types.
We are repeating C's mistakes here, adding built in types instead of
providing them as libraries.
What do you mean by "built in type"? The wchar_t type is implemented through
a typedef. For example, GCC defines the wchar_t type in stddef.h as
typedef wchar_t int;
Rui Maciel
.
|
|
|
| User: "Victor Bazarov" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 12:46:25 PM |
|
|
Rui Maciel wrote:
Ioannis Vranos wrote:
Essentially I am talking about restricting the introduction of new
features in the new standard, only to the most essential ones. I have
the feeling that all these Unicodes will be messy.
How, exactly?
Why are all these
Unicode types needed?
Please take a look at:
http://en.wikipedia.org/wiki/Unicode
After a new version of Unicode, we will have it
introduced as a new built-in type in C++ standard? What will be the
use of the old ones? What I am saying is that we will be having an
continuous accumulation of older built-in character types.
We are repeating C's mistakes here, adding built in types instead of
providing them as libraries.
What do you mean by "built in type"? The wchar_t type is implemented
through a typedef. For example, GCC defines the wchar_t type in
stddef.h as
typedef wchar_t int;
That would be a violation of the C++ Standard. 'wchar_t' is a keyword
in C++. Yes, it is a built-in type.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.
|
|
|
|
|
| User: "Bo Persson" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 10:38:43 AM |
|
|
Ioannis Vranos wrote:
James Kanze wrote:
On Jan 16, 12:40 am, Ioannis Vranos <j...@no.spam> wrote:
But again, it specifically mentions:
"Standard C++ offers two kinds of string literals. The first kind,
contained within double quotes, produces a null-terminated array
of type const char. The second kind, defined as, L"", produces a
null-terminated array of type const wchar_t, where wchar_t is a
wide-character.
==> Neither literal type offers support for Unicode-encoded string
literals". Isn't this wrong?
What are you disagreeing with? Neither literal type is Unicode,
unless an implementation decides to make it Unicode. Most of
the ones I have access to don't.
Those implementations you are mentioning are compiling programs for
OSes that do provide Unicode?
Under Windows I suppose current VC++ implements wchar_t as Unicode,
and in my OS (Linux) I suppose wchar_t is Unicode (haven't verified
the last though).
But they might be different variants of Unicode, like UTF-16 and
UTF-32.
So with these new character types will we get Unicodes under OSes
that do not support Unicode?
Yes. Perhaps we will not use them much there?
With the introduction of these new
types, what will be the use of wchar_t?
Backward compatibility?
Often it will behave the same as either char16_t or char32_t. We just
don't know, portably.
Essentially I am talking about restricting the introduction of new
features in the new standard, only to the most essential ones. I
have the feeling that all these Unicodes will be messy. Why are all
these Unicode types needed? After a new version of Unicode, we will
have it introduced as a new built-in type in C++ standard? What
will be the use of the old ones? What I am saying is that we will
be having an continuous accumulation of older built-in character
types.
We are repeating C's mistakes here, adding built in types instead of
providing them as libraries.
No one has come up with a good way to introduce string literals as a
library only solution. The compiler has to know the types, to do the
proper encoding.
Bo Persson
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 02:07:13 PM |
|
|
Bo Persson wrote:
OSes that do provide Unicode?
Under Windows I suppose current VC++ implements wchar_t as Unicode,
and in my OS (Linux) I suppose wchar_t is Unicode (haven't verified
the last though).
But they might be different variants of Unicode, like UTF-16 and
UTF-32.
Yes, no problem with that. In a system supporting UTF-32, why should we
need UTF-16 or UTF-8?
1) We could use only the largest Unicode type.
2) I think that could be provided only via wchar_t.
So with these new character types will we get Unicodes under OSes
that do not support Unicode?
Yes. Perhaps we will not use them much there?
So do we need all those Unicode types built in?
No one has come up with a good way to introduce string literals as a
library only solution. The compiler has to know the types, to do the
proper encoding.
1) Wouldn't it be better, only the largest Unicode type supported by the
system to be provided?
2) Can't wchar_t alone fulfill this aim?
.
|
|
|
| User: "Rui Maciel" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 03:27:06 PM |
|
|
Ioannis Vranos wrote:
Yes, no problem with that. In a system supporting UTF-32, why should we
need UTF-16 or UTF-8?
You got to be kidding.
1) We could use only the largest Unicode type.
2) I think that could be provided only via wchar_t.
....which means, at least for those whose information is stored using mainly
the BMP code points, occupying 4x the space that is needed to store that
very same information.
So do we need all those Unicode types built in?
Obviously yes, unless you are ok with the idea of spending 4x of what you
need.
1) Wouldn't it be better, only the largest Unicode type supported by the
system to be provided?
There isn't a "one size fits all" solution to this problem. Currently, UTF-8
comes close to be that solution but it has it's drawbacks.
2) Can't wchar_t alone fulfill this aim?
Hard unicode support may be by far the easiest way to implement Unicode
support but, particularly if you only make use of the BMP code points, it
needlessly wastes memory. A lot of memory.
To give you an idea, I have a small pet project which consists of writing a
small JSON parser. That library supported Unicode the hard way and suffered
quite a bit from bloat, needing about 100MB to store the document tree of a
5MB test document. As soon as I switched the Unicode support from UCS4 to
UTF-8, the memory usage of that particular test document went from 100MB to
a bit over 40MB. That's a lot of memory.
Rui Maciel
.
|
|
|
| User: "Ioannis Vranos" |
|
| Title: Re: next ISO C++ standard |
16 Jan 2008 04:44:10 PM |
|
|
Rui Maciel wrote:
Ioannis Vranos wrote:
Yes, no problem with that. In a system supporting UTF-32, why should we
need UTF-16 or UTF-8?
You got to be kidding.
1. To be more precise what I meant is, the compiler should support the
largest character type supported by the system (OS), and if it supports
Unicode, the largest Unicode type supported by the OS.
Otherwise are we going to accumulate Unicodes for the next 10 years as
built-in types and supported literals?
And on an OS that does not support Unicode, would the compiler writer
have to provide all these Unicode types?
I am not much in Unicode types and text manipulation, but the built-in
approach of this magnitude feels wrong to me.
1) We could use only the largest Unicode type.
2) I think that could be provided only via wchar_t.
...which means, at least for those whose information is stored using mainly
the BMP code points, occupying 4x the space that is needed to store that
very same information.
Does any OS really exist that supports more than one Unicode types in
its APIs?
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: next ISO C++ standard |
17 Jan 2008 06:28:53 AM |
|
|
On Jan 16, 11:44 pm, Ioannis Vranos <j...@no.spam> wrote:
1. To be more precise what I meant is, the compiler should
support the largest character type supported by the system
(OS), and if it supports Unicode, the largest Unicode type
supported by the OS.
You've mentionned "Unicode type supported by the OS" several
times now. What do you mean by this? As far as I can tell, the
Unix systems I work on 1) only support 8 bit characters (wide
characters), and 2) require that any encoding used be a superset
of ASCII. I have filenames written in ISO 8859-1 on the file
system (shared by Linux and Solaris), filenames written in
UTF-8, and it doesn't bother the system one way or the other.
Does this mean that the systems in question don't support
Unicode, or that they support all encodings which are a superset
of ASCII?
I don't know what the situation is under Windows, but under
Unix, about the only place encoding for characters other than a
few meta-characters like '/' makes a difference is in input and
output. And there, it typically depends on something external:
the device you're writing to, or the encoding of the font used
for rendering, or the current xmodmap for the keyboard. I can
easily have one window working in ISO 8859-1, and another in
UTF-8, for example. (Creating a file in one window, and doing
an ls in another, does result in some strange looking filenames,
of course.)
Otherwise are we going to accumulate Unicodes for the next 10
years as built-in types and supported literals?
And on an OS that does not support Unicode, would the compiler
writer have to provide all these Unicode types?
I am not much in Unicode types and text manipulation, but the
built-in approach of this magnitude feels wrong to me.
1) We could use only the largest Unicode type.
2) I think that could be provided only via wchar_t.
...which means, at least for those whose information is
stored using mainly the BMP code points, occupying 4x the
space that is needed to store that very same information.
Does any OS really exist that supports more than one Unicode
types in its APIs?
For the most part, Unix is neutral. From what I understand,
however, Windows supports UTF-16 and an 8 bit API---and it would
surprise me somewhat if the latest versions (Vista) didn't allow
UTF-8 in the 8 bit API.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
|
|
|
|
|
| User: "James Kanze" |
|
| Title: Re: next ISO C++ standard |
17 Jan 2008 06:16:40 AM |
|
|
On Jan 16, 1:26 pm, Ioannis Vranos <j...@no.spam> wrote:
James Kanze wrote:
On Jan 16, 12:40 am, Ioannis Vranos <j...@no.spam> wrote:
James Kanze wrote:
C handled wchar_t as a typedef. This doesn't work in C++
because of overload resolution: you want wchar_t to behave as a
character type, when outputting it, for example; if it were a
typedef for int, you have a problem.
I mean long long is merely introduced because C committee decided to
introduce it to C99, no other real reason. What will happen if they
decide in the future to add another such built-in type?
The following version of C++ will almost certainly add it as
well. I'm pretty sure that there is a strong consensus to keep
C++ compatible with C with regards to the integer types.
Note that the C committee wasn't particularly happy with long
long itself. After all, what happens if the next generation of
machines also supports 128 bit types: we all "long long long"?
They accepted it as "wide-spread existing practice", but at the
same time, developped a more general framework for an unlimited
number of integral types. C++ has also adopted this framework:
there is no guarantee that long long is the longest integral
type in a given implementation. (That would be intmax_t, which
is a typedef.)
But again, it specifically mentions:
"Standard C++ offers two kinds of string literals. The
first kind, contained within double quotes, produces a
null-terminated array of type const char. The second kind,
defined as, L"", produces a null-terminated array of type
const wchar_t, where wchar_t is a wide-character.
=3D=3D> Neither literal type offers support for Unicode-encoded string
literals". Isn't this wrong?
What are you disagreeing with? Neither literal type is Unicode,
unless an implementation decides to make it Unicode. Most of
the ones I have access to don't.
Those implementations you are mentioning are compiling
programs for OSes that do provide Unicode?
What does "provide Unicode" mean? I use Unicode under Solaris.
Sun CC generates some other encoding for wide string literals,
and G++ only allows basic ASCII in them to begin with (otherwise
"converting to execution character set: Illegal byte sequence"
For that matter, I get the same error with g++ under Linux.
Under Windows I suppose current VC++ implements wchar_t as
Unicode, and in my OS (Linux) I suppose wchar_t is Unicode
(haven't verified the last though).
Under Windows, wchar_t nominally is UTF-16. But of course, it's
really whatever the code interpreting it interprets it to be.
Under Linux, as far as I can tell, there is no nominal
encoding---it's whatever the program wants it to be. (The
difference, of course, is that Linux doesn't support any wchar_t
IO, so any wchar_t is purely intern to the program.)
A quick test on my machines showed that g++ doesn't support
UTF-32 (which would be the normal Unicode format for the 4 byte
wchar_t), at least in wide string literals, so I don't see how
you can say that it supports Unicode. I haven't tried things
like "toupper( L'\u00E9', std::locale() )", so I don't know
about those, but they're locale dependent anyway.
So with these new character types will we get Unicodes under
OSes that do not support Unicode?
Presumably. The problem isn't really OS support---most OS's are
encoding neutral for most functions. (With a few
exceptions---Posix/Linux pretty much requires that the native
narrow character encoding be a superset of ASCII. But in fact,
about the only place I think that this will be an issue is for
'/', and maybe a few other special separators.)
With the introduction of these new types, what will be the use
of wchar_t?
Support for legacy code. Support for the native 32 bit
encoding, which isn't Unicode under Solaris (nor, I think, most
other Posix systems). Support for whatever the implementation
wants---that's what it currently is.
Essentially I am talking about restricting the introduction of
new features in the new standard, only to the most essential
ones. I have the feeling that all these Unicodes will be
messy.
Well, I won't argue against you there. Having to deal with so
many different encodings and encoding formats is messy. The
problem is that the mess is there, outside of C++, and we have
to deal with it in one way or another.
Why are all these Unicode types needed?
To support all of the formats Unicode standardizes.
After a new version of Unicode, we will have it introduced as
a new built-in type in C++ standard?
If they introduce still more encoding formats, I suppose yes.
Somehow, I don't see that happening.
What will be the use of the old ones? What I am saying is that
we will be having an continuous accumulation of older built-in
character types.
We are repeating C's mistakes here, adding built in types
instead of providing them as libraries.
There's only so much you can do in a library. You can't make a
new integral type, which behaves like an integral type.
Of course, I'm not sure that that's really what is needed for
the Unicode types. Do you really want to be able to increment a
character (as opposed to a small integral value). But again,
character types are integral types in C, C++ wants to be
compatible with C with regards to the integral types, and C
won't use a library for the basic type here. (I'm not sure, but
I believe that char32_t and char16_t also originate in a TR for
C.)
For the other integral types: the language wants to support what
the hardware supports.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "red floyd" |
|
| Title: Re: next ISO C++ standard |
17 Jan 2008 10:33:35 AM |
|
|
James Kanze wrote:
Note that the C committee wasn't particularly happy with long
long itself. After all, what happens if the next generation of
machines also supports 128 bit types: we all "long long long"?
I think we discussed this once before:
128-bit: very long long;
256-bit: really long long;
512-bit: extra long long;
etc....
.
|
|
|
| User: "Ron Natalie" |
|
| Title: Re: next ISO C++ standard |
17 Jan 2008 02:14:15 PM |
|
|
red floyd wrote:
James Kanze wrote:
Note that the C committee wasn't particularly happy with long
long itself. After all, what happens if the next generation of
machines also supports 128 bit types: we all "long long long"?
I think we discussed this once before:
128-bit: very long long;
256-bit: really long long;
512-bit: extra long long;
We were working on a machine that was natively 64 bits over
20 years ago. For practical reasons we needed "int" to
also be 64 bits, so what to call the 32 bit type.
Crazy ideas were:
short long int
and
medium int
We finaly decided on int32.
.
|
|
|
| User: "Victor Bazarov" |
|
| Title: Re: next ISO C++ standard |
17 Jan 2008 02:25:08 PM |
|
|
Ron Natalie wrote:
red floyd wrote:
James Kanze wrote:
Note that the C committee wasn't particularly happy with long
long itself. After all, what happens if the next generation of
machines also supports 128 bit types: we all "long long long"?
I think we discussed this once before:
128-bit: very long long;
256-bit: really long long;
512-bit: extra long long;
We were working on a machine that was natively 64 bits over
20 years ago. For practical reasons we needed "int" to
also be 64 bits, so what to call the 32 bit type.
Crazy ideas were:
short long int
and
medium int
We finaly decided on int32.
What's wrong with just 'short'? Nowhere does it say that 'short'
has to be less than 32 bits, it just shouldn't be less than 16...
Now what do you call a 16-bit integral type after that?
A 'really short' or a 'long char'?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.
|
|
|
| User: "Ron Natalie" |
|
| Title: Re: next ISO C++ standard |
18 Jan 2008 06:21:15 AM |
|
|
Victor Bazarov wrote:
Now what do you call a 16-bit integral type after that?
A 'really short' or a 'long char'?
short short?
.
|
|
|
| User: "red floyd" |
|
| Title: Re: next ISO C++ standard |
18 Jan 2008 10:04:23 AM |
|
|
Ron Natalie wrote:
Victor Bazarov wrote:
Now what do you call a 16-bit integral type after that?
A 'really short' or a 'long char'?
short short?
Who wears short shorts?
.
|
|
|
|
|
| User: "Matthias Buelow" |
|
| Title: Re: next ISO C++ standard |
18 Jan 2008 10:10:39 AM |
|
|
Victor Bazarov wrote:
Now what do you call a 16-bit integral type after that?
A 'really short' or a 'long char'?
Why has there to be one? I presume "short" was introduced because of
backwards-compatibility issues when moving from the PDP-7 to 32-bit
environments like the VAX (and probably used in the same way a decade
later when going 32-bit on the PC), both uses are rather rare today on
32- and 64-bit machines. I see no reason why a 16-bit integer type has
to be provided on these machines.
.
|
|
|
| User: "Victor Bazarov" |
|
| Title: Re: next ISO C++ standard |
18 Jan 2008 11:03:19 AM |
|
|
Matthias Buelow wrote:
Victor Bazarov wrote:
Now what do you call a 16-bit integral type after that?
A 'really short' or a 'long char'?
Why has there to be one? I presume "short" was introduced because of
backwards-compatibility issues when moving from the PDP-7 to 32-bit
environments like the VAX (and probably used in the same way a decade
later when going 32-bit on the PC), both uses are rather rare today on
32- and 64-bit machines. I see no reason why a 16-bit integer type has
to be provided on these machines.
That is not under discussion. What's under discussion is the name of
that type _if_ it is provided. Of course, there is always the 'intXX_t'
one could resort to.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related Articles |
|
|
