469,314 Members | 2,181 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,314 developers. It's quick & easy.

learn C++ or C#

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

Daniel
Jul 17 '08 #1
151 3784
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Java, Ruby, Python

--PA

Jul 17 '08 #2
Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
First I will make a prediction: the .vc guys will suggest C++ and
the .csharp guys will suggest C#.

:-)

If you want to write general business apps, then I will suggest C#.

If you have special requirements for real time, embedded, device
driver programming and similar then go for C++.

Arne
Jul 18 '08 #3
Pavel A. wrote:
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
>If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?

Java, Ruby, Python
:-)

Arne
Jul 18 '08 #4
Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?

Daniel

Both. I'd choose C++ first because once you learn it C# will be really
easy in comparison. If you want to see immediate results, I'd go for C#
though.

Regards.
Jul 18 '08 #5
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.

Daniel

"Pavel A." <pa*****@NOwritemeNO.comwrote in message
news:u7****************@TK2MSFTNGP02.phx.gbl...
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
>If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?

Java, Ruby, Python

--PA

Jul 18 '08 #6
VB6 yay.

--

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
-------------------------------------------------------
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?

Daniel
Jul 18 '08 #7
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.
Jul 18 '08 #8
MC
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
Java. :)

C++ is well past its heyday. C# is (in my opinion) the best-designed of the
3 languages but is very similar to Java, which is more widely used; you
should at least be acquainted with it.
Jul 18 '08 #9
Does C# have as much meticulous control over the micro matters as C++ does?

Daniel

"Larry Smith" <no_spam@_nospam.comwrote in message
news:%2****************@TK2MSFTNGP02.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.

Jul 18 '08 #10
On Thu, 17 Jul 2008 21:28:11 -0700, Daniel <ne******@cableone.netwrote:
Does C# have as much meticulous control over the micro matters as
C++ does?
"Meticulous control" and "micro matters" are not well-defined terminology
in the field of programming. It's not possible to answer that question
without you providing it in a more detailed, less ambiguous way.

In any case, I doubt that's a question you really need an answer to. As
has been explained previously, it really has more to do with what you're
trying to write. While there are specific differences between each
language, with only some exceptions what you can do in one, you can do in
the other. But C# is generally better-suited to dealing with .NET, while
C++ is likely to be better suited if you're having to deal with unmanaged
APIs.

So the proper choice of language has more to do with what you're going to
use it for than in differences between the languages in the abstract.

Pete
Jul 18 '08 #11
MC <fo**************@www.ai.uga.edu.slash.mcwrote:
"Daniel" <ne******@cableone.netwrote in message
news:OZ**************@TK2MSFTNGP03.phx.gbl...
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?

Java. :)

C++ is well past its heyday. C# is (in my opinion) the best-designed of the
3 languages but is very similar to Java, which is more widely used; you
should at least be acquainted with it.
Java 1.4 and C# 1.0 were very similar, but the languages have diverged
significantly since then. Almost all the new features in C# 2.0 and 3.0
either have no real equivalent in Java (e.g. iterator blocks, nullable
types) or have very significant differences (e.g. generics).

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
Jul 18 '08 #12
On Jul 18, 2:31*am, "Daniel" <newso...@cableone.netwrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
It's well worth knowing both, but knowing C++ well is going to take
much more time and energy. I'd suggest learning C# first, still -
moving from C++ to C# is often more of a pain than it seems.
Jul 18 '08 #13

"Arne Vajhøj" <ar**@vajhoej.dkha scritto nel messaggio
news:48***********************@news.sunsite.dk...
First I will make a prediction: the .vc guys will suggest C++ and
the .csharp guys will suggest C#.

:-)
I'm a .vc guy :-)

If you want to write general business apps, then I will suggest C#.
I agree with that.

If you have special requirements for real time, embedded, device
driver programming and similar then go for C++.
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

Jul 18 '08 #14
On Jul 18, 2:31*am, "Daniel" <newso...@cableone.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).
Jul 18 '08 #15
In article news:<OZ**************@TK2MSFTNGP03.phx.gbl>, Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?
It depends what you want to do, and where you want to do it.

C++ is the more powerful language but there is more to learn, C# is
relatively simple but less powerful. OTOH there are more productivity
tools for C# (largely because it has a simpler syntax, so the tools are
easier to write).

