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

Daniel

"Daniel"  wrote in message 
news:OZyOgzF6IHA.2260@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

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

Pavel A. wrote:
> "Daniel"  wrote in message 
> news:OZyOgzF6IHA.2260@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

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.

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."  wrote in message 
news:u7%23ApAG6IHA.3512@TK2MSFTNGP02.phx.gbl...
> "Daniel"  wrote in message 
> news:OZyOgzF6IHA.2260@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
>

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"  wrote in message 
news:OZyOgzF6IHA.2260@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
>

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

"Daniel"  wrote in message 
news:OZyOgzF6IHA.2260@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.

Does C# have as much meticulous control over the micro matters as C++ does?

Daniel

"Larry Smith"  wrote in message 
news:%23qvvjVH6IHA.3512@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.
>

On Thu, 17 Jul 2008 21:28:11 -0700, Daniel  wrote:

> 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

MC  wrote:
> "Daniel"  wrote in message 
> news:OZyOgzF6IHA.2260@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 - 
Web site: http://www.pobox.com/~skeet   
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com

On Jul 18, 2:31 am, "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'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.

"Arne Vajhøj"  ha scritto nel messaggio 
news:487fdc67$0$90274$14726298@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

On Jul 18, 2:31 am, "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?

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

In article news:, 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.

"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

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

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

> Does C# have as much meticulous control over the micro matters as C++
> does?

