learn C++ or C#

  • Thread starter Thread starter Daniel
  • Start date Start date
Assuming that you want to write GUI applications for Windows, you
ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.
Click to expand...

WTL still wasn't officially supported by MSFT the last time I worked with it
(3+ years ago now). There was also no documentation. A quick check and it
still doesn't appear to be supported. This may or may not affect someone's
decision to use it but it is a serious consideration. I do agree however
that it's better than MFC which I abandoned in favour of WTL. Note however
that ATL is incredibly arcane and very difficult to master. It's not for the
weak and most programmers can't handle it. People who care about the
integrity of their programs should seriously consider other choices before
choosing it (and there aren't many unfortunately).
 
Ben said:
ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.
Click to expand...

Ben:

Yes, I think about this sometimes. But I am not sure that WTL provides as many
features as MFC, and it is not supported by Microsoft, which makes me nervous. I
also have a huge investment in MFC, both in knowledge and code base. I wish MFC
were more elegant, but I have gotten used to it.

If this old programmer is going to learn something new, I think it's going to be
C# and .NET.
 
I had forgotten the proper terminology. I meant to ask whether C# was a low
level language to the same extent as C++.

Daniel
 
ok. Thanks.

Giovanni Dicanio said:
I'm a .vc guy :-)



I agree with that.



Moreover, if you want to build Windows shell extensions, you should use
C++.

If you want crossplatform code, you should use C++ (with proper libraries
like wxWidgets for the GUI).

If you want to build small .exe's easy to deploy (no need of huge runtime
to distribute), you should use C++ (with CRT/MFC/ATL statically linked).

If you learn C++ first, then moving to C# is a very easy path, as others
wisely wrote.
Instead, the opposite is not true.

Both languages have pro's and con's: choose the better tool for your
particular job.

Giovanni
Click to expand...
 
What is MSI? What do you mean by "MSI custom actions"?

Daniel

If I haven't made substantial investment in either C++ or C#, which
language
would the experts recommend I become well acquainted with?
Click to expand...

By the way, one reason why a .NET developer might want to learn C++ or
at least C is to be able to write MSI custom actions for installers
(while it's possible to create managed actions, there is a number of
issues and technical difficulties associated with them).
 
Thanks.

David Wilkinson said:
Daniel said:
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Click to expand...

Daniel:

As you are posting in dotnet groups, you should know that there are
actually three languages

C++
C#
C++/CLI

Up to now you have been using C++/CLI, which is the wrong choice if you
want to write GUI Windows applications, because Microsoft no longer
recommends C++/CLi for writing GUI .NET applications.

Assuming that you want to write GUI applications for Windows, you need a
library.

If you use native C++, you will probably want to use the MFC library
(which does not come with VC Express. by the way). MFC is old, and not
very elegant, and has quite a learning curve. But there is a huge base of
available code samples for it, and Microsoft is once again working on
improving it (after many years of neglect). MFC is not portable to other
platforms, but if you separate the back-end of your application from the
GUI, you can port the back-end to other platforms such as MAC/linux. For
me, one of the advantages of going the MFC route is that you can use
static linking, which means that you can deploy without installing any
components on the target machine.

[Note that the main newsgroups for standard C++ are
microsoft.public.vc.language and microsoft.public.vc.mfc]

If you use C#, you will use the .NET library, which is more elegant, and
probably easier to learn than MFC. If you go this route, you need to make
sure that the appropriate version of the .NET framework is installed on
the target system.

There are also hybrid methods, where you write your back-end in standard
C++, the GUI in C#, and build an interface layer using C++/CLI. This may
be appropriate if you have a large amount of legacy C++ code, but it means
you have to learn and understand three languages.

Feel free to ask more questions. This is an important decision, and you
should be sure you make the one that is correct for you.
Click to expand...
 
A good implementation plan is to write your back-end code -- the
business logic of your application -- in a fast portable language (such
as C++) so that it can be built to run on the maximum possible number of
platforms, and then to write a GUI wrapper around it for each platform
on which you want to ship ... you might choose to write such a GUI
wrapper in C# for a Windows version of your software, though other
possibilities (including VB, Java, Python, etc) exist.
Click to expand...

I disagree about the "business logic in C++" part. In practice,
standard C++ tends to be too low-level, verbose, and overcomplicated
for many common patterns that arise when developing a typical business
layer in many desktop and LOB applications. I'd still recommend C# for
that.

Leave C++ for tightly optimized algorithm implementations, device
drivers, shell plugins, MSI custom actions, etc.
 
I disagree about the "business logic in C++" part. In practice,
standard C++ tends to be too low-level, verbose, and overcomplicated
for many common patterns that arise when developing a typical business
layer in many desktop and LOB applications. I'd still recommend C# for
that.

Leave C++ for tightly optimized algorithm implementations, device
drivers, shell plugins, MSI custom actions, etc.
Click to expand...

On the low level stuff. What exactly is the "lowest" level in Windows
C++. I don't mean assembly or machine language. I mean if I wanted
to know how graphics are really drawn on the screen. What would I
look at? I know I can use C++ to createwindow or something like it,
but how is it doing it? Is that part in C or C++? Is that the hidden
source code that Microsoft uses?

Thanks.
 
David said:
Ben:

