Maxim wrote:
I wanted to use advantages of both languages in one project.
A solution is like a big project. You don't have to switch projects
during development. You can hit Ctrl+B and build all the component
together. You can debug across module (project) boundaries.
Tha fact is that UI is
much more simplier to develop in C#. On the other hand C++ is the best
choice to write the calculation algorithms.
That makes a lot of sense.
But i don't want to wrap C++ code in dll, if this is possible.
So you don't like DLLs. Is that a self-imposed rule, a customer
requirement, or an order coming from your company? In .NET it is farily
typical to develop several independent modules. Modularity has numerous
advantages. It reduced unnecessary inter-dependencies between unrelated
parts of your application, eases testing and maintenance of large
projects, fosters reusability and collaboration. It even increases
stability, as you're not required to constantly recompile already stable
modules.
..NET DLLs are standalone, self-descriptive, strongly versioned
components. Although the extension is still ".dll", they have nothing to
do with what used to be known as the DLL-hell.
Note that C# will not be able to consume ISO C++ classes. In most cases,
you'll have to wrap them, it's not an option. C# doesn't know what to do
with C++ constructs like std::vector, std::string, or boost::shared_ptr.
C++/CLI was designed to bridge the gap between the two worlds.
I heard a lot of the .NET's language independence
This is true for CLR types, but not necessarily for ISO C++ ones. .NET
languages are fully aware of managed objects, and they can also call
native C-style functions, but C++/CLI is the only language that can
directly use ISO C++ code.
Tom
