C# vs. C++

[Daniel James]

Re: C# vs. C++

In article news:<4861b785$ 0$90275$1472629 8@news.sunsite. dk>, Arne
Vajhøj wrote:

Good OOP is about limiting choices.

No it isn't. It's about a certain kind of encapsulation.

Using OOP is itself a design choice -- a good one in some cases and a
poor one in others.

You encourage or force developers to do things the right way.

Encouragement and forcing are very different games. In solutions that
lend themselves well to OOP the benefits to be gained from OOP are
encouragement enough -- no need for the language to force the issue.

If your solution is not one that naturally lends itself to an OO
approach then forcing people to use a language that steers them
singlemindedly along an OOP path will only engender resentment and bad
programming.

Multiple inheritance has a rather bad track record.

It's certainly easy to use MI badly -- especially in C++, which doesn't
believe in restricting choices unnecessarily -- but that doesn't mean
that isn't a useful technique, or that it can't be used productively
and well.

Cheers,
Daniel.

[Daniel James]

Re: C# vs. C++

In article news:<VA.000014 44.4776d7db@nos pam.aaisp.org>, Daniel James
wrote:

Ericsson's telephone exchange software is written in
Haskell, for example.

I meant Erlang, not Haskell, or course -- nice to see nobody here is
sufficiently on the ball to spot my blunder!

Cheers,
Daniel.

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

Re: C# vs. C++

Arne Vajhøj wrote:

David Wilkinson wrote:

>C++/CLI as a first class .NET language does indeed appear doomed.
>Maybe using C++ for .NET was a bad concept from the beginning, or
>maybe it was done in by the flawed initial version of MC++. But,
>anyway, it seems dead.
>>
>C++/CLI is great for inter-op, but that is a limited market compared
>to all the things that C# can do in .NET.
>>
>But native C++ lives on, both as a cross platform language, and in
>many MFC/Win32 applications that are never going to switch to .NET.
>The Visual C++ team is strongly committed to improve the native coding
>experience in the next version of Visual Studio, after many years of
>neglect.

>
I tend to agree.
>
People that want to write managed code chose C# instead of C++/CLI. It
is simply easier.
>
C++ will most certainly live on for many years.
>
I am a bit skeptical about MFC though. I think MFC will be
squeezed hard by .NET in the next 10 years. As the UI's need
to get a major rewrite then the apps will switch to .NET !
>
Arne

The new version of MFC is just great! With the Ribbon, docking windows,
new common controls, MSN menus, and a bunch of other things... I wonder
why Microsoft is investing in MFC, if it is doomed...

