lcn2
commented
1 year ago Request closed. User prefers to work on their own copy of the code.
Closed kcrossen closed 1 year ago
lcn2
commented
1 year ago Request closed. User prefers to work on their own copy of the code.
Project goal is to package calc as a Qt/C++. "GUIable" object, so for example, cross compilable into iOS or Android apps.
Current solution is NOOP-ing all keywords that give calc access to the host operating system. These keywords are likely to be interpreted as "unknown function" syntax errors. This must, at minimum, include all directory/file manipulation keywords, but it's hard to imagine how reading/writing from/to stdin/stdout/stderr could even be supported. Instead, there is a C++ object interface, a keyhole so to speak, with methods to pass executable code as text to calc's interpret/execute core, methods to retrieve results (or side-effects) as either user readable text or as the text form of the internal numerator/denominator representation, methods to retrieve errors (typically as user readable text messages), and so forth.
This object must also "thunk" between the null-terminated, DIY memory managed calc text and Qt's memory managed string objects. Memory leakage (only possible on calc side) is detected (because memory is checked out/in explicitly) and flagged via an error method. (All calc internals that can allocate/deallocate memory are instrumented.)
Aside from "console applications", likely a tiny minority of Qt applications, there is no mechanism for compiled applications to communicate text with the user except via screen real estate explicitly created by the developer. Similarly, to affect the host OS file system requires explicit code by the developer. Classic-calc, on the other hand, can delete/modify host OS directories/files via an executed explicit cal file or via a cal file that covertly assembles executable text that can delete/modify host OS directories/files.
To support this feature and current calc in the same code base may involve some complexities. For example, calc-classic (with all of its host OS capabilities) as a wrapper around the proposed object may complicate parsing if the two "layers" are to be absolutely church-and-state. Alternately, it may be handled via two different compile/link chains w/ internal conditionals.
With respect to APCalculator, most of the calculator exists inside the calc object, e.g. the RPN stack (if in RPN mode), builtin or app or user defined functions, abstract Newton's method machinery, etc., etc. What's external is the UI which triggers submission of cal code to calc object, displays the resulting states of calc-internal items, the history recorder, and a help display system.