Josh @ Dreamland
|
|
Posted on: May 18, 2013, 05:48:14 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Here's a question to think about while we're moving shit. A lot of functions take specific types of objects as input. This hasn't been a big problem so far, because all objects have been 2D. When users go 3D, the tier [snip]object_planar[/snip] will need swapped out for a hypothetical [snip]object_spatial[/snip], which implements an x, y, and z. We're going to have cast issues out the ass one way or another, but I think it'd benefit us to have some community discussion before anything big happens. Ideally, we could solve this by moving functions such as motion_add into the object_planar class. But thanks to our friend, [snip=edl]with(){}[/snip], this is, as usual, completely off the table. That said, I think we can still use vtables to help mitigate issues, like so: - Class object_spatial and class object_planar extend class object_positionable, which has a virtual $add_motion
- Each child class, object_planar and object_spatial, implement a motion setter for two and three dimensions, but object_planar ignores the given z coordinate.
If we do this, cast checks can be eliminated for engine code, and errors can be reported for assigning z-motion in a 2D object in debug mode (possibly only when a certain flag is set, like -pedantic or -w-wrong-fucking-dimensionality). Other functions, such as those in extensions, would either have to do cast checking or use the virtual methods from object_positionable to be able to whore the vtable. By the way, let me make one thing clear: if your code contains [snip]dynamic_cast[/snip], you are doing something wrong. Rule of thumb. Any thoughts, suggestions, or visions of disastrous issues with the proposed or existing systems are welcomed. Cheers
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Goombert
|
|
Reply #1 Posted on: May 19, 2013, 05:45:41 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
I really don't have an opinion as I said it is quite fuxd up and I would like to be able to inherit no locals or have an option for that.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Josh @ Dreamland
|
|
Reply #2 Posted on: May 22, 2013, 07:58:34 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
forthevin: You reading this? It seems you've begun migrating [snip]#define[/snip]'d functions to [snip]enigma_user[/snip] by rewriting them as regular functions that call the original. That's, in general, a good idea, but it breaks overloads. Would you be interested in a parser macro specifically designed to alias a function in ENIGMA's compiler? You'd call something like [snip]$ENIGMA_alias(random_integer, irandom)[/snip], and it would create a duplicate definition in the current scope. Just an idea.
Otherwise, we'll have to stick with macros for the time being. Or worse: alias all overloads. Not a fan of that idea.
I don't mind macros, because what we're avoiding is C++ definitions that conflict with user code, not user/ENIGMA code that conflicts with C++ definitions.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #4 Posted on: May 22, 2013, 01:45:00 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
My only bitch with macros is that the syntax checker will sound stupid. The code will read [snip=edl]irandom(1,2,3)[/snip] instead of [snip=edl]choose(1,2,3)[/snip], and the checker will bitch, "Too many arguments to function `random_integer': expected at most 2, provided 3". That might confuse the fuck out of people, or they might assume that ENIGMA is a mind-reading sentient. Either way, it's a little tacky.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
forthevin
|
|
Reply #5 Posted on: May 23, 2013, 01:35:17 pm |
|
|
Joined: Jun 2012
Posts: 167
|
I looked through the commits containing the migration to enigma_user, and it seems that the only [snip]#define[/snip]s I touched was the ones in the mathnc.{cpp,h} files.
You have a good point regarding the confusing renaming and errors. As for whether the overloads should all be aliased, or a parser macro should be implemented instead to handle it, they would give the same result for the user if I understand things correctly. I decided to try to estimate how many overloaded [snip]#define[/snip]'d user functions we have. I searched for them using "grep" ([snip]grep -R '#define [a-zA-Z_][a-zA-Z0-9_]* [a-zA-Z_][a-zA-Z0-9_]*$' *[/snip]), and after filtering out false positives, I ended up with 16 candidates, and it turned out 1 of them was overloaded (namely the [snip]#define irandom random_integer[/snip] case). While I am not certain that the search have caught all overloaded [snip]#define[/snip]'d user functions, I do believe it gives a good guess of how many overloaded functions there are. So, given that there seems to be very few overloaded [snip]#define[/snip]'d user functions, I would propose that we alias the non-overloaded as well as the overloaded ones, unless we find/write more overloaded [snip]#define[/snip]'d user functions.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #6 Posted on: May 23, 2013, 02:41:22 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
By aliased, I assume you mean [snip]#define[/snip]'d? There is another way we have aliased function in the past, but it might not bode as well with [snip]-flto[/snip] when I finally get around to passing that flag. I believe we did it for [snip]make_color[/snip]; we just used [snip=edl]int (*const make_color)(unsigned char,unsigned char,unsigned char) = make_color_rgb;[/snip], which, as you know, copies the function pointer to a new variable. I'm not really a fan of this, as I believe it forces the compiler to make both functions use CALL, but I could be mistaken (especially if we add a [snip]const[/snip] in after that asterisk).
I am personally fine with macros, at very least for now.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Josh @ Dreamland
|
|
Reply #7 Posted on: May 23, 2013, 02:42:33 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Is it just me, or is that snippet tag a bit ugly? Maybe I'll add a teletype tag in the near future.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
polygone
|
|
Reply #8 Posted on: May 23, 2013, 07:26:34 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
I thought draw_get_pixel was added as a macro. Is it just me, or is that snippet tag a bit ugly? Maybe I'll add a teletype tag in the near future.
I always thought it was ugly but you seemed to like it.
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
forthevin
|
|
Reply #9 Posted on: May 24, 2013, 05:30:07 am |
|
|
Joined: Jun 2012
Posts: 167
|
Josh, sorry about the confusion regarding aliasing, I meant aliasing them by writing an inlined function. Given that there seemingly are very few overloaded [snip]#define[/snip]'d user functions, I don't think using inlined function will be much work or be very verbose.
In regards to function pointers, that is still the way it is implemented in the OpenGLES graphics system, while it is implemented through inlined functions in all the other graphics systems. I agree with you about the function pointers, it is not the best option. One thing I am wondering about is whether a template could be used to do the inlining and avoid the issues with a macro. But I still think simple inlined functions should be sufficient for our needs. If things change, we can always reconsider.
Regarding the snippet tag, I don't think it is bad when used for proper C++ code, but it doesn't look nice with Unix commands or the defines.
polygone, draw_get_pixel is indeed added as a macro to draw_getpixel, but draw_getpixel is not an overloaded function, so it would be easy to use an inlined function instead.
In regards to 3D objects, it would be very nice to have them at some point. One issue that I see with the proposed solution is that not all functions are easy to extend. For instance, move_contact_* and move_outside_* take directions as arguments. Would an extra directional argument be provided for the 3D object, such as a latitude-direction? That question also depends on how the 3D object is represented in object_spatial. An alternative to generalizing the different functions dependent on object_planar is to create 3D versions for them to use with the 3D objects instead, but that has some issues as well.
I also have another question, namely how the user should switch between 2D and 3D objects. Will it be switchable as a subsystem in the editor for all objects? And will the switching internally be implemented as a subsystem, or implemented some other way?
|
|
|
Logged
|
|
|
|
|