CalcManager Packaging
Problem Statement
Currently, CalcManager/CalcEngine is implemented in C++ as part of Calculator. Some teams may want to reuse it as an independent library package. Besides, if we want to convert Calculator App to C#, we need to wrap the CalcEngine in C#.
Evidence or User Insights
Potential Consumers
Proposal
Concepts
| Package Name |
Description |
| Ratpack |
Rational Package - to do arbitrary-precision rational math calculation |
| CalcEngine |
Abstraction of the calculation and commands used in Calculator |
| CalcManager |
Integration of different CalcEngine modes (Standard, Scientific, ...) |
Functional Requirements
- Calculator Engine
(accept operator/operand commands and calculate the result to display)
- Arbitrary-precision rational calculation
- Expression parsing *
- Localization support *
- Customizable aliasing (e.g.
arcsin v.s. inverse sin v.s. sin^-1) *
- Expression evaluation *
The requirements with star (*) are not implemented yet, but will be published eventually.
Usage Requirements
CalcEngine will be consumed by ourselves and 1P teams thru NuGet package.
For us, we need a C# wrapper for CalcEngine, because we will do C# conversion for Calculator App.
In sum, we have the following usage requirements:
- Independent NuGet package
- C# wrapper
Portability Requirements
OS
Languages
Implementation Requirements
Ratpak and CalcEngine are implemented in C++, which won't be changed.
- Maintain Ratpack and CalcEngine in C++
- CalcEngine should remain in the Calculator repo
Design Proposal
Choice of Packaging Techniques
To enable interop between C++ and C#, we have 3 choices:
- Expose C API from C++
consumed by C# thru P-Invoke
- Expose COM components from C++
consumed by C# thru COM
- Expose WinRT components from C++ thru C++/WinRT
consumed by C# thru C#/WinRT
Comparison
|
C API |
COM |
WinRT |
| Supported Platforms |
All |
Windows Only |
Windows Only |
| Supported Languages |
All thru FFI |
All with great efforts |
C/C++/C#/Rust/Python with WinRT library All with great efforts |
| Programming Paradigm |
Procedure-oriented |
OOP |
OOP |
| Development Experience |
Easy😊 |
Painful😱 |
Medium😐 |
| Community Engagement |
Widely used |
😒 |
Not popular yet |
| Error Handling |
Catch all explicitly and return error code |
Catch all explicitly and return HRESULT |
Catch all implicitly by C++/WinRT library and return HRESULT |
CalcManager Packaging
Problem Statement
Currently, CalcManager/CalcEngine is implemented in C++ as part of Calculator. Some teams may want to reuse it as an independent library package. Besides, if we want to convert Calculator App to C#, we need to wrap the CalcEngine in C#.
Evidence or User Insights
Potential Consumers
Proposal
Concepts
Functional Requirements
(accept operator/operand commands and calculate the result to display)
arcsinv.s.inverse sinv.s.sin^-1) *The requirements with star (*) are not implemented yet, but will be published eventually.
Usage Requirements
CalcEngine will be consumed by ourselves and 1P teams thru NuGet package.
For us, we need a C# wrapper for CalcEngine, because we will do C# conversion for Calculator App.
In sum, we have the following usage requirements:
Portability Requirements
OS
Languages
Implementation Requirements
Ratpak and CalcEngine are implemented in C++, which won't be changed.
Design Proposal
Choice of Packaging Techniques
To enable interop between C++ and C#, we have 3 choices:
consumed by C# thru P-Invoke
consumed by C# thru COM
consumed by C# thru C#/WinRT
Comparison
All with great efforts