[Jon Skeet [C# MVP]]

Re: C# vs. C++

Daniel James <wastebasket@no spam.aaisp.orgw rote:

It's one of .NET's
significant advantages over Java (intermediate code engine targeted by more
than one source language) but that's about it.

<snip>

Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:

Java (obviously)
Groovy
Scala
JRuby
Jython

That's without even bothering to think. Fortunately Wikipedia allows us
to continue not thinking and expand the list significantly:

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

I don't think even that list is exhaustive by a long chalk though.

(Personally I'd say there are plenty of other things that C# has over
the Java language and that .NET has over the JVM/JRE; Java's
portability is its main benefit over .NET in my experience.)

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

[=?ISO-8859-1?Q?Fernando_G=F3mez?=]

Re: C# vs. C++

Daniel James wrote:

I'm also disappointed that modules won't be in C++0x, but I hope we won't
have to wait too much longer for them.
>

If I might interrupt for a moment, I think that the *only* true
advantage of using C# rather than C++ is that C# has a big standardized
framework so that programmers have a common high-level layer, so that
they don't have to directly deal with the OS.

C++ should be moving onto something similar, IMHO. As the C++0x is doing
with threads, regex, etc.

I know it's something really difficult, but that's a wish of mine.

Regards.

[Hendrik Schober]

Re: C# vs. C++

Arne Vajhøj <arne@vajhoej.d kwrote:

Daniel James wrote:
[...]

>10 first class programmers will do more useful work in less time than
>50 mediocre programmers ... and you will get fewer bugs.
>>
>In a world with concerns such as money you can't afford the mediocre.

>
If you look out in the real world, then you will see that
is not the general opinion.

I see this when using just about every application.
And I hate it.

Arne

Schobi

--
SpamTrap@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

[Andre Kaufmann]

Re: C# vs. C++

Jon Skeet [C# MVP] wrote:

Daniel James <wastebasket@no spam.aaisp.orgw rote:
>

>It's one of .NET's
>significant advantages over Java (intermediate code engine targeted by more
>than one source language) but that's about it.

>
<snip>
>
Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:

The point is that JVM has been officially been restricted to a single
language and wasn't meant to be open for other languages - don't know
it's current state in this regard.

And it's not only the runtime that makes the difference. Can you write
code in Java and use it easily from any other language targeting the JVM ?

[...]

Andre

[Jon Skeet [C# MVP]]

Re: C# vs. C++

On Jun 26, 6:07 am, Andre Kaufmann <andre.kaufmann _re_mo...@t-
online.dewrote:

Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:

>
The point is that JVM has been officially been restricted to a single
language and wasn't meant to be open for other languages - don't know
it's current state in this regard.

I don't think it's ever been "restricted " - I don't remember Sun ever
telling people off for developing any of these languages, for
instance. Sun now employs the JRuby folk IIRC, and gave their blessing
to Groovy too.

Heck, there's even an API (in Java 6 IIRC, but it *might* only be in
Java 7) specifically for scripting, to make binding etc consistent
between different scripting languages targeting the JVM.

And it's not only the runtime that makes the difference. Can you write
code in Java and use it easily from any other language targeting the JVM  ?

Absolutely - and the reverse, in many cases. For instance, you can
easily call Groovy code from Java, should you wish to.

I can't imagine anyone designing a language to run on the JVM which
*wouldn't* take advantage of both the standard APIs and the wealth of
3rd party libraries available - and that will include any extra Java
code you write yourself.

Jon

[Daniel James]

Re: C# vs. C++

In article news:<MPG.22cca 2e1aa56468bdb5@ msnews.microsof t.com>, Jon
Skeet [C# MVP] wrote:

It's one of .NET's significant advantages over Java (intermediate
code engine targeted by more than one source language) but that's
about it.

>
<snip>
>
Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:

Did you notice that the very next paragraph of the bit you snipped said:

... and there are compilers for languages other than Java that
target the JVM, though I understand that the design of the JVM
specifically makes it hard to taget it with C or C++.

So, yes, of course, I agree with you. The point I was making in the bit
you didn't snip is that Java is a single-language environment BY DESIGN.
The Java zealots at Sun would have you believe that you don't need any
language other than Java and that Java is all the languages that you
will ever need ... at least, that was their mantra last time I passed by
the temple.

All the same, most of the languages you list -- and those in the
Wikipedia article you cited -- are experimental "academic" languages,
which aren't likely to be anyone's first choice for commercial
application. Groovy is obviously different, as it's designed to work
alongside Java -- I've not used Groovy but I understand that the synergy
there is good. The same is true to some extent of Jython, in that I
don't think anyone would choose Jython (over Python) unless their
project also used Java.

AspectJ is interesting, but AIUI that's an extension of Java rather than
a different language.

OTOH A remember being very impressed with the AppletMagic Ada for JVM
when I first looked at it -- too long ago now -- but I'm not sure it's
still around. Ada is a real language (one that really deserves to be
better known outside the war-toys factories) and it's interesting that
you can run it well on the JVM.

(Personally I'd say there are plenty of other things that C# has over
the Java language and that .NET has over the JVM/JRE; Java's
portability is its main benefit over .NET in my experience.)

I agree. The .NET team had the benefit of seeing the JVM in action and
of learning from its shortcomings. Their runtime is better in many ways
... but Java has the market penetration and I doubt very much that .NET
will ever displace it completely, even on Windows.

Cheers,
Daniel.

[Daniel James]

Re: C# vs. C++

In article news:<#D7NAH11I HA.6096@TK2MSFT NGP06.phx.gbl>, Andre Kaufmann
wrote:

Singularity has a small amount of assembly code and it's using a
native C# compiler. Cosmos however is meant to be 100% C# code.

Interesting. I've read about Singularity but not about Cosmos (in fact,
I thought Cosmos must be another name for Singularity when you mentioned
the two together in your last post).

The question, then, is how? Presumably Cosmos must touch the metal
somehow ... or is it designed as a guest OS to be run within another,
native, OS?

The point is C++ is not (always) that fast, only if you are an
experienced (expert) C++ developer the resulting C++ application
will be much faster.

You can write bad code in any language, and C++ certainly requires a bit
of care.

Short example (I never thought C++ to be slower in writing to files):
The code is attached below and does nothing but simply writing 5000000
integers to a text file.

What are COMPILER X and COMPILER Y?

Hmm ... there has to be a reason that C# comes out looking so good ...

Do all the programs produce identical output? What, exactly, did you
time (e.g. do you close the files/streams in the timed section of the
code in each case)?

The fprintf and sprintf functions will always be slow as they have to
parse the formatting string each time as well as producing output, so I
wouldn't expect them to do well. I'd expect the iostreams version to be
a good bit quicker and the itoa version to be the fastest. If I had to
guess I'd say that the C# version would be comparable to iostreams.

You could try another benchmark with boost::format -- I bet that would
be slower than any of them.

Another point is C++ could compile (nearly) as fast as any other
language. But therefore C++ must either get rid of (global) macros, or
introduce modules.

Modules are coming, eventually.

It's not global macros that are the problem, it's the fact that there's
no mechanism for the compiler to know that any macros referenced (in
include files, especially) have the same values in all compilation
units/for all builds. If the build system were smarter it could track
that and avoid recompiling header information that had already been
compiled with the same settings.

Macros can be a pain, but they can also be very useful ... I always
advise people to avoid using them if there is an alternative (e.g. use
const int (or even an enum) rather than a #define) but sometimes there
is no alternative and their use is beneficial.

If you look at functional languages targeting .NET e.g. F# and see
what is possible in these language then delegates just look like a
simple toy

That's because they're functional languages, not because they target
NET -- take a look at Haskell or Erlang and see what they can do.

But why have they to be implemented in a library ? C++ could have
integrated delegates from the beginning and add some extensional stuff
into a library ...

They don't have to be implemented in a library, but as they're not in
the core language there's no other way to add them. You could submit a
proposal to the ISO C++ committee asking for delegates as a native
language feature, but I suspect they'd say -- after a couple of years
waiting -- that as delegate functionality can be added as a library,
without changing the core language, there's no point. C++ is already
quite a big language, and making it bigger still just to add a feature
that can be implemented in a library doesn't make good sense.

I don't want to state that boost::function is bad, it's well
written and an perfect extension, I only think a direct implementation
could perform better.

I wouldn't like to judge without seeing direct implementation and
benchmarking it ... but boost::function is pretty efficient, from what
I've seen.

the .NET runtime support system, and if they weren't there would
be no way to add them to C#.

>
I don't know for sure, since you can easily write a .NET compiler by
yourself using the .NET runtime compiler support. Also I've seen many
IL (the .NET assembly code) based extensions, which extend the
language or .NET framework. So I think it would be possible, ...

I think you're missing the point I was making. I wasn't saying that
there was no way you could add delegate support *to* C# if it didn't
have it, I was saying that there was no way you could add delegate
support *in* C# alone. I'm not even 100% sure that that's true, but I am
certain that the result would be a lot less neat than boost::function if
you did! The point I was making was that the C++ language was more
powerful than the C# language, not that you couldn't do stuff with IL
extensions ... you can extend C++ by writing in assembler if you want
to, but that doesn't say anything about the power of C++ as a language.

... but the big advantage is that, as the framework has implemented
delegates, you can use it in every language and pass the pointers
over dll boundaries without any hassle.

I'm sure that's true -- and it *is* an advantage of the environment, no
question ... but (again) it says nothing about the power of expression
of the C# language -- it says nothing about the ease with which *you*
can express complex concepts in *your* C# code.

The main problem about macros is that the C++ compiler has to use
them too. So if it compiles a unit with header file a, it can't use
the already preprocessed and compiled intermediate code of header in
another unit, because a simple macro could convert the whole code in
the preprocessing stage.

Yes, I understand that problem, and you're right. I do think smarter
tools could alleviate that problem to a considerable extent, though.

You can do a lot to improve compile times in Visual C++ with judicious
use of precompiled headers -- but it's tricky to get right if you need
to use more than one PCH file in a project ... and the tendency is to
use the brute force approach of putting everything into a single
monolithic PCH file and so introducing all sorts of unnecessary
dependencies. Again, it's something that better tools could do a lot to
improve.

Modules are probably the best answer, though.

[...]
Delegates and labmda have been added TO C++ IN C++ (in Boost) ...
which is something you couldn't do in C#.

>
Perhaps. But if you look at the library, how many code there's inside
to deal with the differences of different C++ compilers I think it
wasn't an easy task ;-).

That's true ... but if more compilers complies more closely with the
standard it wouldn't be such a problem.

Implicit typed variables are coming to C++ (auto) ... but the need
for them is mostly driven by templates -- what good are they in C#?

>
The same reason - >generics< and LINQ has also driven them.

OK, interesting. I should have thought about generics ... and I know
very little about how LINQ works (reinventing ODBC within the language
...???) An answer to xdoclet in Java.

There could be a Windows standard for all
Windows compilers to have the advantages for natives languages too.
Try to export a template code in C++ in a Windows DLL and use it from
another language - in .NET it's simply no problem.

I take the point that the CLI gives you a standard object representation
for all .NET languages, and lets you define an object in C# and
manipulate it in C++/CLI or VB.NET or whatever ... but you can't create
a template in a C++/CLI program and use it (instantiate it) in a C# or
VB.NET program -- because those languages have no conception of
templates.

The implementation of templates in C++/CLI is not provided by the CLI,
but by the C++ compiler. Templates are therefore not visible to other
NET languages.

That's no different from the situation with native code.

But the only standard there's in Windows, is how to export flat
functions. I wished at least the name mangling would be somewhat
standardized.

Yes, a standard ABI for C++ would be nice. I believe it's one of the
things the standards group is looking at, but don't expect to see it in
the standard in 2009.

[...]
D is interesting too ... can that not be used together with DM
C++? I must say I haven't tried ...

>
It somewhat supports using C++ (indirectly), but as the developer
said, if it would fully support C++ - it would be a full fledged
C++ compiler, which would be not that simple to >implement< ;-).

... but can you not compile D code with the D compiler and C++ code with
the DM C++ compiler and link the two together?

Incidentally, Andrei Alexandrescu presented a paper ...

[snip]

Hm, interesting thanks for mentioning it.

The slides are here:

http://accu.org/content/conf2008/Alexandrescu-accu-functional.pdf

I don't know how much sense they'll make to someone who wasn't at the
talk!

Cheers,
Daniel.

[Jon Skeet [C# MVP]]

Re: C# vs. C++

Daniel James <wastebasket@no spam.aaisp.orgw rote:

Um, there are *plenty* of languages targeting the JVM. Off the top of
my head:

>
Did you notice that the very next paragraph of the bit you snipped said:
>

... and there are compilers for languages other than Java that
target the JVM, though I understand that the design of the JVM
specifically makes it hard to taget it with C or C++.

I didn't, actually. Sorry about that - it does sort of make a nonsense
of the sentence that I *did* quote though.

And yes, I agree that it would be pretty hard to target the JVM with C
or C++.

So, yes, of course, I agree with you. The point I was making in the bit
you didn't snip is that Java is a single-language environment BY DESIGN.
The Java zealots at Sun would have you believe that you don't need any
language other than Java and that Java is all the languages that you
will ever need ... at least, that was their mantra last time I passed by
the temple.

I wouldn't put it as strongly as that. I think there's a big difference
between a platform being deliberately designed to only have one
language targeting it, and a platform being designed explicitly for a
single language with little thought to trying to make life easier for
other languages.

I would put Java into the latter camp rather than the former. Even if
some Java fans think there's no point in having other languages
targeting it, I'm not aware of any ways they've made it *deliberately*
more difficult for other languages in a DRM-like way.

All the same, most of the languages you list -- and those in the
Wikipedia article you cited -- are experimental "academic" languages,
which aren't likely to be anyone's first choice for commercial
application. Groovy is obviously different, as it's designed to work
alongside Java -- I've not used Groovy but I understand that the synergy
there is good. The same is true to some extent of Jython, in that I
don't think anyone would choose Jython (over Python) unless their
project also used Java.

But that's the point - if their project *does* use Python or Ruby
already, or if they've already got a lot of code in Java that they want
to use later with Python or Ruby - then Jython and JRuby are a natural
fit.

If we're talking about languages which are common "first choices" for
commercial applications, even .NET's relatively thin on the ground,
with VB.NET and C# taking the lion's share and C++/CLI and F# pulling
up the rear - at an educated guess. Languages like Boo aren't exactly
commonplace.

AspectJ is interesting, but AIUI that's an extension of Java rather than
a different language.
>
OTOH A remember being very impressed with the AppletMagic Ada for JVM
when I first looked at it -- too long ago now -- but I'm not sure it's
still around. Ada is a real language (one that really deserves to be
better known outside the war-toys factories) and it's interesting that
you can run it well on the JVM.

Right. I'm interested in Scala, as there used to be implementations for
both .NET and the JVM - and because it looks like a nice language. I
haven't had a close look though, and I believe the .NET port is out of
date.

(Personally I'd say there are plenty of other things that C# has over
the Java language and that .NET has over the JVM/JRE; Java's
portability is its main benefit over .NET in my experience.)

>
I agree. The .NET team had the benefit of seeing the JVM in action and
of learning from its shortcomings. Their runtime is better in many ways
.. but Java has the market penetration and I doubt very much that .NET
will ever displace it completely, even on Windows.

Absolutely - I expect both to go on for quite some time, which is fine
by me. (I'm currently working just in Java professionally, and I have
no wish to leave my current employer - but I do hope I write some C#
professionally again at some point.)

I haven't replied to your other posts about LINQ, by the way, but I
think you'd be wise to look into it further - it sounds like you may
have the wrong end of the stick to some extent. It's certainly not like
embedding SQL into C# - there's a lot more to it than that. Personally
I think that LINQ to Objects (the "in process" handling of collections)
is of more use to most people than LINQ to SQL etc, though obviously
the latter has more of an "ooh" and "aah" quality to it.

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

[Andre Kaufmann]

Re: C# vs. C++

Jon Skeet [C# MVP] wrote:

On Jun 26, 6:07 am, Andre Kaufmann <andre.kaufmann _re_mo...@t-
online.dewrote:
[...]
I don't think it's ever been "restricted " - I don't remember Sun ever
telling people off for developing any of these languages, for
instance. Sun now employs the JRuby folk IIRC, and gave their blessing
to Groovy too.

I only read about it some years ago. Perhaps restricted was the wrong
word. But in the past other languages haven't been officially let's say
supported by Sun.

This might have changed today however, since Java is Open Source now.

Heck, there's even an API (in Java 6 IIRC, but it *might* only be in
Java 7) specifically for scripting, to make binding etc consistent
between different scripting languages targeting the JVM.
>

>And it's not only the runtime that makes the difference. Can you write
>code in Java and use it easily from any other language targeting the JVM ?

>
Absolutely - and the reverse, in many cases. For instance, you can
easily call Groovy code from Java, should you wish to.

I don't know the interfaces today. The good old JNI interface was a pain
to deal with.
Is it really that simple in Java too:

- Write a class in any language and compile
- Compile the code to a Dll
- Use the code from any other language targeting the JVM too ?

I read only about using Java classes and vice versa from other
languages, but not how different languages would interact.

I can't imagine anyone designing a language to run on the JVM which
*wouldn't* take advantage of both the standard APIs and the wealth of
3rd party libraries available - and that will include any extra Java
code you write yourself.
>
Jon

Andre

[Jon Skeet [C# MVP]]

Re: C# vs. C++

Andre Kaufmann <andre.kaufmann _re_move_@t-online.dewrote:

Absolutely - and the reverse, in many cases. For instance, you can
easily call Groovy code from Java, should you wish to.

>
I don't know the interfaces today. The good old JNI interface was a pain
to deal with.
Is it really that simple in Java too:
>
- Write a class in any language and compile
- Compile the code to a Dll
- Use the code from any other language targeting the JVM too ?

Well you wouldn't compile to a DLL. You'd compile to class files, and
then potentially jar them up. At that point, there's no difference
between a Java-created class and a class created by a different
language, other than what it chooses to do. (A Groovy class would be
full of calls to the Groovy libraries to do dynamic calls etc.)

Of course, it depends on whether your chosen language *has* a compiler
- some may not. If it doesn't, you'll probably need to use BSF or Java
6's scripting support. It looks like that's the way to go for JRuby,
for example. Jython has jythonc, but that's basically deprecated. See

http://wiki.python.org/jython/JythonMonthly/Articles/September2006/1

for how to run Jython code from Java without jythonc.

It looks like Groovy is one of the best integrated languages in this
respect.

I read only about using Java classes and vice versa from other
languages, but not how different languages would interact.

If you ever get hold of Groovy in Action, we've got a whole chapter
about integrating Groovy - chapter 11.

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

[Andre Kaufmann]

Re: C# vs. C++

Daniel James wrote:

In article news:<#D7NAH11I HA.6096@TK2MSFT NGP06.phx.gbl>, Andre Kaufmann
wrote:

>Singularity has a small amount of assembly code and it's using a
>native C# compiler. Cosmos however is meant to be 100% C# code.

>
Interesting. I've read about Singularity but not about Cosmos (in fact,
I thought Cosmos must be another name for Singularity when you mentioned
the two together in your last post).
The question, then, is how? Presumably Cosmos must touch the metal
somehow ... or is it designed as a guest OS to be run within another,
native, OS?

I don't know all the internals. AFAIK Cosmos includes a compiler, which
translates the IL code generated by C# to x86 code.

No basically it is C# translated directly to native code, with some
extensions to let C# interact directly with the CPU.

[...]

>Short example (I never thought C++ to be slower in writing to files):
>The code is attached below and does nothing but simply writing 5000000
>integers to a text file.

>
What are COMPILER X and COMPILER Y?

Windows C++ compilers, I don't think that the vendors are quite
interesting and I don't want to start compiler wars ;-).

Hmm ... there has to be a reason that C# comes out looking so good ...
>
Do all the programs produce identical output? What, exactly, did you
time (e.g. do you close the files/streams in the timed section of the
code in each case)?

Close doesn't matter and yes all produce the identical output.

The fprintf and sprintf functions will always be slow as they have to
parse the formatting string each time as well as producing output, so I

The printf functions are commonly faster, because they don't have that
much overhead. IIRC correctly IOStreams (e.g. the ones shipped with
VC9.0) are using sprintf internally for formatting.

wouldn't expect them to do well. I'd expect the iostreams version to be
a good bit quicker and the itoa version to be the fastest. If I had to
guess I'd say that the C# version would be comparable to iostreams.

IOStreams are quite slow. At least the ones I know. The reason is that
much overhead due to localization, memory allocation for buffering and
too much code to run through for a simple task.

You could try another benchmark with boost::format -- I bet that would
be slower than any of them.

I think it was quite fast.

>Another point is C++ could compile (nearly) as fast as any other
>language. But therefore C++ must either get rid of (global) macros, or
>introduce modules.

>
Modules are coming, eventually.
>
It's not global macros that are the problem, it's the fact that there's

I mean with global in brackets that macros can be redefined in each and
for each header file and that the propagate to other header files.
So global was perhaps misleading, setting a macro in the compiler
affecting the whole code compiled is not a problem.

no mechanism for the compiler to know that any macros referenced (in
include files, especially) have the same values in all compilation

Yes, that is the main problem.

units/for all builds. If the build system were smarter it could track
that and avoid recompiling header information that had already been
compiled with the same settings.

Therefore it must have an overview over the whole code must distinguish
different header files with the same name etc. I think modules will be a
better solution. IIRC the IBM C++ compiler had some kind of modules
implemented and was quite fast in compilation.

Macros can be a pain, but they can also be very useful ... I always
advise people to avoid using them if there is an alternative (e.g. use
const int (or even an enum) rather than a #define) but sometimes there
is no alternative and their use is beneficial.

I know and agree. I use them too. But they could have been restricted to
have an effect on one single header file or must be globally defined.

>If you look at functional languages targeting .NET e.g. F# and see
>what is possible in these language then delegates just look like a
>simple toy

>
That's because they're functional languages, not because they target
NET -- take a look at Haskell or Erlang and see what they can do.

Yes, it hasn't something to do with .NET. F# is similar to ML, ML is
comparable with Haskell.
It should only proof that delegates can be implemented in C# directly,
as I stated in my recent post.

>But why have they to be implemented in a library ? C++ could have
>integrated delegates from the beginning and add some extensional stuff
>into a library ...

[...]
quite a big language, and making it bigger still just to add a feature
that can be implemented in a library doesn't make good sense.

I know that it's a big no no to change the language. Heck it's even to
complex to add "override" to the language.
I agree that a library is much better regarding compatibility. But it
makes it quite hard for tools implementors (e.g. RAD tools / code
completion etc.) to deal with huge libraries.
I have only the feeling that delegates should be supported directly by
the compiler and that the libraries to implement them got somewhat bloated.

[...]
I wouldn't like to judge without seeing direct implementation and
benchmarking it ... but boost::function is pretty efficient, from what
I've seen.

They have improved, since there aren't that many heap allocations
involved anymore.

There is a comparison on:

http://www.codeproject.com/KB/cpp/CppDelegateImplementation.aspx

[...]
I think you're missing the point I was making. I wasn't saying that
there was no way you could add delegate support *to* C# if it didn't
have it, I was saying that there was no way you could add delegate
support *in* C# alone.

A - O.k. you mean the "template magic" allows C++ to implement delegates
as a library, while you can't in C#, because generics aren't that
flexible enough. Besides I think templates could be implemented in any
other language too, why should it proof the power of C++ ?
(doesn't mean that I don't like them).

I could argue C# to be more powerful because:

- I can compile code on the fly. E.g. I can compile regular expressions
and XSL stylesheets to perform faster as any C++ could to, because
it has to evaluate the regular expressions/stylesheets always.
I can even build and compile script code on the fly.

There are more examples - all languages have pros and cons.
But C++ isn't that effective always.

[...]

>... but the big advantage is that, as the framework has implemented
>delegates, you can use it in every language and pass the pointers
>over dll boundaries without any hassle.

>
I'm sure that's true -- and it *is* an advantage of the environment, no
question ... but (again) it says nothing about the power of expression
of the C# language -- it says nothing about the ease with which *you*
can express complex concepts in *your* C# code.

O.k. yes. I only missed templates in C# for generic code. However, what
I'm badly missing in C# is RAII.

But you aren't restricted to a single language. If you want to express
complex concepts use another language like F# or C++/CLI and reuse the
code in C#.

Don't get me wrong, I still like C++ and it's my main developing
language. But I sometimes miss the developing experience of other
languages and I think the standardization process is quite slow.

[...]
Modules are probably the best answer, though.

Yes, I think that too. Unfortunately they are delayed and not part of
the upcoming standard.

[...]
I take the point that the CLI gives you a standard object representation
for all .NET languages, and lets you define an object in C# and
manipulate it in C++/CLI or VB.NET or whatever ... but you can't create
a template in a C++/CLI program and use it (instantiate it) in a C# or
VB.NET program -- because those languages have no conception of
templates.

Well, the .NET framework has Generics. They aren't that powerful as
templates, but on the other side you have the possibility to export
generic lists to other languages.

The implementation of templates in C++/CLI is not provided by the CLI,
but by the C++ compiler. Templates are therefore not visible to other
NET languages.

Yes. Besides security concerns and loosing the strong typing of
Generics, why shouldn't templates been implemented in other languages too ?

[...]
The slides are here:

http://accu.org/content/conf2008/Alexandrescu-accu-functional.pdf

>

Thanks, I'll have a look at it.

I don't know how much sense they'll make to someone who wasn't at the
talk!
>
Cheers,
Daniel.

Cheers,
Andre

[Andre Kaufmann]

Re: C# vs. C++

Arne Vajhøj wrote:

[...]

>Boost is a good, cool library - sure. But these libraries get somewhat
>bloated, because of all the template stuff and compilation slows down
>more and more.

>
Compilation speed is usually not important.

Why ? For RAD tools it's IMHO essential and if 1000 developers wait
daily an hour for compilation they are loosing simply 1000 hours of
development time, besides the energy wasted.

I'm simply used to quickly recompile my code after a compilation error.
In C++ is meant to compile fast code. Why can't the compiler be not that
fast ? The sad story is - it could be.

[...]
Arne

Andre