Do you really like C++?
Oriol de San Pedro
Hello,
This letter is a bit special, my purpose with this letter is to see what
people really think about the C++ language...
To start it up I have to say I think the C++ is really the best language,
in the sense that there isn't any other better, but still, I think there
are a lot of things about C++ that really don't make a lot of sense, at
least not to me...
The question would be: is it that C++ has some features that, too often,
doesn't make a lot of sense, or is it that I still havent grasped the whole
picture?..
I have spent a lot of time trying to understand what C++ was all about,
then after a lot of effort, and when I say a lot of effort I mean a lot of
effort, I started to see what it all was about, but still after working
with it more and more time I again started questioning seriously the
validity of C++ as a proper, solid language, that actually makes sense...
I took me a lot of time to get into C++, and now that I am inside it I
don't think: Wow! That's beautiful, I love this, ... I mainly think C++
is a complex language that has lots of nonsense features and
characteristics you easily can get lost into, the only practical solution
seems to stay near the basic well understood concepts and never, NEVER try
strange things cause most of them are just there to annoy the poor
programmer, features that are like monsters that can go and ate you... : )
I don't know if someone out there has really understood everything about
C++ or is close to achieving it, or if people say C++ is great just because
they don't want to recognize that they don't truly understand what C++ is
all about...
At least I am sure that most times people want to convince themselves about
the usability and convenience of the rich feature set of C++ just to hide
to themselves or to other people their frustration with it...
So well, that was my opinion, my english isn't very good, but I am sure you
understood it better than, let's say C++, .. or it is not?
I want to know your _HONEST_ opinion!!
At least I will see if this is a common feeling or is it that I am stupid,
be free to express yourself please, I have to know!
I am waiting for your opinion right here...
____Oriol de San Pedro, o...@tinet.fut.es
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
C++ Newsgroup Moderators
Oriol de San Pedro wrote:
>=20
> Hello,
>=20
> This letter is a bit special, my purpose with this letter is to see =
what
> people really think about the C++ language...
> To start it up I have to say I think the C++ is really the best =
language,
Bjarne Stroustrup often mentions that in general, the best C++ can hope
to be is second-best, in that there will always be a language (or a
place for one) that is more specialized for a particular problem.
> in the sense that there isn't any other better, but still, I think =
there
> are a lot of things about C++ that really don't make a lot of sense, at
> least not to me...
Some things don't make sense at first, but after finding out more about
it, it makes sense. Often something is a certain way for compatibility
reasons, or implementation issues. These reasons are important, though
they sometimes get in the way. This is the real world. Things aren't
perfect (oh well :-(
> The question would be: is it that C++ has some features that, too =
often,
> doesn't make a lot of sense, or is it that I still havent grasped the =
whole
> picture?..
Probably both :-)
> I have spent a lot of time trying to understand what C++ was all about,
> then after a lot of effort, and when I say a lot of effort I mean a lot=
of
> effort, I started to see what it all was about, but still after working
> with it more and more time I again started questioning seriously the
> validity of C++ as a proper, solid language, that actually makes =
sense...
> I took me a lot of time to get into C++, and now that I am inside it I
> don't think: Wow! That's beautiful, I love this, ...
Same here. But then you want more! You want built-in types to act just
like user-defined types (and vice-versa)! You want to get rid of all the
standard conversions (and the many integral types)! You want a
'writeonly' type to match the 'readonly' (const) type modifier! Hehe.
> I mainly think C++
> is a complex language that has lots of nonsense features and
> characteristics you easily can get lost into,
If you try to learn the language by reading the standard, then you will
very likely get lost. The significance of each feature will be lost.
> the only practical solution
> seems to stay near the basic well understood concepts and never, NEVER =
try
> strange things cause most of them are just there to annoy the poor
> programmer, features that are like monsters that can go and ate you... =
: )
That's what others suggest, and they have a point, to a certain extent.
Use the simplest features needed to implement a given design.
> I don't know if someone out there has really understood everything =
about
> C++ or is close to achieving it,
I'm sure many understand most of the language as it is defined, but I
believe there are many ideas and idioms that have yet to be discovered.
The interesting massive inlining templates and template metaprograms are
one example of such ideas.
> or if people say C++ is great just because
> they don't want to recognize that they don't truly understand what C++ =
is
> all about...
I get the impression people say C++ sucks becuase they don't understand
it. Fear and hate what you don't understand.
> At least I am sure that most times people want to convince themselves =
about
> the usability and convenience of the rich feature set of C++ just to =
hide
> to themselves or to other people their frustration with it...
>=20
> So well, that was my opinion, my english isn't very good,
Just as good as any other I've read in this forum.
> but I am sure you understood it better than, let's say C++, .. or it =
is not?
I don't understand what that last part meant :-) Huh?
> I want to know your _HONEST_ opinion!!
I love C++! I just hate the crappy excuses for implementations of the
language. There we go again, the real world screwing things up.
> At least I will see if this is a common feeling or is it that I am =
stupid,
> be free to express yourself please, I have to know!
...
People who post here probably know a little more than the average
programmer, so I expect mostly positive views.
--
Chelly Green | che...@eden.com | C++ - http://www.eden.com/~chelly
David A. Cuthbert
>> are a lot of things about C++ that really don't make a lot of sense, at
>> least not to me...
>Some things don't make sense at first, but after finding out more about
>it, it makes sense. Often something is a certain way for compatibility
>reasons, or implementation issues. These reasons are important, though
>they sometimes get in the way. This is the real world. Things aren't
>perfect (oh well :-(
Backwards compatability with C is, IMHO, one of the most painful
problems with C++. Granted, if this were not the case, it wouldn't be
C++.
One of the philosophies that C seems to embrace is the minimization of
keywords in the language (for, if, case, switch, etc.). This has
carried over to C++ (and its programmers), even though C++ adds a ton
of functionality. As a result, C++ has become a syntactial nightmare
at times. Consider the differences between:
int *a; // ptr to integer
const int *b; // ptr to const int
int * const c; // const ptr to int
const int * const d; // const ptr to const int
And then there's the classic starting-out-in-C bug:
int* a, b; // a is a ptr, b is an int
I would MUCH prefer if these could be written as:
ptr int a; // this is a pointer to an integer type
ptr const int b; // same as b, above
const ptr int c; // same as c, above
const ptr const int d; // same as d, above
It is much more obvious and readable (in English, at least) as to what
these are doing.
Someone is bound to point out that I can do a
typedef int * ptr_int;
I don't consider this a valid solution to the readability problem. Am
I really expected to do four "extraneous" typedefs for every single
class I create?
It's also been pointed out that const really modifies what's to its
left. Easier said than read, though, and syntactically ugly, IMHO.
There are a lot of other gripes (e.g., << and >> -- is it the shift
operator, or a template decl?), but I think the point is clear.
>Same here. But then you want more! You want built-in types to act just
>like user-defined types (and vice-versa)! You want to get rid of all the
>standard conversions (and the many integral types)! You want a
>'writeonly' type to match the 'readonly' (const) type modifier! Hehe.
Yep. :-) Though it has been pointed out that there are a number of
solutions to these that can be expressed in C++, some of these should
be inherent in the language. I lose a lot of time implementing these
types of features into my code (debugging them, etc.). Buying them in
a library isn't a valid solution -- I would have a hard time justifying
the need to spend $500 (or more!) to my advisor when software is
probably 1% (or less) of what our group does.
It's becoming clear to me that C++ is not for general use, but for
your hard-core software developer. You really have to take the time
out to learn it, or it will bite you. Even so, it has a lot of
features that I am very reluctant to give up (and switch back to C).
>> I don't know if someone out there has really understood everything about
>> C++ or is close to achieving it,
>I'm sure many understand most of the language as it is defined, but I
>believe there are many ideas and idioms that have yet to be discovered.
>The interesting massive inlining templates and template metaprograms are
>one example of such ideas.
You run into problems when you try to merge the code from two teams
which have different levels of understanding, though. See the const
thread for an example. Heck, it's pretty difficult to merge the code
I wrote a year ago (when I was just learning C++) with the stuff I
write now. :-)
>I get the impression people say C++ sucks becuase they don't understand
>it. Fear and hate what you don't understand.
I wouldn't say that it sucks -- you won't see me running out to buy a
{Fortran, Pascal, Lisp, ...} package to replace my C++ compiler!
Nonetheless, the reality that I do not -- and probably will never --
understand all of the idioms, odd constructs, etc., of the language is
VERY frustrating. (For example, the operator = construct I posted a
week or two ago is a good example; I didn't catch any of the problems
that others illustrated to me)
>I love C++! I just hate the crappy excuses for implementations of the
>language. There we go again, the real world screwing things up.
Hmm... I guess that my perspective is a little different. For me, a
language is not only its definition, but its implementation(s) -- I
don't care how great a language is unless it can produce great code
for me with a reasonable cost and coding effort. I don't care what is
planned for the language; I just don't like it when my code is
suffering from problems in the compiler and causes whatever hardware
I'm working on to lock up. This not only makes my work look bad, but
it can be downright dangerous as well, considering that I'm working
with high voltages and magnetic fields under computer control!
Even so, I still prefer C++ to any other language out there.
--
David A. Cuthbert Graduate Student, Electrical and Computer Engineering
da...@andrew.cmu.edu Carnegie Mellon University
Dale Merrick
I can't fully comment on everything you stated but ...
As a newbie to C++ (came from Delphi) I've got to say that I'm having an
absolute blast! I stayed away from C++ for along time because I had alot
of "gripes" about the language. I've come to realize that those gripes
were unfounded and existed because I had no idea what C++ was about.
I'm still not fully aware of what C++ is about, but I'm learning. There
are some things that I can do in Delphi quicker than I can C++ but that's
because I've used Delphi since it came out and I know the language very
well. I know C++ can do all those things I just don't have the skill to do
them in C++, yet. :)
It's going to take me awhile (a long while) before I can program in C++ as
good as I can in Delphi but I'll get there.
To answer the question: I like C++ alot and I'm slowly beginning to love
it.
--
Dale Merrick
dmer...@vci.net (home)
dal...@atlasvanlines.com (work)
Kurt Watzka
"Oriol de San Pedro" <o...@nil.fut.es> writes:
>Hello,
>This letter is a bit special, my purpose with this letter is to see what
>people really think about the C++ language...
>To start it up I have to say I think the C++ is really the best language,
>in the sense that there isn't any other better, but still, I think there
>are a lot of things about C++ that really don't make a lot of sense, at
>least not to me...
IMHO, there is no best language, in the same way as there is no best
tool for a blacksmith. You will meet different tasks in your working
life, and each task can be handled with a lot of different tools.
Some tools are better adjusted to some tasks than others, but a
"best" tool for any purpose does _not_ exist in most cases.
>The question would be: is it that C++ has some features that, too often,
>doesn't make a lot of sense, or is it that I still havent grasped the whole
>picture?..
Since C++ is a general purpose programming language, some features
of the language will not be necessary for a special purpose, but
this should not be a surprise to anyone. Some of the tools on
a Swiss officers poket knive don't make a lot of sense in _all_
situations ;-).
>I have spent a lot of time trying to understand what C++ was all about,
>then after a lot of effort, and when I say a lot of effort I mean a lot of
>effort, I started to see what it all was about, but still after working
>with it more and more time I again started questioning seriously the
>validity of C++ as a proper, solid language, that actually makes sense...
Sometimes I am afraid that _one_ design goal of C++ has been missed on
the way to make C++ the general problem solver of the 90s: C++ was
meant to be a simple language, according to Bjarne Stroustrup. The
language is both powerful and scalable as it stands, but if you claim
that the language is still simple, try to teach _all_ of the language
in an introductory course on C++.
>I took me a lot of time to get into C++, and now that I am inside it I
>don't think: Wow! That's beautiful, I love this, ... I mainly think C++
>is a complex language that has lots of nonsense features and
>characteristics you easily can get lost into, the only practical solution
>seems to stay near the basic well understood concepts and never, NEVER try
>strange things cause most of them are just there to annoy the poor
>programmer, features that are like monsters that can go and ate you... : )
I have not yet found a feature of C++ that does not make sense in
some situations, and I do not share the feeling that some features
have been invented to "annoy the poor programmer". If you don't need
the corkscrew on a Swiss officers pocket knive to butter your bread,
nobody forces you to use it. However, if you end up with a bottle of
wine some other day, you might be glad that there _is_ a corkscrew
on your pocket knive.
>I don't know if someone out there has really understood everything about
>C++ or is close to achieving it, or if people say C++ is great just because
>they don't want to recognize that they don't truly understand what C++ is
>all about...
IMHO, C++ is a tool, even if there is _some_ philosophy involved. As a
tool, C++ can be approached with an engineering point of view: If it
works, it is O.K. The philosophical parts of mechanics, and the basic
interconnectedness of all events on the quantum level need not be
fully understood to construct a working engine.
Kurt
--
| Kurt Watzka Phone : +49-89-2180-6254
| wat...@stat.uni-muenchen.de
John Nagle
da...@ugcs.caltech.edu (David A. Cuthbert) writes:
>Chelly Green <che...@eden.com> wrote:
>>Oriol de San Pedro wrote:
>>> in the sense that there isn't any other better, but still, I think there
>>> are a lot of things about C++ that really don't make a lot of sense, at
>>> least not to me...
>>Some things don't make sense at first, but after finding out more about
>>it, it makes sense. Often something is a certain way for compatibility
>>reasons, or implementation issues. These reasons are important, though
>>they sometimes get in the way. This is the real world. Things aren't
>>perfect (oh well :-(
And some things, after you find out about them, make less sense.
C++ is weighed down by too much of its own legacy, let alone C legacy.
It's worth noting that some analysts claim that C++ usage peaked
about two years ago. Visual Basic seems to be replacing C++ as the
language for simple GUI applications. Programmer productivity is much
higher in Visual Basic or Java than in C++, and for many applications,
the overhead of those languages isn't a major issue. In any case,
with the major class libraries, you end up defining graphical elements
in form that is essentially interpreted by the class library, so
GUI performance often isn't all that great in C++ anyway.
Also note that all the newer languages for GUI applications (Java,
Visual Basic, and Delphi) all have the following properties:
- automatic storage management (VB and Delphi use reference counting,
and Java uses garbage collection)
- reference semantics, rather than explicit pointers
- no pointer arithmetic
- safety against overwriting memory
C++ has none of these properties.
C++ proponents, Strostrup in particular, have argued that the success
of C++ validates their design decisions. Now that the competition is gaining,
it's time to reexamine that statement.
I'd argue that the next generation of C++ should be syntactically
incompatible, but it should be possible to machine-convert existing C++
and C to the new language. This allows fixing some of the big syntactic
problems. But those aren't the real issue; it's the underlying memory
model that's the killer. Pointer arithmetic needs to go. Sadly,
STL perpetuates pointer arithmetic as a concept when it was on the way out,
making it more difficult to migrate to an environment without it.
There's a role for a low-level language, but as with assembler, you
only want to write a few key sections of programs in it, not the whole
thing.
John Nagle
Tero Parvinen
Oriol de San Pedro wrote:
> grasped the whole picture?..
...
> with it more and more time I again started questioning seriously the
> validity of C++ as a proper, solid language, that actually makes
> sense...
The point in C++ is actually to include the possibility of object
oriented programming into C. The three principles of OOP are
encapsulation, polymorphism and inheritance. Almost all of C++'s
features are aimed at making this stuff possible, proper and solid.
Now you might think that all this is nonsense and you won't ever need it
for anything. Some years back when I didn't know C++ I was working on a
game with a friend. Our main problem was that the different kinds of
spaceships were to have differing numbers of weapons etc. but there had
to be a common interface to the data in order to make the ship editor
and to use the ships in the game. The project died because of these
difficulties. The problem would have been completedy nonexistant had we
had a C++ compliler. OK, you could have done that using structs and
function pointers, but we were working in Pascal then and this is a good
example of the uses of C++.
If you're interested, you'll find more examples and justification in
books which discuss object oriented programming and the three
fundamental things of OOP.
Oh yes, the answer to your question: Yes, I really like C++ :)
--
Tero Parvinen
Tero.P...@hut.fi
http://www.niksula.cs.hut.fi/~tparvine
Joachim Achtzehnter
In article <579umb$3...@netlab.cs.rpi.edu>, na...@netcom.com (John Nagle) wrote:
> [...]
> the newer languages for GUI applications (Java,
> Visual Basic, and Delphi) all have the following properties:
>
> - no pointer arithmetic
> - safety against overwriting memory
>
> C++ has none of these properties.
> I'd argue that the next generation of C++ should be syntactically
> But those aren't the real issue; it's the underlying memory
> model that's the killer. Pointer arithmetic needs to go.
> There's a role for a low-level language, but as with assembler, you
> only want to write a few key sections of programs in it, not the whole
> thing.
Your last paragraph expresses the key point! Sometimes you do need a
language like C++. Since we now have languages with the desirable features
you want, why not just use Java when it is appropriate. There is no need
to bend C++ into something it isn't. Especially not by throwing away the low
level features. Remember, somebody will have to implement those Java runtime
environments!
Joachim
____________________________
joa...@mercury.bc.ca (work)
joa...@wimsey.ca (home)
Steve Heller
wat...@stat.uni-muenchen.de (Kurt Watzka) wrote:
>Sometimes I am afraid that _one_ design goal of C++ has been missed on
>the way to make C++ the general problem solver of the 90s: C++ was
>meant to be a simple language, according to Bjarne Stroustrup. The
>language is both powerful and scalable as it stands, but if you claim
>that the language is still simple, try to teach _all_ of the language
>in an introductory course on C++.
You have pointed out a serious pedagogical problem with C++: going
too fast. Unfortunately, many teachers (and writers) try to cover far
more than they should in an introductory course (or an introductory
book). The result is that the student gets lost very quickly.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
Vadim Zeitlin
In article <57d2to$f...@netlab.cs.rpi.edu>,
hel...@utdallas.edu (Steve Heller) wrote:
>> You have pointed out a serious pedagogical problem with C++: going
>>too fast. Unfortunately, many teachers (and writers) try to cover far
>>more than they should in an introductory course (or an introductory
>>book). The result is that the student gets lost very quickly.
Sorry, but I disagree. You should cover as much as possible.
C++, in my opinion, was never meant to be a simple language
(anyone to argue that BASIC is more difficult to master than C++?).
It was meant to be a powerful one. Indeed, there are some things
that can be done better (or faster, or whatever) in other languages,
but there are practically no projects that cann't be done in C++.
Of course, this power comes at a cost - a complexity. What is
important, however, is that even if you know that you're using
a very powerful and flexible language that has a lot of features,
you don't need to use them all at once. Perhaps you'll even _never_
have to use all of them.
But you should know about their existence - otherwise you shouldn't
use C++ at all, because you are left with complexity, but without
all the rest. That's why I think that even an introductory course
on C++ should cover almost everything (except, perhaps, the newest
additions to the language that are still not widely (at least!)
supported). The course shouldn't insist on details of syntax - it
may be hard to learn a lot of new things that quickly, but it should
show all the possibilities of C++.
And, to come back to the thread's title: I do love C++ (if one
may love a programming language :-)
VZ
Alf P. Steinbach
John Nagle wrote:
...
> Also note that all the newer languages for GUI applications (Java,
> Visual Basic, and Delphi) all have the following properties:
>
> and Java uses garbage collection)
Java has garbage collection. Don't know about VB, but doubt that it has
garbage collection within the language. Delphi does not have garbage
collection within the language. Keep in mind that the *language* Delphi
is an Object Pascal + Borland Pascal marriage, although newbies to
programming in general might not notice anything but the forms-based
userinterface of the IDE.
> - reference semantics, rather than explicit pointers
Delphi (thanks heaven for that!) has explicit pointers. Otherwise it
couldn't
compile standard Pascal programs.
> - no pointer arithmetic
Delphi has pointer arithmetic. Of course.
> - safety against overwriting memory
None of the languages have that. It's an operating system issue if you
are
considering the heap (although the issue is pretty moot with Java).
>
> C++ has none of these properties.
You mean C++ doesn't have any of these lacks of properties. Hm.
>
> C++ proponents, Strostrup in particular, have argued that the success
> of C++ validates their design decisions. Now that the competition is gaining,
> it's time to reexamine that statement.
>
> I'd argue that the next generation of C++ should be syntactically
> incompatible, but it should be possible to machine-convert existing C++
> and C to the new language. This allows fixing some of the big syntactic
> problems. But those aren't the real issue; it's the underlying memory
> model that's the killer. Pointer arithmetic needs to go.
What has religious issues to do in comp.lang.c++.moderated???
Apart from not lacking all the properties you want lacking, Delphi or
Java seems to be good candidate languages. Just rename them to C++.
(Straight face here.)
- Alf
Robert Rodgers
na...@netcom.com (John Nagle) wrote:
> It's worth noting that some analysts claim that C++ usage peaked
>about two years ago.
I'm just curious about this and the following statement. I read
recently that the pool of C++ programmers was still growing by some
multiple-of-ten-thousand-odd per year as of 1995. Now, whether the
fun development is in c++ is another question, but I think it's
premature to say usage has peaked, especially since projects initiated
in the last three years will continue to see development (in C++) at
least for the next several years.
So, do you have a source for C++ having peaked? (God, can you imagine
anyone actually switching to VB4? Ugh.)
> Visual Basic seems to be replacing C++ as the
>language for simple GUI applications. Programmer productivity is much
>higher in Visual Basic or Java than in C++, and for many applications,
I can't imagine anyone is more productive in Java than in a
half-decent C++ environment today. Although it shows a lot of
promise, AWT is the pits, debuggers are weak, the language is about to
undergo another major expansion, and none of the dev environments is
even remotely comparable to VC++, OC, &c&c&c. And that doesn't
include the pathetic performance, even with JIT, and the rank
instability of the two major JIT implementations: Netscape &
Microsoft.
*(I love Java. I'd *rather work in Java*. I love Java. It's cool.
It's neat. But god, is it slow.)
[...]
> C++ proponents, Strostrup in particular, have argued that the success
>of C++ validates their design decisions. Now that the competition is gaining,
>it's time to reexamine that statement.
I agree. I've used GC for about >6 months and I will never work on a
project that wont use it. For one thing, it saves a lot of time and
hassle on my part, but it also *guarantees* that the client will be
happier with the product, which will be faster, safer, and (from the
experience so far), free of leaks.
Although people look at you funny when you discuss "programmer
ethics," the idea of delivering solid, reliable code to the people who
are paying for it seems to me to be something to work for, especially
when (like GC) the cost is minimal.
On the other hand, the GC I'm using is for C++, so you can see that I
don't think that the lack of GC (which can be had -- cheaply -- for
C++) or the availability of pointers (references exist in C++ and
smart programmers use them as much as possible, lowering the
possibility of pointer errors), or the capability of arrays to overrun
(people who persist in using dumb arrays get what they deserve) really
makes a solid case against C++.
If you want a case against C++, a much better starting point is "the
language with everything, including three different models of kitchen
sink," or "a language that, when used properly, is nothing like C, but
when taught, always improperly, is taught like C."
rsr
www.wam.umd.edu/~rsrodger b a l a n c e
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"If we let our friend become cold and selfish and exacting without a
remonstrance, we are no true lover, no true friend."
- Harriet Beecher Stowe
John Nagle
"Alf P. Steinbach" <al...@online.no> writes:
>John Nagle wrote:
>> - safety against overwriting memory
>None of the languages have that. It's an operating system issue if you
>are considering the heap (although the issue is pretty moot with Java).
No, some languages have it, and some don't. C doesn't have it,
C++ doesn't have it, but Java has it, and Visual Basic has it. Standard Pascal
and Ada have it except for references to deallocated pointers.
LISP and Prolog have it. Perl and TCL have it. Modula has it, with
the same exception as noted for Pascal and Ada. FORTRAN doesn't have it.
Forth doesn't have it.
John Nagle
Steve Heller
zei...@dptmaths.ens-cachan.fr (Vadim Zeitlin) wrote:
>That's why I think that even an introductory course
>on C++ should cover almost everything (except, perhaps, the newest
>additions to the language that are still not widely (at least!)
>supported). The course shouldn't insist on details of syntax - it
>may be hard to learn a lot of new things that quickly, but it should
>show all the possibilities of C++.
The main result of such a course will be to leave the novice
programmer so far behind and so confused that he or she may very well
give up programming entirely. Without a solid foundation in the most
fundamental constructs of the language, it's not possible to learn the
more complex aspects.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
Steve Heller
rsro...@wam.umd.edu (Robert Rodgers) wrote:
>If you want a case against C++, a much better starting point is "the
>language with everything, including three different models of kitchen
>sink," or "a language that, when used properly, is nothing like C, but
>when taught, always improperly, is taught like C."
While I agree with most of the rest of your post (except that
garbage collection is not needed when using properly written classes),
I think there's at least one exception to the "always improperly"
phrase. Of course, I'm referring to my C++ book for beginners, which
teaches C++ like C++. For just one example, can you imagine a 500+
page book on C that doesn't use any casts or pointer arithmetic? I
can't.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Vandevoorde
>>>>> "TP" == Tero Parvinen <te...@mnar.tky.hut.fi> writes:
[...]
TP> The point in C++ is actually to include the possibility of object
TP> oriented programming into C. The three principles of OOP are
TP> encapsulation, polymorphism and inheritance. Almost all of C++'s
TP> features are aimed at making this stuff possible, proper and
TP> solid.
[...]
C++ certainly added mechanisms and features to support object-oriented
programming (OOP). However, saying that `almost all of C++'s features
are aimed' at enabling OOP is a gross overstatement IMO. Many of C++'s
features are aimed at supporting other paradigms (e.g., generic
programming) and techniques (e.g., code organization, type safety, ...).
I find it important to remember that OOP is primarily a tool to achieve
code reuse and maintainability through _uncoupling_. In languages where
the intent is to provide ``total run-time polymorphism'' (excluding all
sorts of optimizations), like SmallTalk, OOP provides for a complete
uncoupling solution. In a sense, you could say that with such ``total
polymorphism'' (i.e., the ability to send messages between objects is not
tied to the type-relation between those object), there is no significant
distinction between the OO and generic paradigms.
In C++ however, efficiency and strong type-checking are a prime goals,
so that ``total polymorphism'' is not feasible: polymorphic dispatch
is tied to inheritance, which brings about a new kind of ``coupling''.
As a result, is makes a lot of sense to add a new uncoupling tool in
the form of templates (i.e., explicit support for compile-time
genericity). There are IMO as many features in C++ to enable templates
as there are to enable OOP, and their combination can be exploited to
achieve decoupling _and_ efficiency.
... which is a major reason why I enjoy programming C++.
Daveed
Andrew P. Bajorinas
hel...@utdallas.edu (Steve Heller) wrote:
]zei...@dptmaths.ens-cachan.fr (Vadim Zeitlin) wrote:
]>That's why I think that even an introductory course
]>on C++ should cover almost everything (except, perhaps, the newest
]>additions to the language that are still not widely (at least!)
]>supported). The course shouldn't insist on details of syntax - it
]>may be hard to learn a lot of new things that quickly, but it should
]>show all the possibilities of C++.
] The main result of such a course will be to leave the novice
]programmer so far behind and so confused that he or she may very well
]give up programming entirely. Without a solid foundation in the most
]fundamental constructs of the language, it's not possible to learn the
]more complex aspects.
I agree. This would only serve to show the student what was possible,
but not for them. :) Major frustration would be the only sure result.
Sheesh, if a student finds the "details of syntax" too hard to learn
then perhaps they should be in a different course of study. For
programming, god is in the details.
|----------------------------------------------------------------------------|
| Andrew P. Bajorinas | These opinions are my own and |
| Bajo...@Perkin-Elmer.com | not those of my employer. |
|----------------------------------------------------------------------------|
|"The fact that a believer is happier than a skeptic is no more to the point |
|than the fact that a drunken man is happier than a sober one. The happiness|
|of credulity is a cheap and dangerous quality." George Bernard Shaw |
|____________________________________________________________________________|
Alex Martelli
na...@netcom.com (John Nagle) writes:
...
> Also note that all the newer languages for GUI applications (Java,
>Visual Basic, and Delphi) all have the following properties:
> - automatic storage management (VB and Delphi use reference counting,
> and Java uses garbage collection)
> - reference semantics, rather than explicit pointers
> - no pointer arithmetic
> - safety against overwriting memory
This profile is not specific to languages for GUI applications, nor is
it at all new; indeed, it's basically shared by most object-oriented
languages, *except* C++. If you read Stroustrup's book on C++ design
and evolution, you'll see that his original motivation was to get the
advantages of object-orientedness that he had been used to in Simula,
*without* the performance overhead that is implied by reference
semantics and automatic storage management; he wanted to be able to
have true objects on the stack or with static lifetime, not just on the
heap, hiddenly and implicitly placed there by a language's runtime
mechanisms.
You want reference semantics and automatic storage management? Besides
the three languages you list, you can get them in Simula, Eiffel,
Sather, Modula-3, Oberon, just to list a few major OO languages
that tend to share with C++ some concern for compile-time type
safety, and performance -- Smalltalk. Python, Perl 5, etc, are
available (also with reference semantics and automgmt of storage)
with a more "interpreted", dynamic as opposed to compile-time,
orientation. And I'm sure I've missed a lot of major OO languages
(for example, I don't know how the object model of Ada95 is, from
this point of view, so I'm not listing it:-) from this list.
>C++ has none of these properties.
Exactly: C++ is the ONLY major O-O language that allows me complete
control on memory management issues, including object placement
(heap vs stack vs static -- and finer still, since I can write my
own overloaded operator new for special memory-residence needs).
This still has huge potential for better performance than any
language taking this control away from me -- and just-as-huge
potential for misuse and error on my part. I have to build or
purchase the appropriate infrastructure, from auto_ptr<> to the
most elaborate letter/envelope setup, to get the same reference
semantics and auto-mgmt that other languages "give me for free" --
AND force me to use; and when I have that infrastructure in
place, I'm still not forced to use it in each and every case --
which has good sides AND bad sides, of course, because it allows
me to choose appropriately, but it also allows me to choose
badly and to make mistakes that are simply impossible where
that level of freedom is just not left to the programmer.
> C++ proponents, Strostrup in particular, have argued that the success
>of C++ validates their design decisions. Now that the competition is gaining,
>it's time to reexamine that statement.
Even if there was a way to validate and make sense of your statement
that "the competition is gaining", it would still not mean that. If
another language offers me a better trade-off for some application
(or part of an application), and I'm not averse to using several
languages togeher for some practical reason, I will use said other
language, be that together with, or instead of, C++ -- always have,
always will. And I would NOT like -- indeed, I would HATE -- to
see C++ weaken itself by either adding yet more stuff to try and
emulate another language, OR by cutting away its own flesh to try
not to allow me to make some given mistake or class of mistakes
(thereby inevitably not allowing me, also, to do some things that
are USEFUL to me in certain situations and contexts).
C++ has its own flavour -- a very broad-spectrum, complex language,
allowing me to use, and mix seamlessly, a huge range of features
from styles and idiolects normally not spoken of in the same breath.
This makes a lot of sense, AND leaves all sort of niches for other
languages (probably just assembler "below" it, but lots of different
possibilities "above and to the sides") -- scripting/interpreted ones,
ones easier to use and more constrained (for teaching purposes, for
less-experienced users, etc), ones more fluid and dynamic for easier
and faster change, and so on and so forth.
The very worst mistake the C++ community might perpetrate (not that
there is any real risk of it, of course) would be to abandon its
specific and particular nature -- in other words, to follow your
advice.
> I'd argue that the next generation of C++ should be syntactically
>incompatible, but it should be possible to machine-convert existing C++
>and C to the new language. This allows fixing some of the big syntactic
>problems. But those aren't the real issue; it's the underlying memory
>model that's the killer. Pointer arithmetic needs to go. Sadly,
"If you want Eiffel, you know where to find it" -- or Oberon, Sather,
Modula-3, Java, Ada95, Smalltalk, Visual Basic, Python, Perl 5, etc
etc, all excellent and interesting languages in their own right.
In my opinion, the Fortran community shot itself in the foot when
it came out with the "Fortran 90" standard -- a major revision to
the language which deeply changed its fundamental nature and thrust
(though not going as far as your proposals to insert deep and
pervasive incompatibilities at BOTH syntactic AND semantic levels!).
I don't think it's a coincidence that I, and several others, dropped
what Fortran we still used to do, and switched fully to other
languages, just about at that point; why study a new, untried
language just because it happens to be called the same as an
old one you used to know -- and make appropriate use of in its
areas of strength -- where those strengths and weaknesses have
been fundamentally, utterly changed. I see you'd want C++ to
go along a similar, and even more radical, route -- but WHY, WHY
ON EARTH, should C++ cease to be C++ in a doomed effort to be
"a better Java" or "a better Eiffel" or "a better Oberon" or
"a better anything else"?! The only redeeming feature of this
idea is that it's so utterly absurd that it stands just about
no risk of ever becoming reality.
>STL perpetuates pointer arithmetic as a concept when it was on the way out,
>making it more difficult to migrate to an environment without it.
The main strength of STL is that it matches the "feel" of C++ --
suitably powerful yet low-level and "building-block" oriented.
It doesn't so much DO things for you, as ALLOW you to build (or
purchase) infrastructure and enablers for the actual solutions.
Part of this excellent fit with C++ _is_, of course, that good
old pointers into arrays are perfectly usable in lieu of STL's
iterators -- but there is absolutely nothing in STL "perpetuating"
them, i.e. forcing or even _encouraging_ their use -- it just
allows smoother migration where legacy code has to be upgraded
or the absolute-highest performance is an issue.
> There's a role for a low-level language, but as with assembler, you
>only want to write a few key sections of programs in it, not the whole
And C++ *allows*, though it does not *force*, you, to do exactly
that -- limit the usage of its low-level parts to just those
regions of your program which absolutely need them. But perhaps
you LIKE being forced? Once again, then, I would strongly urge
you to take up Eiffel, or any other excellent language of that
ilk, coming from the "let's MAKE the programmer do things RIGHT"
tradition of Pascal etc. There is lots to be said for that
class of language, of course -- and you can set up for yourself
a mixed-language environment optimized to your heart's desires,
if you have no specific reason to avoid using more than one
language (and this paragraph of yours only makes sense if such
multi-language use is OK in your situation). Among the strengths
of C++ has traditionally been the relative ease of integration
with other languages (which is, of course, vastly facilitated
by C++'s being a *MULTI-PARADIGM* language -- something you
don't seem to appreciate, since you'd want to take away some
of those precious, if low-level, paradigms from it).
Alex
--
DISCLAIMER: these are MY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: mart...@cadlab.it -- Phone: +39 (51) 597 313 [Fax: 597 120]
Cad.Lab S.p.A., v. Ronzani 7/29, 40033 Casalecchio (BO), Italia
Bob Calbridge
hel...@utdallas.edu (Steve Heller) wrote:
>wat...@stat.uni-muenchen.de (Kurt Watzka) wrote:
>>Sometimes I am afraid that _one_ design goal of C++ has been missed on
>>the way to make C++ the general problem solver of the 90s: C++ was
>>meant to be a simple language, according to Bjarne Stroustrup. The
>>language is both powerful and scalable as it stands, but if you claim
>>that the language is still simple, try to teach _all_ of the language
>>in an introductory course on C++.
> You have pointed out a serious pedagogical problem with C++: going
>too fast. Unfortunately, many teachers (and writers) try to cover far
>more than they should in an introductory course (or an introductory
>book). The result is that the student gets lost very quickly.
I could agree to a point. I'm using Steven Prata's book in my class
and I find it extremely detailed, which is what I really worry about.
I had the benefit(?) of understanding C before tackling C++. The book
itself really sticks to the basic C constructs early on except where
IO needed to be discussed.
I was trying to pace the course so that at the end of the semester all
I'd have time to talk about with regards to classes was class basics,
overloading, inheritance and file IO. The unusual thing was that when
I was teaching C I was usually cramming structures and file IO into
the last couple of weeks. In this class I found myself trying to fill
the last couple of weeks. I don't know if I just lucked out with a
good class that could advance quickly (well, not all of them,
but....). The point is, I did have time to go beyond what I
considered as elementary.
The question is, what defines elementary. Most of the texts I've seen
that are suitable for classroom use go pretty far beyond what I
consider to be on the elementary level. But they wouldn't be complete
enough for someone using it as a self-teaching aid. So, where do we
draw the line. Do we just touch on the basics and then pursue
technique, giving the student more time to let the basics seep in? Or
do we just keep on plugging, giving them as much of the language as
time permits.
Bob
Bob Calbridge = bcalb...@dcccd.edu
Senior Network Systems Programmer
Postmaster, Cook, Bottle Washer
Robert Rodgers
hel...@utdallas.edu (Steve Heller) wrote:
>rsro...@wam.umd.edu (Robert Rodgers) wrote:
>>If you want a case against C++, a much better starting point is "the
>>language with everything, including three different models of kitchen
>>sink," or "a language that, when used properly, is nothing like C, but
>>when taught, always improperly, is taught like C."
>
> While I agree with most of the rest of your post (except that
>garbage collection is not needed when using properly written classes),
I don't agree. Take exceptions. Exceptions just make things worse,
not better, and I don't need the hassle. But more generally, I
think GC should be bundled with modern operating systems, not just
because ISVs aren't doing a very good job getting to those properly
written classes, but because it allows developers to do a better job
regardless of how careful they are.
I do my best to avoid memory leaks -- I did before using GC, and I do
it by design even while using GC. I use smart pointers, I use
carefully designed containers, keep things simple, and I usually (as a
backup measure) put as much as humanly possible on the stack (I wish
they would teach this last one -- it's not ideal, but it sure as heck
eliminates 90% of the hassle that people get from new & delete). But
there's always something, especially if you use a lot of third party
libraries (I do) and if you want to have a very lengthly runtime (days
or weeks -- I do).
It's better to just plain eliminate the possibility *and* do the right
thing than to do the right thing and hope you got all the
bugs/problems. Given how little overhead GC actually has (most of the
seriously memory intensive end-user apps only have a few megs of
memory that a collector actually needs to scan -- the rest, be it
bitmaps or what have you, doesn't need to be, it doesn't contain
pointers) there is no reason not to use it, even just as a back up
measure.
>I think there's at least one exception to the "always improperly"
>phrase. Of course, I'm referring to my C++ book for beginners, which
>teaches C++ like C++. For just one example, can you imagine a 500+
>page book on C that doesn't use any casts or pointer arithmetic? I
>can't.
Well, I was actually thinking of formal education. I have not seen
your book, but as you describe it, it sounds like someone should be
using it. I've sampled the books used by the schools on the East
coast, and they range from decent-but-really-C (D&D) to simply
dreadful (I can't remember the name, but one book's presentation is
close to comic-book).
Of course, I'm biased: I think C++ should be taught as classes from
ground zero, day 1. How else are we expecting to create a generation
of programmers who, when stumped with a bug or problem, resort to test
_Classes_ instead of jumping back to simple C programs?
rsr
www.wam.umd.edu/~rsrodger b a l a n c e
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"If we let our friend become cold and selfish and exacting without a
remonstrance, we are no true lover, no true friend."
- Harriet Beecher Stowe
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Chelly Green
Thomas Breuel wrote:
>
...
> What students should be alerted to and taught to avoid is the few
> unsafe or unportable uses of certain pointer casts and some pointer
> arithmetic.
They should be taught the new cast syntax, which makes it clear that
when they use a reinterpret_cast<>, they're doing something that is
usually non-portable. Other pointer/reference casts are safer, assuming
the cast is valid (i.e. the object really is what you're casting to).
--
Chelly Green | che...@eden.com | C++ - http://www.eden.com/~chelly
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Steve Heller
Thomas Breuel <t...@intentionally.blank> wrote:
>Not only can't I imagine a 500+ page book on C that doesn't use casts
>or pointer arithmetic, I also can't imagine why you would want to
>write a 500+ page book on C++ that doesn't explain them.
So as not to confuse the newcomer with error-prone constructs.
There's plenty of time for them to deal with pointer errors later.
>Sweeping casts and pointer arithmetic under the rug in a textbook, in
>my opinion, is not "teaching C++ like C++", but simply keeping
>students in ignorance of a crucial, portable, well-defined aspect of
>C++.
You forgot to mention "error-prone". That's why I provide string and
vector classes to allow them to make progress in their programs
without having to learn about pointers and arrays until they have to
do so.
>What students should be alerted to and taught to avoid is the few
>unsafe or unportable uses of certain pointer casts and some pointer
>arithmetic.
All uses of pointers in application code are unsafe, whether
portable or not, because it is a virtual certainty that they will be
misused in any large application program. Therefore, they must be
confined to the interiors of infrastructure classes. I explain and
illustrate how to do this in my book.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
Jesse Liberty
I'm uncomfortable with this thread because I don't want to be in the position of commenting on or criticizing other
people's primers. So let's move from the specific to the more general. In my opinion a good C++ primer should teach C++
as an object-oriented language.
That is, the primary issue is not whether you examine C++ as a language in its own right -- of course you do -- but
rather whether you can teach C++ as a tool for developing object-oriented programs. Within that context, you may decide
to include pointer arithmetic or casting, but you wouldn't necessarily include either; no primer is 100% exhaustive.
In my own book, I do cover casting, because the issue of when you may be tempted to "cast down" the inheritance
heirarchy is very important and should be understood immediately after inheritance, polymorphism and virtual functions
are introduced. I also talk about casting in the context of C++ as a strongly typed language. These issues are
critical and go beyond the simple syntax to a full understanding of how the language should be used.
-j
Alf P. Steinbach
>
> >are considering the heap (although the issue is pretty moot with Java).
>
> No, some languages have it, and some don't. C doesn't have it,
> C++ doesn't have it
Ok.
> but Java has it, and Visual Basic has it.
Would be interesting to know what you mean by that, exactly.
> Standard Pascal
> and Ada have it except for references to deallocated pointers.
That's not correct. Using standard Pascal, you can write wherever you
want in the process' address space, but it's intentionally awkward --
to do pointer arithmetic in standard Pascal, you must use typecasting in
the form of variant records, e.g. (assuming an integer is the same
size as a memory address, which is part of why it's ugly!)
type word_ptr = ^integer;
procedure SetAddress( var wp: word_ptr; address: integer );
var
kludge : record
case boolean of
true : ( p: word_ptr );
false : ( i: integer )
end;
begin
kludge.i := address; wp := kludge.p;
end; { SetAddress }
Of course, it's much easier to this kind of thing in Ada, which is
meant first and foremost for programming embededded systems!
The Lisp and Prolog discussion below is the sense of your comment on
Fortran, see end of posting. I mention this in case you consider a
"retort" by referring to physical memory adresses or some such (which
would probably contain a new heap of factual errors).
> LISP
[has protection against memory overwrite] That's not correct. In Lisp,
you can overwrite memory accidentally if you use SETQ. This only
applies to allocated memory within each Lisp program, but the op.sys.
is responsible for inter-process protection. For the purposes of your
argument -- safety of object handling -- Lisp is not safe.
> and Prolog have it.
Please. It's not correct. But Prolog is even more of a special case
than Lisp. Prolog only provides assignment through Assert and Retract
in the global database of predicates/facts. Since it only has global
assignment memory / identifiers, there is no protection whatsoever.
> Perl and TCL have it.
Haven't used these, so can't comment.
> Modula has it, with
That's not correct. Look up the facilities of the SYSTEM module.
> the same exception as noted for Pascal and Ada. FORTRAN doesn't have it.
I assume you mean the Fortran common block.
In short, you're way off base, and seem to simply make statements about
things you do not know much about. So I can understand that you
want some "simpler" language than C++ is today -- it's for
professionals who build, buy or already have the abstract support layers
they need.
- Alf
David Bradley
da...@ugcs.caltech.edu (David A. Cuthbert) wrote:
> int *a; // ptr to integer
> const int *b; // ptr to const int
> int * const c; // const ptr to int
> const int * const d; // const ptr to const int
Redo the above as follows
int *a; // Pointer to integer
int const* b; // Pointer to constant integer
int * const c; // Constant pointer to integer
int const * const d; // Constant pointer to constant
integer
All false into place and the simple rule of const follows what it
modifies works well.
But to the topic at hand. I view C++ is a powerful language that
needs some improving, but what language doesn't. I guess the question
I ask is what have we learned from C++ as a language and can we use
that knowledge to create a better language?
There are many things I like about C++ and I don't want to give them
up. I'd rather move on to a language that supports the basic concepts
held within the C++ language but maybe it has a bit better syntax. I
think we could make some areas a little easier to understand and/or
read.
--------------------------------------------
David Bradley dav...@datalytics.com
Software Engineer
Datalytics, Inc. http://www.datalytics.com
Vadim Zeitlin
In article <57ftqh$1...@netlab.cs.rpi.edu>,
Bajo...@Perkin-Elmer.com (Andrew P. Bajorinas) wrote:
>>hel...@utdallas.edu (Steve Heller) wrote:
>>
>>]zei...@dptmaths.ens-cachan.fr (Vadim Zeitlin) wrote:
>>
>>]>That's why I think that even an introductory course
>>]>on C++ should cover almost everything (except, perhaps, the newest
>>]>additions to the language that are still not widely (at least!)
>>]>supported). The course shouldn't insist on details of syntax - it
>>]>may be hard to learn a lot of new things that quickly, but it should
>>]>show all the possibilities of C++.
>>
>>] The main result of such a course will be to leave the novice
>>]programmer so far behind and so confused that he or she may very well
>>]give up programming entirely. Without a solid foundation in the most
>>]fundamental constructs of the language, it's not possible to learn the
>>]more complex aspects.
>>
>>I agree. This would only serve to show the student what was possible,
>>but not for them. :) Major frustration would be the only sure result.
Why? You don't expect to be able to do anything in a language you
just begun to learn, do you? But if you have a broad view of C++,
this should stimulate your curiosity and push you to pursue your study.
At least, I know for sure that I was attracted by C++ because I've
seen some of it's features and I liked them a lot - indeed, I couldn't
use them in my programs at the beginning, so I learned the language to
be able to do it.
>>Sheesh, if a student finds the "details of syntax" too hard to learn
>>then perhaps they should be in a different course of study.
See above - the same logic leads to a statement "if they are
frustrated because they don't understand exceptions, templates etc
right now, they shouldn't learn C++". It's definitely not true.
>>For programming, god is in the details.
Well, I wouldn't know about god :-), but I do think that you shouldn't
try to assimilate all C++ syntax at once - it will be difficult even
for C programmers and yet more difficult for all the others.
In my opinion, details don't really matter much - that's why we have
online help now. The real understanding of the language you use does
matter.
VZ
Jesse Liberty
Steve Heller wrote:
>
> zei...@dptmaths.ens-cachan.fr (Vadim Zeitlin) wrote:
>
> >That's why I think that even an introductory course
> >on C++ should cover almost everything (except, perhaps, the newest
> >additions to the language that are still not widely (at least!)
> >supported). The course shouldn't insist on details of syntax - it
> >may be hard to learn a lot of new things that quickly, but it should
> >show all the possibilities of C++.
>
> The main result of such a course will be to leave the novice
> programmer so far behind and so confused that he or she may very well
> give up programming entirely. Without a solid foundation in the most
> fundamental constructs of the language, it's not possible to learn the
> more complex aspects.
>
Well, I know you and I disagree about this one. I've taught C++ to a
few thousand students; some on line and some in small intensive
seminars. In my experience a four day seminar can cover a lot of
ground with bright, motivated students.
In my four day intensive course for C programmers, we cover classes,
inheritance, polymorphism, abstract data types, streams, pointers,
references, encapsulation, private inheritance, containment,
delegation, multiple inheritance, virtual inheritance, templates,
exceptions, memory-management and a variety of related topics (not in
that order). The four day course for non-programmers must cover more
of the fundamentals; so we get to fewer of the very advanced topics,
but even there we cover the vast majority of what you can do with C++.
The feedback I've received, (I ask for specific feedback on the
material covered each day of the course, then again at the end, and
usually follow up some weeks later) is that this material CAN be
learned in four days if (and perhaps only if) the students are
sufficiently motivated to follow up with exercises and perhaps to
integrate what they've learned into their work.
The point is not to tout the course or my particular methods but only
to tell you that experiences differ; some folks like to learn the key
concepts and drill on them, integrate them into their thinking and
then move on. Others like to see more of the sweep of the language,
and will then return to the parts of most interest to practice and
internalize. Much depends on the students, their experience,
motivation and needs.
-j
--
Jesse Liberty, President
Liberty Associates, Inc.
C++, Java, Active-X
Training and consulting
http://www.libertyassociates.com
Steve Heller
rsro...@wam.umd.edu (Robert Rodgers) wrote:
>I don't agree. Take exceptions. Exceptions just make things worse,
>not better, and I don't need the hassle.
Again, if you write your classes correctly and eliminate the
necessity for ANY pointers in the application code, then you can deal
with exceptions in a robust manner. Remember, destructors are
guaranteed to be called before unwinding the stack at each level, so
if all application variables are stack based, we can guarantee correct
behavior.
>But more generally, I
>think GC should be bundled with modern operating systems, not just
>because ISVs aren't doing a very good job getting to those properly
>written classes, but because it allows developers to do a better job
>regardless of how careful they are.
I can't agree with this either. The problem is that it's not just
memory that can leak. For example, suppose you have an object that
opens a file. If you don't have a destructor for that object, when
will the file be closed? If you do have a destructor for that object,
why do you need GC in the first place?
>I do my best to avoid memory leaks -- I did before using GC, and I do
>it by design even while using GC. I use smart pointers, I use
>carefully designed containers, keep things simple, and I usually (as a
>backup measure) put as much as humanly possible on the stack (I wish
>they would teach this last one -- it's not ideal, but it sure as heck
>eliminates 90% of the hassle that people get from new & delete).
I believe that eliminating any visible pointers is better than using
smart pointers. The polymorphic object idiom allows this in most
cases that are likely to occur in the real world. As for "putt[ing] as
much as possible on the stack", I teach that way. In fact, I tell my
students "don't use pointers except in infrastructure class
implementations".
>But there's always something, especially if you use a lot of third party
>libraries (I do) and if you want to have a very lengthly runtime (days
>or weeks -- I do).
The third party libraries are indeed a problem. However, if the
problem is forgetting to call their cleanup routines, it should be
possible to write a class wrapper that will make sure that happens.
Otherwise, they're buggy, and should be suspected of having other
things wrong with them than just memory allocation.
>>I think there's at least one exception to the "always improperly"
>>phrase. Of course, I'm referring to my C++ book for beginners, which
>>teaches C++ like C++. For just one example, can you imagine a 500+
>>page book on C that doesn't use any casts or pointer arithmetic? I
>>can't.
>Well, I was actually thinking of formal education. I have not seen
>your book, but as you describe it, it sounds like someone should be
>using it. I've sampled the books used by the schools on the East
>coast, and they range from decent-but-really-C (D&D) to simply
>dreadful (I can't remember the name, but one book's presentation is
>close to comic-book).
If you teach C++ or recommend books for that purpose, would you be
interested in seeing an examination copy? If so, email me with your
address.
>Of course, I'm biased: I think C++ should be taught as classes from
>ground zero, day 1. How else are we expecting to create a generation
>of programmers who, when stumped with a bug or problem, resort to test
>_Classes_ instead of jumping back to simple C programs?
I agree.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Bjarne Stroustrup
na...@netcom.com (John Nagle) writes:
> da...@ugcs.caltech.edu (David A. Cuthbert) writes:
> >Chelly Green <che...@eden.com> wrote:
> >>Oriol de San Pedro wrote:
> >>> in the sense that there isn't any other better, but still, I think there
> >>> are a lot of things about C++ that really don't make a lot of sense, at
> >>> least not to me...
>
> >>Some things don't make sense at first, but after finding out more about
> >>it, it makes sense. Often something is a certain way for compatibility
> >>reasons, or implementation issues. These reasons are important, though
> >>they sometimes get in the way. This is the real world. Things aren't
> >>perfect (oh well :-(
>
> And some things, after you find out about them, make less sense.
> C++ is weighed down by too much of its own legacy, let alone C legacy.
>
> It's worth noting that some analysts claim that C++ usage peaked
> about two years ago.
Those analysts must be wrong. My usually reliable sources report steady
growth in the number of C++ users over the last couple of years and no
sign of a change in that. C++ is no longer growing at a rate of more
than 100% a year, but that would be unrealistic to expect after millions
of compilers have been shipped.
Naturally, other lanuages are also growing, but I suspect this is a
case where it is worth distinguishing between the amount of talk/hype
and the amount of use. Also, it's a big world. There is room for
quite a few languages.
> Visual Basic seems to be replacing C++ as the
> language for simple GUI applications. Programmer productivity is much
> higher in Visual Basic or Java than in C++, and for many applications,
> the overhead of those languages isn't a major issue.
The parts of the C++ community that are concerned with that seem
to have taken notice. Witness Optima++ and the soon to be released
Delphi-like tool for C++ (whatever they end up calling it). I suspect
these will not be the last or even the most effective C++ based tools
in this area.
The alternative to C++ is proprietary languages. Some people care
about that - if for no other reason, then because such languages
tend to be limited and constricting outside their original target
domain. I don't like proprietary languages because their owners
invariably fall prey to the temptation to use them as part of some
overall business plan that serves the owner better than the users.
> In any case,
> with the major class libraries, you end up defining graphical elements
> in form that is essentially interpreted by the class library, so
> GUI performance often isn't all that great in C++ anyway.
Indeed, GUIs are such hogs that the performance of the language used to
write minor actions matters less. However, I don't recall the original
message singling out GUIs, so this may be a tangent. For many there is
more to programming than GUI building. C++'s main strength has never
been convenience at the cost of performance.
For good and bad, C++ is a general-purpose language that supports a
variety of programming styles (``paradigms''). For any one application
area, you can construct a language that is more convenient than C++.
However, many (most?) people deal with many application areas and
many of those prefer a multi-paradigm language like C++ over a set
of smaller and more specialized languages.
> Also note that all the newer languages for GUI applications (Java,
> Visual Basic, and Delphi) all have the following properties:
>
> - automatic storage management (VB and Delphi use reference counting,
> and Java uses garbage collection)
> - reference semantics, rather than explicit pointers
> - no pointer arithmetic
> - safety against overwriting memory
>
> C++ has none of these properties.
>
> C++ proponents, Strostrup in particular, have argued that the success
> of C++ validates their design decisions.
That is a very crude and potentially misleading statement of my view of
C++ and the reasons for its success. Have a look at "The Design and
Evolutions of C++" for a fairly detailed discussion of the reasons
behind the design decisions for C++.
The fact that hundreds of thousands of presumably intelligent programmers
have adopted a language that never was the easiest to learn is significant.
It wouldn't have been significant had C++ gained that user population
through extraordinary marketing or through a captive (corporate or
governmental) audience. However, C++ usage became significant while
its marketing dollars were minute compared to what was spent on other
languages and systems. Furthermore, the major suppliers of hardware or
software have consistently favored alternative - and usually proprietary
- languages over C++. Witness: MS/Basic, Apple/ObjectPascal, Borland/Pascal,
Sun/Modula3/Java, DEC/Trellis/Modula3, IBM/ObjectiveC/Smalltalk. For
a supplier, theer are significant benefits from having users tied
in to a language controlled be the supplier.
This still doesn't "validate" all the C++ design decisions. It does however
provide evidence that many decisions were reasonable in their context
and that the flaws were not crippling for large numbers of people.
I at least never clamed that C++ was flawless (see for example D&E and
the ARM). I think that EVERY language - without exception - has flaws
and that we must recognize and acknowledge to be effective at building
real-world software.
> Now that the competition is gaining, it's time to reexamine that statement.
> I'd argue that the next generation of C++ should be syntactically
> incompatible, but it should be possible to machine-convert existing C++
> and C to the new language. This allows fixing some of the big syntactic
> problems. But those aren't the real issue; it's the underlying memory
> model that's the killer. Pointer arithmetic needs to go.
It is easy to design a prettier language than C++ - even I knew how to
do that back in 1980 - both syntactically and semantically. What is
harder is to build a more useful language for real-world applications,
environments, and programmers. Many have tried. it is not as easy as
it appears. It is so much easier to criticise than to construct an
alternative that can stand up to an equivalent degree of scrutiny.
It is not even certain that what is needed is a "next generation C++."
I suspect that to gain significantly over C++ as a tool for constructing
real-world software, we have to go further beyond the current crop of
fashionable languages than most people are willing to believe. I
think that we have much fundamental work ahead of us. Minor tinkering
with the syntax and semantics is not sufficient for a major change in
the way we construct and maintain systems - and no, I do not have such
a language up my sleeve and I do not know of anyone who does.
I'm no fan of fully general pointer arithmetic; it is the source of
too many avoidable programmer errors. However, it may be worth
mentioning that effective garbage collecting implementations of C++
are in use - both commercial implementations and public-domain ones.
Their performance is far better than most people had thought possible
and their implementors didn't have to ban pointer arithmetic, unions,
casts, etc. to achieve that.
I still consider compatibility with C and older C++ programs important,
and there is no shortage of systems where it would be hard to use
automatic garbage collection. With C++, you can have garbage collection
when you need it and can avoid it when you don't want it.
> Sadly,
> STL perpetuates pointer arithmetic as a concept when it was on the way out,
> making it more difficult to migrate to an environment without it.
I think the STL and the concepts and techniques it represents are general
enough, efficient enough, and mathematically clean enough that people
ought to reconsider what it is they like and dislike about pointers.
> There's a role for a low-level language, but as with assembler, you
> only want to write a few key sections of programs in it, not the whole
> thing.
By "low-level language," I assume you mean C++ here. C++ can be used as a
low-level language, but it doesn't have to be. There are benefits from
abandoning the classical model of addressing in a programming language
(for example, it makes garbage collection simpler) but there are also
costs (for starters, there is no one alternative model, there is still
messy things - such as I/O - to deal with, and the classical model does
appear to be close to ideal for many classical algorithms and data
structures). I wrote a paper "Foundations of Native C++ Styles" together
with Andrew Koenig on this topic (see my homepages).
In my opinion, most people shouldn't write in "raw C++" they should
use GUI builders, foundation libraries such as the STL, math libraries,
libraries for data communication, etc. Using such facilities allows
the C++ programmer a variety of higher-level styles and a variety of
engineering tradeoffs. It is even possible to provide C++ libraries to
support traditional low-level (time and spcae critical) programming
tasks better.
The key strenghts of C++ is not so much the facilities it provides
directly as the facilities it can be used to supply. Or, as I was
fond of saying in the early years: "C++ doesn't give you any new and
interesting types, it gives you the tools for building such types
and for using them once you or someone else have built them."
- Bjarne
Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html
Greg Schussman
Oriol de San Pedro wrote:
> This letter is a bit special, my purpose with this letter is to see what
> people really think about the C++ language...
>
> To start it up I have to say I think the C++ is really the best language,
> in the sense that there isn't any other better, but still, I think there
> are a lot of things about C++ that really don't make a lot of sense, at
> least not to me...
I think that there can't be a "best language" without specifying what,
exactly, it is "best" for.
My area of application is computer graphics. I feel that C++ is a
fabulous tool for that job. Its philosophies towards efficiency,
towards low level control, towards high level abstraction,
and toward "not getting in my way", are perfect. It is frightening to
think what graphics would be like in some other languages that I was
required to use in the past. A very heartfelt thanks to Bjarne
Stroustrup.
> The question would be: is it that C++ has some features that, too often,
> doesn't make a lot of sense, or is it that I still havent grasped the whole
> picture?..
I felt the same way. But over time, many of those features have come to
be my favorite tools in day-to-day programming. I believe that the best
tools are the ones you grow into, not out of. I have been growing into
C++
almost daily for just over three years now. It is almost like a martial
art; you don't have to be a grand master to be effective. None the less,
it is enlightening to add to your bag of tricks.
> I want to know your _HONEST_ opinion!!
Honest opinions:
I love C++. I couldn't ask for a better language with which to
write software in the "real world".
I believe that most people who don't appreciate C++ have spent
their time writing software that was one or more of the following:
"trivial", free of real-time/interactive constraints, free of memory
constraints, or so specialized that another language was better.
I believe that Niklaus Wirth (and people with similar views on
language
design) deserve sound spankings for the all the grief they have caused
to real-world programmers. ;)
Thanks for asking.
Greg
Fergus Henderson
b...@research.att.com (Bjarne Stroustrup) writes:
>The alternative to C++ is proprietary languages.
Why do you say that? Most of the languages that are
competitors to C++ are not proprietry. For example:
Ada is an ANSI/ISO-standardized language for which
there are multiple vendors and for which you can
get a high-quality free implementation with source code.
Java is a language for which there are multiple vendors and for
which you can get a free implementation with source code;
people have started work on ISO standardization.
Eiffel is a language for which there are multiple vendors and for
which I think you can get a free implementation with source code;
there is a standard which has been developed by a concensus
process amoung the various vendors.
Sather is a language which has been developed by a University
research group and for which the source code to both
implementations is freely available, I believe.
C --- which remains a very successful competitor to C++ --- is
certainly not any more proprietry than C++ by any measure.
Which alternatives to C++ were you thinking of?
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
John Nagle
"Alf P. Steinbach" <al...@online.no> writes:
>John Nagle wrote:
>>
>> "Alf P. Steinbach" <al...@online.no> writes:
>> >John Nagle wrote:
>>
>> >are considering the heap (although the issue is pretty moot with Java).
>>
>> No, some languages have it, and some don't. C doesn't have it,
>> C++ doesn't have it
>Ok.
>> but Java has it, and Visual Basic has it.
>Would be interesting to know what you mean by that, exactly.
If you have a reference in either language, and it's not nil, you're
guaranteed that it points to a valid object of the indicated type.
Subscripts are checked, and the language knows how big arrays are,
regardless of how they are used. This is considered a major
feature of Java, and while it doesn't get talked about as much
for Visual Basic, it's a feature of that language, too, although
I wouldn't be suprised if there's some backdoor somewhere in the VB
world that lets you bypass type safety.
>> Standard Pascal
>> and Ada have it except for references to deallocated pointers.
>That's not correct. Using standard Pascal, you can write wherever you
>want in the process' address space, but it's intentionally awkward --
>to do pointer arithmetic in standard Pascal, you must use typecasting in
>the form of variant records, e.g. (assuming an integer is the same
>size as a memory address, which is part of why it's ugly!)
There is that, although you have to work hard to break the type
safety. There have been implementations, like Berkely Pascal, that
didn't let you coerce pointers that way. In Pascal, though, it
is defined as an error to do that; ref. "Standard Pascal, User
Reference Manual", by Doug Cooper, ISBN 0-393-30121-4, page 112.
He even writes "A high quality processor will detect the trick
(after all, it's an error) and disallow it." In C and C++, it's legal.
>Of course, it's much easier to this kind of thing in Ada, which is
>meant first and foremost for programming embededded (sic) systems!
Not by accident. You must explicitly include packages like
LOW_LEVEL_IO or functions like UNCHECKED_CONVERSION. It was recognized
back when Ada was being designed that there were rare occasions when
this was needed, but the syntax was designed to discourage its use and
to make it easy to find places where unsafe operations are going on.
Both Ada and Modula were designed to support embedded systems programming,
but that doesn't mean the code has to be unsafe. I once wrote the
file system and all the device drivers for an operating system in
Modula I without explicitly breaking type safety. (Admittedly
there was a major implicit violation in reading in data structures
from disk, which was accomplished via Modula I device variables.
But it was very localized; one could examine and check the operation.)
If an Ada program doesn't have certain specific keywords in it, it's
safe against clobbering memory. That was a major DoD language requirement.
In C and C++, though, unsafe operations look too much like normal
operations. Any pointer arithmetic operation is potentially unsafe.
It's hard to tell which old-style casts are safe and which are unsafe.
I think it's time to treat old-style casts as "static_cast", so that
all the unsafe ones will pop up as errors. If you really want to do
an unsafe cast, you should have to use the explicit C++ "reinterpret_cast".
>The Lisp and Prolog discussion below is the sense of your comment on
>Fortran, see end of posting. I mention this in case you consider a
>"retort" by referring to physical memory adresses or some such (which
>would probably contain a new heap of factual errors).
Huh?
>> LISP
>[has protection against memory overwrite] That's not correct. In Lisp,
>you can overwrite memory accidentally if you use SETQ.
Ah yes, the SETQ hole. Some dialects of LISP don't allow it.
I insisted it be left out of the original AutoLISP for AutoCAD,
for exactly that reason. There's an efficiency penalty for this,
but you get it back in reduced tech support calls.
>> and Prolog have it.
>Please. It's not correct. But Prolog is even more of a special case
>than Lisp. Prolog only provides assignment through Assert and Retract
>in the global database of predicates/facts. Since it only has global
>assignment memory / identifiers, there is no protection whatsoever.
Huh?
How would you put something in the database that isn't valid Prolog
data? The question is whether you can break the underlying language
model. Prolog has good protection against that, although it of course
lacks object encapsulation. Admittedly, pure Prolog isn't very
useful. Trying to do anything procedural, like dealing with a user
interface, is painful. I wrote a system in Turbo Prolog once to
advise on configuring PCs; the algorithm was easy, but handling
retry in the dialogs was very painful.
>> Modula has it, with
>That's not correct. Look up the facilities of the SYSTEM module.
As with Ada, you have to go to considerable trouble to break
through the strong typing.
>> the same exception as noted for Pascal and Ada. FORTRAN doesn't have it.
>I assume you mean the Fortran common block.
FORTRAN has been getting safer over the years, although in some
implementations you can do things like pass a constant by reference
and change the constant. There was always trouble with COMMON,
although things got better when FORTRAN compilers started using
include files. Traditionally, most FORTRAN implementations
don't check subscripts, although, unlike C, they have enough information to
do so. I'm not current in FORTRAN, though; I stopped using it years ago.
>In short, you're way off base, and seem to simply make statements about
>things you do not know much about. So I can understand that you
>want some "simpler" language than C++ is today -- it's for
>professionals who build, buy or already have the abstract support layers
>they need.
Who is this guy?
Most of the legitimate arguments in this area revolve around the
tradeoffs between type safety and efficiency, and we're now seeing this
in the Java vs C++ competition. The proponents of safe languages have
often argued that the penalty for having a safe language is low if
the compiler is smart, but compilers that will, say, hoist a subscript
check out of a loop have historically been very rare. This has
held back the use of safe languages. It will be interesting to see
how Java changes this. Unlike, say, TCL and Perl, which are inherently
inefficient, Java can potentially approach (and maybe pass) C/C++ speeds.
There may be enough competitive pressure behind Java runtime engines
to make this happen.
John Nagle
Michael Malak
In article <57kn90$q...@netlab.cs.rpi.edu>,
Steve Heller <hel...@utdallas.edu> wrote:
>
> I believe that eliminating any visible pointers is better than using
>smart pointers. The polymorphic object idiom allows this in most
>cases that are likely to occur in the real world.
>
>implementations".
What are "infrastructure class implementations"?
How do you program without pointers? (I've been genuinely curious
about this for a while.)
Suppose I have an object A whose lifetime is most of the program's
lifetime. Suppose an object B comes around whose lifetime is
relatively short compared to A's, but must be longer than the
execution of a single function and therefore must reside on the
heap and not the stack. Finally, suppose A needs to be linked
with B.
My limited knowledge tells me there are two ways: intrusive and
non-intrusive.
Intrusive: A contains a B*.
Non-intrusive: A has access to a hash-table map which maps an A*
to a B*
In either case, a pointer is used. Both could be made better by
the use of smart pointers, but you still call those "visible
pointers."
How can one avoid pointers?
--
Michael Malak Home: ma...@access.digex.net
Washington, DC Work: ma...@notes.sonix.com
Chris G. Perrott
Vadim Zeitlin wrote:
>
> In article <57ftqh$1...@netlab.cs.rpi.edu>,
> Bajo...@Perkin-Elmer.com (Andrew P. Bajorinas) wrote:
> >>
> >>]zei...@dptmaths.ens-cachan.fr (Vadim Zeitlin) wrote:
> >>
> >>]>That's why I think that even an introductory course
> >>]>on C++ should cover almost everything
> >>
> >>]programmer so far behind
>
> just begun to learn, do you?
You can do things in Pascal after one week. Maybe Pascal still has a
place as a very first introduction to programming. (At least it's
better than BASIC.)
--
Chris Perrott
Chelly Green
David Bradley wrote:
>
> da...@ugcs.caltech.edu (David A. Cuthbert) wrote:
>
> > int *a; // ptr to integer
> > const int *b; // ptr to const int
> > int * const c; // const ptr to int
> > const int * const d; // const ptr to const int
>
> Redo the above as follows
>
> int *a; // Pointer to integer
> int const* b; // Pointer to constant integer
> int * const c; // Constant pointer to integer
> int const * const d; // Constant pointer to constant
> integer
Actually, if there were any redoing, it would be:
int* a; // pointer to non-const int
int const* b; // pointer to int that can't change through this
// pointed-to int may or may not be const
etc.
> All false into place and the simple rule of const follows what it
> modifies works well.
Ahh, I thought you had just capitalized the English descriptions :-)
> But to the topic at hand. I view C++ is a powerful language that
> needs some improving, but what language doesn't.
So the "needs improving" is redundant.
> I guess the question
> I ask is what have we learned from C++ as a language and can we use
> that knowledge to create a better language?
I ask, can C++ be used to solve real problems? That is the purpose of
the language. I don't think it was meant to simply provide ideas for a
new language (not a HYPE HYPE HYPE copycat language like Java. uck.
sort of same syntax, HYPE HYPE HYPE).
> There are many things I like about C++ and I don't want to give them
> up. I'd rather move on to a language that supports the basic concepts
> held within the C++ language
Well, there is a language that supports the basic concepts in C++ - C++!
C++ is the best C++ around.
> but maybe it has a bit better syntax.
Syntax is what you see. In D&E, Bjarne talks about how the C++ is really
a textual syntax, and the underlying semantics. The syntax is far less
important, yet that's what people see (and gripe about when a little
change is made, such as removal of implicit int). Here is a quote
(Design and Evolution of C++, page 207, bottom):
"A significant use of a non-textual representation would be as a
target for code generation from higher-level languages, program
generators, direct manipulation tools, etc. It would allow such tools to
bypass the traditional C++ syntax. It might even become a tool for
migrating C++ away from some of the more contorted aspects of its
syntax. I maintain that C++'s type sustem and semantics are cleaner than
its syntax, Within C++, there is a much smaller and cleaner language
struggling to get out. An environment like the one I'm envisioning might
be a way of proving that. Providing direct support for varuious forms
for design are obvious applications."
(typos are mine)
I recommend this book to anyone who uses C++. It helps you understand
the reason for some of the reasons C++ is like it is now. Here is a link
to more information:
http://www.research.att.com/~bs/dne.html
> I think we could make some areas a little easier to understand and/or read.
This is one of the great things about the language: you can make your
own additions in the form of classes. If you want a concept to be
represented directly, then make a class that represents this concept.
You design the interface to the class, and only expose what is part of
the abstract state and behavior of this concept. It can be easy to use,
powerful, or both. It can be extensible, efficient, or whatever. You
have a choice. It can be misused, especially if not understood. This
goes for any powerful tool. But when used well, it can enable very
elegant solutions to problems.
Fergus Henderson
"Alf P. Steinbach" <al...@online.no> writes:
>> >John Nagle wrote:
>> >> - safety against overwriting memory
>>
>Would be interesting to know what you mean by that, exactly.
In languages which provide safety against overwriting memory,
if you get a "segmentation fault" or a "general protection error",
it indicates a bug in the language implementation, not in your
program.
>> Standard Pascal
>> and Ada have it except for references to deallocated pointers.
>
>That's not correct. Using standard Pascal, you can write wherever you
>want in the process' address space, but it's intentionally awkward --
>to do pointer arithmetic in standard Pascal, you must use typecasting in
>the form of variant records, e.g. (assuming an integer is the same
>size as a memory address, which is part of why it's ugly!)
Well, a Pascal implementation could check the record tag
when accessing variant records. A Pascal implementation that
did this would have safety against overwriting memory, except
for references to deallocated pointers. I don't know what the
Pascal standard says about whether implementations are required
to do such checks or not.
Ada is very careful to distinguish bounded errors from unbounded
errors. Overwriting random memory is an unbounded error:
it may cause other parts of your program to fail in mysterious
or seemingly random ways at some later point in the program execution.
In C++, there are a lot of things that cause "undefined behaviour",
and these are all unbounded errors.
>In Lisp, you can overwrite memory accidentally if you use SETQ.
Yes, but the Lisp system won't crash if you do so.
Using SETQ results in bounded errors, not unbounded ones.
>In short, you're way off base
I have to say I disagree -- I think John Nagle's comments are quite
relevent. Lack of safety against overwriting memory is a very real
problem that affects C++ programmers.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the
pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S.
Garp.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Wright
To me the power of C++ is that it is an enabling language, however with
power comes responsibility.
If you want to knock out a flashy (but possibly shallow) solution
tomorrow, choose something else (unless you are lucky enough to have a
project ideally suited to one of the application generators).
If you need to build a fast, robust, extensible (and possibly portable)
system and are prepared to study the language before launching into
coding, C++ is a good choice IMHO.
Regards
David Wright "Language shapes the way we think,
Elgol,Isle of Skye,Scotland and determines what we can think about."
dwr...@ealaghol.demon.co.uk - B.L Whorf
Jon Bell
Michael Malak <ma...@access.digex.net> wrote:
>In article <57kn48$p...@netlab.cs.rpi.edu>,
>Bjarne Stroustrup <b...@research.att.com> wrote:
>>
>>However, many (most?) people deal with many application areas and
>>many of those prefer a multi-paradigm language like C++ over a set
>>of smaller and more specialized languages.
>
>the Microsoft world is to use both Visual Basic and Visual C++ in
>the same application. [...]
"the Microsoft world" != "the world". :-)
--
Jon Bell <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
[for beginner's Usenet info, see http://web.presby.edu/~jtbell/usenet/ ]
David A. Cuthbert
Chelly Green <che...@eden.com> wrote:
>David Bradley wrote:
>> Redo the above as follows
>>
>> int *a; // Pointer to integer
>> int const* b; // Pointer to constant integer
>> int * const c; // Constant pointer to integer
>> int const * const d; // Constant pointer to constant
>> integer
>
>Actually, if there were any redoing, it would be:
>
> int* a; // pointer to non-const int
> int const* b; // pointer to int that can't change through this
> // pointed-to int may or may not be const
> etc.
>
>> All false into place and the simple rule of const follows what it
>> modifies works well.
As I said in my earlier post, this isn't an intuitive construction. I
even thought of a worse case here:
int const * a, b;
Ok, so it's pretty clear what a is. What is b? (I don't have access
to a compiler until I return home, but I'm guessing that it's int
const. So const modifies what's to its left, * modifies what is to
its right, but const can also modify what is to its right if nothing
is to its left, but this is an exception to the rule and we shouldn't
use it -- even though it is grammatically correct.)
This is precisely what I was complaining about earlier. I shouldn't
have to look at the DWP or toss the code through a compiler to figure
out what something as simple as this is getting at. Yeah,
yeah... I'm well aware of typedef, that this is syntax, that the
majority of the readers don't think that syntax is important, etc.
But from the perspective of someone who programs as a supplement to
his work, this is a readability nightmare.
>I ask, can C++ be used to solve real problems? That is the purpose of
>the language. I don't think it was meant to simply provide ideas for a
>new language
Yes, it can. But it is often a non-optimum tool for many problems. I
don't expect it to be *the* optimum tool for any problem... but it can
be painfully non-optimum in a number of cases. It's like yanking out
a treestump by trying the stump to your car; it's much easier to get a
tree removal crane.
>Syntax is what you see. In D&E, Bjarne talks about how the C++ is really
>a textual syntax, and the underlying semantics. The syntax is far less
>important, yet that's what people see
I wholeheartedly agree that the underlying semantics are much more
important than the syntax! However, this is being used as an excuse
to ignore syntactical issues.
[D&E p. 207]
> "A significant use of a non-textual representation would be as a
>target for code generation from higher-level languages, program
>generators, direct manipulation tools, etc. It would allow such tools to
>bypass the traditional C++ syntax. It might even become a tool for
>migrating C++ away from some of the more contorted aspects of its
>syntax."
Where are these tools? I have a feeling that they are beyond my
budgetary limits for most of the projects I work on (in my experience,
it's easier to ask for a single $1000 development product rather than
a $700 product and a $300 one).
I hesitate to say it, but I'm under the impression that what is needed
is some sort of standardized superset(s) to C++. For example, I would
like to be able to write a program that puts up some sort of interface
on a GUI without modifying a single line regardless of the target
platform (though it might require the use of an additional support
program; e.g., such a program might require that the user run a window
manager on XWindows, or even a specific window manager). Before
anyone claims that this is impossible or prohibitively expensive, I
point out that HTML is already such a language (though, of course,
much more limited in functionality).
>> I think we could make some areas a little easier to understand and/or read.
>
>This is one of the great things about the language: you can make your
>own additions in the form of classes. If you want a concept to be
>represented directly, then make a class that represents this concept.
>You design the interface to the class, and only expose what is part of
>the abstract state and behavior of this concept. It can be easy to use,
>powerful, or both. It can be extensible, efficient, or whatever. You
>have a choice. It can be misused, especially if not understood.
And this is one of the bad things about the language (or is it OOP in
general? I haven't worked with other OOP languages enough to form an
opinion). If you misuse it, even in a slight way, it is possible (and
probable) to get burned in a bad way later on.
>This goes for any powerful tool. But when used well, it can enable very
>elegant solutions to problems.
Agreed. Since programming in C++, I have created a number of elegant
solutions to the various problems I have faced. Even so, I can forsee
a number of improvements.
--
David A. Cuthbert Graduate Student, Electrical and Computer Engineering
da...@andrew.cmu.edu Carnegie Mellon University
Steve Heller
na...@netcom.com (John Nagle) wrote:
>Subscripts are checked, and the language knows how big arrays are,
>regardless of how they are used. This is considered a major
>feature of Java, and while it doesn't get talked about as much
>for Visual Basic, it's a feature of that language, too, although
>I wouldn't be suprised if there's some backdoor somewhere in the VB
>world that lets you bypass type safety.
Of course, it's easy to write your own (or use someone else's)
bounds-checked-array template in C++ which provides the same features
for the user.
> In C and C++, though, unsafe operations look too much like normal
>operations. Any pointer arithmetic operation is potentially unsafe.
>It's hard to tell which old-style casts are safe and which are unsafe.
>I think it's time to treat old-style casts as "static_cast", so that
>all the unsafe ones will pop up as errors. If you really want to do
>an unsafe cast, you should have to use the explicit C++ "reinterpret_cast".
That's why I don't teach my students to use pointer arithmetic
(other than when accessing array elements inside class
implementations) or casts.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
Steve Heller
Jesse Liberty <jlib...@libertyassociates.com> wrote:
>Well, I know you and I disagree about this one. I've taught C++ to a
>few thousand students; some on line and some in small intensive
>seminars. In my experience a four day seminar can cover a lot of
>ground with bright, motivated students.
>In my four day intensive course for C programmers, we cover classes,
>inheritance, polymorphism, abstract data types, streams, pointers,
>references, encapsulation, private inheritance, containment,
>delegation, multiple inheritance, virtual inheritance, templates,
>exceptions, memory-management and a variety of related topics (not in
>that order). The four day course for non-programmers must cover more
>of the fundamentals; so we get to fewer of the very advanced topics,
>but even there we cover the vast majority of what you can do with C++.
This is a survey course you're referring to, not an actual course in
the C++ language. In other words, I would say that you have not taught
those students C++: you have taught them *about* C++. I've been to
some of those four-day courses in programming topics such as OLE
controls, and I can tell you that when you get home you don't know
the material covered in any meaningful sense. I'll agree that survey
courses have their place, but in my opinion it is quite misleading to
say that they constitute "teaching C++".
By the way, although I haven't taught a few thousand students, I
have taught a total of over 100 in both industry and academia, and my
teaching feedback has been quite positive (e.g., "This is the only
time I've ever felt that I could recommend a teacher for a teaching
excellence award.").
>The feedback I've received, (I ask for specific feedback on the
>material covered each day of the course, then again at the end, and
>usually follow up some weeks later) is that this material CAN be
>learned in four days if (and perhaps only if) the students are
>sufficiently motivated to follow up with exercises and perhaps to
>integrate what they've learned into their work.
In other words, they haven't learned the material during the course,
but can do so after it's over. I won't deny that this approach can
work with some students, but it's not the same as teaching them the
material during the course.
Please note that I'm not claiming that I have an approach that can
actually teach these concepts in four days. I don't believe it's
possible to do so.
>The point is not to tout the course or my particular methods but only
>to tell you that experiences differ; some folks like to learn the key
>concepts and drill on them, integrate them into their thinking and
>then move on. Others like to see more of the sweep of the language,
>and will then return to the parts of most interest to practice and
>internalize. Much depends on the students, their experience,
>motivation and needs.
I agree that there are different learning styles. I also
wholeheartedly with your last sentence. For experienced programmers
who need to learn a new language, it's possible to go faster than with
novices. However, that advantage isn't as great as some might think
when we're talking about moving from procedural to OO programming; in
that case, many experienced programmers have quite a difficult time
making the transition, no matter how the OO language itself is taught.
Steve Heller
ma...@access.digex.net (Michael Malak) wrote:
>In article <57kn90$q...@netlab.cs.rpi.edu>,
>Steve Heller <hel...@utdallas.edu> wrote:
>>
>> I believe that eliminating any visible pointers is better than using
>>smart pointers. The polymorphic object idiom allows this in most
>>cases that are likely to occur in the real world.
>>
>>In fact, I tell my
>>students "don't use pointers except in infrastrucure class
>>implementations".
>What are "infrastructure class implementations"?
The implementation of classes that are written by library designers
rather than by application programmers.
>How do you program without pointers? (I've been genuinely curious
>about this for a while.)
>Suppose I have an object A whose lifetime is most of the program's
>lifetime. Suppose an object B comes around whose lifetime is
>relatively short compared to A's, but must be longer than the
>execution of a single function and therefore must reside on the
>heap and not the stack. Finally, suppose A needs to be linked
>with B.
>My limited knowledge tells me there are two ways: intrusive and
>non-intrusive.
>Intrusive: A contains a B*.
>Non-intrusive: A has access to a hash-table map which maps an A*
> to a B*
>In either case, a pointer is used. Both could be made better by
>the use of smart pointers, but you still call those "visible
>pointers."
>How can one avoid pointers?
In the case you're discussing, you can't avoid using pointers.
However, what you can do is to hide the B* inside the A class and have
the A class manage it, rather than having the user of A see and manage
the pointer. That follows my rule "don't use pointers except in
infrastrucure class implementations".
Alf P. Steinbach
In this posting, I'll try to get back to original issue, namely John's
concern about pointer arithmetic in C++ making it an unsafe language.
After that, a summary so far.
In an earlier article in this thread (se references), John Nagle wrote:
> I'd argue that the next generation of C++ should be syntactically
> incompatible, but it should be possible to machine-convert existing C++
> and C to the new language. This allows fixing some of the big syntactic
> problems. But those aren't the real issue; it's the underlying memory
> model that's the killer. Pointer arithmetic needs to go.
Any language that allows defining an array type with assignment also
allows you to build dynamic memory management (dynamic allocation and
indirection, with indices taking the place of pointers) on top
of such arrays. Perhaps I should reiterate: array indexing has the
exact same problems as pointer dereferencing, and provides you with a
means to implement dynamic memory management. (This has little to do
with array/pointer confusion in C/C++, it also applies to Pascal, say
-- when I tought fundamental programming at Bodoe College, I
introduced linked data structures using arrays instead of pointers.)
So the problems of pointer arithmetic can't be abolished without also
abolishing arrays. I hope you see that abolishing arrays is absurd
within the context of conventional languages like C++.
Summary of JN's last posting with *much* elided, and three comments.
>JN - safety against overwriting memory
>
>APS None of the languages have that. It's an operating system issue if you
> are considering the heap (although the issue is pretty moot with Java).
>
>JN No, some languages have it, and some don't. C doesn't have it,
> C++ doesn't have it
>
>APS Ok.
>JN but Java has it, and Visual Basic has it.
>
>APS Would be interesting to know what you mean by that, exactly.
>
>JN If you have a reference in either language, and it's not nil, you're
> guaranteed that it points to a valid object of the indicated type.
>JN Standard Pascal
> and Ada have it except for references to deallocated pointers.
>
>APS That's not correct. Using standard Pascal, you can write wherever you
> want in the process' address space, but it's intentionally awkward.
>
>JN There is that, although you have to work hard to break the type
> safety.
>APS Of course, it's much easier to this kind of thing in Ada, which is
> meant first and foremost for programming embededded (sic) systems!
>
>JN Not by accident.
> ...
> In C and C++, though, unsafe operations look too much like normal
> operations.
>JN LISP
>APS [has protection against memory overwrite] That's not correct. In Lisp,
> you can overwrite memory accidentally if you use SETQ.
>
>JN Ah yes, the SETQ hole. Some dialects of LISP don't allow it.
>JN and Prolog have it.
>
>APS Please. It's not correct.
>JN Huh?
> How would you put something in the database that isn't valid Prolog
> data?
I wouldn't. But you can access anything in the database, and you
can change (remove or add to) anything in the database. Consider a
set of facts modeling a family tree. Maintaining such a linked
structure
in the database is completely analogous to maintaining a linked
structure
of dynamically allocated memory. The possibilities of bugs are
the same, although the physical representation is quite different.
>JN The question is whether you can break the underlying language
> model.
Hm. Then I must have misunderstood you when you were proposing
abolishing pointer arithmetic from C++.
>JN Modula has it, with
>APS That's not correct. Look up the facilities of the SYSTEM module.
>
>JN As with Ada, you have to go to considerable trouble to break
> through the strong typing.
>JN the same exception as noted for Pascal and Ada. FORTRAN doesn't have it.
>APS I assume you mean the Fortran common block.
>
>JN FORTRAN has been getting safer over the years, although in some
> implementations you can do things like pass a constant by reference
> and change the constant. There was always trouble with COMMON,
> although things got better when FORTRAN compilers started using
> include files. Traditionally, most FORTRAN implementations
> don't check subscripts, although, unlike C, they have enough information to
> do so. I'm not current in FORTRAN, though; I stopped using it years ago.
>APS In short, you're way off base, and seem to simply make statements about
> things you do not know much about. So I can understand that you
> want some "simpler" language than C++ is today -- it's for
> professionals who build, buy or already have the abstract support layers
> they need.
>
>JN Who is this guy?
With respect to this thread, one who points out errors... :-)
- Alf
Fergus Henderson
"Alf P. Steinbach" <al...@online.no> writes:
>Any language that allows defining an array type with assignment also
>allows you to build dynamic memory management (dynamic allocation and
>indirection, with indices taking the place of pointers) on top
>of such arrays.
[...]
>Perhaps I should reiterate: array indexing has the
>exact same problems as pointer dereferencing,
You are wrong, on both theoretical and practical grounds.
First, if array indexing is checked for out-of-bounds errors, then
even if you implement dynamic memory management using arrays, you
still can't do anything that would cause undefined behaviour.
This is in great contrast to pointer errors, which can overwrite
the stack, overwrite the heap management areas (free list etc.),
can cause your program to start trying to execute random data rather
than instructions, and which in general can cause an unbounded
amount of havoc etc.
Second, unless the language also has some means of doing unsafe
type punning, your dynamic memory management scheme will need to
use a different array for every different type. That further limits
the damage you can do. You won't be able to cause any run-time type
errors.
Third, John Nagle wasn't complaining about pointers or dynamic
memory management as such, which can both be made quite safe
(see e.g. Java). He was complaining about pointer arithmetic.
In a language like Java which has dynamic memory management
and garbage collection, no-one in their right mind re-implements
dynamic memory management using arrays, so the theoretical
problems you raise just simply don't occur in practice.
Now in theory you could check pointer arithmetic/dereferencing too, but
that has a problem that checking of array indexing doesn't have: it's
basically impossible to do it efficiently with current technology.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Valentin Bonnard
David Bradley wrote:
> But to the topic at hand. I view C++ is a powerful language that
> I ask is what have we learned from C++ as a language and can we use
> that knowledge to create a better language?
>
> There are many things I like about C++ and I don't want to give them
> up. I'd rather move on to a language that supports the basic concepts
> think we could make some areas a little easier to understand and/or
> read.
I don't think so. I 'know' Ada 83, Ada 95, Basic, C, C++, Caml, Pascal
(precisely TurboPascal, which has some OO possibillities) and Prolog
where 'know' can mean 'has some basic knowledge' or 'very good
understanding' (or anything).
When I learnt these languages, I had sometimes been surprised by the
predecence rules or by some other oddities of the syntax but these
problems were boring at worst. Some concepts (semantic problems), OTOH
aren't trivial to understand deeply (to understand why they are like
they are). This can include OOP, genericity, but not syntax.
C++ is not a simple language, but IMO the complexity mainly comes from
the concepts supported (encapsulation, ction and dtion, polymorphism,
static typing, genericity, overload), not from the syntax (which is
mainly inherited from C).
For example I think 'X * Y;' is never (ok, not often) ambiguous for a
human reader because:
- type name are usually easy to distinguish from variable name
(traling _t or well-known name or ...)
- one never multiply things and to throw the result away
OTOH it's ambiguous for the compiler.
Strange problems are sometimes encountered in real programs like the
well-known:
TypeWithDefaultCtor my_variable ();
vector<vector<int>> my_int_matrix;
TypeWithDefaultCtor::TypeWithDefaultCtor ()
{
TypeWithDefaultCtor (3); // only call annother ctor to do the work
}
But I think only beginners can do these mistakes (since one is a
beginner until he had solved one of these problems ;-).
It's really more difficult to understand why (1) is well-formed
and not (2) than to understand the syntax in itself in the following:
int** pi;
const int*const* pcpci = π // (1)
const int** ppci = π // (2)
vs:
pi: pointer to int; // syntax in some new C++ (D++ ?)
pcpci: pointer to const pointer to const int = pi;
ppci: pointer to pointer to const int = pi;
I think the later, while more explicit, is also far too verbose and
doesn't make the cv-implicit cast rules any easier to understand.
So my question is: what would you want:
- to be added to C++ ?
- to be removed from C++ ?
--
Valentin Bonnard
mailto:bonn...@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
Valentin Bonnard
na...@netcom.com (John Nagle) wrote:
>Subscripts are checked, and the language knows how big arrays are,
>regardless of how they are used. This is considered a major
>feature of Java, and while it doesn't get talked about as much
>for Visual Basic, it's a feature of that language, too, although
>I wouldn't be suprised if there's some backdoor somewhere in the VB
>world that lets you bypass type safety.
>
>It's hard to tell which old-style casts are safe and which are
>unsafe.
But any operations can be unsafe !
a = b + c; // if b and c aren't unsigned, they may overflow
a = vec[i]; // i can perhaps be greater than the size of vec
a = *(vec+i); // ditto
Of course they look like normal operations in any languages.
So perhaps you mean only things specific to C++. Pointer arithmetic
can be understood as a way to replace vec[i] with the shorter p in the
code. Well, we can do pointer arithmetic on any object because _every_
object is an array in C++ (with 1 element).
For cast you should use the new cast syntax (which doesn't mean that
you won't crash in a pogram which use it).
Any language suitable for system programming needs some sort of unsafe
casts anyway.
Bjarne Stroustrup
f...@mundook.cs.mu.OZ.AU (Fergus Henderson) writes
>
> b...@research.att.com (Bjarne Stroustrup) writes:
>
> >The alternative to C++ is proprietary languages.
>
> Why do you say that? Most of the languages that are
> competitors to C++ are not proprietry.
I think you cut my note too drastically. My comments were made in response
to comments specifically related to Visual Basic and mentioning Delphi and
Java. I don't think there should be any controversy over those languages
being proprietary. However, let me comment briefly on the languages you
mention.
> For example:
>
> Ada is an ANSI/ISO-standardized language for which
> there are multiple vendors and for which you can
> get a high-quality free implementation with source code.
Ada was designed for the US department of defense by contractors who
had to meet stringent DoD specifications. The language was trademarked,
some people/organizations were legally oblidged to use it, and the Ada85
ANSI standard was pushed through by a special set of rules allowing the
US government to bypass the usual process.
After the initial failure of Ada to gain the stature expected of it,
the DoD has taken a more enlightened approach.
Ada wasn't mentioned in the posting I commented on, isn't (to my knowledge)
used in the application area discussed, and I wasn't thinking of it.
> Java is a language for which there are multiple vendors and for
> which you can get a free implementation with source code;
> people have started work on ISO standardization.
Java was produced for Sun and for the benefit of Sun. Note the appearence
of Java-based Sun hardware. The liscense for using Java is the most Draconian
I have ever seen. It is doubtful whether the Sun strategy can succeed - we
will know by watching Sun's stockprice and marketshare - and I am under the
impression that Sun has already lost control of Java (to Microsoft).
Maybe there will be an official standard, and maybe that standard will
be adhered to (Remember the Pascal stadards?), but it will be years before
we know. I think that my fear that Java/J++ will be a language subject
to gross manipulation by platform suppliers for the purpose of locking
in users and increasing supplier revenues is not unfounded. I expect
dramatic changes to the Java language itself and wide variations in the
libraries. If I'm wrong, so much the better for Java programmers.
It will be interesting to see how Sun's traditional competitors in the
hardware arena responds to Sun's introduction of Java-specific "net
computers." One obvious strategy would be to back altenative languages
or incompatible versions of Java (and see if Sun can make a lawsuit stick).
> Eiffel is a language for which there are multiple vendors and for
> which I think you can get a free implementation with source code;
> there is a standard which has been developed by a concensus
> process amoung the various vendors.
I have no idea whether Nice is a genuinely open standards body or a tame
organization controlled by ISE or some other small group of vendors.
Nor am I particularly interested. Eiffel started out as a proprietary
language and its vendors and users will of course organize themselves
in any way they consider most adventageous. By "standards" I tend to
think of the standards produced by officially accredited standards bodies.
Anyway, I wasn't thinking of Eiffel in the context of that posting.
> Sather is a language which has been developed by a University
> research group and for which the source code to both
> implementations is freely available, I believe.
I wasn't thinking of Sather in that context. I am not aware that Sather
is an alternative to anything outside research environments.
> C --- which remains a very successful competitor to C++ --- is
> certainly not any more proprietry than C++ by any measure.
C is definitely an alternative. Because C is close to a subset of C++,
it is an inferior alternative wherever C++ implementations and tools
are available, but that is just my opinion. Others think differently.
> Which alternatives to C++ were you thinking of?
In the posting you cut a single line from I said:
Furthermore, the major suppliers of hardware or software have
consistently favored alternative - and usually proprietary
- languages over C++. Witness: MS/Basic, Apple/ObjectPascal,
Borland/Pascal, Sun/Modula3/Java, DEC/Trellis/Modula3,
IBM/ObjectiveC/Smalltalk. For a supplier, there are significant
benefits from having users tied in to a language controlled be
the supplier.
I think I made a creditable attempt to be precise and specify the context
and scope of my statements.
I do think we are heading towards a period of proprietary "standards"
that leaves the users with less choice than we have becomed acustomed
to (primarily thanks to Unix and C). As a user, I do not like that.
However, it may be the normal state of affairs in a rapidly developing
field subject to little effective government regulation/protection/interference.
Fergus Henderson
b...@research.att.com (Bjarne Stroustrup) writes:
>f...@mundook.cs.mu.OZ.AU (Fergus Henderson) writes
>
> > b...@research.att.com (Bjarne Stroustrup) writes:
> >
> > >The alternative to C++ is proprietary languages.
> >
> > Why do you say that? Most of the languages that are
> > competitors to C++ are not proprietry.
>
>I think you cut my note too drastically. My comments were made in response
>to comments specifically related to Visual Basic and mentioning Delphi and
>Java. I don't think there should be any controversy over those languages
>being proprietary.
Fair enough -- the statement makes more sense if understood to be
talking
about those particular alternatives. I didn't read it that way, though,
which is why I asked what you meant.
Certainly there's no doubt that Visual Basic and Delphi are proprietry.
While Java is proprietry in some senses, I don't think it has the same
disadvantages that VB and Delphi have in this respect.
As for why I didn't quote the rest of your post -- well, that was simply
because I agreed with it and had nothing to add.
> > Ada is an ANSI/ISO-standardized language for which
> > there are multiple vendors and for which you can
> > get a high-quality free implementation with source code.
>
>Ada was designed for the US department of defense by contractors who
>had to meet stringent DoD specifications. The language was trademarked,
>some people/organizations were legally oblidged to use it, and the Ada85
>ANSI standard was pushed through by a special set of rules allowing the
>US government to bypass the usual process.
>
>After the initial failure of Ada to gain the stature expected of it,
>the DoD has taken a more enlightened approach.
OK, so Ada was once effectively proprietry, but that isn't the case any
longer. Well, fair enough, but I think we should be more concerned
with the present than the past. After all, C++ was once a proprietry
language in some senses (not *too* far a cry from the situation with
Java today).
> > Java is a language for which there are multiple vendors and for
> > which you can get a free implementation with source code;
> > people have started work on ISO standardization.
>
>Java was produced for Sun and for the benefit of Sun.
The truth but not the whole truth. Sure, Sun will benefit, and that is
a big part of the reason it was produced. But I have little doubt that
Java was also produced in some part for the personal benefit that it's
designers would accrue; in a large part to solve some particular
problems that the designers had found in other languages (such as C++);
and even in some part for the general benefit to society as a whole.
>The license for using Java is the most Draconian I have ever seen.
The Sun Java source license is indeed Draconian, but I don't think that
is particularly relevant anymore, since you don't need any Sun licences
to use Java.
>It is doubtful whether the Sun strategy can succeed - we
>will know by watching Sun's stockprice and marketshare - and I am under the
>impression that Sun has already lost control of Java (to Microsoft).
I think it is already true that Sun no longer has complete control of
Java,
though I think they certainly have more control than Microsoft. The
fact
that Java has so many implementations already limits what Sun can do.
>Maybe there will be an official standard, and maybe that standard will
>be adhered to (Remember the Pascal stadards?), but it will be years before
>we know.
Nevertheless, if you program according to the current Java
specification, with a few caveats (which are all in all probably much
less severe than the many caveats in the C++ draft standard regarding
implementation-defined, unspecified, and undefined behaviour)
then it is pretty certain that in years to come there will be many
Java implementations that will be able to use for your Java programs.
>I think that my fear that Java/J++ will be a language subject
>to gross manipulation by platform suppliers for the purpose of locking
>in users and increasing supplier revenues is not unfounded. I expect
>dramatic changes to the Java language itself and wide variations in the
>libraries. If I'm wrong, so much the better for Java programmers.
I agree that these fears are not unjustified. However, Java
programmers need not worry *if* they are careful to ensure that they do
not let themselves get locked in to any particular vendor.
I too expect significant changes to the Java language, but I expect
that these changes will all be backwards compatible -- and for the
better.
>It will be interesting to see how Sun's traditional competitors in the
>hardware arena responds to Sun's introduction of Java-specific "net
>computers." One obvious strategy would be to back altenative languages
>or incompatible versions of Java (and see if Sun can make a lawsuit stick).
To reiterate, certainly Java programmers need to be careful to avoid
getting locked in to any particular vendor by relying on non-standard
or incompatible features of some particular Java implementation.
However, I think the careful Java programmer who avoids any such
features has little to fear from either Microsoft or Sun. Should
worst come to worst, even if Microsoft *and* Sun *and* Borland all make
versions of Java that are not backwards compatible, there will still be
free implementations of Java as defined by the Java 1.0 specification
available with source code.
P.S. Regarding the subject line: "Do you really like C++?" -- yes, I
do.
It has its drawbacks, and for many applications there are alternatives
such as Java that would be better, but C++ can be a *very* powerful
language, and there are some things you can do in C++ that would be
difficult or even just about impossible in almost any other language.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the
pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S.
Garp.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Fergus Henderson
Valentin Bonnard <bonn...@pratique.fr> writes:
>na...@netcom.com (John Nagle) wrote:
>>Subscripts are checked, and the language knows how big arrays are,
>>regardless of how they are used. This is considered a major
>>feature of Java [...]
>>
>> In C and C++, though, unsafe operations look too much like normal
>>operations. Any pointer arithmetic operation is potentially unsafe.
>>It's hard to tell which old-style casts are safe and which are
>>unsafe.
>
>But any operations can be unsafe !
No, most operations are not unsafe in the sense that unchecked casts
or unchecked pointer arithmetic/dereferencing are.
>a = b + c; // if b and c aren't unsigned, they may overflow
>a = vec[i]; // i can perhaps be greater than the size of vec
>a = *(vec+i); // ditto
The difference between C/C++ and Java here is that in C/C++, you get
undefined behaviour, whereas in Java you get an exception thrown.
So although those operations may fail in Java, the failure is detected
at runtime, effect is localized, the consequences of the error are
bounded, and indeed the behaviour is in fact perfectly well-defined.
Hence they are not nearly as unsafe as the C/C++ equivalents.
Kent Tong
f...@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
>Valentin Bonnard <bonn...@pratique.fr> writes:
>
>>But any operations can be unsafe !
>
>No, most operations are not unsafe in the sense that unchecked casts
>or unchecked pointer arithmetic/dereferencing are.
>
>>a = b + c; // if b and c aren't unsigned, they may overflow
>>a = vec[i]; // i can perhaps be greater than the size of vec
>>a = *(vec+i); // ditto
>
>The difference between C/C++ and Java here is that in C/C++, you get
>undefined behaviour, whereas in Java you get an exception thrown.
I believe regarding "a = b+c" Java is not much different
from C++ in that it will allow the overflow. But, after
all, this is indeed a defined behavior, no matter you
regard it as unsafe or not.
---
Kent Tong
v3 is out!!!
Freeman Installer ==> http://www.netnet.net/users/freeman/
David Chatterton
Thomas Breuel wrote:
> Sun's license for their Java implementation is somewhat strict for
> software that is distributed freely, but let's not forget that it is
> distributed freely and versions of it have been ported and made freely
> available for platforms such as Linux. This strikes me as a lot less
> "draconian" than the original AT&T C++ translator, which was never
> freely available.
>
Well explain that to the Linux user's who could not obtain Java due to
license restrictions for a couple of months this year? Sun could be far
more relaxed with their licensing and still maintain some control over
the language, especially as their current scheme does not seem to be
working. It's a pity Java couldn't exist like Linux :(
David
--
David Chatterton (61-3) 9882 8211 (Tel)
R&D Software Engineer (61-3) 9882 8030 (Fax)
Performance Tools Group ch...@engr.sgi.com
Silicon Graphics Pty.Ltd., 357 Camberwell Rd, Melbourne, Australia
Philip Walden
Thomas Breuel wrote:
>
> b...@research.att.com (Bjarne Stroustrup) writes:
> > I think that my fear that Java/J++ will be a language subject
> > to gross manipulation by platform suppliers for the purpose of locking
> > in users and increasing supplier revenues is not unfounded. I expect
> > dramatic changes to the Java language itself and wide variations in the
> > libraries. If I'm wrong, so much the better for Java programmers.
>
> for Java implementations. On Windows, you are going to get ActiveX
> support. On UNIX, you are going to get POSIX and X11 specific
> functionality. But the fact remains that Java provides a large common
> core of functionality that those people who want to write platform
> independent code can take advantage of. That core includes platform
> independent APIs for facilities like GUIs, databases, multimedia, 3D
> graphics, threads, IPC, garbage collection, sockets, etc.
>
> Compare that to C++, where none of those facilities are standardized,
> and where programmers are placed completely at the mercy of the
> operating system vendor for anything more than very basic I/O
> functionality. Furthermore, C++ name mangling also effectively
> locks users into a single compiler vendor on many platforms.
A while back in another thread, proprietary C++ name mangling was
described to me as a benefit to protect me from mixing mutually
incompatible abi's. The abi's were incompatible as each C++ vendor
attempts to optimize for their machine/market.
Personally, I'd prefer the standardization
--
--------------------------------------------------------------------------
Philip Walden
Hewlett Packard
Product Generation Information Systems
1501 Page Mill Road, M/S 4U-6
Palo Alto, CA 94304
(415) 857-3899 FAX (415) 857-8234
http://www.pgis.hp.com/~pwalden
mailto:phil_...@hp.com
--------------------------------------------------------------------------
Friedrich Knauss
In article <57evjm$q...@netlab.cs.rpi.edu>,
Steve Heller <hel...@utdallas.edu> wrote:
> The main result of such a course will be to leave the novice
>give up programming entirely. Without a solid foundation in the most
>fundamental constructs of the language, it's not possible to learn the
>more complex aspects.
While I understand the desire to teach constructs, I think the
biggest learning hurdle is the OOD part. I'd like to see a C++
class which spent the first week only using CRC cards. Once the
OOD concepts have been learned, understanding the language
constructs which support those concepts becomes much simpler.
I know Bjarne suggests that C++ be learned incrementally, "as a
better C". As much as I respect his development of the
language, I must disagree with him on this. A lot of the things
that make C++ more powerful also make it more abuseable (is that
a word?). This is akin to giving a race car to a teenager who
has just aquired his drivers license.
Having dealt with a lot of code written by engineers at various
levels of development, not least of all my own, it is apparent
that the language constructs are much more easily learned than
their proper application. I'm not trying to imply that you
teach improper use of the fundamentals, but rather that learning
their proper use takes orders of magnitude more time, and in the
interim a whole lot of really painful code can be generated.
--
-- fri...@qualcomm.com
-- Pain is temporary, glory is forever.
Thant Tessman
Bjarne Stroustrup wrote:
> [...] The fact that hundreds of thousands of presumably
> intelligent programmers have adopted a language that never
> was the easiest to learn is significant.
>
> It wouldn't have been significant had C++ gained that user
> population through extraordinary marketing or through a captive
> (corporate or governmental) audience. However, C++ usage became
> significant while its marketing dollars were minute compared to
> what was spent on other languages and systems. [...]
C++ is successful solely because it is an extension of C. The
decision to extend C was a marketing decision. And the decision
to use C++ when it first became available was a marketing decision
based on the (faulty) assumption that C++ was the most effective
way to leverage off of the heavy investment people had already made
in C. And nowdays the decision to use C++ is a marketing decision
based on the heavy investment people have already made in C++.
C++ is the epitome of successful marketing.
-thant
--
Thant Tessman <th...@shoreline-studios.com>
http://www.shoreline-studios.com
Quan Liang
Happen to see you guys discussing this topic.
I started to learn "C++ from Ground" (sorry never took a language course).
After went through, picked one C book and then Java, then Visual Basic
quickly, but with much effort. What I learnt finally is just lost in
confusion of OOP.
Since I couldn't understand OOP and really didn't want to read further
books about the OOP. What I did is to remove all words related to the OOP,
just find what the problem the languages want to do and how they do it. The
result is the learning task become quite easy. I doubt whether many book
authors are also lost in OOP when writing books.
I like C++ (it's beautiful in feeling and powerful) and like Java
(beautiful too and easy) but I don't want to know OOP.
Quan Liang
Programmer
Philip C Plumlee
Quan Liang wrote:
>
> Happen to see you guys discussing this topic.
> I started to learn "C++ from Ground" (sorry never took a language course).
> After went through, picked one C book and then Java, then Visual Basic
> quickly, but with much effort. What I learnt finally is just lost in
> confusion of OOP.
>
> Since I couldn't understand OOP and really didn't want to read further
> books about the OOP. What I did is to remove all words related to the OOP,
> just find what the problem the languages want to do and how they do it. The
> result is the learning task become quite easy. I doubt whether many book
> authors are also lost in OOP when writing books.
>
> I like C++ (it's beautiful in feeling and powerful) and like Java
> (beautiful too and easy) but I don't want to know OOP.
You know OOP; it is the beautiful, powerful and easy feeling you get.
The textbooks' methods of DESCRIBING OOP absolutely without exception
suck. But make OOP easy in a language, and the better code you write,
the more Object Oriented it gets.
Thant Tessman <th...@shoreline-studios.com>
> C++ is successful solely because it is an extension of C. The
> decision to extend C was a marketing decision. And the decision
> to use C++ when it first became available was a marketing decision
> based on the (faulty) assumption that C++ was the most effective
> way to leverage off of the heavy investment people had already made
> in C. And nowdays the decision to use C++ is a marketing decision
> based on the heavy investment people have already made in C++.
>
> C++ is the epitome of successful marketing.
Heavy investment? In a compiler that fits on one floppy disk which you
can usually get for free?
Marketing decisions result in systems like ActiveX, COBOL and dBase. At
any point in the Computer Age one language is better than all the rest,
and C was it from the moment K&R smote the ground with their staff and
it sprang forth. Marketing decisions (successful ones) result in tons of
money. Does Bjarne Stoustrup have 20 billion dollars in stock options?
Keeping this thread on the subject, yes I like C++. And C++ likes me
very very much.
Philip
================================================================
Ashley, Iris & Philip
Philip's Windows & C++ resume: http://users.deltanet.com/~tegan/
Ell
Friedrich Knauss (fkn...@qualcomm.com) wrote:
: While I understand the desire to teach constructs, I think the
: biggest learning hurdle is the OOD part. I'd like to see a C++
: class which spent the first week only using CRC cards. Once the
: OOD concepts have been learned, understanding the language
: constructs which support those concepts becomes much simpler.
: I know Bjarne suggests that C++ be learned incrementally, "as a
: better C". As much as I respect his development of the
: language, I must disagree with him on this. A lot of the things
: that make C++ more powerful also make it more abuseable (is that
: a word?). This is akin to giving a race car to a teenager who
: has just aquired his drivers license.
In his book Design and Evolution of C++, and elsewhere, Stroustrup, says
that one of the keys to using C++ in a good OO ways is to learn good OO
analysis in general. And that good OO large scaling of C++ projects is
based on progressive development in large-scale, C++, OO architectural
practices, and C++ compiler/IDE practices.
Elliott
Igor Siemienowicz
Philip Walden wrote:
> Thomas Breuel wrote:
[ ... pros and cons of java cross-platform compatibility ... ]
> > Compare that to C++, where none of those facilities are standardized,
> > and where programmers are placed completely at the mercy of the
> > operating system vendor for anything more than very basic I/O
> > functionality. Furthermore, C++ name mangling also effectively
> > locks users into a single compiler vendor on many platforms.
>
> A while back in another thread, proprietary C++ name mangling was
> described to me as a benefit to protect me from mixing mutually
> incompatible abi's. The abi's were incompatible as each C++ vendor
> attempts to optimize for their machine/market.
>
> Personally, I'd prefer the standardization
But to my mind, that would go against the basic philosophy of C++. The
compiled binaries (of which name mangles are a part) are SUPPOSED to be
implementation specific so machine-specific optimisation opportunities
are not missed.
It's the C++ code itself that is supposed to work across platforms.
That's the way things were designed.
Java, can implement certain machine-specific optimisations with it's
run-time system, but nowhere near the level of C++.
I think it boils down to requirements. Java provides cross-platform
binary compatibility at the cost of performance. C++ does not.
--
Igor Siemienowicz
ig...@adacel.com.au
Fergus Henderson
David Chatterton <ch...@engr.sgi.com> writes:
>Thomas Breuel wrote:
>> Sun's license for their Java implementation is somewhat strict for
>> software that is distributed freely, but let's not forget that it is
>> distributed freely and versions of it have been ported and made freely
>> available for platforms such as Linux. This strikes me as a lot less
>> "draconian" than the original AT&T C++ translator, which was never
>> freely available.
>
>Well explain that to the Linux user's who could not obtain Java due to
>license restrictions for a couple of months this year?
As far as I'm aware, you can't get AT&T CFront for Linux either.
>It's a pity Java couldn't exist like Linux :(
True, but free software users can still develop their own implementations
of Java (and have done so already, I believe).
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Fergus Henderson
Philip Walden <pwa...@corp.hp.com> writes:
>Thomas Breuel wrote:
>>
>> Furthermore, C++ name mangling also effectively
>> locks users into a single compiler vendor on many platforms.
>
>A while back in another thread, proprietary C++ name mangling was
>described to me as a benefit to protect me from mixing mutually
>incompatible abi's. The abi's were incompatible as each C++ vendor
>attempts to optimize for their machine/market.
>
>Personally, I'd prefer the standardization
Thomas Breuel misspoke. What he should have said was
Furthermore, the lack of standard C++ ABIs also effectively
locks users into a single compiler vendor on many platforms.
Proprietry C++ name mangling is a benefit, given the lack of standard
C++ ABIs. It's the lack of standard ABIs that causes the problem,
not name mangling.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Steve Heller
fkn...@qualcomm.com (Friedrich Knauss) wrote:
>In article <57evjm$q...@netlab.cs.rpi.edu>,
>Steve Heller <hel...@utdallas.edu> wrote:
>> The main result of such a course will be to leave the novice
>>programmer so far behind and so confused that he or she may very well
>>give up programming entirely. Without a solid foundation in the most
>>fundamental constructs of the language, it's not possible to learn the
>>more complex aspects.
>While I understand the desire to teach constructs, I think the
>biggest learning hurdle is the OOD part. I'd like to see a C++
>class which spent the first week only using CRC cards. Once the
>OOD concepts have been learned, understanding the language
>constructs which support those concepts becomes much simpler.
For absolute beginners to programming, you first have to teach them
what a program is, in very simple terms. I agree that it's important
to get them familiar with OOD as soon as possible: the question is
"how soon is that?".
>I know Bjarne suggests that C++ be learned incrementally, "as a
>better C". As much as I respect his development of the
>language, I must disagree with him on this. A lot of the things
>that make C++ more powerful also make it more abuseable (is that
>a word?). This is akin to giving a race car to a teenager who
>has just aquired his drivers license.
I teach as little procedural programming as I think is possible to
do before getting into OOP, which is more than zero. After all, member
functions are first of all functions.
>Having dealt with a lot of code written by engineers at various
>levels of development, not least of all my own, it is apparent
>that the language constructs are much more easily learned than
>their proper application. I'm not trying to imply that you
>teach improper use of the fundamentals, but rather that learning
>their proper use takes orders of magnitude more time, and in the
>interim a whole lot of really painful code can be generated.
I agree. That's why I teach only those constructs that are necessary
to advance the student's learning of programming at any given time.
IMO, tutorial books that start out with, e.g.,"here are the 17 level
of operator precedence" are wrongheaded, as a novice doesn't need to
know them to write simple programs (or any programs at all, if they're
willing to use parentheses).
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
Steve Heller
qli...@ix.netcom.com (Quan Liang) wrote:
>Since I couldn't understand OOP and really didn't want to read further
>books about the OOP. What I did is to remove all words related to the OOP,
>just find what the problem the languages want to do and how they do it. The
>result is the learning task become quite easy. I doubt whether many book
>authors are also lost in OOP when writing books.
Well, I'm certainly not lost in OOP at all. But I don't think I mean
the same as you do by that statement.
>I like C++ (it's beautiful in feeling and powerful) and like Java
>(beautiful too and easy) but I don't want to know OOP.
Since the main virtue of C++ is that it allows OOP, you're missing
the boat here. I can certainly believe that you've never seen a
textbook that explains OOP clearly, but that doesn't mean they don't
exist.
Alex Martelli
jtb...@cs1.presby.edu (Jon Bell) writes:
> Michael Malak <ma...@access.digex.net> wrote:
>>In article <57kn48$p...@netlab.cs.rpi.edu>,
>>Bjarne Stroustrup <b...@research.att.com> wrote:
>>>
>>>However, many (most?) people deal with many application areas and
>>>many of those prefer a multi-paradigm language like C++ over a set
>>>of smaller and more specialized languages.
>>
>>This is a critical flaw in your argument. The common paradigm in
>>the Microsoft world is to use both Visual Basic and Visual C++ in
>>the same application. [...]
>"the Microsoft world" != "the world". :-)
Of course, but analogous sets of preferences applies in other
"worlds". In the "traditional Unix world", for example, the
common paradigm is to use both some shell language and C in
the same application; in the "very traditional mainframe world",
JCL and Cobol; in the "emerging Sun vision of Internet computing",
apparently, TCL and Java. There are also communities where using
a single language is a more common paradigm (LISP, or Smalltalk);
but most languages are apparently perceived as not ideal for both
"scripting/glue" tasks (JCL/VB/ksh/TCL sorts of things) and
"main computation" (Cobol/C++/C/Java sorts of things) by most
of the community of their users, and many applications require
both sorts of tasks to be performed.
Of course, things are never all that black-and-white -- VB, TCL, Perl,
for example, all can surely be used reasonably effectively for both
scripting AND "main computation stuff", if the latter isn't too
computationally intensive/taxing -- and each has been and will be
used to the limit of its sensible applicability -- _and beyond_ that
limit, if one indeed exists, because of the "other pole" of this
dynamic tension between "using the most suitable language for
each portion of an application" and "using just one language".
Mixture of languages with similar and overlapping areas of
excellence is, in my opinion, rarer than mixture of languages
which are perceived as "widely separate" in this regard. Besides
scripting/glue, other examples include languages such as SQL,
which is exceedingly often used for DB access together with
another language to which non-DB-access stuff is left.
Alex
--
DISCLAIMER: these are MY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: mart...@cadlab.it -- Phone: +39 (51) 597 313 [Fax: 597 120]
Cad.Lab S.p.A., v. Ronzani 7/29, 40033 Casalecchio (BO), Italia
Steve Heller
Thant Tessman <th...@shoreline-studios.com> wrote:
>C++ is successful solely because it is an extension of C. The
>decision to extend C was a marketing decision. And the decision
>to use C++ when it first became available was a marketing decision
>based on the (faulty) assumption that C++ was the most effective
>way to leverage off of the heavy investment people had already made
>in C. And nowdays the decision to use C++ is a marketing decision
>based on the heavy investment people have already made in C++.
>C++ is the epitome of successful marketing.
Exactly who was doing this "marketing"? I don't know any companies
where the salesmen make technical decisions as to what language to
use.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
Dann Corbit
Thant Tessman <th...@shoreline-studios.com> wrote in article
<582g82$j...@netlab.cs.rpi.edu>...
> Bjarne Stroustrup wrote:
>
> > [...] The fact that hundreds of thousands of presumably
> > intelligent programmers have adopted a language that never
> > was the easiest to learn is significant.
> >
> > It wouldn't have been significant had C++ gained that user
> > population through extraordinary marketing or through a captive
> > (corporate or governmental) audience. However, C++ usage became
> > significant while its marketing dollars were minute compared to
> > what was spent on other languages and systems. [...]
>
> decision to extend C was a marketing decision. And the decision
> to use C++ when it first became available was a marketing decision
> based on the (faulty) assumption that C++ was the most effective
> way to leverage off of the heavy investment people had already made
> in C. And nowdays the decision to use C++ is a marketing decision
> based on the heavy investment people have already made in C++.
>
> C++ is the epitome of successful marketing.
Where was the marketing campaign for FORTRAN?
Where was the marketing campaign for C?
Where was the marketing campaign for COBOL?
These have been marketed all-right. AFTER they
became successful. C++ gained popularity for
the same reason that all popular languages gain
popularity - because they are effective tools to
solve problems.
PROLOG was marketed as hard as any of the above.
Where is it now? Off in some corner with a few
academic users tinkering away. Why? Because it
is not more effective than other tools already
available to solve the same tasks.
To imagine that C++ is popular solely because it
is somewhat based on C is just plain silly.
What about Objective C? There are many other C
derivatives. What kind of user base do they have?
If I roll up a newspaper and market it as a hammer,
how long will people buy it? Will I build faster
than people using real hammers if I do? If not, I'll
go out of business if I buy newspaper hammers and
try to build houses with them. People stop buying
tools if they don't work.
Don Taylor
Michael Malak wrote:
>
> How do you program without pointers? (I've been genuinely curious
> about this for a while.)
>
cannot be implemented without the use of pointers. Take a look at
Smalltalk and Java for examples of this.
--
Don Taylor (614) 899-5367 | Heresy is only another word
Cutler-Hammer IDT | for freedom of thought.
Westerville, Ohio | <Graham Greene, British novelist>
Don Taylor
Michael Malak wrote:
>
> In article <57kn48$p...@netlab.cs.rpi.edu>,
> Bjarne Stroustrup <b...@research.att.com> wrote:
> >
> >variety of programming styles (``paradigms''). For any one application
> >area, you can construct a language that is more convenient than C++.
> >However, many (most?) people deal with many application areas and
> >many of those prefer a multi-paradigm language like C++ over a set
> >of smaller and more specialized languages.
>
> This is a critical flaw in your argument. The common paradigm in
> the Microsoft world is to use both Visual Basic and Visual C++ in
> are written in C and/or assembly, for a total of up to four languages
> in a single system!
>
I'm not sure where you get your information for the "common paradigm."
Personally I would want to minimize the number of languages I use in a
project. For example, I don't understand your distinction between C and
C++. I don't consider these to be separate languages. C++ allows for
straightforward C programming (that's part of the multiple paradigms
Bjarne is talking about).
As far as the C++/Visual Basic mix is concerned, I see this being split
amongst separate programming groups. The interface between these
languages is through a DLL, and the idea is that the Visual Basic
programmers can use services that have been placed into the DLL and that
the DLL would have been created with C++. If I were the project manager
of a single team I would NEVER mix Visual Basic with C++, if I've
already got a C++ team, then what's the point? Why not just do
everything in C++? With Visual C++ it's easy to do and saves a lot of
headaches.
Now if I managed a Visual Basic team and there were off-the-shelf parts
available for me to use that provides some functionality, then I really
don't care what language the parts were implemented with. Why would you
otherwise deliberately mix the two languages?
> That is today. Tomorrow, Visual J++ (Java with compilation to machine
> code) and Visual Basic 5.0 (which can construct ActiveX controls
> without C++) will replace Visual C++, at least for most new
> application development.
>
That's a sweeping statement. It seems you have made an implicit
assumption that most new application development is going to concern
itself with ActiveX controls, which is not necessarily the case. Even if
it were, Visual C++ handles the creation of these controls just fine -
and I still have a multi-paradigm language I can use for whatever other
tasks will be required by the project. Get it? One project, one
language.
> So today in the Microsoft world, a "set of smaller, and more
> specialized languages" is not "unpreferred", it is the norm --
> I have never seen a resume cross my desk where Visual C++ was
> listed and Visual Basic was not.
>
You haven't seen my resume.
> Tomorrow in the Microsoft world, that "set" of languages may very
> well not include C++.
>
So? I doubt this statement will be true. It also may very well not
include Java, Visual Basic, or a host of other languages.
> Correct me if I'm wrong, but what I hear you saying is that C++ has
> the capability to handle the spectrum of capabilities: RAD through
> libraries, solid OOP through C++ constructs, and drivers through
> the C subset of C++. You further claim that since this is a single
> language, "many prefer it". I disagree, noting the popularity of
> the Visual Basic/Visual C++/assembly triplet today, and the trend
> toward the Visual Basic/Visual J++/C triplet tomorrow.
>
I disagree that these triplets you've identified really correspond to
the majority of Windows projects. From a project management perspective
there is a desire/need to use as few languages as possible.
I think in cases where these triplets are being used each of the
components are produced by separate program teams, where each team is
either in another corporate division, or represent separate commercial
entities; but again each team works in a single language.
Fergus Henderson
Philip C Plumlee <te...@deltanet.com> writes:
>Thant Tessman <th...@shoreline-studios.com>
>
>> C++ is successful solely because it is an extension of C. The
>> decision to extend C was a marketing decision. And the decision
>> to use C++ when it first became available was a marketing decision
>> based on the (faulty) assumption that C++ was the most effective
>> way to leverage off of the heavy investment people had already made
>> in C. And nowdays the decision to use C++ is a marketing decision
>> based on the heavy investment people have already made in C++.
>>
>> C++ is the epitome of successful marketing.
>
>Heavy investment? In a compiler that fits on one floppy disk which you
>can usually get for free?
I don't understand what you're getting at here.
The fact that a compiler is available for free does not necessarily
imply anything about the investment required to create that compiler.
Indeed, probably more total man-hours have gone into the development of
gcc than most other compilers. GNU Ada is available for free, but I
think it's development cost the US government something of the order of
$US 1 million.
Similarly, the fact that a compiler may fit on one floppy disk does not
necessarily imply anything at all about the amount of investment
required to create that compiler.
But in any case, the heavy investment that people have in C is primarily
the millions of lines of existing C code; the value of all the C
compilers put together is *much* less than the value of the C code.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
linh (l.) dang
>>>> "Fergus" == Fergus Henderson <f...@murlibobo.cs.mu.OZ.AU> writes:
Fergus> David Chatterton <ch...@engr.sgi.com> writes:
>> Thomas Breuel wrote:
>>> Sun's license for their Java implementation is somewhat strict
>>> for software that is distributed freely, but let's not forget
>>> that it is distributed freely and versions of it have been ported
>>> and made freely available for platforms such as Linux. This
>>> strikes me as a lot less "draconian" than the original AT&T C++
>>> translator, which was never freely available.
>> Well explain that to the Linux user's who could not obtain Java
>> due to license restrictions for a couple of months this year?
Fergus> As far as I'm aware, you can't get AT&T CFront for Linux
Fergus> either.
Yes you can... Last year (or so) a company advertized a CFront-based
C++ compilter for Linux saying it's better than G++. This post started
a long flame-war.
The situation with Linux-Java is PORTED BY LINUXERS and Sun didn't let
them release it.
>> It's a pity Java couldn't exist like Linux :(
L.D.
--
=====================================================================
Linh Dang Nortel Technology
Member of Scientific Staff Speech Recognition Software
li...@nortel.ca
=====================================================================
David Chatterton
Fergus Henderson wrote:
>
> David Chatterton <ch...@engr.sgi.com> writes:
>
> >Thomas Breuel wrote:
> >> Sun's license for their Java implementation is somewhat strict for
> >> software that is distributed freely, but let's not forget that it is
> >> distributed freely and versions of it have been ported and made freely
> >> available for platforms such as Linux. This strikes me as a lot less
> >> "draconian" than the original AT&T C++ translator, which was never
> >> freely available.
> >
> >Well explain that to the Linux user's who could not obtain Java due to
> >license restrictions for a couple of months this year?
>
>
AT&T Cfront was available free to universities, but Linux was not around
back then.
My point is that it is not as freely available as it could be, and no
matter what the licensing situation is, Microsoft will still try to
consume it.
David
--
David Chatterton (61-3) 9882 8211 (Tel)
R&D Software Engineer (61-3) 9882 8030 (Fax)
Performance Tools Group http://reality.sgi.com/chatz_engr
Silicon Graphics Pty.Ltd., 357 Camberwell Rd, Melbourne, Australia
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
John Nagle
Thomas Breuel <t...@intentionally.blank> writes:
>b...@research.att.com (Bjarne Stroustrup) writes:
>> I think that my fear that Java/J++ will be a language subject
>> to gross manipulation by platform suppliers for the purpose of locking
>> in users and increasing supplier revenues is not unfounded. I expect
>> dramatic changes to the Java language itself and wide variations in the
>> libraries. If I'm wrong, so much the better for Java programmers.
For most of the last five years, one could have made that statement about
C++. One can hope that with the release of the ANSI standard for C++
this situation will improve. ANSI C, for example, is reasonably portable
today, although it took many years to reach that point. It's in the nature
of how Java is used that it has higher compatibility requirements than C++,
and this may help to hold things together.
The real issue is the object broker wars. We're in the middle of a
major competitive struggle over what is basically a connector issue, how
program components plug into each other. This is the world of OLE,
OpenDoc, Active-X, CORBA, and Java Beans. Until now, language issues
have driven interface issues like this, but the situation is reversing,
and this time, who loses the object broker wars will have a major impact
on the direction of programming languages.
John Nagle
John Nagle
Don Taylor
Thant Tessman wrote:
>
> Bjarne Stroustrup wrote:
>
> > [...] The fact that hundreds of thousands of presumably
> > intelligent programmers have adopted a language that never
> > was the easiest to learn is significant.
> >
> > It wouldn't have been significant had C++ gained that user
> > population through extraordinary marketing or through a captive
> > (corporate or governmental) audience. However, C++ usage became
> > significant while its marketing dollars were minute compared to
> > what was spent on other languages and systems. [...]
>
> decision to extend C was a marketing decision. And the decision
> to use C++ when it first became available was a marketing decision
> based on the (faulty) assumption that C++ was the most effective
> way to leverage off of the heavy investment people had already made
> in C. And nowdays the decision to use C++ is a marketing decision
> based on the heavy investment people have already made in C++.
>
> C++ is the epitome of successful marketing.
>
this statement, one that really stands out is who was doing the
marketing? It sure wasn't AT&T Bell Labs, the creators of the language.
The reason I switched to C++ was simply that it allowed me to compile my
already-existing C project, and yet provide the flexibility of working
over parts of the project design that would benefit from OOP. The fact
of the matter is I didn't have the resources to start over using another
language.
Aside from these details I should point out that most of the people
currently using C++ ARE previous C programmers, and C programmers are an
interesting lot. They have this preoccupation with performance. I know a
lot of people that view C as the greatest cross-platform macro assembler
ever invented. My only point to this being that when C++ was introduced
it was explained that performance was a critical issue, and in fact that
supposedly a program written in C++ would run at least 90% as fast as
the same program that was written in C (I don't know if that's still a
language goal). So the efficiency of C++ was very important to the
people using it.
All this suggests it was not simply "marketing" that caused the
language's popularity. I for one am getting very tired of marketing
being blamed for all the successes in this industry.
--
Don Taylor (614) 899-5367 | Heresy is only another word
Cutler-Hammer IDT | for freedom of thought.
Westerville, Ohio | <Graham Greene, British novelist>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Philip Walden
Thomas Breuel wrote:
>
> Igor Siemienowicz <ig...@adacel.com.au> writes:
> > But to my mind, that would go against the basic philosophy of C++. The
> > compiled binaries (of which name mangles are a part) are SUPPOSED to be
> > implementation specific so machine-specific optimisation opportunities
> > are not missed.
>
> calling conventions and implementation strategies, but to eventually
> standardize on a single convention per platform.
>
I believe you have it it right. There should be no optimization
advantage to have different name manglers on the same machine. After all
optimizing C compilers can generate libraries that are interoperable on
the same machine.
--
-------------------------------------------------------------------------
-
Philip Walden
Hewlett Packard
Product Generation Information Systems
1501 Page Mill Road, M/S 4U-6
Palo Alto, CA 94304
(415) 857-3899 FAX (415) 857-8234
http://www.pgis.hp.com/~pwalden
mailto:phil_...@hp.com
-------------------------------------------------------------------------
-
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrew Koenig
> C++ is successful solely because it is an extension of C. The
> decision to extend C was a marketing decision.
The first of these sentences is false. The second is mostly false.
If the first statement were true, then any language that was an
extension of C would be successful. But I know of at least two
such languages that were not successful.
Whether or not it is legitimate to call the decision to make C++ an
extension of C a marketing decision depends on your definition of
marketing. It is certainly true that one of the reasons that C++
was based on C was to make C++ more attractive to C users than it
would be otherwise. But if that is all it takes to define something
as a marketing decision, then it's hard to imagine any kind of user-
oriented software system that's not based on marketing.
If, on the other hand, you define marketing as being based on a
business plan, then the nature of C++ was definitely not a marketing
decision. In fact, Bjarne's early efforts to make C++ available outside
of AT&T met with strong resistance from the marketing people because
C++ was upward compatible with C and would therefore compete with it.
So if C++ were nothing more than a marketing decision, it would have
looked very different from C.
--
--Andrew Koenig
a...@research.att.com
Stan Friesen
In article <581nr8$f...@netlab.cs.rpi.edu>, fkn...@qualcomm.com (Friedrich Knauss) writes:
|> While I understand the desire to teach constructs, I think the
|> biggest learning hurdle is the OOD part.
This matches my own experience in *learning* C++.
It was only after I paid close attention to OOD that I was able to
use the language effectively.
--
s...@elsegundoca.ncr.com sar...@ix.netcom.com
The peace of God be with you.
Dann Corbit
Michael Malak <ma...@access.digex.net> wrote in article
<5852vf$2...@netlab.cs.rpi.edu>...
[snip]
[this thread appears to be wandering off-topic -- mod]
> The time to deploy a hammer is 5 seconds, in contrast to the time to
> deploy a programming language, which is a year or two.
>
> If I told you that the newspaper hammer was rolled in such a way
> that it was as effective as a regular hammer at hitting nails,
> but when hitting your thumb it didn't hurt, you might believe me.
> I could tell you that the rolling created an internal structure
> similar to Aztec architecture, giving it these unique properties.
> If I were a credible, well-published source, you might believe me,
> at least for the five seconds until you try out the newspaper.
>
> The lengthy deployment time and heavy investment for a new
> programming language creates the well-documented FUD
> phenomenon in our industry (fear, uncertainty, doubt).
> Going with a C derivative from AT&T, the creator of C, and
> a derivative which is going through the ANSI standardization process,
> seems like a safe bet in the FUD world. Objective C and other
> C derivatives are proprietary by comparison to C++.
I do not accept that FUD drives success or failure of programming
languages. I always use the tools I want to use for a job,
including what programming language to use. If I try something
and it does not work 'as advertised' I won't use it again.
C++ has been around for about a decade. That's quite an eternity
in Computer-land. If you can fool highly educated engineers
for that long, you have really accomplished something.
I do accept a bit of what you say, though. If I think that a
single company completely controls the use of some tool, I will
be nervous to use it. The more open and available, the better.
But computer languages are specifications on paper, and pretty
much anyone can try to do an implementation.
Having real competition also prevents stagnation. If driven to
innovate, people do.
[snip]
Igor Siemienowicz
Thomas Breuel wrote:
> Igor Siemienowicz <ig...@adacel.com.au> writes:
> > But to my mind, that would go against the basic philosophy of C++. The
> > compiled binaries (of which name mangles are a part) are SUPPOSED to be
> > implementation specific so machine-specific optimisation opportunities
> > are not missed.
> The intent, I believe, was to let C++ implementors figure out good
> calling conventions and implementation strategies, but to eventually
> standardize on a single convention per platform.
But that doesn't REALLY solve the major problem that library vendors
have, does it? If you have a code library, the source for which you want
to keep secret, you still have distribute multiple binaries if you want
to support multiple platforms.
And quite frankly, I think that reaching a standard for binaries on
platforms like Wintel is little more than a pipe-dream. Not only are
there a number of different chipsets, with different optimisation
opportunities, but the multiplicity of compiler vendors is rather high.
Each of them has their own secret and proprietary methods of
optimisation that they're not going to share with the others.
[ ... snippage ... ]
--
Igor Siemienowicz
ig...@adacel.com.au
Ell
A major reason C++ was based on C was Stroustrup's desire to have the C
language with classes. Simula had classes and Stroustrup wanted to
incorporate them with C. Stroustrup states this in the book Design and
Evolution of C++.
Elliott
Kevin J Hopps
Michael Malak wrote:
>
> In article <57kn48$p...@netlab.cs.rpi.edu>,
> Bjarne Stroustrup <b...@research.att.com> wrote:
> >
> >For good and bad, C++ is a general-purpose language that supports a
> >variety of programming styles (``paradigms''). For any one application
> >area, you can construct a language that is more convenient than C++.
> >However, many (most?) people deal with many application areas and
> >many of those prefer a multi-paradigm language like C++ over a set
> >of smaller and more specialized languages.
>
> This is a critical flaw in your argument. The common paradigm in
> the Microsoft world is to use both Visual Basic and Visual C++ in
> the same application. Further, for those that need them, drivers
> are written in C and/or assembly, for a total of up to four languages
> in a single system!
A "paradigm" is a model, a way of looking at something. To say that
C++ supports a variety of paradigms is to say that it suports the
implementation of software solutions which arise out of these different
ways of looking at problems. For example, people may look at the
same problem through an object oriented paradigm or a procedural
paradigm. C++ supports both.
It may be true that in "the Microsoft world," (which used to be called
Earth :-) VB and VC++ are used together, but using multiple languages
together is not what is meant by multiple paradigms.
--
Kevin J. Hopps
Software Development Specialist
Imation
Igor Siemienowicz
Philip Walden wrote:
> Thomas Breuel wrote:> >
> > Igor Siemienowicz <ig...@adacel.com.au> writes:
> > > But to my mind, that would go against the basic philosophy of C++. The
> > > compiled binaries (of which name mangles are a part) are SUPPOSED to be
> > > implementation specific so machine-specific optimisation opportunities
> > > are not missed.
> > The intent, I believe, was to let C++ implementors figure out good
> > calling conventions and implementation strategies, but to eventually
> > standardize on a single convention per platform.
> I believe you have it it right. There should be no optimization
> advantage to have different name manglers on the same machine. After all
> optimizing C compilers can generate libraries that are interoperable on
> the same machine.
But differences in compiled binaries go well beyond simple name
mangling. True, optimisation shouldn't really affect name-mangling one
way or the other, but the different secret and proprietory methods that
compiler vendors have of optimising their compiled code are bound to
make their binaries incompatible anyway. Name mangling differences are
simply a way of making sure that the linker can't join up binaries that
aren't going to work with each other. It's protection.
I first learnt about this when I used the DOS port of gcc (DJGPP). This
compiler has a 32-bit DOS extender, and a flat memory model. There's no
way that the libraries compiled under that compiler are going to be
compatible with anything from Borland, Microsoft or Watcomm. So the name
mangling is different, just to protect the careless. It actually
explained this point in the documentation.
--
Igor Siemienowicz
ig...@adacel.com.au
David Vandevoorde
>>>>> "FH" == Fergus Henderson <f...@murlibobo.cs.mu.OZ.AU> writes:
[...]
FH> As far as I'm aware, you can't get AT&T CFront for Linux either.
Greg Comeau used to (and still might) sell a port of Cfront 3.x
for Linux. (He's moving to EDG's front-end now.)
Daveed
David Wright
In article <5877un$9...@netlab.cs.rpi.edu>, Stan Friesen
<s...@elsegundoca.ncr.com> writes
>In article <581nr8$f...@netlab.cs.rpi.edu>, fkn...@qualcomm.com (Friedrich
>Knauss) writes:
>|> While I understand the desire to teach constructs, I think the
>|> biggest learning hurdle is the OOD part.
>
>This matches my own experience in *learning* C++.
>
>It was only after I paid close attention to OOD that I was able to
>use the language effectively.
Absolutely.
I am migrating from Modula-2 to C++.
As far as syntax is concerned the differences are not stunning;
I could just adopt my ingrained (8 years) M-2 paradigms but that would
hardly be the point.
The real hurdle is change of paradigm not change of syntax.
Regarding the question "Do you like C++?"
The language is just a way of expressing design ideas to the computer
system. C++ provides powerful facilities to allow that expression of
ideas.
So, do I like it? Yes.... I think. ;-)
Regards
David Wright "Language shapes the way we think,
Elgol,Isle of Skye,Scotland and determines what we can think about."
dwr...@ealaghol.demon.co.uk - B.L Whorf
John Saunders
Igor Siemienowicz <ig...@adacel.com.au> wrote in article
<589ghb$i...@netlab.cs.rpi.edu>...
Sorry to quote all this, but it seemed necessary:
I don't understand what optimization within binary modules has to do with
the interface between binary modules. Therefore, I don't know why the name
mangling would have to be different to save us from the interface
differences. But perhaps there's some sort of optimization that linkers
perform nowadays?
It's been a long time, but I have worked on systems where compilers from
different vendors were used to produce binaries which were then linked
together. It was necessary to use pragmas or compiler switches to ensure
that calling conventions were compatible, but it was possible, if not easy.
I'm not sure why that wouldn't be true for C++, but then, I'm about a
decade behind on compiler technology.
> I first learnt about this when I used the DOS port of gcc (DJGPP). This
> compiler has a 32-bit DOS extender, and a flat memory model. There's no
> way that the libraries compiled under that compiler are going to be
> compatible with anything from Borland, Microsoft or Watcomm. So the name
> mangling is different, just to protect the careless. It actually
> explained this point in the documentation.
Not necessarily so. If the compiler has no pragmas or switches that permit
it to be compatible with another compiler, then you're right. But that's
the fault of gcc, not a reason for incompatible name mangling.
> Igor Siemienowicz
> ig...@adacel.com.au
John Saunders
j...@jws.ultranet.com
J. Kanze
hel...@utdallas.edu (Steve Heller) writes:
> That's why I don't teach my students to use pointer arithmetic
> (other than when accessing array elements inside class
> implementations) or casts.
Excellent. I agree wholeheartedly. So what do you do if your
"students" are experienced C programmers, who are convinced that this is
the only way to go?
--
James Kanze +33 (0)3 88 14 49 00 email: ka...@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
John Nagle
Thomas Breuel <t...@intentionally.blank> writes:
>With a high quality native code compiler for Java, you can write
>numerical code that runs about as fast as equivalent C++ code.
Do you know of any such compilers? I do heavy number crunching
where the source code is generated automatically and compiled. This would
be much cleaner in Java than in C++, but right now, the hard-code
compiler situation isn't very good.
John Nagle
Michael Malak
Perhaps I wasn't clear in my original article:
There are two reasons to prefer one language over another. First,
one language may inherently fit a problem better. Second, one
language may be better supported (tool availability).
For language reasons alone, we will want to write the device
drivers in a different language than the application.
For the application, in these days of componentware, we have a
split in the application between the RAD layer and the OOP
layer. It would be nice if these could be in the same
language (e.g. Java). But due to tool availability, the
choice in the Microsoft World is Visual Basic/Visual C++
today and Visual Basic/Visual J++ tomorrow.
The remainder of this article consists of paragraph-by-paragraph
refutations on technological points, about half of it specific to
the Microsoft world:
In article <584au0$q...@netlab.cs.rpi.edu>,
Don Taylor <d...@idt.ch.etn.com> wrote:
>Michael Malak wrote:
>>
>> In article <57kn48$p...@netlab.cs.rpi.edu>,
>> Bjarne Stroustrup <b...@research.att.com> wrote:
>> >
>> >For good and bad, C++ is a general-purpose language that supports a
>> >variety of programming styles (``paradigms'').
>>
>> This is a critical flaw in your argument. The common paradigm in
>> the Microsoft world is to use both Visual Basic and Visual C++ in
>> the same application. Further, for those that need them, drivers
>> are written in C and/or assembly, for a total of up to four languages
>> in a single system!
>>
>
>I'm not sure where you get your information for the "common paradigm."
It is the paradigm encouraged by Microsoft.
>Personally I would want to minimize the number of languages I use in a
>project. For example, I don't understand your distinction between C and
>C++. I don't consider these to be separate languages. C++ allows for
>straightforward C programming (that's part of the multiple paradigms
>Bjarne is talking about).
Visual C++ allows one to compile a .C file as opposed to a .CPP file.
The former is more convenient for device drivers since you don't
have to extern "C" all over the place.
>If I were the project manager
>of a single team I would NEVER mix Visual Basic with C++, if I've
>already got a C++ team, then what's the point? Why not just do
>everything in C++? With Visual C++ it's easy to do and saves a lot of
>headaches.
Reuse is higher with components (OLE/ActiveX Controls) than with
C++ objects.
>Now if I managed a Visual Basic team and there were off-the-shelf parts
>available for me to use that provides some functionality, then I really
>don't care what language the parts were implemented with. Why would you
>otherwise deliberately mix the two languages?
Inevitably there are domain-specific components that need to be
developed.
>Even if
>it were, Visual C++ handles the creation of these controls just fine -
You cannot easily use a graphical resource editor to create controls
in Visual C++. This will be fixed in Visual Basic 5.0.
Further, to create a COM object (the mechanism of communication
between components) in Visual C++ requires too much code. In
Visual J++, every object can be a COM object nearly automatically.
The language definitions have nothing to do with this, of course;
it's all Microsoft's push. Their ActiveX Template Library for
C++ is not well supported (rumor is that it will never ship with
Visual C++).
>> Tomorrow in the Microsoft world, that "set" of languages may very
>> well not include C++.
>>
>So? I doubt this statement will be true. It also may very well not
>include Java, Visual Basic, or a host of other languages.
Releases and information about future releases of Visual C++ have
slowed to a trickle. Releases of Visual J++ and Visual Basic have
been rapid. It appears as though Microsoft has shifted its
development efforts. The PC industry generally follows Microsoft,
sooner or later.
Despite Microsoft's efforts, there will be some holdouts. In 1992,
Microsoft tried to shift everyone from DOS to Windows by making
their C/C++ compiler (7.0) not run easily under DOS. To this day,
many people still use Microsoft C 6.0. (Due to the backlash, 8.0
does in fact run under DOS easily, but not many people know this.)
But that tactic by Microsoft no doubt sped up the transition from
DOS to Windows.
Similarly, Microsoft will encourage a transition from C++ to
Visual Basic and Java, at least for many applications. Their
forthcoming Internet/RAD Studio product is proof.
>> language, "many prefer it". I disagree, noting the popularity of
>> the Visual Basic/Visual C++/assembly triplet today, and the trend
>> toward the Visual Basic/Visual J++/C triplet tomorrow.
>>
>I disagree that these triplets you've identified really correspond to
>the majority of Windows projects. From a project management perspective
>there is a desire/need to use as few languages as possible.
Perhaps if reuse is not a concern (and often it is not), then you
would be correct -- use as few languages as possible, and create
a monolithic application.
More often, organizations are interested in reuse at least insofar
as creating similar applications in the same domain. Reuse is
higher with components, and when using components the need for
a single language is less.
>I think in cases where these triplets are being used each of the
>components are produced by separate program teams, where each team is
>either in another corporate division, or represent separate commercial
>entities; but again each team works in a single language.
In terms of percentage share of new development, C++ will eventually
go down. That much is obvious; the only question is when. We know
that the presence of Visual Basic has had an impact on C++. (I.e.,
if Visual Basic did not exist, more new projects would be done in
C++.) Similarly, Visual Basic 5.0 and Visual J++ will have impact
on C++. Again, the question is how much.
I'm in no position to make market share estimates and predictions.
My original article was merely refuting, by anecdotal evidence, the
claim by Bjarne Stroustrup:
:However, many (most?) people deal with many application areas and
:many of those prefer a multi-paradigm language like C++ over a set
:of smaller and more specialized languages.
--
Michael Malak Home: ma...@access.digex.net
Washington, DC Work: ma...@notes.sonix.com
J. Kanze
da...@ugcs.caltech.edu (David A. Cuthbert) writes:
> Chelly Green <che...@eden.com> wrote:
> >David Bradley wrote:
> >> Redo the above as follows
> >>
> >> int *a; // Pointer to integer
> >> int const* b; // Pointer to constant integer
> >> int * const c; // Constant pointer to integer
> >> int const * const d; // Constant pointer to constant
> >> integer
> >
> >Actually, if there were any redoing, it would be:
> >
> > int* a; // pointer to non-const int
> > int const* b; // pointer to int that can't change through this
> > // pointed-to int may or may not be const
> > etc.
> >
> >> All false into place and the simple rule of const follows what it
> >> modifies works well.
>
> As I said in my earlier post, this isn't an intuitive construction. I
> even thought of a worse case here:
>
> int const * a, b;
>
> Ok, so it's pretty clear what a is. What is b? (I don't have access
> to a compiler until I return home, but I'm guessing that it's int
> const. So const modifies what's to its left, * modifies what is to
> its right, but const can also modify what is to its right if nothing
> is to its left, but this is an exception to the rule and we shouldn't
> use it -- even though it is grammatically correct.)
For the record, `b' is "int const".
I think that most people would agree that the C++ declaration syntax
isn't the most intuitive. (My first reaction to Java was: since they do
not have any C compatibility, why did they keep the declaration syntax?
Why not just use Modula 3, and be done with it?)
This said, I consider the above example a red herring. Of course you
can write confusing and unreadable C++; I don't think anyone could
reasonably say otherwise. But no reasonable software engineer is going
to declare two variables in the same statement, regardless of what the
language allows. Since this particular case doesn't occur in well
written code, it doesn't bother me.
--
James Kanze +33 (0)3 88 14 49 00 email: ka...@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Scott Ellsworth
>hel...@utdallas.edu (Steve Heller) writes:
>
>> That's why I don't teach my students to use pointer arithmetic
>> (other than when accessing array elements inside class
>> implementations) or casts.
>
>Excellent. I agree wholeheartedly. So what do you do if your
>"students" are experienced C programmers, who are convinced that this is
>the only way to go?
Beat them about the head and shoulders until they stop it.
Actually, I am a bit more subtle. I present my "file o doom". This is a
C++ file I create at the start of each new group I teach, which contains a list
of common C and C++ errors. I then point out how C++ can avoid these errors
with proper paranoia, and how common C coding techniques will bring these
errors back.
I also usually give them a clear synopsis of just how long it took to find the
bug engendered, and pound the idea that debug versions, tests, and stability
are feasible, but expensive. The alternatives cost more.
This does not get them out of the habit of using casts, but it does bring them
'round to using new style casts if they must cast. It helps that every one of
these programs, if at all possible, is drawn from experience. For example,
the "old casts are evil" problem:
class Base {...};
class Der1 {...};
class Der2 {...};
Original code:
Base * holder[10]; // programmer uses old C arrays, not
// protectable C++ class
...
holder[2] = new Base();
...
Base * used = holder[2];
used->BaseMethod();
modified by maintainence programmer after six months to be
holder[2] = new Der1();
...
Der1 * used = (Der1)holder[2];
used->Der1Method(); // after all, we _know_ it is a Der1
and modified by differnt programmer some months later to be
holder[2] = new Der2();
with no other code changes. Suddenly, all hell breaks loose,
and a bug that takes a good week of someone's time shows
up. The maintainence programmer figured that changing
the Der1 to a Der2 was perfectly safe, as anyone using the
polymorphic nature of the critter would be either safe, or
protected by compiler errors. The old style cast defeated
this protection, and caused a lot of expensive grief.
The moral:
1. Using an old style cast can produce code that a reasonable code
change later will break.
2. Using a standard unwrapped C array can give you enough rope to
hang yourself.
Scott
--
f...@deltanet.com. If this fails, try f...@pobox.com
"You die, she dies, EVERYbody dies" - Heavy Metal
"When a great many people are unable to find work, unemployment results" -
Calvin Coolidge, attrib. by Stanley Walker, City Editor, p. 131 (1934)
Steve Heller
ka...@gabi-soft.fr (J. Kanze) wrote:
>hel...@utdallas.edu (Steve Heller) writes:
>> That's why I don't teach my students to use pointer arithmetic
>> (other than when accessing array elements inside class
>> implementations) or casts.
>Excellent. I agree wholeheartedly. So what do you do if your
>"students" are experienced C programmers, who are convinced that this is
>the only way to go?
Any experienced C programmer who doesn't understand why pointers are
dangerous is beyond my help. Luckily, this doesn't happen very often.
Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller
Thant Tessman
Dann Corbit wrote:
[...]
> C++ gained popularity for the same reason that all
> popular languages gain popularity - because they are
> effective tools to solve problems. [...]
A point most people don't understand is that in business,
as in evolution, you don't have to be the best to survive,
you merely have to be good enough. C++'s success is
evidence that it is "good enough".
> To imagine that C++ is popular solely because it
> is somewhat based on C is just plain silly.
> What about Objective C? There are many other C
> derivatives. What kind of user base do they have?
If I remember correctly, Objective-C is/was proprietary.
Also, I admit that there are some things about C++ that I
prefer over Objective-C. But this dosn't contradict
my point which is that only C++ and Objective-C are
(mostly) backwards compatible with C source, NOT merely
"somewhat based on C". And this is the key.
Another principle of economics is that people prefer
to make many small incremental investments over fewer
large investments even if the total cost of the
small investments is greater than the cost of the
large investments.
C++ is backwards compatible with C so that it can market
itself as an incremental solution, and people think that
if they know C they have an advantage adopting C++ because
they already know it a "little bit". But the truth is that
that the resources spent fighting C++ far outweigh the
resources necessary to switch to a better language.
This is why C++'s success is due far more to marketing
considerations than to engineering considerations, and
this is why my hatred for C++ is unbounded.
(I don't mean to tarnish the role of marketing in business.
You can't fault a salesman for selling a customer sh*t if
that's what the customer wants.)
-thant
P.S. When I talk about languages better than C++, I'm not
refering to other "C" derivatives like Eifel, or Objective-C,
or Sather (although everyone I know familiar with those languages
prefer them to C++), I'm talking about Standard ML, or Dylan, or
Erlang, or Scheme, or Modula-3, etc.
--
Thant Tessman <th...@acm.org>
Igor Siemienowicz
John Saunders wrote:
> Igor Siemienowicz <ig...@adacel.com.au> wrote in article
> > But differences in compiled binaries go well beyond simple name
> > mangling. True, optimisation shouldn't really affect name-mangling one
> > way or the other, but the different secret and proprietory methods that
> > compiler vendors have of optimising their compiled code are bound to
> > make their binaries incompatible anyway. Name mangling differences are
> > simply a way of making sure that the linker can't join up binaries that
> > aren't going to work with each other. It's protection.
> I don't understand what optimization within binary modules has to do with
> the interface between binary modules. Therefore, I don't know why the name
> mangling would have to be different to save us from the interface
> differences. But perhaps there's some sort of optimization that linkers
> perform nowadays?
There ARE some types of optimisation that DO affect the interface to a
binary module. One simple example is alignment of data with word or
double-word boundaries. Now I realise that these things can be
manipulated with pragmas and so on, but if different compilers do it
differently, the binaries won't work with each other.
Some other things that different compilers treat differently are the
'register' and 'inline' keywords and the way constructors of global
objects are called. All of these might affect the compatibility of
different binaries.
> > I first learnt about this when I used the DOS port of gcc (DJGPP). This
> > compiler has a 32-bit DOS extender, and a flat memory model. There's no
> > way that the libraries compiled under that compiler are going to be
> > compatible with anything from Borland, Microsoft or Watcomm. So the name
> > mangling is different, just to protect the careless. It actually
> > explained this point in the documentation.
> Not necessarily so. If the compiler has no pragmas or switches that permit
> it to be compatible with another compiler, then you're right. But that's
> the fault of gcc, not a reason for incompatible name mangling.
But making one compiler's binaries compatible with another's is
difficult, because, as I said in a previous post, optimisation methods
tend to be commercially sensitive technology. It is conceivable that the
secrecy of a compiler's optimisation methods would be compromised by
publishing the interface to the binaries. I believe this is one of the
reasons that we don't have a universal binary interface for compiled
modules.
Which would be nice.
--
Igor Siemienowicz
ig...@adacel.com.au
Fergus Henderson
"John Saunders" <j...@jws.ultranet.com> writes:
>Igor Siemienowicz <ig...@adacel.com.au> wrote in article
>I don't understand what optimization within binary modules has to do with
>the interface between binary modules. Therefore, I don't know why the name
>mangling would have to be different to save us from the interface
>differences.
One difficult issue is data representation, particularly as it concerns
the implementation of C++ features such as virtual functions,
inheritence, multiple inheritence, virtual inheritence, empty base
classes, pointers to members, RTTI, array element counts for delete [],
and so forth. Even if the calling convention is already standardized,
you also need to standardize the representation of any data that might
be passed between modules. Furthermore there are a number of other
issues such as exception handling that also affect the interface
between binary modules.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
al...@esi.co.il
> I think it boils down to requirements. Java provides cross-platform
> binary compatibility at the cost of performance. C++ does not.
Not to start another flame war but this is slightly off:
Today this is true but in the future JIT's can evolve to a point where
they
will perform specific optimizations to your system and this can help
Java reach
speed's which are not so slow (the technology has to evolve and there is
no way to
tell how fast it will be though some say faster than C++).
What Java lack's now and in the future (t is a curse and a blessing) is
the ability
to customize and create specific solutions at a low level but for
application
programmers this should not matter.
Bottom line:
Java provides cross-platform binary compatibility at the cost of
capabilities.
C++ does neither.
--
Shai Almog al...@esi.co.il ESI Expert Solutions International.
http://www.esi.co.il:8080/~almog/
Nick Wedd
{This thread has drifted off-topic. Please direct general discussions
of
comparative programming languages to other groups or email. -mod}
Dann Corbit <dco...@solutionsiq.com> writes
>
< snip >
>PROLOG was marketed as hard as any of the above.
Hyped up, yes. Actually marketed sensibly?
>Where is it now? Off in some corner with a few
>academic users tinkering away. Why? Because it
>is not more effective than other tools already
>available to solve the same tasks.
I don't think this is the reason. I suspect it has more
to do with defective implementations.
I use Prolog for real, non-academic, work, but I know
that this is unusual. The language is very effective
for what I do. But the implementation I use has problems.
I would be interested in people's opinions of why Prolog
is in this state.
Nick
--
Nick Wedd ni...@maproom.demon.co.uk
John Saunders
> Philip Walden wrote:
> > Thomas Breuel wrote:> >
> > > Igor Siemienowicz <ig...@adacel.com.au> writes:
> > > > But to my mind, that would go against the basic philosophy of C++.
The
> > > > compiled binaries (of which name mangles are a part) are SUPPOSED
to be
> > > > implementation specific so machine-specific optimisation
opportunities
> > > > are not missed.
>
> > > The intent, I believe, was to let C++ implementors figure out good
> > > calling conventions and implementation strategies, but to eventually
> > > standardize on a single convention per platform.
>
> > I believe you have it it right. There should be no optimization
> > advantage to have different name manglers on the same machine. After
all
> > optimizing C compilers can generate libraries that are interoperable on
> > the same machine.
>
> mangling. True, optimisation shouldn't really affect name-mangling one
> way or the other, but the different secret and proprietory methods that
> compiler vendors have of optimising their compiled code are bound to
> make their binaries incompatible anyway. Name mangling differences are
> simply a way of making sure that the linker can't join up binaries that
> aren't going to work with each other. It's protection.
>
Sorry to quote all this, but it seemed necessary:
I don't understand what optimization within binary modules has to do
with
the interface between binary modules. Therefore, I don't know why the
name
mangling would have to be different to save us from the interface
differences. But perhaps there's some sort of optimization that linkers
perform nowadays?
It's been a long time, but I have worked on systems where compilers from
different vendors were used to produce binaries which were then linked
together. It was necessary to use pragmas or compiler switches to ensure
that calling conventions were compatible, but it was possible, if not
easy.
I'm not sure why that wouldn't be true for C++, but then, I'm about a
decade behind on compiler technology.
> I first learnt about this when I used the DOS port of gcc (DJGPP). This
> compiler has a 32-bit DOS extender, and a flat memory model. There's no
> way that the libraries compiled under that compiler are going to be
> compatible with anything from Borland, Microsoft or Watcomm. So the name
> mangling is different, just to protect the careless. It actually
> explained this point in the documentation.
Not necessarily so. If the compiler has no pragmas or switches that
permit
it to be compatible with another compiler, then you're right. But that's
the fault of gcc, not a reason for incompatible name mangling.
> Igor Siemienowicz
> ig...@adacel.com.au
John Saunders
j...@jws.ultranet.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Albert Kanze
na...@netcom.com (John Nagle) writes:
|> >That's not correct. Using standard Pascal, you can write wherever
you
|> >want in the process' address space, but it's intentionally awkward
--
|> >to do pointer arithmetic in standard Pascal, you must use
typecasting in
|> >the form of variant records, e.g. (assuming an integer is the same
|> >size as a memory address, which is part of why it's ugly!)
|>
|> There is that, although you have to work hard to break the type
|> safety. There have been implementations, like Berkely Pascal, that
|> didn't let you coerce pointers that way. In Pascal, though, it
|> is defined as an error to do that; ref. "Standard Pascal, User
|> Reference Manual", by Doug Cooper, ISBN 0-393-30121-4, page 112.
|> He even writes "A high quality processor will detect the trick
|> (after all, it's an error) and disallow it." In C and C++, it's
legal.
I believe that the Pascal standard requires to tag to be checked. (Of
course, I don't think any of the Pascal compilers implement the
standard:-).)
And this behavior is also illegal in C++; it is called undefined
behavior. So, although I wouldn't swear to it, I believe that a C++
compiler would be free to generate a tag, check it, and treat an error
as an error. (This could be more difficult than it sounds. If memory
serves me right, the C standard requires sizeof a union to be equal to
sizeof its largest member. This makes finding space for the tag
somewhat more difficult.)
--
James Kanze home: ka...@gabi-soft.fr +33 (0)3 88 14
49 00
office: ka...@vx.cit.alcatel.fr +33 (0)1 69 63
14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg,
France
-- Conseils en informatique industrielle --
Valentin Bonnard
{Please don't overquote. -mod}
Scott Ellsworth wrote:
>
> In article <58davc$s...@netlab.cs.rpi.edu>, ka...@vx.cit.alcatel.fr wrote:
>
> >hel...@utdallas.edu (Steve Heller) writes:
> >
> >> That's why I don't teach my students to use pointer arithmetic
> >> (other than when accessing array elements inside class
> >> implementations) or casts.
> >
> >Excellent. I agree wholeheartedly. So what do you do if your
> >"students" are experienced C programmers, who are convinced that this is
> >the only way to go?
>
Ok, but anyway, this has nothing to do with C, C++, Ada 9X or Prolog:
if one programmer add a constraint on a data and don't document that/
don't put an assert to check it at runtime, and if annother one change
the data so that this constraint isn't meet, then some time can be
lost.
This is a problem with assertions and well-defined interface.
> The moral:
> 1. Using an old style cast can produce code that a reasonable code
> change later will break.
>
> 2. Using a standard unwrapped C array can give you enough rope to
> hang yourself.
I don't see why that follow.
The old style cast meant static_cast; it was less obvious for a person
who doesn't know all the definitions, but it was just that.
The 'unwrapped C array' could just be replaced by a vector.
The readers of this example shouldn't think that all arguments for
vector or new style cast are meaningless like this one.
BTW after some thinking I really don't understand why people are
against pointer arithmetic; some people are even against C because it
supports ptr arithmetic !!!
(OTOH C arrays have some strange (ie not-easy-for-begginners)
properties)
--
Valentin Bonnard
mailto:bonn...@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
Tim Ottinger
Philip Walden wrote:
> >
> > Compare that to C++, where none of those facilities are standardized,
> > and where programmers are placed completely at the mercy of the
> > operating system vendor for anything more than very basic I/O
> > functionality. Furthermore, C++ name mangling also effectively
> > locks users into a single compiler vendor on many platforms.
>
> A while back in another thread, proprietary C++ name mangling was
> described to me as a benefit to protect me from mixing mutually
> incompatible abi's. The abi's were incompatible as each C++ vendor
> attempts to optimize for their machine/market.
First off, C++ has not only the iostreams and STL, but there is quite
an industry in 3rd party class libraries, free and commercial. Rogue
Wave, for example, covers many platforms with considerably more than
simple containers and basic I/O. There are plenty of persistence libs,
lots of UI stuff, gobs of numerical processing libraries, networking
class libraries, and the rest. I actually don't use my hardware
vendor for much of anything but the compiler. Mainly because I have
several hardware vendors.
Secondly, the proprietary C++ mangling is a fine thing. For C++ to
be compatible across platforms, you only have to be able to compile
it in each place. You don't have to be able to link x86 objects with
HP/UX shared libraries, nor do you have to be able to link GNU and
HP code together. If you can compile and link your apps and libraries
on multiple compilers by multiple vendors, then that's close enough
for me.
Cool?
--
********************************************************************
In some sense, all of life is design. The way we pick our friends,
the way we plant a garden, and the way we choose software is all
design. Sometimes we do things by habit, other times by carefully
weighing the pros and cons, and sometimes we make experiments.
-- Ralph Johnson --
Tim Ottinger
Hi all.
And first: yes, I really like C++.
Steve Heller wrote:
>
> rsro...@wam.umd.edu (Robert Rodgers) wrote:
> >I do my best to avoid memory leaks -- I did before using GC, and I
do
> >it by design even while using GC. I use smart pointers, I use
> >carefully designed containers, keep things simple, and I usually (as a
> >backup measure) put as much as humanly possible on the stack (I wish
> >they would teach this last one -- it's not ideal, but it sure as heck
> >eliminates 90% of the hassle that people get from new & delete).
>
> I believe that eliminating any visible pointers is better than using
> smart pointers. The polymorphic object idiom allows this in most
> cases that are likely to occur in the real world. As for "putt[ing] as
> much as possible on the stack", I teach that way. In fact, I tell my
> students "don't use pointers except in infrastructure class
> implementations".
>
> >But there's always something, especially if you use a lot of third party
> >libraries (I do) and if you want to have a very lengthly runtime (days
> >or weeks -- I do).
>
> The third party libraries are indeed a problem. However, if the
> problem is forgetting to call their cleanup routines, it should be
> possible to write a class wrapper that will make sure that happens.
> Otherwise, they're buggy, and should be suspected of having other
> things wrong with them than just memory allocation.
There are real problems to overcome in many frameworks that are worth
mentioning. In a lot of MFC code, for example, the normal idiom is to
create the objects on the heap as-needed, and tie their life to the
object lifetime, not the function lifetime.
Using the idiom means that you have to have smart pointers, and not
using it means that you may confuse old MFC programmers. Now, we could
maybe get around it by creating class member variable objects and try
to use those instead of creating the objects on the fly, but I've just
not seen people trying to do it.
But I'm willing to break with dumb traditions, and maybe this is one.
And you're right about 3rd party libraries. When we use bounds checker
or purify, we find that the code we write is considerably safer than
the code we rely on from 3rd parties. It makes you consider not using
anything that doesn't have the 'purify'd' label on it.
--
Tim
tott...@dave-world.net
David A. Cuthbert
[regarding the int const * a, b example]
J. Kanze <ka...@gabi-soft.fr> wrote:
>This said, I consider the above example a red herring. Of course you
>can write confusing and unreadable C++; I don't think anyone could
>reasonably say otherwise. But no reasonable software engineer is going
>to declare two variables in the same statement, regardless of what the
>language allows. Since this particular case doesn't occur in well
>written code, it doesn't bother me.
Hmm... I must have missed this bit somewhere along the line. I often
use a construct like "int x, y" to declare a coordinate or "color fg,
bg" to declare a text attribute, etc. (I intentionally do not use
pair<> because its member names can easily get confusing, and writing
a class when I need this for a single function seems... well, silly,
and an additional class to debug.) Declaring multiple variables seems
reasonable (and, IMHO, preferred) when they are somehow linked. I
fail to see how this is an unreasonable practice.
Nonetheless, I have to admit that I fail to see an example where I
will have two pointers to const int that are somehow linked. *Maybe*
as iterators, but I would call that IntList::iterator begin, end; and
I don't have the syntactical problem here. I was bitten (well,
nipped) by a char * problem in some quick test code I did recently,
but I wouldn't have coded that the same way for anything even
marginally beyond that test.
>I think that most people would agree that the C++ declaration syntax
>isn't the most intuitive.
I often wonder what C++ would be like if it didn't retain the C syntax
(or at least compatability with it). I think Stroustrup mentioned in
D&E something about Algol68, but I'm not familiar with that language.
Ah, well... a bit of C++'s success does stem from its C compatability.
I suppose that we're stuck with everything that entails, good and bad.
--
David A. Cuthbert Graduate Student, Electrical and Computer Engineering
da...@andrew.cmu.edu Carnegie Mellon University