Refactoring stdcpp.list.d to remove duplications #19
Conversation
some of the functions have no difference in the interface structure on all our target runtimes so these have been moved out of any version compilation as they increase duplications in the API. they are removed from all three runtimes and just represented by a single interface since they are linkable and callable from C++ without any foreign additions
Emmankoko
force-pushed
the
dup
branch
3 times, most recently
from
2160a43
to
b3ac92e
Compare
These ones have been moved to todo lists because as at now, D cannot call C++ templated member/nested functions and so for future improvements. we fix reference issues as well
|
The trouble with merging all the common code is when it the common code gets updated for operating system X, it doesn't get tested against other versions (and sometimes it is impractical to do those tests). This happens again and again with merged implementations for diverse systems. By not having merged code, then the expert on X can freely work on the version for X without being concerned about other systems. Experts on other systems can merge those changes into their version blocks as necessary. This methodology dramatically reduces the introduction of regressions. Also, the person chasing down a bug in X's implementation benefits from not being distracted by a snarl of versions (which is typical of C .h files). The D lexer is very fast, there is no speed purpose to merging similar code. I'm sorry, but it's a no for this. |
|
I think I totally agree with you on the future implementation changes by the vendors and its effect.. but I thought this through because a change in implementation in any version of say.. But I think I can be agreeing with you on the case of 'Anything can happen'. |
most functions have common interfaces on all our target runtimes and so they have been removed to get only one interface representing under no conditional compilation block.