C++ can be used to write software for a huge range of systems -- not
only Windows but also Mac, linux and others (including mini and
mainframe computers, and embedded systems). 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); but not nearly so many as can run C++
programs.

C++ can be used to write system-level code: operating systems, device
drivers, etc.. Although there are research projects and proof of concept
implementation that use C# for these things, current C# implementations
do not allow C# to be used for this kind of work with mainstream OSes --
you can't write even a Windows device driver in C#. If you want to do
driver work then choose C++ (or even C).

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.

Alternatively you could write your application logic in a webserver
format and use your platform's browser for the GUI, which would save you
writing any platform-specific GUI code at all.

Personally, I usually write the application back-end in C++ and then
write the Windows-specific GUI wrapper in C++ using MFC ... but then I'm
from a C++ background and I just do what comes naturally.

Cheers,
Daniel.
Jul 18 '08 #16

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

Thanks,
Giovanni
Jul 18 '08 #17
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
implementation 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. I expect that it will be very
compliant as time progresses just not now.
Does Mono fully support C# 3?
I cannot compile anymore:

[Task:File=/home/ken/projects/Capture/Capture/inMatch.cs, Line=266,
Column=32, Type=Error, Priority=Normal, Description=Feature `query
expressions' cannot be used because it is not part of the C# 2.0 language
specification(CS1644)]
Does Mono fully support .NET Framework 3.5 ?
definitely not.

Mono is about portability you have to build with that in mind and you can
be fully portable. I write my test classes on Console and run them on
Linux as well. I have socket based tests and I need two machine to make
it work.

Ken
Jul 18 '08 #18
Daniel wrote:
If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
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.

--
David Wilkinson
Visual C++ MVP
Jul 18 '08 #19
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
implementation 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. I expect that it will be very
compliant as time progresses just not now.
>Does Mono fully support C# 3?

I cannot compile anymore:

[Task:File=/home/ken/projects/Capture/Capture/inMatch.cs, Line=266,
Column=32, Type=Error, Priority=Normal, Description=Feature `query
expressions' cannot be used because it is not part of the C# 2.0
language specification(CS1644)]
Sounds like a command line option, or lack thereof, put you in C# 2
compatibility mode. Certainly the compiler wouldn't be describing a feature
such as LINQ query expressions if it didn't understand it.
>
>Does Mono fully support .NET Framework 3.5 ?

definitely not.

Mono is about portability you have to build with that in mind and you
can be fully portable. I write my test classes on Console and run
them on Linux as well. I have socket based tests and I need two
machine to make it work.

Ken

Jul 18 '08 #20
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

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