From a language perspective yes. There's really not much you can do in one
that you can't do in the other. C++ has more elegant constructs
IMO and also supports multiple inheritance but that's highly overrated.
It's also much more difficult to learn and much less forgiving if you make a
mistake (i.e., easier for your program to blow up). For all intents and
purposes however (to answer your question), the real difference under
Windows is that C# relies exclusively on .NET while C++ doesn't. C++
therefore provides a complete and natural gateway to the entire OS so you
have that power at your disposal if you need it. It's much easier to call
the WinAPI that is since its interface was designed for C/C++ programmers.
By contrast, in C# you have to call into the "P/Invoke" services if you need
to do something that .NET doesn't support. That simply means you have to
call routines outside of .NET to get your work done (usually a C++ library).
In practice however you can write most mainstream .NET programs without
relying on the WinAPI whatsoever (or very minimal support anyway). C# is
also a more natural fit for .NET than C++ since it was designed from the
ground-up for this platform. Of course you can now also choose C++/CLI which
makes .NET programming much easier than in the past (for C++ developers). I
stronlgy recommend against it however. C# is really the de facto platform
for .NET and most shops will choose it over C++. Your support issues will
also be much easier since there will be fewer bugs (since C++ is far easier
to screw up) and it's easier to find qualfied C# programmers compared to
C++. .NET is also much easier than the WinAPI in general (including any of
the available C++ platforms for programming the WinAPI) so the real decision
boils down to whether you're choosing .NET or the WinAPI. Most programs can
now rely on .NET so you're probably safe choosing it. Unless performance is
a major factor (you need blazing speed for some reason), or you do in fact
have to rely on the WinAPI a lot (for things that .NET doesn't support),
.NET and C# will give you most of the "meticulous" control you're seeking.
You'll also find it *much* easier than C++ and the WinAPI. Note however that
if you want to become a Windows programming master then C++ is the clear
winner (in the long run you'll also command more money from employers).

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

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

On Jul 18, 2:56 pm, "Ben Voigt [C MVP]" <r...@nospam.nospam> wrote:
> > [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

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

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

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"  wrote in message 
news:op.ueg1rnw48jd0ej@petes-computer.local...
> On Thu, 17 Jul 2008 21:28:11 -0700, Daniel  wrote:
>
>> 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

Thanks.  Your thorough explanation is what I need.

Daniel

"Larry Smith"  wrote in message 
news:%23oT8zxN6IHA.1192@TK2MSFTNGP05.phx.gbl...
>> Does C# have as much meticulous control over the micro matters as C++
>> does?
>
> From a language perspective yes. There's really not much you can do in one
> that you can't do in the other. C++ has more elegant constructs
> IMO and also supports multiple inheritance but that's highly overrated.
> It's also much more difficult to learn and much less forgiving if you make 
> a
> mistake (i.e., easier for your program to blow up). For all intents and
> purposes however (to answer your question), the real difference under
> Windows is that C# relies exclusively on .NET while C++ doesn't. C++
> therefore provides a complete and natural gateway to the entire OS so you
> have that power at your disposal if you need it. It's much easier to call
> the WinAPI that is since its interface was designed for C/C++ programmers.
> By contrast, in C# you have to call into the "P/Invoke" services if you 
> need
> to do something that .NET doesn't support. That simply means you have to
> call routines outside of .NET to get your work done (usually a C++ 
> library).
> In practice however you can write most mainstream .NET programs without
> relying on the WinAPI whatsoever (or very minimal support anyway). C# is
> also a more natural fit for .NET than C++ since it was designed from the
> ground-up for this platform. Of course you can now also choose C++/CLI 
> which
> makes .NET programming much easier than in the past (for C++ developers). 
> I
> stronlgy recommend against it however. C# is really the de facto platform
> for .NET and most shops will choose it over C++. Your support issues will
> also be much easier since there will be fewer bugs (since C++ is far 
> easier
> to screw up) and it's easier to find qualfied C# programmers compared to
> C++. .NET is also much easier than the WinAPI in general (including any of
> the available C++ platforms for programming the WinAPI) so the real 
> decision
> boils down to whether you're choosing .NET or the WinAPI. Most programs 
> can
> now rely on .NET so you're probably safe choosing it. Unless performance 
> is
> a major factor (you need blazing speed for some reason), or you do in fact
> have to rely on the WinAPI a lot (for things that .NET doesn't support),
> .NET and C# will give you most of the "meticulous" control you're seeking.
> You'll also find it *much* easier than C++ and the WinAPI. Note however 
> that
> if you want to become a Windows programming master then C++ is the clear
> winner (in the long run you'll also command more money from employers).
>
>
>

ok. Thanks.

"Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it> wrote in message 
news:uyIJu8K6IHA.1592@TK2MSFTNGP04.phx.gbl...
>
> "Arne Vajhøj"  ha scritto nel messaggio 
> news:487fdc67$0$90274$14726298@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
>
>
>

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

Daniel

"Pavel Minaev"  wrote in message 
news:f21ed502-645b-40e9-a5a0-d54cc68a9957@z16g2000prn.googlegroups.com...
On Jul 18, 2:31 am, "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?

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"  wrote in message 
news:eeyAnVN6IHA.4352@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

On Fri, 18 Jul 2008 09:40:45 -0700, 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++.

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

On Jul 18, 1:36 pm, Daniel James  wrote:
> 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 Jul 18, 1:52 pm, Pavel Minaev  wrote:
> On Jul 18, 1:36 pm, Daniel James  wrote:
>
> > 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.

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.

On Fri, 18 Jul 2008 11:00:29 -0700, jmDesktop   
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] 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

On Jul 18, 2:20 pm, "Peter Duniho" 
wrote:
> On Fri, 18 Jul 2008 11:00:29 -0700, jmDesktop   
> 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)?

On Fri, 18 Jul 2008 11:59:48 -0700, jmDesktop   
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

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

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"  wrote in message 
news:#qvvjVH6IHA.3512@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.
>

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

Pavel Minaev wrote:
> On Jul 18, 2:31 am, "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?
> 
> 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

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

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

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

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

[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

In article news:<#QIPHUP6IHA.2336@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.

In article 
news:
, 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.

In article news:, 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.

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

On Jul 19, 5:11 am, Arne Vajhøj  wrote:

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

"David Wilkinson"  ha scritto nel messaggio 
news:eqw%23E9Y6IHA.2064@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

"Daniel James"  ha scritto nel messaggio 
news:VA.0000146f.1a0de5c6@nospam.aaisp.org...

> news:
> , 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

[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

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

Daniel James wrote:
> In article news:, 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

On Jul 19, 5:56 pm, David Wilkinson  wrote:
> 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.

On Jul 19, 4:36 pm, "Giovanni Dicanio" <gdicanio@_NOSPAM_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 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

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

Daniel James wrote:
> In article 
> news:
> , 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

In article news:, Larry Smith 
wrote:
> 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.

5%? Maybe. It's certainly no more than about 10%.

The percentage doesn't change much for other languages, though, bad 
programmers will write bad code in any language.

Remember Sturgeon's (second) rule.
http://en.wikipedia.org/wiki/Sturgeon%27s_revelation

Cheers,
 Daniel.

In article news:<#eYqo1Z6IHA.1200@TK2MSFTNGP04.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/archive/2007/08/08/visual-c-futures.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.

In article news:, David Wilkinson 
wrote:
> 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.

That's a good point -- and well made -- and if your apps are all desktop 
apps then it may be a good enough solution for you. I achieve much the 
same by running Windows apps in a Windows VM under linux; it means I have 
to have a licensed copy of Windows to run in the VM, which you avoid by 
using Crossover (or Wine), but that is not a big problem.

Many customers, though, insist on a native application and won't accept 
the additional cost in hardware resources needed by either Crossover or a 
VM.

In my work I have often had to share code between a desktop application 
and an embedded application, so the separation between back-end logic 
(ROMmable) and GUI has been very important.

Cheers,
 Daniel.

Daniel James wrote:
> 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.

Daniel:

Maybe I should not say "Microsoft does not recommend" then. Do you think 
"Microsoft does not promote" would be more accurate? Or do you feel that is too 
strong also?

I'm sure there are some advanced users who use C++/CLI to write GUI .NET 
applications, but the vast majority of the C++/CLI questions I see in the 
newsgroups/forums come from novices who have downloaded VC++ Express and have 
found that, absent MFC, the only out-of-the-box way to write GUI applications is 
to use .NET. Many of these folks, like the OP, are not even aware that the 
language they are using is not C++. They have chosen C++ because the name sounds 
familiar, or perhaps know it a bit already, but the vast majority of these 
people would have been batter off downloading VC# Express instead. At any rate, 
they are not going to be happy if the forms designer in VC++ is crippled.

But even experienced C++ users seem to be embracing C# over C++/CLI. It's not 
just the designer tools; some features (such as LINQ) are not even available in 
C++/CLI. It's a shame after all the effort that went into C++/CLI (after the 
initial MC++ debacle), but there it is.

What's the solution? I think MS has to fully face up to the fact that VC++ is 
for native code, get the IDE back to the level of usability/responsiveness we 
had in VC6, and put MFC (and the PSDK) into VC++ Express. I don't think it is 
anybody's interest to "entrap" beginners into C++/CLI.

-- 
David Wilkinson
Visual C++ MVP

Pavel Minaev  wrote:
> On Jul 19, 4:36 pm, "Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it>
> wrote:
> [...]
>> 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.

  I've looked at this list and I agree with the unsigned vs. signed
  issue, everything else I don't agree with. I can't see how you can
  implement a dynamic array that doesn't invalidate iterators upon
  insertion (might be my limited imagination, though).
  I don't think I've used 'std::auto_ptr' in the last five years. If
  I needed a smart pointer (which is rather rare if you use the above
  mentioned tools) I needed (and used) a ref-counting off-the-shelf
  one. And there's no function template partial specialization, so it
  can't mess with the overloading rules.
  I agree that C++ is a huge and complex beast to deal with, but I
  also agree with Giovanni that a modern use of it leads to save,
  robust, and easily maintainable code. Unfortunately I also have to
  agree that too few programmers are using it that way.

  I think it all boils down to the old observation that C's heritage
  is both a bless and a curse for C++. That's valid for teaching it,
  too. C++ was taught as a better C for far too long and that still
  hasn't changed enough. To many studentsare taught a style that begs
  for subtle bugs, alltough there are better ways to make use of the
  language.
  My personal opinion is that most programmers would benefit a lot
  from reading Koenig/Moo's "Accelerated C++" even though it's meant to
  be for novices. I read it many years ago (because I teach C++) and
  while I don't think it showed me anything I didn't know yet, it did
  teach me that C++ has changed enough throughout the last 15 years to
  make it possible to teach it to students in a way that makes them
  programming the style Giovanni advertized from day one.
  I have 15-20 lectures (90mins each) to teach C++ to students who had
  one year of Java-only exposure and found that it's possible to go all
  the way from "Hello, world!" to template meta-programming in that
  time. I hammer a lot of rules of thumb into them and teach them a
  style where C++ is a like big box of Lego bricks from which your can
  safely build anything you need. I rarely ever have a semester where I
  give an exercise where they have to write 'new', let alone 'delete',
  but they see 'std::vector' in lesson two, along with 'std::string'
  and IO. C++ is still more unsafe than other languages because it just
  relies on programmers not to do stupid things, but given a modern
  combination of compiler/RTL/std lib you get a lot of meaningful run-
  time error messages in debug mode while still enjoying full speed in
  release mode.

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

  But that's really hard to do if you don't do manual memory and the
  like. Mostly this happens because programmers only use C++ as a
  better C -- which is exactly what Giovanni said would lead to subtle
  bugs.

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

  IME the crashs reported from testing tend to happen in certain parts