learn C++ or C#

[Daniel]

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

Daniel

[Larry Smith]

But hey, if you guys want to keep wasting time arguing about pointless

differences, be my guest.

http://en.wikipedia.org/wiki/Hypocrisy

[David Wilkinson]

Peter Duniho wrote:

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.

Not only is the "using" mechanism less convenient/elegant for the client of the
class than RAII (not to mention the possibility of forgetting to do it), but a
C# Dispose'd object can still be used (unlike a C++ object that goes out of
scope or is delete'd). This places an additional burden on the writer of an
IDisposable class.

IMHO, any use of a Dispose'd object should automatically cause a
"ObjectIsDeadEx ception" rather than relying on the author to test and throw an
ObjectDisposedE xception in every method.

--
David Wilkinson
Visual C++ MVP

[Peter Duniho]

On Thu, 24 Jul 2008 11:23:49 -0700, David Wilkinson
<no******@effis ols.comwrote:

Not only is the "using" mechanism less convenient/elegant for the client
of the class than RAII (not to mention the possibility of forgetting to
do it), but a C# Dispose'd object can still be used (unlike a C++ object
that goes out of scope or is delete'd).

I was comprehending your post until "or is delete'd". There's nothing in
C++ to stop someone from trying to use an object that's been deleted, and
depending on how the memory was allocated and what the class does in its
destructor, doing so might even work for awhile.

This places an additional burden on the writer of an IDisposable class.

I don't see how it's any more burden than already exists in C++. There's
no requirement that a disposable class actually catch post-disposal uses.
It's nicer, but then so too would it be nicer for a C++ class to catch
uses that occur after destruction. And I think it's easier for a C# class
to do so, because the object is still actually allocated and the code in
the class can behave predictably; in C++, sometimes using an object after
destruction will fail immediately, and sometimes it won't.

IMHO, any use of a Dispose'd object should automatically cause a
"ObjectIsDeadEx ception" rather than relying on the author to test and
throw an ObjectDisposedE xception in every method.

I don't disagree that RAII allows for an object to simply "disappear" when
the scope is exited, but this is how "using" works in C# too. Variables
declared in the "using" statement are valid only for the scope of the
block of that statement.

And just as in C#, the reference to the variable declared in the "using"
statement could "escape" by being passed to something else, so too could a
pointer to a stack-allocated C++ object escape. RAII in C++ doesn't
actually guarantee that you can't use the object reference after the
object itself has been destroyed. It just ensures that the object is
destroyed outside a particular scope, just as "using" does.

If anything, at least with a garbage collecting system, you know that if
you have a reference to something, that's a valid reference. The object
itself might be in an unusable state, but it will always be able to tell
you that one way or the other.

Again, in terms of any practical difference between the two, any
difference is negligible and not a point worth worrying about in terms of
comparing the languages. One might save a little typing over the other
(and there are other examples going the other direction), but in the
greater scheme of things, that's just not important.

Pete

[Andre Kaufmann]

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 ?

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

The RAD tools have to parse the source code, which is more complex in
C++ and therefore there aren't that much (good) RAD tools for C++ or
they feel somewhat sluggish.
So let's restrict the "easier" part on development of good RAD tools not
on using them.

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

With easier I meant the whole development experience - so it was perhaps
somewhat misleading to use the word "easier".
With development experience I mean Intellisense / refactoring / fast
compilation and so on.

There are GUI frameworks supported by different languages including C++:

C++ (/CLI): WinForms, VCL
C# : WinForms
Delphi : VCL

But IMHO the development experience in C#, Delphi is better than in C++,
just because of the compilation speed. It makes a huge difference if you
wait multiple minutes after having touched the GUI or just a few seconds.

Andre

[Andre Kaufmann]

Peter Duniho wrote:

On Thu, 24 Jul 2008 11:23:49 -0700, David Wilkinson
<no******@effis ols.comwrote:
[...]
I don't disagree that RAII allows for an object to simply "disappear"
when the scope is exited, but this is how "using" works in C# too.
Variables declared in the "using" statement are valid only for the scope
of the block of that statement.
[...]

For scoped resource handling I think "using" is a good alternative for
RAII. But I miss RAII sometimes in C#:

E.g:

list (a) - holds a file object (f)
list (b) - holds the same file object (f)

When I remove (f) from list (a) I have to check if list (b) holds the
file object too or rely on GC to close it - but I think that wouldn't be
a good idea, since the file would be open, till the GC has disposed the
object.

In C++ I can use RAII smart pointers to ensure that the file is closed
as soon as it's not used anymore. In C# I have no automatism to handle
this.

I see that there are benefits in GC over RC = reference counting, but
IMHO both are relevant:

GC - for memory
RC - for resources
Andre

[David Wilkinson]

Peter Duniho wrote:

