Re: how does C# compare to C++ and VB

[Peter Duniho]

On Fri, 18 Jul 2008 07:03:37 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

[...]

>Seriously though, I think you're overthinking things. C#, C++, and
VB all have substantially the same kinds of features. They are more
like each other (especially C++ and C#) than they are like most other
languages. Each language has some specific differences, and some

C# is far closer to Java and VB.NET than it is to C++.

I agree whole-heartedly about being closer to Java. But the OP didn't ask
about Java. :)

I disagree on the VB/VB.NET point, but I guess that's a matter of opinion
so not entirely unexpected. In spite of some fundamental conceptual
differences between C++ and C#, I find moving back and forth between those
languages much easier than moving back and forth between C# and VB.NET and
so to me they are more similar to each other than C# is to VB.NET (and
this is especially true if only limiting the comparison to C++/CLI rather
than C++ more generally).

C++ has
substantially the same OOP features as C#, but templates can do a not of
things generics can't,

And generics can do things templates can't. They are similar, but not
equivalent.

other features are more powerful as well, and as a
result C++ supports modern non-OOP programming styles (TMP for example).

IMHO it's inflammatory to describe one language as "more powerful" as
compared to another, and in most cases (including this one) decidedly
inaccurate.

Of course, if by "other features are more powerful" you did not mean to
imply that C# does not also have "more powerful" features, then my concern
is misplaced. But that's not how I read your statement.

Pete

[Ben Voigt [C++ MVP]]

Peter Duniho wrote:

On Fri, 18 Jul 2008 07:03:37 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

>[...]

>>Seriously though, I think you're overthinking things. C#, C++, and
VB all have substantially the same kinds of features. They are more
like each other (especially C++ and C#) than they are like most
other languages. Each language has some specific differences, and
some

C# is far closer to Java and VB.NET than it is to C++.

I agree whole-heartedly about being closer to Java. But the OP
didn't ask about Java. :)

I disagree on the VB/VB.NET point, but I guess that's a matter of
opinion so not entirely unexpected. In spite of some fundamental

They don't "look" alike, but the actual feature matrices for VB.NET and C#
are almost identical. VB has exception filters that C# doesn't. I suspect
we'd be hard-pressed to list more than 6 more differences.

conceptual differences between C++ and C#, I find moving back and
forth between those languages much easier than moving back and forth
between C# and VB.NET and so to me they are more similar to each
other than C# is to VB.NET (and this is especially true if only
limiting the comparison to C++/CLI rather than C++ more generally).

>C++ has
substantially the same OOP features as C#, but templates can do a
not of things generics can't,

And generics can do things templates can't. They are similar, but not
equivalent.

Generics can do things that the Microsoft C++ compiler can't do with
templates, because Microsoft C++ doesn't support the C++ standard
(specifically export). Since I'm aware of only one C++ compiler that does
implement export, your statement is correct for all practical purposes.

However, the Microsoft C++ compiler does support generics.

>

>other features are more powerful as well, and as a
result C++ supports modern non-OOP programming styles (TMP for
example).

IMHO it's inflammatory to describe one language as "more powerful" as
compared to another, and in most cases (including this one) decidedly
inaccurate.

Would you disagree that C++ is more powerful than C? It's practically a
100% superset. The same is true of C++ vs C#, although they're a lot closer
in capability. Actually one of the big points in favor of C# is that it's
controlled by a single company, so new features reach developers a lot more
often, in many cases earlier. C++03 beats C# 1.x which was available at the
same time. And C++0x will be a near superset of whatever version of C# is
out at the same time, probably 4.x

>
Of course, if by "other features are more powerful" you did not mean
to imply that C# does not also have "more powerful" features, then my
concern is misplaced. But that's not how I read your statement.

C# has some of these powerful features that don't have a direct equivalent
in C++. There's some very nice syntactic sugar, like anonymous methods
(although closures are coming soon to C++ as well). But none of them
respresent a truely different paradigm, such as TMP is, so ultimately most
of the reasons to choose C# over C++ (such as garbage collection, runtime
code generation, etc) come from either lack of features (making the language
easier to learn) or the CLR, which isn't a feature of any particular .NET
language. These can be accomplished in C++ by using an appropriate library
and runtime, one of which, thanks to the /clr option, is .NET itself.

