Daniel said:
I had it half in mind to repeat your tests and try to see where the C++
versions were taking their time ... I obviously can't do that very
meaningfully if I can't know that I'm using the same tools.
You are using one of the same C++ compiler ;-). You can do a simple test
of your own, write integers to a file with iostreams and with sprintf
with the latest Microsoft VC/C# compiler. Sprintf should be faster, C#
fastest.
I guess at least the C# compiler must have been a Microsoft one <smile>
Yes, there are other alternatives, but their heap management is IMHO slower.
[...]
I haven't got a VC9 installation handy ... but in VC8 the iostream
implementation certainly doesn't use sprintf. That would be a very
I'm sorry to say, but it does.
Have a look at the file "...VS2005\VC\crt\src\xlocnum".
Search for "ld".
Set a break point on this function and then use a fstream object and
write an integer to it to see by yourself.
suboptimal implementation when you already know the type of the value
that's to be formatted. The overhead of printf is quite considerable as
the "%d" (or whatever) has to be interpreted on every call.
Yes. I think it is done for consistency reasons, to use the same
formatting.
There is certainly some overhead associated with streams, too, but it
should be less than that with the ?printf functions, except in a very
naive implementation.
You're right that localization imposes some overhead with streams -- but
not for printing integers.
The problem is only, C# (.NET) deals with localization too and the
strings are Unicode - meaning it's using 16 Bit characters.
So I'm somewhat disappointed from C++ performance (in this regard), why
do I need localization for a simple integer ?
..NET isn't (generally) faster in large projects, because the memory
footprint is still somewhat higher - IMHO.
[...]
boost::format( "%d" ) % charvar
boost::format takes the type (char) from the variable and ignores the
type implied by the %d, so you get a character rather than a number. The
only way to get the result you wanted is to cast the variable to an int
(yuk).
Didn't know that boost::format supports the printf formatting syntax
too. I used only the placeholder style: %1% %2%
[...]
I agree entirely that modules will be a better solution ... but I don't
think that means that we shouldn't also try to improve tool support for
efficient compilation of today's sourcecode. There are millions and
[...]
Yes agreed. But on the other side I once asked in the C++ forum why C++
still doesn't support >override<, while all other languages do.
I had a huge problem, with template virtual base classes and somewhere
in the object hierarchy the base function hasn't been overridden and the
compiler logically didn't complain about it. Fortunately I had VC which
has a proprietary extension supporting override for native code too to
ensure that the compiled code does what I expected it to do.
I was only told in the forum that this is a minor problem and therefore
there is no need for override to get into the next standard.
I don't use this coding style anymore, but anyways if I have to use a
class library which uses this style I can't control it's functionality
at compile time.
[on "Macros are useful too"]
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.
That wouldn't be compatible with C. In particular it wouldn't be
compatible with the way that C (and C++) allows you to redefine the
NDEBUG macro and include assert.h repeatedly to turn ASSERT macros on
and off throughout a compilation unit. That's a very widespread usage in
some codebases, and restricting the use of macros would break it.
Yes, but in this case and for this files I explicitly could activate the
old behavior. Or the other way round - doesn't matter.
On the other side a global definition of the assert macro and local
redefines would to the trick too.
They *could*, but they haven't been. If you were to add a
metaprogramming facility to C# it wouldn't be the C# that we know today.
OTOH if you were to design a metaprogramming facility to add to C# the
resulting language might be a bit nicer to use than C++ is now ... using
C++ templates for metaprogramming (rather than just for implementing
generics) is a bit of a hack -- but it's a very powerful hack, and the
fact that it has been used so much shows how much people want to do this
sort of thing.
They are powerful for sure, but if they are used too much the code gets
unreadable and hard to debug and maintain. By the way 'D' has IMHO a
good, way more readable implementation of meta templates directly in the
language.
E.g:
template Function(long n)
{
static if (n < 0) .....
else ......
}
I'm not suggesting that C++ is the best language imaginable, just that
it is the best language available today for solving most of the
programming problems with which I find myself faced.
I would perhaps migrate to 'D' if I could use my C++ more easily.
[...]
It's not that template couldn't be implemented by other languages, just
that -- at present -- they aren't.
As I wrote above, IMHO the implementation in 'D' is superior.
Even if they were I'm not sure that you would be able to achieve
inter-language compatibility with templates, as (in C++, at least) they
are source-code abstractions, and you need a C++ compiler to make use of
them.
To problem is templates aren't strong typed, in contrast to generics. If
they would be used for multiple languages e.g. in .NET and if the code
would be compiled at startup of the application, as it's done (normally)
in .NET, the code could fail to compile.
But it certainly could be done - just remove the compilation checking
from generics and you potentially would have it ;-).
Maybe if someone were to come up with a standard for some sort of
meta-code representation then different languages would be able to share
template representations that had been compiled (or part-compiled) down
to that meta-code. The "export" feature in C++ does something along
those lines, but AIUI the intermediate form is still largely C++.
Unfortunately "export" doesn't do what it's meant to be. It doesn't
separate translation units. But yes, I agree that templates could be
supported over language boundaries too.
I said Andrei had been talking about a mixture of C++ and functional
programming, didn't I? Well, it's D not C++. Still interesting, though.
Hm, the headline is about the 'D' language in it's current
implementation version 2.0.
Cheers,
Andre
