Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > next ISO/ANSI standard for C++

Reply
Thread Tools

next ISO/ANSI standard for C++

 
 
skoco
Guest
Posts: n/a
 
      02-11-2004
Hello!
Do you know when will be the new standard for c++ approved? And WHAT
will be inside? Hope there will be some thread and synchro classes,
text and XML parsing, new containers and other new things. God save me
from coding in boring & slow & no pointers java!!
p.s.: how much time usually needs the compiler vendors to implement
new standards?
p.s.2: anybody knows which compiler supports export keyword?

Thanks to you all.
 
Reply With Quote
 
 
 
 
Sharad Kala
Guest
Posts: n/a
 
      02-11-2004

"skoco" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> Hello!
> Do you know when will be the new standard for c++ approved? And WHAT
> will be inside? Hope there will be some thread and synchro classes,
> text and XML parsing, new containers and other new things. God save me
> from coding in boring & slow & no pointers java!!
> p.s.: how much time usually needs the compiler vendors to implement
> new standards?
> p.s.2: anybody knows which compiler supports export keyword?


I don't know when C++ standard is going to be revised again. But I really wish
that things you mentioned like threads, XML parsing etc are included this time.
Now that jdk1.5 is out and it has generics support (on template lines), C++
should also get rich enough with other things in a standard way.
No idea how much time our compiler vendors will take to adopt the new additions.
May be people like Greg Comeau can comment on this
Right now only Comeau has proper support for export keyword AFAIK.

-Sharad



 
Reply With Quote
 
 
 
 
Wolfgang Kaufmann
Guest
Posts: n/a
 
      02-11-2004
* Thus spoke skoco <(E-Mail Removed)>:

Hallo,

> Do you know when will be the new standard for c++ approved?


No. My guess is that we won't be seeing it any time soon. (2006-2009)

> And WHAT will be inside?


<http://std.dkuug.dk/jtc1/sc22/wg21/>

> p.s.: how much time usually needs the compiler vendors to implement
> new standards?


Too long.


Wolfgang.
--
"I can remember the exact instant when I realized that a large part of my life
from then on was going to be spent in finding mistakes in my own programs."
-- Maurice Wilkes, 1947
 
Reply With Quote
 
Claudio Puviani
Guest
Posts: n/a
 
      02-11-2004
"Sharad Kala" <(E-Mail Removed)> wrote
>
> "skoco" <(E-Mail Removed)> wrote
> > Hello!
> > Do you know when will be the new standard for c++ approved? And WHAT
> > will be inside? Hope there will be some thread and synchro classes,
> > text and XML parsing, new containers and other new things. God save me
> > from coding in boring & slow & no pointers java!!
> > p.s.: how much time usually needs the compiler vendors to implement
> > new standards?
> > p.s.2: anybody knows which compiler supports export keyword?

>
> I don't know when C++ standard is going to be revised again. But I really wish
> that things you mentioned like threads, XML parsing etc are included this

time.
> Now that jdk1.5 is out and it has generics support (on template lines), C++
> should also get rich enough with other things in a standard way.
> No idea how much time our compiler vendors will take to adopt the new

additions.
> May be people like Greg Comeau can comment on this
> Right now only Comeau has proper support for export keyword AFAIK.


I don't mean this deprecatingly, but the you both seem to be new to C++ and
unaware of the underlying philosophy of the language. C++, like C, takes a
minimalist approach to language features and standard libraries, which is what
has allowed C and C++ to be so easily ported to a large number of vastly
different platforms. Let's look at your wish list point by point:

1) Threads - threads are a concept that doesn't exist on every platform. Many
embedded systems don't have threads. Some older, but still supported systems,
also don't have threads. For this reason alone, adding threads to the language
is dangerous. But to make things worse, threads don't work the same way on all
operating systems. Some allow different scheduling strategies, some don't. Some
allow time slice quantization, some don't. Some allow scheduling priorities,
some don't. Some allow signals to go to any thread, some force signals to go to
specific threads, some have no signals at all. The Standards committee isn't
about to jump in that tar pit when they can just waggle their finger in the
direction of pthreads.

