on goto
in [General Programming]
|
From: Nick Keighley on 12 May 2010 09:46 On 12 May, 12:44, Richard Heathfield <r...(a)see.sig.invalid> wrote: > Nick Keighley wrote: > > On 12 May, 03:00, pete <pfil...(a)mindspring.com> wrote: > > <snip> > > >> I find SEME to be less objectionable in functions > >> which are small enough so that you can't look at one exit > >> without noticing the all the rest of the exits. > > > is there any other sort of function? > > Hell yes! I once counted 11 pages (of blue stripey listing) between the "if" and it's corresponding "else". And that was 11 pages of dense and tangled code. I think it had gotos as well. Wish I'd framed it.
From: Richard Heathfield on 12 May 2010 10:14 gwowen wrote: > On May 12, 2:02 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > >> If you use the 3-D algorithm presented as an example in this thread to >> do the above, your an idiot. (Remember, the algorithm aborts when it >> finds *one* object that is the right value.) > <snip> > The actual return criteria are more complex in the > real life case, but the principal is the same. <snip> > Also, if you're going to say "your an idiot", you'll get a better > response if you learn the difference between "you're" and "your". Oh, > and the difference between "return" and "abort". If you're going to pick holes in people's spelling, you'll get a better response if you learn the difference between "principal" and "principle". You might also get a better response if you behaved a little more politely. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: wolfgang kern on 12 May 2010 08:37 Alexei A. Frounze explained the cause: <--q> "wolfgang kern" <nowh...(a)never.at> wrote: > Nathan Baker wrote: >>> Ok Nate, we had enough discussions on this matter since HLLs >>> entered our progamming world ... >>> We better give up arguing and let the 'faster' programmers >>> be proud of their 'maintainable/foolproof-readable' sources >>> which are awful detours with "abstraction layers" while the >>> few hardware freaks like me work on "really existing things" :) >> The CPU experiences a nightmare while executing HLL code. >> Perhaps there is an instructive way for us to demonstrate this fact? > Even we could try this one more time, I daubt that > 'fundamental' HLL-coders may listen at all. > The believe in their holy compilers seem to be very strong :) > I think demonstration of the bloated redundance isn't required, > disassemble whatsoever you find (windoze+lunix/app+sys) and > see as of immediate all the weird detours created by 'a tool'. > The few programmers who know both worlds may be aware and > create lesser bloated and faster code even with HLL. There are several reasons for what you call compiler-produced bloat: - copy-pasted code at the source level (can happen in asm too) - duplicate functionality and data in different parts of big applications (can happen in asm too) - overly complicated code (can happen in asm too) - dead code and data (can happen in asm too) - error handling code (you probably need it in asm too) - use of macros, inlining and templates (macros exist in asm too) - calling convention support code for interoperation, variable argument subroutines, exception handling and debugging (you may need or want some of them in asm too) - code alignment (you may need it in asm too) - inadequately chosen optimization switches or speed preference over size - global variables, including not tightly packed structures (you may want data alignment in asm too) So, some of it comes from bad or complex source code, some from the fact that applications are made from many different parts done independently by different people, some is dictated by the overall API design and some from how the compiler and linker are used. Then again, often times quickly making software is more important than making it fast or small or both. Depends on the business model, which you may be unable to change other than by quitting your employer and finding a "better" one or starting your own company or simply going self- employed. I'm just explaining how this bloat is possible and expected. Alex </--q> I fully agree with your notes, also ASM may use Libs and are often 'compiled' instead of designed. But even ASM may have to follow API calling conventions, we are free (in opposition to the poor C-coders) to avoid these 'oh so common' stack-copy-detours in our ASM-functions ... __ wolfgang
From: gwowen on 12 May 2010 11:10 On May 12, 3:14 pm, Richard Heathfield <r...(a)see.sig.invalid> wrote: > If you're going to pick holes in people's spelling, you'll get a better > response if you learn the difference between "principal" and > "principle". You might also get a better response if you behaved a > little more politely. Physician, heal thyself. Still baiting Nilges in comp.lang.c? Jesus must be so proud.
From: Richard Heathfield on 12 May 2010 12:54
gwowen wrote: > On May 12, 3:14 pm, Richard Heathfield <r...(a)see.sig.invalid> wrote: > >> If you're going to pick holes in people's spelling, you'll get a better >> response if you learn the difference between "principal" and >> "principle". You might also get a better response if you behaved a >> little more politely. > > Physician, heal thyself. Look more closely. Had you not criticised a spelling error, I would not have dreamed of criticising your misuse of "principle". > Still baiting Nilges in comp.lang.c? I think you must be reading a different comp.lang.c. > Jesus must be so proud. I think you'll find that the majority of posters in clc would prefer to avoid silly religious arguments. If you want to ignore that preference, that's up to you, but don't expect me to join in. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within |