On Thursday, 26 February 2015 at 00:54:57 UTC, Walter Bright
wrote:
On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:
It does annoy me that I can't comment on the exceptions case,
...
COM is also an excellent candidate for consideration. If COM
works
well, then I imagine anything should work.
Microsoft's latest C++ presents a model for this that I'm
generally
happy with; distinct RC pointer type. We could do better by
having
implicit cast to scope(T*) (aka, borrowing) which C++ can't
express;
scope(T*) would be to T^ and T* like const(T*) is to T* and
immutable(T*).
Microsoft's Managed C++ had two pointer types, and it went over
like a lead zeppelin.
This is not true for those of us working on Windows.
It just got replaced by C++/CLI, which was an improved version
based on feedback about Managed C++.
The main difference was the removal of double underscore prefixes
and making the keywords semantic. The multiple pointer types are
still there.
https://msdn.microsoft.com/en-us/library/ms379603%28v=vs.80%29.aspx
Maybe it failed the goal of having C++ developers fully embrace
.NET, but it achieved its goal of providing an easier way to
integrate existing C++ code into .NET applications, instead of
the P/Invoke dance.
The same syntax extensions that became the foundation of the
second coming of COM, aka WinRT and is at the kernel of Windows 8.
Specially because this,
"Creating Windows Runtime Components in C++"
https://msdn.microsoft.com/library/windows/apps/hh441569/
is way simpler than this
"Creating a Basic Windows Runtime Component Using Windows Runtime
Library"
https://msdn.microsoft.com/en-us/library/jj155856%28v=vs.110%29.aspx
It might happen that with C++14 and Windows 10, C++/CLI and
C++/CX will become irrelevant, but until then, they have been
useful integrating C++ code into .NET and Store applications.
--
Paulo
