* Re: Software landmines (was: Why C++ is successful)
@ 1998-08-22 0:00 dewar
1998-08-23 0:00 ` Dale Stanbrough
1998-08-24 0:00 ` Richard D Riehle
0 siblings, 2 replies; 74+ messages in thread
From: dewar @ 1998-08-22 0:00 UTC (permalink / raw)
<<A 'return', at least in C/C++/VB, returns you to the place the current
procedure was called from. 'goto' control flow can be endlessly channeled
here and there and never has to return to where the initial linear control
flow was originally diverted. That seems to be a huge advantage of 'return'
over 'goto'.
>>
No, it is a huge advantage of return over a *bad* use of goto. But nearly
every feature in a language can be badly misused. We didn't eliminate
assignments from Ada, even though they can be (and are all the time)
horribly misused, and even though we know perfectly well that you can
write programs with no assignments with no loss in expressive power.
Instead we left in the assignment, and wise programmers use it to improve
the clarity of their programs, and foolish programmers create havoc with
it (by the way most programmers furiously overuse assignments, and it is
far too common to see a variable assignment used to establish a constant
value -- of course languages like traditional C which have no capability
for defining constants aggravate the problem!)
The goto is the same, wise programmers use it occasionally to clarify
their code, foolish programmers create havoc with it (although this happens
less often, since people are FAR more aware of the goto danger than the
assignment danger).
Fanatics in both cases decry straying from the pure road (yes there
are plenty of people who consider an assignment statement as just as
evil as a goto, and would not dream of using either :-)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-22 0:00 Software landmines (was: Why C++ is successful) dewar @ 1998-08-23 0:00 ` Dale Stanbrough 1998-08-23 0:00 ` dewar 1998-08-23 0:00 ` Andi Kleen 1998-08-24 0:00 ` Richard D Riehle 1 sibling, 2 replies; 74+ messages in thread From: Dale Stanbrough @ 1998-08-23 0:00 UTC (permalink / raw) dewar@gnat.com wrote: "No, it is a huge advantage of return over a *bad* use of goto. But nearly every feature in a language can be badly misused. We didn't eliminate assignments from Ada, even though they can be (and are all the time) horribly misused, and even though we know perfectly well that you can write programs with no assignments with no loss in expressive power." Do you have examples of the bad/excessive use of assignment statements? Dale ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-23 0:00 ` Dale Stanbrough @ 1998-08-23 0:00 ` dewar 1998-08-23 0:00 ` Andi Kleen 1 sibling, 0 replies; 74+ messages in thread From: dewar @ 1998-08-23 0:00 UTC (permalink / raw) In article <dale-2308981004320001@dale.ppp.cs.rmit.edu.au>, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > dewar@gnat.com wrote: > > "No, it is a huge advantage of return over a *bad* use of goto. But nearly > every feature in a language can be badly misused. We didn't eliminate > assignments from Ada, even though they can be (and are all the time) > horribly misused, and even though we know perfectly well that you can > write programs with no assignments with no loss in expressive power." > > Do you have examples of the bad/excessive use of assignment statements? > > Dale > Well of course there are many programmers, who in a manner analogous to the "gotophobes" consider *any* assignment statement as anathematic, and prefer languages where no assignments are allowed. It is of course common knowledge that assignment statements are unnecessary, and that just as it is possible to program without gotos, it is possible to program without assignment statements. Indeed it is a good excercise at least to make students learning Ada or some other reasonable language that has appropriate features, write a program avoiding assignment statements completely. But in normal use of a language like Ada, it certainly is relatively unlikely that many people would agree to this kind of extremism. It is actually probably the case that many Ada programmers would find the notion of programming without assignments as bizarre and foreign (in much the same way as a Fortran-67 programmer considers programming without gotos as bizarre, oops, that should be Fortran66). As for programs that overuse assignments these are indeed common. In fact it is rare that I see a big Ada program that does not have instances of initialized declarations of variables without a constant keyword that are in fact constants. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-23 0:00 ` Dale Stanbrough 1998-08-23 0:00 ` dewar @ 1998-08-23 0:00 ` Andi Kleen 1 sibling, 0 replies; 74+ messages in thread From: Andi Kleen @ 1998-08-23 0:00 UTC (permalink / raw) dale@cs.rmit.edu.au (Dale Stanbrough) writes: > dewar@gnat.com wrote: > > "No, it is a huge advantage of return over a *bad* use of goto. But nearly > every feature in a language can be badly misused. We didn't eliminate > assignments from Ada, even though they can be (and are all the time) > horribly misused, and even though we know perfectly well that you can > write programs with no assignments with no loss in expressive power." > > Do you have examples of the bad/excessive use of assignment statements? Assignments are equivalent to gotos. Just write the function as a big loop case .. statement, then you can use assignments as goto. In functional programming languages like ML or Scheme it is possible and easy to write assignless code, but these have lots of special tools (e.g. easy closures) that make that easier. -Andi ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-22 0:00 Software landmines (was: Why C++ is successful) dewar 1998-08-23 0:00 ` Dale Stanbrough @ 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` dennison ` (3 more replies) 1 sibling, 4 replies; 74+ messages in thread From: Richard D Riehle @ 1998-08-24 0:00 UTC (permalink / raw) In article <6rnhhe$e2u$1@nnrp1.dejanews.com>, dewar@gnat.com wrote: >... We didn't eliminate >assignments from Ada, even though they can be (and are all the time) >horribly misused, and even though we know perfectly well that you can >write programs with no assignments with no loss in expressive power. I cannot imagine writing a large program totally devoid of assignment statements. In fact, I sometimes see people programming around the assignment by parenthetical nesting of function returns and find it confusing, reminsicent of the German sentences of philosophers who, in an attempt to extract every nuance from an idea without leaving any possibility for misinterpretation, along with, what seems to be an attempt to avoid using an excessive number of periods in their sentences, construct long, dependent clause-filled sentences, the effect of which is to leave one, if, in fact, one is still reading, without any sense of what the original idea might have been from the beginning. Don't take away my assignment statements, Robert. The help me write crisp, short code sentences that ordinary mortals can understand. In fact, as an old time Fortranner, I sometimes write a function that looks like, function F ( ... ) return some-data-type is Result : some-data-type := initial-value; begin Result := algorithmic-part; return Result; end F; >... most programmers furiously overuse assignments, and it is >far too common to see a variable assignment used to establish a constant >value I am not sure what you mean. If I want to define constants, Zero : constant := 0; Null_List := some-value; how do I set the initial value without assignment. For private members in C++ this is really easy without assignment. I can use (must use) an initialization list. In Ada we have to have an assignment somewhere to make this happen. of course languages like traditional C which have no capability >for defining constants aggravate the problem!) But this is not true for C++ where one can use the initialization list as shown above and one can even define a function as a const, the parameters as const, etc. In this respect, C++ is a little more powerful (read, safer) than Ada especially when using pointers as parameters. For lots of other reasons, I still prefer Ada. Richard Riehle richard@adaworks.com www.adaworks.com ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Richard D Riehle @ 1998-08-25 0:00 ` dennison 1998-08-25 0:00 ` Andi Kleen ` (2 subsequent siblings) 3 siblings, 0 replies; 74+ messages in thread From: dennison @ 1998-08-25 0:00 UTC (permalink / raw) In article <6rsg0d$pcj@dfw-ixnews3.ix.netcom.com>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > statements. In fact, I sometimes see people programming around the > assignment by parenthetical nesting of function returns and find it > confusing, reminsicent of the German sentences of philosophers who, > in an attempt to extract every nuance from an idea without leaving any > possibility for misinterpretation, along with, what seems to be an > attempt to avoid using an excessive number of periods in their sentences, > construct long, dependent clause-filled sentences, the effect of which > is to leave one, if, in fact, one is still reading, without any sense > of what the original idea might have been from the beginning. Wow. You even write self-documenting prose. :-) -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` dennison @ 1998-08-25 0:00 ` Andi Kleen 1998-08-25 0:00 ` Brian Rogoff 1998-08-28 0:00 ` Matthew Heaney [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> 3 siblings, 1 reply; 74+ messages in thread From: Andi Kleen @ 1998-08-25 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > > Don't take away my assignment statements, Robert. The help me write > crisp, short code sentences that ordinary mortals can understand. In > fact, as an old time Fortranner, I sometimes write a function that > looks like, > > function F ( ... ) return some-data-type is > Result : some-data-type := initial-value; > begin > Result := algorithmic-part; > return Result; > end F; I think you misunderstand. Even purely functional languages like ML have a way to write this so that you don't have to put the complete program into one expression. What they don't have, and I think that is what Robert was refering to, is a way to cause side effects and change the program state by an assignment. -Andi ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-25 0:00 ` Andi Kleen @ 1998-08-25 0:00 ` Brian Rogoff 0 siblings, 0 replies; 74+ messages in thread From: Brian Rogoff @ 1998-08-25 0:00 UTC (permalink / raw) On 25 Aug 1998, Andi Kleen wrote: > Richard D Riehle <laoXhai@ix.netcom.com> writes: > > > > Don't take away my assignment statements, Robert. The help me write > > crisp, short code sentences that ordinary mortals can understand. In > > fact, as an old time Fortranner, I sometimes write a function that > > looks like, > > > > function F ( ... ) return some-data-type is > > Result : some-data-type := initial-value; > > begin > > Result := algorithmic-part; > > return Result; > > end F; > > I think you misunderstand. Even purely functional languages like ML have I think ML is what most FPers would call impure, since the MLs that I know of, SML and CAML, both have assignable references. ML is "functional" in that it has higher-order functions, but the designers of ML consciously included assignment. If you look closely, you can see a little bit of ML in Ada-95. -- Brian ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` dennison 1998-08-25 0:00 ` Andi Kleen @ 1998-08-28 0:00 ` Matthew Heaney 1998-08-28 0:00 ` Richard D Riehle [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> 3 siblings, 1 reply; 74+ messages in thread From: Matthew Heaney @ 1998-08-28 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > >... most programmers furiously overuse assignments, and it is > >far too common to see a variable assignment used to establish a constant > >value > > I am not sure what you mean. If I want to define constants, > > Zero : constant := 0; > Null_List := some-value; > > how do I set the initial value without assignment. For private > members in C++ this is really easy without assignment. I can use > (must use) an initialization list. In Ada we have to have an > assignment somewhere to make this happen. The issue lies in the difference between "assignment" and "binding." The problem with Ada is that the syntax for both is the same, so whenever people see ":=" they always think of assignment, even when it really means binding. In the example above, Zero : constant := 0; is a binding operation, not an assignment operation. The name Zero is bound to a value. Indeed, any time you see the keyword "constant" in a declaration, then you should treat that to mean "bind," not "assign." Ada is wildly inconsistent wrt binding. To bind a name to a function, I use the keyword "is": function F (X : T1) return T2 is begin <body> end F; means the same thing as type FT is function (X : T1) return T2; F : constant FT := begin <body> end; Why not use the operator "is" everywhere binding is intended? I think it's true that in Eiffel, binding doesn't use the assignment operator, it uses the keyword "is", as in Zero : Integer is 0; which is the equivalent of Zero : constant Integer := 0; in Ada. So when Robert says "programmers misuse assignment," he means (I think) that they are using assignment when they really want to use binding. The latter use is indicating by the presence of the keyword "constant". Unfortunately, the syntax for binding in Ada also uses the assignment operator, so Ada programmers blur the distinction between binding and assignment (if they are aware of it at all). I regard this as a flaw in the language. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` Matthew Heaney @ 1998-08-28 0:00 ` Richard D Riehle 1998-08-29 0:00 ` Matthew Heaney 1998-08-29 0:00 ` Matthew Heaney 0 siblings, 2 replies; 74+ messages in thread From: Richard D Riehle @ 1998-08-28 0:00 UTC (permalink / raw) In article <m3g1eithld.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: In response to Richard Riehle's question about initialization of values with the assignment statement, > >The issue lies in the difference between "assignment" and "binding." I ran to my bookshelf to find an entry in any computer science text on "binding" in the context you have used it. None. Reference, please. >The problem with Ada is that the syntax for both is the same, so >whenever people see ":=" they always think of assignment, even when it >really means binding. I understand the distinction, and your reference to Eiffel, below, is correct. >In the example above, > Zero : constant := 0; >is a binding operation, not an assignment operation. The name Zero is >bound to a value. So, in this respect, C++ initialization lists better express the "binding" requirement than Ada assignments. >Indeed, any time you see the keyword "constant" in a declaration, then >you should treat that to mean "bind," not "assign." >Ada is wildly inconsistent wrt binding. To bind a name to a function, I >use the keyword "is": > >function F (X : T1) return T2 is >begin > <body> >end F; > >means the same thing as > >type FT is function (X : T1) return T2; > >F : constant FT := begin <body> end; > >Why not use the operator "is" everywhere binding is intended? Your function example is interesting. In an Eiffel feature declaration, the syntatical placement for "is" in declaring a function is the same as Ada rather than as you prefer. >I think it's true that in Eiffel, binding doesn't use the assignment >operator, it uses the keyword "is", as in > > Zero : Integer is 0; > This is true. A feature declaration in Eiffel is the same for any declaration. This is called by Bertrand, "the principle of minimum surprise." When referencing any feature in an Eiffel class, the client of the class sees attributes identically to functions. An "is" is used only for constant or routine feature. Non-constant attributes are not initialized with a "is" keyword. Also, the Eiffel model for "attachment" and "reattachment" more closely approximates what you and Robert are describing as alternatives to excessive use of the assignment statement. With that understanding in place, I suggest that, in using the assignment operation for defining constants, the difference between "binding" and "assignment" is a rather subtle semantic issue for most practical programmers. Also, several consecutive assignment statements in Ada will often be more readable than the parentheticaly clauses of function returns that serve as their substitute. Ada, unlike Eiffel, is not designed to reduce the number of assignment statements. The suggestion that we use fewer assignment statements is liable to create the same mess that "gotoless" programming fomented in the COBOL world. Robert knows that pre-ANSI 85 COBOL was inadequately designed to support programs without GO TO statements. Only with the advent of "END ..." constructs did COBOL become more amenable to reducing the number of GO TO's. Ada is designed to encourage the use of the assigment statement. Suggesting that we do not use it so often is probably counterproductive and can only be realized with some important changes in the language. You have already noted some of these, Matthew. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` Richard D Riehle @ 1998-08-29 0:00 ` Matthew Heaney 1998-08-29 0:00 ` Matthew Heaney 1 sibling, 0 replies; 74+ messages in thread From: Matthew Heaney @ 1998-08-29 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > >The issue lies in the difference between "assignment" and "binding." > > I ran to my bookshelf to find an entry in any computer science text > on "binding" in the context you have used it. None. Reference, please. Here are some references: Programming Language Concepts and Paradigms David A. Watt Programming Languages: Design and Implementation Terrence W. Pratt and Marvin V. Zelkowitz Principles of Programming Languages R.D. Tennent Programming Language Structures Carlo Ghezzi and Mehdi Jazayeri Although they're a bit heavy on the theory, you might also want to take a look at: Introduction to the Theory of Programming Languages Bertrand Meyer The Denotational Description of Programming Languages Michael Gordon The Meyer book contains a good description of the meaning of assignment. Hope that helps, Matt ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` Richard D Riehle 1998-08-29 0:00 ` Matthew Heaney @ 1998-08-29 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1 sibling, 1 reply; 74+ messages in thread From: Matthew Heaney @ 1998-08-29 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > So, in this respect, C++ initialization lists better express the > "binding" requirement than Ada assignments. One of the areas in Ada in which the assignment vs initialization issue arises is in the declaration of limited types: declare O : LT; begin Initialize (O); <use O> The thing I find distasteful here is that the initialization of object O occurs after its declaration. Sometimes this means the state of O is undefined. (However, many times limited objects come with a defined, default state. For example, Is_Open is defined to return False for a newly declared instance of File_Type.) I've advocated in the past that the language syntax should be amended to add an initialization operation ("constructor"): declare File : File_Type'Open (In_Mode, "matt.dat"); begin We could even use the constant keyword in such a declaration. > Also, several consecutive assignment statements in Ada will often be > more readable than the parentheticaly clauses of function returns that > serve as their substitute. Agree. I often see programmers use many nested function calls in an expression. What I have to do then is to mentally unravel the expression. So why not save me the trouble? Use a declare block to declare a few intermediate objects, and feed them to the ultimate subprogram call. > The suggestion that we use fewer assignment statements is liable to > create the same mess that "gotoless" programming fomented in the COBOL > world. Let's make sure everyone knows what this means: o It DOES mean "don't use a variable when a constant will do." o It does NOT mean "use nested function calls to return intermediate values, instead of declaring intermediate constant objects" Yes, you really should use constant object declarations to hold intermediate values, even though this requires a few more "assignments." (The scare quotes are there to remind the reader that the declaration of a constant object isn't really an assignment.) > Ada is designed to encourage the use of the assigment statement. Yes. Far too few programmers use declare blocks and constant object declarations to simplify complex expressions. Instead of Op (Get_A (10), Get_B (X), Get_C (Y)); it's better to do declare A : constant Integer := Get_A (10); B : constant Float := Get_B (X); C : constant Boolean := Get_C (Y); begin Op (A, B, C); end; As we have noted, the declarations above aren't really "assignment" statements. They are "binding" operations. The distinction would be more clear (and consistent) if the language allowed you to say: declare A : Integer is Get_A (10); B : Float is Get_B (X); C : Boolean is Get_C (Y); begin Op (A, B, C); end; The "renames" clause is a binding operator in Ada (although technically it binds a name to an object, not a value). A hip way to do the above directly in the language is declare A : Integer renames Get_A (10); B : Float renames Get_B (X); C : Boolean renames Get_C (Y); begin Op (A, B, C); end; That way we can avoid the use of the assignment operator, so the declaration won't be confused with an assignment statement. It's a bit of a bummer that we have 3 ways ("constant T :=", "renames", "is") of doing essentially the same thing. Why not just one way? > Suggesting that we do not use it so often is probably > counterproductive and can only be realized with some important changes > in the language. An unambiguous way to say this is that, in a declaration, you should use the keyword "constant" whenever the object doesn't change its value. Yet another way to say this is "don't use assignment when you really mean binding." Matt P.S. About the meaning of binding: let me dig up my books on programming language theory. You usually see it mentioned in books about functional programming, and in explications of denotational semantics. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-29 0:00 ` Matthew Heaney @ 1998-09-06 0:00 ` John G. Volan 1998-09-07 0:00 ` Mats Weber 0 siblings, 1 reply; 74+ messages in thread From: John G. Volan @ 1998-09-06 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > Yes. Far too few programmers use declare blocks and constant object > declarations to simplify complex expressions. Instead of > > Op (Get_A (10), Get_B (X), Get_C (Y)); > > it's better to do > > declare > A : constant Integer := Get_A (10); > B : constant Float := Get_B (X); > C : constant Boolean := Get_C (Y); > begin > Op (A, B, C); > end; There's a subtle difference between these two examples: In the latter case, the local constant declarations will be elaborated in the indicated order, so the function calls are going to be done sequentially. But in the former case, the language defines no particular order of evaluation of the actual procedure parameters, so these function calls might occur in any order. A smart compiler for the right kind of target machine may even be able to schedule these calls to occur in parallel. ... > The "renames" clause is a binding operator in Ada (although technically > it binds a name to an object, not a value). A hip way to do the above > directly in the language is > > declare > A : Integer renames Get_A (10); > B : Float renames Get_B (X); > C : Boolean renames Get_C (Y); > begin > Op (A, B, C); > end; I'm curious: Does this have the same effect as the above, i.e., are the function calls forced into a sequential order? Or is their evaluation deferred until the aliases A, B, and C are actually used as parameters to the Op call, in which case the aliased function calls get executed in an undefined order? -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-06 0:00 ` John G. Volan @ 1998-09-07 0:00 ` Mats Weber 1998-09-07 0:00 ` dewarr 0 siblings, 1 reply; 74+ messages in thread From: Mats Weber @ 1998-09-07 0:00 UTC (permalink / raw) John G. Volan wrote: > > declare > > A : Integer renames Get_A (10); > > B : Float renames Get_B (X); > > C : Boolean renames Get_C (Y); > > begin > > Op (A, B, C); > > end; > > I'm curious: Does this have the same effect as the above, i.e., are the > function calls forced into a sequential order? Or is their evaluation > deferred until the aliases A, B, and C are actually used as parameters > to the Op call, in which case the aliased function calls get executed in > an undefined order? Yes, it has the same effect. Each function call is evaluated during the elaboration of the renames it appears in. You are in fact renaming the object that contains the function result. (See RM 3.3(10)). ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-07 0:00 ` Mats Weber @ 1998-09-07 0:00 ` dewarr 1998-09-08 0:00 ` Tucker Taft 1998-09-16 0:00 ` Software landmines (was: Why C++ is successful) Matthew Heaney 0 siblings, 2 replies; 74+ messages in thread From: dewarr @ 1998-09-07 0:00 UTC (permalink / raw) In article <35F3FF42.D1E163E0@elca-matrix.ch>, Mats.Weber@elca-matrix.ch wrote: > John G. Volan wrote: > > > > declare > > > A : Integer renames Get_A (10); > > > B : Float renames Get_B (X); > > > C : Boolean renames Get_C (Y); > > > begin > > > Op (A, B, C); > > > end; > > > > I'm curious: Does this have the same effect as the above, i.e., are the > > function calls forced into a sequential order? Or is their evaluation > > deferred until the aliases A, B, and C are actually used as parameters > > to the Op call, in which case the aliased function calls get executed in > > an undefined order? > > Yes, it has the same effect. Each function call is evaluated during the > elaboration of the renames it appears in. You are in fact renaming the object > that contains the function result. (See RM 3.3(10)). > I must say that I find the renaming of function calls like this to be a confusing oddity. It seems much clearer to me to use ordinary constant declarations. The two seem completely equivalent! -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-07 0:00 ` dewarr @ 1998-09-08 0:00 ` Tucker Taft 1998-09-08 0:00 ` Precalculation of parameters (was: Software landmines) dennison 1998-09-16 0:00 ` Software landmines (was: Why C++ is successful) Matthew Heaney 1 sibling, 1 reply; 74+ messages in thread From: Tucker Taft @ 1998-09-08 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote: : In article <35F3FF42.D1E163E0@elca-matrix.ch>, : Mats.Weber@elca-matrix.ch wrote: : > John G. Volan wrote: : > : > > > declare : > > > A : Integer renames Get_A (10); : > > > B : Float renames Get_B (X); : > > > C : Boolean renames Get_C (Y); : > > > begin : > > > Op (A, B, C); : > > > end; : > > : > > I'm curious: Does this have the same effect as the above, i.e., are the : > > function calls forced into a sequential order? Or is their evaluation : > > deferred until the aliases A, B, and C are actually used as parameters : > > to the Op call, in which case the aliased function calls get executed in : > > an undefined order? : > : > Yes, it has the same effect. Each function call is evaluated during the : > elaboration of the renames it appears in. You are in fact renaming the object : > that contains the function result. (See RM 3.3(10)). : > : I must say that I find the renaming of function calls : like this to be a confusing oddity. It seems much clearer : to me to use ordinary constant declarations. The two : seem completely equivalent! They are equivalent unless the result type is return-by-reference. If the result-type is return-by-reference, only the rename would be legal, and simply denotes the same object denoted by the original return statement's expression. If the result-type is the more common return-by-reference, then the two are equivalent for all intents and purposes, though you might think that the renaming approach could result in fewer copies in some (not-too-smart ;-) compilers. By the way, the original point that a "smart" compiler can parallelize: Op(Get_A(..), Get_B(..), Get_C(..)) more easily than the "sequential" form involving named constants is a bit bogus. To parallelize, the compiler needs to prove that Get_A, Get_B, and Get_C don't interfere with one another. Given that, there is no reason that the "sequential" form couldn't be parallelized as well. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 74+ messages in thread
* Precalculation of parameters (was: Software landmines) 1998-09-08 0:00 ` Tucker Taft @ 1998-09-08 0:00 ` dennison 1998-09-09 0:00 ` Tucker Taft 0 siblings, 1 reply; 74+ messages in thread From: dennison @ 1998-09-08 0:00 UTC (permalink / raw) In article <Eyz7Co.J4t.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > By the way, the original point that a "smart" compiler can parallelize: > > Op(Get_A(..), Get_B(..), Get_C(..)) > > more easily than the "sequential" form involving named constants is a > bit bogus. To parallelize, the compiler needs to prove that Get_A, > Get_B, and Get_C don't interfere with one another. Given that, there > is no reason that the "sequential" form couldn't be parallelized as well. But if the language specifically states that the order of evaluation of parameters is undefined, then it doesn't have to prove they don't interfere. It can just assume they shouldn't. I don't know if that's the way Ada is defined, but I believe that was the claim that was being made. Is that actually the rule? -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-08 0:00 ` Precalculation of parameters (was: Software landmines) dennison @ 1998-09-09 0:00 ` Tucker Taft 1998-09-09 0:00 ` dennison 0 siblings, 1 reply; 74+ messages in thread From: Tucker Taft @ 1998-09-09 0:00 UTC (permalink / raw) dennison@telepath.com wrote: : In article <Eyz7Co.J4t.0.-s@inmet.camb.inmet.com>, : stt@houdini.camb.inmet.com (Tucker Taft) wrote: : > By the way, the original point that a "smart" compiler can parallelize: : > : > Op(Get_A(..), Get_B(..), Get_C(..)) : > : > more easily than the "sequential" form involving named constants is a : > bit bogus. To parallelize, the compiler needs to prove that Get_A, : > Get_B, and Get_C don't interfere with one another. Given that, there : > is no reason that the "sequential" form couldn't be parallelized as well. : But if the language specifically states that the order of evaluation of : parameters is undefined, then it doesn't have to prove they don't interfere. : It can just assume they shouldn't. Running two computations in parallel is very different from running them in an "arbitrary" (but still sequential) order. Suppose each function adds one to the global variable "Count". You get the same result independent of which order the functions are evaluated, but you don't get the same result if you run them in parallel, and the machine instructions involved in adding one to the global are interleaved arbitrarily. : ... I don't know if that's the way Ada is : defined, but I believe that was the claim that was being made. : Is that actually the rule? RM95 6.4(10) permits evaluation of parameters in an "arbitrary" order. RM95 1.1.4(18) defines "arbitrary" order, indicating that it must be an order that is equivalent to some sequential ordering. If you have the annotated RM, it explicitly mentions the example given above in AARM 1.1.4(18.d). : -- : T.E.D. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-09 0:00 ` Tucker Taft @ 1998-09-09 0:00 ` dennison 1998-09-10 0:00 ` Tucker Taft 0 siblings, 1 reply; 74+ messages in thread From: dennison @ 1998-09-09 0:00 UTC (permalink / raw) In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > dennison@telepath.com wrote: > > : Is that actually the rule? > > RM95 6.4(10) permits evaluation of parameters in an "arbitrary" > order. RM95 1.1.4(18) defines "arbitrary" order, indicating > that it must be an order that is equivalent to some sequential > ordering. ^^^^^^^^^^^^^^^ ^^^^^^^^ Ahhh. That was the part I was missing. So language was specifically added to the RM to prevent compilers from blindly parallelizing this. Out of curiosity, what was the reason this was done? I can't find anything about it in the Rationale. -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-09 0:00 ` dennison @ 1998-09-10 0:00 ` Tucker Taft 1998-09-10 0:00 ` dewarr 0 siblings, 1 reply; 74+ messages in thread From: Tucker Taft @ 1998-09-10 0:00 UTC (permalink / raw) dennison@telepath.com wrote: : In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>, : stt@houdini.camb.inmet.com (Tucker Taft) wrote: : > dennison@telepath.com wrote: : > : > : Is that actually the rule? : > : > RM95 6.4(10) permits evaluation of parameters in an "arbitrary" : > order. RM95 1.1.4(18) defines "arbitrary" order, indicating : > that it must be an order that is equivalent to some sequential : > ordering. ^^^^^^^^^^^^^^^ : ^^^^^^^^ : Ahhh. That was the part I was missing. So language was specifically added to : the RM to prevent compilers from blindly parallelizing this. Out of : curiosity, what was the reason this was done? I can't find anything about it : in the Rationale. All code within a single task is defined to be "sequential." This is critical to being able to prove things about safe access to global variables. If the RM allowed parallel evaluation of parameter expressions, all of the discussion in RM95 9.10 about sharing variables between tasks and about "independent addressability" would have to apply to sharing variables and manipulating neighboring packed-array components between different parameter evaluations, which would dramatically increase the likelihood of erroneous execution per 9.10(11). See RM95 9.10 for a discussion of these issues. The critical paragraph is 9.10(13), where any two actions that occur as part of the execution of a single task are defined to be "sequential." In some ways, that *is* the definition of a "task." : -- : T.E.D. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Precalculation of parameters (was: Software landmines) 1998-09-10 0:00 ` Tucker Taft @ 1998-09-10 0:00 ` dewarr 0 siblings, 0 replies; 74+ messages in thread From: dewarr @ 1998-09-10 0:00 UTC (permalink / raw) In article <Ez28B6.DMI.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > dennison@telepath.com wrote: > > : In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>, > : stt@houdini.camb.inmet.com (Tucker Taft) wrote: > : > dennison@telepath.com wrote: > : > > : > : Is that actually the rule? > : > > : > RM95 6.4(10) permits evaluation of parameters in an "arbitrary" > : > order. RM95 1.1.4(18) defines "arbitrary" order, indicating > : > that it must be an order that is equivalent to some sequential > : > ordering. ^^^^^^^^^^^^^^^ > : ^^^^^^^^ > > : Ahhh. That was the part I was missing. So language was specifically added to > : the RM to prevent compilers from blindly parallelizing this. Out of > : curiosity, what was the reason this was done? I can't find anything about it > : in the Rationale. > > All code within a single task is defined to be "sequential." This > is critical to being able to prove things about safe access to global > variables. If the RM allowed parallel evaluation of parameter expressions, > all of the discussion in RM95 9.10 about sharing variables between tasks and > about "independent addressability" would have to apply to sharing variables > and manipulating neighboring packed-array components between different > parameter evaluations, which would dramatically increase the likelihood > of erroneous execution per 9.10(11). > > See RM95 9.10 for a discussion of these issues. The critical paragraph > is 9.10(13), where any two actions that occur as part of the execution > of a single task are defined to be "sequential." In some ways, that > *is* the definition of a "task." > > : -- > : T.E.D. > > -- > -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ > Intermetrics, Inc. Burlington, MA USA > Note that in one respect Ada went MUCH too far, and that is the decision that for a binary operator you must evaluate either left-then-right, or right-then-left. While I don't think anyone would argue for the collateral (parallel) evaluation semantics of Algol-68 in a language with side effects, it is still annoying that in (f + g) + (h + i) where f,g,h,i are function calls, that f/g/h/i g/f/h/i f/g/i/h g/f/i/h h/i/f/g h/i/g/f i/h/f/g i/h/g/f are all permitted orders, but no other orders (e.g. f/h/g/i are permissible. This seems to me to be silly over specification. Note that it is very hard to construct an example where this matters (and even the ACVC tests do not test for this). -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-07 0:00 ` dewarr 1998-09-08 0:00 ` Tucker Taft @ 1998-09-16 0:00 ` Matthew Heaney 1 sibling, 0 replies; 74+ messages in thread From: Matthew Heaney @ 1998-09-16 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: > > > > declare > > > > A : Integer renames Get_A (10); > > > > B : Float renames Get_B (X); > > > > C : Boolean renames Get_C (Y); > > > > begin > > > > Op (A, B, C); > > > > end; > I must say that I find the renaming of function calls > like this to be a confusing oddity. It seems much clearer > to me to use ordinary constant declarations. The two > seem completely equivalent! Funny, since using Ada95, I always use "renames" in preference to "constant T :=". One difference is that renames is available for limited types: declare File : File_Type renames Standard_Output; begin This nicely emphasizes that this isn't assignment: it's a binding of a name to an object, which is completely different, and justifies the different syntax. For a while now I've felt that Ada really got the concept of initialization all wrong. Dijkstra speaks to the issue in Chap 10, An Essay on the Notion: "The Scope of Variables" in his book A Displine of Programming: (start of quote) Upon second thought it seems only honest to use different notations [for initialization and assignment], for they are very different operations: while the initializing statement is in a sense a creative one (it creates a variable with an initial value), the true assignment statement is a destructive one in the sense that it destroys information, viz. the variable's former value. (end of quote) He hit the nail right on the head. The problem with Ada is that it blurs the distinction between initialization and assignment, especially since it uses the assignment operator in a constant declaration. (Although even Dijkstra used the assignment operator in his declarations. The only difference is that he marks initialization with the keyword "vir" (for "virgin"), and Ada marks it using "constant".) Robert, you pointed out in an earlier post how many programmers "misuse assignment." This is confirmed by my own experience. However, if many programmers do the wrong thing wrt a specific language construct, then that may indicate something is wrong with the language itself, and not with the programmers. The use of the assignment operator where initialization is intended tends to inculcate the idea that there really isn't any difference. This is unfortunate. One obvious problem with the Ada approach is that limited objects can't be initialized during their declaration (except for default initialization, of course). Better would have been true constructor operations, with a different syntax. In the past I've suggested something like: declare File : File_Type'Open ("matt.dat", In_File); begin so that no assignment operator is required in order to do initialization. Unfortunately, not being able to initialize a limited object during its elaboration means that there's a zone between the object declaration and object initialization, in which the state of the object may be undefined. (Or only defined via what's possible using default initialization - but that kind of initialization isn't very interesting or useful.) It also means if I build up a value in a declarative region, via a series of constant declarations, then when I reach the declaration of a limited object, I have to stop the declarative region, since I can't use the limited object until I've initialized it, which doesn't occur until the start of the exectuble region. This is a real bummer, since I have to create variables when constants would do. The assignment operator in Ada is very confusing still, because I can use it as a renames operator for a limited object that's a default parameter: procedure Op (File : File_Type := Standard_Output); Very confusing indeed, since the assignment operator is clearly not being used for assignment! I'm all for language parsimony, but this overloading of the assignment operator is only going to confuse neophytes. So if I seem inclined to use a renames clause when the language allows me to use assignment operator, it's because I'm trying to emphasize that the declaration has the sense of a binding operation, and to de-emphasize any notion of assignment. When I look at the constant declaration declare A : constant Integer := Get_A (...); begin I really have to cringe, since it looks so much like an assignment. Thinking about it more, I think that Ada unnecessarily exposed the fact that an entity is a constant object, when all a client really cares about is that it's a name bound to a value. It would have been hipper if the language allowed this to be hidden somehow, so that only the implementator of an abstraction has to know that the return value is really a constant object. It would also be more consistent with other syntactic constructs that bind a name to a value: package P is ... binds the name P to a package. procedure Op (...) is ... binds the name Op to a procedure. type T is ... bind the name T to a type. -but- declare A : constant Integer := ...; begin binds the name A to a value??? Why not a uniform syntax: declare A : Integer is ...; begin or maybe declare value A : Integer is ...; Using renames comes close to being able to do that: declare A : Integer renames ...; begin It's sort of a bummer that we have two different keywords (renames vs is) to do binding. But the language problem we really need to solve is array initialization. For example, it's sometimes required to have array components whose state is a function of their index value. If the array components are limited, then there's no simple way to do that (say, to pass in the index value as the discriminant of a task object, to serve as its Id), except by using two array declarations and indirection. One idea I had is something like: task type Task_Type (Id : Positive) is ...; type Array_Type is array (Positive range <>) of Task_Type; declare O : Array_Type (1 .. N)'(for I in O'Range O(I)); begin You could even invoke a constructor using this syntax: type CT is ...; constructor CT'Initialize (Index : Positive); type T is array (Positive range <>) of CT; declare O : T (1 .. N)'(for I in O'Range O(I)'Initialize (I)); begin ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <35eca5d9.4354839@news.geccs.gecm.com>]
* Re: Software landmines (was: Why C++ is successful) [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> @ 1998-09-01 0:00 ` Richard D Riehle 0 siblings, 0 replies; 74+ messages in thread From: Richard D Riehle @ 1998-09-01 0:00 UTC (permalink / raw) Brian, Silly indeed! I do not appreciate your use of the pejorative "silly" in response to my postingsince it seems to be a deliberate insult. I do admit that my hastily composed example could have been coded with more clarity. It did not occur to me that I would need to submit a perfect code example to make such a simple point but, since martinets abound, I submit a new, probably unnecessary, example. In case you have missed my original point in your zeal to criticize the code fragment, it is as follows: Ada is designed to encourage use of the assignment statement if we also want our code to be clear and readable. This was in response to Robert's (correct) assertion that programmers use assignment statements too liberally. I am appending your code example and mine in case some masochist wants to read it. I hope you understand that my example was not intended to represent real code. Perhaps the way I wrote the assignment statement confused you regarding my intentions. I concur that, if there is a simple algorithm, it can be stated as part of the declaration. In the kind of function I had in mind, there could be multiple possible values for the Result. In this case, the choice is between, Example (1) function F1 (paramter-list) return Result-type is Result : Result-type := initial-value; begin if condition-1 then Result := result-1; elsif condition-2 then Result := result-2; else Result := result-3; end if; return Result; end F1; versus Example(2) function F2 (paramter-list) return Result-type is begin if condition-1 then return result-1; elsif condition-2 then return result-2; else return result-3; end if; return Result; end F2; The two (simplified) functions epitomize the debate about a particular coding style. Example(2) illustrates how functions avoid using an extraneous assignment statement. Some practitioners prefer Example(1). I use both in my coding. It depends on the complexity of the function, my audience (everyone on the project is an ex-Fortranner), along with several helpings of intuition. Over the years I have found that Example(1) has been less error-prone and easier for the average programmer to maintain. Your mileage may vary according your experience. -- ==================== Original Postings ==================== -- What follows is my original message along with Mr. Orpin's -- rather impolite reply. -- =========================================================== In article <35eca5d9.4354839@news.geccs.gecm.com>, abuse@borpin.demon.co.uk (Brian Orpin) wrote: in response to the following code fragment submitted by me, >On Mon, 24 Aug 1998 19:47:31 GMT, Richard D Riehle ><laoXhai@ix.netcom.com> wrote: > >> Don't take away my assignment statements, Robert. The help me write >> crisp, short code sentences that ordinary mortals can understand. In >> fact, as an old time Fortranner, I sometimes write a function that >> looks like, > >> function F ( ... ) return some-data-type is >> Result : some-data-type := initial-value; >> begin >> Result := algorithmic-part; >> return Result; >> end F; > >Which of course is pretty silly <g>. Result has a default value that is >never used. Could easily be written.. > >function F ( ... ) return some-data-type is > Result : some-data-type := algorithmic-part; >begin > return Result; >end F; > >or even > >function F ( ... ) return some-data-type is >begin > return algorithmic-part; >end F; > >YMMV ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful
@ 1998-08-06 0:00 Robert Dewar
1998-08-07 0:00 ` harald.mueller
0 siblings, 1 reply; 74+ messages in thread
From: Robert Dewar @ 1998-08-06 0:00 UTC (permalink / raw)
Lars says
<<Are you saying tht GC would introduce a larger risk for incorrect
programs than exceptions? If so, why?
>>
Most certainly! GC introduces a huge risk for incorrect programs. Garbage
collectors assume that the pointer structure of a program is correct. If
it is corruptede, garbage collectors can cause horrible havoc. Indeed this
havoc often only shows up after several mark-and-sweep type cycles of the
GC, and it can be almost impossible to track them down
(said from horrible experiences in implementing general GC!)
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-06 0:00 Why C++ is successful Robert Dewar @ 1998-08-07 0:00 ` harald.mueller 1998-08-07 0:00 ` Brian Rogoff 0 siblings, 1 reply; 74+ messages in thread From: harald.mueller @ 1998-08-07 0:00 UTC (permalink / raw) In article <dewar.902415458@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > Lars says > > <<Are you saying tht GC would introduce a larger risk for incorrect > programs than exceptions? If so, why? > >> > > Most certainly! GC introduces a huge risk for incorrect programs. Garbage > collectors assume that the pointer structure of a program is correct. If > it is corruptede, garbage collectors can cause horrible havoc. Indeed this > havoc often only shows up after several mark-and-sweep type cycles of the > GC, and it can be almost impossible to track them down > > (said from horrible experiences in implementing general GC!) > Now that's interesting. I did never write a GC, but I wrote a heap management system, which had bugs in it for the first few weeks, and you wouldn't believe it: A correct GC would have been MUCH BETTER than my wrong heap management. So? Actually, the problem with new/delete schemes is that the *user*(!!) can corrupt the heap, e.g. by deleting stack variables: f(C* p) { C defaultC; C* c; if (p == null) c = &defaultC; else c = p; ... ... ... delete c; } Similar with static class variables etc. You wouldn't believe how many heaps silently and very late crash after such errors (which are mostly introduced innocently during maintenance - "we dont have to create a new C all the time - just let's have a single static one"). HMMueller -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-07 0:00 ` harald.mueller @ 1998-08-07 0:00 ` Brian Rogoff 1998-08-07 0:00 ` Timothy Welch 0 siblings, 1 reply; 74+ messages in thread From: Brian Rogoff @ 1998-08-07 0:00 UTC (permalink / raw) On Fri, 7 Aug 1998 harald.mueller@siemenscom.com wrote: > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > Most certainly! GC introduces a huge risk for incorrect programs. Garbage > > collectors assume that the pointer structure of a program is correct. If > > it is corruptede, garbage collectors can cause horrible havoc. Indeed this > > havoc often only shows up after several mark-and-sweep type cycles of the > > GC, and it can be almost impossible to track them down > > > > (said from horrible experiences in implementing general GC!) > > Now that's interesting. I did never write a GC, but I wrote a heap management > system, which had bugs in it for the first few weeks, and you wouldn't > believe it: A correct GC would have been MUCH BETTER than my wrong heap > management. So? I have nothing against GC, in fact I like it in general and wish its use was more widespread, but a very large part of your problem is that the language you are working in (1) Doesn't distinguish between pointers to local variables and pointers to heap allocated memory. (2) Allows you to get a pointer to any local variable, rather than forcing you to be explicit about which local variables can be pointed to, or "aliased". (3) Makes it easy to do all kinds of other arbitrary weird things with pointers. In an otherwise very similar language, Ada, none of these are a problem. Sure, the user could always declare every local variable as aliased, and make every pointer "access all" to point to heap and local variables, and insist on using Unchecked_Access ("&" in C/C++) and Unchecked_Conversion (casting) to turn off all the checks, but the presence of "Unchecked_" anything tells you where the problem might be. Modula-3 has the requirement that any module which uses unsafe features of the language be labelled as UNSAFE, which is an idea I like too, though it also has GC so you proabbly wouldn't write allocators in M3. I tend to think of Ada as being semantically similar to C++ (especially wrt to the fact that Ada allows low level programming), except that while C++ allows you to be safe, the defaults are unsafe, and while Ada allows you to be unsafe, the defaults are safe. Since I'm sort of a slapdash programmer, I prefer help from the compiler to avoid the sort of mishaps Harald describes. Doubtless the C++ experts out there who are writing reliable code are a lot smarter than me and don't need this kind of help, or they get it by using tools like Lint and Purify; probably both. I don't have the same problems in Ada that I do in C or C++, even though I'm *far* more familiar with C than Ada (I use C every day). -- Brian ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-07 0:00 ` Brian Rogoff @ 1998-08-07 0:00 ` Timothy Welch 1998-08-08 0:00 ` Robert Dewar 0 siblings, 1 reply; 74+ messages in thread From: Timothy Welch @ 1998-08-07 0:00 UTC (permalink / raw) On Fri, 7 Aug 1998 13:21:17 -0700, Brian Rogoff <bpr@shell5.ba.best.com> wrote: >I have nothing against GC, in fact I like it in general and wish its use >was more widespread, but a very large part of your problem is that the >language you are working in > >(1) Doesn't distinguish between pointers to local variables and pointers > to heap allocated memory. > >(2) Allows you to get a pointer to any local variable, rather than forcing > you to be explicit about which local variables can be pointed to, or > "aliased". > >(3) Makes it easy to do all kinds of other arbitrary weird things with > pointers. > Out of curiousity why are (1) and (2) problems? Can't the GC just check to see if the pointer is pointing to memory on the stack? Tim ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-07 0:00 ` Timothy Welch @ 1998-08-08 0:00 ` Robert Dewar 1998-08-08 0:00 ` Jeffrey C. Dege 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1998-08-08 0:00 UTC (permalink / raw) Timothy Welch says <<>(1) Doesn't distinguish between pointers to local variables and pointers > to heap allocated memory. > >(2) Allows you to get a pointer to any local variable, rather than forcing > you to be explicit about which local variables can be pointed to, or > "aliased". > >(3) Makes it easy to do all kinds of other arbitrary weird things with > pointers. > Out of curiousity why are (1) and (2) problems? Can't the GC just check to see if the pointer is pointing to memory on the stack? >> Undoubtedly at least *part* of the problem in using C is that people are not sufficiently aware of what can go wrong. Microsoft has a rather amazing book that pretends to be a book about software techniques, but in fact is little more than a set of perfectly standard coding procedures to avoid pitfalls in C. When I read it, I was surprised that professional C programmers would find such a book useful, but the questions above are a reminder that you often people are not aware of the dangers. I must say I worry about CS curriculums in which people are only getting exposed to C and C++ and hence simply don't register important language design principles (after all the idea that it is obviously a bad idea to allow pointers to local variables is a very old one, dating back at least to Pascal, which means coming up to 30 years. Timothy, to answer your questions. (1) is a serious problem, since it can allow dangling pointers. That is, when you leave a scope with such a pointer, then you have a pointer to inactive stack. Using this pointer later on can cause serious damage, e.g. clobbering a return point stored on the stack. These dangling pointers are created even though you never use free. There is no practical implementation mechanism for efficiently detecting such a dangling pointer. (2) is of course related, but is at a more conceptual level. Aliasing is always dangerous because it can cause code to be very difficult to read, understand, and maintain (as well as leading to accidental bugs in the first place). Consider in C: (everything is an int or a *int) a = b; c = 3 + q; *d = 4; That assignment to *d *may* modify the values of a and c. This means you cannot just read ahead in the code at this stage, you have to ensure that it is not possible for d to be pointing to a or c, or worse discover that it is possible, and that one of the first two assignments is dead. A (good) compiler will make an attempt to determine the answer (it is not always possible to do this reliably). A compiler that does not make this effort risks generating horrible code for the above, since it has to forget the values of a and c in registers. A compiler that tries hard still often finds that it has to be conservative and assume the worst. A (good) programmer will make an attempt to determine the answer (it is not always possible to do this reliably). A programmer that does not make this effort risks seriously misunderstanding the above, since they will have to forget the assigned values of a and c. A programmer that tries hard still often finds that they have to be conservative and assume the worst. Note the parallel language here is quite deliberate. Whey you set obstacles for a compiler, you set them for a programmer as well. A clever compiler can compensate, and that's OK, since machine time is cheap, so what if the compilation takes longer (but as noted, even a clever compiler can be fooled). A clever programmer can compensate, and that is NOT OK, since programmer time is not cheap, and maintenance mistakes are very costly. In Pascal and Ada 83, a decision was made to completely disallow pointers to local variables, and this is undoubtedly the best decision from a language point of view. However, especially when interfacing to other languages, this proves an annoying restriction. For example, if you are interfacing to a language like C that typically requires pointers to parameters to be passed, then it is annoying not to be able to pass pointers to local variables. Ada 83 programmers would often resort to nasty low level junk (i.e. use of the 'Address attribute) for this purpose, leading to code that has all the disadvantages discussed above, and more. Why more? Becuase (a) address gives untyped pointers, like void*, and (b) the semantics of whether the aliasing attempt "works" correctly is not clear from the standard. Ada 95 compromises by allowing you to declare a variable as aliased, which means that it is allowable to take its "address", using the strongly typed 'Access attribute. An Ada 95 program that declared every local variable to be aliased would be equivalent to the C semantics (it would also be a travesty!) Generally you should alias local variables ONLY in connection with interfacing to foreign code. Yes, as with all rules, including this one, there are exceptions to this rule that are legitimate, but if you find you are using aliased extensively, something may be wrong with your approach. Robert Dewar P.S. with respect to the GC part of your question, sure, you can determine that a pointer points to the stack, but the dangling pointer case can cause unimaginable chaos in a garbage collector. Indeed the combination of garbage collection with semantics that allow dangling pointers is a dangerous one, dangerous enough to make a language design quite dubious from a practical point of view. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-08 0:00 ` Robert Dewar @ 1998-08-08 0:00 ` Jeffrey C. Dege 1998-08-10 0:00 ` Laurent GUERBY 0 siblings, 1 reply; 74+ messages in thread From: Jeffrey C. Dege @ 1998-08-08 0:00 UTC (permalink / raw) On 8 Aug 1998 08:27:02 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: > >Undoubtedly at least *part* of the problem in using C is that people are not >sufficiently aware of what can go wrong. Microsoft has a rather amazing >book that pretends to be a book about software techniques, but in fact is >little more than a set of perfectly standard coding procedures to avoid >pitfalls in C. When I read it, I was surprised that professional C >programmers would find such a book useful, but the questions above are >a reminder that you often people are not aware of the dangers. If you're talking about Steve McGuire's books, (Code Complete, Writing Solid Code), I'm a professional C programmer, and I didn't find anything in them that I hadn't been aware of for many years. >I must >say I worry about CS curriculums in which people are only getting exposed >to C and C++ and hence simply don't register important language design >principles (after all the idea that it is obviously a bad idea to allow >pointers to local variables is a very old one, dating back at least to >Pascal, which means coming up to 30 years. I have to agree with the above. A CS curriculumn should have some breadth to it. Exposure to a variety of languages is a part of this, as is instruction in the theory underlying compilers. -- The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" ("I found it!") but rather "hmm....that's funny..." -- Isaac Asimov ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-08 0:00 ` Jeffrey C. Dege @ 1998-08-10 0:00 ` Laurent GUERBY 1998-08-12 0:00 ` Andy Ward 0 siblings, 1 reply; 74+ messages in thread From: Laurent GUERBY @ 1998-08-10 0:00 UTC (permalink / raw) jdege@jdege.visi.com (Jeffrey C. Dege) writes: > On 8 Aug 1998 08:27:02 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: > > > >Undoubtedly at least *part* of the problem in using C is that people are not > >sufficiently aware of what can go wrong. Microsoft has a rather amazing > >book that pretends to be a book about software techniques, but in fact is > >little more than a set of perfectly standard coding procedures to avoid > >pitfalls in C. When I read it, I was surprised that professional C > >programmers would find such a book useful, but the questions above are > >a reminder that you often people are not aware of the dangers. > > If you're talking about Steve McGuire's books, (Code Complete, Writing > Solid Code), I'm a professional C programmer, and I didn't find anything > in them that I hadn't been aware of for many years. > [...] "Code Complete" author is Steve McConnell, not Steve McGuire. I think Robert talks about the latter. The former, "Code Complete", is a very nice book IMHO, and amongst the languages covered there is Ada (together with C/C++/Pascal/VB). It makes a nice advocacy package for strongly typed language BTW (you can shoot yourself into the foot easily with language X whereas you get an error message with language Y ;-). A little quote for c.l.a. readers, from the "goto" pro and cons section (reminds me of some threads ;-): "Finally, the goto was incorporated into the Ada language, the most carefully engineered programming language in history. Ada was developped long after the arguments on both sides of the goto debate had been fully developped, and after considering all sides of the issue, Ada engineers decided to include the goto" -- Laurent Guerby <guerby@bnp-eng.remcomp.com>, Team Ada, Linux/GNU addict "Use the Source, Luke. The Source will be with you, always (GPL)." ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-10 0:00 ` Laurent GUERBY @ 1998-08-12 0:00 ` Andy Ward 1998-08-14 0:00 ` Robert Dewar 0 siblings, 1 reply; 74+ messages in thread From: Andy Ward @ 1998-08-12 0:00 UTC (permalink / raw) > A little quote for c.l.a. readers, from the "goto" pro and cons >section (reminds me of some threads ;-): > >"Finally, the goto was incorporated into the Ada language, the most >carefully engineered programming language in history. Ada was >developped long after the arguments on both sides of the goto debate >had been fully developped, and after considering all sides of the >issue, Ada engineers decided to include the goto" > Ahh... but have you ever found a "good" reason for using it? I have used goto in C and Pascal in certain rare cases, but I have always found clearer ways to code these cases in Ada. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Why C++ is successful 1998-08-12 0:00 ` Andy Ward @ 1998-08-14 0:00 ` Robert Dewar 1998-08-14 0:00 ` Software landmines (was: Why C++ is successful) dennison 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1998-08-14 0:00 UTC (permalink / raw) Andy said <<Ahh... but have you ever found a "good" reason for using it? I have used goto in C and Pascal in certain rare cases, but I have always found clearer ways to code these cases in Ada. >> The two obvious uses vfor gotos in Ada are 1) to get a loop "continue" mechanism 2) to write finite state machines encoding the state into the PC. Yes, some people prefer case statements for this purpose, but many people prefer the use of labels and gotos as the most obvious translation of labeled states with arrows between them. In general, the use of gotos makes sense if the resulting code is clearer and easier to maintain. THat's relatively rare, but not non-existnent, and it is quite common to run across tortured code with multiple boolean flags which can be easily simplified using a goto. For example, I find the following perfectly clear: <<sort>> for J in 1 .. N - 1 loop if D (J) > D (J + 1) then Swap (D(J), D(J + 1)); goto Sort; end if; It is a little tricky to program this without the goto and not make it less clear. Actuallky many people who try this end up with a different algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort :-) \x1adp ^ permalink raw reply [flat|nested] 74+ messages in thread
* Software landmines (was: Why C++ is successful) 1998-08-14 0:00 ` Robert Dewar @ 1998-08-14 0:00 ` dennison 1998-08-15 0:00 ` Thaddeus L. Olczyk ` (2 more replies) 0 siblings, 3 replies; 74+ messages in thread From: dennison @ 1998-08-14 0:00 UTC (permalink / raw) In article <dewar.903074236@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Andy said > > <<Ahh... but have you ever found a "good" reason for using it? I have used > goto in C and Pascal in certain rare cases, but I have always found clearer > ways to code these cases in Ada. > >> > > The two obvious uses vfor gotos in Ada are > > 1) to get a loop "continue" mechanism for a simple loop, embedding the rest of the loop code in the body of the if statement is clearer. For nested loops where you want to "continue" an outer loop, I can see it. Not that I'd do such a thing. As a "goto-holic" who has been straight for 10 years, the best bet is abstinence. One day at a time. :-) > For example, I find the following perfectly clear: > > <<sort>> for J in 1 .. N - 1 loop > if D (J) > D (J + 1) then > Swap (D(J), D(J + 1)); > goto Sort; > end if; > > It is a little tricky to program this without the goto and not make it > less clear. Actuallky many people who try this end up with a different > algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort :-) So the "average" poor maintainer schlep looks at this and thinks "is this just a continue, or a complete restarting of the loop?" Oh yeah, that's clear. %-( If anyone does something this bizzare, they'd better put copious comments around it explaining its semantics. Otherwise, its the software equivalent of a land mine. Its just sitting there waiting for someone to touch it, then ...BOOM! Very good counterexample to your own point. T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-14 0:00 ` Software landmines (was: Why C++ is successful) dennison @ 1998-08-15 0:00 ` Thaddeus L. Olczyk 1998-08-16 0:00 ` Robert Dewar 1998-08-16 0:00 ` Jay Martin 2 siblings, 0 replies; 74+ messages in thread From: Thaddeus L. Olczyk @ 1998-08-15 0:00 UTC (permalink / raw) On Fri, 14 Aug 1998 14:13:10 GMT, dennison@telepath.com wrote: >In article <dewar.903074236@merv>, > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >> Andy said >> >> <<Ahh... but have you ever found a "good" reason for using it? I have used >> goto in C and Pascal in certain rare cases, but I have always found clearer >> ways to code these cases in Ada. >> >> >> >> The two obvious uses vfor gotos in Ada are >> >> 1) to get a loop "continue" mechanism > >for a simple loop, embedding the rest of the loop code in the body of the if >statement is clearer. For nested loops where you want to "continue" an outer >loop, I can see it. Not that I'd do such a thing. As a "goto-holic" who has >been straight for 10 years, the best bet is abstinence. One day at a time. :-) > Most experienced C programmers will tell you that continue is just a glorified goto. >> For example, I find the following perfectly clear: >> >> <<sort>> for J in 1 .. N - 1 loop >> if D (J) > D (J + 1) then >> Swap (D(J), D(J + 1)); >> goto Sort; >> end if; >> >> It is a little tricky to program this without the goto and not make it >> less clear. Actuallky many people who try this end up with a different >> algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort >:-) Assuming I've read your code correctly, a better way would be for J in 1 .. N - 1 loop continue=true; if D (J) > D (J + 1) then Swap (D(J), D(J + 1)); continue=false; end if; if continue then ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-14 0:00 ` Software landmines (was: Why C++ is successful) dennison 1998-08-15 0:00 ` Thaddeus L. Olczyk @ 1998-08-16 0:00 ` Robert Dewar 1998-08-17 0:00 ` dennison 1998-08-16 0:00 ` Jay Martin 2 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1998-08-16 0:00 UTC (permalink / raw) T.E.D says For a simple loop, embedding the rest of the loop code in the body of the if statement is clearer. For nested loops where you want to "continue" an outer loop, I can see it. Not that I'd do such a thing. Even in the simple case: for J in 1 .. N loop if D (J) = NaN then goto Continue; end if; giant section of code <<Continue>> null; end loop; as opposed to for J in 1 .. N loop if D (J) /= NaN then giant section of code end if; end loop; there may be a preference for the goto. It shows the reader right up front that the loop does nothing at all to NaN's, without having to match up the if with the end if at the end of the giant section of code to know this. Also, it means that the giant section of code has one less level of indentation. But it's a toss up in this case, and for most purposes we would prefer the second case. Where it gets tricky is for J in 1 .. N loop if condition 1 then ... if condition 2 then ... if conditoin 3 then goto Continue; Now T.E.D's prescription is not so clear, and we end up having to severely contort things, or introduce a boolean flag which we keep testing as we unwind to the end. Remember that the continue here is just like a return. If you are allergic to using a loop continue or exit, you should be allergic to using a return (other than at the end of a function). Some people are, and that is at least consistent. But I see a lot of Ada programmers who will use a return without hesitation from a nested loop, but still turn green at the sight of a goto. That makes no sense to me. As a "goto-holic" who has been straight for 10 years, the best bet is abstinence. One day at a time. :-) Maybe the comparison is apt. If you really are unable to figure out how to use gotos properly, then perhaps abstinence is the "best bet", but just as we know that wine drunk in moderation can actually be a health benefit, and is most certainly not a health danger, the occasional use of a goto can be beneficial for the clarity and efficiency of your code. We can appreciate and sympathize with the poor goto-holic's who may not risk this, but it does not mean the rest of us have to abstain :-) So the "average" poor maintainer schlep looks at this and thinks "is this just a continue, or a complete restarting of the loop?" Oh yeah, that's clear. %-( The idea that code can ever be maintained by incompetent shlep's who do not understand the language they are writing in is of course a serious error. Yes, I know it happens, look at the results, need I say more? On the other hand, I see no reason to accept this rhetoric, if indeed you do have these poor maintainer shleps looking at the code, we have only T.E.D.'s unsupported allegation that they will have more trouble with my form than some other form (note that, perhaps wisely, T.E.D does not attempt to demonstrate the beautifully clear, alternative, goto-free form -- enough other competent people have tripped on that already :-) If anyone does something this bizzare, they'd better put copious comments around it explaining its semantics. Otherwise, its the software equivalent of a land mine. Its just sitting there waiting for someone to touch it, then ...BOOM! Well of course any code needs commenting, and pointing out the critical details of the algorithm in use, especially if, as in this case, it is likely to be an unfamiliar algorithm, is definitely a good idea. Very good counterexample to your own point. I don't think so! ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-16 0:00 ` Robert Dewar @ 1998-08-17 0:00 ` dennison 1998-08-18 0:00 ` adam 1998-08-19 0:00 ` ell 0 siblings, 2 replies; 74+ messages in thread From: dennison @ 1998-08-17 0:00 UTC (permalink / raw) In article <dewar.903281994@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > T.E.D says > > But it's a toss up in this case, and for most purposes we would prefer > the second case. Where it gets tricky is > > for J in 1 .. N loop > if condition 1 then > ... > if condition 2 then > ... > if conditoin 3 then > goto Continue; > > Now T.E.D's prescription is not so clear, and we end up having to > severely contort things, or introduce a boolean flag which we keep > testing as we unwind to the end. > > Remember that the continue here is just like a return. If you are allergic > to using a loop continue or exit, you should be allergic to using a return > (other than at the end of a function). Some people are, and that is at > least consistent. But I see a lot of Ada programmers who will use a return > without hesitation from a nested loop, but still turn green at the sight > of a goto. That makes no sense to me. > Good point. Typically in this case I would "cheat" it and embed the inside of the loop in a subprogram, with a return statement. You think that's no better than using a "goto". I think it IS better, because the rule for where control goes to after a return statement is much clearer than for goto. For the return, I just start reading code after the subprogram call. For goto, I have to search the entire source for the label that is being jumped to. Just as importantly, someone can completely change my structure just by moving that label. But yes, we are probably talking Bordeaux vs. Mad Dog 20-20. > So the "average" poor maintainer schlep looks at this and thinks > "is this just a continue, or a complete restarting of the loop?" > Oh yeah, that's clear. %-( > > On the other hand, I see no reason to accept this rhetoric, if indeed > you do have these poor maintainer shleps looking at the code, we have > only T.E.D.'s unsupported allegation that they will have more trouble > with my form than some other form (note that, perhaps wisely, T.E.D > does not attempt to demonstrate the beautifully clear, alternative, > goto-free form -- enough other competent people have tripped on that > already :-) Why take my word for it? The very fact that "other competent people have tripped on that" proves how obtuse it is. You'd be quite lucky to have a maintanence staff as good as the folks here on c.l.*, and *they* can't even make a simple change to your code without completely screwing it up. I couldn't hope to come up with a better example. T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-17 0:00 ` dennison @ 1998-08-18 0:00 ` adam 1998-08-19 0:00 ` Tucker Taft 1998-08-19 0:00 ` ell 1 sibling, 1 reply; 74+ messages in thread From: adam @ 1998-08-18 0:00 UTC (permalink / raw) In article <6r9f8h$jtm$1@nnrp1.dejanews.com>, dennison@telepath.com wrote: > In article <dewar.903281994@merv>, > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > T.E.D says > > > > But it's a toss up in this case, and for most purposes we would prefer > > the second case. Where it gets tricky is > > > > for J in 1 .. N loop > > if condition 1 then > > ... > > if condition 2 then > > ... > > if conditoin 3 then > > goto Continue; > > > > Now T.E.D's prescription is not so clear, and we end up having to > > severely contort things, or introduce a boolean flag which we keep > > testing as we unwind to the end. > > > > Remember that the continue here is just like a return. If you are allergic > > to using a loop continue or exit, you should be allergic to using a return > > (other than at the end of a function). Some people are, and that is at > > least consistent. But I see a lot of Ada programmers who will use a return > > without hesitation from a nested loop, but still turn green at the sight > > of a goto. That makes no sense to me. > > > > Good point. Typically in this case I would "cheat" it and embed the inside of > the loop in a subprogram, with a return statement. . . . I've been thinking about a similar problem that I keep running into, where you execute a sequence of statements, and after many of the statements, you have to make some test to ensure that the statement was successful or that your pointers aren't null or that you don't have garbage data or something like that. I don't like code like blah-blah-blah; if not error-condition-1 then keep-going; if not error-condition-2 then still-keep-going; if not error-condition-3 then everythings-still-fine-keep-going; etc. because it's hard to read unless you have a terminal that's shaped like a parallelogram. Also, if you keep this up, you end up being able to put only 30 characters on a line, and it takes 3 lines to code one Ada statement. Having a flag that you keep testing is one alternative. So is "goto". So is T.E.D's workaround of putting the code in a subprogram and using "return". So is defining a local exception: declare error : exception; begin blah-blah-blah; if error-condition-1 then raise error; end if; keep-going; if error-condition-2 then raise error; end if; still-keep-going; if error-condition-3 then raise error; end if; everythings-still-fine-keep-going; etc. exception when error => ... end; Question: Would you expect the compiler to optimize the "raise error" to a simple branch to the exception handler in this case, assuming the exception handler didn't contain any statements that depended on Ada's exception features? Note that I think using a local exception is an option *only* because the thing I'm testing for is an error condition; it wouldn't be appropriate for most other types of conditions. Anyway, here's my main question: Is it desirable to expand the syntax of "exit" to cover cases like this? I think it might be nice. I'm thinking that code like this could look something like: block_to_do_stuff: begin blah-blah-blah; exit block_to_do_stuff when error-condition-1; keep-going; exit block_to_do_stuff when error-condition-2; still-keep-going; exit block_to_do_stuff when error-condition-3; everythings-still-fine-keep-going; etc. end block_to_do_stuff; I think one of the Ada 9X proposals actually had a feature like this, but unfortunately it also changed the semantics of "exit" in a way that would change the meanings of a lot of Ada 83 code. Probably, that's why it was dropped from the final Ada 95 definition. But I think that the exit-block feature in my example would be a very useful addition to the next version of Ada. (I'd define it so that this use of "exit" requires a block name, so that the semantics of "unnamed" exit statements are unchanged; that way, there wouldn't be any upward compatibility problems.) So do the rest of you think it's a useful enough feature to consider adding to Ada? -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-18 0:00 ` adam @ 1998-08-19 0:00 ` Tucker Taft 1998-08-19 0:00 ` adam 0 siblings, 1 reply; 74+ messages in thread From: Tucker Taft @ 1998-08-19 0:00 UTC (permalink / raw) adam@irvine.com wrote: : ... : Anyway, here's my main question: Is it desirable to expand the syntax of : "exit" to cover cases like this? I think it might be nice. I'm thinking that : code like this could look something like: : block_to_do_stuff: : begin : blah-blah-blah; : exit block_to_do_stuff when error-condition-1; : keep-going; : exit block_to_do_stuff when error-condition-2; : still-keep-going; : exit block_to_do_stuff when error-condition-3; : everythings-still-fine-keep-going; : etc. : end block_to_do_stuff; : I think one of the Ada 9X proposals actually had a feature like this, but : unfortunately it also changed the semantics of "exit" in a way that would : change the meanings of a lot of Ada 83 code. Probably, that's why it was : dropped from the final Ada 95 definition. The Ada 9x proposal was "upward consistent" in that it didn't change the meaning of any existing programs to a new legal meaning, but it did make some of them illegal (those that involved exits from blocks nested in loops, I believe). : ... But I think that the exit-block : feature in my example would be a very useful addition to the next version : of Ada. (I'd define it so that this use of "exit" requires a block name, : so that the semantics of "unnamed" exit statements are unchanged; that way, : there wouldn't be any upward compatibility problems.) We also considered this proposal. Basically, we couldn't find a "clean" solution that looked like it wasn't just an add-on rather than something built in from the beginning. Also, the problem being solved is relatively minor, and we had bigger fish to fry (mix those metaphors liberally, please). : So do the rest of you think it's a useful enough feature to consider adding : to Ada? If there were a solution that treated loops and blocks symmetrically, that would be nice. But a proposal that only allows exiting from unnamed loops, while disallowing exiting from unnamed blocks, is a kludge. I would prefer something which allowed an unnamed "exit" to be legal only if there were exactly one block or loop enclosing the point. If there were more than one, then the exit would have to be named. This way, adding another level of block or loop to an existing program with an unnamed exit would never result in an exit going to the wrong place, but it might result in the program becoming illegal. This avoids a kind of "Beaujolais" effect for unnamed exit statements (the "Beaujolais" effect is a case where adding or removing a declaration from a "used" package would change the meaning of a program from one legal interpretation to another -- Ada 95 doesn't have them, Ada 83 had very few (all obscure), "used" C++ namespaces have them for sure). The general Ada principle is to require that the programmer write more if that will help to make the meaning clear to the reader. (Note that sometimes writing *less* makes things clearer to the reader. The key is to keep the signal to noise ratio high.) Unnamed exits should be limited to cases where there is no ambiguity, especially if they can exit multiple kinds of constructs. The C situation is bad news, where a "break" is used to exit both switch and loop, and there is no "named" version of it. I have seen plenty of bugs where a break was meant to exit a loop, but really only exited the nearest enclosing switch, or vice-versa. : -- Adam -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-19 0:00 ` Tucker Taft @ 1998-08-19 0:00 ` adam 0 siblings, 0 replies; 74+ messages in thread From: adam @ 1998-08-19 0:00 UTC (permalink / raw) In article <ExwxsA.EEL.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > adam@irvine.com wrote: > : ... > : Anyway, here's my main question: Is it desirable to expand the syntax of > : "exit" to cover cases like this? I think it might be nice. I'm thinking that > : code like this could look something like: > > : block_to_do_stuff: > : begin > : blah-blah-blah; > : exit block_to_do_stuff when error-condition-1; > : keep-going; > : exit block_to_do_stuff when error-condition-2; > : still-keep-going; > : exit block_to_do_stuff when error-condition-3; > : everythings-still-fine-keep-going; > : etc. > : end block_to_do_stuff; > > : I think one of the Ada 9X proposals actually had a feature like this, but > : unfortunately it also changed the semantics of "exit" in a way that would > : change the meanings of a lot of Ada 83 code. Probably, that's why it was > : dropped from the final Ada 95 definition. > > The Ada 9x proposal was "upward consistent" in that it didn't change the > meaning of any existing programs to a new legal meaning, but it did make > some of them illegal (those that involved exits from blocks nested in loops, > I believe). Not just blocks--I think compound statements were involved. If my recollection is correct, it would have made the following code illegal: for I in Arr'Range loop if Arr (I) = Search_Value then Found_Index := I; exit; <==== illegal according to 9X draft end if; end loop; But I do remember now that this would have been illegal and not legal with a different meaning. As I recall, I did a grep through the code of my main project for "exit;" (which would have always been illegal under this proposal---the proposed syntax did not allow for "exit" all by itself) and found it occurred about a hundred times. I thought this was pretty obnoxious. > If there were a solution that treated loops and blocks symmetrically, > that would be nice. But a proposal that only allows exiting from > unnamed loops, while disallowing exiting from unnamed blocks, is > a kludge. I would prefer something which allowed an unnamed "exit" to be > legal only if there were exactly one block or loop enclosing the point. Actually, this would make a lot of sense to me. I think I tend to do this anyway when two loops are nested, but I'd have to look through my code to make sure. I'd support a proposal like this; the amount of previously legal code that would be made illegal would be IMHO *much* less than the dropped 9X proposal did. I also agree that this is a minor problem. I'm willing to add this case to the short list of situations where "goto" is appropriate. Now all I have to do is go against all my training and allow that 4-letter word into my code. Easier said than done. :) -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-17 0:00 ` dennison 1998-08-18 0:00 ` adam @ 1998-08-19 0:00 ` ell 1998-08-19 0:00 ` Charles Hixson ` (2 more replies) 1 sibling, 3 replies; 74+ messages in thread From: ell @ 1998-08-19 0:00 UTC (permalink / raw) In article <6r9f8h$jtm$1@nnrp1.dejanews.com>, dennison@telepath.com wrote: > In article <dewar.903281994@merv>, > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > T.E.D says > > > > But it's a toss up in this case, and for most purposes we would prefer > > the second case. Where it gets tricky is > > > > for J in 1 .. N loop > > if condition 1 then > > ... > > if condition 2 then > > ... > > if conditoin 3 then > > goto Continue; > > > > Now T.E.D's prescription is not so clear, and we end up having to > > severely contort things, or introduce a boolean flag which we keep > > testing as we unwind to the end. > > > > Remember that the continue here is just like a return. If you are allergic > > to using a loop continue or exit, you should be allergic to using a return > > (other than at the end of a function). Some people are, and that is at > > least consistent. But I see a lot of Ada programmers who will use a return > > without hesitation from a nested loop, but still turn green at the sight > > of a goto. That makes no sense to me. A 'return', at least in C/C++/VB, returns you to the place the current procedure was called from. 'goto' control flow can be endlessly channeled here and there and never has to return to where the initial linear control flow was originally diverted. That seems to be a huge advantage of 'return' over 'goto'. Elliott -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-19 0:00 ` ell @ 1998-08-19 0:00 ` Charles Hixson 1998-08-19 0:00 ` adam 1998-08-20 0:00 ` Gerry Quinn 2 siblings, 0 replies; 74+ messages in thread From: Charles Hixson @ 1998-08-19 0:00 UTC (permalink / raw) That is the same as the argument for break and continue. A good one I feel. It is true that, as was written earlier, break and continue are always(?) implemented as-if they were goto statements, nevertheless because of their restricted compass (either the immediate block, or a named enclosing block) they do not impair code readability to the same extent as the goto does. As a famous man once said "GoTo considered harmful to programming". It has been years since I used a language so crippled that I choose an algorithm construction that required a goto to properly implement it. Please note that that is a two-part statement, partially language design and partially algorithm choice. Ada is not such a crippled language, as "exit when" is a perfectly adequate loop-leaving method. (I'm not sure what Ada has that corresponds to continue, but that is a less frequently needed choice). ell@access.digex.net wrote: > > In article <6r9f8h$jtm$1@nnrp1.dejanews.com>, > dennison@telepath.com wrote: > > In article <dewar.903281994@merv>, > > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > > T.E.D says > > > > > > But it's a toss up in this case, and for most purposes we would prefer > > > the second case. Where it gets tricky is > > > > > > for J in 1 .. N loop > > > if condition 1 then > > > ... > > > if condition 2 then > > > ... > > > if conditoin 3 then > > > goto Continue; > > > > > > Now T.E.D's prescription is not so clear, and we end up having to > > > severely contort things, or introduce a boolean flag which we keep > > > testing as we unwind to the end. > > > > > > Remember that the continue here is just like a return. If you are allergic > > > to using a loop continue or exit, you should be allergic to using a return > > > (other than at the end of a function). Some people are, and that is at > > > least consistent. But I see a lot of Ada programmers who will use a return > > > without hesitation from a nested loop, but still turn green at the sight > > > of a goto. That makes no sense to me. > > A 'return', at least in C/C++/VB, returns you to the place the current > procedure was called from. 'goto' control flow can be endlessly channeled > here and there and never has to return to where the initial linear control > flow was originally diverted. That seems to be a huge advantage of 'return' > over 'goto'. > > Elliott > > -----== Posted via Deja News, The Leader in Internet Discussion ==----- > http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum -- Charles Hixson charleshixson@earthling.net (510) 464-7733 or chixso@mtc.dst.ca.us ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-19 0:00 ` ell 1998-08-19 0:00 ` Charles Hixson @ 1998-08-19 0:00 ` adam 1998-08-19 0:00 ` Dan Higdon 1998-08-20 0:00 ` Ell 1998-08-20 0:00 ` Gerry Quinn 2 siblings, 2 replies; 74+ messages in thread From: adam @ 1998-08-19 0:00 UTC (permalink / raw) In article <6renh8$ga7$1@nnrp1.dejanews.com>, ell@access.digex.net wrote: > A 'return', at least in C/C++/VB, returns you to the place the current > procedure was called from. 'goto' control flow can be endlessly channeled > here and there and never has to return to where the initial linear control > flow was originally diverted. That seems to be a huge advantage of 'return' > over 'goto'. No, to me this seems to be a huge advantage of "return" over "using too many goto's in your code that go every which way so that your code ends up looking like spaghetti." No one is supporting the idea of using that many goto's, the way programmers used to. Those who think goto's are OK think they should be limited to certain specific situations, and your objection really doesn't apply when goto's are used in that sort of careful, disciplined fashion. Of course, "goto" can be dangerous in the hands of an inexperienced programmer; but so, for that matter, can every other construct of every language. In the 22 years or so since programmers have started treating "goto" as an evil, I've seen some pretty strange arguments purporting to explain *why* goto's were bad. The most bizarre one I've seen argued that if your code is structured as follows: Transformation-1; goto L; Transformation-2; L: .... where Transformation-1 and Transformation-2 are sequences of statements or something else that transform your current program state from one thing to another, then the presence of "goto" in effect means that your code contains the inverse function of Transformation-2, which cancels the effect of Transformation-2. The author offered this as an explanation why "goto" makes code harder to understand. I don't remember exactly where I read this, but it was in one of the ACM publications. Of course, this is nonsense. There are good reasons why a researcher might want to think of a "program" as a sequence of mathematical transformations on the program state, but an ordinary programmer trying to write correct code, or to read or maintain someone else's code, isn't going to think about things that way. That's why I'm skeptical about most of the arguments I see about why GOTO IS EVIL. There often seems to be an implicit assumption that mathematical purity, or an aesthetically beautiful program structure, or something similar, equals readability, but that isn't the case. So when I see statements like "'goto' control flow can be endlessly channeled here and there and never has to return to where the initial linear control flow was originally diverted", my reaction is, "So what?" This argument contains no explanation *why* this makes programs harder to work with. So, personally, I think arguments against "goto" (or against any other construction) should demonstrate things from the programmer's point of view. That is, how does this EVIL NASTY construct actually make it harder for a programmer to understand what's going on, or make it easier for a programmer to miss something and write incorrect code? If the argument doesn't address the issue from that angle, it's worthless, IMHO. Now, here are a couple arguments on the other side: (1) Say you want to avoid the EVIL NASTY "goto" by putting the code into a subroutine and using "return". Well, you have to give the subroutine a name. In place of the nested "if" causing the problem, you'll have a call to this subroutine. Now, when a programmer looks through the main line of code, she'll see a call to this subroutine, and she'll have to know what it does. Can you give the subroutine a name that will make it obvious to the maintenance programmer what's going on? Sometimes you can. But if all you're doing is extracting some code and sticking it in a subroutine, most of the time you can't give it a good descriptive name, since it reflects just a random sequence of statements and not a concept that can be easily compartmentalized. So in this case, IMHO doing this is worse than using "goto", since it makes the program less clear. Of course, you can probably figure out a way to redesign the code to make it clear, and your code will be more readable since it has smaller, more compact subroutines that perform a well-defined purpose. But this just illustrates the importance of good design in general; a programmer who simply says "RETURN is a lot better than GOTO" and moves code around just to avoid the GOTO is unlikely to end up with a more readable and maintainable program. (2) (This one is about "continue", since Charles Hixson later argued that this was also superior to "goto" for the same reasons.) If you have a loop that looks like: while (blah-blah) { some-if-statements... some-more-if-statements... xxx; yyy; zzz; } someone reading the program might assume that xxx, yyy, and zzz are always going to happen before the loop repeats. So if there's something new that needs to be done during every loop iteration, it looks like you can just add it to the end of the loop, after zzz. If there's a "continue" statement somewhere above that, this assumption is incorrect and your modification may well be wrong. If you replace the "continue" with a "goto", at least there will be a label somewhere toward the bottom of the loop, alerting you to the fact that you will have to decide whether to put the new code before or after the label, or look for the place where this label is goto'ed. In fact, this is exactly why I stopped using "continue" when I was a C programmer. (I didn't replace them with goto's, I used Boolean flags instead.) Now all of this may be a matter of how each individual programmer tends to think when they look at programs. The point is that, based on my experience, arguments about "returning to where the linear control flow was diverted" and "restricted compass" don't make a whole lot of sense in the real world. GOTO can be used in ways that enhance readability or in ways that impair it, and so can every other feature of every language. -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-19 0:00 ` adam @ 1998-08-19 0:00 ` Dan Higdon 1998-08-20 0:00 ` adam 1998-08-20 0:00 ` Ell 1 sibling, 1 reply; 74+ messages in thread From: Dan Higdon @ 1998-08-19 0:00 UTC (permalink / raw) adam@irvine.com wrote in message <6rf59b$2ud$1@nnrp1.dejanews.com>... <snip prelude> >Now, here are a couple arguments on the other side: <snip point 1> >(2) (This one is about "continue", since Charles Hixson later argued that this >was also superior to "goto" for the same reasons.) If you have a loop that >looks like: > > while (blah-blah) { > some-if-statements... > some-more-if-statements... > > xxx; > yyy; > zzz; > } > >someone reading the program might assume that xxx, yyy, and zzz are always >going to happen before the loop repeats. So if there's something new that >needs to be done during every loop iteration, it looks like you can just add >it to the end of the loop, after zzz. If there's a "continue" statement >somewhere above that, this assumption is incorrect and your modification may >well be wrong. If you replace the "continue" with a "goto", at least there >will be a label somewhere toward the bottom of the loop, alerting you to the >fact that you will have to decide whether to put the new code before or after >the label, or look for the place where this label is goto'ed. In fact, this >is exactly why I stopped using "continue" when I was a C programmer. (I >didn't replace them with goto's, I used Boolean flags instead.) So, you've actually changed the algorithm of your code, added an unnecessary data item and added yet another compare/branch to avoid a well understood (IMHO) construct of the C language? Perhaps I'm the only one who thinks writing code that will execute efficiently is equally important as writing readable code. If I didn't care about efficiency, I sure wouldn't be using a 3rd generation procedural language (OO or not) - there are (IMHO) many more succinct and mathematically rigorous languages out there than C or Eiffel (ML and Haskell come to mind, niether of which have gotos, fwiw). I'm not trying to start a language war - I'm pointing out that gotos and the implicit goto forms (break, continue, etc) are a tool of the language. They wouldn't be there if you NEVER needed them. So if you have a case that warrants their use, you should use them, rather than trying to hamstring yourself with hokey constructs. If you *need* that boolean value later, then by all means add it. But I think that using a boolean flag to erase a GOTO is not contributing to the solution, just adding inefficiency into the generated code, and one more symbol for the programmer to have to track. ---------------------------------------- hdan@charybdis.com "Throwing fire at the sun" ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-19 0:00 ` Dan Higdon @ 1998-08-20 0:00 ` adam 1998-08-20 0:00 ` Dan Higdon [not found] ` <m33eagru5g.fsf@mheaney.ni.net> 0 siblings, 2 replies; 74+ messages in thread From: adam @ 1998-08-20 0:00 UTC (permalink / raw) In article <l5HC1.6840$wN.1856764@news.giganews.com>, "Dan Higdon" <hdan@charybdis.com> wrote: > > adam@irvine.com wrote in message <6rf59b$2ud$1@nnrp1.dejanews.com>... > > <snip prelude> > > >Now, here are a couple arguments on the other side: > > <snip point 1> > > >(2) (This one is about "continue", since Charles Hixson later argued > >that this was also superior to "goto" for the same reasons.) If > >you have a loop that looks like: > > > > while (blah-blah) { > > some-if-statements... > > some-more-if-statements... > > > > xxx; > > yyy; > > zzz; > > } > > > >someone reading the program might assume that xxx, yyy, and zzz are > >always going to happen before the loop repeats. So if there's > >something new that needs to be done during every loop iteration, it > >looks like you can just add it to the end of the loop, after zzz. > >If there's a "continue" statement somewhere above that, this > >assumption is incorrect and your modification may well be wrong. If > >you replace the "continue" with a "goto", at least there will be a > >label somewhere toward the bottom of the loop, alerting you to the > >fact that you will have to decide whether to put the new code > >before or after the label, or look for the place where this label > >is goto'ed. In fact, this is exactly why I stopped using > >"continue" when I was a C programmer. (I didn't replace them with > >goto's, I used Boolean flags instead.) > > So, you've actually changed the algorithm of your code, added an > unnecessary data item and added yet another compare/branch to avoid > a well understood (IMHO) construct of the C language? Perhaps I'm > the only one who thinks writing code that will execute efficiently > is equally important as writing readable code. If I didn't care > about efficiency, I sure wouldn't be using a 3rd generation > procedural language (OO or not) - there are (IMHO) many more > succinct and mathematically rigorous languages out there than C or > Eiffel (ML and Haskell come to mind, niether of which have gotos, > fwiw). Well, I might have used GOTO if I had to do it over again. My early training taught me to avoid them, and this avoidance has become kind of ingrained. I still probably wouldn't use "continue", however. However: #1: Adding a flag in the manner I've described does not change the algorithm, it merely changes the way the flow of control is expressed. Unless you adopt a definition of "algorithm" that is so strict as to be useless except to an academic. #2: How important efficiency is depends on what you're writing. If you're working on time-critical code, it's very important, but if you're working on an application where most of the program's time will be spent waiting for the user to type in some input, a few hundred microseconds isn't anything to worry about. #3: A good optimizing compiler wouldn't do a compare/branch. It might set the flag, then notice that the next thing done is to test it, so it would blow off the test and just branch to wherever the "continue" statement was going to branch anyway. An even better optimizing compiler would then figure out that the flag is never actually tested, so it would just get rid of it. #4: Programmers don't always get to choose which language they use. #5: In this thread, we're arguing about readability and maintainability. If you have a situation where every nanosecond is critical, fine, but most of us are willing to give up a few nanoseconds in order to save time debugging and maintaining programs. If you've ever written a subroutine that was called at only one point in the rest of the program, instead of coding it inline so that you can avoid an unnecessary procedure call with all the stack pushes and pops, then certainly you have to admit that readability is worth sacrificing a couple machine cycles for, sometimes. > I'm not trying to start a language war - I'm pointing out that gotos > and the implicit goto forms (break, continue, etc) are a tool of the > language. They wouldn't be there if you NEVER needed them. There are lots of language constructs that aren't really "needed". And there are plenty of cases where an individual programmer, or a programming department, adopts a policy of avoiding a particular construct, which is fine as long as the prohibition isn't 100% absolute. A long time ago, I programmed in COBOL, and most of the programmers around me agreed that the ALTER statement was just a bad idea and shouldn't be used. I'll bet few would disagree with such a policy. -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-20 0:00 ` adam @ 1998-08-20 0:00 ` Dan Higdon [not found] ` <m33eagru5g.fsf@mheaney.ni.net> 1 sibling, 0 replies; 74+ messages in thread From: Dan Higdon @ 1998-08-20 0:00 UTC (permalink / raw) adam@irvine.com wrote in message <6rfra4$rul$1@nnrp1.dejanews.com>... >Well, I might have used GOTO if I had to do it over again. My early >training taught me to avoid them, and this avoidance has become kind >of ingrained. I still probably wouldn't use "continue", however. Then you probably wouldn't object to something like (pseudocode, as I'm not much of an Eiffel programmer): loop if not <condition> then -- whole bunch of stuff end if end loop Instead? That at least still only has you making the decision to branch once, instead of once when you set the flag and once when you decide what you meant earlier. I'll agree on the 'continue' avoidance, although I've found that constructs like that can make code a little cleaner if there is a whole lot of code in the "else" case. (Probably putting that code into a separate function would make it even more clear. :-) >However: > >#1: Adding a flag in the manner I've described does not change the >algorithm, it merely changes the way the flow of control is expressed. >Unless you adopt a definition of "algorithm" that is so strict as to >be useless except to an academic. You're checking the exit condition twice instead of once. That's a little like saying that the 'k' term of a "Big O" analysis doesn't matter, IMHO. It's not the meat of the algorithm, but it's definitely a detail. >#2: How important efficiency is depends on what you're writing. If >you're working on time-critical code, it's very important, but if >you're working on an application where most of the program's time will >be spent waiting for the user to type in some input, a few hundred >microseconds isn't anything to worry about. I probably shouldn't have come from a code efficiency standpoint - my real objection is related to boolean flag usage. If your algorithm demands that you be able to remind yourself later about a condition, then by all means. As this relates to the topic: I think that the use of boolean flags strictly for local flow control is a software landmine. An unappreciated one (because so much Pascal has been taught, and that's the only way to get Pascal to do some things), but a landmine none the less. >#3: A good optimizing compiler wouldn't do a compare/branch. It might <snip> I'm too suspicious of tool quality to rely on good compilers too much. >#4: Programmers don't always get to choose which language they use. Too true - I have to use C++. Hence my fear of tool quality. :-) >#5: In this thread, we're arguing about readability and >maintainability. If you have a situation where every nanosecond is >critical, fine, but most of us are willing to give up a few >nanoseconds in order to save time debugging and maintaining programs. Yes, I want to get back on topic as well - I agree that nanosecond timing considerations and readable code don't always coexist peacfully. Sadly, it looks like we're getting into the subjective side of what is readable and maintainable. I find flags (local vars - not object data slots) distracting. Obviously you do not. I guess we'll have to agree to disagree? >There are lots of language constructs that aren't really "needed". >And there are plenty of cases where an individual programmer, or a >programming department, adopts a policy of avoiding a particular >construct, which is fine as long as the prohibition isn't 100% I'll agree with that - we don't use exceptions (time sensitivity issues) or templates (bad compiler support) in our C++ code usually, but sometimes a template is the best way to do something. (But don't get me started on the STL - one of the most compelling reasons to switch away from C++ yet, IMHO.) >absolute. A long time ago, I programmed in COBOL, and most of the >programmers around me agreed that the ALTER statement was just a bad >idea and shouldn't be used. I'll bet few would disagree with such a >policy. I've not had the pleasure(?) of programming in COBOL - FORTRAN was my teething ring. But I suspect ALTER is about as much fun to maintain as an arithmatic IF statement. :-) ---------------------------------------- hdan@charybdis.com "Throwing fire at the sun" ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <m33eagru5g.fsf@mheaney.ni.net>]
* Re: Software landmines (was: Why C++ is successful) [not found] ` <m33eagru5g.fsf@mheaney.ni.net> @ 1998-08-31 0:00 ` Frank Adrian 1998-08-31 0:00 ` Robert I. Eachus 1998-09-01 0:00 ` dewarr 1998-09-06 0:00 ` Jonathan Guthrie 1 sibling, 2 replies; 74+ messages in thread From: Frank Adrian @ 1998-08-31 0:00 UTC (permalink / raw) Matthew Heaney wrote in message ... >A scanner is also another abstraction best implemented using gotos. A scanner is a well enough defined abstraction with enough well constructed (and fast) implementations around that anyone trying to write his own from scratch should be censured. [SNIP (of things that I agree with for the most part)] >Use gotos when they make sense. One time they do make sense is to >implement a state machine, which requires transitions between states. >This is typical for tasks and scanners. Again, the tasks you mention should be subsumed by code generators or higher-level design packages, not wasting programmers' time wondering if they got the goto in (and pointing to) the right place. Now the question is whether or not all "proper" uses of goto can be subsumed by higher-level constructs (such as exception mechanisms, loop continuations or breaks, etc.) which have much less of a cognative load than a fully general and unstructured goto. I tend to think so. -- Frank A. Adrian First DataBank frank_adrian@firstdatabank.com (W) franka@europa.com (H) This message does not necessarily reflect those of my employer, its parent company, or any of the co-subsidiaries of the parent company. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-31 0:00 ` Frank Adrian @ 1998-08-31 0:00 ` Robert I. Eachus 1998-08-31 0:00 ` Biju Thomas 1998-09-01 0:00 ` dewarr 1 sibling, 1 reply; 74+ messages in thread From: Robert I. Eachus @ 1998-08-31 0:00 UTC (permalink / raw) In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian" <frank_adrian@firstdatabank.com> writes: > Again, the tasks you mention should be subsumed by code generators or > higher-level design packages, not wasting programmers' time wondering if > they got the goto in (and pointing to) the right place. A fine point of view for an application developer. But there are those of us who build tools like compilers, scanner generators, parser generators, etc. Your code may not have gotos, and my code may not have gotos, but when you use my tools to generate your code, don't be surprised to find occasional (or not so occasional) gotos. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-31 0:00 ` Robert I. Eachus @ 1998-08-31 0:00 ` Biju Thomas 1998-08-31 0:00 ` Robert Martin 1998-09-01 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 74+ messages in thread From: Biju Thomas @ 1998-08-31 0:00 UTC (permalink / raw) Robert I. Eachus wrote: > > In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian" <frank_adrian@firstdatabank.com> writes: > > > Again, the tasks you mention should be subsumed by code generators or > > higher-level design packages, not wasting programmers' time wondering if > > they got the goto in (and pointing to) the right place. > > A fine point of view for an application developer. But there are > those of us who build tools like compilers, scanner generators, parser > generators, etc. Your code may not have gotos, and my code may not > have gotos, but when you use my tools to generate your code, don't be > surprised to find occasional (or not so occasional) gotos. These tools may be generating gotos since they are decades old, and nobody ever tried to improve upon them. Biju Thomas ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-31 0:00 ` Biju Thomas @ 1998-08-31 0:00 ` Robert Martin 1998-09-01 0:00 ` Martin Dowie 1998-09-01 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 74+ messages in thread From: Robert Martin @ 1998-08-31 0:00 UTC (permalink / raw) Biju Thomas wrote in message <35EB3B71.ED6D4066@ibm.net>... >Robert I. Eachus wrote: >> >> In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian" <frank_adrian@firstdatabank.com> writes: >> >> > Again, the tasks you mention should be subsumed by code generators or >> > higher-level design packages, not wasting programmers' time wondering if >> > they got the goto in (and pointing to) the right place. >> >> A fine point of view for an application developer. But there are >> those of us who build tools like compilers, scanner generators, parser >> generators, etc. Your code may not have gotos, and my code may not >> have gotos, but when you use my tools to generate your code, don't be >> surprised to find occasional (or not so occasional) gotos. > >These tools may be generating gotos since they are decades old, and >nobody ever tried to improve upon them. As long as the generated code does not have to be maintained, it doesn't matter if it generates goto's or not. Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-31 0:00 ` Robert Martin @ 1998-09-01 0:00 ` Martin Dowie 0 siblings, 0 replies; 74+ messages in thread From: Martin Dowie @ 1998-09-01 0:00 UTC (permalink / raw) In article <6sfr1m$gi7$1@hirame.wwa.com>, Robert Martin <rmartin@oma.com> writes > >Biju Thomas wrote in message <35EB3B71.ED6D4066@ibm.net>... >>Robert I. Eachus wrote: >>> >>> In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian" ><frank_adrian@firstdatabank.com> writes: >>> >>> > Again, the tasks you mention should be subsumed by code generators or >>> > higher-level design packages, not wasting programmers' time wondering >if >>> > they got the goto in (and pointing to) the right place. >>> >>> A fine point of view for an application developer. But there are >>> those of us who build tools like compilers, scanner generators, parser >>> generators, etc. Your code may not have gotos, and my code may not >>> have gotos, but when you use my tools to generate your code, don't be >>> surprised to find occasional (or not so occasional) gotos. >> >>These tools may be generating gotos since they are decades old, and >>nobody ever tried to improve upon them. > >As long as the generated code does not have to be maintained, it doesn't >matter if it generates goto's or not. absolutely - otherwise we'd be arguing against compilers/linkers generating assembler language 'jump' statements -- Martin Dowie ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-31 0:00 ` Biju Thomas 1998-08-31 0:00 ` Robert Martin @ 1998-09-01 0:00 ` Robert I. Eachus 1998-09-02 0:00 ` dennison 1 sibling, 1 reply; 74+ messages in thread From: Robert I. Eachus @ 1998-09-01 0:00 UTC (permalink / raw) In article <35EB3B71.ED6D4066@ibm.net> Biju Thomas <bijuthom@ibm.net> writes: > These tools may be generating gotos since they are decades old, and > nobody ever tried to improve upon them. NO! Excuse the shouting. If I am implementing your LALR(k) grammar as a state machine, the only realization that makes sense is to have hundreds of (sometimes thousands of) states. I label the states, and the code moves from state to state, recognizing that some states shift information onto the stack, and others reduce the stack (thus the old name of a shift-reduce parser). The final program makes spaghetti code look well organized, but the maintenance is done on the grammer not on its realization. If you have a "more modern" tool, building the tables is just the first step. Now your tool applies various transformations to the tables which further complexify the resulting code. The resulting compacted and optimized tables bear little or no resemblence to the grammar, but the tables take a few thousand bytes of space, not a few million, and the parser executes ten or so times as fast. It is worth the effort, but now the optimized grammar realization bears little resemblence to the original parser output. (To be more formal, the parser generator might accept some superset of LALR(1) grammars as input, and produce LR(1) tables as output. The final optimized tables may not be in LR(k) for any k.) The final representation (in machine code) is going to use jumps and branches in any case. But the code generated by the tool, if in a high-level language can use a case statement or gotos. Best however, is to put addresses in the tables and have the state machine "table driven." Each state corresponds to executing the core of the driver program with the address of the next state, and the stack as nominal inputs. This core can either be written as a procedure, or as just a block of statements wrapped in a loop. But what you end up with is a driver program that is itself a realization of an FSM. So far so good, but this FSM must handle are several exceptional cases/states. One is the final state, another is when due to the way the tables were compressed, you want to return to a previous point in the processing. (You reach the end of a table, but instead of an error, it says to contine with another table--but you don't want to repeat the setup code...) The final case of course, is error handling. It usually turns out that when writing this driver program, you can use loops, exception handling, continue statements, etc., to cover all but one of the loop backs. But much cleaner and clearer--and I have written those driver programs in PL/I, Ada, and C--is to use one or two well placed gotos. A different way of stating it is that any flowchart of the driver cannot be embedded in a plane. So we are back to where this discussion started. There appear to be some circumstances which justify use of gotos in Ada. But the only cases that anyone in this group has seen involve implementing finite state machines of one kind or another. I think that the structure that makes gotos appropriate is exactly when the flowchart cannot be embedded. I'd like to find more cases if they exist. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-09-01 0:00 ` Robert I. Eachus @ 1998-09-02 0:00 ` dennison 0 siblings, 0 replies; 74+ messages in thread From: dennison @ 1998-09-02 0:00 UTC (permalink / raw) In article <EACHUS.98Sep1171449@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) wrote: > or two well placed gotos. A different way of stating it is that any > flowchart of the driver cannot be embedded in a plane. ..without flow lines crossing. Right?. There's a mathematical way to express that, but my graph theory is too rusty to come up with it now. -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-31 0:00 ` Frank Adrian 1998-08-31 0:00 ` Robert I. Eachus @ 1998-09-01 0:00 ` dewarr 1 sibling, 0 replies; 74+ messages in thread From: dewarr @ 1998-09-01 0:00 UTC (permalink / raw) In article <JTCG1.566$H52.143421@client.news.psi.net>, "Frank Adrian" <frank_adrian@firstdatabank.com> wrote: > Matthew Heaney wrote in message ... > >A scanner is also another abstraction best implemented using gotos. > > A scanner is a well enough defined abstraction with enough well constructed > (and fast) implementations around that anyone trying to write his own from > scratch should be censured. > > [SNIP (of things that I agree with for the most part)] > > >Use gotos when they make sense. One time they do make sense is to > >implement a state machine, which requires transitions between states. > >This is typical for tasks and scanners. > > Again, the tasks you mention should be subsumed by code generators or > higher-level design packages, not wasting programmers' time wondering if > they got the goto in (and pointing to) the right place. > > Now the question is whether or not all "proper" uses of goto can be subsumed > by higher-level constructs (such as exception mechanisms, loop continuations > or breaks, etc.) which have much less of a cognative load than a fully > general and unstructured goto. I tend to think so. > -- > Frank A. Adrian > First DataBank > > frank_adrian@firstdatabank.com (W) > franka@europa.com (H) > > This message does not necessarily reflect those of my employer, > its parent company, or any of the co-subsidiaries of the parent > company. > > The idea that writing your own scanner is a bad idea probably shows simply a lack of awareness. The general tools available for writing scanners generate extremely inefficient scanners compared to what can be achieved if a scanner is specialized to a particular language. In particular, the whole notion of finite state machines is a red herring when it comes to constructing efficient scanners for particular languages. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) [not found] ` <m33eagru5g.fsf@mheaney.ni.net> 1998-08-31 0:00 ` Frank Adrian @ 1998-09-06 0:00 ` Jonathan Guthrie 1 sibling, 0 replies; 74+ messages in thread From: Jonathan Guthrie @ 1998-09-06 0:00 UTC (permalink / raw) In comp.lang.ada Matthew Heaney <matthew_heaney@acm.org> wrote: > I routinely use gotos to implement tasks. Tasks usually execute a state > machine, and gotos are the most natural way to implement the jumping > between states that is required. I have seen the assertion made that gotos are a natural way of handling FSM's, and I have to mildly disagree with that statement. I'm working on an industrial control system (well, it's industrial-style--- the system itself is intended to be installed at the fuelling positions in automotive service stations) which consists of something like 2 dozen programs running on 1+2N computers (where 'N' is the number of fuelling positions) written in (so far) four different programming languages and running under three different operating systems. The set up is absolutely lousy with FSMs, but I can't use the PC to encode the state because those programs that have FSMs have more than one. (The least I have in any is in the DS-5000 source, which has 3 FSMs in about 2000 lines of BASIC.) I can't encode the state in the PC because I know of no way of doing that (short of merging all of the state machines, which is not possible due to memory constraints) when multiple independant finite state machines exist in the same program. I think I understand how to use it in scanners, though. I hadn't realized that it isn't necessary to save the state of the scanner (with the possible exception of lookahead characters) when the scanner isn't active. I would have to check my sources to see if I've already built that assumption in to my code. (I'd be willing to bet that I have. That seems to be the difference between the FSMs I usually write and those independant ones I've been building for Additech.) Anyway, I would have to say that gotos are a natural way of handling some FSMs, but not all. -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-19 0:00 ` adam 1998-08-19 0:00 ` Dan Higdon @ 1998-08-20 0:00 ` Ell 1998-08-21 0:00 ` Ell 1 sibling, 1 reply; 74+ messages in thread From: Ell @ 1998-08-20 0:00 UTC (permalink / raw) adam@irvine.com wrote: >In article <6renh8$ga7$1@nnrp1.dejanews.com>, > ell@access.digex.net wrote: > >> A 'return', at least in C/C++/VB, returns you to the place the current >> procedure was called from. 'goto' control flow can be endlessly channeled >> here and there and never has to return to where the initial linear control >> flow was originally diverted. That seems to be a huge advantage of 'return' >> over 'goto'. >No, to me this seems to be a huge advantage of "return" over "using too many >goto's in your code that go every which way so that your code ends up looking >like spaghetti." No one is supporting the idea of using that many goto's, >the way programmers used to. Those who think goto's are OK think they should >be limited to certain specific situations, and your objection really doesn't >apply when goto's are used in that sort of careful, disciplined fashion. My point is that 'return' applies a default discipline to 'goto'. In fact it's so useful that it now becomes OK to use 'return' quite liberally. This affords much flexibility. >Of >course, "goto" can be dangerous in the hands of an inexperienced programmer; >but so, for that matter, can every other construct of every language. I'm willing to use 'goto' in time critical code where inlines are not possible, to save stack winding and unwinding. Other than that I'd rather use a procedure call and returns to get back. Elliott -- :=***=: Objective * Pre-code Modelling * Holistic :=***=: Hallmarks of the best SW Engineering "The domain object model is the foundation of OOD." Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell Copyright 1998 Elliott. exclusive of others' writing. may be copied without permission only in the comp.* usenet and bitnet groups. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-20 0:00 ` Ell @ 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` John Goodsen 1998-08-21 0:00 ` Larry Brasfield 0 siblings, 2 replies; 74+ messages in thread From: Ell @ 1998-08-21 0:00 UTC (permalink / raw) ell@access.digex.net (Ell) wrote: >I'm willing to use 'goto' in time critical code where inlines are not >possible, to save stack winding and unwinding. Other than that I'd >rather use a procedure call and returns to get back. And even then, I try to organize the code so that I invoke 'goto :labelX' and jump to its target ':labelX' **within** a single procedure/function/module. I try **never** to cross procedure/funtion/module boundaries with a 'goto', when I use it for time critical code. Elliott -- :=***=: Objective * Pre-code Modelling * Holistic :=***=: Hallmarks of the best SW Engineering "The domain object model is the foundation of OOD." Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell Copyright 1998 Elliott. exclusive of others' writing. may be copied without permission only in the comp.* usenet and bitnet groups. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Ell @ 1998-08-21 0:00 ` John Goodsen 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` Larry Brasfield 1 sibling, 1 reply; 74+ messages in thread From: John Goodsen @ 1998-08-21 0:00 UTC (permalink / raw) Ell wrote in message <35dfb9a8.4685477@news.erols.com>... >ell@access.digex.net (Ell) wrote: > >>I'm willing to use 'goto' in time critical code where inlines are not >>possible, to save stack winding and unwinding. Other than that I'd >>rather use a procedure call and returns to get back. > >And even then, I try to organize the code so that I invoke 'goto >:labelX' and jump to its target ':labelX' **within** a single >procedure/function/module. > >I try **never** to cross procedure/funtion/module boundaries with a >'goto', when I use it for time critical code. > It seems you are saying two things. You use goto to save stack winding/unwinding in time critical code, yet you never goto around a "stack boundary" (e.g. a procedure/function boundary). How do you use goto's to increase efficiency in these cases then? thanks in advance, -- John Goodsen Saguaro Software, Inc. / Training & Consulting in: jgoodsen@saguarosoft.com - User Centered Systems Analysis http://www.saguarosoft.com - Object Oriented Architecture and Design 602.283.0142 / 888.298.2566 - Rapid Incremental Delivery S/W Process "Example isn't another way to teach, it is the only way to teach. " - Albert Einstein ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` John Goodsen @ 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` Ell 0 siblings, 1 reply; 74+ messages in thread From: Ell @ 1998-08-21 0:00 UTC (permalink / raw) "John Goodsen" <jgoodsen@saguarosoft.com> wrote: >Ell wrote in message <35dfb9a8.4685477@news.erols.com>... >> >>ell@access.digex.net (Ell) wrote: >>> >>>I'm willing to use 'goto' in time critical code where inlines are not >>>possible, to save stack winding and unwinding. Other than that I'd >>>rather use a procedure call and returns to get back. >>And even then, I try to organize the code so that I invoke 'goto >>:labelX' and jump to its target ':labelX' **within** a single >>procedure/function/module. >>I try **never** to cross procedure/funtion/module boundaries with a >>'goto', when I use it for time critical code. >It seems you are saying two things. You use goto to save stack >winding/unwinding in time critical code, yet you never goto around >a "stack boundary" (e.g. a procedure/function boundary). >How do you use goto's to increase efficiency in these cases then? I don't. I organize the relevant code - say for a sort - so that it all resides within a single procedure/function/module. I then subdivide the code by preceding logical blocks with a 'labelX'. And then I use 'goto' to navigate from block to block. Typically, I end most blocks of code headed by a ':labelX' with a 'goto' that leads to the first line of code immediately after where the 'goto' that entered the block was called. E.g. procedure xyz { // remember, code preceded by a ':labelX' must be entered // by an explicit 'goto labelX' call. it can *not* be entered by // default "flow control fall through" with MSDOS batch files. xysytr wekll jhgjie goto label 1 :label 2 // label 2 ceiue mhjyy return // exits procedure altogether :label 1 // label 1 lkjhgf touuy cnnfe goto label 2 // go back to next line after where this block // was called }; In the above, the final block of code to be executed exits the procedure with a 'return' Of course you can make things more interesting with a conditional constructs like 'if', 'case', or 'switch'. procedure xyz { xysytr wekll jhgjie goto label 2 :label 2 // label 2 ceiue mhjyy goto label 3 :label 3 // label 3 lkjhgf touuy cnnfe if x = 0 goto label 2 elseif x = 1 goto label 4 else return // leaves procedure endif :label 4 // label 4 hjuye mhyd lasdfl // procedure is left after this line }; Elliott -- :=***=: Objective * Pre-code Modelling * Holistic :=***=: Hallmarks of the best SW Engineering "The domain object model is the foundation of OOD." Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell Copyright 1998 Elliott. exclusive of others' writing. may be copied without permission only in the comp.* usenet and bitnet groups. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Ell @ 1998-08-21 0:00 ` Ell 0 siblings, 0 replies; 74+ messages in thread From: Ell @ 1998-08-21 0:00 UTC (permalink / raw) ell@access.digex.net (Ell) wrote: > // remember, code preceded by a ':labelX' must be entered > // by an explicit 'goto labelX' call. it can *not* be entered by > // default "flow control fall through" with MSDOS batch files. Rather: > // remember, code preceded by a ':labelX' must be entered > // by an explicit 'goto labelX' call. it can *not* be entered by > // default "flow control fall through" [like] MSDOS batch files. ^^^^ Elliott -- :=***=: Objective * Pre-code Modelling * Holistic :=***=: Hallmarks of the best SW Engineering "The domain object model is the foundation of OOD." Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell Copyright 1998 Elliott. exclusive of others' writing. may be copied without permission only in the comp.* usenet and bitnet groups. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` John Goodsen @ 1998-08-21 0:00 ` Larry Brasfield 1998-08-21 0:00 ` Jeffrey C. Dege ` (2 more replies) 1 sibling, 3 replies; 74+ messages in thread From: Larry Brasfield @ 1998-08-21 0:00 UTC (permalink / raw) Ell wrote in message <35dfb9a8.4685477@news.erols.com>... >ell@access.digex.net (Ell) wrote: > >>I'm willing to use 'goto' in time critical code where inlines are not >>possible, to save stack winding and unwinding. Other than that I'd >>rather use a procedure call and returns to get back. > >And even then, I try to organize the code so that I invoke 'goto >:labelX' and jump to its target ':labelX' **within** a single >procedure/function/module. > >I try **never** to cross procedure/funtion/module boundaries with a >'goto', when I use it for time critical code. Is there any language in ordinary use that permits a goto to cross a procedure boundary? If so, how are goto target name scopes defined? If not, why make so much of trying to avoid such goto's? <g> --Larry Brasfield Above opinions may be mine alone. (Humans may reply at unundered larry_br@sea_net.com ) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Larry Brasfield @ 1998-08-21 0:00 ` Jeffrey C. Dege 1998-08-20 0:00 ` Phlip ` (2 more replies) 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` Bob Collins 2 siblings, 3 replies; 74+ messages in thread From: Jeffrey C. Dege @ 1998-08-21 0:00 UTC (permalink / raw) On Fri, 21 Aug 1998 01:29:16 GMT, Larry Brasfield <larry_br@sea_net.com> wrote: > >Is there any language in ordinary use that permits >a goto to cross a procedure boundary? If so, how >are goto target name scopes defined? If not, why >make so much of trying to avoid such goto's? <g> C's setjmp()/longjmp() functions provide for a goto() across procedure boundaries. Or at least from a function to a function that called it. -- "It is not Microsoft's monopoly that I object to, it is the mediocrity of their products." -- Larry Ellison, CEO of Oracle ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Jeffrey C. Dege @ 1998-08-20 0:00 ` Phlip 1998-08-21 0:00 ` Larry Brasfield [not found] ` <DOSXjHE9T6DM9Jw9nAyaPxfz@news.rdc1.bc.wave.home.com> 2 siblings, 0 replies; 74+ messages in thread From: Phlip @ 1998-08-20 0:00 UTC (permalink / raw) Jeffrey C. Dege wrote in message ... >On Fri, 21 Aug 1998 01:29:16 GMT, Larry Brasfield <larry_br@sea_net.com> wrote: >> >>Is there any language in ordinary use that permits >>a goto to cross a procedure boundary? If so, how >>are goto target name scopes defined? If not, why >>make so much of trying to avoid such goto's? <g> > >C's setjmp()/longjmp() functions provide for a goto() across procedure >boundaries. Or at least from a function to a function that called it. We all know that's not what Ell thought he meant, if anything. >-- >"It is not Microsoft's monopoly that I object to, it is the mediocrity of >their products." -- Larry Ellison, CEO of Oracle -- Phlip (no replies - address munged) ======= http://users.deltanet.com/~tegan/home.html ======= -- Whip me. Beat me. Make me install Oracle. -- ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Jeffrey C. Dege 1998-08-20 0:00 ` Phlip @ 1998-08-21 0:00 ` Larry Brasfield [not found] ` <DOSXjHE9T6DM9Jw9nAyaPxfz@news.rdc1.bc.wave.home.com> 2 siblings, 0 replies; 74+ messages in thread From: Larry Brasfield @ 1998-08-21 0:00 UTC (permalink / raw) Jeffrey C. Dege wrote in message ... >On Fri, 21 Aug 1998 01:29:16 GMT, Larry Brasfield <larry_br@sea_net.com> wrote: >> >>Is there any language in ordinary use that permits >>a goto to cross a procedure boundary? If so, how >>are goto target name scopes defined? If not, why >>make so much of trying to avoid such goto's? <g> (Assembler allows cross-procedure jumps. Most variants require goto's for interesting programs.) >C's setjmp()/longjmp() functions provide for a goto() across procedure >boundaries. Or at least from a function to a function that called it. setjmp/longjmp provide stack adjustment as well. This makes longjmp closer to a form of return, IMO. Perhaps "computed return" since its argument determines which setjmp call to return (again) from. Where I have seen setjmp/longjmp used effectively, it made the code easier to understand in much the same way that exceptions in other languages can. This resembles the conservative use of goto when it is constrained to a well defined path taken only for exceptional conditions. --Larry Brasfield Above opinions may be mine alone. (Humans may reply at unundered larry_br@sea_net.com ) ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <DOSXjHE9T6DM9Jw9nAyaPxfz@news.rdc1.bc.wave.home.com>]
* Re: Software landmines (was: Why C++ is successful) @ 1998-08-22 0:00 ` dewar 1998-08-24 0:00 ` dennison ` (2 more replies) 0 siblings, 3 replies; 74+ messages in thread From: dewar @ 1998-08-22 0:00 UTC (permalink / raw) <<> Good point. Typically in this case I would "cheat" it and embed the inside of > the loop in a subprogram, with a return statement. . . . >> This is typical of the kind of obfuscation that I find odd when it is used in a desparate attempt to avoid a goto spelled G-O-T-O. A return *is* a goto statement, so is an exit statement. They are both reasonably well disciplined goto statements, so this means they are neither better nor worse than corresponding disciplined use of goto. But to introduce a procedure just for the purpose of avoiding spelling the goto with g-o-t-o seems very strange. It is like an alcoholic thinking it is OK to put fruit and yeast in a pot and drink it months later, because, after all, no alcohol was put in the pot :-) -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-22 0:00 ` dewar @ 1998-08-24 0:00 ` dennison 1998-08-28 0:00 ` Matthew Heaney 1998-08-24 0:00 ` Martin Dowie 1998-09-22 0:00 ` Charles H. Sampson 2 siblings, 1 reply; 74+ messages in thread From: dennison @ 1998-08-24 0:00 UTC (permalink / raw) In article <6rnh8p$dno$1@nnrp1.dejanews.com>, dewar@gnat.com wrote: > <<> Good point. Typically in this case I would "cheat" it and embed the inside > of > > the loop in a subprogram, with a return statement. . . . >> > ... > A return *is* a goto statement, so is an exit statement. They are both > reasonably well disciplined goto statements, so this means they are neither > better nor worse than corresponding disciplined use of goto. Perhaps. But two years from now the maintainer will have no clue how "disciplined" I am being with that goto, without reading every line of code to make sure. This whole line of reasoning makes me very uncomfortable, as it has a striking similarity to the arguments I used to hear against strong-typing. After all, a disciplined software engineer won't need strong-typing either, right? It will just get in his way. > It is like an alcoholic thinking it is OK to put fruit and yeast in a pot > and drink it months later, because, after all, no alcohol was put in the > pot :-) Geez. I see your point. I guess I do tend to horribly abuse exit and return. Perhaps I need to start going to the meetings again. :-) -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` dennison @ 1998-08-28 0:00 ` Matthew Heaney 1998-08-28 0:00 ` dennison 0 siblings, 1 reply; 74+ messages in thread From: Matthew Heaney @ 1998-08-28 0:00 UTC (permalink / raw) dennison@telepath.com writes: > This whole line of reasoning makes me very uncomfortable, as it has a > striking similarity to the arguments I used to hear against > strong-typing. After all, a disciplined software engineer won't need > strong-typing either, right? It will just get in his way. No. Among other things, the purpose of strong typing is to prevent accidents, not get in your way. If a "strongly typed" abstraction is difficult to use, then something is wrong with the implementation of the abstraction. Saying that strong typing gets in your way is a little like saying that using a speedometer gets in your way, because you can't see how fast the wheel is rotating. All a language can do is give the programmer the tools he needs to compose abstractions. If the programmer writes bad abstractions, by misusing the type system, then it's the fault of the programmer. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` Matthew Heaney @ 1998-08-28 0:00 ` dennison 1998-08-30 0:00 ` Matthew Heaney 1998-08-31 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 74+ messages in thread From: dennison @ 1998-08-28 0:00 UTC (permalink / raw) In article <m3iujetijb.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > dennison@telepath.com writes: > > > This whole line of reasoning makes me very uncomfortable, as it has a > > striking similarity to the arguments I used to hear against > > strong-typing. After all, a disciplined software engineer won't need > > strong-typing either, right? It will just get in his way. > > No. Among other things, the purpose of strong typing is to prevent > accidents, not get in your way. If a "strongly typed" abstraction is > difficult to use, then something is wrong with the implementation of the > abstraction. > > Saying that strong typing gets in your way is a little like saying that > using a speedometer gets in your way, because you can't see how fast the > wheel is rotating. My point exactly. Why doesn't this same logic apply to goto's vs. more structured flow control statements? -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` dennison @ 1998-08-30 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1998-08-31 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 74+ messages in thread From: Matthew Heaney @ 1998-08-30 0:00 UTC (permalink / raw) dennison@telepath.com writes: > > Saying that strong typing gets in your way is a little like saying that > > using a speedometer gets in your way, because you can't see how fast the > > wheel is rotating. > > My point exactly. Why doesn't this same logic apply to goto's vs. more > structured flow control statements? The premise to your argument is that goto-less ("more structured") control flow statements are better then using a goto directly. What we are debating is whether to accept this premise. My only criterion for goodness is whether something makes the program easier to understand. Is the program more or less complex by using the statement? This question can only be answered by the human programmers that write programs using the statement. Bohm-Jacopini showed that only 3(?) constructs were necessary to implement all control flow. But so what? They weren't saying don't use other constructs. In one of his books, Dijkstra spoke of minimizing the "intellectual distance" between the problem and its solution (in the form of a computer program). If using a goto makes the implementation of an algorithm simpler, then I'm all for it. The goal IS "make the program simple to understand." The goal is NOT "don't use a goto." When I write a state-based abstraction - for example, just about any task - then the first thing I do is write a little state transition diagram. This is my problem. Now I want to transform this problem into a solution. To reduce translation error, I want be able to translate the STD more or less directly into program text. The _simplest_ way, in my opinion, is to use a goto. This allows me to easily navigate among the states, directly, just like in the STD. Now this doesn't mean a solution using "more structured" control flow statements isn't possible. Of course it's possible. But what we're debating is whether this alternate solution is better than the goto. What is deemed "better" is a social phenonmenon. God did not decide that goto-less control flow is better. You did, by making a personal choice. Other programmers (like me and Robert) have made a different choice. One can come up with a theory about whether something is better, but any theory must stand the test of observation. Any theory which contradicts observation should be thrown out. Any theory about using (or not using) a programming construct needs to be tested against observation, by performing an empirical study that measures the defect rates of programmers using the construct. If theory says use a construct, but observation reveals that programmers who use the construct produce more errors, then the theory needs to be thrown out. For example, there's a pernicious myth that exiting (or returning) from the middle of a loop is bad, and that the only proper way to write a loop is to state the termination condition explicitly, as a predicate appearing at the top of the loop. This theory was indeed put to the test, and guess what? Programmers using a test-and-exit from the middle of the loop produced fewer errors than those programmers who tried to put the test at the top of the loop. The researchers found that the exit-from-the-middle construct had a better "cognitive fit" than the other constructs. If you want to read the gory details, the article is Cognitive Strategies and Looping Constructs: An Empirical Study Soloway, Bonar, Ehrlich CACM, Nov 83, Vol 26, No 11, p 853-860 The goodness of a language construct should not be determined by doctrinaire computer scientists or mathematicians. The only thing that matters is whether working programmers think it's easier to understand, and whether by using the construct programmers inject fewer errors into the code. I think it was Stroustrup who said, "Programming is a human activity. Forget that, and all is lost." ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-30 0:00 ` Matthew Heaney @ 1998-09-06 0:00 ` John G. Volan 0 siblings, 0 replies; 74+ messages in thread From: John G. Volan @ 1998-09-06 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > For example, there's a pernicious myth that exiting (or returning) from > the middle of a loop is bad, and that the only proper way to write a > loop is to state the termination condition explicitly, as a predicate > appearing at the top of the loop. Maybe the real problem is not where the loop exit occurs _vertically_, but rather where it occurs _horizontally_ -- that, at what nesting depth. Take a look at the thread "Mid-Loop 'Until' Proposal" from c.l.e. Consider the comparison I make between a possible Eiffel extension that would grant a loop more freedom as to where an "until" clause could be placed, yet still require the terminating postcondition to appear at the outermost level of nesting; versus Ada's "exit when" statement, which can reach out and affect the control-flow of its enclosing loop from some arbitrarily deep level of nesting. -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-28 0:00 ` dennison 1998-08-30 0:00 ` Matthew Heaney @ 1998-08-31 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 74+ messages in thread From: Robert I. Eachus @ 1998-08-31 0:00 UTC (permalink / raw) In article <6s6h4a$ha9$1@nnrp1.dejanews.com> dennison@telepath.com writes: > My point exactly. Why doesn't this same logic apply to goto's vs. more > structured flow control statements? Let's not start this argument again. ;-) But there is visible bias in your question, which has to be rooted out before the answer is obvious. There are many situations in which if statements, for loops, while loops, etc., are more structured than gotos. So if you want to write a well structured program you use them. There are a few cases where the best structure uses gotos. In those cases, if you are trying to write a well structured program, you use a goto--unless you are molested by the goto gestapo. In my personnal experience, these have only occured in programs which implemented finite state machines. (And even then the main FSM loop was implemented as a loop. The gotos were to deal with special cases such as the final state.) There are rather more cases where the goto is better than the stuctures available in langauges not as rich as Ada. In those cases the best choice may be to change languages. ;-) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-22 0:00 ` dewar 1998-08-24 0:00 ` dennison @ 1998-08-24 0:00 ` Martin Dowie 1998-08-24 0:00 ` Martin Dowie 1998-08-25 0:00 ` adam 1998-09-22 0:00 ` Charles H. Sampson 2 siblings, 2 replies; 74+ messages in thread From: Martin Dowie @ 1998-08-24 0:00 UTC (permalink / raw) In article <6rnh8p$dno$1@nnrp1.dejanews.com>, dewar@gnat.com writes >This is typical of the kind of obfuscation that I find odd when it is used >in a desparate attempt to avoid a goto spelled G-O-T-O. > >A return *is* a goto statement, so is an exit statement. They are both >reasonably well disciplined goto statements, so this means they are neither >better nor worse than corresponding disciplined use of goto. but the arguement for not using 'goto' is that it is up to the programmer to get it right, and that they can send the flow of control anywhere. it is up to the compiler writer to get the 'return' to go to the right place and the language defines exactly where that should be. i'm sure that you're compilers got it right mr dewar ;-) -- Martin Dowie ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Martin Dowie @ 1998-08-24 0:00 ` Martin Dowie 1998-08-24 0:00 ` Mark A Biggar 1998-08-25 0:00 ` adam 1 sibling, 1 reply; 74+ messages in thread From: Martin Dowie @ 1998-08-24 0:00 UTC (permalink / raw) In article <$3XHNBAxSZ41Ew4G@dowie-cs.demon.co.uk>, Martin Dowie <martin@dowie-cs.demon.co.uk> writes >In article <6rnh8p$dno$1@nnrp1.dejanews.com>, dewar@gnat.com writes >>This is typical of the kind of obfuscation that I find odd when it is used >>in a desparate attempt to avoid a goto spelled G-O-T-O. >> >>A return *is* a goto statement, so is an exit statement. They are both >>reasonably well disciplined goto statements, so this means they are neither >>better nor worse than corresponding disciplined use of goto. > and all the "Jackson" fans will want to point out that there is no such thing as a 'goto' of data structures, but there are sequences, selections and iterations. -- Martin Dowie ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Martin Dowie @ 1998-08-24 0:00 ` Mark A Biggar 1998-08-25 0:00 ` Martin Dowie 0 siblings, 1 reply; 74+ messages in thread From: Mark A Biggar @ 1998-08-24 0:00 UTC (permalink / raw) Martin Dowie wrote: > In article <$3XHNBAxSZ41Ew4G@dowie-cs.demon.co.uk>, Martin Dowie > <martin@dowie-cs.demon.co.uk> writes > >In article <6rnh8p$dno$1@nnrp1.dejanews.com>, dewar@gnat.com writes > >>This is typical of the kind of obfuscation that I find odd when it is used > >>in a desparate attempt to avoid a goto spelled G-O-T-O. > >>A return *is* a goto statement, so is an exit statement. They are both > >>reasonably well disciplined goto statements, so this means they are neither > >>better nor worse than corresponding disciplined use of goto. > and all the "Jackson" fans will want to point out that there > is no such thing as a 'goto' of data structures, but there > are sequences, selections and iterations. Yes, there is, Pointers are the data structure equivelant of the goto statement. Multiple aliases can get you into worse trouble then goto's any day. At least a goto has an explisitly labeled target, while in most languages a variable with multiple aliaes has no marking what-so-ever. Note, that Ada is one of the few languages that requires such marking with the "aliased" keyword. -- Mark Biggar mark.a.biggar@lmco.com ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Mark A Biggar @ 1998-08-25 0:00 ` Martin Dowie 1998-08-25 0:00 ` Mark A Biggar 0 siblings, 1 reply; 74+ messages in thread From: Martin Dowie @ 1998-08-25 0:00 UTC (permalink / raw) In article <35E1E74D.AF98CE26@lmco.com>, Mark A Biggar <mark.a.biggar@lmco.com> writes >Yes, there is, Pointers are the data structure equivelant of the goto statement. >Multiple aliases can get you into worse trouble then goto's any day. >At least a goto has an explisitly labeled target, while in most languages >a variable with multiple aliaes has no marking what-so-ever. Note, that >Ada is one of the few languages that requires such marking with the >"aliased" keyword. but the data structures that 'jacksonites' refer to are the 'real world' ones eg. a report might consist of a title page, plus a contents page, plus an iteration of text pages plus an iteration of index pages. also, can't see who you equate a pointer to a goto. eg type ptr is access ...; type rec is record int:integer; my_ptr:ptr; end record; here, the point forms part of a sequence. the thing a pointer points to itself has a specific structure which can be descibed in terms of sequences, selections and iterations. i would have thought a better equivilant of a pointer would be a subprogram. anyway, suffice to say that 'jacksonites' tend to be the biggest 'goto-phobes' in any office. -- Martin Dowie ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-25 0:00 ` Martin Dowie @ 1998-08-25 0:00 ` Mark A Biggar 1998-08-26 0:00 ` Martin Dowie 0 siblings, 1 reply; 74+ messages in thread From: Mark A Biggar @ 1998-08-25 0:00 UTC (permalink / raw) Martin Dowie wrote: > In article <35E1E74D.AF98CE26@lmco.com>, Mark A Biggar > <mark.a.biggar@lmco.com> writes > >Yes, there is, Pointers are the data structure equivelant of the goto statement. > >Multiple aliases can get you into worse trouble then goto's any day. > >At least a goto has an explisitly labeled target, while in most languages > >a variable with multiple aliaes has no marking what-so-ever. Note, that > >Ada is one of the few languages that requires such marking with the > >"aliased" keyword. > but the data structures that 'jacksonites' refer to are > the 'real world' ones eg. a report might consist of > a title page, plus a contents page, plus an iteration > of text pages plus an iteration of index pages. Yes but even that description may contain what are efectively pointers, what do you think goes in the bibliography end the end of the document. And, what is a URL but a pointer. > also, can't see who you equate a pointer to a goto. eg > type ptr is access ...; > type rec is record > int:integer; > my_ptr:ptr; > end record; But, that's a controlled use of pointers, just like "return" and "exit" are controlled uses of "goto". It's cases like the following where pointers are like uncontrolled goto's: type ptr is access all integer; X: aliased integer; Y: ptr := X'ACCESS; or even worse Y: ptr := X'UNCHECKED_ACCESS; -- Mark Biggar mark.a.biggar@lmco.com > > here, the point forms part of a sequence. the thing > a pointer points to itself has a specific structure > which can be descibed in terms of sequences, selections > and iterations. i would have thought a better equivilant > of a pointer would be a subprogram. > > anyway, suffice to say that 'jacksonites' tend to be the > biggest 'goto-phobes' in any office. > -- > Martin Dowie ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-25 0:00 ` Mark A Biggar @ 1998-08-26 0:00 ` Martin Dowie 0 siblings, 0 replies; 74+ messages in thread From: Martin Dowie @ 1998-08-26 0:00 UTC (permalink / raw) In article <35E2FC29.954D706C@lmco.com>, Mark A Biggar <mark.a.biggar@lmco.com> writes >Martin Dowie wrote: >> but the data structures that 'jacksonites' refer to are >> the 'real world' ones eg. a report might consist of >> a title page, plus a contents page, plus an iteration >> of text pages plus an iteration of index pages. > >Yes but even that description may contain what are efectively pointers, >what do you think goes in the bibliography end the end of the document. >And, what is a URL but a pointer. a data structure for a biblography would be an iterations of one or more references, a reference in turn would be broken down, say in to a sequence of author plus title plus ISBN A URL is an iteration of characters, a broswer program to use this URL data structure would have an iteration of URLs as its input. "pointing" is a function, but the only data structures allowed for in JSP are sequence, selection and iteration, as jackson argues that these are the data structures found in the 'real world', and since or program design is meant to model this 'real world' he argues there is no place for a 'goto' in program design - how it's implemented is a different matter. -- Martin Dowie ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-24 0:00 ` Martin Dowie 1998-08-24 0:00 ` Martin Dowie @ 1998-08-25 0:00 ` adam 1 sibling, 0 replies; 74+ messages in thread From: adam @ 1998-08-25 0:00 UTC (permalink / raw) In article <$3XHNBAxSZ41Ew4G@dowie-cs.demon.co.uk>, Martin Dowie <martin@dowie-cs.demon.co.uk> wrote: > but the arguement for not using 'goto' is that it is up to the > programmer to get it right, and that they can send the flow of > control anywhere. > > it is up to the compiler writer to get the 'return' to go to the > right place and the language defines exactly where that should be. If this is a good argument against GOTO, it's an even better argument against using assignment statements, expressions, procedure calls, and any other language constructs that actually perform any work. After all, when you use an assignment statement, look at the number of things that the programmer could get wrong. They can mistype the variable name on the left side. If the right-hand side is an expression, they could get wrong any of the variables in the right side, or the operators, or the location of parentheses, etc. I've made all these mistakes many, many times. So is using a GOTO any worse? Is the chance of getting a GOTO wrong significantly greater than the chance of screwing something else up? I sure don't see it. The most likely error is that the programmer puts the label in the wrong place. But remember what the whole "return" thing was about: one programmer said that instead of for J in 1 .. N loop if condition 1 then ... if condition 2 then ... if condition 3 then goto Continue; he would extract the code into a subroutine and use "return" instead of "goto Continue". Well, if the programmer got the location of the label CONTINUE wrong, whether via a logic error or a typo, why is it any less likely that the programmer would get the "continue" location wrong when cutting-and-pasting the code he/she wants to extract into a subroutine? The arguments against GOTO seem to keep getting lamer and more disconnected from real programming experience. -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-22 0:00 ` dewar 1998-08-24 0:00 ` dennison 1998-08-24 0:00 ` Martin Dowie @ 1998-09-22 0:00 ` Charles H. Sampson 2 siblings, 0 replies; 74+ messages in thread From: Charles H. Sampson @ 1998-09-22 0:00 UTC (permalink / raw) <dewar@gnat.com> wrote: > ... > > A return *is* a goto statement, so is an exit statement. They are both > reasonably well disciplined goto statements, so this means they are neither > better nor worse than corresponding disciplined use of goto. > > ... O. k., I'll bite. In what sense are return statements and exit state- ments goto statements? The only commonalty I can see is that all three are in the class that used to be called "transfer of control" statements. Be- fore I comment further, I want to make sure I fully understand the claim. (Similar statements have been made by several people. I'm just picking on the guy that I consider best able to defend himself.) I got in very late on this thread, which is why I haven't participated before. I've found it very interesting, but it does tend to go on. I have a 31-day backlog of c.l.a posts and it's amazing how many of them are de- voted to this one thread. Charlie -- To get my correct email address, replace the "claveman" by "csampson" in my fake (anti-spam) address. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Larry Brasfield 1998-08-21 0:00 ` Jeffrey C. Dege @ 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` Bob Collins 2 siblings, 0 replies; 74+ messages in thread From: Ell @ 1998-08-21 0:00 UTC (permalink / raw) "Larry Brasfield" <larry_br@sea_net.com> wrote: >Ell wrote in message <35dfb9a8.4685477@news.erols.com>... >> >>ell@access.digex.net (Ell) wrote: >>> >>>I'm willing to use 'goto' in time critical code where inlines are not >>>possible, to save stack winding and unwinding. Other than that I'd >>>rather use a procedure call and returns to get back. >>And even then, I try to organize the code so that I invoke 'goto >>:labelX' and jump to its target ':labelX' **within** a single >>procedure/function/module. >>I try **never** to cross procedure/funtion/module boundaries with a >>'goto', when I use it for time critical code. >Is there any language in ordinary use that permits >a goto to cross a procedure boundary? If so, how >are goto target name scopes defined? I'm so into the aphorism that I've never even tried to cross function, or procedure boundaries in C, C++, or Pascal using 'goto :labelX'. >If not, why >make so much of trying to avoid such goto's? <g> Even within a function or procedure, things can get hairy. I think that in general within a function, or procedure, flow control should only be diverted by conditionals like 'if', 'case', or 'while/do'. And in general the most extreme flow control action by these conditionals should be 'return', or a procedure/function call. Elliott -- :=***=: Objective * Pre-code Modelling * Holistic :=***=: Hallmarks of the best SW Engineering "The domain object model is the foundation of OOD." Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell Copyright 1998 Elliott. exclusive of others' writing. may be copied without permission only in the comp.* usenet and bitnet groups. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-21 0:00 ` Larry Brasfield 1998-08-21 0:00 ` Jeffrey C. Dege 1998-08-21 0:00 ` Ell @ 1998-08-21 0:00 ` Bob Collins 2 siblings, 0 replies; 74+ messages in thread From: Bob Collins @ 1998-08-21 0:00 UTC (permalink / raw) In article <M34D1.9023$hr3.4288091@news.rdc1.bc.wave.home.com>, "Larry Brasfield" <larry_br@sea_net.com> wrote: > Is there any language in ordinary use that permits > a goto to cross a procedure boundary? If so, how > are goto target name scopes defined? If not, why > make so much of trying to avoid such goto's? <g> IIRC, Pascal (the CDC Pascal I used in the 70s and 80s), allowed gotos to any label in scope. In the main program, one could declare a label (mine was an emergency 666:) and then goto that label from any procedure or function inside the main program. I used that for emergency exits, when I ran out of storage or some such thing. Ada exceptions eliminated that goto need. I don't know about modern Pascal. -- Bob Collins <mailto:collins@cs.wm.edu> <http://ratbert.cs.wm.edu> ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-19 0:00 ` ell 1998-08-19 0:00 ` Charles Hixson 1998-08-19 0:00 ` adam @ 1998-08-20 0:00 ` Gerry Quinn 2 siblings, 0 replies; 74+ messages in thread From: Gerry Quinn @ 1998-08-20 0:00 UTC (permalink / raw) In article <6renh8$ga7$1@nnrp1.dejanews.com>, ell@access.digex.net wrote: > >A 'return', at least in C/C++/VB, returns you to the place the current >procedure was called from. 'goto' control flow can be endlessly channeled >here and there and never has to return to where the initial linear control >flow was originally diverted. That seems to be a huge advantage of 'return' >over 'goto'. > I never realised that! Who are these fiends who rechannel my gotos? - Gerry ---------------------------------------------------------- gerryq@indigo.ie (Gerry Quinn) ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-14 0:00 ` Software landmines (was: Why C++ is successful) dennison 1998-08-15 0:00 ` Thaddeus L. Olczyk 1998-08-16 0:00 ` Robert Dewar @ 1998-08-16 0:00 ` Jay Martin 1998-08-17 0:00 ` Robert Dewar 2 siblings, 1 reply; 74+ messages in thread From: Jay Martin @ 1998-08-16 0:00 UTC (permalink / raw) dennison@telepath.com wrote: > > In article <dewar.903074236@merv>, > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > Andy said > > > > <<Ahh... but have you ever found a "good" reason for using it? I have used > > goto in C and Pascal in certain rare cases, but I have always found clearer > > ways to code these cases in Ada. > > >> > > > > The two obvious uses vfor gotos in Ada are > > > > 1) to get a loop "continue" mechanism > > for a simple loop, embedding the rest of the loop code in the body of the if > statement is clearer. For nested loops where you want to "continue" an outer > loop, I can see it. Not that I'd do such a thing. As a "goto-holic" who has > been straight for 10 years, the best bet is abstinence. One day at a time. :-) > > > For example, I find the following perfectly clear: > > > > <<sort>> for J in 1 .. N - 1 loop > > if D (J) > D (J + 1) then > > Swap (D(J), D(J + 1)); > > goto Sort; > > end if; > > > > It is a little tricky to program this without the goto and not make it > > less clear. Actuallky many people who try this end up with a different > > algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort > :-) > > So the "average" poor maintainer schlep looks at this and thinks "is this > just a continue, or a complete restarting of the loop?" Oh yeah, that's > clear. %-( > > If anyone does something this bizzare, they'd better put copious comments > around it explaining its semantics. Otherwise, its the software equivalent of > a land mine. Its just sitting there waiting for someone to touch it, then > ...BOOM! > > Very good counterexample to your own point. Yup. I'll take my stab at what I think the algorithm is doing. I prefer flags and subroutines to gotos. inline void SwapFirstOutOfOrderElements(T D[], int N, bool& NoOutOfOrderElements) { NoOutOfOrderElements = true; for(int J = 0; J < (N-1); J++) { if (D[J] > D[J+1]) { Swap(D[J], D[J+1]); NoOutOfOrderElements = false; break; }//if// }//for// }//SwapFirstOutOfOrderElements// inline void SomeoneShootMeSort(T D[], int N) { bool NoOutOfOrderElements; do { SwapFirstOutOfOrderElements(D, N, NoOutOfOrderElements); } while (!NoOutOfOrderElements); } Heh, its probably got a bug some where in there and heh, do-while syntax sure sucks. The subroutine name is probably too short, maybe it should be "ScanFromTheFrontOfTheArrayAndSwapTheFirstTwoAdjacentOutOfOrderElements". No wait thats too short.... Maybe we should now go onto exponential time and random "highly probable to be sorted" sorts. Jay ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Software landmines (was: Why C++ is successful) 1998-08-16 0:00 ` Jay Martin @ 1998-08-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 74+ messages in thread From: Robert Dewar @ 1998-08-17 0:00 UTC (permalink / raw) May I suggest that if anyone else wants to post alternative solutions to my sorting statement, that they run them to at least make sure that they do in fact have the effect of sorting the data? If your algorithm does not sort, it is most certainly not equiavlent to what I wrote. Of course if it does sort, it still does not mean it is the same algorithm :-) ^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~1998-09-22 0:00 UTC | newest] Thread overview: 74+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-08-22 0:00 Software landmines (was: Why C++ is successful) dewar 1998-08-23 0:00 ` Dale Stanbrough 1998-08-23 0:00 ` dewar 1998-08-23 0:00 ` Andi Kleen 1998-08-24 0:00 ` Richard D Riehle 1998-08-25 0:00 ` dennison 1998-08-25 0:00 ` Andi Kleen 1998-08-25 0:00 ` Brian Rogoff 1998-08-28 0:00 ` Matthew Heaney 1998-08-28 0:00 ` Richard D Riehle 1998-08-29 0:00 ` Matthew Heaney 1998-08-29 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1998-09-07 0:00 ` Mats Weber 1998-09-07 0:00 ` dewarr 1998-09-08 0:00 ` Tucker Taft 1998-09-08 0:00 ` Precalculation of parameters (was: Software landmines) dennison 1998-09-09 0:00 ` Tucker Taft 1998-09-09 0:00 ` dennison 1998-09-10 0:00 ` Tucker Taft 1998-09-10 0:00 ` dewarr 1998-09-16 0:00 ` Software landmines (was: Why C++ is successful) Matthew Heaney [not found] ` <35eca5d9.4354839@news.geccs.gecm.com> 1998-09-01 0:00 ` Richard D Riehle -- strict thread matches above, loose matches on Subject: below -- 1998-08-06 0:00 Why C++ is successful Robert Dewar 1998-08-07 0:00 ` harald.mueller 1998-08-07 0:00 ` Brian Rogoff 1998-08-07 0:00 ` Timothy Welch 1998-08-08 0:00 ` Robert Dewar 1998-08-08 0:00 ` Jeffrey C. Dege 1998-08-10 0:00 ` Laurent GUERBY 1998-08-12 0:00 ` Andy Ward 1998-08-14 0:00 ` Robert Dewar 1998-08-14 0:00 ` Software landmines (was: Why C++ is successful) dennison 1998-08-15 0:00 ` Thaddeus L. Olczyk 1998-08-16 0:00 ` Robert Dewar 1998-08-17 0:00 ` dennison 1998-08-18 0:00 ` adam 1998-08-19 0:00 ` Tucker Taft 1998-08-19 0:00 ` adam 1998-08-19 0:00 ` ell 1998-08-19 0:00 ` Charles Hixson 1998-08-19 0:00 ` adam 1998-08-19 0:00 ` Dan Higdon 1998-08-20 0:00 ` adam 1998-08-20 0:00 ` Dan Higdon [not found] ` <m33eagru5g.fsf@mheaney.ni.net> 1998-08-31 0:00 ` Frank Adrian 1998-08-31 0:00 ` Robert I. Eachus 1998-08-31 0:00 ` Biju Thomas 1998-08-31 0:00 ` Robert Martin 1998-09-01 0:00 ` Martin Dowie 1998-09-01 0:00 ` Robert I. Eachus 1998-09-02 0:00 ` dennison 1998-09-01 0:00 ` dewarr 1998-09-06 0:00 ` Jonathan Guthrie 1998-08-20 0:00 ` Ell 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` John Goodsen 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` Larry Brasfield 1998-08-21 0:00 ` Jeffrey C. Dege 1998-08-20 0:00 ` Phlip 1998-08-21 0:00 ` Larry Brasfield [not found] ` <DOSXjHE9T6DM9Jw9nAyaPxfz@news.rdc1.bc.wave.home.com> 1998-08-22 0:00 ` dewar 1998-08-24 0:00 ` dennison 1998-08-28 0:00 ` Matthew Heaney 1998-08-28 0:00 ` dennison 1998-08-30 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1998-08-31 0:00 ` Robert I. Eachus 1998-08-24 0:00 ` Martin Dowie 1998-08-24 0:00 ` Martin Dowie 1998-08-24 0:00 ` Mark A Biggar 1998-08-25 0:00 ` Martin Dowie 1998-08-25 0:00 ` Mark A Biggar 1998-08-26 0:00 ` Martin Dowie 1998-08-25 0:00 ` adam 1998-09-22 0:00 ` Charles H. Sampson 1998-08-21 0:00 ` Ell 1998-08-21 0:00 ` Bob Collins 1998-08-20 0:00 ` Gerry Quinn 1998-08-16 0:00 ` Jay Martin 1998-08-17 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox