Suggestion: rectangle_t and rect_t typedefs
Reporter: time-killer-games | Status: open | Last Modified: August 25, 2020, 05:03:15 pmBasically, idea is to make a special typedef for std::string and call it rectangle_t. This data type can have its values parsed with functions we could provide in enigma_user, something like this: http://cpp.sh/4smsc (but those calls to exit(1) and cout/endl can be replaced with a DEBUG_MESSAGE with M_INFO severity). Then, there could be yet another data type we could add that doesn't use strings but rather a typedef of a struct with the name rect_t. This one could be used for more common tasks that don't require the slow string parsing. The members of the rect_t struct would be an unsigned int width/height and a signed int x/y.
I wanted approval of this idea before making a pull request. The pull request will be split into two parts. The first one will add the string parsing logic functions to estring.h along with the string typedef rectangle_t. Then I'll add to that pull request the struct rect_t someonewhere else, probably wherever we put our math related functions in universal system.
The second pr will be slightly unrelated but on a similar topic - I will do some general type fixes to our window related code, the first thing that comes to mind is we are using a signed int for width/height in some places when it should be unsigned. That may or may not be the only thing to do with the latter pr. Anyway, what are your thoughts on this guys?
I've just started upgrading the syntax checker. I upgraded it a few years back to use a proper tokenizer; now I'm updating it to use a proper AST.
This will put us in a position to support complex structure types. Now is indeed the time to start talking about what we would like rect_t
, vec2_t
, vec3_t
, vec4_t
, quaternion_t
, matrix_t
, polygon_t
, array_t
, etc, to look like, and how they should play with the existing API.
It would not be good to use a string for these types. Serializing numbers to/from string would be very expensive. However, we can discuss serialization logic for printing, IPC, RPC, etc.
I was actually going to use this for my video player extension for video_set_rectangle. I've noticed using std::map with integer values will sometimes give some random number as the default value when uninitialized, (instead of zero), outsize of the reasons i listed for adding this already, I was going to use these functions as a workaround to that issue by using a string in the std::map instead. If you don't like that idea I'll see if I can find a better approach.