Yes, I think about this sometimes. But I am not sure that WTL
provides as many features as MFC, and it is not supported by
Microsoft, which makes me nervous. I also have a huge investment in
MFC, both in knowledge and code base. I wish MFC were more elegant,
but I have gotten used to it.
Click to expand...

I guess I didn't actually say "for new C++ code". I meant to though. There
are certainly good reasons to keep an existing MFC application as MFC that
probably outweigh any benefits of WTL.
 
First, let's straighten out some terminology: I don't feel that there's  
any such thing as "Windows C++".  C++ is a language, Windows is an  
operating system with an API (or, a lot of different APIs, depending on  
how you look at it :) ).

The majority of the Windows API has nothing at all to do with C++.  It's  
all accessible by C or other similar purely procedural, non-OOP  
languages.  Even where the Windows API starts to look like C++ (e.g. COM,  
GDI+), you can in fact get by without C++ albeit with more complicated  
code (since you have to write explicitly the things that C++ would do for 
you).

So it's important to be clear about whether you're talking about the  
Windows API and if so what part, or if you're talking about a language and  
if so, why it is a particular language is of particular interest.


That's a pretty vague question.  The most literal answer is "the graphics  
driver".  That's the part of the operation system that actually interfaces  
directly with the video hardware, and it's the only thing that really  
knows "how graphics are really drawn on the screen".


CreateWindow() doesn't draw graphics.  It just sets up an OS object that  
provides for a specific kind of way to draw graphics.


How is what doing what?  That's a lot of pronouns without any clear  
antecedent.

Pete
Click to expand...

How is a windows drawn on the screen? Is that where the OS provided
APIs come in (we don't need to know how they work)?
 
Ben said:
I guess I didn't actually say "for new C++ code". I meant to though. There
are certainly good reasons to keep an existing MFC application as MFC that
probably outweigh any benefits of WTL.
Click to expand...

No, I'm certainly not going to rewrite my existing MFC applications. But even if
I were to start a new GUI application, I would probably go with MFC because I
know what to do, and have a bunch of supporting code ready to go, etc.

To use WTL or C#/.NET I would have to learn a bunch of stuff, and of the two I
think I would go with C#.

Fortunately most of my consulting work is cross-platform non-GUI C++, si I do
not need to worry about this. The code is developed in Visual Studio, but runs
as a console application in various linux/Unix systems, as well as Windows. My
client also wraps it in C++/CLI for Windows GUI with C#, but I am not
responsible for that.
 
Actually, VB.NET usage has surpassed C#. Thought I would point that out,
this came from a forester survey if memory serves me correctly.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium?
http://msmvps.com/blogs/alvin/Default.aspx
 
Peter said:
The majority of the Windows API has nothing at all to do with C++. It's
all accessible by C or other similar purely procedural, non-OOP
languages. Even where the Windows API starts to look like C++ (e.g.
COM, GDI+), you can in fact get by without C++ albeit with more
complicated code (since you have to write explicitly the things that C++
would do for you).
Click to expand...

COM in C sounds as about as much fun as 1000 meter swimming with
50 pounds of lead ...

Unlike Win32 API then COM is intended for C++ (or other OO language).

Arne
 
Pavel said:
By the way, one reason why a .NET developer might want to learn C++ or
at least C is to be able to write MSI custom actions for installers
(while it's possible to create managed actions, there is a number of
issues and technical difficulties associated with them).
Click to expand...

There are several type of code where C++ is either better or
plain necessary.

But is "write MSI custom actions for installers" really a common task ?

Arne
 
Ken said:
A lot of the .net framework is directly from Microsoft. A lot is
implemented a totally different way.
Click to expand...

AFAIK then no code at all in Mono comes from Microsoft.

Arne
 
Alvin said:
Actually, VB.NET usage has surpassed C#. Thought I would point that out,
this came from a forester survey if memory serves me correctly.
Click to expand...

There were indeed a Forrester report claiming that.

But it does not match very well with what people observe. Try search
for C# and VB.NET at your favorite job site and see how many hits
you find. There are practically always about twice as many C# jobs as
VB.NET jobs.

Arne
 
Actually, VB.NET usage has surpassed C#. Thought I would point that out,
this came from a forester survey if memory serves me correctly.
Click to expand...

There are no hard statistics anywhere I'm familiar with that can
definitively say who's winning the battle. It would be very difficult to
measure. The IDS (Income Data Services) organization may have something
useful to say on the subject, I don't know. They are very well-known in the
employment research field and produce a lot of statistics on these matters
in general. IIRC they claim there were 6 million C++ developers in 2004 for
instance. Id 'be interested in what they may have to say on the trend to C#.
In any case, there are also sites that gather informal information on the
subject. See here for a few examples:

http://www.langpop.com/
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://gigaom.com/2007/09/07/top-10-programming-languages-of-the-future-you-voted/

These sites provide mixed and sometimes contradictory info on the subject
(some even negative for C#). Note that references to VB can be misleading
however since since it's more entrenched than C# (having been around for
longer) and doesn't necessarily mean VB.NET. In any case, in my experience
(having worked for a lot of different companies), I see the move to C# far
more often than VB.NET. It's an informal observation only but that's my
personal take on it. If you even look at the number of postings in MSFT's C#
NG for example, C# always has more daily postings than VB.NET and VC.NET put
together. Or try Googling for .NET job postings. C# gets top-billing in
almost most cases. These may be empirical observations only, but it's hard
to ignore them.
 
Back
Top