An Honest question about where C++ goes from here
ZHN
place at this time. Certainly java, and C# will have a devastating impact on
c++ int the near future. In fact I have been looking at microsoft NET
technology only to find that c++ is really being phased out to a great extent.
If this trend continues we may find ourselves having to give up a great deal
of
what we've learned for some proprietary language or other. If nothing else
this is a very serious question simply becuase it implies the possibility of
being undervalued as a programmer. In fact it's sad to see a newbie java
programmer being worth up to twenty percent more than an overly experienced
C++
programmer is worth in some markets. Here we are with what is the most
flexible, most capable (and most taxing) language around and yet worth half
of
what others may be worth with half the brain fatigue that we have to suffer..
Why?
The question here is what is the solution? What does
the
C++ community need to do(both from a technological viewpoint as well as from a
political perspective) to stop this insidious devaluation of the C++
programmer?
Chris Peter S.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Mike Smith
news:20010104121404...@ng-fk1.aol.com...
> Well there you have it. I am a little concerned with events in the
market
> place at this time. Certainly java, and C# will have a devastating impact
on
> c++ int the near future. In fact I have been looking at microsoft NET
> technology only to find that c++ is really being phased out to a great
extent.
> If this trend continues we may find ourselves having to give up a great
deal
> of
> what we've learned for some proprietary language or other. If nothing
else
> this is a very serious question simply becuase it implies the possibility
of
> being undervalued as a programmer. In fact it's sad to see a newbie java
> programmer being worth up to twenty percent more than an overly
experienced
> C++
> programmer is worth in some markets. Here we are with what is the most
Very key words there - "in some markets". If you're looking for someone to
write Web-enabled applets, then Java is a clear choice over C++. If you're
looking for someone to write, say, real-time machine vision or data
acquisition applications, then Java's not so attractive. Remember,
businesses don't hire developers in order to give them an opportunity to
work on something for fun; they're out to make money. It makes sense to
apply the most applicable tool to the problem at hand.
--
Mike Smith
One man's theology is another man's belly laugh. --R. A. Heinlein
Francis Glassborow
<z...@aol.com> writes
>If nothing else
>this is a very serious question simply becuase it implies the possibility of
>being undervalued as a programmer. In fact it's sad to see a newbie java
>programmer being worth up to twenty percent more than an overly experienced
>C++
>programmer is worth in some markets.
C++ is just a language in which programmers work. Good programmers are
multilingual. Mediocre ones follow the fashion of the day.
>
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Assaf Lavie
Don't you think it's about time that people stopped focusing all their
efforts on learning complex syntaxes, complex resource management semantics
and keywords up the ying-yang?
Isn't it about time people start using languages that have Reflection, true
OO, type safety, AOP (I can go on)?
C++ is great, but it can most certainly be improved. What better way of
perpetuating C++ is there than allowing it to exist forever in other
'derived' languages?
Assaf.
"ZHN" <z...@aol.com> wrote in message
news:20010104121404...@ng-fk1.aol.com...
> Well there you have it. I am a little concerned with events in the market
> place at this time. Certainly java, and C# will have a devastating impact on
> c++ int the near future. In fact I have been looking at microsoft NET
> technology only to find that c++ is really being phased out to a great
extent.
> If this trend continues we may find ourselves having to give up a great deal
> of
> what we've learned for some proprietary language or other. If nothing else
> this is a very serious question simply becuase it implies the possibility of
> being undervalued as a programmer. In fact it's sad to see a newbie java
> programmer being worth up to twenty percent more than an overly experienced
> C++
> programmer is worth in some markets. Here we are with what is the most
> flexible, most capable (and most taxing) language around and yet worth half
> of
> what others may be worth with half the brain fatigue that we have to
suffer..
> Why?
> The question here is what is the solution? What does
> the
> C++ community need to do(both from a technological viewpoint as well as from
a
> political perspective) to stop this insidious devaluation of the C++
> programmer?
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Julian Smith
Francis Glassborow <fran...@robinton.demon.co.uk> wrote:
> In article <20010104121404...@ng-fk1.aol.com>, ZHN
> <z...@aol.com> writes
> >If nothing else
> >this is a very serious question simply becuase it implies the
possibility of
> >being undervalued as a programmer. In fact it's sad to see a newbie
java
> >programmer being worth up to twenty percent more than an overly
experienced
> >C++
> >programmer is worth in some markets.
>
> C++ is just a language in which programmers work. Good programmers are
> multilingual. Mediocre ones follow the fashion of the day.
That's true to an extent, but I think you underplay the amount of time
it takes to master the language-specific details of C++. There are
whole books devoted to explaining C++-specific problems (e.g.
Effective/More Effective C++), and most people don't have time to study
them properly, let alone do the same for other languages as well. If
the industry suddenly switches languages, that means that lots of
programmers find themselves with lots of hard-won knowledge that simply
isn't useful.
If new languages like C# are significantly better than C++, then this
wouldn't be too much of a problem, because the language-independent
knowledge that developed while using C++ can be used. But if the likes
of C# have the same type of problems as C++, then we all end up having
to start from scratch again (Effective C# anyone?). This is no good for
the industry (it's inefficient), and no good for experienced
programmers (their experience is devalued).
So in the industry as it exists at the moment, I simply don't buy the
argument that being a Good Programmer (or Software Engineer if you
wish) is all that matters. Another example is knowledge of the details
of Win32. I think I'm a fairly competent C++ programmer, but in the
last year or so I've moved from propriatry/Unix systems to Win32 work,
and it's a real struggle to actually do anything useful because there's
so much (non-conceptual) stuff to learn about.
To me, this is the real problem with Microsoft's domination of the
industry. They seem to keep on finding ever more complicated ways of
implementing stuff that was invented and understood twenty years ago,
rather than figuring out genuinely new things that would make computers
easier to use and programme.
- Julian
Sent via Deja.com
http://www.deja.com/
Dietmar Kuehl
ZHN (z...@aol.com) wrote:
: The question here is what is the solution? What does the
: C++ community need to do(both from a technological viewpoint as well as from
a
: political perspective) to stop this insidious devaluation of the C++
: programmer?
First of all, I can't see a real problem: I'm using the language which
is appropriate for a certain task which means that I'm using many more
language than just C++. My current working set includes C++, Java,
Python, CorbaScript, PHP, XSLT, and make. ... and that are just the
languages I'm using side by side in the current project. It is good to
have the right tool at hand. I haven't looked at C# yet but I guess
that sooner or later I will learn this one, too, at least to the degree
where I can determine for what I would use it such that I can use it
where appropriate.
On the other hand, I'm clearly doing most of my work in C++ for a very
simple reason: C++ is not restricting me in any way. People often say
that C++ is not purely object oriented. Exactly! What I can't
understand is why this would be considered to be a bad thing. It is
good that C++ provides more than a very restricted tool: Object
orientation alone is pretty useless! You end up creating a mess similar
to the stuff created by structured programming when trying to solve
problem for which object orientation isn't well suited. That is, I
would appreciate it if C++ is maintained and supported in the future,
too. To make C++ more attractive, I would like better support for some
features like
- functional programming, ie. closures and lambdas in some form
- type information with capabilities similar to Java's reflection
- better template support, most notably something like 'typeof()'
I think that things like these may be subject to the next round of
standardization. This means, however, that someone should go ahead
and write corresponding proposals suitable for standardization.
What is, however, more important is the support of lots of tools to do
things like arbitrary internet connection (getting URLs, sending
e-mails), GUI components (the whole suite: from a simple label, over
buttons, menus, editors, to video players), database access (one
interface to all kind of database systems), and lots of other stuff.
That is what makes use of Java (and probably also C#) so easy:
Everything is already present and you can just use it. However, I don't
like the approach taken by Java to provide this stuff, ie. blowing up
the "language" definition by a huge library with components for
basically everything - normally with a lame interface which stabilizes
at a bad compromise after several versions. That is, I don't think that
the language standard should be extended by such library components.
Instead, I got the view that a new standard (or set of standards) is
created which defines such library components. Boost is moving towards
this direction and may provide all we need eventually but in this case
it is simply moving to slow...
One option to get on par with Java would be a tool which just takes
Java code and provides a C++ interface to it: Hijacking Java to provide
a first shot at all these tools like a platform independent GUI. This
is obviously possible, if necessary going via CORBA. The problem with
this is that certain things have lame performance in Java. However, the
marketing buzz is putting the money where Java is (and maybe where C#
is) and not where C++ is. Thus, the C++ community just doesn't have the
capacity to create all this stuff themselves, unless these efforts
become better orchestrated, that is.
Thinking about the stuff written above, I think a summary would be
this: To me (note that this is my personal feeling and no judgement
which applies generally) the Java language sucks (although there are
some nice features like reflection and something similar to lambdas)
but Java comes with a huge library of useful components. The C++
language is brilliant (note that this is again my view) but C++ comes
only with a small library. Although the stuff which is in the C++
library is superior to the equivalent stuff in the Java library, it is
not sufficient and lots of the stuff in the Java library is missing in
C++.
As a final note, I also want to point out that C++ can not really
compete where binary platform independence is necessary. That is, lots
of hype is centered around things sent to the client. That's a market
not addressed by C++ (unless the C++ decides to create a suitable byte
code and a corresponding interpreter). Since this area is most visible
lots of work in C++ is simply ignored by the public.
--
<mailto:dietma...@yahoo.de> <http://www.dietmar-kuehl.de/~kuehl/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
James Kanze
> In article <20010104121404...@ng-fk1.aol.com>, ZHN
> <z...@aol.com> writes
> >If nothing else this is a very serious question simply becuase it
> >implies the possibility of being undervalued as a programmer. In
> >fact it's sad to see a newbie java programmer being worth up to
> >twenty percent more than an overly experienced C++ programmer is
> >worth in some markets.
> C++ is just a language in which programmers work. Good programmers
> are multilingual. Mediocre ones follow the fashion of the day.
You know that, and I know that, but the people who are hiring don't.
I once know a guy who was refused an interview because he had Unix
experience (on a Sun) and the customer wanted Sun OS. Impossible to
convince personel that they were two names for the same thing, much
less that the experience on one OS is easily transferrable to another.
(This was in the pre-Solaris days.)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> Well there you have it. I am a little concerned with events in the
> market place at this time. Certainly java, and C# will have a
> devastating impact on c++ int the near future. In fact I have been
> looking at microsoft NET technology only to find that c++ is really
> being phased out to a great extent.
I'm not sure what NET technology is, but I can assure you that the
market for good C++ programmers is as good as ever. Maybe better;
most of the follow the fad crowd have moved on, so when you present
your CV, you aren't competing for attention with a lot of people whose
only real skill is churning out an impressive CV.
For the moment, I haven't seen Java replacing C++ that much. More
often, it's either creating new applications completely (where C++
will eventually also have a role to play), or it is replacing Perl,
Tcl, or Visual Basic. In the long run, I think that Java, and
probably C#, will help C++.
> If this trend continues we may find ourselves having to give up a
> great deal of what we've learned for some proprietary language or
> other. If nothing else this is a very serious question simply
> becuase it implies the possibility of being undervalued as a
> programmer. In fact it's sad to see a newbie java programmer being
> worth up to twenty percent more than an overly experienced C++
> programmer is worth in some markets.
In some markets. I've both in my CV, and I don't see a difference in
the offers according to the language. I do see a difference according
to the domain: e-Business seems to offer considerably more than other
fields, and that is mostly Java, but also XML and networking
experience. Also, technico-commercial will definitely outpay any
purely technical work, for those who prefer talking about software to
producing it.
> Here we are with what is the most flexible, most capable (and most
> taxing) language around and yet worth half of what others may be
> worth with half the brain fatigue that we have to suffer..
Because it's always been that way. The pointy-haired manager
definitely makes more than Dilbert, and Wally probably makes the
same. Off hand, I've never seen a company where technical skills were
rewarded as much as managerial skills. And to be honest, I think this
is probably correct, WHEN real managerial skills are present. A good
manager will improve the productivity of everyone under him. (And I
say this fully recognizing that my managerial skills are close to
zero.)
> Why?
> The question here is what is the solution?
> What does the C++ community need to do(both from a technological
> viewpoint as well as from a political perspective) to stop this
> insidious devaluation of the C++ programmer?
Nothing.
Compared to, say electronics engineers, C++ programmers have it very
good. Many would claim that we are already overpaid:-). Compared to
sales or management, of course, programmers in any language aren't
doing that well, but that's always been the case, and probably always
will be.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Francis Glassborow
de...@op59.net> writes
>If new languages like C# are significantly better than C++, then this
>wouldn't be too much of a problem, because the language-independent
>knowledge that developed while using C++ can be used. But if the likes
>of C# have the same type of problems as C++, then we all end up having
>to start from scratch again (Effective C# anyone?). This is no good for
>the industry (it's inefficient), and no good for experienced
>programmers (their experience is devalued).
I think you have just put your finger on one of the major causes of
problems in the software industry.
I have been heard to say, cynically, that it was about time the UK had a
new exam system because parents and employers had got to understand the
current one (and yes, we soon had a new system:) Perhaps the same
applies to computer languages, as soon as some people have come to
understand a language it is time to move on and invent a new one.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Jim Hyslop
dietma...@yahoo.com wrote:
[snip]
> However, the
> marketing buzz is putting the money where Java is (and maybe where C#
> is) and not where C++ is.
word!
C# isn't about languages, it's about marketing. Microsoft is much better
at marketing than they are at providing quality software.
C++ will not go away and die, for a couple of reasons. First, C# is
targeted specifically at Windows networking applications (if I
understand it correctly). You cannot use it on any other platform,
including embedded software. Second, there is a C++ huge code base now.
Heck, if COBOL can still be alive and kicking in the 21st century, what
makes you think C++ is gonna shrivel up and disappear? :-)
> As a final note, I also want to point out that C++ can not really
> compete where binary platform independence is necessary. That is, lots
> of hype is centered around things sent to the client.
[snip]
Is there any product that can deliver binary platform-independence?
--
Jim
To suppress Deja's product links, add this header:
x-noproductlinks: yes
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrea Ferro
Chris Peter S. says:
>place at this time. Certainly java, and C# will have a devastating
impact on
>c++ int the near future. In fact I have been looking at microsoft NET
>technology only to find that c++ is really being phased out to a great
extent.
Only partially agreed. The kind of problems the paltform addresses
(and most importantly the philosophy there) is not the same adressed
by C++. Others already had their point on this:
Dietmar Kuehl says:
>What is, however, more important is the support of lots of tools to do
>things like arbitrary internet connection (getting URLs, sending
>e-mails), GUI components (the whole suite: from a simple label, over
>buttons, menus, editors, to video players), database access (one
>interface to all kind of database systems), and lots of other stuff.
and Mike Smith says:
>Very key words there - "in some markets". If you're looking for
someone to
>write Web-enabled applets, then Java is a clear choice over C++. If
you're
>looking for someone to write, say, real-time machine vision or data
>acquisition applications, then Java's not so attractive. Remember,
what is changing is that there used to be a huge fraction of
applications
that were in the C++ "domain". Now there's a big lot of new stuff. Not
so
many years ago the internet was completelly different than it is today.
Applications used to run on whatever platform and eventually communicate
with other applications running on a phisically different machine. Think
to client server. The client was an application. The server was mostly a
different one. Sometimes you only had SQL. Sometimes you had more logic
on the server. In some cases you had RPC. This is still C. Than OO came
and C++ and RPC was to become CORBA. Now the model is different: the
client is gonna become a browser. Port 80 (HTTP) is gonna become the
primary communication channel. XML and SOAP could already replace RPC
and CORBA. Less efficient? Remember that new applications are no more
a company server serving a bunch of LAN (or WAN) clients. It's an
internet server application serving the whole internet. An in some cases
it's gonna be B2B, that's a server serving a remote server.
In a LAN you can listen and open whatever port without much concern for
security as long as the LAN is behind a firewall (and remote clients can
use tunneling). But what if the client is remote and NOT under your
control. You cannot install something on a client. How many C++
applications can remote between a client and a server when the server
is separated from the internet by a double firewall (DMZ) and the client
is on an unforeseable platform somewere on the internet behind one or
more firewalls and proxies and finally behind a NATing router.
Since the biggest fraction of development today is of that kind, it is
no surprise that:
>it's sad to see a newbie java
>programmer being worth up to twenty percent more than an overly
experienced
this all, to me, is like a deja-vu. Anybody remembers "Decline and Fall
of
the American programmer"? The paradigm changed from centralized
mainframe
to distributed LAN based PCs. And
>If this trend continues we may find ourselves having to give up a great
deal
>what we've learned for some proprietary language or other. If nothing
else
>this is a very serious question simply becuase it implies the
possibility of
>being undervalued as a programmer.
What gives the C++ programmer the right to think he would have been
invunerable to a paradigm shift like the one just "killed" the cobol
programmer? But is the cobol, rpg etc. programmer dead at all? I do not
think C++ will die. It just will not cope with the new kind of
applications.
And it may evolve as Assaf Lavie says:
>Why would you want to 'prevent' C++ from making way to newer languages.
>...
>C++ is great, but it can most certainly be improved. What better way of
>perpetuating C++ is there than allowing it to exist forever in other
>'derived' languages?
and Julian Smith:
>If new languages like C# are significantly better than C++, then this
>wouldn't be too much of a problem, because the language-independent
and Dietmar Kuehl:
>Instead, I got the view that a new standard (or set of standards) is
>created which defines such library components. Boost is moving towards
>this direction and may provide all we need eventually but in this case
>it is simply moving to slow...
>
>As a final note, I also want to point out that C++ can not really
>compete where binary platform independence is necessary. That is, lots
>of hype is centered around things sent to the client. That's a market
>not addressed by C++ (unless the C++ decides to create a suitable byte
>code and a corresponding interpreter). Since this area is most visible
>lots of work in C++ is simply ignored by the public.
of course the paradigm shift I was mentioned does not come from nowere.
Mike Smith has a point here:
>businesses don't hire developers in order to give them an opportunity
to
>work on something for fun; they're out to make money. It makes sense
to
>apply the most applicable tool to the problem at hand.
you say:
>flexible, most capable (and most taxing) language around and yet worth
half
>what others may be worth with half the brain fatigue that we have to
suffer..
>...
>C++ community need to do(both from a technological viewpoint as well as
from a
>political perspective) to stop this insidious devaluation of the C++
>programmer?
flexible, but not so flexible that it is the best language for any
possible problem. And the C++ community, assuming it's mostly made of
C++ programmers, should act neither politically nor technologically.
We should maybe act on ourselves. As soon as solutions of new problems
emerge as new languages, we may try to keep updating. So far Java was
the
mos C++ like language on the internet. But do have a look on the
premises
of C#. It is proprietary for the moment. Of course: it's first compiler
is
still beta. Would you say "C with classes" and the C++ you had with
C-front
were anything but proprietary languages ? Have you an idea of the time
it
took to "baby" C++ to become a real language? How long do you think MS
has
been working on C#? I did not yet know that language, but each time I
study
a new bit of it ... it looks more and more like the language I would
design
to inprove C++. Maybe with just a little bit too emphasis on some types
and
conventions that are more MS than "unix". But COM and CORBA are not that
different after all. And Variants are not that much of a bad idea. Of
course
C# assumes a complex runtime environment. Almost a little OS by itself.
But
it's not made to write low level code. It's made to handle the philosofy
of "Microsoft.NET". And can you really say that's not the philosofy the
largest part of the industry is moving toward? Did you notice the stp
turn MS took to "port" it's platform toward internet some years ago?
Internet was born in unix. Suppose a completelly new paradigm emerges
that is foreign to both NT and unix. Who would you bet on to be the
fastest to adapt? I'm not defending MS. I do not like MS. But it is not
true that MS is sucessfull only because it's big. Thes leads us to what
Julian Smith says:
> Another example is knowledge of the details
>of Win32. I think I'm a fairly competent C++ programmer, but in the
>last year or so I've moved from propriatry/Unix systems to Win32 work,
>and it's a real struggle to actually do anything useful because there's
>so much (non-conceptual) stuff to learn about.
>...
>To me, this is the real problem with Microsoft's domination of the
>industry. They seem to keep on finding ever more complicated ways of
>implementing stuff that was invented and understood twenty years ago,
>rather than figuring out genuinely new things that would make computers
>easier to use and programme.
not reallly agreed. There's a LOT of new stuff. And a LOT of details are
there for compatibility to old versions. You do not really need them.
Unfortunatelly there's no clear line between what's old and what's new.
Also reinventing things is because they actually have several
overlapping
technologies. And if you go and study them ALL (not worth unless you are
retired and have a lot of time) you can see the milestones of computing
history there.
The real problem to face is not just to keep studing, is to keep up with
the speed of evolution. Take it this way: forget the Win API, just go
and
see .NET. See how the managed to have multiple languages converge on a
uniform environment. And an environment that is a platform that is a
high
score on what the industry needs right now. Then figure they had to
foresee where the industry was gonna go before getting to do that. And
compare the size of the platform and the time it took them to do it
(fiew
years). Finally immagine what it will be out in the next 5 years,
remembering 5 years ago MS platforms almost did not have a TCP/IP stack!
I'm not scared because C++ cannot handle the new problems. I'm scared
because I suspect 95% of current tecnologies will be outdated in fiew
years. Technologies like CORBA, are already. And in a sense the TCP/IP
itself is. They can do almost anything just on HTTP! Figures?
--
Posted from adsl-21-135.38-151.net24.it [151.38.135.21]
via Mailgate.ORG Server - http://www.Mailgate.ORG
Balog Pal
> That's true to an extent, but I think you underplay the amount of time
> it takes to master the language-specific details of C++. There are
> whole books devoted to explaining C++-specific problems (e.g.
> Effective/More Effective C++),
Books like you mention exactly help the learning process. For other
languages you don't even have those morality guides and the distilled wisdom
what traps to avoid. Tha lack of alike books for others does not mean that
language ie easier to use in life.
> and most people don't have time to study them properly,
Well, it's their problem. And ours in the outcome. A plenty of professions
are tied to license, so whoever is allowed to practice them is behind a
verified learning process (like an MD or an engineer). On the field of
programming everyone is entitled to sell snake oil, and who pays for it
generally can't tell the difference.
> let alone do the same for other languages as well. If
> the industry suddenly switches languages, that means that lots of
> programmers find themselves with lots of hard-won knowledge that simply
> isn't useful.
I don't see how that happens. Industry is about making money. It will not
shift to other languages wthout rreason, especially if it has investent in
the old one, and good results too. Sure a plenty of pilot projects may be
initiated, but looking around I see almost all such attemts leading to
complete failure. Like the old day's visual basic trap. You can make the
first few steps extremely fast, that makes the impression of big progress.
You feel the fisrt 90% ready in few weeks. Then the rest10% takes years, or
you just can't make it work reliably.
> If new languages like C# are significantly better than C++, then this
> wouldn't be too much of a problem, because the language-independent
> knowledge that developed while using C++ can be used. But if the likes
> of C# have the same type of problems as C++, then we all end up having
> to start from scratch again (Effective C# anyone?). This is no good for
> the industry (it's inefficient), and no good for experienced
> programmers (their experience is devalued).
Do you think C# is any better than C++? Is it available on almost all
platforms? Are there any types of application that can be made faster, and
more reliable? If all the gain is that even people with IQ 20 lower can
learn it to some medium level, I think it's not a big deal. Those peole
generally just create mess regardless which language or tools they happen to
use.
> So in the industry as it exists at the moment, I simply don't buy the
> argument that being a Good Programmer (or Software Engineer if you
> wish) is all that matters.
Being a good anything never worked out alone. Especially if you measure
success in terms of $ earned. I know lots of very good doctors, teachers,
lawyers, carpenters, etc, who make much less money than other, worse but
more lucky people (or with other benfits putting them on top, like
relations.)
> Another example is knowledge of the details
> of Win32. I think I'm a fairly competent C++ programmer, but in the
> last year or so I've moved from propriatry/Unix systems to Win32 work,
> and it's a real struggle to actually do anything useful because there's
> so much (non-conceptual) stuff to learn about.
That's life. :) Some years ago I had pretty good knowledge of programming
the DOS api, and WIN3.1, which made the benefit in the time, but is just
dead knowledge now. But I would definitely cry if someone wanted me to write
something targeting that platform, without an extremely good reason. WIN32
and the other more current systems have so much good stuff.
> To me, this is the real problem with Microsoft's domination of the
> industry.
If you can offer anything better fit for typor purpose you'll likely
convince the management. In the time between notice that domination
originates from the lack of strong alternatives. And for that not MS is to
be blamed. Especially taking into account the possible competitors. IBM
could have created a working OS/2, but it never took itself seriously.
Then, NT4 is not at all that bad to be bashed. You can do anythin on it,
without really much effort, and without much dealing with M$. Is the unix
you left behind superior? I don't think so.
> They seem to keep on finding ever more complicated ways of
> implementing stuff that was invented and understood twenty years ago,
> rather than figuring out genuinely new things that would make computers
> easier to use and programme.
And who requires you to jump on any of those new shiny tech, instead of
using the ones you used in the last few years without problems? Most of
those are not serious, just read M$ itself. Use DAO. 6 monh later, DAO is
obsolete, use ADO, another half year: ADO sux, use RDO, OLE-DB, or whatever
buzzword they found for the next vaporware. I never install anything M$
produces before at least 2 (preferably 3) service packs are issued, and for
technologies 1 year wait is essential. By that time with high chance it's
flushed by its creator.
Paul
Francis Glassborow
<James...@dresdner-bank.com> writes
>You know that, and I know that, but the people who are hiring don't.
And that is one of the most serious problems facing the industry.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
"Andrea Ferro"
>C# isn't about languages, it's about marketing.
almost agreed. As a matter of fact C# isA language. At least
no less a language than Java or any interpreted/JIT-Compiled
language can be.
>Microsoft is much better
>at marketing than they are at providing quality software.
that I DO subscribe!
>C++ will not go away and die, for a couple of reasons. First, C# is
>targeted specifically at Windows networking applications (if I
>understand it correctly). You cannot use it on any other platform,
>including embedded software. Second, there is a C++ huge code base now.
>Heck, if COBOL can still be alive and kicking in the 21st century, what
>makes you think C++ is gonna shrivel up and disappear? :-)
Agreed that C++ will not die. And I also subscribe COBOL as an
example. But as far as I know C# is gonna be standard. MS will
obviously be somehow involved being some guys there the C#
equivalent to Stroustrup for C++. But it will be ISO/ANSI to
actually work on the standard. This is not gonna happen next
week, of course! As far as C++ comitee started before C was
finished, chances are that ANSI/ISO C# will be done after
C# sucessor is alive and kicking!
Also C# is not confined to Win. As far as I know MS is not gonna
work on any other implementation. But they already have promises
of support from other parties. If C# proves anything but useless
you will see it on some Unix someday. However it is to be noted
that C# is not actually the target of the port. The environment
is. If you port the runtime environment of the .NET platform
then C# (as well as many other tools and add ons) will come along
for free. This is almost the reverse of the relationship between
Unix, a HAL core platform and C. Whatever HW you may invent, just
port an appropriate HAL core and a C compiler. Unix itself comes
for free. This is simplifyed of course, but almost true. Same
there. Whatever HW and OS your platform is, port the core of the
environment and all the tools come along. C# included.
>> As a final note, I also want to point out that C++ can not really
>> compete where binary platform independence is necessary. That is,
lots
>> of hype is centered around things sent to the client.
>[snip]
>Is there any product that can deliver binary platform-independence?
Depends on what you consider binary. If you are thinking it the
C/C++ way, not as far as I know. But if you do not develop kernel
software or low level hight-speed stuff like CAD and similar, than
you have more chances. For some (limited) extend, Java is portable.
However Java actually failed to be really platform independent. One
of the ideas behind .NET (and therefore C# too) is to exploit the
idea of a virtual environment. C# deliverables are binary but not
silico-binary. They are targeted to a "virtual processor". And they
assume a specific environment (also somewhat virtual). This is not
much different than the idea of a HW abstraction layer. It is in
fact an OS abstraction layer. Of course JIT compiling is as
feasible as interpreting or install time compiling (or even
developing a silicon executer, if you are no less strong than
intel/motorola/ibm and such are).
Therefore C# will probably never be usable for developing some
sort of SW. But this means not it will be "slow". Just it assumes
a particular environment. I foresee flames on C# speed. We had
them on C++ speed compared to C. Expecially because of "hidden"
parameters like this, virtual functions being "slow" and similar
"problems". There were flames comparing C++ and Smalltalk method
invocation too. Of course C# will be compared. And will be slow or
as fast as. But there's a HUGE number of applications that you may
develop in C#. And it may prove powerfull enough to develop air
traffic management or similar very large applications. And it may
also prove, on many respects, better than Smalltalk or C++ in
doing that. But it will never beat C++ on CAD. Think it this way:
COBOL is still here. It was not hurt by C++ and OO. It was hurt
by the diffusion of mice enabled graphical desktops and SQL
servers. What language would you pick today to handle a
text-screen application with data on record structured files?
I would still pick COBOL. Just there are no more many of those
apps needed. C++ will die when C++ specific apps will. It will
be hurted a bit know because new kind of apps are needed and
because new more specific languages are coming. When they were
not here, you had no choice. Let's put it this way: if all you
have is a hammer everithing looks like a nail. But a screwdriver
will not totally displace a hammer. It's just for screws. Unless
you decide to just use screws and glue and get rid of nails, you
will still need your hammer.
--
Posted from adsl-21-135.38-151.net24.it [151.38.135.21]
via Mailgate.ORG Server - http://www.Mailgate.ORG
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Chris Newton
> Well there you have it. I am a little concerned with
> events in the market place at this time. Certainly java,
> and C# will have a devastating impact on c++ int the
> near future.
[...]
> The question here is what is the solution? What does
> the C++ community need to do(both from a
> technological viewpoint as well as from a political
> perspective) to stop this insidious devaluation of
> the C++ programmer?
The way I see it, C++ has two basic problems.
1. C++'s PR is very bad.
2. The C++ language has some silly fundamental flaws.
These are not independent problems.
Many of the good bits of C++ were only finalised to the point of
usability with the '98 standard. Many of the big C++ apps out there are
older than that, and hence use C++ as it was in the early days. For
example, the application framework we work with at work was written
in-house starting from about five years ago. We use exceptions, but no
STL, templates, namespaces, etc. They just weren't around then, it's too
much work to retrofit them onto 500K lines of code, and it creates too
much stylistic inconsistency with old code to start tacking them on now.
Compared to that age of C++, most of the new pseudo-clones are indeed
much better.
Notice that it's taken until this past year for the first introductory
book to be published that actually treats C++ as more than enhanced C
(Accelerated C++). By now, most of the newbie programmers it's aiming
for are long gone. The old hands often refuse to accept that C++ has
moved on, and have skills in the language 5 years out of date.
In between are those of my generation, who learned C++ in the mid-late
'90s, but we are stuck with old projects or old managers. If the C++
community can't get the message across to those people, and soon, then I
predict with some confidence that C++ will turn into the next COBOL
before the next version of the standard sees the light of day. The
people young or aware enough to be up-to-date will have moved on, and
C++ will be regarded forever as the dinosaur that, ten years ago, it
was.
But seriously, technology does move on. C++ is a good language, but
certainly better can be done. What irritates me is that, while C++ is
fundamentally handicapped or even broken in several ways, these new
languages don't actually seem to fix them. I can entirely see why Bjarne
Stroustrup gets upset at unfair language comparisons at this point.
For example, we get wonderful code examples, such as the following
(which I've borrowed from Nicolai Josuttis's Compse library on Boost):
pos = remove_if (coll.begin(),coll.end(),
compose_f_gx_hx(logical_and<bool>(),
bind2nd(greater<int>(),4),
bind2nd(less<int>(),7)));
I'm sorry, but that's just hideous, and I wouldn't dream of writing it
in a real program. It's a necessary hack because C++ is fundamentally
broken in this area. Functional languages have had the equivalent of the
following for years (syntax invented to make the point):
pos = remove_if(coll.begin(), coll.end(), (x)->(x > 4 && x < 7));
Adding such a simple lambda-function to the power of the STL algorithms
would have been a huge step forward. In fact, adding something along
those lines would be almost trivial; it just requires an "anonymous
function" concept, and the syntax to write one. It's hardly a challenge
for professional compiler writers! And yet, who has done this in their
new language? No-one.
C++ has a great thing in the STL, and handicaps it by forcing
programmers to write the sort of <expletive deleted> quoted above. I
stress that no offence toward Mr Josuttis is intended here. The fact
that the code above is required is a weakness of the language, and the
fact that he's trying to help fix it is admirable. But in the long run,
languages where you can write the second version are just better than
C++, end of story.
The same goes for silly things like the new-style casts. It's lovely
that the academics think that static_cast<>, dynamic_cast<>, etc. should
look ugly because casting is ugly. In the real world, most programmers I
know turn around and say "stuff that, it's hard to read, I'm going to
write (int)x". That includes a lot of the good ones, who value
readability and maintainability as much, if not more, than using the
latest fads in technical correctness.
Given examples like these, is it any wonder that those managers who are
five years behind the times don't see the merits of the STL?
Now, as I said, the truly irritating thing is that the "new" languages
like Java and C# don't address these genuine problems. Instead, they
make a big play of things like replacing all of the .s, ->s and ::s with
just .s. Personally, I find it slightly harder to follow code written in
that style, but either way, it's hardly the great leap forward people
make it out to be. Similarly, they hype things like adding garbage
collection (which is useful, but fundamentally handicapped, at least in
Java) and improved type-safety (which is fundamentally broken in C#).
These things could be the saving grace of C++. On technical merits, I
don't feel there is yet any language that makes great advances over C++.
(When there is, I will move on to program in it.) Obviously the new
languages have good points. Java is much better suited to internet
development, for example. But these are limited areas, small in relation
to the overall field of C++ development. Until something radical comes
along and fixes the fundamental weaknesses of C++, it will continue to
have genuine merit.
Ultimately, what we need is to convince the senior guys that C++ is
still evolving and remains useful. And that takes good PR, which right
now, we don't have. As a slightly radical suggestion for consideration,
renaming the language to something that doesn't sound like it's twenty
years old, combined with a decent branding effort, would help. Too many
managers think C++ came from the stone age, because they're too stupid
and ill-informed to find out any better.
What we also need is for the next revision of C++ to fix the more
glaring weaknesses. In particular, I'd cite the complete absence of:
- a lambda function to combine with the STL;
- a standard threading library;
- a standard garbage collecting mechanism
as the three biggest fundamental flaws in the language as it stands. Add
these things, in a way that fits with the langauge as it stands, and
once again C++ is way ahead of the other languages in the technical
race.
Ironically, none of these is far from the current state of development.
People have produced close approximations to all of them. See, for
example:
- http://www.oonumerics.org/tmpw00/striegnitz.html
- threading classes in every toolkit out there
- http://www.boost.org/libs/smart_ptr/smart_ptr.htm
respectively.
Obviously, work goes on both for PR and for language development. The
ACCU have had numerous articles in their magazines and presentations at
their conferences on the newer aspects of C++. The standards guys
obviously devote considerable effort to finding and fixing the language
flaws. The question becomes: what do we, the average C++ users, need to
do to help these people do these things better?
If we can answer that, C++ will live. If we can't, it will die.
Just my $1,043,655 and 2 cents :-)
Chris
Daniel James
> C# isn't about languages, it's about marketing. Microsoft is much better
> at marketing than they are at providing quality software.
I don't think so. I think C# is a little about languages but mostly about
politics.
The languages side is that Microsoft clearly feel the need for a
high-level object-oriented language producing platform-independent
executable code suitable for distribution on the internet, and directly
supporting calls to components and interfaces written in native code.
That's where the politics come in. I think MS would have been quite happy
using their extended Java, but Sun's court action prevented them from
extending Java to support, for example, COM interfaces. MS's extensions
reduced the portability of Java applications that used them by tieing them
to the MS Java compiler and the Windows JVM - but any application that's
going to use COM it's pretty-much tied to Windows anyway so I can only
view Sun's actions as gratuitous Microsoft-bashing of the worst kind.
Prohibited from extending Java, MS felt they had to invent an entirely new
language - unencumbered by any use of the 'J'-word - in order to support
applications that otherwise might have been written in Java. That they
have felt obliged to do this is a tragedy for the computing industry -
there is now another language to learn (at least for those of us who earn
our living by working all or partly with Microsoft's systems) that offers
little new.
Note that none of this has anything to do with C++, it's all about Java.
C# competes with Java, not with C++.
> ... C# is targeted specifically at Windows networking applications
> (if I understand it correctly). You cannot use it on any other platform,
> including embedded software.
C# is one of MS's .NET languages, all of which target a new Intermediate
Language (IL) that MS have had to invent because Sun won't let them use
Java Bytecode. MSIL is apparently richer than Java Bytecode in that it
provides fuller support for languages other than Java that need to
generate code to manage, for example, pointers.
If I understand it correctly, MSIL is supposed to be an open standard that
can freely be ported to other platforms than Windows - whether this will
ever happen depends on any number of things, of course. I also understand
that translators will be avilable to translate MSIL applications to native
code (at least for Windows).
MS are apparently still developing Visual C++ (and crawling slowly towards
the ISO language) and there is even supposed to be a C++ version for .NET
(called "Managed C++", if the magazine I have before me is to be believed)
- so even MS don't see C# replacing C++.
Cheers,
Daniel
[nospam.demon.co.uk is a spam-magnet. Replace nospam with sonadata to
reply]
Martin Berger
> What we also need is for the next revision of C++ to fix the more
> glaring weaknesses. In particular, I'd cite the complete absence of:
> - a lambda function to combine with the STL;
> - a standard threading library;
> - a standard garbage collecting mechanism
the problem is that such things are not at all easy to integrate
into C++ with all its problems. i hope that C++ will die as soon
as possible to give way for a language that has all the advantages
of C++ (aptly summarized as: "C++ is the second best language for
everything"), but is done right from the start. such a language
does not exist now and C++ cannot evolve into it. however most
(but maybe not all) of the technology is already out there
and needs only to be assembled, be it with regards to types,
memory management, module systems or compilers.
it would be great if rather than jealously guarding c++ territory
against upstarts such as Java or C#/.net, the much admired experts
in this and related forums would get together and begin to work
towards a C++ replacement. it would be much better & would arrive
much earlier with their input & help than without.
martin
Francis Glassborow
Andrea Ferro <And...@UrkaDVD.it> writes
>Agreed that C++ will not die. And I also subscribe COBOL as an
>example. But as far as I know C# is gonna be standard. MS will
>obviously be somehow involved being some guys there the C#
>equivalent to Stroustrup for C++. But it will be ISO/ANSI to
>actually work on the standard. This is not gonna happen next
>week, of course! As far as C++ comitee started before C was
>finished, chances are that ANSI/ISO C# will be done after
>C# sucessor is alive and kicking!
When MS have even less reason than Sun Microsystems for actually getting
an ISO/ANSI standard? That sounds like a triumph of hope over
experience:)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
writes
>I don't see how that happens. Industry is about making money. It will not
>shift to other languages wthout rreason, especially if it has investent in
>the old one, and good results too.
But the problem is the precipitous way they jump to a new language.
Those making the decisions too often do not understand (think of
dot.coms)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<chris...@no.junk.please.btinternet.com> writes
>The same goes for silly things like the new-style casts. It's lovely
>that the academics think that static_cast<>, dynamic_cast<>, etc. should
>look ugly because casting is ugly. In the real world, most programmers I
>know turn around and say "stuff that, it's hard to read, I'm going to
>write (int)x".
No responsible programmer would do that:) Quite apart from anything
else, you would now have to add a comment explaining why you cast. Which
will take even longer and be subject to all the multitude of problems
associated with keeping comments up to date. Next you will be telling us
that single (colour coded:) variable names are the way to go. (read
Bjarne's paper on colour coded variables:) Published in Overload, April
1998.
>
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Sergey P. Derevyago
[snip]
> What we also need is for the next revision of C++ to fix the more
> glaring weaknesses. In particular, I'd cite the complete absence of:
> - a lambda function to combine with the STL;
> - a standard threading library;
> - a standard garbage collecting mechanism
> as the three biggest fundamental flaws in the language as it stands. Add
> these things, in a way that fits with the langauge as it stands, and
> once again C++ is way ahead of the other languages in the technical
> race.
A very good post, i'm really impressed.
BTW I don't think that "a standard threading library" is an easy
thing to get.
AFAIK it can't be done without some (significant?) overhead on all platforms,
which violates a well known "zero overhead rule". However, I think some
reasonable good library can be (easily?) created. For example, we can look at
http://www.cs.wustl.edu/~schmidt/ACE.html
Next. IMHO "a standard garbage collecting mechanism" is not so usefull and can
be easily adressed in terms of STL or some other framework.
And I have (at least) one issue to add. IMHO C++ exception
handling is
conceptually far from perfect (yes, it's yet another "major chutzpah" ;) I
think that the throw(???) clause is implemented exactly in a reverse way.
IMHO
compiler needs exactly one answer: whether function can throw. It doesn't
matter _what_ it gonna throw. So it seems like a nothrow keyword would be
much
more useful. Consider:
1.
// f can throw what it wants
void f()
{
// ...
}
2.
// f is not allowed to throw (checked at compile time)
void f() nothrow
{
// ...
}
3.
void f()
{
// ...
nothrow { // you can't throw in this scope (checked at compile time)
// ...
}
// ...
}
IMHO with nothrow clauses and blocks one can easily create exception-safe
code,
which is a nightmare in current C++.
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
Francis Glassborow
Berger <martinb@--remove--me--dcs.qmw.ac.uk> writes
>it would be great if rather than jealously guarding c++ territory
>against upstarts such as Java or C#/.net, the much admired experts
>in this and related forums would get together and begin to work
>towards a C++ replacement. it would be much better & would arrive
>much earlier with their input & help than without.
The World already has enough 'perfect' languages that few outside
academia actually use:)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Balog Pal
"Chris Newton" <chris...@no.junk.please.btinternet.com> wrote
> Notice that it's taken until this past year for the first introductory
> book to be published that actually treats C++ as more than enhanced C
> (Accelerated C++).
I don't think so. I didn't make a real stat, but all books I remember to
read stated C++ is a new language, not a C with extras. Can't fing my C++
Primer, but it is as old as C++ and I'm sure it writes that too.
Paul
Dean Roddey
something better doesn't come along, then something worse will take its
place. I don't think that Java and C# are without their places, but they
aren't want I'm looking for for the kind of work I want to do. As soon as I
get rich, I'll start working on this problem :-)
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
dro...@charmedquark.com
http://www.charmedquark.com
"It takes two buttocks to make friction"
- African Proverb
"Martin Berger" <martinb@--remove--me--dcs.qmw.ac.uk> wrote in message
news:3A587697.591745F4@--remove--me--dcs.qmw.ac.uk...
> the problem is that such things are not at all easy to integrate
> into C++ with all its problems. i hope that C++ will die as soon
> as possible to give way for a language that has all the advantages
[snip]
> towards a C++ replacement. it would be much better & would arrive
> much earlier with their input & help than without.
>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dean Roddey
language, I don't agree with the statement quoted below. I find that I don't
even have to think about how to write exception safe code anymore, its just
completely natural and not that hard. If you have a powerful suite of
'janitorial' classes, the vast majory of issues are handled trivially.
And, I think I'd have to consider *very* carefully about using the 'nothrow'
thing. It causes the same problems that exception specifications cause,
which is that you wire in characteristics that layer upon layer of upstream
code depends on. So if you end up having to change it, you are screwed. My
opinion is that you should just write exception safe code at all times,
because its guaranteed to work regardless of whether the underlying code
throws or not and because its just good discipline.
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
dro...@charmedquark.com
http://www.charmedquark.com
"It takes two buttocks to make friction"
- African Proverb
"Sergey P. Derevyago" <non-ex...@iobox.com> wrote in message
news:3A5887F9...@iobox.com...
> Chris Newton wrote:
> IMHO with nothrow clauses and blocks one
> can easily create exception-safe code,
> which is a nightmare in current C++.
Martin Berger
> >it would be great if rather than jealously guarding c++ territory
> >against upstarts such as Java or C#/.net, the much admired experts
> >in this and related forums would get together and begin to work
> >towards a C++ replacement. it would be much better & would arrive
> >much earlier with their input & help than without.
>
> The World already has enough 'perfect' languages that few outside
> academia actually use:)
as they say, a programming language is either use by everyone or
by no one.
academic languages are usually intended to explore a certain design
choice, usually concerning typing systems. given academic interests
and financial constraints, such languages can not be a match for
"real" languages, until for some reason or other, they get picked
up by a significant number of developers, because there is no
substitute for large scale developer input to steer language
evolution.
java, c and c++ started out that way ...
but the fact that everyone uses a language does not mean improvement
is impossible. are you suggesting that c++ is an exception upon which
no improvement is possible?
martin
Ross Smith
>
> "Chris Newton" <chris...@no.junk.please.btinternet.com> wrote
>
> > Notice that it's taken until this past year for the first introductory
> > book to be published that actually treats C++ as more than enhanced C
> > (Accelerated C++).
>
> I don't think so. I didn't make a real stat, but all books I remember to
> read stated C++ is a new language, not a C with extras. Can't fing my C++
> Primer, but it is as old as C++ and I'm sure it writes that too.
They all _write_ that, yes.
They pay lip service to the idea, but they only talk the talk, they
don't walk the walk. For all their introductory blather about C++ being
a Whole New Language, the vast majority of books on C++ still start out
by teaching you C.
The first two questions when evaluating a teach-yourself-C++ book should
be:
-- Does it teach std::vector _before_ C-style arrays?
-- Does it teach std::string _before_ character arrays/pointers?
If the answer to either question is "no", put the book back on the shelf
(prefereably the wrong shelf, to reduce the chances of some other poor
schmuck picking it up), and buy _Accelerated C++_ instead.
--
Ross Smith <ros...@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"Normally he was insane, but he had lucid moments
when he was merely stupid." -- Heinrich Heine
Francis Glassborow
Berger <martinb@--remove--me--dcs.qmw.ac.uk> writes
>java, c and c++ started out that way ...
None of those started as theoretical languages, and none of them were
written to prove a point, or support an attitude. Each was written as a
working language. I am not convinced that that applies to Pascal, the
various generations of Modula or ML1 etc.
>
>but the fact that everyone uses a language does not mean improvement
>is impossible. are you suggesting that c++ is an exception upon which
>no improvement is possible?
Where did I say that? But sometimes getting used to what you have (warts
and all) is better than fore ever looking for the end of the rainbow.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<dro...@charmedquark.com> writes
>Agreed. I use C++ extensively, and I'm hardly any basher of it. But if
>something better doesn't come along, then something worse will take its
>place. I don't think that Java and C# are without their places, but they
>aren't want I'm looking for for the kind of work I want to do. As soon as I
>get rich, I'll start working on this problem :-)
But C, C++, Forth etc. (and even arguably Java) were invented exactly to
meet what one person wanted to do, then they spread because others found
them useful. I think you need to develop your language first and that
might lead to riches:)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
writes
>"Chris Newton" <chris...@no.junk.please.btinternet.com> wrote
>
>> Notice that it's taken until this past year for the first introductory
>> book to be published that actually treats C++ as more than enhanced C
>> (Accelerated C++).
>
>I don't think so. I didn't make a real stat, but all books I remember to
>read stated C++ is a new language, not a C with extras. Can't fing my C++
>Primer, but it is as old as C++ and I'm sure it writes that too.
So why did they all start by teaching you C?
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrew Koenig
My theory is that there is strong inner pressure to teach a subject
the way one learned it. Most people in a position to teach C++
learned first. Therefore, they teach C first.
I, too learned C first--and it took me more than a decade to overcome
the pressure to teach C as the first part of teaching C++.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Dean Roddey
> meet what one person wanted to do, then they spread because others found
> them useful. I think you need to develop your language first and that
> might lead to riches:)
Its something I'd love to do, but my immediate goals are to make some bucks
off of the C++ frameworks I've put 10 years into. If I do make enough bucks
to step back and take some time on some non-immediate term goals, a language
would definitely be high on my list. I think that, having spent this long
developing general purpose OO frameworks, and now building applications on
top of them, I've gained a pretty good vision of what a good general purpose
next generation OO language would be (one that would reflect both good and
bad lessons learned from C++ and other languages.)
But, given that I have to get rich first before I can work on it, I wouldn't
hold my breath if I were you.
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
dro...@charmedquark.com
http://www.charmedquark.com
"It takes two buttocks to make friction"
- African Proverb
michel....@cstjean.qc.ca
Ross Smith <ros...@ihug.co.nz> wrote:
> The first two questions when evaluating a teach-yourself-C++ book
> should
> be:
>
> -- Does it teach std::vector _before_ C-style arrays?
> -- Does it teach std::string _before_ character arrays/pointers?
>
> If the answer to either question is "no", put the book back on the
> shelf
> (prefereably the wrong shelf, to reduce the chances of some other poor
> schmuck picking it up), and buy _Accelerated C++_ instead.
That's a little too simple... and C++ is not so simple (although
buying "Accelerated C++" is a simple and good idea :-).
In fact, I'd like to teach std::map before std::vector...
I agree std::vector must be taught as the normal thing to use
for an array, but depending on the author preferred progression,
he may have to explain C-style array first. It's not what you
teach first that matters that much, it's what you teach to
use. Most books will explain "while" and "do-while" before
"for", although there is certainly more for loops than
do-while in most people code...
As an author myself, of books that teach programming using C++
instead of teaching C++ to programmers, I wanted to introduce
std::vector first but changed my mind when I saw how many simple
things I couldn't do or explain simply because of that choice.
A vector of constants for example. I had the choice of explaining
simple C-style arrays first or postpone a number of subjects. I
chose the former mainly because I had to follow a certain
official curriculum that was independant of the language chosen.
We are now devising a new curriculum and I think it will be
possible (at least easier) to use std::vector first (and I'll
be happy to change my books).
Anyway let me assure you my students are not using C-style arrays
instead of std::vector after they've learned both.
I guess I can't see a good reason not to use std::string from the
start. But it is a pity that if you want to teach file streams,
you have to use c_str with fstream::open for example...
Choosing a book is not simple... please go deeper than the
"contents" pages!
--
Michel Michaud
michel....@cstjean.qc.ca
http://www3.sympatico.ca/
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ko van der Sloot
Francis Glassborow <francis.g...@ntlworld.com> writes:
|> In article <3A58D83C.D0EF72A0@--remove--me--dcs.qmw.ac.uk>, Martin
|> Berger <martinb@--remove--me--dcs.qmw.ac.uk> writes
|> >java, c and c++ started out that way ...
|>
|> None of those started as theoretical languages, and none of them were
|> written to prove a point, or support an attitude. Each was written as a
|> working language. I am not convinced that that applies to Pascal, the
|> various generations of Modula or ML1 etc.
|>
|> >
|> >but the fact that everyone uses a language does not mean improvement
|> >is impossible. are you suggesting that c++ is an exception upon which
|> >no improvement is possible?
|>
|> Where did I say that? But sometimes getting used to what you have (warts
|> and all) is better than fore ever looking for the end of the rainbow.
But what did we gain since good-old Algol68.
That was mostly a theoretical language. Hard to implement in those days.
Shouldnt be a problem today.
Does anyone know is/use it these days?
Ko vd Sloot
Andrea Ferro
towards
>the ISO language) and there is even supposed to be a C++ version for
.NET
>(called "Managed C++", if the magazine I have before me is to be
believed)
>- so even MS don't see C# replacing C++.
Managed C++ is an extension to C++. It is C++ enriched with a ton of non
standard extensions that ... do not byte the standard.
On the lines of __cdecl, __pascal and similar "enhanced" modifiers.
--
Posted from adsl-21-135.38-151.net24.it [151.38.135.21]
via Mailgate.ORG Server - http://www.Mailgate.ORG
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrea Ferro
Please direct C#-specific followups to email or to the
appropriate newsgroups (if any). -mod}
>>example. But as far as I know C# is gonna be standard. MS will
>>obviously be somehow involved being some guys there the C#
>>equivalent to Stroustrup for C++. But it will be ISO/ANSI to
>>actually work on the standard. This is not gonna happen next
>>week, of course! As far as C++ comitee started before C was
>>finished, chances are that ANSI/ISO C# will be done after
>>C# sucessor is alive and kicking!
>
>When MS have even less reason than Sun Microsystems for actually
getting
>an ISO/ANSI standard? That sounds like a triumph of hope over
>experience:)
This comes from a MS press release:
Standardization, industry support
Microsoft recently submitted C#'s language specifications to
the European Computer Manufacturers Association (ECMA) for its
review. The company expects the ECMA's support will lead to
standardization by the International Standards Organization (ISO).
Standardization allows multiple technology vendors to create their
own versions of C#, thus allowing developers to use the language
on more operating platforms and to choose the version of the
language that best meets their needs, Goodhew said. Standardization
also provides users, academics, vendors a say -- through the regional
and international boards -- in determining future changes in the
language, he added.
Although still months away from its commercial release, C# has
garnered strong support within the technology industry, with
numerous companies already employing the new technology. The
companies include Apex Software, Bunka Orient Co., Component
Source, devSoft, FarPoint Technologies, LEAD Technologies,
ProtoView, Seagate Software, Sheridan Software Systems, Software
Artisans, Stingray, VideoSoft, Andersen Consulting, Proxicom,
Pandesic, Razorfish, Sapient, Rare Medium, Scient, USWeb/CKS,
Viant, ActiveState, Dyadic Systems, Fujitsu Software Corp,
Interactive Software Engineering, QKS, Skippi-Net, TMT
Development, NuMega (Compuware) and Rational.
You can find the whole article at
www.microsoft.com/presspass/features/2000/jun00/06-26csharp.asp
James Kanze
> The first two questions when evaluating a teach-yourself-C++ book
> should be:
> -- Does it teach std::vector _before_ C-style arrays?
> -- Does it teach std::string _before_ character arrays/pointers?
> If the answer to either question is "no", put the book back on the
> shelf (prefereably the wrong shelf, to reduce the chances of some
> other poor schmuck picking it up), and buy _Accelerated C++_
> instead.
It's not quite that simple. In practice, the first program is hello,
world. It uses a string literal. And even in C++, string literals
are C-style arrays, which convert to a char* at the drop of a hat.
In practice, the need to interface to ofstream::open and various
initialization needs force an author to introduce C-style arrays
earlier than he might like.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Martin Berger
> think that, having spent this long
> developing general purpose OO frameworks, and now building applications on
> top of them, I've gained a pretty good vision of what a good general purpose
> next generation OO language would be (one that would reflect both good and
> bad lessons learned from C++ and other languages.)
while it won't make you rich, sharing your insights, for example in this forum,
might make you friends ...
martin
Martin Berger
> None of those started as theoretical languages, and none of them were
> written to prove a point, or support an attitude. Each was written as a
> working language.
sorry, what i meant was that they started out as languages that "no one"
used.
> >but the fact that everyone uses a language does not mean improvement
> >is impossible. are you suggesting that c++ is an exception upon which
> >no improvement is possible?
>
> Where did I say that?
where did i say you said ...
> But sometimes getting used to what you have (warts
> and all) is better than fore ever looking for the end of the rainbow.
maybe, but i claim that this does not hold with respect to C++.
i predict that a well-designed *and well marketed* language that aims
at the C++ niche and overcomes c++'s problems will catch on like wildfire,
because it will make program development significantly more efficient.
i claim that there is not such language today but there should be.
martin
Francis Glassborow
<dro...@charmedquark.com> writes
>Its something I'd love to do, but my immediate goals are to make some bucks
>off of the C++ frameworks I've put 10 years into. If I do make enough bucks
>to step back and take some time on some non-immediate term goals, a language
>would definitely be high on my list. I think that, having spent this long
>developing general purpose OO frameworks, and now building applications on
>top of them, I've gained a pretty good vision of what a good general purpose
>next generation OO language would be (one that would reflect both good and
>bad lessons learned from C++ and other languages.)
>
>But, given that I have to get rich first before I can work on it, I wouldn't
>hold my breath if I were you.
I think you should note that most successful languages were invented by
someone who wanted to do something, and inventing a language only helped
them achieve that goal. Languages invented by those that just wanted to
invent a better language (whatever that may mean) have not normally
prospered.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
And do you remember Sun's press releases for almost four years? Sorry, I
am cynical, I will believe it when it happens (and happily participate
in the process) but I, among others, wasted considerable time taking
Sun's statements at face value and I see no reason to believe MS (they
do not have the best of track records re standards)
>
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Chris Newton
> Chris Newton <chris...@no.junk.please.btinternet.com> writes
> >The same goes for silly things like the new-style casts.
> >It's lovely that the academics think that static_cast<>,
> >dynamic_cast<>, etc. should look ugly because casting
> >is ugly. In the real world, most programmers I know turn
> >around and say "stuff that, it's hard to read, I'm going to
> >write (int)x".
>
> No responsible programmer would do that:)
While I appreciate the little :) there, I think that in seriousness,
that point is debatable. I don't want to start that argument here, since
I'm sure we've all heard it before. I imagine that most people on this
forum would agree on the correct answer anyway, at least in principle.
My point, however, was that in the real world, a lot of people
programming C++ don't understand it very well. Bizarre notations,
however academically correct, aren't helping to overcome this problem.
Actually they're probably making things worse, because they put those
people off learning more.
> Next you will be telling us that single (colour coded:) variable
> names are the way to go. (read Bjarne's paper on colour coded
> variables:) Published in Overload, April 1998.
Sorry, you lost me; that's a few months before I discovered Overload.
I'm curious now, though. Are Overload back issues published on-line
anywhere? The ACCU site only seems to have tables of contents, unless I
missed something.
Regards,
Chris
Balog Pal
"Francis Glassborow" <francis.g...@ntlworld.com> wrote
> >I don't think so. I didn't make a real stat, but all books I remember to
> >read stated C++ is a new language, not a C with extras. Can't fing my C++
> >Primer, but it is as old as C++ and I'm sure it writes that too.
>
> So why did they all start by teaching you C?
Well, I did fetch my Lipmann (it's a translation of a (C)1990 edition, i
guess the first) and "teach C first" is something definitely not applying
that book. It almost "doesn't even mention C".
Paul
Balog Pal
> They all _write_ that, yes.
>
> They pay lip service to the idea, but they only talk the talk, they
> don't walk the walk. For all their introductory blather about C++ being
> a Whole New Language, the vast majority of books on C++ still start out
> by teaching you C.
>
> The first two questions when evaluating a teach-yourself-C++ book should
> be:
>
> -- Does it teach std::vector _before_ C-style arrays?
> -- Does it teach std::string _before_ character arrays/pointers?
>
> If the answer to either question is "no", put the book back on the shelf
> (prefereably the wrong shelf, to reduce the chances of some other poor
> schmuck picking it up), and buy _Accelerated C++_ instead.
Well. As experienced programmer, amybe I should do that, but for a beginner
a book on that track in not necessarily that good.
C++ has the language part and the library part. I'd definitely want them
thought in that order. I also hed a big deal of problems with people who
just skipped those precious parts of book describing silly things like
literals, promotion, evaluation order in expressions, etc.
I don't think you can jump in and starting use premaid stuff before knowing
the basic language elements, and all of them at least on perfect read level.
And not even mentioning std:: is not even preferred by quite many
programmers who use almost all other features of C++. How many
standard-conforming compilers we have today? How many we had 1 year ago
(when a published-today book war likely written)?
If the reader launch, say a MSVC learning edition on his win98 will the
std:: using code samples compile, or they just produce all kind of cryptic
error messages, or just a simple '1001 internal compiler error, call
support'.
Hopingly 2 years from now I will fully agree with your opinion, but not
today.
Paul
Jonathan Thornburg
(who if I've unwrapped the multilevel quoting properly was probably
Chris Newton <chris...@no.junk.please.btinternet.com>) wrote:
[[about new-style casts]]
>Bizarre notations,
>however academically correct, aren't helping to overcome this problem.
>Actually they're probably making things worse, because they put those
>people off learning more.
<flame>
If one considers new-style casts "bizarre notations", then indeed one
might feel this way.
If, on the other hand, one considers the old-style cast
(int) x
to be a slightly bizarre notation
[which is hard to spot by eye in source code, which is utterly
impractical to grep for in source code, which provides no error
checking whatsoever against a large class of programmer errors,
and which offers no explicit documentation of which of several
different sorts of semantics is desired]
which is supported only for backwards compatability, while the new-style
casts
static_cast<int>(x)
const_cast<int>(x)
reinterpret_cast<int>(x)
dynamic_cast<int>(x)
are a natural and easy-to-use part of C++
[and are easy to spot in source code by either eyes or
mechanical searching, which provide considerable error-checking,
and which explicitly document what sort of semantics are
involved]
then you might reach somewhat different conclusions about which should
be taught first to non-guru programmers.
>> Next you will be telling us that single (colour coded:) variable
>> names are the way to go. (read Bjarne's paper on colour coded
>> variables:) Published in Overload, April 1998.
>
>Sorry, you lost me; that's a few months before I discovered Overload.
I think this is a garbled reference to the classic
Bjarne Stroustrup
"Generalizing Overloading for C++2000"
Overload, Issue 25. April 1, 1998.
http://www.research.att.com/~bs/whitespace98.pdf
Excellent reading!
--
-- Jonathan Thornburg <jth...@thp.univie.ac.at>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Only 7 countries have the death penalty for children. Which are they?
A: Congo, Iran, Nigeria, Pakistan[*], Saudi Arabia, United States, Yemen
[*] Pakistan moved to end this in July 2000. -- Amnesty International,
http://www.web.amnesty.org/ai.nsf/index/AMR511392000
john wong
> I'm not scared because C++ cannot handle the new problems. I'm scared
> because I suspect 95% of current tecnologies will be outdated in fiew
> years. Technologies like CORBA, are already. And in a sense the TCP/IP
> itself is. They can do almost anything just on HTTP! Figures?
>
HTTP runs on TCP/IP... and TCP/IP is THE protocol suite of the Internet. i
don't see how TCP/IP will be outdated in a few years... am i missing some
industrial trends here?
Chris Newton
> > Bizarre notations, however academically correct, aren't
> > helping to overcome this problem. Actually they're
> > probably making things worse, because they put those
> > people off learning more.
>
> <flame>
> If one considers new-style casts "bizarre notations", then
> indeed one might feel this way.
I do. Writing
x = y
when you mean "x is equal to y" is a natural notation. It's been bred
into us ignorant westerners since before we started school. We all know
what happens when you use == in your language instead, and have = mean
something slightly different...
Similarly, writing
f(2, 3)
when you want to work out the result of a function f acting on values 2
and 3 is arguably a natural notation. Writing
if (x < 7)
when you want to do something "if x is less than 7" is a natural
notation, although
if x < 7
might be better.
Any programmer, from whatever background, would have no problem with
remembering and understanding these things. Any programmer could read
code using these notations and guess, correctly, at what it meant, even
if they did not program the language.
That's important, because it's how things catch on; everyone who
programs a successful language started by learning it. A lot of that
learning comes from seeing other people's code. I'm sure it's not
coincidental that there are few real world examples of modern C++ used
well, and that there are also few real world examples of programmers
learning modern C++ well.
On the other hand, writing
x = const_cast<A&>(a)
when you mean "take the const A & a and take away its constancy" is not
a natural notation. The notation is completely non-suggestive of what it
does. Even if you are familiar with related concepts - the existence of
casting and/or C++ templates - then at first sight the code above might
suggest the exact opposite of what it actually means.
I don't think I need to provide an argument that writing
pos = remove_if (coll.begin(),coll.end(),
compose_f_gx_hx(logical_and<bool>(),
bind2nd(greater<int>(),4),
bind2nd(less<int>(),7)));
to mean "remove any entry x in coll such that x>4 and x<7, and then tell
me what's left" is unnatural. :-)
I'm not arguing against the technical correctness or merits of the
new-style casts, just the hideous way we have of expressing them. I hope
I'm still in the 10% of C++ programmers who appreciate them and use
them. The fact remains that I am in a small minority. When it comes to
choosing a programming language, the majority will vote with their
fingers.
> I think [Francis' reference to Bjarne's paper on colour coded
> variables] is a garbled reference to the classic
> Bjarne Stroustrup
> "Generalizing Overloading for C++2000"
> Overload, Issue 25. April 1, 1998.
> http://www.research.att.com/~bs/whitespace98.pdf
> Excellent reading!
Thanks - I'll dig out my Acrobat Reader.
Regards,
Chris
Sourav Laskar
people who don't want to undergo discipline. With all the
spoonfeeding they get, they don't stop to think the least
what consequences their superfast coding will produce
one year down the line. I have practical experience
where two groups, one in C++ and the other in JAVA
were trying to talk with a proprietary protocol.
The JAVA team as usual takes less time to build,
but ends up taking more time in tuning their software.
As for C++ not keeping up with technology, what I
understand is that it was designed with the foremost
concern to enable programmers; not to pile up all kinds
of libraries -- just the bare minimum essential ones to
enable production of higher order portable libraries --
whatever you say, network API, SQL API .........
The standardization committee did not take a decade
just to sleep most of the time.
Where does C++ go from here. Well as long as there are
people and companies who value discipline, C++ will live.
But there aren't many, of course and that is why disciplined
C++ people command far higher salaries, and will continue
to do so.
-Sourav
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
[...]
> On the other hand, writing
> x = const_cast<A&>(a)
> when you mean "take the const A & a and take away its constancy" is
> not a natural notation.
So what is the "natural notation"?
I think part of the argument in favor of the new style notation is
that it isn't natural, because casting isn't natural. At least,
that's why I use them -- because I have to think about them, and they
won't slip in accidentally because they just happen to be natural.
Of course, this means that I do still use the old style casts in the
rare occasions when a type conversion IS natural (almost always, the
equivalent of a static_cast which does a real conversion, e.g.:
(double)i, to force floating point arithmetic in an expression).
> The notation is completely non-suggestive of what it does. Even if
> you are familiar with related concepts - the existence of casting
> and/or C++ templates - then at first sight the code above might
> suggest the exact opposite of what it actually means.
> I don't think I need to provide an argument that writing
> pos = remove_if (coll.begin(),coll.end(),
> compose_f_gx_hx(logical_and<bool>(),
> bind2nd(greater<int>(),4),
> bind2nd(less<int>(),7)));
> to mean "remove any entry x in coll such that x>4 and x<7, and then tell
> me what's left" is unnatural. :-)
But that's different, because at least for the expression part (x>4
and x<7), there is a natural expression. In fact, it's very
different, because elsewhere in C++, it would be expressed by
something fairly similar to this natural expression.
I also think that if generic programming is to really catch on, this
problem will have to be addressed. I can't imagine anyone writing
something like the above, in preference to a loop. Whereas :
pos = remove_if( coll.begin() , coll.end() ,
lambda_f( int x ) { return x > 4 && y < 7 ; } ) ;
or even
pos = remove_if( coll.begin() , coll.end() ,
lambda {
bool operator()( int x ) {
return x > 4 && y < 7 ;
}
} ) ;
seem plausible. (My experience with anonymous inner classes in Java
makes me somewhat more wary than I would have been in the past.
Still, the fact that something can be abused has never been an
argument for not incorporating it into the language, provided it also
has legitimate uses.)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
jsvendsen
>"Chris Newton" <chris...@no.junk.please.btinternet.com> wrote
>> Notice that it's taken until this past year for the first introductory
>> book to be published that actually treats C++ as more than enhanced C
>> (Accelerated C++).
>read stated C++ is a new language, not a C with extras. Can't fing my C++
>Primer, but it is as old as C++ and I'm sure it writes that too.
a number of books STATE that C++ is a new language, if they TREAT it as one
is a different matter. the introductory chapters of most C++ books teach
C with iostreams, and maybe a few simple classes.
note that i'm not convinced that this is such a horrible thing as many
other posters in this group chooses to express. while i find it important to
emphasize the benefits of using C++ features rather than their C
predecessors, i think that lack of C knowlendge at some point will leave
most C++ programmers quite stuck.
jon svendsen
Christopher Barber
"Chris Newton" <chris...@no.junk.please.btinternet.com> wrote in message
news:937pes$aep$1...@plutonium.btinternet.com...
> ZHN <z...@aol.com> wrote...
> 2. The C++ language has some silly fundamental flaws.
> ...
> For example, we get wonderful code examples, such as the following
> (which I've borrowed from Nicolai Josuttis's Compse library on Boost):
> pos = remove_if (coll.begin(),coll.end(),
> compose_f_gx_hx(logical_and<bool>(),
> bind2nd(greater<int>(),4),
> bind2nd(less<int>(),7)));
>
> in a real program. It's a necessary hack because C++ is fundamentally
> broken in this area. Functional languages have had the equivalent of the
> following for years (syntax invented to make the point):
> pos = remove_if(coll.begin(), coll.end(), (x)->(x > 4 && x < 7));
>
> Adding such a simple lambda-function to the power of the STL algorithms
> would have been a huge step forward. In fact, adding something along
> those lines would be almost trivial; it just requires an "anonymous
> function" concept, and the syntax to write one. It's hardly a challenge
> for professional compiler writers! And yet, who has done this in their
> new language? No-one.
We have included support for lambda functions (aka anonymous functions or
closures) in the Curl programming language and there are several other
relatively
new languages that also do so (such as Dylan). I agree that this is an
important
feature.
> These things could be the saving grace of C++. On technical merits, I
> don't feel there is yet any language that makes great advances over C++.
> (When there is, I will move on to program in it.) Obviously the new
> languages have good points. Java is much better suited to internet
> development, for example. But these are limited areas, small in relation
> to the overall field of C++ development. Until something radical comes
> along and fixes the fundamental weaknesses of C++, it will continue to
> have genuine merit.
Yes, I agree. Most new languages are designed to address an specific
application domain in some way that improves over other languages, but
even if it is successful in that, there may be many application domains
where
existing languages are fine or even superior. However, unless C++ evolves
fast enough, some other language will eventually come along that is superior
in some comercially important domain (such as internet development, B2B,
etc.) while at the same time its equal in other domains. I think that this
would
in the long run lead to the demise of the language. Considering the glacial
pace
of changes to most language standards, I think this is a genuine risk for
C++.
- Christopher
Ross Smith
We don't need language extensions for lambda expressions; you can do
this sort of thing with C++ now. See http://lambda.cs.utu.fi/ for an
implementation by Jaakko Järvi.
The library lets you write expressions like:
> // find the first element between 10 and 20
> iter = find_if(a.begin(),a.end(), free1 > 10 && free1 < 20 );
>
> // count the elements <= 6
> int i = count_if(a.begin(),a.end(), free1 <= 6 );
>
> // compute x² + x³ for each element x in a
> transform(a.begin(), a.end(), d.begin(), bind(pow, free1, 2) + bind(pow,
free1, 3) );
>
> // change all elements > 5 to 5
> for_each(a.begin(),a.end(), if_then(free1 > 5, free1 = 5) );
("free1" etc are the free variables in a lambda expression, equivalent
to x and y in James's examples.)
--
Ross Smith <ros...@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"Normally he was insane, but he had lucid moments
when he was merely stupid." -- Heinrich Heine
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Paul
> the ISO language) and there is even supposed to be a C++ version for .NET
> (called "Managed C++", if the magazine I have before me is to be believed)
> - so even MS don't see C# replacing C++.
If Visual C++ went away what would Windows be developed with in future ? I
doubt they're in a huge rush to port it all to C#
Francis Glassborow
<jsve...@bergen.frisurf.no> writes
>note that i'm not convinced that this is such a horrible thing as many
>other posters in this group chooses to express. while i find it important to
>emphasize the benefits of using C++ features rather than their C
>predecessors, i think that lack of C knowlendge at some point will leave
>most C++ programmers quite stuck.
Yes, but it is a matter of when such things as C-style arrays should be
taught, not if they should be taught at all.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Thant Tessman
Chris Newton wrote:
[...]
> - a lambda function to combine with the STL;
> - a standard threading library;
> - a standard garbage collecting mechanism
Am I the only one that thinks it's insane to try to add lambda,
threading, and GC to C++ instead of just switching to one of several
languages that do this stuff already and do it better than C++ ever
could? Not that I think it's going to happen any time soon, but why
would the supplanting of C++ by something better in itself be a bad
thing? (No, I'm not talking about Java or C#.)
[...]
-thant
news.w-link.net
I've sometimes wished for a lambda capability in C++ instead of trying to
muck around with named functors. Lambda would have been nice, but it wasn't
worth the switch to another language for. How many Scheme compilers can
call C++ libraries? Not to mention I'd have to re-learn the language, too.
Etc etc.
-J
"Thant Tessman" <th...@acm.org> wrote in message
news:3A5DF545...@acm.org...
Chris Newton
> Chris Newton wrote:
> [...]
> > On the other hand, writing
> > x = const_cast<A&>(a)
> > when you mean "take the const A & a and take away
> > its constancy" is not a natural notation.
>
> So what is the "natural notation"?
Something like make_modifiable(a), make_nonconst(a) or remove_const(a),
perhaps? Just about anything is better than const_cast<A&>(a).
> I think part of the argument in favor of the new style
> notation is that it isn't natural, because casting isn't
> natural.
Neither is the result of adding two chars being an int, but it still
generates a warning in my compiler when I do it. Since my coding
standard stipulates no warnings, I'm going to add the cast to make it
clear that I haven't made a mistake. Let's not even mention what happens
when I ask C++ what 1/2 is... :-)
Like I said, it's lovely that the academics think that casting notation
should be ugly because casting is ugly. The fact remains that ugly and
counter-intuitive notations, as exemplified throughout this thread, put
real world people off C++. The original question was about how to stop
that happening, and part of the answer is for the academics not to try
and impose their will on others' programming style.
[...]
> > I don't think I need to provide an argument that writing
> > pos = remove_if (coll.begin(),coll.end(),
> > compose_f_gx_hx(logical_and<bool>(),
> > bind2nd(greater<int>(),4),
> > bind2nd(less<int>(),7)));
> > to mean "remove any entry x in coll such that x>4 and x<7,
> > and then tell me what's left" is unnatural. :-)
>
> But that's different, because at least for the expression part
> (x>4 and x<7), there is a natural expression. In fact, it's
> very different, because elsewhere in C++, it would be
> expressed by something fairly similar to this natural
> expression.
But in this context, it can't be, at least not without the additional
baggage of defining its own function away from where it's actually used.
It's the same root problem; there's too much artificial baggage for a
simple thing.
> I also think that if generic programming is to really catch on,
> this problem will have to be addressed. I can't imagine
> anyone writing something like the above, in preference to
> a loop. Whereas :
>
> pos = remove_if( coll.begin() , coll.end() ,
> lambda_f( int x ) { return x > 4 && y < 7 ; } ) ;
>
>
> or even
>
> pos = remove_if( coll.begin() , coll.end() ,
> lambda {
> bool operator()( int x ) {
> return x > 4 && y < 7 ;
> }
> } ) ;
>
> seem plausible.
That's tending to what I had in mind, yes. To give another example, it's
currently the case that
transform(in.begin(), in.end(), out.begin(), toupper);
contains a nasty, well-hidden error. I'd be impressed if anyone who
hadn't read the thread on this group regarding that example could spot
it, though. When the language makes the above correct, or makes it a
syntax error and insists on something like your
transform(in.begin(), in.end(), out.begin(),
lambda(char x){return toupper(x);});
instead, get back to me. :-)
Now, to Ross Smith, whose post I can see in Deja but not in my
newsreader:
I agree that very clever things can be done in this area as things
stand, by the advanced use of templates. I don't think that entirely
solves the problem, though. There are still a few awkward limitations on
what you can do, and it requires masses of clever template tricks to do
the rest. Sadly, templates themselves are sorely in need of
simplification. I support this claim by the facts that (a) about 3
people reading this might know and understand the rules about templates,
type deduction and so on in their entirety, and (b) almost no currently
available compiler gets them 100% right. For that matter, I don't know
of any that do, although I'm sure the better ones are close by now.
That means that, on many compilers, you can't currently use those
lambda-esque template libraries. On those where you can, you probably
take a massive hit to your compilation time. I'm very grateful to those
writing these libraries - they're a big step forward - but it would be
much easier on many counts just to introduce a simple lambda function
concept into the language.
Regards,
Chris
Tony
"jsvendsen" <jsve...@bergen.frisurf.no> wrote in message
news:qo376.2278$k25....@news1.oke.nextra.no...
> Balog Pal wrote:
> >"Chris Newton" <chris...@no.junk.please.btinternet.com> wrote
> >> Notice that it's taken until this past year for the first introductory
> >> book to be published that actually treats C++ as more than enhanced C
> >> (Accelerated C++).
> >I don't think so. I didn't make a real stat, but all books I remember to
> >read stated C++ is a new language, not a C with extras. Can't fing my C++
> >Primer, but it is as old as C++ and I'm sure it writes that too.
>
> a number of books STATE that C++ is a new language, if they TREAT it as
one
> is a different matter. the introductory chapters of most C++ books teach
> C with iostreams, and maybe a few simple classes.
It's not really a new language though. A concession was made to the C folks
who
extended the C standard to mean "binary compatible". C++ is actually the
major
revision to C that couldn't be had without making a whole bunch of people
who
built a process around and undocumented, never intended "feature" in the C
language.
Hence, twas easier just to call it quits with C and make it C++ instead.
The problem with perspectives on C++ seem to be the push to embrace all
aspects of it
and not realizing that C paradigms are equally as acceptable to use (for
instance, making
everything an object just because you can is probably a bad thing to do).
Just because
C++ has templates, doesn't mean you have to use them.
Tony
Davlet Panech
Assaf Lavie <AssafLavie_D...@hotmail.com> wrote:
> Why would you want to 'prevent' C++ from making way to newer
languages.
> Don't you think it's about time that people stopped focusing all their
> efforts on learning complex syntaxes, complex resource management
semantics
> and keywords up the ying-yang?
There are some good reasons for all that complexity; IMHO C++ has a good
chance to outlive most of those trendy languages like Java because it
has quite a few features that they don't have, including those that you
seem to dismiss as inferior (lack of "true" OO, type safety, reflection,
etc.). I mean lack of true OO is not necessarily a bad thing. And what
do you mean by "true" OO exactly? The ability to write
non-object-oriented code? I'd say it's agood thing... (think of
something like text processing)
D.P.
> Isn't it about time people start using languages that have Reflection,
true
> OO, type safety, AOP (I can go on)?
>
> C++ is great, but it can most certainly be improved. What better way
of
> perpetuating C++ is there than allowing it to exist forever in other
> 'derived' languages?
>
> Assaf.
>
> "ZHN" <z...@aol.com> wrote in message
> news:20010104121404...@ng-fk1.aol.com...
> > Well there you have it. I am a little concerned with events in the
market
> > place at this time. Certainly java, and C# will have a devastating
impact on
> > c++ int the near future. In fact I have been looking at microsoft
NET
> > technology only to find that c++ is really being phased out to a
great
> extent.
> > If this trend continues we may find ourselves having to give up a
great deal
> > of
> > what we've learned for some proprietary language or other. If
nothing else
> > this is a very serious question simply becuase it implies the
possibility of
> > being undervalued as a programmer. In fact it's sad to see a newbie
java
> > programmer being worth up to twenty percent more than an overly
experienced
> > C++
> > programmer is worth in some markets. Here we are with what is the
most
> > flexible, most capable (and most taxing) language around and yet
worth half
> > of
> > what others may be worth with half the brain fatigue that we have to
> suffer..
> > Why?
> > The question here is what is the solution?
What does
> > the
> > C++ community need to do(both from a technological viewpoint as well
as from
> a
> > political perspective) to stop this insidious devaluation of the C++
> > programmer?
>
> [ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
> [ about comp.lang.c++.moderated. First time posters: do this! ]
>
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
LR
Davlet Panech wrote:
[snip]
> There are some good reasons for all that complexity; IMHO C++ has a good
> chance to outlive most of those trendy languages like Java because it
> has quite a few features that they don't have, including those that you
> seem to dismiss as inferior (lack of "true" OO, type safety, reflection,
> etc.).
Although, I guess that lanuguages sometimes evolve/mutate over the years
and get new features.
> I mean lack of true OO is not necessarily a bad thing. And what
> do you mean by "true" OO exactly? The ability to write
> non-object-oriented code? I'd say it's agood thing... (think of
> something like text processing)
[snip]
Why isn't text processing something that should be done with OO methods?
LR.
Davlet Panech
>
> Why isn't text processing something that should be done with OO
methods?
It just seems very unnatural to think of a pattern search in terms of
objects, hierarchies and message passing, I would say a single clean
algorithm would be much more straightforward. But I guess it's a matter
of opinion...
D.P.
>
> LR.
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Gabriel Zachmann
>
>
> Chris Newton wrote:
>
> [...]
>
> > - a lambda function to combine with the STL;
> > - a standard threading library;
> > - a standard garbage collecting mechanism
>
> Am I the only one that thinks it's insane to try to add lambda,
> threading, and GC to C++ instead of just switching to one of several
> languages that do this stuff already and do it better than C++ ever
> could? Not that I think it's going to happen any time soon, but why
Well, it seems to me that if a language wants to get any significant
wide-spread use, then it just has to provide a way to allow software vendors
to integrate legacy code as seamless as possible.
After all, a company's code base is one of it's major assets.
So, I think, the right way would be to improve C++ into some "C**",
such that C** is a (almost) superset of C++, yet is better designed and has
a few carefully chosen additional features (like lamda functions).
Ok, I admit
"superset of C++ and better designed"
sounds like a contradiction ;-)
Just my tupence,
Gab.
--
/---------------------------------------------------------------------\
| Paradigm is a word too often used by those |
| who would like to have a new idea |
| but cannot think of one. |
| (Mervyn King, Deputy Governor, Bank of England) |
| |
| za...@igd.fhg.de g...@gab.cx Gabriel....@gmx.net |
| www.igd.fhg.de/~zach/ www.gab.cx __@/' |
\---------------------------------------------------------------------/
Brian McNamara!
>Chris Newton wrote:
>> I don't think I need to provide an argument that writing
>> pos = remove_if (coll.begin(),coll.end(),
>> compose_f_gx_hx(logical_and<bool>(),
>> bind2nd(greater<int>(),4),
>> bind2nd(less<int>(),7)));
>> to mean "remove any entry x in coll such that x>4 and x<7, and then tell
>> me what's left" is unnatural. :-)
>
>But that's different, because at least for the expression part (x>4
>and x<7), there is a natural expression. In fact, it's very
>different, because elsewhere in C++, it would be expressed by
>something fairly similar to this natural expression.
>
>I also think that if generic programming is to really catch on, this
>problem will have to be addressed. I can't imagine anyone writing
>something like the above, in preference to a loop. Whereas :
>
> pos = remove_if( coll.begin() , coll.end() ,
> lambda_f( int x ) { return x > 4 && y < 7 ; } ) ;
Indeed. There have already been replies about the various "lambda
libraries" which use macros and/or expression templates to express
things like this.
FC++ takes the STL-style approach, but the (parametric) polymorphism in
the library makes it easier to say. The example predicate above
>> compose_f_gx_hx(logical_and<bool>(),
>> bind2nd(greater<int>(),4),
>> bind2nd(less<int>(),7)));
can be expressed as
compose_f_gx_hx( logical_and, greater(_,4), less(_,7) )
in FC++ (presuming the appropriate using-declarations). FC++ function
objects like "less" are polymorphic (templated) and will deduce their
types based on arguments/context, and the functoids also support
currying so you needn't say bind1st() and bind2nd() everywhere (which
makes the code ugly).
It doesn't look spectacular in the example above, but in some cases
it's very nice; for example, compare
plus(4) // FC++
bind1st(plus<int>(),4) // STL
lambda(int x){ return x+4; } // imagined lambda syntax
(The currying stuff in FC++ is not yet available at
http://www.cc.gatech.edu/~yannis/fc++/
but it will be part of the upcoming 1.2 release of the library.)
--
Brian M. McNamara lor...@acm.org : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )
Jon Kalb
>Francis> So why did they all start by teaching you C?
>
>My theory is that there is strong inner pressure to teach a subject
>the way one learned it. Most people in a position to teach C++
>learned first. Therefore, they teach C first.
>
>I, too learned C first--and it took me more than a decade to overcome
>the pressure to teach C as the first part of teaching C++.
I think a similar inner pressure causes C++ teachers (and writers) to
teach the "Modern" features of C++ (namespaces, STL, std::string,
exceptions, templates) after teaching "Classic" C++.
When I look at a book on C++ for the first time, one of the first
things I do is look at where std::string and std::vector are
introduced. The good writers (Koenig, Lippman, Stroustrup, etc.)
introduce these classes early and use them extensively in their
examples. Poorer writers (we know who they are) cover these classes
(and the other "Modern" topics) only after covering the material that
has been part of C++ since the beginning. This is a disservice to the
student/reader.
I know from personal experience that the pressure exits. I think it
is understandable. I just don't think it is acceptable.
--
jonk
Sent via Deja.com http://www.deja.com/
Before you buy.
Thant Tessman
> Am I the only one that thinks it's insane to try to add
> lambda, threading, and GC to C++ instead of just switching
> to one of several languages that do this stuff already and
> do it better than C++ ever could?
"news.w-link.net" wrote:
> Legacy Code :)
>
> I've sometimes wished for a lambda capability in C++ instead
> of trying to muck around with named functors. Lambda would
> have been nice, but it wasn't worth the switch to another
> language for. How many Scheme compilers can call C++ libraries?
> Not to mention I'd have to re-learn the language, too.
> Etc etc.
I doubt the need to call C++ libraries is high on most people's list of
excuses for not abandoning C++. C libraries are a different story, but
the ability to call C functions is, out of necessity, common even among
languages with very different calling conventions.
C++ is a monstrously complicated language. The thought of trying to add
lambda or threading to the language is almost vomit-inducing. The claim
that it would be just too much work to learn an alternative language
(especially something as simple as Scheme) is hard to take seriously.
As for whether people will use C++ in the future, I don't even
understand why people use it now. I use C++ because I need exceptionally
efficient access to one particular C library (OpenGL) and C++ is
admittedly better than C. But my situation can't be typical, and were it
different I would abandon C++ with no regrets whatsoever.
jsvendsen
>The problem with perspectives on C++ seem to be the push to embrace all
>aspects of it
>and not realizing that C paradigms are equally as acceptable to use (for
>instance, making
>everything an object just because you can is probably a bad thing to do).
>Just because
>C++ has templates, doesn't mean you have to use them.
i completely agree.
printf, arrays and C-casts is perfectly valid C++
a number of people don't seem to realize this.
Mark Wilden
>
> i completely agree.
> printf, arrays and C-casts is perfectly valid C++
>
> a number of people don't seem to realize this.
I very much doubt if there are many people in this (sometimes overly)
standard-oriented newsgroup who don't realize that those things are
perfectly valid C++.
Where you'll find disagreement is whether they are good C++. But there's
nothing wrong with using the parts of C++ you like and not using the
parts you don't.
Dennis Yelle
[...]
> it's very nice; for example, compare
>
> plus(4) // FC++
> bind1st(plus<int>(),4) // STL
> lambda(int x){ return x+4; } // imagined lambda syntax
Shorter is not necessarily better.
I have never used a lambda language,
but given the examples above, I think I know what
lambda( int x){ return x*x+2*x+7; }
would do. I don't have any guess how to do that in FC++.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
lrus...@my-deja.com
Davlet Panech <davlet...@hotmail.com> wrote:
>
>
> >
> > Why isn't text processing something that should be done with OO
> methods?
>
> It just seems very unnatural to think of a pattern search in terms of
> objects, hierarchies and message passing, I would say a single clean
> algorithm would be much more straightforward. But I guess it's a
matter
> of opinion...
Yes, of course it's a matter of opinion. I guess that part of mine is
formed by reading Software Tools and Software Tools in Pascal. The
section on Text Patterns contains code that looks like it might benefit
from a collection of classes in a hierarchy.
Part of the code looks something like this, although, I've rewritten it,
and this is psuedo code, not c++, c, pascal, fortran, etc.
case (pat) {
BEGINING_OF_LINE:
if(position == 0) advance = 0;
break;
ANY_CHARACTER: // match any character
if(current_character != NEWLINE) advance = 1;
break;
CLASS_CHARACTER: // match a character in a class eg [0-9]
if(current_character is a member of the class) advance = 1;
break;
.
.
.
}
I guess that when I see case statements like this, I wonder if the code
would benefit from the use of objects.
But as you said, its a matter of opinion.
LR.
Usually lr...@superlink.net
wr...@my-deja.com
In article <93fn2h$lbv$1...@uranium.btinternet.com>,
"Chris Newton" <chris...@no.junk.please.btinternet.com> wrote:
> Jonathan Thornburg <jth...@galileo.thp.univie.ac.at> wrote...
> > Chris Newton <chris...@no.junk.please.btinternet.com>) wrote
> > Bjarne Stroustrup
> > "Generalizing Overloading for C++2000"
> > Overload, Issue 25. April 1, 1998.
> > http://www.research.att.com/~bs/whitespace98.pdf
In this paper, Bjarne talks about overloading whitespace operator to
make certain notation more convenient for scientists, etc. :
x y means x*y. Makes sense.
Now if I write
x * y
what would that be? Dereferencing y and multiplying by x from the left?
Or multiplying x and y? Or syntax error?
Wroot
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> FC++ takes the STL-style approach, but the (parametric) polymorphism in
> the library makes it easier to say. The example predicate above
> >> compose_f_gx_hx(logical_and<bool>(),
> >> bind2nd(greater<int>(),4),
> >> bind2nd(less<int>(),7)));
> can be expressed as
> compose_f_gx_hx( logical_and, greater(_,4), less(_,7) )
> in FC++ (presuming the appropriate using-declarations).
Can the composed function/object access local variables? This is an
essential part of the lambda proposal, although it wasn't mentioned in
the last article.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> > Why isn't text processing something that should be done with OO
> > methods?
> It just seems very unnatural to think of a pattern search in terms
> of objects, hierarchies and message passing, I would say a single
> clean algorithm would be much more straightforward. But I guess it's
> a matter of opinion...
Text processing isn't just pattern searching. A pattern searcher
might be a class. It might even be a polymorphic class -- if the
pattern is a simple string, it uses BM, a choice between a set of
strings, KMP, or a full regular expression if required.
FWIW, I have several "text processing" elements in my tool box:
- A class which divides a string into fields. It's polymorphic; the
actual type depends on the definition of a field separator. (If I
were doing it today, the class itself would use delegation, rather
than inheritance, for the customization. But the delegate would
still be polymorphic.)
- My regular expression parser uses polymorphic nodes in the
expression graph; once parsed, the semantic evaluation is based on
the visitor pattern, with a polymorphic visitor. (It might be
possible to do this easier; it is *very* old code.)
- My program for formatting comments is based on the formatter in
"Programming Tools in Pascal"; the original version (in C) was
almost a pure rewrite. The current version uses a polymorphic
agent class to pass information between the input side and the
output. While there is much of the code I might write differently
today, I'm pretty sure about this particular design decision.
On the other hand, my string class never had any polymorphism, and the
only polymorphism in SetOfChar is using a derived class to provide a
special set of constructors (which understand the character class
syntax) -- this could also easily (and perhaps better) be done with
free functions.
I've occasionally considered what it would mean to write something
like TeX in C++. IMHO, it would simplify the program a lot; there are
a lot of cases where Knuth switches (either case or a series of if's)
on a type field in the elements, and maintaining the contents of a box
as a chained list of polymorphic elements seems a possible solution.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sean Dynan
--Sean.
<snip>
> > > Bjarne Stroustrup
> > > "Generalizing Overloading for C++2000"
> > > Overload, Issue 25. April 1, 1998.
> > > http://www.research.att.com/~bs/whitespace98.pdf
>
> In this paper, Bjarne talks about overloading whitespace operator to
> make certain notation more convenient for scientists, etc. :
> x y means x*y. Makes sense.
<snip>
Bjarne Stroustrup
jsve...@bergen.frisurf.no (jsvendsen) writes
> Tony wrote:
> >The problem with perspectives on C++ seem to be the push to embrace all
> >aspects of it
> >and not realizing that C paradigms are equally as acceptable to use (for
> >instance, making
> >everything an object just because you can is probably a bad thing to do).
> >Just because
> >C++ has templates, doesn't mean you have to use them.
>
> i completely agree.
> printf, arrays and C-casts is perfectly valid C++
>
> a number of people don't seem to realize this.
I haven't met anyone who didn't realize that. People who recommend a more
modern approach to C++ may regret that C-style casts are perfectly valid C++,
but they know that they are.
However, it seems that many people don't appreciate that C-style casts and
arrays are among the most error-prone facilities in C and C++ and possibly
the main sources of persistent errors in C and C++ software. For example,
two years ago about 30% of all (reported) software-related security violations
were exploitations of array overflow. C++ provides less error-prone facilities
and supports less error-prone and easier-to-use and easier-to-learn
techniques.
Printf() is a milder case, but it is an unnecessary source of type errors,
and its cousin scanf() is a menace.
For a more detailed view of part of my reasoning, see "Learning Standard C++
as a New Language" (link from my "papers" page).
- Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs
David J. Littleboy
"Dennis Yelle" <denn...@jps.net> wrote in message
news:3A660251...@jps.net...
> "Brian McNamara!" wrote:
> [...]
> > It doesn't look spectacular in the example above, but in some cases
> > it's very nice; for example, compare
> >
> > plus(4) // FC++
> > bind1st(plus<int>(),4) // STL
> > lambda(int x){ return x+4; } // imagined lambda syntax
>
> Shorter is not necessarily better.
> I have never used a lambda language,
> but given the examples above, I think I know what
> lambda( int x){ return x*x+2*x+7; }
> would do. I don't have any guess how to do that in FC++.
Exactly. The beauty of lambda is that it tells you exactly what it's doing
in the language you are actually programming in. The (currently known)
alternatives just don't provide anything like that clarity of expression.
C++ would be that much a better language were it to provide either lambda or
something that provided equivalent clarity of expression.
David J. Littleboy
Tokyo, Japan
David J. Littleboy
"Thant Tessman" <th...@acm.org> wrote:
>
> C++ is a monstrously complicated language. The thought of trying to add
> lambda or threading to the language is almost vomit-inducing. The claim
> that it would be just too much work to learn an alternative language
> (especially something as simple as Scheme) is hard to take seriously.
Threading is in itself complex, and adding a complex functionality adds that
much complexity. However, a downwards funarg lambda would fit very nicely
into the existing structure. I'm not convinced that GC would fit well in
C++, but there seem to be quite a few who want it...
> As for whether people will use C++ in the future, I don't even
> understand why people use it now. I use C++ because I need exceptionally
> efficient access to one particular C library (OpenGL) and C++ is
> admittedly better than C. But my situation can't be typical, and were it
> different I would abandon C++ with no regrets whatsoever.
Since very few of the other languages out there make anywhere near as strong
a commitment to efficiency as C++, it looks to me that as long as your
requirements include efficiency, it's going to be hard to abandon C++. And I
also think that efficiency will always be a serious concern for a
significant percentage of applications. (That is, the argument that
computers are getting faster and we're going to have cycles to spare has
always been dead wrong and always will be.)
David J. Littleboy
Tokyo, Japan
David J. Littleboy
<wr...@my-deja.com> wrote:
>
> In this paper, Bjarne talks about overloading whitespace operator to
> make certain notation more convenient for scientists, etc. :
> x y means x*y. Makes sense.
>
> Now if I write
> x * y
> what would that be? Dereferencing y and multiplying by x from the left?
> Or multiplying x and y? Or syntax error?
A timing error. About 2 months and 2 weeks early<g>. Check your calendar.
David J. Littleboy
Tokyo, Japan
Brian McNamara!
>> FC++ takes the STL-style approach, but the (parametric) polymorphism in
>> the library makes it easier to say. The example predicate above
>> >> compose_f_gx_hx(logical_and<bool>(),
>> >> bind2nd(greater<int>(),4),
>> >> bind2nd(less<int>(),7)));
>> can be expressed as
>> compose_f_gx_hx( logical_and, greater(_,4), less(_,7) )
>> in FC++ (presuming the appropriate using-declarations).
>Can the composed function/object access local variables? This is an
>essential part of the lambda proposal, although it wasn't mentioned in
>the last article.
No. Closing on the local environment is something still outside the
reach of what templates can do. :)
(Though, I have thought about this a bit--how would lambda behave in a
language with "value" semantics, variables with scoped lifetimes, etc.?
It just isn't as pretty as in functional languages. As a result,
having to explicitly capture values from the environment in C++ doesn't
bother me that much... If I could come up with reasonable semantics for
lambda capture, though, I might try some of the expression-template
tricks that other libraries use...)
--
Brian M. McNamara lor...@acm.org : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<ma...@pagm.com> writes
>> i completely agree.
>> printf, arrays and C-casts is perfectly valid C++
>>
>> a number of people don't seem to realize this.
>
>I very much doubt if there are many people in this (sometimes overly)
>standard-oriented newsgroup who don't realize that those things are
>perfectly valid C++.
>
>Where you'll find disagreement is whether they are good C++. But there's
>nothing wrong with using the parts of C++ you like and not using the
>parts you don't.
This reminds me of a colleague who for almost a decade resisted using
iostream facilities because he was more comfortable with those in
stdio.h and thought them better. Last year he did an in depth analysis
of his error logs and discovered that problems with stdio functions were
causing over 30% of the runtime errors in his work, most of these would
not happen with iostream. He has just changed his company's coding
guidelines.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Thant Tessman
"David J. Littleboy" wrote:
> [...] Since very few of the other languages out there make
> anywhere near as strong a commitment to efficiency as C++,
> it looks to me that as long as your requirements include
> efficiency, it's going to be hard to abandon C++. [...]
C++'s efficiency comes at the cost of development effort. The more
complex the application, the higher this cost. Talk of lambda and
threading and GC should be a pretty big hint that it's time to
re-evaluate whether this cost in development effort hasn't become
prohibitive.
-thant
James Kanze
> No. Closing on the local environment is something still outside the
> reach of what templates can do. :)
I didn't use the word "closure" intentionally:-). Depending on what
you mean by closure, my lambda does or does not fulfil the
requirements. I tend to consider it a closure, but a sort of C++
closure, which is different than a closure in some other languages
(because C++ is different than the other languages).
> (Though, I have thought about this a bit--how would lambda behave in a
> language with "value" semantics, variables with scoped lifetimes, etc.?
> It just isn't as pretty as in functional languages. As a result,
> having to explicitly capture values from the environment in C++ doesn't
> bother me that much... If I could come up with reasonable semantics for
> lambda capture, though, I might try some of the expression-template
> tricks that other libraries use...)
The difference in closure in C++, compared to closure in, say, Lisp,
is the same difference as for variables, expressions, etc. in
general. In C++, objects have a rigorously defined lifetime; it is up
to the programmer to ensure that use corresponds to lifetime, and not
the reverse. A C++ closure would be no different.
It's still very useful, in order to create functional objects to pass
to called functions.
To be totally useful, given the current emphisis on templates, the
language would also have to be extended to allow instantiation over
local classes. Also, when I originally considered the idea, I wasn't
familiar with STL, and its use of value semantics for functional
objects. To be useful with the STL, the lambda class would have to
support copy semantics; should a copy of the lambda still refer to the
local variables, or a copy of them?
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
John Crickett
<snip>
> Talk of lambda and
> threading and GC should be a pretty big hint that it's time to
> re-evaluate whether this cost in development effort hasn't become
> prohibitive.
Arguably it has been re-evaluated, and those that value development
time over runtime efficiency, have moved to Java where some of what you
suggest is available...
Personally I don't find that I'm particularly more productive in Java,
much as I like Java it is very restrictive. I'm prepared to make the
effort to learn a language, so I prefer the power and flexability that
C++ affords me. I've never used multiple inheritance but like tht fact
that I have the choice! Yes I almost exclusively write OO code, but I
have the choice of writing procedural if I want to etc.
Personally I'd rather not see any of your suggestions added to the
language, I like the choice I have at the moment we WRT GC and
Threading, I can't comment on lambda/functional programming.
Regards, J
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Balog Pal
> C++'s efficiency comes at the cost of development effort. The more
> complex the application, the higher this cost. Talk of lambda and
> threading and GC should be a pretty big hint that it's time to
> re-evaluate whether this cost in development effort hasn't become
> prohibitive.
A can't really catch the point. GC creates a big buzz, but do we really need
it? The "casual" C++ programmer can use string, and stl containers maybe
plus auto_ptr) without ever running into a memory issue. And a nt-so-casual
has all the resource guard classes for years. Anyone around remember the
last memory leak issue?
Threading is really not for everyone, it requires some special thinking, to
handle the shared stuff right, but otherwise it largely _simplifies_ the
program in several lifelike situations, especially if you write a server.
Lambda is probably a quite particular aspect. What I miss in C++ badly is
local functions. Probably it wouldn't be such a big deal to add them to the
language in the simplest form (ie function is not different from any other
just scoped in a block) or even in a form like in pascal (having access to
the locals visible from surrounding scope). But chances something like that
ever added is 0.0001% or less.
Paul
Thant Tessman
John Crickett wrote:
> Thant Tessman <th...@acm.org> wrote:
> <snip>
> > Talk of lambda and
> > threading and GC should be a pretty big hint that it's time to
> > re-evaluate whether this cost in development effort hasn't become
> > prohibitive.
>
> Arguably it has been re-evaluated, and those that value development
> time over runtime efficiency, have moved to Java where some of what you
> suggest is available...
[...]
Java is not exactly on the top of my list of alternatives to C++. It has
major flaws--some of which, ironically, are the product of an attempt
not to scare off C and C++ programmers. Besides, Java wasn't really
intended to replace C++.
For an example of a decent language specifically designed as a
replacement for C++ for application and systems programming, check out
Dylan. There are others...
-thant
Thant Tessman
Balog Pal wrote:
> [...] GC creates a big buzz, but do we really need it?
The STL and smart pointers and other techniques have made memory bugs
less common, but the lack of GC still has a huge influence on how one
programs in C++, not least because of the influence on the design of C++
itself. This influence might not be obvious to someone who hasn't done
significant programming in a language without GC, but it's very real.
Besides, the string class, for example, is a big help. But how many
programmers could have written the string class themselves? Whose to say
that the issues faced by the authors of the string class aren't going to
be faced by programmers trying to build things for which no
off-the-shelf solution exists? How many of them are going to be the kind
of experts that have implemented the STL?
> Threading is really not for everyone [...]
Threading is almost easy in a functional programming language.
> [...] What I miss in C++ badly is local functions. [...]
...and the ability for those functions to be passed out of their local
scope even if they refer to variables within that scope. This is what
closures are about and they make programming a lot more pleasant, and
the language that supports them a lot more powerful.
Now days there are folks doing things with C++ templates that would be
considered downright amazing if it didn't look so clumsy compared to
languages that support lambda and closures outright.
-thant
David J. Littleboy
"Thant Tessman" <th...@acm.org> wrote:
> Balog Pal wrote:
> > [...] GC creates a big buzz, but do we really need it?
>
> The STL and smart pointers and other techniques have made memory bugs
> less common, but the lack of GC still has a huge influence on how one
> programs in C++, not least because of the influence on the design of C++
> itself. This influence might not be obvious to someone who hasn't done
> significant programming in a language without GC, but it's very real.
You mean "programming in a language _with_ GC" <g>. Yes. It's very
different. One gets very careless about memory resources very quickly. C++
forces you to think about your memory and take care of it. But there are
advantages, mainly efficiency. It's a tradeoff. If you don't like the end of
the tradeoff C++ adopts, don't use C++.
> Besides, the string class, for example, is a big help. But how many
> programmers could have written the string class themselves? Whose to say
> that the issues faced by the authors of the string class aren't going to
> be faced by programmers trying to build things for which no
> off-the-shelf solution exists? How many of them are going to be the kind
> of experts that have implemented the STL?
The whole point of providing a standard library is to provide things that
are hard to do yourself. Writing a decent string class would be hard in any
language. In fact, an acceptably efficient decent string class would be
_impossible_ in most languages, and one would simply use the one coded in
assembler provided with the system.
> > Threading is really not for everyone [...]
> Threading is almost easy in a functional programming language.
I'm reminded of certain Prolog types who claimed to be able to implement
Unix in two lines of Prolog. The sorts of threading that are natural (and I
admit they are natural) in functional programming language tend to be rather
inefficient, since they are based on a stack model that requires heap
allocation and garbage collection of the stack.
> > [...] What I miss in C++ badly is local functions. [...]
>
> ...and the ability for those functions to be passed out of their local
> scope even if they refer to variables within that scope. This is what
> closures are about and they make programming a lot more pleasant, and
> the language that supports them a lot more powerful.
Upwards funargs are certainly lots of fun. But they require a far more
complex and expensive stack handling mechanism, and are seriously
inappropriate for C++. (Anyway, the semantics of local variables in C++
preclude upwards funargs, since destructors must be called on scope exit.
C++ isn't a functional language.) If you insist on that sort of thing, use
Scheme, T, Common Lisp, or whatever. General-purpose computer hardware
provides hardware support for (or at least easy efficient implementation of)
straightforward stack based semantics. C++ is designed to reflect the
efficiency of modern general-purpose hardware.
Downwards funargs, on the other had, would fit exceeding well in the C++
memory and stack model, and would be a significant addition.
The bottom line is that C++ isn't what you want. For those of us who like
the tradeoffs and design decisions that underlie C++, it is what we want.
David J. Littleboy
Tokyo, Japan
Jeff Petkau
news:b2s96.657$9t1.1...@nnrp.gol.com...
> "Dennis Yelle" <denn...@jps.net> wrote:
> > "Brian McNamara!" wrote:
> > [...]
> > > It doesn't look spectacular in the example above, but in some cases
> > > it's very nice; for example, compare
> > >
> > > plus(4) // FC++
> > > bind1st(plus<int>(),4) // STL
> > > lambda(int x){ return x+4; } // imagined lambda syntax
> >
> > Shorter is not necessarily better.
> > I have never used a lambda language,
> > but given the examples above, I think I know what
> > lambda( int x){ return x*x+2*x+7; }
> > would do. I don't have any guess how to do that in FC++.
> C++ would be that much a better language were it to provide either lambda
or
> something that provided equivalent clarity of expression.
I think it's come up already in this thread, but it's so nifty it's
worth repeating. Using the lambda library (http://lambda.cs.utu.fi)
this would be
ll_namespace::free1_type x;
x + 4;
x*x + 2*x + 7;
It also has a very nice 'bind' thingy:
bind(spackle, 3, free2, "hello", free1, free1);
meaning lambda(x,y) { spackle(3,y,"hello",x,x); }
Also 'tie' and 'tuple' templates, for when One Value Just Isn't Enough.
--Jeff
ps.
What's really missing to make these generally useful is of course
typeof() and automatic variable typing. Put that poor auto keyword
to use at last!
Francis Glassborow
writes
>Besides, the string class, for example, is a big help. But how many
>programmers could have written the string class themselves?
Lots, and not just for practice but because they do not want a template
instantiation of a class that contains everything but the kitchen sink.
The library version is an excellent standby, but expert programmers
often need something different.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Balog Pal
> Besides, the string class, for example, is a big help. But how many
> programmers could have written the string class themselves?
I think any one of those deserves title 'programmer'. And probably most
actually did write, maybe even several implementations, if they started the
work in an environment not having one ready.
The same applies to the basic containers, like list, array. Whoever can not
implement basic things like that should go bact to learn, and not attemt to
write any production code. Tha latter would only lead to disaster.
[In case you meand implementation of string in the form it got standardised,
I'm talking about "plain" implementations. ]
> Whose to say
> that the issues faced by the authors of the string class aren't going to
> be faced by programmers trying to build things for which no
> off-the-shelf solution exists? How many of them are going to be the kind
> of experts that have implemented the STL?
I think STL is quite another issue. All the non-templated implemetations of
iostreams, containers and string worked pretty well, without compications.
And you need not be an expert at all to implement one of those.
> > [...] What I miss in C++ badly is local functions. [...]
>
> ...and the ability for those functions to be passed out of their local
> scope even if they refer to variables within that scope. This is what
> closures are about and they make programming a lot more pleasant, and
> the language that supports them a lot more powerful.
>
> Now days there are folks doing things with C++ templates that would be
> considered downright amazing if it didn't look so clumsy compared to
> languages that support lambda and closures outright.
Yes, I saw a lpenty of stuff with templates that I'd call "genially neat" or
"crazy abuse" just depending on my mood for the day. But I believe many of
those just show missing functionality, and a kind that would be easy to add
straight. (Some most basic examples are lengthof, add/remove const). And I
must agree that while adding the algorithms is a step toward a geed
direction in principle, but on the use part it creates mostly non0intuitive
to non-readable code.
Paul
Francis Glassborow
writes
>The same applies to the basic containers, like list, array. Whoever can not
>implement basic things like that should go bact to learn, and not attemt to
>write any production code. Tha latter would only lead to disaster.
Yes, before a programmer is qualified they should write an
implementation of a linked list for themselves :)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> "Thant Tessman" <th...@acm.org> wrote
> > C++'s efficiency comes at the cost of development effort. The more
> > complex the application, the higher this cost. Talk of lambda and
> > threading and GC should be a pretty big hint that it's time to
> > re-evaluate whether this cost in development effort hasn't become
> > prohibitive.
> A can't really catch the point. GC creates a big buzz, but do we
> really need it? The "casual" C++ programmer can use string, and stl
> containers maybe plus auto_ptr) without ever running into a memory
> issue. And a nt-so-casual has all the resource guard classes for
> years. Anyone around remember the last memory leak issue?
The question isn't whether you have memory leaks or not; the question
is the cost of avoiding them. GC isn't a silver bullet, but used
correctly, it can reduce the cost.
> Threading is really not for everyone, it requires some special
> thinking, to handle the shared stuff right, but otherwise it largely
> _simplifies_ the program in several lifelike situations, especially
> if you write a server.
The problem with making threading standard is what model to
standardize. In practice, this is one of the rare cases where I think
Java made the correct decision. The standard threading is very, very
primitive. About all it's good for is to support the implementation
of whatever model you need on top of it. (A C++ programmer would feel
right at home with Java's threading model: lots of possibilities for
undefined behavior, a real concern about potential efficiency, and
access to a very low level, with a do it yourself approach for
anything more evolved. Just the opposite of most of Java.)
> Lambda is probably a quite particular aspect. What I miss in C++
> badly is local functions. Probably it wouldn't be such a big deal to
> add them to the language in the simplest form (ie function is not
> different from any other just scoped in a block) or even in a form
> like in pascal (having access to the locals visible from surrounding
> scope). But chances something like that ever added is 0.0001% or
> less.
There are technical problems involved with nested functions in C++; to
be useful, they need access to the local variables *and* one needs to
be able to pass their address. This requires more information than
the standard pointer to function is able to handle.
My idea of lambda classes is basically a means of implementing nested
functions. Of course, what you are really implementing is a nested
object which happens to contain a function, and gives that function
access to the surrounding context. This avoids the problem of
pointers to functions, since you have a pointer to an everyday object.
And I would argue that this is more idiomatic C++ anyway; in general,
instead of using pointers to functions, you should be using objects;
an object can do everything the function can, and can also maintain
state, which the function can't.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
John Crickett
Thant Tessman <th...@acm.org> wrote:
> Java is not exactly on the top of my list of alternatives to C++. It
has
> major flaws--some of which, ironically, are the product of an attempt
> not to scare off C and C++ programmers. Besides, Java wasn't really
> intended to replace C++.
Agreed Java has some major flaws however its regularly talked about
(normally by the less well informed) as being a replacement for C++,
providing the features you asked for. My comment was somewhat tongue in
check :-)
> For an example of a decent language specifically designed as a
> replacement for C++ for application and systems programming, check out
> Dylan. There are others...
I cannt say I've heard of Dylan, but its about time for me to learn a
new language so I'll look it up.
Regards, J
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Thant Tessman
"David J. Littleboy" wrote:
[...]
> The bottom line is that C++ isn't what you want. For those
> of us who like the tradeoffs and design decisions that
> underlie C++, it is what we want.
Were this the only reason people chose to use C++, I would have no
complaints. But C++ is *fashionable*. Techno-groupies think they're
plugged in just for knowing what it is. The problem is that resources
get dumped into C++ and its infrastructure that could be better spent
elsewhere. And this thread alone is ample proof that many of those with
an investment in this infrastructure (whether personal or financial)
have no reason to divert attention away from it, even when obviously
superior alternatives exist. They'd rather spend their time trying to
make their code exception-safe or thread-safe, or writing smart
pointers, or playing games with templates to simulate closures or deal
with call traits, etc., etc...
-thant
Balog Pal
news:3A6BF32B...@dresdner-bank.com...
> > Lambda is probably a quite particular aspect. What I miss in C++
> > badly is local functions. Probably it wouldn't be such a big deal to
> > add them to the language in the simplest form (ie function is not
> > different from any other just scoped in a block) or even in a form
> > like in pascal (having access to the locals visible from surrounding
> > scope). But chances something like that ever added is 0.0001% or
> > less.
>
> There are technical problems involved with nested functions in C++; to
> be useful, they need access to the local variables *and* one needs to
> be able to pass their address. This requires more information than
> the standard pointer to function is able to handle.
Hmm, point taken.
However, in a C++ version that suppors local functions in could be handled.
A standard pfn really is insufficient, but an extended pfn could be invented
for good. It would be a pointer with context, ie having two parts, an
old-stlye pfn, and a pointer to context [plus inf about the original pointer
type, if needed]. It then could be used for local functions (context links
to the stack frame, or something), and member functions as well (context
providing the hidden this parameter).
On dereferencing such a pointer the compiler could call regular, local and
object unctions without problem, and transparently to the user. We could
just forget specialisatoin on functor classes, and similar stuff. And any
callback-using machanism would be glad.
> My idea of lambda classes is basically a means of implementing nested
> functions. Of course, what you are really implementing is a nested
> object which happens to contain a function, and gives that function
> access to the surrounding context.
Yeah, but that is something cumbersome, and forces you to put the class def
outside the function (I recall a local class can't be used in template
deduction).
> This avoids the problem of
> pointers to functions, since you have a pointer to an everyday object.
An avoids some benefits too. Certainly this is something that at leatst
works, and works now, so that is the way we walk in need. While I keep
thinking about more elegant solutions.
> And I would argue that this is more idiomatic C++ anyway; in general,
> instead of using pointers to functions, you should be using objects;
I don't differ on the last. But I think it is pretty limiting, that I can
either pass a function, that must be static, without ability to pass an
instance, or on the other end, I can pass an instance, but then be tied to
use one specific function in it (say, op()). When in both cases I'd like to
pass both. And in a way that az ordinary human with mere IQ at mere 190
can track. :) Am I really weird-thinking?
> an object can do everything the function can, and can also maintain
> state, which the function can't.
And if we put state and functions together, we get to ... ;->
Paul
Sean Kelly
Thant Tessman <th...@acm.org> wrote:
>
> The STL and smart pointers and other techniques have made memory bugs
> less common, but the lack of GC still has a huge influence on how one
> programs in C++, not least because of the influence on the design of
C++
> itself.
Certainly, but it should be noted that a programmer can implement GC in
his program, should he consider it appropriate. Personally, I like
this idea far more than having it mandated by the language. GC in Java
is both a great convenience and a great stumbling block, coming from a
non-GC background. Sometimes I just want to explicitly delete
something, darnit :).
> This influence might not be obvious to someone who hasn't done
> significant programming in a language without GC, but it's very real.
One might also argue that the advent of high-level programming
languages has made programmers lazy and that it's easy to develop bad
habits when you haven't coded in assembler for a while.
> Besides, the string class, for example, is a big help. But how many
> programmers could have written the string class themselves?
Perhaps a small portion. But the real issue is "how many programmers
could write A string class themselves?" And I think that number is
considerable. Since the STL standard (and implementations) didn't
really settle down until a few years ago, most competent programmers
had already developed their own versions of the majority of those
classes. They were certainly neccessary, and it's much better to code
a really terrific implementation once and use it everywhere than wing
it for every project.
> Threading is almost easy in a functional programming language.
So is writing a program that compiles. Threading WELL is quite another
thing :).
Sean
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David J. Littleboy
"Thant Tessman" <th...@acm.org> wrote:
> "David J. Littleboy" wrote:
> > The bottom line is that C++ isn't what you want. For those
> > of us who like the tradeoffs and design decisions that
> > underlie C++, it is what we want.
>
> Were this the only reason people chose to use C++, I would have no
> complaints. But C++ is *fashionable*. Techno-groupies think they're
> plugged in just for knowing what it is. The problem is that resources
> get dumped into C++ and its infrastructure that could be better spent
> elsewhere.
If that really is a problem (which I, by the way, doubt: doesn't that
describes the Java situation far better than the C++ situation<g>), aren't
you in the wrong place? This is (presumably) a technical discussion about
C++, and your technical concerns go against the basic design decisions of
the language. Those aren't going to change, and shouldn't.
> And this thread alone is ample proof that many of those with
> an investment in this infrastructure (whether personal or financial)
> have no reason to divert attention away from it, even when obviously
> superior alternatives exist.
I think the idea that an "obviously superior alternatives exist[s]" is
simply wrong. Different approaches have different goals, and no one language
is superior. Every language is superior to every other language. APL, ADA,
Scheme. Each one will be far superior to C++ in certain situation. And vice
versa.
> They'd rather spend their time trying to
> make their code exception-safe or thread-safe, or writing smart
> pointers, or playing games with templates to simulate closures or deal
> with call traits, etc., etc...
Right. It's a technical discussion group. (Although I agree that adding
support for downward funargs to the language would be preferable to template
kludges<g>. But note that I preface this desire by pointing out that
downward funargs actually fit nicely into the _existent_ C++ scoping,
memory, object models. Hopefully this counts as a constructive comment.)
David J. Littleboy
Tokyo, Japan
David J. Littleboy
"Balog Pal" <pa...@lib.hu> wrote:
> "James Kanze" <James...@dresdner-bank.com> wrote:
> > My idea of lambda classes is basically a means of implementing nested
> > functions. Of course, what you are really implementing is a nested
> > object which happens to contain a function, and gives that function
> > access to the surrounding context.
>
> Yeah, but that is something cumbersome, and forces you to put the class
def
> outside the function
The whole point of a lambda keyword would be that it would be a syntactic
notation for a local class. lambda int (int x) { return x + y; } would
define the (anonymous) class and function as a call to its constructor when
executed.
> (I recall a local class can't be used in template deduction).
Uh, local classes in functions currently don't exist (I think).
> > This avoids the problem of
> > pointers to functions, since you have a pointer to an everyday object.
>
> An avoids some benefits too. Certainly this is something that at leatst
> works, and works now, so that is the way we walk in need. While I keep
> thinking about more elegant solutions.
No. It's a very elegant solution. Pointers to functions are too low-level
and C-like for my taste. Objects that provide an operator() are much more
C++-like.
> > And I would argue that this is more idiomatic C++ anyway; in general,
> > instead of using pointers to functions, you should be using objects;
Exactly.
David J. Littleboy
Tokyo, Japan
Jens Kilian
> However, in a C++ version that suppors local functions in could be handled.
> A standard pfn really is insufficient, but an extended pfn could be invented
> for good. It would be a pointer with context, ie having two parts, an
> old-stlye pfn, and a pointer to context [plus inf about the original pointer
> type, if needed].
A closure is a closure is a closure, and a closure by any other name would
still be a closure. If you have local functions, you may as well have lambda,
because that is all that lambda really is: an unnamed local function.
"Those who do not understand Lisp are doomed to reinvent it... poorly."
--
mailto:j...@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
James Kanze
> In article <3A68BF8D...@acm.org>,
> Thant Tessman <th...@acm.org> wrote:
> > The STL and smart pointers and other techniques have made memory
> > bugs less common, but the lack of GC still has a huge influence on
> > how one programs in C++, not least because of the influence on the
> > design of C++ itself.
> Certainly, but it should be noted that a programmer can implement GC
> in his program, should he consider it appropriate. Personally, I
> like this idea far more than having it mandated by the language. GC
> in Java is both a great convenience and a great stumbling block,
> coming from a non-GC background. Sometimes I just want to
> explicitly delete something, darnit :).
So do it. GC certainly doesn't stop you, even in Java. In Java, of
course, you would have to agree on a specific name for the destructor
function -- AWT uses dispose in one case. In GC for C++, I don't see
any reason why the delete operator would be removed. The only thing
would be that you don't need it for memory management reasons. (You
might still need so that the destructor is called in a timely
fashion.)
> > This influence might not be obvious to someone who hasn't done
> > significant programming in a language without GC, but it's very
> > real.
> One might also argue that the advent of high-level programming
> languages has made programmers lazy and that it's easy to develop
> bad habits when you haven't coded in assembler for a while.
I'd say that it is especially easy to develop bad habits IF you've
coded too much in assembler.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> Hmm, point taken.
What if we arrange it so that the actual pointer pointed to a
structure with the address of the function, and the context?
Of course, that would be nothing other than a lambda class with a
virtual fonction:-).
> > My idea of lambda classes is basically a means of implementing
> > nested functions. Of course, what you are really implementing is
> > a nested object which happens to contain a function, and gives
> > that function access to the surrounding context.
> Yeah, but that is something cumbersome, and forces you to put the
> class def outside the function (I recall a local class can't be used
> in template deduction).
Well, I conceived the idea long before anyone thought of instantiating
templates on functional objects. At the time, the standard solution
was to use an abstract base class for the interface, and pass a
concrete instance.
There are already strong reasons to allow templates to be instantiated
over local classes. I could imagine this as an extension. And it
would be necessary for lambda classes to be useful, since a lambda
class is *only* defined within a function; you can't instantiate it,
nor derive from it, outside of the function whose context it exposes.
> > This avoids the problem of pointers to functions, since you have a
> > pointer to an everyday object.
> An avoids some benefits too. Certainly this is something that at
> leatst works, and works now, so that is the way we walk in
> need. While I keep thinking about more elegant solutions.
I'm not sure what benefits it would avoid, done correctly. I agree
that to be useful, it must be possible to instantiate templates on
it. But since it represents a major addition to the language
anyway...
> > And I would argue that this is more idiomatic C++ anyway; in
> > general, instead of using pointers to functions, you should be
> > using objects;
> I don't differ on the last. But I think it is pretty limiting, that
> I can either pass a function, that must be static, without ability
> to pass an instance, or on the other end, I can pass an instance,
> but then be tied to use one specific function in it (say,
> op()). When in both cases I'd like to pass both. And in a way that
> az ordinary human with mere IQ at mere 190 can track. :) Am I really
> weird-thinking?
> > an object can do everything the function can, and can also
> > maintain state, which the function can't.
> And if we put state and functions together, we get to ... ;->
A class.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627