2) Synchronization mechanisms - even if we ignore point 1, which would make this
point moot, and look at the simplest of synchronization mechanisms: the mutex.
Even lowly mutexes are different across platforms. On some platforms, mutexes
are recursive, on others, recursive calls deadlock you. On some platforms,
mutexes can be shared across processes, on others, you have different promitives
to do that. And then, the poor Standards critters would have to choose what
primitives to include. Semaphores? Condition variables? Events? Mailboxes? FIFO
queues? Atomic integer operations? And do you emulate them on platforms that
don't support them natively? With all respect due to the immensely competent
people on the committee, I wouldn't trust even them to make that choice for me.

3) XML - now this one's easy. XML is an application-specific data
representation. That has no business being shoehorned into a language
specification. Again, the Standards committee would correctly point you to one
of the many existing libraries.

This keeps coming back, but the C++ community just doesn't want a Java-like,
bloated, jack-of-all-trades-but-master-of-none standard library.

Claudio Puviani


 
Reply With Quote
 
Sharad Kala
Guest
Posts: n/a
 
      02-11-2004

> I don't mean this deprecatingly, but the you both seem to be new to C++ and
> unaware of the underlying philosophy of the language. C++, like C, takes a
> minimalist approach to language features and standard libraries, which is what
> has allowed C and C++ to be so easily ported to a large number of vastly
> different platforms. Let's look at your wish list point by point:


Don't want to sound cheeky, cocky or start a flame war but seems like you think
you are expert enough to judge other people. I personally think one should
refrain from it unless you like to argue much.

Most of the projects I have worked on have required XML somewhere or the other.
You need to resort to 3rd party libraries like Xerces/MSXML etc and their
intricacies each time you switch to a new library.
Wouldn't be good if there was a standard way to write the code and it would have
been portable too.

I know writing programs involving threads in a standard way is tricky, owing to
OS differences.
But now that most of the major projects require threads somewhere or the other
and then you include #ifdefs for your platform in your code because your product
runs on various platforms. Wouldn't it be good to just provide a standard way of
making the calls and let the compiler decide what to do under the hood?

Though I agree with you that the minimalist approach has made C and C++ to be
easily portable across platforms and extending the library would require more
work to be done by our compiler vendors. I have been reading about the
possibilities of library getting extended for quite some time and just voiced
what I felt would make life of a developer to concentrate more on standard ways
rather than deal with 3rd party or OS intricacies.

-Sharad


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      02-11-2004
"Sharad Kala" <(E-Mail Removed)> wrote...
>
> > I don't mean this deprecatingly, but the you both seem to be new to C++

and
> > unaware of the underlying philosophy of the language. C++, like C, takes

a
> > minimalist approach to language features and standard libraries, which

is what
> > has allowed C and C++ to be so easily ported to a large number of vastly
> > different platforms. Let's look at your wish list point by point:

>
> Don't want to sound cheeky, cocky or start a flame war but seems like you

think
> you are expert enough to judge other people. I personally think one should
> refrain from it unless you like to argue much.


Everybody is allowed to judge other people, and one doesn't have to be
an expert to do that (at least according to my experience). This is
a public forum and I personally think one should refrain from telling
others what they should refrain from (although I don't always follow
my own advice either).

> Most of the projects I have worked on have required XML somewhere or the

other.

So what? Out of twenty-plus years I've been programming, only about
two years total I did some work involving XML. Doesn't at all speak
to XML widespread-ness, but mostly to the length of one's career, no?

> You need to resort to 3rd party libraries like Xerces/MSXML etc and their
> intricacies each time you switch to a new library.
> Wouldn't be good if there was a standard way to write the code and it

would have
> been portable too.


No, it wouldn't. Just like it wouldn't to have some kind of networking
or GUI capability.

> I know writing programs involving threads in a standard way is tricky,

owing to
> OS differences.
> But now that most of the major projects require threads somewhere


Got any statistics about that?

> or the other
> and then you include #ifdefs for your platform in your code because your

product
> runs on various platforms. Wouldn't it be good to just provide a standard

way of
> making the calls and let the compiler decide what to do under the hood?


No. The more the compiler has to decide, the less probable it is to
have a decent compiler or a compiler that satisfies enough people for
it to be a viable product. By the time such compiler comes out, the
language will have died.

>
> Though I agree with you that the minimalist approach has made C and C++ to

be
> easily portable across platforms and extending the library would require

more
> work to be done by our compiler vendors. I have been reading about the
> possibilities of library getting extended for quite some time and just

