learn C++ or C#

[Daniel]

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

Daniel

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

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).

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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Giovanni Dicanio wrote:

"Daniel James"

>C# targets a virtual machine
architecture , so C# programs can run only on computers for which such a
runtime (a JIT compiler or an interpreter) is available -- that means
Windows, certainly, and platforms that support Mono (an Open Source
NET-compatible runtime);

I've heard about Mono before. But I wonder: what is the level of
implementation of Mono?
Is Mono as robust as the Microsoft .NET framework implementation?
Does Mono fully support C# 3?
Does Mono fully support .NET Framework 3.5 ?

http://mono.ximian.com/class-status/
http://www.mono-project.com/Mono_Project_Roadmap

should provide you with some info.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Alvin Bruney [ASP.NET MVP] wrote:

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

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

[Giovanni Dicanio]

[David Wilkinson]

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.

Do you know if it is possible to throw native C++ exceptions from the C++
layer, and directly catch them at the C++/CLI or C# layer?

Or must the C++/CLI layer catch all native C++ exceptions (like those
derived from std::exception) and rethrow them in a different form, derived
from managed base exception class System.Exceptio n ?

Thanks,
Giovanni

[Daniel James]

In article news:<#Q******* *******@TK2MSFT NGP03.phx.gbl>, Daniel wrote:

I had forgotten the proper terminology. I meant to ask whether C# was

a low

level language to the same extent as C++.

The short, quick, easy answer is: "No".

In fact, that's largely an artefact of the way that C# is currently
implemented, not of the language itself. It's possible to conceive of a
C# implementation that generated native code which could -- with a
little library support -- be just as low-level as C++. There are
research projects that use such implementations of C# to implement OSes
... but nothing mainstream.

For all practical purposes the quick answer should suffice.

Cheers,
Daniel.

[Daniel James]

In article
news:<28******* *************** ************@r6 6g2000hsg.googl egroups.com>
, Pavel Minaev wrote:

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 would have to disagree.

There is a lot of C++ code about that is lower-level than it needs to
be. When sensibly used C++ can result in code that is every bit as
high-level an abstraction of the business logic as you get with C#.

Sure, bad C++ programming will lead to a poor abstraction and
overcomplex code, but so will bad programming in any language.

Cheers,
Daniel.

[Daniel James]

In article news:<ee******* *******@TK2MSFT NGP03.phx.gbl>, David Wilkinson
wrote:

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

If you are an experienced C++ programmer but know no C# (or other .NET
language) and you want to write an application for the .NET runtime that
has some GUI functionality but a lot more back-end logic it might well
be ideal to use C++/CLI for the whole thing. There are no hard-and-fast
rules, here, just a lot of technologies that can play together or on
their own and which have different strengths and weaknesses.

It's perfectly possibly to use C++/CLI to write GUI .NET applications --
it wouldn't be everybody's choice (for a number of good reasons) but it
is certainly possible ... and what Microsoft "recommend" shouldn't play
a big part in your decision-making process. Their recommendations are
often more political than technical, and in any case can't consider the
specific technical factors affecting any individual case.

For that matter: I don't think I've seen any definitive statement from
Microsoft saying that C++/CLI is no longer recommended for GUI .NET
applications ... can you provide a reference/link for that?

If you use native C++, you will probably want to use the MFC library
...

That's certainly a valid choice, and a reasonable one for a native C++
application that's limited to the Windows platform.

Other good choices would be Qt or the wxWdigets libraries which also
target other OSes, such as linux and MacOS.

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 ...

Yes, indeed. It's also an appropriate strategy if you want your back-end
code to be portable to ther systems but want to code a platform-specific
GUI for each target system to take best advantage of the facilities of
each platform. The Windows front-end can then be C# (or whatever takes
your fancy), and you can use other tools for other platforms.

Cheers,
Daniel.

[David Wilkinson]

Giovanni Dicanio wrote:

Do you know if it is possible to throw native C++ exceptions from the C++
layer, and directly catch them at the C++/CLI or C# layer?

Or must the C++/CLI layer catch all native C++ exceptions (like those
derived from std::exception) and rethrow them in a different form, derived
from managed base exception class System.Exceptio n ?

Giovanni:

I don't know about that. The code I am talking about is a mathematical library
that uses exceptions (derived from std::exception) internally, but catches them
and converts them to error codes for the client.

--
David Wilkinson
Visual C++ MVP

[Pavel Minaev]

On Jul 19, 5:11*am, Arne Vajhøj <a...@vajhoej.d kwrote:

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 ?

If you develop desktop applications, you typically have to make
installers for them. And, yes, given the limitations of Windows
Installer, it often requires one to write a custom action to do a
particular check or operation.

[Giovanni Dicanio]

"Daniel James" <wa*********@no spam.aaisp.orgh a scritto nel messaggio
news:VA******** **********@nosp am.aaisp.org...

news:<28******* *************** ************@r6 6g2000hsg.googl egroups.com>
, Pavel Minaev wrote:

>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 would have to disagree.

There is a lot of C++ code about that is lower-level than it needs to
be. When sensibly used C++ can result in code that is every bit as
high-level an abstraction of the business logic as you get with C#.

I agree with Daniel.

The main problem of C++ code is "old style" C++ code, more similar to C than
C++.
e.g. when raw pointers like char* are used instead of robust string classes
like std::string/CString, or instead of robust container classes like
std::vector.

Using tools like string classes, container classes and smart pointers makes
C++ code robust and easy to write and manage.

Giovanni