Thread: Character Movement

  1. #31
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by mike65535 View Post
    OK, I'll have to think about this one a bit (not familiar with moving cursors around)

    But this:
    Code:
        x++;                 <--- why add one, then take away two?
        x = x - 2;
    Eh, I think I see what he's saying..but no. People shouldn't rely on the compiler fixing their ........-ups because they write bad code like that.
    X += 1; X -=2; will ALWAYS be equivalent to X -= 1; It doesn't make it more readable the other way, IMO.

  2. #32
    Registered User
    Join Date
    Mar 2011
    Posts
    216
    I didn't have it before, but I added it cause I was getting confused. But it made me more confused.

  3. #33
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Another thing I just thought I should mention.

    getch() is not used anymore.

    Also, you have includes to determine if this is a windows platform or DOS? Because I thought you were looking for some cross-platform capabilities...but you're relying on a (deprecated) DOS specific library.

    getch() is part of the console IO library (conio.h) which is now pretty much deprecated. The only good thing is it has non-buffered I/O which is why I'm guessing you're using it. Most people use some other form if they're looking for cross platform stuff. Perhaps you should create the logic for it in 2 different objects, and link to different ones depending on what platform it's on - because this will only work in DOS/Windows.

    Just some food for thought. Not sure what people use now-a-days for non-buffered I/O, most people don't use non-buffered I/O, you can obviously find some stuff with ncurses, I'm not sure what the ncurses lib compatibility with Windows is, though.

    EDIT:
    The normal forms (which used buffered input) in the c std libs are getc() or getchar() - one's typically implemented differently than the other, think getc() is faster - or some crap like that - but for all intents and purposes they're the same thing. You would have to call to the terminal though to disable echo'ing, might be able to do that with a VT100 command (think you can, don't recall).

  4. #34
    Registered User
    Join Date
    Mar 2011
    Posts
    216
    getch() actually works for me with just <stdio.h>, not even conio.h is needed.

  5. #35
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by binks View Post
    getch() actually works for me with just <stdio.h>, not even conio.h is needed.
    And?

    You're in all likelihood using a compiler that is auto-linked against that library because it recognizes the getch() function. If you're using a M$ compiler (ie. Visual Studio), seeing as they are the ones who made the console I/O library, it isn't farfetched that they would automatically link against it.

    Sun's compiler, CC auto-links against the stdio library, stdlib, and a few others if it recognizes a function from there in code. Doesn't mean that code will compile on another OS that has the same standardized libraries.

    Regardless, I'm sure if you pull stdio out of your includes, it will still work, if it DOESN'T, then M$ stuck the function into the stdio package...which is a standard, and they're even dumber and less friendly to developers than I originally thought. The stdio package is an established standard and people shouldn't be bolting additional functionality to it. My guess would be that stdio has nothing to do with it working, it's probably just seeing it and linking against the console I/O lib.

    This creates a two points:
    A) Just because your compiler auto-includes it, doesn't make it a standard
    B) People shouldn't be bolting stuff onto standardized libraries - I don't even think M$ is that arrogant
    Last edited by Syndacate; 04-26-2011 at 05:25 PM. Reason: typo

  6. #36
    Registered User
    Join Date
    Mar 2011
    Posts
    216
    Well, I'm on Dev-C++. This project is merely for my own learning benefit, and to show off to a few friends Cross-platform compatability wasn't really a big deal for me. If it works, it works

  7. #37
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Syndacate View Post
    And?

    You're in all likelihood using a compiler that is auto-linked against that library because it recognizes the getch() function.

    You should take a look at the library structure of some of these runtime libraries... lots of headers... one library with everything in it.

    Pelles C for example has one crt.lib and crt64.lib from which it extracts all standard library functions so it only has to link with 1 of 2 libraries to assemble an executable.

    The header structure is a different matter. They are for the compiler (as you know) and many times there are duplications of functions that are called by other library functions.

    It's a fluke that it works without conio.h ... and should not be trusted as you say...

  8. #38
    Registered User
    Join Date
    Mar 2011
    Posts
    216
    I never would have thought Dev-C++ would auto link, since it's a beta... Some things bug the crap out of me about it, but I'm to lazy to uninstall it for another one haha

  9. #39
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Yes well... get unlazy... DEV-C++ has been abandoned for nearly a decade now.
    You can do so much better.

  10. #40
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by CommonTater View Post
    Yes well... get unlazy... DEV-C++ has been abandoned for nearly a decade now.
    You can do so much better.
    Yeah, my thoughts exactly. It was an epic editor..but it's like, 10 years old dead now - no active dev. That's the only reason why I refused to look into it again.

    Quote Originally Posted by binks View Post
    I never would have thought Dev-C++ would auto link, since it's a beta... Some things bug the crap out of me about it, but I'm to lazy to uninstall it for another one haha
    It's a beta..but it's an ancient beta. There is no active dev on it and there hasn't been for quite some time. It's a dead project. Auto-linking isn't hard, though, and the GNU guys get things right like 9 times out of 10.

    Quote Originally Posted by binks View Post
    Well, I'm on Dev-C++. This project is merely for my own learning benefit, and to show off to a few friends Cross-platform compatability wasn't really a big deal for me. If it works, it works
    Then why bother checking to see if it's a Windows platform at the top?

    Quote Originally Posted by CommonTater View Post
    You should take a look at the library structure of some of these runtime libraries... lots of headers... one library with everything in it.
    Yeah, it could most definitely be part of windows.h, that header includes pretty much everything under the sun in windows land.

    Quote Originally Posted by CommonTater View Post
    Pelles C for example has one crt.lib and crt64.lib from which it extracts all standard library functions so it only has to link with 1 of 2 libraries to assemble an executable.
    It's not a bad idea to do it that way, not sure I like that much control being left up to "it" - but I guess for novice and/or lazy programmers it works out. I'd prefer if any compiler ALWAYS gave me an error, opposed to auto-including something.

    It ........es me off to no end when I'm working on a Sun machine and CC auto-includes stdio and I didn't think to include it, then I move the code somewhere, give it to somebody, another dev, another machine, w.e - and it breaks in like 40,000 places. I rather deal with the error that I create when I create it.

    I'm sure there's a flag you can pass it, but I guess it hasn't bothered me that much to check, lol.

    Quote Originally Posted by CommonTater View Post
    The header structure is a different matter. They are for the compiler (as you know) and many times there are duplications of functions that are called by other library functions.

    It's a fluke that it works without conio.h ... and should not be trusted as you say...
    Yeah, there are multiple ways of handling it. One way is finding it during compilation, and linking against it at link time. The other way is using header file magic. It isn't far-fetched that they'd stick something in there to make it work with the console I/O lib out of the box, but yeah, shouldn't be trusted.

    Though I suppose, in the end, if this code's never even leaving the dev-c++ ide, then it really doesn't matter.

  11. #41
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Syndacate View Post
    Yeah, it could most definitely be part of windows.h, that header includes pretty much everything under the sun in windows land.
    For clarity... I'm talking about runtime libraries (used by the linker)... not headers (used by the compiler).

    With the C standard library in a single .lib file the linker can easily be set up to always (invisibly) link against that file. Which is a good thing...

    This should not, however, allow the compiler to succeed without the necessary .h files.

  12. #42
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by CommonTater View Post
    For clarity... I'm talking about runtime libraries (used by the linker)... not headers (used by the compiler).

    With the C standard library in a single .lib file the linker can easily be set up to always (invisibly) link against that file. Which is a good thing...

    This should not, however, allow the compiler to succeed without the necessary .h files.
    I disagree. I don't believe it's good to link standard libraries to anything else than what's part of the standard. If you're talking about windows.h, then yeah, they can do whatever they want, but I don't feel it should link against them invisibly.

    Unless you modify the compiler, though, there's no way to determine that a problem with linked libraries exist. That will cause the linker to puke.

    There must be something in the header included that defines the functions (just the prototypes), even if they're extern'ed, or the compiler won't be satisfied. It can't just be left out, or the compiler will error. Unmet dependencies for definitions can then be linked to after object compilation, if not, the linker will throw an error. If there was nothing in the header, it would not know that it needs to link against it, even if it adds the link path to the output compilation or sets up some code for dynamic linking.

    Also, the linker doesn't have to be a runtime system, unless it's dynamically linked (ie. dll's or so's), it typically isn't. Most linking is done at compile time, that yields the best performance and is much more reliable. Though even if it's dynamically linked, there still has to be a call to the dynamic lib loader in the header included it to know to do so, this will contain the code to dynamically load the lib at runtime. Though C/C++ was meant to do everything at compile time, hence, static linking. DLL's and the like was shoved into it, and isn't part of C or C++ in and of itself as preprocessor macro expansions are.

  13. #43
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Syndicate ... You don't appear to be understanding my point...

    For example ...
    Pelles C has one library file ... crt.lib which is about 800k in size and contains a few hundred function objects.
    The same package also has 63 different header files that prototype functions from this one library.

    It's not a one to one relationship between header and library... never has been as far as I know and it certainly isn't so in Windows.

    So in your source you #include <stdio.h> ... there is no stdio.lib... the actual function objects are in crt.lib ... and there is nothing in stdio.h that refers to stdlib.h.

    stdio.h informs the *compiler* of the functions it prototypes from crt.lib so that your program can compile.
    At this point it's just another library... an object file, not a program.
    The linker automatically loads crt.lib and links in the required function objects --and only the required objects-- to complete the executable program.

    There neither is nor does there need to be a one to one relationship here... In fact, having a one to one relationship would slow the linker down to a painful crawl.

  14. #44
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by CommonTater View Post
    Syndicate ... You don't appear to be understanding my point...

    For example ...
    Pelles C has one library file ... crt.lib which is about 800k in size and contains a few hundred function objects.
    The same package also has 63 different header files that prototype functions from this one library.

    It's not a one to one relationship between header and library... never has been as far as I know and it certainly isn't so in Windows.

    So in your source you #include <stdio.h> ... there is no stdio.lib... the actual function objects are in crt.lib ... and there is nothing in stdio.h that refers to stdlib.h.

    stdio.h informs the *compiler* of the functions it prototypes from crt.lib so that your program can compile.
    At this point it's just another library... an object file, not a program.
    The linker automatically loads crt.lib and links in the required function objects --and only the required objects-- to complete the executable program.

    There neither is nor does there need to be a one to one relationship here... In fact, having a one to one relationship would slow the linker down to a painful crawl.
    I'm well aware how it works, I'm not entirely sure what you're getting at.

    Yes, they can all exist in one object, that doesn't mean anything. The point is it has multiple headers to deal with it. I know what the include macro expansions do.

    I'm well aware of how the compilation process works. It doesn't change my point, it's not dynamic linking..

    I never said anything about there needing to exist a 1-1 correlation between functions and headers. You made that ........ up on your own.

    I simply don't agree with the idea that everything is set with one header inclusion, like windows has, with its windows.h header. I also find it completely useless to make multiple headers which all reference the same object file to link against. It's pointless. If you pack everything into one object, might as well make one header to link against.

    In my ideal world, there would be multiple headers, each header prototypes functions which are in its corresponding library to link against. That's the way a good portion of C libs are setup, it's the way I'm used to, and it's a way that makes sense.

    If I want to replace an I/O library, I would rather not have ALL the C lib stuff become an issue - name collisions galore. It's nice when you can just tell it not to look for include paths, then specify where it can find things - or replace the library for static linking temporarily.

    It goes under the simple philosophy of not putting all your eggs in one basket. Except this time the eggs are functions.

  15. #45
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Ok... now I get what you're saying... I don't necessarily agree but I get the point now.

    Replacing parts of libraries is no big deal... for example my setup has string.h with functions like strlen(), strcat() etc. that we're all familiar with. I also have a private library doing the same things with dynamically allocated strings (dstring.h and dstring.lib)... no conflicts result because I simply prefixed the function names... dstrlen(), dstrcat() etc. This of course also leaves the original functions available to me when I need them too... I just don't see where this is much of a problem.

    For windows includes... You do realize there are nearly 2000 header files provided in the Windows SDK, don't you? Somehow I'd prefer using windows.h to having to list the 50 or 60 headers it couples in for me... And windows.h only includes the most basic windows functions (mostly contained in kernel32.lib)... there's a ton of other stuff (comctrl.h, shlwapi.h, winsock.h, winsock2.h, etc. etc.) that goes into making a windows program which is not included by windows.h.

    I don't really see a problem with this and neither does my compiler...
    Last edited by CommonTater; 04-27-2011 at 12:11 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. wide character (unicode) and multi-byte character
    By George2 in forum Windows Programming
    Replies: 6
    Last Post: 05-05-2007, 12:46 AM
  2. BMP Movement
    By Vicious in forum Game Programming
    Replies: 11
    Last Post: 06-06-2002, 11:19 AM
  3. Movement
    By got matt? in forum C++ Programming
    Replies: 4
    Last Post: 03-26-2002, 11:52 AM