>
Pete

[Jon Skeet [C# MVP]]

Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:

I disagree on the VB/VB.NET point, but I guess that's a matter of
opinion so not entirely unexpected. In spite of some fundamental

They don't "look" alike, but the actual feature matrices for VB.NET and C#
are almost identical. VB has exception filters that C# doesn't. I suspect
we'd be hard-pressed to list more than 6 more differences.

I'm game to see if we can manage it between us. No cheating and looking
it up though. If anyone fancies verifying my guesses, however, that's a
different matter :)

VB 9 has XML literals; C# doesn't.

C# 3 has lambda expressions with block bodies (i.e. multiple
statements); VB 9 only allows lambdas of a single expression, IIRC.

VB 9 allows mutable anonymous types; they're always immutable in C#.

VB allows late binding; C# doesn't (yet).

C# has pointers and allows unsafe code. I'm not sure whether VB has
this yet.

C# has iterator blocks; I don't believe VB does.

That's 6 - can anyone add to it to go to *more* than 6?

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

[Peter Duniho]

On Fri, 18 Jul 2008 12:34:14 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:

[...]
That's 6 - can anyone add to it to go to *more* than 6?

Sure, I think there's at least a couple of obvious ones:

-- VB has a concept of a "default instance". That is, if you refer to
a type by name rather than an explicitly allocated instance, VB creates
the instance for you. I don't know VB well enough to know if that's a
language feature or something special to the Form class, but it's
certainly something that happens in VB but not in C#.

-- The "With" statement.

-- VB's support for declaring an event handler that specifies what
event it's actually handling (in C# you have to subscribe the event
explicitly).

Oops, sorry. That's three.

I suspect an expert in both languages could come up with a great deal many
more than that.

That said, I don't really disagree with the overall idea that VB.NET and
C# share a great number of features. That's not surprising given that
they are specifically designed to target the same run-time and framework.

What does surprise me is that Ben can on the one hand argue that VB.NET
and C# are closer to each other than C# is to C++, and yet on the other
hand argue that C++ is essentially a "superset" of C#. At best, C++ can
only be thought of as a superset of C++ if one looks only at the Microsoft
C++/CLI implementation of C++ (reasoning that I find a bit disingenuous),
but even if one does, the implication of that assumption is that C++ is
just as similar to VB.NET as C# is.

But as I've said before, personally I find all three languages
functionally to be basically equivalent. This entire discussion is
starting to smack of "my langauge is better than yours" and I think that's
a silly discussion to have. Religious arguments of that nature don't
interest me much.

Pete

[Ben Voigt [C++ MVP]]

Peter Duniho wrote:

On Fri, 18 Jul 2008 12:34:14 -0700, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:

>[...]
That's 6 - can anyone add to it to go to *more* than 6?

Sure, I think there's at least a couple of obvious ones:

-- VB has a concept of a "default instance". That is, if you
refer to a type by name rather than an explicitly allocated instance,
VB creates the instance for you. I don't know VB well enough to know
if that's a language feature or something special to the Form class,
but it's certainly something that happens in VB but not in C#.

-- The "With" statement.

-- VB's support for declaring an event handler that specifies what
event it's actually handling (in C# you have to subscribe the event
explicitly).

Oops, sorry. That's three.

These seem to me to be more syntactic than anything, unlike the ones Jon
came up with, which for the most part cannot be duplicated in the other
language at all.

[snip]

>
What does surprise me is that Ben can on the one hand argue that
VB.NET and C# are closer to each other than C# is to C++, and yet on
the other hand argue that C++ is essentially a "superset" of C#. At
best, C++ can only be thought of as a superset of C++ if one looks
only at the Microsoft C++/CLI implementation of C++ (reasoning that I
find a bit disingenuous), but even if one does, the implication of
that assumption is that C++ is just as similar to VB.NET as C# is.

Let's use "natural numbers", "cardinal numbers", and "real numbers". Would
you dispute that "natural numbers" are most similar to "cardinal numbers",
but "real numbers" are a superset of both?

Similarly, C++ is an almost 100% superset of C89, yet C89 and C99 are far
closer to each other in every respect than to C++.

