learn C++ or C#
Daniel
would the experts recommend I become well acquainted with?
Daniel
Pavel A.
news:OZyOgzF6...@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
Arne Vajhøj
> 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
Arne Vajhøj
:-)
Arne
Fernando Gómez
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.
Daniel
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." <pav...@NOwritemeNO.com> wrote in message
news:u7%23ApAG6...@TK2MSFTNGP02.phx.gbl...
Alvin Bruney [ASP.NET MVP]
--
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" <news...@cableone.net> wrote in message
news:OZyOgzF6...@TK2MSFTNGP03.phx.gbl...
Larry Smith
> 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.
MC
> 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.
Daniel
Daniel
"Larry Smith" <no_spam@_nospam.com> wrote in message
news:%23qvvjVH...@TK2MSFTNGP02.phx.gbl...
Peter Duniho
> 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
![Jon Skeet [C# MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUcZ7cLpd5PD7juf-mIIANWDJjBlFAMnXgv2fuTUtqywc6Q3AUmOvVJgg=s40-c)
Jon Skeet [C# MVP]
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
Pavel Minaev
> 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.
Giovanni Dicanio
"Arne Vajhøj" <ar...@vajhoej.dk> ha scritto nel messaggio
news:487fdc67$0$90274$1472...@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
Pavel Minaev
> 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).
Daniel James
> 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.
Giovanni Dicanio
"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
Ken Foskey
> 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
David Wilkinson
> 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
Larry Smith
> 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).
Ben Voigt [C++ MVP]
> 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.
Ben Voigt [C++ MVP]
> 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.
Jon Skeet [C# MVP]
> > [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
Larry Smith
>> 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).
David Wilkinson
> 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.
Daniel
level language to the same extent as C++.
Daniel
"Peter Duniho" <NpOeS...@nnowslpianmk.com> wrote in message
news:op.ueg1r...@petes-computer.local...
Daniel
Daniel
"Larry Smith" <no_spam@_nospam.com> wrote in message
news:%23oT8zxN...@TK2MSFTNGP05.phx.gbl...
Daniel
"Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it> wrote in message
news:uyIJu8K6...@TK2MSFTNGP04.phx.gbl...
>
> "Arne Vajh�j" <ar...@vajhoej.dk> ha scritto nel messaggio
Daniel
Daniel
"Pavel Minaev" <int...@gmail.com> wrote in message
news:f21ed502-645b-40e9...@z16g2000prn.googlegroups.com...
Daniel
"David Wilkinson" <no-r...@effisols.com> wrote in message
news:eeyAnVN6...@TK2MSFTNGP03.phx.gbl...
Peter Duniho
> 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
Pavel Minaev
> 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.
jmDesktop
On the low level stuff. What exactly is the "lowest" level in Windows
C++. I don't mean assembly or machine language. I mean if I wanted
to know how graphics are really drawn on the screen. What would I
look at? I know I can use C++ to createwindow or something like it,
but how is it doing it? Is that part in C or C++? Is that the hidden
source code that Microsoft uses?
Thanks.
Peter Duniho
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]
> 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.
jmDesktop
wrote:
> On Fri, 18 Jul 2008 11:00:29 -0700, jmDesktop <needin4mat...@gmail.com>
How is a windows drawn on the screen? Is that where the OS provided
APIs come in (we don't need to know how they work)?
David Wilkinson
> 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.
Peter Duniho
wrote:
> How is a windows drawn on the screen? Is that where the OS provided
> APIs come in (we don't need to know how they work)?
Again, it depends. The question is too vague to answer, because there are
a variety of ways a window could be drawn on the screen.
That said, for the typical, mainstream Windows application, yes...the OS
itself provides the implementation that actually draws the window-specific
graphics on the screen. This includes things like the frame, titlebar,
menu, scrollbars, etc.
An application uses this built-in functionality, and then optionally
provides its own customized drawing for the "client" area of the window.
Where it doesn't provide customized drawing, it usually simply adds "child
windows" (in a .NET Forms application, this is in the form of Control
sub-classes) to the main window, and each child window implements its own
drawing (again, as part of the OS API and implementation).
Pete
Hendrik Schober
> What is MSI? What do you mean by "MSI custom actions"?
http://www.google.com/search?q=MSI+custom+actions
The very first hit explained it to me, who hadn't heard
the term before either.
> Daniel
Schobi
Alvin Bruney [ASP.NET MVP]
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.com> wrote in message
news:#qvvjVH6...@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.
>
Arne Vajhøj
> 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
Arne Vajhøj
> On Jul 18, 2:31 am, "Daniel" <newso...@cableone.net> wrote:
>> If I haven't made substantial investment in either C++ or C#, which language
>> would the experts recommend I become well acquainted with?
>
> 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
Arne Vajhøj
> 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
Arne Vajhøj
> "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?
http://mono.ximian.com/class-status/
http://www.mono-project.com/Mono_Project_Roadmap
should provide you with some info.
Arne
Arne Vajhøj
> 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
Larry Smith
> 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.
Giovanni Dicanio
> 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
Daniel James
news:<28f7d1cf-3d11-4f6f...@r66g2000hsg.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.
Daniel James
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.
Daniel James
> 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.
David Wilkinson
> 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.
Pavel Minaev
> There are several type of code where C++ is either better or
> plain necessary.
>
> But is "write MSI custom actions for installers" really a common task ?
If you develop desktop applications, you typically have to make
installers for them. And, yes, given the limitations of Windows
Installer, it often requires one to write a custom action to do a
particular check or operation.
Giovanni Dicanio
"David Wilkinson" <no-r...@effisols.com> ha scritto nel messaggio
news:eqw%23E9Y6I...@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
Giovanni Dicanio
"Daniel James" <waste...@nospam.aaisp.org> ha scritto nel messaggio
news:VA.0000146...@nospam.aaisp.org...
> news:<28f7d1cf-3d11-4f6f...@r66g2000hsg.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#.
I agree with Daniel.
The main problem of C++ code is "old style" C++ code, more similar to C than
C++.
e.g. when raw pointers like char* are used instead of robust string classes
like std::string/CString, or instead of robust container classes like
std::vector.
Using tools like string classes, container classes and smart pointers makes
C++ code robust and easy to write and manage.
Giovanni
Giovanni Dicanio
> It's perfectly possibly to use C++/CLI to write GUI .NET applications --
> it wouldn't be everybody's choice (for a number of good reasons) but it
> is certainly possible ... and what Microsoft "recommend" shouldn't play
> a big part in your decision-making process. Their recommendations are
> often more political than technical, and in any case can't consider the
> specific technical factors affecting any individual case.
>
> For that matter: I don't think I've seen any definitive statement from
> Microsoft saying that C++/CLI is no longer recommended for GUI .NET
> applications ... can you provide a reference/link for that?
I would suggest reading this comment by Steve Teixeira to Somasegar's blog
post titled "Visual C++ Futures":
http://blogs.msdn.com/somasegar/archive/2007/08/08/visual-c-futures.aspx#4746812
<quote>
[...]
Hopefully I'm helping to paint a more accurate picture of the role of
C++/CLI. In a nutshell, we're focused on areas where we can add maximal
value, and we're deliberately avoiding investments in "me too" areas where
we can offer little value beyond a "C# with a preprocessor" experience. In
practical terms, this will often mean leaving the UI designer space in the
capable hands of C# and VB.NET while VC++ focuses on ensuring developers can
get the most out of the "guts" of their software.
[...]
Steve Teixeira
Group Program Manager, VC++
</quote>
Giovanni
David Wilkinson
> 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
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.
Pavel Minaev
> It's a pity that Microsoft's only supported native C++ GUI platform is MFC, but
> there it is.
Why restrict yourself to Microsoft-produced GUI frameworks, though? Qt
is an excellent-quality powerful framework with full commercial
support on Windows and Microsoft C++ compilers, and complete Visual
Studio integration - and that's just one example.
Pavel Minaev
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
> 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.
Larry Smith
> 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.
Arne Vajhøj
But it is easier to write bad code in C++ than in so many'
other languages.
C++ has some very unsafe constructs (many of them inherited from C).
The C++ language is pretty complex to master. C++ has all the
implementation specific/undefined gotchas. And there is usually a
gap between the C++ standard and the C++ compilers implementation.
Arne
Daniel James
> > 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.
Daniel James
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:
> 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.
David Wilkinson
> 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.
Hendrik Schober
> 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
of the code and correlate with the style used in there. I rarely saw
more than one crash per year in my code /while testing on my machine/
and went years without having one checked in.
And that's not really hard to do if you write code the way Giovanni
suggests.
Schobi
--
Spam...@gmx.de is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
Pavel Minaev
> 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).
Depends on the container, but that was not my point. In C#, if you use
an invalid enumerator, you will _consistently_ get an exception. In C+
+, unless you're using a debugging STL implementation (and even then
all checks are usually disabled in release mode by default), your
invalidate vector iterator will happily dereference, and you'll get a
segfault at best, and will silently read or write some random memory
value at worst - it's precisely how those "heap corruption" errors
appear.
> 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.
Ironically, a typical C++ refcounted smart pointer is often on average
slower than a good mark&sweep GC. Especially if you're using Boost/TR1
shared_ptr, which allocates the reference counter separately from the
object itself.
> And there's no function template partial specialization, so it
> can't mess with the overloading rules.
My mistake, sorry. Just plain template specializations, not partial
ones.
By the way, partial function specialization will be in C++0x, so those
3 paragraphs might well become a few more :)
> 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.
There's one more thing to it. "Modern use" of C++ really looks a lot
like C# or Java - you generally see MI only in context of abstract
base classes (read: interfaces), you see proliferation of pointers
over stack-allocated objects (again, because of interfaces), you don't
see many overly clever template metaprogramming abuses etc.
The question is then, if the "modern subset" of C++ closely matches
that of C#, but C# also doesn't have all the legacy cruft, then why
choose C++ over C# for a typical project?
(There are other valid reasons such as portability, but I'm
deliberately restricting this argument to languages only, not to
available implementations).
> 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.
Until we get concepts in C++0x, essentially any C++ program that
heavily uses templates in general, and template metaprogramming in
particular (yes, that includes STL and Boost) is a rather masochistic
exercise when it comes to deciphering compiler error messages.
> > 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.
Not really. Perhaps I would have to clarify - my observations were in
a development environment where knowledge of the subtleties of C++ was
encouraged and widespread, and usage of STL in its entirety - not just
strings and containers, but also algorithms, binders etc, where
possible - was mandatory; and we also used shared_ptr/weak_ptr from
Boost, as well as a couple of our own Boost-style templates. We
certainly didn't use C++ as "better C" - far from it.
Giovanni Dicanio
"David Wilkinson" <no-r...@effisols.com> ha scritto nel messaggio
news:ejb5Iil6...@TK2MSFTNGP05.phx.gbl...
> 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,
100% agree!
> and put MFC (and the PSDK) into VC++ Express.
VC++ Express 2008 includes PSDK out-of-the-box.
Unfortunately, MFC is not there.
So, maybe the VC2008 Express users may use WTL for GUI development (I recall
there was an article on CodeProject about that).
However, a beginner who wants to write a GUI app for Windows can save lots
of time if he uses VC# Express with its RAD-style GUI designer.
Giovanni
Larry Smith
>> 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.
That's certainly true, but comparing a typical language to C++ is like
comparing a truck full of eggs to a tanker full of nitroglycerin. If your
driver's incompetent 95% of the time then you'll either end up with a lot of
broken eggs or a lot of dead bodies.
Arne Vajhøj
> In article news:<u0RfIKc6...@TK2MSFTNGP02.phx.gbl>, 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.
But in languages like C and C++ they can create bugs that are
both disastrous and very hard to find.
Arne
Arne Vajhøj
> 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).
I don't agree for 2.0.
My list of .NET 2.0 & C# 2.0 new features and their "Java status":
FtpWebRequest - URLConnection has had support for FTP many years
Ping - missing
HttpListener - missing
GZipStream - GZIP*Stream has existed many years
partial classes - missing
DbProviderFactory - JDBC worked that way always
generics - Java got it in 1.5 (and it is not that different)
nullable types - Java has had wrapper objects forever
anonymous methods - Java has anonymous classes
static classes - missing
different accessability get & set - Java getters & setters obviously can
7 out of 11 seems to be in Java .
.NET 3.0/3.5 & C# 3.0 I will agree. Java does not have much of that
stuff and it does not seem as if Java will get it either in the future.
Arne
Peter Duniho
> Jon Skeet [C# MVP] wrote:
>> 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).
>
> I don't agree for 2.0.
>
> My list of .NET 2.0 & C# 2.0 new features and their "Java status":
It's not clear to me that your list is a complete enumeration of all .NET
2.0 and all C# 2.0 features. Heck, you didn't even include iterator
blocks, which was specifically mentioned by Jon.
And in your own list...
> FtpWebRequest - URLConnection has had support for FTP many years
> Ping - missing
> HttpListener - missing
> GZipStream - GZIP*Stream has existed many years
> partial classes - missing
> DbProviderFactory - JDBC worked that way always
> generics - Java got it in 1.5 (and it is not that different)
I suppose that depends on your definition of "that different".
Personally, I'd say it's _very_ different. Java generics are just a
compile-time wrapper. I understand why they did it that way, but it
significantly limits their utility.
> nullable types - Java has had wrapper objects forever
Not the same at all. Nullable<T> isn't just a "wrapper" for value types
(though I can see why one might view them that way). In particular, using
a wrapper in Java requires boxing the value.
Of course, since in Java you can't define your own non-nullable types, the
need for Nullable<T> in Java is obviously dramatically reduced. But the
wrapper types still aren't the same.
> anonymous methods - Java has anonymous classes
And is missing delegates. Anonymous methods don't really make any sense
without delegates, so sure...maybe you don't see how anonymous methods
aren't the same as anonymous classes. But they aren't.
Now, if you want to argue that C# is missing anonymous classes, I don't
disagree with that. But having anonymous classes doesn't mean that Java
supports the same thing as anonymous methods.
> static classes - missing
I don't understand this. Are you saying that C# didn't get to use
"static" when declaring a class until 2.0? That doesn't sound right to
me. I'm also not clear on what you mean by "missing" with respect to
Java, since you can effectively create a static class in Java just as
easily in C#.
I must be misunderstanding what you mean by "static classes"...please
elaborate.
> different accessability get & set - Java getters & setters obviously can
Java doesn't even have properties. The fact that Java's relatively
inferior work-around to lacking properties inherently allows different
accessibility for the getter and setter seems irrelevant to me.
> 7 out of 11 seems to be in Java .
I count different: 8 of 11 seem _not_ to be in Java (that's assuming
you're correct about "static classes"...since I don't understand how
you're using that term, I might be wrong there :) ). Though, since your
list of new features for .NET 2.0 and C# isn't a complete enumeration
anyway, it's not like any count of that particular list is a useful
comparison anyway.
Pete
Arne Vajhøj
> On Sun, 20 Jul 2008 16:49:43 -0700, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Jon Skeet [C# MVP] wrote:
>>> 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).
>>
>> I don't agree for 2.0.
>>
>> My list of .NET 2.0 & C# 2.0 new features and their "Java status":
>
> It's not clear to me that your list is a complete enumeration of all
> .NET 2.0 and all C# 2.0 features. Heck, you didn't even include
> iterator blocks, which was specifically mentioned by Jon.
It is a list I had from another context.
>> generics - Java got it in 1.5 (and it is not that different)
>
> I suppose that depends on your definition of "that different".
> Personally, I'd say it's _very_ different. Java generics are just a
> compile-time wrapper. I understand why they did it that way, but it
> significantly limits their utility.
>
>> nullable types - Java has had wrapper objects forever
>
> Not the same at all. Nullable<T> isn't just a "wrapper" for value types
> (though I can see why one might view them that way). In particular,
> using a wrapper in Java requires boxing the value.
>
> Of course, since in Java you can't define your own non-nullable types,
> the need for Nullable<T> in Java is obviously dramatically reduced. But
> the wrapper types still aren't the same.
>
>> anonymous methods - Java has anonymous classes
>
> And is missing delegates. Anonymous methods don't really make any sense
> without delegates, so sure...maybe you don't see how anonymous methods
> aren't the same as anonymous classes. But they aren't.
>
> Now, if you want to argue that C# is missing anonymous classes, I don't
> disagree with that. But having anonymous classes doesn't mean that Java
> supports the same thing as anonymous methods.
>> different accessability get & set - Java getters & setters obviously can
>
> Java doesn't even have properties. The fact that Java's relatively
> inferior work-around to lacking properties inherently allows different
> accessibility for the getter and setter seems irrelevant to me.
You are missing the point.
The discussion is whether C#'s and Java's ways had split with C# 2.0
features.
The fact that Java does not have Nullable is not an indication of
such a split, because Java does not have any need for Nullable, because
in Java you use the wrapper classes. Different ways of achieving the
same goal.
Same applies to the rest.
These additions to C# made C# more similar to Java not less similar.
>> static classes - missing
>
> I don't understand this. Are you saying that C# didn't get to use
> "static" when declaring a class until 2.0? That doesn't sound right to
> me. I'm also not clear on what you mean by "missing" with respect to
> Java, since you can effectively create a static class in Java just as
> easily in C#.
>
> I must be misunderstanding what you mean by "static classes"...please
> elaborate.
http://www.google.com/search?hl=en&q=C%23+static+class&btnG=Google+Search
>> 7 out of 11 seems to be in Java .
>
> I count different: 8 of 11 seem _not_ to be in Java
Only if you count implementation.
But that is not so relevant for the discussion.
> Though, since your
> list of new features for .NET 2.0 and C# isn't a complete enumeration
> anyway, it's not like any count of that particular list is a useful
> comparison anyway.
It is a sample of the features.
As all samples it has some uncertainty, but claiming that a sample
is not useful shows a blatant lack of understanding of statistics.
Arne
MC
>>> 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.
>
> But in languages like C and C++ they can create bugs that are
> both disastrous and very hard to find.
Exactly. And that is what led us to get accustomed to personal computers
crashing, in the 1980s. Ten years earlier, in the mainframe era, with "less
powerful" languages, it was very hard for a program written in a high-level
language to crash the machine. Normally they terminated with recognizable
errors (e.g., divide by zero) or they simply misbehaved (produced the wrong
output). C# thankfully brings us back into that world. Program errors are
program errors, not computer crashes.
Arne Vajhøj
> 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).
True.
But how many real life C++ program will actually run unchanged
(and without a zillion #ifdef's) on all those platforms ?
> 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).
If one is into that type of stuff, then C/C++ is absolutely the rigth
way to go.
> 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++)
But why ? You will be able to write the same business logic cheaper
in Java, C# or Python.
You do not need any of the C/C++ specialties for that.
Arne
Peter Duniho
> [...]
> You are missing the point.
That can only be true if you are as well.
> The discussion is whether C#'s and Java's ways had split with C# 2.0
> features.
>
> The fact that Java does not have Nullable is not an indication of
> such a split, because Java does not have any need for Nullable, because
> in Java you use the wrapper classes. Different ways of achieving the
> same goal.
So why did you include "nullable types" as an example of the "split" of
"C# and Java's ways"? If anything at all, that's an example of
convergence, not divergence.
> Same applies to the rest.
Ditto.
> These additions to C# made C# more similar to Java not less similar.
The addition of the Ping class make C# more similar to Java, even though
Java doesn't have that? Likewise all the other things that even you agree
Java doesn't have?
If you're trying to make a point, you're not being very clear about what
point it is you're trying to make. You keep writing things that are
mutually exclusive of each other.
>>> static classes - missing
>> I don't understand this. Are you saying that C# didn't get to use
>> "static" when declaring a class until 2.0? That doesn't sound right to
>> me. I'm also not clear on what you mean by "missing" with respect to
>> Java, since you can effectively create a static class in Java just as
>> easily in C#.
>> I must be misunderstanding what you mean by "static classes"...please
>> elaborate.
>
> http://www.google.com/search?hl=en&q=C%23+static+class&btnG=Google+Search
Well, that's the definition I use. So that doesn't represent a change in
C# 2.0 at all. In either C# or Java you can write a static class (a class
with no instance members is by definition a static class). Just because
the keyword gained usage as a class declaration modifier in 2.0 doesn't
mean you couldn't static classes in 1.0.
In addition, you are again confused about what you're trying to
demonstrate. If Java's object wrappers for value types is in fact just
"different ways of achieving the same goal", then so too is simply
defining a class without any instance members just a "different way of
achieving the same goal".
Suffice to say, I find your assertions uncompelling.
> [...]
>> Though, since your
>> list of new features for .NET 2.0 and C# isn't a complete enumeration
>> anyway, it's not like any count of that particular list is a useful
>> comparison anyway.
>
> It is a sample of the features.
Then it's useless with respect to measuring the actual differences between
the languages.
> As all samples it has some uncertainty, but claiming that a sample
> is not useful shows a blatant lack of understanding of statistics.
Claiming that a sample _is_ useful without showing that it's a
statistically significant (large enough sample size) and statistically
correct (sample collected in a statistically random way) sample shows a
blatant lack of understanding of statistics.
Pete
Jon Skeet [C# MVP]
> > 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).
>
> I don't agree for 2.0.
>
> My list of .NET 2.0 & C# 2.0 new features and their "Java status":
I'll restrict it to language features, as that's what I was talking
about.
> partial classes - missing
Yup.
> generics - Java got it in 1.5 (and it is not that different)
It's *massively* different. Hugely, vastly different. IMO, of course,
but type erasure is fundamental difference IMO.
> nullable types - Java has had wrapper objects forever
Not the same thing. While I don't like to micro-optimise too often,
the fact that Nullable<T> is still a value type in C# 2 is a big deal.
Likewise the fact that you can deal with *any* nullable type
generically , instead of having to know the wrapper type in advance.
> anonymous methods - Java has anonymous classes
Unwieldy enough to be a real pain, and read-only access to local
variables. As Peter says, the lack of delegates is significant here.
> static classes - missing
Yup.
> different accessability get & set - Java getters & setters obviously can
Yup.
In addition:
o Iterator blocks
o Other improvements to delegates (irrelevant to Java without
delegates to start with)
> 7 out of 11 seems to be in Java .
In my count, only "different accessibility for properties" is really
there for Java.
Jon
Jon Skeet [C# MVP]
wrote:
> Well, that's the definition I use. So that doesn't represent a change in
> C# 2.0 at all. In either C# or Java you can write a static class (a class
> with no instance members is by definition a static class). Just because
> the keyword gained usage as a class declaration modifier in 2.0 doesn't
> mean you couldn't static classes in 1.0.
No, you couldn't. A static class isn't just "a clas with no instance
members". On the declaration side, when a class is made static the
compiler will *prevent* you from adding instance members. It also
means you don't have any constructors at all, which is impossible in
C# 1 - you get a default constructor if you don't specify any
constructors.
On the calling side, a class declared as static can't accidentally be
used like a "normal" class. You can't declare a variable of that type
(including parameters) or use it as a generic type parameter, for
example.
I'm not claiming these are massive differences, but they're things
which couldn't be achieved in C# 1. They let the compiler help you
find potential problems before they occur - as well as making
intentions clearer to other developers, of course.
Jon
Peter Duniho
wrote:
> No, you couldn't. A static class isn't just "a clas with no instance
> members". On the declaration side, when a class is made static the
> compiler will *prevent* you from adding instance members. It also
> means you don't have any constructors at all, which is impossible in
> C# 1 - you get a default constructor if you don't specify any
> constructors. [...]
Yes, I understand that. But by making all the members static, and the
constructor private, without any public member to return an instance of
the class, it's still effectively a static class.
If Arne were willing to accept these kinds of subtle differences as
legitimate differences, I wouldn't push it. But he isn't (see his
comments about nullable types). If he's happy for something to be "the
same" as long as it effectively behaves the same, then there shouldn't in
his view be any difference between these various ways to do a "static
class".
If anything, I'd say you can get a lot closer to a real C# 2.0 "static
class" in Java than you can to a real "nullable type", but Arne says the
former isn't in Java while the latter is. Of course, further complicating
matters is that Arne _also_ says the latter _isn't_. Which is very
confusing. :)
Pete
jmDesktop
Just a definition question. What does "domain logic" mean? Thanks.
Jon Skeet [C# MVP]
> 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>
Update to this - I've been chatting with Miguel de Icaza recently
(about something else) and he mentioned that the C# 3.0 support is now
actually completed. I'm not sure how much of it has been released yet,
but when Mono 2.0 comes out it should be fully C# 3.0 compliant.
Jon
Pavel Minaev
> Just a definition question. What does "domain logic" mean? Thanks.
Essentially a synonym for "business logic". As usual, see Wikipedia
for details:
Ben Voigt [C++ MVP]
>
> I don't understand this. Are you saying that C# didn't get to use
> "static" when declaring a class until 2.0? That doesn't sound right
> to me. I'm also not clear on what you mean by "missing" with respect
> to Java, since you can effectively create a static class in Java just
> as easily in C#.
>
> I must be misunderstanding what you mean by "static classes"...please
> elaborate.
Java and C# use the term "static class" in totally different ways. In C#, a
nested class definition provides privileged access to private members of the
parent when properly addressed using a parent reference, and to generic
argument of the parent, but not an instance of the parent. In Java, a
nested class definition creates an "inner class" which is bound to an
instance of the parent, sort of like the closure that C# uses for anonymous
methods. In Java, "static class" is used to create a nested class that
isn't also an "inner class".
Ben Voigt [C++ MVP]
>> both disastrous and very hard to find.
>
> Exactly. And that is what led us to get accustomed to personal
> computers crashing, in the 1980s. Ten years earlier, in the
> mainframe era, with "less powerful" languages, it was very hard for a
> program written in a high-level language to crash the machine. Normally
> they terminated with recognizable errors (e.g., divide by
> zero) or they simply misbehaved (produced the wrong output). C#
> thankfully brings us back into that world. Program errors are
> program errors, not computer crashes.
This has absolutely zilch to do with language and everything to do with the
monolithic vs micro-kernel war.
Ben Voigt [C++ MVP]
>> 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.
>
> Until we get concepts in C++0x, essentially any C++ program that
> heavily uses templates in general, and template metaprogramming in
> particular (yes, that includes STL and Boost) is a rather masochistic
> exercise when it comes to deciphering compiler error messages.
That's what comments are for. We've had the capability to implement
compile-time asserts for quite some time, and the compile error will bring
you directly to the assert and the associated explanatory comment. Concepts
will be nicer of course, but it's not true to say you can't work with
templates usefully.
Ben Voigt [C++ MVP]
> [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?
For synchronous exceptions, no. If the C++ code is compiled with
asynchronous exceptions, then they map onto Win32 structured exceptions,
just like .NET exceptions, and they can be caught by .NET exception handlers
(although they will all appear as a generic 'C++ native exception' with no
more information available).
>
> 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
Daniel James
wrote:
> 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.
That comes back to what the blog /does/ say ... MS have apparently decided
(rightly or wrongly) that their customers want to use C# for GUI work, so
they are only providing GUI tools that target C#. That, in turn, gives the
impression that Microsoft want the users to use C# ... it's a vicious
circle.
It's also true that it's much easier to write these automated tools to work
with a simpler language (like C#) than a more complex one (like C++), so MS
make their own job easier by deciding not to support generation of C++
code.
As a programmer and /user/ of these tools, I would much rather that they
did the hard stuff for me automatically and let me do the easy stuff
myself!
> 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.
There are situations that absolutely require code that runs in a sandbox,
for security and/or robustness. In those cases a JVM or CLI language is
essential. For everything else I'd much rather work with native code
generation -- whatever language is being used.
So, yes, I think native code is the way to go for C++ ... and I'd choose
Java rather than C# for the sandboxed environments because it has greater
market penetration. To me, C# is a language that should never have been.
The case for it was only ever a business case (the licensing difficulties
with Sun over Java) not a technical one.
As far as C++/CLI goes: The word coming out of Redmond a couple of years
ago was that Microsoft's own programmers found that programming for the CLI
in C++/CLI (using the internal prototype tools) was more productive than
programming in C#, and that there was some swing back to C++ from C#
internally. I think that happened in Microsoft because Microsoft has some
extremely capable people, and they probably appreciated the power of C++
over C# more than an average programmer would do, and I think that this was
all taking place before some of the more sophisticated C# productivity
tools became available to make life easier for the C# guys.
I think it's tragic that we don't get the same level of tool support for
C++ as for C# -- I know it's harder to do, but I think the rewards are
obvious. C# would not be a serious choice for the professional programmer
if the tool support was as good for C++, and it's sad that C++'s acceptance
is being hampered just because the inferior language has better tools.
Cheers,
Daniel.
JF
> if the tool support was as good for C++, and it's sad that C++'s
> acceptance
> is being hampered just because the inferior language has better tools.
Presumably you've seen what most "C++" programmers pass off for code.
Therefore, while you may in fact be an excellent C++ programmer yourself (a
very rare breed), in reality most companies are bleeding huge $ from the
mess their so-called C++ programmers are producing. The bloodpath for most
other languages is also messy but far less severe. Whether it's
intrinsically superior to C# or not is therefore meaningeless. Outside the
halls of academia, C++ is (usually) a failure because most practitioners
can't handle it as well as a simpler and more forgiving language like C#
(which is hardly a second-rate language in its own right).
Pavel Minaev
> So, yes, I think native code is the way to go for C++ ... and I'd choose
> Java rather than C# for the sandboxed environments because it has greater
> market penetration. To me, C# is a language that should never have been.
> The case for it was only ever a business case (the licensing difficulties
> with Sun over Java) not a technical one.
Personally, looking at how slow Java develops, and how much mess they
accumulate due to need to stay backwards, and general resistance to
change (see Java generics for an example), I'm glad that we have C#
for purely technical reasons.
Ben Voigt [C++ MVP]
But most of the C# coders have only a fraction of the skill set (and
understanding of the underlying system) of even the not-so-good C++
developers. So yes, the average mistake made by the C++ dev is more
expensive to fix... but that doesn't mean that the C# coders won't make the
same mistake or that it won't be just as hard to fix when they do (though it
may be "less expensive" in dollars because C# man-hours cost less).
Giovanni Dicanio
> So, yes, I think native code is the way to go for C++
Agree.
> ... and I'd choose
> Java rather than C# for the sandboxed environments because it has greater
> market penetration. To me, C# is a language that should never have been.
> The case for it was only ever a business case (the licensing difficulties
> with Sun over Java) not a technical one.
I don't know about C# vs. Java market penetration.
However, I think that C# 3.0 is much better than Java. I'm glad that
Microsoft designed such a language (and framework).
Cheers,
Giovanni
Larry Smith
> understanding of the underlying system) of even the not-so-good C++
> developers.
Their understanding of the system is definitely superior but their
programming skills probably aren't much better. Most would likely write very
poor C# code as well, only now they have a safety net.
> So yes, the average mistake made by the C++ dev is more expensive to
> fix... but that doesn't mean that the C# coders won't make the same
> mistake or that it won't be just as hard to fix when they do (though it
> may be "less expensive" in dollars because C# man-hours cost less).
We definitely part company here. Pretty much every C++ program I've ever
seen is infested with serious design problems and outright bugs (latent or
otherwise). While I don't doubt that most C# programs have many problems as
well, it's not nearly on the same order of magnitude. The complexity of C++
coupled with the number of ways to shoot yourself in the foot (or rather
"blow your leg off" as Stroustrup once put it) makes it the 3rd rail of
programming languages. With C# you'll likely cry, with C++ you're gonna fry.
MC
>> fix... but that doesn't mean that the C# coders won't make the same
>> mistake or that it won't be just as hard to fix when they do (though it
>> may be "less expensive" in dollars because C# man-hours cost less).
>
> We definitely part company here. Pretty much every C++ program I've ever
> seen is infested with serious design problems and outright bugs (latent or
> otherwise). While I don't doubt that most C# programs have many problems
> as well, it's not nearly on the same order of magnitude. The complexity of
> C++ coupled with the number of ways to shoot yourself in the foot (or
> rather "blow your leg off" as Stroustrup once put it) makes it the 3rd
> rail of programming languages. With C# you'll likely cry, with C++ you're
> gonna fry.
Yes... the big difference is that with C#, errors manifest themselves as
incorrect output or recognizable error messages rather than random crashes
or memory leaks.
Andre Kaufmann
> JF wrote:
> [...]
> But most of the C# coders have only a fraction of the skill set (and
> understanding of the underlying system) of even the not-so-good C++
The problem is that you don't need the same skill set in C# (or other
languages) to solve a single problem and therefore even an experienced
developer will make less mistakes.
Multi-threading, GUI development is much easier in most of the other
languages compared to the efforts you have to take in C++, because they
support it out of the box. Fortunately C++ has Boost.
I've been a long time a die hard C++ programmer, but after having used
other languages like C#, D, Delphi or extending my C++ applications with
Python, Lua I know ask myself why all the stuff must be that complex in C++.
The only programming paradigm I miss in the other languages is RAII.
That's IMHO still a big plus of C++.
> developers. So yes, the average mistake made by the C++ dev is more
> expensive to fix... but that doesn't mean that the C# coders won't make the
> same mistake or that it won't be just as hard to fix when they do (though it
> may be "less expensive" in dollars because C# man-hours cost less).
A simple example:
How do I ensure in C++ that I have successfully overridden a base class
virtual function and that the compiler throws an error if the base class
implementation has changed ?
Andre
Larry Smith
> languages compared to the efforts you have to take in C++, because they
> support it out of the box. Fortunately C++ has Boost.
To be fair, this has nothing to do with C++ as a language (which has no
support for multi-threading or GUI whatsoever). You have to separate the
tools from the language itself.
> The only programming paradigm I miss in the other languages is RAII.
> That's IMHO still a big plus of C++.
RAII is also vastly superior to "IDispose" and "using" statements. OTOH,
.NET advocates will point out that the GC takes care of cleaning most
resources so the programmer has to do nothing at all. IMO the C++ paradigm
is still a better design but the reasons run too deep to get into here.
> A simple example:
>
> How do I ensure in C++ that I have successfully overridden a base class
> virtual function and that the compiler throws an error if the base class
> implementation has changed ?
C++ has many warts, many a legacy of C itself. From cast issues (very
dangerous) to forgetting to handle newly added class members in your
existing copy constructors and copy assignment operators. Templates are also
an incredible source of difficulty and potential errors (very difficult to
understand, read, and get right beyond the basics - some things will be
improving in C++0x but it's really too late). The use of #includes and
headers in general (from C) is also a hornets nest of serious problems. Not
to mention the usual issues of pointer handling, the cryptic nature of the
syntax itself (from C style arrays to function pointers to many types of
arcane C++ constructs like binders, adapters, etc. - did I mention
templates?). The dizzying array of rules and trap doors in general is very
difficult to master.
I also have some serious pet peeves. Why didn't they permit local classes to
be passed as template arguments. I once asked Stroustrup about this at a
conference but I wasn't satisfied with his terse response. The fact is that
many templates are useful for small local tasks. Why should I use the
"for_each" template for instance (among many others) if the tiny function
object I want to pass has to be declared outside the function itself (where
I'm using "for_each"). It would be so much cleaner to just declare the
function object locally. C# allows me to use anonymous methods which is so
much cleaner. The issues surrounding C++ go on and on.
Don't get me wrong, C++ is still a very powerful and flexible language with
incredible versatility (and very elegant design constructs in spite of all
the problems). The trade-off is that it's very difficult to master and
therefore prone to many serious problems. Even very experienced developers
have to continuously bend their minds out of shape and remain on guard years
after learning the language. This is not the hallmark of a successful
language in spite of C++'s "stellar" reputation and the millions who
continue struggling with it.
Giovanni Dicanio
[Larry Smith]
>> The only programming paradigm I miss in the other languages is RAII.
>> That's IMHO still a big plus of C++.
>
> RAII is also vastly superior to "IDispose" and "using" statements. OTOH,
> .NET advocates will point out that the GC takes care of cleaning most
> resources so the programmer has to do nothing at all.
The GC is fine for memory resources - it runs a garbage collection process
when under memory pressure.
But, what about non-memory resources (like sockets, textures, files, etc.) ?
I think that GC is designed for memory resources only, and has very little
clue about non-memory resources.
Instead, if you use RAII and a smart pointer (like shared_ptr, or some
intrusive reference count smart pointer) to manage non-memory resources,
they will be released as soon as the ref count becomes 0, making a very
efficient use of precious resources.
Yes, C# is a very well designed language, which incorporates lots of lessons
learned from C++, Java and Visual Basic.
But C# has not discovered destructors yet :)
Giovanni
Larry Smith
> when under memory pressure.
> But, what about non-memory resources (like sockets, textures, files, etc.)
> ?
> I think that GC is designed for memory resources only, and has very little
> clue about non-memory resources.
Yes, that's what "IDisposable" is for as previously mentioned. The "using"
statement is just a compiler-generated wrapper around it, putting your code
in a "try/finally block behind the scenes and calling
"IDisposable.Dispose()" for you. RAII is clearly much better than this.
> Instead, if you use RAII and a smart pointer (like shared_ptr, or some
> intrusive reference count smart pointer) to manage non-memory resources,
> they will be released as soon as the ref count becomes 0, making a very
> efficient use of precious resources.
>
> Yes, C# is a very well designed language, which incorporates lots of
> lessons learned from C++, Java and Visual Basic.
> But C# has not discovered destructors yet :)
Actually it has destructors but they're not the same as C++ destructors
(they're just compiler-generated wrappers for "Object.Finalize()"). I
already agree that object creation/destruction in C++ is cleaner and more
natural IMO. This hardly makes up for the many problems in C++ however. Like
many others, I have a love/hate relationship with it but objectively
speaking (IMO anyway), it's still a failure for the reasons I mentioned
previously.
Andre Kaufmann
>> Multi-threading, GUI development is much easier in most of the other
>> languages compared to the efforts you have to take in C++, because they
>> support it out of the box. Fortunately C++ has Boost.
>
> To be fair, this has nothing to do with C++ as a language (which has no
> support for multi-threading or GUI whatsoever). You have to separate the
> tools from the language itself.
I don't think so. What would C++ be without the standard library ?
And that GUI development is easier in other languages has IMHO something
to do with the language. C++ isn't IMHO fast enough in compilation to be
a good RAD language - at least you don't have the same developing
experience in C++ as in other languages.
> [...]
> RAII is also vastly superior to "IDispose" and "using" statements. OTOH,
Yes. Using is fine if I hold a resource in a control block, but if the
resource is held by let's say multiple lists, I have to use some kind of
smart pointers to handle the resources efficiently. In C# I can rely on
the GC to free the memory - so far that's fine. But resources should be
freed immediately, if they aren't used anymore.
> .NET advocates will point out that the GC takes care of cleaning most
> resources so the programmer has to do nothing at all. IMO the C++ paradigm
> is still a better design but the reasons run too deep to get into here.
>
>
> [...]
> understand, read, and get right beyond the basics - some things will be
> improving in C++0x but it's really too late). The use of #includes and
> headers in general (from C) is also a hornets nest of serious problems. Not
I don't think that it's too late, C++ modules could fix many problems.
But since they aren't in the upcoming standard I perhaps have to agree -
it will be too late.
> [...]
Andre
Peter Duniho
<gdicanio@_nospam_email_dot_it> wrote:
> [Larry Smith]
>
>>> The only programming paradigm I miss in the other languages is RAII.
>>> That's IMHO still a big plus of C++.
>>
>> RAII is also vastly superior to "IDispose" and "using" statements. OTOH,
>> .NET advocates will point out that the GC takes care of cleaning most
>> resources so the programmer has to do nothing at all.
>
> The GC is fine for memory resources - it runs a garbage collection
> process
> when under memory pressure.
> But, what about non-memory resources (like sockets, textures, files,
> etc.) ?
> I think that GC is designed for memory resources only, and has very
> little
> clue about non-memory resources.
This distinction has nothing to do with the _language_. If the OS was
entirely garbage collected, then these "non-memory resources" wouldn't be
an issue. They would be managed the same way memory is in .NET and you'd
never have to worry about disposing them.
Now, with certain types of objects you'd still have to deal with closing,
flushing, etc. But that's not something that RAII inherently solves; it
just happens that C++ classes can take advantage of that to handle those
operations. The OS API itself isn't based on C++ and requires the program
to deal with managing those operations.
In C++, RAII provides a convenient way to deal with that, and in C#, the
"using" statement does the same. You may prefer one syntax over the
other, but I personally don't see a difference between the two that would
justify an argument of superiority one way or the other. Larry's claim of
"vastly superior" seems particularly baseless. Vastly? Pure hyperbole.
Pete