Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
Dennis Schridde schreef: Am Sonntag, 3. Juni 2007 schrieb Ari Johnson: On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jun 3 17:51:56 2007 New Revision: 1440 URL: http://svn.gna.org/viewcvs/warzone?rev=1440view=rev Log: * turn some usages of WinAPI types (*WORD) into their native C counterparts (e.g. int, unsigned int, etc.) Are you sure about that? Int and unsigned int vary in size according to the ABI. It is far better to use integers of a known size that will not change according to the system you are on. uint32_t and int32_t, for instance. As long as you stay on the same system that should not matter, should it? Eg. if that int never reaches the borders of your system (via file or network), then it should be perfectly legal to use them.. Not to mention that the native `int` type usually is faster than any random fixed-size integer. So throwing that speed gain away for an assurance of size which you _don't_ need, seems rather stupid to me. Even though that speed gain is usually very small (if it exists in the first place), the fact that you don't need the _only_ advantage of fixed size types, above the native C types, is enough reason _not_ to use them above the native C types. All we need as a minimum size, but those are provided for every single type anyway. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
Ari Johnson schreef: On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Dennis Schridde schreef: Am Sonntag, 3. Juni 2007 schrieb Ari Johnson: On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jun 3 17:51:56 2007 New Revision: 1440 URL: http://svn.gna.org/viewcvs/warzone?rev=1440view=rev Log: * turn some usages of WinAPI types (*WORD) into their native C counterparts (e.g. int, unsigned int, etc.) Are you sure about that? Int and unsigned int vary in size according to the ABI. It is far better to use integers of a known size that will not change according to the system you are on. uint32_t and int32_t, for instance. As long as you stay on the same system that should not matter, should it? Eg. if that int never reaches the borders of your system (via file or network), then it should be perfectly legal to use them.. Not to mention that the native `int` type usually is faster than any random fixed-size integer. So throwing that speed gain away for an assurance of size which you _don't_ need, seems rather stupid to me. Even though that speed gain is usually very small (if it exists in the first place), the fact that you don't need the _only_ advantage of fixed size types, above the native C types, is enough reason _not_ to use them above the native C types. Is this really the case? On LP64 architectures, 'int' is 32 bits while the native word size on the hardware is 64 bits. Do you have benchmarks on various systems to back this up? I think I shouldn't have even mentioned the speed difference, since it hardly is the most important argument. What is more important in this discussion is: don't use what you don't need. I'll elaborate: the only difference between a regular `int` and say `int32_t` is that `int32_t` provides an additional guarantee that it will _always_ be exactly 32bit long. This is the only difference, and as such the only advantage of using int32_t above int. If however you simply don't need that additional guarantee, then I'd say: don't use it. Now please tell me. Why should we at all want to have that size guarantee in any non-networking, non-file code ? I think we don't need it anywhere in those portions of code, so would really vote for using a plain `int` instead and leave the compiler a bit more freedom for optimizations, etc. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Now please tell me. Why should we at all want to have that size guarantee in any non-networking, non-file code ? I think we don't need it anywhere in those portions of code, so would really vote for using a plain `int` instead and leave the compiler a bit more freedom for optimizations, etc. Compiler won't dare to optimize on the assumption that the coder will not make any assumptions on the size of his declared types, so it makes no difference either way. My person opinion right now (it could change tomorrow), is that we should just stick to the ugly UDWORD, SWORD, BOOL etc types that warzone was originally coded with, just because it makes things consistent. I like consistent. It also gives the source code a sort of retro, 90ies feel to it ;-) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On Mon, 04 Jun 2007 13:18:21 -0400 Ari Johnson [EMAIL PROTECTED] wrote: On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Now please tell me. Why should we at all want to have that size guarantee in any non-networking, non-file code ? I think we don't need it anywhere in those portions of code, so would really vote for using a plain `int` instead and leave the compiler a bit more freedom for optimizations, etc. Like I said originally, as long as you are very careful when you deal with file or networking code, it doesn't matter to me. However, what I have seen in the past is a lot of carelessness on variable types that eventually get read from or written to the disk. (I still haven't looked at the networking code but I'm sure it's just as much of a mess.) Using the same size variables in the non- file/networking code to represent data that gets put on disk or the network also has the advantages of catching issues earlier and documenting the size of the data on disk or the network more clearly. Basically, the we'll worry about it when it's on disk or the network attitude has been the cause of enough problems to make me wary of anyone who holds it. I have to agree, only if 100% positive that this 'int' will not come later to think that it should be int32_t instead. If you wants network code, file save code, and other code to be 100% compatable, between all machines and compilers, then only option is to specify size exact on how it should be. -- Click to find great rates on medical insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QS4STAf65YbdLliYCqBiGHWnN/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Ari Johnson schreef: On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: I think I shouldn't have even mentioned the speed difference, since it hardly is the most important argument. What is more important in this discussion is: don't use what you don't need. I'll elaborate: the only difference between a regular `int` and say `int32_t` is that `int32_t` provides an additional guarantee that it will _always_ be exactly 32bit long. This is the only difference, and as such the only advantage of using int32_t above int. If however you simply don't need that additional guarantee, then I'd say: don't use it. Now please tell me. Why should we at all want to have that size guarantee in any non-networking, non-file code ? I think we don't need it anywhere in those portions of code, so would really vote for using a plain `int` instead and leave the compiler a bit more freedom for optimizations, etc. Like I said originally, as long as you are very careful when you deal with file or networking code, it doesn't matter to me. However, what I have seen in the past is a lot of carelessness on variable types that eventually get read from or written to the disk. (I still haven't looked at the networking code but I'm sure it's just as much of a mess.) Using the same size variables in the non-file/networking code to represent data that gets put on disk or the network also has the advantages of catching issues earlier and documenting the size of the data on disk or the network more clearly. I agree on the documenting part. As for catching issues earlier that's not true at all, since you most likely simply won't have any size problems when using fixed with types (and as such there's no issue on that topic to catch). Basically, the we'll worry about it when it's on disk or the network attitude has been the cause of enough problems to make me wary of anyone who holds it Well, if you only worry about it when it's on the disk/network already then you're to late already. My thoughts for going about writing to disk/network however are that it is the responsibility of the disk/network read/write code to make sure sizes and endianness are dealt with, and _not_ the responsibility for all of Warzone's code. The first of those (read/write code being responsible) is localized and as such easy to maintain, the latter however (every single piece of code is responsible) is very difficult to maintain and debug. This of course _does_ mean that you should be fairly careful when writing those interfacing functions for reading/writing from disk/network streams. I find that to be much easier to maintain though than having to repeat writing similar code with similar responsibilities all over Warzone's codebase. The problem is that Warzone doesn't isolate such things. When reading data from disk, the common method is to read directly into a game struct. Then the endianizing code that I added has to modify it in place in the struct. It would be much better if we actually did segregate the code and ended up with a clean interface, but right now that's not what we have. This is definitely an area where we could stand to see a *lot* of improvement. Btw one example of where I think we _do_not_ need a fixed size type: uint32_t i; for (i = 0; i x; ++i) doSomethingWith(i); I hope we both can agree here, that this code really does _not_ need the fixed size guarantee (only a minimum size guarantee, because `i` needs to be able to hold `x`). Yes, we can. So in this example case I personally think code like this is better (a tiny little bit more readable as well): unsigned int i; for (i = 0; i x; ++i) doSomethingWith(i); I don't know that it's more readable, but it's not problematic. This kind of variables and most temporaries used to contain arithmetic results, are the main ones I'm thinking of really. That's fine by me. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jun 3 17:51:56 2007 New Revision: 1440 URL: http://svn.gna.org/viewcvs/warzone?rev=1440view=rev Log: * turn some usages of WinAPI types (*WORD) into their native C counterparts (e.g. int, unsigned int, etc.) Are you sure about that? Int and unsigned int vary in size according to the ABI. It is far better to use integers of a known size that will not change according to the system you are on. uint32_t and int32_t, for instance. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
Am Sonntag, 3. Juni 2007 schrieb Ari Johnson: On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jun 3 17:51:56 2007 New Revision: 1440 URL: http://svn.gna.org/viewcvs/warzone?rev=1440view=rev Log: * turn some usages of WinAPI types (*WORD) into their native C counterparts (e.g. int, unsigned int, etc.) Are you sure about that? Int and unsigned int vary in size according to the ABI. It is far better to use integers of a known size that will not change according to the system you are on. uint32_t and int32_t, for instance. As long as you stay on the same system that should not matter, should it? Eg. if that int never reaches the borders of your system (via file or network), then it should be perfectly legal to use them... --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On 6/3/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 3. Juni 2007 schrieb Ari Johnson: On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jun 3 17:51:56 2007 New Revision: 1440 URL: http://svn.gna.org/viewcvs/warzone?rev=1440view=rev Log: * turn some usages of WinAPI types (*WORD) into their native C counterparts (e.g. int, unsigned int, etc.) Are you sure about that? Int and unsigned int vary in size according to the ABI. It is far better to use integers of a known size that will not change according to the system you are on. uint32_t and int32_t, for instance. As long as you stay on the same system that should not matter, should it? Eg. if that int never reaches the borders of your system (via file or network), then it should be perfectly legal to use them... Except that much of our code *does* reach a file or the network. As long as you contain it and are certain that the minimum size of the type on any system will always be enough for what the code at hand requires, then it's fine, but I have seen a few places in our code where lack of clarity on what size a given variable was caused me headaches in porting to the Mac. Just be careful. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On Sun, 03 Jun 2007 15:03:14 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 3. Juni 2007 schrieb Ari Johnson: On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jun 3 17:51:56 2007 New Revision: 1440 URL: http://svn.gna.org/viewcvs/warzone?rev=1440view=rev Log: * turn some usages of WinAPI types (*WORD) into their native C counterparts (e.g. int, unsigned int, etc.) Are you sure about that? Int and unsigned int vary in size according to the ABI. It is far better to use integers of a known size that will not change according to the system you are on. uint32_t and int32_t, for instance. As long as you stay on the same system that should not matter, should it? Eg. if that int never reaches the borders of your system (via file or network), then it should be perfectly legal to use them... --Dennis It would be much safer to use u/int32_t, since nobody knows all functions that are use by network code. Then all 32 vs 64bit systems may have problems later on. -- Click to get free info on kitchen remodeling at 50% - 70% off http://tagline.hushmail.com/fc/CAaCXv1MQyEbZdLpv91jw1OiYAK4ALz5/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev