Driving forces
Posted: Sun Aug 20, 2023 6:26 pm
- Platform Separation
With modern versions of C++, there is little need for OS specific things other than in networking, and console io. So those will be wrapped and ideally isolated from the rest of the code.
- Use of Char*
There is not a lot of reason to use C style strings for much of uox code. Ideally std::string (or a variant) will be used. This also eliminate another platform difference in terms of some of the lower level C string functions.
- Creation of frequently used "utility" functions.
There are several commonly needed functions (such as string manipulation to split, parse, lower, trim, etc) and a few others. In addition
some common lower level types are used. These will be separated out, into a utility directory (and namespace), as common, reusable (outside uox as well) items.
- Data sizes
UO was defined in a time during memory constraints, and low network speeds. So data was constructed to minimize sizes. However, in the world of 64 it processors, maintain that size through out processing is not necessary beneficial (as the processor works on 32 or 64 bits natively). So the data sizes will mainly be significant when reading/writing to packets. Otherwise, int (or uint if needed) will be the common data size used. This should simplify a few overflow concerns for some processing.
- Types
One of the things that is present in UOX3(or the lack of use is present), is the lack of Project defined types. I believe this mainly due to is C origins. Uox will define a set of small components (types), that have the ability to described themselves in a text format(and back). The goal, would be to modularize the code and promote standardization in input/output.
There is also a lot of ENUMS used in UOX3. However, there is not a standardized way to describe those enums in text format (and back). That is another area where I want to focus.
These types should not be confused with the use of "typedefs". The modern use of "using = " will be used, to aid in indicating the "type" of data that is being constructed, not just the size.