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

[jmDesktop]

On Jul 18, 1:52*pm, Pavel Minaev <int...@gmail.c omwrote:

On Jul 18, 1:36*pm, Daniel James <wastebas...@no spam.aaisp.orgw rote:

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.

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.

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.

[Peter Duniho]

On Fri, 18 Jul 2008 11:00:29 -0700, jmDesktop <ne***********@ gmail.com>
wrote:

On the low level stuff. What exactly is the "lowest" level in Windows
C++.

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.

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?

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

I know I can use C++ to createwindow or something like it,

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

but how is it doing it?

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

Pete

[Ben Voigt [C++ MVP]]

David Wilkinson wrote:

Ben Voigt [C++ MVP] wrote:

>ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.

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.

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.

>
If this old programmer is going to learn something new, I think it's
going to be C# and .NET.

[jmDesktop]

On Jul 18, 2:20*pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Fri, 18 Jul 2008 11:00:29 -0700, jmDesktop <needin4mat...@ gmail.com*
wrote:

On the low level stuff. *What exactly is the "lowest" level in Windows
C++.

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.

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?

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

I know I can use C++ to createwindow or something like it,

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

but how is it doing it?

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

Pete

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

[David Wilkinson]

Ben Voigt [C++ MVP] wrote:

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.

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.

--
David Wilkinson
Visual C++ MVP

[Peter Duniho]

On Fri, 18 Jul 2008 11:59:48 -0700, jmDesktop <ne***********@ gmail.com>
wrote:

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

Again, it depends. The question is too vague to answer, because there are
a variety of ways a window could be drawn on the screen.

That said, for the typical, mainstream Windows application, yes...the OS
itself provides the implementation that actually draws the window-specific
graphics on the screen. This includes things like the frame, titlebar,
menu, scrollbars, etc.

An application uses this built-in functionality, and then optionally
provides its own customized drawing for the "client" area of the window.
Where it doesn't provide customized drawing, it usually simply adds "child
windows" (in a .NET Forms application, this is in the form of Control
sub-classes) to the main window, and each child window implements its own
drawing (again, as part of the OS API and implementation) .

Pete

[Hendrik Schober]

Daniel wrote:

What is MSI? What do you mean by "MSI custom actions"?

http://www.google.com/search?q=MSI+custom+actions

The very first hit explained it to me, who hadn't heard
the term before either.

Daniel

Schobi

[Alvin Bruney [ASP.NET MVP]]

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
-------------------------------------------------------
"Larry Smith" <no_spam@_nospa m.comwrote in message
news:#q******** ******@TK2MSFTN GP02.phx.gbl...

>I meant which of the two languages C++ or C# should I pursue, if I don't
already have projects I have to support in either one. If I I have to
give support for an application I created in one of those two languages,
then that is the language I have to be most familiar with. Once I use
the language in a substantial project I have to support, I am committed
to that language.

This is a religious issue and it really depends on what you plan on doing.
That said, for "general-purpose" programming in the Windows world, C# is
usually the way to go these days IMO. I believe the trend has been
strongly moving in that direction for a period of years now. Note (FWIW)
that I spent many years in the C++ trenches.

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

Pavel Minaev wrote:

On Jul 18, 2:31 am, "Daniel" <newso...@cable one.netwrote:

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

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

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

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

Ken Foskey wrote:

On Fri, 18 Jul 2008 11:46:56 +0200, Giovanni Dicanio wrote:

>I've heard about Mono before. But I wonder: what is the level of
implementati on of Mono?
Is Mono as robust as the Microsoft .NET framework implementation?

A lot of the .net framework is directly from Microsoft. A lot is
implemented a totally different way.

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

Arne