• (cs) in reply to bit
    Anonymous:
    dubwai:

    So until someone can show me a code snippet that uses gotos and cannot be rewritten not to use them, I have to believe that gotos are never necessary.  I've not used a single one since I learned to program in basic.  I've never even desired to use them.  I don't even use labelled breaks.  Never wanted to.

    Oh, but anything can be rewritten in assembly, so every single high level construct (and thus every single programming language) is unnecessary.

    Is there a point here?

  • (cs) in reply to jtwine
    jtwine:

    dubwai:
    The thing about the 'gotos are sometimes necessary' argument is that Java doesn't allow gotos yet I've never heard of a single one of the thousands of Java projects failing for the want of a goto.

    And yet, no-one has written a high-performance OS in Java...!  [;)]

    Seriously, <FONT face="Courier New" size=2>goto</FONT>s are sometimes used in high-performance/RTOS kind of code, like kernels and drivers.  When dealing with an environment where each instruction counts (like small embedded systems), your outlook changes than when doing average desktop or server development.  Moreso when your outlook on enhancing performance is to just throw another blade in the server!

    Do you know for a fact that Java is slower than C?  In fact modern VMs have been shown to allocate and deallocate Objects faster than C++.  The main reason there are a lot of slow Java apps has a lot more to do with the designers/developers of those apps than Java.  This myth is perpetuated to a large degree by those same people.  "It's not my fault, Java is slow!"  I've written small applications to do regex searches of large files in Java that are on par, if not faster than egrep or the nt shell find command.  I didn't even try to do it in a sophisticated way.

    The other thing is there is nothing inherently slow in the concept of try/catch/finally.  It could simple unroll into the exact same goto code given here again and again.  The point I am making is that there are certain uses of gotos that are fine but there are a lot more that are not.  Istead of putting up a sign on the egde of a grand canyon observation deck that says "don't fall off" I think it's better to erect a guard rail.

  • (cs) in reply to dubwai
    dubwai:
    Do you know for a fact that Java is slower than C?


    I think that's a safe assumption.
  • (cs) in reply to Z
    Anonymous:
    dubwai:

    The thing about the 'gotos are sometimes necessary' argument is that Java doesn't allow gotos yet I've never heard of a single one of the thousands of Java projects failing for the want of a goto.



    Well, in Java programs people usually don't care about performance or well-structured control flow. (note: I think some uses of goto are good because they make the program easier to understand and reason about, and clearer programs are IMHO a Good Thing(tm))


    Are you suggesting that one uses gotos to create well structured control flow?  And I'll ask again for your proof that Java applications are slow.  Mine aren't.

    If there is a use of goto that has no formalized counterpart, please tell us what it is.

    Anonymous:
    dubwai:

    So until someone can show me a code snippet that uses gotos and cannot be rewritten not to use them, I have to believe that gotos are never necessary.  I've not used a single one since I learned to program in basic.  I've never even desired to use them.  I don't even use labelled breaks.  Never wanted to.



    For an enlightening discussion about possible valid uses of goto-statements, I would recommend the following article:

    		 <COLGROUP> <COL width="10%"> <COL width="1%"> <COL width="89%">
    Structured Programming with <ITALIC>go to</ITALIC> Statements
    Donald E. Knuth
    December 1974  
    ACM Computing Surveys (CSUR)<FONT size=-2>,  Volume 6 Issue 4 </FONT>


    It gives an overview of the common uses of goto, and the equivalent goto-less programs. One observation that is made (shown in other papers) is that one has to do more computation of use more variables if goto's are to be avoided.

    I can't access that but in any event, note that this was written 3 decades ago.  Was try/catch/finally even a formalized structure at the time?

  • (cs) in reply to Maurits

    Maurits:
    dubwai:
    Do you know for a fact that Java is slower than C?


    I think that's a safe assumption.

    Based upon what?

  • someone (unregistered)

    Everybody knows that you should never use "goto" statements. Well, except in one or two rare circumstances that you won't come across anyway. But even when you do come across those situations, they're usually "mirage cases" where there's no need to "goto" anyway.

    I just lost all respect for this place now.

  • (cs) in reply to Anonymous

    Anonymous:
    I always use COMEFROM statements instead of GOTO statements.

    You must be doing dynamic programming then.

  • (cs) in reply to dubwai
    dubwai:

    Maurits:
    dubwai:
    Do you know for a fact that Java is slower than C?


    I think that's a safe assumption.

    Based upon what?

    Highly scientific research

  • Masklinn (unregistered) in reply to dubwai
    dubwai:

    Maurits:
    dubwai:
    Do you know for a fact that Java is slower than C?


    I think that's a safe assumption.

    Based upon what?


    Just about every single comparison of both languages ever submitted to anyone?

    Oh, and the fact that the JVMs are more than likely written in C or C++ too for most of their components, last time I checked you could hardly go faster than the tools used to build you...
  • (cs) in reply to Masklinn
    Anonymous:
    dubwai:

    Maurits:
    dubwai:
    Do you know for a fact that Java is slower than C?


    I think that's a safe assumption.

    Based upon what?


    Just about every single comparison of both languages ever submitted to anyone?

    The above is just false.

    Anonymous:

    Oh, and the fact that the JVMs are more than likely written in C or C++ too for most of their components, last time I checked you could hardly go faster than the tools used to build you...

    That's a very oversimplified assesment.  The JVM might be written in C but it doesn't run in C.  It's a compiled program.  Java can now create and destroy Objects faster than C++ because of how it manages the heap.

    I could make all kinds of wild claims and not back them up with anything but who would care?  Maybe you should stop believing what you like to believe and actually gain some knowledge before spouting off.  You might want to look up JIT compilers.

  • Hank Miller (unregistered) in reply to dubwai
    dubwai:

    That's a very oversimplified assesment.  The JVM might be written in C but it doesn't run in C.  It's a compiled program.  Java can now create and destroy Objects faster than C++ because of how it manages the heap.


    True.  Java delays destroying objects until garbage collection, which can often wait until there is nothing else to do (waiting for user input, or a database).   Lack of pointers also means that objects can be moved around in memory, which if done intelligently can make things seem faster

    Of course if you count the overhead of garbage collection, (including moving objects) java needs more CPU, but that CPU can be moved to times when the computer is otherwise not busy, this is better from a user point of view.

    You pay for this though.   RAII does not work well in java because there is no way to be sure that an object is released  when you next try to get it.   Sometimes this matters, sometimes it does not.

    In many cases where java is faster, it is because the work is being done in a built in, which was optimized by experts, and generally written in C/C++.  Of course the JIT does an excellent job these days, which helps a lot.

    dubwai:

    I could make all kinds of wild claims and not back them up with anything but who would care?  Maybe you should stop believing what you like to believe and actually gain some knowledge before spouting off.  You might want to look up JIT compilers.



    No matter what you do in Java I can do it faster in C (assuming a good compiler, which may not exist).   However sometimes you can do things with nice code faster in java than C.  

    Of course I can get faster yet with hand optimized machine code (binary, not assembly!), but the work required to do this means that the code you can write in one week in Java will take a large team several years.  

    In nearly all cases programs are waiting on either disks or users, which are orders of magnitude slower than any particular language.   I write a lot of code in python which is slow by benchmarks, but is still fast enough for my application so I don't care.  

    Those arguing about which language is faster are looking at the wrong point.   CPUs are cheap, and much faster than users.   Programmer and user time is expensive.  So if you can deliver a program faster, and save users time, you save everyone money.   There are very few cases where spending extra time to save a few milliseconds adds up to be worth the effort.    There may however be tiny specific parts where spending a little extra time optimizing is worth the effort.

    You already knew that didn't you?   So why debate which is faster in general, when it doesn't matter.
  • James (unregistered) in reply to dubwai

    dubwai:
    Do you know for a fact that Java is slower than C?  In fact modern VMs have been shown to allocate and deallocate Objects faster than C++. 

    As with all things, it depends on how the features of a language are used/abused.  No matter how much heap management you have, I contend that allocating off of the stack in a C++ program, meaning an adjustment of the stack pointer, beats the hell out of any heap allocation.

    My last personal, direct experience with Java was more than 8 years ago.  Of course, some would correctly assume that technologies like HotSpot were created for a particular reason.  Any idea what that might be? 

    Maybe they addressed the performance issues in the "modern" VMs, which means there were/are performance issues in the first place, and maybe Java is best left on big hardware where seems to thrive now.

    Running on identical hardware, is Java more likely to run a poorly designed program that abuses dynamically allocated memory than C/C++?  Dunno.  Perhaps, but then so is the .Net platform.  Does not mean that either is faster overall.  I have seen many contrived examples that show one side faster than the other.  Your Java RegEx app .vs. someone else's code, or perhaps the Unreal engine implemented in Java .vs. its C++ implementation.  CRT .vs. Java VM startup times, etc.

    I have generally believed that the best measure of a language is what it is used for, and what it can be used for.  Yes, C/C++ can make some pretty good Java VMs, can Java?  I see plenty of high performance games (and their internal interpreters) written in C/C++.  What has Java contributed to high-performance-on-the-desktop recently that I might not have read about?

    Lastly, I understand the point of wanting to erect a "guard rail", but it is inappropriate to tie the hands of the experienced just because some newbies might hurt themselves.  Give them the information, and let them learn about the right and wrong ways to use something.

  • (cs) in reply to James

    Java is supposed to be easy to learn, and is almost becoming the new BASIC for introducing programmers, and from the way I've seen others pick it up I believe them, but as someone who learned C++ pretty darn well beforehand, I wanted nothing to do with it. Something about knowing propper manual pointer math makes Java's reference/not-a-reference behavior feel catastrophically backward. Then again, PHPs quasi-strong typing doesn't bother me a lick (possibly since PHP is a simple web scripting langauge that doesn't pretend to do anything more than web-scripting-like things, whereas people are claiming Java should be used for EVERYTHING). Who knows?

  • bit (unregistered) in reply to dubwai
    dubwai:

    Is there a point here?

    Yes, a purely logical one. You can't dismiss GOTOs simply because they can be rewritten another way, because any high level construct can be rewritten another way (more efficient). You have to show HOW these statements are worse than others in that respect. You haven't.

  • (cs) in reply to bit
    Anonymous:
    dubwai:

    Is there a point here?

    Yes, a purely logical one. You can't dismiss GOTOs simply because they can be rewritten another way, because any high level construct can be rewritten another way (more efficient). You have to show HOW these statements are worse than others in that respect. You haven't.

    I wasn't trying to show that.  I was arguing that they aren't necessary in modern high-level languages.  I don't feel motivated to back up points I haven't made.

  • (cs) in reply to Hank Miller
    Anonymous:

    True.  Java delays destroying objects until garbage collection, which can often wait until there is nothing else to do (waiting for user input, or a database).   Lack of pointers also means that objects can be moved around in memory, which if done intelligently can make things seem faster


    Actually I'm not talking about the delay.  I recently read an article on IBMs website about how the nature of generational heap allocation allows for more effecient allocation and deallocation of Objects in memory.  I can't remember exactly what the reason was.  If I can find the article I'll post a link.



    Those arguing about which language is faster are looking at the wrong point.   CPUs are cheap, and much faster than users.   Programmer and user time is expensive.  So if you can deliver a program faster, and save users time, you save everyone money.   There are very few cases where spending extra time to save a few milliseconds adds up to be worth the effort.    There may however be tiny specific parts where spending a little extra time optimizing is worth the effort.

    You already knew that didn't you?   So why debate which is faster in general, when it doesn't matter.

    It's also something that is pretty hard to define and benchmark.  Anyway. it pointless.

  • (cs) in reply to dubwai

    I'll just point out that I am not sayng that Java is for everything.  I just get tired of the 'Java is slow' comments.  It's just not true.  All the 'real programmers' (as in Mel) can waste their licves doing what compilers can do better for all I care.

  • (cs) in reply to P-Nuts

    Anonymous:
    However, one legitimate (if infrequent) use of goto is to get out of more than one nested loop, as break/continue only get you out of the first one:

    OUTER:
    for (int i=0; i<N; ++i) {
      for (int j=0; j<N; ++j) {
        // do stuff that might not need all the i,j combinations
        if (done) break OUTER;
      }
    }

    There you go.

  • Z (unregistered) in reply to dubwai
    dubwai:
    Z:
    dubwai:

    The thing about the 'gotos are sometimes necessary' argument is that Java doesn't allow gotos yet I've never heard of a single one of the thousands of Java projects failing for the want of a goto.



    Well, in Java programs people usually don't care about performance or well-structured control flow. (note: I think some uses of goto are good because they make the program easier to understand and reason about, and clearer programs are IMHO a Good Thing(tm))


    Are you suggesting that one uses gotos to create well structured control flow?  And I'll ask again for your proof that Java applications are slow.  Mine aren't.

    If there is a use of goto that has no formalized counterpart, please tell us what it is.


    I have not argued about the general efficiency of Java programs, just about the style of programs that is usually written in Java (i.e. programs where utmost speed is not of essence).

    To remove all goto's from a program, one must either do more computation or use more memory. This, however, may not be an interesting fact, depending on the type of program one writes.

    My point is that when goto's are used in well-structured ways, I don't find them ugly just because Dijkstra said so in '69 (at a time when they were horribly overused).

    dubwai:
    Z:
    dubwai:

    So until someone can show me a code snippet that uses gotos and cannot be rewritten not to use them, I have to believe that gotos are never necessary.  I've not used a single one since I learned to program in basic.  I've never even desired to use them.  I don't even use labelled breaks.  Never wanted to.



    For an enlightening discussion about possible valid uses of goto-statements, I would recommend the following article:

    		 <colgroup><col width="10%"><col width="1%"><col width="89%"></colgroup>
    Structured Programming with <italic>go to</italic> Statements
    Donald E. Knuth
    December 1974  
    ACM Computing Surveys (CSUR)<font size="-2">,  Volume 6 Issue 4 </font>


    It gives an overview of the common uses of goto, and the equivalent goto-less programs. One observation that is made (shown in other papers) is that one has to do more computation of use more variables if goto's are to be avoided.

    I can't access that but in any event, note that this was written 3 decades ago.  Was try/catch/finally even a formalized structure at the time?



    Oops, I didn't think about the accesibility problem. No, try-catch-finally was not in vogue then, but some structures that predate them (and are more structured) are discussed, such as Zahns event-indicators. On the other hand, is it really readable code when exceptions are used for method-local control flow in our standard imperative languages?* You'll have to convince me of that. The examples in the paper are som small, that they would hardly qualify for using exceptions.

    As for efficiency, maybe a SGC (Sufficiently Good Compiler) could reorganize the exceptions-based code so that it boils down to a simple goto, but I doubt it. For example, have you ever looked at the cr*p Java-compilers output? It's horrible.


    * Note: in a language such as Oz (www.mozart-oz.org), exceptions are used in many more circumstances than in normal imperative languages, but I guess we should keep the discussion to mainstream languages.
  • Z (unregistered) in reply to phelyan
    phelyan:

    Anonymous:
    However, one legitimate (if infrequent) use of goto is to get out of more than one nested loop, as break/continue only get you out of the first one:

    OUTER:
    for (int i=0; i<n ;="" ++i="" {="">
      for (int j=0; j<n ;="" ++j="" {="">
        // do stuff that might not need all the i,j combinations
        if (done) break OUTER;
      }
    }
    </n></n>

    There you go.



    Labelled breaks are not a feature of C/C++, so you can't resort to them (and I guess that Anonymous is talking about C/C++, since you don't have goto's in Java).
  • (cs) in reply to Z
    Anonymous:
    phelyan:

    Anonymous:
    However, one legitimate (if infrequent) use of goto is to get out of more than one nested loop, as break/continue only get you out of the first one:

    OUTER:
    for (int i=0; i<N {="" ++i="" ;="">
      for (int j=0; j<N {="" ;="" ++j="">
        // do stuff that might not need all the i,j combinations
        if (done) break OUTER;
      }
    }
    </N></N>

    There you go.



    Labelled breaks are not a feature of C/C++, so you can't resort to them (and I guess that Anonymous is talking about C/C++, since you don't have goto's in Java).

    Now, where was that thing I forgot in my post... Ah, here it is:

    [;)]

  • Zahlman (unregistered) in reply to loneprogrammer
    loneprogrammer:
    Anonymous:
    Although in C++ you would probably solve the problem with RAII. And personally, I've never run into a need for anything like this (which is always the common example) "in all my years".

    Your solution uses extra variables for no reason.  The goto code does the same thing, but with less memory.


    No, it does not (on both counts). I have the same res1 through res5 representing resources, and 'result' for the actual return value. Even if the goto code could be written without 'result', it would make no difference, because of "named return value optimization" (and a rather trivial case of it here) - the space is already allocated on the stack and won't be duplicated by a compiler that wasn't written by drunken college students at 3am.

    But really, we're talking about local variables, and not even a significant number of them. Even if it weren't the same - if <=24 bytes on the stack for something that doesn't recurse (or call anything else) matters, well, I don't know what to tell you :\

    The worst difference that could occur is in speed - and I would argue that a decent compiler could fix this too anyway - in the case where a resource allocation fails and the compiler is dumb, there could be a couple of unneeded checks for null-ness of the pointers. Oh teh nos!

    Maybe memory doesn't matter for your code, but sometimes it matters a lot.  That's why OS kernels are still written in C, even today!


    I don't believe that. I believe the decisions are driven mostly by dogma. (http://c2.com/cgi/wiki?OldRulesWithForgottenReasons) Hell, properly written C++ code provides more information to the compiler than C code can, affording more optimization opportunities.

    If you haven't personally needed to write code like that, then go ahead and don't use goto.  Just don't extrapolate from "you" to "everybody."


    Show me a *real* code sample and then we can talk.
  • Zahlman (unregistered) in reply to Maurits
    Maurits:
    dubwai:
    Do you know for a fact that Java is slower than C?


    I think that's a safe assumption.


    A highway is not faster than a gravel road. They are both motionless.

    Similarly programming languages.
  • BogusDude (unregistered) in reply to tobermory

    Quote user "Anonymous": Personally, I consider exceptions an ugly kludge, as bad as poorly used gotos. They're effectively a COMEFROM statement.

    <snip>

    void doSomethingRisky() {  allocateThreadResources();
     getFileLock();  doStuff();  unlockFile();  deallocateResources(); }

    If getFileLock throws an exception, the thread resources never get deallocated. If doStuff throws an exception, the file remains locked and the thread resources are never deallocated. And even if it's unlockFile that fails, you won't get the chance to deallocate those thread resources.

    <snip again>

    End Quote

    Once again, this should be re-written as: class ThreadResources { ThreadResources() { allocateThreadResources(); }

    virtual ~ThreadResources() { deallocateResources(); }

    Stuff GiveAccessToThreadResources() { return m_Stuff; // Alternatively you could wrap all // the operations on threadresources. I'm lazy } };

    class FileLock { /// ... omitted for brevity, see ThreadResources };

    void doSomethingRisky() { ThreadResources threadRes; FileLock fileLock (File);    doStuff(); }

    That way, there won't be any leaks no matter what exception gets thrown. Exception handling only works correctly when the code is Object Oriented. That means that RAII is correctly followed and that methods and functions are written with exception safety in mind.

    < NB: this forum software is hideous :P NNNNNNNB: Yes it is :)

  • Procyon (unregistered) in reply to Aristotle Pagaltzis

    class Resource {
      Resource *child;
      void *const data;
     
      Resource() : data(alloc_res1( ) {
        if(!data) throw BadAlloc();
      }

     public:
      Resource( unsigned count ) {
        child = --count ? &Resource( count ) : &Resource();
        if(!data = alloc_res2( child.getData() ) throw BadAlloc();
      }
     
      void *getData() {return data;}
    };

    // no gotos.  A bit more complex, but if this function becomes complex
    // we don't need to worry about the spaghetti code of deallocation.  Leaks are
    // impossible.  Notice that the function becomes trivial, as the reusable object controls
    // all the allocation and deallocation.
    int foo() {
      try {
        Resource r(5);
        return 0;
      } catch( const BadAlloc &e ) {
        return -1;
      }
    }

  • (cs) in reply to Aristotle Pagaltzis
    Aristotle Pagaltzis:
    int foo() {
        void * res1, * res2, * res3, * res4, * res5;
        int result = -1;

        res1 = alloc_res1();
        if( ! res1 ) goto leave;

        res2 = alloc_res2( res1 );
        if( ! res2 ) goto dealloc_res1;

        res3 = alloc_res2( res2 );
        if( ! res3 ) goto dealloc_res2;

        res4 = alloc_res2( res3 );
        if( ! res4 ) goto dealloc_res3;

        res5 = alloc_res2( res4 );
        if( ! res5 ) goto dealloc_res4;

        do_something( res5 );

        result = 0

        dealloc_res( res5 );

        delloc_res4:
        dealloc_res( res4 );

        delloc_res3:
        dealloc_res( res3 );

        delloc_res2:
        dealloc_res( res2 );

        delloc_res1:
        dealloc_res( res1 );

        leave:
        return result;
    }


    BLAH.  I've been drinking too :)

    Granted, not possible in C, but then again, there's alot of constructs that aren't possible in C that are in C++, but none vice-versa, which is why I don't use C.

    Take 2:
    class Resource {
      Resource *child;
      void *const data;
     
      Resource() : data(alloc_res1( ) {
        if(!data) throw BadAlloc();
      }

     public:
      Resource( unsigned count ) {
        child = --count ? &Resource( count ) : &Resource();
        if(!data = alloc_res2( child.getData() ) throw BadAlloc();
      }
     
      ~Resource() {
        if(data) dealloc_res(data);
      }

      void *getData() {return data;}
    };

    // no gotos.  A bit more complex, but if this function becomes complex
    // we don't need to worry about the spaghetti code of deallocation.  Leaks are
    // impossible.  Notice that the function becomes trivial, as the reusable object
    // controls all the allocation and deallocation.
    int foo() {
      try {
        Resource r(5);
        do_something(r.getData());
        return 0;
      } catch( const BadAlloc &e ) {
        return -1;
      }
    }
    														</td></tr></tbody></table></td></tr></tbody>

  • (cs) in reply to tobermory
    Anonymous:
    Personally, I consider exceptions an ugly kludge, as bad as poorly used gotos. They're effectively a COMEFROM statement.

    When you write code like this:
    try
    {
     doSomethingRisky();
    }
    catch( BorkedException b )
    {
     flagError();
    }
    you have no idea precisely what part of the code that may throw exceptions called by doSomethingRisky has triggered the flagError unless you have a unique exception for each failure. And even if you do, you end up with something every bit as nasty as directly calling gotos from the code under doSomethingRisky into labels in the position of the catch block.

    Everything you call from your function can potentially be an exit point, bypassing the function entirely. You want to clean up? Tough. Let's consider the doSomethingRisky() function in more depth.
    void doSomethingRisky()
    {
     allocateThreadResources();
     getFileLock();
     doStuff();
     unlockFile();
     deallocateResources();
    }
    If getFileLock throws an exception, the thread resources never get deallocated. If doStuff throws an exception, the file remains locked and the thread resources are never deallocated. And even if it's unlockFile that fails, you won't get the chance to deallocate those thread resources.

    Worse, if it fails, it fails invisibly. There is no indication in this function whether the errors are being handled at some higher level or not. Looking at that code doesn't tell you if there's error handling or not; it's quite possible that every failure has its own exception that cleans up appropriately, but it's not visible at this level.

    Personally I prefer error handling of the form:

    int errorCode = doSomethingRisky();
    switch( errorCode )
    {
    BAD_THING_ERROR:
     flagBadThingError();
     break;
    ...
    }

    Because error codes have to be visibly propagated up the function tree, you can tell at a glance whether a function has implemented error handling or not. If a function dies without achieving its aims, control returns to the function that called it and doesn't go to the exception code, and a simple test of the return value lets you know whether or not you have to clean up.

    But I'm not usually working with mission-critical code. If every function I was going to call had an unacceptable chance of failure and the need to clean up a heap of things after it, nesting conditionals to handle it this way would make the code hideous. Far better would be to adopt the Linux kernel modus operandi:

    int doSomethingRisky()
    {
     if(!allocateThreadResources())
     {
      goto threadAllocateFailure;
     }
     if(!getFileLock())
     {
      goto fileLockFailure;
     }
     doStuff();

    fileLockFailure:
     unlockFile();
    threadAllocateFailure:
     deallocateThreadResources();
    }

    Less code, no nesting and silly indentation, and probably the most transparent way of achieving that flow control possible. It's efficient from a low-level perspective, too.

    I hope this convinces some people at least that gotos have their place.

    NB: this forum software is hideous :P
     
    Excellent, tobermory.
     
    David
     
  • (cs) in reply to Z
    Anonymous:
    dubwai:
    Z:
    dubwai:

    The thing about the 'gotos are sometimes necessary' argument is that Java doesn't allow gotos yet I've never heard of a single one of the thousands of Java projects failing for the want of a goto.



    Well, in Java programs people usually don't care about performance or well-structured control flow. (note: I think some uses of goto are good because they make the program easier to understand and reason about, and clearer programs are IMHO a Good Thing(tm))


    Are you suggesting that one uses gotos to create well structured control flow?  And I'll ask again for your proof that Java applications are slow.  Mine aren't.

    If there is a use of goto that has no formalized counterpart, please tell us what it is.


    I have not argued about the general efficiency of Java programs, just about the style of programs that is usually written in Java (i.e. programs where utmost speed is not of essence).

    To remove all goto's from a program, one must either do more computation or use more memory. This, however, may not be an interesting fact, depending on the type of program one writes.


    I guess I'm not convinced that this is a law.  For example, a while loop is a replacement for a goto.  Does it take more memory or instructions to implement a while loop than the corresponding goto code?

    Given a well structured use of gotos, we can generally define a syntax that formalized that structure.  We can (hypothetically) compile that code into something that is completely equivalent to what the goto version compiles to.  How does that use more memory or instructions?

    Anonymous:

    My point is that when goto's are used in well-structured ways, I don't find them ugly just because Dijkstra said so in '69 (at a time when they were horribly overused).

    I don't either.  If goto is the best way to do something, then I have no problem with it. But in a language like C++, I have not seen any evidence that gotos are ever the best solution (assuming one can use try/catch/throw.

    Anonymous:

    [snip]

    Oops, I didn't think about the accesibility problem. No, try-catch-finally was not in vogue then, but some structures that predate them (and are more structured) are discussed, such as Zahns event-indicators. On the other hand, is it really readable code when exceptions are used for method-local control flow in our standard imperative languages?* You'll have to convince me of that. The examples in the paper are som small, that they would hardly qualify for using exceptions.

    As for efficiency, maybe a SGC (Sufficiently Good Compiler) could reorganize the exceptions-based code so that it boils down to a simple goto, but I doubt it. For example, have you ever looked at the cr*p Java-compilers output? It's horrible.


    * Note: in a language such as Oz (www.mozart-oz.org), exceptions are used in many more circumstances than in normal imperative languages, but I guess we should keep the discussion to mainstream languages.

    I'm not sure what you mean.  I find exceptions extremely intuitive.  Also, are you talking about the bytecodes that a Java compiler produces?  What's horrible about them?  It's pretty much like reading assembly.  Not something I think about much.

    The mantr of exceptions is that they should only be used when there are exceptional conditions.  That is, the time you spend in exception handing code should be a very small portion of the applications runtime.  For this reason Exceptions are loaded with heavyweight information.  And it's a good thing too.  That info has saved me a lot of time and the company I work for a lot of money.

  • Z (unregistered) in reply to dubwai
    dubwai:
    Z:

    I have not argued about the general efficiency of Java programs, just about the style of programs that is usually written in Java (i.e. programs where utmost speed is not of essence).

    To remove all goto's from a program, one must either do more computation or use more memory. This, however, may not be an interesting fact, depending on the type of program one writes.


    I guess I'm not convinced that this is a law.  For example, a while loop is a replacement for a goto.  Does it take more memory or instructions to implement a while loop than the corresponding goto code?

    Given a well structured use of gotos, we can generally define a syntax that formalized that structure.  We can (hypothetically) compile that code into something that is completely equivalent to what the goto version compiles to.  How does that use more memory or instructions?


    Of course we can always invent new statements, but I think that the langages that we use are rather static in that the structures for control-flow are pre-determined. For programs that onlöy use the standard control-flow structures (loops and conditional-blocks), it was proven in "Notes on avoiding 'go to' statements", Donald E. Knuth and Robert W. Floyd, INformation Processing Letters 1, February 1971, that in general, the removal of goto-statements cannot be done without using either more memory or doing more computation. This, however, may or may not be interesting to you, depending on the type of systejms you are interested in. And as always, we could hope for the Good Compiler to save us, but that is not likely, IMHO.

    dubwai:

    Z:

    [snip]
    No, try-catch-finally was not in vogue then, but some structures that predate them (and are more structured) are discussed, such as Zahns event-indicators. On the other hand, is it really readable code when exceptions are used for method-local control flow in our standard imperative languages?* You'll have to convince me of that. The examples in the paper are som small, that they would hardly qualify for using exceptions.

    As for efficiency, maybe a SGC (Sufficiently Good Compiler) could reorganize the exceptions-based code so that it boils down to a simple goto, but I doubt it. For example, have you ever looked at the cr*p Java-compilers output? It's horrible.


    * Note: in a language such as Oz (www.mozart-oz.org), exceptions are used in many more circumstances than in normal imperative languages, but I guess we should keep the discussion to mainstream languages.

    I'm not sure what you mean.  I find exceptions extremely intuitive.  Also, are you talking about the bytecodes that a Java compiler produces?  What's horrible about them?  It's pretty much like reading assembly.  Not something I think about much.

    The mantr of exceptions is that they should only be used when there are exceptional conditions.  That is, the time you spend in exception handing code should be a very small portion of the applications runtime.  For this reason Exceptions are loaded with heavyweight information.  And it's a good thing too.  That info has saved me a lot of time and the company I work for a lot of money.



    I don't find exceptions hard to understand (when they are not used in WTF-esque ways of course :-) ), but as you say, they are a heavyweight feature of mainstream languages. Therefore, I do not think that using exceptions for local control-flow (as has been done in this thread) is a good idea. In other languages, the designers of the language anticipate the use of exceptions for local control-flow, and the langage and compiler is targeted to handle those cases also, see for example Oz mentioned above.

    The bytecode issue: Java compilers are typically very very bad. They perform no optimizations at all, and reading the code one sees that there is not even a peephole optimizer in them (for non-compiler people: a peephole optimizer is the simplest for of optimizer used in compilers, and also one that is very important for the final result). For example, generated Java bytecode more often than not contains jumps to jumps, which naturally should be folded into one jump. Use javap and read some bytecode, it is entertaining :) Yeah, I know, "the JIT will take care of it" is the standard answer. But if it is VERY simple to fix at compile-time, why not do it?
  • (cs) in reply to Z

    Z:

    The bytecode issue: Java compilers are typically very very bad. They perform no optimizations at all, and reading the code one sees that there is not even a peephole optimizer in them (for non-compiler people: a peephole optimizer is the simplest for of optimizer used in compilers, and also one that is very important for the final result). For example, generated Java bytecode more often than not contains jumps to jumps, which naturally should be folded into one jump. Use javap and read some bytecode, it is entertaining :) Yeah, I know, "the JIT will take care of it" is the standard answer. But if it is VERY simple to fix at compile-time, why not do it?

    I've looked at the bytecodes with javap and I don't see what you are referring to.  Are you talking about old versions (1.2 and lower?)  My understanding is that javac does a lot of optimization.  Also at runtime, it is optimized even further by inlining methods that are called often and loop unrolling (I think).  My understanding is that the main purpose of JIT is compile natively for the platform.

  • Wind (unregistered) in reply to swanage
    swanage:
    As astutely pointed out earlier, the goto with the continue doesn't re-evaluate the condition of the loop, whereas 'continue;' would. For example, consider get(), if you evaluate it second time, you'll read the next character from standard input. With the goto construct you won't advance your position in the stream, with 'continue;' you do.


    You made a valid point. But I still don't understand why one would need 'goto' in the original poster's situtation.
    You just add one more loop then the problem is solved, with more precise logic presented by the code itself. (add a 'while (true)' immediately after first 'while')
    while( sysmgr->getProcessCount() != 0 )
    {
      while (1)
      {
         .
         .
         .
         /* change all 'goto' to 'continue' */
         .
         .
         .
         sysmgr->CloseCurrentProcess();

         break;
      }
    }

  • Wes Landaker (unregistered) in reply to Aristotle Pagaltzis

    Ignoring that this code looks like it's doing something an incredibly wrong way and is just begging for better data structures, here is an easy way to get rid of the goto while keeping it "pretty".

    int foo() {
    void * res1 = 0;
    void * res2 = 0;
    void * res3 = 0;
    void * res4 = 0;
    void * res5 = 0;
    int result = -1;

    res1 = alloc_res1();
    if( res1 ) res2 = alloc_res2( res1 );
    if( res2 ) res3 = alloc_res2( res2 );
    if( res3 ) res4 = alloc_res2( res3 );
    if( res4 ) res5 = alloc_res2( res4 );

    if (res1 && res2 && res3 && res4 && res5) {
      result = 0
      do_something( res5 );
    }
  
    if (res5) dealloc_res( res5 );
    if (res4) dealloc_res( res4 );
    if (res3) dealloc_res( res4 );
    if (res2) dealloc_res( res4 );
    if (res1) dealloc_res( res4 );

    return result;
}
  • (cs) in reply to Aristotle Pagaltzis

    Aristotle Pagaltzis:
    Procedural mindset? What else would you use in C? Sure, I’ve never needed a GOTO in Perl either.

    OO is just a formalization of good procedural code.  At runtime, it works just like procedural code does.  There's nothing magical about it.

  • (cs) in reply to dubwai

    OO is just a formalization of good procedural code.

    Indeed. C can be just as OO as any other language, it's just not as easy to do. Generally speaking, if OO has been done in a given piece of C code, the chances are it's been done by someone who knows what they are doing, and it won't be as WTF-loaded as the average bit of VB.

    Simon

  • (cs) in reply to Z
    Z:

    Of course we can always invent new statements, but I think that the langages that we use are rather static in that the structures for control-flow are pre-determined.

    And my point is that I don't know of any useful constructs that are not formalized by modern languages.  I am not talking about languages were there are missing structures such as exceptions.

    Z:

    For programs that onlöy use the standard control-flow structures (loops and conditional-blocks), it was proven in "Notes on avoiding 'go to' statements", Donald E. Knuth and Robert W. Floyd, INformation Processing Letters 1, February 1971, that in general, the removal of goto-statements cannot be done without using either more memory or doing more computation. This, however, may or may not be interesting to you, depending on the type of systems you are interested in. And as always, we could hope for the Good Compiler to save us, but that is not likely, IMHO.

    If you don't trust compilers, why use them?  Just use machine code.

  • Keith (unregistered)

    I'm puzzled as to why nobody's notice one feature of the code that at least qualifies as a "Jeeze": the programmer keeps on using sysmgr->CurrentProcess() rather than calling it once and leaving it at that. Here's how I'd fix things.

    while (sysmgr->getProcessCount() != 0)
{
    crntProcess = sysmgr->CurrentProcess();

    // Inactivation is not guaranteed and may take up to 3 calls.
    crntProcess->TryInactivate();

    if (crntProcess->IsActive())
    {
        Sleep(DEFAULT_TIMEOUT);
    }
    else
    {
        /* ED: Snip */

        // disconnect child processes
        if (crntProcess->HasChildProcesses())
        {
            /* ED: Snip */
        }

        /* ED: Snip */
   
        if (crntProcess->IsReusable())
        {
            sysmgr->ReuseCurrentProcess();
        }
        else
        {
            sysmgr->CloseCurrentProcess();
        }
    }
}

    Much clearer. Mind you, asides from the ill-advised, but forgivable use of goto, using the name TryInactivate—assuming there's a good reason why they wouldn't automatically deactivate—as a method name (why not TryDeactivate?), and not leaving in an obvious repeating pattern in the code, it's not all that bad.

    And to those who are saying exceptions ought to be used, this might be a time-critical piece of code and exceptions tend to be slow, so the use of exceptions wouldn't be a good idea here, especially seeing as this appears to be code from a real-time or embedded operating system.

  • Bytecodes is not codebytes (unregistered) in reply to dubwai

    Okay, I have a code snippet I use pretty often in my Applications I develope. It is a simple function and I prefer using GOTO operands for speed and clarity. I would be VERY happy if you replied this post with equivalent code in Java, have it readable, and have it execute faster than my C code, or anyway near. If you do that I will will present a more complex function for you. When you have replied with equivalent code in Java then I will transform into a Java-developer and will never touch any other language again.

    Okay, here is your tasks, the simple one:    (I present the complex one for you if you are interested enough, first off you have to translate this one)

    Suggested Tasklist:

    Task #:   Task (difficulty level)

    1:   Try see the logic so you can translate it to Java. (Quite cumbersome)

    2:   Write same code in Java (Very difficult)

    3:   Have it execute faster than my C code (Impossible)

     

    Here comes the simple small codesnippet:

    (Sidenote: The importance here is not the speed of _rotl() functions or math simplifications, but the advantage GOTO statement can have against While, If, for and so on in some situations)

    void randomfunction(int v)
    {
    

     //  .. superior secret function with superior code, but not relevant  
     
    };
    

    int function1(int arg1)
    {
     int c;
     int lv = _rotl(arg1, 4);
     
     START:
      c--;
      if(lv>600) goto OP4;
    

     OP1:
      c++;
      lv += _rotr(lv, arg1) / 1.5;
      if (lv < _rotl(arg1,1)) goto OP3;
    

     OP2:
      c++;
      _rotl(arg1,4);
      if ( (lv/4) > arg1) goto OP5;
      c--;
      
     OP3:
      c++;
      arg1++;
      if (c>10) goto OP8;
      if (lv>c) goto OP6;
      randomfunction(c);
      
     OP4:
      c--;
      arg1 += 10;
      lv -= 10;
      if(lv > arg1) goto OP1;
      randomfunction(lv);
    

     OP5:
      c++;
      lv = arg1 * lv;
      if (arg1 < lv) goto START;
      randomfunction(arg1);
    

     OP6:
      c++;
      if (lv>10) goto OP3;
      if (lv<500) goto OP2;
      if (lv==666 goto OP8:
    

     OP7:
      c--
      lv++;
      arg1+=lv;
      if(((lv/101) % 100) < arg1) goto OP2;
      
     OP8:
      c--
      lv -= arg1;
      if (lv>50) goto OP3;
      c++;
     
     OP9:
      c++;
      if(c==42) goto START;
      lv = _rotr(arg1, c);
     
     OP10:
      c -= lv;
      if(c!=42) goto OP7;
      
     return arg1;
    };
     
    Good luck!
  • Bytecodes is not codebytes (unregistered) in reply to Bytecodes is not codebytes

    Oh btw, my previous post above ^^ was a reply to dubwai and his comments about Java is not slow and that he has never seen code where GOTO's is neccessary.

    And ofcourse, if I had the skill and time, I could code a JIT/Java/AI/Superior/Multicomplex compiler in C and have it read, compile and execute Java source code faster than current Java-versions itselfs. Is that the proof of C being faster than Java?

  • Bytecodes is not codebytes (unregistered) in reply to Bytecodes is not codebytes

    Oh btw, do not claim a simple database like situation where amount calls to randomfunction is the data in a table with arg1. The reason this doesn't work is that this function will at majority of arguments end up in endless loops. The size of a speedoptimized precalculated database will be huge and defeats the task big time.

    I really think a java-version of above one is possible, I am really looking forward to post the complex one.

  • (cs) in reply to Bytecodes is not codebytes
    Anonymous:

    Oh btw, do not claim a simple database like situation where amount calls to randomfunction is the data in a table with arg1. The reason this doesn't work is that this function will at majority of arguments end up in endless loops. The size of a speedoptimized precalculated database will be huge and defeats the task big time.

    I really think a java-version of above one is possible, I am really looking forward to post the complex one.

    yawn...  Without explaining the state pattern I'll just give the naive implementation.

        private static final int START = 0;
        private static final int OP1 = 1;
        private static final int OP2 = 2;
        private static final int OP3 = 3;
        private static final int OP4 = 4;
        private static final int OP5 = 5;
        private static final int OP6 = 6;
        private static final int OP7 = 7;
        private static final int OP8 = 8;
        private static final int OP9 = 9;
        private static final int OP10 = 10;

        int function1(int arg1)
        {
            int c = 0;
            int lv = _rotl(arg1, 4);
            int go_to = START;
           
            while (go_to >= 0) {
                switch (go_to) {
                    case START:
                        c--;
                        if(lv>600) {
                            go_to = OP4;
                            break;
                        }
                       
                    case OP1:
                        c++;
                        lv += _rotr(lv, arg1) / 1.5;
                        if (lv < _rotl(arg1,1)) {
                            go_to = OP3;
                            break;
                        }
                       
                    case OP2:
                        c++;
                        _rotl(arg1,4);
                        if ( (lv/4) > arg1) {
                            go_to = OP5;
                            break;
                        }
                        c--;
                       
                    case OP3:
                        c++;
                        arg1++;
                        if (c>10) {
                            go_to = OP8;
                            break;
                        }
                        if (lv>c) {
                            go_to = OP6;
                            break;
                        }
                        randomfunction(c);
                       
                    case OP4:
                        c--;
                        arg1 += 10;
                        lv -= 10;
                        if(lv > arg1) {
                            go_to = OP1;
                            break;
                        }
                        randomfunction(lv);
                       
                    case OP5:
                        c++;
                        lv = arg1 * lv;
                        if (arg1 < lv) {
                            go_to = START;
                            break;
                        }
                        randomfunction(arg1);
                       
                    case OP6:
                        c++;
                        if (lv>10) {
                            go_to = OP3;
                            break;
                        }
                        if (lv<500) {
                            go_to = OP2;
                            break;
                        }
                        if (lv==666) {
                            go_to = OP8;
                                break;
                        }
                       
                    case OP7:
                        c--;
                        lv++;
                        arg1+=lv;
                        if(((lv/101) % 100) < arg1) {
                            go_to = OP2;
                            break;
                        }
                       
                    case OP8:
                        c--;
                        lv -= arg1;
                        if (lv>50) {
                            go_to = OP3;
                            break;
                        }
                        c++;
                       
                    case OP9:
                        c++;
                        if(c==42) {
                            go_to = START;
                            break;
                        }
                        lv = _rotr(arg1, c);
                       
                    case OP10:
                        c -= lv;
                        if(c!=42) {
                            go_to = OP7;
                            break;
                        }
                       
                        return arg1;
                   
                    default:
                        go_to = -1;
                        break;
                }
            }
           
            return -1;
        }

  • (cs) in reply to Bytecodes is not codebytes
    Anonymous:

    And ofcourse, if I had the skill and time, I could code a JIT/Java/AI/Superior/Multicomplex compiler in C and have it read, compile and execute Java source code faster than current Java-versions itselfs. Is that the proof of C being faster than Java?

    No.  I'm not sure you understand what the word 'proof' means.  Furthermore, Java compilers and JVMs have already been written C so I'm not sure what your point is.

  • Bytecodes is not codebytes (unregistered) in reply to dubwai

    My point was that Java compilers and JVMs can't be absolutely optimally coded, therefor there is always a way to code a more optimally version. I may call it CoffeVM and it is better than any existing Java compilers and JVMs. The fact itself proves that Java is not faster than C. Java is created using C, and Java is not optimal, it can't be.

    Anyway here comes a more complex codesnippet for you to translate:

    (Concentrate on speed and readability)

     

    int randomfunction(int v)
    {
     
     //  .. superior secret function with superior code, but not relevant  
     
     return v;
    };
    


    #define FL(v)  for( (v) = 0; (v) < arg1; (v) += lv) 
    

    int function1(int arg1)
    {
     int c,i,j,k,l,m,n,o,p,q,r,s;
     c=i=j=k=l=m=n=o=p=q=r=s=0;
     int lv = _rotl(arg1, 4);
     
     START: FL(i) if (lv-- > 600*c+randomfunction(c)+c++)                  goto OP4; else
     OP1: FL(j) if (lv+=6 < _rotl(arg1,1)-c++)                             goto OP3; else
     OP2: FL(k) if ( (lv += _rotr(lv, arg1) / 1.5 /4) > arg1)              goto OP5; else
     OP3: FL(l) if (c>10*arg1+c++)                                         goto OP8; else
     OP4: FL(m) if (lv > arg1-c--)                                         goto OP6; else
     OP5: FL(n) if (arg1 < lv+c++)                                         goto START; else
     OP6: FL(o) if ((lv += _rotr(lv, arg1)) / 1.5 > randomfunction(lv))    goto OP9; else
     OP7: FL(p) if (lv<500*arg1-c--)                                       goto OP2; else
     OP8: FL(q) if (lv>50*arg1+randomfunction(c))                          goto OP3; else
     OP9: FL(r) if (c += c++ + arg1*10 == 42)                              goto START; else
     OP10: FL(s) if (c+(arg1+=lv/2)+(lv+=arg1*4)!=42)                      goto START;
     
     return arg1;
    };
    

     
  • (cs) in reply to Bytecodes is not codebytes
    Anonymous:

    My point was that Java compilers and JVMs can't be absolutely optimally coded, therefor there is always a way to code a more optimally version. I may call it CoffeVM and it is better than any existing Java compilers and JVMs. The fact itself proves that Java is not faster than C. Java is created using C, and Java is not optimal, it can't be.

    Anyway here comes a more complex codesnippet for you to translate:

    (Concentrate on speed and readability)

     

    int randomfunction(int v)
    {
     
     //  .. superior secret function with superior code, but not relevant  
     
     return v;
    };
    


    #define FL(v)  for( (v) = 0; (v) < arg1; (v) += lv) 
    

    int function1(int arg1)
    {
     int c,i,j,k,l,m,n,o,p,q,r,s;
     c=i=j=k=l=m=n=o=p=q=r=s=0;
     int lv = _rotl(arg1, 4);
     
     START: FL(i) if (lv-- > 600*c+randomfunction(c)+c++)                  goto OP4; else
     OP1: FL(j) if (lv+=6 < _rotl(arg1,1)-c++)                             goto OP3; else
     OP2: FL(k) if ( (lv += _rotr(lv, arg1) / 1.5 /4) > arg1)              goto OP5; else
     OP3: FL(l) if (c>10*arg1+c++)                                         goto OP8; else
     OP4: FL(m) if (lv > arg1-c--)                                         goto OP6; else
     OP5: FL(n) if (arg1 < lv+c++)                                         goto START; else
     OP6: FL(o) if ((lv += _rotr(lv, arg1)) / 1.5 > randomfunction(lv))    goto OP9; else
     OP7: FL(p) if (lv<500*arg1-c--)                                       goto OP2; else
     OP8: FL(q) if (lv>50*arg1+randomfunction(c))                          goto OP3; else
     OP9: FL(r) if (c += c++ + arg1*10 == 42)                              goto START; else
     OP10: FL(s) if (c+(arg1+=lv/2)+(lv+=arg1*4)!=42)                      goto START;
     
     return arg1;
    };
    

     

    Um, this contains define statements.  What exactly does that have to do with goto?  Also, you don't think that putting multiple statements on a single line makes them faster, do you?

  • (cs) in reply to Bytecodes is not codebytes
    Anonymous:

    My point was that Java compilers and JVMs can't be absolutely optimally coded, therefor there is always a way to code a more optimally version. I may call it CoffeVM and it is better than any existing Java compilers and JVMs. The fact itself proves that Java is not faster than C. Java is created using C, and Java is not optimal, it can't be.

    Apparently 'fact' is another word you are not really understanding.  Why can't a JVM be optimally coded?  Why can't something writen in C be as fast as something written in C?

  • Bytecodes is not codebytes (unregistered) in reply to dubwai
    [image] Anonymous wrote:

    My point was that Java compilers and JVMs can't be absolutely optimally coded, therefor there is always a way to code a more optimally version. I may call it CoffeVM and it is better than any existing Java compilers and JVMs. The fact itself proves that Java is not faster than C. Java is created using C, and Java is not optimal, it can't be.

    Anyway here comes a more complex codesnippet for you to translate:

    (Concentrate on speed and readability)

     

    int randomfunction(int v)
    {
     
     //  .. superior secret function with superior code, but not relevant  
     
     return v;
    };
    


    #define FL(v)  for( (v) = 0; (v) < arg1; (v) += lv) 
    

    int function1(int arg1)
    {
     int c,i,j,k,l,m,n,o,p,q,r,s;
     c=i=j=k=l=m=n=o=p=q=r=s=0;
     int lv = _rotl(arg1, 4);
     
     START: FL(i) if (lv-- > 600*c+randomfunction(c)+c++)                  goto OP4; else
     OP1: FL(j) if (lv+=6 < _rotl(arg1,1)-c++)                             goto OP3; else
     OP2: FL(k) if ( (lv += _rotr(lv, arg1) / 1.5 /4) > arg1)              goto OP5; else
     OP3: FL(l) if (c>10*arg1+c++)                                         goto OP8; else
     OP4: FL(m) if (lv > arg1-c--)                                         goto OP6; else
     OP5: FL(n) if (arg1 < lv+c++)                                         goto START; else
     OP6: FL(o) if ((lv += _rotr(lv, arg1)) / 1.5 > randomfunction(lv))    goto OP9; else
     OP7: FL(p) if (lv<500*arg1-c--)                                       goto OP2; else
     OP8: FL(q) if (lv>50*arg1+randomfunction(c))                          goto OP3; else
     OP9: FL(r) if (c += c++ + arg1*10 == 42)                              goto START; else
     OP10: FL(s) if (c+(arg1+=lv/2)+(lv+=arg1*4)!=42)                      goto START;
     
     return arg1;
    };
    

     

                

             Um, this contains define statements.  What exactly does that have to do with goto?  Also, you don't think that putting multiple statements on       a single line makes them faster, do you?

     

    True, the define statement is there so I can nest the goto's within the if statements within the loops where everything is related to each other. Thats the true benefit of the GOTO-command. The define stuff is created to easy the reading up for you, to get my code readable. Putting multiple statements on a single line is not making anything faster, just contributing in readability. But my codesnippet is quite optimized for the task, executiontime, not talking about amount of lines of code here.

  • Bytecodes is not codebytes (unregistered) in reply to dubwai
     

    Apparently 'fact' is another word you are not really understanding.  Why can't a JVM be optimally coded?  Why can't something writen in C be as fast as something written in C?

    ------

    Claiming Java is the ultimate language and it is optimally designed in all ways is silly.

  • (cs) in reply to Bytecodes is not codebytes
    Anonymous:

    Anyway here comes a more complex codesnippet for you to translate:

    (Concentrate on speed and readability)

     

    int randomfunction(int v)
    {
     
     //  .. superior secret function with superior code, but not relevant  
     
     return v;
    };
    


    #define FL(v)  for( (v) = 0; (v) < arg1; (v) += lv) 
    

    int function1(int arg1)
    {
     int c,i,j,k,l,m,n,o,p,q,r,s;
     c=i=j=k=l=m=n=o=p=q=r=s=0;
     int lv = _rotl(arg1, 4);
     
     START: FL(i) if (lv-- > 600*c+randomfunction(c)+c++)                  goto OP4; else
     OP1: FL(j) if (lv+=6 < _rotl(arg1,1)-c++)                             goto OP3; else
     OP2: FL(k) if ( (lv += _rotr(lv, arg1) / 1.5 /4) > arg1)              goto OP5; else
     OP3: FL(l) if (c>10*arg1+c++)                                         goto OP8; else
     OP4: FL(m) if (lv > arg1-c--)                                         goto OP6; else
     OP5: FL(n) if (arg1 < lv+c++)                                         goto START; else
     OP6: FL(o) if ((lv += _rotr(lv, arg1)) / 1.5 > randomfunction(lv))    goto OP9; else
     OP7: FL(p) if (lv<500*arg1-c--)                                       goto OP2; else
     OP8: FL(q) if (lv>50*arg1+randomfunction(c))                          goto OP3; else
     OP9: FL(r) if (c += c++ + arg1*10 == 42)                              goto START; else
     OP10: FL(s) if (c+(arg1+=lv/2)+(lv+=arg1*4)!=42)                      goto START;
     
     return arg1;
    };
    

     

    It's been a while (coming up on a decade) since I coded any C, but I believe what you have here is equivalent to:

    int function1(int arg1)
    {
     int c,i,j,k,l,m,n,o,p,q,r,s;
     c=i=j=k=l=m=n=o=p=q=r=s=0;
     int lv = _rotl(arg1, 4);
     
     START: FL(i) if (lv-- > 600*c+randomfunction(c)+c++)                  goto OP4;
     OP1: FL(j) if (lv+=6 < _rotl(arg1,1)-c++)                             goto OP3;
     OP2: FL(k) if ( (lv += _rotr(lv, arg1) / 1.5 /4) > arg1)              goto OP5;
     OP3: FL(l) if (c>10*arg1+c++)                                         goto OP8;
     OP4: FL(m) if (lv > arg1-c--)                                         goto OP6;
     OP5: FL(n) if (arg1 < lv+c++)                                         goto START;
     OP6: FL(o) if ((lv += _rotr(lv, arg1)) / 1.5 > randomfunction(lv))    goto OP9;
     OP7: FL(p) if (lv<500*arg1-c--)                                       goto OP2;
     OP8: FL(q) if (lv>50*arg1+randomfunction(c))                          goto OP3;
     OP9: FL(r) if (c += c++ + arg1*10 == 42)                              goto START;
     OP10: FL(s) if (c+(arg1+=lv/2)+(lv+=arg1*4)!=42)                      goto START;
     
     return arg1;
    };

    code of this form has already been shown to have a trivial transation.

    If not, please format the code in a non-jackass way.  I really hope you are purposely obfusctating because you think it will mess me up and that you don't actually think this is good code.

  • (cs) in reply to Bytecodes is not codebytes
    Anonymous:
     

    Apparently 'fact' is another word you are not really understanding.  Why can't a JVM be optimally coded?  Why can't something writen in C be as fast as something written in C?

    ------

    Claiming Java is the ultimate language and it is optimally designed in all ways is silly.

    OK, why are you telling me that?  You seem to be claiming that C is the ultimate language and it is optimally designed in all ways.  So maybe you should talk to yourself about that.

  • (cs) in reply to Bytecodes is not codebytes

    Out of curiosity, what kind of application would this code be for anyway?

  • Bytecodes is not codebytes (unregistered) in reply to dubwai

    START: FL(i) if (lv-- > 600*c+randomfunction(c)+c++)                  goto OP4; else
     OP1: FL(j) if (lv+=6 < _rotl(arg1,1)-c++)                             goto OP3;

    is absolutely not equivalent to

    START: FL(i) if (lv-- > 600*c+randomfunction(c)+c++)                  goto OP4;
     OP1: FL(j) if (lv+=6 < _rotl(arg1,1)-c++)                             goto OP3;

    In your example the second line is not nested whitin the first.

    The code IS really real code, written in a way to NOT obfuscate. Try see what my point is, goto's within nested loops is necessary. I am still waiting for the translated version.

Leave a comment on “When It's OK To GOTO”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article