Daniel said:
I didn't say you couldn't use C# to write an OS -- most OS code doesn't
need to be particularly low level. My remark about C#'s unsuitability for
writing drivers should be taken in the context of Windows, which provides
no underlying support for C# (or any .NET language) to perform direct
access to the hardware -- a prerequisite for driver writing.
I don't know much about Singularity ... but as I understand it although the
OS (including driver code) is described as being "all written in C#" the
drivers do rely upon an assembler-coded library for all direct hardware
manipulations. That does rather change the nature of the game.
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.
[...]
It's true that compilation is slowed somewhat by extensive use of
templates. That's the trade-off: you get expressive language/library
features with impressively fast run times, but you have to pay a little in
build times to get it.
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.
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.
C++ COMPILER X: AMD 3500+ WIN VISTA
fprintf: 8417 ms
iostreams: 7329 ms
sprintf: 4463 ms
itoa: 2001 ms
C#: 2261 ms
C++ COMPILER X: INTEL QUAD CORE WIN2008
iostreams: 5091 ms
fprintf: 4586 ms
sprintf: 2322 ms
itoa: 1263 ms
C#: 1045 ms
C++ COMPILER Y: INTEL QUAD CORE WIN2008
fprintf: 4485 ms
sprintf: 2360 ms
iostreams: 2047 ms
itoa: 1656 ms
C#: 1045 ms
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.
Let's not get bogged down in irrelevant specifics -- the point here is that
C++ allows something like Boost::function to be written as library code in
C++ itself. Delegates in C# are only possible because delegates are part of
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
- and I think they proof that delegates could have implemented in C#
directly too.
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, instead it's using IMHO a rather ugly syntax for member
function pointers, which are bound to a single class type.
I know boost::function is perhaps much more powerful than a direct
implementation would be, but it could be still extended with a library
too. 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.
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, 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.
[snip]
After I had replaced all the TMP stuff by generated code the code size
could be reduced to 1MB.
How long ago was this? Compilers have got much better in recent years.
Hm, 3 years ago.
I think some of the things in Loki are nice from an academic standpoint but
a bit too abstruse for everyday use in most teams. They show the power of
C++ admirably and they may perform a useful task in very specific
circumstances but you don't need to reach such dizzying heights of
complexity to gain real benefits from TMP or the other C++ features that
raise it above the also-ran languages.
Yes, C++ has macros. If you don't like them don't use them.
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.
This - and mainly this - makes the C++ compiler that slow, because it's
compiling code over and over again. There are solutions like precompiled
header files, but it's not a standardized solution.
There is a lot of C++ that is inherited from C in order to maintain as much
compatibility as possible between the languages. That may look like a
disadvantage to C++ now, but when C++ was new it was a great help to
achieving acceptance for C++ -- because it was so very well integrated with
the dominant language of the day: C.
I agree that it's was good for C++ to be based and compatible with C,
however it's not so good IMHO that it hasn't been separated more from C.
[...]
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 ;-).
It has the advantage that it can be used by any (compliant) C++
compiler, but the downside is huge libraries and somewhat slower code.
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. I'm not an
C# expert, I'm developing more in C++ so I might be inaccurate.
[...]
some special innovation of .NET, because it isn't. 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.
It's not only about it. 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.
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.
[...]
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< ;-).
Incidentally, Andrei Alexandrescu presented a paper this spring on a new
version of DM C++ with functional programming primitives that he's been
working on with Walter Bright ... interesting stuff, but I don't think most
of the audience were quite convinced.
Hm, interesting thanks for mentioning it.
Have you used another language than C++ too, to make a good
comparison?
[...]
Cheers,
Daniel.
Code sample: ( I know that fstreams can be somewhat tweaked)
fprintf:
FILE* file3 = fopen("fprintf.txt", "w");
for (unsigned int i = 0; i < 5000000; ++i) fprintf(file3, "%d", i);
sprintf:
FILE* file = fopen("sprintf.txt", "w");
char buffer[8];
for (unsigned int i = 0; i < 5000000; ++i) {
sprintf(buffer, "%d", i);
fwrite(buffer, strlen(buffer), 1, file);
}
itoa:
FILE* file2 = fopen("itoa.txt", "w");
char buffer[8];
for (unsigned int i = 0; i < 5000000; ++i) {
itoa(i, buffer, 10);
fwrite(buffer, strlen(buffer), 1, file2);
}
iostreams:
ofstream f("ofstream.txt");
for (unsigned int i = 0; i < 5000000; ++i) f << i;
C#:
StreamWriter f = File.CreateText("csharp.txt");
for (uint i = 0; i < max; ++i) f.Write(i);
Cheers Andre