voiced
> what I felt would make life of a developer to concentrate more on standard

ways
> rather than deal with 3rd party or OS intricacies.


Please voice it in comp.std.c++ and see what kind of reaction you get.

"OS intricacies" are not going away any time soon, and are becoming more
and more numerous every year. How do you really expect language creators
to follow those and integrate them into the language? And (for the sake
of argument) if the Committee does catch up with OS changes and other new
technologies (like XML) popping up here and there, you would also need
compiler developers to catch up, and they cannot do it without the language
being fully defined.

The only way to standardise C++ way of treating things like network, GUI,
XML, threads, OS-specific stuff, etc., is to make them standard as well.
How long will that take and how rigid will they become?

V


 
Reply With Quote
 
Jason
Guest
Posts: n/a
 
      02-11-2004
"Sharad Kala" <(E-Mail Removed)> wrote in message news:c0dhv0>
Most of the projects I have worked on have required XML somewhere or the
other.
> You need to resort to 3rd party libraries like Xerces/MSXML etc and their
> intricacies each time you switch to a new library.
> Wouldn't be good if there was a standard way to write the code and it

would have
> been portable too.


There are many 3rd party libraries, or you can even write your own XML
parser (gasp!). C++ is used because it, as a "core entity", is portable. If
you add too many features too quickly it is hard to find conforming
compilers. With Java this isn't the case, because Sun make Java and it's
class libraries, and that is the end of things; there is no need for vendor
agreement. What I am trying to say is C++ is borne out of a different
community ethic.

Anyway, what about ASN.1. I want ASN.1 support in C++ not pesky XML.

.... these are my thoughts anyway, and of course they are not correct in any
formal sense.


 
Reply With Quote
 
Peter van Merkerk
Guest
Posts: n/a
 
      02-11-2004
"Sharad Kala" <(E-Mail Removed)> wrote in message
news:c0dhv0$15p7am$(E-Mail Removed)-berlin.de...
>
> > I don't mean this deprecatingly, but the you both seem to be new to C++

and
> > unaware of the underlying philosophy of the language. C++, like C,

takes a
> > minimalist approach to language features and standard libraries, which

is what
> > has allowed C and C++ to be so easily ported to a large number of

vastly
> > different platforms. Let's look at your wish list point by point:

>
> Don't want to sound cheeky, cocky or start a flame war but seems like you

think
> you are expert enough to judge other people. I personally think one

should
> refrain from it unless you like to argue much.
>
> Most of the projects I have worked on have required XML somewhere or the

other.

Your experience is not necessarilly representative for the rest of the
world. The majority of projects I have done many projects that didn't
involve XML. What people use most is highly dependant on the kind of
projects they do and what kind of business they are in.

> You need to resort to 3rd party libraries like Xerces/MSXML etc and their
> intricacies each time you switch to a new library.


I would not like to see standard C++ become as bloated as Java. I would
like to see (interface) standardization for libraries in some areas, but
not as part of the C++ standard.

> Wouldn't be good if there was a standard way to write the code and it

would have
> been portable too.


The way I see it is best to keep the core of C++ lean and mean. The more
features that are added to core definition the less portable the language
becomes, simply because some features are not available on every
conceivable platform. For areas that tend to be domain specific I prefer to
see separate standards, rather than a single standard that covers
everything-but-the-kitchen-sink.

> I know writing programs involving threads in a standard way is tricky,

owing to
> OS differences.
> But now that most of the major projects require threads somewhere or the

other
> and then you include #ifdefs for your platform in your code because your

product
> runs on various platforms. Wouldn't it be good to just provide a standard

way of
> making the calls and let the compiler decide what to do under the hood?


Yes, but what if the compiler cannot make that decision? How to overcome
conceptual differences? Often the differences are more than just different
names for functions that do the same thing. Just letting the compiler deal
with it (emulating things in case of semantic differences) would lead to
suboptimal results, less programmer control and more likely to lead to
unexpected behaviour.

Don't get me wrong, I would like to see standardization in this area. I
write software that has to run on multiple platforms, and I know that it is
a real pain to get software to do compile and do the right thing on all
platforms. But the problems described above are based on experiences with
libraries that hide platform differences (with varing success).

> Though I agree with you that the minimalist approach has made C and C++

to be
> easily portable across platforms and extending the library would require

