Page 9 of 21 FirstFirst ... 456789101112131419 ... LastLast
Results 121 to 135 of 307

Thread: Coder's Hang-out

  1. #121
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0


    Yes, but that doesn't change what the program itself does.
    It does change the result.


    What kind of compiler are you using? Works perfectly, compiled with g++. Static variables are zeroed out anyway, so you could just set its first three elements to '3', not bothering to include a terminating zero, and it would still work.
    Visual Studio of course... And i know you'll comment that but i have my resons to restricting all my windows projects to visual C++... lol
    And yes... Auto 0ed out... But when you do that, it demands that it is the same size. "333" is 4 bytes, because i'd be trying to store that 4 byte thing into a 5 byte thing, problem for compiler.



    Download Links:
    Links are hidden from guests. Please register to be able to view these links. First part reads a sample file, associating the characters with morse codes. Then it displays those codes appropriate for each keypress. No error checking, memory cleanup, and that sort of stuff, but you get the idea. And yes, kohlrak, it uses... pointers!
    But you're not using it to store anything other than an address... And does that morse thing work for C++ also?


    It depends on how it's implemented in the standard library. Most common would be to go character-by-character on the two strings, calculate the difference of the characters ASCII codes, and if it's not zero, return it, otherwise continue comparing.
    The reason you can't put a string in a single variable to handle it is that C uses zero terminated strings, unlike Pascal, where the first byte of a string was its length. You can have arbitarily long strings in C (as in: possibly a hundred gazillion letters long), but obviously you can't have arbitarily large variables (int, long int, and the like have an implementation defined size)

    Dude, i don't mean the standard library. I mean C++ itself. This can be done and checked without any of the standard library. It's an IF statement... Buuuuuuuuuuuuut... Wouldn't that take longer than one big number? One would think when they make it they'd make it so they could compare all values at once if possible.

  2. #122
    Join Date
    Feb 2005
    Location
    Limbo
    Posts
    3,706
    Thanks
    0
    Thanked 2 Times in 2 Posts
    EP Points
    10

    Default

    Quote Originally Posted by kohlrak
    It does change the result.
    It shouldn't, if you write the program correctly.
    Quote Originally Posted by kohlrak
    Visual Studio of course... And i know you'll comment that but i have my resons to restricting all my windows projects to visual C++... lol
    And yes... Auto 0ed out... But when you do that, it demands that it is the same size. "333" is 4 bytes, because i'd be trying to store that 4 byte thing into a 5 byte thing, problem for compiler.
    It could give a warning, true. But it should definitely compile. Simply because string literals are automatically allocated, constant arrays, handled by the compiler. So it's not passing a 4 byte thing into a 5 byte thing, it's passing a memory address into a memory address (because arrays are pointers).
    This is illustrated well by the "apple"[3] syntax. (Or 3["apple"], if you want to get sick, they're identical.)
    BTW, my only problem with Visual Studio is that it froze up on me several times, and it got annoying. And that it doesn't conform to the standard. But if you'll be writing programs solely for Windows, it's definitely the best choice (since it bears the MS name).
    Quote Originally Posted by kohlrak
    But you're not using it to store anything other than an address... And does that morse thing work for C++ also?
    Anything other than an address? What do you mean by that? They're strings, that's how they're stored. Obviously there would be more efficient methods, but this was the most simple.
    I'm using the C standard library, but those could be replaced by their STL counterparts, or just simply including the same headers. So, yep.

    Quote Originally Posted by kohlrak
    Dude, i don't mean the standard library. I mean C++ itself. This can be done and checked without any of the standard library. It's an IF statement... Buuuuuuuuuuuuut... Wouldn't that take longer than one big number? One would think when they make it they'd make it so they could compare all values at once if possible.
    You're wrong. String are classes, made available for you through standard headers. Try not including any headers, and you'll see it doesn't work. In C++ that's done by operator overloading, and it works a bit different to my understanding.
    It doesn't take longer than fitting it into an appropriate variable since a) it exits as soon as the result is known, b) no conversion is needed, whereas converting it into numbers would be more difficult. And c) the size of int is limited, the size of a string isn't. That would call for more checking and whatnot.
    Last edited by pkt-zer0; 25th-December-2005 at 18:45.

  3. #123
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0
    It shouldn't, if you write the program correctly.

    It could give a warning, true. But it should definitely compile. Simply because string literals are automatically allocated, constant arrays, handled by the compiler. So it's not passing a 4 byte thing into a 5 byte thing, it's passing a memory address into a memory address (because arrays are pointers).
    This is illustrated well by the "apple"[3] syntax. (Or 3["apple"], if you want to get sick, they're identical.)
    BTW, my only problem with Visual Studio is that it froze up on me several times, and it got annoying. And that it doesn't conform to the standard. But if you'll be writing programs solely for Windows, it's definitely the best choice (since it bears the MS name).
    Nope... Won't compile. Gives the cannot convert char[4] to char[5] error. =p

    Anything other than an address? What do you mean by that? They're strings, that's how they're stored. Obviously there would be more efficient methods, but this was the most simple.
    I'm using the C standard library, but those could be replaced by their STL counterparts, or just simply including the same headers. So, yep.
    no no no, in that example the pointers only held the address of another variable. Thing is, people use (and i think you were amoung those that sugested this) to use pointers as stand alone variables to contain data within the pointers themselves. In other words a code like this...

    Download Links:
    Links are hidden from guests. Please register to be able to view these links. Or somthing like that... maybe i misunderstood you. lol

    You're wrong. String are classes, made available for you through standard headers. Try not including any headers, and you'll see it doesn't work. In C++ that's done by operator overloading, and it works a bit different to my understanding.
    It doesn't take longer than fitting it into an appropriate variable since a) it exits as soon as the result is known, b) no conversion is needed, whereas converting it into numbers would be more difficult. And c) the size of int is limited, the size of a string isn't. That would call for more checking and whatnot.
    I know string classes are. I'm not talking about the string class though. I'm talking about a constant string, which is also known as a char array.

    here... lemme make this easier so there isn't any more confusion... (X'D)

    Download Links:
    Links are hidden from guests. Please register to be able to view these links. But uh... while you're at it... want to show us an example of how the string class auto decides it's size to fit the needed situation and not go over or under that size? As usual, the header files are filled with nast garbage variables that are... welll. yea. lol Let's just say, hard to read. I have a theory i'm gonna try out but something tells me this isnt' gonna work. lol

    EDIT: Theory worked... X'D never thought of this, i'm gonna experiment...

    EDIT2: Now to figure how they got it to work for cin.... Then to find how they got the + function to work. X'D
    Last edited by kohlrak; 26th-December-2005 at 04:38.

  4. #124
    Join Date
    Feb 2005
    Location
    Limbo
    Posts
    3,706
    Thanks
    0
    Thanked 2 Times in 2 Posts
    EP Points
    10

    Default

    Quote Originally Posted by kohlrak
    Nope... Won't compile. Gives the cannot convert char[4] to char[5] error. =p
    Just tried it in MS VC++ 6.0, and compiled without errors. BTW, "333" is just a shorter version of the { '3', '3', '3', '\0' } initialization. It's not really a variable..

    Download Links:
    Links are hidden from guests. Please register to be able to view these links. Aieee. That's pretty wrong. I mean, you probably wanted to use *array="Pie" in the third row, but that would just make the pointer point to some bogus memory area.

    Quote Originally Posted by kohlrak
    EDIT2: Now to figure how they got it to work for cin.... Then to find how they got the + function to work. X'D
    Operator overloading? Possibly done by determining the length of both strings, adding them, and resizing the available memory if necessary.

  5. #125
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0
    Just tried it in MS VC++ 6.0, and compiled without errors. BTW, "333" is just a shorter version of the { '3', '3', '3', '\0' } initialization. It's not really a variable..

    Download Links:
    Links are hidden from guests. Please register to be able to view these links. Aieee. That's pretty wrong. I mean, you probably wanted to use *array="Pie" in the third row, but that would just make the pointer point to some bogus memory area.


    Operator overloading? Possibly done by determining the length of both strings, adding them, and resizing the available memory if necessary.
    The real trick is how they append one string to another so quickly without a while loop when they use the + function. (You can tell it isn't a while loop cause it dosn't take half an hour to do. (and yes, i'm well aware that was a hyperbole. lol) )

  6. #126
    Join Date
    Feb 2005
    Location
    Limbo
    Posts
    3,706
    Thanks
    0
    Thanked 2 Times in 2 Posts
    EP Points
    10

    Default

    Well, nowadays processors are pretty fast. 1 GHz ~ 1 billion operations per second.
    You are aware that the while loop is pretty freaking fast, aren't you? I mean, it's almost at machine code level, taking up two clock cycles at most.

    BTW, what IS the trick, then? Stop being so mysterious about it.

    EDIT: I checked out its implementation in g++. Definitely more complicated than a simple while. And yes, it does have that as well, several instances, at that. So it's speed truly is lower than a non-object version. But it's more robust, that's for certain.
    Download the library source from here, check in the libg++/src/ directory for Strings.h and Strings.cc
    ftp://ftp.mirrorservice.org/sites/so....8.1.3.tar.bz2
    Last edited by pkt-zer0; 26th-December-2005 at 21:53.

  7. #127
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0
    Well, nowadays processors are pretty fast. 1 GHz ~ 1 billion operations per second.
    You are aware that the while loop is pretty freaking fast, aren't you? I mean, it's almost at machine code level, taking up two clock cycles at most.
    Not as fast as you think... lol 1ghz... based on my 2.5 i'd have to say that's about 1000 increments and printing them out per second.

    BTW, what IS the trick, then? Stop being so mysterious about it.
    If i knew i wouldn't ask. =p

    EDIT: I checked out its implementation in g++. Definitely more complicated than a simple while. And yes, it does have that as well, several instances, at that. So it's speed truly is lower than a non-object version. But it's more robust, that's for certain.
    Download the library source from here, check in the libg++/src/ directory for Strings.h and Strings.cc
    ftp://ftp.mirrorservice.org/sites/so....8.1.3.tar.bz2
    Is it commented at all? And is it filled with a bunch of nonsence global variablse like "_t" then have a "_T" then have "_Tc" and "_tC" and another "_TC"? X'D

  8. #128
    Join Date
    Feb 2005
    Location
    Limbo
    Posts
    3,706
    Thanks
    0
    Thanked 2 Times in 2 Posts
    EP Points
    10

    Default

    Quote Originally Posted by kohlrak
    Not as fast as you think... lol 1ghz... based on my 2.5 i'd have to say that's about 1000 increments and printing them out per second.
    Actually, faster. Try repeating a single operation in a loop (without printing it to screen), and timing it with GetTickCount, maybe. It IS fast, believe me. I mean, C code executes in virtually 0 seconds, unless there's something involving a peripheral (screen, harddrive). So yeah, the CPU and memory are hella fast.

    Quote Originally Posted by kohlrak
    Is it commented at all? And is it filled with a bunch of nonsence global variablse like "_t" then have a "_T" then have "_Tc" and "_tC" and another "_TC"? X'D
    Well, it's an open source project, meaning anyone could modify it, so yeah, it's pretty well commented. It is more readable (and more compact) then most code I produce, anyway.

  9. #129
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0
    Actually, faster. Try repeating a single operation in a loop (without printing it to screen), and timing it with GetTickCount, maybe. It IS fast, believe me. I mean, C code executes in virtually 0 seconds, unless there's something involving a peripheral (screen, harddrive). So yeah, the CPU and memory are hella fast.
    You forget, when you're talkin' FPS and stuffs, ick... A second is like forever, especially if you're like me with ADHD. lol

    Well, it's an open source project, meaning anyone could modify it, so yeah, it's pretty well commented. It is more readable (and more compact) then most code I produce, anyway.
    The more compact, the better... well.. the less code the better. lol

    Another good one, how much does calling a function slow down a computer verses a macros? And how much more space does it take on the compy? And! Another one, how much more does it take to call from a DLL?

    As for pointies... I have a good challenge for you if you ever get bored PKT. Write a source code that when compilled and run, it'll copy itself from the ram and write it to a file and save it as ".ram". Chances are it'll crash alot... but i have a funny feeling we might get something intresting from it... Who knows what we'd learn if it succeeded?

    EDIT: Reminds me of looking at the direct X API. lol

    EDIT2: Hm... I wonder how you can really output anything to the screen if C++ has no functions of it's own... And i wonder how a hello program would look in ASM... i got a disassembler here but it only opens ".com" files. lol

    EDIT3: Holy crap... I managed to open up an exe file in this thing and... o.o Dude, it looks like somthing i once saw in visual C++ 6.0 when debugging a file one time...
    Last edited by kohlrak; 28th-December-2005 at 07:33.

  10. #130
    Join Date
    Feb 2005
    Location
    Limbo
    Posts
    3,706
    Thanks
    0
    Thanked 2 Times in 2 Posts
    EP Points
    10

    Default

    Quote Originally Posted by kohlrak
    You forget, when you're talkin' FPS and stuffs, ick... A second is like forever, especially if you're like me with ADHD. lol
    Yeah, but it makes a difference, computing 1000 of 10 billion operations a second. If you raise the times you execute the loop high enough, it will take more than a second. But it's interesting to see how high it goes.

    Quote Originally Posted by kohlrak
    Another good one, how much does calling a function slow down a computer verses a macros? And how much more space does it take on the compy? And! Another one, how much more does it take to call from a DLL?
    Macros are simply text replaced with other text in the code, during compile time. So it doesn't slow anything at all, only what's executed within. With functions, the return address and values go on the stack, so your only problem would be that filling, and the program crashing. Don't' worry, it's pretty large, for this purpose at least, but going into infinite recursion crashes it, recursion itself eats up pretty much of the stack, as well. With the stack being the part of the memory that's accessed with the greatest speed, that's not quite good.
    DLLs are Dynamically Linked Libraries, meaning they get linked run-time, more precisely on start. I don't think that's much slower (obviously you'll get smaller executable sizes than including the libraries in the EXE itself), but version incompatibilities could be a problem sometimes.

    Quote Originally Posted by kohlrak
    As for pointies... I have a good challenge for you if you ever get bored PKT. Write a source code that when compilled and run, it'll copy itself from the ram and write it to a file and save it as ".ram". Chances are it'll crash alot... but i have a funny feeling we might get something intresting from it... Who knows what we'd learn if it succeeded?
    I'm not sure if Windows would let me do that, kinda like it wouldn't let me access the video memory directly, still, worth a try. Anyway, the code is obviously there in the EXE file in some form. I'm not sure if it's self-extracting, or uncompressed.
    Download Links:
    Links are hidden from guests. Please register to be able to view these links. Arrgh, doesn't work. Tried copying memory from an array containing a sample string, and it wouldn't let me go much further than the end of the array. Gotta learn the Windows API sometime.

    Quote Originally Posted by kohlrak
    EDIT2: Hm... I wonder how you can really output anything to the screen if C++ has no functions of it's own...
    C was designed for portability. Since not all computers even have a screen, you don't get standard methods for output. The good thing is you could even code for whatever weird sort of terminal you'd like.

    Quote Originally Posted by kohlrak
    EDIT3: Holy crap... I managed to open up an exe file in this thing and... o.o Dude, it looks like somthing i once saw in visual C++ 6.0 when debugging a file one time...
    Yep, Assembler is nice. Even nicer if you understand what things do.
    BTW, here's some code a guy I know wrote. He's pretty into low-level coding, so yeah. Beware.

  11. #131
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0

    Macros are simply text replaced with other text in the code, during compile time. So it doesn't slow anything at all, only what's executed within. With functions, the return address and values go on the stack, so your only problem would be that filling, and the program crashing. Don't' worry, it's pretty large, for this purpose at least, but going into infinite recursion crashes it, recursion itself eats up pretty much of the stack, as well. With the stack being the part of the memory that's accessed with the greatest speed, that's not quite good.
    DLLs are Dynamically Linked Libraries, meaning they get linked run-time, more precisely on start. I don't think that's much slower (obviously you'll get smaller executable sizes than including the libraries in the EXE itself), but version incompatibilities could be a problem sometimes.
    So in other words, writing functions themselves rather than macros wouldn't change the speed any, just risk chance of crashing.. What do you me recursion? In otherwords, are you talking about calling the function within itself or are you talking about calling it from wherever? (If you mean calling from wherever, i'll just use the while loop and the debug runtime and find the exact number. lol)

    I'm not sure if Windows would let me do that, kinda like it wouldn't let me access the video memory directly, still, worth a try. Anyway, the code is obviously there in the EXE file in some form. I'm not sure if it's self-extracting, or uncompressed.
    Download Links:
    Links are hidden from guests. Please register to be able to view these links. Arrgh, doesn't work. Tried copying memory from an array containing a sample string, and it wouldn't let me go much further than the end of the array. Gotta learn the Windows API sometime.
    lol, we all should... But the winapi is more than just an API, it's pratically a whole new language in itself, and from what i've seen the vocabulary and such are bigger and such than C++ itself. lol

    C was designed for portability. Since not all computers even have a screen, you don't get standard methods for output. The good thing is you could even code for whatever weird sort of terminal you'd like.
    Yea, but, it would require that somthing other than C++ was to do stuff like output. Something foreign would have to be thrown in there. Weather it be a call to a non C++ dll or so forth.

    Yep, Assembler is nice. Even nicer if you understand what things do.
    BTW, here's some code a guy I know wrote. He's pretty into low-level coding, so yeah. Beware.
    Oh yea, could you imagin all the nice things we could do. The biggest problem we'd face is figuring out all we need to run the programs on a specific operating system. I've actually opened some of the prebuild files that come after compiling the script. With windows compilers, actually, there is C++ code added to it. I thought i saw one of the files was called runtime. Alot of stuff we really don't see. and i have a theory. That since C++ (pretty sure it is) gets converted to assembly before it's compiled (now where that data is stored, we dont' know) we not only have assemblers and maybe disassemblers on our computers with our compilers, but we may also be able to fix many problems we have with our problems. Liiiiike, the fact that ints are 4 bytest, perhaps just finding that information (probably stored in the ram while it compiles) we could edit how big datatypes are and more than just that. Another little trick, with assembly, we could write huge projects, then delete the garbage with a disassembler. I'm sure there is lots of code in the C++ program files that we have that most of it isn't even needed or used. Could speed up things quite a bit and maybe take them to the same speed as assembly programs, only that we didn't have to type in all the ASM junk. We could just open the ASM file with notepad, highlight and backspace out all the funk and it'd work better. If this is true, we could very well speed up some of these games we play on our computer, such as halo or call of duty or such. Then being wonderful coders we are, release a program that would cut out all that junk, or the optimized file.

    EDIT: I just found out 1 good reson to use printf() over "cout <<". lol cout ALWAYS prints1 char at a time. That means cout is slower, how did i find this out and that printf dosn't? I used my thread project. Now i like threads, it's just i wish the so called mutex would actually work. They have things out there to keep threads from corrupting (or at least it should), but they don't work. Just take up more code space. lol
    Last edited by kohlrak; 28th-December-2005 at 21:48.

  12. #132
    Join Date
    Feb 2005
    Location
    Limbo
    Posts
    3,706
    Thanks
    0
    Thanked 2 Times in 2 Posts
    EP Points
    10

    Thumbs up

    Quote Originally Posted by kohlrak
    So in other words, writing functions themselves rather than macros wouldn't change the speed any, just risk chance of crashing.. What do you me recursion? In otherwords, are you talking about calling the function within itself or are you talking about calling it from wherever? (If you mean calling from wherever, i'll just use the while loop and the debug runtime and find the exact number. lol)
    Not exactly. Macros are as fast as the code contained within them. Since that's all they are.
    Functions, however, take up memory additional to that what's used within, because the function that called them will have to store where to continue executing the code.
    Recursion is calling the function from within itself, yeah. Like the common

    int factorial( int n ) return (n<=1) ? 1 : n*factorial(n-1);

    For calculating n! . One-liners win.

    Quote Originally Posted by kohlrak
    Yea, but, it would require that somthing other than C++ was to do stuff like output. Something foreign would have to be thrown in there. Weather it be a call to a non C++ dll or so forth.
    Exactly what I said. That's why it's portable. Had there been default functions for those thrown in, compilers would be pretty freaking huge, with a gazillion of libraries.

    Quote Originally Posted by kohlrak
    That since C++ (pretty sure it is) gets converted to assembly before it's compiled (now where that data is stored, we dont' know) we not only have assemblers and maybe disassemblers on our computers with our compilers, but we may also be able to fix many problems we have with our problems.
    There is an option in certain compilers to dump the code to file during different parts of the compilation, for example after the macros have been replaced, or after all of it's been converted to assembler. But no, don't try to optimize it, it's already written pretty well, by people who specialize in that sort of stuff. You're always free to write your own compiler, sometime in the future.

    Quote Originally Posted by kohlrak
    Liiiiike, the fact that ints are 4 bytest, perhaps just finding that information (probably stored in the ram while it compiles) we could edit how big datatypes are and more than just that.
    The size of integers have nothing to do with assembler, but rather, the compiler. In C, it's implementation-defined, meaning that there's a pre-defined value in the compiler that stores the size of integers. Yeah, it can be changed, you just have to build your own compiler. gcc is open source, so that might be a way if you really want to mess with that.
    Ints are 4 bytes because they're optimized for 32bit CPUs, obviously.

    Quote Originally Posted by kohlrak
    Another little trick, with assembly, we could write huge projects, then delete the garbage with a disassembler. I'm sure there is lots of code in the C++ program files that we have that most of it isn't even needed or used. Could speed up things quite a bit and maybe take them to the same speed as assembly programs, only that we didn't have to type in all the ASM junk. We could just open the ASM file with notepad, highlight and backspace out all the funk and it'd work better. If this is true, we could very well speed up some of these games we play on our computer, such as halo or call of duty or such. Then being wonderful coders we are, release a program that would cut out all that junk, or the optimized file.
    Just removing random stuff doesn't optimize things. Sure, it makes it faster, but unless you're replacing those things with something else, it won't work. Anyway, this is a 'been-there-done-that' sort of situation. Where speed is critical, people prefer to use highly optimized assembler code. Though this is the smaller part of the speed issue.

    Quote Originally Posted by kohlrak
    EDIT: I just found out 1 good reson to use printf() over "cout <<". lol cout ALWAYS prints1 char at a time. That means cout is slower, how did i find this out and that printf dosn't? I used my thread project. Now i like threads, it's just i wish the so called mutex would actually work. They have things out there to keep threads from corrupting (or at least it should), but they don't work. Just take up more code space. lol
    C++ was always slower than C, but more safe, due to the object oriented approach. The good thing is that you won't break a program by misusing an object, simply because the object itself won't let you. You can easily kill off variables by making a simple mistake while reading stuff with scanf, however.

  13. #133
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0
    Not exactly. Macros are as fast as the code contained within them. Since that's all they are.
    Functions, however, take up memory additional to that what's used within, because the function that called them will have to store where to continue executing the code.
    Recursion is calling the function from within itself, yeah. Like the common

    int factorial( int n ) return (n<=1) ? 1 : n*factorial(n-1);

    For calculating n! . One-liners win.
    So, basically, as long as i don't have a function call itself, i don't have to worry about anything, right?


    Exactly what I said. That's why it's portable. Had there been default functions for those thrown in, compilers would be pretty freaking huge, with a gazillion of libraries.
    Yea, but somthing has to come from some where. This means, something non C++ or non C has to be hidden some where. I'm a bit curious how they got this forign stuff in without any errors...

    There is an option in certain compilers to dump the code to file during different parts of the compilation, for example after the macros have been replaced, or after all of it's been converted to assembler. But no, don't try to optimize it, it's already written pretty well, by people who specialize in that sort of stuff. You're always free to write your own compiler, sometime in the future.
    Like who? You know it's pretty well not optimized if microsoft written it. No one knows assembly so no one'd know, yet using Visual C++ is the best choice for windows, because of all the APIs for visual C++ only, but then we're once again stuck with unoptimized crap.

    The size of integers have nothing to do with assembler, but rather, the compiler. In C, it's implementation-defined, meaning that there's a pre-defined value in the compiler that stores the size of integers. Yeah, it can be changed, you just have to build your own compiler. gcc is open source, so that might be a way if you really want to mess with that.
    Ints are 4 bytes because they're optimized for 32bit CPUs, obviously.
    Well, i think that stuff would be built in the ASM code, though, since ASM is direct processor code.

    Just removing random stuff doesn't optimize things. Sure, it makes it faster, but unless you're replacing those things with something else, it won't work. Anyway, this is a 'been-there-done-that' sort of situation. Where speed is critical, people prefer to use highly optimized assembler code. Though this is the smaller part of the speed issue.
    Well, like i said, i'm sure there is a bunch of junk in there that isn't even used. If it's not used, it's not needed and can be safely cut out. Alot of the exception codes that you can see with a hex editor which is put into the code, could easily be cured. If you have your own code in you own program with exceptions because you need it to be a certain range, why have a set of exception checkers and such that check for values over your ranges in both directions? In other words, there is stuff in there that protects code from going too high, but if you have an if statement or such that handles the thing for another value, isn't that exception handle of the higher value worhtless? Wouldn't that junk be worth cutting out and just kill everything that depends on that code and the dependencies of that. No adding, just removing a heck of a lot, and depending how often junk like that is called, could put it at the same speed as ASM code. Plus dramatically cut down on the mem needed.

    C++ was always slower than C, but more safe, due to the object oriented approach. The good thing is that you won't break a program by misusing an object, simply because the object itself won't let you. You can easily kill off variables by making a simple mistake while reading stuff with scanf, however.
    Thing is, i was using a C++ compiler. And objects don't really have that protection that you think they do. I crash all the time, especially cause string can't be initialized. I'm guessing "cout <<" was horribly coded with a while loop and a call to printf or something of the sort. And i thought C was object oriented. I thought anything with functions was object oriented. And heck, aren't structs mearly C's way of calling objects similar to C++ only without operator overloading?

  14. #134
    Join Date
    Feb 2005
    Location
    Limbo
    Posts
    3,706
    Thanks
    0
    Thanked 2 Times in 2 Posts
    EP Points
    10

    Default

    Quote Originally Posted by kohlrak
    So, basically, as long as i don't have a function call itself, i don't have to worry about anything, right?
    Right. There always might be exceptions though, but it's not typical that 16000 functions are called at the same time, unless you did something very wrong.
    Quote Originally Posted by kohlrak
    Yea, but somthing has to come from some where. This means, something non C++ or non C has to be hidden some where. I'm a bit curious how they got this forign stuff in without any errors...
    That's where standards and APIs and drivers come in. They just do the stuff, so you should't have to care about how it's done. It's just done, somehow.
    Quote Originally Posted by kohlrak
    Like who? You know it's pretty well not optimized if microsoft written it. No one knows assembly so no one'd know, yet using Visual C++ is the best choice for windows, because of all the APIs for visual C++ only, but then we're once again stuck with unoptimized crap.
    Get gcc then, it's open source. Meaning that anyone that found anything that was worth improving, did so. Resulting in great speed/stability/reliability/whatever. Also, not all APIs are Visual C++ only. OpenGL and glut (things I used for graphics and input) both work perfectly well under Linux, too. But I agree, there are far too many Win-only stuff.
    Quote Originally Posted by kohlrak
    Well, i think that stuff would be built in the ASM code, though, since ASM is direct processor code.
    Yes, ASM is direct processor code. What does that have to do with how large memory blocks are assigned to an individual variable type? Nothing.

    Quote Originally Posted by kohlrak
    Well, like i said, i'm sure there is a bunch of junk in there that isn't even used. If it's not used, it's not needed and can be safely cut out. Alot of the exception codes that you can see with a hex editor which is put into the code, could easily be cured. If you have your own code in you own program with exceptions because you need it to be a certain range, why have a set of exception checkers and such that check for values over your ranges in both directions? In other words, there is stuff in there that protects code from going too high, but if you have an if statement or such that handles the thing for another value, isn't that exception handle of the higher value worhtless? Wouldn't that junk be worth cutting out and just kill everything that depends on that code and the dependencies of that. No adding, just removing a heck of a lot, and depending how often junk like that is called, could put it at the same speed as ASM code. Plus dramatically cut down on the mem needed.
    Yeah, optimizing. If something seems slow, code your version of it, to see if it's faster. If it IS, use it, if not, revert. However...
    Have you ever checked out Cassini, the "Open Source" Saturn Emulator? Those fools just disassembled the code, and put the ~2MB of assembler into a text file. See if you can improve it in a hundred million years.
    Truly, ASM is not pleasant to the eye in the case of larger programs. It is good for making a select few functions smaller/faster, though, but you don't need a disassembler for that.
    Quote Originally Posted by kohlrak
    Thing is, i was using a C++ compiler. And objects don't really have that protection that you think they do. I crash all the time, especially cause string can't be initialized. I'm guessing "cout <<" was horribly coded with a while loop and a call to printf or something of the sort. And i thought C was object oriented. I thought anything with functions was object oriented. And heck, aren't structs mearly C's way of calling objects similar to C++ only without operator overloading?
    Object orientation is an approach to programming, a programming method itself, alternative to structured programming, it has nothing to do with the actual datatypes themselves.
    In structured programming, you make loops and functions to handle the data.
    In object oriented programming, you make objects that are autonomous in some way, and have them go at it. The thing is that here the data is contained in the objects themselves, and is not manipulated from the outside. The objects re-assign their inner variables according to various instructions you may give them, and then behave accordingly. So, you could have a Player object, with a Jump method, that would make it jump, without you having to care about the exact details (collision, velocity, animation).
    BTW, the difference between structs and classes in C++ is that structs data fields default to public, whereas classes' default to private. There is no private/public distinction in C, therefore no need for classes.

  15. #135
    Join Date
    Apr 2005
    Location
    Pennsylvania, USA
    Posts
    520
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by pkt-zer0
    Right. There always might be exceptions though, but it's not typical that 16000 functions are called at the same time, unless you did something very wrong.
    I don't think it's possible to make that bad of a mistake...

    That's where standards and APIs and drivers come in. They just do the stuff, so you should't have to care about how it's done. It's just done, somehow.
    One should worrry, it also goes through the processor like everything else. What if there is a faster way? Plus, i'm curious how they introduce forign things into it. The information could make things possible in the long run. Like calling VB functions from VB's OCX or whatever they are (their dlls i think they are) and using some of those functions. You don't see the point now, but think of it in other ways, such as, calling assembly code or doing things with C++ that directly mess with the hardware? Perhaps you want to make a program in C++ that overclocks or somthing like that. Or how about hardware drivers in C++! I thought that's what the << and >> was for anyway.

    Get gcc then, it's open source. Meaning that anyone that found anything that was worth improving, did so. Resulting in great speed/stability/reliability/whatever. Also, not all APIs are Visual C++ only. OpenGL and glut (things I used for graphics and input) both work perfectly well under Linux, too. But I agree, there are far too many Win-only stuff.
    Well, there are alot of things that are... Plus, i keep trying to get it but i can never find the thing.

    Yes, ASM is direct processor code. What does that have to do with how large memory blocks are assigned to an individual variable type? Nothing.
    Processor processes the program, that means everything in it, therefor it reads what the OS says, therefor, assembly should have the last word even over the OS if the assembly code says so because it's send directly to the processor over the OS. We forget here, the processor is the computer itself and makes all the choices, the OS is just another program the processor calculates.

    Yeah, optimizing. If something seems slow, code your version of it, to see if it's faster. If it IS, use it, if not, revert. However...
    Have you ever checked out Cassini, the "Open Source" Saturn Emulator? Those fools just disassembled the code, and put the ~2MB of assembler into a text file. See if you can improve it in a hundred million years.
    Truly, ASM is not pleasant to the eye in the case of larger programs. It is good for making a select few functions smaller/faster, though, but you don't need a disassembler for that.
    Yea you do... Unless you know of a program that could convert some other things back to C or C++ so we can optimise it.

    Object orientation is an approach to programming, a programming method itself, alternative to structured programming, it has nothing to do with the actual datatypes themselves.
    In structured programming, you make loops and functions to handle the data.
    In object oriented programming, you make objects that are autonomous in some way, and have them go at it. The thing is that here the data is contained in the objects themselves, and is not manipulated from the outside. The objects re-assign their inner variables according to various instructions you may give them, and then behave accordingly. So, you could have a Player object, with a Jump method, that would make it jump, without you having to care about the exact details (collision, velocity, animation).
    BTW, the difference between structs and classes in C++ is that structs data fields default to public, whereas classes' default to private. There is no private/public distinction in C, therefore no need for classes.
    Exactly, therefor C is also object oriented.... Actually, with a little intellegence (and alot of hard to read code) you could actually use namespaces to as classes to do the same thing as objects. Only, you'd have to copy and paste the namespaces and rename them to make new objects. lol

    That also means, you could emulate object orientation in structured language... What scares me is those languages that don't use functions or objects. o.o i think VB's one of them. lol

Similar Threads

  1. Visit The Hang Out!
    By Georgyw5k in forum Free 4 All
    Replies: 5
    Last Post: 28th-November-2003, 05:18
  2. Do You Hang Up On Advertisement Callers?
    By ((KvN)) in forum Free 4 All
    Replies: 52
    Last Post: 21st-July-2003, 11:16

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About Us

We are the oldest retro gaming forum on the internet. The goal of our community is the complete preservation of all retro video games. Started in 2001 as EmuParadise Forums, our community has grown over the past 18 years into one of the biggest gaming platforms on the internet.

Social