Re: porting from C++Builder

Daniel wrote:
You should be aware that Microsoft is no longer promoting C++/CLI as
a
language
for .NET GUI applications, just for interfacing to native C++ code.
C# is really recommended for GUI code. You can use it for GUI code,
but you may regret it.

yes, that's correct and there is a very strong reason for taking this
position. the reasons is not entirely technical. the reason got his
roots in
late 90s. the java was growing and, obviously, microsoft initially
tried to
do their best to make every single java developer a better life when
programming in java, under windows. but the treat of having crowds of
developers raising questions like "if my program runs the same
everywhere,
why would i wanna stay in windows, that means that my skills are
portable"
and this simple idea, java as a platform, write once run everywhere
was
something to make microsoft do something about! so far so good. now,
after
almos 13 years, we realize that sun's java campain was smoke and
mirrors.
that java didn't run all that well anywhere, that it left behind a
huge trace
of "so and so code" and despites everything looked so good (better
c++, implementation inheritance) in reality java suffered from the
less common denominator syndrom (of not really running well
anywhere). but microsoft felt
the treat and reacted in the most normal way, i would you would you
name it.
they stopped investments in java, especially after the very same
anders
finished windows foundation classes, a better java, the father of .net
framework and we all know what happened. microsoft got inspired by
many and
they made their own programming language, in this case, c#,
architected by
the one of the most brilliant minds of the 20st centuries (anders).
.NET
meant a better life for all windows programmers and give microsoft
the chance they've been looking for, to offer a new opportunity a new
practical reason
that crowds of developers would rather stay and develop windows
applications. .NET was a better java! a finally, native and
unrestricted JAVA, being able
to actually fulfill real life, daily, practical needs for so many, in
the industry. and that mattered! whatever java was missing, c# (and
.net/cli) did have, true support for properties, object oriented
support of intermediate assembly, true windows support, and instead
of cross platform, offered cross language interoperability. the
crowds reacted and in a way, it makes perfect sense not to certify
C++ developers, since these guys know so much, that
their systems certify themselves! on the other hand, in mfc (and
later on in
atl) you see a bizare mix of the most advanced C++ features
(templates,
multiple inheritance) coupled, mixed together with horrible
(completely unnaceptable, type unsafe) c preprocessor macros, so
horrible and
innapropiate that they make one wonder... it's legacy, it was the way
to go,
a long time back, they've been accepted for aparent simplicity, when
in fact,
the C++ language supposed to get true support for properties, events,
etc in order to offer true COMPONENTNESS to the masses (just like BCB
dialect, and
VCL, never fully ported to C++ did once). Even today, the 0x upcoming
C++ standard say NOTHING about support for properties and events

I agree with you, but how about the combination of std::function/std::bind for
events? This is the way to go in C++ 0x (and with older compilers you have
boost)... (yeah I know... std::function is not the fastest implementation...but
it exists :-)
For properties it's easy to build a property class using templates.
C++ is too flexible (and complex) to avoid (in general) adding every
favorite feature into the core language, just build a library :-)
Of course, there are a lot things that could be better if the language is
enhanced, but this is not the case, at least in my opinion.


(true
componentness) for the simple reason that the ANSI C++ comitee is 99%
politics and 20 years old technical agendas (spliting hairs instead of
actually doing what the crowd need). from this point of view, c# is
definitely better, vb as well was alligned, keeping some familiar
feel and
touch and the impression that still feels like the old days, etc.

i am adding all these words, trying to give you the reason microsoft
recommends c# instead of C++ for most cases, especially when it comes
to
inhouse programming for data entry forms, fat client applications,
etc.

what will happen with C++ is another story. i sure hope that microsoft
realized that an entire segment of developers (the industry standards
via mfc crowd) maybe desearved a smother life, in terms of porting
their applications into the 21st century. on top of that, i bet that
a lot of expenisve
marketing analysis show that one of the reasons unix still exists (in
one
form or another) is the fact that many people can reuse their
existing skills (mostly in c and c++) over decades. then it's the
issues of still running applications writen tens of years ago, et
cetera, et cetera, et cetera.

you recommended, possibly, a complete rewrite in C#. this sentense
tells me
that you most likely deal with systems under a million lines of
source code (10k, 20k, etc)

for the rest of us, porting legacy applications of high complexity to
C# is
as impossible (read funny) as deciding not to use English in
business, but esperando...

