TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

Portability issue? Array indexing variables

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
Slysven



Joined: 10 Apr 2011
Posts: 365
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Tue Feb 14, 2012 3:38 pm    Post subject: Portability issue? Array indexing variables Reply with quote

Reading up (to refresh the grey matter between my ears) I came across the recommendation that for optimum portability (and we know that TinTin++ is run on a wide variety of platforms Smirk ) variables used to manipulate arrays, for example, should be declared as of type 'size_t' rather than 'int', 'unsigned int', 'long int' etc. and that when doing maths with them the results should be stored in variables of type 'ptrdiff_t'.

This is already in gcc compilers, although there was a brief time in the past where size_t defaulted to a 'signed int' in common situations, this was rapidly corrected to the unsigned type that it should have been.

I found this article which expands and explains it better than I can: http://eetimes.com/discussion/programming-pointers/4026076/Why-size-t-matters

I note that we are currently using 'ints' for manipulating the ses->map->room_list[] array, and I'm certain there are other cases. I guess this is something to go onto the todo list as well? Cool

PS. #MAP CREATE 10 produces a map with space for ten rooms which are numbered, not surprisingly 1 to 10, but the 'C' code in which TinTin++ is written uses an array of pointers to those rooms and 'C' numbers its arrays starting at 0 not 1, so by rights we ought to be able to have a room with 0 as its vnumb. On the other hand we have been using -1 as an invalid or 'error' value for some functions that return a room number (which should change to the unsigned size_t type) so that becomes problematic; logically then we should use 0 as the error case?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue Feb 14, 2012 9:07 pm    Post subject: Reply with quote

vnum 0 is reserved as the error case, though the design assumes an error free map. I guess I can change -1 to 0, I'll check out the link when I have time.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group