Re: Future of MFC?

In article news:<eWZULgU$HHA.3940@xxxxxxxxxxxxxxxxxxxx>, Giovanni Dicanio
wrote:
I think that there are some "architectural" differences between
native and managed, that make it easier to develop high-quality tools
for managed world (.NET) than native (C++/MFC).

You are absolutely right that it's easier to make the tools for .NET, but I
don't see that as any reason not to provide tools that are just as good and
that target native code -- which pretty-much means C++, in the Windows
world, now that Microsoft have abandoned native code generation for all the
other languages they support.

I think that .NET reflection is one of the good technologies
that help having better tools for .NET

Runtime reflection is a very useful technique -- and it certainly does make
it easier to generate tools -- but it's not essential. I rather dislike
reflection (my experience of it is mostly through Java rather than .NET, but
the principle is the same) as it leads to inefficient code, and does not
enforce type-safety.

There are several papers about on why reflection should be considered
harmful. Google should find a few very quickly.

I think that reflection and type information in .NET are also
important ingredients for the development of .NET components (C++ with
ATL seems much more hard work to me, IMHO).

NET and Java frameworks use reflection to discover properties about a
control at runtime. Code designers for such frameworks typically use the
same reflection techniques to discover a control's properties and methods
(at (the designer's) runtime) so that they can render and use the control.
This is nothing new: it's (an extension of) the same trick that IDispatch
interfaces in COM support.

There are other ways of providing this sort of information -- one might
envisage embedded metadata within a control that would be used by the
designer code to determine the control's interfaces and capabilities, and to
enable the designer to generate code that called the interfaces natively
without any need for runtime reflection in the generated application. It's
not rocket science.

I wonder if some C++ guru could implement reflection in C++, too, using
e.g. some template-based "magic"...

The nearest equivalent of reflection in C++ is RTTI, which allows the type
of an object to be discovered at runtime, and allows an object to be queried
to see whether it can be downcast to a particular interface ... of course,
the interface in question has to be known at compile time, so its not much
use for determining the capabilities of interfaces exposed by arbitrary
libraries dynamically-linked at runtime.

David C. once proposed here about a compiler switch to consider "char" as
Unicode ...

It is a given in both C and C++ that sizeof(char)==1. That's a fundamental
assumption that's enshrined in so much behaviour of the standard runtime
libraries that pretty-much nothing would work if you broke it.

In Windows apps you can include the tchar header and use preprocessor magic
to toggle the definition TCHAR between char and wchar_t -- without losing
the ability to refer to each explicitly -- so there's not really very much
reason to want to redefine char.

The problem with C++ is the "legacy", the need to support old or
cross-platform libraries, etc. [*]
[snip]
[*] However, support for legacy code (to be mantained) and for
cross-platform libraries development, are also some of the real
strengths of C++.

Absolutely!

... in .NET they can just have one string type, while in C++ we
have a lot (too much...) string types ...

Yes, true, but you don't actually need to use all those string types in any
one application ... if you're not using legacy code you can largely ignore
the raw-pointer string types (LPCTSTR, etc) except to call C APIs, and if
you don't use COM you can forget all about the various BSTR-based types.
That only really leaves CString and/or std::string.

... errors because of CStringA/W mismatch...

If people don't know the difference between wide and narrow char strings
there's not much that can be done to help them in ANY language or framework.

In fact, one of the cool things when a new technology (like .NET) is
invented, is that there is no legacy, and the designers are free to take
the best parts from several different worlds, and put them together in
harmony, and make new choices learning from the errors of the past, and
being free to innovate.

Yup, the .NET implementors have it way too easy. <smile>

So in .NET we have concepts like component-software (from VB6,
without the complexity of COM and ATL...), the idea of event-handlers and
properties (from VB, again), the garbage collector (from Java), the
templates (from C++ ...

Yes, you said it, these "cool" new things are all taken from other tools
that did them without the advantages of being able to start with a clean
***. In fact, none of .NET is actually new (any more than anything in Java
is) ... what's new is that it's all been bundled together and that Microsoft
have spent a small fortune building tools to make it easier to use.

Now all I want them to do is to spend another small fortune building
equivalent tools for a platform I actually care about -- native C++ (with or
without MFC).

... .NET "generics" seem to me different from C++ templates - for
example, I don't know if advanced things like template
meta-programming or Boost could be done in .NET...), etc.

No, .NET generics are just that -- generics. You can't do metaprogramming
with them. OTOH if you're using C++/CLI you can use all the power of C++
metaprogramming in .NET code just as you can in native code.

Cheers,
Daniel.



.