04 Mar, 2011, RoFAdmin wrote in the 1st comment:
Votes: 0
Hey eveyone-

So I'm looking at Roms buffering system, and its leaving me with a few observations id like to make, and questions id like to ask and get some feedback on from people who might be just a tad more familiar with it then i am. Some of the observations may seem obvious, but i have follow up questions.

This is a version of Rom that has been upgraded to C++ in case anyone gets confused when i start asking about using std::string

Observation 1: The whole concept behind it is that you need to store a large amount of string data somewhere, that is larger then your typical max_string_length, and it appears to be using predetermined sizes.

Observation 2: Pretty much the buffering system is used to store output that is going to be written to the client before it is actually written.

Observation 3: The buffer has 3 states. SAFE. OVERFLOW. FREED pretty much telling you the buffer is safe to use and read from, the buffer is overflowing, or the buffer has been freed and put into the free pool.

So my questions.

1) First one obviously is, are my observations pretty much correct?

2) Is there any finer intricacies of the buffer system that im missing?

3) Wouldn't just switching the output buffer of a character to an std::string simplify the issue? Since you can simply append the additional data onto the string without worrying about the string getting to big? Plus you simply just create and destroy the buffers on demand since i see no real need for the pooling system rom uses to begin with. Just seems simpler to me no?

4) What complications or annoyances could come from switching the system to using std:string?

5) Do you think it would be a solid choice to move the buffer system to this? why or why not? and do you have a better idea?


Thanks in advance guys. I'm sure ill get some good input.
Ill be gone till Sunday so no responses from me till then, but I've had this and a few other questions rolling around in my brain so i figured i might as well post em up to have some good reading when i get back. Might have a few more posts coming as well.
04 Mar, 2011, David Haley wrote in the 2nd comment:
Votes: 0
std::string isn't necessarily designed for lots of small appends and taking data off of the beginning. If you were very performance sensitive (you probably aren't) you would care about that, because it would be allocating and freeing memory without really needing to.
04 Mar, 2011, Tyche wrote in the 3rd comment:
Votes: 0
RoFAdmin said:
1) First one obviously is, are my observations pretty much correct?


Well the first is suspect. For the most part these strings have a short lifetime, so I wouldn't say it's designed to store large amounts of strings. There are shared string implementations in other muds, like Envy, that are designed to do that. Part of the functionality is pretty much what string class does. It dynamically increases the size of a string as you add to it, up to the limit you've decided (in the stock code that's 16K).

RoFAdmin said:
3) Wouldn't just switching the output buffer of a character to an std::string simplify the issue? Since you can simply append the additional data onto the string without worrying about the string getting to big?


There is a limit to the size of a C++ string, string::max_size. It's implementation dependent. But note this value in modern systems is often ridiculously large, so functions in the mud dependent on the notion that buffers have a small size limit, like socket descriptor buffers might cause you problems.

RoFAdmin said:
Plus you simply just create and destroy the buffers on demand since i see no real need for the pooling system rom uses to begin with. Just seems simpler to me no?


Like everything, it depends. The ROM system never frees memory. It's a high water mark system. Freeing a buffer just marks it available for future use.
Custom allocators and memory pools are often reimplemented in many C++ applications rather that just new/delete all over the place.

RoFAdmin said:
4) What complications or annoyances could come from switching the system to using std:string?


Just the caveats above. Don't assume string functions won't throw exceptions due to size. C++ strings may also contain NUL, Buffer assumes NUL is string terminator.
Random Picks
0.0/3