Posted by
Jens Thiel on
Jul 17, 2002; 5:14am
URL: http://quantlib.414.s1.nabble.com/Re-Some-questions-tp10129p10130.html
> Another thing, I noticed that a .NET module, which appears to
> be a re-implementation of QuantLib in C#, has been created. I
> would like to
> know what are the goals of this project and how the collaboration
> between the
> two development efforts is going to work.
I also have some time available now, and I started the .NET project last
week, and continued yesterday. I agreed with Nando to be ahead a week or so
before officially announcing the availability of the module.
Initially, QuantLib.NET will be a proof-of-concept, a replacement for our
existing COM wrappers around the C++ version, and a personal dive into .NET
technology and also the existing QuantLib.
I collected the following items as "goals" (see references at end):
# deliver a working QuantLib implementation targeted to the
CLR in platform-independent code
- support CLRs on different platforms (eg mono[1], rotor[2][3])
- maybe supply native optimizations after profiling since
you can easily merge namespaces from multiple assemblies
# Use C# instead of managed C++
- a test implementation in managed C++ was not so "nice"
(don't know if I should check this in)
- I personally find C# more productive for .NET development
- better .NET and VS.NET integration than C++
- forced to write plattform-independent code
- free implementations available from MS[4], mono[1] and
rotor[3]. You can use Emacs+make or alternative free
IDEs like SharpDevelop[5]
# follow .NET guidelines for class libraries and integrate
smoothly in the .NET world
- bring in experiences from COM development
- use common interfaces, events and delegates
- allow to easily access data from different sources
- supply parameterless ctors and factories for COM
(also come doesn't like overloads)
# Support COM interop to make QuantLib.NET available in eg.
Excel (97+), Access (97+), VB6 and others
# Intensive unit-testing and examples
# For the future:
- Generate web services and support XML
I can generally see some problems here
# we have to give up templates for now (but generics
will be available in a future .NET release (see
papers at m$ research)
# syncing C++ and .NET development will be the hardest
part, but having unit tests can help a lot
# performance; but we can substitute critical code
with native implementations. We may also see improved
JIT compilers in the future.
I think I will ask Nando to announce the .NET module at the beginning of
next week, but early feedback is always welcome! If there is sufficient
interest I'll also try to update the CVS more frequently (but don't
complain, it's currently mostly untested code...).
With the beginning of next week, current snapshots will be available for
download, so you can start using .NET instantly with eg. Excel.
Please post your questions or comments. I would also like to discuss some
architectural issues like mixing of managed/unmanaged code, since I am new
to .NET for myself.
Jens.
References (as usual, must be on one line)
[1]
http://www.go-mono.com/[2]
http://www.oreillynet.com/pub/a/dotnet/2001/06/27/dotnet.html[3]
http://msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/901/msdncompositedoc.xml
[4]
http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml
[5]
http://www.icsharpcode.net/OpenSource/SD/default.asp