Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c

2007-06-04 Thread Giel van Schijndel
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

2007-06-04 Thread Giel van Schijndel
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

2007-06-04 Thread Per Inge Mathisen
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

2007-06-04 Thread vs2k5
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

2007-06-04 Thread Ari Johnson
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

2007-06-03 Thread 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.

___
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

2007-06-03 Thread Dennis Schridde
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

2007-06-03 Thread Ari Johnson
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

2007-06-03 Thread vs2k5
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