Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUDs
➜ General
➜ Integer types
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Baron Sengir
USA (29 posts) Bio
|
| Date
| Tue 17 Nov 2009 12:21 AM (UTC) |
| 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 | | Top |
|
| Posted by
| Zeno
USA (2,871 posts) Bio
|
| Date
| Reply #1 on Tue 17 Nov 2009 12:30 AM (UTC) |
| 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 | | Top |
|
| Posted by
| Baron Sengir
USA (29 posts) Bio
|
| Date
| Reply #2 on Tue 17 Nov 2009 12:40 AM (UTC) |
| 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 | | Top |
|
| Posted by
| Nick Cash
USA (626 posts) Bio
|
| Date
| Reply #3 on Tue 17 Nov 2009 12:49 AM (UTC) 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 | | Top |
|
| Posted by
| Baron Sengir
USA (29 posts) Bio
|
| Date
| Reply #4 on Tue 17 Nov 2009 10:57 AM (UTC) |
| 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 | | Top |
|
| Posted by
| Wjmurdick
(13 posts) Bio
|
| Date
| Reply #5 on Tue 17 Nov 2009 01:20 PM (UTC) |
| 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. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #6 on Tue 17 Nov 2009 02:54 PM (UTC) |
| 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 | | Top |
|
| Posted by
| Baron Sengir
USA (29 posts) Bio
|
| Date
| Reply #7 on Thu 19 Nov 2009 12:17 AM (UTC) |
| 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 | | Top |
|
| Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
| Date
| Reply #8 on Thu 19 Nov 2009 02:18 AM (UTC) |
| 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 | | Top |
|
| Posted by
| Wjmurdick
(13 posts) Bio
|
| Date
| Reply #9 on Thu 19 Nov 2009 12:06 PM (UTC) |
| 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).
| | 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.
28,270 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top