>
But as I've said before, personally I find all three languages
functionally to be basically equivalent. This entire discussion is
starting to smack of "my langauge is better than yours" and I think
that's a silly discussion to have. Religious arguments of that
nature don't interest me much.

I'd suggest you read some of Stroustrup's papers to understand just how far
beyond simple OOP C++ can go. Yes, if you restrict yourself to thinking of
the approach you'd take with C#, then all three are basically equivalent.
But C++ enables other approaches entirely that C# and VB have no way to
represent.

>
Pete

[Peter Duniho]

On Fri, 18 Jul 2008 14:24:38 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

[...]

>Oops, sorry. That's three.

These seem to me to be more syntactic than anything, unlike the ones Jon
came up with, which for the most part cannot be duplicated in the other
language at all.

On "With" I see your point (though I'm not sure why it's relevant...it's
still a real difference between the languages). On the other two, I don't
see those as any more "simply syntactic" than for example VB's lack of
multi-statement lamba's (which are at least partially duplicated simply by
putting the code in a separate method, just as anonymous methods
themselves don't do anything you couldn't write explicitly if you wanted
to), or iterator blocks (again, it's just "compiler magic"...you could
implement the same functionality more explicitly in VB.NET if you like,
just without any help from the compiler).

Let's use "natural numbers", "cardinal numbers", and "real numbers".
Would
you dispute that "natural numbers" are most similar to "cardinal
numbers",
but "real numbers" are a superset of both?

Forgive me if I fail to see the point of the analogy. The "superset" and
"subset" relationship mathematics between the kinds of numbers you
describe is well-defined. Not so with computer languages, nor the idea of
"similar".

The problem here is (I believe) is a fundamental difference in the way we
perceive the concepts of "similar".

[...]
I'd suggest you read some of Stroustrup's papers to understand just how
far
beyond simple OOP C++ can go. Yes, if you restrict yourself to thinking
of
the approach you'd take with C#, then all three are basically equivalent.
But C++ enables other approaches entirely that C# and VB have no way to
represent.

Why not provide an example? I'm not going to go off picking to read
random writings by the designer of C++ in the hopes of figuring out what
you mean. If you think there's such a clear difference, it should not be
difficult to present a practical example clearly demonstrating how C++ is
"more powerful" in a way that C# cannot be.

Personally, the thing I find "most powerful" about C# is its integration
with .NET. Yes, you can write .NET code in C++. But it's clumsy, and
frankly I don't feel that features in C++ that aren't available in C#
justify dealing with the clumsiness. The relative frequency with which
the opposing issues come up is heavily weighted in favor of C#, at least
in my own experience.

Others may have different experiences and thus different conclusions. But
I don't think that justifies a claim of one language being "more powerful"
than others. Indeed, that sort of claim just leads to pointless, endless
debates about "my language is better than yours", which as I've mentioned
I find completely valueless.

Pete

[Ben Voigt [C++ MVP]]

Peter Duniho wrote:

On Fri, 18 Jul 2008 14:24:38 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

>[...]

>>Oops, sorry. That's three.

These seem to me to be more syntactic than anything, unlike the ones
Jon came up with, which for the most part cannot be duplicated in
the other language at all.

