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

[Ben Voigt [C++ MVP]]

Peter Duniho wrote:

On Thu, 24 Jul 2008 10:25:47 -0700, Giovanni Dicanio
<gdicanio@_nosp am_email_dot_it wrote:

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

It's quite objective. In C++, the burden is on the library developer, the
user needs no extra syntax to benefit from automatic cleanup.

>

>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

Nothing could be further from the truth. Lazy (or deferred, if you prefer)
cleanup breaks access to shared resources, and does so
non-deterministical ly.

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.

No, in C# it's not possible to create an object that automatically performs
cleanup when it becomes unreachable. You can only do so (1) manually, or
(2) when its memory is reclaimed.

>
Which only brings us back to your purely subjective complaints about
"using".

Pete

[Ben Voigt [C++ MVP]]

Peter Duniho wrote:

On Thu, 24 Jul 2008 10:35:59 -0700, Larry Smith <no_spam@_nospa m.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.

The C# way is brittle. If C# let you use a using statement with types that
don't support IDisposable, then it would be better. But right now, adding
IDisposable support to an existing class is always an impermissible breaking
change.

In C++, you can add a destructor without any changes to the code which
references the class.

That's a much bigger issue than saving a single line of code.

[Ben Voigt [C++ MVP]]

Peter Duniho wrote:

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.

C++ delete calls the implementation of 'operator delete' after running the
destructor, which can mark the memory with a pattern (or on some CPUs, even
set up data breakpoints to trap any future access to that memory) which in
debug builds would detect use after free. You can use something like
electric fence which will deallocate the segment, generating a segfault on
any future access to that object. All of which can be done without any
changes to the class being protected.

So no, these aren't "in C++", because one of the prime ideals of C++ is "you
don't pay for what you don't use". You turn on these features during
debugging, and perhaps in extremely critical environments where failure
detection is more important than efficiency you might leave them on in the
release build. In all other circumstances, you convince yourself through
thorough testing that these sorts of bugs have been eliminated, and disable
the checks.

[Peter Duniho]

On Thu, 24 Jul 2008 15:14:38 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nos pamwrote:

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

It's quite objective. In C++, the burden is on the library developer,
the
user needs no extra syntax to benefit from automatic cleanup.

You don't seem to have read the statements you quoted.

I'm talking about the question of the syntax itself, not the semantics.
The need to include a "using" statement is not a "burden". It's just a
different way to write the same thing.

[...]

>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

Nothing could be further from the truth.

Ah, more hyperbole. Yup...that really makes your point compelling.

Lazy (or deferred, if you prefer)
cleanup breaks access to shared resources, and does so
non-deterministical ly.

In a 100% GC-ed system, a resource that's eligible for "cleanup" is not
"shared" by any code anywhere, by definition. Your statement makes no
sense.

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

No, in C# it's not possible to create an object that automatically
performs
cleanup when it becomes unreachable.

I never said it was. But nice straw man.

Pete

[Peter Duniho]

On Thu, 24 Jul 2008 15:17:05 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nos pamwrote:

The C# way is brittle. If C# let you use a using statement with types
that
don't support IDisposable, then it would be better. But right now,
adding
IDisposable support to an existing class is always an impermissible
breaking
change.

In C++, you can add a destructor without any changes to the code which
references the class.

If C++ didn't have its own brittle behaviors (including limitations on the
use of stack-allocated classes), I might think your point has some merit
here.

But it does, so I don't.

Pete

[Peter Duniho]

On Thu, 24 Jul 2008 15:22:47 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nos pamwrote:

[...essay on C++ built-in testing aids...]
In all other circumstances, you convince yourself through
thorough testing that these sorts of bugs have been eliminated, and
disable
the checks.

Yes, I'm aware of all of the debugging aids C++ includes so that you can
hopefully detect coding errors that simply aren't possible in C#.

As far as I'm concerned, you're just making my point for me.

[Andre Kaufmann]

Peter Duniho wrote:

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

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

I can include reference counting, but I can't use smart pointers. I
prefer GC memory handling, but for resources GC can't be used
effectively, because often resources have to be released directly.
I do a lot of multi threaded programming, there I permanently have the
need of some kind of reference counted resource handling.

