Thread: Superprogram Edit

  1. #1
    Registered User
    Join Date
    Sep 2003

    Superprogram Edit

    I dont know; bloodshed wont run passed the second line its the new version;; its some crap; been trying to get on and download borland; but this dial-up crap is killing me.

    Help me people

  2. #2
    Registered User
    Join Date
    May 2003
    1) Don't repost. We all saw your problem the first time.

    2) Don't just post your code with 40-some mistakes and then expect people to fix it. If you want to pay me $35 an hour, with a minimum charge of 4 hours, I will debug your code. Otherwise, ask specific questions about specific errors, after researching the error yourself, and people will help you.

    3) How the hell did you write code and end up with that many errors? Write small segments and compile, write small segments and compile, etc. Don't just throw the whole damn thing down and then try to debug it. Especially not when you're new to the language.
    Last edited by Cat; 09-26-2003 at 10:08 AM.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  3. #3
    Grammar Police HybridM's Avatar
    Join Date
    Jan 2003
    If it fails to compile on one (reputable) compiler with 40+ errors, it's not going to compile on Borland either.
    Thor's self help tip:
    Maybe a neighbor is tossing leaf clippings on your lawn, looking at your woman, or harboring desires regarding your longboat. You enslave his children, set his house on fire. He shall not bother you again.

    OS: Windows XP
    Compiler: MSVC

  4. #4
    Registered User
    Join Date
    Sep 2003


    Sorrry for the repost; cant find a good compiler anywhere to download; but in any amount thanks for your help guys

  5. #5
    Registered User
    Join Date
    May 2003
    It's not the compiler's fault that your code is buggy. Fix the code, any compiler should be fine.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  6. #6
    Hardware Engineer
    Join Date
    Sep 2001

    Good advice!

    Killer Mike,

    Sorry, to reply without giving you any direct help. But, I'm at work, and I can only do this during "little breaks", and the computer that I'm at right now doesn't have a compiler, so I can't test-compile your code, and I can't test any specific suggestions either.

    Although Cat is being hard on you, he/she is giving you really excellent advice.

    It's difficult for anyone to debug a program with 40 errors.

    So, start out with a simple "Hello World" type program... maybe "Welcome to SuperProgram".

    Test Compile and test-run that. Add 1 or 2 lines of code and test-compile and test-run again, etc., etc., etc. When you write a function, write an empty function first, with a return line if the function is supposed to return something. At this point the function can return anything... Maybe "return 3 ;" That way, you can tell that your main function is calling the new function correctly.

    If you develop your program this way, you will know where any errors are... in the last few lines of code that you added.

    It is also useful to add extra cout statements during test/debug/development. You can display variables, results, return values, etc., to "see" what your program is doing.

    One program I wrote has a bunch of if(Debug) cout... statements. When Debug == 0, the program runs normally. When I change Debug to 1, it displays all of the variables. This is quite common, but it's usually done with pre-compiler directives, so your "normal" exe file doesn't include all of the extra debug shtuff.

    It takes some practice to learn to use these techniques. For example, you can't call a function that you haven't defined yet. You have to know what you can leave-out without adding errors. Once you learn to do this, programming gets a lot more fun! Or at least a lot less frustrating.

    ALL programmers write programs this way. NOBODY writes an entire program and then test-compiles and test-runs. Of course, as you gain experience, you will be able to test less frequently. It is good practice to test each function you write before moving on to the next thing, no mater how experienced you are!

    Compiler error messages can be misleading. Compilers are easily confused, and they don't know what you are trying to do. The first error message usually points to where the first error is... plus-or-minus one line. But, I've misplaced one little curly-brace, and the compiler reported hundreds of errors! This is really funny... when it happens to someone else!

    Linker error messages can be worse, because you loose the line-number references during the compile process.

    I just saw your other post. Please read the board hints & guidelines. There's some stuff in there about titles, cross-posting & bumping... it might prevent some future flaming!
    Last edited by DougDbug; 09-26-2003 at 07:29 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. (Multiline) Edit Control Limit
    By P4R4N01D in forum Windows Programming
    Replies: 9
    Last Post: 05-17-2008, 11:56 AM
  2. line number on a rich edit control
    By rakan in forum Windows Programming
    Replies: 1
    Last Post: 02-18-2008, 07:58 AM
  3. WS_HSCROLL in ES_READONLY edit box error
    By Homunculus in forum Windows Programming
    Replies: 4
    Last Post: 02-13-2006, 08:46 AM
  4. Multiline Edit Box Parser
    By The Brain in forum Windows Programming
    Replies: 6
    Last Post: 11-01-2005, 07:15 PM
  5. Replies: 3
    Last Post: 07-23-2005, 08:00 AM