On "With" I see your point (though I'm not sure why it's
relevant...it's still a real difference between the languages). On
the other two, I don't see those as any more "simply syntactic" than
for example VB's lack of multi-statement lamba's (which are at least
partially duplicated simply by putting the code in a separate method,
just as anonymous methods themselves don't do anything you couldn't
write explicitly if you wanted to), or iterator blocks (again, it's

Ahh, but lambda's can be traversed as a parse tree instead of turned into a
delegate. The workaround of putting the code in a separate method doesn't
support that.

just "compiler magic"...you could implement the same functionality
more explicitly in VB.NET if you like, just without any help from the
compiler).

>Let's use "natural numbers", "cardinal numbers", and "real numbers".
Would
you dispute that "natural numbers" are most similar to "cardinal
numbers",
but "real numbers" are a superset of both?

Forgive me if I fail to see the point of the analogy. The "superset"
and "subset" relationship mathematics between the kinds of numbers you
describe is well-defined. Not so with computer languages, nor the
idea of "similar".

So you snipped the (self-evident) example using computer languages. In any
case, "superset" does not imply "similar".

>
The problem here is (I believe) is a fundamental difference in the
way we perceive the concepts of "similar".

>[...]
I'd suggest you read some of Stroustrup's papers to understand just
how far
beyond simple OOP C++ can go. Yes, if you restrict yourself to
thinking of
the approach you'd take with C#, then all three are basically
equivalent. But C++ enables other approaches entirely that C# and VB
have no way to represent.

Why not provide an example? I'm not going to go off picking to read
random writings by the designer of C++ in the hopes of figuring out
what you mean. If you think there's such a clear difference, it
should not be difficult to present a practical example clearly
demonstrating how C++ is "more powerful" in a way that C# cannot be.

Well, there are quite a few examples here:
http://www.codeproject.com/KB/cpp/crc_meta.aspx

But a simple one you should be very familiar with is
EqualityComparer::Default

Just you try to make a Dictionary in .NET that supports *any* Key class or
struct without a virtual call to test equality. I suspect that the .NET JIT
is coded to specifically recognize Dictionary or at least
EqualityComparer::Default and perform a spot optimization, because doing the
virtual call would kill performance. C++ templates easily implement the
different comparison cases at compile-time with no runtime overhead, using
type traits and partial specialization.

Or try making a cache that uses a different data structure for small objects
vs big ones, without the consumer having to select the right one.

Multiple inheritance isn't all that useful -- unless you combine it with
CRTP for composition of multiple behaviors. Let's say I had a word
processing control, and a derived class that implements stylus entry
(handwriting recognition). And another derived class that provides skinning
(i.e. select a color scheme). And another one that automatically backed up
the users' data periodically in case of power loss while the app is open.
And another that implements text-to-speech. In C#, is there any way to get
more than one of these behaviors at the same time without reimplementing the
functionality? Not without modifying one of the components to inherit from
a different one. In C++, if you implement CRTP composition or even template
parameter inheritance support then you can build any combination without any
of the variants having prior knowledge of any of the others.

[Jon Skeet [C# MVP]]

Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:

On "With" I see your point (though I'm not sure why it's
relevant...it's still a real difference between the languages). On
the other two, I don't see those as any more "simply syntactic" than
for example VB's lack of multi-statement lamba's (which are at least
partially duplicated simply by putting the code in a separate method,
just as anonymous methods themselves don't do anything you couldn't
write explicitly if you wanted to), or iterator blocks (again, it's

Ahh, but lambda's can be traversed as a parse tree instead of turned into a
delegate. The workaround of putting the code in a separate method doesn't
support that.

On the other hand, lambdas with multiple statements can't be turned
into a parse tree by the C# compiler either:

Expression<Actionf = () ={ int i=0; i++; }

gives:

error CS0834: A lambda expression with a statement body cannot be
converted to an expression tree

Just a minor point, and mostly irrelevant to the discussion on C++
though.

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

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Fri, 18 Jul 2008 07:03:37 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

>C# is far closer to Java and VB.NET than it is to C++.

I agree whole-heartedly about being closer to Java. But the OP didn't
ask about Java. :)

I disagree on the VB/VB.NET point, but I guess that's a matter of
opinion so not entirely unexpected. In spite of some fundamental
conceptual differences between C++ and C#, I find moving back and forth
between those languages much easier than moving back and forth between
C# and VB.NET and so to me they are more similar to each other than C#
is to VB.NET (and this is especially true if only limiting the
comparison to C++/CLI rather than C++ more generally).

C#<->VB.NET converters are much better than C#<->C++ converters.

Which I see as a reasonable indication of how close the languages
are.

Arne

[Peter Duniho]

On Fri, 18 Jul 2008 16:04:06 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

Ahh, but lambda's can be traversed as a parse tree instead of turned
into a
delegate. The workaround of putting the code in a separate method
doesn't
support that.

The use of lambda's as expressions is why I wrote "partially duplicated".
That said, you could in fact construct the parse tree explicitly. The
lambda expression is not _mandatory_. In that sense, "it's just syntax".

[...]

>Forgive me if I fail to see the point of the analogy. The "superset"
and "subset" relationship mathematics between the kinds of numbers you
describe is well-defined. Not so with computer languages, nor the
idea of "similar".

So you snipped the (self-evident) example using computer languages. In
any
case, "superset" does not imply "similar".

I never said it does. As far as your example being "self-evident", that's
in the eye of the beholder. Suffice to say, I disagree with your claim of
"self-evident", and that is in fact the crux of the point here.

[...]
Just you try to make a Dictionary in .NET that supports *any* Key class
or
struct without a virtual call to test equality. I suspect that the .NET
JIT
is coded to specifically recognize Dictionary or at least
EqualityComparer::Default and perform a spot optimization, because doing
the
virtual call would kill performance. C++ templates easily implement the
different comparison cases at compile-time with no runtime overhead,
using
type traits and partial specialization.

You seem to be making the assumption that this difference represents "more
power". I simply disagree. And again, this is because you are trying to
argue a point ("a language is more powerful than another") before we have
decided to agree on the definition of "more powerful". You have a priori
defined "more powerful" in a way that supports your claim, so of course
your claims seem self-evident to you. But they fail to convince someone
who doesn't agree on the definition.

The other issue is that I've never said that C++ doesn't have features
that C# has. That's not the point. I readily admit the languages are
different. The question is whether C++ has ALL the features C# has. As
far as I know, it doesn't. Certainly the C++ I'm familiar with doesn't.

All that said, your religious view of C++ as _the_ superior language is
intractable, and it's this sort of religious view that I find pointless to
try to debate. Tautological arguments are the norm, openness to
compromise is absent, and I detest such discussions. So I won't bother
you further on the point.

Pete

[Peter Duniho]

On Fri, 18 Jul 2008 17:15:15 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

C#<->VB.NET converters are much better than C#<->C++ converters.

"much better" == subjective, unquantified opinion.

Which I see as a reasonable indication of how close the languages
are.

You may. But it could be more an indication of how the languages are used
than anything else.

In any case, I'm not insisting that anyone else take the same view. My
own personal experience is irrefutable as it pertains to my own
perceptions, and that is that I find it easier for _me_ to translate
between C++ and C# than to translate between either of those and VB.NET.

YMMV, and I don't care. It doesn't have anything to do with _my_
impressions, which was all I was sharing.

Pete

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Fri, 18 Jul 2008 17:15:15 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

>C#<->VB.NET converters are much better than C#<->C++ converters.

"much better" == subjective, unquantified opinion.

Should be obvious to anyone with experience in the languages.

But let us find the last complete program you posted in this
group 100 lines. I will find a converter that convert it to
VB.NET - you will find a converter that converts it to C++
(not C++/CLI), we post the two here and then people can compare.

OK ?

In any case, I'm not insisting that anyone else take the same view. My
own personal experience is irrefutable as it pertains to my own
perceptions, and that is that I find it easier for _me_ to translate
between C++ and C# than to translate between either of those and VB.NET.

YMMV, and I don't care. It doesn't have anything to do with _my_
impressions, which was all I was sharing.

Who on earth would convert manually between C# and VB.NET at all ?

Translations are very good. Usually you convert and it either just
works or you have to make a few trivial changes.

Arne

[Peter Duniho]

On Fri, 18 Jul 2008 17:30:23 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

Peter Duniho wrote:

>On Fri, 18 Jul 2008 17:15:15 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

>>C#<->VB.NET converters are much better than C#<->C++ converters.

"much better" == subjective, unquantified opinion.

Should be obvious to anyone with experience in the languages.

Ah, yes...like Ben's "self-evident" comment. Suffice to say, I don't find
that sort of expression a valid debating style. "Should be obvious",
"self-evident", etc. are just crutches for people who don't feel like
proving their point.

But let us find the last complete program you posted in this
group 100 lines. I will find a converter that convert it to
VB.NET - you will find a converter that converts it to C++
(not C++/CLI), we post the two here and then people can compare.

OK ?

What would make you think that a single data point in any way represents a
valid study?

Who on earth would convert manually between C# and VB.NET at all ?

I find myself doing it somewhat regularly, when dealing with different
code examples different people post. The context isn't about getting a
program to work; it's about understanding what someone else has written.

In spite of the fact that the most common scenario is seeing VB.NET code,
I still find it easier to deal with C++ code.

I'm not sure what it is about "my own personal experience" that you are
having trouble comprehending, but that's the bottom line here. None of
your comments regarding machine translation are relevant at all with
respect to my observations about the different languages.

Pete

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Fri, 18 Jul 2008 17:30:23 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

>Peter Duniho wrote:

>>On Fri, 18 Jul 2008 17:15:15 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
C#<->VB.NET converters are much better than C#<->C++ converters.
"much better" == subjective, unquantified opinion.

Should be obvious to anyone with experience in the languages.

Ah, yes...like Ben's "self-evident" comment. Suffice to say, I don't
find that sort of expression a valid debating style. "Should be
obvious", "self-evident", etc. are just crutches for people who don't
feel like proving their point.

Well - I actually offered a demonstration below. Which makes your
comment above look rather stupid.

>But let us find the last complete program you posted in this
group 100 lines. I will find a converter that convert it to
VB.NET - you will find a converter that converts it to C++
(not C++/CLI), we post the two here and then people can compare.

OK ?

What would make you think that a single data point in any way represents
a valid study?

Last 10 so ?

>Who on earth would convert manually between C# and VB.NET at all ?

I find myself doing it somewhat regularly, when dealing with different
code examples different people post. The context isn't about getting a
program to work; it's about understanding what someone else has written.

It is quite common to want to do something manually to learn from it,
but it is rather irrelevant in a discussion of whether it is easy to
do automatically.

Arne

[Peter Duniho]

On Fri, 18 Jul 2008 17:47:06 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

Well - I actually offered a demonstration below. Which makes your
comment above look rather stupid.

I don't doubt that you believe that.

[...]
It is quite common to want to do something manually to learn from it,
but it is rather irrelevant in a discussion of whether it is easy to
do automatically.

The only person having that discussion is you. I am participating in a
different discussion that is about my own perceptions regarding the
specific similarities between the languages.

You are free to carry on your own conversation with yourself if you like.
But don't expect me to agree that it's relevant.

Pete

[Pavel Minaev]

On Jul 19, 3:04*am, "Ben Voigt [C++ MVP]" <[e-mail]:

But a simple one you should be very familiar with is
EqualityComparer::Default

Just you try to make a Dictionary in .NET that supports *any* Key class or
struct without a virtual call to test equality.

If you mean doing so while keeping the existing interface of
Dictionary, then it's possible, though tricky - once you get the
comparer, you create dynamic methods for all the search operations
that directly invoke the most derived implementation of
IComparer<T>.Compare on the actual comparer instance. In effect, you
still have dynamic dispatch, but it's moved outside the loop where it
kills performance.

In fact, I wouldn't be surprised if JIT was able to lift virtual
method resolution outside the loop on its own, without any dirty Emit
tricks.

On the other hand, if you mean writing my own class with interface
different from that of Dictionary, that's quite doable, too, and will
actually look very similar to std::map:

class Map<TKey, TValue, TComparer>
where TComparer : IComparer, new()
{
readonly TComparer comparer = new TComparer(); // calls to Compare()
on this won't be virtual, and will likely be inlined
}

This is particularly efficient if you then pass an empty struct,
rather than class, as TComparer.

[Ben Voigt [C++ MVP]]

>>Forgive me if I fail to see the point of the analogy. The

>>"superset" and "subset" relationship mathematics between the kinds
of numbers you describe is well-defined. Not so with computer
languages, nor the idea of "similar".

So you snipped the (self-evident) example using computer languages. In
any
case, "superset" does not imply "similar".

I never said it does. As far as your example being "self-evident",
that's in the eye of the beholder. Suffice to say, I disagree with
your claim of "self-evident", and that is in fact the crux of the
point here.

Before we forget, here was the example:

"C++ is an almost 100% superset of C89, yet C89 and C99 are far closer to
each other in every respect than to C++."

Do you want to contest that?

>

>[...]
Just you try to make a Dictionary in .NET that supports *any* Key
class or
struct without a virtual call to test equality. I suspect that the
.NET JIT
is coded to specifically recognize Dictionary or at least
EqualityComparer::Default and perform a spot optimization, because
doing the
virtual call would kill performance. C++ templates easily
implement the different comparison cases at compile-time with no
runtime overhead, using
type traits and partial specialization.

You seem to be making the assumption that this difference represents
"more power". I simply disagree. And again, this is because you are
trying to argue a point ("a language is more powerful than another")
before we have decided to agree on the definition of "more powerful".
You have a priori defined "more powerful" in a way that supports your
claim, so of course your claims seem self-evident to you. But they
fail to convince someone who doesn't agree on the definition.

The other issue is that I've never said that C++ doesn't have features
that C# has. That's not the point. I readily admit the languages are
different. The question is whether C++ has ALL the features C# has. As
far as I know, it doesn't. Certainly the C++ I'm familiar with
doesn't.
All that said, your religious view of C++ as _the_ superior language
is intractable, and it's this sort of religious view that I find
pointless to try to debate. Tautological arguments are the norm,
openness to compromise is absent, and I detest such discussions. So
I won't bother you further on the point.

I didn't say "superior". Simplicity and barriers to making mistakes are
advantageous in their own right. I said "almost superset" and "more
powerful" and I stand behind that claim.

>
Pete

[Peter Duniho]

On Mon, 21 Jul 2008 10:49:52 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

Before we forget, here was the example:

"C++ is an almost 100% superset of C89, yet C89 and C99 are far closer to
each other in every respect than to C++."

Do you want to contest that?

I'm not sure what you mean. I do contest that it's an example relevant to
what C# is similar to.

But if all you meant by "self-evident" that the example is, as a
self-contained statement having no implication anywhere else in this
thread, "self-evident", no...I wouldn't have any reason to contest that.

[...]
I didn't say "superior". Simplicity and barriers to making mistakes are
advantageous in their own right. I said "almost superset" and "more
powerful" and I stand behind that claim.

Well, I find "superior" and "more powerful" practically synonymous. But
more problematic is that you haven't defined "powerful" in a way that
allows for any factual statement to be used using the term. And in
particular, you seem to be using the term differently than I would.

As a tautological assertion, perhaps your claim has basis. But then, any
tautological assertion would. :)

Pete

[Ben Voigt [C++ MVP]]

Pavel Minaev wrote:

On Jul 19, 3:04 am, "Ben Voigt [C++ MVP]" <[e-mail]:

>But a simple one you should be very familiar with is
EqualityComparer::Default

Just you try to make a Dictionary in .NET that supports *any* Key
class or struct without a virtual call to test equality.

If you mean doing so while keeping the existing interface of
Dictionary, then it's possible, though tricky - once you get the
comparer, you create dynamic methods for all the search operations
that directly invoke the most derived implementation of
IComparer<T>.Compare on the actual comparer instance. In effect, you
still have dynamic dispatch, but it's moved outside the loop where it
kills performance.

Congratulations, you can do it by *re-implementing the C++ rules for
templates*. Pretty cool that .NET gives you the dynamic codegen to let you
do it, but still waaaay more difficult than using C++ to do it.

>
In fact, I wouldn't be surprised if JIT was able to lift virtual
method resolution outside the loop on its own, without any dirty Emit
tricks.

On the other hand, if you mean writing my own class with interface
different from that of Dictionary, that's quite doable, too, and will
actually look very similar to std::map:

class Map<TKey, TValue, TComparer>
where TComparer : IComparer, new()
{
readonly TComparer comparer = new TComparer(); // calls to Compare()
on this won't be virtual, and will likely be inlined
}

This is particularly efficient if you then pass an empty struct,
rather than class, as TComparer.

They will be virtual unless TComparer is a struct. Which, unfortunately,
EqualityComparer<Tisn't, and EqualityComparer<T>.Default isn't.

But honestly, you've done a great job of working within the confines of .NET
and making the JIT work for you.

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Fri, 18 Jul 2008 17:47:06 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

>It is quite common to want to do something manually to learn from it,
but it is rather irrelevant in a discussion of whether it is easy to
do automatically.

The only person having that discussion is you.

Actually it was you that wrote:

#What would make you think that a single data point in any way
#represents a valid study?

in response to me talking about automatic conversions.

So yes - you were actually also participating in that discussion.

Arne

[Daniel]

(although closures are coming soon to C++ as well). But none of them
respresent a truely different paradigm, such as TMP is, so ultimately most

What does TMP stand for?

Daniel

[Ben Voigt [C++ MVP]]

Daniel wrote:

>(although closures are coming soon to C++ as well). But none of them
respresent a truely different paradigm, such as TMP is, so
ultimately most

What does TMP stand for?

Template Meta-Programming

>
Daniel