Jul 18 '08 #21
On Jul 18, 2:56*pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
[Task:File=/home/ken/projects/Capture/Capture/inMatch.cs, Line=266,
Column=32, Type=Error, Priority=Normal, Description=Feature `query
expressions' cannot be used because it is not part of the C# 2.0
language specification(CS1644)]

Sounds like a command line option, or lack thereof, put you in C# 2
compatibility mode. *Certainly the compiler wouldn't be describing a feature
such as LINQ query expressions if it didn't understand it.
Indeed, you need the command line option -langversion:linq but to
quote the documentation:

<quote>
This enables the C# 3.0 support. Only a few features of C# 3.0 have
been implemented in the Mono C# compiler, so not everything is
available.
</quote>

:(

Jon
Jul 18 '08 #22
>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


ATL/WTL follow modern C++ principles much better than MFC, and should
probably be the library of choice for C++ Windows-only GUI.
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).
Jul 18 '08 #23
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.

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

--
David Wilkinson
Visual C++ MVP
Jul 18 '08 #24
I had forgotten the proper terminology. I meant to ask whether C# was a low
level language to the same extent as C++.

Daniel

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Thu, 17 Jul 2008 21:28:11 -0700, Daniel <ne******@cableone.netwrote:
>Does C# have as much meticulous control over the micro matters as C++
does?

"Meticulous control" and "micro matters" are not well-defined terminology
in the field of programming. It's not possible to answer that question
without you providing it in a more detailed, less ambiguous way.

In any case, I doubt that's a question you really need an answer to. As
has been explained previously, it really has more to do with what you're
trying to write. While there are specific differences between each
language, with only some exceptions what you can do in one, you can do in
the other. But C# is generally better-suited to dealing with .NET, while
C++ is likely to be better suited if you're having to deal with unmanaged
APIs.

So the proper choice of language has more to do with what you're going to
use it for than in differences between the languages in the abstract.

Pete

Jul 18 '08 #25
ok. Thanks.

"Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_itwrote in message
news:uy**************@TK2MSFTNGP04.phx.gbl...
>
"Arne Vajhøj" <ar**@vajhoej.dkha scritto nel messaggio
news:48***********************@news.sunsite.dk...
>First I will make a prediction: the .vc guys will suggest C++ and
the .csharp guys will suggest C#.

:-)

I'm a .vc guy :-)

>If you want to write general business apps, then I will suggest C#.

I agree with that.

>If you have special requirements for real time, embedded, device
driver programming and similar then go for C++.

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

Jul 18 '08 #26
What is MSI? What do you mean by "MSI custom actions"?

Daniel

"Pavel Minaev" <in****@gmail.comwrote in message
news:f2**********************************@z16g2000 prn.googlegroups.com...
On Jul 18, 2:31 am, "Daniel" <newso...@cableone.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).
Jul 18 '08 #27
Thanks.

"David Wilkinson" <no******@effisols.comwrote in message
news:ee**************@TK2MSFTNGP03.phx.gbl...
Daniel wrote:
>If I haven't made substantial investment in either C++ or C#, which
language would the experts recommend I become well acquainted with?

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.

--
David Wilkinson
Visual C++ MVP

Jul 18 '08 #28
On Fri, 18 Jul 2008 09:40:45 -0700, Daniel <ne******@cableone.netwrote:
I had forgotten the proper terminology. I meant to ask whether C# was a
low
level language to the same extent as C++.
I guess I would describe C++ as being "lower level" than C#. However, if
you're writing .NET code the difference doesn't matter. C++ has roughly
the same degree of "high level" features that C# has and vice a versa, and
even in C# you can write "unsafe" code to do certain "low level" things.
The main limitation with C# is that if you write C# code, it has to
execute in the managed environment, which excludes it from certain kinds
of applications (already discussed elsewhere in these threads).

Pete
Jul 18 '08 #29
On Jul 18, 1:36*pm, Daniel James <wastebas...@nospam.aaisp.orgwrote:
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.
Jul 18 '08 #30
On Jul 18, 1:52*pm, Pavel Minaev <int...@gmail.comwrote:
On Jul 18, 1:36*pm, Daniel James <wastebas...@nospam.aaisp.orgwrote:
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.
Jul 18 '08 #31
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
Jul 18 '08 #32
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.

Jul 18 '08 #33
On Jul 18, 2:20*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.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)?
Jul 18 '08 #34
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
Jul 18 '08 #35
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
Jul 18 '08 #36
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
Jul 18 '08 #37
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@_nospam.comwrote in message
news:#q**************@TK2MSFTNGP02.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.
Jul 19 '08 #38
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
Jul 19 '08 #39
Pavel Minaev wrote:
On Jul 18, 2:31 am, "Daniel" <newso...@cableone.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
Jul 19 '08 #40
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
implementation 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
Jul 19 '08 #41
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
Jul 19 '08 #42
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
Jul 19 '08 #43
[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.Exception ?

Thanks,
Giovanni

Jul 19 '08 #44
In article news:<#Q**************@TK2MSFTNGP03.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.
Jul 19 '08 #45
In article
news:<28**********************************@r66g200 0hsg.googlegroups.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.
Jul 19 '08 #46
In article news:<ee**************@TK2MSFTNGP03.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.

Jul 19 '08 #47
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.Exception ?
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
Jul 19 '08 #48
On Jul 19, 5:11*am, Arne Vajhøj <a...@vajhoej.dkwrote:
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.
Jul 19 '08 #49

"David Wilkinson" <no******@effisols.comha scritto nel messaggio
news:eq****************@TK2MSFTNGP02.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

Jul 19 '08 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

17 posts views Thread by Rob | last post: by
42 posts views Thread by Bicho Verde | last post: by
55 posts views Thread by Elijah | last post: by
30 posts views Thread by Rhino | last post: by
8 posts views Thread by Hermawih | last post: by
21 posts views Thread by TAM | last post: by
85 posts views Thread by abhi | last post: by
31 posts views Thread by anand devarajan | last post: by
34 posts views Thread by pandit | last post: by
65 posts views Thread by Chris Carlen | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.