Without knowing what you're aiming at, what the requirements are and so on,
the whole discussion would stay abstract, which for me is pointless and
without any real application.
The .Net framework is released as standard with XP, and it's hard not
getting it on your system if you have 2K.
MS Office 2003 actually is built on .Net so it is a requirement.
If you know C++, then MFC is simply some libraries to assist in what you're
trying to accomplish. I was educated with Borland's Builder and found it
harder to figure what was actually going on under the hood. This is one
benefit of .Net. To get a C# application up and running is trivial, and you
have complete control over everything. The transition from C++ to C# was a
relatively easy one since OOD was something that was engrained in my brain
through my education.
If there's no requirement for the application to be written in an
application, it still comes down to what you want that application to do.
Java's great for cross platform systems, but falls over on Windows based
OS's simply from a performance and effienceny perspective.
I've come from a Builder background, then learnt VC++ and MFC, finally
moving onto .Net and feel, in terms of the work I do, there's no comparison
with the tools, power and ease that .Net provides. Again someone elses
scenario may suit a different set of technologies, it revolves around the
requirements.
"- HAL9000" <gu***@mail.org> wrote in message
news:78********************************@4ax.com...
I don't think I have a "language goal".
After doing some investigation it appears as though switching to
C++Builder is the best move. This seems to minimize total effort -
both up-front and down the road.
The (1) new program language learning curve is less with CBuilder
than what it would be for MFC. I already know C++ and I don't know
C#. And (2) code can still be developed quickly since many
components/widgets are offered in both IDE's. In fact C++Builder
looks like it offers more widgets.
A side benefit is a potentially easy port to Linux in the future as
well by just transporting to CBuilderX.
It seems like the .NET framework is the cart before the horse. Unless
you can easily demand customers install the framework, it is useless.
When the framework is pre-installed in the OS (Longhorn) things will
be different.
Can you imagine MS requiring the .NET framework installed before you
could install Office 2003 or other new MS program. How about
requiring it with winXpSp2? I don't think so! MS isn't going to
require it - yet they expect its software development customers to
require the framework.
On Wed, 27 Apr 2005 13:21:24 +0100, "Dan Bass" <Not Listed> wrote:
Your question is a bit flip sided.
On the one hand you want an "easy as possible" windows application, yet
you
want to ensure it's not hard to port to MFC? Surely the fact that it's
easy
to start with means porting it from that point shouldn't be any problem.
If the application is not trivial, then I'd suggets sticking to the
language
which you want to end up with. C# is strictly OO, where C++ and MFC sort
of
sits in the middle of the road between procedural and object orientation.
These differences could fundamentally influence your design strategy.
If you're eventual goal is MFC, start it in MFC, applications are quick
and
easy to knock up there and the time spent porting from a .Net (Managed
C++,
C# or Vb.Net) to MFC on any application passed "Hello World" will not be
worth the effort when compared to the minimul time you'd save in .Net
knocking up an application.
Hope that makes sense.
Thanks.
Dan.
"- HAL9000" <gu***@mail.org> wrote in message
news:tq********************************@4ax.com. .. Hello,
Background:
I am familiar with VB.NET, vanilla C++, and Pascal but not Csharp.
Please confirm/comment:
If I want to get a windows application running quickly (and minimize
total effort), and have the eventual goal of porting back to MFC (that
is, no .NET requirement), should I write the application in Csharp
initially? I read a comment on a web page that suggested that this
sort of porting back may be easy to do in VS 2005. I don't know...
Dichotomy:
It seems as though another option is a managed C++ project. In that
case I would tackle MFC now and thus not have to eventually port back.
Other:
Another option seems to be to adopt Trolltech's Qt which seems to
have the luxury of no porting back to MFC, or to Linux.
Thanks...
