learn C++ or C#

[Daniel James]

Re: learn C++ or C#

In article
news:<28f7d1cf-3d11-4f6f-9b86-b9b863cbc286@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]

Re: learn C++ or C#

In article news:<eeyAnVN6I HA.4352@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]

Re: learn C++ or C#

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]

Re: learn C++ or C#

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]

Re: learn C++ or C#


"David Wilkinson" <no-reply@effisols. comha scritto nel messaggio
news:eqw%23E9Y6 IHA.2064@TK2MSF TNGP02.phx.gbl. ..

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.

Thanks David.

Giovanni

[Giovanni Dicanio]

Re: learn C++ or C#


"Daniel James" <wastebasket@no spam.aaisp.orgh a scritto nel messaggio
news:VA.0000146 f.1a0de5c6@nosp am.aaisp.org...

news:<28f7d1cf-3d11-4f6f-9b86-b9b863cbc286@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

[Giovanni Dicanio]

Re: learn C++ or C#

[Daniel James]

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?

I would suggest reading this comment by Steve Teixeira to Somasegar's blog
post titled "Visual C++ Futures":

http://blogs.msdn.com/somasegar/archive/2007/08/08/visual-c-futures.aspx#4746812

<quote>

[...]

Hopefully I'm helping to paint a more accurate picture of the role of
C++/CLI. In a nutshell, we're focused on areas where we can add maximal
value, and we're deliberately avoiding investments in "me too" areas where
we can offer little value beyond a "C# with a preprocessor" experience. In
practical terms, this will often mean leaving the UI designer space in the
capable hands of C# and VB.NET while VC++ focuses on ensuring developers can
get the most out of the "guts" of their software.
[...]

Steve Teixeira

Group Program Manager, VC++

</quote>


Giovanni

[David Wilkinson]

Re: learn C++ or C#

Pavel Minaev wrote:

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.

Pavel:

Well, I use Inno Setup for my installations, and for that you have to do the
customization in Pascal (unfortunately) .

--
David Wilkinson
Visual C++ MVP

[David Wilkinson]

Re: learn C++ or C#

Daniel James wrote:

In article news:<eeyAnVN6I HA.4352@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.

Daniel:

These are indeed difficult decisions, and I do not believe the dust has fully
settled on the managed/native issue (maybe it never will).

I for one am glad that I have stuck with native code and MFC up till now.
Investing a lot of time in MC++ would certainly have been a big mistake, and
it's beginning to look like the same for C++/CLI (at least for GUI).

QT or wxwidgets are good for cross-platform, but QT is expensive and I'm not
sure about the longevity of wxwidgets. But really I do not think about porting
my applications any more, because I feel that CrossOver MAC and CrossOver Linux
do a pretty good job of running Windows applications.

So although I started out separating the "business logic" of my application from
the GUI (and writing the former in just ANSI C++, with no Microsoft-specific
stuff), I now think of using it in a revised app with the GUI in .NET and C#.
But not any time soon.

It's a pity that Microsoft's only supported native C++ GUI platform is MFC, but
there it is. It's inelegant, and bloated, but it works, for the most part. So
for now I'm sticking with MFC, forgetting about C++/CLI, and starting to learn
C# in my spare time.

--
David Wilkinson
Visual C++ MVP

[Pavel Minaev]

Re: learn C++ or C#

On Jul 19, 5:56 pm, David Wilkinson <no-re...@effisols. comwrote:

It's a pity that Microsoft's only supported native C++ GUI platform is MFC, but
there it is.

Why restrict yourself to Microsoft-produced GUI frameworks, though? Qt
is an excellent-quality powerful framework with full commercial
support on Windows and Microsoft C++ compilers, and complete Visual
Studio integration - and that's just one example.

[Pavel Minaev]

Re: learn C++ or C#

On Jul 19, 4:36 pm, "Giovanni Dicanio" <gdicanio@_NOSP AM_email_DOT_it >
wrote:

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.

Well, sort of. Until you accidentially invalidate an iterator by
modifying the container - U.B. Or mix signed and unsigned integer
types in an arithmetic expression and get weird results because of the
silent signed->unsigned conversion rule (and it is very easy to do so,
since a lot of standard library functions return unsigned integers -
e.g. size() of any STL container is unsigned). Or forget that
assignment operator and "copy" constructor for auto_ptr are actually
move and not copy. Or put an auto_ptr into a container (and why not,
if it lets you do so without any compaints...). Or try to make sense
of three paragraphs of ISO C++ standard describing overload resolution
for template functions in presence of partial specializations (the one
where synthetic types are involved). The problem is, you have to be a C
++ expert to write good C++ code, and, not any less important, to be
able to understand advanced C++ code written by others that's thrown
at you.

