[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUDs
. -> [Folder]  General
. . -> [Subject]  Integer types
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
Integer types

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Posted by Baron Sengir   USA  (29 posts)  [Biography] bio
Date Tue 17 Nov 2009 12:21 AM (UTC)  [ quote  ]
Message
Could anyone give me a quick explanation on when it is best to use the different integer types? Multiple sections of the code use different types (int, sh_int, long) and I am curious as to when it is best to use each one (in ROM). It appears that a lot of sh_int and int are used just for simple integers to be stored, while the long looks like it is used a bit more often for storing the flags (immunities, vulnerabilities, parts, etc). Should I go along with this and stick to sh_int and int (most of my variables to be stored in pfiles are VERY low, usually below 20 or so) and figure out how to utilize the long integers only if I decide to do something along the lines of making a new type of flag?
Baron Sengir
aka Co-Admin/Head Coder of "Dark Ages: Legendary Secrets"
Currently in R&D Phase
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Reply #1 on Tue 17 Nov 2009 12:30 AM (UTC)  [ quote  ]
Message
http://www.space.unibe.ch/comp_doc/c_manual/C/CONCEPT/data_types.html

sh_int = short, typically "maxes" around 32k.
int = integer, typically "maxes" around 2.1bil

This all depends and isn't exact, but you get the idea. If you expect the number reach 32k and higher, use an int.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] top
Posted by Baron Sengir   USA  (29 posts)  [Biography] bio
Date Reply #2 on Tue 17 Nov 2009 12:40 AM (UTC)  [ quote  ]
Message
Great info on that site Zeno. Fairly self explanatory (as for how high/low the values of each type can go), which sums up and answers my question. I'll just use sh_int for the most part (I don't see many, if any at all, of my variables stored to files to reach +-32K). Many thanks!
Baron Sengir
aka Co-Admin/Head Coder of "Dark Ages: Legendary Secrets"
Currently in R&D Phase
[Go to top] top
Posted by Nick Cash   USA  (626 posts)  [Biography] bio
Date Reply #3 on Tue 17 Nov 2009 12:49 AM (UTC)  [ quote  ]

Amended on Tue 17 Nov 2009 12:51 AM (UTC) by Nick Cash

Message
The naming and usage of integers in Diku derivatives has always been sporadic and strange, though some of that may be because some of the software is very old.

In general, Zeno is correct. If you plan on a number going over ~32k you will want to use int, otherwise sh_int should be fine.

