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

subramanian100in@yahoo.com wrote:

Quote:

Current ISO C++ standard is ISO C++ 1998. Am I correct ?

No, the latest standard is 2003.

Quote:

When is the next standard expected ? What is the URL for knowing it ?

Committee home: http://www.open-std.org/jtc1/sc22/wg21/

Quote:

Will it contain libraries for network programming as part of the
standard library ?

No.

Quote:

>.(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

In article <05112d9b-f69e-4be4-a370-b0e8cfc2b616
@t1g2000pra.googlegroups.com>, subramanian100in@yahoo.com says...

Quote:

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.

Quote:

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/

Quote:

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.

Jerry Coffin wrote:

Quote:

>

Quote:

>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?

Corrected some text:

Ioannis Vranos wrote:

Quote:

Jerry Coffin wrote:

Quote:

>>

Quote:

>>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?

Ioannis Vranos wrote:

Quote:

[..]
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

On 2008-01-15 11:55, Ioannis Vranos wrote:

Quote:

Corrected some text:
>
Ioannis Vranos wrote:

Quote:

>Jerry Coffin wrote:

Quote:

>>>
>>>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

Erik WikstrÃ¶m wrote:

Quote:

>

Quote:

>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.

Interesting link on C++0x indeed:

http://en.wikipedia.org/wiki/C%2B%2B0x

Ioannis Vranos wrote:

Quote:

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?

On Jan 15, 10:03 pm, Ioannis Vranos <j...@no.spamwrote:

Quote:

Ioannis Vranos wrote:

Quote:

Interesting link on C++0x indeed:

Quote:

http://en.wikipedia.org/wiki/C%2B%2B0x

Quote:

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".

Quote:

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ée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Ioannis Vranos wrote:

Quote:

Ioannis Vranos wrote:

Quote:

>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

James Kanze wrote:

Quote:

[..]
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.

Ten? I can only see four: regular ("blah"), UTF-16 (u"blah"), UTF-32
(U"blah"), and wide (L"blah"). What are the other six?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov wrote:

Quote:

James Kanze wrote:

Quote:

>[..]
>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.

>
Ten? I can only see four: regular ("blah"), UTF-16 (u"blah"), UTF-32
(U"blah"), and wide (L"blah"). What are the other six?
>
V

Raw (R"....")
UTF8 (u8"....")
And I think the Raw comes in the various UTF and wide flavors, as well,
but I'm not sure.

James Kanze wrote:

Quote:

>
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?

On Jan 15, 11:35 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:

Quote:

James Kanze wrote:

Quote:

[..]
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.

Quote:

Ten? I can only see four: regular ("blah"), UTF-16 (u"blah"),
UTF-32 (U"blah"), and wide (L"blah"). What are the other six?

I though I posted a table recently:

encoding '\' recognized
"blah" native yes
u8"blah" UTF-8 yes
u"blah" UTF-16 yes
U"blah" UTF-32 yes
L"blah" native yes
R"blah" native no
u8R"blah" UTF-8 no
uR"blah" UTF-16 no
UR"blah" UTF-32 no
LR"blah" native no

There are four different character types, but you have string
literals either in the native encoding or in UTF-8 for char. In
addition, you can have string literals in which things like "\n"
represent a backslash followed by an n, rather than a new line.
Useful, for example, for specifying regular expressions, where
the expression might contain a large number of \. (The 'R' here
means "raw".)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jan 16, 12:40 am, Ioannis Vranos <j...@no.spamwrote:

Quote:

James Kanze wrote:

Quote:

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.

Quote:

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.

Quote:

But again, it specifically mentions:

Quote:

"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.

Quote:

==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ée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bo Persson wrote:

Quote:

OSes that do provide Unicode?

Quote:

>>
>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.

Quote:

>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?

Quote:

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?

Ioannis Vranos wrote:

Quote:

Interesting link on C++0x indeed:
>
http://en.wikipedia.org/wiki/C%2B%2B0x

There it is mentioned:

"For the purpose of enhancing support for Unicode in C++ compilers, the
definition of the type char has been modified to be both at least the
size necessary to store an eight-bit coding of UTF-8 and large enough to
contain any member of the compilers basic execution character set. It
was previously defined as only the latter".

Regarding UTF8, Wikipedia mentions:

"UTF-8 encodes each character in one to four octets (8-bit bytes):

1. One byte is needed to encode the 128 US-ASCII characters (Unicode
range U+0000 to U+007F).
2. Two bytes are needed for Latin letters with diacritics and for
characters from Greek, Cyrillic, Armenian, Arabic, Syriac and Thaana
alphabets (Unicode range U+0080 to U+07FF).
3. Three bytes are needed for the rest of the Basic Multilingual
Plane (which contains virtually all characters in common use).
4. Four bytes are needed for characters in the other planes of
Unicode, which are rarely used in practice".

So I am confused.

Q1: Will "char" support only one of these 4 8-bit bytes or all of them?
If only one, which one?

Q2: Do we also get the restriction of a 8-bit char? What will happen on
machines where a byte is different than 8 bits?

In such a system how many bytes will sizeof(char) be? char becomes
unsigned char only? CHAR_BIT of <climits>, <limits.h>, and
<numeric_limits<char>::digits of <limitsbecome always 8?

Currently there are systems where CHAR_BIT and
numeric_limits<char>::digits are more than 8.

James Kanze wrote:

Quote:

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....

On 2008-01-17 11:48, Ioannis Vranos wrote:

Quote:

Ioannis Vranos wrote:

Quote:

>Interesting link on C++0x indeed:
>>
>http://en.wikipedia.org/wiki/C%2B%2B0x

>
>
There it is mentioned:
>
"For the purpose of enhancing support for Unicode in C++ compilers, the
definition of the type char has been modified to be both at least the
size necessary to store an eight-bit coding of UTF-8 and large enough to
contain any member of the compilers basic execution character set. It
was previously defined as only the latter".
>
>
Regarding UTF8, Wikipedia mentions:
>
"UTF-8 encodes each character in one to four octets (8-bit bytes):
>
1. One byte is needed to encode the 128 US-ASCII characters (Unicode
range U+0000 to U+007F).
2. Two bytes are needed for Latin letters with diacritics and for
characters from Greek, Cyrillic, Armenian, Arabic, Syriac and Thaana
alphabets (Unicode range U+0080 to U+07FF).
3. Three bytes are needed for the rest of the Basic Multilingual
Plane (which contains virtually all characters in common use).
4. Four bytes are needed for characters in the other planes of
Unicode, which are rarely used in practice".
>
>
So I am confused.
>
>
Q1: Will "char" support only one of these 4 8-bit bytes or all of them?
If only one, which one?

There is only one thing to support, and if char is 8 bits that is
supported. What is meant with the above is that if you want to use a
character which is not included in the 128 US-ASCII characters you will
need a sequence of two or more chars, i.e. in a char array of size 4 you
can encode all Unicode characters.

Quote:

Q2: Do we also get the restriction of a 8-bit char? What will happen on
machines where a byte is different than 8 bits?

What restrictions are you talking about? A C++ byte is as large as it
needs to be, but at least 8 bits.

Quote:

In such a system how many bytes will sizeof(char) be? char becomes
unsigned char only? CHAR_BIT of <climits>, <limits.h>, and
<numeric_limits<char>::digits of <limitsbecome always 8?

sizeof(char), sizeof(unsigned char), and sizeof(signed char) is defined
to be 1. Or put another way, in C++ a byte is as large as a char. The
number of bits in a char is implementation defined.

--
Erik WikstrÃ¶m

red floyd wrote:

Quote:

James Kanze wrote:
>

Quote:

>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.

Ron Natalie wrote:

Quote:

red floyd wrote:

Quote:

>James Kanze wrote:
>>

Quote:

>>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

Victor Bazarov wrote:

Quote:

Now what do you call a 16-bit integral type after that?
A 'really short' or a 'long char'?
>

short short?

Ron Natalie wrote:

Quote:

Victor Bazarov wrote:
>

Quote:

>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?

Victor Bazarov wrote:

Quote:

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.

Matthias Buelow wrote:

Quote:

Victor Bazarov wrote:
>

Quote:

>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

Victor Bazarov wrote:

Quote:

>
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.

Is there any intXX_t type in C++03? Will there be any in C++0x?

On 2008-01-18 18:16, Ioannis Vranos wrote:

Quote:

Victor Bazarov wrote:

Quote:

>>
>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.

>
>
Is there any intXX_t type in C++03? Will there be any in C++0x?

<stdint.h>/<cstdintwill be in C++0x.

--
Erik WikstrÃ¶m

On Jan 18, 5:10 pm, Matthias Buelow <m...@incubus.dewrote:

Quote:

Victor Bazarov wrote:

Quote:

Now what do you call a 16-bit integral type after that?
A 'really short' or a 'long char'?

Quote:

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.

Short was present in K&R-I; same size as int on a PDP-11 and a
Honeywell 6000, smaller on IBM 370 and Interdata 8/32.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Having char being a UTF8 Unicode type, what happens to implementations
that support EBCDIC characters and char holds EBCDIC characters?

http://en.wikipedia.org/wiki/EBCDIC

In article <fmrf8c$125a$1@ulysses.noc.ntua.gr>,
ivranos@no.spamfreemail.nospam.gr says...

Quote:

Having char being a UTF8 Unicode type, what happens to implementations
that support EBCDIC characters and char holds EBCDIC characters?

Char is not a UTF-8 Unicode type. Rather, it is a type that is
guaranteed to be at least 8 bits, so it can _hold_ UTF-8 data -- but it
can also hold whatever other data you prefer that will fit.

On an EBCDIC machine, you'd create an EBCDIC string just like you always
have:

char x[] = "abcdef";

but if you want a UTF-8 string, you can do:

char x[] = u8"abcdef";

The former uses whatever character set has been chosen by the
implementation. The latter is guaranteed to use UTF-8 encoding (or,
under the as-if rule, is at least guaranteed to act like it did...)

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jerry Coffin wrote:

Quote:

>
Char is not a UTF-8 Unicode type. Rather, it is a type that is
guaranteed to be at least 8 bits, so it can _hold_ UTF-8 data -- but it
can also hold whatever other data you prefer that will fit.
>
On an EBCDIC machine, you'd create an EBCDIC string just like you always
have:
>
char x[] = "abcdef";
>
but if you want a UTF-8 string, you can do:
>
char x[] = u8"abcdef";
>
The former uses whatever character set has been chosen by the
implementation. The latter is guaranteed to use UTF-8 encoding (or,
under the as-if rule, is at least guaranteed to act like it did...)

I have created a new thread with subject: "C++0x two Unicode proposals.
A correction one and a different one", two days ago. Please comment in
that thread. Thanks for your comments.

Regards,

Ioannis A. Vranos

next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

re: next ISO C++ standard

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about