Topic: The future of C++
Author: Alexander Terekhov <terekhov@web.de>
Date: Fri, 14 May 2004 21:10:22 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
[...]
> That's not the purpose; if an object such as std::string is to be
> immutable, it must be constructed before the first user thread is
> created.
It must not.
> The problem is that if you have something like:
>
> static std::string const ref( "someText" ) ;
>
> void
> f( std::string const& param )
> {
> if ( param == ref ) ...
> }
>
> you need a lock around the if.
You need not.
> Whereas if I do the same thing with char
> const[]/char const* and strcmp, I don't. (I am assuming, of course,
> that param is only visible in the calling thread, and that f can be
> called from more than one thread.)
You don't need a lock if you do the same thing with std::string.
>
> This seems counter-intuitive; one expects user defined types, especially
> such low level user defined types, to behave more or less like built-in
> types.
I agree that the following is kinda counter-intuitive.
int thing[123];
int read_global_thing() {
return thing[0]; // non-modifying access
}
vs
std::string thing;
int read_global_thing() {
return thing[0]; // modifying access
}
But the problem doesn't arise if you access it via "const &".
regards,
alexander.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Fri, 7 May 2004 14:38:14 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message
news:<uisfbeyvq.fsf@boost-consulting.com>...
> kanze@gabi-soft.fr writes:
> > Frank Buss <fb@frank-buss.de> wrote in message
> > news:<c7392u$88v$1@newsreader2.netcologne.de>...
> >> kanze@gabi-soft.fr wrote:
> > [...]
> >> > At least if I understand the documentation correctly, it also
> >> > can't be used directly for what is one of the more common
> >> > locking idioms in my code: the lock is acquired in a function
> >> > and is returned as part of the return value. (Typically in a
> >> > sort of a smart pointer -- I acquire access to the object and a
> >> > lock for it from a single function, and automatically free the
> >> > lock when the access goes out of scope. The entire thing works
> >> > a lot like auto_ptr, with the addition that which ever object
> >> > holds the valid pointer also holds the lock.)
> >> Looks like a mutex is what you are searching for, perhaps wrapped
> >> in a small class with overloaded operator= etc., something like a
> >> smart pointer which wraps a mutex.
> > I know what I am looking for; I've even written it for Posix
> > compatible platforms:-). You cut the sentence I was responding to:
> > a recommendation to use Boost's threading package. Boost's
> > threading package requires the lock on a mutex to have lexical
> > scope; there are a lot of times when my locks don't -- the respect
> > transfer of ownership rules much like those of auto_ptr.
> That's why we didn't prohibit dynamic allocation of locks ;-)
Yes. std::auto_ptr< boost::lock > would do the trick:-). However:
I originally started thinking about the issue during an email discussion
with Scott Meyers over the double checked locking idiom for a
singleton. The fact is that there is no correct implementation which
doesn't either lock on every call to Singleton::instance, or use
assembler or some other very special code to implement memory barriers.
But it occured to me that very often, using the singleton, once you
acquired the reference to it, would also require a lock, and that in
such cases, if you used the same lock when accessing the singleton AND
in Singleton::instance(), you don't pay any more for locking than if
Singleton::instance() wasn't locked -- all you've done is move the
acquisition of the lock necessary to use the singleton forward.
And while using
std::auto_ptr< boost::lock >( new boost::lock( someMutex ) )
would certainly fulfil the desired semantics, I suspect that most
implementations of operator new will also acquire a lock, which defeats
the whole purpose of the exercise.
Now, I basically think that the "correct" solution is to just lock in
Singleton::instance(), and then lock when you access the object, using
two separate lock/unlock sequences, at least until the profiler says
otherwise. And that when the profiler says otherwise, the simplest
solution is just to drop the locks in Singleton::instance(), and ensure
that Singleton::instance() is called at least once before threading is
started. But the context of the discussion was saving a lock, and the
problem is intellectually stimulating, even if it is of no practical
interest:-).
And finally, having thought about all this, it occured to me that we do
something similar in our current application. In our case, it isn't
singletons, but objects acquired from our data base -- we acquire an
object through a smart pointer, which also manages a lock on the
object. Here too, I'm not convinced that this is the right solution --
we now access several different objects in the same transaction, which
requires some special, and fairly complex, code to avoid deadlocks. But
it was a very elegant solution for the initial requirements, where the
code never accessed more than one object at a time.
> Yes, a moveable but non-copyable lock would be better.
Or maybe a lock-ownership policy:-). I can imagine that there are a few
cases where reference counted locks might be reasonable too.
Seriously, I'm against over complexity. The Boost solution is right
something between 90-95% of the time. All I'd ask for is access to the
underlying lock()/unlock() functions on mutex, so I can provide a custom
solution for the few remaining cases.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orient e objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Alexander Terekhov <terekhov@web.de>
Date: Mon, 10 May 2004 01:07:02 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
[...]
> I originally started thinking about the issue during an email discussion
> with Scott Meyers over the double checked locking idiom for a
> singleton. The fact is that there is no correct implementation which
> doesn't either lock on every call to Singleton::instance, or use
> assembler or some other very special code to implement memory barriers.
Thread-specific data can be used instead of atomic<>-with-membars.
> But it occured to me that very often, using the singleton, once you
> acquired the reference to it, would also require a lock,
Not if it's immutable (or uses atomic<> internally).
regards,
alexander.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Mon, 10 May 2004 01:07:02 +0000 (UTC) Raw View
kanze@gabi-soft.fr writes:
> > That's why we didn't prohibit dynamic allocation of locks ;-)
>
> Yes. std::auto_ptr< boost::lock > would do the trick:-). However:
>
> I originally started thinking about the issue during an email discussion
> with Scott Meyers over the double checked locking idiom for a
> singleton. The fact is that there is no correct implementation which
> doesn't either lock on every call to Singleton::instance, or use
> assembler or some other very special code to implement memory barriers.
You use boost::call_once and that problem goes away.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Michael Glassford <nospam@hotmail.com>
Date: Mon, 10 May 2004 01:07:03 +0000 (UTC) Raw View
<kanze@gabi-soft.fr> wrote in message
news:d6652001.0405060058.610b9f10@posting.google.com...
[snip discussion of std::auto_ptr< boost::lock >(...), etc.]
> Seriously, I'm against over complexity. The Boost solution is right
> something between 90-95% of the time. All I'd ask for is access to
> the underlying lock()/unlock() functions on mutex, so I can provide
a
> custom solution for the few remaining cases.
I'll add it to my list of things to think about. As a quick idea,
would adding protected lock() and unlock() members to the mutex
classes work? (Not public so they can't be called accidentally by
users of the class, not private so you can create a derived mutex
class that works in conjunction with a lock class that you design).
Mike
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Matt Austern <austern@well.com>
Date: Mon, 10 May 2004 01:07:03 +0000 (UTC) Raw View
dave@boost-consulting.com (David Abrahams) writes:
> kanze@gabi-soft.fr wrote in message news:<d6652001.0404230219.38317210@posting.google.com>...
> > David Abrahams <dave@boost-consulting.com> wrote in message
> > news:<ur7uh6v88.fsf@boost-consulting.com>...
> > > davideng2004@yahoo.com (David Eng) writes:
> >
> > > > We are moving to grid computing, yet C++ committee doesn't think it
> > > > is important to standardize a thread library.
> >
> > > Please. Did you submit a proposal for a standard threads library?
> > > Did anyone? [hint: the answer is no]
> >
> > I was under the impression that the Boost threading library was being
> > discussed. Internally, of course, and only for inclusion in the next
> > version of the standard.
>
> Someone may be discussing it, but if so only in the hallways between
> sessions. And we don't have a proposal. Without a proposal, hallway
> discussion is not very meaningful.
We don't have a proposal yet, but my understanding is the same as
James's: that there's discussion going on, with the intention that
a proposal be submitted.
At the moment I believe that Boost threading library is the only
threading library that's likely to be proposed any time soon. So if
anyone here has an alternative threading approach that they prefer,
now's the time to start working on a proposal.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Mon, 10 May 2004 22:06:39 +0000 (UTC) Raw View
Alexander Terekhov <terekhov@web.de> wrote in message
news:<409BB6F4.9A19F5A9@web.de>...
> kanze@gabi-soft.fr wrote:
> [...]
> > I originally started thinking about the issue during an email
> > discussion with Scott Meyers over the double checked locking idiom
> > for a singleton. The fact is that there is no correct
> > implementation which doesn't either lock on every call to
> > Singleton::instance, or use assembler or some other very special
> > code to implement memory barriers.
> Thread-specific data can be used instead of atomic<>-with-membars.
The problem is that at least on some systems, accessing thread specific
data involves acquiring a lock, so you don't gain anything. If an
implementation has a good implementation of thread specific data, of
course, it is an alternative.
> > But it occured to me that very often, using the singleton, once you
> > acquired the reference to it, would also require a lock,
> Not if it's immutable (or uses atomic<> internally).
But if it's immutable, it is sufficient to ensure that it is created
before starting threading, and you don't need a lock anywhere. (Hmmm.
I suppose if you had a data base in which you could create and destroy
objects, but not modify them, the case might occur.)
--
James Kanze GABI Software
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Mon, 10 May 2004 22:13:50 +0000 (UTC) Raw View
Michael Glassford <nospam@hotmail.com> wrote in message
news:<1dGdnXyKGfXWUQbdRVn-hg@adelphia.com>...
> <kanze@gabi-soft.fr> wrote in message
> news:d6652001.0405060058.610b9f10@posting.google.com...
> [snip discussion of std::auto_ptr< boost::lock >(...), etc.]
> > Seriously, I'm against over complexity. The Boost solution is right
> > something between 90-95% of the time. All I'd ask for is access to
> > the underlying lock()/unlock() functions on mutex, so I can provide
> > a custom solution for the few remaining cases.
> I'll add it to my list of things to think about. As a quick idea,
> would adding protected lock() and unlock() members to the mutex
> classes work? (Not public so they can't be called accidentally by
> users of the class, not private so you can create a derived mutex
> class that works in conjunction with a lock class that you design).
That sounds like a very good compromize; about the only possible
objection I can see is that it requires an abuse of derivation to use
the special functions.
In one project I worked on in the past, dangerous functions were
qualified with names beginning with "unsafe_"; what about calling them
"unsafe_lock" and "unsafe_unlock"? (OK, it's just an idea. I'm not
fully convinced myself.)
The real problem, I think, is that we are dealing with two levels of
abstraction, one very low level, where you are on your own, and one at a
higher level, which should be used most of the time. Normally, that
would be two, apparently separate classes, and as long as you dealt
strictly at the higher level, you wouldn't need to even be aware of the
lower level. That doesn't quite work here, because even as a client of
the higher level, you have to manage the lifetime and the sharing of the
lower level object; it would be very hard to use Lock if you couldn't
refer to the mutex it should lock on.
So even from a purely abstract design level, I'm not sure what the most
elegant solution would be. What I want is a low level interface that is
not normally available, but that can be made available if I do something
intentional to get to it. And in fact, the only solution I can think of
which meets exactly those requirements is protected. Even if that
wasn't really the original use protected was designed for. Who knows,
maybe we're even creating a new idiom. (It will be an easy idiom to
recognize. How often do you see protected elements in a class with no
virtual functions?)
--
James Kanze GABI Software
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Mon, 10 May 2004 23:21:44 +0000 (UTC) Raw View
David Abrahams wrote:
> kanze@gabi-soft.fr writes:
>>Yes. std::auto_ptr< boost::lock > would do the trick:-). However:
Somehow, I have the horrible feeling that will break in
an obscure way which will not be discovered until it's too late.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: Tue, 11 May 2004 14:56:49 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
>
> So even from a purely abstract design level, I'm not sure what the most
> elegant solution would be. What I want is a low level interface that is
> not normally available, but that can be made available if I do something
> intentional to get to it.
Sort of like FILE*, from which (with most implementations) you can drop
down to a file descriptor to do lower level reads and writes.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Alexander Terekhov <terekhov@web.de>
Date: Tue, 11 May 2004 14:56:49 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
[...]
> > > But it occured to me that very often, using the singleton, once you
> > > acquired the reference to it, would also require a lock,
>
> > Not if it's immutable (or uses atomic<> internally).
>
> But if it's immutable, it is sufficient to ensure that it is created
> before starting threading, and you don't need a lock anywhere. ...
But that defeats the purpose (save on memory and/or processor
cycles needed to initialize the thing until the first use...
which may never occur).
regards,
alexander.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Thu, 13 May 2004 14:18:33 +0000 (UTC) Raw View
Alexander Terekhov <terekhov@web.de> wrote in message
news:<40A006EA.A41E8CBA@web.de>...
> kanze@gabi-soft.fr wrote:
> [...]
> > > > But it occured to me that very often, using the singleton, once
> > > > you acquired the reference to it, would also require a lock,
> > > Not if it's immutable (or uses atomic<> internally).
> > But if it's immutable, it is sufficient to ensure that it is
> > created before starting threading, and you don't need a lock
> > anywhere. ...
> But that defeats the purpose (save on memory and/or processor cycles
> needed to initialize the thing until the first use... which may never
> occur).
That's not the purpose; if an object such as std::string is to be
immutable, it must be constructed before the first user thread is
created. The problem is that if you have something like:
static std::string const ref( "someText" ) ;
void
f( std::string const& param )
{
if ( param == ref ) ...
}
you need a lock around the if. Whereas if I do the same thing with char
const[]/char const* and strcmp, I don't. (I am assuming, of course,
that param is only visible in the calling thread, and that f can be
called from more than one thread.)
This seems counter-intuitive; one expects user defined types, especially
such low level user defined types, to behave more or less like built-in
types.
--
James Kanze GABI Software
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Frank Buss <fb@frank-buss.de>
Date: Mon, 3 May 2004 15:50:32 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote:
> Not completely. What happens if some of the generated code uses
> static variables. An obvious candidate would be exception processing,
> and at least one compiler I have used does fail if two threads throw
> an exception at the same time.
You are right, the standard must say something about threads to ensure a
compiler, which works with threads, but the language needs not to be
changed, only some definitions for thread safety needs to be added, I
think.
This is not easy, because your problem with static variables and the like
is a general problem of imperative programming languages. The best
solution would be to start threads without manual programming it, which
is possible with referential transparency, because every part of an
expression can be evaluated without side effects:
http://c2.com/cgi/wiki?ReferentialTransparency
But would be nice to have explicit thread support for C++, because
writing imperative programs is easier, at least for me.
> At least if I understand the documentation correctly, it also can't be
> used directly for what is one of the more common locking idioms in my
> code: the lock is acquired in a function and is returned as part of
> the return value. (Typically in a sort of a smart pointer -- I
> acquire access to the object and a lock for it from a single function,
> and automatically free the lock when the access goes out of scope.
> The entire thing works a lot like auto_ptr, with the addition that
> which ever object holds the valid pointer also holds the lock.)
Looks like a mutex is what you are searching for, perhaps wrapped in a
small class with overloaded operator= etc., something like a smart
pointer which wraps a mutex.
--
Frank Bu , fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Tue, 4 May 2004 22:24:58 +0000 (UTC) Raw View
Frank Buss <fb@frank-buss.de> wrote in message
news:<c7392u$88v$1@newsreader2.netcologne.de>...
> kanze@gabi-soft.fr wrote:
[...]
> > At least if I understand the documentation correctly, it also can't
> > be used directly for what is one of the more common locking idioms
> > in my code: the lock is acquired in a function and is returned as
> > part of the return value. (Typically in a sort of a smart pointer
> > -- I acquire access to the object and a lock for it from a single
> > function, and automatically free the lock when the access goes out
> > of scope. The entire thing works a lot like auto_ptr, with the
> > addition that which ever object holds the valid pointer also holds
> > the lock.)
> Looks like a mutex is what you are searching for, perhaps wrapped in a
> small class with overloaded operator= etc., something like a smart
> pointer which wraps a mutex.
I know what I am looking for; I've even written it for Posix compatible
platforms:-). You cut the sentence I was responding to: a
recommendation to use Boost's threading package. Boost's threading
package requires the lock on a mutex to have lexical scope; there are a
lot of times when my locks don't -- the respect transfer of ownership
rules much like those of auto_ptr. And I could imagine that there are
cases where one might want shared ownership as well; after all, most of
the time, you lock to protect access to memory, so it isn't surprising
to find the same idioms for possession of locks as for possession of
memory.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orient e objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Wed, 5 May 2004 19:40:06 +0000 (UTC) Raw View
kanze@gabi-soft.fr writes:
> Frank Buss <fb@frank-buss.de> wrote in message
> news:<c7392u$88v$1@newsreader2.netcologne.de>...
>
>> kanze@gabi-soft.fr wrote:
>
> [...]
>> > At least if I understand the documentation correctly, it also can't
>> > be used directly for what is one of the more common locking idioms
>> > in my code: the lock is acquired in a function and is returned as
>> > part of the return value. (Typically in a sort of a smart pointer
>> > -- I acquire access to the object and a lock for it from a single
>> > function, and automatically free the lock when the access goes out
>> > of scope. The entire thing works a lot like auto_ptr, with the
>> > addition that which ever object holds the valid pointer also holds
>> > the lock.)
>
>> Looks like a mutex is what you are searching for, perhaps wrapped in a
>> small class with overloaded operator= etc., something like a smart
>> pointer which wraps a mutex.
>
> I know what I am looking for; I've even written it for Posix compatible
> platforms:-). You cut the sentence I was responding to: a
> recommendation to use Boost's threading package. Boost's threading
> package requires the lock on a mutex to have lexical scope; there are a
> lot of times when my locks don't -- the respect transfer of ownership
> rules much like those of auto_ptr.
That's why we didn't prohibit dynamic allocation of locks ;-)
Yes, a moveable but non-copyable lock would be better.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: jtorjo@yahoo.com (John Torjo)
Date: Fri, 30 Apr 2004 15:04:31 +0000 (UTC) Raw View
> If technology is changed, the language shall be changed too.
I'm not sure I follow. Should C++ change in order to fit
ADO,ODBC,COM,XML (if you think that's a technology) or who knows what
other technology?
The point is technologies come and go. Should we have C++ features
that just come and go? I think the only thing C++ should do is allow a
technology to be mapped as a library in C++. And I think existing C++
is doing quite a good job at it.
Best,
John
John Torjo
Freelancer
-- john@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: jtorjo@yahoo.com (John Torjo)
Date: Fri, 30 Apr 2004 15:04:36 +0000 (UTC) Raw View
hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<fPmdnXzyEbNVeBTd4p2dnA@speakeasy.net>...
> Jorge Rivera wrote:
>
> >>
> >> I've been putting a lot of time into C++ lately, and I know there are
> >> significant strength in the language that Java lacks. But they may not
> >> be sufficient to keep anything but a niche in the emerging environment.
> >> One view I've seen expressed on usenet is that Sun, Microsoft, IBM,
> >> Borland, etc., are a bunch of idiots for shifting their focus to Java (or
> >> C#).
> >> There's not much to say to in response to such assertions. They seem to
> >> speak for themselves.
> >>
> >
> > I agree that both Java and C# provide more pacakges. However, to me,
> > part of the beaty of C++ is that it is a programming language, not a set
> > of technologies.
>
> I can't say much for C#. I've never even written hello world in it. As for
> Java. Java *_is_* a programming language. It has many very nice features.
> One of the best things about Java is the significant structure it
> manifests. Because of the clearly defined structure of packages
> hierarchies, and the suite of intuitive tools to go with it, it really does
> enhance a more abstract style of programming.
>
> I really don't like to dwell on comparrisons, but some of them are worth
> presenting as a means of suggesting improvements to the way C++ is
> designed, supported, and used. One example that comes to mind from just
> today's experiences is the difference between a typical make and Makefile
> approach to building projects, and the javac and jakarta ant approach.
>
makefiles are a thing of the past.
Usually every IDE has its own way of handling projects (take for
instance msvc).
However, you should try boost bjam. Very easy - sort of a java ant.
>
> OTOH, the fact that Java provides a far more uniform infrastructure across
> platforms and projects makes it far easier to create powerful tools for
> supporting the programmer in these environments. I'm not just talking
> about the JRE. I'm talking about a level of IDE support powerful enough
> that I am virtually assured that my code will compile and run without
> producing errors in the sense defined by the language specification.
>
> Many of these features have their origins in C++, but for one reason or
> another they have not gained the same level of effectiveness in C++ as they
> have in Java.
>
True. I do think that in the near future (3-5 years), someone (maybe
me :D) with a lot of C++ experience should sit down and learning from
C++ mistakes, make a new language.
Best,
John
John Torjo
Freelancer
-- john@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: Fri, 30 Apr 2004 16:01:02 +0000 (UTC) Raw View
In message <6b74193f.0404130754.5c40f511@posting.google.com>, David Eng
<davideng2004@yahoo.com> writes
>As I posted in CORBA group, I believe the future of C++ depends on
>CORBA (the same is true that the future of CORBA depends on the future
>of C++). Applications are built today are distributed applications
>instead of stand alone applications.
There is a common trap that assumes that an individuals view of
something is the same as everyone else's. There are many things done
with C++ that have nothing to do with distributed systems/processes.
Indeed most of the applications I use actually have to be protected from
interference from elsewhere, they are essentially single system, local
applications. For example, when editing digital video I have absolutely
no need for any kind of distributed process and will probably disconnect
from the outside world so as to ensure that nothing interrupts the flow
of data from, for example, camera to hard drive.
In the same way, if CORBA was mainly concerned with C++ it would have no
future. Its strength is exactly that it is multi-platform,
multi-language. It would be a mistake for CORBA to tie itself to C++.
Now, unless some positive suggestions surface I do not intend to further
participate in this dialogue which seems to consist of a good number of
assertions and basically 'X ought to do something about this.' I have
long been a practitioner of the dictum 'Put up, or shut up.' I.e. if you
(generic usage) are not willing to act stop telling other people what
they should do.'
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: jtorjo@yahoo.com (John Torjo)
Date: Fri, 30 Apr 2004 16:38:06 +0000 (UTC) Raw View
jorgeri@rochester.rr.com (Jorge Rivera) wrote in message news:<K0gic.115094$e17.9048@twister.nyroc.rr.com>...
> >
> > I've been putting a lot of time into C++ lately, and I know there are
> > significant strength in the language that Java lacks. But they may not be
> > sufficient to keep anything but a niche in the emerging environment. One
> > view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> > etc., are a bunch of idiots for shifting their focus to Java (or C#).
> > There's not much to say to in response to such assertions. They seem to
> > speak for themselves.
> >
>
> I agree that both Java and C# provide more pacakges. However, to me,
> part of the beaty of C++ is that it is a programming language, not a set
> of technologies.
>
> I don't think the C++ language should grow to the point of Java and C#.
> If you need what Java has, go right ahead and use it. If you're
> needs are well-served by C++, stick to it.
>
> It is simple enough.
>
Right on!
Another thing: generics have a reusability at an order of magnitude
higher that OOP (IMO).
So a good library in C++ is worth 20 of Java or so ;)
Best,
John
John Torjo
Freelancer
-- john@torjo.com
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too
easy!
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.at@xmission.dot.com (llewelly)
Date: Wed, 28 Apr 2004 06:19:48 +0000 (UTC) Raw View
hattons@globalsymmetry.com ("Steven T. Hatton") writes:
[snip]
> OTOH, the fact that Java provides a far more uniform infrastructure across
> platforms and projects makes it far easier to create powerful tools for
> supporting the programmer in these environments. I'm not just talking
> about the JRE. I'm talking about a level of IDE support powerful enough
> that I am virtually assured that my code will compile and run without
> producing errors in the sense defined by the language specification.
>
> Many of these features have their origins in C++, but for one reason or
> another they have not gained the same level of effectiveness in C++ as they
> have in Java.
[snip]
IMO, the primary reason C++ environments typically do not provide
that level of support for writting code which is correct w.r.t
the langauge definition has everything to do with the incredible
complexity of parsing C++, and very little to do what gets
bundled into the standard library. (Short of a complete library
for parsing and transforming C++ source code, that is.)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Wed, 28 Apr 2004 14:45:30 +0000 (UTC) Raw View
Frank Buss <fb@frank-buss.de> wrote in message
news:<c6h93m$5r8$1@newsreader2.netcologne.de>...
> davideng2004@yahoo.com (David Eng) wrote:
[...]
> > Besides, you have to deal with
> > compiler, processor, and memory system if the language doesn't support
> > thread to write multi-thread applications.
> A standard library could hide it, like the STL library hides the
> implementation details.
Not completely. What happens if some of the generated code uses static
variables. An obvious candidate would be exception processing, and at
least one compiler I have used does fail if two threads throw an
exception at the same time.
Generally speaking, threading is a special case, because it must be
recognized by the basic language. Today, in the Unix world, we count on
compilers being not just standard C++ compliant, but also Posix
compliant (and Posix does recognize threads). It's a bit awkward, since
Posix compliance doesn't say anything about threads, but we can
exterpolate most things rather intuitively -- the main unanswered
question concerns the initialization of local static variables (or even
global statics, if a constructor of a global static starts a thread).
> I just can write vector<int> and don't need to know anything about the
> memory system. The Boost library has cross platform thread support:
> http://www.boost.org/libs/thread/doc/index.html
Except that it doesn't work for the most important platform: mine:-).
At least if I understand the documentation correctly, it also can't be
used directly for what is one of the more common locking idioms in my
code: the lock is acquired in a function and is returned as part of the
return value. (Typically in a sort of a smart pointer -- I acquire
access to the object and a lock for it from a single function, and
automatically free the lock when the access goes out of scope. The
entire thing works a lot like auto_ptr, with the addition that which
ever object holds the valid pointer also holds the lock.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orient e objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Wed, 28 Apr 2004 14:45:29 +0000 (UTC) Raw View
Hyman Rosen <hyrosen@mail.com> wrote in message
news:<1082653676.100127@master.nyc.kbcfp.com>...
> Jim Melton wrote:
> > Writing distributed programs is hard.
> And yet, Ada supports it as a built-in feature of
> the language, in compilers which support the
> Distributed Systems Annex E.
> <http://www.adaic.org/standards/95lrm/html/RM-E.html>
That doesn't mean that writing distributed programs isn't hard. It
might mean that if you want to do hard things, you need Ada:-).
Seriously, I'm not sure what a language should do to support distributed
programming. The problem is that so many things that we do which have
negligible cost (for most people) don't have negligible cost when you
distribute. When the cost of calling a function goes up to 10-100
milliseconds, regardless of what you do in the function, you really have
to think about doing as much as possible, in a single function. If I'm
developping in C++, on a single machine, I won't hesitate to use getters
for each individual piece of data. If I'm working over a Corba
interface to a remote machine, however, I'll design a custom function:
getWhatINeed -- the server must know enough about me to send everything
in one go (in a specialized struct which contains everything that I
need, typed).
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orient e objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Thu, 29 Apr 2004 15:58:13 +0000 (UTC) Raw View
kanze@gabi-soft.fr wrote in message news:<d6652001.0404230219.38317210@posting.google.com>...
> David Abrahams <dave@boost-consulting.com> wrote in message
> news:<ur7uh6v88.fsf@boost-consulting.com>...
> > davideng2004@yahoo.com (David Eng) writes:
>
> > > We are moving to grid computing, yet C++ committee doesn't think it
> > > is important to standardize a thread library.
>
> > Please. Did you submit a proposal for a standard threads library?
> > Did anyone? [hint: the answer is no]
>
> I was under the impression that the Boost threading library was being
> discussed. Internally, of course, and only for inclusion in the next
> version of the standard.
Someone may be discussing it, but if so only in the hallways between
sessions. And we don't have a proposal. Without a proposal, hallway
discussion is not very meaningful.
--
David Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Thu, 29 Apr 2004 15:58:13 +0000 (UTC) Raw View
davideng2004@yahoo.com (David Eng) wrote in message news:<6b74193f.0404231240.192743d1@posting.google.com>...
> David Abrahams <dave@boost-consulting.com> wrote in message news:<ur7uh6v88.fsf@boost-consulting.com>...
> > The "C++ committee thinks" (as though we are all of one mind, but I'll
> > play along) that a threading library is important. I don't think we
> > have any threading experts with the time to bring forward a proposal
> > on it. If you think you're qualified, please do it yourself.
>
> No! I don't think I am qualified, but that doesn't mean I cannot have
> a opinion about thread.
You're perfectly qualfied to have an opinion about threads. You're
not qualified to make pronouncements about what the committee thinks
is important.
<snip reasons threads are important>
> For all these reasons, C++ standard
> committee shall consider next standard shall support thread.
Sorry, the committee doesn't work that way. Things don't get
considered just because they're important. It's a volunteer
organization, and topics are only considered when there are people
with the energy and expertise to lead the way. If nobody who can do
that for threads shows up, nothing's going to happen.
--
David Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: davideng2004@yahoo.com (David Eng)
Date: Sat, 24 Apr 2004 23:09:02 +0000 (UTC) Raw View
jorgeri@rochester.rr.com (Jorge Rivera) wrote in message news:<K0gic.115094$e17.9048@twister.nyroc.rr.com>...
> >
> > I've been putting a lot of time into C++ lately, and I know there are
> > significant strength in the language that Java lacks. But they may not be
> > sufficient to keep anything but a niche in the emerging environment. One
> > view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> > etc., are a bunch of idiots for shifting their focus to Java (or C#).
> > There's not much to say to in response to such assertions. They seem to
> > speak for themselves.
> >
>
> I agree that both Java and C# provide more pacakges. However, to me,
> part of the beaty of C++ is that it is a programming language, not a set
> of technologies.
>
> I don't think the C++ language should grow to the point of Java and C#.
> If you need what Java has, go right ahead and use it. If you're
> needs are well-served by C++, stick to it.
>
> It is simple enough.
This is too simplicity. How can you separate a programming language
with a set of technology that use that language. If the technology is
changing, how could the language is not changed? Otherwise, no
technology will use the language.
No one suggests that C++ should grow to the point of Java or C#. But
what's wrong for C++ to add some libraries to help to better use C++?
Do you complain about STL? A programming language never shall be
static. If technology is changed, the language shall be changed too.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.at@xmission.dot.com (llewelly)
Date: Sun, 25 Apr 2004 00:03:43 +0000 (UTC) Raw View
nesotto@cs.auc.dk ("Thorsten Ottosen") writes:
[snip]
> what do you mean? It already has namespaces which IMO are superior
> to packages.
[snip]
What kind of 'packages' are you thinking of? Why do you think
namespaces are superior?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: davideng2004@yahoo.com (David Eng)
Date: Sun, 25 Apr 2004 09:26:13 +0000 (UTC) Raw View
"Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message news:<Fsmdnfd76ID_gxrd4p2dnA@speakeasy.net>...
> I believe C++ has a lot of problems when it comes to competing with Java and
> C#. People who have never coded in Java (I can't comment on C# directly)
> really have no idea of the strengths Java has as far as ease of use.
C++'s disadvantage is not because the strength of Java's ease of use,
rather Java and C# come with a middleware platform.
> C++ _*needs*_ some kind of module support. It probably also should have
> checked exceptions. I have the sense many C++ programmers don't really
> understand the concepts of listeners and events as they are used commonly
> in Java. All one really needs to do is to pick up _The Java Programming
> Language_, by Arnold, Gosling and Holmes, and read the first 10 or so
> chapters to see how much Java offers as core features.
I don't know what you mean by module support. But C++ programmers
know quite well about listeners and events. It is simply a callback
mechanism which is used in every systems. Arnold, Gosling and Holmes'
book is about J2SE. Actually, it is much less offers than C++
standard. The difference is J2SE's extension called J2EE, which is a
middleware platform. J2EE is nothing new. It is based on two
technologies: CGI and CORBA. Unlike CGI and CORBA which are language
independent, J2EE is only for Java so that Java is easier to write
distributed application. However, a distributed environment is
heterogonous. Most mission critical systems cannot afford garbage
collection and unable to access to operating system.
> Too often C++ programmers become defensive and dismissive of these strengths
> of Java. If someone presents an I idea which even hints that it may have
> been influence by java, it is automatically rejected.
I agree. How often some C++ programmer argue C++ is a language and
nothing to do with technology that uses C++. They think C++ shall be
static and needn't change when the technology is changed. I think
this view is very damage to C++. If this view is held, I believe C++
will become FORTURN.
> I've been putting a lot of time into C++ lately, and I know there are
> significant strength in the language that Java lacks. But they may not be
> sufficient to keep anything but a niche in the emerging environment. One
> view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> etc., are a bunch of idiots for shifting their focus to Java (or C#).
> There's not much to say to in response to such assertions. They seem to
> speak for themselves.
Because they don't like CORBA. They think CORBA is too complicated.
But it is nature for a middleware that support different platform and
different language to be complicated. They want to make it simple.
In Java case, it only supports a single language. In Net case, it
only supports a single platform. But this is not a solution. A
distributed environment is heterogonous. Most mission critical
applications have to access to operating system and they cannot afford
garbage collection. The problem is, in my opinion, the lack of
collaboration between C++ and CORBA, and C++ is too slow to adapt the
change of technology.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kcline17@hotmail.com (Kevin Cline)
Date: Sun, 25 Apr 2004 19:55:21 +0000 (UTC) Raw View
Jim Melton <jim.melton@lmco.com> wrote in message news:<c63j4f$bkl1@cui1.lmms.lmco.com>...
> The CORBA C++ binding suffers from much of the same baggage as the C++
> language: backward compatibility.
> At the time the binding was specified,
> there was no STL, consequently no std::string (one of the biggest disasters
> of the binding). To change the binding now would break *all* existing
> programs, so it will not be done lightly.
Binding is done by the IDL compiler with support from the marshalling
code. Why not define a modern C++ binding that could be selected when
the IDL is compiled?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: davideng2004@yahoo.com (David Eng)
Date: Sun, 25 Apr 2004 19:55:22 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message news:<ur7uh6v88.fsf@boost-consulting.com>...
> davideng2004@yahoo.com (David Eng) writes:
>
> > We are moving to grid computing, yet C++
> > committee doesn't think it is important to standardize a thread
> > library.
>
> Please. Did you submit a proposal for a standard threads library?
> Did anyone? [hint: the answer is no]
>
> The "C++ committee thinks" (as though we are all of one mind, but I'll
> play along) that a threading library is important. I don't think we
> have any threading experts with the time to bring forward a proposal
> on it. If you think you're qualified, please do it yourself.
No! I don't think I am qualified, but that doesn't mean I cannot have
a opinion about thread. As a software engineer who make living by
writing code, I feel strongly C++ should supports thread, especially,
in a distributed environment. A thread library is different from a
language which supports thread. In a thread library, lock and unlock
must be called explicitly while they can be called implicitly in a
language that supports thread. The system will be deadlock if
something happens before the unlock is called explicitly in a thread
library. It will never happen if the language support thread because
the unlock will be called implicitly. Besides, you have to deal with
compiler, processor, and memory system if the language doesn't support
thread to write multi-thread applications. Furthermore, without a
standard thread, you have to use these proprietary thread libraries
which are hard to maintain and scale cross different platforms and
development environments. For all these reasons, C++ standard
committee shall consider next standard shall support thread.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Maciej Sobczak <no.spam@no.spam.com>
Date: Sun, 25 Apr 2004 19:55:21 +0000 (UTC) Raw View
Hi,
Jim Melton wrote:
> The CORBA C++ binding suffers from much of the same baggage as the C++
> language: backward compatibility. At the time the binding was specified,
> there was no STL, consequently no std::string (one of the biggest disasters
> of the binding). To change the binding now would break *all* existing
> programs, so it will not be done lightly.
I do not see any reason why there should be only *one* binding.
CORBA is used not only to maintain legacy systems, but also to write new
ones, where it does not really matter if the binding was defined 10
years ago or just a while ago. The "new" and "old" bindings could of
course interoperate over the wire, just like components in different
languages do. After all, the whole idea of binding is to decouple
components from the implementation details of each other.
Having the strings bound to std::string and arrays to STL sequences
would be beneficial to those who want to use CORBA in new systems. I do
not understand what is the merit of repeating this compatibility
argument over and over well 6 years after the C++ standard was set up.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Steven T. Hatton" <hattons@globalsymmetry.com>
Date: Sun, 25 Apr 2004 19:55:22 +0000 (UTC) Raw View
Thomas Richter wrote:
> Whether this should be part of C++ or not is another question, but it
> should be definitely mandatory part of the CORBA specifications to
> have. A specific implementation could still make use of a potential
> "standard" mutex/threading class as soon as we had one.
>
>> I still cannot understand why C++ doesn't have a
>> standard thread library. We are moving to grid computing, yet C++
>> committee doesn't think it is important to standardize a thread
>> library.
>
> This is true to some degree, but is another argument.
>
> So long,
> Thomas
Has this been mentioned in this context? I know virtually nothing about it
other than Stroustrup mentions it in one of his web pages, and the
introductions I've read sound hopeful.
/*----------------------Excerpt------------------*/
Overview of ACE
The ADAPTIVE Communication Environment (ACE) is a freely available,
open-source object-oriented (OO) framework that implements many core
patterns for concurrent communication software. ACE provides a rich set of
reusable C++ wrapper facades and framework components that perform common
communication software tasks across a range of OS platforms. The
communication software tasks provided by ACE include event demultiplexing
and event handler dispatching, signal handling, service initialization,
interprocess communication, shared memory management, message routing,
dynamic (re)configuration of distributed services, concurrent execution and
synchronization.
ACE is targeted for developers of high-performance and real-time
communication services and applications. It simplifies the development of
OO network applications and services that utilize interprocess
communication, event demultiplexing, explicit dynamic linking, and
concurrency. In addition, ACE automates system configuration and
reconfiguration by dynamically linking services into applications at
run-time and executing these services in one or more processes or threads.
ACE continues to improve and its future is bright. ACE is supported
commercially via the Riverace corporation using an open-source business
model. In addition, many members of the ACE development team are currently
working on building The ACE ORB (TAO).
/*------------------END-Excerpt------------------*/
http://www.cs.wustl.edu/~schmidt/ACE-overview.html
http://www.awprofessional.com/title/0201604647
http://www.awprofessional.com/title/0201795256
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: davideng2004@yahoo.com (David Eng)
Date: Sun, 25 Apr 2004 19:55:22 +0000 (UTC) Raw View
Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message news:<c6803n$pqs$1@mamenchi.zrz.TU-Berlin.DE>...
> Hi,
>
> > > I also feel that CORBA does its job possibly only half the way it could.
> > > For example, it nicely runs new threads for me serving my objects, but
> > > at the same time it doesn't provide necessary services for keeping
> > > object states consistent amongst the threads - there are no "mutex"
> > > specifications in CORBA.
>
> > I blame this for C++. The thread mode should be built into C++
> > instead of CORBA.
>
> But then, CORBA *requires* the corresponding ORB/POA implementation to
> provide threads one way or another, why doesn't it require from the
> implementing library to provide some mutex mechanism as well? Or
> rather, to make the internal locking mechanism any suitable
> implementation must have anyhow available to the outside as a service?
> Whether this should be part of C++ or not is another question, but it
> should be definitely mandatory part of the CORBA specifications to
> have. A specific implementation could still make use of a potential
> "standard" mutex/threading class as soon as we had one.
The problem is if threads are specified by CORBA, the behavior of
implementation would be disaster. There is big different between a
thread library and a language that supports thread. In a thread
library, the lock and unlock must be called explicitly while they can
be called implicitly in a language with thread mode. In a distributed
environment, you cannot guarantee the unlock will be called
explicitly. What happen if an exception is thrown? Then the system
will locked for ever. If a language supports thread, the unlock will
be called implicitly in this situation. Since CORBA support multiple
languages and not every languages support thread. So, it is difficult
for CORBA to specify a thread mode. That's why I wonder why C++
standard doesn't have a thread standard. If a language doesn't
support thread, it will put huge burden on developers in multi-thread
applications since the compiler, processor, and memory system all can
alter the behavior of a multi-threaded applications.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Thomas Richter <thor@cleopatra.math.tu-berlin.de>
Date: Sun, 25 Apr 2004 19:55:22 +0000 (UTC) Raw View
Hi Jim,
> Writing distributed programs is hard.
Gee, I know. I'm writing one.
> If you have any doubt, just Google
> this group for discussions on multi-threading. Distributed programming is
> multi-threading with unknown latency and unreliable communication. It takes
> more to write a distributed program than to just slap some middleware
> between two programs you wrote. The CORBA spec represents 10 years of
> experience with what is required to do distributed programming. The stuff
> you don't think you need... you'll need it.
The point is not that "I think I don't need it, so drop it". The thing is
that the stuff I need is pretty elaborate already in fields where there's
absolutely no need for being so complex. Why's there no "layered" design
of the iterface so "I don't need to care about what I don't need to use".
> The CORBA C++ binding suffers from much of the same baggage as the C++
> language: backward compatibility. At the time the binding was specified,
> there was no STL, consequently no std::string (one of the biggest disasters
> of the binding). To change the binding now would break *all* existing
> programs, so it will not be done lightly.
Of course. First, that doesn't make things better, of course. It only
explains the reasons. But what about offering an optional new binding
as an extension?
> At the risk of straying even farther off-topic for this group, I'll point
> out that Michi Henning has gone on to write a middleware designed to work
> much more intuitively with C++, and has taken quite a bit of heat from,
> among others, Steve Vinoski.
I've been following this discussion, actually. However, CORBA is pretty
much standard, it works, so I'm currently very reluctant to choose
something different (incompatible).
> Again, this is off-topic for this group, and you might want to take these
> comments to the CORBA group, but "mutex" has no tractable meaning in
> distributed programming. CORBA specifies the interface by which clients may
> access distributed services, and it defines language bindings by which
> programmers may implement (or access) those services.
But whenever I implement a distributed program, it is very common that
need to consider the situation that several clients approach one server
at the same time, so I need to care about consistency very much so. I
would even go further and say that this is a pretty much central problem
in distributed software.
Ok, what about the following: I believe that the CORBA folks know quite
a lot about these problems, so what about setting up a list of features
that are generally considered "necessary" to implement a distributed
program. If the result will not be part of CORBA, it could become
part of C++ since synchronization problems are not only CORBA specific
but more general. I would really suggest that one knowledgable member
of the CORBA group approaches the C++ committee by ideas of how a
standard "distributed services" library should look like. If it also
contains threading and mutexes, it will be quite useful for everyone
else in C++.
>> > The answer is clear, the C++ standard committee and OMG
>> > must work together to create a better mapping and association between
>> > C++ and CORBA.
>>
>> Bingo.
> I don't get the question.
No question. Just my answer. I agree.
> From a CORBA programmer's perspective, a better
> C++ binding would be desirable. But from a C++ programmer's perspective, why
> should I care?
Well, even *if* you don't write CORBA, a library providing necessary services
for CORBA (and even though I'm far from an expert, I believe threads and
mutexes are essential for that) and for CORBA applications will help you a lot
in other situations. Plus, these are the people that should have the
experience in the field.
> Why do you assume that CORBA will triumph over SOAP or EJB or
> the next greatest fad in distributed programming?
I, personally? I don't know. I'm using it "because it works". If I also
get a SOAP or EJB implementation that is common enough to be found available
for Java, C++, C and various operating systems like Linux or Windows, I
could also use that.
So long,
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: hattons@globalsymmetry.com ("Steven T. Hatton")
Date: Mon, 26 Apr 2004 01:38:30 +0000 (UTC) Raw View
Jorge Rivera wrote:
>>
>> I've been putting a lot of time into C++ lately, and I know there are
>> significant strength in the language that Java lacks. But they may not
>> be sufficient to keep anything but a niche in the emerging environment.
>> One view I've seen expressed on usenet is that Sun, Microsoft, IBM,
>> Borland, etc., are a bunch of idiots for shifting their focus to Java (or
>> C#).
>> There's not much to say to in response to such assertions. They seem to
>> speak for themselves.
>>
>
> I agree that both Java and C# provide more pacakges. However, to me,
> part of the beaty of C++ is that it is a programming language, not a set
> of technologies.
I can't say much for C#. I've never even written hello world in it. As for
Java. Java *_is_* a programming language. It has many very nice features.
One of the best things about Java is the significant structure it
manifests. Because of the clearly defined structure of packages
hierarchies, and the suite of intuitive tools to go with it, it really does
enhance a more abstract style of programming.
I really don't like to dwell on comparrisons, but some of them are worth
presenting as a means of suggesting improvements to the way C++ is
designed, supported, and used. One example that comes to mind from just
today's experiences is the difference between a typical make and Makefile
approach to building projects, and the javac and jakarta ant approach.
I've been using the gnu autotools for the better part of a decade, and I
still find most of my actions are based on guess work, and simply knowing
what worked in the past. I sat down with ant for a day, and understood the
basics.
C++ coders seem to accept these kinds of difficulties as being part of
working with the language. But the frequently presented rationalization
that the reason C++ is hard to used and learn is because it's powerful is
only partly valid. Certainly, there are capabilities in C++ that cause the
programmer to have a deeper understanding of what it actually taking place
at the level of memory mapping. And there are efficiency enhancing
features that require more care and understanding in C++ than in Java.
OTOH, the fact that Java provides a far more uniform infrastructure across
platforms and projects makes it far easier to create powerful tools for
supporting the programmer in these environments. I'm not just talking
about the JRE. I'm talking about a level of IDE support powerful enough
that I am virtually assured that my code will compile and run without
producing errors in the sense defined by the language specification.
Many of these features have their origins in C++, but for one reason or
another they have not gained the same level of effectiveness in C++ as they
have in Java.
> I don't think the C++ language should grow to the point of Java and C#.
> If you need what Java has, go right ahead and use it. If you're
> needs are well-served by C++, stick to it.
>
> It is simple enough.
One of the biggest problems I see is that people entering the industry are
presented with the alternatives of learning Java, C#, C++, or some less
popular language. C++ tends to be less well supported by the kinds of
tools that make it easy to learn the language, and to locate resources such
as classes in a library.
The C++ programmers who have a few more years of experience simply accept
that it was difficult to learn, and that's just the cost of using it. Many
of them don't seem interested in reducing the barriers to entry for the
people coming behind them. One thing these oldtimers fail to appreciate is
that there is far more to learn in order to produce software that matches
today's expectations, than there was 10 years ago.
I see that resistance to change as rather shortsighted. Leaving the
callousness of the attitude to the side, it is reasonable such an
indifference to the difficulties faced by new entrants in to the field will
reduce the number of new programmers who choose to focus on C++. That
could prove to have a significant cumulative impact. There will be fewer
people creating new libraries and technologies. There will be less
interest on the part of companies to invest in C++ related technologies,
while at the same time the financial and intellectual resources will be
diverted into the competing languages. That will result in a steady
improvement in those technologies while C++ loses ground.
There are people who will tell you they heard the same thing 10 years ago
about C++. 'It didn't happen then, and it won't happen now.' That may
well be true. But it certainly isn't the the credit of those peoples who
refuse to consider improvements and enhancements. The success of C++ is
not due to their resistance. It is despite it.
I certainly don't want to break the language, or make it just like Java, or
C#. I'm glad there are people with conservative leanings who provide a
counter force to that introduce by new suggestions. But I do believe there
is a lot of room for improvement.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: hattons@globalsymmetry.com ("Steven T. Hatton")
Date: Mon, 26 Apr 2004 01:41:22 +0000 (UTC) Raw View
Thorsten Ottosen wrote:
> "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
> | C++ _*needs*_ some kind of module support.
>
> what do you mean? It already has namespaces which IMO are superior
> to packages.
I don't see C++ namespaces as being similar to Java packages other than a
vaguely similar notion of containment and hierarchy. I'm not sure Java
packages are an ideal solution to what I find problemmattic with C++. I
know a good deal of my hands-on time spent while learning C++ has involved
issues related to #includes and linking libraries. I find the CPP approach
to 'modularity' frustrating to put it mildly.
> | It probably also should have
> | checked exceptions.
>
> checked exceptions are a pain to use; I never use them. See eg.
I was trying to explain to someone why I rarely have to trace through code
with a debugger in Java because of the edit-time code verification JBuilder
provides. At first I didn't realize exactly what was keeping me safe. But
after thinking about it, I realized it was the use of checked exceptions.
With JBuilder, I am alerted to the existence of a /throws/ modifier I have
failed to handle. I can then highlight the selected statement, hit
Ctl+shift+C and the statement is automatically wrapped in a properly
constructed try/catch block handling each exception type explicitly.
That goes back to my belief that IDE support should be a consideration when
designing new language features. I would be loath to write all that code
by hand. Especially if I had to dig through reference documentation to
determine exactly what might be thrown by each function call.
> http://www.mindview.net/Etc/Discussions/CheckedExceptions
This is less than convincing to me. He basically says he taught people to do
it in the word possible way, and by golly, that's what they did!
"My theory is that when someone is trying to do something and you are
constantly prodding them with annoyances, they will use the quickest device
available to make those annoyances go away so they can get their thing
done, perhaps assuming they'll go back and take out the device later. I
discovered I had done this in the first edition of Thinking in Java:
...
} catch (SomeKindOfException e) {}
"And then more or less forgot it until the rewrite. How many people thought
this was a good example and followed it? I began seeing the same kind of
code, and realized people were stubbing out exceptions and then they were
disappearing. The overhead of checked exceptions was having the opposite
effect of what was intended, something that can happen when you experiment
(and I now believe that checked exceptions were an experiment based on what
someone thought was a good idea, and which I believed was a good idea until
recently)."
This is a complete working example of how I handle situations of this nature
in Java. It is far more verbose than it needs to be in oder to effectively
use Java's exception mechanism, but it demonstrate the general case:
package checkedexceptions;
/**
* Extended <code>Exception</code> for demonstration.
*/
public class MyException extends Exception {
public MyException() {}
public MyException(String message) {
super(message);
}
public MyException(String message, Throwable cause) {
super(message, cause);
}
public MyException(Throwable cause) {
super(cause);
}
}
package checkedexceptions;
import java.io.PrintStream;
/**
* A program to demonstreate exception handling in Java
*
*/
public class ExceptionChecker {
/**
* Added to make the example as general as possible.
*/
private PrintStream err;
/**
* Default constructor.
*/
public ExceptionChecker() {
this(System.err);
}
/**
* Constructor allowing the error stream to be specified.
* @param err Specified err <code>PrintStream</code>.
*/
public ExceptionChecker(PrintStream err) {
this.err = err;
}
/**
* Demonstrates throwing an <code>Exception</code> subclass.
* @throws MyException Deterministaclly throws
*/
void generateException() throws MyException {
throw new MyException("This was on purpose.");
}
/**
* Catches <code>MyException</code> and prints the stack
* trace to <code>err</code>.
*/
void tryIt(){
try {
generateException();
}
catch (MyException ex) {
ex.printStackTrace(this.err);
}
}
/**
* Catches and implicitly rethrows <code>MyException</code>
* @throws MyException
*/
void doubleTry() throws MyException {
this.tryIt();
}
/**
* Throws any <code>Exception</code> subclass as <code>Exception</code>
* @throws Exception
*/
void lazyTry() throws Exception {
this.doubleTry();
}
public static void main(String[] args) {
ExceptionChecker ec = new ExceptionChecker();
ec.tryIt();
try {
ec.doubleTry();
ec.lazyTry();
}
catch (MyException ex) {
ex.printStackTrace();
}
catch (Exception ex) {
ex.printStackTrace();
}
}
}
checkedexceptions.MyException: This was on purpose.
at
checkedexceptions.ExceptionChecker.generateException(ExceptionChecker.java:17)
at checkedexceptions.ExceptionChecker.tryIt(ExceptionChecker.java:22)
at checkedexceptions.ExceptionChecker.main(ExceptionChecker.java:35)
checkedexceptions.MyException: This was on purpose.
at
checkedexceptions.ExceptionChecker.generateException(ExceptionChecker.java:17)
at checkedexceptions.ExceptionChecker.tryIt(ExceptionChecker.java:22)
at checkedexceptions.ExceptionChecker.doubleTry(ExceptionChecker.java:30)
at checkedexceptions.ExceptionChecker.main(ExceptionChecker.java:38)
>http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
> and note that C# did not include them.
I don't see the two references you provided as a support for the status quo
in C++. The first article was simply not persuasive. The second merely
demonstrates that the notion of using checked exceptions needs refinement.
In both cases the argument that the exception /had/ to be "quietly
swallowed" is probably not correct.
> | Too often C++ programmers become defensive and dismissive of these
> strengths
> | of Java. If someone presents an I idea which even hints that it may
> | have been influence by java, it is automatically rejected.
>
> Some might do that. However AFAICT, the general opinion of the C++
> comittee is that C++ should be easier to use; some changes to the core
> language can help this and a larger std library can help this.
That kind of reminds me of an anecdote from the Army. When people suggested
certain things others would respoind "the General isn't gonna like that."
How do they know? Did they ask the General?
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nesotto@cs.auc.dk ("Thorsten Ottosen")
Date: Mon, 26 Apr 2004 01:42:26 +0000 (UTC) Raw View
"llewelly" <llewelly.at@xmission.dot.com> wrote in message
news:86fzatq6lv.fsf@Zorthluthik.local.bar...
| nesotto@cs.auc.dk ("Thorsten Ottosen") writes:
| [snip]
| > what do you mean? It already has namespaces which IMO are superior
| > to packages.
| [snip]
|
| What kind of 'packages' are you thinking of?
I was thinking of Java packages when Steven mentioned module support. They
exist primarily to group code together, just like namespaces.
| Why do you think
| namespaces are superior?
because you can
1. have your package spread freely over files and directories; you are not
forced to use one directory
2. you can use a short qualified notation
3. you can put together a new packages just by picking what to include from
an old
As an example of 2, consider
// java
package foo.bar.x.y.z;
public class X { .... }
// somewhere else
foo.bar.x.y.z.X x = new foo.bar.x.y.z.X();
[remark: so you are forced to make an import statement which won't work when
there is two X's flying around]
// C++
#include <foo/bar/x/y/z/X.hpp>
namespace foobar = foo::bar::x::y::z;
foobar::X x;
br
Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nesotto@cs.auc.dk ("Thorsten Ottosen")
Date: Mon, 26 Apr 2004 18:29:34 +0000 (UTC) Raw View
===================================== MODERATOR'S COMMENT:
Warning -- topic drift.
===================================== END OF MODERATOR'S COMMENT
""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:YL2dnewENt-_Whfd4p2dnA@speakeasy.net...
| Thorsten Ottosen wrote:
|
| > "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
|
| > | C++ _*needs*_ some kind of module support.
| >
| > what do you mean? It already has namespaces which IMO are superior
| > to packages.
|
| I don't see C++ namespaces as being similar to Java packages other than a
| vaguely similar notion of containment and hierarchy. I'm not sure Java
| packages are an ideal solution to what I find problemmattic with C++. I
| know a good deal of my hands-on time spent while learning C++ has involved
| issues related to #includes and linking libraries.
was that because you had to learn it by yourself from scratch?
FWIW, it took me some time to set up a make-system for a large a java
project too.
Have you ever used bjam from boost?
| > | It probably also should have
| > | checked exceptions.
| >
| > checked exceptions are a pain to use; I never use them. See eg.
|
| I was trying to explain to someone why I rarely have to trace through code
| with a debugger in Java because of the edit-time code verification
JBuilder
| provides. At first I didn't realize exactly what was keeping me safe.
safe from what?
| But
| after thinking about it, I realized it was the use of checked exceptions.
| With JBuilder, I am alerted to the existence of a /throws/ modifier I have
| failed to handle.
how do you define "handle". e.printStackTrace() ?
| That goes back to my belief that IDE support should be a consideration
when
| designing new language features. I would be loath to write all that code
| by hand.
another reason why it might be wrong what you're doing.
| > http://www.mindview.net/Etc/Discussions/CheckedExceptions
|
| This is less than convincing to me. He basically says he taught people to
do
| it in the word possible way, and by golly, that's what they did!
yes indeed.
[snip example]
|
>http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsW
ereAMistake.html
|
| > and note that C# did not include them.
|
| I don't see the two references you provided as a support for the status
quo
| in C++.
wrt checked exceptions, then they probably do; together with C#'s decision
not to use them. They
remove flexibility of a program immensely (just consider the rules for
redefing a virtual function which throws a couple of
exceptions).
What I woul like to see in C++ is to change the current exception specs not
to do runtime-checks, but merely
to be a documentation feature that won't have anything to do with
overloading or redefinition.
| The first article was simply not persuasive. The second merely
| demonstrates that the notion of using checked exceptions needs refinement.
| In both cases the argument that the exception /had/ to be "quietly
| swallowed" is probably not correct.
Bruce Eckel don't advocate to swallow exceptions. He had a wrong example in
his first book.
On his page you can find a class that allows checked exceptions to be
rethrown as an unchecked.
br
Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Frank Buss <fb@frank-buss.de>
Date: Mon, 26 Apr 2004 22:29:49 +0000 (UTC) Raw View
davideng2004@yahoo.com (David Eng) wrote:
> A thread library is different from a
> language which supports thread. In a thread library, lock and unlock
> must be called explicitly while they can be called implicitly in a
> language that supports thread. The system will be deadlock if
> something happens before the unlock is called explicitly in a thread
> library. It will never happen if the language support thread because
> the unlock will be called implicitly.
Java supports threads, but you can have deadlocks even if the language
supports threads, but perhaps do you have ideas how the language can
avoid it? With functional languages like Haskell and Parallel Haskell it
would be easier, because there are no side-effects so the compiler can
parallelize the program without the need to program it explicit, but
deadlocks are still possible, if you want explicit synchronisation.
> Besides, you have to deal with
> compiler, processor, and memory system if the language doesn't support
> thread to write multi-thread applications.
A standard library could hide it, like the STL library hides the
implementation details. I just can write vector<int> and don't need to
know anything about the memory system. The Boost library has cross
platform thread support:
http://www.boost.org/libs/thread/doc/index.html
--
Frank Bu , fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Mon, 26 Apr 2004 22:29:49 +0000 (UTC) Raw View
davideng2004@yahoo.com (David Eng) wrote in message
news:<6b74193f.0404231240.192743d1@posting.google.com>...
> David Abrahams <dave@boost-consulting.com> wrote in message
> news:<ur7uh6v88.fsf@boost-consulting.com>...
> > davideng2004@yahoo.com (David Eng) writes:
> > > We are moving to grid computing, yet C++ committee doesn't think
> > > it is important to standardize a thread library.
> > Please. Did you submit a proposal for a standard threads library?
> > Did anyone? [hint: the answer is no]
> > The "C++ committee thinks" (as though we are all of one mind, but
> > I'll play along) that a threading library is important. I don't
> > think we have any threading experts with the time to bring forward a
> > proposal on it. If you think you're qualified, please do it
> > yourself.
> No! I don't think I am qualified, but that doesn't mean I cannot have
> a opinion about thread. As a software engineer who make living by
> writing code, I feel strongly C++ should supports thread, especially,
> in a distributed environment. A thread library is different from a
> language which supports thread. In a thread library, lock and unlock
> must be called explicitly while they can be called implicitly in a
> language that supports thread.
In the Boost threading library, I believe that lock and unlock are
private functions, which cannot be called explicitly. In no C++
threading library that I am familiar with is it necessary to call unlock
explicitly. On the other hand, there are significant cases where the
lock does not obey normal scoping rules; the locking mechanisms built
into languages like Java don't work in such cases, and require
significant complications to work around their limits.
> The system will be deadlock if something happens before the unlock is
> called explicitly in a thread library.
A deadlock can occur whether the locks are part of the language, or in a
separate library.
> It will never happen if the language support thread because the unlock
> will be called implicitly.
Only when you leave the scope in which the lock is held. Exactly as in
C++.
> Besides, you have to deal with compiler, processor, and memory system
> if the language doesn't support thread to write multi-thread
> applications.
Memory synchronization issues is one reason why threading must be
treated at the language level. Things like initialization of local
statics is another. IMHO, the interface to the locking functions should
remain a library function.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orient e objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Mon, 26 Apr 2004 22:29:48 +0000 (UTC) Raw View
"Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
news:<Fsmdnfd76ID_gxrd4p2dnA@speakeasy.net>...
> David Eng wrote:
> > I blame this for C++. The thread mode should be built into C++
> > instead of CORBA. I still cannot understand why C++ doesn't have a
> > standard thread library. We are moving to grid computing, yet C++
> > committee doesn't think it is important to standardize a thread
> > library.
> Is the problem that the committee doesn't think it's important, or is
> it that the committee doesn't have the resources? What about
> http://www.boost.org/libs/thread/doc/index.html? That seems to have
> the unofficial blessing of the committee. I agree that C++ /seems/ a
> bit behind the times when it comes to threading, and many other
> issues. What about X509, and all the other crypto stuff. Take a look
> at the standard Java SDK, and compare that to what you can get with a
> 'standard' C++ setup. I haven't looked at C#'s offerings, but I
> gather it comes with a similar arsenal of libraries.
If not following every silly fad that comes along means being behind the
times, so be it. There is no particular reason to integrate everything
into the language standard; there are even several very good reasons not
to, if you want to remain a general purpose language, instead of
targetting just a few niches.
> > The [other] area bothers me is database access layer. All these
> > database vendors promote JDBC because there is no a standard C++
> > access library. If these vendors stop to support their proprietary
> > C++ API, who will use C++ in a distributed environment? I never
> > head C++ committee even has an initiative to standardize a database
> > access layer library.
> There are many open source libraries available, and for that matter,
> you could probably make a C++ to JDBC bridge. I suspect it's already
> been done. Nonetheless, I agree that standards are a good thing. I
> find myself spending a lot of time hunting around for solutions to
> things I get as part of Java either with the JSDK or as a freely
> available extension. And let us not forget XML.
For the equivalent of JDBC, there's always the OTL. I'm not sure that
it is the right solution: I have my doubts about ostreaming selection
parameters, and I haven't used it enough concretely to confirm or deny
them. But it looks like a good point to start discussions, and it
certainly does get the job done.
For the rest, I repeat: not everything belongs in a language standard.
Generally speaking, if you can implement it in standard C++, it only
belongs in a language standard if it is needed pretty universally:
std::vector, std::string or std::sort, for example. Otherwise, the
basic argument for is based on the fact that you cannot implement it, or
you cannot implement it efficiently, in standard C++. Threading
certainly qualifies, a data base bridge might. std::latest_in_format
doesn't. (Why XML, for example, and not BER encoded ASN.1? BER encoded
ASN.1 is probably more widely used, is certainly stabler, and has been
around a lot longer.)
> > No matter how great C++ is, without a standard thread and data
> > access libraries, C++ will have a hard time to survive in a
> > distributed computing. Just to imagine how C++ can survive in a
> > system computing without an I/O library! If the committee thinks
> > proprietary libraries can do the job, I am sure that C++ will not
> > be a mainstream programming language; it will downgrade to a third
> > class language doing some limited applications.
> I believe C++ has a lot of problems when it comes to competing with
> Java and C#. People who have never coded in Java (I can't comment on
> C# directly) really have no idea of the strengths Java has as far as
> ease of use.
Java's fine for some things, especially if you are working in one of the
niches where it is specialized. It doesn't cut it if you need
reliability or safety, though, and it doesn't lend itself to large scale
programming, nor to system level programming. (You can't implement a
JVM in Java, for example. And I've done some large scale work in Java
to know of its weaknesses there.)
> C++ _*needs*_ some kind of module support.
I think that there is a general consensus that textual inclusion is NOT
the ideal way of handling modules. Regretfully, there doesn't seem to
be much consensus as to what is the right way.
> It probably also should have checked exceptions.
I agree, but I suspect that I am in a very small minority.
It's worth noting, too, that most Java developers systematically derive
from RunTimeException to avoid the checking. In practice, Java doesn't
really have checked exceptions -- it just pretends it does. (In
practice, Java seems to have found an interesting compromize: all the
pains of checked exceptions, without any of the advantages.)
> I have the sense many C++ programmers don't really understand the
> concepts of listeners and events as they are used commonly in Java.
What makes you think this? I seems like a commonly used idiom in C++.
And a lot safer in C++ than in Java, at least in the typical uses I've
seen. Generally speaking, to use it well, you need multiple
inheritance. Or at least some way of enforcing a contract for an
interface. On the other hand, of course, it is a lot easier to use if
you have garbage collection, but since it typically doesn't involve
cycles, and uses objects that make no sense other than on the heap, you
can get by reasonably well with invasive reference counting. You also
need some sort of type safe container to hold your listeners, and that
is (or was until very recently) seriously lacking in Java.
> All one really needs to do is to pick up _The Java Programming
> Language_, by Arnold, Gosling and Holmes, and read the first 10 or so
> chapters to see how much Java offers as core features.
Actually, if you don't get beyond the first 10 or so chapters, you'll
find more of what is missing. Practically speaking, in fact, unless you
get to libraries or infrastructure, you'll really only encounter things
that are missing. Java, the language, has a very few advantages over
C++: it's easier to parse, if you need to write a parser, it has garbage
collection, and it has real arrays, that act like first class objects.
On the other hand, you don't have any scope dependant user defined
types, and so no destructors or other clean-up mechanism, you don't have
any possibility of writing type safe containers, listern mechanisms,
etc., the language pretty much forbids writing strict interfaces (no
programming by contract), it has strange rules for the resolution of
virtual functions, which means that you often end up in a virtual
function on an object that hasn't been constructed. You complained
about the fact that C++ uses textual inclusion to separate interface
from implementation; Java doesn't even allow the separation. The
absense of any possibility to use programming by contract pretty much
excludes the use of Java for critical systems, and the lack of
separation between the class definition and its implementation pretty
much means you can't use it on large projects.
> Too often C++ programmers become defensive and dismissive of these
> strengths of Java. If someone presents an I idea which even hints
> that it may have been influence by java, it is automatically rejected.
Not at all. I've done some fairly large projects in Java, and at one
time, knew it at least as well as I know C++. The more I used it,
however, the more I realized that it simply wasn't appropriate for the
type of work I do (large scale servers), nor for the type of work I'd
done a lot of in the past (real time industrial systems and system level
programming). It would be my first choice for a web page server (based
on JSP), and despite all of the problems due to the lack of type safe
containers and multiple inheritance, I really liked Swing. But in both
cases, it isn't the language which is determinating, it is the
infrastructure or the library.
> I've been putting a lot of time into C++ lately, and I know there are
> significant strength in the language that Java lacks. But they may
> not be sufficient to keep anything but a niche in the emerging
> environment.
In which environment. There are certain environments in which C++ has
pratically disappeared (if it was ever present). They are very much in
view, but taken globally, I don't know if they represent that big of a
percentage of actual software.
> One view I've seen expressed on usenet is that Sun, Microsoft, IBM,
> Borland, etc., are a bunch of idiots for shifting their focus to Java
> (or C#). There's not much to say to in response to such assertions.
> They seem to speak for themselves.
Hmmm. Microsoft seems to have moved its focus from Java, and at least
for the moment, C# or not, seems to take the attitude that C++ will be
around for a long time as well, and has a place in their plans. Borland
seems to prefer Delphi. But that is neither here nor there. There is
definitly a market for the latest fad; it would be silly for any of the
above named companies to ignore it. Just as it would be silly for them
to put all of their eggs in the Java basket. IMHO, Microsoft seems to
have understood this, and is steering a middle ground. Sun seems to
have shot itself in the foot, not so much because it supported and
pushed Java, but because it forgot its bread and butter products (Unix
based workstations) in doing so. (Note that Microsoft hasn't slowed
down developments on Windows or MS-Office simply because they have C#.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orient e objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Jim Melton <jim.melton@lmco.com>
Date: Thu, 22 Apr 2004 16:29:39 +0000 (UTC) Raw View
"Thomas Richter" <thor@cleopatra.math.tu-berlin.de> wrote in message
news:c607kn$q19$2@mamenchi.zrz.TU-Berlin.DE...
>
> Hi,
>
> > As I posted in CORBA group, I believe the future of C++ depends on
> > CORBA (the same is true that the future of CORBA depends on the future
> > of C++). Applications are built today are distributed applications
> > instead of stand alone applications. For C++ to success in this
> > environment, it has to have a middleware platform. C++ has a
> > disadvantage comparing to Java and C# which both have a middleware
> > platform. However, CORBA can become the middleware platform for C++.
>
> Oh well. For that to happen, the OMG should possibly do its homework
> first. I'm using CORBA with its C++ bindings here, and I'd to read the
> "standard literature" for that task, the Henning/Vinoski book, and the
> C++ CORBA bindings are *still* giving me headaches. Does it really
> have to be *that* complicated? I wouldn't have problems with two
> mappings, or a layered design with a simple, general purpose
> top-layer, and a specialized layer that provides all the fancy
> extensions I rarely need. Currently, CORBA and its C++ mapping is both
> too special and too general at once.
Writing distributed programs is hard. If you have any doubt, just Google
this group for discussions on multi-threading. Distributed programming is
multi-threading with unknown latency and unreliable communication. It takes
more to write a distributed program than to just slap some middleware
between two programs you wrote. The CORBA spec represents 10 years of
experience with what is required to do distributed programming. The stuff
you don't think you need... you'll need it.
The CORBA C++ binding suffers from much of the same baggage as the C++
language: backward compatibility. At the time the binding was specified,
there was no STL, consequently no std::string (one of the biggest disasters
of the binding). To change the binding now would break *all* existing
programs, so it will not be done lightly.
At the risk of straying even farther off-topic for this group, I'll point
out that Michi Henning has gone on to write a middleware designed to work
much more intuitively with C++, and has taken quite a bit of heat from,
among others, Steve Vinoski.
> I also feel that CORBA does its job possibly only half the way it could.
> For example, it nicely runs new threads for me serving my objects, but
> at the same time it doesn't provide necessary services for keeping
> object states consistent amongst the threads - there are no "mutex"
> specifications in CORBA.
Again, this is off-topic for this group, and you might want to take these
comments to the CORBA group, but "mutex" has no tractable meaning in
distributed programming. CORBA specifies the interface by which clients may
access distributed services, and it defines language bindings by which
programmers may implement (or access) those services.
> On the plus side, CORBA provides lots of language bindings, so I can
> really interact with Java, Python, Perl,..., but the integration into
> the C++ language really deserves a cleanup.
Absolutely.
> > The answer is clear, the C++ standard committee and OMG
> > must work together to create a better mapping and association between
> > C++ and CORBA.
>
> Bingo.
I don't get the question. From a CORBA programmer's perspective, a better
C++ binding would be desirable. But from a C++ programmer's perspective, why
should I care? Why do you assume that CORBA will triumph over SOAP or EJB or
the next greatest fad in distributed programming? C++ will be integrated
into every middleware for which a vendor can make a business case. C++ will
continue to be required for mission-critical applications where one can't
afford to have the JVM crash, or can't afford the non-determinism of garbage
collection, or requires access to operating system facilities not available
in a virtual machine, or ...
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin IS&S
(303) 971-3846
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Thu, 22 Apr 2004 16:29:39 +0000 (UTC) Raw View
davideng2004@yahoo.com (David Eng) writes:
> We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library.
Please. Did you submit a proposal for a standard threads library?
Did anyone? [hint: the answer is no]
The "C++ committee thinks" (as though we are all of one mind, but I'll
play along) that a threading library is important. I don't think we
have any threading experts with the time to bring forward a proposal
on it. If you think you're qualified, please do it yourself.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Thu, 22 Apr 2004 17:45:31 +0000 (UTC) Raw View
David Abrahams wrote:
> davideng2004@yahoo.com (David Eng) writes:
>
>
>>We are moving to grid computing, yet C++
>>committee doesn't think it is important to standardize a thread
>>library.
Actually, "grid computing", even if it happens, is independent
of threads. Threads are a local issue. Things like CORBA
need marshalling support, not threading. An introspection
mechanism good enough to do that would be helpful. The
ability to iterate through the data members of an object at
template instantiation time would be helpful.
A good metric for template/instrospection interaction is
whether you can write a template that generates efficient
marshalling code for an object. If one could write different templates
that generated marshalling for a few common protocols (OpenRPC,
Java RMI, Microsoft DCOM, SOAP), that would be a big win.
> Please. Did you submit a proposal for a standard threads library?
> Did anyone? [hint: the answer is no]
>
> The "C++ committee thinks" (as though we are all of one mind, but I'll
> play along) that a threading library is important. I don't think we
> have any threading experts with the time to bring forward a proposal
> on it. If you think you're qualified, please do it yourself.
I'd put locking in the language, but leave threading to POSIX.
I've discussed an approach to object-level safe locking before.
If someone wants to solicit me to write a formal proposal,
I'd be willing to do it.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Thomas Richter <thor@cleopatra.math.tu-berlin.de>
Date: Fri, 23 Apr 2004 14:34:09 +0000 (UTC) Raw View
Hi,
> > I also feel that CORBA does its job possibly only half the way it could.
> > For example, it nicely runs new threads for me serving my objects, but
> > at the same time it doesn't provide necessary services for keeping
> > object states consistent amongst the threads - there are no "mutex"
> > specifications in CORBA.
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA.
But then, CORBA *requires* the corresponding ORB/POA implementation to
provide threads one way or another, why doesn't it require from the
implementing library to provide some mutex mechanism as well? Or
rather, to make the internal locking mechanism any suitable
implementation must have anyhow available to the outside as a service?
Whether this should be part of C++ or not is another question, but it
should be definitely mandatory part of the CORBA specifications to
have. A specific implementation could still make use of a potential
"standard" mutex/threading class as soon as we had one.
> I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library.
This is true to some degree, but is another argument.
So long,
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Steven T. Hatton" <susudata@setidava.kushan.aa>
Date: Fri, 23 Apr 2004 14:34:10 +0000 (UTC) Raw View
David Eng wrote:
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA. I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library.
Is the problem that the committee doesn't think it's important, or is it
that the committee doesn't have the resources? What about
http://www.boost.org/libs/thread/doc/index.html? That seems to have the
unofficial blessing of the committee. I agree that C++ /seems/ a bit
behind the times when it comes to threading, and many other issues. What
about X509, and all the other crypto stuff. Take a look at the standard
Java SDK, and compare that to what you can get with a 'standard' C++ setup.
I haven't looked at C#'s offerings, but I gather it comes with a similar
arsenal of libraries.
> The [other] area bothers me is database access layer. All
> these database vendors promote JDBC because there is no a standard C++
> access library. If these vendors stop to support their proprietary
> C++ API, who will use C++ in a distributed environment? I never head
> C++ committee even has an initiative to standardize a database access
> layer library.
There are many open source libraries available, and for that matter, you
could probably make a C++ to JDBC bridge. I suspect it's already been done.
Nonetheless, I agree that standards are a good thing. I find myself
spending a lot of time hunting around for solutions to things I get as part
of Java either with the JSDK or as a freely available extension. And let
us not forget XML.
> No matter how great C++ is, without a standard thread
> and data access libraries, C++ will have a hard time to survive in a
> distributed computing. Just to imagine how C++ can survive in a
> system computing without an I/O library! If the committee thinks
> proprietary libraries can do the job, I am sure that C++ will not be a
> mainstream programming language; it will downgrade to a third class
> language doing some limited applications.
I believe C++ has a lot of problems when it comes to competing with Java and
C#. People who have never coded in Java (I can't comment on C# directly)
really have no idea of the strengths Java has as far as ease of use.
C++ _*needs*_ some kind of module support. It probably also should have
checked exceptions. I have the sense many C++ programmers don't really
understand the concepts of listeners and events as they are used commonly
in Java. All one really needs to do is to pick up _The Java Programming
Language_, by Arnold, Gosling and Holmes, and read the first 10 or so
chapters to see how much Java offers as core features.
Too often C++ programmers become defensive and dismissive of these strengths
of Java. If someone presents an I idea which even hints that it may have
been influence by java, it is automatically rejected.
I've been putting a lot of time into C++ lately, and I know there are
significant strength in the language that Java lacks. But they may not be
sufficient to keep anything but a niche in the emerging environment. One
view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
etc., are a bunch of idiots for shifting their focus to Java (or C#).
There's not much to say to in response to such assertions. They seem to
speak for themselves.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Hyman Rosen <hyrosen@mail.com>
Date: Fri, 23 Apr 2004 14:34:10 +0000 (UTC) Raw View
Jim Melton wrote:
> Writing distributed programs is hard.
And yet, Ada supports it as a built-in feature of
the language, in compilers which support the
Distributed Systems Annex E.
<http://www.adaic.org/standards/95lrm/html/RM-E.html>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: SFriesen@korelectronics.com (Stanley Friesen)
Date: Fri, 23 Apr 2004 14:34:10 +0000 (UTC) Raw View
davideng2004@yahoo.com (David Eng) wrote in message news:<6b74193f.0404200953.4e2851d0@posting.google.com>...
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA. I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library. The another area bothers me is database access layer.
I do not see grid computing being so pervasive as you seem to think.
I WILL NOT run distributed apps on my personal computer at home, not
even with a broadband connection. And at work it is unlikely that
many of the main applications I run will be grid apps any time soon.
> All
> these database vendors promote JDBC because there is no a standard C++
> access library. If these vendors stop to support their proprietary
> C++ API, who will use C++ in a distributed environment? I never head
> C++ committee even has an initiative to standardize a database access
> layer library. No matter how great C++ is, without a standard thread
> and data access libraries, C++ will have a hard time to survive in a
> distributed computing. Just to imagine how C++ can survive in a
> system computing without an I/O library! If the committee thinks
> proprietary libraries can do the job, I am sure that C++ will not be a
> mainstream programming language; it will downgrade to a third class
> language doing some limited applications.
C++ is, and will remain, a good language for performance-critical
systems, where the performance cost of grid computing is too high.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: jorgeri@rochester.rr.com (Jorge Rivera)
Date: Fri, 23 Apr 2004 22:44:10 +0000 (UTC) Raw View
>
> I've been putting a lot of time into C++ lately, and I know there are
> significant strength in the language that Java lacks. But they may not be
> sufficient to keep anything but a niche in the emerging environment. One
> view I've seen expressed on usenet is that Sun, Microsoft, IBM, Borland,
> etc., are a bunch of idiots for shifting their focus to Java (or C#).
> There's not much to say to in response to such assertions. They seem to
> speak for themselves.
>
I agree that both Java and C# provide more pacakges. However, to me,
part of the beaty of C++ is that it is a programming language, not a set
of technologies.
I don't think the C++ language should grow to the point of Java and C#.
If you need what Java has, go right ahead and use it. If you're
needs are well-served by C++, stick to it.
It is simple enough.
Jorge L.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.fr
Date: Fri, 23 Apr 2004 23:54:49 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote in message
news:<ur7uh6v88.fsf@boost-consulting.com>...
> davideng2004@yahoo.com (David Eng) writes:
> > We are moving to grid computing, yet C++ committee doesn't think it
> > is important to standardize a thread library.
> Please. Did you submit a proposal for a standard threads library?
> Did anyone? [hint: the answer is no]
I was under the impression that the Boost threading library was being
discussed. Internally, of course, and only for inclusion in the next
version of the standard.
> The "C++ committee thinks" (as though we are all of one mind, but I'll
> play along) that a threading library is important. I don't think we
> have any threading experts with the time to bring forward a proposal
> on it. If you think you're qualified, please do it yourself.
It's also important to put things in a historical perspective. The C++
standard was published in 1998. That means that most of the features
being including were stabilized at least a year before, and were
proposed many years before that. I think that the cut-off date for a
completely new feature would have been something like 1995, possibly
even earlier. While I don't think that anyone today doubts the
importance of threads, I'm not sure that you could have said the same
thing in 1995. (And BTW, some of the large servers I work on still
don't use threads. All things considered, threads mean extra work, and
unless they otherwise save you more work than they cost, you're better
off without them.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orient e objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place S mard, 78210 St.-Cyr-l' cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nesotto@cs.auc.dk ("Thorsten Ottosen")
Date: Sat, 24 Apr 2004 15:58:29 +0000 (UTC) Raw View
"Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
news:Fsmdnfd76ID_gxrd4p2dnA@speakeasy.net...
| Is the problem that the committee doesn't think it's important, or is it
| that the committee doesn't have the resources?
lack of resources can be a problem. For example, if no threading experts are
willing to sacrifice their
freetime on helping the comittee, the commettee probably won't consider
threads.
| I believe C++ has a lot of problems when it comes to competing with Java
and
| C#. People who have never coded in Java (I can't comment on C# directly)
| really have no idea of the strengths Java has as far as ease of use.
it all depends. I think C++ can be very easy to use if you learn it the
right way.
| C++ _*needs*_ some kind of module support.
what do you mean? It already has namespaces which IMO are superior
to packages.
| It probably also should have
| checked exceptions.
checked exceptions are a pain to use; I never use them. See eg.
http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
and note that C# did not include them.
| Too often C++ programmers become defensive and dismissive of these
strengths
| of Java. If someone presents an I idea which even hints that it may have
| been influence by java, it is automatically rejected.
Some might do that. However AFAICT, the general opinion of the C++ comittee
is that C++ should be easier to use; some changes to the core language can
help this and a larger std library can help this.
br
Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: unoriginal_username@yahoo.com (Le Chaud Lapin)
Date: Fri, 16 Apr 2004 16:07:23 +0000 (UTC) Raw View
davideng2004@yahoo.com (David Eng) wrote in message news:<6b74193f.0404130754.5c40f511@posting.google.com>...
> As I posted in CORBA group, I believe the future of C++ depends on
> CORBA (the same is true that the future of CORBA depends on the future
> of C++). [snip]
> CORBA's strength is built on programming language independence. [snip]
Yuck. Please don't take this perosonally, but I find distrbuted
polylingual polymorphic objects disgusting. After years of duking it
out with Microsoft COM abominations, I am convinced that some
boundaries are not meant to be blurred, and making an
all-encompassing, super model for "distributed objects" is gross if it
comes with box of duct tape and chicken wire.
Every language has a distinct type space, and no matter what trickery
is employed, if programs written in two different languages must
communicate with each other, at some point, the boundary between the
type spaces must be dealt with. Any attempt to smooth over the
interface without regard for the fact that the type spaces *are*
distinct results in cumbersome tools like data marshallers and weird
compilers that require perturbation of the host languages.
If multilingual interaction is required, it would be much better to
find a way to get data from node A to node B, entirely within the
framework of one prescribed language [why not C++?], then provide
specific mechanisms to translate from the prescribed language to a
target language as necessary, and if possible. After all, the
boundary will have to be crossed by someone at some point anyway, so
why make everyone suffer when it is the polyglot who is asking for it?
You might say, "Well, there is an enormous benefit of having
language-independent objects accessible from any node by any
language." I would agree if it were actually possible to have such a
thing.
No unified typespace can scale to the mode of aggregation that complex
(not complicated) systems demand without the need to think carefully
about what happens when aggregate objects need to cross from the
unified type space to a specific type space. I doubt that it is
possible to go from
Associative_Polyarchy<String_, Associative_List<unsigned int,
Polyarchy<String_> > >
on a node running C++ to the same thing on a node running C# while
keeping the data structure in one piece. The problem is that I use my
source language to construct things, and if the elements of
construction do not exist in the target language, then I must somehow
manually syntesize the construct anyway. If it is stipulated that I
must choose from a particular set of primitives, and use them in a
certain way in my source language, then guess what? I am no longer
speaking my native language. This fact can be seen by reading between
the lines on Microsoft's MSDN site. They openly profess .NET's
language independence while surreptitiously attempting to displace C++
in favor of C#, which, among other things will allow to them to
provide platforms and tools on Unix & Company undermining their market
dominance.
-Chaud Lapin-
By the way, French is language-independent. All you have to do is
learn how to get from French to English, French to German, French to
Swahili...
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: im_not_giving_it_here@i_hate_spam.com (Asfand Yar Qazi)
Date: Sat, 17 Apr 2004 22:54:16 +0000 (UTC) Raw View
David Eng wrote:
> > For many years now enterprise business application development has
> > been the core area for the use of C++.
> > Today a significant share to this segment has already been lost to
> > SUN's Java technology and with MS now abandoning C++ in favour if its
> > proprietery .NET and C# technology, how long can we except C++ to hold
> > on against these might competitors?
> > Has C++ become a dying language?
> > What is the future of C++?
>
<snip>
I consider C++ to be an object-oriented cross-platform assembler, so it
is the only way to go for writing high-performance multi-platform game
(and other real-time) code.
--
http://www.it-is-truth.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Steven T. Hatton" <hattons@globalsymmetry.com>
Date: Sun, 18 Apr 2004 06:03:37 +0000 (UTC) Raw View
Bryan Bullard wrote:
> One of the primary strengths of C++ is that it is general purpose and
> doesn't try to conform to all the latest bells and whistles (like Java
> does). In 10 or 15 years when all the technologies that are built into
> Java have become obsolete what good will Java be?
Which technologies are those? There is the core Java language as specified
in _The Java Language Specification_, by, James Gosling, Bill Joy, Guy
Steele, Gilad Bracha, and then there is a huge collection of fairly well
integrated supporting libraries. Note: that's the same Guy Steele who
coauthored the highly regarded _C: A Reference Manual, Fifth Edition_.
CORBA should not be part of the C++ language anymore than Enterprise
JavaBeans, or RMI are part of the Java Language Specification.
Nonetheless, CORBA represents the direct C++ counterpart of come of Java's
most successful technologies.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Mon, 19 Apr 2004 17:34:26 +0000 (UTC) Raw View
There's something to be said for providing C++ with
enough introspection to allow generation of marshalling code
via suitable templates. Currently, you have to define
interfaces for CORBA, OpenRPC, or DCOM in an external
language which is then processed into C source by an
interface generator.
This direction might give the template fanatics something
useful to do.
Actually, RMI is part of the "core Java" specification.
John Nagle
Animats
Steven T. Hatton wrote:
> CORBA should not be part of the C++ language anymore than Enterprise
> JavaBeans, or RMI are part of the Java Language Specification.
> Nonetheless, CORBA represents the direct C++ counterpart of come of Java's
> most successful technologies.
>
>
>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Thomas Richter <thor@cleopatra.math.tu-berlin.de>
Date: Tue, 20 Apr 2004 14:28:47 +0000 (UTC) Raw View
Hi,
> As I posted in CORBA group, I believe the future of C++ depends on
> CORBA (the same is true that the future of CORBA depends on the future
> of C++). Applications are built today are distributed applications
> instead of stand alone applications. For C++ to success in this
> environment, it has to have a middleware platform. C++ has a
> disadvantage comparing to Java and C# which both have a middleware
> platform. However, CORBA can become the middleware platform for C++.
Oh well. For that to happen, the OMG should possibly do its homework
first. I'm using CORBA with its C++ bindings here, and I'd to read the
"standard literature" for that task, the Henning/Vinoski book, and the
C++ CORBA bindings are *still* giving me headaches. Does it really
have to be *that* complicated? I wouldn't have problems with two
mappings, or a layered design with a simple, general purpose
top-layer, and a specialized layer that provides all the fancy
extensions I rarely need. Currently, CORBA and its C++ mapping is both
too special and too general at once.
I also feel that CORBA does its job possibly only half the way it could.
For example, it nicely runs new threads for me serving my objects, but
at the same time it doesn't provide necessary services for keeping
object states consistent amongst the threads - there are no "mutex"
specifications in CORBA.
On the plus side, CORBA provides lots of language bindings, so I can
really interact with Java, Python, Perl,..., but the integration into
the C++ language really deserves a cleanup.
> The answer is clear, the C++ standard committee and OMG
> must work together to create a better mapping and association between
> C++ and CORBA.
Bingo.
So long,
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: davideng2004@yahoo.com (David Eng)
Date: Wed, 21 Apr 2004 15:48:29 +0000 (UTC) Raw View
Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message news:<c607kn$q19$2@mamenchi.zrz.TU-Berlin.DE>...
> I also feel that CORBA does its job possibly only half the way it could.
> For example, it nicely runs new threads for me serving my objects, but
> at the same time it doesn't provide necessary services for keeping
> object states consistent amongst the threads - there are no "mutex"
> specifications in CORBA.
I blame this for C++. The thread mode should be built into C++
instead of CORBA. I still cannot understand why C++ doesn't have a
standard thread library. We are moving to grid computing, yet C++
committee doesn't think it is important to standardize a thread
library. The another area bothers me is database access layer. All
these database vendors promote JDBC because there is no a standard C++
access library. If these vendors stop to support their proprietary
C++ API, who will use C++ in a distributed environment? I never head
C++ committee even has an initiative to standardize a database access
layer library. No matter how great C++ is, without a standard thread
and data access libraries, C++ will have a hard time to survive in a
distributed computing. Just to imagine how C++ can survive in a
system computing without an I/O library! If the committee thinks
proprietary libraries can do the job, I am sure that C++ will not be a
mainstream programming language; it will downgrade to a third class
language doing some limited applications.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Bryan Bullard <reply@to.group.com>
Date: Thu, 15 Apr 2004 21:21:45 +0000 (UTC) Raw View
"David Eng" <davideng2004@yahoo.com> wrote in message
news:6b74193f.0404130754.5c40f511@posting.google.com...
>
> > For many years now enterprise business application development has
> > been the core area for the use of C++.
> > Today a significant share to this segment has already been lost to
> > SUN's Java technology and with MS now abandoning C++ in favour if its
> > proprietery .NET and C# technology, how long can we except C++ to hold
> > on against these might competitors?
> > Has C++ become a dying language?
> > What is the future of C++?
>
> As I posted in CORBA group, I believe the future of C++ depends on
> CORBA (the same is true that the future of CORBA depends on the future
> of C++). Applications are built today are distributed applications
> instead of stand alone applications. For C++ to success in this
> environment, it has to have a middleware platform. C++ has a
> disadvantage comparing to Java and C# which both have a middleware
> platform. However, CORBA can become the middleware platform for C++.
> CORBA's strength is built on programming language independence. There
> is need for Java or C# to talk to C++. If C++ doesn't have a future,
> why applications need to talk to C++? If no applications talk to C++,
> then why people need to use CORBA since Java has EJB middleware and C#
> has .NET? The answer is clear, the C++ standard committee and OMG
> must work together to create a better mapping and association between
> C++ and CORBA. They must understand that the future of C++ and CORBA
> is dependent on each other. If they realize this relationship, I
> believe the future of C++ and CORBA is bright. The reason is simple:
> together, C++ and CORBA can build mission critical applications which
> Java and C# cannot even think about.
One of the primary strengths of C++ is that it is general purpose and
doesn't try to conform to all the latest bells and whistles (like Java
does). In 10 or 15 years when all the technologies that are built into Java
have become obsolete what good will Java be?
..
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Edward Diener <eldiener@earthlink.net>
Date: Thu, 15 Apr 2004 21:21:45 +0000 (UTC) Raw View
David Eng wrote:
> > For many years now enterprise business application development has
> > been the core area for the use of C++.
> > Today a significant share to this segment has already been lost to
> > SUN's Java technology and with MS now abandoning C++ in favour if
> its > proprietery .NET and C# technology, how long can we except C++
> to hold > on against these might competitors?
> > Has C++ become a dying language?
> > What is the future of C++?
>
> As I posted in CORBA group, I believe the future of C++ depends on
> CORBA (the same is true that the future of CORBA depends on the future
> of C++).
Hardly.
C++ thrives very well, thank you, for a wide variety of platforms,
compilers, and standard libraries despite Sun's, Microsoft's, and Borland's
attempts to treat it as a second-rate language in order to promote their own
favored computer programming languages. It can adapt itself to CORBA, DCOM,
and most whatever other middleware comes down the road. Getting caught up in
the politics of software development hype is, thankfully, not what C++ is
all about.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: davideng2004@yahoo.com (David Eng)
Date: Wed, 14 Apr 2004 14:39:49 +0000 (UTC) Raw View
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
As I posted in CORBA group, I believe the future of C++ depends on
CORBA (the same is true that the future of CORBA depends on the future
of C++). Applications are built today are distributed applications
instead of stand alone applications. For C++ to success in this
environment, it has to have a middleware platform. C++ has a
disadvantage comparing to Java and C# which both have a middleware
platform. However, CORBA can become the middleware platform for C++.
CORBA's strength is built on programming language independence. There
is need for Java or C# to talk to C++. If C++ doesn't have a future,
why applications need to talk to C++? If no applications talk to C++,
then why people need to use CORBA since Java has EJB middleware and C#
has .NET? The answer is clear, the C++ standard committee and OMG
must work together to create a better mapping and association between
C++ and CORBA. They must understand that the future of C++ and CORBA
is dependent on each other. If they realize this relationship, I
believe the future of C++ and CORBA is bright. The reason is simple:
together, C++ and CORBA can build mission critical applications which
Java and C# cannot even think about.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 13 Feb 03 18:46:32 GMT Raw View
kanze@gabi-soft.de (James Kanze) wrote
> The question was: is there any code/compiler where the resulting program
> would be measurably slower if C++ imposed a specific order. The above
> example is completely irrelevant to this question, since the expressions
> are so simple that no reordering is possible, and since they only
> involve built-in types, with everything visible to the compiler, so the
> reordering could take place anyway if it were safe, since the compiler
> could see everything, and apply the as-if rule.
The way that your question is worded, there can only be one
answer. If you gave the compiler the freedom to rearrange the
order of operations, it could still choose not to. If we
assume that the only reason why a compiler would bother to
change the order of evaluation is speed, then clearly it would
not make it any slower.
Having received this answer, did it prove some point of yours?
I don't quite understand what you're getting at, and I don't
have enough time to dig through this thread to find out how
your question arose in the first place.
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 15 Feb 2003 12:00:37 -0500 Raw View
allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0302121303.5d75ff6b@posting.google.com>...
> kanze@gabi-soft.de (James Kanze) wrote
> > The question was: is there any code/compiler where the resulting
> > program would be measurably slower if C++ imposed a specific order.
> > The above example is completely irrelevant to this question, since
> > the expressions are so simple that no reordering is possible, and
> > since they only involve built-in types, with everything visible to
> > the compiler, so the reordering could take place anyway if it were
> > safe, since the compiler could see everything, and apply the as-if
> > rule.
> The way that your question is worded, there can only be one answer. If
> you gave the compiler the freedom to rearrange the order of
> operations, it could still choose not to. If we assume that the only
> reason why a compiler would bother to change the order of evaluation
> is speed, then clearly it would not make it any slower.
I don't understand your answer. The question asked for any combination
of code and compiler for which a restriction in the ordering would make
the program measurably slower. Obviously, if the compiler currently
doesn't reorder, a combination involving that compiler wouldn't be a
counter example.
Current compilers DO reorder, and on machines with a small register set,
like Intel, this reordering does affect performance. What I think,
however, is that most of this reordering, or at least the reordering
that counts for performance, could take place under the "as if" rule,
even with stricter rules concerning order. The stricter rules would
require the compiler to inhibit reordering when it couldn't prove that
the reordering didn't change observable behavior.
> Having received this answer, did it prove some point of yours? I
> don't quite understand what you're getting at, and I don't have enough
> time to dig through this thread to find out how your question arose in
> the first place.
What I'm getting at is that IMHO, a lot of the undefined and unspecified
behavior in C++ is unnecessary. It could be fully defined, with no
serious disadvantages.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Michel de Becdelihvre" <BCV@inlog.fr>
Date: 11 Feb 03 17:20:01 GMT Raw View
"Thomas Hansen" <thomas.hansenNOSPAMORILLSUEYOURXXX@adramatch.com> a icrit
dans le message de news: 39fv3vk4m0v28430c0h68nf6depv6fp6ip@4ax.com...
> On 07 Jan 03 13:12:05 GMT, there came a drop of sanity from
[ --- Please see the FAQ before posting. --- ]
> I once saw a test by Don Box claiming that C# was 100 times faster
> then C++, the test was something like this:
>
> C++
> class X
> {
> int y;
> };
> int main()
> {
> for(int n=0;n<10000;++n)
> {
> X x;
> }
> return 0;
> }
>
> C#
>
> class X
> {
> private int y;
> static void main()
> {
> for( int n=0;n<10000;++n)
> {
> X x = new x();
> }
> }
> }
>
> ...
>
> Needless to say the C# app ran 100 times faster since the GC didn't
> kick in before the app died...
If I remember well, there was also a delete involved in the C++ version,
and it was used to "demonstrate" the "power" of a special feature of C# : a
special fast GC for very short lived objects.
The only trouble here is that a C++ programmer would not have allocated
heap memory here, but on the stack so the exemple was more rethoric and
marketing than real world.
More seriously, depending on memory allocation patterns (if heavy memory
fragmentation can occur), a good GC language *may often* be faster than
naive C++ without "new" overloading. Writing a good custom allocator for a
few critical classes is not such a common skill in most programming shops.
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: Thomas Hansen <thomas.hansenNOSPAMORILLSUEYOURXXX@adramatch.com>
Date: 5 Feb 2003 20:44:50 -0500 Raw View
On 07 Jan 03 13:12:05 GMT, there came a drop of sanity from
thp@cs.ucr.edu containing:
>In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
>[...]
>+ My only point is that people just screeming out that
>+ Java is slower don't really know what they are talking about.
>
>Were we misled when we were told that C/C++ derives significant speed
>benefits from features like:
> - unspecified order of evaluation for most operators,
> - undefined the behavior when, between two sequence points an object
> is modified and accessed for any purpose other than to compute
> the new value,
> - not requiring bounds checking for array accesses,
> - not requiring stack-overflow checking.
> - etc.
>
>Tom Payne
>
>
> [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
> [ about comp.lang.c++.moderated. First time posters: do this! ]
>
>[ comp.std.c++ is moderated. To submit articles, try just posting with ]
>[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
>[ --- Please see the FAQ before posting. --- ]
I once saw a test by Don Box claiming that C# was 100 times faster
then C++, the test was something like this:
C++
class X
{
int y;
};
int main()
{
for(int n=0;n<10000;++n)
{
X x;
}
return 0;
}
C#
class X
{
private int y;
static void main()
{
for( int n=0;n<10000;++n)
{
X x = new x();
}
}
}
...
Needless to say the C# app ran 100 times faster since the GC didn't
kick in before the app died...
What's MORE interresting is what happen if you increased the
iterations from 10 000 to 1 000 000 000 000?!?
The C++ application would still run within a couple of seconds, while
the C# application would somewhere between 10 000 and 1 000 000 000
000 let the GC kick in and do it's job which would decrease the
performance in the C# application with a magnitude of a million (I'm
fabricating numbers here, but the basic fact still stands...)
making the C++ app run about a billion (still fabricating) times
faster then the C# app...
So much for benchmarks designed to "kill" old habits, like the habit
of using C++ instead of the currently "fully fledged cutting edge
programming language boy on the block"...
When that's said I think Java and C# are some seriously asskicking
languages, and 90% of all my current code is written in either Java or
C#, the reason is "time to market" and the ability to make a
WebService or an HTML Click button event with the click of a WYSIWYG
IDE, but those last 10% NOBODY in the world would EVER get me to
change to ANYTHING ELSE then C++, except maybe assembler code...
I use in my daily job roughly about 90% C#/CLR through ASP.NET for all
the GUI, HTML rendering and business logic, but my programming
libraries are and still will continue to be implemented in C++ with
the help of my old friend COM and ATL...
C++ rules, Java rules heck even C# rules but NOTHING rules as much as
when all three are combined (e.g. Client side Java Applets, server
side CLR (C# "bytecode") and native compiled C++ code in CPU/RAM
demanding libraries...
If Java is so much faster then C++ why ain't no OS's implemented in
Java, why haven't any dBase vendors converted their engines to Java,
heck why haven't nobody even implemented a VM in Java?!?!?!?
Actually my theory about the bubble that cracked in Y2K and made a
million or so coders unemployed all over the world is that there was
way to much pragmatic religious beliefs about the "best" internet
server, "best" dBase server, "best" OS, "best" programming language
etc...
The "best" xxx (pick your choice and std::string<char
*>::replace("xxx", concept) ) are the one that is "fast enough",
"scalabe enough" and has the LEAST time to market...
Look at www.stepstone.com they had a billion dollars os so in
developing costs.
I could probably have made the whole site in a weekend with help from
SQL server, ASP.NET, C#, Java and C++ working together in a well oiled
machinery...
Where I work we are three coders and we are daily using about 10
programming languages/concepts;
HTML
XML
XSLT
C++
C#
FoxPro
JavaScript
Java
SQL
HTTP
SOAP
...
Funny thing is that isolated NONE of them is worth Jack Shit, but put
together they work swell...
Time to get grounded, stick your finger in the dirt and taste the soil
that made you...
Sincerely
Thomas
--
"FOOT-AND-MOUTH BELIEVED TO BE FIRST VIRUS
UNABLE TO SPREAD THROUGH MICROSOFT OUTLOOK"
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 07 Feb 03 16:56:56 GMT Raw View
Thomas Hansen <thomas.hansenNOSPAMORILLSUEYOURXXX@adramatch.com> wrote
in message news:<39fv3vk4m0v28430c0h68nf6depv6fp6ip@4ax.com>...
> On 07 Jan 03 13:12:05 GMT, there came a drop of sanity from
> thp@cs.ucr.edu containing:
> >In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> >[...]
> >+ My only point is that people just screeming out that
> >+ Java is slower don't really know what they are talking about.
> >Were we misled when we were told that C/C++ derives significant speed
> >benefits from features like:
> > - unspecified order of evaluation for most operators,
> > - undefined the behavior when, between two sequence points an
object
> > is modified and accessed for any purpose other than to compute
> > the new value,
> > - not requiring bounds checking for array accesses,
> > - not requiring stack-overflow checking.
> > - etc.
> then C++, the test was something like this:
> C++
> class X
> {
> int y;
> };
> int main()
> {
> for(int n=0;n<10000;++n)
> {
> X x;
> }
> return 0;
> }
> C#
> class X
> {
> private int y;
> static void main()
> {
> for( int n=0;n<10000;++n)
> {
> X x = new x();
> }
> }
> }
> ...
> Needless to say the C# app ran 100 times faster since the GC didn't
> kick in before the app died...
I'd still expect the C++ code above to beat it hands down. No dynamic
allocation is still faster than even the best dynamic allocation. It's
hard to get below 0 when dealing with runtime.
Perhaps the C++ benchmark used dynamic allocation as well. If the loop
contents were "X* x = new X", I don't know which would win. Probably
the language with garbage collection; if you do enough iterations for
garbage collection to cut in, you run out of memory with the C++
implementation:-).
Adding a delete x in the loop will create the most favorable case for
some implementations of malloc/free (which tend to underly new/delete).
Not a very realistic case, either.
> What's MORE interresting is what happen if you increased the
> iterations from 10 000 to 1 000 000 000 000?!?
> The C++ application would still run within a couple of seconds, while
> the C# application would somewhere between 10 000 and 1 000 000 000
> 000 let the GC kick in and do it's job which would decrease the
> performance in the C# application with a magnitude of a million (I'm
> fabricating numbers here, but the basic fact still stands...)
The basic fact that you are fabricating numbers:-)?
The differences will depend largely on the implementation. More to the
point, they don't mean anything, since the memory allocation pattern is
totally unrealistic for any real application. And memory management
strategies tend to vary greatly in performance depending on memory
allocation patterns.
> making the C++ app run about a billion (still fabricating) times
> faster then the C# app...
Still fabricating, yes.
The only case I know where an actual application was implemented using
both garbage collection and with manual memory management, the garbage
collected version was slightly faster. (Since the test was run by
people very favorable to garbage collection, I presume that they chose
an application for which their garbage collector would give good
results.)
In practice, I've seen a number of cases of large blocks of code where
the difference in performance between Java and C++ was less than 10%.
With the difference not always in favor of C++, either.
> So much for benchmarks designed to "kill" old habits, like the habit
> of using C++ instead of the currently "fully fledged cutting edge
> programming language boy on the block"...
> When that's said I think Java and C# are some seriously asskicking
> languages, and 90% of all my current code is written in either Java or
> C#, the reason is "time to market" and the ability to make a
> WebService or an HTML Click button event with the click of a WYSIWYG
> IDE, but those last 10% NOBODY in the world would EVER get me to
> change to ANYTHING ELSE then C++, except maybe assembler code...
I've been in projects where we've used C++ for time to market reasons.
Let's face it, it takes considerably *less* time to develop robust C++
than it does to develop robust Java. Not that C++ really helps you a
lot, but at least it doesn't actively try and prevent you from writing
robust code, as is the case with Java.
> I use in my daily job roughly about 90% C#/CLR through ASP.NET for all
> the GUI, HTML rendering and business logic, but my programming
> libraries are and still will continue to be implemented in C++ with
> the help of my old friend COM and ATL...
> C++ rules, Java rules heck even C# rules but NOTHING rules as much as
> when all three are combined (e.g. Client side Java Applets, server
> side CLR (C# "bytecode") and native compiled C++ code in CPU/RAM
> demanding libraries...
> If Java is so much faster then C++ why ain't no OS's implemented in
> Java, why haven't any dBase vendors converted their engines to Java,
> heck why haven't nobody even implemented a VM in Java?!?!?!?
Probably because Java doesn't provide the necessary functionality. A
lot of the newer parts of Oracle ARE written in Java (at least according
to Oracle), but the basic data base engine makes extensive use of shared
memory. Something which Java doesn't allow. And of course, a lot of
the parts were originally written before Java was available, or reached
its current levels of performance. Rewriting them in Java would require
a lot more effort than just maintaining the original C or C++.
Note that in such cases, you probably don't use standard C++ either,
which doesn't have functions such as mmap or shmat. The difference is
that if my implementation offers such functions (it does), it can still
be called C++. Sun owns the Java trademark, and won't allow anything
with such additions to be called Java.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: thp@cs.ucr.edu
Date: Tue, 28 Jan 2003 02:12:53 +0000 (UTC) Raw View
John Nagle <nagle@animats.com> wrote:
+ Paul Hsieh wrote:
+
+> But the right answer, as Intel and other compiler vendors perfectly
+> understand, is to provide the option for compiler re-ordering for
+> performance.
+
+
+ Not good. Compiler options should not change the results of
+ the computation. Compiler writers do that out of desperation,
+ since they can't change the language. If it can change the
+ results, it should appear in the source text, as a pragma
+ if necessary.
+
+ It's tough to decide how far a floating point optimizer
+ is allowed to go. Do you allow the compiler to apply
+
+ a*b + a*c ==> a*(b+c)
+
+ for example?
I agree. How "if" is "as-if enough"? Floating-point representations
are already approximations. Is it good enough if close a*(b+c) is as
close an approximation as a*b+a*c would have been?
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: brangdon@cix.co.uk (Dave Harris)
Date: 28 Jan 2003 06:36:05 -0500 Raw View
gdr@integrable-solutions.net (Gabriel Dos Reis) wrote (abridged):
> What is wrong with 'const int [8]'? One can use a reference to such
> thingy and pass it to a function. Is the automatic decay that is
> boring you?
Yes.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
brangdon@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Tue, 28 Jan 2003 21:12:12 +0000 (UTC) Raw View
thp@cs.ucr.edu wrote in message news:<b14mh6$382$1@glue.ucr.edu>...
> John Nagle <nagle@animats.com> wrote:
> + Paul Hsieh wrote:
> +> But the right answer, as Intel and other compiler vendors perfectly
> +> understand, is to provide the option for compiler re-ordering for
> +> performance.
> + Not good. Compiler options should not change the results of
> + the computation. Compiler writers do that out of desperation,
> + since they can't change the language. If it can change the
> + results, it should appear in the source text, as a pragma
> + if necessary.
> + It's tough to decide how far a floating point optimizer
> + is allowed to go. Do you allow the compiler to apply
> + a*b + a*c ==> a*(b+c)
> + for example?
> I agree. How "if" is "as-if enough"? Floating-point representations
> are already approximations. Is it good enough if close a*(b+c) is as
> close an approximation as a*b+a*c would have been?
The problem is that you must know the values of a, b and c to know
whether it is safe or not.
C originally allowed the compiler to rewrite (a+b)+c as a+(b+c). This
freedom was dropped at the insistance of numerics specialists.
There are definitly cases where such reordering isn't a problem, and
Paul Hsieh has pointed out. And if compilers offer switches to allow
optimizations in such cases, it is because numerics specialists have
found them useful.
But the problem at hand involves reordering of operations on the same
values. C/C++ does not currently allow changing associativity where it
would change the results (which includes most floating point
operations). The compiler currently cannot interpret (a+b)+c as
a+(b+c), but is has the freedom to evaluation a, b and c in any order it
wishes. The question is: does this freedom ever make a difference in
real code. Note that if the evaluation of a, b and c does not involve
any side effects, and the compiler can determine this, then the
reordering will still be legal under the as-if rule.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 29 Jan 03 11:04:44 GMT Raw View
brangdon@cix.co.uk (Dave Harris) wrote in message
news:<memo.20030126113935.24301E@brangdon.madasafish.com>...
> qed@pobox.com (Paul Hsieh) wrote (abridged):
> > double function (restrict double * a, restrict double * b) {
> > double f = 0.0;
> > for (i=0; i < ARRAY_LIMIT; i++) f += a[i] * b[i];
> > return f;
> > }
> It seems to me this is a good example of where the "as-if" rule would
> be sufficient. Only a local variable is written to, so the only
> visible behaviour is the return result. The compiler can rewrite the
> body any way it likes so long as the return result is the same.
It's floating point. The changing order of the additions will change
the results. In this case, it probably doesn't matter, but C was made
stricter when it was standardized on demand of the numerics people --
original C allowed changing associativity, e.g. implementing a+(b+c)
rather than (a+b)+c, but the numerics people insisted that this kind of
liberty made correct programs impossible.
The example is irrelevant to the question at hand, however. C/C++ does
impose an order where sequence points are involved, and it doesn't allow
changing associativity. So a compiler can't reorder the adds under
the current rules. Making the current rules stricter won't change anything.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 29 Jan 2003 12:44:03 -0500 Raw View
qed@pobox.com (Paul Hsieh) wrote in message
news:<796f488f.0301241329.5d729a57@posting.google.com>...
> kanze@gabi-soft.de (James Kanze) wrote:
> > qed@pobox.com (Paul Hsieh) wrote:
> > > kanze@gabi-soft.de (James Kanze) wrote:
> > > > thp@cs.ucr.edu wrote:
> > > > Can you show a case where this would make a mesurable difference
> > > > in a real program? (I know that David Chase asked the question
> > > > many years back, and got no real concrete answer. And compiler
> > > > technology has improved since then.)
> > > Linpack (or just dot products in general) -- on
> > > pipelined/superscalar FP architectures (like the Athlon or
> > > Pentium) this can make a difference on the order of 300%.
> > I repeat: can you show the actual code where it would make a
> > difference? It's been ages since I've looked at linpack, but I don't
> > remember seeing any place where the compiler couldn't do just as
> > well with using the as-if rule.
> Dot product -- You don't know what a dot product is?
I once knew:-).
> Ok, here you go:
> double function (restrict double * a, restrict double * b) {
> double f = 0.0;
> for (i=0; i < ARRAY_LIMIT; i++) f += a[i] * b[i];
> return f;
> }
> In a modern CPU, the multiplies are all parallel and will fly as fast
> as necessary (up to one new result per clock, on an Athlon, for
> example.) However, the "f +=" is the problem here. You have to wait
> for previous adds to complete, before a new one could start (4 clocks
> per add on the Athlon.) If at least we could do this:
> double function (restrict double * a, restrict double * b) {
> double f0 = 0.0, f1 = 0.0, f2 = 0.0, f3 = 0.0;
>
> for (i=0; i < ARRAY_LIMIT; i+=4) {
> f0 += a[i] * b[i];
> f1 += a[i+1] * b[i+1];
> f2 += a[i+2] * b[i+2];
> f3 += a[i+3] * b[i+3];
> }
> return f0 + f1 + f2 + f3;
> }
Sure, but since the current C/C++ rules already don't allow this
rewrite, fixing them won't help much.
I would expect any compiler for such a platform to offer a switch which
would allow something like this, -fsloppy-fp, or something like that.
If you know that there will be no overflow, and you aren't worried by
the difference in the results (which should be slight, if the results
are meaningful to begin with), and ARRAY_LIMIT is a constant and a
multiple of 4, loop unrolling is a well known optimization trick, which
many optimizers are capable of.
> This second snippet is *MUCH* faster than the first because of explit
> parallelism. In theory it can be as much as 4 times faster (since
> there are enough parallel FADDs to launch and complete on every
> clock.) However the number of splits performed here (4 -- for the
> Athlon's 4 cycle FADD pipeline) is clearly platform dependent, and
> therefore, ideally, should be handled in the compiler.
Ideally, everything concerning optimization should be handled by the
compiler:-).
> > [...] Where complicated expressions were involved,
> > there were no side effects. (And if you're counting on the compiler
> > to do parallelization, it will have to do a lot of static analysis;
> > enough to detect when the as-if rule can be applied and when not.)
> > > The Intel C/C++ Compiler (which is uses a common backend with
> > > their Fortran compiler) comes with many switches, including a FP
> > > re-ordering switch which, technically, violates the C/C++
> > > standard, because of this.
> > If you are willing to accept wrong results, obviously the compiler
> > can optimize better:-).
> Its wrong with respect to the C++ rules. Programmers in the real
> world tend not to give a flying F about the C++ rules, if their
> compiler can violate them and give them better results. For correct
> functionality, the numeric analytical properties supersedes C++'s
> impositions. And for a large segment of programmers, so does
> performance.
The fact is that (a+b)+c is not equal to a+(b+c), that numeric
programmers typically pay a lot of attention to this, and that Fortran
forbids rearranging in the presence of parameters, because it gives
wrong results.
In specific cases, the programmer may know that the reordering is OK.
In such cases, compilers, both Fortran and C++, typically order flags to
allow it. Such flags aren't the default, and the languages don't allow
it, because in many cases, it gives wrong results.
I'm not sure what your point is. My point remains: show me some code
and a compiler where removing the current freedoms in the C++ expression
evaluation would result in slower code.
> > Seriously, in this case, you the user have told the compiler that
> > the possible differences don't matter.
> That's solely a "C++ rules" point of view. Of course it can make a
> huge difference to the programmer if it makes their code faster!
> > [...] I don't see where this is relevant
> > to my argument -- if you tell the compiler that the possible differences
> > don't matter, it has more possibilities of applying the as-if rule.
> I brought it up to point out that this this is a problem that has
> forced compilers vendors to work around it.
What problem has forced what compiler vendors to work around?
The question was: is there any code/compiler where the resulting program
would be measurably slower if C++ imposed a specific order. The above
example is completely irrelevant to this question, since the expressions
are so simple that no reordering is possible, and since they only
involve built-in types, with everything visible to the compiler, so the
reordering could take place anyway if it were safe, since the compiler
could see everything, and apply the as-if rule.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: brangdon@cix.co.uk (Dave Harris)
Date: 25 Jan 2003 20:18:22 -0500 Raw View
gdr@integrable-solutions.net (Gabriel Dos Reis) wrote (abridged):
> brangdon@cix.co.uk (Dave Harris) writes:
>
> | gdr@integrable-solutions.net (Gabriel Dos Reis) wrote (abridged):
> | > A naive approach would consist in saying, the expression { 1, 2, 3,
> | > x, y, z } has type 'int [6]' provided x, y, z ares ints.
> |
> | I had more in mind that the expression would have type:
> | const std::vector<int>
>
> Yeah, I intended the "const" (but missed to write it out explicitly)
> but I would personnaly don't want the dynamic allocation implied by
> std::vector<int>.
That's why I mentioned that some new type may be needed.
On the other hand, a const vector can't be grown or shrunk, so it doesn't
need dynamic allocation. Similar issues arise with:
const std::string s = "Hello, World\n";
It would be nice to think this would not copy the bytes of the string. In
general that is hard to do, because the object's destructor needs to
behave differently if its array memory wasn't allocated dynamically. With
stack objects the compiler should be able to keep track, because it knows
where the object came from. For heap objects an extra flag might be
needed, which probably isn't worth it.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
brangdon@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Gabriel Dos Reis <gdr@integrable-solutions.net>
Date: 27 Jan 03 05:22:31 GMT Raw View
brangdon@cix.co.uk (Dave Harris) writes:
| gdr@integrable-solutions.net (Gabriel Dos Reis) wrote (abridged):
| > brangdon@cix.co.uk (Dave Harris) writes:
| >
| > | gdr@integrable-solutions.net (Gabriel Dos Reis) wrote (abridged):
| > | > A naive approach would consist in saying, the expression { 1, 2, 3,
| > | > x, y, z } has type 'int [6]' provided x, y, z ares ints.
| > |
| > | I had more in mind that the expression would have type:
| > | const std::vector<int>
| >
| > Yeah, I intended the "const" (but missed to write it out explicitly)
| > but I would personnaly don't want the dynamic allocation implied by
| > std::vector<int>.
|
| That's why I mentioned that some new type may be needed.
What is wrong with 'const int [8]'? One can use a reference to such
thingy and pass it to a function. Is the automatic decay that is boring you?
--
Gabriel Dos Reis, gdr@integrable-solutions.net
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: thp@cs.ucr.edu
Date: 27 Jan 2003 05:41:27 -0500 Raw View
In comp.lang.c++.moderated Paul Hsieh <qed@pobox.com> wrote:
+ thp@cs.ucr.edu wrote in message news:<b0lft3$p1h$1@glue.ucr.edu>...
[...]
+> The issue of the gains from unspecified order of evaluation came up a
+> year or two ago on cmomp.std.c, and I got some convincing arguments
+> from Nick Mclaren to the effect that it can make a significant
+> difference in important real-world situations. I didn't push the
+> matter, but he and others convinced me that the the akwardness might
+> be in the language for important reasons.
+
+ Yes, he is doubtlessly citing one of many examples from Prof. Kahan
+ (kind of the godfather of the IEEE-754 standard.) And he is correct.
My guess is that he is thinking of his own very extensive experience
in these matters (but I agree with you about Kahan excellent
contributions).
+ But the right answer, as Intel and other compiler vendors perfectly
+ understand, is to provide the option for compiler re-ordering for
+ performance.
+ The point about dot products, is that typically the order of the terms
+ has nothing to do with the numerical stability of the computation.
+ I.e., no static program ordering can guarantee the most numerically
+ stable computation anyway (since the ordinates may be re-ordered
+ depending on the source data anyway.) Given this fact, it makes sense
+ that since there is no imposed ordering that makes any difference, the
+ compiler should be allowed to take advantage of this somehow.
So, if I understand correctly, the as-if rule would give conforming
implementations all of the permission they need to optimally reorder
the the dot-product computation, even if the Standard specified some
particular order. Right?
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: brangdon@cix.co.uk (Dave Harris)
Date: 27 Jan 2003 05:42:19 -0500 Raw View
qed@pobox.com (Paul Hsieh) wrote (abridged):
> double function (restrict double * a, restrict double * b) {
> double f = 0.0;
>
> for (i=0; i < ARRAY_LIMIT; i++) f += a[i] * b[i];
> return f;
> }
It seems to me this is a good example of where the "as-if" rule would be
sufficient. Only a local variable is written to, so the only visible
behaviour is the return result. The compiler can rewrite the body any way
it likes so long as the return result is the same.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
brangdon@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Mon, 27 Jan 2003 20:28:33 +0000 (UTC) Raw View
Paul Hsieh wrote:
> But the right answer, as Intel and other compiler vendors perfectly
> understand, is to provide the option for compiler re-ordering for
> performance.
Not good. Compiler options should not change the results of
the computation. Compiler writers do that out of desperation,
since they can't change the language. If it can change the
results, it should appear in the source text, as a pragma
if necessary.
It's tough to decide how far a floating point optimizer
is allowed to go. Do you allow the compiler to apply
a*b + a*c ==> a*(b+c)
for example?
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: qed@pobox.com (Paul Hsieh)
Date: Fri, 24 Jan 2003 22:14:15 +0000 (UTC) Raw View
thp@cs.ucr.edu wrote in message news:<b0igss$gl1$1@glue.ucr.edu>...
> Paul Hsieh <qed@pobox.com> wrote:
> + thp@cs.ucr.edu wrote in message news:<avp4oe$br2$1@glue.ucr.edu>...
> +> James Kanze <kanze@gabi-soft.de> wrote:
> +> + nagle@animats.com (John Nagle) wrote in message
> +> [...]
> +> +> But it's definitely do-able. Any compiler that maintains a flow graph
> +> +> internally could probably add that optimization. As I pointed out in
> +> +> another posting, though, you have to be willing to detect some errors
> +> +> "early".
> +> +
> +> + Or detect that there is no change in the observable behavior.
> +> +
> +> + This is probably one of the great advantages of having bounds checking
> +> + built into the language. The compiler "knows" about the observable
> +> + behavior of bounds checking (including that it aborts the program, so
> +> + any changes of state in the loop which aren't immediately visible can't
> +> + affect any futhre behavoir, since there won't be any).
> +>
> +> This raises a very interesting point. If I understand the
> +> implications of undefined behavior correctly, under the current
> +> Standard, a conforming can hoist bounds check out of the loop, even if
> +> the loop body accesses a volatile variable. However, if the Standard
> +> were to define the behavior at bounds violation to be say the throwing
> +> of an exception, that check could not be hoisted out of that loop.
> +>
> +> In other words to require bounds checks but allow them to be hoisted,
> +> requires some rather tedious amendments to the Standard. It's not a
> +> simple matter of defining behavior at the point of overflow.
> +
> + What's wrong with "a provable bounds overrun may case an exception to
> + be thrown from any enclosing scope"?
>
> Would that be unspecified or implementation-defined behavior or
> something else?
>
> + (I.e., there is no guarantee
> + that even the code leading up to the bounds overrun is executed.)
>
> So, that doesn't sound like unspecified or implementation-defined
> behavior, since you are specifically allowing the test and throw
> to be hoisted.
Right, what I meant to say is that a "bounds overrun exception" (which
is being proposed to always happen) may actually be thrown early. If
someone tries to catch this exception inside the hoist point, then
woudln't it just be illegal to hoist it outside of that scope?
--
Paul Hsieh
http://bstring.sourceforge.net
http://www.pobox.com/~qed/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: qed@pobox.com (Paul Hsieh)
Date: 25 Jan 03 13:37:24 GMT Raw View
thp@cs.ucr.edu wrote in message news:<b0lft3$p1h$1@glue.ucr.edu>...
> In comp.lang.c++.moderated Paul Hsieh <qed@pobox.com> wrote:
> + kanze@gabi-soft.de (James Kanze) wrote:
> +> thp@cs.ucr.edu wrote:
> +> > In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> +> > [...]
> +> > + My only point is that people just screeming out that
> +> > + Java is slower don't really know what they are talking about.
> +>
> +> > Were we misled when we were told that C/C++ derives significant speed
> +> > benefits from features like:
> +>
> +> Probably.
> +>
> +> > - unspecified order of evaluation for most operators,
> +>
> +> Can you show a case where this would make a mesurable difference in a
> +> real program? (I know that David Chase asked the question many years
> +> back, and got no real concrete answer. And compiler technology has
> +> improved since then.)
> +
> + Linpack (or just dot products in general) -- on pipelined/superscalar
> + FP architectures (like the Athlon or Pentium) this can make a
> + difference on the order of 300%. The Intel C/C++ Compiler (which is
> + uses a common backend with their Fortran compiler) comes with many
> + switches, including a FP re-ordering switch which, technically,
> + violates the C/C++ standard, because of this.
>
> The issue of the gains from unspecified order of evaluation came up a
> year or two ago on cmomp.std.c, and I got some convincing arguments
> from Nick Mclaren to the effect that it can make a significant
> difference in important real-world situations. I didn't push the
> matter, but he and others convinced me that the the akwardness might
> be in the language for important reasons.
Yes, he is doubtlessly citing one of many examples from Prof. Kahan
(kind of the godfather of the IEEE-754 standard.) And he is correct.
But the right answer, as Intel and other compiler vendors perfectly
understand, is to provide the option for compiler re-ordering for
performance.
The point about dot products, is that typically the order of the terms
has nothing to do with the numerical stability of the computation.
I.e., no static program ordering can guarantee the most numerically
stable computation anyway (since the ordinates may be re-ordered
depending on the source data anyway.) Given this fact, it makes sense
that since there is no imposed ordering that makes any difference, the
compiler should be allowed to take advantage of this somehow.
--
Paul Hsieh
http://bstring.sourceforge.net
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: qed@pobox.com (Paul Hsieh)
Date: 25 Jan 03 13:37:43 GMT Raw View
kanze@gabi-soft.de (James Kanze) wrote:
> qed@pobox.com (Paul Hsieh) wrote:
> > kanze@gabi-soft.de (James Kanze) wrote:
> > > thp@cs.ucr.edu wrote:
> > > Can you show a case where this would make a mesurable difference in
> > > a real program? (I know that David Chase asked the question many
> > > years back, and got no real concrete answer. And compiler
> > > technology has improved since then.)
>
> > Linpack (or just dot products in general) -- on pipelined/superscalar
> > FP architectures (like the Athlon or Pentium) this can make a
> > difference on the order of 300%.
>
> I repeat: can you show the actual code where it would make a
> difference? It's been ages since I've looked at linpack, but I don't
> remember seeing any place where the compiler couldn't do just as well
> with using the as-if rule.
Dot product -- You don't know what a dot product is? Ok, here you go:
double function (restrict double * a, restrict double * b) {
double f = 0.0;
for (i=0; i < ARRAY_LIMIT; i++) f += a[i] * b[i];
return f;
}
In a modern CPU, the multiplies are all parallel and will fly as fast
as necessary (up to one new result per clock, on an Athlon, for
example.) However, the "f +=" is the problem here. You have to wait
for previous adds to complete, before a new one could start (4 clocks
per add on the Athlon.) If at least we could do this:
double function (restrict double * a, restrict double * b) {
double f0 = 0.0, f1 = 0.0, f2 = 0.0, f3 = 0.0;
for (i=0; i < ARRAY_LIMIT; i+=4) {
f0 += a[i] * b[i];
f1 += a[i+1] * b[i+1];
f2 += a[i+2] * b[i+2];
f3 += a[i+3] * b[i+3];
}
return f0 + f1 + f2 + f3;
}
This second snippet is *MUCH* faster than the first because of explit
parallelism. In theory it can be as much as 4 times faster (since
there are enough parallel FADDs to launch and complete on every
clock.) However the number of splits performed here (4 -- for the
Athlon's 4 cycle FADD pipeline) is clearly platform dependent, and
therefore, ideally, should be handled in the compiler.
> [...] Where complicated expressions were involved,
> there were no side effects. (And if you're counting on the compiler to
> do parallelization, it will have to do a lot of static analysis; enough
> to detect when the as-if rule can be applied and when not.)
>
> > The Intel C/C++ Compiler (which is uses a common backend with their
> > Fortran compiler) comes with many switches, including a FP re-ordering
> > switch which, technically, violates the C/C++ standard, because of
> > this.
>
> If you are willing to accept wrong results, obviously the compiler can
> optimize better:-).
Its wrong with respect to the C++ rules. Programmers in the real
world tend not to give a flying F about the C++ rules, if their
compiler can violate them and give them better results. For correct
functionality, the numeric analytical properties supersedes C++'s
impositions. And for a large segment of programmers, so does
performance.
> Seriously, in this case, you the user have told the compiler that the
> possible differences don't matter.
That's solely a "C++ rules" point of view. Of course it can make a
huge difference to the programmer if it makes their code faster!
> [...] I don't see where this is relevant
> to my argument -- if you tell the compiler that the possible differences
> don't matter, it has more possibilities of applying the as-if rule.
I brought it up to point out that this this is a problem that has
forced compilers vendors to work around it.
--
Paul Hsieh
http://bstring.sourceforge.net
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 23 Jan 2003 05:47:11 -0500 Raw View
qed@pobox.com (Paul Hsieh) wrote in message
news:<796f488f.0301200827.1e6187c9@posting.google.com>...
> kanze@gabi-soft.de (James Kanze) wrote:
> > thp@cs.ucr.edu wrote:
> > > In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> > > [...]
> > > + My only point is that people just screeming out that
> > > + Java is slower don't really know what they are talking about.
> > > Were we misled when we were told that C/C++ derives significant
> > > speed benefits from features like:
> > Probably.
> > > - unspecified order of evaluation for most operators,
> > Can you show a case where this would make a mesurable difference in
> > a real program? (I know that David Chase asked the question many
> > years back, and got no real concrete answer. And compiler
> > technology has improved since then.)
> Linpack (or just dot products in general) -- on pipelined/superscalar
> FP architectures (like the Athlon or Pentium) this can make a
> difference on the order of 300%.
I repeat: can you show the actual code where it would make a
difference? It's been ages since I've looked at linpack, but I don't
remember seeing any place where the compiler couldn't do just as well
with using the as-if rule. Where complicated expressions were involved,
there were no side effects. (And if you're counting on the compiler to
do parallelization, it will have to do a lot of static analysis; enough
to detect when the as-if rule can be applied and when not.)
> The Intel C/C++ Compiler (which is uses a common backend with their
> Fortran compiler) comes with many switches, including a FP re-ordering
> switch which, technically, violates the C/C++ standard, because of
> this.
If you are willing to accept wrong results, obviously the compiler can
optimize better:-).
Seriously, in this case, you the user have told the compiler that the
possible differences don't matter. I don't see where this is relevant
to my argument -- if you tell the compiler that the possible differences
don't matter, it has more possibilities of applying the as-if rule.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: 23 Jan 2003 05:49:36 -0500 Raw View
In comp.lang.c++.moderated Paul Hsieh <qed@pobox.com> wrote:
+ kanze@gabi-soft.de (James Kanze) wrote:
+> thp@cs.ucr.edu wrote:
+> > In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
+> > [...]
+> > + My only point is that people just screeming out that
+> > + Java is slower don't really know what they are talking about.
+>
+> > Were we misled when we were told that C/C++ derives significant speed
+> > benefits from features like:
+>
+> Probably.
+>
+> > - unspecified order of evaluation for most operators,
+>
+> Can you show a case where this would make a mesurable difference in a
+> real program? (I know that David Chase asked the question many years
+> back, and got no real concrete answer. And compiler technology has
+> improved since then.)
+
+ Linpack (or just dot products in general) -- on pipelined/superscalar
+ FP architectures (like the Athlon or Pentium) this can make a
+ difference on the order of 300%. The Intel C/C++ Compiler (which is
+ uses a common backend with their Fortran compiler) comes with many
+ switches, including a FP re-ordering switch which, technically,
+ violates the C/C++ standard, because of this.
The issue of the gains from unspecified order of evaluation came up a
year or two ago on cmomp.std.c, and I got some convincing arguments
from Nick Mclaren to the effect that it can make a significant
difference in important real-world situations. I didn't push the
matter, but he and others convinced me that the the akwardness might
be in the language for important reasons.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: qed@pobox.com (Paul Hsieh)
Date: 20 Jan 03 05:58:35 GMT Raw View
igivanov@yahoo.com (Igor Ivanov) wrote in message
> allan_w@my-dejanews.com (Allan W) wrote in message
> > I'd like to see the next standard explicitly state that arrays (both
> > STL and built-in) are bounds-checked, UNLESS compiled in a special
> > mode that disables bounds checking. (There are good reasons to disable
> > it, especially in legacy code that intentionally declares 1-element
> > arrays and indexes past the end...)
>
> I don't see how C arrays could be checked without testing *each*
> dereferenced pointer in the program. On the other hand, a C array as
> an "object" doesn't have a defined interface at all, so I am not sure
> there is something to check.
It is only required that the compiler *prove* that an array is not
overrun, not necessarily that it check it on every access. Compilers
for other high level languages do this. The ANSI C standard (and
probably the C++ standard) just says that out-of-bounds access are
undefined -- but what that means is that compilers today could go
ahead and define them to throw a fault or compiler warning/error or
whatever.
That said, another way to do this is to provide usable libraries which
mitigates buffer overflow problems. I have done this with a high
performance, yet safe and powerful string library:
http://bstring.sourceforge.net
Checks are done in "outer loops", and the inner loops have been
implemented with performance in mind (and checked with a profiler on
multiple compilers.)
Using reliable libraries such as the above is a better alternative
since it does require changing compilers. Perhaps such libraries
should be added to the standard, but in absence of this, just making
them available and actually using them is a good alternative.
--
Paul Hsieh
http://www.pobox.com/~qed
http://bstring.sourceforge.net
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: brangdon@cix.co.uk (Dave Harris)
Date: 20 Jan 2003 07:49:07 -0500 Raw View
gdr@integrable-solutions.net (Gabriel Dos Reis) wrote (abridged):
> A naive approach would consist in saying, the expression { 1, 2, 3,
> x, y, z } has type 'int [6]' provided x, y, z ares ints.
I had more in mind that the expression would have type:
const std::vector<int>
In other words, I wanted a higher level object which was more
self-describing. So that, for example, it could be passed to some function
and the function would know how many ints there were. (Perhaps some new
type is needed for this, rather then std::vector. There is no need to
store a capacity.)
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
brangdon@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: 20 Jan 03 13:03:08 GMT Raw View
In comp.std.c++ Igor Ivanov <igivanov@yahoo.com> wrote:
[...]
+ I don't see how C arrays could be checked without testing *each*
+ dereferenced pointer in the program.
One could start by inserting bounds-checking code in exactly that way,
and then optimize away as much of it as possible. The big win occurs
when such code gets hoisted out of loops.
Tom Payne
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: qed@pobox.com (Paul Hsieh)
Date: Mon, 20 Jan 2003 16:23:47 +0000 (UTC) Raw View
thp@cs.ucr.edu wrote in message news:<avp4oe$br2$1@glue.ucr.edu>...
> James Kanze <kanze@gabi-soft.de> wrote:
> + nagle@animats.com (John Nagle) wrote in message
> [...]
> +> But it's definitely do-able. Any compiler that maintains a flow graph
> +> internally could probably add that optimization. As I pointed out in
> +> another posting, though, you have to be willing to detect some errors
> +> "early".
> +
> + Or detect that there is no change in the observable behavior.
> +
> + This is probably one of the great advantages of having bounds checking
> + built into the language. The compiler "knows" about the observable
> + behavior of bounds checking (including that it aborts the program, so
> + any changes of state in the loop which aren't immediately visible can't
> + affect any futhre behavoir, since there won't be any).
>
> This raises a very interesting point. If I understand the
> implications of undefined behavior correctly, under the current
> Standard, a conforming can hoist bounds check out of the loop, even if
> the loop body accesses a volatile variable. However, if the Standard
> were to define the behavior at bounds violation to be say the throwing
> of an exception, that check could not be hoisted out of that loop.
>
> In other words to require bounds checks but allow them to be hoisted,
> requires some rather tedious amendments to the Standard. It's not a
> simple matter of defining behavior at the point of overflow.
What's wrong with "a provable bounds overrun may case an exception to
be thrown from any enclosing scope"? (I.e., there is no guarantee
that even the code leading up to the bounds overrun is executed.)
This is infinitely better than the current situation, and if you have
this kind of bug in your code, its not clear that you need better
granularity than this to debug it.
If you access a volatile variable inside a bounds check, then is such
a "provable bounds overrun" even possible? Can't accessing it can
cause a side effect that changes other values, including loop counts?
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Gabriel Dos Reis <gdr@integrable-solutions.net>
Date: 20 Jan 03 17:50:55 GMT Raw View
brangdon@cix.co.uk (Dave Harris) writes:
| gdr@integrable-solutions.net (Gabriel Dos Reis) wrote (abridged):
| > A naive approach would consist in saying, the expression { 1, 2, 3,
| > x, y, z } has type 'int [6]' provided x, y, z ares ints.
|
| I had more in mind that the expression would have type:
| const std::vector<int>
Yeah, I intended the "const" (but missed to write it out explicitly)
but I would personnaly don't want the dynamic allocation implied by
std::vector<int>.
--
Gabriel Dos Reis, gdr@integrable-solutions.net
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: thp@cs.ucr.edu
Date: Tue, 21 Jan 2003 19:04:45 +0000 (UTC) Raw View
Paul Hsieh <qed@pobox.com> wrote:
+ thp@cs.ucr.edu wrote in message news:<avp4oe$br2$1@glue.ucr.edu>...
+> James Kanze <kanze@gabi-soft.de> wrote:
+> + nagle@animats.com (John Nagle) wrote in message
+> [...]
+> +> But it's definitely do-able. Any compiler that maintains a flow graph
+> +> internally could probably add that optimization. As I pointed out in
+> +> another posting, though, you have to be willing to detect some errors
+> +> "early".
+> +
+> + Or detect that there is no change in the observable behavior.
+> +
+> + This is probably one of the great advantages of having bounds checking
+> + built into the language. The compiler "knows" about the observable
+> + behavior of bounds checking (including that it aborts the program, so
+> + any changes of state in the loop which aren't immediately visible can't
+> + affect any futhre behavoir, since there won't be any).
+>
+> This raises a very interesting point. If I understand the
+> implications of undefined behavior correctly, under the current
+> Standard, a conforming can hoist bounds check out of the loop, even if
+> the loop body accesses a volatile variable. However, if the Standard
+> were to define the behavior at bounds violation to be say the throwing
+> of an exception, that check could not be hoisted out of that loop.
+>
+> In other words to require bounds checks but allow them to be hoisted,
+> requires some rather tedious amendments to the Standard. It's not a
+> simple matter of defining behavior at the point of overflow.
+
+ What's wrong with "a provable bounds overrun may case an exception to
+ be thrown from any enclosing scope"?
Would that be unspecified or implementation-defined behavior or
something else?
+ (I.e., there is no guarantee
+ that even the code leading up to the bounds overrun is executed.)
So, that doesn't sound like unspecified or implementation-defined
behavior, since you are specifically allowing the test and throw
to be hoisted.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: qed@pobox.com (Paul Hsieh)
Date: 21 Jan 03 07:24:28 GMT Raw View
kanze@gabi-soft.de (James Kanze) wrote:
> thp@cs.ucr.edu wrote:
> > In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> > [...]
> > + My only point is that people just screeming out that
> > + Java is slower don't really know what they are talking about.
>
> > Were we misled when we were told that C/C++ derives significant speed
> > benefits from features like:
>
> Probably.
>
> > - unspecified order of evaluation for most operators,
>
> Can you show a case where this would make a mesurable difference in a
> real program? (I know that David Chase asked the question many years
> back, and got no real concrete answer. And compiler technology has
> improved since then.)
Linpack (or just dot products in general) -- on pipelined/superscalar
FP architectures (like the Athlon or Pentium) this can make a
difference on the order of 300%. The Intel C/C++ Compiler (which is
uses a common backend with their Fortran compiler) comes with many
switches, including a FP re-ordering switch which, technically,
violates the C/C++ standard, because of this.
--
Paul Hsieh
http://www.pobox.com/~qed
http://bstring.sourceforge.net/
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: "Rob" <nospam@does.not.exist>
Date: 16 Jan 03 05:23:00 GMT Raw View
"Igor Ivanov" <igivanov@yahoo.com> wrote in message
news:d117aff2.0301131058.827d3e6@posting.google.com...
> allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0301130228.3bbb4628@posting.google.com>...
> > > thp@cs.ucr.edu wrote
> > > > - not requiring bounds checking for array accesses,
> >
> > igivanov@yahoo.com (Igor Ivanov) wrote
> > > IMHO this is one of the most disgusting features of C/C++. I guess
> > > that the time (and money) saved in all programs written in these
> > > languages that ever ran is negligent compared to the time (and money)
> > > lost due to buffer overruns and the like. C-style arrays and strings
> > > are probably hopeless anyway, but the C++ STL is not AFAIK.
> >
> > When programs are written correctly, bounds-checking does nothing
> > but slow the operation down. This is especially important in tight
> > loops, and/or in real-time code such as certain parts of operating
> > systems or device drivers.
>
> This is true, but
> a) as we all know, each program has at least 1 bug; as you noted,
> debugging at a certain point becomes very expensive;
That bug can be eliminated by disciplined design and coding techniques.
Unfortunately, using those techniques relies on humans, and humans are
notorious for taking shortcuts.
> b) in 90% (for the sake of argument) of all code written bounds
> checking dosen't matter either because the code is doing something
> else which takes much more time, or the total execution time is just
> negligent with or w/o checking.
I won't speculate on the percentage, but the total execution time of
bounds checking can be a significant burden for some applications.
YMMV of course, but the assumption that bounds checking is
insignificant will probably bite at the worst time (eg reusing code
in an application with hard real time constraints).
>
> Hence it comes as a reasonable requirement that we'd like to be able
> to deliberately leave bounds checking on at all times in at least some
> parts of the program. In other parts which we are prepared to debug
> more thorougly we'd like to turn checking on only during debugging.
Some compilers support options for bounds checking, but that is
turned off for production code.
>
> >
> > But you're right -- debugging these problems is very expensive. Also,
> > I expect that at least 2/3 of all security holes Unix systems or
> > on various servers on the Internet, comes from someone finding a way
> > to exploit a buffer overflow.
> >
> > "QOI! QOI!" But the fact is, major C and C++ compilers simply don't
> > provide a way to this.
> >
> > I'd like to see the next standard explicitly state that arrays (both
> > STL and built-in) are bounds-checked, UNLESS compiled in a special
> > mode that disables bounds checking. (There are good reasons to disable
> > it, especially in legacy code that intentionally declares 1-element
> > arrays and indexes past the end...)
>
> I don't see how C arrays could be checked without testing *each*
> dereferenced pointer in the program. On the other hand, a C array as
> an "object" doesn't have a defined interface at all, so I am not sure
> there is something to check.
Sure it is. It could be picked up by analysing all the source for a
program
at once (rather than one file at a time). C++ compilers don't do that (they
work
with one source file at a time), but other tools could --- if there was
sufficient
demand for development of such a tool. Certainly, lint used to do analysis
using relationships between multiple source files (although I can't recall
offhand if it actually checked things like array bounds).
More practically, it comes down to defining test cases, and using those test
cases to verify with run-time tests. The difficulty then is proving that
those
run time tests pick up every possible usage. And the issues discussed above
about performance overhead, but those may be eliminated (eg by compiling
in a DEBUG mode).
[Snip]
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: kuyper@wizard.net ("James Kuyper Jr.")
Date: Sat, 11 Jan 2003 17:27:12 +0000 (UTC) Raw View
James Kanze wrote:
....
> (How far should the compiler use this knowledge? If the programmer
> writes "sin(x)*sin(x) + cos(x)*cos(x)", should the compiler replace the
> expression by 1.0?)
I once wrote a program which contained the equivalent of that
expression. The purpose was to test the accuracy of the sin() and cos()
functions. It would have been broken (for my purposes) by such an
optimization; except that I thought about that very possibility, and
made sure that the sin() and cos() evaluations occurred in an entirely
different translation unit from the '+', in order to make it difficult
to perform such an optimization.
I think such an optimization would be legal, and in most cases,
desirable. It probably wouldn't come up very often, however.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gdr@integrable-solutions.net (Gabriel Dos Reis)
Date: Sat, 11 Jan 2003 18:54:01 +0000 (UTC) Raw View
loic.actarus.joly@wanadoo.fr (Lo=EFc Joly) writes:
| James Kanze wrote:
|=20
| > (How far should the compiler use this knowledge? If the programmer
| > writes "sin(x)*sin(x) + cos(x)*cos(x)", should the compiler replace t=
he
| > expression by 1.0?)
|=20
| I do not think it could do so.
How can the program tell the difference?
--=20
Gabriel Dos Reis, gdr@integrable-solutions.net
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Sat, 11 Jan 2003 18:54:50 +0000 (UTC) Raw View
James Kanze <kanze@gabi-soft.de> wrote:
+ nagle@animats.com (John Nagle) wrote in message
[...]
+> But it's definitely do-able. Any compiler that maintains a flow graph
+> internally could probably add that optimization. As I pointed out in
+> another posting, though, you have to be willing to detect some errors
+> "early".
+
+ Or detect that there is no change in the observable behavior.
+
+ This is probably one of the great advantages of having bounds checking
+ built into the language. The compiler "knows" about the observable
+ behavior of bounds checking (including that it aborts the program, so
+ any changes of state in the loop which aren't immediately visible can't
+ affect any futhre behavoir, since there won't be any).
This raises a very interesting point. If I understand the
implications of undefined behavior correctly, under the current
Standard, a conforming can hoist bounds check out of the loop, even if
the loop body accesses a volatile variable. However, if the Standard
were to define the behavior at bounds violation to be say the throwing
of an exception, that check could not be hoisted out of that loop.
In other words to require bounds checks but allow them to be hoisted,
requires some rather tedious amendments to the Standard. It's not a
simple matter of defining behavior at the point of overflow.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: igivanov@yahoo.com (Igor Ivanov)
Date: 11 Jan 2003 23:54:29 -0500 Raw View
KIM Seungbeom <musiphil@bawi.org> wrote in message news:<3E1EE28B.21B2A5A0@bawi.org>...
> Igor Ivanov wrote:
> >
> > thp@cs.ucr.edu wrote in message news:<avdrc8$qf2$1@glue.ucr.edu>...
> > > In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> [snip]
> > lost due to buffer overruns and the like. C-style arrays and strings
> > are probably hopeless anyway, but the C++ STL is not AFAIK.
>
> You can use an implementation with debug support (such as STLport),
> can't you?
Yes I can, and do use STLPort, but having it in the Standard is a
different matter. Until then it's just a feature of an implementation
and no one is obliged to use it even if it is there. IMO not having
checked iterators/indexes in the language standard is about as harmful
as allowing the compiler to generate code from syntactically incorrect
code.
Igor
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: 13 Jan 03 09:02:38 GMT Raw View
In comp.lang.c++.moderated James Kanze <kanze@gabi-soft.de> wrote:
+ thp@cs.ucr.edu wrote in message news:<avinsu$gji$1@glue.ucr.edu>...
[...]
+> Okay, so if those very significant pitfalls don't offer speed
+> advantages, why are they still in the language?
+
+ Don't ask me. Historical reasons, I suppose.
Traps and pitfalls in programming languages can kill people. IMHO,
organizations have a moral obligation not to leave gratuitous hazards
in their wakes. (Perhaps product liability laws can be extended to
cover language designs.)
It's my impression that most texts and courses on C/C++ leave many of
the undefined behavior pitfalls unmentioned. Thus, for example, most
practicing C/C++ programmers don't realize the dangers of modifying an
oject and otherwise accessing it (except to determine the new value)
in the same expression. Most of their errors will be caught in
debugging, but there is no guarantee that one of those errors won't
remain in mission-critical software.
Tom Payne
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 13 Jan 03 15:09:56 GMT Raw View
> thp@cs.ucr.edu wrote
> > - not requiring bounds checking for array accesses,
igivanov@yahoo.com (Igor Ivanov) wrote
> IMHO this is one of the most disgusting features of C/C++. I guess
> that the time (and money) saved in all programs written in these
> languages that ever ran is negligent compared to the time (and money)
> lost due to buffer overruns and the like. C-style arrays and strings
> are probably hopeless anyway, but the C++ STL is not AFAIK.
When programs are written correctly, bounds-checking does nothing
but slow the operation down. This is especially important in tight
loops, and/or in real-time code such as certain parts of operating
systems or device drivers.
But you're right -- debugging these problems is very expensive. Also,
I expect that at least 2/3 of all security holes Unix systems or
on various servers on the Internet, comes from someone finding a way
to exploit a buffer overflow.
"QOI! QOI!" But the fact is, major C and C++ compilers simply don't
provide a way to this.
I'd like to see the next standard explicitly state that arrays (both
STL and built-in) are bounds-checked, UNLESS compiled in a special
mode that disables bounds checking. (There are good reasons to disable
it, especially in legacy code that intentionally declares 1-element
arrays and indexes past the end...)
Almost as good would be to have the standard say that all arrays are
always bounds-checked. Then the shoe would be on the other foot --
major compilers WOULD offer this same choice, for legacy reasons.
The catch, I'm sure many of you have noticed, is that raw pointers
typically won't have information about index ranges. This doesn't
just affect heap arrays, but also program sections that MIGHT point
to objects on the heap. And existing compilers can't exactly change
the way pointers are stored for next version, not without making
all existing libraries obsolete overnight. Furthermore, if a library
changes the way operator new works (to save the array size somewhere),
how does this fit in with placement new?
I don't have a good answer for that. Maybe someone smarter than I
can figure out a good compromise?
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: Francis Glassborow <francis.glassborow@ntlworld.com>
Date: 14 Jan 03 04:46:32 GMT Raw View
In article <7f2735a5.0301130228.3bbb4628@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>The catch, I'm sure many of you have noticed, is that raw pointers
>typically won't have information about index ranges. This doesn't
>just affect heap arrays
Indeed it does not, as C-style arrays (of all flavours) are passed
around via pointers its impact is so extensive as to require an entire
redesign of the language. Face it, that is not going to happen.
So let us spend time on consideration of how we can provide appropriate
tools to programmers. Providing range checked array like containers
(with the range checking applied throughout, rather than just to a
specific form of access) might help. Even better if those could reside
entirely on the stack (use of appropriate template technology)
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: agriff@tin.it (Andrea Griffini)
Date: 14 Jan 2003 06:05:28 -0500 Raw View
On 13 Jan 03 09:02:38 GMT, thp@cs.ucr.edu wrote:
>It's my impression that most texts and courses on C/C++ leave many of
>the undefined behavior pitfalls unmentioned.
Worse than that, at least here in italy. I've seen
university-level material used for C++ courses
telling that if you access an array outside its
size you'll get a runtime error (crash).
So not only they're not telling the students about
the daemons that are present in C++... they're even
telling them about angels that no programmer can
count on when working in C++.
Students are not left with a doubt about that... an
optimistic misconception is used to fill the gap.
Andrea
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: igivanov@yahoo.com (Igor Ivanov)
Date: 14 Jan 2003 06:17:08 -0500 Raw View
allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0301130228.3bbb4628@posting.google.com>...
> > thp@cs.ucr.edu wrote
> > > - not requiring bounds checking for array accesses,
>
> igivanov@yahoo.com (Igor Ivanov) wrote
> > IMHO this is one of the most disgusting features of C/C++. I guess
> > that the time (and money) saved in all programs written in these
> > languages that ever ran is negligent compared to the time (and money)
> > lost due to buffer overruns and the like. C-style arrays and strings
> > are probably hopeless anyway, but the C++ STL is not AFAIK.
>
> When programs are written correctly, bounds-checking does nothing
> but slow the operation down. This is especially important in tight
> loops, and/or in real-time code such as certain parts of operating
> systems or device drivers.
This is true, but
a) as we all know, each program has at least 1 bug; as you noted,
debugging at a certain point becomes very expensive;
b) in 90% (for the sake of argument) of all code written bounds
checking dosen't matter either because the code is doing something
else which takes much more time, or the total execution time is just
negligent with or w/o checking.
Hence it comes as a reasonable requirement that we'd like to be able
to deliberately leave bounds checking on at all times in at least some
parts of the program. In other parts which we are prepared to debug
more thorougly we'd like to turn checking on only during debugging.
>
> But you're right -- debugging these problems is very expensive. Also,
> I expect that at least 2/3 of all security holes Unix systems or
> on various servers on the Internet, comes from someone finding a way
> to exploit a buffer overflow.
>
> "QOI! QOI!" But the fact is, major C and C++ compilers simply don't
> provide a way to this.
>
> I'd like to see the next standard explicitly state that arrays (both
> STL and built-in) are bounds-checked, UNLESS compiled in a special
> mode that disables bounds checking. (There are good reasons to disable
> it, especially in legacy code that intentionally declares 1-element
> arrays and indexes past the end...)
I don't see how C arrays could be checked without testing *each*
dereferenced pointer in the program. On the other hand, a C array as
an "object" doesn't have a defined interface at all, so I am not sure
there is something to check.
>
> Almost as good would be to have the standard say that all arrays are
> always bounds-checked. Then the shoe would be on the other foot --
> major compilers WOULD offer this same choice, for legacy reasons.
I don't agree with "always". There indeed can be tight loops as you
mentioned.
>
> The catch, I'm sure many of you have noticed, is that raw pointers
> typically won't have information about index ranges. This doesn't
> just affect heap arrays, but also program sections that MIGHT point
> to objects on the heap. And existing compilers can't exactly change
> the way pointers are stored for next version, not without making
> all existing libraries obsolete overnight. Furthermore, if a library
> changes the way operator new works (to save the array size somewhere),
> how does this fit in with placement new?
[]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Fri, 10 Jan 2003 01:30:35 +0000 (UTC) Raw View
John Nagle <nagle@animats.com> wrote:
+ thp@cs.ucr.edu wrote:
+
+> In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
+> +> Were we misled when we were told that C/C++ derives significant speed
+> +> benefits from features like:
+> +
+> + Probably.
+> +
+> +> - unspecified order of evaluation for most operators,
+> +
+> + Can you show a case where this would make a mesurable difference in a
+> + real program?
+
+
+ If you require that order of evaluation be strictly maintained,
+ you give up common subexpression optimization, which is valuable.
AFAIK, those are two distinct notions.
[...]
+> +> - undefined the behavior when, between two sequence points an object
+> +> is modified and accessed for any purpose other than to compute
+> +> the new value,
+
+
+ Is this an issue for multithread programs?
Yes, also for monothreaded ones.
+>
+> +> - not requiring bounds checking for array accesses,
+> +
+> + As has been pointed out, most of the bounds checks are easily optimized
+> + out.
+
+
+ I wouldn't say "easily", having built a program verification
+ system that did things like that. But it's definitely do-able.
+ Any compiler that maintains a flow graph internally could
+ probably add that optimization. As I pointed out in another
+ posting, though, you have to be willing to detect some errors
+ "early".
AFAIK, that conforms.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 10 Jan 03 04:40:28 GMT Raw View
allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0301071936.3c817bb1@posting.google.com>...
> > >> Glen <lpepicel@nycap.rr.com> wrote
> > >> > As far as the C++ programmer's career is concerned embedded
> > >> > devices like cell phones and PDAs are a growth area and these
> > >> > things don't run Java as fast as your 2500 Mhz desktops
> > >> > do... In fact they don't even run C++ apps that fast :)
> kanze@gabi-soft.de (James Kanze) wrote
> > >> That may be because they simulate C++ using a virtual machine
> > >> written in Java:-). Seriously, Java does seem to be trying to
> > >> compete as a language for cell phone software, at least at the
> > >> application level. (And the most frequently used OS for cell
> > >> phones is written in C++ -- some people claim that that is why it
> > >> is so slow.)
> Allan W <allan_w@my-dejanews.com> writes
> > >LOL!
> > >So far, I've never had any of these pleasures:
> Francis Glassborow <francis.glassborow@ntlworld.com> wrote
> > Did you understand the statement? He wrote 'The most frequently used
> > OS for cell phones' that is not synonymous with 'The most frequently
> > used OS for desktops'. It is the later that all your subsequent
> > comments seem to refer.
> Did you read the remark that you quoted above? I was pointing out that
> things that happen on desktops, do NOT seem to happen on cellphones.
As the poster to whom you were replying, I found your reply a pleasantly
humorous way of making the point. I had, in fact, forgotten to put a
simley on the parenthetical remark (although I did once read one person
who claimed this).
As your remarks humorously point out, OS's for cell phones are not
really closely related to the OS's for general computers (which probably
contain significant amounts of C++ as well). As for relative speed,
aside from the fact that I don't really believe that the OS in question
is particularly slow, there are many different ways to slow down a
system, and you can do almost all of them in C++. What is more
relevant, obviously, is that you can also do what you have to to speed
up the system. Or to make it more robust.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: Glen <lpepicel@nycap.rr.com>
Date: 10 Jan 2003 06:23:55 -0500 Raw View
>
As for relative speed,
> aside from the fact that I don't really believe that the OS in question
> is particularly slow, there are many different ways to slow down a
> system, and you can do almost all of them in C++. What is more
> relevant, obviously, is that you can also do what you have to to speed
> up the system. Or to make it more robust.
>
> --
> James Kanze
Yeah. I don't know what this thread is about. their is no question in
my mind the C++ is faster than Java.
I wasn't saying small devices had 'slow' OS though :) I was saying the
small devices are slow themselves... the hardware is slow.
Glen.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: igivanov@yahoo.com (Igor Ivanov)
Date: 10 Jan 2003 06:30:14 -0500 Raw View
thp@cs.ucr.edu wrote in message news:<avdrc8$qf2$1@glue.ucr.edu>...
> In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
[snip]
> Were we misled when we were told that C/C++ derives significant speed
benefits
[snip]
> - not requiring bounds checking for array accesses,
[snip]
IMHO this is one of the most disgusting features of C/C++. I guess
that the time (and money) saved in all programs written in these
languages that ever ran is negligent compared to the time (and money)
lost due to buffer overruns and the like. C-style arrays and strings
are probably hopeless anyway, but the C++ STL is not AFAIK.
Igor
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Fri, 10 Jan 2003 18:51:15 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote in message
news:<3E1DC072.4060407@animats.com>...
> thp@cs.ucr.edu wrote:
> > In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> > >> Were we misled when we were told that C/C++ derives significant
> > >> speed benefits from features like:
> > > Probably.
> > >> - unspecified order of evaluation for most operators,
> > > Can you show a case where this would make a mesurable difference in a
> > > real program?
> If you require that order of evaluation be strictly maintained,
> you give up common subexpression optimization, which is valuable.
Only if the compiler cannot determine that the change is without effects
under the as if rule.
> This is most important when expressions have many function calls, and
> the compiler can't see the function to tell if it has side effects.
> It's an issue in mathematical programming, where "sin", "cos", "sqrt",
> etc. appear in large formulas.
If the common subexpression has calls to a function which the compiler
can't see, the compiler cannot treat it as a common subexpression. Even
with the current freedoms. Since the mathematical functions like sin
are part of the standard, the compiler CAN know about them. I have
actually seen one C compiler that did. It rather seems an exception
however.
(How far should the compiler use this knowledge? If the programmer
writes "sin(x)*sin(x) + cos(x)*cos(x)", should the compiler replace the
expression by 1.0?)
> FORTRAN handles this by building the math functions into the
> language and specifying that they have no side effects and depend only
> on their inputs.
The semantics of the math functions in C and C++ are also defined by the
standard. They may be in the library sub-chapters, but those chapters
are just as much a part of the language definition as the rest.
> C and C++ don't have a way to specify that a function is a "pure
> function" in that sense. They should.
That's another question.
Even an omniscient compiler can't detect this. Functions like acos may
set the global variable errno, which means that they aren't pure
functions, in the mathematical sense, even though we want the compiler
to treat them as such.
> (It's frustrating doing number-crunching in C/C++. Optimization of
> math functions is weak, multidimensional array support is weak,
> temporary array support is weak, and thus "Numerical Recipes in C"
> contains ugly, inefficient code. I'm working on some computer vision
> code today. It's painful.)
> > >> - undefined the behavior when, between two sequence points an
> > >> object is modified and accessed for any purpose other than
> > >> to compute the new value,
> Is this an issue for multithread programs?
Multithreading introduces additional questions. If Posix like
guarantees are assumed (and nothing more), then it really is only
relevant if the expression contains locks (and unlocks).
If the system provides additional operations (like atomic increment),
I'm less sure. I still rather doubt that there would be any cases where
stricter rules would result in slowing down a legal program -- in fact,
without stricter rules, I rather doubt that it is even possible to
correctly use such functions in complex expressions.
> > >> - not requiring bounds checking for array accesses,
> > > As has been pointed out, most of the bounds checks are easily optimized
> > > out.
> I wouldn't say "easily", having built a program verification
> system that did things like that.
Easily is relative:-).
> But it's definitely do-able. Any compiler that maintains a flow graph
> internally could probably add that optimization. As I pointed out in
> another posting, though, you have to be willing to detect some errors
> "early".
Or detect that there is no change in the observable behavior.
This is probably one of the great advantages of having bounds checking
built into the language. The compiler "knows" about the observable
behavior of bounds checking (including that it aborts the program, so
any changes of state in the loop which aren't immediately visible can't
affect any futhre behavoir, since there won't be any).
I'm curious about how Java handles this; the Java benchmarks which equal
or beat C++ all use intensive array operations (in a way which requires
the C++ compiler to take aliasing into account). Formally, Java cannot
hoist the checks, because the error is an exception, which can be
caught, and the code which catches it (or code that executes later) can
see just how far you got in the loop. I suspect that it uses a variant
of my two loop strategy -- due to just in time compiling, it doesn't
have to actually generate the second, error checking variant of the loop
unless it is needed.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: KIM Seungbeom <musiphil@bawi.org>
Date: 11 Jan 03 03:10:50 GMT Raw View
Igor Ivanov wrote:
>
> thp@cs.ucr.edu wrote in message news:<avdrc8$qf2$1@glue.ucr.edu>...
> > In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> [snip]
> > Were we misled when we were told that C/C++ derives significant
speed
> benefits
> [snip]
> > - not requiring bounds checking for array accesses,
> [snip]
>
> IMHO this is one of the most disgusting features of C/C++. I guess
> that the time (and money) saved in all programs written in these
> languages that ever ran is negligent compared to the time (and money)
> lost due to buffer overruns and the like. C-style arrays and strings
> are probably hopeless anyway, but the C++ STL is not AFAIK.
You can use an implementation with debug support (such as STLport),
can't you?
--
KIM Seungbeom <musiphil@bawi.org>
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 10 Jan 2003 23:02:07 -0500 Raw View
thp@cs.ucr.edu wrote in message news:<avinsu$gji$1@glue.ucr.edu>...
> >> - not requiring stack-overflow checking.
> > All of the C++ implementations I currently use do have
> > stack-overflow checking. Implemented by a combination of hardware
> > and the OS, so the runtime cost is effectively zero. (This WOULD be
> > an expensive requirement for more primative machines, without memory
> > mapping or protected pages. Since C++ targets such machines as
> > well, this probably should be left undefined behavior, with quality
> > of implementation issues ensuring that it is present when the
> > run-time cost is reasonable.)
> Amidst the overhead of a function call, how significant is a check for
> stack overflow, especially when inlining and tailcall optimization are
> available?
Typically, on the small processors where stack overflow isn't
automatically checked by hardware, you don't get extensive optimization
either. And you tend to have some pretty small functions at times. It
could make a difference.
In practice, the last time I didn't have stack overflow checking was
well over ten years ago (Zortec C++ under MS-DOS 3.1). Since it seems
to be present where ever reasonable, why insist?
> +> - etc.
> + Never seen any speedup due to etc. either:-).
> Okay, so if those very significant pitfalls don't offer speed
> advantages, why are they still in the language?
Don't ask me. Historical reasons, I suppose.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: loic.actarus.joly@wanadoo.fr (=?ISO-8859-1?Q?Lo=EFc_Joly?=)
Date: Sat, 11 Jan 2003 08:02:06 +0000 (UTC) Raw View
James Kanze wrote:
> (How far should the compiler use this knowledge? If the programmer
> writes "sin(x)*sin(x) + cos(x)*cos(x)", should the compiler replace the
> expression by 1.0?)
I do not think it could do so. In mathematics, "sin(x)*sin(x) +=20
cos(x)*cos(x)" is equal to one, but in computer science, with floating=20
point calculations, I am not sure it is still the case.
--=20
Lo=EFc
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: hyrosen@mail.com (Hyman Rosen)
Date: Sat, 11 Jan 2003 17:23:08 +0000 (UTC) Raw View
John Nagle wrote:
> If you require that order of evaluation be strictly maintained,
> you give up common subexpression optimization
No such thing. All these requirements are as-if, so you could still
optimize anything you want, as long as you are not removing visible
side-effects.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.@@xmission.dot.com (llewelly)
Date: Thu, 9 Jan 2003 05:10:12 +0000 (UTC) Raw View
allan_w@my-dejanews.com (Allan W) writes:
> > > kon@iki.fi (Kalle Olavi Niemitalo) wrote
> > > > If an exception ever propagates to a part that was compiled
> > > > without exception support, then the program will terminate().
>
> > allan_w@my-dejanews.com (Allan W) writes:
> > > I think this pretty much removes any "optimization" you would have
> > > had by turning off exceptions in the first place. When code compiled
> > > with #exceptions=no makes a function call, it must check on return
> > > to see if an exception has been thrown. This turns code like this:
> > >
> > > if (foo()) bar();
> > >
> > > into code like this:
> > >
> > > bool temp = foo();
> > > if (exception_has_been_thrown()) terminate();
> > > if (temp) {
> > > bar();
> > > if (exception_has_been_thrown()) terminate();
> > > }
> > > Which probably isn't much different than the code that would have
> > > been generated without #exception=no.
>
> llewelly.@@xmission.dot.com (llewelly) wrote
> > Not for a range-table implementation. When stack unwinding reaches a
> > frame compiled with #exception=no, no entry for that form will be
> > found in the range-table. Having found no entry, the stack unwind
> > code calls terminate(). The #exception=no code thus requires no
> > such overhead.
>
> How does it "know" that it's reached such a section? It has to be
> marked somewhere... Think about it.
[snip]
At the time I wrote the above, I thought every scope compiled
with #exception=yes would have an entry in the range
table. Therefor, any stack frame which contained a return address
not found in the range table would have to correltate with a scope
compiled with #exception=no. This scheme would work, and would
require no overhead for scopes compiled with #exception=no.
However - it would prevent, or at least reduce the effectiveness of a
space optimization: if a scope has no catch blocks, and no
non-trivial destructors, it doesn't need an entry in the range
table, under current semantics. (I believe at least one compiler
already does this optimization.) With the #exceptions feature,
those scopes would need range-table entries, in order to
distinguish them from scopes compiled with #exceptions=no.
The ifs you imply overhead, however, are not necessary.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: schnitker@sigma-c.com (Uwe Schnitker)
Date: 09 Jan 03 14:12:42 GMT Raw View
kanze@gabi-soft.de (James Kanze) wrote in message news:<d6651fb6.0301020346.45b60a60@posting.google.com>...
> Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
> news:<fCDW22S7qKE+EwDj@robinton.demon.co.uk>...
> > In message <d6651fb6.0212300235.6f30cea2@posting.google.com>, James
> > Kanze <kanze@gabi-soft.de> writes
>
> > >In what applications. I've done benchmarks where Java was faster
> > >than C++. I've also done benchmarks where the reverse was true. And
> > >I've seen more than a few cases where the results depend on the
> > >platform.
>
> > You are not comparing languages but implementations. Worse, you are
> > comparing implementations in the context of a particular task.
>
> Obviously. What else can you compare? (I might also add: what else is
> interesting? When I program, I use an implementation in the context of
> a particular task -- not some abstract language.)
>
> > I think the whole issue of which language is faster is a futile one.
>
> Totally agreed. My only point is that people just screeming out that
> Java is slower don't really know what they are talking about. Some
> implementations of Java may be slower than some other implementation of
> C++ for some specific tasks. If performance is a critical point, you
> run *your* benchmarks which test for *your* particular task on the
> implementations which *you* will have to use.
There is an important difference, IMHO:
With C++, the programmer - or her PHB :-( - has control over most of
the implementation (Compiler, Libraries) used, with Java the user -
or his PHB :-( - chooses the (or just uses the default-installed) JVM.
This is not important when programming custom software for a client,
because then both PHB's are the same person, but it makes a huge
difference with shrink-wrap software. The mere existance of an
implementation which would execute the Java code faster doesn't
mean most - or even any - of your customers will use that
implementation. And suggesting your customers to install and
configure dozens of JVM to be able to run several different
applications with acceptable performance might be futile.
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: thp@cs.ucr.edu
Date: 09 Jan 03 14:13:16 GMT Raw View
In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
+ thp@cs.ucr.edu wrote in message news:<avdrc8$qf2$1@glue.ucr.edu>...
+> In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
+> [...]
+> + My only point is that people just screeming out that
+> + Java is slower don't really know what they are talking about.
+
+> Were we misled when we were told that C/C++ derives significant speed
+> benefits from features like:
+
+ Probably.
+
+> - unspecified order of evaluation for most operators,
+
+ Can you show a case where this would make a mesurable difference in a
+ real program? (I know that David Chase asked the question many years
+ back, and got no real concrete answer. And compiler technology has
+ improved since then.)
No.
+> - undefined the behavior when, between two sequence points an object
+> is modified and accessed for any purpose other than to compute
+> the new value,
+
+ Ditto.
No.
+> - not requiring bounds checking for array accesses,
+
+ As has been pointed out, most of the bounds checks are easily optimized
+ out.
+
+ It's interesting to note that the benchmarks where Java does best
+ against C++ generally involve intensive array use. Apparently, bounds
+ checking (correctly optimized) costs less than what is lost due to
+ potential aliasing.
Interesting indeed.
+> - not requiring stack-overflow checking.
+
+ All of the C++ implementations I currently use do have stack-overflow
+ checking. Implemented by a combination of hardware and the OS, so the
+ runtime cost is effectively zero. (This WOULD be an expensive
+ requirement for more primative machines, without memory mapping or
+ protected pages. Since C++ targets such machines as well, this probably
+ should be left undefined behavior, with quality of implementation issues
+ ensuring that it is present when the run-time cost is reasonable.)
Amidst the overhead of a function call, how significant is a check for
stack overflow, especially when inlining and tailcall optimization are
available?
+> - etc.
+
+ Never seen any speedup due to etc. either:-).
Okay, so if those very significant pitfalls don't offer speed
advantages, why are they still in the language?
Tom Payne
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: nagle@animats.com (John Nagle)
Date: Thu, 9 Jan 2003 18:42:38 +0000 (UTC) Raw View
thp@cs.ucr.edu wrote:
> In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> +> Were we misled when we were told that C/C++ derives significant speed
> +> benefits from features like:
> +
> + Probably.
> +
> +> - unspecified order of evaluation for most operators,
> +
> + Can you show a case where this would make a mesurable difference in a
> + real program?
If you require that order of evaluation be strictly maintained,
you give up common subexpression optimization, which is valuable.
This is most important when expressions have many function calls,
and the compiler can't see the function to tell if it has side
effects. It's an issue in mathematical programming, where
"sin", "cos", "sqrt", etc. appear in large formulas.
FORTRAN handles this by building the math functions into the
language and specifying that they have no side effects and
depend only on their inputs. C and C++ don't have a way to
specify that a function is a "pure function" in that sense.
They should. (It's frustrating doing number-crunching in
C/C++. Optimization of math functions is weak, multidimensional
array support is weak, temporary array support is weak,
and thus "Numerical Recipes in C" contains ugly, inefficient
code. I'm working on some computer vision code today.
It's painful.)
>
> +> - undefined the behavior when, between two sequence points an object
> +> is modified and accessed for any purpose other than to compute
> +> the new value,
Is this an issue for multithread programs?
>
> +> - not requiring bounds checking for array accesses,
> +
> + As has been pointed out, most of the bounds checks are easily optimized
> + out.
I wouldn't say "easily", having built a program verification
system that did things like that. But it's definitely do-able.
Any compiler that maintains a flow graph internally could
probably add that optimization. As I pointed out in another
posting, though, you have to be willing to detect some errors
"early".
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Thu, 9 Jan 2003 22:30:45 +0000 (UTC) Raw View
Allan W <allan_w@my-dejanews.com> wrote:
+ francis.glassborow@ntlworld.com (Francis Glassborow) wrote
+> Note that I do not think that exceptions are the only tool for handling
+> problems, but I do think it is a valuable one. It might be useful if we
+> had a standard mechanism for turning exception handling off such as:
+>
+> #define NO_EXCEPTIONS
+>
+> Together with agreed consequences of that (for example that catch
+> clauses become no-ops)
+
+ Might be nice to have a standard way to do this (as opposed to assuming
+ that "most" compilers will have compiler switches for it). It wouldn't
+ be a macro, though, and not a #pragma either. (Both of these are
+ currently within either the user's or the implementation's perogative to
+ mean something else.) Perhaps some new type of directive, as in
+ #exceptions=no
If such a feature were added, it would be handy to be able to invoke
it from the command line as well, so that it could be used without
editing source files, e.g., when compile a C program with a C++
compiler. AFAIK, however, there is no concept of command line or
flags that is recognized by the Standard.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Wed, 8 Jan 2003 00:50:44 +0000 (UTC) Raw View
> > kon@iki.fi (Kalle Olavi Niemitalo) wrote
> > > If an exception ever propagates to a part that was compiled
> > > without exception support, then the program will terminate().
> allan_w@my-dejanews.com (Allan W) writes:
> > I think this pretty much removes any "optimization" you would have
> > had by turning off exceptions in the first place. When code compiled
> > with #exceptions=no makes a function call, it must check on return
> > to see if an exception has been thrown. This turns code like this:
> >
> > if (foo()) bar();
> >
> > into code like this:
> >
> > bool temp = foo();
> > if (exception_has_been_thrown()) terminate();
> > if (temp) {
> > bar();
> > if (exception_has_been_thrown()) terminate();
> > }
> > Which probably isn't much different than the code that would have
> > been generated without #exception=no.
llewelly.@@xmission.dot.com (llewelly) wrote
> Not for a range-table implementation. When stack unwinding reaches a
> frame compiled with #exception=no, no entry for that form will be
> found in the range-table. Having found no entry, the stack unwind
> code calls terminate(). The #exception=no code thus requires no
> such overhead.
How does it "know" that it's reached such a section? It has to be
marked somewhere... Think about it.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Charles Calvert <cbciv@yahoo.com>
Date: 08 Jan 03 04:05:06 GMT Raw View
On 4 Jan 2003 16:06:45 -0500, kanze@gabi-soft.de (James Kanze) wrote
in <d6651fb6.0301020346.45b60a60@posting.google.com>:
[snip]
>Bad programmers tend to move to the latest fad. Today, I expect most
of
>them are working on Web applications in Java (although from my
>experience with the pages I've visited, ASP seems to have even worse
>programmers -- I don't know what language is behind it).
VBScript, which explains a lot.
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Wed, 8 Jan 2003 05:15:48 +0000 (UTC) Raw View
pjp@dinkumware.com ("P.J. Plauger") wrote
> ...there are still plenty of compilers that
> *do* generate smaller executables when you explicitly disable exception
> handling. Lucky for us, those compiler writers are still too lazy to
> do all the optimizations they should.
> ===================================== MODERATOR'S COMMENT:
> This is almost a flame, but I seem to detect the tongue-in-cheek.
> ===================================== END OF MODERATOR'S COMMENT
I don't think it's either tongue-in-cheek, or a flame. I think it's
factual.
There certainly are compilers that let you disable exception handling
manually, but don't do it automatically. Is this lucky for Dinkumware?
Perhaps that was the tongue-in-cheek part, but I suspect there's at
least a grain of truth in it...
At any rate, making statements that are entirely true but obvious,
should not be considered "flaming." It's certainly true that some
compilers have room for more optimizations. It's probably even true
that ALL compilers have room for more optimizations.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 8 Jan 2003 05:36:10 -0500 Raw View
> >> Glen <lpepicel@nycap.rr.com> wrote
> >> > As far as the C++ programmer's career is concerned embedded devices
> >> > like cell phones and PDAs are a growth area and these things don't
> >> > run Java as fast as your 2500 Mhz desktops do... In fact they don't
> >> > even run C++ apps that fast :)
> >kanze@gabi-soft.de (James Kanze) wrote
> >> That may be because they simulate C++ using a virtual machine written
> >> in Java:-). Seriously, Java does seem to be trying to compete as a
> >> language for cell phone software, at least at the application level.
> >> (And the most frequently used OS for cell phones is written in C++ --
> >> some people claim that that is why it is so slow.)
> Allan W <allan_w@my-dejanews.com> writes
> >LOL!
> >
> >So far, I've never had any of these pleasures:
Francis Glassborow <francis.glassborow@ntlworld.com> wrote
> Did you understand the statement? He wrote 'The most frequently used OS
> for cell phones' that is not synonymous with 'The most frequently used
> OS for desktops'. It is the later that all your subsequent comments seem
> to refer.
Did you read the remark that you quoted above? I was pointing out that
things that happen on desktops, do NOT seem to happen on cellphones.
I'll say it another way, without ANY attempt at humor:
The most-frequently-used OS for cellphones was written in C++; the
most-frequently-used OS for desktops was not. Cellphones tend to be
reliable, and the speed tends to be predictable; desktops tend to
crash fairly often, and sometimes they slow down for no apparent reason.
If the only factor that affected a system's speed and reliability
was the language used to program it, then I would have to conclude
that cellphones demonstrate the superiority of C++. (It isn't, so
it doesn't...)
I'll apologize for offending you, if/when I understand how I did. I
respect you and generally agree with you... these comments startle me.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 8 Jan 2003 05:36:51 -0500 Raw View
Thomas Mang <a9804814@unet.univie.ac.at> wrote
> Bob Hairgrove schrieb:
>
> > On 30 Dec 02 18:49:12 GMT, Thomas Mang <a9804814@unet.univie.ac.at>
> > wrote:
> >
> > [snip...]
> >
> > >E.g. a compiler switch to determine wether calls to
> > >delete / delete [] will have the current semantic, or will
> > >have equal semantic (runtime-checking will determine if an
> > >array or a single object gets deleted). It's not uncommon to
> > >see 'delete' called for arrays, either because the programmer
> > >didn't know it was an array, or because he just forgot the
> > >'[]' tokens.
> > >
> > >With such a compiler swith, the performance gurus get what
> > >they currently get (in practice: marginally faster code, but
> > >occasionally simply wrong delete called), and the qualitiy
> > >gurus could get a safe-call to delete, at the cost of very
> > >slightly degraded performance.
> > >Both parties have enough fans to justify such a switch.
> >
> > This would have to be resolved at compile time, not runtime (i.e.
> > delete vs. delete[] ... oder??...)
>
> No, not at compile-time (how should it?).
>
> code wouldn't be affected; e.g. you write 'delete' for deleting a
> single element, and 'delete []' for an array. Without the switch off
> (default), the compilers takes this as is. With the switch on, the
> compiler inserts code such as:
>
> if (__IsArray)
> delete [] x
> else
> delete x
>
> where __IsArray is a simple implementation-dependent mechanism to
> find out wether the heap-allocated memory was acquired using new[]
> or new (A single bit just preceding the pointer value would
> suffice - in practice it'd certainly a bit more [literally, some
> bits more.....]).
>
> I wonder how much ill-formed programs this would fix (during run-time).
If we made substance abuse legal, how much would crime drop?
If you suggest this as a compiler-extension, it sounds like a decent
idea. (It would have the added "advantage" from a sales point of
view, of keeping your customers captive -- they couldn't easily port
to some other compiler without fixing the code.)
If you suggest this as a language extension -- "Compilers must be
able to make delete[] and delete act the same way, automatically
handling both single-element and array allocations" -- this is a
bad idea. It essentially forces compilers to cater to people that
commonly make this mistake. In other words, your "performance gurus"
would lose to your "quality gurus".
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thomas.hyer@ubsw.com (Tom Hyer)
Date: 8 Jan 2003 13:17:13 -0500 Raw View
thp@cs.ucr.edu wrote in message news:<avdrc8$qf2$1@glue.ucr.edu>...
> In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> [...]
> + My only point is that people just screeming out that
> + Java is slower don't really know what they are talking about.
>
> Were we misled when we were told that C/C++ derives significant speed
> benefits from features like:
> - unspecified order of evaluation for most operators,
> - undefined the behavior when, between two sequence points an object
> is modified and accessed for any purpose other than to compute
> the new value,
> - not requiring bounds checking for array accesses,
> - not requiring stack-overflow checking.
> - etc.
>
> Tom Payne
>
Received wisdom in the LISP community is that LISP is "1.5 to 2 times
slower" than C. I don't have much LISP skill, but in the (highly
numerical) testbeds I have written this seems more like a factor of 5.
I was under pressure to write Java at a previous job, so I cooked up a
test suite (random generation and Cholesky decomposition) and it was
2.5 to 3 times slower than C++. This was a couple years ago, but
there is reason to believe the situation has not really changed. See:
http://www.coyotegulch.com/reviews/almabench.html
Doug Bagley has put together a large series of different tests at
http://www.bagley.org/~doug/shootout. I think some of the tests are
unrealistically small, but they have to be for the Python and Ruby
versions to run at all. For larger and more numerical tasks, you
really want to trade safety for speed.
-- Tom Hyer
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 8 Jan 2003 14:16:36 -0500 Raw View
thp@cs.ucr.edu wrote in message news:<avdrc8$qf2$1@glue.ucr.edu>...
> In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
> [...]
> + My only point is that people just screeming out that
> + Java is slower don't really know what they are talking about.
> Were we misled when we were told that C/C++ derives significant speed
> benefits from features like:
Probably.
> - unspecified order of evaluation for most operators,
Can you show a case where this would make a mesurable difference in a
real program? (I know that David Chase asked the question many years
back, and got no real concrete answer. And compiler technology has
improved since then.)
> - undefined the behavior when, between two sequence points an object
> is modified and accessed for any purpose other than to compute
> the new value,
Ditto.
> - not requiring bounds checking for array accesses,
As has been pointed out, most of the bounds checks are easily optimized
out.
It's interesting to note that the benchmarks where Java does best
against C++ generally involve intensive array use. Apparently, bounds
checking (correctly optimized) costs less than what is lost due to
potential aliasing.
> - not requiring stack-overflow checking.
All of the C++ implementations I currently use do have stack-overflow
checking. Implemented by a combination of hardware and the OS, so the
runtime cost is effectively zero. (This WOULD be an expensive
requirement for more primative machines, without memory mapping or
protected pages. Since C++ targets such machines as well, this probably
should be left undefined behavior, with quality of implementation issues
ensuring that it is present when the run-time cost is reasonable.)
> - etc.
Never seen any speedup due to etc. either:-).
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Wed, 8 Jan 2003 20:33:42 +0000 (UTC) Raw View
Allan W <allan_w@my-dejanews.com> wrote:
+ pjp@dinkumware.com ("P.J. Plauger") wrote
+> ...there are still plenty of compilers that
+> *do* generate smaller executables when you explicitly disable exception
+> handling. Lucky for us, those compiler writers are still too lazy to
+> do all the optimizations they should.
+
+> ===================================== MODERATOR'S COMMENT:
+> This is almost a flame, but I seem to detect the tongue-in-cheek.
+> ===================================== END OF MODERATOR'S COMMENT
+
+ I don't think it's either tongue-in-cheek, or a flame. I think it's
+ factual.
Agreed.
+ There certainly are compilers that let you disable exception handling
+ manually, but don't do it automatically. Is this lucky for Dinkumware?
+ Perhaps that was the tongue-in-cheek part, but I suspect there's at
+ least a grain of truth in it...
Agreed.
+ At any rate, making statements that are entirely true but obvious,
+ should not be considered "flaming." It's certainly true that some
+ compilers have room for more optimizations. It's probably even true
+ that ALL compilers have room for more optimizations.
Agreed: Dinkumware makes money on their exceptionless libraries
because code bloat can be avoided under plenty of C++ compilers by
disabling exception handling.
So, why can't code bloat similarly be avoided when compiling C code
under such C++ compilers?
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: brangdon@cix.co.uk (Dave Harris)
Date: 5 Jan 2003 11:25:43 -0500 Raw View
a9804814@unet.univie.ac.at (Thomas Mang) wrote (abridged):
> E.g. a compiler switch to determine wether calls to delete / delete []
> will have the current semantic, or will have equal semantic
> (runtime-checking will determine if an array or a single object
> gets deleted).
If you actually want this, you can simply replace new with new[] and
delete with delete[] everywhere.
> With such a compiler swith, the performance gurus get what they
> currently get (in practice: marginally faster code
And smaller memory allocations. There is no need to store a count for
single-object new. Nor even a 1-bit flag, which probably needs a whole
word anyway.
> Both parties have enough fans to justify such a switch.
Although then we'd have two different languages. However, it would be
reasonable for an implementation to throw an exception, or abort, if the
delete didn't match the new.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
brangdon@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Neil Butterworth" <neil_butterworth@lineone.net>
Date: 5 Jan 2003 11:27:18 -0500 Raw View
"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0301020346.45b60a60@posting.google.com...
> And how do you compute the average? The only real application I know of
> in Pascal that is still being used is TeX, and that was written by
> Knuth. If Knuth is the only programmer around still using Pascal (not
> unlikely, IMHO), then its going to be pretty hard for any language to be
> the average competence of Pascal programmers:-).
Lots of programmers are still using Pascal, in the shape of Borland's Delphi
product.
NeilB
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Mon, 6 Jan 2003 00:40:24 +0000 (UTC) Raw View
James Kanze <kanze@gabi-soft.de> wrote:
+ already5chosen@yahoo.com (Michael S) wrote in message
+ news:<f881b862.0212230642.76ca81f9@posting.google.com>...
+> nagle@animats.com (John Nagle) wrote in message
+> news:<3E03F52A.7050406@animats.com>...
+
+> Agreed, 100%.
+
+> See my thread "Three features you would like to have not in C++"
+> (relegated to the second page now) for more of the same. There were
+> 50+ answers criticizing my "top three" but amazingly nobody posted
+> three undesired features of his own.
+
+ Fergus Henderson did. His top choice was undefined behavior.
+
+ It also has the advantage that in removing undefined behavior (by
+ defining it), you can't possibly break existing code.
Hmmmmm. In principle at least, it could break code that conforms to
existing extensions of C/C++, e.g., POSIX or GCC, and could perhaps
preclude future some extensions. That said, however, I agree that C
and C++ have way too much undefined behavior for my taste. Perhaps
there could be a special modes or implemenation category where
implementations are required throw special exceptions when null
pointers are dereferenced, stacks overflow, array indices go out of
bounds, etc.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: scottm@toast.net ("Scott Mayo")
Date: Mon, 6 Jan 2003 04:17:02 +0000 (UTC) Raw View
<thp@cs.ucr.edu> wrote in message news:avafqm$dcv$3@glue.ucr.edu...
> James Kanze <kanze@gabi-soft.de> wrote:
> + already5chosen@yahoo.com (Michael S) wrote in message
> + news:<f881b862.0212230642.76ca81f9@posting.google.com>...
> +> nagle@animats.com (John Nagle) wrote in message
> +> news:<3E03F52A.7050406@animats.com>...
> +
> +> Agreed, 100%.
> +
> +> See my thread "Three features you would like to have not in C++"
> +> (relegated to the second page now) for more of the same. There were
> +> 50+ answers criticizing my "top three" but amazingly nobody posted
> +> three undesired features of his own.
> +
> + Fergus Henderson did. His top choice was undefined behavior.
> +
> + It also has the advantage that in removing undefined behavior (by
> + defining it), you can't possibly break existing code.
>
> Hmmmmm. In principle at least, it could break code that conforms to
> existing extensions of C/C++, e.g., POSIX or GCC, and could perhaps
> preclude future some extensions. That said, however, I agree that C
> and C++ have way too much undefined behavior for my taste. Perhaps
> there could be a special modes or implemenation category where
> implementations are required throw special exceptions when null
> pointers are dereferenced, stacks overflow, array indices go out of
> bounds, etc.
That would be an interesting language, but it wouldn't be C, and it
probably wouldn't be C++. Not all hardware traps NULL pointer
dereference, some might not even trap stack overflow, and array
indicies checks require fat pointers, as has been described elsewhere.
Since C more or less guarantees that pointers will be the machine
equivalent of an address(*) and
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: scottm@toast.net ("Scott Mayo")
Date: Mon, 6 Jan 2003 19:51:50 +0000 (UTC) Raw View
""Scott Mayo"" <scottm@toast.net>:
> <thp@cs.ucr.edu>:
> > Hmmmmm. In principle at least, it could break code that conforms to
> > existing extensions of C/C++, e.g., POSIX or GCC, and could perhaps
> > preclude future some extensions. That said, however, I agree that C
> > and C++ have way too much undefined behavior for my taste. Perhaps
> > there could be a special modes or implemenation category where
> > implementations are required throw special exceptions when null
> > pointers are dereferenced, stacks overflow, array indices go out of
> > bounds, etc.
> That would be an interesting language, but it wouldn't be C, and it
> probably wouldn't be C++. Not all hardware traps NULL pointer
> dereference, some might not even trap stack overflow, and array
> indicies checks require fat pointers, as has been described elsewhere.
> Since C more or less guarantees that pointers will be the machine
> equivalent of an address(*) and
Hm. Moderation doesn't save us from incomplete posts, that's for sure.
I tell you, we need stricter compile time checking on these things...
Anyway, the point was that C at least promises to stay close to the
hardware, and most of what you want takes a language very far
from the hardware indeed. A compile time flag to add more checks
isn't a bad thing, but the resulting language wouldn't interoperate
very well with C, which *knows* that "pointers are addresses" and
"arrays are fast".
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: 07 Jan 03 13:12:05 GMT Raw View
In comp.std.c++ James Kanze <kanze@gabi-soft.de> wrote:
[...]
+ My only point is that people just screeming out that
+ Java is slower don't really know what they are talking about.
Were we misled when we were told that C/C++ derives significant speed
benefits from features like:
- unspecified order of evaluation for most operators,
- undefined the behavior when, between two sequence points an object
is modified and accessed for any purpose other than to compute
the new value,
- not requiring bounds checking for array accesses,
- not requiring stack-overflow checking.
- etc.
Tom Payne
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: llewelly.@@xmission.dot.com (llewelly)
Date: Sat, 4 Jan 2003 09:22:58 +0000 (UTC) Raw View
thp@cs.ucr.edu writes:
[snip]
> I don't see any enabling of shadow stacks.
[gcc -v output snipped]
I don't either.
>
> +> I realize that this naive test doesn't prove anything, but I would
> +> normally expect EH logic, e.g., range tables, to grow with program
> +> size,
> + [snip]
> +
> + I believe that is an oversimplification. As I remember the range-table
> + implementation, the size of the range-tables will be proportional
> + to the number of scopes which require cleanup action (non-trivial
> + destructors, and catch() blocks). (Plus the ever-present small
> + constant). Compiling a C program as C++ with exceptions will not
> + show you the true cost of the range table.
>
> That's my point. I don't think that compiling C programs with C++
> compilers needs to bloat or slow the code, except perhaps for the
> "ever-present small constant".
[snip]
Then we agree, as far as compiling C programs with C++ compilers
goes. However, for C++ programs which do not need exceptions, I
think disabling them is useful in certain situations.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Francis Glassborow <francis.glassborow@ntlworld.com>
Date: 04 Jan 03 14:35:00 GMT Raw View
In article <7f2735a5.0212301510.40d40ca0@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>kanze@gabi-soft.de (James Kanze) wrote
>> Glen <lpepicel@nycap.rr.com> wrote
>> > As far as the C++ programmer's career is concerned embedded devices
>> > like cell phones and PDAs are a growth area and these things don't
run
>> > Java as fast as your 2500 Mhz desktops do... In fact they don't
even
>> > run C++ apps that fast :)
>>
>> That may be because they simulate C++ using a virtual machine written
in
>> Java:-). Seriously, Java does seem to be trying to compete as a
>> language for cell phone software, at least at the application level.
>> (And the most frequently used OS for cell phones is written in C++ --
>> some people claim that that is why it is so slow.)
>
>LOL!
>
>So far, I've never had any of these pleasures:
Did you understand the statement? He wrote 'The most frequently used OS
for cell phones' that is not synonymous with 'The most frequently used
OS for desktops'. It is the later that all your subsequent comments seem
to refer.
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: Thomas Mang <a9804814@unet.univie.ac.at>
Date: 04 Jan 03 14:44:11 GMT Raw View
Bob Hairgrove schrieb:
> On 30 Dec 02 18:49:12 GMT, Thomas Mang <a9804814@unet.univie.ac.at>
> wrote:
>
> [snip...]
>
> >E.g. a compiler switch to determine wether calls to delete / delete [] will
> >have the current semantic, or will have equal semantic (runtime-checking will
> >determine if an array or a single object gets deleted). It's not uncommon to
> >see 'delete' called for arrays, either because the programmer didn't know it
> >was an array, or because he just forgot the '[]' tokens.
> >
> >With such a compiler swith, the performance gurus get what they currently get
> >(in practice: marginally faster code, but occasionally simply wrong delete
> >called), and the qualitiy gurus could get a safe-call to delete, at the cost
> >of very slightly degraded performance.
> >Both parties have enough fans to justify such a switch.
>
> This would have to be resolved at compile time, not runtime (i.e.
> delete vs. delete[] ... oder??...)
No, not at compile-time (how should it?).
code wouldn't be affected; e.g. you write 'delete' for deleting a single element,
and 'delete []' for an array. Without the switch off (default), the compilers
takes this as is. With the switch on, the compiler inserts code such as:
if (__IsArray)
delete [] x
else
delete x
where __IsArray is a simple implementation-dependent mechanism to find out wether
the heap-allocated memory was acquired using new[] or new (A single bit just
preceding the pointer value would suffice - in practice it'd certainly a bit more
[literally, some bits more.....]).
I wonder how much ill-formed programs this would fix (during run-time).
best regards,
Thomas
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: drpizza@anti-flash.co.uk ("DrPizza")
Date: Sat, 4 Jan 2003 20:00:35 +0000 (UTC) Raw View
""Andrei Alexandrescu"" <andrewalex@hotmail.com> wrote in message
news:av4vlg$bu3r3$1@ID-14036.news.dfncis.de...
> ""DrPizza"" <drpizza@anti-flash.co.uk> wrote in message
> news:auk47e$poa$1@venus.btinternet.com...
> > "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> > news:rOGblzF4vzB+Ewd+@robinton.demon.co.uk...
> > > no vector<bool> specialisation.
> > Rename it bit_vector or similar, and let vector<bool> be a proper
> > container/sequence. If people really need the space/speed trade-off that
> the
> > packed vector<bool> currently requires, let them type bit_vector.
> >
> > > remove auto_ptr and replace with a well considered set of smart
> pointers
> > I think that a well-considered set of smart pointers is required, but
> that
> > auto_ptr should remain as one of those smart pointers. Its name is a bit
> > objectionable, I suppose. But it's not really worth removing.
>
> Better yet, replace them with one policy-based smart pointer, and make
> auto_ptr behavior one of the default-provided policies.
The only problem is that this requires a new language feature (template
typedefs), rather than being a pure library solution, though I would certainly
like to have template typedefs (though I think that they should remain
syntactic short-hand, not introduce new types, just like non-template
typedefs).
--
Now Playing: Cosmicman - Krystal Dreams
char a[99999],*p=a;main(int c,char**V){char* v=c>0?1[V]:V;if(c<0)for(c=1;c;c
+=!(91^*v)-!(93^*v),++v);else for(;(c=*v)&&93^c;p+=!(62^c)-!(60^c),*p+=!(43^
c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p),91^c||(v=*p?main(0,++v),v-2:\
main(-1,++v)-1),++v);return v;}/*bf prog as argv[1]. drpizza@battleaxe.net*/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 4 Jan 2003 16:06:45 -0500 Raw View
Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:<fCDW22S7qKE+EwDj@robinton.demon.co.uk>...
> In message <d6651fb6.0212300235.6f30cea2@posting.google.com>, James
> Kanze <kanze@gabi-soft.de> writes
> >In what applications. I've done benchmarks where Java was faster
> >than C++. I've also done benchmarks where the reverse was true. And
> >I've seen more than a few cases where the results depend on the
> >platform.
> You are not comparing languages but implementations. Worse, you are
> comparing implementations in the context of a particular task.
Obviously. What else can you compare? (I might also add: what else is
interesting? When I program, I use an implementation in the context of
a particular task -- not some abstract language.)
> I think the whole issue of which language is faster is a futile one.
Totally agreed. My only point is that people just screeming out that
Java is slower don't really know what they are talking about. Some
implementations of Java may be slower than some other implementation of
C++ for some specific tasks. If performance is a critical point, you
run *your* benchmarks which test for *your* particular task on the
implementations which *you* will have to use. You ignore blanket
statements which really don't mean anything. And you weigh the
performance issues against other aspects: if software reliability is
important, for example, Java is probably excluded before you start --
even if for your particular case, it would be a lot faster.
> Let us have a new argument as to which language has the better
> programmers. I guess something like 8051 assembler probably wins that
> as bad programmers keep away from getting quite so close to the metal
> :-)
Bad programmers tend to move to the latest fad. Today, I expect most of
them are working on Web applications in Java (although from my
experience with the pages I've visited, ASP seems to have even worse
programmers -- I don't know what language is behind it). Not so many
years ago, the latest fad was C++, and some of those programmers may
have gotten stuck in it, so I doubt that we have the best. On the
average, of course -- there are some remarkably good C++ programmers out
there (and some good Java programmers as well).
At the other extreme, the really gifted programmer is likely to know
quite a few languages, and to be drawn to the exotic. So for the
overall better programmers, I'd look to something like Haskel, Modula-3
or some other language with very little actual use.
And how do you compute the average? The only real application I know of
in Pascal that is still being used is TeX, and that was written by
Knuth. If Knuth is the only programmer around still using Pascal (not
unlikely, IMHO), then its going to be pretty hard for any language to be
the average competence of Pascal programmers:-).
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Thomas Mang <a9804814@unet.univie.ac.at>
Date: 05 Jan 03 02:20:37 GMT Raw View
Allan W schrieb:
[snip]
>
> This "advice" might make sense in a very few, very limited situations.
> (I can't think of one offhand.) If the program has to instantiate a
few
> million objects, or if it has to run for a very long time (or even for
> a few hours), this is folly.
>
> Who advocates such a position? Please tell me it isn't any sort of
teacher!
No, fortunately!
[snip]
>
> > C++ is IMHO not one of those "easy" languages, because you can get
quiet
> > easily things wrong without even knowing just having entered
undefined
> > territory.
>
> Expertise will always require experience, which requires time. But I
think
> that most of the problems that inexperienced programmers will run
into,
> come with the problem domain rather than the language itself. For
instance,
> nothing in C++ causes one-off errors to become more common or severe
than
> in any other language.
>
> For the few common errors that are C++-specific, I think that most of
> them are well-known and a very little education can help prevent them.
> (Similar statements would be true of any language.) An example is
> using a single equals sign for equivalence comparisons:
> bool a = (b=c); // Oops! Meant (b==c)!
> This particular problem is made much worse by the fact that so many
> other languages use = for comparison, and still other languages (those
> with "assignment statements") overload the same syntax for both
> purposes. It has the effect of making the assignment "look natural"
> especially for multi-lingual programmers.
this assignment/equality-check error is probably one of the more
popular, and as a
consequence also quite known
(still it happens).
I find other constructs more dangerous, because they are not that known.
E.g. the comma operator in an expression (arguments are evaluated left
to right) and
function argument passing
(argument evaluation is unspecified).
>
>
> > So other programming languages (Java, Perl..) have, regarding this
issue,
> > these two advantages over C++:
> > a) (usually) writing less code to get a given task done. (-> saves
time ->
> > saves costs)
>
> Can you give an example of some "given task" that (usually) needs
> more code in C++? I've found C++ to be pretty average in this regard,
> especially modern C++ with the STL. By "average" I mean that there are
> a few tasks which typically require more code, and there are others
> that typically require much less.
Sorry, I meant at programming-language level, not considering 3rd-party
libraries.
In Java, you have GUI straightforward. In C++ (at standard-level), you
can try to
program "char-images".
("char-maps" or something like that)
>
> Changing the rules on constructs which frequently cause inadvertent
errors
> is a good idea. Is delete versus delete[] one of those constructs?
>
> Perhaps I'm no longer in a position to answer that, since my designs
> typically make such errors rare. It's natural for me to do so, and I
no
> longer give it much thought. I don't know if this is a natural
evolution
> to take as a software developer, or if it's something I've done when
> dealing with C++ as a defense against this problem...
>
> Still, I'll at least take this position: Changing constructs that are
> frequently misused by accident is a good thing. Changing constructs
> that are frequently misused by carelessness or naive programmers is
> not a good thing. As an example of the latter, it's not all that rare
> for naive programmers to use operator overloading horrendously,
despite
> frequent advice not to. If a naive programmer defines operator+ for
two
> customers (and who knows what it's supposed to accomplish), that
> doesn't mean we shouldn't have operator overloading!
I totally agree, but the question of the day is now:
What errors are due to misuse, carelessness and lazyness, and which are
symptoms of
a confusing language syntax?
I'll be hard to distinguish between them.
BTW, in which category would you put the "remove" of the std-library
algorithms?
I wonder if there's any use (in benign code) of 'remove' without a
subsequent call
to 'erase'.
I do consider this function confusing and a high-candidate source for
trouble,
unless you know about it. Then it's easy to manage.
I can't put even this simple example in one of your two categories.
best regards,
Thomas
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: thp@cs.ucr.edu
Date: Sun, 5 Jan 2003 07:43:09 +0000 (UTC) Raw View
"P.J. Plauger" <pjp@dinkumware.com> wrote:
[...]
+I wrote:
+[...]
+> P.J. Plauger wrote:
+> [...]
+> > Meanwhile, we continue to make money licensing a C++ library that
+> > can avoid all use of exceptions, for those unreconstructed people
+> > who think that might be important.
+>
+> So, why would anyone pay for such a library if EH overhead is incurred
+> even when EH is unused, e.g., when there are no catches and/or throws,
+> as in the case of C programs?
+
+ Gee, I dunno. Except maybe that there are still plenty of compilers that
+ *do* generate smaller executables when you explicitly disable exception
+ handling.
Doesn't that work when compiling C code under those C++ compilers?
I.e., must EH be disabled via source-code directives, or can
command-line flags be used?
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Fri, 3 Jan 2003 07:04:37 +0000 (UTC) Raw View
llewelly <llewelly.@@xmission.dot.com> wrote:
+ thp@cs.ucr.edu writes:
+
+> David Abrahams <dave@boost-consulting.com> wrote:
+> + pjp@dinkumware.com ("P.J. Plauger") writes:
+> +
+> +>> The question is not "whether to use C++" but rather
+> +>> "which, if any, C++ extensions to use". Particularly within the
+> +>> operating-systems community, there is a prevalent opinion that
+> +>> compiling with a C++ compiler will necessarily bloat and slow their
+> +>> code. "Exception handling is turned on whether you use it or not, and
+> +>> surely that has to take up time and space."
+> +>
+> +> Y'know, I still believe that myself to this day.
+> +
+> + And even I, who you might not expect to hear it from, was going to say
+> + that it's true.
+> +
+> +> Perhaps it's because nobody has shown me a compiler that really does
+> +> support exceptions with zero time and space overhead,
+> +
+> + And they never will. Zero time overhead in the non-exceptional case
+> + is possible today, and can be demonstrated it for small programs.
+> + Zero space overhead is not. The logic for EH functionality has to go
+> + somewhere!
+>
+> If a program contains no catches and no throws, I don't see why any
+> "logic for EH" has to go into the executable.
+>
+> Out of curiosity, I compiled two programs under gcc and g++ and
+> compared their sizes:
+>
+>
+> program gcc g++ overhead percent
+>
+> int main(){} 13417 13745 328 bytes 2.4%
+>
+> 700-line C program 19930 20218 288 bytes 1.4%
+> (single file)
+
+ Does your copy of gcc use sj-lj (shadow stack) exceptions, or
+ dwarf2-unwind (range-table)? For recent versions (3.x) of gcc, gcc
+ -v will show a line that says 'Configured with: ...' if you see
+ --enable-sjlj-exceptions, that is what you are using. If you don't
+ see it - you are using a range-table implementation. (I suspect
+ that --enable-sjlj-exceptions is forced for both cygwin and mingw
+ gcc. For most other platforms, range-table is the default)
I don't see any enabling of shadow stacks.
[thp@cs thp]$ gcc -v Reading specs from
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.0.4/specs Configured with:
../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share/gcc-3.0.4
--enable-shared --enable-threads=posix --disable-checking
--enable-long-long --enable-cstdio=stdio --enable-clocale=generic
--enable-languages=c,c++,f77,objc,java --program-suffix=-3.0.4
--enable-objc-gc --host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix gcc version 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)
+> I realize that this naive test doesn't prove anything, but I would
+> normally expect EH logic, e.g., range tables, to grow with program
+> size,
+ [snip]
+
+ I believe that is an oversimplification. As I remember the range-table
+ implementation, the size of the range-tables will be proportional
+ to the number of scopes which require cleanup action (non-trivial
+ destructors, and catch() blocks). (Plus the ever-present small
+ constant). Compiling a C program as C++ with exceptions will not
+ show you the true cost of the range table.
That's my point. I don't think that compiling C programs with C++
compilers needs to bloat or slow the code, except perhaps for the
"ever-present small constant".
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Fri, 3 Jan 2003 16:39:57 +0000 (UTC) Raw View
James Kanze <kanze@gabi-soft.de> wrote:
+ thp@cs.ucr.edu wrote in message news:<au9pfe$aph$1@glue.ucr.edu>...
+
+ [...]
+> If a program contains no catches and no throws, I don't see why any
+> "logic for EH" has to go into the executable.
+
+ Because the compiler cannot necessarily know that the program contains
+ no catches and no throws. Classical linkers are unable to determine
+ this either.
+
+> Out of curiosity, I compiled two programs under gcc and g++ and
+> compared their sizes:
+
+> program gcc g++ overhead percent
+
+> int main(){} 13417 13745 328 bytes 2.4%
+
+> 700-line C program 19930 20218 288 bytes 1.4%
+> (single file)
+
+> I realize that this naive test doesn't prove anything, but I would
+> normally expect EH logic, e.g., range tables, to grow with program
+> size, which seems not to be happening here. (Perhaps that 300-or-so
+> bytes is simply code for catching uncaught exceptions.)
+
+ Why would you expect this? I would expect EH logic to grow with the
+ number of automatic variables which have destructors. If you are able
+ to compile with C, the code obviously doesn't have any.
Agreed. My point (with which you seem to agree) is that EH overhead
is not necessary when a C program is compile via a C++ compiler.
This subthread started with my somewhat sarcastic observation
that:
> Particularly within the operating-systems community, there is a
> prevalent opinion that compiling with a C++ compiler will
> necessarily bloat and slow their code. "Exception handling is
> turned on whether you use it or not, and surely that has to take
> up time and space."
P.J. Plauger's replied:
> Y'know, I still believe that myself to this day. Perhaps it's
> because nobody has shown me a compiler that really does support
> exceptions with zero time and space overhead, or that optimizes
> away all exception handling code in a program with no catch
> clauses.
I presume he meant code with no catches and no throws, e.g., C
programs, since that was the matter under discussion. He continued:
> Meanwhile, we continue to make money licensing a C++ library that
> can avoid all use of exceptions, for those unreconstructed people
> who think that might be important.
So, why would anyone pay for such a library if EH overhead is incurred
even when EH is unused, e.g., when there are no catches and/or throws,
as in the case of C programs?
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: andrewalex@hotmail.com ("Andrei Alexandrescu")
Date: Fri, 3 Jan 2003 21:38:54 +0000 (UTC) Raw View
""DrPizza"" <drpizza@anti-flash.co.uk> wrote in message
news:auk47e$poa$1@venus.btinternet.com...
> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> news:rOGblzF4vzB+Ewd+@robinton.demon.co.uk...
> > no vector<bool> specialisation.
> Rename it bit_vector or similar, and let vector<bool> be a proper
> container/sequence. If people really need the space/speed trade-off that
the
> packed vector<bool> currently requires, let them type bit_vector.
>
> > remove auto_ptr and replace with a well considered set of smart
pointers
> I think that a well-considered set of smart pointers is required, but
that
> auto_ptr should remain as one of those smart pointers. Its name is a bit
> objectionable, I suppose. But it's not really worth removing.
Better yet, replace them with one policy-based smart pointer, and make
auto_ptr behavior one of the default-provided policies.
Andrei
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Sat, 4 Jan 2003 00:27:26 +0000 (UTC) Raw View
===================================== MODERATOR'S COMMENT:
This is almost a flame, but I seem to detect the tongue-in-cheek.
===================================== END OF MODERATOR'S COMMENT
<thp@cs.ucr.edu> wrote in message news:av37sm$g1i$1@glue.ucr.edu...
> This subthread started with my somewhat sarcastic observation
> that:
>
> > Particularly within the operating-systems community, there is a
> > prevalent opinion that compiling with a C++ compiler will
> > necessarily bloat and slow their code. "Exception handling is
> > turned on whether you use it or not, and surely that has to take
> > up time and space."
>
> P.J. Plauger's replied:
>
> > Y'know, I still believe that myself to this day. Perhaps it's
> > because nobody has shown me a compiler that really does support
> > exceptions with zero time and space overhead, or that optimizes
> > away all exception handling code in a program with no catch
> > clauses.
>
> I presume he meant code with no catches and no throws, e.g., C
> programs, since that was the matter under discussion. He continued:
>
> > Meanwhile, we continue to make money licensing a C++ library that
> > can avoid all use of exceptions, for those unreconstructed people
> > who think that might be important.
>
> So, why would anyone pay for such a library if EH overhead is incurred
> even when EH is unused, e.g., when there are no catches and/or throws,
> as in the case of C programs?
Gee, I dunno. Except maybe that there are still plenty of compilers that
*do* generate smaller executables when you explicitly disable exception
handling. Lucky for us, those compiler writers are still too lazy to
do all the optimizations they should.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Tue, 31 Dec 2002 21:06:16 +0000 (UTC) Raw View
kon@iki.fi (Kalle Olavi Niemitalo) wrote
> allan_w@my-dejanews.com (Allan W) writes:
> > Worst of all -- what happens if some parts of the program are compiled
> > with #exceptions=no and other parts are not?
>
> If an exception ever propagates to a part that was compiled
> without exception support, then the program will terminate().
I think this pretty much removes any "optimization" you would have
had by turning off exceptions in the first place. When code compiled
with #exceptions=no makes a function call, it must check on return
to see if an exception has been thrown. This turns code like this:
if (foo()) bar();
into code like this:
bool temp = foo();
if (exception_has_been_thrown()) terminate();
if (temp) {
bar();
if (exception_has_been_thrown()) terminate();
}
Which probably isn't much different than the code that would have
been generated without #exception=no.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Noel Yap <Noel.Yap@morganstanley.com>
Date: 01 Jan 03 12:18:46 GMT Raw View
Thomas Mang wrote:
> E.g. a compiler switch to determine wether calls to delete / delete []
will
> have the current semantic, or will have equal semantic
(runtime-checking will
> determine if an array or a single object gets deleted). It's not
uncommon to
> see 'delete' called for arrays, either because the programmer didn't
know it
> was an array, or because he just forgot the '[]' tokens.
>
> With such a compiler swith, the performance gurus get what they
currently get
> (in practice: marginally faster code, but occasionally simply wrong
delete
> called), and the qualitiy gurus could get a safe-call to delete, at
the cost
> of very slightly degraded performance.
> Both parties have enough fans to justify such a switch.
IMHO, such a switch isn't that necessary since delete can be avoided
much of the time. I'm not advocating memory leaks, but rather the use
of std::auto_ptr, boost:array, and std::vector. What do you think?
Thanks,
Noel
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: Francis Glassborow <francis.glassborow@ntlworld.com>
Date: 01 Jan 03 12:25:44 GMT Raw View
In message <d6651fb6.0212300235.6f30cea2@posting.google.com>, James
Kanze <kanze@gabi-soft.de> writes
>In what applications. I've done benchmarks where Java was faster than
>C++. I've also done benchmarks where the reverse was true. And I've
>seen more than a few cases where the results depend on the platform.
You are not comparing languages but implementations. Worse, you are
comparing implementations in the context of a particular task.
I think the whole issue of which language is faster is a futile one.
Let us have a new argument as to which language has the better
programmers. I guess something like 8051 assembler probably wins that as
bad programmers keep away from getting quite so close to the metal :-)
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: rhairgroveNoSpam@Pleasebigfoot.com (Bob Hairgrove)
Date: 1 Jan 2003 18:04:47 -0500 Raw View
On 30 Dec 02 18:49:12 GMT, Thomas Mang <a9804814@unet.univie.ac.at>
wrote:
[snip...]
>E.g. a compiler switch to determine wether calls to delete / delete [] will
>have the current semantic, or will have equal semantic (runtime-checking will
>determine if an array or a single object gets deleted). It's not uncommon to
>see 'delete' called for arrays, either because the programmer didn't know it
>was an array, or because he just forgot the '[]' tokens.
>
>With such a compiler swith, the performance gurus get what they currently get
>(in practice: marginally faster code, but occasionally simply wrong delete
>called), and the qualitiy gurus could get a safe-call to delete, at the cost
>of very slightly degraded performance.
>Both parties have enough fans to justify such a switch.
This would have to be resolved at compile time, not runtime (i.e.
delete vs. delete[] ... oder??...)
Bob Hairgrove
rhairgroveNoSpam@Pleasebigfoot.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 1 Jan 2003 18:06:45 -0500 Raw View
kanze@gabi-soft.de (James Kanze) wrote
> Glen <lpepicel@nycap.rr.com> wrote
> > As far as the C++ programmer's career is concerned embedded devices
> > like cell phones and PDAs are a growth area and these things don't run
> > Java as fast as your 2500 Mhz desktops do... In fact they don't even
> > run C++ apps that fast :)
>
> That may be because they simulate C++ using a virtual machine written in
> Java:-). Seriously, Java does seem to be trying to compete as a
> language for cell phone software, at least at the application level.
> (And the most frequently used OS for cell phones is written in C++ --
> some people claim that that is why it is so slow.)
LOL!
So far, I've never had any of these pleasures:
* Having to wait 15 minutes for my cellphone to "boot," while it
shows me a graphic that says "Cellphone" and a moving blue line
* Being told that my cellphone is out of memory, so I should
close down some applications (but the error message prevents
me from doing so).
* Clicking on a number in my phone book, and then waiting two
minutes for it to start dialing
* Being told that now that I've upgraded my phone, I can no
longer call some of the old phone numbers
* Someone has hacked into my phone, and is now loading a virus
so that every time I turn the phone on, it dials Dial-A-Porn
* Being told that in order to dial certain new numbers, first
I need a new plug-in. The download is "free" (but uses up
10 cell minutes at 12 cents per minute) but the install
program displays 25 ads, and then tells me that I don't have
the right priviliges, please try again...
* Suddenly the screen shows only 3 letters or digits at a time,
because my display screen's driver malfunctions
* My cellphone has a unique phone number, but each and every person
that wishes to call me has to do it a different way. The only way
to figure out how to call me, is to call the cellphone company
first and ask how to do it -- incurring a one-time $15 cost.
* My Cellphone model A-1000-01 is compatible with headphone model
A-1000-01-H, but not with power supply A-1000-01-P, but the only
way to get the $12 headphone is to buy the bundle with the $59
power supply, even though I already have a power supply that works.
* I registered the cellphone in my name, but if I want to let my
wife use it, I have to pay extra money -- or be called a
"Cellphone pirate"
I've also never experienced a "Slow cellphone." Or maybe I have -- not
sure what this means. Did you write a cellphone program that would
calculate an arbitrary digit of PI, and then ask for the 1000th digit?
If not, what the heck is a "slow cellphone?"
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 1 Jan 2003 18:07:40 -0500 Raw View
Thomas Mang <a9804814@unet.univie.ac.at> wrote
> Believe it or not, but I have seen "recommendations" such as "you don't have
> to delete dynamically allocated memory. There's enough RAM, so don't bother
> with this complex stuff".
>
> Great advice, isn't it? I was just missing an additional note like "this has
> also the advantage that destructors won't be called, so it even speeds up your
> program".
This "advice" might make sense in a very few, very limited situations.
(I can't think of one offhand.) If the program has to instantiate a few
million objects, or if it has to run for a very long time (or even for
a few hours), this is folly.
Who advocates such a position? Please tell me it isn't any sort of teacher!
> Indeed, I sometimes have the feeling instead of hiring programmers knowing (to
> a high degree, who knows everything?) what they are doing, they set the
> hardware requirements to the newest chipset available.
Using the newest chipset available has many advantages, not the least of
which is reduced development time. However, testing should be done on as
many platforms as possible, including both extremes that clients will use --
that means that if you're going to support an 8Mhz 8086 with 1/2 Megabyte
of RAM, you need to have one in the office, and someone has to actually
use it!
> C++ is IMHO not one of those "easy" languages, because you can get quiet
> easily things wrong without even knowing just having entered undefined
> territory.
Expertise will always require experience, which requires time. But I think
that most of the problems that inexperienced programmers will run into,
come with the problem domain rather than the language itself. For instance,
nothing in C++ causes one-off errors to become more common or severe than
in any other language.
For the few common errors that are C++-specific, I think that most of
them are well-known and a very little education can help prevent them.
(Similar statements would be true of any language.) An example is
using a single equals sign for equivalence comparisons:
bool a = (b=c); // Oops! Meant (b==c)!
This particular problem is made much worse by the fact that so many
other languages use = for comparison, and still other languages (those
with "assignment statements") overload the same syntax for both
purposes. It has the effect of making the assignment "look natural"
especially for multi-lingual programmers.
This is a common enough problem; but once you've learned C++ enough to
call yourself proficient in the language, such errors ought to be rare
(unfortunately that's not the same thing as never making that mistake).
> So other programming languages (Java, Perl..) have, regarding this issue,
> these two advantages over C++:
> a) (usually) writing less code to get a given task done. (-> saves time ->
> saves costs)
Can you give an example of some "given task" that (usually) needs
more code in C++? I've found C++ to be pretty average in this regard,
especially modern C++ with the STL. By "average" I mean that there are
a few tasks which typically require more code, and there are others
that typically require much less.
> b) less pitfalls and, as a consequence less responsibility for programmers (->
> potentially less bugs -> saves costs).
I haven't found this to be the case either.
> E.g. a compiler switch to determine wether calls to delete / delete [] will
> have the current semantic, or will have equal semantic (runtime-checking will
> determine if an array or a single object gets deleted). It's not uncommon to
> see 'delete' called for arrays, either because the programmer didn't know it
> was an array, or because he just forgot the '[]' tokens.
Changing the rules on constructs which frequently cause inadvertent errors
is a good idea. Is delete versus delete[] one of those constructs?
Perhaps I'm no longer in a position to answer that, since my designs
typically make such errors rare. It's natural for me to do so, and I no
longer give it much thought. I don't know if this is a natural evolution
to take as a software developer, or if it's something I've done when
dealing with C++ as a defense against this problem...
Still, I'll at least take this position: Changing constructs that are
frequently misused by accident is a good thing. Changing constructs
that are frequently misused by carelessness or naive programmers is
not a good thing. As an example of the latter, it's not all that rare
for naive programmers to use operator overloading horrendously, despite
frequent advice not to. If a naive programmer defines operator+ for two
customers (and who knows what it's supposed to accomplish), that
doesn't mean we shouldn't have operator overloading!
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kon@iki.fi (Kalle Olavi Niemitalo)
Date: Sun, 29 Dec 2002 21:45:50 +0000 (UTC) Raw View
allan_w@my-dejanews.com (Allan W) writes:
> #exceptions=no
Consider imitating the #pragma STDC mechanism of C99.
It uses "ON", "OFF" and "DEFAULT" rather than "yes" and "no",
and can be scoped inside a compound statement.
> You've identified one consequence: catch clauses become no-ops,
> presumably because there's never anything to catch. But then,
> does the syntax of the no-op code have to be valid?
I'd say it has to be valid. The compiler must be able to find
the closing brace, at least.
> Is #if-ed out code a relevant precedent?
I don't think so. More like "if (false) { ... }".
> What happens to throw expressions?
I think this #exceptions=no should just promise to the compiler
that the code will not use any exceptions. If something breaks
this promise by throwing an exception, then I think terminate()
should be called immediately.
> With exceptions off, does new revert to new(std::nothrow)?
I don't like that idea. If you want new(std::nothrow), you
should use that explicitly. Otherwise, people would write
things like
#exceptions=no
void f() {
std::auto_ptr<foo> p = new foo;
if (p)
p->g();
else
h();
}
and if you now switched to #exceptions=yes, h() would no longer
be called in the out-of-memory case.
> What happens to dynamic_cast<> that fails?
If it was a cast to a reference type, it calls terminate().
If it was a cast to a pointer type, it returns NULL as usual.
> typeid(*NULL)?
Calls terminate(). If you need to handle NULL, check it
separately.
> Worst of all -- what happens if some parts of the program are compiled
> with #exceptions=no and other parts are not?
If an exception ever propagates to a part that was compiled
without exception support, then the program will terminate().
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Mon, 30 Dec 2002 15:17:19 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote in message
news:<3E0C0349.1090802@animats.com>...
> Allan W wrote:
> >>>Michael S wrote:
> >>>>As it stays now, C++ holds only one major advantage over Ada-95 -
> >>>>the absence of multythreading support at the language level.
> >>hyrosen@mail.com (Hyman Rosen) wrote
> >>>I don't understand. You claim that C++'s lack of multiprogramming
> >>>support is an *advantage* over Ada, which has it?
> >>Yes. It is an advantage.
> Locking, at least, should be in the language, since on many
> machines, locks may require the generation of special machine
> instructions. That's something which should be done by the compiler.
I'm not sure what you mean by locking. On the machines I use today, any
instruction which can "lock" can only be executed in protected mode;
"locking", at the user level, can only be done by means of systems calls
(such as pthread_mutex_lock).
At a lower level, or on simpler machines, it is possible to inhibit
interruptions, which effectively locks. Is this what you were talking
about?
For many operations, I only want to modify a single variable, which can
in fact be modified atomically. For this to work in a multithreaded
environment, however, the modification must be surrounded by some sort
of memory barrier instructions. Is this what you meant?
Independantly of locking, the compiler must be aware of threading, since
it should not move loads and stores across threading primitives. In
practice, this isn't a problem, because for each platform, the compiler
does what is necessary. (Or doesn't, in which case it can't be used to
generate threaded code.)
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Mon, 30 Dec 2002 15:37:38 +0000 (UTC) Raw View
allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0212271311.55a9f181@posting.google.com>...
> > Michael S <already5chosen@yahoo.com> writes
> > >See my thread "Three features you would like to have not in C++"
> > >(relegated to the second page now) for more of the same. There were
> francis.glassborow@ntlworld.com (Francis Glassborow) wrote
[...]
> > remove auto_ptr and replace with a well considered set of smart pointers
> Can you post a list of requirements? I think the biggest problem with
> auto_ptr is that nobody really knew exactly what it was supposed to
> accomplish.
Regretfully, I don't think that there is any real consensus even today.
> I think the original goal was to use it like this:
> void foo() {
> auto_ptr<foo> myfoo = new foo;
> // Whatever... possibly even throwing
> }
> Which it currently satisfies quite well. It also worked as "owned"
> pointer members in classes. But then someone wanted to use it for
> argument passing, and so changes were made... Currently, people want
> to use it in a vector<>, which of course doesn't work at all.
The problem is that people needed a smart pointer which supports
argument passing (and returning). If you want to enforce the rule that
an object is owned by a smart pointer, always, the obvious way it to use
a factory method which returns the smart pointer to create it.
I agree that it was probably a mistake to try and make auto_ptr solve
all problems. But even today, there is NO consensus for any of the
other types of pointers.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Thomas Mang <a9804814@unet.univie.ac.at>
Date: 30 Dec 02 18:49:12 GMT Raw View
Allan W schrieb:
> Thomas Mang <a9804814@unet.univie.ac.at> wrote
> > ...in the earlier days up to the 80's, it was
> > generally more
> > cost-efficient to program in assembly than to buy new hardware.
>
> Although that can only take you so far... skill with assembly language
> can make a slow computer seem much faster, but only to a point. You
> can't expect to run real-time full-color graphics with 256 bytes of
> RAM connected to a 4-bit processor, no matter how good you are with
> assembly language.
>
> > However, the
> > trend changed more and more towards hardware upgrades, and I think it
> > was at
> > the end of the 80's(according to the article), upgrading hardware became
> > finally cheaper. This trend is still going on, the spread being
> > certainly much
> > wider and still widening.
>
> The trend has gone too far.
>
> A simple cost/benefit analysis will tell you that upgrades are often
> the best way to go. We THINK we can improve this program's efficiency
> by 10%, but it will take a team of six programmers 9 months to do it,
> at a cost of $500k. We KNOW we can improve this computer's efficiency
> overnight by spending $50k on an upgrade... which one would you do?
>
> But the fact that computers are more powerful today than yesterday,
> has proved to be an excuse for lazy programming. Just because your
> desktop PC today has half a gigabyte of RAM, doesn't mean that your
> program ought to use up half a gigabyte of RAM!
Exactly. But C++ should not be used by lazy programmers.
Believe it or not, but I have seen "recommendations" such as "you don't have
to delete dynamically allocated memory. There's enough RAM, so don't bother
with this complex stuff".
Great advice, isn't it? I was just missing an additional note like "this has
also the advantage that destructors won't be called, so it even speeds up your
program".
Indeed, I sometimes have the feeling instead of hiring programmers knowing (to
a high degree, who knows everything?) what they are doing, they set the
hardware requirements to the newest chipset available.
C++ is IMHO not one of those "easy" languages, because you can get quiet
easily things wrong without even knowing just having entered undefined
territory.
So other programming languages (Java, Perl..) have, regarding this issue,
these two advantages over C++:
a) (usually) writing less code to get a given task done. (-> saves time ->
saves costs)
b) less pitfalls and, as a consequence less responsibility for programmers (->
potentially less bugs -> saves costs).
That doesn't mean C++ should have full GC (although a compiler switch to
enable this could be REALLY usefull), but other required additions to
implementations can try to catch up with other languages:
E.g. a compiler switch to determine wether calls to delete / delete [] will
have the current semantic, or will have equal semantic (runtime-checking will
determine if an array or a single object gets deleted). It's not uncommon to
see 'delete' called for arrays, either because the programmer didn't know it
was an array, or because he just forgot the '[]' tokens.
With such a compiler swith, the performance gurus get what they currently get
(in practice: marginally faster code, but occasionally simply wrong delete
called), and the qualitiy gurus could get a safe-call to delete, at the cost
of very slightly degraded performance.
Both parties have enough fans to justify such a switch.
regards,
Thomas
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 30 Dec 02 19:45:45 GMT Raw View
Glen <lpepicel@nycap.rr.com> wrote in message
news:<3E081F9B.3090409@nycap.rr.com>...
> The answer is so simple:
> C++ is F-A-S-T!
> neither Java or C# are as fast or even attempt to be.
In what applications. I've done benchmarks where Java was faster than
C++. I've also done benchmarks where the reverse was true. And I've
seen more than a few cases where the results depend on the platform.
Generally speaking, given the best current compiler technology, I expect
that Java would have a slight edge. In practice, the best current
compiler technology is rarely available, and whichever language has the
best technology for the application in question generally wins. (All of
the benchmarks where Java beats C++ were run on a PC. A platform where
Java has remarkably advanced compiler technology and C++ rather
primitive.)
There are cases where Java cannot come close. Java defines the
representation of machine types much more precisely, for example, and if
the hardware doesn't directly support Java's definition, it will be
decidedly slower. Thus, people writing code for 36 bit machines should
probably avoid Java if performance will ever be an issue. For most
people, however, this is not an issue.
> So, If your _not_ doing a time critical app, Java is a good choice,
> along with a dozen others.
> As far as the C++ programmer's career is concerned embedded devices
> like cell phones and PDAs are a growth area and these things don't run
> Java as fast as your 2500 Mhz desktops do... In fact they don't even
> run C++ apps that fast :)
That may be because they simulate C++ using a virtual machine written in
Java:-). Seriously, Java does seem to be trying to compete as a
language for cell phone software, at least at the application level.
(And the most frequently used OS for cell phones is written in C++ --
some people claim that that is why it is so slow.)
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: nagle@animats.com (John Nagle)
Date: Mon, 30 Dec 2002 20:32:37 +0000 (UTC) Raw View
James Kanze wrote:
> nagle@animats.com (John Nagle) wrote in message
>> Locking, at least, should be in the language, since on many
>>machines, locks may require the generation of special machine
>>instructions. That's something which should be done by the compiler.
>>
>
> I'm not sure what you mean by locking. On the machines I use today, any
> instruction which can "lock" can only be executed in protected mode;
> "locking", at the user level, can only be done by means of systems calls
> (such as pthread_mutex_lock).
Yes, IA-32 has poor lock primitives. Itanium has a proper test and
set instruction, as do some mainframes. (Does the AMD 64-bit
architecture?)
Even on IA-32, you can do an atomic decrement-and-test,
so you can build a locking primitive that doesn't make a system
call unless it has to block. This makes locking much cheaper
than if you have to make a system call every time.
Since this is so target-dependent,
and the exact instruction sequences generated matter, it's
something that should be encapsulated in a standard way.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Thu, 2 Jan 2003 04:16:18 +0000 (UTC) Raw View
In article <7f2735a5.0212271337.52983300@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>It might be worth doing, but it's a LOT of work and I don't know how
>much gain. My bet is that it won't happen.
And the whole point is that all those things have to be done if C++
Source is to be compiled and linked without exceptions. I do not know
what the most appropriate answers are but without them talking about C++
without exceptions is pie-in-the-sky.
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: drpizza@anti-flash.co.uk ("DrPizza")
Date: Thu, 2 Jan 2003 04:16:50 +0000 (UTC) Raw View
"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:rOGblzF4vzB+Ewd+@robinton.demon.co.uk...
> no vector<bool> specialisation.
Rename it bit_vector or similar, and let vector<bool> be a proper
container/sequence. If people really need the space/speed trade-off that the
packed vector<bool> currently requires, let them type bit_vector.
> remove auto_ptr and replace with a well considered set of smart pointers
I think that a well-considered set of smart pointers is required, but that
auto_ptr should remain as one of those smart pointers. Its name is a bit
objectionable, I suppose. But it's not really worth removing.
> no export.
Certainly; whilst it may piss off the people who've worked so hard to
implement it, the impact it'll make to normal developers should be minimal.
FWIW, my three would be:
1) Remove pointless C compatibility, for instance the local function
declaration "feature" that bites people in the ass. No, I don't think that C
compatibility is something that should be striven for. More often than not it
hinders C++ developers, and it won't win over C developers as they don't care
anyway.
2) Remove exception specifications. Stack unwinding is important; unless I
explicitly say terminate() or exit(), unwind the damn thing before exiting.
3) Remove the cop-out clause for allocators (the one that makes portable use
of custom pointer types impossible).
--
Now Playing: System F - Elevate
char a[99999],*p=a;main(int c,char**V){char* v=c>0?1[V]:V;if(c<0)for(c=1;c;c
+=!(91^*v)-!(93^*v),++v);else for(;(c=*v)&&93^c;p+=!(62^c)-!(60^c),*p+=!(43^
c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p),91^c||(v=*p?main(0,++v),v-2:\
main(-1,++v)-1),++v);return v;}/*bf prog as argv[1]. drpizza@battleaxe.net*/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: drpizza@anti-flash.co.uk ("DrPizza")
Date: Thu, 2 Jan 2003 04:17:16 +0000 (UTC) Raw View
"John Nagle" <nagle@animats.com> wrote in message
news:3E07CF00.5070000@animats.com...
> Hyman Rosen wrote:
> D is probably too close to Java
> and C#, and for that matter Objective C, to get
> any traction.
D is even more flawed than C++.
--
Now Playing: Marc van Linden - Another Dimension
char a[99999],*p=a;main(int c,char**V){char* v=c>0?1[V]:V;if(c<0)for(c=1;c;c
+=!(91^*v)-!(93^*v),++v);else for(;(c=*v)&&93^c;p+=!(62^c)-!(60^c),*p+=!(43^
c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p),91^c||(v=*p?main(0,++v),v-2:\
main(-1,++v)-1),++v);return v;}/*bf prog as argv[1]. drpizza@battleaxe.net*/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Thu, 2 Jan 2003 06:26:41 +0000 (UTC) Raw View
thp@cs.ucr.edu wrote in message news:<au9pfe$aph$1@glue.ucr.edu>...
[...]
> If a program contains no catches and no throws, I don't see why any
> "logic for EH" has to go into the executable.
Because the compiler cannot necessarily know that the program contains
no catches and no throws. Classical linkers are unable to determine
this either.
> Out of curiosity, I compiled two programs under gcc and g++ and
> compared their sizes:
> program gcc g++ overhead percent
> int main(){} 13417 13745 328 bytes 2.4%
> 700-line C program 19930 20218 288 bytes 1.4%
> (single file)
> I realize that this naive test doesn't prove anything, but I would
> normally expect EH logic, e.g., range tables, to grow with program
> size, which seems not to be happening here. (Perhaps that 300-or-so
> bytes is simply code for catching uncaught exceptions.)
Why would you expect this? I would expect EH logic to grow with the
number of automatic variables which have destructors. If you are able
to compile with C, the code obviously doesn't have any.
> +> or that optimizes away all exception handling code in a program with
> +> no catch clauses.
> Does the program have throws?
> + That one can be done for certain trivial programs,
> Why only trivial programs? For instance, if I understand correctly,
> g++ can link-in complex code that has been compiled under gcc and
> therefore (presumably) has no EH logic in it.
If I understand the standard algorithm correctly, the "EH code" consists
on one hand of code to call the destructors of the automatic variables,
and on the other, tables in which return addresses can be looked up. If
a function contains no automatic variables which have destructors, there
is no code to call the destructors, and there is nothing to put in the
table. (The table obviously must use some sort of associative
addressing.)
> + but those
> + "unreconstructed" types you mention below who care about every byte
> + and cycle will have to start using exceptions and demanding better
> + implementations before it ever happens for nontrivial programs (it
> + ain't gonna happen). It's a vicious cycle.
> I see an increasing interest in C++ within the embedded-systems
> community, and those folks care very much about bytes, cycles, and
> nanowatts. I expect them to push for low-overhead EH and for
> implementations where unused EH generates no overhead.
And I expect that compilers for such systems will continue to offer
options to generate code without exception handling, and libraries that
don't use exceptions. (A lot of such systems can't use dynamic memory
anyway, so most of the standard library is out.)
> + In general, even the most-efficient EH implementations today have room
> + for considerable optimization.
> E.g., not linking-in the uncaught-exception catcher if the program
> never throws?
> +> Meanwhile, we continue to make money licensing a C++ library that can
> +> avoid all use of exceptions, for those unreconstructed people who think
> +> that might be important.
> That would make most sense for people whose C++ implemenations
> generate no overhead for unused EH.
There's more to it than that. If the library uses exceptions
(e.g. operator new throws), then the compiler WILL generate exception
handling code.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Thu, 2 Jan 2003 06:27:10 +0000 (UTC) Raw View
hyrosen@mail.com (Hyman Rosen) wrote in message
news:<1040927513.515827@master.nyc.kbcfp.com>...
> James Kanze wrote:
> > The fact that:
> > std::vector<int> v( std::istream_iterator<char>( cin ),
> > std::istream_iterator<char>() ) ;
> > declares an external function, for example.
> This goes all the way back to the C base of C++.
Sort of. The above declaration isn't legal C:-). Seriously, the
problem (at least in this case) comes from the fact that the syntax
doesn't distinguish between a function style cast (which doesn't exist
in C) and a function declaration. In hindsight, it probably would have
been better to require that the typename always be in parentheses in a
cast -- if there is only one parameter, the parentheses around it can be
dropped (necessary for backwards compatibility), but otherwise, the
syntax is "(typename)( parameter-list[opt] )".
> But yes, it would be nice to it fixed.
> > Or the fact that in
> > std::vector<std::vector<int>> v ;
> > the '>>' is interpreted as a shift right token.
> I think we should keep this; let it be a pons asinorum for new C++
> programmers, as well as a lesson to future language designers :-)
> Notice that your requested changes are pure syntax, while John Nagle's
> requests were semantic.
Just for the record, I wasn't requesting any changes. John had asked
what is IMHO a valid question involving changes which break existing
code. Regretfully, his examples all involved code which is not
necessarily bad, at least in the minds of a certain number of users. I
just suggested some cases where I think that there is a consensus that
the current langauge is "bad".
Note that in both cases, correcting the problem may break existing,
correct code. In both cases, I suspect that the amount of code that
would break is small. But in neither case is there any way I know of to
know how small.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.@@xmission.dot.com (llewelly)
Date: Thu, 2 Jan 2003 06:33:33 +0000 (UTC) Raw View
thp@cs.ucr.edu writes:
> David Abrahams <dave@boost-consulting.com> wrote:
> + pjp@dinkumware.com ("P.J. Plauger") writes:
> +
> +>> The question is not "whether to use C++" but rather
> +>> "which, if any, C++ extensions to use". Particularly within the
> +>> operating-systems community, there is a prevalent opinion that
> +>> compiling with a C++ compiler will necessarily bloat and slow their
> +>> code. "Exception handling is turned on whether you use it or not, and
> +>> surely that has to take up time and space."
> +>
> +> Y'know, I still believe that myself to this day.
> +
> + And even I, who you might not expect to hear it from, was going to say
> + that it's true.
> +
> +> Perhaps it's because nobody has shown me a compiler that really does
> +> support exceptions with zero time and space overhead,
> +
> + And they never will. Zero time overhead in the non-exceptional case
> + is possible today, and can be demonstrated it for small programs.
> + Zero space overhead is not. The logic for EH functionality has to go
> + somewhere!
>
> If a program contains no catches and no throws, I don't see why any
> "logic for EH" has to go into the executable.
>
> Out of curiosity, I compiled two programs under gcc and g++ and
> compared their sizes:
>
>
> program gcc g++ overhead percent
>
> int main(){} 13417 13745 328 bytes 2.4%
>
> 700-line C program 19930 20218 288 bytes 1.4%
> (single file)
Does your copy of gcc use sj-lj (shadow stack) exceptions, or
dwarf2-unwind (range-table)? For recent versions (3.x) of gcc, gcc
-v will show a line that says 'Configured with: ...' if you see
--enable-sjlj-exceptions, that is what you are using. If you don't
see it - you are using a range-table implementation. (I suspect
that --enable-sjlj-exceptions is forced for both cygwin and mingw
gcc. For most other platforms, range-table is the default)
> I realize that this naive test doesn't prove anything, but I would
> normally expect EH logic, e.g., range tables, to grow with program
> size,
[snip]
I believe that is an oversimplification. As I remember the range-table
implementation, the size of the range-tables will be proportional
to the number of scopes which require cleanup action (non-trivial
destructors, and catch() blocks). (Plus the ever-present small
constant). Compiling a C program as C++ with exceptions will not
show you the true cost of the range table.
It is possible to write large C++ programs with exceptions disabled,
which nonetheless use destructors everywhere.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kon@iki.fi (Kalle Olavi Niemitalo)
Date: Thu, 2 Jan 2003 06:42:16 +0000 (UTC) Raw View
allan_w@my-dejanews.com (Allan W) writes:
> When code compiled with #exceptions=no makes a function call,
> it must check on return to see if an exception has been thrown.
I was thinking of a table-based implementation that locates
unwinding code and exception handlers by looking up return
addresses. If the caller was compiled without exception support,
then the return address will not be found in the table.
At least, that's how I think it would work. I don't have
experience on implementing exceptions so I may have missed some
crucial point. In that case, I suppose the result could be
undefined instead.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.@@xmission.dot.com (llewelly)
Date: Thu, 2 Jan 2003 06:52:30 +0000 (UTC) Raw View
allan_w@my-dejanews.com (Allan W) writes:
> kon@iki.fi (Kalle Olavi Niemitalo) wrote
> > allan_w@my-dejanews.com (Allan W) writes:
> > > Worst of all -- what happens if some parts of the program are compiled
> > > with #exceptions=no and other parts are not?
> >
> > If an exception ever propagates to a part that was compiled
> > without exception support, then the program will terminate().
>
> I think this pretty much removes any "optimization" you would have
> had by turning off exceptions in the first place. When code compiled
> with #exceptions=no makes a function call, it must check on return
> to see if an exception has been thrown. This turns code like this:
>
> if (foo()) bar();
>
> into code like this:
>
> bool temp = foo();
> if (exception_has_been_thrown()) terminate();
> if (temp) {
> bar();
> if (exception_has_been_thrown()) terminate();
> }
> Which probably isn't much different than the code that would have
> been generated without #exception=no.
[snip]
Not for a range-table implementation. When stack unwinding reaches a
frame compiled with #exception=no, no entry for that form will be
found in the range-table. Having found no entry, the stack unwind
code calls terminate(). The #exception=no code thus requires no
such overhead.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: hyrosen@mail.com (Hyman Rosen)
Date: Thu, 26 Dec 2002 19:31:48 +0000 (UTC) Raw View
James Kanze wrote:
> The fact that:
> std::vector<int> v( std::istream_iterator<char>( cin ),
> std::istream_iterator<char>() ) ;
> declares an external function, for example.
This goes all the way back to the C base of C++.
But yes, it would be nice to it fixed.
> Or the fact that in
> std::vector<std::vector<int>> v ;
> the '>>' is interpreted as a shift right token.
I think we should keep this; let it be a pons asinorum
for new C++ programmers, as well as a lesson to future
language designers :-)
Notice that your requested changes are pure syntax,
while John Nagle's requests were semantic.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Thu, 26 Dec 2002 20:48:34 +0000 (UTC) Raw View
Francis Glassborow wrote:
> In article <f881b862.0212230642.76ca81f9@posting.google.com>, Michael S
> <already5chosen@yahoo.com> writes
> remove auto_ptr and replace with a well considered set of smart pointers
The auto_ptr mess does indicate a problem with the language.
Even if you try really hard, you can't get that right.
I struggled with this for a while, when I was proposing
"strict mode" for C++. You can't do smart pointers safely
as C++ is currently defined. Doing them at all well is
tough, which is why we have so many different implementations
of them with different weaknesses.
Is there any serious work going on in this area?
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Fri, 27 Dec 2002 20:49:30 +0000 (UTC) Raw View
"llewelly" <llewelly.%@xmission.dot.com> wrote in message news:868yyf18fa.fsf@Zorthluthik.foo...
> pjp@dinkumware.com ("P.J. Plauger") writes:
>
> [snip]
> > Perhaps not, but the library that shipped with cfront certainly defined
> > a de facto standard, to the point that several other vendors copied it
> > bug for bug. Moreover, for the first few years of its work the library
> > subcommittee of X3J16 was aiming for *binary*
>
> Binary compatibility? In what sense? Was X3J16 aiming for a standard
> that made binary compatiblity between a new version of an
> implementation, and an old version of the same implementation
> feasible (as opposed to required)?
Yes.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: scottm@toast.net ("Scott Mayo")
Date: Fri, 27 Dec 2002 20:53:56 +0000 (UTC) Raw View
> Please note that even without standard language support, C++ is widely
> used in multithreaded applications. It won't take much to formalize
> existing practice to turn it into a portable standard -- some of it
> will come from POSIX, no doubt, and maybe they will also take ideas
> from Ada. For starters, add std::fork and a few IPC objects, and modify
> a few C functions that are currently thread-unsafe. Add or change a few
> rules about when side-effects must be complete and when data cannot be
> held in a cache, and that might be all that's needed! Or perhaps there
> are a lot more issues that come up that I can't see, but that's one of
> the advantages of having experts look into it.
It tends to be more complex. You need (at least) mutexes (critical
sections, for you win32 folk) for multithreading, but when you
program threads seriously, the kind of mutex at you use matters.
Sometimes you want a blocked thread to sleep while waiting.
OTOH, sometimes calling into the OS to sleep the thread is the
Wrong Thing. I'd be worried about C++ standarization creating
"a mutex object", but not specifying the underlying semantics. Then when
I get the dictate from my employers stating that henceforth we All
Must Use the C++ Standard For All Thread Work, In The Name
of Portability, I'll have problems.
Also, sometimes people have to write single threaded applications -
they really are still useful, and they often allow for much faster code.
(It's nice when malloc doesn't have to lock on every call!) If the standard
marched in with threading support, it might become impossible to
ever create a C++ program with single-thread efficiences. And that
would be Bad.
But if these problems can be solved - if I can specify a spinning mutex,
a blocking mutex, a spinning semaphore, a blocking semaphore,
and maybe a Win32-style Event; and if implementations can still specify
that the app is single threaded (with obvious loss of access to mt'ed
corners of the standard), then I'd be very happy to see C++ provide
them for me. I agree that in a world where so much code is multi-threaded,
C++'s non-support of threads creates real porting problems.
Unsafe C functions are typically replaced by versions with a _r
suffix, which are thread safe (at the cost of extra parameters.) C++
could certainly adopt those; generally it implicitly has.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Fri, 27 Dec 2002 21:12:28 +0000 (UTC) Raw View
Allan W wrote:
>>>Michael S wrote:
>>>
>>>>As it stays now, C++ holds only one major advantage over Ada-95 - the
>>>>absence of multythreading support at the language level.
>>>>
>
>>hyrosen@mail.com (Hyman Rosen) wrote
>>
>>>I don't understand. You claim that C++'s lack of
>>>multiprogramming support is an *advantage* over Ada,
>>>which has it?
>>>
>
>>Yes. It is an advantage.
Locking, at least, should be in the language, since
on many machines, locks may require the generation of
special machine instructions. That's something which
should be done by the compiler.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: scottm@toast.net ("Scott Mayo")
Date: Fri, 27 Dec 2002 22:24:15 +0000 (UTC) Raw View
> As for multithreading *at the language level*, I suppose there might
> be a few concessions. Perhaps expanding or clarifying the definition
> of volatile. I doubt it will be too drastic. Things like semaphors
> or mutexes are natural and obvious candidates for library objects,
> and I doubt that anyone would do it much differently.
Mutexes come in 2 flavors, machine level and OS level. They have
different uses, even though they both have the effect of only allowing
up to 1 thread into a section of code. Semaphores tend to vary by
platform; some are based on negative values, some positive, and some
you get to pick. Making all this standard is a valuable goal but maybe
not a trivial one.
> > I have the impression that the whole idea of imrovement by removing
> > features rather than adding more and more is a little too oriental for
> > you and many many other posters.
> (I'll assume that by "oriental" you were not making a racial slur for
> "Asian." Dictionary.com returns a whole page of definitions such as
> "Of or pertaining to the orient or east; eastern" or "'Asian' is now
> strongly preferred in place of 'Oriental' for persons native to Asia
> or descended from an Asian." But there is one line that says it means
> "Lustrous and valuable". I have never before heard it used in this
> sense, but since neither one quite makes sense there I'll give you
> the benefit of the doubt.)
Oriental has the historical sense of "exotic, mysterious, and foreign."
This makes little sense in these modern times, but it's not an uncommon
usage in older writings. It also pops up in perfumes (oriental perfumes
are a class of perfumes, and are not all from Asia.) If we've gotten
so politically correct that we have to discard completely innocent
words on the off chance that someone might think offense is intended,
it's time to give up on this whole language thing, and return to the trees.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Fri, 27 Dec 2002 22:24:18 +0000 (UTC) Raw View
Allan W <allan_w@my-dejanews.com> wrote:
[...]
+ In short, legacy code has already been paid for, and if we made it
+ worthless, people would (justifiably) be angry.
Agreed.
+ thp@cs.ucr.edu wrote
+> So, what should happen in the case at hand? Let's take C-style
+> strings as a concrete example. The Committee has taken the
+> appropriate first step by introducing C++-strings. The next step
+> might be to deprecate C-style strings and maybe encourage/require
+> implementations to have a mode where they issue warnings upon use of
+> deprecated constructs. Later, the standard might attach undefined
+> behavior to the reading or writing of C-stings.
+
+ Very interesting view of the issue. Let's analyze it.
[...]
+ (Arrays of char could still be the common denominator, of course; but if
+ the library didn't supply such things as strlen(), individual projects
+ would have to write it themselves anyway. Take this far enough and major
+ projects would have to replace the very feature you propose removing from
+ the language.)
Please understand that the above was intended as a concrete example of
how a removal process might function. I'm very much opposed to
removing C-style strings at this time, and I don't anticipate that
view changing within my lifetime.
My main annoyance with C-strings is the kinks that they induce in
C++'s string semantics, e.g., the fact that one cannot add two string
literals. I expect, however, that there are other (and perhaps
better) ways to get rid of such kinks.
[...]
+> In any case, breaking
+> that much existing code at the current time is not acceptable.
+
+ As someone else asked recently: how much is acceptable?
Committees are very good at resolving such questions.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Fri, 27 Dec 2002 22:25:05 +0000 (UTC) Raw View
francis.glassborow@ntlworld.com (Francis Glassborow) wrote
> Note that I do not think that exceptions are the only tool for handling
> problems, but I do think it is a valuable one. It might be useful if we
> had a standard mechanism for turning exception handling off such as:
>
> #define NO_EXCEPTIONS
>
> Together with agreed consequences of that (for example that catch
> clauses become no-ops)
Might be nice to have a standard way to do this (as opposed to assuming
that "most" compilers will have compiler switches for it). It wouldn't
be a macro, though, and not a #pragma either. (Both of these are
currently within either the user's or the implementation's perogative to
mean something else.) Perhaps some new type of directive, as in
#exceptions=no
However, I think this is a pretty tall order. You've identified one
consequence: catch clauses become no-ops, presumably because there's
never anything to catch. But then, does the syntax of the no-op code
have to be valid?
void bar() {
try {
std::cout << "Bar!";
} catch(std::Exception) {
Now is the time for all good men to come to the aid of
their syntax errors.
What can we put inside this "no-op" section? Comments,
obviously -- which means we can't have /* without
a matching */. But what about quotes -- do they have to
match? Can we have non-matching left and right braces?
if (false) { std::cout << "Missing brace and quote...
}
}
Is #if-ed out code a relevant precedent?
What happens to throw expressions?
void foo2() {
throw std::exception("NO!");
// If exceptions are disabled, does this line run?
std::cout << "Unreachable code";
}
void foo1() {
foo2();
// If exceptions are disabled, does this line run?
std::cout << "foo1";
}
void main() {
try {
foo1();
} catch(...) {
// If exceptions are disabled, this is a no-op... right?
std::cout << "Caught";
}
// If exceptions are disabled, does this line run?
std::cout << "main\n";
}
What does this program display, with exceptions disabled? Whatever
answer you pick, won't that surprise somebody?
With exceptions off, does new revert to new(std::nothrow)? What
happens to dynamic_cast<> that fails? typeid(*NULL)?
Worst of all -- what happens if some parts of the program are compiled
with #exceptions=no and other parts are not? If a no-exception
function calls an exception-enabled function, is the no-exception
function's catch block still a no-op? If so, what happens to the
exception -- do we keep going up the call tree until we find one that's
enabled? Do we execute destructors in the no-exception function?
Perhaps we just disallow this -- we state that all parts of the program
must have the same #exceptions value, similar to the ODR. But doesn't
that mean that third-party libraries have to ship two versions for each
compiler they support?
It might be worth doing, but it's a LOT of work and I don't know how
much gain. My bet is that it won't happen.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Fri, 27 Dec 2002 22:25:08 +0000 (UTC) Raw View
> Michael S <already5chosen@yahoo.com> writes
> >See my thread "Three features you would like to have not in C++"
> >(relegated to the second page now) for more of the same. There were
francis.glassborow@ntlworld.com (Francis Glassborow) wrote
> no vector<bool> specialisation.
Instead of removing it completely, how 'bout renaming it "bitvector?"
I think that vector<bool> does have usefulness(*) -- the only
unfortunate thing about it, is that it's lumped in with vector
even though it isn't a sequence.
(*) Alright, I've never used it yet -- but that doesn't mean it
can't be useful. Furthermore, for any code that currently uses it,
changing the name will be an easier fix than refactoring code to
stop using it completely.
> remove auto_ptr and replace with a well considered set of smart pointers
Can you post a list of requirements? I think the biggest problem with
auto_ptr is that nobody really knew exactly what it was supposed to
accomplish. I think the original goal was to use it like this:
void foo() {
auto_ptr<foo> myfoo = new foo;
// Whatever... possibly even throwing
}
Which it currently satisfies quite well. It also worked as "owned"
pointer members in classes. But then someone wanted to use it for
argument passing, and so changes were made... Currently, people want
to use it in a vector<>, which of course doesn't work at all.
> no export.
Why is it that you don't want this feature? EDG/Comeau spent all that
time and energy to make it work, and now you want to back it out?
Here again, I think that what people wanted it to do, and what it
actually does, don't match. Is it fair to say that export doesn't work
well with seperate compilation combined with current linker technology?
If so, doesn't that suggest a way to overcome this (and possibly other)
problems? Or would you say that export is doomed from the start, and
no matter how it's defined it can never accomplish what most people
apparently assumed it would do?
> Unfortunately removing any of those breaks existing code even though the
> first one also breaks future code (unless the author understands why
> vector<bool> is not a sequence container and specialises their own
> templates appropriately.
If you got rid of vector<bool> specialization, users in the future might
assume that it used less memory than it really does. But it would
certainly "work correctly" if "correctly" means a container of type
bool -- and anything you can do with bool, you can do with vector<bool>
elements.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Noel Yap <Noel.Yap@morganstanley.com>
Date: 28 Dec 02 12:25:37 GMT Raw View
Allan W wrote:
> ILS is the "star" .Net language -- because it's so low language, it
> can be used to support compilers for any language.
I've heard this isn't exactly true in practice since the CLR is biased
towards OO languages. For example, implementations for functional
programming languages are running into problems and even VB had to be
aborted in favor of VB.Net.
> The next C++ standard will come out in a few years. It will fix some
> of the perceived "problems" in the language, address possible errors,
> add new features to support even more styles of programming... to
> suggest that Microsoft (or any other for-profit company) wants to
> ignore that language is simply rediculous.
I find it funny that people tend to spell ridiculous as "rediculous"
when opining :-)
Anyway, IMHO, Aspect-Oriented Programming support would be a really neat
feature.
Noel
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: Maciej Sinilo <msinilo@NOSPAM.kki.net.pl (dot)>
Date: 28 Dec 02 12:30:32 GMT Raw View
In article from 26 Dec 2002 12:55:31 -0500 Glen says...
> The answer is so simple:
>
> C++ is F-A-S-T!
>
> neither Java or C# are as fast or even attempt to be. So, If your
_not_
> doing a time critical app, Java is a good choice, along with a dozen
others.
With Java & C# you are probably right, but from benchmarks at
http://www.bagley.org/~doug/shootout/ it seems that OCaml and Mercury
(for example) are not so far behind C/C++ (and sometimes even faster).
--
Maciej Sinilo
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: gdr@integrable-solutions.net (Gabriel Dos Reis)
Date: Thu, 26 Dec 2002 09:17:52 +0000 (UTC) Raw View
c141592653589@hotmail.com (MJ) writes:
| I don't understand why adding a keyword should be an obstacle for a
| new language feature.
A new keyword, unless of the abominable form _([A-Z]|_).*, means reserving
an identifier previously in user name space. That means, potentially
breaking existing programs. In order words, keywords have cost. The
issue is whether among the people who care about C++, there are enough
ready to pay the price for a new keyword.
--
Gabriel Dos Reis, gdr@integrable-solutions.net
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Thu, 26 Dec 2002 10:05:45 +0000 (UTC) Raw View
In article <uel88do5t.fsf@boost-consulting.com>, David Abrahams
<dave@boost-consulting.com> writes
>In general, even the most-efficient EH implementations today have room
>for considerable optimization.
However, IMHO, that optimisation potential is there exactly because
exceptions are being used to report problems. The alternatives (other
than just completely ignoring the possibility that something could go
wrong) so mix the error handling with the normal code that it would take
a high IQ AI to unravel it.
Note that I do not think that exceptions are the only tool for handling
problems, but I do think it is a valuable one. It might be useful if we
had a standard mechanism for turning exception handling off such as:
#define NO_EXCEPTIONS
Together with agreed consequences of that (for example that catch
clauses become no-ops)
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Thu, 26 Dec 2002 16:39:36 +0000 (UTC) Raw View
already5chosen@yahoo.com (Michael S) wrote
> As it stays now, C++ holds only one major advantage over Ada-95 - the
> absence of multythreading support at the language level. It would not
> take me by surprise if this advantage will evaporate too in five years
> to come.
You're suggesting that C++ is somehow better than Ada-95 because it
does NOT have multithreading support at the language level?
Please note that even without standard language support, C++ is widely
used in multithreaded applications. It won't take much to formalize
existing practice to turn it into a portable standard -- some of it
will come from POSIX, no doubt, and maybe they will also take ideas
from Ada. For starters, add std::fork and a few IPC objects, and modify
a few C functions that are currently thread-unsafe. Add or change a few
rules about when side-effects must be complete and when data cannot be
held in a cache, and that might be all that's needed! Or perhaps there
are a lot more issues that come up that I can't see, but that's one of
the advantages of having experts look into it.
I doubt that even the C++ Standardization Committee can make multi-
threading or multi-processing simple and easy, but they can at least
make it possible to write multiprocess programs that ought to compile
and run on any OS that supports it, and perhaps they can spot the
most likely "gotchas" and make them less likely.
One thing I'm sure of. For programs and programmers that don't use the
new facilities, the new features won't impact you at all -- and modulo
a new keyword or two, practically all of your legacy software will work.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Thu, 26 Dec 2002 16:40:08 +0000 (UTC) Raw View
Designing a new language while in a laboratory is very different than
designing a new version of that same language.
Stroustrup decided to make his language upward-compatible with C, for
some extremely good reasons; but while he was working, he got to decide
exactly what "upward-compatible with C" meant.
By the time the language got to the C++ Standardization Committee, there
were thousands of users. With a few exceptions, the committee wasn't
there to design new features and better ways to do things; the point was
to make sure that you could write a C++ program that worked on Unix,
Microsoft Windows, mainframes, etc., equally well. Oh, and since people
have already paid good money for their existing compilers, let's try to
make sure that the programs they already wrote don't need to be scrapped
and restarted from scratch.
Buying a new compiler every few years is bad enough (but neccesary). Can
you imagine what it would be like to have to start all of your projects
over again from scratch, every 10 years or so? Buying a "translator"
would help, but only a little bit -- translators aren't perfect,
especially when it comes to retaining comments, and retraining would be
a problem as well.
In short, legacy code has already been paid for, and if we made it
worthless, people would (justifiably) be angry.
thp@cs.ucr.edu wrote
> So, what should happen in the case at hand? Let's take C-style
> strings as a concrete example. The Committee has taken the
> appropriate first step by introducing C++-strings. The next step
> might be to deprecate C-style strings and maybe encourage/require
> implementations to have a mode where they issue warnings upon use of
> deprecated constructs. Later, the standard might attach undefined
> behavior to the reading or writing of C-stings.
Very interesting view of the issue. Let's analyze it.
The ability to use strings starts in most cases with the ability to
define string constants. Even before you bother reading and writing
strings, you need a way to create them within the code.
std::string name = "Thp";
uses a string literal -- which has type char*. Would you take this
ability away? Obviously not -- but what's the alternative? Would you
make "Thp" be of type std::string? This has huge ramifications --
now string literals would be the only type of literals that have a
constructor and a destructor. This program:
int main() { "Thp"; }
would now have clean-up code that runs after main is finished. It's
also one of the very few places where the compiler generates data
that's defined in the library -- the only other cases I can think
of are certain exceptions, and RTTI.
Viewing the compiler code that constructs the string literal would
also be very illuminating -- certainly the letters 'T', 'h', and 'p'
would have to be stored somewhere, along with either a length or a
terminating sentinel. Starting to look like a C-style string.
May I also point out that C++ needs to be compatible with more than
just C? Mixed-language development, by definition, cannot be specified
in the C++ standard -- and yet it happens all the time. By definition
it is non-portable, but every platform I know of takes pains to make
sure that it is possible, and usually even easy. For instance, they
document calling conventions in excruciating detail, so that we can
determine in advance if Fortran can call a C++ extern "C" function, and
so that we certainly can call it from Assembly. No two languages seem
to use the same internal structure for strings(*), but C-style strings
have such great simplicity that it has been used as the common
denominator in many projects.
(Arrays of char could still be the common denominator, of course; but if
the library didn't supply such things as strlen(), individual projects
would have to write it themselves anyway. Take this far enough and major
projects would have to replace the very feature you propose removing from
the language.)
(*) .NET is the first exception to this that I'm aware of, but I wouldn't
be surprise if it wasn't the first. Still, shared representation for
strings seems to be the exception, not the rule.
> In any case, breaking
> that much existing code at the current time is not acceptable.
As someone else asked recently: how much is acceptable?
But you're right -- C compatibility would be a minor issue compared
with C++ compatibility. (See my remarks at the beginning of this
article.) The value of sizeof("Thp") would no longer have anything to
do with the number of characters in the string! AFAIK, every significant
C++ project includes C-style strings at some point.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 26 Dec 2002 12:53:52 -0500 Raw View
Thomas Mang <a9804814@unet.univie.ac.at> wrote
> ...in the earlier days up to the 80's, it was
> generally more
> cost-efficient to program in assembly than to buy new hardware.
Although that can only take you so far... skill with assembly language
can make a slow computer seem much faster, but only to a point. You
can't expect to run real-time full-color graphics with 256 bytes of
RAM connected to a 4-bit processor, no matter how good you are with
assembly language.
> However, the
> trend changed more and more towards hardware upgrades, and I think it
> was at
> the end of the 80's(according to the article), upgrading hardware became
> finally cheaper. This trend is still going on, the spread being
> certainly much
> wider and still widening.
The trend has gone too far.
A simple cost/benefit analysis will tell you that upgrades are often
the best way to go. We THINK we can improve this program's efficiency
by 10%, but it will take a team of six programmers 9 months to do it,
at a cost of $500k. We KNOW we can improve this computer's efficiency
overnight by spending $50k on an upgrade... which one would you do?
But the fact that computers are more powerful today than yesterday,
has proved to be an excuse for lazy programming. Just because your
desktop PC today has half a gigabyte of RAM, doesn't mean that your
program ought to use up half a gigabyte of RAM! I've seen programs
that use up twelve pages of source code and thousands of bytes worth
of static variables, just to put today's date and time in a human-
readable format. My instinct to improve the code (not because it's
especially a bottleneck -- just because it offends me to look at it!)
is overridden with the reply, "memory is cheap, CPU cycles are cheap,
concentrate on meeting the deadline."
It shows, too, in simple programs (i.e. invoicing, or E-mail clients)
that take up 100 Megabytes of disk space and require 20 seconds to
load on a 1Ghz P5.
What's the point of getting a computer with twice as much space, only
to load programs that take up ten times as much space? You're right,
efficiency isn't considered as important as it used to be -- and that's
a damn shame.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: 26 Dec 2002 12:55:00 -0500 Raw View
shannon.barber@myrealbox.com (Shannon Barber) wrote
> "Carl Daniel" <cpdaniel@nospam.mvps.org> wrote
> C++ is clearly not the premiere .Net language. You could attempt to
> figure out if it's VB.Net or C#, but it is not C++. There's no
> dynamic-code compilation for C++/ME like there is for VB & C#, support
> for everything in C++ was given a lower priority (such as WinForms,
> though it is due in 2003Q1).
ILS is the "star" .Net language -- because it's so low language, it
can be used to support compilers for any language.
In other words, there is no "star" language. The whole point of .Net
and especially the CLS, is to put languages on an even footing.
Some have accused Microsoft of putting languages in a blender,
homoginizing them so that the individual language no longer matters.
(As if that was a bad thing!) Others are accusing Microsoft of being
secret language bigots, preferring one language (usually C#), and
supporting other languages only "to make money." (As if THAT was a
bad thing!)
Clearly, one camp or another is wrong. Could it be both?
The next C++ standard will come out in a few years. It will fix some
of the perceived "problems" in the language, address possible errors,
add new features to support even more styles of programming... to
suggest that Microsoft (or any other for-profit company) wants to
ignore that language is simply rediculous.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Glen <lpepicel@nycap.rr.com>
Date: 26 Dec 2002 12:55:31 -0500 Raw View
The answer is so simple:
C++ is F-A-S-T!
neither Java or C# are as fast or even attempt to be. So, If your _not_
doing a time critical app, Java is a good choice, along with a dozen others.
As far as the C++ programmer's career is concerned embedded devices like
cell phones and PDAs are a growth area and these things don't run Java
as fast as your 2500 Mhz desktops do... In fact they don't even run C++
apps that fast :)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Thu, 26 Dec 2002 18:39:08 +0000 (UTC) Raw View
llewelly.@@xmission.dot.com (llewelly) wrote
> What about moving everything in the standard library into std:: ?
> That's done, not in the pipeline, but it does seem (to me) to be a
> similar case.
Why stop with the library?
#std::include <std::iostream>
std::int std::main(std::int argc, std::char** argv) {
std::for(std::int i=0; i<10; ++i)
std::cout << ' ' << i;
std::cout << std::endl;
}
For that matter, why not apply it to operators and other
non-alpha punctuation, too?
std::int std::main std::(
std::int argc std::,
std::char std::* std::* argv std::
) std::{
std::for std::( std::int i std::= 0 std::;
i std::< 10 std::; std::++ i std::)
std::cout std::<< ' ' std::<< i std::;
std::cout std::<< std::endl std::;
std::}
We could even apply the std::prefix to numeric literals (i.e. std::0).
I think we better leave char and string literals alone, though...
that would be std::excessive std::, std::don't std::you std::think std::?
std::-)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Thu, 26 Dec 2002 18:48:06 +0000 (UTC) Raw View
David Abrahams <dave@boost-consulting.com> wrote:
+ pjp@dinkumware.com ("P.J. Plauger") writes:
+
+>> The question is not "whether to use C++" but rather
+>> "which, if any, C++ extensions to use". Particularly within the
+>> operating-systems community, there is a prevalent opinion that
+>> compiling with a C++ compiler will necessarily bloat and slow their
+>> code. "Exception handling is turned on whether you use it or not, and
+>> surely that has to take up time and space."
+>
+> Y'know, I still believe that myself to this day.
+
+ And even I, who you might not expect to hear it from, was going to say
+ that it's true.
+
+> Perhaps it's because nobody has shown me a compiler that really does
+> support exceptions with zero time and space overhead,
+
+ And they never will. Zero time overhead in the non-exceptional case
+ is possible today, and can be demonstrated it for small programs.
+ Zero space overhead is not. The logic for EH functionality has to go
+ somewhere!
If a program contains no catches and no throws, I don't see why any
"logic for EH" has to go into the executable.
Out of curiosity, I compiled two programs under gcc and g++ and
compared their sizes:
program gcc g++ overhead percent
int main(){} 13417 13745 328 bytes 2.4%
700-line C program 19930 20218 288 bytes 1.4%
(single file)
I realize that this naive test doesn't prove anything, but I would
normally expect EH logic, e.g., range tables, to grow with program
size, which seems not to be happening here. (Perhaps that 300-or-so
bytes is simply code for catching uncaught exceptions.)
+> or that optimizes away all exception handling code in a program with
+> no catch clauses.
Does the program have throws?
+ That one can be done for certain trivial programs,
Why only trivial programs? For instance, if I understand correctly,
g++ can link-in complex code that has been compiled under gcc and
therefore (presumably) has no EH logic in it.
+ but those
+ "unreconstructed" types you mention below who care about every byte
+ and cycle will have to start using exceptions and demanding better
+ implementations before it ever happens for nontrivial programs (it
+ ain't gonna happen). It's a vicious cycle.
I see an increasing interest in C++ within the embedded-systems
community, and those folks care very much about bytes, cycles, and
nanowatts. I expect them to push for low-overhead EH and for
implementations where unused EH generates no overhead.
+ In general, even the most-efficient EH implementations today have room
+ for considerable optimization.
E.g., not linking-in the uncaught-exception catcher if the program
never throws?
+> Meanwhile, we continue to make money licensing a C++ library that can
+> avoid all use of exceptions, for those unreconstructed people who think
+> that might be important.
That would make most sense for people whose C++ implemenations
generate no overhead for unused EH.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.%@xmission.dot.com (llewelly)
Date: Thu, 26 Dec 2002 19:07:19 +0000 (UTC) Raw View
pjp@dinkumware.com ("P.J. Plauger") writes:
[snip]
> Perhaps not, but the library that shipped with cfront certainly defined
> a de facto standard, to the point that several other vendors copied it
> bug for bug. Moreover, for the first few years of its work the library
> subcommittee of X3J16 was aiming for *binary*
Binary compatibility? In what sense? Was X3J16 aiming for a standard
that made binary compatiblity between a new version of an
implementation, and an old version of the same implementation
feasible (as opposed to required)?
> compatibility with the
> cfront iostreams library. In the end, they destroyed even *source*
> compatibility.
[snip]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Thu, 26 Dec 2002 19:28:27 +0000 (UTC) Raw View
> > Michael S wrote:
> > > As it stays now, C++ holds only one major advantage over Ada-95 - the
> > > absence of multythreading support at the language level.
> hyrosen@mail.com (Hyman Rosen) wrote
> > I don't understand. You claim that C++'s lack of
> > multiprogramming support is an *advantage* over Ada,
> > which has it?
> Yes. It is an advantage.
> And the absence of garbage collection support *at the language level"
> is a major advantage over Java/C#.
> Ah, If it only was possible to drop memory management support *at the
> language level* ! Wet dreams.
> By good ole "C" virtue things like thease are supported at the level
> of standard library. Or better optional standard library. Or de-facto
> standard library.
>
> I have the impression that the whole idea of imrovement by removing
> features rather than adding more and more is a little too oriental for
> you and many many other posters.
(I'll assume that by "oriental" you were not making a racial slur for
"Asian." Dictionary.com returns a whole page of definitions such as
"Of or pertaining to the orient or east; eastern" or "'Asian' is now
strongly preferred in place of 'Oriental' for persons native to Asia
or descended from an Asian." But there is one line that says it means
"Lustrous and valuable". I have never before heard it used in this
sense, but since neither one quite makes sense there I'll give you
the benefit of the doubt.)
Perhaps you just didn't explain yourself well. Yes, I now recognize
what you were saying. In fact, moving things like I/O from the compiler
to the library is what made C so great in the first place, and what's
made it so extensible (non-standard extensions for multithreading, for
instance).
As for multithreading *at the language level*, I suppose there might
be a few concessions. Perhaps expanding or clarifying the definition
of volatile. I doubt it will be too drastic. Things like semaphors
or mutexes are natural and obvious candidates for library objects,
and I doubt that anyone would do it much differently.
I hope they make one exception. Suppose a variable has the value
0x12345678. One thread is trying to read it, and another thread is
trying to change it to 0. Without any IPC, the first thread might
get 0x12345678 or 0 -- but it also might get 0x12340000 or 0x00005678,
if the second thread has started to modify the value but not yet
finished. With full IPC the first thread will only get one of the
"correct" values, but the program will run slowly. Many CPUs and most
OSs have a way to load or save an integral value without fear of
interruption. Sometimes this operation is slightly more slow than
simply reading the value, but very much faster than using some IPC
construct such as a semaphore. Allowing the compiler to emit this
code inline, in a standard and portable way, would be a Good Idea(tm).
Compilers on systems that don't support this would simply create a
semaphore instead.
Language implementation of memory management: What would you have
preferred? I'm trying to imagine how
MyClass *m = new MyClass[5];
would look without language support for memory management. All I
can come up with is:
MyClass * m = malloc(sizeof(MyClass)*5);
for (int i=1; i<5; ++i) // Oops!
// Construct in-place -- if we didn't
// have (placement) operator new, then
// this would probably have been legal syntax...
m[i]->MyClass();
(Notice the bug, which the compiler would never make)
I suppose you have the same complaint about automatic generation of
copy constructors, assignment operators, and the like? If you didn't
write code to call it, then you don't want it called -- is that it?
I vastly prefer the notation we have today. I've tried to figure out
if it's just prejudice (this is the way I learned), or if it really
is superior. I think it's the latter, because it's less error-prone,
but I have no way of being sure.
(Before you tell me it's prejudice -- you have no way of knowing either.)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pardux@ally.ptf.ntu-kpi.kiev.ua ("Anton V. Tykhyy")
Date: Thu, 26 Dec 2002 19:30:06 +0000 (UTC) Raw View
>> I suggest that those who are interested begin working. The new languages
>> could tentatively be called "C++ with Aspects", or "C++ with Reflection",
>> or "C++ with Improved Syntax", just like C++ began as "C with Classes".
I'm interested, currently working, but the product is not publishable yet
(hopefully will be in 2-4 months)
--
Regards, pardux
=== ICQ#38457991 === Origin: Delirium canis (c) ===
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: austern@well.com (Matt Austern)
Date: Fri, 20 Dec 2002 17:40:25 +0000 (UTC) Raw View
kanze@gabi-soft.de (James Kanze) writes:
> austern@well.com (Matt Austern) wrote in message
> news:<dilof7h4as5.fsf@mattlinux.localdomain>...
> > nagle@animats.com (John Nagle) writes:
> > > > I think that's true. Changes that break code will be
> > > > considered, but
>
> > > > the critera are more stringent than "the vast majority of
> > > > code would be unaffected".
>
> > > What are the criteria? Are they written down somewhere?
>
> > No. It's a judgement call, it'll have to be considered on a
> > case by case basis, and I'm sure that not every committee
> > member will use the same criteria. Some of the relevant
> > questions to ask: how much code is likely to break, whether it
> > will break quietly or noisily, whether it's easy to fix the
> > breakage.
>
> > As I said, I can think of some changes that will almost
> > certainly be considered seriously even thought they'll break
> > code.
>
> Any on tap.
Sure, any changes that involve adding a new keyword. (Technically I
suppose we could add keywords that aren't in the user namespace, like
WG14 did with _Bool and _Complex, but I haven't seen any support for
that sort of thing. My impression is that most folks on the Committee
find it a bit distasteful.)
I think that 'restrict' is likely to make it into a future version of
C++. That'll break every program that uses that word as an
identifier.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: austern@well.com (Matt Austern)
Date: Fri, 20 Dec 2002 19:26:02 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) writes:
> To make this more concrete, consider the following changes:
>
> -- Disallow overriding of a non-virtual function.
> -- Disallow delete of const pointers.
> -- Disallow "delete this".
>
> These are all things that are usually errors.
> Suppose we examined some large body of code, and
> determined that N% of the time these situations
> came up, they were errors. How high would N have
> to be to justify the change? 90%? 99%? 99.99%?
> 100%?
For those changes, my personal opinion is that N would have to be very
close to 100%. I'd be willing to be slighly more lenient with the
second of the three proposals. Here's my reasoning.
These hypothetical changes at least have the virtue that they don't
cause silent changes in the meaning of existing programs, so that's
something. Now a couple of other questions that I would always ask in
the case of a change that can potentially break user code: how easy is
it to fix the breakage, and what does the change get you that you
didn't have before?
For all three changes, the answer is that no new programming
techniques are made possible. We would get better diagnostics if
users do something wrong accidentally, and that's it. And, of course,
compiler vendors can already give diagnostics for code that they think
is more likely to be wrong than right. Legal code that might not be
what the programmer really meant is just what warnings are for.
For the second proposed change there's an easy mechanical way for
users to fix code that was broken by the change. For the first and
the third, there isn't. I've only rarely written 'delete this', but
every time I have, it's because I couldn't think of any way to
redesign my program to avoid 'delete this' or the moral equivalent.
(By which I mean things like 'p = this; delete p;'. If you're allowed
to get around a ban on 'delete this' by a simple spelling change, then
I'd say there's no point to having the ban in the first place.)
Similarly, there are some useful techniques, especially involving base
classes that are templatized on classes that inherit from them, that
are only possible because of the ability to override non-virtual
member functions.
I can easily believe that these features are more often used
incorrectly than correctly. But if there's no good substitute for
them in the cases where they are used correctly, then getting rid of
them would make C++ a less useful language.
So I'd recommend against all three of these changes. The first one
strikes me as eliminating a commonly useful feature, the third strikes
me as eliminating a feature that's rarely useful but occasionally
indispensable. The second change strikes me as mostly harmless, but
I'd still recommend against it because it was extensively discussed
before the C++ Standard was released. Maybe the decision we made was
right, maybe it was wrong, but I'd rather not reopen settled decisions
unless there's new information that wasn't available at the time the
decision was originally made.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Fri, 20 Dec 2002 19:29:48 +0000 (UTC) Raw View
Thomas Mang wrote:
>>>I think that's true. Changes that break code will be considered, but
>>>the critera are more stringent than "the vast majority of code would
>>>be unaffected".
>>>
>> What are the criteria? Are they written down somewhere?
>>
>> I'd argue that if your code isn't publicly visible, you
>>should't expect it to be protected against future language
>>changes. If a change is proposed, the universe of
>>source code available without an NDA should be examined
>>for conflicts to see how serious the problem is.
>>
>
> Or even better, if "mechanical" ways allow an automatic transformation of source
> code.
Now that's a good idea. For C++0x, we should expect that
mechanical translation from the old version to the new should
be possible, rather than that old code should always run
unmodified. Otherwise, the language can only add cruft;
we can never get rid of any.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: chrisnewton@no.junk.please.btinternet.com ("Chris Newton")
Date: Fri, 20 Dec 2002 19:29:58 +0000 (UTC) Raw View
"John Nagle" <nagle@animats.com> wrote...
> To make this more concrete, consider the following changes:
>
> -- Disallow overriding of a non-virtual function.
> -- Disallow delete of const pointers.
> -- Disallow "delete this".
>
> These are all things that are usually errors.
> Suppose we examined some large body of code, and
> determined that N% of the time these situations
> came up, they were errors. How high would N have
> to be to justify the change? 90%? 99%? 99.99%?
> 100%?
The problem, I think, is that it's hard to gauge how often such things
are errors across the whole C++ programming world. Some things are
clearly very dangerous to do and have demonstrably better alternatives
available. Others can be dangerous, but can also be very useful.
If those designing the language had restricted features so they could be
used only in certain ways, I think C++ would have been far less
successful. Who imagined the clever tricks with templates that we have
today back when someone first started playing with a preprocessor a few
years ago?
For the record, I think "delete this;" is perfectly acceptable and, in
my experience, widely (and correctly) used. I have also seen plenty of
instances of the other two being used correctly as well. In all three
cases, arbitrarily banning them would result in existing code breaking,
and having to be reworked in an unnecessarily cumbersome fashion as a
result.
Cheers,
Chris
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.@@xmission.dot.com (llewelly)
Date: Fri, 20 Dec 2002 21:36:05 +0000 (UTC) Raw View
kanze@gabi-soft.de (James Kanze) writes:
[snip]
> The day they changed new to throw rather than to return a null
> pointer, they broke every single bit of "correct" code that then
> existed. (Correct code, at that time, being code which
> carefully tested the return of every new, and propagated the
> error to where ever it was to be handled.) Now, I'm certainly
> not one to encourage the overuse of exceptions, nor to recommend
> breaking code, but I hardly see how any other decision would
> have been reasonable.
>
> But I feel that this was a very special case. And I can't
> remember having heard of anything similar in the pipelines yet.
[snip]
What about moving everything in the standard library into std:: ?
That's done, not in the pipeline, but it does seem (to me) to be a
similar case.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.@@xmission.dot.com (llewelly)
Date: Fri, 20 Dec 2002 21:36:11 +0000 (UTC) Raw View
austern@well.com (Matt Austern) writes:
[snip]
> Sure, any changes that involve adding a new keyword. (Technically I
> suppose we could add keywords that aren't in the user namespace, like
> WG14 did with _Bool and _Complex, but I haven't seen any support for
> that sort of thing. My impression is that most folks on the Committee
> find it a bit distasteful.)
>
> I think that 'restrict' is likely to make it into a future version of
> C++. That'll break every program that uses that word as an
> identifier.
[snip]
I think we need namespaced keywords. std::restrict instead of restrict.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gdr@integrable-solutions.net (Gabriel Dos Reis)
Date: Sat, 21 Dec 2002 18:08:22 +0000 (UTC) Raw View
llewelly.@@xmission.dot.com (llewelly) writes:
| kanze@gabi-soft.de (James Kanze) writes:
|
| [snip]
| > The day they changed new to throw rather than to return a null
| > pointer, they broke every single bit of "correct" code that then
| > existed. (Correct code, at that time, being code which
| > carefully tested the return of every new, and propagated the
| > error to where ever it was to be handled.) Now, I'm certainly
| > not one to encourage the overuse of exceptions, nor to recommend
| > breaking code, but I hardly see how any other decision would
| > have been reasonable.
| >
| > But I feel that this was a very special case. And I can't
| > remember having heard of anything similar in the pipelines yet.
| [snip]
|
| What about moving everything in the standard library into std:: ?
Were there any standard library before we got the Standard? <g>
--
Gabriel Dos Reis, gdr@integrable-solutions.net
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kuyper@wizard.net ("James Kuyper Jr.")
Date: Sat, 21 Dec 2002 20:21:49 +0000 (UTC) Raw View
Gabriel Dos Reis wrote:
....
> Were there any standard library before we got the Standard? <g>
Yes, if by "the Standard" you mean the ISO C++ standard. There was the C
standard library, which has been a part of the C++ environment from the
very beginning. Of course, the very beginning pre-dates even the first
official C standard. But even before then there was still a standard
library, even if it was a de-facto standard, rather than a de-jure one.
Like most de-facto standards, there were LOTS of variations.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Thomas Mang <a9804814@unet.univie.ac.at>
Date: 22 Dec 02 04:14:41 GMT Raw View
"David B. Held" schrieb:
> "Grex" <tiff_master@yahoo.com> wrote in message
> news:a6150b7f.0212140326.45196cf4@posting.google.com...
>> For many years now enterprise business application development
>> has been the core area for the use of C++.
>> Today a significant share to this segment has already been lost to
>> SUN's Java technology and with MS now abandoning C++ in favour
>> if its proprietery .NET and C# technology, how long can we except
>> C++ to hold on against these might competitors?
>> Has C++ become a dying language?
>> What is the future of C++?
>
> The fact of the matter is, C++ always has and will continue to hold a
> place among languages that emphasizes performance as well as
> elegance and ease of use. Most of the trendy new languages are very
> similar to each other in that they buy programmer simplicity at
> run-time.
> For applications where that is acceptable, those languages may gain
> ground. But that will not be acceptable for all applications, and C++
> will continue to dominate that field. Consider also the massive
> installed
> codebase of C/C++, and show me a comparable number of Java or C#
> libraries. Yes, you can link to those C++ libraries from most
> languages,
> but A) people still *write* the libraries in C/C++, and B) there are
> certainly a large number of useful libraries that are *only* usable in
> C++.
But what is true is that the strength of C/C++ is not what the current
trend
is.
One main advantage of C was a programming language portable to most
systems,
but still very fast. Still back then, code in assembler language was
written to
get the most out of the CPU or memory (literally, every byte saved was
a very
good byte).
I've read about a cost/reward - comparison about programming in
low-level
languages (primarily assembler back then) and hardware upgrade.
The result was that in the earlier days up to the 80's, it was
generally more
cost-efficient to program in assembly than to buy new hardware.
However, the
trend changed more and more towards hardware upgrades, and I think it
was at
the end of the 80's(according to the article), upgrading hardware became
finally cheaper. This trend is still going on, the spread being
certainly much
wider and still widening.
As a result, I think today programming in assembly has become much less
(in
percent). Because the high-performance did not pay for the drawbacks of
non-portability, maintainability, development time (and thus effort and
cost).
Instead, higher level languages (like c++) became more prominent
Personally, I see similarities between the shift back then and today.
One main
focus (note: I don't have any statistics, nor will I use words like
'most
focus'. I am just telling what I see happening around me) today is
towards RAD,
portable web applications and so on. All these projects use, to a high
degree
complex hierarchies (like communication, GUI, threads ...) at the top
level. As
a consequence, languages already capturing all these libraries as core
elements
became more popular.
The "speed" C++ can achieve is, assuming you are not using a museum
machine,
not that important for the front end of these applications.(what does a
high-performance application help when the bottle neck is a
communication line,
or a screen? Screen refresh rates did not boost up as much as RAM or CPU
power).
Certainly, at the lower level (where performance really matters), C++
is a
high-candidate language. But how long will the performance be really
needed at
these lower levels for the main apps (okay, already written libraries
will
probably still be highly used, but IMO just as an implementation
detail)?
Now the similarity presented "graphically":
high-perf. requ. dev. time / maintain. focused
70/80s: assembler C (and certainly some others)
90s: C, C++, Java, Perl, python, scripting
languages.....
assembler not present in the 90s (assuming we are showing the "top" used
languages). Will C++ fade the same way?
I wouldn't wonder if the performance C++ can provide is not considered
important any more for the vast majority of projects in some years.
Also, the trend has already reached C++ (and is even implemented at
it's core;
as an OO oriented language (yes, not only OO, but OO is one orientation)
supporting RTTI, polymorphism.....) at a standard-level, and to a
certain
degree at programmer level(e.g. handling sytem resources pretty
liberately,
much more liberately ('wasteful' comes to mind) than would be actually
required
just taking some discipline. Indeed, today's hardware allows such
"freedom"
much more than the hardware years ago. In such cases, languages with
garbage
collection and other memory control feeatures can truely be less memory
consuming).
But today, as important as standardization is (I am pro it), it does
currently
not provide the features for state-of-the-art (and even some-state-ago-)
applications.
Who of us ships console applications? (apps that use only features
provided by
the standard)?
I dare to say, few.
Most applications today have a GUI part, threads, communication. For
them,
different frameworks (and whole development tools) exist, but not
standardized
(and thus only limited portable). Here is exactly the point where Java,
python
and their colleagues come into play with their benefits.
At the lower levels, C++ is certainly dominant. But some decades ago,
assembler
was also quite dominant at the low levels, but not that much any more.
Everybody can guess now what role, using linear extrapolation, C++ can
have in
some decades.
So I conclude: As long as the C++ language as a whole standardized
language
itself does not try to catch up (GUI, threads, communication, ...), it
will
miss the future trend, and as a consequence, popularity / importance.
That does not mean C++ will die; Indeed, I think this event will be
beyond the
pragmatic consequences for most of us (if ever). But I think well it
loses it's
place at the center, and rather be "damned" to a niche at the edge.
regards,
Thomas
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: shannon.barber@myrealbox.com (Shannon Barber)
Date: 22 Dec 02 04:20:31 GMT Raw View
"Electric Ninja" <noway@jose.dude> wrote in message
news:<kqzL9.121606$%p6.13150004@twister.neo.rr.com>...
> As long as there are computer games begging for speed and midlevel
> subsystems needing to be created, C++ will remain popular. Not to
> mention
> legacy code and the joy of flexibility. Relax.
This is not forward-looking with the industry. 20 years ago if you
wanted to make a game, you had to write it in assembly. 10 years ago
you could write it in C. Today you can use C++ on many platforms,
though still not all (GBA is the oft quoted exception).
Let me try to remember the quote.... "Blessed are the game
programmers, for they shalt not have to deal with legacy file
formats." Legacy game code is not valuable. It is often platform
specific and features & flexibility are commonly sacrificed for speed.
It's easy to decide to make the next game in a new language iff the
development team is comfortable with it. Though Carmack continues to
develop in C, the rest of the DooM III team finished the game using
C++. You can see in the future how some portion of the game could be
written in C or C++ then finished using C#. They already have to
distribute a bunch of support files to install (OpenGL and/or
DirectX), so adding the .Net CRT to the list isn't a huge issue.
The only liability with using a platform such as Java (they are
working on or may have recently released a game SDK) or .Net is the
garbage collector. It is an unacceptable liability for hard-time
systems, but games are soft-time so it's exceedingly annoying not
catastrophic. (And before anyone starts jumping up&down about how
"fast" the new garbage collectors are, what really matters is how long
the collection stalls are and unless the de/allocations take less than
200ns I wouldn't be impressed anyway.)
The vast majority of the code that has to be fast is now implemented
in hardware. You just need to dynamically-configure it with software.
It's quite feasible to make a game in Visual Basic 6 or C# (now that
Dx9 has been released). It's not going to go head-to-head with
Quake4, but achieving an acceptable level of performance shouldn't be
difficult if you don't shoot-for-the-moon.
Once the graphics pipeline was sealed in silicon, the attention turned
to audio. Now several decent 3D hardware audio cards are available.
There two areas with high-processing demand left, AI and physics. If
those go to silicon, then games will essential be scripts for the
hardware engines. You could use just about any language if this ever
happens (an interpreted one may still be too slow).
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: shannon.barber@myrealbox.com (Shannon Barber)
Date: 22 Dec 02 04:21:07 GMT Raw View
"Carl Daniel" <cpdaniel@nospam.mvps.org> wrote
>> and with MS now abandoning C++ in favour if its
>> proprietery .NET and C# technology
>
> Rubbish. Microsoft has a stronger commitment to C++ than ever before.
> C++
> is the premiere .NET language, with capabilities that no other .NET
> language
> can match.
>
C++ is clearly not the premiere .Net language. You could attempt to
figure out if it's VB.Net or C#, but it is not C++. There's no
dynamic-code compilation for C++/ME like there is for VB & C#, support
for everything in C++ was given a lower priority (such as WinForms,
though it is due in 2003Q1).
It remains to be seen if C++ makes a good language to use with .Net,
but it seems plausible (much like OLE automation, it's far easier with
VB, but you can do it with C++).
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Sun, 22 Dec 2002 07:11:15 +0000 (UTC) Raw View
In article <86bs3gh1il.fsf@Zorthluthik.foo>, llewelly
<"llewelly."@?.dot.com.invalid> writes
>What about moving everything in the standard library into std:: ?
> That's done, not in the pipeline, but it does seem (to me) to be a
> similar case.
Not really because adding using namespace std was almost a complete fix.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Sun, 22 Dec 2002 07:11:15 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote
> >> I'd argue that if your code isn't publicly visible, you
> >>should't expect it to be protected against future language
> >>changes. If a change is proposed, the universe of
> >>source code available without an NDA should be examined
> >>for conflicts to see how serious the problem is. (This
> >>would include not just open source, but everything you
> >>get with a MSDN subscription, for example.) If there's
> >>no serious conflict in that body of code, the change
> >>is reasonable.
> Allan W wrote:
> > But your point is valid one. I especially like your first
> > statement, but I'd point out that you CAN protect your code
> > from future language changes today....
> To make this more concrete, consider the following changes:
>
> -- Disallow overriding of a non-virtual function.
> -- Disallow delete of const pointers.
> -- Disallow "delete this".
>
> These are all things that are usually errors.
> Suppose we examined some large body of code, and
> determined that N% of the time these situations
> came up, they were errors. How high would N have
> to be to justify the change? 90%? 99%? 99.99%?
> 100%?
For the first one, I'd hate to see this become literally an error --
it would be a good idea for the compiler to issue a warning, but then
it should go ahead and accept the code anyway. Neccesary because there
is no workaround if this becomes illegal.
For the other two, I'd go with a fairly low threshhold -- perhaps the
90% that you suggest. The reason is that the code can trivially be
changed to accomplish the same thing in ways that do not trigger the
error message (i.e. with a cast). Of course, good compilers will
support legacy code by allowing the code anyway, perhaps with a
compiler switch to say so.
For comparison purposes, more and more compilers will currently flag
this code
if (a=b) {
with a warning message because it uses assignment instead of comparison.
The code will compile correctly despite the warning message; also, even
without any compiler switches, the code can trivially be reformatted to
avoid the warning by writing it as
if (!!(a=b)) {
which has the same semantics and probably optimizes to the same code anyway.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Sun, 22 Dec 2002 07:12:13 +0000 (UTC) Raw View
Matt Austern wrote:
> nagle@animats.com (John Nagle) writes:
>
>
>> To make this more concrete, consider the following changes:
>>
>>-- Disallow overriding of a non-virtual function.
>>-- Disallow delete of const pointers.
>>-- Disallow "delete this".
>>
>> These are all things that are usually errors.
>>Suppose we examined some large body of code, and
>>determined that N% of the time these situations
>>came up, they were errors. How high would N have
>>to be to justify the change? 90%? 99%? 99.99%?
>>100%?
>>
>
> For those changes, my personal opinion is that N would have to be very
> close to 100%.
I posed that question to get a reading on how people
feel about feature deletion. Now I know.
What this means is that there's little hope of removing
any of the cruft from C++. Which is a problem. C# and
Java were created not to add features, but to make some
of the uglier ones of C++ go away.
C++ could be a considerably cleaner language with
some cleanup. The price of entry for new C++ programmers
could be lowered substantially. But there is little
sentiment here for making that happen.
This is unfortunate.
It's particularly striking that there's a sizable
community of people who stay with ANSI C, and don't
use C++, even though their compiler will compile C++.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: a9804814@unet.univie.ac.at (Thomas Mang)
Date: Sun, 22 Dec 2002 07:12:40 +0000 (UTC) Raw View
Matt Austern schrieb:
>
> Sure, any changes that involve adding a new keyword. (Technically I
> suppose we could add keywords that aren't in the user namespace, like
> WG14 did with _Bool and _Complex, but I haven't seen any support for
> that sort of thing. My impression is that most folks on the Committee
> find it a bit distasteful.)
>
> I think that 'restrict' is likely to make it into a future version of
> C++. That'll break every program that uses that word as an
> identifier.
That's true if the code is taken to the new compiler version and compiled.
If implementations are required to ship a diagnostic tool to
a) convert automatically code whenever this is 100% doable and safe
b) inform clients about conflicts between the C++ - version "the code was
programmed in" and the new C++ version, so they can fix it manually (maybe
semi-automatically).
In conjunction with the built-in lexer/parser, this should be
straightforward. IMO, all the C-sytle casts should have been easily
transformble to the C++-style casts(static_cast, const_cast,
reinterpret_cast). And the same with other stuff too.
What's left would be a directive at the start of each code file (maybe
automatically added by the compiler) that inserts the C++-version of the
written code.
Along with that information, implementations could also store some sort of
(standardized) extra information about standard conformance. Like:
#pragma cppversion Cpp98__no_namespace_std____no_cpp_casts.
to accomodate the fact not all implementations are fully standard conformant
and have to do some diagnostics later when the feature is implemented.
(Okay, I admit few implementations will like to publicly announce their
lacks. OTOH, this is not thought to report "bugs", just the major lacking
features, which every experienced programmer will find out quite soon
anyhow.)
best regards,
Thomas
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: philippe_mori@hotmail.com ("Philippe Mori")
Date: Sun, 22 Dec 2002 07:13:05 +0000 (UTC) Raw View
It works fine as long as we can make the old code compatible so that old
compiler can still compile it...
For example implicit would not have been a problem since we can do the
following:
1) Find and remplace any implicit in code and remplace it by something
else. Also ensure that the replacement is wanted (in case the file is run
twice in the converter) and that it won't cause any new conflict (if the
replacement word happen to be already used).
2) Have a way to tell that the compiler support a feature. If not, define
implicit as nothing so that new code will be equivalent to old code on old
compilers...
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Greg@Brewer.net ("Greg Brewer")
Date: Sun, 22 Dec 2002 07:13:36 +0000 (UTC) Raw View
I read most of this thread. Alot anyway. I saw a lot to respond about but
I don't want to write half a dozen individual postings.
> Grex wrote:
> > For many years now enterprise business application development has
> > been the core area for the use of C++.
> > Today a significant share to this segment has already been lost to
> > SUN's Java technology and with MS now abandoning C++ in favour if its
> > proprietery .NET and C# technology, how long can we except C++ to hold
> > on against these might competitors?
I'm not sure in this area. I see definite advantages to C++: templates,
multiple inheritance, and control over object lifetimes are three that come
to mind. On the other hand, the ones making the decision about language to
use in a new project don't seem to be programmers. I don't know about
nationally but in my locality the demand for C++ programmers is weak; most
positions I see require experience with Java, C#, or JavaScript.
> > Has C++ become a dying language?
Maybe. It would help if the standards committee could come up with some
extensions that could excite the people deciding the language of choice.
I've been reading up on how to program in these newer languages. Most of
what I read is exactly the same as in C++. Most of the rest has an exact
equivalent in C++. We need to discover what these other languages provide
and make sure was can supply the same functionality.
Someone else suggested optional standard libraries. I think this is a
wonderful idea. If done though, it needs to be done in a manner that allows
the compiler publisher to tout this. Maybe "C++/Web Edition".
> > What is the future of C++?
No idea. Right now, I'm pessimistic. 10 years ago, I was having trouble
finding employment because all my skills were mainframe and employers wanted
microcomputer. Now that I have 9 years microcomputer experience, everyone
wants other languages.
Greg Brewer
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: lutherbaker@yahoo.com (Luther Baker)
Date: 22 Dec 2002 07:52:14 -0500 Raw View
news:<a6150b7f.0212140326.45196cf4@posting.google.com>...
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
I have a tendency to sound critical - and thats NOT what I'm doing
here. Your questions seem to be posed by many people lately. So in
advance, forgive me, but I'd like to throw in my $0.02 and suggest
something here.
Imagine any computer system divided into layers. At the lowest layer,
we have hardware, the next layer might be machine language
instructions, the next layer might be assembly language, the next
layer might be C/C++ or fortran etc., and up a few more layers - we
have frameworks such as .net and J2ee. Now, there's no way around
these layers. The machine only understands machine language, etc.
Herein lies why C/C++ is far from a dying language.
Its currently the best interface we have as programmers to get close
to the hardware and make the higher, popular frameworks a practical
reality. ".net" and Java can be built in C/C++. C/C++ are plumbing
languages. You have (almost) complete control over the hardware,
memory allocation, binary representation, etc. True, the role of C/C++
has surely changed - as new programming frameworks have creeped in ...
and there are even lower languages (assembly in your C/C++) but
realize that most modern frameworks can be (were) written in C/C++.
Eventually - you have to talk directly to the machine and there isn't
a more user friendly way to do that right now. The future of C++ is
unknown, but until intel starts executing Java bytecodes natively,
there just isn't a more powerful development tool/Object Oriented
abstraction over the computer hardware.
Futhermore, C/C++ wasn't built specifically for distributed computing,
memory managed enterprise applications. No, instead, you use C/C++ to
build these frameworks yourself. If you can think it, you can build it
in C/C++. Remember, the entire Windows operating system was written in
C. The Unix operating system is written in C. Native Java and .net
frameworks are written in C/C++. Without C/C++, .net and Java teams
would have to start writing their frameworks in assembly or machine
code ... ick. I don't think so.
I think people often mis-understand something here. True, C/C++
doesn't have automatic garbage collection - but it shouldn't. If you
want that, you must write it. C/C++ was designed to be a user friendly
abstraction over the computer hardware. Just because it was the
enterprise language of choice at one time, doesn't mean thats its
singular calling. Fundamentally, C/C++'s value has remained unchanged.
Maybe there's space out there for another intermediary language that
does include automatic garbage collection - while maintaining a close
posture with the hardware. Sounds good! That'd be great. But for now,
C/C++ is what it is. Nothing more, nothing less. Bjarne's idea to
provide an Object Oriented programming paradigm over the hardware did
not include making garbage collection decisions for the developer.
Programmers are individually responsible for that next level. The
libraries, the containers, the memory management. That's why it takes
large companies like SUN and Microsoft to role out these new
frameworks. Had Bjarne included GC, he would only have been narrowing
the scope of C/C++. Instead, you as a developer decide on an algorithm
and build smart pointers and use your GC. There are plenty of people
that have done this. SUN went so far as to say not only do we want GC,
but here's a host of other things - classloaders, JVM, write-once run
anywhere ... but its all still just a subset of C/C++.
I can't predict the future - but I can guess that most high level
software design/architecture advances will probably come from the high
level Java, J2EE and ".net" abstractions and most tricky, idiomatic,
native, language specific patterns will be realized in C/C++. C/C++
may become the tool of choice for hardcore programmers and engineering
scientists as well as students or performance based industries like
Fighter Jets. I'd agree that it just it'd be silly to ignore the
advances made with the new distributed frameworks when writing
something, like, say a distributed information application.
But again, the beauty and lifetime of C/C++ exists in its incredible
potential to build anything - and talk directly to the hardware to
make it happen exactly as you say. To get any closer, you'd have to
manually get down and alter the intel instruction set.
Until we have hardware that executes Java natively (probably soon)
C/C++ still presents the best interface for a programmer to do
everything from writing small, extremely fast code to native local
applications to creating these magnificent distributed, memory managed
frameworks that SUN and MS so adamantly adore. From students to
advanced engineering scientists/programmers to new corporations
building competitive frameworks - it will probably remain the language
of choice for a little while longer.
-Luther
Finally - in regards to your comment
"how long can we except C++ to hold
> on against these might competitors?"
it begs to be mentioned that MS and SUN both have vested interests in
the languages/frameworks that they are pushing. C++ was never "sold"
to the public in the fashion of Java and ".net". C/C++ was grounded in
OO theory and scientific research and became the great language it is
today soley on its own merits. Bjarne and SWB are to be commended for
their efforts of past.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: busysteve@yahoo.com (Stephen Mathews)
Date: 22 Dec 2002 08:54:24 -0500 Raw View
tiff_master@yahoo.com (Grex) wrote in message news:<a6150b7f.0212140326.45196cf4@posting.google.com>...
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
>
> [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
> [ about comp.lang.c++.moderated. First time posters: do this! ]
>
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
I work in a multi-language environment and am one of the few who use
'em all. My first choice is C++ for everything 'cause I've been using
it happily since '96 (I started in '95 but that whole OO thing took me
a year to get). With all the developers I work with VB is the
majority Java comes next, Perl, etc.. C++ is viewed as something like
guru-hood. Some black art practiced in dark places. I think
languages like Java and C# only have the advantage of being pushed via
marketing. Remember, the true purpose of marketing is to make one
desire. That's the only thing that sets 'em apart, from a high-level
viewpoint. As I evangelize about C++ I've managed to remove the dark
shroud for some. I think if we all do that this question that started
this whole thing wouldn't be.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Herb Sutter <hsutter@gotw.ca>
Date: 22 Dec 2002 08:58:22 -0500 Raw View
>"Grex" <tiff_master@yahoo.com> wrote in message
>news:a6150b7f.0212140326.45196cf4@posting.google.com...
>> Has C++ become a dying language?
>> What is the future of C++?
These are excellent questions worth discussing, but I disagree with most or
all of the assumptions that preceded the questions. I'll speak to just one
of them in particular from personal knowledge:
>> and with MS now abandoning C++ in favour
>> if its proprietery .NET and C# technology
I really feel the need to correct this misimpression. That's completely
untrue, although I don't blame people for getting that wrong idea after
being blasted with a lot of C# marketing. Considerable internal .NET (i.e.,
not just native) development at Microsoft is being done in C++.
Just to be excruciatingly clear about this, Microsoft is not abandoning C++.
Rather the opposite: I know of no company today that is making as large an
investment as Microsoft in active and ongoing development of its C++
products. That's one of the reasons I chose to come here; it's where a lot
of the C++ action is. And I don't mean just for the (alas long-overdue)
catchup conformance work in the 7.1 release that's about to ship, but also
for future releases' development already in progress, in particular to make
(and keep) C++ a first-class language on .NET. For more background, see my
September 2002 CUJ article:
Standard C++ Meets Managed C++
http://www.gotw.ca/publications/standard_c++_meets_managed_c++.htm
David put it well in his followup:
On 19 Dec 2002 15:10:29 -0500, "David B. Held"
<dheld@codelogicconsulting.com> wrote:
>The fact of the matter is, C++ always has and will continue to hold a
>place among languages that emphasizes performance as well as
>elegance and ease of use. Most of the trendy new languages are very
>similar to each other in that they buy programmer simplicity at run-time.
>For applications where that is acceptable, those languages may gain
>ground. But that will not be acceptable for all applications, and C++
>will continue to dominate that field.
Nicely said. Don't get me wrong, I think languages like Java and C# and Perl
and Python and others have their place and have great uses, and I'm glad
there's continuing interest in language development; it should never be a
dead field. I've always said to use the right tool for the job, including
different languages for different parts of the same project in whatever
combination makes sense. To narrow one's focus on a single language or tool
as the be-all and end-all is myopic at best; I wouldn't use C++ for
scripting, for example, just as I wouldn't use Java for writing an operating
system.
To simply write off the world's most widely used commercial programming
language because other languages are being created and marketed strikes me
as a little premature. :-) For example, Java was hyped incredibly more than
any other language has ever been, and nearly every year since 1995 saw press
reports that Java usage would surpass C++ usage in 12 to 24 months. Pundits'
picks notwithstanding, today as we are about to enter 2003, in every study
I've seen Java continues to show as a distant 3rd in commercial application
development. There's marketing and then there's what software developers are
actually doing to get their jobs done.
Returning to the original questions:
>> Has C++ become a dying language?
>> What is the future of C++?
As Scott Meyers so eloquently put it two months ago at our TCS3 event, just
as has consistently been true in the past of programming languages, C++ will
not be supplanted until a language comes along that is strong in all the
areas where C++ is strong (e.g., OO, generic programming, efficiency,
flexibility, library building) and is also strong in areas where C++ is weak
(e.g., complexity). That may take a while, because for all its complexity
C++ is quite strong in many important areas that matter to developers now
and will continue to matter in the coming years.
Herb
---
Herb Sutter (www.gotw.ca)
Convener, ISO WG21 - Secretary, ANSI J16 (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
C++ community program manager, Microsoft (www.gotw.ca/microsoft)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: hyrosen@mail.com (Hyman Rosen)
Date: Sun, 22 Dec 2002 21:53:52 +0000 (UTC) Raw View
John Nagle wrote:
> This is unfortunate.
No, it is not. You had three features you wanted removed, and
you discovered that two of them were actively used. Shouldn't
you take that as a sign that your thesis is in error? Like it
or not, C++ features interact synergistically in ways that the
community has come to rely upon. Willy-nilly removal in an
attempt to "improve" the language will just break it.
I don't know for sure, but I have serious doubts as to whether
the designers of Java and C# actually understood C++ well enough
to know what it was that they were leaving out.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: austern@well.com (Matt Austern)
Date: Mon, 23 Dec 2002 01:04:36 +0000 (UTC) Raw View
hyrosen@mail.com (Hyman Rosen) writes:
> John Nagle wrote:
> > This is unfortunate.
>
> No, it is not. You had three features you wanted removed, and
> you discovered that two of them were actively used. Shouldn't
> you take that as a sign that your thesis is in error? Like it
> or not, C++ features interact synergistically in ways that the
> community has come to rely upon. Willy-nilly removal in an
> attempt to "improve" the language will just break it.
Yes. I would judge a new feature that happened to break code much
less stringently than deliberately removing an existing feature---
that is, deliberately making a change that can have no effect other
than breaking code.
All changes have to be evaluated on their cost/benefit ratio. If I
saw a higher benefit, I'd be willing to put up with a higher cost.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: already5chosen@yahoo.com (Michael S)
Date: Mon, 23 Dec 2002 14:54:30 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote in message news:<3E03F52A.7050406@animats.com>...
> Matt Austern wrote:
>
> > nagle@animats.com (John Nagle) writes:
> >
> >
> >> To make this more concrete, consider the following changes:
> >>
> >>-- Disallow overriding of a non-virtual function.
> >>-- Disallow delete of const pointers.
> >>-- Disallow "delete this".
> >>
> >> These are all things that are usually errors.
> >>Suppose we examined some large body of code, and
> >>determined that N% of the time these situations
> >>came up, they were errors. How high would N have
> >>to be to justify the change? 90%? 99%? 99.99%?
> >>100%?
> >>
> >
> > For those changes, my personal opinion is that N would have to be very
> > close to 100%.
>
>
> I posed that question to get a reading on how people
> feel about feature deletion. Now I know.
>
> What this means is that there's little hope of removing
> any of the cruft from C++. Which is a problem. C# and
> Java were created not to add features, but to make some
> of the uglier ones of C++ go away.
>
> C++ could be a considerably cleaner language with
> some cleanup. The price of entry for new C++ programmers
> could be lowered substantially. But there is little
> sentiment here for making that happen.
>
> This is unfortunate.
>
> It's particularly striking that there's a sizable
> community of people who stay with ANSI C, and don't
> use C++, even though their compiler will compile C++.
>
> John Nagle
> Animats
>
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Agreed, 100%.
See my thread "Three features you would like to have not in C++"
(relegated to the second page now) for more of the same. There were
50+ answers criticizing my "top three" but amazingly nobody posted
three undesired features of his own. It looks like C++ folks are very
reluctant to the idea of removing something from the language. They
just don't feel that complexity in general and lack of transparency in
particular is The Problem of C++.
As it stays now, C++ holds only one major advantage over Ada-95 - the
absence of multythreading support at the language level. It would not
take me by surprise if this advantage will evaporate too in five years
to come.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: hyrosen@mail.com (Hyman Rosen)
Date: Mon, 23 Dec 2002 15:53:14 +0000 (UTC) Raw View
Michael S wrote:
> As it stays now, C++ holds only one major advantage over Ada-95 - the
> absence of multythreading support at the language level.
I don't understand. You claim that C++'s lack of
multiprogramming support is an *advantage* over Ada,
which has it?
I find C++'s automatic instantiation of templates,
and the concomitant ability to partially specialize
to be an advantage over Ada.
I find C++'s multiple inheritance to be an advantage
over Ada.
Ada types with constructors and destructors can only be
declared in library-level packages, and must inherit from
a particular base class. Constructors aren't called on
objects initialized with aggregates, so such types must
be made private to prevent users from bypassing them.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: c141592653589@hotmail.com (MJ)
Date: Mon, 23 Dec 2002 18:24:51 +0000 (UTC) Raw View
austern@well.com (Matt Austern) wrote in message news:<diladj08vk1.fsf@mattlinux.localdomain>...
...
> Sure, any changes that involve adding a new keyword.
I don't understand why adding a keyword should be an obstacle for a
new language feature. It is much easier to write a source code
converter for that than for other changes.
-- Michael
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: thp@cs.ucr.edu
Date: Mon, 23 Dec 2002 18:25:14 +0000 (UTC) Raw View
John Nagle <nagle@animats.com> wrote:
[...]
+ What this means is that there's little hope of removing
+ any of the cruft from C++. Which is a problem. C# and
+ Java were created not to add features, but to make some
+ of the uglier ones of C++ go away.
Yes, but, IMHO, the success of Java comes mainly from what was added:
- garbage collection
- graphical I/O
- reference semantics (which implies reseatable references, which
eliminates/hides the need for pointers)
- Multithreading
- etc.
+ C++ could be a considerably cleaner language with
+ some cleanup. The price of entry for new C++ programmers
+ could be lowered substantially. But there is little
+ sentiment here for making that happen.
+
+ This is unfortunate.
Agreed. And, if I understand correctly, there is precedent within the
history of C for what ought to happen. My understanding is based on a
talk by Steve Johnson on the portabilzation of C that I heard about 20
to 25 years ago -- any inaccuracies are the result of my
misunderstandings and faulty memory.
IIRC, when C was first introduced it was mostly viewed as a
replacement for PDP-11 assembly language. The compilers did not
enforce type restrictions and programmers used C pretty much the way
they would an assembler, without regard to types. When Steve
developed the Portable C Compiler, he found that he had to take a much
more highly typed "Pascal-like" view of data. Management and
colleagues would not allow the compiler to enforce such a view since
it would break too many economically significant programs --- hence
the developement of lint, a static analysis tool. In effect, lint
defined a portable subset of the language and deprecated dangerous and
unportable constructs. A decade or so later, the standardization
process attached "undefined behavior" to many of those constructs.
So, what should happen in the case at hand? Let's take C-style
strings as a concrete example. The Committee has taken the
appropriate first step by introducing C++-strings. The next step
might be to deprecate C-style strings and maybe encourage/require
implementations to have a mode where they issue warnings upon use of
deprecated constructs. Later, the standard might attach undefined
behavior to the reading or writing of C-stings. In any case, breaking
that much existing code at the current time is not acceptable.
+ It's particularly striking that there's a sizable
+ community of people who stay with ANSI C, and don't
+ use C++, even though their compiler will compile C++.
Agreed. It upsets C die-hards when it's pointed out that most C
programs are C++ programs. They are programming in C++ whether they
like it or not. The question is not "whether to use C++" but rather
"which, if any, C++ extensions to use". Particularly within the
operating-systems community, there is a prevalent opinion that
compiling with a C++ compiler will necessarily bloat and slow their
code. "Exception handling is turned on whether you use it or not, and
surely that has to take up time and space."
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: c141592653589@hotmail.com (MJ)
Date: Mon, 23 Dec 2002 18:26:05 +0000 (UTC) Raw View
austern@well.com (Matt Austern) wrote in message news:<dilof7h4as5.fsf@mattlinux.localdomain>...
> nagle@animats.com (John Nagle) writes:
> >
> > What are the criteria? Are they written down somewhere?
>
> No. It's a judgement call, it'll have to be considered on a case by
> case basis, and I'm sure that not every committee member will use the
> same criteria. Some of the relevant questions to ask: how much code
> is likely to break, whether it will break quietly or noisily, whether
> it's easy to fix the breakage.
austern@well.com (Matt Austern) wrote in message news:<dil3cos8umf.fsf@mattlinux.localdomain>...
> Maybe the decision we made was right, maybe it was wrong, but I'd
> rather not reopen settled decisions unless there's new information
> that wasn't available at the time the decision was originally made.
If neither the criteria nor the reasonings for a decision are written
down somewhere, and it is not possible to reopen a settled decision,
then we are in a dilemma. Beyond new information which wasn't
available at the time I could imagine that a different point of view /
changed priorities play a role, for instance the emphasis on the fact
that the majority of the programmers are beginners, and that the
language should be enabled to improve the learning curve by issuing
more errors and warnings.
> For all three changes, the answer is that no new programming
> techniques are made possible. We would get better diagnostics if
> users do something wrong accidentally, and that's it. And, of course,
> compiler vendors can already give diagnostics for code that they think
> is more likely to be wrong than right. Legal code that might not be
> what the programmer really meant is just what warnings are for.
But if it is up to the vendors then warnings will differ from compiler
to compiler. The next thing is, that it is necessary to have the
option to suppress the warning locally (for indicating that a certain
part of the code is written down intentionally - example: type casts).
Should that be done by vendor specific #pragmas? I don't think so. A
standardization is needed here.
> For the second proposed change there's an easy mechanical way for
> users to fix code that was broken by the change. For the first and
> the third, there isn't. I've only rarely written 'delete this', but
> every time I have, it's because I couldn't think of any way to
> redesign my program to avoid 'delete this' or the moral equivalent.
> (By which I mean things like 'p = this; delete p;'. If you're allowed
> to get around a ban on 'delete this' by a simple spelling change, then
> I'd say there's no point to having the ban in the first place.)
> Similarly, there are some useful techniques, especially involving base
> classes that are templatized on classes that inherit from them, that
> are only possible because of the ability to override non-virtual
> member functions.
>
> I can easily believe that these features are more often used
> incorrectly than correctly. But if there's no good substitute for
> them in the cases where they are used correctly, then getting rid of
> them would make C++ a less useful language.
It is not necessary to ban a technique or feature in order to avoid
unintended behaviour. Just make the abuse more difficult.
I think, there should be put more effort into developping strategies
for migrating code from one standard to the next, rather than
focussing too much on keeping things compatible.
-- Michael
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kuyper@wizard.net ("James Kuyper Jr.")
Date: Mon, 23 Dec 2002 18:26:39 +0000 (UTC) Raw View
John Nagle wrote:
....
> What this means is that there's little hope of removing
> any of the cruft from C++. Which is a problem. C# and
> Java were created not to add features, but to make some
> of the uglier ones of C++ go away.
There has to be a language that worries a lot about backward
compatibility; C++ is that language. There should also be languages that
move beyond the limits imposed by backward compatibility. And someday,
one of those languages will become more popular than C++. That's life
(for a computer language). But I wouldn't start writing up the obituary
for C++ just yet.
....
> It's particularly striking that there's a sizable
> community of people who stay with ANSI C, and don't
> use C++, even though their compiler will compile C++.
Believe it or not, there can be sound, intelligent reasons for doing so.
But this isn't the right newsgroup for discussing those reasons.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kuyper@wizard.net ("James Kuyper Jr.")
Date: Mon, 23 Dec 2002 18:26:44 +0000 (UTC) Raw View
Greg Brewer wrote:
....
> Maybe. It would help if the standards committee could come up with some
> extensions that could excite the people deciding the language of choice.
Let language vendors come up with the extensions; then the committee can
bless them. And there have been a fair number of popular extensions that
the committee should be blessing.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gdr@integrable-solutions.net (Gabriel Dos Reis)
Date: Mon, 23 Dec 2002 18:27:24 +0000 (UTC) Raw View
kuyper@wizard.net ("James Kuyper Jr.") writes:
| Gabriel Dos Reis wrote:
| ....
| > Were there any standard library before we got the Standard? <g>
|
| Yes, if by "the Standard" you mean the ISO C++ standard.
Would you mind giveing concrete references?
Before we got an ISO standard, the ARM wa the facto standard. And the
ARM described no standard library.
And the ARM wasn't legistating about C. It was concerned with *C++*.
--
Gabriel Dos Reis, gdr@integrable-solutions.net
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gdr@integrable-solutions.net (Gabriel Dos Reis)
Date: Mon, 23 Dec 2002 18:27:32 +0000 (UTC) Raw View
francis.glassborow@ntlworld.com (Francis Glassborow) writes:
| In article <86bs3gh1il.fsf@Zorthluthik.foo>, llewelly
| <"llewelly."@?.dot.com.invalid> writes
| >What about moving everything in the standard library into std:: ?
| > That's done, not in the pipeline, but it does seem (to me) to be a
| > similar case.
|
| Not really because adding using namespace std was almost a complete fix.
And if he was talking about C headers <xxx.h>, programs that used them
can still continue to use them without adding any explicit std::
qualification.
--
Gabriel Dos Reis, gdr@integrable-solutions.net
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Mon, 23 Dec 2002 18:31:56 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote in message
news:<3E02AEFA.6020405@animats.com>...
> Allan W wrote:
> > nagle@animats.com (John Nagle) wrote
> >> I'd argue that if your code isn't publicly visible, you
> >>should't expect it to be protected against future language changes.
> >>If a change is proposed, the universe of source code available
> >>without an NDA should be examined for conflicts to see how serious
> >>the problem is. (This would include not just open source, but
> >>everything you get with a MSDN subscription, for example.) If
> >>there's no serious conflict in that body of code, the change is
> >>reasonable.
> > But your point is valid one. I especially like your first statement,
> > but I'd point out that you CAN protect your code from future
> > language changes today....
> To make this more concrete, consider the following changes:
> -- Disallow overriding of a non-virtual function.
> -- Disallow delete of const pointers.
> -- Disallow "delete this".
> These are all things that are usually errors.
Are they?
The first is used in the standard library, in the iostream hierarchy.
Anyone who has ever gotten a streambuf from a specific subclass of
istream or ostream has used it. Without it, I'd need a dynamic_cast
when reading a filebuf or a stringstream buf, with a run-time error
instead of a compile time error. Not a good trade-off, IMHO.
I don't personaly use the second, but some people fought hard to get it
in. It was forbidden by the ARM. Apparently, some people are using it;
otherwise, there would have been one less accrimonious dispute in the
standards committee.
And the third is probably used in about a third of my own classes.
> Suppose we examined some large body of code, and determined that N% of
> the time these situations came up, they were errors. How high would N
> have to be to justify the change? 90%? 99%? 99.99%? 100%?
It would doubtlessly depend on the large body of code. From a selfish
point of view, if you examine all of my code, and it isn't used, then
who needs it:-). Although... Some eight or ten years ago, when Java
was being formulated, I'd have probably said yes to banning private
virtual functions. Today, most of my virtual functions are private.
What makes C++ strong, I suspect, is that the authors haven't tried to
second guess what the future will want.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Mon, 23 Dec 2002 19:47:34 +0000 (UTC) Raw View
<thp@cs.ucr.edu> wrote in message news:au48m3$k3c$1@glue.ucr.edu...
> + It's particularly striking that there's a sizable
> + community of people who stay with ANSI C, and don't
> + use C++, even though their compiler will compile C++.
>
> Agreed. It upsets C die-hards when it's pointed out that most C
> programs are C++ programs. They are programming in C++ whether they
> like it or not.
It doesn't upset me. But it does seem to upset C++ die-hards when
it's pointed out that many C++ programs are C programs.
OTOH, it really annoyed me to discover one day that I had been
speaking prose all my life.
> The question is not "whether to use C++" but rather
> "which, if any, C++ extensions to use". Particularly within the
> operating-systems community, there is a prevalent opinion that
> compiling with a C++ compiler will necessarily bloat and slow their
> code. "Exception handling is turned on whether you use it or not, and
> surely that has to take up time and space."
Y'know, I still believe that myself to this day. Perhaps it's because
nobody has shown me a compiler that really does support exceptions
with zero time and space overhead, or that optimizes away all
exception handling code in a program with no catch clauses.
Meanwhile, we continue to make money licensing a C++ library that can
avoid all use of exceptions, for those unreconstructed people who think
that might be important.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Mon, 23 Dec 2002 19:55:21 +0000 (UTC) Raw View
"Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote in message
news:m3lm2h27nu.fsf@uniton.integrable-solutions.net...
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> | Gabriel Dos Reis wrote:
> | ....
> | > Were there any standard library before we got the Standard? <g>
> |
> | Yes, if by "the Standard" you mean the ISO C++ standard.
>
> Would you mind giveing concrete references?
>
> Before we got an ISO standard, the ARM wa the facto standard. And the
> ARM described no standard library.
Perhaps not, but the library that shipped with cfront certainly defined
a de facto standard, to the point that several other vendors copied it
bug for bug. Moreover, for the first few years of its work the library
subcommittee of X3J16 was aiming for *binary* compatibility with the
cfront iostreams library. In the end, they destroyed even *source*
compatibility.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Mon, 23 Dec 2002 23:29:37 +0000 (UTC) Raw View
"MJ" <c141592653589@hotmail.com> wrote in message
news:423c153c.0212220257.450260ca@posting.google.com...
> austern@well.com (Matt Austern) wrote in message news:<diladj08vk1.fsf@mattlinux.localdomain>...
>
> ...
> > Sure, any changes that involve adding a new keyword.
>
> I don't understand why adding a keyword should be an obstacle for a
> new language feature. It is much easier to write a source code
> converter for that than for other changes.
Unless you happen to have a code base of several million lines of
code. Or have hundreds of customers who do...
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: already5chosen@yahoo.com (Michael S)
Date: Mon, 23 Dec 2002 23:44:35 +0000 (UTC) Raw View
hyrosen@mail.com (Hyman Rosen) wrote in message news:<1040658320.568779@master.nyc.kbcfp.com>...
> Michael S wrote:
> > As it stays now, C++ holds only one major advantage over Ada-95 - the
> > absence of multythreading support at the language level.
>
> I don't understand. You claim that C++'s lack of
> multiprogramming support is an *advantage* over Ada,
> which has it?
>
Yes. It is an advantage.
And the absence of garbage collection support *at the language level"
is a major advantage over Java/C#.
Ah, If it only was possible to drop memory management support *at the
language level* ! Wet dreams.
By good ole "C" virtue things like thease are supported at the level
of standard library. Or better optional standard library. Or de-facto
standard library.
I have the impression that the whole idea of imrovement by removing
features rather than adding more and more is a little too oriental for
you and many many other posters.
> I find C++'s automatic instantiation of templates,
> and the concomitant ability to partially specialize
> to be an advantage over Ada.
>
> I find C++'s multiple inheritance to be an advantage
> over Ada.
Plenty of OOP experts would disagree. I personally have no opinion.
>
> Ada types with constructors and destructors can only be
> declared in library-level packages, and must inherit from
> a particular base class. Constructors aren't called on
> objects initialized with aggregates, so such types must
> be made private to prevent users from bypassing them.
>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: David Abrahams <dave@boost-consulting.com>
Date: Tue, 24 Dec 2002 00:37:09 CST Raw View
pjp@dinkumware.com ("P.J. Plauger") writes:
>> The question is not "whether to use C++" but rather
>> "which, if any, C++ extensions to use". Particularly within the
>> operating-systems community, there is a prevalent opinion that
>> compiling with a C++ compiler will necessarily bloat and slow their
>> code. "Exception handling is turned on whether you use it or not, and
>> surely that has to take up time and space."
>
> Y'know, I still believe that myself to this day.
And even I, who you might not expect to hear it from, was going to say
that it's true.
> Perhaps it's because nobody has shown me a compiler that really does
> support exceptions with zero time and space overhead,
And they never will. Zero time overhead in the non-exceptional case
is possible today, and can be demonstrated it for small programs.
Zero space overhead is not. The logic for EH functionality has to go
somewhere!
> or that optimizes away all exception handling code in a program with
> no catch clauses.
That one can be done for certain trivial programs, but those
"unreconstructed" types you mention below who care about every byte
and cycle will have to start using exceptions and demanding better
implementations before it ever happens for nontrivial programs (it
ain't gonna happen). It's a vicious cycle.
In general, even the most-efficient EH implementations today have room
for considerable optimization.
> Meanwhile, we continue to make money licensing a C++ library that can
> avoid all use of exceptions, for those unreconstructed people who think
> that might be important.
--
David Abrahams
dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Matt Austern <austern@well.com>
Date: Tue, 24 Dec 2002 00:37:25 CST Raw View
c141592653589@hotmail.com (MJ) writes:
> austern@well.com (Matt Austern) wrote in message news:<diladj08vk1.fsf@mattlinux.localdomain>...
>
> ...
> > Sure, any changes that involve adding a new keyword.
>
> I don't understand why adding a keyword should be an obstacle for a
> new language feature. It is much easier to write a source code
> converter for that than for other changes.
It isn't necessarily an obstacle. As I've said, the committee will
almost certainly consider some new keywords. But we'll do that
knowing that we'll be breaking some user code.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kuyper@wizard.net ("James Kuyper Jr.")
Date: Thu, 26 Dec 2002 08:39:11 +0000 (UTC) Raw View
thp@cs.ucr.edu wrote:
....
> Agreed. It upsets C die-hards when it's pointed out that most C
> programs are C++ programs. They are programming in C++ whether they
> like it or not. ...
Many C programs can also be compiled as C++ programs, most of them with
almost exactly the same behavior. That doesn't mean that the C
programmer is programming in C++. The C programmer is not spending any
time thinking about about all of the C++ alternatives to C constructs,
because the compiler won't be being used in a mode where it will
recognize those alternatives.
"Good milk and good cheese is good English and good Fries" is a
traditional saying that emphasizes how similar English and Friesland
Deutsch are; it has exactly the same meaning in both languages. That
doesn't mean that I'm necessarily speaking Friesland Deutsch when I
utter that sentence.
In the near future, C programs are going to start sprouting features
that made it into the C99 standard, that aren't in C++ yet: 'restrict'
qualification, size-named integer types, VLAs, type-generic math (which
isn't quite the same as C++ function overloads), designated
initializers, an implementation of complex arithmetic that is
considerably less than completely compatible with C++'s version, static
and type qualifiers in parameter array declarations, and a swarm of new
floating point math functions, to name just a few. I don't know about
anyone else, but I intend to make heavy use of every one of the features
I just named. Some of those features will never be part of C++. The
committees worked hard to keep the two languages as compatible as
possible, but no more so; C is migrating off in one direction, and C++
is heading in another.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Thu, 26 Dec 2002 08:39:14 +0000 (UTC) Raw View
already5chosen@yahoo.com (Michael S) wrote in message
news:<f881b862.0212230642.76ca81f9@posting.google.com>...
> nagle@animats.com (John Nagle) wrote in message
> news:<3E03F52A.7050406@animats.com>...
> Agreed, 100%.
> See my thread "Three features you would like to have not in C++"
> (relegated to the second page now) for more of the same. There were
> 50+ answers criticizing my "top three" but amazingly nobody posted
> three undesired features of his own.
Fergus Henderson did. His top choice was undefined behavior.
It also has the advantage that in removing undefined behavior (by
defining it), you can't possibly break existing code.
> It looks like C++ folks are very reluctant to the idea of removing
> something from the language.
I think most languages have to deal with a certain amount of tradition.
Part of the tradition of C++ (which comes directly from C) is that a
efficient implementation must be possible on just about any conceivable
architecture. This was certainly a valid consideration in the early
days of C, when word addressed machines (with different sizes for char*
and int*), 36 bit machines (with 9 bit bytes), ones complement and
signed magnitude, etc. were still being sold in significant numbers.
Today, I'm not sure how much this requirement is based on any reality,
and how much it is just tradition. (I think that there is still one 36
bit ones complement machine being sold today, so there is probably still
some reality involved.)
In the case of one typical example of undefined behavior, leaving the
order of evaluation undefined and specifying that modifications of an
object without an intervening sequence point is undefined behavior, was
definitely conditionned by the compiler technology available at the time
C was being developed, and uncertainties with regards to how
optimization technology would evolve. Today, I think we're far enough
along to know that removing this added freedom will not affect program
speed. But the tradition is there.
> They just don't feel that complexity in general and lack of
> transparency in particular is The Problem of C++.
I've not seen anyone claiming that C++ is too simple. It's problems are
known. A good solution to them isn't.
> As it stays now, C++ holds only one major advantage over Ada-95 - the
> absence of multythreading support at the language level.
I'm curious as to why you consider the absence as an advantage.
Multithreading is one thing that cannot be done simply in a library.
(The presense of threads affects the meaning of things like sequence
points, and must be taken into account by the compiler.)
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kuyper@wizard.net ("James Kuyper Jr.")
Date: Thu, 26 Dec 2002 08:47:03 +0000 (UTC) Raw View
Michael S wrote:
....
> See my thread "Three features you would like to have not in C++"
> (relegated to the second page now) for more of the same. There were
> 50+ answers criticizing my "top three" but amazingly nobody posted
> three undesired features of his own. It looks like C++ folks are very
> reluctant to the idea of removing something from the language. ...
That's not particularly amazing; removing a feature from a language is
virtually guaranteed to break existing code somewhere; the feature
wouldn't have existed unless somebody thought it was useful, even if
they were wrong. And there's a decent chance they were right.
Adding a feature is quite a bit safer.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Thu, 26 Dec 2002 08:48:45 +0000 (UTC) Raw View
hyrosen@mail.com (Hyman Rosen) wrote in message
news:<0ygN9.16630$cR2.3955@nwrddc04.gnilink.net>...
> John Nagle wrote:
> > This is unfortunate.
> No, it is not. You had three features you wanted removed, and you
> discovered that two of them were actively used.
I think he did ask a legitimate question. He just chose some very bad
examples.
I think that there are a few features where there might actually be a
consensus that they are misfeatures. The fact that:
std::vector<int> v( std::istream_iterator<char>( cin ),
std::istream_iterator<char>() ) ;
declares an external function, for example. Or the fact that in
std::vector<std::vector<int>> v ;
the '>>' is interpreted as a shift right token.
In both cases, there are "simple" fixes: don't allow function
declarations within functions, and interpret '>>' as two '>' tokens
anytime such an interpretation would be legal (the legality being
determined without look-ahead -- e.g. seeing > > at that point would be
legal, even if it rendered future code illegal).
Of course, both of these "simple" fixes potentially break code. It is
currently legal to declare functions within a function, and any code
which does so will be broken by making it illegal. And a right shift
operator can very well occur within a template parameter; interpreting
it as two '>' will break that code.
In both cases, there are simple fixes for the broken code. But they
must be applied.
So the question is: supposing we can more or less accurately determine
what percentage of code will actually be affected (a rather daring
supposition, actually, since most code is not open source, and there is
no reason to suppose that open source code is in any way a
representative sampling of existing code), how much code must be
affected to make the change unacceptable? If we could somehow prove
that 99% of existing code did not declare functions within a function,
are we justified in breaking the other 1% in order to correct what I'm
sure most people would consider a misfeature?
I think it is a question worth discussing in its own right,
independantly of the validity of the examples chosen.
(For what it is worth, no code that I have written, nor any code that I
have seen at any of my clients, would be affected by either of the above
two changes. But that probably only represents something like
0.000000001% of all the C++ code in the world, give or take a few 0's.
Which is a long way from 99%.)
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Thu, 26 Dec 2002 09:01:32 +0000 (UTC) Raw View
Hyman Rosen wrote:
> This is it folks. This is all you get. Anything
> more drastic will require the invention of a new language.
>
> I suggest that those who are interested begin working. The new languages
> could tentatively be called "C++ with Aspects", or "C++ with Reflection",
> or "C++ with Improved Syntax", just like C++ began as "C with Classes".
There's a serious effort, led by Walter Bright, who wrote
much of the Zortech C++ compiler, to define a language called
"D". A compiler exists and can be downloaded.
http://www.digitalmars.com/d
D is a reasonable direction. It's not backwards
compatible with C++. D has garbage collection,
no multiple inheritance, no preprocessor, modules,
and cleaner syntax, which are the same choices
Java makes. It does have templates like
C++, rather than polymorphism like Java.
D is probably too close to Java
and C#, and for that matter Objective C, to get
any traction.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Thu, 26 Dec 2002 09:04:28 +0000 (UTC) Raw View
In article <f881b862.0212230642.76ca81f9@posting.google.com>, Michael S
<already5chosen@yahoo.com> writes
>Agreed, 100%.
>See my thread "Three features you would like to have not in C++"
>(relegated to the second page now) for more of the same. There were
>50+ answers criticizing my "top three" but amazingly nobody posted
>three undesired features of his own. It looks like C++ folks are very
>reluctant to the idea of removing something from the language. They
>just don't feel that complexity in general and lack of transparency in
>particular is The Problem of C++.
no vector<bool> specialisation.
remove auto_ptr and replace with a well considered set of smart pointers
no export.
Unfortunately removing any of those breaks existing code even though the
first one also breaks future code (unless the author understands why
vector<bool> is not a sequence container and specialises their own
templates appropriately.
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Daniel.Miller@tellabs.com ("Dan'l Miller")
Date: Wed, 18 Dec 2002 19:58:15 +0000 (UTC) Raw View
Stefan Ram wrote:
> tiff_master@yahoo.com (Grex) writes:
>
>>Today a significant share to this segment has already been lost to
>>SUN's Java technology and with MS now abandoning C++ in favour if its
>>proprietery .NET and C# technology, how long can we except C++ to hold
>>on against these might competitors?
>
>
> I develope many applications with Perl because it
> (i.e., CPAN) supplies /portable/ calls for systems
> like sockets, Web pages, file systems, GUIs and so on.
>
> The rationale for not including such features into
> C or C++ often is that they are not available under
> every architecture or environment. While it is true,
> that some libraries for C++ are available, which
> implement such features for some environments or
> even for several environment, these are not
> standardized by ISO.
Perl is not standardized by ISO. Why should C++ live up to a higher
expectation than Perl?
I would claim that Perl has a bennevolent dictator, who enforces not only the
language content (and the OS-independent bindings to which you refer), but also
issues the one sole singular implementation of Perl.
Conversely, C++ is designed by committee. C++ has multiple implementations
in the form of multiple compilers from multiple (competing) vendors. Although
we can imagine a hypothetical alternate universe where ISO would be 1) a
benevolent dictator and 2) a software-development organization which issued the
one true and only C++ compiler for every operating system, that is not this
universe's ISO (nor this universe's IEC, nor this universe's ANSI, nor this
universe's BSI, nor this universe's ETSI, and so forth).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Thu, 19 Dec 2002 17:56:52 +0000 (UTC) Raw View
Matt Austern wrote:
> cpdaniel@nospam.mvps.org ("Carl Daniel") writes:
>
>
>>"Steve Clamage" <clamage@eng.sun.com> wrote in message
>>news:Pine.SOL.4.33.0212170811080.14034-100000@taumet...
>>
>>>On Tue, 17 Dec 2002, John Nagle wrote:
>>>
>>>> The future of C++ looks a lot like the present.
>>>>Any proposed substantial change gets shot down.
>>>>
>>>>
>>>On the contrary, the C++ Committee is actively considering several
>>>substantial extensions to C++.
>>>
>>>But if by "change" you mean altering C++ syntax or semantics such
>>>that many or most current valid programs become invalid, you are
>>>correct: such proposals routinely are rejected.
>>>
>>I think I can relate to the sentiment in John's posting. The feeling I get,
>>at least from disucssions on this NG, is that a change which breaks any
>>conceivable code is rejected, even if the vast majority of code would be
>>unaffected and the proposal is otherwise sound and useful.
>>
>
> I think that's true. Changes that break code will be considered, but
> the critera are more stringent than "the vast majority of code would
> be unaffected".
What are the criteria? Are they written down somewhere?
I'd argue that if your code isn't publicly visible, you
should't expect it to be protected against future language
changes. If a change is proposed, the universe of
source code available without an NDA should be examined
for conflicts to see how serious the problem is. (This
would include not just open source, but everything you
get with a MSDN subscription, for example.) If there's
no serious conflict in that body of code, the change
is reasonable.
This provides an objective, independently verifiable
criterion for backwards compatibility. It's "publish or
perish" for code.
John Nagle
Animats
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "David B. Held" <dheld@codelogicconsulting.com>
Date: 19 Dec 2002 15:10:29 -0500 Raw View
"Grex" <tiff_master@yahoo.com> wrote in message
news:a6150b7f.0212140326.45196cf4@posting.google.com...
> For many years now enterprise business application development
> has been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour
> if its proprietery .NET and C# technology, how long can we except
> C++ to hold on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
The fact of the matter is, C++ always has and will continue to hold a
place among languages that emphasizes performance as well as
elegance and ease of use. Most of the trendy new languages are very
similar to each other in that they buy programmer simplicity at run-time.
For applications where that is acceptable, those languages may gain
ground. But that will not be acceptable for all applications, and C++
will continue to dominate that field. Consider also the massive installed
codebase of C/C++, and show me a comparable number of Java or C#
libraries. Yes, you can link to those C++ libraries from most languages,
but A) people still *write* the libraries in C/C++, and B) there are
certainly a large number of useful libraries that are *only* usable in C++.
Not only that, but I think C++ is continuing to innovate in ways that
newer languages can only dream of. I don't see any new languages
with the same emphasis on doing as much at compile time as C++.
Certainly neither Java nor C# fit that description. I see C++ as being
relevant for a very long time. If anything, I would argue that it is the
success of C++ that has forced Java, C#, et al into the "niche" of
unified object models, GC, and all the other pork that comes with
runtime-heavy languages. Not to say that there aren't any concepts
that can be borrowed from other languages, but C++ is hardly obsolete.
Dave
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Matt Austern <austern@well.com>
Date: 19 Dec 2002 15:11:42 -0500 Raw View
kanze@gabi-soft.de (James Kanze) writes:
> "Robert Klemme" <bob.news@gmx.net> wrote in message
> news:<atmpr0$kv3r$1@ID-52924.news.dfncis.de>...
> > "Grex" <tiff_master@yahoo.com> schrieb im Newsbeitrag
> > news:a6150b7f.0212140326.45196cf4@posting.google.com...
>
> > > For many years now enterprise business application development has
> > > been the core area for the use of C++. Today a significant share to
> > > this segment has already been lost to SUN's Java technology and with
> > > MS now abandoning C++ in favour if its proprietery .NET and C#
> > > technology, how long can we except C++ to hold on against these
> > > might competitors? Has C++ become a dying language? What is the
> > > future of C++?
>
> > think of what happened to FORTRAN. see? i don't think that C++ will
> > be obsolete in the near of middle future - maybe even not in the long
> > term.
>
> Or Cobol -- there are still new projects being written in Cobol.
>
> In fact, I think the original posting is just a troll, and I'm sort of
> surprised the moderators let it by. (In the case of clc++m, it's rather
> difficult to find a rule by which to refuse it, even if the moderator
> recognizes it as a troll, but it certainly has nothing to do with the
> C++ standard.)
I'm not the moderator who approved that post, but I think it was
appropriate: there is going to be a new revision of the C++ Standard,
discussion about it has already started, and one's view of the future
uses of C++ is directly related to one's view of how the standard
ought to evolve. What kinds of uses of C++ are important, and what
kinds of problems should the new standard try to solve? This is a
question that everyone who's concerned about C++ ought to be asking
themselves right now.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Thu, 19 Dec 2002 23:17:57 +0000 (UTC) Raw View
> > John Nagle wrote:
> > > The future of C++ looks a lot like the present.
> > > Any proposed substantial change gets shot down.
> "Steve Clamage" <clamage@eng.sun.com> wrote
> > On the contrary, the C++ Committee is actively considering several
> > substantial extensions to C++.
> >
> > But if by "change" you mean altering C++ syntax or semantics such
> > that many or most current valid programs become invalid, you are
> > correct: such proposals routinely are rejected.
cpdaniel@nospam.mvps.org ("Carl Daniel") wrote
> I think I can relate to the sentiment in John's posting. The feeling I get,
> at least from disucssions on this NG, is that a change which breaks any
> conceivable code is rejected, even if the vast majority of code would be
> unaffected and the proposal is otherwise sound and useful.
Note that there never is any "final decision" here in this newsgroup.
It's a discussion, and one of the benefits is that our feelings become
known to the C++ Committee.
Both the pro and con positions should be aired. Sometimes I'll even
post comments about the pro side if I don't like it, or vice-versa.
And frankly, it's usually much easier to see problems with an idea
than it is to see the underlying merit.
Still, even if the perponderance of sentiment here is that an idea is
bad, that doesn't mean it won't affect people on the C++ Committee
in some way. And breaking one program doesn't mean that they won't
do it. Even the C++-style comments could break code:
int i = 100 //*comment*/
+5;
Much worse than breaking code, is "silently" changing it's meaning.
In old C, that would have initialized i to 20; in C++, it would
initialize to 105, and neither one would issue a warning or error.
Bjarne Stroustrup considered this before deciding to keep it as a
language feature (this was long before the standardization committee
was formed). He must have felt it was rare enough.
(Sometimes the underlying merit is apparent only to the person
posting the idea. I recall a thread a few years ago, where someone
wanted to do something completely contrary to the whole C++ concept
of vtables -- they wanted to alter the vtable directly, or maybe it
was "just" the vpointer, in order to alter an object's behavior at
runtime. Almost all of the posters objected to the idea, and he took it
personally, getting very defensive, and claimed that people here just
weren't ready for C++ to evolve...)
...But you're right, sometimes the "con" position gets a bit
monotonous. For instance, the C++ Committee already understands the
dangers of adding new keywords to the language, and understands better
than most posters here how to minimize that risk. (It's never totally
eliminated -- yes, even a weird word like "mutable" could conceivably
have been used as a variable name in some program somewhere.) And yet,
every time someone discusses a proposal involving a new keyword, the
reaction seems to indicate that doing such a thing is totally
inconceivable.
But give the C++ Committee credit for thinking. The fact that someone
makes a proposal here doesn't neccesarily mean it's going to go into
the standard; the fact that someone objects doesn't neccesarily mean
that it won't. They've done an excellent job so far(*), and I'm sure
that they will continue to do so in the future.
(*) Everywhere except exception-specifications... and I wonder if
ANYBODY could have done any better at the time.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Fri, 20 Dec 2002 00:33:21 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote
> I'd argue that if your code isn't publicly visible, you
> should't expect it to be protected against future language
> changes. If a change is proposed, the universe of
> source code available without an NDA should be examined
> for conflicts to see how serious the problem is. (This
> would include not just open source, but everything you
> get with a MSDN subscription, for example.) If there's
> no serious conflict in that body of code, the change
> is reasonable.
MSDN already has lots of code that voilates the current standard.
Such as void main().
But your point is valid one. I especially like your first
statement, but I'd point out that you CAN protect your code
from future language changes today.
* Get a computer.
* Load an O/S and a compiler.
* Hide it all away in a vault somewhere.
* Write your program using the compiler you have.
* Don't connect any I/O except for whatever is needed by your
program. Do not connect to the Internet or any Bulletin Board
system. Unplug the modem.
* Never ever upgrade any part of the computer (except possibly
changes to your program, using the same compiler.)
Barring hardware or power failures, your computer will be working 50
years from now just as well as it works today. Surely by then expectations
will have risen; your computer system will certainly be viewed as archaic.
But it will work, and you will be isolated (for better or worse) from any
changes in the computer language.
Imagine, though, if someone had done that in December 1952. For one thing,
the vault would be unbelievably big, to hold the computers available at
the time, plus the card punches and blank cards. (You'd also have gone
through millions of tube replacements in the intervening years.) Did
FORTRAN and COBOL exist in 1952? If so, you would indeed have been isolated
from any change to either language... your compiler conforms to 1952's
vision of "state of the art." (If not, we can still say the same thing
about the assembly language.)
Perhaps it is a matter of degree. Just how isolated do you want to be?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: scottm@toast.net ("Scott Mayo")
Date: Fri, 20 Dec 2002 04:01:50 +0000 (UTC) Raw View
"John Nagle":
> I'd argue that if your code isn't publicly visible, you
> should't expect it to be protected against future language
> changes. If a change is proposed, the universe of
> source code available without an NDA should be examined
> for conflicts to see how serious the problem is. (This
> would include not just open source, but everything you
> get with a MSDN subscription, for example.) If there's
> no serious conflict in that body of code, the change
> is reasonable.
Um. That certainly protects Linux coders, Microsoft, and some
freeware authors. Now who is going to protect the rest of us, who
don't publish code for the very simple reason that the lawyers
forbid it, and who are, I'm guessing, still a huge majority in
this industry? Does this mean I have to ape Microsoft's coding
style to be quite safe?
> This provides an objective, independently verifiable
> criterion for backwards compatibility. It's "publish or
> perish" for code.
I cannot publish - I work for a real company with a toothy
view of its intellectual property rights. And you're
scaring me.
<soapbox> Let me just say that I have been wonderfully
happy with the C++ committees' willingness to preserve
existing code. Thanks. </soapbox>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: austern@well.com (Matt Austern)
Date: Fri, 20 Dec 2002 04:17:14 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) writes:
> > I think that's true. Changes that break code will be considered, but
>
> > the critera are more stringent than "the vast majority of code would
> > be unaffected".
>
>
>
> What are the criteria? Are they written down somewhere?
No. It's a judgement call, it'll have to be considered on a case by
case basis, and I'm sure that not every committee member will use the
same criteria. Some of the relevant questions to ask: how much code
is likely to break, whether it will break quietly or noisily, whether
it's easy to fix the breakage.
As I said, I can think of some changes that will almost certainly be
considered seriously even thought they'll break code.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Fri, 20 Dec 2002 06:59:21 +0000 (UTC) Raw View
Allan W wrote:
> nagle@animats.com (John Nagle) wrote
>
>> I'd argue that if your code isn't publicly visible, you
>>should't expect it to be protected against future language
>>changes. If a change is proposed, the universe of
>>source code available without an NDA should be examined
>>for conflicts to see how serious the problem is. (This
>>would include not just open source, but everything you
>>get with a MSDN subscription, for example.) If there's
>>no serious conflict in that body of code, the change
>>is reasonable.
>
> But your point is valid one. I especially like your first
> statement, but I'd point out that you CAN protect your code
> from future language changes today....
To make this more concrete, consider the following changes:
-- Disallow overriding of a non-virtual function.
-- Disallow delete of const pointers.
-- Disallow "delete this".
These are all things that are usually errors.
Suppose we examined some large body of code, and
determined that N% of the time these situations
came up, they were errors. How high would N have
to be to justify the change? 90%? 99%? 99.99%?
100%?
John Nagle
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Fri, 20 Dec 2002 16:34:24 +0000 (UTC) Raw View
In article <dilof7h4as5.fsf@mattlinux.localdomain>, Matt Austern
<austern@well.com> writes
>No. It's a judgement call, it'll have to be considered on a case by
>case basis, and I'm sure that not every committee member will use the
>same criteria. Some of the relevant questions to ask: how much code
>is likely to break, whether it will break quietly or noisily, whether
>it's easy to fix the breakage.
For example, silent breakage of existing code is a 'No, never.' for me
and I believe that it is for most of my colleagues on the BSI language
Panels which is one reason that the UK votes 'No' to Standards changes
more often then any other country. The only time that such change is
acceptable is where it rectifies an ambiguity (i.e. whatever we do some
code will break)
Now other changes are a matter of cost/benefit and there we will not all
agree because assessing that ratio depends on which C++ sub-communities
we are familiar with.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: hyrosen@mail.com (Hyman Rosen)
Date: Fri, 20 Dec 2002 16:37:10 +0000 (UTC) Raw View
John Nagle wrote:
> -- Disallow "delete this".
> These are all things that are usually errors.
Certainly not this one. This technique is used
quite often by objects which maintain their own
lifetime.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: a9804814@unet.univie.ac.at (Thomas Mang)
Date: Fri, 20 Dec 2002 16:54:38 +0000 (UTC) Raw View
>
> > I think that's true. Changes that break code will be considered, but
> > the critera are more stringent than "the vast majority of code would
> > be unaffected".
>
> What are the criteria? Are they written down somewhere?
>
> I'd argue that if your code isn't publicly visible, you
> should't expect it to be protected against future language
> changes. If a change is proposed, the universe of
> source code available without an NDA should be examined
> for conflicts to see how serious the problem is.
Or even better, if "mechanical" ways allow an automatic transformation of source
code.
Think about 'explicit' vs. 'implicit'. Had the language been born just yesterday,
I guess 'implicit' had precedence. For backward compatibility, 'explicit' was
used.
But it's quite easy to automatically change most (and probably even all) already
written code -> just declare all the currently-used constructors as 'implicit'.
The only job of the programmer would be then to delete the 'implicit' keyword for
all constructors that really don't need it.
So why can't the standard require implementations to ship along with the current
implementation an automatic conversion tool that transforms written code into the
newest standard version(Say, from C++ 98 to C++03)? (Certainly only if the changes
/ conversions can be made really automatic to a high degree).
This way, changes in the standard would be much. Which in turn could improve C++
to a very high degree.
regards,
Thomas
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Fri, 20 Dec 2002 16:58:02 +0000 (UTC) Raw View
austern@well.com (Matt Austern) wrote in message
news:<dilof7h4as5.fsf@mattlinux.localdomain>...
> nagle@animats.com (John Nagle) writes:
> > > I think that's true. Changes that break code will be
> > > considered, but
> > > the critera are more stringent than "the vast majority of
> > > code would be unaffected".
> > What are the criteria? Are they written down somewhere?
> No. It's a judgement call, it'll have to be considered on a
> case by case basis, and I'm sure that not every committee
> member will use the same criteria. Some of the relevant
> questions to ask: how much code is likely to break, whether it
> will break quietly or noisily, whether it's easy to fix the
> breakage.
> As I said, I can think of some changes that will almost
> certainly be considered seriously even thought they'll break
> code.
Any on tap.
The day they changed new to throw rather than to return a null
pointer, they broke every single bit of "correct" code that then
existed. (Correct code, at that time, being code which
carefully tested the return of every new, and propagated the
error to where ever it was to be handled.) Now, I'm certainly
not one to encourage the overuse of exceptions, nor to recommend
breaking code, but I hardly see how any other decision would
have been reasonable.
But I feel that this was a very special case. And I can't
remember having heard of anything similar in the pipelines yet.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: tiff_master@yahoo.com (Grex)
Date: 17 Dec 02 04:40:25 GMT Raw View
For many years now enterprise business application development has
been the core area for the use of C++.
Today a significant share to this segment has already been lost to
SUN's Java technology and with MS now abandoning C++ in favour if its
proprietery .NET and C# technology, how long can we except C++ to hold
on against these might competitors?
Has C++ become a dying language?
What is the future of C++?
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Tue, 17 Dec 2002 06:19:11 +0000 (UTC) Raw View
The future of C++ looks a lot like the present.
Any proposed substantial change gets shot down.
John Nagle
Animats
Grex wrote:
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Robert Klemme" <bob.news@gmx.net>
Date: 17 Dec 2002 12:39:08 -0500 Raw View
"Grex" <tiff_master@yahoo.com> schrieb im Newsbeitrag
news:a6150b7f.0212140326.45196cf4@posting.google.com...
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
think of what happened to FORTRAN. see? i don't think that C++ will be
obsolete in the near of middle future - maybe even not in the long term.
regards
robert
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Electric Ninja" <noway@jose.dude>
Date: 17 Dec 2002 12:39:56 -0500 Raw View
As long as there are computer games begging for speed and midlevel
subsystems needing to be created, C++ will remain popular. Not to mention
legacy code and the joy of flexibility. Relax.
"Grex" <tiff_master@yahoo.com> wrote in message
news:a6150b7f.0212140326.45196cf4@posting.google.com...
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
> Has C++ become a dying language?
> What is the future of C++?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly <llewelly.@@xmission.dot.com>
Date: 17 Dec 2002 12:43:20 -0500 Raw View
tiff_master@yahoo.com (Grex) writes:
> For many years now enterprise business application development has
> been the core area for the use of C++.
I think there are dozens of other important areas. Embedded systems,
device drivers, OSes, console games (like for playstation2, etc),
logic for hubs, routers, telco switches, DVD players, CD players -
the list goes on and on.
> Today a significant share to this segment has already been lost to
> SUN's Java technology
lost? I think C++ is ill-suited for many of those applications - so I
don't consider this a loss.
> and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology,
I doubt C# will turn out to be well-suited for anything Java is
not well-suited for. For the present, there are C, C++, and Java
jobs in my area, but no C# jobs at all. Not one.
> how long can we except C++ to hold
> on against these might competitors?
Niether of those languages has the expressiveness or the low-level
features of C++. There will always be areas they are good for, and
always areas C++ is much, Much better for.
> Has C++ become a dying language?
People have been calling fortran a dying language for decades. It's
not dead yet - and I doubt fortran ever had the userbase (in sheer
numbers) C++ has now. C is also a primitive language, lacking the
financial backing of Java or C#, and lacking comparable built-in
technologies - yet it remains strong.
> What is the future of C++?
After much fasting, meditation, and prayer, this program was revealed
unto me. Compile and run it to learn the future of several important
languages.
#include<iostream>
using std::cout;
using std::endl;
char const* lang_name(int i)
{
switch(i%4)
{
case 0:return "C++";
case 1:return "fortran";
case 2:return "Ada";
case 3:return "C";
}
return "";
}
int main()
{
for(int i= 0; i < 200; ++i)
{
cout << "Year " << 2002+i << ": Death of " << lang_name(i) << " predicted." << endl;
}
}
[snip]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Carl Daniel" <cpdaniel@nospam.mvps.org>
Date: 17 Dec 2002 12:44:15 -0500 Raw View
"Grex" <tiff_master@yahoo.com> wrote in message
news:a6150b7f.0212140326.45196cf4@posting.google.com...
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java technology
Rubbish. IME, Java has found success mostly in new development areas. I
don't think it's taken a significant number of developer seats from C++.
> and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology
Rubbish. Microsoft has a stronger commitment to C++ than ever before. C++
is the premiere .NET language, with capabilities that no other .NET language
can match.
> , how long can we except C++ to hold
> on against these might competitors?
Many years to come.
> Has C++ become a dying language?
Aren't all languages dying? If there's one constant, it's change...
> What is the future of C++?
More of the same. C++ remains the language of choice for a very broad array
of problem domains.
-cd
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: jts43@cornell.edu ("J. Todd Slack")
Date: Tue, 17 Dec 2002 18:12:07 +0000 (UTC) Raw View
> > Has C++ become a dying language?
> > What is the future of C++?
Do people still us COBOL, FORTRAN, etc? today?
They have been around long before .NET.
-Jason
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Thomas.Matthews@pb.com (Thomas Matthews)
Date: Tue, 17 Dec 2002 18:12:48 +0000 (UTC) Raw View
tiff_master@yahoo.com (Grex) wrote in message news:<a6150b7f.0212140326.45196cf4@posting.google.com>...
> For many years now enterprise business application development has
> been the core area for the use of C++.
For many years now people have been posting to news:comp.lang.c and
news:comp.lang.c++ asking about the future of the language. For many
years people have not used a search engine to look for these articles
that keep appearing. Many people seem to be abandoning the search
engine and the FAQ in favor of adding more articles to the Usenet
system.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
Much of the base of users for C and C++ have not converted over to
.NET or C# technology in favor of sticking with a known technology.
The cost of converting over to an MS specific technology does not
outweigh the cost of staying with a known portable language.
> Has C++ become a dying language?
Hmm, look at the sales of compilers. Have no fear, C++ will not die
for many years. The language keeps changing.
But why do you ask? If you're so worried about it dying, then choose
another langauge such as FORTRAN or Lisp to program in. For that
matter, just switch to COBOL.
> What is the future of C++?
"Hmmm. Difficult to tell, Future is always changing." -- Yoda.
At the moment, I could care less about the future of C++. I'm still
learning on the best techniques for using it. I suppose, someday I
will know it all, but I may die before then. ;-)
-- Thomas Matthews
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: "Georg D." <georg74@i-one.at>
Date: 17 Dec 2002 16:01:52 -0500 Raw View
"Grex" <tiff_master@yahoo.com> schrieb im Newsbeitrag
news:a6150b7f.0212140326.45196cf4@posting.google.com...
> For many years now enterprise business application development has
> been the core area for the use of C++.
This is just a temporary phenomenon. There was a lack of other languages,
i.e. other languages with suitable evnvironment and support (which
includes availability of developers and programmers). Technical
characteristics of a programming language itself is only a minor one among
many other factors which influence its usage in a distinct field. If you
want to analyze a possible future development, you have to look at various
aspects of a language and estimate their importance.
Future of C++ <-- future of development environments and support fot it.
> Today a significant share to this segment has already been lost to
> SUN's Java technology and with MS now abandoning C++ in favour if its
> proprietery .NET and C# technology, how long can we except C++ to hold
> on against these might competitors?
There are still no real "competitors" to C++. Mentioned languages,
better say development environments and models will replace C++ in
areas where it was actually misused and where it wasn't supported well.
All this only for areas and platforms where mentioned language will
have a better support.
> Has C++ become a dying language?
Definitively not. There is hardly a scenario where C++ could be replaced
in a significant number of its use areas by any of presently known
languages. This is not really comparable, but - is C a dying language?
Someone may be surprised, but the answer is - not yet.
> What is the future of C++?
The future of a great share of software development is in open and
heterogenous, interconnected environments, where C++ will have a
significant use in appropriate (and this are many) fields.
IMO, key factors are
- standardization of the language itself, where quality is more
important than features.
- standardization of a growing common part of libraries
- growing experience and availability of developers and programmers
- vast amount of already available models, solutions, libraries etc.
- high performance, high reliability development environments and
CASE tools (btw. the present trend of feature-packed but buggy
compilers and libraries is counter-productive)
- open source development, portable development and high quality
support on many platforms
- availability of multi-target / multi-platform IDEs
Georg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: clamage@eng.sun.com (Steve Clamage)
Date: Tue, 17 Dec 2002 22:47:24 +0000 (UTC) Raw View
On Tue, 17 Dec 2002, John Nagle wrote:
>
> The future of C++ looks a lot like the present.
> Any proposed substantial change gets shot down.
>
On the contrary, the C++ Committee is actively considering several
substantial extensions to C++.
But if by "change" you mean altering C++ syntax or semantics such
that many or most current valid programs become invalid, you are
correct: such proposals routinely are rejected.
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Tue, 17 Dec 2002 22:50:18 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote
> The future of C++ looks a lot like the present.
> Any proposed substantial change gets shot down.
In general discussion on this newsgroup, someone is sure to mention
the "con" side of any argument... I see this as a service, not an
execution. I think that most people on the standards committee
read and interact with this newsgroup, to see fresh new ideas and to
help them to be responsive to what people want. Despite this, people
who post to this newsgroup do not form a democracy that votes on
issues -- they air the issue, try to pursuade committee members.
My point is, just because 25 people tell you that your idea has flaws,
doesn't mean that it won't (in some form) be addressed in the next
standard.
> Grex wrote:
>
> > For many years now enterprise business application development has
> > been the core area for the use of C++.
> > Today a significant share to this segment has already been lost to
> > SUN's Java technology and with MS now abandoning C++
Microsoft has not "abandoned" C++. In fact, there have been many
enhancements, and their compiler is growing more standards-compliant
with every release. They may well turn out to be the second compiler
to achieve 100% compliance.
> > in favour if its
> > proprietery .NET and C# technology,
> > how long can we except C++ to hold
> > on against these might competitors?
You could also say they "abandoned" PC-DOS in favor of its proprietary
Windows technology. .NET is a platform, and there's no reason that
Microsoft (or YOU!) can't produce a compiler that runs on that platform.
As for C#, it is a new language. It's similarities to C++ should be no
more startling than Java's similarities to C++ -- there are enough
important differences to keep the languages distinct.
Perhaps you're noticing that Microsoft has hyped C# more than C++
lately. It's their newest language; they wish to promote it, in order
to get people using it so it remains viable, and also to generate
sales revenue. Just because they hype C# doesn't mean that they
abandon C++. Just because Ford promotes a new model of car, doesn't
mean that they don't have big expectations for their older models.
> > Has C++ become a dying language?
Not from where I sit. Even if Microsoft did "abandon" C++, other
vendors would keep it going -- both on Windows and on other platforms.
> > What is the future of C++?
The Crystal Ball is hazy, but I can see a few things in the fog. I see
a new standard being ratified, looks like about 2008 or 2009. There are
many new features, but there are surprisingly few changes needed for
legacy code. Most of the new features promote coding safety, by flagging
common errors as mistakes or by more reliably reporting runtime exceptions.
There will be much effort trying to provide usability guarantees for the
Embedded C++ community; despite this, the Embedded C++ community will
largely ignore them, claiming that they need their own version of the
standard anyway. I see Bjarne Stroustrup's son getting married to the
daughter of what's-his-name, the guy that invented Java -- and much
public debate about the symbolism involved, but eventually it will be
obvious that this was just another April Fool's joke, as Bjarne doesn't
even have a son. (That won't stop people from quoting the "press release"
for years to come!) There will be huge changes in the way that exceptions
work, and while this *will* require changes to legacy code that uses
exception specifications, research will show that there are only six major
code bases worldwide that use exception specs anyway. I see someone
raising controversy by publicly announcing that he has incontrovertable
proof that Andrew Koenig and Elvis Presley are in fact one and the same
person, but this person will face humiliation when the "proof" turns
out to be a drunken scribble on the back of a photo of -- not Elvis, but
The Beatles. I see great efforts to make code easier to share,
especially library classes. I see great strides in the way people define
and use std::swap.
Beyond that I can't tell -- my Crystal Reports Ball is too cloudy. :-)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: cpdaniel@nospam.mvps.org ("Carl Daniel")
Date: Wed, 18 Dec 2002 01:12:26 +0000 (UTC) Raw View
"Steve Clamage" <clamage@eng.sun.com> wrote in message
news:Pine.SOL.4.33.0212170811080.14034-100000@taumet...
> On Tue, 17 Dec 2002, John Nagle wrote:
> >
> > The future of C++ looks a lot like the present.
> > Any proposed substantial change gets shot down.
> >
>
> On the contrary, the C++ Committee is actively considering several
> substantial extensions to C++.
>
> But if by "change" you mean altering C++ syntax or semantics such
> that many or most current valid programs become invalid, you are
> correct: such proposals routinely are rejected.
I think I can relate to the sentiment in John's posting. The feeling I get,
at least from disucssions on this NG, is that a change which breaks any
conceivable code is rejected, even if the vast majority of code would be
unaffected and the proposal is otherwise sound and useful.
-cd
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: austern@well.com (Matt Austern)
Date: Wed, 18 Dec 2002 01:57:03 +0000 (UTC) Raw View
cpdaniel@nospam.mvps.org ("Carl Daniel") writes:
> "Steve Clamage" <clamage@eng.sun.com> wrote in message
> news:Pine.SOL.4.33.0212170811080.14034-100000@taumet...
> > On Tue, 17 Dec 2002, John Nagle wrote:
> > >
> > > The future of C++ looks a lot like the present.
> > > Any proposed substantial change gets shot down.
> > >
> >
> > On the contrary, the C++ Committee is actively considering several
> > substantial extensions to C++.
> >
> > But if by "change" you mean altering C++ syntax or semantics such
> > that many or most current valid programs become invalid, you are
> > correct: such proposals routinely are rejected.
>
> I think I can relate to the sentiment in John's posting. The feeling I get,
> at least from disucssions on this NG, is that a change which breaks any
> conceivable code is rejected, even if the vast majority of code would be
> unaffected and the proposal is otherwise sound and useful.
I think that's true. Changes that break code will be considered, but
the critera are more stringent than "the vast majority of code would
be unaffected". That's one criterion. (Although it's a tricky one:
C++ is used so widely that nobody is qualified to say what the vast
majority of C++ code looks like. I'd have a hard time even talking
about the ranges of projects that C++ is used for at the company where
I work.) Other criteria: the breakage is noisy rather than silent,
and there's a simple and mechanical process for fixing the broken
code.
Changes that introduce new keywords like 'restrict', for example, will
be considered, even though every such change breaks user code.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: llewelly.@@xmission.dot.com (llewelly)
Date: Wed, 18 Dec 2002 02:17:38 +0000 (UTC) Raw View
austern@well.com (Matt Austern) writes:
[snip]
> Changes that introduce new keywords like 'restrict', for example, will
> be considered, even though every such change breaks user code.
[snip]
I'd like to see namespaced reserved words - 'std::restrict' as opposed to
'restrict'. I think this would greatly reduce the amount of code
affected. However - I've seen two large projects migrated from C
to C++, and only 'class' and 'this' resulted in conflicts - which
were easily fixed.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 18 Dec 02 16:05:46 GMT Raw View
"Robert Klemme" <bob.news@gmx.net> wrote in message
news:<atmpr0$kv3r$1@ID-52924.news.dfncis.de>...
> "Grex" <tiff_master@yahoo.com> schrieb im Newsbeitrag
> news:a6150b7f.0212140326.45196cf4@posting.google.com...
> > For many years now enterprise business application development has
> > been the core area for the use of C++. Today a significant share to
> > this segment has already been lost to SUN's Java technology and with
> > MS now abandoning C++ in favour if its proprietery .NET and C#
> > technology, how long can we except C++ to hold on against these
> > might competitors? Has C++ become a dying language? What is the
> > future of C++?
> think of what happened to FORTRAN. see? i don't think that C++ will
> be obsolete in the near of middle future - maybe even not in the long
> term.
Or Cobol -- there are still new projects being written in Cobol.
In fact, I think the original posting is just a troll, and I'm sort of
surprised the moderators let it by. (In the case of clc++m, it's rather
difficult to find a rule by which to refuse it, even if the moderator
recognizes it as a troll, but it certainly has nothing to do with the
C++ standard.)
For starters, of course, the first sentence is misleading: business
applications have been A core area for the use of C++, but certainly not
the only one, and probably not the most important -- every major
telephone system in Europe is written in C++, and I don't see anything
likely to change there. In fact, in critical applications, C++ is
gaining (at the expense of Ada). And these are domains where Java
doesn't even try to be present.
Even in the domain of business applications, my impression is that the
Java fad is over. Java is still being used; for Web based applications,
it is doubtlessly the preferred language, by far. But the move to
convert everything to Java seems to have died out, almost relegating
Java to the role of a niche language (although Web based applicaions is
a pretty big niche). In some cases, I definitly regret this --
Java/Swing is IMHO definitely superior to C++/MFC, but most new client
software seems to adapt the latter.
Obviously, Microsoft would love to see everyone adopt a solution
VC++/C#. (Just as Sun would like to see Sparc/Solaris/Java replace the
PC's.) But I don't think it will happen. More importantly, I have the
impression that Microsoft doesn't think it will happen either. Witness
their recent interest in and commitment to the C++ standard.
And of course, none of these evolutions have anything to do with the
relative technical merits of any of the languages. Any more than any of
the preceding evolutions did.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: kanze@gabi-soft.de (James Kanze)
Date: 18 Dec 02 16:08:58 GMT Raw View
"Carl Daniel" <cpdaniel@nospam.mvps.org> wrote in message
news:<_XyL9.1997$DF.470@newssvr19.news.prodigy.com>...
> > Has C++ become a dying language?
> Aren't all languages dying? If there's one constant, it's change...
That's a good point. The C++ that I first learned (with an old Zortech
compiler) is dead.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Wed, 18 Dec 2002 17:15:00 +0000 (UTC) Raw View
In article <7f2735a5.0212171054.509fe25@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
> I see Bjarne Stroustrup's son getting married to the
>daughter of what's-his-name, the guy that invented Java -- and much
>public debate about the symbolism involved, but eventually it will be
>obvious that this was just another April Fool's joke, as Bjarne doesn't
>even have a son.
That will be news to him and a great relief as he can stop paying the
young man's University fees :-) Obviously your crystal ball's C++ driven
embedded processor has undefined behaviour.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]