In a professional environment you would see more discretion (well, I would hope you see more, but I'm an embedded systems programmer so it actually matters to me) as to which you use. Each integer also has an unsigned variant that will remove signage from your number, giving you a larger range starting from 0. Below is a brief description in case you don't want to wade through the link Zeno posted.

Typically the layout is thus:

char = 1-byte, values -127 to 128, 0-255 unsigned
short = 2-bytes, values -32,768 to 32,767, 0-65,535 unsigned
int = 4-bytes, values -2,147,483,648 to 2,147,483,647, unsigned 0-4,294,967,295

Most people writing serious code will have a types file that accounts for system variations (such as what long's stand for :) and generalize them to:

sint8 / uint8
sint16 / uint16
sint32 / uint32

sint being signed int, uint being unsigned int.

This takes some of the guesswork out. More or less you should always pick the smallest possible choice for your problem, which helps you be efficient with your memory and track down errors.

As you will see, though, now that RAM is huge, people are very careless and just throw int's at everything. For hobbyist projects like MUDs that may be fine (and you'll see it everywhere in your code base), but if you want to become a decent programmer try to keep these rules in mind.

I would say you should error on the side of unsigned integers (as most systems do), but that would probably cause a lot of type issues in many of the more common MUD code bases these days.

~Nick Cash
http://www.nick-cash.com
[Go to top] top
Posted by Baron Sengir   USA  (29 posts)  [Biography] bio
Date Reply #4 on Tue 17 Nov 2009 10:57 AM (UTC)  [ quote  ]
Message
I have been trying to keep my code as memory friendly as possible, hence me looking for ways to clean up and compact the code as I go along. I believe I will be fine with short integers for anything new I plan, thanks to the info and clarifications you guys have given me. Another question comes to mind about the unsigned integers now. Very rarely will I have any value in my code that will be negative, and so I can definitely see the advantage of going with an unsigned short integer (to give me larger overall number to work with). But that would mean I would have to track down and reassign each and every variable that I already have to an unsigned integer, as well as checking each function that calls or manipulates those signed sh_int and int and make modifications to each of those in turn, would it not? If so, do you think it would really make that much of a difference memory-wise currently, or should I add this to my 'to-do-once-I'm-a-better-coder' list?
Baron Sengir
aka Co-Admin/Head Coder of "Dark Ages: Legendary Secrets"
Currently in R&D Phase
[Go to top] top
Posted by Wjmurdick   (13 posts)  [Biography] bio
Date Reply #5 on Tue 17 Nov 2009 01:20 PM (UTC)  [ quote  ]
Message
Well, switching from uint to sh_int would usually save you 2 bytes per conversion. Word versus 1/2 word.

But, the tradeoff is that CPUs are naturally designed to handle words (not 1/2 words) and so in many cases internally they may pad the sh_int. So you may save memory, but you may increase cpu usage.

Course, neither is likely to be very noticeable (memory or cpu to be honest).

Use of sh_int in MUDs is simply a hold-over from the days when RAM was severely limited and you had to optimize and save every bit you could.

IMHO the better place to work on saving memory in traditional MUD code would be to work on replacing statically defined arrays with something else such as a linked-list or vector from the STL. That way you would have less memory usage up front and your data-storage could grow and shrink as you needed it to.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #6 on Tue 17 Nov 2009 02:54 PM (UTC)  [ quote  ]
Message
Wjmurdick said:
IMHO the better place to work on saving memory in traditional MUD code would be to work on replacing statically defined arrays with something else such as a linked-list or vector from the STL. That way you would have less memory usage up front and your data-storage could grow and shrink as you needed it to.

Agreed. Structure padding -- when the compiler adds bytes to avoid the alignment problems wjmurdick was talking about -- can remove most gains from messing with data types, however there are a lot of big, static arrays that could be allocated dynamically and thereby save a fair bit of space.

That said, if you're storing 64-bit integers when you only need single bytes, and you're storing a lot of these, you can still get good savings by using better data storage. But this is relatively unlikely in a MUD.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Baron Sengir   USA  (29 posts)  [Biography] bio
Date Reply #7 on Thu 19 Nov 2009 12:17 AM (UTC)  [ quote  ]
Message
That sounds good. For starters Ill try to have my newly created arrays set as dynamic. I'll take a look and see if any of my arrays can be altered like that. I am pretty sure most of my defined static arrays use all of the assigned memory, but it can't hurt to check again right? :) Anywho, thanks again for the info.
Baron Sengir
aka Co-Admin/Head Coder of "Dark Ages: Legendary Secrets"
Currently in R&D Phase
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Reply #8 on Thu 19 Nov 2009 02:18 AM (UTC)  [ quote  ]
Message
If you want to be more efficient, and you are using C++ rather than C, you should take a look at the Standard Template Library (STL).

Diku-based MUDs are littered with stuff like this:


skills.c:   char buf[MAX_STRING_LENGTH];
skills.c:      snprintf( buf, MAX_STRING_LENGTH, "a burnt %s", food->pIndexData->name );


(MAX_STRING_LENGTH is 4096).

Now really, for a printf like this, is the name of the food really going to be something like 4080 characters long? I think not.

The string type in STL can dynamically grow to allow for however much data you have in it, so it is much more efficient for storing string data, rather than just allocating 4096 bytes and hoping for the best.

Similarly, the vector collection type lets you store arrays without having to decide in advance some arbitrary number of elements as your maximum.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Wjmurdick   (13 posts)  [Biography] bio
Date Reply #9 on Thu 19 Nov 2009 12:06 PM (UTC)  [ quote  ]
Message
Quote:
Similarly, the vector collection type lets you store arrays without having to decide in advance some arbitrary number of elements as your maximum.


Agreed, the Vector data structure in the STL is one of my best friends when working with C++. Being able to push/pop, but then turn around and access individual elements like an array using an index ([]) is good stuff.

Quote:
The string type in STL can dynamically grow to allow for however much data you have in it, so it is much more efficient for storing string data, rather than just allocating 4096 bytes and hoping for the best.


Two other great benefits of using the string data type are a) you don't have to worry about the null terminating character when modifying the string's size and b) it has lots of great functionality already built in (find, replace, swap, length, etc).

[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

2,918 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]