more
> work to be done by our compiler vendors. I have been reading about the
> possibilities of library getting extended for quite some time and just

voiced
> what I felt would make life of a developer to concentrate more on

standard ways
> rather than deal with 3rd party or OS intricacies.


Maybe you feel more comfortable with Java (not flame, just a suggestion).

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl




 
Reply With Quote
 
Sharad Kala
Guest
Posts: n/a
 
      02-11-2004

"Victor Bazarov" <(E-Mail Removed)> wrote in message
newstsWb.7733$uV3.18367@attbi_s51...
> "Sharad Kala" <(E-Mail Removed)> wrote...
> >
> > > I don't mean this deprecatingly, but the you both seem to be new to C++

> and
> > > unaware of the underlying philosophy of the language. C++, like C, takes

> a
> > > minimalist approach to language features and standard libraries, which

> is what
> > > has allowed C and C++ to be so easily ported to a large number of vastly
> > > different platforms. Let's look at your wish list point by point:

> >
> > Don't want to sound cheeky, cocky or start a flame war but seems like you

> think
> > you are expert enough to judge other people. I personally think one should
> > refrain from it unless you like to argue much.

>
> Everybody is allowed to judge other people, and one doesn't have to be
> an expert to do that (at least according to my experience). This is
> a public forum and I personally think one should refrain from telling
> others what they should refrain from (although I don't always follow
> my own advice either).


I never asked anyone not to refrain. I cannot stop anyone as you correctly
pointed out it's a public forum.
I just said that "I personally think...". I just told that one should be careful
enough while making statements
if one wants to have healthy discussions rather than ego-clashes.


> > Most of the projects I have worked on have required XML somewhere or the

> other.
>
> So what? Out of twenty-plus years I've been programming, only about
> two years total I did some work involving XML. Doesn't at all speak
> to XML widespread-ness, but mostly to the length of one's career, no?


XML has become popular only in recent years.
I may be near about your half age and cannot claim to say that this has been in
use for 20 yrs. But in the recent times XML has become an important form of data
exchange. There are even industry-wide protocols that are entirely XML based.
Atleast it has so happened that I have had to deal with XML in all my projects.

> > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
> > intricacies each time you switch to a new library.
> > Wouldn't be good if there was a standard way to write the code and it

> would have
> > been portable too.

>
> No, it wouldn't. Just like it wouldn't to have some kind of networking
> or GUI capability.


Getting offtopic..Just the other day I helped someone with Xerces because it has
peculiarity with treating whitespaces as text nodes.
There is a transcode API that allocates memory and expects user to free it.
Point is there are so many intracacies in handling with these
3rd party libraries.

> > I know writing programs involving threads in a standard way is tricky,

> owing to
> > OS differences.
> > But now that most of the major projects require threads somewhere

>
> Got any statistics about that?

Nope.

> > or the other
> > and then you include #ifdefs for your platform in your code because your

> product
> > runs on various platforms. Wouldn't it be good to just provide a standard

> way of
> > making the calls and let the compiler decide what to do under the hood?

>
> No. The more the compiler has to decide, the less probable it is to
> have a decent compiler or a compiler that satisfies enough people for
> it to be a viable product. By the time such compiler comes out, the
> language will have died.


Agreed. As I said earlier too that writing thread code in a standard way would
be tricky. Thread started with what *would* be good to have in a standard
library.
But I do agree that it's a lot of work for compiler vendors.Don't think though
it's the case with XML though.

> > Though I agree with you that the minimalist approach has made C and C++ to

> be
> > easily portable across platforms and extending the library would require

> more
> > work to be done by our compiler vendors. I have been reading about the
> > possibilities of library getting extended for quite some time and just

> voiced
> > what I felt would make life of a developer to concentrate more on standard

> ways
> > rather than deal with 3rd party or OS intricacies.

>
> Please voice it in comp.std.c++ and see what kind of reaction you get.
>
> "OS intricacies" are not going away any time soon, and are becoming more
> and more numerous every year. How do you really expect language creators
> to follow those and integrate them into the language? And (for the sake
> of argument) if the Committee does catch up with OS changes and other new
> technologies (like XML) popping up here and there, you would also need
> compiler developers to catch up, and they cannot do it without the language
> being fully defined.
>
> The only way to standardise C++ way of treating things like network, GUI,
> XML, threads, OS-specific stuff, etc., is to make them standard as well.
> How long will that take and how rigid will they become?


