Am 15.04.2018 um 15:28 schrieb Bald Eagle:

> Having a dual code where one is "newbie friendly" for extensive debugging would
> allow the "advanced/expert version" to run quickly without any such trammels.
> 
> Less speedy but easier to code/maintain would be to have whole sets of dual
> subroutines that can be selected with such a flag.  One slow, but rich in
> information and feedback messages, the other optimized for speed.

Actually no -- quite the opposite: That would be more difficult to maintain.

It would be a comparatively easy job to pepper the source code with
checks that can be turned on or off at compile time, and then build one
binary with the checks and one without.

Having duplicate versions of individual code to be selected at run-time
would introduce a host of challenges and drawbacks:

- It would require some mechanism to branch to one of the two code
variants, introducing extra processing overhead even to the
high-performance path and making the code more difficult to read.

- It would require to actually maintain the two codepaths in source
code; naively, this would mean maintaining two copies of the code,
making sure to port any functional changes between the two, while also
making sure /not/ to port the intentional differences.

- In a less naive approach, the problem of keeping the codepaths in sync
could be greatly simplified by some meta-programming approach, but these
come at a dear cost: Implementing each function as a huge C-style
preprocessor macro would severely "uglify" the code and make debugging
impossible; C++-style templates /can/ be debugged, but only with
difficulty; and using a dedicated meta-programming tool to generate two
separate C++ "source" code files would solve most of the debugging
problems, but make it more complicated to just try out some changes,
while also making the whole project significantly more difficult to
understand for new contributors.

- Either way, it would increase the overhead involved in bug reports:
Most people don't even report the full version number in their first
post; now we'd also need to know what code path they had chosen.


We actually do have some experience with alternate code paths in POV-Ray
chosen at run-time, namely the various optimized noise implementations.
Fortunately, the noise code is comparatively small and very stable, and
has also undergone extensive unit testing by professionals from AMD and
Intel respectively. Otherwise it would probably a maintenance nightmare.

There's also the root solver, which can be switched between sturm and
non-sturm in some primitives. Again, the job of the root solver is
pretty limited in scope and well-defined, and the implementations are
pretty mature.

Post a reply to this message