-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typified editmap #73713
Typified editmap #73713
Conversation
The code won't link, but I can't figure out why. It linked fine as long as I forgot to include the new header file in line.cpp (with a complaint that the new function should be static if it didn't have a header). However, when I included the missing file there's a whole range of errors from xmemory claiming tripoint_bub_ms doesn't match any instantiation of the tripoint template. |
Co-authored-by: Jianxiang Wang (王健翔) <qrox@sina.com>
Is there some syntax to tell the code checker that yes, there is an unused parameter here, but it has to be there? Edit: Testing a syntax that shouldn't be legal based on how dummy pointers are used in override operations. We'll see if that appeases the style demons. |
I think the correct solution would be providing different specializations when the
I guess it might have been done that way to ensure |
I tried to define two templates with different profiles, but that's thwarted by the default parameters that result in both of them matching all the usage, and thus making it ambiguous. I don't understand C templates, but it seems you toss out some text and the compiler tries to match whatever to it, so there wouldn't be any way to specify you only want point derivatives, or only tripoint derivatives. I can be wrong, of course, but my attempt failed. I don't see why placing code in coordinates.h would provide anything that a coordinates_operations.h including both line.h and coordinates.h wouldn't. Headers have no use for the line operations, and so would benefit from being able to include just the definitions of the specific types, without the code baggage that also drags additional header file baggage with it. |
I think you can use
|
I've tried to figure out how to use enable_if, but to no avail (I've tried a lot of different permutations, and none seem to work). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to work. The std::enable_if
ensures that only one template declaration is valid for point
and tripoint
.
Co-authored-by: Jianxiang Wang (王健翔) <qrox@sina.com>
Co-authored-by: Jianxiang Wang (王健翔) <qrox@sina.com>
Co-authored-by: Jianxiang Wang (王健翔) <qrox@sina.com>
Co-authored-by: Jianxiang Wang (王健翔) <qrox@sina.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Thanks! I'm in the middle of testing another PR, but expect to get there during the day. |
Summary
None
Purpose of change
Changed untyped (tri)points to typed ones. This time focusing on editmap.h/cpp.
Describe the solution
Go through the code and figure out what types the untyped stuff is. Change it and update used operations to work.
Describe alternatives you've considered
Testing
Additional context
It got messy with line, as introducing typed operations resulted in circular header copying. Addressed that by introducing a new header file containing the typed operation while the actual implementation remains in line.cpp.
The implementation is ugly, because the bresenham stuff generates a vector, and so cannot easily be coaxed into generating a vector of a typed type, nor is it an easy conversion to deal with the resulting vector.
I suspect it can be dealt with via modern macros ("lambda"?), but I can't do it.
It can also be noted that there are other cases where side header files may be needed to avoid circular dependencies, and this may be needed for future conversions (earlier conversion has worked around these issues by converting the result from the untyped implementation. I have a vague feeling that bresenham has caused this kind of trouble earlier).