thigs just don't work that way, not in this time and space. that WHY,
if you
pay attention, you will see microsoft (we do) remembering that there
is an
entire market segment of legacy MFC apps (interesting VCL and BCB
belong to
that segment as well, except that the C++ dialect in BCB does have
full
support of properties and events and an anternative framework which
still
feel fresh even after almost 13 years) - so, they remembered that
crowds of excellent developers, dealing with super complex C++ legacy
code, could not possibly migrate, not over night to .NET. some of
them do, but others just
had to keep those systems running, offering whatever features their
users
needed, on daily basis.

another category is commercial software applications. .NET runtime
did not
always exist everywhere. sometimes, in certain commercial
applications, raw performance is essential. in other applications,
security is very important.
and i am not talking about security in general, but precisely about
the level
of confidence that your native, fully compiled and encrypted and
compressed
code, could not be reverse engineered because the cost of this would
be
higher than the cost of simply rewriting it.

i know, .NET offers a full range of obfuscators, sometimes, entire
apps are dressed into a native stub, instantiating the managed stuff
in memory, it's a looooong story. i do know about JITs, about the
strategy of actually bringing manged code at the level of "native"
code, but there are places where native
code is needed, and the (so hard to get) skills of C++ programmers
will
always be fully rewarded.

so, it's commercial software (in a box). then drivers. then system
level development, anti viruses, security software, even legacy
enterprise applications, then development tools, reality cannot be
put in a box and go
like "hey, this is better, it's my way or the highway" - it simply
doesn't
work that way.

So, David, if you pay attention, you should be aware that most
recently, Microsoft started to actually pay attention to this market
segment. I
recently received my MSDN Magazine (October 2008, vol 23 no 11)
containing an invitation to best practices, october 27-30, 2008,
hynes convention center, boston, ma). Do yourself and other a favor
and take a look at that flier.
It's mostly C++!!! NATIVE C++!!! Among speakers, you see his
excellency herb sutter, even the "god" of C++ bjarne stroustrup
himself, embarassing everyone about the lack of properties and events
support in the new upcoming C++0x standard (which will take another
20 years of dog fights to get to the market :-) No disrepect! But
don't you see a pattern here? I would! And I do not
think that this is about "hey, my language is better than yours" (i am
personally fluent in about 20 programming languages, frameworks, etc)
but
about the Microsoft's realization that the world we live in is
getting to the point of general acceptance at standard levels, for
languages, frameworks,
one day even component models (unrelated to framework's definition)
and even kernels! so, C++ has definitely a good place and will still
secure an
excellent position, for at least our life time! well, if this is the
case (just like the reality of global economy, village, you name it)
it's time for Microsoft to realize that and take the world again, by
storm, and win! just
like they always did and we did, with them as well. I remember a
yellow flier I've got in late 80's from Microsoft, it said like that:
do you wanna know
who is the most important person at Microsoft? Well, open it! and
inside it
said simply "YOU ARE!"

So is here and now.

Let's hope for the best, I am super confident that the most brilliant
minds
in the known universe will find a way and we'll get all better and
better,
day by day, as developers, business men, managers, owners,
consultants, in a
way, we are all a part of Microsoft and the other way around, right?

Have Fun, Follow your Joy,
Daniel

--
Cholo Lennon
Bs.As.
ARG







.

Relevant Pages

  • Re: porting from C++Builder
    ... the java was growing and, obviously, microsoft initially tried to ... that crowds of developers would rather stay and develop windows applications. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: porting from C++Builder
    ... that's correct and there is a very strong reason for taking this ... the java was growing and, obviously, microsoft initially tried to ... that crowds of developers would rather stay and develop windows applications. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: C# is a proprietary programming language ??
    ... I initially thought that C# is an ECMA standard as Microsoft submitted to them. ... It is open to everyone to create a compiler for C# or anything. ... Example, rpg language. ... > Java tried this too, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C History (was: null terminated strings)
    ... Java again, this time as a server language. ... Microsoft Transaction Server and convince everyone to pretend they ... created the design. ...
    (comp.os.vms)
  • Re: C# is a proprietary programming language ??
    ... >> Java tried this too, ... >> so when Microsoft added some extensions to the language to make it ... >> Of course, if you write code in C# on Windows, you can't run it on UNIX. ...
    (microsoft.public.dotnet.languages.csharp)
Loading