>Not only is the "using" mechanism less convenient/elegant for the
client of the class than RAII (not to mention the possibility of
forgetting to do it), but a C# Dispose'd object can still be used
(unlike a C++ object that goes out of scope or is delete'd).

I was comprehending your post until "or is delete'd". There's nothing
in C++ to stop someone from trying to use an object that's been deleted,
and depending on how the memory was allocated and what the class does in
its destructor, doing so might even work for awhile.

>This places an additional burden on the writer of an IDisposable class.

I don't see how it's any more burden than already exists in C++.
There's no requirement that a disposable class actually catch
post-disposal uses. It's nicer, but then so too would it be nicer for a
C++ class to catch uses that occur after destruction. And I think it's
easier for a C# class to do so, because the object is still actually
allocated and the code in the class can behave predictably; in C++,
sometimes using an object after destruction will fail immediately, and
sometimes it won't.

>IMHO, any use of a Dispose'd object should automatically cause a
"ObjectIsDeadE xception" rather than relying on the author to test and
throw an ObjectDisposedE xception in every method.

I don't disagree that RAII allows for an object to simply "disappear"
when the scope is exited, but this is how "using" works in C# too.
Variables declared in the "using" statement are valid only for the scope
of the block of that statement.

And just as in C#, the reference to the variable declared in the "using"
statement could "escape" by being passed to something else, so too could
a pointer to a stack-allocated C++ object escape. RAII in C++ doesn't
actually guarantee that you can't use the object reference after the
object itself has been destroyed. It just ensures that the object is
destroyed outside a particular scope, just as "using" does.

If anything, at least with a garbage collecting system, you know that if
you have a reference to something, that's a valid reference. The object
itself might be in an unusable state, but it will always be able to tell
you that one way or the other.

<snip>

Pete:

Well, I think C++ programmers (even bad ones) are generally aware of lifetime
issues, whereas C# programmers can be lulled into a sense of false security by
the "garbage collector will take care of everything" mindset.

I just find this notion of the "half dead" object rather disturbing. Surely it
would have been possible for the C# language to be defined such that use of a
Dispose'd object automatically throws an exception?

--
David Wilkinson
Visual C++ MVP

[Peter Duniho]

On Thu, 24 Jul 2008 12:30:34 -0700, Andre Kaufmann
<an************ *********@t-online.dewrote:

[...]
When I remove (f) from list (a) I have to check if list (b) holds the
file object too or rely on GC to close it - but I think that wouldn't be
a good idea, since the file would be open, till the GC has disposed the
object.

In C++ I can use RAII smart pointers to ensure that the file is closed
as soon as it's not used anymore. In C# I have no automatism to handle
this.

But you can include reference counting in the C# object if you want. You
can even implement a "smart pointer" class that uses Dispose() to
decrement the counter and call Dispose() on the wrapped object if it
reaches 0.

Personally, I've had enough headaches with reference counting in my
lifetime, and I try to avoid it when I can, smart pointers
notwithstanding . I prefer to not create designs in the first place where
unique ownership of the object is unclear. But there's nothing about C#
that precludes using that technique if you find yourself in a situation
where you think it's useful or needed.

Pete

[Peter Duniho]

On Thu, 24 Jul 2008 12:41:17 -0700, David Wilkinson
<no******@effis ols.comwrote:

Well, I think C++ programmers (even bad ones) are generally aware of
lifetime issues, whereas C# programmers can be lulled into a sense of
false security by the "garbage collector will take care of everything"
mindset.

I have seen too much bad C++ code (especially code with rampant memory
leaks) in my life to have the high opinion of bad C++ programmers you
apparently have. Conversely, part of being proficient with C# is
understanding how the garbage collection works, and how that interacts
with the non-garbage-collecting parts of the platform. Only bad C#
programmers are "lulled into a sense of false security".

I just find this notion of the "half dead" object rather disturbing.
Surely it would have been possible for the C# language to be defined
such that use of a Dispose'd object automatically throws an exception?

Well, first of all, to some extent it's a question of what the CLR
requires, not what C# requires. And sure, it could. But why?
IDisposable has a specific goal in mind, and no part of that goal involves
requiring that an object become unusable after Dispose() is called.

Inasmuch as there may be classes out there for which it makes sense to
still be able to use the object after it's been disposed, why should the
language or run-time impose an arbitrary restriction on that ability?

As an example: the Form class does not dispose instances when the Form is
closed if it was shown using ShowDialog(), even though it does if the Form
was shown using Show(). This inconsistent behavior is to allow retrieval
of values from the controls in the form after it's been closed. But one
can easily imagine an implementation that completely separates the
unmanaged aspects from the managed aspects, copying any data from the
unmanaged resources upon disposal so that they are still accessible. Then
closing the modal form could be the same as closing the non-modal form: in
both cases, closing implies disposal.

But one could only make that more consistent behavior as long as the
run-time allows a disposed object to be used after Dispose() is called.

Just because an object is done with its unmanaged resources, that doesn't
mean to me that it's "half-dead". It's just done with the unmanaged
resources. If a class wants to allow disposal prior to actually being
done with the object and still permit certain operations on the object
after disposal, that should be its right.

Pete

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nn owslpianmk.comw rote:

<snip>

Just because an object is done with its unmanaged resources, that doesn't
mean to me that it's "half-dead". It's just done with the unmanaged
resources. If a class wants to allow disposal prior to actually being
done with the object and still permit certain operations on the object
after disposal, that should be its right.

MemoryStream is one example, by the way - you can still call ToArray on
it after closing it as a stream.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Ben Voigt [C++ MVP]]

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 ?

You can't do that in any language I'm aware of, so it's a non-issue. Did
you mean "error if the signature of the function in the base class has
changed"?

>
Andre