Widespread C++ Competency Gap?
Bjarne Stroustrup <9758-26353> 0112760
This message is a response to a lot of outrageous inaccuracies, innuendo,
rudeness, and flat-out false statements about C++ and its user community.
The most dignified response would be a solid technical paper documenting
the beauty and power of C++. However, people who believe even part of
the rubbish posted about C++ will be unlikely to invest the time to get
hold of such a paper and read it. In fact, the stated purpose of some
of the worst postings has been to warn people against gaining an under-
standing of C++. Also, there is no shortage of material describing C++
and its uses. Consequently, I chose to respond directly.
I consider a large portion of the bashing of C++ and the C++ users
unwarranted, ill-informed, self-serving, and intellectually dishonest.
Sadly, one must expected some mud to be thrown at anything successful,
but I think some posters have gone too far in their attacks on C++.
Please note, that I am NOT claiming C++ is perfect, that I am NOT
saying that every critic of C++ is dishonest or ill-informed, that
I'm not suggesting people should stop discussing C++'s strengths and
weaknesses (where relevant), and that I am NOT telling you to stop
using your favorite programming language and use C++ instead.
I am asking people to clean up their act, to be honest and up-front
with their aims and motives, to refrain from unsupported derogatory
statements, to avoid ``have you stopped beating your wife'' style of
demagogy, and to get a minimum of acquaintance with C++ before
starting to give advice (positive or negative) about it.
If you - like most people - have not been engaging in disreputable
debating practices, please don't take offense from my words; they
are not aimed at you.
And do, please do, learn not only C++, but also other languages,
systems, and techniques that might be helpful to your work and
intellectual growth. A closed mind is a recipe for bigotry.
Personally, I have found many stimulating ideas in Ada, Algol68,
CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
written in those languages. For most of the kind of work I do,
I prefer C++, but I have never found learning a new language
unrewarding. The thing to remember, though, is that a programming
language - any programming language - is a means to an end (the
building of systems), rather than an end in itself. Considering
how to build better systems and how various languages can serve
that end is a much better use of time than fighting language wars.
Please remember that a system can be ``better'' according to many
different criteria. The particular purpose of a system together
with the particular context of its development often have decisive
effects on the judgement of a system by its builders and - more
importantly - of its users.
Below, I present abbreviated versions of common unfair attacks on C++
in quotes and then comment on them. Naturally, I try to make my comments
helpful to people suffering from the root causes of those of the attacks
that have a basis in reality rather than being just manifestations of
commercial or intellectual rivalry.
``C++ sucks''
If you think so, go use what you consider better. It may indeed
be better than C++ for your purposes.
C++ is a very useful language that is used successfully by MANY
people in MANY application areas. I guess that is a large part of
what bothers some. By being successful, C++ offends many who
have strong notions of what else ought to be successful.
The major cause of complaints is C++ undoubted success. As someone
remarked:
There are only two kinds of programming languages:
those people always bitch about and those nobody uses.
C++ isn't perfect. That is well known and acknowledged from the
start. It is, however, a reasonably carefully thought-out language
where the design is based part on acknowledged principles and part
on solid experience and feedback from actual use. See my book
``The Design and Evolution of C++'' for an exposition of the aims
of C++, the design process that led to the current language, the
reasons for particular design decisions, etc.
I wish I had an electronic equivalent to a little duck-horn,
so that a rude BEEP was triggered by every unsupported derogative
statement about C++. The noise would be deafening, though.
An increasing number of people seem to relish displaying their
ignorance and poor manners by snide remarks and gratuitous
inaccuracies.
At a recent conference, a speaker asked for a show of hands and
found that twice as many people claimed to hate C++ as had ever
written even a single small C++ program. The only word for such
behavior is bigotry. In dealing with the current wave of C++ bashing,
we should remember that bigotry is bred by ignorance and fear.
It should also be remembered that if bigotry is not opposed but
allowed to fester and sow distrust real harm results.
``C++ is too complex''
C++ is much more complicated than, say, C and Pascal. However,
MANY have succeeded in learning and applying C++. It has been
demonstrated again and again that you don't need to be a genius
to learn C++ in a reasonable time or to use C++ well. Further,
it has been demonstrated that there are several distinct ways
of reaching that level of competence.
So, what about C++ is hard to learn, and why? Someone knowing C
well can learn Pascal in a week - and vice versa. Becoming expert
- that is, learning to avoid the more common pitfalls and using
common idioms of the new language - is harder. It could even take
a couple of months. The reason for the easy transition is that
the languages are fundamentally similar. All that needs to be
learned is a bit of syntax and a few simple ways of using the
new syntax. Often, this can be learned from looking at the briefest
description of the language and some code. The time and effort
needed is a small fraction of was originally invested in becoming
an effective programmer.
This is where C++ is different. The key concepts of data abstraction
and object-oriented programming are new to most people. Yes, these
days most people have heard about OOP, but most have no practical
experience with it and can no more do a object-oriented design than
swim or bicycle based only on having read an article on the subject.
You can use C++ effectively as a more strongly type checked C with
a bit of simple data abstraction and library use thrown in after
a week. However, becoming comfortable with OOP/OOD takes most people
much longer. Estimates of six to eighteen month for becoming really
proficient are often quoted, are in line with my personal experience
with new C++ projects, and are in line with experience with other
languages supporting OO.
That demonstrates that the problems with notation and other language-
technical details are minor. They are typically overcome within weeks.
The real problems - as with any language - are conceptual: How to make
a good design; not (just) how to express it.
The much touted problems with readability are again vastly overstated.
You can write obscure code in any language, and significant programs
in a language you have only superficial knowledge about are always
unreadable - especially if prejudice prevent you from actually
trying to overcome notational barriers. A major part of readability
is simply familiarity and experience.
The idea that a manager or a complete novice in a language can come
even close to comprehending a significant program because some inherent
virtue of a particular language is nothing more than marketing hype
and self-delusion. When people make such claims I wonder what else
they might believe or be willing to claim.
So why do reasonably clever and experienced people sometimes fail
to learn C++ or fail to use it effectively after they have supposedly
learned it? Usually because they have the wrong expectations. This
actually has to be the case because I haven't found any strong
correlation between what we could call smarts and becoming good
C++ programmers. Some really clever programmers fail, and some
supposedly mediocre ones succeed spectacularly.
The ones that fail are usually the ones who believe they know
everything already. Coming to C++ with a ``C is THE language''
or ``OO means Smalltalk'' attitude is a recipe for failure.
You can write in an (almost) pure C or (almost) pure Smalltalk
style in C++, but that usually is not a good use of C++. Doing
that involves a constant battle with the fundamental concepts
of C++ and with the C++ type system. Against the fundamental
structure of a language - any language - you can win Pyrrhic
victories only.
Another mistake is made by people who firmly believe that THEY
don't need tutorial material. ``Real programmers read only code
and reference manuals.'' That attitude is a recipe for disaster
with C++. Undoubtedly, someone can learn OOP from reading code
- after all Alan Kay (partly) learned OO by deciphering an 80
page Simula program thinking it was Algol. However, most people
are not in the same league as Alan.
Experience shows that trying to learn OOP or C++ from the ARM
(``The Annotated C++ Reference Manual'') is usually a BIG mistake.
It is a nice book, I can recommend t (:-), but not as a tutorial.
After all, most people wouldn't try learning a natural language
exclusively from a grammar plus a dictionary. Few would succeed.
Naturally, I recommend my ``The C++ Programming Language (2nd
edition)'' for learning C++, but there are many other good books
out there, and my book is not the best tutorial for everyone.
Take advice from others who have succeeded in becoming good C++
programmers (rather than from self-proclaimed C++ haters or people
without ractical C++ experience). It is a curious phenomenon to find
self-proclaimed C++ haters trying to cash in on C++'s popularity
by teaching C++, writing articles on C++, and even by writing
C++ textbooks as their first C++ project.
Whatever you do, focus on concepts and design issues rather than
language-technical details. The details will come in time provided
the basic concepts are there. Try to avoid relying exclusively on
``how-to manuals'' and ``handy-hints books.'' I have even noticed
people on the net who clearly were trying to learn C++ without any
textbook or reference manual; such an effort must be most frustrating
and have a low probability of succeeding. It is also a sad waste
of time even if it - against all odds - should succeed.
Another thing to keep in mind is that C++ is not Windows, Unix,
X, MacApp, Etc. These systems have their own logic and complexities
distinct from those of C++. Simultaneously trying to learn event-driven
user interfaces, distributed computing, OOD, and C++ is definitely
hard. However, C++ is often the least complicated entity in such a
collection of concepts/tools/systems/libraries. Blaming C++ for the
complexity of a system used through it is not quite fair - even if
C++ and its various program development environments are the most
visible and tangible part of such a system.
The bottom line is that the world is VERY complex, and to some
extent the tools we use reflects that. Among the tools we use,
C++ is nowhere near the most complex.
Whatever the reason, and contrary to the popular doomsday scenarios,
most programmers who genuinely try succeed in becoming productive C++
programmers in a reasonable time.
``C++ programmers are idiots''
When C++ was new, one of the things that pleased me most was
that discussions about C++ were so much better informed than
discussions about most other languages, that the understanding
of key concepts were so much better in C++ groups than in, say,
C and Pascal groups, and that groups such as comp.lang.c++ were
so much more polite and supportive than that of other groups.
Clearly, I thought naively, C++ attracts a much better class of
programmers, learning C++ helps people to absorb the key concepts
of good programming/design, and the resulting success makes people
more tolerant and helpful.
I was wrong. The phenomenon was real, but it had little to do with
C++. In a small dedicated community, life is relatively easy. people
do their homework, people have access to reasonable sources of
information, gross errors and misconceptions are corrected before
they can cause significant harm, compilers and teaching materials
are up-to-date, etc.
This is not and cannot be the case in a multi-hundred-thousand
member community: Some will be taught out of outdated or unsuitable
books, some will use antiquated compilers and tools, some will
be taught by charlatans, some will be remote from current and
reliable news-sources, some will have unsuitable rules and
regulations imposed on their work, etc. Also, in a rapidly growing
community, most users will be novices.
Does this make C++ programmers idiots? or ``on average idiots?''
Not at all, but the average C++ programmer is not part of a
relatively closely knit elite with access to the latest
information and tools. Neither is the average C++ programmer
someone with a lot of spare time for study and stimulating
intellectual debate. When the number of any group goes up,
the average - in every way - MUST converge towards the industry
average.
Proponents of languages that still have relatively minute - and
therefore relatively close-knit and well-informed user communities
- are making the mistake I made: seeing the evident success and
enthusiasm of their fellow ``cult members'' as a direct consequence
of qualities of their favorite language. They are wrong; if - against
all odds - their language should escape into the mainstream the
vastly enlarged user community will get its share of the problems
and failures.
Many of C++'s problems are best ascribed to problems with the scale
of the user community and the scale of the problems attacked - as
opposed to problems with the C++ language design.
Many of the most experienced individuals and organizations in the
industry (and academia) use C++. Ascribing their choice of C++ over
alternatives to stupidity, ignorance, or inexperience is arrogant
and insulting - and in many cases simply wishful thinking based on
a limited field of knowledge.
I still think the average C++ programmer is pretty smart, but rarely
a fanatic, and usually too busy getting the work done to bother with
language laws or the latest academic advances in OO type theory.
Fortunately, one doesn't need to be a genius to write good C++.
``C++ is just C, but worse''
C++ can be used just like C, but it doesn't have to be and in general
it isn't. Many (most?) people start with C++ as a more strongly type
checked versions of C, use libraries, add a bit of data abstraction,
and then progress to a more complete and effective use of the C++
specific features. That is in my experience a good way to progress,
especially if you are not in an environment where genuine experience
with OO in C++ is available and supported by management.
One effect of this gradual approach is that as long as the number of
C++ programmers and C++ projects is growing rapidly, much (most?)
C++ code will be written by people at the beginning of their personal
or organizational learning curve. Their code will reflect it.
However, this situation does not last - however much as detractors
would like it to. All the personal and indirect experience I have
indicates that people are moving right along as expected.
Talking about C/C++ as if it were one thing and ascribing every
weakness of C and negative past experience with C to C++ is just
plain wrong. personally, I take most uses of the compound ``C/C++''
as an indication of ignorance.
Considering C a smaller, faster, and better specified alternative
to C++ is another popular fallacy. The C-like subset of C++ is as
fast, as well specified, and easier to deal with than C itself.
One source of popularity of this fallacy is an unwillingness
by some C/Pascal-level programmers not to learn something really
new. Another is wishful thinking by some proponents of more
advanced languages: after all, if C++ is simply a more complicated
C it cannot be a serious competitor to a more advanced language.
``C++ is useless/unreliable/dangerous because it lacks feature/property X''
Also heard as ``you can't write real/reliable/maintainable/elegant/
re-usable/object-oriented/modern software without feature X - and C++
doesn't have X.''
Bosh!
Once you - as many - have seen a few dozen large industrial C++
projects completed on time, as budgeted and going through maintenance
as hoped for, clever arguments based on the necessity of individual
language features - invariably features absent in C++ - lose
their credibility. Such arguments remain interesting sources for
ideas for improvements of C++, but their central sales/propaganda
message is fundamentally discredited.
Over the years C++ has been deemed useless because it lacked
(among other things) type checking, metaclasses, multiple
inheritance, garbage collection, generics, concurrency support,
exceptions, co- and contra-variance, dynamic linking, typecase
switches. Simultaneously, if was - often by the same people -
deemed useless because it was too complicated and had too many
features. At the same time, a steady and increasing stream of
projects were successfully completed in C++.
My firm conclusion is that no single feature is truly necessary.
Much more successful software has been written in languages proclaimed
BAD, than has been written in languages acclaimed as saviors of
suffering programmers; much more.
Also, each time C++ has acquired another feature - according to my
original view of how the language should evolve - the absolutely
essential feature people used as proof of C++'s fatal weakness
changed.
The real driving logic seems to be:
If feature X is in <<favorite language>> and not in C++,
it MUST be fundamental to <<favorite buzzword>>.
That is backwards and illogical, but it makes commercial and
psychological sense. After all, if <<favorite language>> didn't
have such a killer feature arguing against C++ in a simple-minded
manner could be unpleasantly hard. One of the oldest and most
disreputable tricks in the book is to define OO so that <<favorite
language>> and no other language really supports OO. Since every
neat feature can be illustrated by a neat example that can't be
done without some ugliness in a language that doesn't have the
feature, the redefine-OO trick always takes in a few suckers.
Fortunately, these ``neat features'' rarely prove as essential in
practice as their proponents claim they are in theory.
If no feature is essential, then why use any features? You can in
theory write anything in machine code, and apparently get anything
to work in the real world using C. However, why should you where
there is a better alternative available? Many people strongly
prefer C++ over procedural languages such as C and Pascal and
deem the feature set provided by C++ close to essential for
their applications. A feature need not be essential to be helpful.
The set of features provided by C++ is such that aspects of
most major features get used in most major programs - directly
or indirectly.
I do not consider the set of features in C++ excessive; where a
genuinely needed feature is missing from a programming language,
the result isn't that the programmer has to understand less to
work on a system; the result is that the complexities gets represented
in the code itself rather than in a common form in a programming
language. A major benefit of supporting a feature directly in a
language or in a standard library is that much of the effort needed
to understand one system will pay off when looking at another
system where similar language and library features have been used.
Such benefits are far harder to achieve when mechanisms are provided
through code in a simpler language.
Remember that many C++ features are there primarily to allow library
building. Not every feature needs to be used directly by every user,
nor does every feature have to be examined in detail by every tutorial.
``C++ is not Object-oriented''
C++ supports object-oriented programming (as defined by most
people). C++ supports it pretty well for real-world applications.
Its type system and general model of the world are coherent and
relevant to real applications.
The proof of the pudding is in the eating, so I consider the fact
that many large projects have been completed using C++ much more
significant than the fact that C++ doesn't conform to the latest
fashion of OO theology.
Have a look at the ``Design Patterns'' book by Gamma et.al. for
examples of elegant designs clearly expressed in relatively
straightforward C++.
I observe that there are a lot of myths about what features C++ has
and doesn't have, and also about the essential soundness of the
features that people (mostly) agree that it does have. Many posters
and even many writers of academic papers really ought to update
their knowledge of C++. It would be unfair to seriously complain
just because someone didn't know about a feature added to the
upcoming C++ standard sometime during the last year or a feature
for which an implementation wasn`t generally available. However,
I see claims based on the 1985 edition of ``The C++ Programming
Language.'' That - especially when comparisons are made with
experimental languages - is totally misleading. Doing so in 1994
is intellectual sloppiness bordering on dishonesty.
If comparing C++ to a widely distributed language, at least try
to compare to C++ as distributed over the last few of years (say,
as described in the 1991 2nd edition of ``The C++ Programming
Language.'' If comparing with an experimental language. Try to
get up-to-date information - say ``The Design and Evolution
of C++'' or the C++ standards committees working paper. ``The C++
Report'' and other magazines tries to keep their readers informed
and tend to be only a meeting or two behind the committee. Simply
relying on hostile hearsay from the net is not respectable.
``C++ compilers/tools are too buggy''
Yes, but they are getting better.
Yes, but compilers/tools are never quite good enough.
Yes, but they have - often just barely - been good enough for real work.
Yes, but they are still better than the alternatives on many platforms.
Most importantly, C++ and its various implementations have a solid
core where different compilers tend to agree and where the code
generated is reliably good. There are several ways of looking at
a language. If your job is to write a test suite or your aim is
to ``push the envelope'' of what can be done, you hit a lot of
annoying bugs and variation between implementations. If your job
is to build systems, you try hard to avoid the grey areas - and
often succeed.
By and large, C++ compilers have been ``ok but not great'' according
to the standards of their community. Some have been better. Now that
the rate of language changes has decreased, I expect to see significant
improvements in quality; in fact, I think I'm already seeing signs
of that.
C++ tools are improving in general: For example, I had expected it
to be years before I saw a C++ debugger that allowed you to stop
a program at a breakpoint, rewrite a function, and then restart
the program using the new function. Sun now sells a C++ system
handles does that. Another example of the improved state of affairs
is the wide availability of memory-leak detectors, simple browsers,
and other useful program development tools.
``The C++ standards committee is out of control''
(whatever that means)
First of all, you can't believe everything you hear on comp.lang.c++,
comp.std.c++, etc. In general, such forums are noisy and dominated by
a relatively low number of people with strong opinions and relatively
few restraints on expressing those opinions. If you consider the net
in any way representative, you can get a spectacularly warped view
of the world.
Facts:
Most proposals for language extensions are rejected.
Most proposals for changes are rejected.
Most accepted changes and extensions are minor.
The committee is working on a rather tight and definite
schedule (Committee draft and US public review
early in 1995, final vote as soon after as ISO
rules allows for).
The committee is working of a schedule as tight as
that of other language standards (e.g. C and Ada).
Most members of the committee are honest, competent,
and hardworking individuals.
Most members of the committee would rather see
a finished standard and get on with something else.
The committee is responsive to events and opinions in
the C++ community at large - partly through the
organizations the members represent and partly
through a general willingness to listen and explain.
Many members help popularize the deliberations and
decisions of the committee (but it is hard to
reach a large and diffused user community - see
messages on the net, magazine articles, conference
talks, etc.).
If you can, come to a meeting and see for yourself. There is no fee
for attending a single meeting and you don't have to represent anyone
to visit. Reasonably enough, you can't vote at your first meeting,
though. Some members may show impatience if you try to take precious
committee time without having done your homework, but you can listen
and there are lots of time to discuss things outside formal sessions
of the committee as a whole.
Currently, work is focused on clarification and on libraries.
Just one language extension has been approved during last 8 months
(adoption of the keyword ``explicit'' to suppress use of a constructor
for implicit conversion) - and that's a restriction.
Much work has been done on details of name lookup, overload
resolution, the type system, the memory and object models, etc.
The major event in the library area was the adoption of the STL
library in response to demands for containers, etc.
It might be worth mentioning that two things are happening at once:
Compilers are being developed and distributed at the same time
the language development is continuing. Whichever order those two
things happen in, *someone* will complain. Moreover, if language
development stopped, people would complain too. Already, some
people are complaining because the rate of language change has
slowed to a crawl.
I find it blatantly unfair when posters use strong words against
``the committee'' because it is a nebulous concept like ``the
bureaucrats.'' The committee consists of hardworking individuals
most of whom just happen to be unable to respond to comments in
various forums. Suggestion: Don't post anything about the committee
that you would be ashamed saying to me face-to-face in public.
Also, please remember that the committee members are all volunteers.
``I have heard of lots of C++ disasters''
- and senator McCarthy had heard of 200 communists in the US state
department; he even claimed to have a list in his pocket.
There were a month-long thread in comp.lang.c++ and elsewhere
headed ``C++ disasters.'' In fact, no genuine C++ disasters were
documented. There were lots of statements on the form ``X failed
and they might have used C++'' and ``X was in trouble and they
used C++'' but I didn't see any message making a causal link
between C++ use and failure plausible. C++ was being blamed for
everything from the collapse of the US phone system (it didn't
collapse and the breakdown people keep referring to occurred in
a system not written in C++) to the Denver airport baggage
handling system (there were/are a bit of C++ in that system but
not anywhere near as much C++ as C and assembler). By the quality
of the ``logic'' applied it is a marvel that C++ wasn't also
blamed for the (possible) crumbling of the runway surface.
Genuine C++ failures must occur. After all, when a lot of people
try some non-trivial new tool - any new gadget - some will ``fail.'
I think it would be fair to guess that 10% to 20% will miss the
point, find the tool not to their taste, fail to use it correctly,
apply the tool in an area that it is unsuited for, etc. By that
logic and the sheer weight of numbers we must conclude that more
programmers have had some failure learning or using C++ than have
tried any other OO language. This would explain the emotional heat
of some criticisms of C++.
Many more have succeeded with C++, though, and most failures must
have occurred on a small scale or we would have heard much about
them - people tend not to be shy about publishing other people's
failures (even in an ideal world that would be bad taste). I see
no evidence that projects using C++ have a greater failure rate
than projects in general. In my limited experience, the opposite
seems to be the case, despite that C++ appears to be used on a
disproportionate number of ``ambitious'' projects. I take this
as a testimony to people's good sense, to C++'s flexibility, and
to the fact that strong core of genuine C++ experts have always
recommended caution in the adoption of C++ and new techniques.
On the other hand, the C++ community is somewhat to blame for not
doing more to publicize their successes. As usual, the C++ community
is anarchic and possesses no central focus - such as a single users
group or a central coordinating organization. Usually, that is an
advantage because it helps foster initiative, but when it comes to
collecting and dispensing information the C++ community is at a
disadvantage compared to communities focused of a single central
company or organization. It would be a major benefit if someone
would collect - and make easily available - brief descriptions of
a couple of hundred C++ projects of significant size.
``I just don't like C++''
Fine. There are lots of things I don't like. Sometimes, I object
to aesthetic aspects; sometimes something just doesn't serve my
needs. If asked, I may even express my negative opinion, but rarely
rudely, and never as an unprovoked attack or a snide remark about
other people's work. If I am perceived to do so by lack of
consideration or I slip up (nobody is perfect), I apologize.
I don't apologize for C++, though. I find C++ the best choice for
a wide range of applications. If you can find the time, I encourage
you to try to find out why that is. Many have found the effort
worthwhile.
I wish more people would distinguish between an expression of
personal opinion/taste (such as ``I just don't like C++'') and what
is claimed to to be an expression of objective fact (such as ``C++
sucks''). It seems to me that a significant number of posters have
difficulties distinguishing their personal opinions from objective
facts.
Live and let live is a good policy. Spending a lot of emotional
energy attacking other people's work is unhealthy.
Final comment:
In this note, I didn't try to present technical arguments
for (or against :-) C++. You can find many of my technical
arguments and opinions in my books and papers. Other good
sources of information about C++ and its use are the proceedings
of the USENIX C++ conferences, ``The C++ Report,'' Andy Koenig's
column in JOOP, and (to a lesser extent) the OOPSLA proceedings.
I encourage the C++ community to make a greater effort to document
work done in C++ and make such information more generally available
(that is, not just preaching to the choir).
In general, I encourage people to popularize their favorite
programming system through solid examples, rather than by
merely scoring points off imagined opponents by clever programming
tricks or demagogy.
In general, try to be a bit more tolerant and refrain from
hyperbole. We need an intellectual honest discussion and a
greater degree of professionalism in the discussion of
programming and programming languages.
- Bjarne Stroustrup
John Carson
: This message is a response to a lot of outrageous inaccuracies, innuendo,
: rudeness, and flat-out false statements about C++ and its user community.
: The most dignified response would be a solid technical paper documenting
(long text message deleted)
I agree. However after reading a few of these message I just delete them
as noise. I have been teaching C++ for about three years now and have
also encountered some hostility toward the language. I find it comes
from people (I'm dealing with professionals here) who are scared when
they find that they can't quickly grasp the concepts necessary to design
and build classes. Since they can't understand the concepts quickly,
they need to blame something other than themselves so the language is the
obvious target. Upon working with these students I find they can't
really handle C either but they don't realize it because in C you can
avoid features such as structures and pointers and believe you are
programming in C.
I eventually attempt to demonstrate the value of C++ to these programmers
by giving them a typical software maintenance task. I have a simple
banking problem written both in C and C++. I ask them to add a few
features and they find they can upgrade the C++ version easily and the C
version is much more difficult. I explain that class design is very
sophisticated and not for everyone. However, once classes are designed
properly, the remainder of the programming chore is significantly easier.
On the other hand, many of my professional friends who did not like C and
would even choose Ada over C have embraced C++ and refuse to use anything
else.
I, too, get comments confusing C++ and Microsoft Windows. From the
programmers point of view the two may be one in the same.
Anyway, I'm not sure why people who do not like C++ take the time to read
these newsgroups and make such comments.
Regards,
John C.
Dr. Richard Botting
It seems to fit under the heading of C++ Competency.
I had students entering my classes from other institutions who consider
themselves experts in C++ and such like. I do not consider that I'm
an expert but I can hack up C++ code that implements a simple
set of objects/ADTS/classes/....
So I worry about things like this in their code:
All data members are public
The classes don't relate to reality as I recognize it.
A data member of a class declared as an array of pointers
to some objects, rather than an array of the objects.
(I think it is recodable with no hastle to run faster and
and with 50% less RAM...)
My question: Should I attempt to correct these habits?
And if yes.... How?
--
EMail: di...@csci.csusb.edu=rbot...@wiley.csusb.edu.
ftp://ftp.csci.csusb.edu/dick
<a href="http://www.csci.csusb.edu/dick/">WWW</a>
Disclaimer::=`CSUSB may or may not agree with this message`.
Copyright(1994)::=`Copy as long as you include this copyright and signature`.
Robb Nebbe
than your prefered language then you probably aren't competent
to comment on it.
Robb Nebbe
Igor Chudov
: I have had a new experience recently and would like a little advice.
: It seems to fit under the heading of C++ Competency.
: I had students entering my classes from other institutions who consider
: themselves experts in C++ and such like. I do not consider that I'm
: an expert but I can hack up C++ code that implements a simple
: set of objects/ADTS/classes/....
: So I worry about things like this in their code:
: All data members are public
: The classes don't relate to reality as I recognize it.
:### data member of a class declared as an array of pointers
:### to some objects, rather than an array of the objects.
:### I think it is recodable with no hastle to run faster and
:### and with 50% less RAM...)
: My question: Should I attempt to correct these habits?
: And if yes.... How?
Yes, except for the last one marked by '###'. Array of objects which can
have descendants will create hardly recognizable problems when you put a
descendant into an array and retrieve it as a parent (due to copy semantics
of an assignment to an array element).
----------------------------------------------------------------------------
IMHO. Igor Chudov, Resource Solutions Intl office (918)588-2309
Systems Engineer, for WilTel. home (918)585-5862
E-mail: igor_...@wiltel.com
http://m-net.arbornet.org/~ichudov
1819 South Jackson #32-P Tulsa OK 74107
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.
Dean Schulze
>I worry about things like this in their code:
>...
> A data member of a class declared as an array of pointers
> to some objects, rather than an array of the objects.
> (I think it is recodable with no hastle to run faster and
> and with 50% less RAM...)
>My question: Should I attempt to correct these habits?
There is at least one good reason to use an array of pointers to
objects instead of an array of objects. Each element in an array of
objects can only be initialized with the default constructor for that class.
So if you want to have some of those objects initialized with something
other than the default constructor you have to use an array of pointers to
objects instead of an array of objects.
Dean Schulze
Frederic Guerin
: This message is a response to a lot of outrageous inaccuracies, innuendo,
: rudeness, and flat-out false statements about C++ and its user community.
: The most dignified response would be a solid technical paper documenting
: the beauty and power of C++. However, people who believe even part of
: the rubbish posted about C++ will be unlikely to invest the time to get
: hold of such a paper and read it. In fact, the stated purpose of some
: of the worst postings has been to warn people against gaining an under-
: standing of C++. Also, there is no shortage of material describing C++
: and its uses. Consequently, I chose to respond directly.
[ ... ]
Let me put my 0.02$.
I admit that from time to time, I *disregard* some technologies ( e.g.
language or OS ). I know that this is not open-minded and regressive,
but what can I say, I guess it's human. BTW, I don't think something
being human means it is excusable.
This said, it seems that when people don't like a technology, they try to
rationalize their feeling. Some succeed, providing good argument, and
many don't and resort to fallacies like the ones the C++ language is
faced with in your message.
Now, if there are so many people that *disregard* C++, and if most of
their arguments are simply dumb, this is not sufficient to make them
*friends* of the C++'er class. We may postulate ( sorry for this 20$
word ) that there must be some deeper reasons that one don't want to
admit.
Popularity, of course, is part of the problem as you mention it.
A language becoming popular means for practitioners of some other
language, that they will get less job, find less reusable components
and poorer tools, etc. This is relative of course, of what they had
expected of the future before. This is a very bad news for them.
Also, for people that want to stay up-front of new software
breakthrough, there is a big chance that the *real stuff* will be
pioneered in the more popular language. Another bad news.
But why then do these people simply don't change their mind and adopt
the new language ?
Well, it is occurring right now. But this is painful. It requires efforts.
So we are screeming.
The fact is that here many people think C++ ask too much for what they
will be rewarded with. The language is simply too complex to use for
their needs. They don't want to bother with very low-level implementation
details, or very high level concepts for efficiency purpose which can
be pass-by in their favorite language. They are
amateur user and don't want to look all the time in their reference manual
to find the good syntax and semantic of a particular construct.
BTW, this is not a critique. It is just the statement that C++ is not
primarily targetted at occasional users. IMHO, C++ must go forward
and not change it's mind for that matter.
Moreover, as Bjarne said, it is not impossible to think of set of
libraries together with a framework and a good book to use a sort of
Easy C++. Not quite to remember, simpler semantic, etc.
I apology if I offended someone with those words.
********************************************************
BTW, I never had the chance to tell you ( Bjarne ) all my respect,
for your work, for your insight, and for the advancement in language
design you made. Thanks.
Frederic Guerin
Frederic Guerin
: This message is a response to a lot of outrageous inaccuracies, innuendo,
: rudeness, and flat-out false statements about C++ and its user community.
: The most dignified response would be a solid technical paper documenting
: the beauty and power of C++. However, people who believe even part of
: the rubbish posted about C++ will be unlikely to invest the time to get
: hold of such a paper and read it. In fact, the stated purpose of some
: of the worst postings has been to warn people against gaining an under-
: standing of C++. Also, there is no shortage of material describing C++
: and its uses. Consequently, I chose to respond directly.
[ ... ]
we will be rewarded with. The language is simply too complex to use for
David Siegel
>The most dignified response would be a solid technical paper documenting
>the beauty and power of C++. However, people who believe even part of
>the rubbish posted about C++ will be unlikely to invest the time to get
>hold of such a paper and read it.
Well, I believe most of the "rubbish" posted about C++, but I'd like to
hear the other side of the story. I'd be surprised to find it convincing,
though, since some of the frequently cited C++ "advantages" are unconvincing,
at best (compatibility with C and ancient linkers come immediately to
mind).
Nonetheless, I _will_ read such a paper, in the hopes of finding some
"beauty" I somehow missed.
>Personally, I have found many stimulating ideas in Ada, Algol68,
>CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
>written in those languages.
We agree on this.
>but I have never found learning a new language
>unrewarding.
I have (there are some _nasty_ 4GLs out there -- don't think I learned
anything from RPG, either), but it's usually interesting, especially
as you head away from the mainstream toward active research.
>Below, I present abbreviated versions of common unfair attacks on C++
>in quotes and then comment on them. Naturally, I try to make my comments
>helpful to people suffering from the root causes of those of the attacks
>that have a basis in reality rather than being just manifestations of
>commercial or intellectual rivalry.
> The much touted problems with readability are again vastly overstated.
My biggest complaint on this topic: automatic type conversion. I _really_,
_really_ hate compilers doing obscure things behind my back. The new
"explicit" keyword helps, but, of course, the default's wrong.
Why not make "explicit" the default, and require conforming compilers to
support a "default is implicit" switch? That should prevent breaking
the existing codebase.
> Proponents of languages that still have relatively minute - and
> therefore relatively close-knit and well-informed user communities
> - are making the mistake I made: seeing the evident success and
> enthusiasm of their fellow ``cult members'' as a direct consequence
> of qualities of their favorite language. They are wrong; if - against
> all odds - their language should escape into the mainstream the
> vastly enlarged user community will get its share of the problems
> and failures.
Valid point, but I think you're underplaying the problems stemming from
the interactions of novices and needlessly complicated languages.
-dms
Ed Cayce
> Dr. Richard Botting writes:
>>I worry about things like this in their code:
>>...
>> A data member of a class declared as an array of pointers
>> to some objects, rather than an array of the objects.
>> (I think it is recodable with no hastle to run faster and
>> and with 50% less RAM...)
> There is at least one good reason to use an array of pointers to
>objects instead of an array of objects. Each element in an array of
>objects can only be initialized with the default constructor for that class.
>So if you want to have some of those objects initialized with something
>other than the default constructor you have to use an array of pointers to
>objects instead of an array of objects.
I also use arrays of object pointers very often - For the reason mentioned
above, as well as avoiding hassles of linked lists/etc, when I have
objects that are not likely to be sorted, etc often. If I know I will
be having a set range of objects, maybe between 5 & 50, an array
of pointers doesn't waste too much space - and the access is quick,
& I can access them directly through an index.
I mean, 50 pointers is (usually) 50 * 4 = 200 bytes. Not bad.
--
The opinions expressed in this article are actually YOURS...
You just don't know it yet!
John Max Skaller
>In <D0Iys...@research.att.com> b...@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>
>Well, I believe most of the "rubbish" posted about C++, but I'd like to
>hear the other side of the story. I'd be surprised to find it convincing,
>though, since some of the frequently cited C++ "advantages" are unconvincing,
>at best (compatibility with C and ancient linkers come immediately to
>mind).
In that case you completely miss the point of C++.
Its _principle_ advantage is that it gains leverage off C.
That is why it is popular -- it preserves the large C code
base, programmer base, and it it permitted a portable
implementation to be written (CFront).
The issue here is not whether C++ is the best
language which one could design, but to design one that
was worth the effort working on -- that is, one which
would have widespread use.
>Valid point, but I think you're underplaying the problems stemming from
>the interactions of novices and needlessly complicated languages.
And you are ignoring the commercial realities of the
world. Bjarne tried to design a language which provided an
upgrade path which would ensure it's popularity and which
would introduce programmers to modern concepts.
And succeeded. Of course there is a compromise
in a language which supports both machine level programming
and OO!
--
JOHN (MAX) SKALLER, INTERNET:max...@suphys.physics.su.oz.au
Maxtal Pty Ltd,
81A Glebe Point Rd, GLEBE Mem: SA IT/9/22,SC22/WG21
NSW 2037, AUSTRALIA Phone: 61-2-566-2189
Kevlin Henney
>Well, I believe most of the "rubbish" posted about C++, but I'd like to
>hear the other side of the story. I'd be surprised to find it convincing,
>though, since some of the frequently cited C++ "advantages" are unconvincing,
>at best (compatibility with C and ancient linkers come immediately to
>mind).
We are developing a realtime system that must be portable across a number of
platforms conforming to the standard POSIX spec (the standard binding is in
C), the realtime POSIX spec/draft (the standard binding for which is in C),
accessing BSD sockets (the standard API defined in C), allow low level
access and run on systems that use standard UNIX linkers.
In this case there is no doubt that C compatibility is important; C++'s
high availability is also more than a little persuasive. For our purposes
Ada, Eiffel, Smalltalk and co are not even on the starting blocks.
+---------------------------+-------------------------------------------+
| Kevlin A P Henney | Human vs Machine Intelligence: |
| kev...@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd | |
+---------------------------+-------------------------------------------+
Martin Brunecky
> And succeeded. Of course there is a compromise
>in a language which supports both machine level programming
>and OO!
Right. Just call it properly "Object Oriented Assembly".
After all, "C" success was mainly to to the fact that it was
(and still is) mainly a "Portable Assembly".
--
>>> Opinions presented above are solely of my own, not those of my employer <<<
Martin Brunecky mar...@xvt.com (303)443-5130 ext 229 or 443-4223
Robb Nebbe
|>
|> We are developing a realtime system that must be portable across a number of
|> platforms conforming to the standard POSIX spec (the standard binding is in
|> C), the realtime POSIX spec/draft (the standard binding for which is in C),
|> accessing BSD sockets (the standard API defined in C), allow low level
|> access and run on systems that use standard UNIX linkers.
|>
The students in our software engineering course are doing a project that
is something like this. The have the Ada POSIX interface, all the realtime
facilities of Ada, an interface to BDS sockets that is much cleaner
than the C interface (written by two students after a semester of Ada)
and low-level access.
Now unless they are really ambitious they won't need the realtime
facilities or the low-level access to finish the project but they are
there to fall back on. The project will be distributed acrossed two
different types of machines and I wouldn't expect any difficulty migrating
to another architecture.
|> In this case there is no doubt that C compatibility is important; C++'s
|> high availability is also more than a little persuasive. For our purposes
|> Ada, Eiffel, Smalltalk and co are not even on the starting blocks.
I don't know about Eiffel and Smalltalk but Ada 83 works fairly well
for this kind of a project and the new revision of Ada works even
better.
Maybe I should change the thread to "Widespread Ada Competency Gap" :-)
Robb Nebbe
Barry Margolin
]
]>I worry about things like this in their code:
]>...
]> A data member of a class declared as an array of pointers
]> to some objects, rather than an array of the objects.
]> (I think it is recodable with no hastle to run faster and
]> and with 50% less RAM...)
]
]>My question: Should I attempt to correct these habits?
]
] There is at least one good reason to use an array of pointers to
]objects instead of an array of objects. Each element in an array of
]objects can only be initialized with the default constructor for that class.
Another reason to use an array of pointers is if you want to use the array
elements polymorphically. You can assign a Derived* to a Base*, and then
call virtual functions to get the overriding versions of methods defined in
the Derived. But if you have an array of objects rather than pointers, you
can't have Derived objects in the array. This loses much of the power of
OO programming.
--
Barry Margolin
BBN Internet Services Corp.
bar...@near.net
Zippy
backlash from those who are the victums of OO hype. Despite Brooks'
admonition that "there is no silver bullet," too many articles have
been written that describe how OO will save the world. Since C++
is an OOL, it has the responsibility to save the world. When people
discover that it doesn't make the task of programming something that
any idiot can do flawlessly, people are disappointed. Being people,
their disappointment may turn to vindictiveness. Their spite should
be turned agains those who made the inflated promises rather than
the language, but if they were the sort to engage in that sort
of reasoning, they would not have been taken in by the hype in the
first place.
Other examples of this process include COBOL, AI and 4GLs. COBOL was
to save the world because it would let managers understand what their
programmers were up to and all managers understood that the problem
with getting working code delivered on time was that programmers were
not being effectively managed. More recently, AI in general, and
expert systems in particular, was going to save the world because
declarative programming eliminates the need to say *how* to solve
a problem; one only need state the problem and the expert system
will produce the solution. (Or throw some data sets at a neural net
and let it learn the solution from them.) Next, 4GLs promised to
save the world: simple example programs showed how fast and easy
this approach is when compared to writing the whole example program
from scratch but these tools suffer considerably when given real
industrial-strength problems to solve.
These paneceas all overlook the fact that programming is and I suspect
will remain hard work that requires creative, intelligent and well-
trained practitioners to produce reliable results. "There is no silver
bullet" but there are tools that help. C++ is one very useful tool as
are Prolog, LISP and application generators. All of these must be used
for the correct reasons at the correct time to be effective.
For myself, both my productivity and quality doubled while constructing
my first large C++ program when compared to my previous experience with
the C lanaguage. Since this was my first production C++ program, I
did this while learning much of the language. The code proved to
be quite extendable; adding features to the program was very easy.
In short, I got what I wanted from the language. Perhaps my success
was due to the fact that I had already had several years experience
with OO before moving to C++. Data abstraction was by no means a new
concept.
Another thing to consider is our educational system. Almost every
programmer I've every worked with or spoken to on this subject
defines programming as coding. Analysis and design (and test)
are steps that are considered to be mere formalities and to be
eliminated whenever possible. I beleive that the reason for this
attitude is that from the start, our educators evaluate programming
students by running the code and comparing the results with expected
program output. Design documentation is not required and would not be
looked at if the student created it. By the time that a programmer
enters the professional ranks, the programmer has 4 years of
experience in doing it wrong. When presented with programming
techniques that require analysis and design, the typical programmer
is at a loss and turns this feeling against the tool.
Eric Peabody
U64...@uicvm.uic.edu
>I had students entering my classes from other institutions who consider
>themselves experts in C++ and such like. I do not consider that I'm
>an expert but I can hack up C++ code that implements a simple
>set of objects/ADTS/classes/....
>
>So I worry about things like this in their code:
> All data members are public
Also make all it a rule that any unused member fucntions will weight
against them ( in case they want a function which returns a pointer to a
member ).
I should point out that sometimes when the code is complicated
you may want to temporarily make the members public and then
change them to private after you get the code running and fix
access violations ( I recently had to this with something
invloving handle classes, friends and inheritence ).
> The classes don't relate to reality as I recognize it.
all over you (RHIP :) ).
I presume the focus of this class is C++ and not OOA/OOD. If so
I would just pioint out to the class that any classes they write
are probably not the best and that they would (eventually) learn
how to choose classes in a OOA/OOD class (pun not intended but apreciated)
.
> A data member of a class declared as an array of pointers
> to some objects, rather than an array of the objects.
> (I think it is recodable with no hastle to run faster and
> and with 50% less RAM...)
r or int and no virtual functions.
An array of pointers or references may be more appropriate if you
want the objects to behave polymorphically ( sorry I can't think of as better w
ay
to say this. Can anyone help on that point.)
>My question: Should I attempt to correct these habits?
( you shouldn't teach them how todress stylishly ( it's opinion)
and you shouldn't teach a college english student handwriting).
the question is will they listen. Yesterdqay I read an article
in the newspaper that said most colllge graduates can't read a bus schedual,
and I was recently told by a facultly member that he was told by a student
If I get an F it's your fault.
> And if yes.... How?
Mainly as style guidelines ( if you break them often your grade on a project
goes down).
------------------
Thaddeus L. Olczyk
>
>--
David Siegel
>In article <3cdnj2$q...@panix.com> dsi...@panix.com (David Siegel) writes:
>>In <D0Iys...@research.att.com> b...@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>>
>>Well, I believe most of the "rubbish" posted about C++, but I'd like to
>>hear the other side of the story. I'd be surprised to find it convincing,
>>though, since some of the frequently cited C++ "advantages" are unconvincing,
>>at best (compatibility with C and ancient linkers come immediately to
>>mind).
> In that case you completely miss the point of C++.
>Its _principle_ advantage is that it gains leverage off C.
>That is why it is popular -- it preserves the large C code
>base, programmer base, and it it permitted a portable
>implementation to be written (CFront).
It's principle distinction, anyway, and most of the reason the language's
so much uglier than, say, Eiffel or Modula-3. Advantage? A matter of
opinion, to be sure.
>Bjarne tried to design a language which provided an
>upgrade path which would ensure it's popularity and which
>would introduce programmers to modern concepts.
It's clear that was the attempt. The argument (at least, the sensible
part of it), is about whether the compromises overshadow the benefits.
-dms
David Siegel
>We are developing a realtime system that must be portable across a number of
>platforms conforming to the standard POSIX spec (the standard binding is in
>C), the realtime POSIX spec/draft (the standard binding for which is in C),
>accessing BSD sockets (the standard API defined in C), allow low level
>access and run on systems that use standard UNIX linkers.
The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
the features you mention as essential.
I've personally built real-time systems in Smalltalk, portable across
most major Unix platforms.
C binding and low-level access are _not_ sufficient reasons to use C++.
-dms
Jos Horsmeier
|Below, I present abbreviated versions of common unfair attacks on C++
|in quotes and then comment on them. [ ... ]
|``C++ programmers are idiots''
IMHO, I find people who are gifted with a spark of silliness or
lunacy quite a creative type of programmers if I may say so. This
doesn't just apply to C++ programmers. I consider it a pro if
someone happens to be `slightly idiot.'
kind regards,
Jos aka j...@and.nl
ps. No smiley here, I'm serious about this ...
m...@mole-end.matawan.nj.us
>
> This message is a response to a lot of outrageous inaccuracies, innuendo,
> rudeness, and flat-out false statements about C++ and its user community.
> I consider a large portion of the bashing of C++ and the C++ users
> unwarranted, ill-informed, self-serving, and intellectually dishonest.
> Sadly, one must expected some mud to be thrown at anything successful,
> but I think some posters have gone too far in their attacks on C++.
I've thought that for a long time, Bjarne, because they are abusing this
newsgroup (IMO) if for no other reason.
Let them spend as much ASCII bashing CLOS on a CLOS newsgroup, or Ada on
an Ada newsgroup, or any other language on its own ground. The result
will be a flurry of angry mail as the newsgroup is buried under their
postings, and enough of that mail will ring with outrage at their ignorance
that they might just think about it.
But C++ is large enough, and this newsgroup is busy enough, to survive
both their ignorant postings and the continuous flurry of FAQs from
newbies, so they get away with posting articles which ought not be posted.
--
(This man's opinions are his own.)
From mole-end Mark Terribile
m...@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
(Training and consulting in C, C++, UNIX, etc.)
Andrew Koenig
> > In that case you completely miss the point of C++.
> >Its _principle_ advantage is that it gains leverage off C.
> >That is why it is popular -- it preserves the large C code
> >base, programmer base, and it it permitted a portable
> >implementation to be written (CFront).
> It's principle distinction, anyway, and most of the reason the language's
> so much uglier than, say, Eiffel or Modula-3. Advantage? A matter of
> opinion, to be sure.
As is beauty. When one knows something well enough, beauty
and ugliness tend to give way to familiarity.
--
--Andrew Koenig
a...@research.att.com
Igor Chudov
: >We are developing a realtime system that must be portable across a number of
: >platforms conforming to the standard POSIX spec (the standard binding is in
: >C), the realtime POSIX spec/draft (the standard binding for which is in C),
: >accessing BSD sockets (the standard API defined in C), allow low level
: >access and run on systems that use standard UNIX linkers.
: The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
: the features you mention as essential.
How are you going to work with realtime with a system with garbage collection
(namely, Eiffel)? You don't have much control over GC to ensure that your
system will be responsive enough.
David Siegel
>How are you going to work with realtime with a system with garbage collection
>(namely, Eiffel)? You don't have much control over GC to ensure that your
>system will be responsive enough.
Exactly the way you do in C++ -- by being careful about the objects you
create and free (leave scope, release, whatever).
Given C++'s penchant for behind the scenes memory management, C++ is one
of the worst languages to use, if this is your yardstick.
-dms
Igor Chudov
: >How are you going to work with realtime with a system with garbage collection
: >(namely, Eiffel)? You don't have much control over GC to ensure that your
: >system will be responsive enough.
: Exactly the way you do in C++ -- by being careful about the objects you
: create and free (leave scope, release, whatever).
Oops - there is some gap or misunderstanding here. You can be very, very
careful about objects that you create. The minimal time your garbage collector
will work is proportional to the number of objects you use plus the number of
objects that the collector has to delete. It can't be less. It means that for
a realtime system there will me a minimal time during which your program is
blocked and cannot respond. Very often it is inappropriate for such systems.
This is very simple actually.
: Given C++'s penchant for behind the scenes memory management, C++ is one
: of the worst languages to use, if this is your yardstick.
What is my yardstick? More complex than yours, that's enough. It is probably
not good for a yardstick...
Paul R. Potts
sch...@asgard.lpl.arizona.edu wrote:
> There is at least one good reason to use an array of pointers to
> objects instead of an array of objects. Each element in an array of
> objects can only be initialized with the default constructor for that class.
> So if you want to have some of those objects initialized with something
> other than the default constructor you have to use an array of pointers to
> objects instead of an array of objects.
Very true! I use the array-of-pointers construct a lot in my coding.
I heard somewhere that an array version of the new operator that allowed
specifying a constructor to call for each object was being considered for
addition to the standard. Has this been adopted? It would certainly make
this kind of code cleaner.
-Paul-
--
Paul R. Potts - ppo...@frymulti.com - http://www.frymulti.com/~ppotts
Martin Brunecky
Where can I get an Ada compiler & debugger for Windows 3.1 or Windows NT 3.5
for say ... $300 range ?
Pete Becker
>
>>Bjarne tried to design a language which provided an
>>upgrade path which would ensure it's popularity and which
>>would introduce programmers to modern concepts.
>
>It's clear that was the attempt. The argument (at least, the sensible
>part of it), is about whether the compromises overshadow the benefits.
>
Obviously they do. That's why nobody uses it.
-- Pete
Carlos Perez
: Where can I get an Ada compiler & debugger for Windows 3.1 or Windows NT 3.5
: for say ... $300 range ?
Let's see... $5,000 for the pentium, $300 for the OS, $40 to 50K/year for the
programmer.... so broke can only afford a $99 compiler :-)
Seriously, I can relate to the issue of affordability of Ada compilers
which is why I use GNAT (which is free). Comes without a debugger but
Ada programmers generally don't need debuggers <grin>.
I read that Alsys has a Windows Ada system (win bindings and all)
called ActivAda (sp?) for a list price of $999 and $295 for students.
I don't have the article in front of me, but check out the Dec. 12 issue
of PC Week. Appears targeted to the serious Windows developer on a
budget who also wants an upgrade path to Ada 95.
--
-- Carlos Perez "My other car is Ada"
-- pe...@oldcolo.com
-- team Ada (Ada95: object-oriented, multi-threaded, totally-cool)
Erik Naggum
| Where can I get an Ada compiler & debugger for Windows 3.1 or Windows
| NT 3.5 for say ... $300 range?
would you be willing _not_ to have to pay for it? check out
cs.nyu.edu:/pub/gnat
and look for gnat-2.00-dos-bin-disk1.zip, gnat-2.00-dos-bin-disk2.zip, and
gnat-2.00-i586-ibm-winnt3.5-bin.tar.gz.
if you really want to pay for it, I'm sure they won't be unhappy with that.
#<Erik>
--
The check is in the mail. This won't hurt. You'll find it on the Web.
Jesper Kaagaard
: I've personally built real-time systems in Smalltalk, portable across
: most major Unix platforms.
That can hardly be true since UNIX as such is not a real-time operating
system. Are you confussing fast with real-time ?
--- peter
Stefan Monnier
Igor Chudov <igor_...@wiltel.com> wrote:
] Oops - there is some gap or misunderstanding here. You can be very, very
] will work is proportional to the number of objects you use plus the number of
] objects that the collector has to delete. It can't be less. It means that for
] a realtime system there will me a minimal time during which your program is
] blocked and cannot respond. Very often it is inappropriate for such systems.
Well, malloc and free take time too. There is no reason why the
garbage collector *has* to take more time and no reason for the
garbage collector to use bigger chunks of CPU time either. Real-time GC
is not easy to do, but it is doable and has been done.
] This is very simple actually.
Is it ?
Stefan
--
--------------------------------------------------------------------
-- Suicidez-vous jeune, vous profiterez plus longtemps de la mort --
--------------------------------------------------------------------
William D Clinger
Oops - there is some gap or misunderstanding here. You can be very,
very careful about objects that you create. The minimal time your
garbage collector will work is proportional to the number of objects
you use plus the number of objects that the collector has to delete.
It can't be less. It means that for a realtime system there will me a
minimal time during which your program is blocked and cannot respond.
Very often it is inappropriate for such systems.
This is very simple actually.
Also very false. Not all garbage collectors require time proportional
to the number of objects used plus the number of objects deleted. For
example, Baker's real-time garbage collector (CACM 21:4, April 1978)
completes an entire flip in time proportional to the total size of the
objects in use. The number of objects being deleted is irrelevant.
Furthermore this has little to do with latency, which is the matter
at hand. Baker's algorithm is typically implemented so that an increment
of gc is performed only when storage is allocated, and the time spent
in that increment is bounded by a constant c times the amount of storage
being allocated. So if you are careful never to allocate more than
N bytes at a time, then your program will never be blocked for more
than cN microseconds.
There are more sophisticated real-time garbage collection algorithms
than Baker's, but his is sufficient to refute Chudov's claim. On the
other hand, it is reasonable to question whether systems that rely
upon real-time gc are truly portable at present, because the number
of implementations that use real-time garbage collection is currently
very small.
William Clinger
John Max Skaller
>In <D0MrG...@ucc.su.OZ.AU> max...@physics.su.OZ.AU (John Max Skaller) writes:
>
>> In that case you completely miss the point of C++.
>>Its _principle_ advantage is that it gains leverage off C.
>>That is why it is popular -- it preserves the large C code
>>base, programmer base, and it it permitted a portable
>>implementation to be written (CFront).
>
>It's principle distinction, anyway, and most of the reason the language's
>so much uglier than, say, Eiffel or Modula-3. Advantage? A matter of
>opinion, to be sure.
Its my opinion this explains why C++ is popular, and thus
_available_.
>
>>Bjarne tried to design a language which provided an
>>upgrade path which would ensure it's popularity and which
>>would introduce programmers to modern concepts.
>
>It's clear that was the attempt. The argument (at least, the sensible
>part of it), is about whether the compromises overshadow the benefits.
But the argument is pointless. In a given commercial
situation someone has to make a commercial decision: whether
to use C++ or some other language. That choice is quite
rightly affected by a lot of things other than the "quality"
of the language.
For example: Eiffel may well be a better language,
but I don't have a commercial quality compiler so it is,
at present, useless to me, except perhaps for experimentation.
OTOH I have 4 excellent C++ compilers. (Not counting
GNU, which would make 5). And I have access to a lot of
useful software -- libraries, programs, public domain
and commercial code. Some of it is actually C code,
for example Funnel Web (literate programming tool).
Often in the commercial world, it is just
necessary to write code to meet a commercial need.
There may not be any difficult design issues -- often
its just a simple matter of hack work.
So your question is valid -- but only in
a given context. A more useful question is probably
"In _what_ contexts is it best to use C++,
or some other language?"
And for me the answer is "all of them" because if I cant
use C++ I'm unlikely to be (commercially) interested in the job.
Thant Tessman
In article <D0MrG...@ucc.su.OZ.AU>, max...@physics.su.OZ.AU writes:
[...]
> In that case you completely miss the point of C++.
> Its _principle_ advantage is that it gains leverage off C.
[...]
No, C++ is hindered by C. The advantage that C++ has in the market
place is that people who know C or who have a stable of C programmers
are fooled into thinking that they can take advantage of more advanced
computer programming concepts with less effort than it would take to
learn an entirely new programming language. Maybe Stroustrup thinks
this is the case, but it is definitely not my experience. And even
Stroustrup warns that it is a mistake to consider C++ "simply a more
complicated C".
thant
Jim McDonald
Actually, there are GC schemes that interpolate structure creation
with space reclamation so that even over relatively small time
intervals (e.g. much less than a millisecond, perhaps a microsecond),
the fraction of time spent in GC can be bounded.
There is a rather extensive literature on GC now doing back for
thirty years. Maybe someone from the lisp community could compile
a bibliography and post it here...
Richard Larson
>
...
> Whatever you do, focus on concepts and design issues rather than
> language-technical details. The details will come in time provided
> the basic concepts are there. Try to avoid relying exclusively on
> ``how-to manuals'' and ``handy-hints books.'' ...
I'd like to second that point: I have been teaching myself C++ off-and-on
for a year or so, and even using highly recommended texts, get frustrated
at some feature or other, often provided to give compatibility with C,
which is far from my favorite language. Recently I started reading
"The Design and Evolution of C++", which I found gave clear answers to many
questions of the form "why would anyone want to do _that_?" It really is
true that the language involves a sufficiently different mindset that you
must spend more time than usual thinking about the "why?" rather than the
"how?". Having a good source of answers to "why?" questions is essential
to learning the language.
------------------------------------------------------------------------
Richard G. Larson, Professor, | U. of Illinois at Chicago
Department of Mathematics, Statistics, | 851 S. Morgan St, M/C 249
and Computer Science | Chicago IL 60607-7045
* PGP public key available via finger * | R...@uic.edu (312) 996-8616
Jim McDonald
In article <3clb3m$c...@gateway.wiltel.com>, ich...@wiltel.com (Igor Chudov) writes:
|> David Siegel (dsi...@panix.com) wrote in comp.lang.c++:
|> : In <3ckb8g$8...@gateway.wiltel.com> ich...@wiltel.com (Igor Chudov) writes:
|> : >How are you going to work with realtime with a system with garbage collection
|> : >(namely, Eiffel)? You don't have much control over GC to ensure that your
|> : >system will be responsive enough.
|>
|> : Exactly the way you do in C++ -- by being careful about the objects you
|> : create and free (leave scope, release, whatever).
|>
|> Oops - there is some gap or misunderstanding here. You can be very, very
|> careful about objects that you create. The minimal time your garbage collector
|> will work is proportional to the number of objects you use plus the number of
|> objects that the collector has to delete. It can't be less.
Ah, but it can be! One of the "bug" reports we received at Lucid for our Common
Lisp system was "GC runs too fast", because we managed to (correctly!) collect
space faster than this. (The user presumed that we must be doing something wrong
to be able to run so quickly.) The simple idea is that the compiler
(possibly/probably with guidance from the user) can determine that some data is
allocated with a stack discipline, hence freeing that space amounts to reseting
one pointer, no matter how many objects have been created during that epispode.
|> It means that for
|> a realtime system there will me a minimal time during which your program is
|> blocked and cannot respond. Very often it is inappropriate for such systems.
But that minimal time can be less than a microsecond.
|> This is very simple actually.
Not that simple--there are many ingenious ways to allocate and reclaim space.
Steve Tynor
| : The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
| : the features you mention as essential.
|
| How are you going to work with realtime with a system with garbage collection
| (namely, Eiffel)? You don't have much control over GC to ensure that your
| system will be responsive enough.
There are, of course, real time GC's, and in fact we have one running in
the lab working with our Eiffel compiler. Depending on your realtime
requirements (everyone has a different definition of "realtime"... :-)),
it may indeed be possible to use a GC'd language like Eiffel for your
realtime system.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
TowerEiffel: Have your cake and eat it too.
Steve Tynor Internet: Steve...@atlanta.twr.com
Tower Technology UUCP: twratl!Steve.Tynor
WWW: http://www.cm.cf.ac.uk/Tower/
Mike Chapman
|> In article <3cdnj2$q...@panix.com> dsi...@panix.com (David Siegel) writes:
|> >In <D0Iys...@research.att.com> b...@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
|> >
|> >Well, I believe most of the "rubbish" posted about C++, but I'd like to
|> >hear the other side of the story. I'd be surprised to find it convincing,
|> >though, since some of the frequently cited C++ "advantages" are unconvincing,
|> >at best (compatibility with C and ancient linkers come immediately to
|> >mind).
|>
|> Its _principle_ advantage is that it gains leverage off C.
|> base, programmer base, and it it permitted a portable
|> implementation to be written (CFront).
|>
There are other IMHO better languages which have the same benefits.
These benefits do not imply that the language has to be a superset
of C.
|> The issue here is not whether C++ is the best
|> language which one could design, but to design one that
|> was worth the effort working on -- that is, one which
|> would have widespread use.
To design it was worthwhile.
Not so sure about the using it bit.
|>
|> >Valid point, but I think you're underplaying the problems stemming from
|> >the interactions of novices and needlessly complicated languages.
|>
|> And you are ignoring the commercial realities of the
|> world. Bjarne tried to design a language which provided an
|> upgrade path which would ensure it's popularity and which
|> would introduce programmers to modern concepts.
Unfortunately commercial success is always an argument which
wins over any valid engineering argument.
|>
|> And succeeded. Of course there is a compromise
|> in a language which supports both machine level programming
|> and OO!
Of course there is always compromise.
I just think that some of the compromises which were taken,
in particular source level compatability with 'C', and the
'C' compilation model where not the best ones which could have
been made.
--
Mike Chapman
Steve Freeman
So? I am familiar with many things in both categories, which
doesn't mean I still don't prefer the beautiful things (speaking
metaphorically, let's say Modula-3), to the ugly things (I'll
leave this one open).
steve
--
- - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Steve Freeman, Research Scientist, Rank Xerox France.
Surface: Rank Xerox Research Centre,
6, chemin de Maupertuis, 38240 Meylan, France.
Internet: steve....@xerox.fr
Phone: +33 76 61 50 21
Fax: +33 76 61 50 99
but wotthehel wotthehel
toujours gai
-- mehitabel the cat
John Max Skaller
>
>In article <D0MrG...@ucc.su.OZ.AU>, max...@physics.su.OZ.AU writes:
>
>[...]
>
>> In that case you completely miss the point of C++.
>> Its _principle_ advantage is that it gains leverage off C.
>
>[...]
>
>No, C++ is hindered by C.
Of course! The two claims are not inconsistent -- on
the contrary they are tightly coupled!
>The advantage that C++ has in the market
>place is that people who know C or who have a stable of C programmers
>are fooled into thinking that they can take advantage of more advanced
>computer programming concepts with less effort than it would take to
>learn an entirely new programming language.
They can.
>Maybe Stroustrup thinks
>this is the case, but it is definitely not my experience. And even
>Stroustrup warns that it is a mistake to consider C++ "simply a more
>complicated C".
The reason they can is not that it easier to learn C++,
but that it is easier to learn C++ than learn language X AND
convert all your code to X, AND convince management to convert
all their systems to X, AND find a compiler for X, AND find
support for X, AND find a good specification of X AND find
good books on X AND find peers who understand X ....
Converting C to C++ is usually easy. Sometimes,
as easy as falling off a greasy compiler switch and writing
extern "C" { .. :-}
Michael Wagner
I missed the beginning of this thread.
Could someone who saved Bjarne Stroustrups defense send a copy to me ?
Thanks
Mike
C. Frederick Hart
| Oops - there is some gap or misunderstanding here. You can be very,
| very careful about objects that you create. The minimal time your
| garbage collector will work is proportional to the number of objects
| you use plus the number of objects that the collector has to
| delete. It can't be less. It means that for a realtime system there
| will me a minimal time during which your program is blocked and cannot
| respond. Very often it is inappropriate for such systems.
I assume that your comment regarding the "minimal time your garbage
collector will work" refers to the pauses in the execution of the
program during which the garbage collector will be executing. If this
is the case, then the statement is not necessarily true. There are
collectors which perform their work incrementally. In some collectors,
the pauses experienced can be effectively bounded making them useful
for many realtime tasks. Furthermore, there are collector designs that
impose no cost for recovering dead objects so the cost of collection
is essentially proportional to the number of live objects only.
Finally, as has been noted in this group before, many implementations
of malloc/free have poor realtime characteristics (no guaranteed
bounds on allocation or freeing) and would not be any better for
realtime software than a GC'd system.
-- Fred Hart (fh...@atlanta.twr.com)
Tower Technology Corporation http://www.cm.cf.ac.uk/Tower/
Robert Martin
>If you can't think of a least one area where a language is better
>than your prefered language then you probably aren't competent
>to comment on it.
This statement should be named: "Nebbe's Rule" and should be made a
rule of net ettiquette.
--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@rcmcon.com | Object Oriented Analysis
2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 | C++
David Siegel
>A more useful question is probably
> "In _what_ contexts is it best to use C++,
> or some other language?"
Granted.
>And for me the answer is "all of them" because if I cant
>use C++ I'm unlikely to be (commercially) interested in the job.
And for me: "Virtually none", since the cost of developing infrastructure
in C++ that's unneeded by more thoroughly OO languages is prohibitive.
-dms
David Siegel
>Oops - there is some gap or misunderstanding here. You can be very, very
>careful about objects that you create. The minimal time your garbage collector
>will work is proportional to the number of objects you use plus the number of
>objects that the collector has to delete. It can't be less. It means that for
>a realtime system there will me a minimal time during which your program is
>blocked and cannot respond. Very often it is inappropriate for such systems.
If you're not generating garbage, the garbage collector doesn't run.
Very simple, really.
-dms
Dean Schulze
> For example: Eiffel may well be a better language,
>but I don't have a commercial quality compiler so it is,
>at present, useless to me, except perhaps for experimentation.
You can get commercial Eiffel compilers, but what you can't yet
get is a numeric library for Eiffel. So whatever Eiffel's merits
are it is worthless for numeric work unless you are willing to first
write your own numeric classes. (The Eiffel standard numeric class
suffers from a flaw that, according to one Eiffel programmer,
renders the numeric class practically useless for developing generic
numeric library classes. I understand that both the problem in
the numeric class and the unavailability of numeric libraries are
being fixed. What took so long?)
Dean Schulze
Andrew Koenig
> If you're not generating garbage, the garbage collector doesn't run.
> Very simple, really.
Sure ... as long as you know when you're generating garbage.
For example, one implementation of a GC-based language I use
has the property that it doesn't use a stack at all. In other
words, every procedure activaction record is garbage collected.
Except, of course, for the ones it can figure out represent
tail recursion and can therefore optimize away.
Except that sometimes it is not possible to optimize away
an activation record even if tail recursion is used because
the program might be creating (the equivalent of) a pointer
to some local variable and storing it somewhere. So in that
case garbage is generated even if there is a tail recursion.
It is *not* easy to look at a program in this language and say
that it will or will not generate garbage. I expect that this
is not an unusual phenomenon.
--
--Andrew Koenig
a...@research.att.com
Dale Stanbrough
writes:
>"... making a C++ implementation 100% type-safe -- would require either
>linker support or a mechanism (an environment) allowing the compiler
>access to information from separate compilations."
>
...and this of course is where Ada fits in! :-)
Dale
-------------------------------------------------------------
Dale Stanbrough, RMIT, Melbourne, Australia, da...@rmit.edu.au
GNU Ada 94 (GNAT) => the best $0 you'll ever spend.
Available for DOS, Linux, OS/2, Sun Sparc, Sun Solaris, ...
Coming to a GNU supported platform near you soon...
David Siegel
>Sure ... as long as you know when you're generating garbage.
>For example, one implementation of a GC-based language I use
>has the property that it doesn't use a stack at all. In other
>words, every procedure activaction record is garbage collected.
>[...]
>It is *not* easy to look at a program in this language and say
>that it will or will not generate garbage. I expect that this
>is not an unusual phenomenon.
It sounds about as easy as looking at a C++ program and spotting
all the implicit type conversions. Luckily, most garbage collected
systems have tools for profiling garbage creation.
-dms
Lars Thomas Hansen
Well, simple in principle. But:
A program which performs allocation, even when none of the allocated data
becomes garbage, may trigger the collector when the allocation arena
overflows because the arena is (typically) bounded. When the collector
discovers that there is still no space available (after the collection), it
moves some live data to an older generation and/or expands the arena, but
the collection has already happened. I could see how you could have some
switch
(do-not-collect-but-expand-instead #t)
<code which allocates a lot>
(do-not-collect-but-expand-instead #f)
to give the collector a hint about this sort of behavior, but it does not
seem like a general solution to the problem 'is it optimal to collect or
expand at this point?'.
Also, in the presence of a generational collector, even assignments may
trigger a garbage collection: an assignment which creates a pointer from an
older to a younger generation will cause the collector to add a record of
this assignment to its remembered set; in collectors where the remembered
set is not large enough to hold all possible such records [*], the
remembered set may eventually overflow and trigger at least a remembered set
compaction, or, ultimately, a full garbage collection.
So if your program does not perform allocation or assignment, you may be
able to guarantee that no collections will happen. Unless, of course, your
continuation frames are heap-allocated, in which case non-tail-recursive
function calls are out too. :-)
--lars
[*] Card-marking schemes do not have this problem.
Joe Buck
Stroustrup's defense of C++, "Widespread C++ Competency Gap", etc.
to remove inappropriate newsgroups from the Newsgroups line.
In particular, don't followup to comp.std.c++. It was ill-considered
for Dr. Stroustrup to post it to comp.std.c++ in the first place, since
surely he knew it was flamebait and it had no relevance to the
standardization effort.
Followups are directed to comp.lang.c++.
--
-- Joe Buck <jb...@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729
David Siegel
> (do-not-collect-but-expand-instead #t)
> <code which allocates a lot>
> (do-not-collect-but-expand-instead #f)
>to give the collector a hint about this sort of behavior, but it does not
>seem like a general solution to the problem 'is it optimal to collect or
>expand at this point?'.
I'd like something a little different -- a way to tell the runtime system
to "promote" an object that I expect will be long-lived, so as to defer
filling "new-space", and skip scavenges of intermediate generations.
-dms
Bob Steagall
>From: rma...@rcmcon.com (Robert Martin)
>Subject: Re: Widespread C++ Competency Gap?
>Date: Thu, 15 Dec 1994 18:10:02 GMT
>ne...@lglsun.epfl.ch (Robb Nebbe) writes:
I'll second this motion ;->
Bob
Jim McDonald
Lucid Common Lisp has macros something like:
(with-normal-consing-area (foo))
(with-consing-area *dynamic-space* (foo))
(with-consing-area *read-only-space* (foo))
etc.
for the dozen or so kinds of consing areas.
[Btw, "consing" is used to indicate generic structure creation,
not just calls to the CONS function.]
The effect is that FOO is executed in the intended environment.
The actual mechanism typically involves switching small pieces
of code that play roles similar to "malloc".
I don't remember the exact names of the macros offhand, and don't
have a User's Guide handy, so the syntax may vary a bit from
what I indicated, but the general idea should be useful in many
contexts.
-Tony L. Hansen
< From: th...@disney.com (Thant Tessman)
<
< No, C++ is hindered by C. The advantage that C++ has in the market place
< is that people who know C or who have a stable of C programmers are fooled
< into thinking that they can take advantage of more advanced computer
< programming concepts with less effort than it would take to learn an
< entirely new programming language. Maybe Stroustrup thinks this is the
< case, but it is definitely not my experience. And even Stroustrup warns
< that it is a mistake to consider C++ "simply a more complicated C".
Interestingly enough, my experience with various groups has been the
opposite from yours. Perhaps it's all in how you approach the learning of
the more advanced computer programming concepts that C++ supports.
Tony Hansen
han...@pegasus.att.com, to...@attmail.com
att!pegasus!hansen, attmail!tony
David Weller
John Carson <car...@gwis2.circ.gwu.edu> wrote:
>
>I agree. However after reading a few of these message I just delete them
>as noise. I have been teaching C++ for about three years now and have
>also encountered some hostility toward the language. I find it comes
>from people (I'm dealing with professionals here) who are scared when
>they find that they can't quickly grasp the concepts necessary to design
>and build classes. Since they can't understand the concepts quickly,
>they need to blame something other than themselves so the language is the
>obvious target.
Hmm...well, I've dealt with my fair share of folks who don't like C++
either, and it wasn't because they're incapable of understand or
designing a good class. However, your point is well made -- people
reject languages based more on ignorance than fact. I'll bet I've
seen it MUCH more than you have :-)
>On the other hand, many of my professional friends who did not like C and
>would even choose Ada over C have embraced C++ and refuse to use anything
>else.
>
No fair! I'll bet you didn't tell them about Ada95, did you? :-)
--
Frustrated with C/C++, Pascal, Fortran? Ada95 _might_ be for you!
For all sorts of interesting Ada95 tidbits, run the command:
"finger dwe...@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
Proud employee of
Link^H^H^H^Singer-Link^H^H^H^^H^H^HCAE-Link^H^H^H^H^H Hughes Training.
Stephen J Bevan
... The reason they can is not that it easier to learn C++,
but that it is easier to learn C++ than learn language X AND
convert all your code to X, AND convince management to convert
all their systems to X, AND find a compiler for X, AND find
support for X, AND find a good specification of X AND find
good books on X AND find peers who understand X ....
It isn't clear to me that you need to convert all your code to X or
convince managment to convert all their systems to X. If you have
legacy code/systems, leave them alone and write interfaces to them in
language X, this takes much less effort than re-writing them and works
for all legacy code/systems, not just C ones. The difficultly of
finding a compiler, finding support, a good specification and good
books depend on what exactly X is (IMHO Smalltalk and Eiffel rate
approximately the same as C++ in these categories). Finding peers who
understand X is always a problem, even with C++.
Stephen J Bevan
... It is *not* easy to look at a program in this language and say
that it will or will not generate garbage.
I agree, but is that situation really that different from looking at a
program in C++ and trying to figure out when and where
constructors/destructors will be called?
Joe
In article <3ci9a2$m...@tools.near.net> Barry Margolin,
bar...@nic.near.net writes:
>Another reason to use an array of pointers is if you want to use the
array
>elements polymorphically. You can assign a Derived* to a Base*, and then
>call virtual functions to get the overriding versions of methods defined
in
>the Derived. But if you have an array of objects rather than pointers,
you
>can't have Derived objects in the array. This loses much of the power of
>OO programming.
I agree with this 100%. That was the first thing that came to mind as I
read the article.
Aside from polymorphism, there is another legitimate reason to have an
array of
object pointers. For example, what if you want the elements of the array
to outlive
the life time of its Wrapper object? That is to say, the destruction of
these elements
at the destruction of its Wrapper object may not be the desired effect.
The actual
members of the array, in many situations, would be determined and put in
the array at runtime. These could reference other objects in the
application which should persist even after the Wrapper object expires.
This is totally dependent on the context of a specific application, and
both types
of storage has their appropriate uses.
It would be nice to be able to select which constructor is called for the
array
elements when a class containing that array is declared. Unless I'm
completely
misfiring here (I'm still struggling with the nuances of the language),
what really
concerns me is the inability to select which constructor to use to
initialize a
member object of a class at that class's declaration:
class A
{
public:
...
protected:
...
private:
B theB(10, this); // For example... I wish I could do this, or
should this work?
...
};
Oh, well... It is an evolving language:-)
Joe
pbru...@co.alameda.ca.us
Thant Tessman
In article <D0v1L...@nntpa.cb.att.com>,
han...@pegasus.bl-els.att.com writes:
> Interestingly enough, my experience with various groups has been the
> opposite from yours. Perhaps it's all in how you approach the learning of
> the more advanced computer programming concepts that C++ supports.
Pardon my scepticism. What languages are you comparing C++ to? Which
concepts are you trying to teach/learn?
thant
[comp.std.c++ removed from newsgroups]
Jim Adcock
|Let's see... $5,000 for the pentium, $300 for the OS, $40 to 50K/year for the
|programmer.... so broke can only afford a $99 compiler :-)
Nit: Where do you shop for computers? My local store has good pentiums
for < $2000, good 486 machines for < $1000. That leaves you $4099 to
ship to whatever your favorite compiler team ;-)
James McKim
>David Siegel (dsi...@panix.com) wrote in comp.lang.c++:
>: In <787227...@wslint.demon.co.uk> kev...@wslint.demon.co.uk (Kevlin Henney) writes:
>
>: >We are developing a realtime system that must be portable across a number of
>: >platforms conforming to the standard POSIX spec (the standard binding is in
>: >C), the realtime POSIX spec/draft (the standard binding for which is in C),
>: >accessing BSD sockets (the standard API defined in C), allow low level
>: >access and run on systems that use standard UNIX linkers.
>
>: The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
>: the features you mention as essential.
>
>How are you going to work with realtime with a system with garbage collection
>(namely, Eiffel)? You don't have much control over GC to ensure that your
>system will be responsive enough.
Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
GC. Not sure about the other vendors. If such fine-tuning is still
insufficient then you can always turn automatic GC off, write your
own collector and be no worse off than in any language that did not support
automatic GC.
>----------------------------------------------------------------------------
>IMHO. Igor Chudov, Resource Solutions Intl office (918)588-2309
>Systems Engineer, for WilTel. home (918)585-5862
> E-mail: igor_...@wiltel.com
> http://m-net.arbornet.org/~ichudov
> 1819 South Jackson #32-P Tulsa OK 74107
>
> f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.
Hope this helps,
-- Jim
--
*------------------------------------------------------------------------------*
Jim McKim (203)-548-2458 In exactly 3.2 seconds it will be a few
Internet: j...@hgc.edu minutes to 5:00.
James McKim
>James McKim (j...@hgc.edu) wrote in comp.lang.c++:
>: In article <3ckb8g$8...@gateway.wiltel.com> igor_...@wiltel.com (Igor Chudov) writes:
>: >How are you going to work with realtime with a system with garbage collection
>: >(namely, Eiffel)? You don't have much control over GC to ensure that your
>: >system will be responsive enough.
>
>: Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
>: GC. Not sure about the other vendors. If such fine-tuning is still
>: insufficient then you can always turn automatic GC off, write your
>: own collector and be no worse off than in any language that did not support
>: automatic GC.
>
>provides only the way to enable and disable garbage collection and also to
>set some limits and criteria when to start the garbage collection.
>
>AFAIK, both Tower and ISE provide approximately the same kind of fine
>tuning. I'll appreciate if you post your corrections in the news if I am
>wrong.
Another poster also asked for more info. As I sit here looking at both
Tower's and ISE's MEMORY classes, they appear to provide at least a bit
more capability than you ascribe to SiG. OTOH I have not had occasion to
use these facilities and so cannot speak with authority about them. Perhaps
we can get someone from each vendor to speak up?
>
>This kind of fine tuning along with non-incremental GC, being nice in
>general, does not provide enough flexibility for real-time applications.
>
>None of existing Eiffel vendors provides incremental garbage collector that
>can work in parallel with the execution (or stealing LITTLE pieces of
>processor time), although Tower informed that they have been working on this
>problem. This type of GC can enable the apps to be really (sorry for the
>clumsiness) real-time.
This is surprising as Meyer has always advocated incremental collection,
see OO Software Construction and Eiffel: The Language. In fact in the
latter he implies that ISE's collector _is_ incremental. We really need
someone from ISE to speak up here.
>
>To be able to use the latter type of GC, however, whole runtime system has to
>be modified along with the GC, so it is hardly possible to add realtime GC
>without changes in runtime. The argument that we can add our own realtime
>GC to existing runtime sounds too optimistic.
Well, I didn't say it would be _easy_ :-). But why would building
your own garbage collector be more difficult for an Eiffel system
than it would be for a C++ system?
>
>You are right that in general nothing prevents Eiffel to be able to work in
>RT.
>
>Best regards,
>----------------------------------------------------------------------------
>IMHO. Igor Chudov, Resource Solutions Intl office (918)588-2309
>Systems Engineer, for WilTel. home (918)585-5862
> E-mail: igor_...@wiltel.com
> http://m-net.arbornet.org/~ichudov
> 1819 South Jackson #32-P Tulsa OK 74107
>
> f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.
Happy Holidays,
Cameron Laird
John Max Skaller <max...@physics.su.OZ.AU> wrote:
.
.
.
> The reason they can is not that it easier to learn C++,
>but that it is easier to learn C++ than learn language X AND
>convert all your code to X, AND convince management to convert
>all their systems to X, AND find a compiler for X, AND find
>support for X, AND find a good specification of X AND find
>good books on X AND find peers who understand X ....
.
.
SOOOOO true. In fact, should someone wish to
turn this thread in a productive direction, I'd
welcome specific examples of effective ways to
talk about Eiffel and/or Smalltalk with manage-
ment and junior programmers. Thant? Anyone?
*That*'s where the real challenge lies, at least
in my part of the commercial world.
I narrowed distribution.
--
Cameron Laird ftp://ftp.neosoft.com/pub/users/claird/home.html
cla...@Neosoft.com +1 713 267 7966
cla...@litwin.com +1 713 996 8546
Kevin K. Lewis
>How are you going to work with realtime with a system with garbage collection
>(namely, Eiffel)? You don't have much control over GC to ensure that your
>system will be responsive enough.
Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
GC. Not sure about the other vendors. If such fine-tuning is still
insufficient then you can always turn automatic GC off, write your
own collector and be no worse off than in any language that did not support
automatic GC.
This is _very_ interesting to me. Could you (or someone else) explain
how this is done? How does one write a collector? Can you use
explicit calls to deallocate individual objects?
I work in a real time environment, and we've pretty much given up on
the idea of using a garbage-collected language for any of our
time-critical tasks. If we could eliminate (I don't think "reduce"
would be enough) the risk of a GC kicking off at an inopportune time,
we might be able to consider higher-order languages.
Are there any papers, etc, that I could access? Thanks much for any
help.
--
Kevin K. Lewis | My opinions may be unreasonable
lew...@aud.alcatel.com | but such is the voice of inspiration
Igor Chudov
: >How are you going to work with realtime with a system with garbage collection
: >(namely, Eiffel)? You don't have much control over GC to ensure that your
: >system will be responsive enough.
: Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
: GC. Not sure about the other vendors. If such fine-tuning is still
: insufficient then you can always turn automatic GC off, write your
: own collector and be no worse off than in any language that did not support
: automatic GC.
As for Eiffel, I worked with SiG Eiffel compiler. For 'fine tuning' it
provides only the way to enable and disable garbage collection and also to
set some limits and criteria when to start the garbage collection.
AFAIK, both Tower and ISE provide approximately the same kind of fine
tuning. I'll appreciate if you post your corrections in the news if I am
wrong.
This kind of fine tuning along with non-incremental GC, being nice in
general, does not provide enough flexibility for real-time applications.
None of existing Eiffel vendors provides incremental garbage collector that
can work in parallel with the execution (or stealing LITTLE pieces of
processor time), although Tower informed that they have been working on this
problem. This type of GC can enable the apps to be really (sorry for the
clumsiness) real-time.
To be able to use the latter type of GC, however, whole runtime system has to
be modified along with the GC, so it is hardly possible to add realtime GC
without changes in runtime. The argument that we can add our own realtime
GC to existing runtime sounds too optimistic.
You are right that in general nothing prevents Eiffel to be able to work in
RT.
Best regards,
Igor Chudov
[ ... many absolutely right things ... ]
: >
: >To be able to use the latter type of GC, however, whole runtime system has to
: >be modified along with the GC, so it is hardly possible to add realtime GC
: >without changes in runtime. The argument that we can add our own realtime
: >GC to existing runtime sounds too optimistic.
: Well, I didn't say it would be _easy_ :-). But why would building
: your own garbage collector be more difficult for an Eiffel system
: than it would be for a C++ system?
Well, it seems like another holy war is about to start... Let us postpone
it.
--
Happy Holidays!
Jean-Marc Jezequel
|> James McKim (j...@hgc.edu) wrote in comp.lang.c++:
|> : In article <3ckb8g$8...@gateway.wiltel.com> igor_...@wiltel.com (Igor Chudov) writes:
|> : >How are you going to work with realtime with a system with garbage collection
|> : >(namely, Eiffel)? You don't have much control over GC to ensure that your
|> : >system will be responsive enough.
|>
|> : Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
|> : GC. Not sure about the other vendors. If such fine-tuning is still
|> : insufficient then you can always turn automatic GC off, write your
|> : own collector and be no worse off than in any language that did not support
|> : automatic GC.
|>
|> As for Eiffel, I worked with SiG Eiffel compiler. For 'fine tuning' it
|> provides only the way to enable and disable garbage collection and also to
|> set some limits and criteria when to start the garbage collection.
|>
|> AFAIK, both Tower and ISE provide approximately the same kind of fine
|> tuning. I'll appreciate if you post your corrections in the news if I am
|> wrong.
I did it for a telecom application with ISE Eiffel 3.2.2.
The GC is activated once in a while (when certain criterions are statisfied), and at least
every half second. Then we measured that it never takes over the processor for more than
5ms before returning. However reaching this result took some fine tuning effort (the more
you call the GC, the less time it takes for each call, but this is not linear
and has a lower limit).
It would have been wonderfull to have a primitive of the kind
partial_collect(maximum_duration_allowed)
[cross-posting restricted]
PS: Igor Chudov, can you acknoledge this post, since I am not sure I reaches you.
+-------------------------------+---------------------------------------+
| Jean-Marc Jezequel | Tel : +33 99847192 |
| IRISA/CNRS | Fax : +33 99847171 |
| Campus de Beaulieu | e-mail : jeze...@irisa.fr |
| F-35042 RENNES (FRANCE) | http://www.irisa.fr |
+-------------------------------+---------------------------------------+
Igor Chudov
: I did it for a telecom application with ISE Eiffel 3.2.2.
: The GC is activated once in a while (when certain criterions are statisfied), and at least
: every half second. Then we measured that it never takes over the processor for more than
: 5ms before returning. However reaching this result took some fine tuning effort (the more
: you call the GC, the less time it takes for each call, but this is not linear
: and has a lower limit).
: It would have been wonderfull to have a primitive of the kind
: partial_collect(maximum_duration_allowed)
: [cross-posting restricted]
: PS: Igor Chudov, can you acknoledge this post, since I am not sure I reaches you.
Yes, I got it. Thanks. This 5 ms collection time is very good, although it
can be unsuitable for some other types of applications, namely for the
embedded systems that are used to manage car engines (I talked to one
embedded system developer recently, it was very useful).
The idea of partial_collect is very good, but I am not sure how you can
circumvent the time needed to traverse all objects belonging to the root
set in case of mark-and-sweep strategy.
Happy Holidays!
Kelvin Nilsen
applications may be interested in:
K. Nilsen. Reliable Real-Time Garbage Collection of C++. Computing
Systems. vol. 7, no. 4, (Fall 1994).
Though the title mentions C++, the techniques can be generalized to support
other languages. The paper discusses "accurate" (as opposed to conservative)
garbage collection techniques, and describes the performance constraints
that characterize "real-time performance".
To summarize, our garbage collection technique supports worst-case memory
allocation delays of 500 microseconds at predictable times and worst-case
memory access delays of 2 microseconds. The amortized allocation and
memory access costs are nearly indistinguishable from more traditional
C++ techniques for memory management. We rely on a "small" amount of
hardware support coupled with the memory system to achieve this performance.
The general design of the memory subsystem is portable between CPU
architectures. A FPGA prototype is currently under construction. Eventually,
we intend to package all of the special circuitry on a single chip, the cost
of which remains to be determined.
Additional reports are available by anonymous ftp from
ftp.cs.iastate.edu:/pub/kelvin
Kelvin Nilsen/Dept. of Computer Science/Iowa State University/Ames, IA 50011
(515) 294-2259 kel...@cs.iastate.edu uunet!cs.iastate.edu!kelvin
Thant Tessman
In article <3dc3mm$1...@Starbase.NeoSoft.COM>,
cla...@Starbase.NeoSoft.COM writes:
> In fact, should someone wish to
> turn this thread in a productive direction, I'd
> welcome specific examples of effective ways to
> talk about Eiffel and/or Smalltalk with manage-
> ment and junior programmers. Thant? Anyone?
> *That*'s where the real challenge lies, at least
> in my part of the commercial world.
Our project uses a combination of Scheme and C++. We use C++ in the
speed critical parts of our application (and in general any place C is
appropriate), and we use Chez Scheme as the scripting/extension
language. (There's much more to it but I don't think I'm supposed to
be describing the architecture in too much detail.)
I was lucky. I didn't have to convince "management" of the advantages
of Scheme. I only had to convince the technical lead who, luckily, is
a very smart guy. It was fairly obvious to him that Scheme was the
only way we were going to get anything reasonable done in any
reasonable amount of time.
We were initially *very* concerned about using Scheme in a real-time
application both because of its speed and because Scheme does garbage
collections. We devised all sorts of alternate emergency backup plans
in case Scheme didn't work out. As it turns out, the amount of time
our application spends in Scheme is not that big, and, to our great
relief, garbage collection (at least in Chez Scheme) was fast enough
to be a complete non-issue.
***
Why we were able to use Scheme:
The scheme we eventually chose was a commercially supported product
which was robust and fast and it had a good chance of being around for
a while.
We were not concerned with software market conditions (beyond what I
said above). We had no intention of selling it to anybody, or making
it work on every platform on the planet. We just had to get it
working.
To our knowledge, much of what we were doing had never been done
before. Or at least there were many parts of our system that we
couldn't buy from other folks.
***
When we are working on the Scheme side of our system, there isn't a
week that doesn't go by where somebody on the team doesn't
spontaneously erupt with "Scheme is cool." When we are working on the
C++ side of our application, there isn't a week that doesn't go by
when somebody doesn't vehemently spout "C++ sucks!"
Programming in C++ is so painful we constantly think about ways of
moving more of the application out of the C++ side. It's irrelevant
at this point, but if I had a chance to do it over, I'd seriously
consider a few other languages in order to avoid using C++ as much as
possible. SML and Dylan are my favorites. There are other problems,
but the main problem with SML is that it doesn't provide a good
foreign function interface. The main problem with Dylan is that it
doesn't exist. And neither language can hold a candle to Scheme's
elegance and teachability.
One more interesting note: I'm told that big financial institutions
are always exploring advanced software development techniques.
Apparently, they use languages like Smalltalk and Common Lisp all the
time because they lose large amounts of money in small amounts of time
when their software doesn't do what it needs to do. They are also
extremely secretive about this for obvious reasons.
thant
Robert J. Brown
: In article <3dc3mm$1...@Starbase.NeoSoft.COM>,
: cla...@Starbase.NeoSoft.COM writes:
: ***
: ***
: thant
If you are looking for better real-time performance from a scheme based
language, and this could be your ticket to get cured of C++, then look
into Yale's T. T is a fast compiled and extended version of scheme. It
is only available on certain hardware platforms, however, so you may or
may not be able to use it.
Brian Hawley
: In article <3da1nd$f...@gateway.wiltel.com> igor_...@wiltel.com (Igor Chudov) writes:
[snip unrelated stuff]
: >
: >To be able to use the latter type of GC, however, whole runtime system has to
: >be modified along with the GC, so it is hardly possible to add realtime GC
: >without changes in runtime. The argument that we can add our own realtime
: >GC to existing runtime sounds too optimistic.
: Well, I didn't say it would be _easy_ :-). But why would building
: your own garbage collector be more difficult for an Eiffel system
: than it would be for a C++ system?
Ah, finally something that I have competency in!
It would be much easier to retrofit Eiffel, Scheme, Oberon and such with
a custom garbage collector because those languages have been specifically
designed to allow GC. These languages place restrictions on the behavior
of pointers, do not allow integers to be used as pointers (or don't trace
them), and have certain structures in memory that facilitate GC. These
structures and restrictions can be used to implement your alternate GC in
the same way that they were used in the standard.
C++ does not have these restrictions, nor does it have the necessary
structures to do GC with the same ease that Eiffel and such do. Therefore
if you intend to use GC _of_any_kind_ in your system, it is better that
you start with a language that was designed with that ability in mind.
As to my competency, I had to retrofit C++ with GC when I was working on
a compiler for Oberon-2 (a fast GCed procedural/oop language) to Ansi C++
that would generate human-editable code with no macros. In order to do
the GC (and several other things) I had to make the same restrictions on
C++ behavior that Oberon has. Unfortunately, since these restrictions
couldn't be enforced, the C++ code was slower than the corresponding
Oberon code (although it was at least as fast as code made in the normal
C++ style). Your mileage may vary, but mine usually hasn't.
: *------------------------------------------------------------------------------*
: Jim McKim (203)-548-2458 In exactly 3.2 seconds it will be a few
: Internet: j...@hgc.edu minutes to 5:00.
Brian Hawley
bha...@orion.it.luc.edu and math.luc.edu
John Nagle
>Ah, finally something that I have competency in!
>It would be much easier to retrofit Eiffel, Scheme, Oberon and such with
>a custom garbage collector because those languages have been specifically
>designed to allow GC. These languages place restrictions on the behavior
>of pointers, do not allow integers to be used as pointers (or don't trace
>them), and have certain structures in memory that facilitate GC. These
>structures and restrictions can be used to implement your alternate GC in
>the same way that they were used in the standard.
>C++ does not have these restrictions, nor does it have the necessary
>structures to do GC with the same ease that Eiffel and such do. Therefore
>if you intend to use GC _of_any_kind_ in your system, it is better that
>you start with a language that was designed with that ability in mind.
But see the Ellis/Detlefs paper on garbage collection for
C++, and a safe subset of C++ that makes it work. They impose very
few restrictions on C++, and use Boehm's garbage collector. If
you send E-mail to "el...@parc.xerox.com", he'll send you his
paper on the subject.
John Nagle
Hans Boehm
>None of existing Eiffel vendors provides incremental garbage collector that
>can work in parallel with the execution (or stealing LITTLE pieces of
>processor time), although Tower informed that they have been working on this
>problem. This type of GC can enable the apps to be really (sorry for the
>clumsiness) real-time.
>To be able to use the latter type of GC, however, whole runtime system has to
>be modified along with the GC, so it is hardly possible to add realtime GC
>without changes in runtime. The argument that we can add our own realtime
>GC to existing runtime sounds too optimistic.
I'm not an expert on real-time programming. But I'm always confused
by these discussions. It seems to me that "real-time" is usually
intended to mean one of the following two extremes, or anything
in between:
1. Reasonable interactive response on a fast machine. Maybe good enough
so that a video game isn't too jerky.
2. Part of a safety critical system that requires millisecond or so
GUARANTEED response, and GUARANTEED space bounds.
At the first extreme, even stop-the-world collectors may be adequate,
and VM-synchronized collectors are usually fine. It's possible
to provide this sort of collector largely as an add-on library, even for (very
slightly restricted) C, at least with appropriate OS support.
My impression is that essentially no application at the second extreme
currently uses any form of dynamic memory allocation, either malloc/free
style, or garbage collected. (They also don't use VM, or conventional
networks. They may avoid processor caches.) My guess is that there are such
applications that could benefit from dynamic allocation, but they're probably
in the minority (which doesn't make them uninteresting). There are several
obstacles in the way:
a. If you use a malloc/free style facility you have to bound allocation
time and fragmentation overhead. Most standard implementations don't
have terribly useful worst-case bounds on either (though their average
performance may be very good).
b. Most (all?) language specifications say nothing useful about resource
consumption, and particularly not space consumption.
Most conventional implementation specifications aren't much better.
You clearly need (at least) compiler-dependent tools to analyze worst-case
resource consumption.
c. A compacting real-time GC avoids problem (a), but requires compiler
support, and some run-time overhead. But point (b) also requires
specialized compiler support.
d. Since you have to statically bound worst-case space usage, it may
often be just as easy to allocate space statically. (I would love to know
how often this is really the case. Any informed opinions?)
I suspect this discussion is really about points somewhere between the
above 2 extremes. But it would be nice to make that explicit.
Hans-J. Boehm
(bo...@parc.xerox.com)
Standard disclaimer ...
Don Yuniskis
Hans Boehm <bo...@parc.xerox.com> wrote:
>I'm not an expert on real-time programming. But I'm always confused
>by these discussions. It seems to me that "real-time" is usually
>intended to mean one of the following two extremes, or anything
>in between:
>
>1. Reasonable interactive response on a fast machine. Maybe good enough
>so that a video game isn't too jerky.
>
>2. Part of a safety critical system that requires millisecond or so
>GUARANTEED response, and GUARANTEED space bounds.
Actually, neither is really correct. Typically real-time == real-fast.
However, real-fast != real-time. Also, real-time !-> real-fast
(read: does not imply).
It's easiest to just remember that real-time applications factor time
into their performance specification. Contrast this with non-real-time
applications, whether batch or interactive:
- the IRS processing tax returns
batch, obviously wants to be VERY fast since there are so
many returns to be processed, but NOT real-time; if a return
isn't processed in the next mS, S or even day, the application
*still* continues to function properly
- a PC user editing a document
interactive, would like to be reasonably fast soas not to annoy
the user; again not real-time...
By contrast, an ABS break system for a car is real-time as it must respond
within a predefined time window. This example is moderately fast (on the
order of milliseconds) but it need not be "real-fast". I guess to stretch
the analogy, a pacemaker could also be considered a "slow" real-time
system... it deals with evcents on theorder of a second.
These two examples also can be used to distinguish between soft and
hard real time applications; but, you could make a case for either one
being the HRT case (or both or neither, depending on your system
specification). For example, you could envision the brakes as HRT in
that they MUST be serviced "now" -- or, as is typical in most available
ABS systems, the manual system functions even in the absence of ABS
and so failure to service the brake event could be undesirable, but
tolerable occasionally. Likewise, the pacemaker could be HRT if
you assume the patient's heart must be kicked NOW... or, you could
envision it as soft real-time figuring "better late than never".
The distinction lies in the value function you associate with the
task's deadline.
>At the first extreme, even stop-the-world collectors may be adequate,
>and VM-synchronized collectors are usually fine. It's possible
>to provide this sort of collector largely as an add-on library, even for (very
>slightly restricted) C, at least with appropriate OS support.
Yes. Assuming the OS deal's with "real-time" and not just "real-fast"...
>My impression is that essentially no application at the second extreme
>currently uses any form of dynamic memory allocation, either malloc/free
>style, or garbage collected. (They also don't use VM, or conventional
>networks. They may avoid processor caches.) My guess is that there are such
>applications that could benefit from dynamic allocation, but they're probably
>in the minority (which doesn't make them uninteresting). There are several
>obstacles in the way:
>
>a. If you use a malloc/free style facility you have to bound allocation
>time and fragmentation overhead. Most standard implementations don't
>have terribly useful worst-case bounds on either (though their average
>performance may be very good).
>
>b. Most (all?) language specifications say nothing useful about resource
>consumption, and particularly not space consumption.
>Most conventional implementation specifications aren't much better.
>You clearly need (at least) compiler-dependent tools to analyze worst-case
>resource consumption.
>
>c. A compacting real-time GC avoids problem (a), but requires compiler
>support, and some run-time overhead. But point (b) also requires
>specialized compiler support.
>
>d. Since you have to statically bound worst-case space usage, it may
>often be just as easy to allocate space statically. (I would love to know
>how often this is really the case. Any informed opinions?)
>
>I suspect this discussion is really about points somewhere between the
>above 2 extremes. But it would be nice to make that explicit.
Again, all of this depends upon your application's real-time criteria.
It depends upon whether or not you are HRT or SRT. And, it also depends
on whether your OS can detect missed deadlines and how you recover from
this...
I'm working on an application which uses all of these "no-no's":
malloc/free (actually new/delete), VM and GC. The trick is making
sure that a mechanism is suited to the particular area of
application. For instance, all my interrupt drivers are wired down
to avoid the chance of encountering a page fault when least expected ;-)
Yet, other parts of the application are free to swap to fit the
hardware implementation I choose.
Kelvin Nilsen
>I'm not an expert on real-time programming. But I'm always confused
>by these discussions. It seems to me that "real-time" is usually
>intended to mean one of the following two extremes, or anything
>in between:
>1. Reasonable interactive response on a fast machine. Maybe good enough
>so that a video game isn't too jerky.
>2. Part of a safety critical system that requires millisecond or so
>GUARANTEED response, and GUARANTEED space bounds.
Based on my experiences attempting to "educate" the real-time community
as to the potential benefits of dynamic memory management and real-time
garbage collection, I would say that Hans has done a good job of
characterizing the spectrum of applications that might be considered to
be "real-time", as well as summarizing the difficulties and challenges
faced by those who attempt to utilize dynamic memory management in
real-time systems.
I would like to point out that there is a very important (increasingly so)
application domain that I'll call:
1.99: Part of a large system (that is not safety critical) that
requires GUARANTEED response and GUARANTEED space bounds.
This includes video-on-demand servers, tv-top multimedia boxes, virtual
reality systems, and voice-based human-computer interfaces. Some might
argue that no guarantees are necessary in such systems. But won't the
service providers need to provide guarantees to the consumer that:
a) Her window-oriented TV viewer won't run out of memory and crash right
in the middle of the winning Super Bowl touchdown play?
b) His on-demand viewing of the latest Arnold Swarzenegger movie won't
degrade during the final scene?
c) Her voice processing system won't arbitrarily ignore words spoken during
inattentive periods, possibly negating the intended meanings of complete
sentences?
d) His new virtual reality system won't give him nausea because the
video doesn't synchronize perfectly with audio and mechanical
events?
e) Her new Pen computer won't misinterpret her hasty but quite legible
FAX instructions and send an important confidential document to
the wrong recipient?
Even if the supplier makes no explicit guarantees, such guarantees are
implied. Can you imagine trying to watch TV on anything as unreliable
as Microsoft Windows is today? Wouldn't we see huge class-action law
suits against suppliers of products that fail to deliver acceptable
quality? Are company executives willing to risk their future careers on
high-volume distribution of "unguaranteed" software products? Even if
there is no class-action law suit against the company, market competition
is likely to impose a stiff penalty on suppliers of unreliable and/or
otherwise disfunctional "real-time" components.
(Note: I am speaking of "guarantee" in the colloquial sense of the word.
I often buy guaranteed products that are in fact flawed. A guarantee
provides me with an opportunity to have my money refunded or the product
replaced. The product suppliers have presumably performed a risk analysis
upon which they base the guarantee's coverage, the company's stated
liabilities, and the product's prices. A developer of reliable real-time
software may not always be able to afford the high resource costs of
providing 100% assurance that all response-time and memory-allocation
needs will always be satisfied. In these cases, the developer must
quantify the likelihood that certain bounds will be violated, and management
must make decisions as to how these risks are to be tolerated.)
>d. Since you have to statically bound worst-case space usage, it may
>often be just as easy to allocate space statically. (I would love to know
>how often this is really the case. Any informed opinions?)
As Hans' original posting already emphasized, dynamic memory management is
not currently used in existing "hard" real-time systems, so it is difficult
to give factual data to back any opinion, one way or the other... but here
are a few examples that demonstrate that it is not always desirable to
statically allocate all real-time memory needs (because of the high
implementation costs and the constraints imposed on program functionality):
1) Your personal digital assistant (PDA) specifies that it supports
up to 30 minutes of voice notes or 100 pages of handwritten notes,
or any combination of the two in appropriate proportions. Now, add
in memory for your address book, your appointments, received FAXes,
and your to-do list...
2) Your program supports several distinct phases or modes of operation,
each of which uses memory for different purposes. (consider the
control software for a fighter aircraft: takeoff, land, dogfight,
in-flight refuel, cruise, and attack-land-target are all mutually
exclusive modes of operation)
3) Your program makes use of huge amounts of memory, but only "small"
portions of this memory need to be accessed at any particular time
during program execution. (example: SGI's Ada Paintball virtual
reality system is reported to require 500 MBytes of real RAM, but
would run in "much less memory" if there was a reliable way to
manage dynamic memory without violating real-time constraints.)
4) Your program supports "guaranteed" minimal levels of service,
with optional service enhancements provided as resources permit.
a) The throughput of many multimedia applications is significantly
improved through the use of disk and network caches and/or prefetch
buffers. Dynamic memory management allows service quality to be
enhanced through the use of dynamically allocated cache buffers
whenever extra memory is available to serve these purposes.
b) In distributed and parallel real-time systems, it is often desirable
to shift data and tasks between processors in order to better balance
the load. This migration of responsibilities requires that memory
be allocated on the target nodes to represent the relocated tasks
and/or their data.
c) Some important real-time applications require the solution of
difficult problems for which no constant-time algorithms exist.
In these circumstances, it may be necessary for the real-time
software to make an initial (constant-time) guess at the proper
solution and then try to incrementally refine this guess as time
and memory permit. Being able to dynamically allocate memory
provides maximum opportunity to dynamically select between
various time-space tradeoffs in order to optimize the quality of
service for each operating domain. (Hint: many of these sorts
of applications are military related)
In summary, real-time programmers would like to be able to do just about
everything that traditional programmers do. They are forced by current
technology limitations to limit system functionality. My "informed"
opinion is that it is no more appropriate to expect real-time programmers
to statically allocate all memory than it is for us to remove the new
operation from C++.
David Hanley
I had an idea, that, if practical, would go a long way to
justifying GC for me. If this idea is not new( and I'm guessing it
isn't ) could someone please comment about it to me?
The idea is to use an extra processor to do garbage collection.
This would relieve the first processor for almost any memory management
tasks. GC'd programs might therefore run even more quickly than manually
msnsged ones. This might also be a good way to utilize extra processors
on multiple-processor machines. Multiprocessor machines will be the
norm in a couple of more years, IMHO.
Anyways here's the idea: Periodically, the entire program data
space is copied into temporary space, along with a copy of the
rootset. Unfortunately, the execution of the program must be halted
for this. On the bright side, this could be done while the task would
be halted ( I'm assuming a multitasking machine here ) anyways, so we
might not lose very much.
The program can be allowed to execute once again on it's
processor. Meanwhile, on the second processor, the list of objects
that cannot be accessed from the rootset will be built. The next GC
interrupt will simply add this to the freelist, before copying the
dataspace again.
If this could be done without copying the dataspace, it
would, of course, be even better( or even fantastic ). I tend to
think this turns out to be a necessary step.
Comments?
--
------------------------------------------------------------------------------
| David James Hanley -- dha...@lac.eecs.uic.edu -- C++, OOD, martial arts |
| Laboratory for advanced computing | My employer barely KNOWS me. |
------------------------------------------------------------------------------
"There are trivial truths & there are great truths. The opposite of a
trivial truth is plainly false."
"The opposite of a great truth is also true."
-Neils Bohr
Norman Ramsey
See a number of PLDI papers, possibly starting with this one:
Proceedings of the ACM SIGPLAN Symposium on Compiler Construction,
Proceedings of the ACM SIGPLAN Conference on Programming
Language Design
and Implementation (1979-) (Refs: 340)
@Article{appel:88,
author = "Andrew W. Appel and John R. Ellis and Kai
Li",
title = "Real-Time Concurrent Collection on Stock
Multiprocessors",
pages = "11--20",
journal = sigplan,
year = "1988",
month = jul,
volume = "23",
number = "7",
note = pldi88,
}
Hans Boehm
> The idea is to use an extra processor to do garbage collection.
>...
> Anyways here's the idea: Periodically, the entire program data
>space is copied into temporary space, along with a copy of the
>rootset. Unfortunately, the execution of the program must be halted
>for this. On the bright side, this could be done while the task would
>be halted ( I'm assuming a multitasking machine here ) anyways, so we
>might not lose very much.
>...
> If this could be done without copying the dataspace, it
>would, of course, be even better( or even fantastic ). I tend to
>think this turns out to be a necessary step.
You want to use a copy-on-write technique. You write-protect the
pages at the beginning of the collection, and copy them in response
to a write fault. The page can then be unprotected. The collector
looks at either the copied page, or the original page if there is none.
Mark Weiser and I mentioned this in our Sept. 1988 SP&E paper.
We were not the original inventors of this idea either. There is a reference
in the paper. We subsequently abandoned the idea in favor of the
approach described in the 1991 PLDI paper coauthored by Demers, Shenker,
and myself. The snapshot algorithm with copy-on-write probably has
slightly better pause times. But the later algorithm also allows
concurrency, has lower and more predictable space requirements, is
easier to implement, and requires less OS support.
Note that a stop-the-world snapshot probably takes roughly as much time
as a garbage collection. (I don't have the exact numbers here. On standard
hardware, it may take appreciably longer if there is any paging.)
Henry Baker
dha...@matisse.eecs.uic.edu (David Hanley) wrote:
This is a brilliant idea!!
Now look at the URL's
ftp://ftp.netcom.com/pub/hb/hbaker/RealTimeGC.html (also .ps.Z)
ftp://ftp.netcom.com/pub/hb/hbaker/CacheCGC.html (also .ps.Z)
(Great minds think alike! :-)
Ronald F. Guilmette
David Hanley <dha...@matisse.eecs.uic.edu> wrote:
>
> I had an idea, that, if practical, would go a long way to
>justifying GC for me. If this idea is not new( and I'm guessing it
>isn't ) could someone please comment about it to me?
>
Yea, like maybe all of those mostly-good Pentiums that paranoid people
are about to toss out. (1/2 :-)
--
-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: r...@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -
John Ellis
These languages [Eiffel, Scheme, Oberon] place restrictions on the
behavior of pointers, do not allow integers to be used as pointers
(or don't trace them) ... C++ does not have these restrictions ...
Contrary to the received wisdom, no significant restrictions need be
placed on the C++ language to allow for efficient garbage collection.
Compared to other GC langauges such as Eiffel, Oberon, Modula-3, Lisp,
etc. there are only three C++ language features that raise specific
issues for garbage collection: interior pointers, unions, and casts
from pointers to integers and back. Of these, only the last needs to
be restricted.
In implementations where a sufficiently large integer type exists, C++
allows a pointer to be cast to an integer and back to a pointer,
potentially hiding the pointer from the garbage collector. This
dubious language feature is not portable, since some implementations
may not have an integer type sufficiently large to hold a pointer.
There is no practical way for a collector to handle this language
feature, so its use must be prohibited when using GC. This is not an
important restriction.
For more information on C++ garbage collection, see "Safe, Efficient,
Garbage Collection for C++", by myself and Dave Detlefs
(ftp://ftp.parc.xerox.com/pub/ellis/gc).
I had to make the same restrictions on C++ behavior that Oberon
has. Unfortunately, since these restrictions couldn't be
enforced, the C++ code was slower than the corresponding Oberon
code (although it was at least as fast as code made in the normal
C++ style).
Can you give details about which restrictions on C++ code caused its
garbage collection to be slower than the corresponding Oberon code?
Taylor Hutt
John Ellis <el...@parc.xerox.com> wrote:
>Brian Hawley writes:
>
> These languages [Eiffel, Scheme, Oberon] place restrictions on the
> behavior of pointers, do not allow integers to be used as pointers
> (or don't trace them) ... C++ does not have these restrictions ...
> I had to make the same restrictions on C++ behavior that Oberon
> has. Unfortunately, since these restrictions couldn't be
> enforced, the C++ code was slower than the corresponding Oberon
> code (although it was at least as fast as code made in the normal
> C++ style).
>
>Can you give details about which restrictions on C++ code caused its
>garbage collection to be slower than the corresponding Oberon code?
Can you give details on the 'restrictions' on pointers in Oberon?
Paul Wilson
>justifying GC for me. If this idea is not new( and I'm guessing it
>isn't ) could someone please comment about it to me?
>
> The idea is to use an extra processor to do garbage collection.
>This would relieve the first processor for almost any memory management
>tasks. GC'd programs might therefore run even more quickly than manually
>msnsged ones. This might also be a good way to utilize extra processors
>on multiple-processor machines. Multiprocessor machines will be the
>norm in a couple of more years, IMHO.
>
> Comments?
>
One problem with parallelizing GC's is that the major cost of an
incremental or concurrent GC is often in the coordination between
the GC itself and the running application program. Parallelizing
the GC's tracing of reachable data only gets you so far, and then
you're up against the coordination costs, which are harder to
eliminate and are likely to be higher anyway, especially in an
incremental generational GC. (Generational techniques decrease
tracing costs at an increase in coordination costs.)
In the real-time context, this is especially important, because the
coordination costs are likely to be the most unpredictable---whether
the a program operation is expensive or cheap depends not only on
what the program itself is up to, but which data the collector has
traced so far and which data it hasn't.
This is one of the reasons we chose not to use a copying strategy
in our stock-hardware real-time GC. With a copy collector, you have
to coordinate changes by the collector (moving things around) with
what the program is doing, as well as coordination changes by the
application with what the GC is doing. It's easier to put reasonable
bounds on coordination costs if only the application is modifying
the data. (This is discussed in the paper pub/garbage/GC93/wilson.ps
on cs.utexas.edu, and more generally in the survey paper
pub/garbage/bigsurv.ps.)
As far as parallel GC goes, in some circumstance you may be better
of parallelizing the GC with itself, but not with the application
program, i.e., you can run the app in parallel for a while, then
stop and GC using all procesors for GC work.
Unfortunately, in a parallel system it's much harder to provide
real-time guarantees, because you can't guarantee that a parallel
GC will find enough parallelism to keep up with a parallel application.
In bad cases, the application may construct linear lists that take
a long time for the GC to traverse, and whose traversal can't be
parallelized in any reasonably efficient way. A more likely problem
is the construction of data structures that could in principle
be traversed in parallel, but which interact poorly with the GC's
task-spawning heuristics.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wil...@cs.utexas.edu)
| Recent papers on garbage collection, memory hierarchies, persistence and
| Scheme interpreters and compilers available via ftp from cs.utexas.edu
| (128.83.139.9), in pub/garbage or http://www.cs.utexas.edu/oops/)
Paul Wilson
Norman Ramsey <nor...@flaubert.bellcore.com> wrote:
>
>See a number of PLDI papers, possibly starting with this one:
>
> author = "Andrew W. Appel and John R. Ellis and Kai
>Li",
> title = "Real-Time Concurrent Collection on Stock
> Multiprocessors",
Anybody interested in real-time GC should be aware that this and other
algorithms that rely on virtual memory hardware for coordination are
not really real time (or at best, very, very soft real time).
Even Baker's real-time copying algorithm may not be usefully real-time
without specialized hardware support like Kelvin Nilsen's. Copying
collection is hard to make real-time without a significant performance
hit.
John Ellis
Anybody interested in real-time GC should be aware that this and
other algorithms that rely on virtual memory hardware for
coordination are not really real time (or at best, very, very soft
real time).
Even Baker's real-time copying algorithm may not be usefully real-time
without specialized hardware support like Kelvin Nilsen's.
A clarification: The only difference in real-time behavior between
Baker's real-time copying algorithm and a VM-synchronized copying
algorithm is a constant factor related to the page size. Both
algorithms have the property that pauses between program steps are
bounded by a constant, and both algorithms can slow the program's
progress for long, essentially unpredictable periods of time as the
program references data in from-space that must be copied to to-space.
The maximum pause between individual program steps in Baker's
algorithm is smaller, but the overall decrease in program progress is
essentially the same.
Paul is correct in saying that the known copying algorithms may not be
useful for many or most commercial applications labelled "real-time".
Henry Baker
Ellis) wrote:
> Paul Wilson writes:
>
> Anybody interested in real-time GC should be aware that this and
> other algorithms that rely on virtual memory hardware for
> coordination are not really real time (or at best, very, very soft
> real time).
>
> Paul is correct in saying that the known copying algorithms may not be
> useful for many or most commercial applications labelled "real-time".
I believe that Kaleida's ScriptX uses a version of my 'Treadmill'
RT GC algorithm. I don't know what its latencies are, but it is
supposedly good enough for multimedia. Although it doesn't copy, it is
isomorphic to a copying algorithm. WWW references URL's:
John Nagle
>Paul is correct in saying that the known copying algorithms may not be
>useful for many or most commercial applications labelled "real-time".
Many of the existing C/C++ storage allocators that don't use
garbage collection don't have hard upper bounds on response time,
either.
I used to be opposed to putting garbage collection into C++.
But memory leaks and bad pointers cause so much trouble in C++ that
it's worth considering, especially for GUI-type applications.
It's possible to get manual allocation right, but getting it right requires
that storage management be a primary consideration in design,
if not the primary consideration. This warps class library design.
C++ programs have to obsess on who owns what, even when who owns
what isn't a major functional issue for the program.
A good example is the distinction between collections and
containers. In Smalltalk, collections are a generally useful tool
for dealing with groups of objects, regardless of who owns them.
Containers include the concept of ownership; an object can't be in
two containers at once (at least for STL containers). This prevents
the use of containers for representing temporary groups of objects.
Yes, it's possible to work around this by adding an extra layer of
pointers, but it's unnecessarily messy.
John Nagle
Greg Morrisett
Paul Wilson <wil...@cs.utexas.edu> wrote:
>Anybody interested in real-time GC should be aware that this and other
>algorithms that rely on virtual memory hardware for coordination are
>not really real time (or at best, very, very soft real time).
>
>Even Baker's real-time copying algorithm may not be usefully real-time
>without specialized hardware support like Kelvin Nilsen's. Copying
>collection is hard to make real-time without a significant performance
>hit.
I disagree. See the work by Nettles and O'Toole.
They show that copying garbage collection can be done incrementally,
concurrently, and with guaranteed pause times. The basic idea is
to make a replica of the heap instead of destructively updating the
current version. Then the mutator (user's program) can access the
old replica while the collector is building the compacted replica.
The overheads are quite acceptable.
Here's some references all of which can be found at the following URL:
http://www.cs.cmu.edu:8001/afs/cs.cmu.edu/project/venari/www/home.html.
Concurrent Compacting Garbage Collection of a Persistent Heap.
James O'Toole, Scott Nettles, and David Gifford. Proceedings of SOSP '93.
Replication-Based Real-Time Garbage Collection. Scott Nettles and
James O'Toole. Prog. Language Design and Implementation '93.
Replication-Based Incremental Copying Collection Scott M. Nettles,
James W. O'Toole, David Pierce, and Nicholas Haines.
Proceedings of the SIGPLAN International Workshop on Memory Management,
1992.
Kelvin Nilsen
>>
>>Even Baker's real-time copying algorithm may not be usefully real-time
>>without specialized hardware support like Kelvin Nilsen's. Copying
>>collection is hard to make real-time without a significant performance
>>hit.
>I disagree. See the work by Nettles and O'Toole.
>They show that copying garbage collection can be done incrementally,
>concurrently, and with guaranteed pause times. The basic idea is
>to make a replica of the heap instead of destructively updating the
>current version. Then the mutator (user's program) can access the
>old replica while the collector is building the compacted replica.
>The overheads are quite acceptable.
The Nettles and O'Toole technique shows some promise. But I think
you are overstating their results. Last time I checked:
1. The guaranteed pause times were not really guaranteed in the analytical
sense. Rather, they were guaranteed in the sense of "tweak and tune
and measure". There are not very many developers of hard real-time
systems who are willing to trust this as a reliable guarantee. At the
very least, they would want a reliable characterization of the
parameter sensitivities upon which the worst-case latencies depend.
(If my application or the environment in which it runs changes a little
bit, how much more do I have to tweak and tune and measure in order
to reinstill confidence in its real-time behavior?)
2. Without hardware support, the guaranteed pause times are still rather
high, at least for the techniques detailed in the published papers.
The pause times are much too high to support many realistic real-time
workloads.
3. One of the main performance advantages of the Nettles, O'Toole et al
technique is that the GC bookkeeping overhead associated with every
read operation in Baker's algorithm is eliminated and replaced with
bookkeeping overhead associated with write operations in their algorithm.
In an applicative language like SML, this is a big win, because reads
are much more frequent than writes (the measurements reported so far
are based on applicative programming styles). However, it is not so
clear how this technique would perform on imperative programming
language workloads.
If you read their papers carefully, you will see that each describes
slightly different variants of an original idea. Furthermore, you will
find that none provides analytical proofs of real-time performance.
I have corresponded with Nettles and O'Toole in an attempt to nail them
down as to the worst-case behavior of their real-time garbage collector.
After going several rounds with them, they conceded that they had really
not considered their technique to be "real-time" in the "hard real-time"
sense of the word. Rather, they were thinking more in terms of
"interactive", in approximately the same sense that generational garbage
collectors are "real time".
By the way, I do not want to belittle the contributions of Nettles and
O'Toole. Their algorithms are interesting and useful. Their use of
the word "real-time" is not necessarily "wrong". It is consistent with
the use of the word by other researchers, especially those in the
"real-time garbage collection" community. I don't even want to state
that appropriate variants of their algorithm cannot be shown to be
"hard real-time". I simply want to point out that as of today:
1. Their techniques have not yet been shown to be hard real-time, and
doing so is a nontrivial problem.
2. Their techniques have not yet been empirically evaluated on workloads
that are representative of the imperative programming world (e.g. C++).
Paul Johnson
catagories of applications in the real-time world:
* Traditional control loops. These include the car engine management
mentioned earlier, and also aircraft engine management (FADEC)
and other avionics applications. These systems are characterised by
tight timing constraints (frequently the sample timing is part of the
stability analysis for the system) and no dynamic memory.
* Newer control systems, where more intelligence is required. E.g a
building with N lifts trying to minimise waiting time for lift
users. Simple control-loop algorithms will not work here: the
system must plan ahead using heuristics to keep the lifts fairly
evenly distributed through the building. These systems have looser
time constraints, but need dynamic memory allocation and garbage
collection.
Frequently a system can be partitioned into traditional and new
sections. For example the lift controller I mentioned above would
need hard-GC control loops for the individual lifts, to ensure that
they stopped in the right places, but the planning software could
afford to be a few hundred milliseconds late on occasion.
Paul.
--
Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. |
+44 245 473331 ext 3245 +-----------+-----------------------------------------+
Work: <p...@gec-mrc.co.uk> | You are lost in a twisty maze of little
Home: <Pa...@treetop.demon.co.uk> | standards, all different.
Paul Wilson
Henry Baker <hba...@netcom.com> wrote:
>>
>> Paul is correct in saying that the known copying algorithms may not be
>> useful for many or most commercial applications labelled "real-time".
>
>I believe that Kaleida's ScriptX uses a version of my 'Treadmill'
>RT GC algorithm. I don't know what its latencies are, but it is
>supposedly good enough for multimedia. Although it doesn't copy, it is
>isomorphic to a copying algorithm.
Kaleida's non-copying collector (due to Wade Hennessey) is basically a copy
of ours, using a snapshot write barrier rather than an incremental update
write barrier. (We hope to do some experiments with ours Real Soon, to
quantify the costs and benefits of both approaches.)
Our collector is, in turn, partly inspired by your treadmill algorithm,
generalized to deal with multiple object sizes, and using either Dijkstra
or Steele's incremental update write barrier (it's configurable to do
either) rather than a read barrier. (Thomas Wang had an earlier "fake
copying" GC for C, but it wasn't real-time.)
Paul Wilson
John Ellis <el...@parc.xerox.com> wrote:
>
>A clarification: The only difference in real-time behavior between
>Baker's real-time copying algorithm and a VM-synchronized copying
>algorithm is a constant factor related to the page size. Both
>algorithms have the property that pauses between program steps are
>bounded by a constant, and both algorithms can slow the program's
>progress for long, essentially unpredictable periods of time as the
>program references data in from-space that must be copied to to-space.
>The maximum pause between individual program steps in Baker's
>algorithm is smaller, but the overall decrease in program progress is
>essentially the same.
This is true for the worst case, making either algorithm unsuitable
for most hard real-time applications. If you only need soft real-time,
though, Baker's original copying algorithm probably comes out ahead
of the VM-assisted one, because of that constant related to the page
size. Sensitivity to inscrutable page-granularity locality problems
makes the VM-assisted approaches significantly more likely to run into
bad cases, IMHO.
If you can accept that kind of potential slowdown, though, the Appel-Ellis-Li
algorithm has some very nice features, like being able to work with standard
compilers and achieve reasonable efficiency.
John Ellis
prohibited to allow safe operation of C++ garbage collectors. Fergus
Henderson responds:
Yes, it's hardly a restriction at all, since the code wasn't
strictly conforming C++ anyway.
I disagree -- according to the ARM and the June '94 draft:
A value of integral type can be explicitly converted to a pointer.
A pointer converted to an integer of sufficient size (if any such
exists on the implementation) and back to the same pointer type
will have its original value; mappings between pointers and
integers are otherwise implementation-defined. [5.2.9]
Has this been changed in later versions of the draft working paper?
(This is a wierd corner of the language, since it explicitly defines
the behavior of a feature that won't work on all implementations. It
was inherited from C.)
Fergus also says that the following byte scrambling is conforming and
that therefore a garbage-collection proposal must prohibit it:
int i, *p;
unsigned char buf[sizeof(int*)], *p_rep = (char *) &p;
p = (int *)malloc(sizeof(int));
*p = 0;
for (i = 0; i < sizeof(int*); i++)
buf[i] = p_rep[sizeof(int*) - 1 - i];
I disagree. While this code "conforms", its behavior is unspecified
(implementation-dependent):
A pointer to an object can be explicitly converted to a pointer to
an object of different type. In general, the results of this are
unspecified... [5.2.9]
(Has this changed recently?)
Such constructs do not need to be explicitly prohibited by the
garbage-collection language proposal. According to the C++
specification, the behavior of any program that uses an
implementation-dependent construct is by definition
implementation-dependent, regardless of whether it uses garbage
collection. How an implementation's collector behaves in the presence
of such constructs is thus up to the implementation.
Our proposal contains a complete discussion of these safety issues.
Brian Hawley
: Brian Hawley writes:
: I had to make the same restrictions on C++ behavior that Oberon
: has. Unfortunately, since these restrictions couldn't be
: enforced, the C++ code was slower than the corresponding Oberon
: code (although it was at least as fast as code made in the normal
: C++ style).
: Can you give details about which restrictions on C++ code caused its
: garbage collection to be slower than the corresponding Oberon code?
The garbage collection code itself was not slower; all of the converted
code was. I believe that the difference arose when the C++ compiler tried
to optimize code that was logically structured to be efficient Oberon.
Certain common operations like type-tests are typically more efficient in
a single-inheritance system, and certain arithmetic operators behave
differently in Oberon. These differences had to be adjusted for, and the
adjusted operations were not as efficient.
It was not restrictions in C++ that caused the slowdown in any case. The
natural flexibility of C++ (mostly inherited from C) was the problem in
the situations where restriction was a factor. Because the restrictions
that were placed on the C++ code by its source (Oberon) were not known to
the C++ compiler, they could not be depended on for extra optimizations.
Also, the common expressions of the two languages aren't the same. A native
code compiler for Oberon has this knowledge and can take advantage of it.
Thanks for the gc reference. I look forward to reading it.