Post by Ioannis VranosIt looks like you are missing a crucial fact. CLI (and MS .NET) was not
created for C#, but to be a *multilingual* environment.
If you consider using different words for the same things to be
"multilingual" you are right. This is what I'm referring to as C#:
C# essentially exactly exposes the layout and capability of .Net's
object model. You can replace C# by VB.Net and do exactly the same
as in C# except that you are using a notion which resembles more
VB. I'm in no way in the position to judge the language bindings you
have listed other than C# and VB.Net because I haven't looked at
them but I'm pretty sure that they are essentially C# using the look
and feel of the respective languages. Depending on their original
object model, this may fit more or less. For example, I would expect
that Eiffel and Java (the language, apparently the class system is
ignored) can be mapped without much changes while Smalltalk and
Python programmers may be more comfortable with the respective .Net
version than with C# but would not really consider the .Net version
to be an implementation of their respective language - unless the
.Net versions of these language also rely on non-standardized features
of the underlying VM in which case they become as useless as C++/CLI.
Returning from guessing and focussing on C++/CLI again: I don't care about
the "managed" portion of C++/CLI because I can already use a semantically
equally powerful language, C#, to express this stuff. The advantage of
C# is that it does not use abominations forced into a language with an
inherently different object model than C#: the C++ object model does not
really fit the .Net object model at all. There are portions which are
similar but even these don't really fit. As a consequence, C++/CLI
mutates C++ even at the very core, namely when it comes to pointers and
references. It also retains the original C++ stuff but essentially using
any of those will render the resulting assemblies non-portable. As a
consequence, C++/CLI is a complete non-option to people concerned about
the portability of their applications. ... and to make things plain: it
is not really my choice to desire portability! It is a necessity because
my customers use a variety of platforms and it is typically not really an
option for them to change - or, put differently, if I would not support
their platform, they would choose a different provider who supports their
platform.
Post by Ioannis VranosThat means that
whatever you can do with C# you will be able to do with other languages.
Yes but it will do me no good anyway: first of all, none of the language
bindings I looked at leaves the original language unchanged. That is, I
have to learn a new language anyway. Although it may resemble what I'm
already used to, it has the inherent danger of luring me into believing
that I know what is going on when I actually don't. Thus, I'm better off
learning a new language and its associated semantics anyway. ... and this
does not only apply to me but to everybody. I know that many people are
really learn resistant but just pretending that this is OK is not a
solution as it will introduce subtle problems. That is, the solution is
not to make these people comfortable but to get rid of them (yes, I am an
asshole if comes to people who refuse to move on and learn something new).
That said, I can see that offering people something they feel more
comfortable with is appealing to many. Personally, I have different reasons
to be appealed by the .Net environment, namely that it provides a
standardized platform (this does not apply e.g. to the Java VM as I don't
consider the definitions imposed by one company to be a standard) with quite
a few desirable features. However, I consider the abilities of this platform
exposed in their typical languages (i.e. C#, possibly in the instance of
being labeled to be actually a different language) to be inferior to what
I'm used to. Sure enough, I can [at least conceptually] realize everything
on this platform which I can realize in C++ but I prefer to do it the C++
way. My complaint about C++/CLI (excluding the process how it is created) is
essentially, that it does not let me program for .Net in the C++ way -
portably.
... and there is no point in pointing me to a gazillion of languages
available for .Net or to pretend that there is a standard for C++/CLI. I
think I have a pretty firm grasp on what this stuff is all about and I'm
already using it. Essentially I'm just pointing out that the world is not
as nice as the advertisement is saying it is. That is, you are ****** if
you use C++/CLI beyond the managed parts although this is where the power
of C++/CLI lies and the remainder of C++/CLI has no real relation to C++
at all, despite its name. Whether C++/CLI is a service or disservice to
the C++ community will depend strongly on whether assemblies using stuff
outside the usual managed stuff will become portable or not.
--
<mailto:***@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]