 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Le Chaud Lapin
Guest
|
 Posted: Wed Jun 01, 2005 9:33 pm Post subject: Pathology Of Bad Software Architecture |
 |
|
Salut All,
There is a thread running concurrently about the merits/demerits of
garbage collection. Some of us think that necessity for GC is, in many
cases, is a manifestation of lack of good form in software design and
might have been obviated by a design with greater structural integrity.
We are arguing that GC is often used as patch for a more fundamental
problem. Others are arguing that GC is sufficiently useful to C++ that
it should be integrated into the language.
Rather than continue in that post, I thought we should start in a fresh
context and expand the topic more broadly, since the essence of what we
anti-GC folks are arguing has not so much to do with GC, but the
pathology of bad software architecture.
IMO, this topic could equally apply to the situation where a programmer
infests his code with catch/re-throw constructs to potentially catch
exceptions that are thrown by functions worried about receiving
negative values for parameters that are inherently discrete and
non-negative - the infamous signed vs. unsigned int argument. The
essence of what we are saying is that a primary goal of software
engineering should be to structure a systems so that certain hard
questions never need be asked. In the case of int vs. unsigned int, we
(or at least I, if David likes int) will never create functions that
have int parameters representing quantities that are inherently
non-negative. The fruits of this discipline is that all concomitant
problems with what to do about all those ASSERT/try/catch blocks will
never need to be addressed.
But concerning GC, let me begin by saying that I never said that GC was
bad. Scheme was my 4th programming language - I cannot part with it,
so I keep that garbage-collecting monster on my laptop. What I said,
and what I think David was agreeing with, is that if you take a
particular software project where the programmer is begging for GC, and
examine closely why the programmer wants it, you might find that in
many cases, but not all, that the programmer is attempting to mititgate
a problem that would not existed had he chosen and alternate design
pattern that not only eliminates the need for GG, but actually yields
better overall form.
So to repeat, the essence of our argument is that there is a pathology
in programming, and whenever you have a defective system (leaking
memory for example), good form results from addressing the pathology,
not applying superficial mechanisms to cope with one of its
manifestations.
-Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Jun 02, 2005 12:49 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
Le Chaud Lapin wrote:
| Quote: | There is a thread running concurrently about the
merits/demerits of garbage collection. Some of us think that
necessity for GC is, in many cases, is a manifestation of lack
of good form in software design and might have been obviated
by a design with greater structural integrity. We are arguing
that GC is often used as patch for a more fundamental problem.
Others are arguing that GC is sufficiently useful to C++ that
it should be integrated into the language.
|
Which are really two unrelated things. That people can misuse
garbage collection seems to me to be obvious. People can misuse
addition, too. (And do -- I've seen more than a few cases of
addition where overflow would be possible for certain inputs.)
The fact that someone can misuse something has never been an
argument for not putting it in the langage. (We're not about to
remove addition, I hope. Although all things considered, it's
probably more error prone than garbage collection.)
There are really only two questions with regards to
standardization: can it be used usefully, and does it cost less
than the advantages. With regards to garbage collection, the
first seems to be obviously true. The second is more complex;
introducing garbage collection does have an effect on the
existing language, and the cost of this effect will not be
zero. But it is an analysis which can be carried out calmly,
without accusing those in favor of garbage collection of being
incompetent in algorithms, or such. An argument along the lines
of "garbage collection is too expensive because..." is quite
acceptable.
| Quote: | Rather than continue in that post, I thought we should start
in a fresh context and expand the topic more broadly, since
the essence of what we anti-GC folks are arguing has not so
much to do with GC, but the pathology of bad software
architecture.
|
To tell the truth, I suspect something like comp.programming or
comp.software-eng would be more appropriate formums. In my
experience, good architects are good architects in any language.
| Quote: | IMO, this topic could equally apply to the situation where a
programmer infests his code with catch/re-throw constructs to
potentially catch exceptions that are thrown by functions
worried about receiving negative values for parameters that
are inherently discrete and non-negative - the infamous signed
vs. unsigned int argument. The essence of what we are saying
is that a primary goal of software engineering should be to
structure a systems so that certain hard questions never need
be asked. In the case of int vs. unsigned int, we (or at
least I, if David likes int) will never create functions that
have int parameters representing quantities that are
inherently non-negative.
|
In mathematical terms, a cardinal, I think. Regretfully, C++
doesn't have any built-in type which models cardinals, and most
of us are too lazy to write a class to model it. (It is, of
course, a cost/benefits decision. Given that you have to range
check everything anyway, the benefits of such a class are
extremely limited.)
| Quote: | The fruits of this discipline is that all concomitant problems
with what to do about all those ASSERT/try/catch blocks will
never need to be addressed.
|
Generally, in a good design, you validate input in such a way
that later overflow (or invalid values) cannot occur. You don't
normally validate everywhere. Except, possibly, in debugging
code -- I very frequently use asserts like:
assert( i > 0 && i < someMax ) ;
If the upstream code is correct, of course, the assert will
never trigger.
| Quote: | But concerning GC, let me begin by saying that I never said
that GC was bad. Scheme was my 4th programming language - I
cannot part with it, so I keep that garbage-collecting monster
on my laptop. What I said, and what I think David was
agreeing with, is that if you take a particular software
project where the programmer is begging for GC, and examine
closely why the programmer wants it, you might find that in
many cases, but not all, that the programmer is attempting to
mititgate a problem that would not existed had he chosen and
alternate design pattern that not only eliminates the need for
GG, but actually yields better overall form.
|
So. Some people may want garbage collection for the wrong
reasons. But those haven't been the reasons people have been
putting forward here.
When Java first appeared, there were a number of specious claims
made about it, and some of its features. Including garbage
collection. ("Memory leaks are impossible", or "You don't have
to worry about resource management".) Such claims were largely
made by the marketing gurus -- regretfully, the technical people
behind Java didn't denounce them loud enough. And because Java
became the in language, a lot of less competent people adopted
them.
But if you look at the recent threads here, there have been no
such outrageous claims. The C++ community is more mature than
the Java community was at that time (and you hear a lot less
ridiculous claims about Java today), and the arguments here have
mainly been based on a cost/benefits basis.
| Quote: | So to repeat, the essence of our argument is that there is a
pathology in programming, and whenever you have a defective
system (leaking memory for example), good form results from
addressing the pathology, not applying superficial mechanisms
to cope with one of its manifestations.
|
Good form involves avoiding the problem to begin with. Using
the most cost effective means available. Garbage collection
reduces the amount of code you have to write, and simplifies
certain categories of code. Which means that it reduces total
development cost. Obviously, if you misuse it, you'll get into
trouble. Just as if you misuse addition.
If you don't have garbage collection, and you leak memory, the
program is incorrect. Nobody disputes this. If, however, you
want to design the program so that there are no leaks to begin
with, it is easier (less work, and thus cheaper) with garbage
collection.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Llewelly
Guest
|
| Posted: Thu Jun 02, 2005 10:53 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
"Le Chaud Lapin" <unoriginal_username (AT) yahoo (DOT) com> writes:
| Quote: | Salut All,
There is a thread running concurrently about the merits/demerits of
garbage collection. Some of us think that necessity for GC is, in many
cases, is a manifestation of lack of good form in software design and
might have been obviated by a design with greater structural integrity.
We are arguing that GC is often used as patch for a more fundamental
problem. Others are arguing that GC is sufficiently useful to C++ that
it should be integrated into the language.
|
What makes you think these two statements are mutually exclusive? I
don't believe there has ever been a useful feature that has not
been used to cover up a 'more fundamental problem'.
It seems to me the people who support GC are well aware of potential
misuses, but believe these are outweighed by the good uses.
| Quote: | Rather than continue in that post, I thought we should start in a fresh
context and expand the topic more broadly, since the essence of what we
anti-GC folks are arguing has not so much to do with GC, but the
pathology of bad software architecture.
IMO, this topic could equally apply to the situation where a programmer
infests his code with catch/re-throw constructs to potentially catch
exceptions that are thrown by functions worried about receiving
negative values for parameters that are inherently discrete and
non-negative - the infamous signed vs. unsigned int argument. The
essence of what we are saying is that a primary goal of software
engineering should be to structure a systems so that certain hard
questions never need be asked. In the case of int vs. unsigned int, we
(or at least I, if David likes int) will never create functions that
have int parameters representing quantities that are inherently
non-negative. The fruits of this discipline is that all concomitant
problems with what to do about all those ASSERT/try/catch blocks will
never need to be addressed.
|
A strategy that works beautfully for a programmer who re-invents every
wheel. Hundreds of existing useful libraries supply functions with
int parameters that can never have a valid non-negative value. Do
you wrap these libraries, or re-implement them? In the real world,
you will often not have time for either.
| Quote: |
But concerning GC, let me begin by saying that I never said that GC was
bad. Scheme was my 4th programming language - I cannot part with it,
so I keep that garbage-collecting monster on my laptop. What I said,
and what I think David was agreeing with, is that if you take a
particular software project where the programmer is begging for GC, and
examine closely why the programmer wants it, you might find that in
many cases, but not all, that the programmer is attempting to mititgate
a problem that would not existed had he chosen and alternate design
pattern that not only eliminates the need for GG, but actually yields
better overall form.
So to repeat, the essence of our argument is that there is a pathology
in programming, and whenever you have a defective system (leaking
memory for example), good form results from addressing the pathology,
not applying superficial mechanisms to cope with one of its
manifestations.
|
One person's pathology is another's optimization.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Le Chaud Lapin
Guest
|
| Posted: Fri Jun 03, 2005 7:50 am Post subject: Re: Pathology Of Bad Software Architecture |
|
|
Llewelly wrote:
| Quote: | What makes you think these two statements are mutually exclusive? I
don't believe there has ever been a useful feature that has not
been used to cover up a 'more fundamental problem'.
|
But there is a difference between a problem with the language and a
problem with the programmer. IMO, the problem of GC in C++ is most
often with the programmer. To take to opposite argument, one could say
that high-level languages like C++ are not necessary - assembly
language is good if the programmer simply learns how to type really
fast and know what to write at all times. Of course, that would be
silly. The "problem" really is with the language. A programmer can
have perfect form in assembly language and be exceptionally skilled at
producing perfect code and still not be able to compete with mediocre
programmer in a high-level language.
In the case of GC, I am saying that the programmer starts off with
something of bad form, "fixes" it with GC, and ends up with something
that has perfect memory usage and bad form.
| Quote: | A strategy that works beautfully for a programmer who re-invents every
wheel. Hundreds of existing useful libraries supply functions with
int parameters that can never have a valid non-negative value. Do
you wrap these libraries, or re-implement them? In the real world,
you will often not have time for either.
|
This is a good question. What _does_ one do when they use a function
f(x) from a third-party library that has return type of int when they
know that the return value can never be negative? Do you apply an
ASSERT to it? What if you are writing a function g(x) that uses f(x),
and you know that your g(x) could never return a negative value, but
you know that the person/people intending to use your function will
apply ASSERT on it if they see that the return value is int? Do you
put an ASSERT in your g(x)? Do you put a comment in the documentation
for g(x) saying, "Hey, even though I made this have return type int, it
will always return non-negative values, so you can relax and not ASSERT
it to death."
IMO opinion, in each of these two cases, the roots of the problem are:
1. GC: Programmer uses a "bones and ligaments" model, closely related
to the PIMPL idiom, forcing auto_ptrs<> and lack of true containment.
The fix is to rely more heavily on concrete types, and containers of
them, and use abstract types sparingly. I think it would be a good
exercise to take existing systems and see if it is possible to refactor
the classes (and overall structure) so that abstract types are almost
elminated. I think this is possible with heavy use of containers, but
not just a bunch of flat map<>'s. I am thinking thing of rich
structure like containers maping scalars to containers of objects
containing containers of containers of containers type scenarios.
2. ASSERTS on return type int vs unsigned int: Programmer is
attempting to accommodate an idea that is already conceptually
anomalous. The fix is to stop entertaining the absurd and write
internal functions correctly. If you use a function that has return
type of int, and you know that it is conceptually anomalous for that
function to return a negative value, don't wrap it in assert. Complain
to the author if possible, pretend type was unsigned int, and use it as
such.
-Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Allan W
Guest
|
| Posted: Fri Jun 03, 2005 7:51 am Post subject: Re: Pathology Of Bad Software Architecture |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote (formatting added):
| Quote: | There are really only two questions with regards to
standardization:
(1) can it be used usefully,
With regards to garbage collection, the first seems to be
obviously true.
|
Not sure it's obvious -- not even sure what "used usefully" means --
but I agree that GC would be useful for certain types of programs,
if we can pin down the answers to certain questions such as if,
when and how the destructor is fired.
| Quote: | and
(2) does it cost less than the advantages.
The second is more complex;
introducing garbage collection does have an effect on the
existing language, and the cost of this effect will not be
zero. But it is an analysis which can be carried out calmly,
without accusing those in favor of garbage collection of being
incompetent in algorithms, or such. An argument along the lines
of "garbage collection is too expensive because..." is quite
acceptable.
|
Yes.
Seems to me that there's a simple answer, too. Like most
features of the C++ language, we simply need to ensure that
programs which do NOT use it have zero (runtime) cost.
Just because that answer is simple doesn't make it easy.
I'd guess that the most difficult part would be some way of
recognizing *at a language level* that GC is, or is not, used.
(I am NOT talking about a compiler setting!) A related question
is how to mix code that DOES use GC, with code that DOES NOT.
I don't have answers to these parts -- that's not to say that
answers don't exist.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Stephen Howe
Guest
|
| Posted: Fri Jun 03, 2005 7:56 am Post subject: Re: Pathology Of Bad Software Architecture |
|
|
| Quote: | Others are arguing that GC is sufficiently useful to C++ that
it should be integrated into the language.
|
And those arguments will fall on deaf ears,until 2 questions are answered:
1. Is the proposed GC an optional part of C++ such that all those who have
no use of it are not forced to use it; or is it compulsory?
2. If it is optional, will all vendors be forced to supply GC or would it be
acceptable to supply a C++ compiler lacking a GC?
Until these questions are answered, nothing is worth discussing.
If it is compulsory, changing the meaning of the original language, then I
would venture to say GC will never make it in.
D is a good example of a language where GC is optional.
I can live with that.
Stephen Howe
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Jun 03, 2005 12:52 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
Allan W wrote:
| Quote: | kanze (AT) gabi-soft (DOT) fr wrote (formatting added):
There are really only two questions with regards to
standardization:
(1) can it be used usefully,
With regards to garbage collection, the first seems to be
obviously true.
Not sure it's obvious -- not even sure what "used usefully" means --
but I agree that GC would be useful for certain types of programs,
|
So it "can* be used usefully. The possibility exists.
| Quote: | if we can pin down the answers to certain questions such as
if, when and how the destructor is fired.
|
More generally, any feature must be defined in order to be used.
Up to a point: when the side effects of the ++ operator take
place are not strictly defined (sometime between the preceding
and the next sequence point), but it is still useful from time
to time.
| Quote: | and
(2) does it cost less than the advantages.
The second is more complex;
introducing garbage collection does have an effect on the
existing language, and the cost of this effect will not be
zero. But it is an analysis which can be carried out
calmly, without accusing those in favor of garbage
collection of being incompetent in algorithms, or such. An
argument along the lines of "garbage collection is too
expensive because..." is quite acceptable.
Yes.
Seems to me that there's a simple answer, too. Like most
features of the C++ language, we simply need to ensure that
programs which do NOT use it have zero (runtime) cost. Just
because that answer is simple doesn't make it easy. I'd guess
that the most difficult part would be some way of recognizing
*at a language level* that GC is, or is not, used.
|
The real question is how to specify that it is not being used.
If garbage collection requires a separate keyword (e.g. gcnew),
the problem is fairly trivial. Otherwise, I don't know.
| Quote: | (I am NOT talking about a compiler setting!) A related
question is how to mix code that DOES use GC, with code that
DOES NOT. I don't have answers to these parts -- that's not
to say that answers don't exist.
|
The question is whether the standard library be allowed to use
garbage collection; as far as the standard is concerned, all
other code is user code, and if user code uses garbage
collection, then garbage collection has been used. I can
imagine that some people would be unhappy if something like:
std::vector< char > raw( 1000 ) ;
caused garbage collection to be pulled in.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Daniel James
Guest
|
| Posted: Fri Jun 03, 2005 12:55 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
In article
news:<1117649979.600952.101330 (AT) g47g2000cwa (DOT) googlegroups.com>, Le Chaud
Lapin wrote:
| Quote: | ... never create functions that have int parameters representing
quantities that are inherently non-negative. The fruits of this
discipline is that all concomitant problems with what to do about
all those ASSERT/try/catch blocks will never need to be addressed.
|
I believe that is a false argument. The same program logic errors that
might lead to an int becoming unexpectedly negative will lead to an
unsigned int acquiring an unexpectedly large positive value. Assertions
(or whatever) in the code are not made less necessary by the change of
type.
--
Daniel James | djng
Sonadata Limited | at sonadata
UK | dot co dot uk
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Nicola Musatti
Guest
|
| Posted: Fri Jun 03, 2005 12:58 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
Le Chaud Lapin wrote:
[...]
| Quote: | In the case of GC, I am saying that the programmer starts off with
something of bad form, "fixes" it with GC, and ends up with something
that has perfect memory usage and bad form.
|
You fail to consider that GC may be a very reasonable solution to
memory management in many concrete situations. For instance, in the
application I'm working on when the user selects one of his/her
customers a rather complicate data structure is created. When the user
selects another customer I have no use for the previous customer's
data. Why do I have to waste programming time to
free such memory? If I had GC I wouldn't have to sprinkle my code with
shared_ptr's or some alternative scheme.
[...]
| Quote: | 1. GC: Programmer uses a "bones and ligaments" model, closely related
to the PIMPL idiom, forcing auto_ptrs<> and lack of true containment.
The fix is to rely more heavily on concrete types, and containers of
them, and use abstract types sparingly. I think it would be a good
exercise to take existing systems and see if it is possible to refactor
the classes (and overall structure) so that abstract types are almost
elminated. I think this is possible with heavy use of containers, but
not just a bunch of flat map<>'s. I am thinking thing of rich
structure like containers maping scalars to containers of objects
containing containers of containers of containers type scenarios.
|
When all's said and done it all boils down to how much client classes
see of the internal details of supplier classes. The use of abstract
classes helps minimize the interdependencies among implementation
details of different subsystems, thus reducing compile time and making
it possible to provide patches by replacing only parts of an
application.
Cheers,
Nicola Musatti
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Peter Dimov
Guest
|
| Posted: Fri Jun 03, 2005 12:59 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
Le Chaud Lapin wrote:
| Quote: | This is a good question. What _does_ one do when they use a function
f(x) from a third-party library that has return type of int when they
know that the return value can never be negative? Do you apply an
ASSERT to it?
|
Yes.
| Quote: | What if you are writing a function g(x) that uses f(x),
and you know that your g(x) could never return a negative value, but
you know that the person/people intending to use your function will
apply ASSERT on it if they see that the return value is int? Do you
put an ASSERT in your g(x)?
|
Sometimes.
| Quote: | Do you put a comment in the documentation
for g(x) saying, "Hey, even though I made this have return type int,
it will always return non-negative values,
|
Yes. It's not called a comment, it's called a Returns clause, and it's a
crucial part of the documentation. If you know what precisely is the
function supposed to return, you can always deduce whether negative values
are valid. And if you don't, you can't use the function.
| Quote: | so you can relax and not ASSERT it to death."
|
No.
Using types with a greater range than necessary helps the receiver of the
value check the assumptions of the sender. Testing whether the value is out
of range is an easy and surprisingly effective way of catching bugs.
In the signed/unsigned case specifically, C and C++ allow you to return -1
from a function returning unsigned, sometimes even without a warning. So
making the return type unsigned doesn't automatically mean that the return
value will be correct. It will be nonnegative, but still incorrect.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Jun 03, 2005 1:00 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
Stephen Howe wrote:
| Quote: | Others are arguing that GC is sufficiently useful to C++ that
it should be integrated into the language.
And those arguments will fall on deaf ears,until 2 questions
are answered:
1. Is the proposed GC an optional part of C++ such that all
those who have no use of it are not forced to use it; or is it
compulsory?
2. If it is optional, will all vendors be forced to supply GC
or would it be acceptable to supply a C++ compiler lacking a
GC?
Until these questions are answered, nothing is worth discussing.
|
And until there has been some discussing, there can be no answer
to these questions.
There's already been some discussion, of course, and I gather
that there is pretty much a consensus that the answer to the
first is no. But more discussion is still needed to determine
when and if I implicitly use it: obviously, std::string should
use it, but std::vector?
| Quote: | If it is compulsory, changing the meaning of the original
language, then I would venture to say GC will never make it
in.
|
I think that there is a concensus on that, yes. Especially the
"changing the meaning of the original language" part; any
proposal which would change the meaning of, or invalidate,
currently legal programs will have a very hard time getting
adopted. (With certain limits, of course. I don't think
introducing a new keyword, e.g. gc_new, would make adoption
impossible, even if it breaks programs which already use that
keyword as a user defined symbol.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Jun 03, 2005 1:00 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
Le Chaud Lapin wrote:
| Quote: | Llewelly wrote:
What makes you think these two statements are mutually exclusive? I
don't believe there has ever been a useful feature that has not
been used to cover up a 'more fundamental problem'.
But there is a difference between a problem with the language
and a problem with the programmer. IMO, the problem of GC in
C++ is most often with the programmer. To take to opposite
argument, one could say that high-level languages like C++ are
not necessary - assembly language is good if the programmer
simply learns how to type really fast and know what to write
at all times. Of course, that would be silly.
|
But that is, fundamentally, exactly what you are saying. A good
programmer can write assembler, so we don't need C, much less
C++.
| Quote: | The "problem" really is with the language. A programmer can
have perfect form in assembly language and be exceptionally
skilled at producing perfect code and still not be able to
compete with mediocre programmer in a high-level language.
|
Exactly. And exactly the same argument holds for garbage
collection. A good programmer needs less effort to achieve the
same results with garbage collection.
| Quote: | In the case of GC, I am saying that the programmer starts off
with something of bad form, "fixes" it with GC, and ends up
with something that has perfect memory usage and bad form.
|
So you're claiming that the only possible use of garbage
collection is fixing broken programs. That doesn't correspond
to the reasons which the proponents of garbage collection are
putting forth. If you don't want garbage collection, why not
address those reasons, instead of inventing some imaginary uses
of garbage collection.
| Quote: | A strategy that works beautfully for a programmer who
re-invents every wheel. Hundreds of existing useful libraries
supply functions with int parameters that can never have a
valid non-negative value. Do you wrap these libraries, or
re-implement them? In the real world, you will often not have
time for either.
This is a good question. What _does_ one do when they use a
function f(x) from a third-party library that has return type
of int when they know that the return value can never be
negative?
|
The same thing one always does, whenever the return value has a
limited range (which is usually the case).
| Quote: | Do you apply an ASSERT to it?
|
It partially depends on what you are doing with the value.
Posix guarantees that the return value of open will be either
-1, or a small, non-negative value. I check for -1, because it
is a sentinal value, with special semantics, but otherwise, I
trust it. After all, the only thing I do with the value is pass
it back to Posix.
In other cases, I have been known to verify that the return
value of streambuf->sgetc() is either -1 or in the range
0...UCHAR_MAX. For example, if I am using it as an index into a
table.
I'm more trusting of lower level code; I test arguments a lot
more than I test return values.
So the answer is: there is no general rule.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Fri Jun 03, 2005 3:17 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
"Peter Dimov" <pdimov (AT) gmail (DOT) com> writes:
| Quote: | Le Chaud Lapin wrote:
so you can relax and not ASSERT it to death."
No.
Using types with a greater range than necessary helps the receiver of the
value check the assumptions of the sender. Testing whether the value is out
of range is an easy and surprisingly effective way of catching bugs.
In the signed/unsigned case specifically, C and C++ allow you to return -1
from a function returning unsigned, sometimes even without a warning. So
making the return type unsigned doesn't automatically mean that the return
value will be correct. It will be nonnegative, but still incorrect.
|
Yeah, this one is debatable, IMO. I understand what Peter's saying,
but I still prefer to use unsigned. The logic is that when a signed
negative number wraps, it is almost always closer to zero than to
INT_MIN, so it will wrap to a very large positive number and whatever
assert() I'm using to check that the value isn't too large is also
going to catch these cases. It's a tradeoff between expressiveness
and economy of code on the one hand, and absolute ability to catch
errors on the other. I happen to think the balance goes in favor of
using unsigned, but I understand why others don't.
To see that this all lies on a continuum, think about references.
"Everyone knows" it's possible to create a NULL reference if you try
hard enough, but "nobody" checks for them. Unfortunately, it's easier
to get into trouble with int than it is with references  .
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Larry Evans
Guest
|
| Posted: Fri Jun 03, 2005 3:20 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
On 06/03/2005 02:50 AM, Le Chaud Lapin wrote:
| Quote: | Llewelly wrote:
[snip]
IMO opinion, in each of these two cases, the roots of the problem are:
1. GC: Programmer uses a "bones and ligaments" model, closely related
[snip]
elminated. I think this is possible with heavy use of containers, but
not just a bunch of flat map<>'s. I am thinking thing of rich
structure like containers maping scalars to containers of objects
containing containers of containers of containers type scenarios.
You lost me here. Pseudo code or real c++ would clarify, possibly |
with "before" and "after" shots (e.g. bad code showing the problem
and good code showing the above solution).
| Quote: |
2. ASSERTS on return type int vs unsigned int: Programmer is
[snip]
function to return a negative value, don't wrap it in assert. Complain
to the author if possible, pretend type was unsigned int, and use it as
such.
I certainly agree. |
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Robert Kindred
Guest
|
| Posted: Fri Jun 03, 2005 3:21 pm Post subject: Re: Pathology Of Bad Software Architecture |
|
|
"Peter Dimov" <pdimov (AT) gmail (DOT) com> wrote
| Quote: | Le Chaud Lapin wrote:
[]
This is a good question. What _does_ one do when they use a function
f(x) from a third-party library that has return type of int when they
know that the return value can never be negative? Do you apply an
ASSERT to it?
Yes.
Using types with a greater range than necessary helps the receiver of the
value check the assumptions of the sender. Testing whether the value is
out
of range is an easy and surprisingly effective way of catching bugs.
In the signed/unsigned case specifically, C and C++ allow you to return -1
from a function returning unsigned, sometimes even without a warning. So
making the return type unsigned doesn't automatically mean that the return
value will be correct. It will be nonnegative, but still incorrect.
|
This reminds me of Ray Lischner's question as to why currency is a signed
value in some program. Your answer is better than mine.
Robert Kindred
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