I see your point and do agree to many extents with even what Claudio has to say.
Let me clearify here. I just meant it would have been good had there been
standard ways
to do things. Never meaning that it *should* be the case or that there are no
issues with extending the library.





 
Reply With Quote
 
Sharad Kala
Guest
Posts: n/a
 
      02-11-2004

"Peter van Merkerk" <(E-Mail Removed)> wrote in message
news:c0dll9$15pv8g$(E-Mail Removed)-berlin.de...
> "Sharad Kala" <(E-Mail Removed)> wrote in message
> news:c0dhv0$15p7am$(E-Mail Removed)-berlin.de...
> >
> > > I don't mean this deprecatingly, but the you both seem to be new to C++

> and
> > > unaware of the underlying philosophy of the language. C++, like C,

> takes a
> > > minimalist approach to language features and standard libraries, which

> is what
> > > has allowed C and C++ to be so easily ported to a large number of

> vastly
> > > different platforms. Let's look at your wish list point by point:

> >
> > Don't want to sound cheeky, cocky or start a flame war but seems like you

> think
> > you are expert enough to judge other people. I personally think one

> should
> > refrain from it unless you like to argue much.
> >
> > Most of the projects I have worked on have required XML somewhere or the

> other.
>
> Your experience is not necessarilly representative for the rest of the
> world. The majority of projects I have done many projects that didn't
> involve XML. What people use most is highly dependant on the kind of
> projects they do and what kind of business they are in.


True..I can only voice my opinions.

> > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
> > intricacies each time you switch to a new library.

>
> I would not like to see standard C++ become as bloated as Java. I would
> like to see (interface) standardization for libraries in some areas, but
> not as part of the C++ standard.


Yes, there needs to be some kind of standardization if not in standard then with
3rd library interfaces.

> > Wouldn't be good if there was a standard way to write the code and it

> would have
> > been portable too.

>
> The way I see it is best to keep the core of C++ lean and mean. The more
> features that are added to core definition the less portable the language
> becomes, simply because some features are not available on every
> conceivable platform. For areas that tend to be domain specific I prefer to
> see separate standards, rather than a single standard that covers
> everything-but-the-kitchen-sink.


> > I know writing programs involving threads in a standard way is tricky,

> owing to
> > OS differences.
> > But now that most of the major projects require threads somewhere or the

> other
> > and then you include #ifdefs for your platform in your code because your

> product
> > runs on various platforms. Wouldn't it be good to just provide a standard

> way of
> > making the calls and let the compiler decide what to do under the hood?

>
> Yes, but what if the compiler cannot make that decision? How to overcome
> conceptual differences? Often the differences are more than just different
> names for functions that do the same thing. Just letting the compiler deal
> with it (emulating things in case of semantic differences) would lead to
> suboptimal results, less programmer control and more likely to lead to
> unexpected behaviour.
>
> Don't get me wrong, I would like to see standardization in this area. I
> write software that has to run on multiple platforms, and I know that it is
> a real pain to get software to do compile and do the right thing on all
> platforms. But the problems described above are based on experiences with
> libraries that hide platform differences (with varing success).



>
> Maybe you feel more comfortable with Java (not flame, just a suggestion).


Not actually. C++ has been my 1st love as far as PLs go

I am aware with the issues in having a standard with everything.
When I replied to the OP I just supported the *wish* to point out the numerous
differences one has
to deal with different OS/libraries. I know that it isn't actually actually
feasible to have a standard for everything
unless one is ready to compromise with efficiency and performance.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Reading of file by next of map file and by next of file descriptor. =?ISO-8859-2?Q?Miros=B3aw?= Makowiecki C++ 1 07-10-2007 02:46 AM
Perl 5.00404 - Label not found for "next " , next() function Liora Perl Misc 5 01-12-2007 03:36 AM
Next (the other next) Gen "DVD" storage Alan Browne Digital Photography 13 05-31-2005 05:53 PM
CurrentElement->next = CurrentElement->next->next (UNDEFINED?) Deniz Bahar C Programming 2 03-09-2005 12:45 AM
Skipping content in Array within loop and go to the next (of NEXT function) Tad McClellan Perl Misc 3 05-13-2004 10:14 PM



Advertisments