Don't get me wrong, C++ is a great language, and the time I've spent
writing in it was great. But from my experience, I would never let it
anywhere near domain logic except where it is spefically needed, when
I have the choice, because too many times I've witnessed how even
skilled and experienced (5+ years) C++ developers wrote some seemingy
trivial code which then broke things in subtle ways. I once spent 2
whole work days in the debugger trying to find the code that lead to
"Heap corrupted" error which invariably manifested itself under
unclear conditions after the program was used for 2-3 hours. It's not
fun at all. It's also something that's much, much rarer in the
"managed code" land.

[David Wilkinson]

Re: learn C++ or C#

David Wilkinson wrote:

So although I started out separating the "business logic" of my
application from the GUI (and writing the former in just ANSI C++, with
no Microsoft-specific stuff), I now think of using it in a revised app
with the GUI in .NET and C#. But not any time soon.

Oops. I meant to say that while my original reason for separating GUI from
business logic was for porting to Mac or Linux, I now think it more likely that
I will use my native C++ business logic in a .NET C# application on Windows.

--
David Wilkinson
Visual C++ MVP

[Larry Smith]

Re: learn C++ or C#

I have the choice, because too many times I've witnessed how even

skilled and experienced (5+ years) C++ developers wrote some seemingy
trivial code which then broke things in subtle ways. I once spent 2
whole work days in the debugger trying to find the code that lead to
"Heap corrupted" error which invariably manifested itself under
unclear conditions after the program was used for 2-3 hours. It's not
fun at all. It's also something that's much, much rarer in the
"managed code" land.

I completely agree with you. After many years in the field I have yet to
meet one C++ programmer whose code I actually trust. Experience typically
makes little difference. Novices will make many mistakes because they're
inexperienced. The experienced will still make many mistakes but at this
stage they should know better. Design skills are another matter entirely
(usually very poor). This is not arrogance speaking because I know there are
decent programmers out there. Unfortunately they are few and far between.
Most are just a very expensive burden on their employers and management is
usually clueless. I once met a very senior person in C++ circles (I won't
mention his name) and I asked him for his opinion. He suggested that perhaps
5% of all C++ programmers are competent. I wish I were that optimistic.

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

Re: learn C++ or C#

Daniel James wrote:

In article
news:<28f7d1cf-3d11-4f6f-9b86-b9b863cbc286@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.

But it is easier to write bad code in C++ than in so many'
other languages.

C++ has some very unsafe constructs (many of them inherited from C).
The C++ language is pretty complex to master. C++ has all the
implementation specific/undefined gotchas. And there is usually a
gap between the C++ standard and the C++ compilers implementation.

Arne

[Daniel James]

Re: learn C++ or C#

In article news:<#eYqo1Z6I HA.1200@TK2MSFT NGP04.phx.gbl>, Giovanni Dicanio wrote:

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?

>
I would suggest reading this comment by Steve Teixeira to Somasegar's
blog post titled "Visual C++ Futures":
>
http://blogs.msdn.com/somasegar/arch...s.aspx#4746812

Thanks for that. I had seen it before ... and I don't see anything there
that suggests that C++/CLI is "not recommended" for GUI code. All Steve
says that's at all relevant is that MS don't propose to spend time writing
GUI design tools that target C++/CLI when they already have some that
target C# and there are other things they want to spend resources on to
support C++.

That's a fair enough viewpoint, and the message in the blog is that MS (or,
at least, the C++ team) are following what they believe to be the wishes of
their customers in that respect.

That doesn't mean that they don't recommend using C++/CLI, it means that
they won't provide any tools to help you do that. That's not big deal,
really, because it doesn't actually matter what language any automatically
generated code is in -- the form designer might as well spit out a compiled
assembly as C#. Microsoft do say that the C# generated by the designers
isn't supposed to be edited by the user -- that's how they get away with
emitting such poorly structured code.

You don't actually *need* to have any tools to help you write GUI code,
anyway. You can do it all by hand. The form designers may save you some
time but in a large project that time is not significant, and hand-crafted
code will be better structured and more maintainable than anything that
comes from the designers.

Cheers,
Daniel.