If I haven't made substantial investment in either C++ or C#, which language
would the experts recommend I become well acquainted with?
Daniel
Jul 17 '08
151  4986 
"Daniel James" <wa*********@nospam.aaisp.orgha scritto nel messaggio
news:VA******************@nospam.aaisp.org...
news:<28**********************************@r66g200 0hsg.googlegroups.com>
, Pavel Minaev wrote:
>I disagree about the "business logic in C++" part. In practice,
standard C++ tends to be too low-level, verbose, and overcomplicated
for many common patterns that arise when developing a typical business
layer in many desktop and LOB applications.
I would have to disagree.
There is a lot of C++ code about that is lower-level than it needs to
be. When sensibly used C++ can result in code that is every bit as
high-level an abstraction of the business logic as you get with C#.
I agree with Daniel.
The main problem of C++ code is "old style" C++ code, more similar to C than
C++.
e.g. when raw pointers like char* are used instead of robust string classes
like std::string/CString, or instead of robust container classes like
std::vector.
Using tools like string classes, container classes and smart pointers makes
C++ code robust and easy to write and manage.
Giovanni
[Daniel James]
It's perfectly possibly to use C++/CLI to write GUI .NET applications --
it wouldn't be everybody's choice (for a number of good reasons) but it
is certainly possible ... and what Microsoft "recommend" shouldn't play
a big part in your decision-making process. Their recommendations are
often more political than technical, and in any case can't consider the
specific technical factors affecting any individual case.
For that matter: I don't think I've seen any definitive statement from
Microsoft saying that C++/CLI is no longer recommended for GUI .NET
applications ... can you provide a reference/link for that?
I would suggest reading this comment by Steve Teixeira to Somasegar's blog
post titled "Visual C++ Futures": http://blogs.msdn.com/somasegar/arch...s.aspx#4746812
<quote>
[...]
Hopefully I'm helping to paint a more accurate picture of the role of
C++/CLI. In a nutshell, we're focused on areas where we can add maximal
value, and we're deliberately avoiding investments in "me too" areas where
we can offer little value beyond a "C# with a preprocessor" experience. In
practical terms, this will often mean leaving the UI designer space in the
capable hands of C# and VB.NET while VC++ focuses on ensuring developers can
get the most out of the "guts" of their software.
[...]
Steve Teixeira
Group Program Manager, VC++
</quote>
Giovanni
Pavel Minaev wrote:
If you develop desktop applications, you typically have to make
installers for them. And, yes, given the limitations of Windows
Installer, it often requires one to write a custom action to do a
particular check or operation.
Pavel:
Well, I use Inno Setup for my installations, and for that you have to do the
customization in Pascal (unfortunately).
--
David Wilkinson
Visual C++ MVP
Daniel James wrote:
In article news:<ee**************@TK2MSFTNGP03.phx.gbl>, David Wilkinson
wrote:
>C++/CLI ... is the wrong choice if you want to write GUI Windows
applications, because Microsoft no longer recommends C++/CLi
for writing GUI .NET applications.
If you are an experienced C++ programmer but know no C# (or other .NET
language) and you want to write an application for the .NET runtime that
has some GUI functionality but a lot more back-end logic it might well
be ideal to use C++/CLI for the whole thing. There are no hard-and-fast
rules, here, just a lot of technologies that can play together or on
their own and which have different strengths and weaknesses.
It's perfectly possibly to use C++/CLI to write GUI .NET applications --
it wouldn't be everybody's choice (for a number of good reasons) but it
is certainly possible ... and what Microsoft "recommend" shouldn't play
a big part in your decision-making process. Their recommendations are
often more political than technical, and in any case can't consider the
specific technical factors affecting any individual case.
For that matter: I don't think I've seen any definitive statement from
Microsoft saying that C++/CLI is no longer recommended for GUI .NET
applications ... can you provide a reference/link for that?
>If you use native C++, you will probably want to use the MFC library
...
That's certainly a valid choice, and a reasonable one for a native C++
application that's limited to the Windows platform.
Other good choices would be Qt or the wxWdigets libraries which also
target other OSes, such as linux and MacOS.
>There are also hybrid methods, where you write your back-end in
standard C++, the GUI in C#, and build an interface layer using
C++/CLI. This may be appropriate if you have a large amount of
legacy C++ code ...
Yes, indeed. It's also an appropriate strategy if you want your back-end
code to be portable to ther systems but want to code a platform-specific
GUI for each target system to take best advantage of the facilities of
each platform. The Windows front-end can then be C# (or whatever takes
your fancy), and you can use other tools for other platforms.
Daniel:
These are indeed difficult decisions, and I do not believe the dust has fully
settled on the managed/native issue (maybe it never will).
I for one am glad that I have stuck with native code and MFC up till now.
Investing a lot of time in MC++ would certainly have been a big mistake, and
it's beginning to look like the same for C++/CLI (at least for GUI).
QT or wxwidgets are good for cross-platform, but QT is expensive and I'm not
sure about the longevity of wxwidgets. But really I do not think about porting
my applications any more, because I feel that CrossOver MAC and CrossOver Linux
do a pretty good job of running Windows applications.
So although I started out separating the "business logic" of my application from
the GUI (and writing the former in just ANSI C++, with no Microsoft-specific
stuff), I now think of using it in a revised app with the GUI in .NET and C#.
But not any time soon.
It's a pity that Microsoft's only supported native C++ GUI platform is MFC, but
there it is. It's inelegant, and bloated, but it works, for the most part. So
for now I'm sticking with MFC, forgetting about C++/CLI, and starting to learn
C# in my spare time.
--
David Wilkinson
Visual C++ MVP
On Jul 19, 5:56*pm, David Wilkinson <no-re...@effisols.comwrote:
It's a pity that Microsoft's only supported native C++ GUI platform is MFC, but
there it is.
Why restrict yourself to Microsoft-produced GUI frameworks, though? Qt
is an excellent-quality powerful framework with full commercial
support on Windows and Microsoft C++ compilers, and complete Visual
Studio integration - and that's just one example.
On Jul 19, 4:36*pm, "Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it>
wrote:
The main problem of C++ code is "old style" C++ code, more similar to C than
C++.
e.g. when raw pointers like char* are used instead of robust string classes
like std::string/CString, or instead of robust container classes like
std::vector.
Using tools like string classes, container classes and smart pointers makes
C++ code robust and easy to write and manage.
Well, sort of. Until you accidentially invalidate an iterator by
modifying the container - U.B. Or mix signed and unsigned integer
types in an arithmetic expression and get weird results because of the
silent signed->unsigned conversion rule (and it is very easy to do so,
since a lot of standard library functions return unsigned integers -
e.g. size() of any STL container is unsigned). Or forget that
assignment operator and "copy" constructor for auto_ptr are actually
move and not copy. Or put an auto_ptr into a container (and why not,
if it lets you do so without any compaints...). Or try to make sense
of three paragraphs of ISO C++ standard describing overload resolution
for template functions in presence of partial specializations (the one
where synthetic types are involved). The problem is, you have to be a C
++ expert to write good C++ code, and, not any less important, to be
able to understand advanced C++ code written by others that's thrown
at you.
Don't get me wrong, C++ is a great language, and the time I've spent
writing in it was great. But from my experience, I would never let it
anywhere near domain logic except where it is spefically needed, when
I have the choice, because too many times I've witnessed how even
skilled and experienced (5+ years) C++ developers wrote some seemingy
trivial code which then broke things in subtle ways. I once spent 2
whole work days in the debugger trying to find the code that lead to
"Heap corrupted" error which invariably manifested itself under
unclear conditions after the program was used for 2-3 hours. It's not
fun at all. It's also something that's much, much rarer in the
"managed code" land.
David Wilkinson wrote:
So although I started out separating the "business logic" of my
application from the GUI (and writing the former in just ANSI C++, with
no Microsoft-specific stuff), I now think of using it in a revised app
with the GUI in .NET and C#. But not any time soon.
Oops. I meant to say that while my original reason for separating GUI from
business logic was for porting to Mac or Linux, I now think it more likely that
I will use my native C++ business logic in a .NET C# application on Windows.
--
David Wilkinson
Visual C++ MVP
I have the choice, because too many times I've witnessed how even
skilled and experienced (5+ years) C++ developers wrote some seemingy
trivial code which then broke things in subtle ways. I once spent 2
whole work days in the debugger trying to find the code that lead to
"Heap corrupted" error which invariably manifested itself under
unclear conditions after the program was used for 2-3 hours. It's not
fun at all. It's also something that's much, much rarer in the
"managed code" land.
I completely agree with you. After many years in the field I have yet to
meet one C++ programmer whose code I actually trust. Experience typically
makes little difference. Novices will make many mistakes because they're
inexperienced. The experienced will still make many mistakes but at this
stage they should know better. Design skills are another matter entirely
(usually very poor). This is not arrogance speaking because I know there are
decent programmers out there. Unfortunately they are few and far between.
Most are just a very expensive burden on their employers and management is
usually clueless. I once met a very senior person in C++ circles (I won't
mention his name) and I asked him for his opinion. He suggested that perhaps
5% of all C++ programmers are competent. I wish I were that optimistic.
Daniel James wrote:
In article
news:<28**********************************@r66g200 0hsg.googlegroups.com>
, Pavel Minaev wrote:
>I disagree about the "business logic in C++" part. In practice,
standard C++ tends to be too low-level, verbose, and overcomplicated
for many common patterns that arise when developing a typical business
layer in many desktop and LOB applications.
I would have to disagree.
There is a lot of C++ code about that is lower-level than it needs to
be. When sensibly used C++ can result in code that is every bit as
high-level an abstraction of the business logic as you get with C#.
Sure, bad C++ programming will lead to a poor abstraction and
overcomplex code, but so will bad programming in any language.
But it is easier to write bad code in C++ than in so many'
other languages.
C++ has some very unsafe constructs (many of them inherited from C).
The C++ language is pretty complex to master. C++ has all the
implementation specific/undefined gotchas. And there is usually a
gap between the C++ standard and the C++ compilers implementation.
Arne
In article news:<#e**************@TK2MSFTNGP04.phx.gbl>, Giovanni Dicanio wrote:
For that matter: I don't think I've seen any definitive statement
from Microsoft saying that C++/CLI is no longer recommended for
GUI .NET applications ... can you provide a reference/link for
that?
I would suggest reading this comment by Steve Teixeira to Somasegar's
blog post titled "Visual C++ Futures":
http://blogs.msdn.com/somasegar/arch...s.aspx#4746812
Thanks for that. I had seen it before ... and I don't see anything there
that suggests that C++/CLI is "not recommended" for GUI code. All Steve
says that's at all relevant is that MS don't propose to spend time writing
GUI design tools that target C++/CLI when they already have some that
target C# and there are other things they want to spend resources on to
support C++.
That's a fair enough viewpoint, and the message in the blog is that MS (or,
at least, the C++ team) are following what they believe to be the wishes of
their customers in that respect.
That doesn't mean that they don't recommend using C++/CLI, it means that
they won't provide any tools to help you do that. That's not big deal,
really, because it doesn't actually matter what language any automatically
generated code is in -- the form designer might as well spit out a compiled
assembly as C#. Microsoft do say that the C# generated by the designers
isn't supposed to be edited by the user -- that's how they get away with
emitting such poorly structured code.
You don't actually *need* to have any tools to help you write GUI code,
anyway. You can do it all by hand. The form designers may save you some
time but in a large project that time is not significant, and hand-crafted
code will be better structured and more maintainable than anything that
comes from the designers.
Cheers,
Daniel.
In article news:<u0**************@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.
Remember Sturgeon's (second) rule. http://en.wikipedia.org/wiki/Sturgeon%27s_revelation
Cheers,
Daniel.
In article news:<ex**************@TK2MSFTNGP06.phx.gbl>, David Wilkinson
wrote:
But really I do not think about porting my applications any more,
because I feel that CrossOver MAC and CrossOver Linux do a pretty
good job of running Windows applications.
That's a good point -- and well made -- and if your apps are all desktop
apps then it may be a good enough solution for you. I achieve much the
same by running Windows apps in a Windows VM under linux; it means I have
to have a licensed copy of Windows to run in the VM, which you avoid by
using Crossover (or Wine), but that is not a big problem.
Many customers, though, insist on a native application and won't accept
the additional cost in hardware resources needed by either Crossover or a
VM.
In my work I have often had to share code between a desktop application
and an embedded application, so the separation between back-end logic
(ROMmable) and GUI has been very important.
Cheers,
Daniel.
Daniel James wrote:
Thanks for that. I had seen it before ... and I don't see anything there
that suggests that C++/CLI is "not recommended" for GUI code. All Steve
says that's at all relevant is that MS don't propose to spend time writing
GUI design tools that target C++/CLI when they already have some that
target C# and there are other things they want to spend resources on to
support C++.
That's a fair enough viewpoint, and the message in the blog is that MS (or,
at least, the C++ team) are following what they believe to be the wishes of
their customers in that respect.
That doesn't mean that they don't recommend using C++/CLI, it means that
they won't provide any tools to help you do that. That's not big deal,
really, because it doesn't actually matter what language any automatically
generated code is in -- the form designer might as well spit out a compiled
assembly as C#. Microsoft do say that the C# generated by the designers
isn't supposed to be edited by the user -- that's how they get away with
emitting such poorly structured code.
You don't actually *need* to have any tools to help you write GUI code,
anyway. You can do it all by hand. The form designers may save you some
time but in a large project that time is not significant, and hand-crafted
code will be better structured and more maintainable than anything that
comes from the designers.
Daniel:
Maybe I should not say "Microsoft does not recommend" then. Do you think
"Microsoft does not promote" would be more accurate? Or do you feel that is too
strong also?
I'm sure there are some advanced users who use C++/CLI to write GUI .NET
applications, but the vast majority of the C++/CLI questions I see in the
newsgroups/forums come from novices who have downloaded VC++ Express and have
found that, absent MFC, the only out-of-the-box way to write GUI applications is
to use .NET. Many of these folks, like the OP, are not even aware that the
language they are using is not C++. They have chosen C++ because the name sounds
familiar, or perhaps know it a bit already, but the vast majority of these
people would have been batter off downloading VC# Express instead. At any rate,
they are not going to be happy if the forms designer in VC++ is crippled.
But even experienced C++ users seem to be embracing C# over C++/CLI. It's not
just the designer tools; some features (such as LINQ) are not even available in
C++/CLI. It's a shame after all the effort that went into C++/CLI (after the
initial MC++ debacle), but there it is.
What's the solution? I think MS has to fully face up to the fact that VC++ is
for native code, get the IDE back to the level of usability/responsiveness we
had in VC6, and put MFC (and the PSDK) into VC++ Express. I don't think it is
anybody's interest to "entrap" beginners into C++/CLI.
--
David Wilkinson
Visual C++ MVP
Pavel Minaev <in****@gmail.comwrote:
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
-- Sp******@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
On Jul 20, 3:07*pm, "Hendrik Schober" <SpamT...@gmx.dewrote:
* 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.
"David Wilkinson" <no******@effisols.comha scritto nel messaggio
news:ej**************@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
>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.
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.
Daniel James wrote:
In article news:<u0**************@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
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":
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
On Sun, 20 Jul 2008 16:49:43 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
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<Tisn'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<Tin 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
Peter Duniho wrote:
On Sun, 20 Jul 2008 16:49:43 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
>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<Tisn'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<Tin 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...=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
>>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.
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.
Daniel James wrote:
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
On Sun, 20 Jul 2008 18:55:20 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
[...]
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...=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
On Jul 21, 12:49*am, Arne Vajhøj <a...@vajhoej.dkwrote:
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<Tis 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
On Jul 21, 4:28*am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
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
On Sun, 20 Jul 2008 22:45:26 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
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
On Jul 19, 12:40*pm, Pavel Minaev <int...@gmail.comwrote:
On Jul 19, 4:36*pm, "Giovanni Dicanio" <gdicanio@_NOSPAM_email_DOT_it>
wrote:
The main problem of C++ code is "old style" C++ code, more similar to Cthan
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.
Just a definition question. What does "domain logic" mean? Thanks.
On Jul 18, 3:08*pm, "Jon Skeet [C# MVP]" <sk...@pobox.comwrote:
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
On Jul 21, 3:43*pm, jmDesktop <needin4mat...@gmail.comwrote:
Just a definition question. *What does "domain logic" mean? *Thanks.
Essentially a synonym for "business logic". As usual, see Wikipedia
for details: http://en.wikipedia.org/wiki/Domain_logic
>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.
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".
>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.
This has absolutely zilch to do with language and everything to do with the
monolithic vs micro-kernel war.
>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.
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.
Giovanni Dicanio wrote:
[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
In article news:<ej**************@TK2MSFTNGP05.phx.gbl>, David Wilkinson
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.
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.
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).
On Jul 23, 6:13*pm, Daniel James <wastebas...@nospam.aaisp.orgwrote:
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.
JF wrote:
>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.
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).
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).
[Daniel James]
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
Ben Voigt [C++ MVP] wrote:
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
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.
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.
[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
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.
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.
Larry Smith wrote:
>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
On Thu, 24 Jul 2008 06:43:30 -0700, Giovanni Dicanio
<gdicanio@_nospam_email_dot_itwrote:
[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
>>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 ?
It would be another language since it must include the library by
definition. Contrast this to C# whose basic support is primitive (see the
standard for yourself). In any case, the claim that GUI development is
"easier" in C# compared to C++ has nothing to do with the languages
themselves. It's the rich set of classes in MSFT's framework combined with
better development tools that make C# easier (noting that C# is a natural
fit for the framework unlike C++). Provide an equivalent C++ library and
better tools and it will be just as easy (not taking into account the actual
language differences).
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.
The "using" statement is ugly compared to RAII. Moreover, in theory your
unmanaged resources may never be released if you neglect to call
"IDisposable.Dispose()". Other problems also exist with this pattern.
>
>.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.
The core language is in place. Enhancements won't change that. The problems
inherent in C++ will remain forever unless it morphs into a different
language (but then it won't be C++ anymore).
"Peter Duniho"
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.
Destructor and "scope" syntax in C++ is cleaner, simpler and more elegant
than C# bloated 'using'.
Moreover, there is big difference between C++ RAII and C# "using".
In Andre's words:
<quote>
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.
</quote>
For example: I think that there is nothing like shared_ptr in C#.
With shared_ptr you can have a *deterministic* resource manager, and you can
wrap also non-memory resources in classes and store shared_ptr to these
class instances into STL containers, and that works fine and is very elegant
and simple.
And there are also intrusive smart pointers, you may consider Eugene
Gershink's implementation here: http://www.gershnik.com/articles/refcnt_ptr.asp
BTW: I'd like to make it clear that I'm saying neither that C++ is better
than C#, nor that C# is better than C++. Simply, both languages have pros
and cons.
Giovanni
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
That's hardly a valid argument, considering that RAII requires no "using"
statement whatsoever. This alone justifies an argument that there is a
difference in favour of C++ (in contrast to your assertion).
Larry's claim of "vastly superior" seems particularly baseless. Vastly?
Pure hyperbole.
Point conceded. Scratch the word "vastly".
On Thu, 24 Jul 2008 10:25:47 -0700, Giovanni Dicanio
<gdicanio@_nospam_email_dot_itwrote:
"Peter Duniho"
>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.
Destructor and "scope" syntax in C++ is cleaner, simpler and more elegant
than C# bloated 'using'.
Purely subjective. That sort of claim has no place in a technical
discussion.
Moreover, there is big difference between C++ RAII and C# "using".
In Andre's words:
<quote>
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.
</quote>
RAII doesn't _inherently_ support "smart pointers", nor does a garbage
collecting system prevent one from implementing "smart pointers".
As I pointed out before, in a 100% GC-ed system, "smart pointers" become
unnecessary anyway. But in a mixed system (i.e. pretty much any current
platform), it's entirely possible to implement "smart pointers", and they
can work in a very similar way to that implemented with RAII.
Which only brings us back to your purely subjective complaints about
"using".
Pete
On Thu, 24 Jul 2008 10:35:59 -0700, Larry Smith <no_spam@_nospam.com>
wrote:
>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
That's hardly a valid argument, considering that RAII requires no "using"
statement whatsoever. This alone justifies an argument that there is a
difference in favour of C++ (in contrast to your assertion).
You save a whole line of code. Wow! Yup...that definitely outweighs any
advantage that garbage collection has with respect to simplifying and
improving the robustness of memory management. After all, that's what
programmers really care about. I'd much rather save a line of code than
make it more likely that my code is correct.
>Larry's claim of "vastly superior" seems particularly baseless.
Vastly?
Pure hyperbole.
Point conceded. Scratch the word "vastly".
Replace it with "insignificantly", and then _maybe_ you've got a point.
Personally, I think a discussion comparing/constrasting languages should
be limited to things that actually matter.
But hey, if you guys want to keep wasting time arguing about pointless
differences, be my guest.
Pete This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Rob |
last post by:
i know javascript, vbscript, asp css and alot more and im only 14 i was
wondering which is easier to learn php or cgi. any help?
|
by: Bicho Verde |
last post by:
I have now free time and money to do what I want :-)
I have some basic skills in programming (C, Pascal, Macromedia
Actionscript) but don't know exactly what to do in the world of programming.
And...
|
by: Elijah |
last post by:
I have read many of the topics on learning C++ or Java first.
It seems like everyone says something different.
I would like to know if I should learn C++ or Java.
First a little about myself.
I...
|
by: Rhino |
last post by:
I am giving some thought to applying for some jobs that want people with
Java and C++ experience. I have been writing Java for several years and am
fluent enough that I don't have to get help with...
|
by: Hermawih |
last post by:
Hello ,
I want your opinion about this .
In order to say it clearly , I think I have to describe it in long sentences .
I could consider myself as Intermediate/Advance Access Developer ;...
|
by: TAM |
last post by:
Hi,
I read that ASP.NET uses VB.NET instead of VBScript. I also read that
ASP.NET is a subset of VB.NET. So if I learn VB.NET first then do I have the
knowledge for programming ASP.NET...
|
by: abhi |
last post by:
hi everybody am new to this group and help me to learn C
|
by: anand devarajan |
last post by:
hi friends,
im anand im just a beginner in c learning for the past two
weeksnow i can write simple prgs can anyone help me to get well known
to c lang so that i should able to write even tough...
|
by: pandit |
last post by:
hai all,
i want to become a good programmer. one of my friends ( named
"arnuld", he posts here infrequently), taught me Lisp. so i am not a
programming beginner.
i have heard these 2 points....
|
by: Chris Carlen |
last post by:
Hi:
From what I've read of OOP, I don't get it. I have also found some
articles profoundly critical of OOP. I tend to relate to these articles.
However, those articles were no more objective...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