[...]
But there's nothing about C# that precludes using that
technique if you find yourself i

If you could add methods to value structures in C# I would agree. But
currently in C# you have to either use a temporary object in combination
with using or call the AddRef / Release functions by hand.

Perhaps it wouldn't be a good idea to add the complexity of C++ which
allows RAII to C#, but some kind of simple automatism would IMHO help too.

E.g. the temporary objects could be replaced by some kind of using which
calls specified methods of an object.

Pseudo code:

MyObject o; // member variable
....
autocall(o) --calls enter / leave methods automatically
{ // call o.enter()
} // call o.leave()

Pete

Andre

[Peter Duniho]

On Thu, 24 Jul 2008 22:43:52 -0700, Andre Kaufmann
<an************ *********@t-online.dewrote:

Peter Duniho wrote:

>On Thu, 24 Jul 2008 12:30:34 -0700, Andre Kaufmann
<an*********** **********@t-online.dewrote:
[...]
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.

I can include reference counting, but I can't use smart pointers.

Why not?

I prefer GC memory handling, but for resources GC can't be used
effectively, because often resources have to be released directly.
I do a lot of multi threaded programming, there I permanently have the
need of some kind of reference counted resource handling.

For what it's worth, I've done a fair amount of multi-threaded programming
in C# without needing ref-counting.

Not that I agree that ref-counting can't be done in C#, but I've found
that in many cases, what's really needed is a different way of looking at
the problem.

>[...]
But there's nothing about C# that precludes using that
technique if you find yourself i

If you could add methods to value structures in C# I would agree.

I don't know what you mean here. What methods do you want to add? To
what structure? How would that help?

But currently in C# you have to either use a temporary object in
combination with using or call the AddRef / Release functions by hand.

How is a smart pointer not a temporary object?

Perhaps it wouldn't be a good idea to add the complexity of C++ which
allows RAII to C#, but some kind of simple automatism would IMHO help
too.

E.g. the temporary objects could be replaced by some kind of using which
calls specified methods of an object.

Pseudo code:

MyObject o; // member variable
....
autocall(o) --calls enter / leave methods automatically
{ // call o.enter()
} // call o.leave()

Why not just create a smart-pointer-like class or struct that does that
with the "using" statement? Adds a ref when the object is created,
decrements the ref on disposal, zero ref-count causes disposal of the
wrapped object.

Maybe I'm just being obtuse, but I don't see what the big problem is.

Pete

[Daniel James]

In article news:<Od******* *******@TK2MSFT NGP02.phx.gbl>, Mc wrote:

Yes... the big difference is that with C#, errors manifest themselves
as incorrect output or recognizable error messages rather than random
crashes or memory leaks.

At least you KNOW there's something wrong when you get a random crash ...
that incorrect output you get from your C# program is really much more
dangerous.

I think you and Larry and others here blowing the C# trumpet are vastly
over-stating the case about C++ being hard to use and hard to get right.
The fact is that bad programmers will write bad code in any language, and
if you want good code you have to employ good programmers. Once you have
those your problems will start to go away -- whatever language you are
using.

Of course, you need good management, too. Bad management and irrational
budgetary constraints can ruin a project just as easily as bad programming.

Cheers,
Daniel.

[Daniel James]

In article news:<OP******* *******@TK2MSFT NGP04.phx.gbl>, Larry Smith wrote:

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.

I think the answer to that is "it looked too hard at the time" ... and IIRC
that constraint is to be removed an some future version of the standard.

I certainly agree that the ability to use a local class as an argument
would make the use of for_each much more natural.

C# allows me to use anonymous methods which is so
much cleaner

You can achieve the same sort of effect with boost::lambda

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.

I think it's /only/ the very experienced developers (and those who aren't
but think they are -- which is more worrying) who "continuous ly bend their
minds out of shape" looking for new ways to use the expressive power of the
language. These are the library builders, the Boost developers, the
Alexandrescus of the world ... most C++ programmers just /use/ their work
and are grateful for the way that it makes their lives easier and more
pleasant.

Cheers,
Daniel.