C# vs. C++

[Hendrik Schober]

Re: C# vs. C++

Daniel James wrote:

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

Usually iostreams are implemented using the 'printf()' family,
so it's very unlikely they're faster. It's sad, because with all
the type info known at compile-time streams ought to be faster
than 'printf()', but that potential was never used. Dietmar Kühl
once had an implementation that didn't do this and was regarded
fast, but for some reason it never took off.

[...]
Daniel.

Schobi

[Rudy Velthuis]

Re: C# vs. C++

Hendrik Schober wrote:

You can always throw processing power at this problem
(www.xoreax.com). This worked great for a company I used
to work for and turned 60mins into 12mins.

Still a long time. <g>

--
Rudy Velthuis http://rvelthuis.de

"Ignorance simplifies ANY problem." -- R. Lucke

[Hendrik Schober]

Re: C# vs. C++

Rudy Velthuis <newsgroups@rve lthuis.dewrote:

Hendrik Schober wrote:
>

> You can always throw processing power at this problem
> (www.xoreax.com). This worked great for a company I used
> to work for and turned 60mins into 12mins.

>
Still a long time. <g>

Yes, but this was several MLoC. And usually you don't
have to compile /everything/ during writing/fixing
code.

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

[Daniel James]

Re: C# vs. C++

In article news:<MPG.22cdf 296d59b8340dbd@ msnews.microsof t.com>, Jon
Skeet wrote:

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

Not really. First bit says the JVM is only meant to be for Java, second
bit says that hasn't stopped people using it for other languages
(without Sun's blessing, at least in the earlier cases).

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

Yeah ... Sun would probably say that the JVM has no opcodes that can be
used to support pointer arithmetic (a) because Java doesn't need them,
and (b) because they're potentially unsafe; but I bet they regarded the
fact that that meant you couldn't target it from C or C++ as an added
bonus.

No, I don't suppose they went out of their way to make it impossible to
implement C or C++ to target the JVM /per se/, but I do think they saw
pointer manipulations as a bad thing and deliberately left them out of
the instruction set of the JVM so people couldn't use them -- after all:
Java doesn't need them, and who would be silly enough to use anything
else.

There's a big difference in mindset, though, between what Sun did with
Java (we've just reinvented p-code and it's just for our new language
called 'Java' -- so we've called it the "Java Virtual Machine") and what
Microsoft did with .NET (we've just reinvented p-code (again) -- and we
want it to be able to run any language you like, and we want third
parties to port their languages to it ... oh, and we've just developed a
new language called C# that will target this and nothing else, but don't
you worry about that).

Now, admittedly, MS needed to shout all they could about any advantages
offered by the CLI over the JVM, so that they could attract attention
away from the JVM -- which was becoming an established standard -- so
they had some interest in gathering as much 3rd-party support as
possible in any way they could ... but it looks like a very different
attitude to mixed-language programming to me!

Does anyone actually use Eiffel.NET, BTW? I haven't heads anything about
it since it was heralded as one of the first examples of a third-party
language targeting the CLI, way back when.

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.

Yes, I agree. Sorry, I think you missed my point -- I should probably
have said "but" or "whereas" or something in there -- Most of the
languages mentioned are just research toys, BUT (I went on to say)
Jython and Groovy (and JRuby, if you say so, I know less about that) do
have real-world uses.

I hadn't seen Scala before ... it looks very Java-like (perhaps
unsurprisingly) and I'm not sure quite what makes it different, on a
first glance. I'll obviously have to read further.

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

I certainly don't know much about it ... usually it's been discussed as
a way to bind databases to C# code (and it all seemed very reminiscent
of the hype that ODBC got when it was new). I'll look further, thanks
for the "heads up".

Cheers,
Daniel.

[Daniel James]

Re: C# vs. C++

In article news:<uIaWQv81I HA.5140@TK2MSFT NGP02.phx.gbl>, Andre Kaufmann
wrote:

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.

OK, that's interesting. It's C# but not C#.NET.

What are COMPILER X and COMPILER Y?

>
Windows C++ compilers, I don't think that the vendors are quite
interesting ...

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.

I guess at least the C# compiler must have been a Microsoft one <smile>

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

Close *does* matter ... especially if the output is buffered up to that
point and only written to disk on the close call. It could be that all
the real work actually takes place outside the timing loop in some of
your tests.

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.

I haven't got a VC9 installation handy ... but in VC8 the iostream
implementation certainly doesn't use sprintf. That would be a very
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.

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.

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

>
I think it was quite fast.

boost::format does very similar processing to that done by sprintf. It
makes use of the actual type of its arguments rather than taking that
from the format string, but still had to parse the string for layout,
etc. It's usually very slow.

It also has surprising results in some cases -- if you use a char
variable as an 8-bit integer and try to print it using

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

[on macros and compilation]

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.

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
millions of lines of C++ code in use today, and that body of code won't
magically be converted to use modules one rainy day in (say) 2015 when
compilers start to support them!

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

(This sort of code also makes it very hard to write the sort of 'smart'
compilation system that I was talking about ... but that doesn't mean
that it's not worth trying!)

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.

That's kinda what I've been saying all along, yes.

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

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.

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.

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

It's not that template couldn't be implemented by other languages, just
that -- at present -- they aren't.

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.

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

The slides are here:
http://accu.org/content/conf2008/Ale...functional.pdf

>
Thanks, I'll have a look at it.

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.

Cheers,
Daniel.

[Daniel James]

Re: C# vs. C++

In article news:<utZpg981I HA.6096@TK2MSFT NGP06.phx.gbl>, Hendrik
Schober wrote:

Usually iostreams are implemented using the 'printf()' family,

That's obviously an easy-but-naive implementation, I'd hope that as C++
continued to mature quick hacks like that would disappear.

Certainly the current Visual C++ (Dinkumware) runtime doesn't seem to
use sprintf.

Cheers,
Daniel.

[Jon Skeet [C# MVP]]

Re: C# vs. C++

On Jun 27, 11:56 am, Daniel James <wastebas...@no spam.aaisp.org>
wrote:

Skeet wrote:

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

>
Not really. First bit says the JVM is only meant to be for Java, second
bit says that hasn't stopped people using it for other languages
(without Sun's blessing, at least in the earlier cases).

I think we'll have to agree to disagree about the wording that started
this subthread then. To me, Java *is* an "intermedia te code engine
targeted by more
than one source language". It just isn't an intermediate code engine
*designed* to be targeted by more than one source language.

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

>
Yeah ... Sun would probably say that the JVM has no opcodes that can be
used to support pointer arithmetic (a) because Java doesn't need them,
and (b) because they're potentially unsafe; but I bet they regarded the
fact that that meant you couldn't target it from C or C++ as an added
bonus.

Not sure. I strongly suspect that treating Sun as a single entity
doesn't really work here. Different employees of Sun are likely to
have different attitudes.

<snip>

There's a big difference in mindset, though, between what Sun did with
Java (we've just reinvented p-code and it's just for our new language
called 'Java' -- so we've called it the "Java Virtual Machine") and what
Microsoft did with .NET (we've just reinvented p-code (again) -- and we
want it to be able to run any language you like, and we want third
parties to port their languages to it ... oh, and we've just developed a
new language called C# that will target this and nothing else, but don't
you worry about that).

Agreed, although I don't think MS ever claimed that they want you to
be able to run "any language you like" - it needs to have a certain
degree of similarity to the underlying platform. (Some people have
criticised it for precisely this reason, in fact.)

<snip>

Does anyone actually use Eiffel.NET, BTW? I haven't heads anything about
it since it was heralded as one of the first examples of a third-party
language targeting the CLI, way back when.

I haven't heard of much use, but that's a good example of where the
platform gets in the way of the language. From what I remember,
multiple inheritance in Eiffel.NET is a bit of a kludge with various
limitations. In other words, .NET doesn't have the same set of
limitations as Java when it comes to porting languages to it, but
there certainly *are* limitations.

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.

>
Yes, I agree. Sorry, I think you missed my point -- I should probably
have said "but" or "whereas" or something in there -- Most of the
languages mentioned are just research toys, BUT (I went on to say)
Jython and Groovy (and JRuby, if you say so, I know less about that) do
have real-world uses.

Righto.

I hadn't seen Scala before ... it looks very Java-like (perhaps
unsurprisingly) and I'm not sure quite what makes it different, on a
first glance. I'll obviously have to read further.

From what I've seen it has some similarities to C# 3, but taken a bit
further. It supports a functional style of programming much more
neatly than Java does. It may also have some dynamic aspects, although
I can't remember offhand.

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

>
I certainly don't know much about it ... usually it's been discussed as
a way to bind databases to C# code (and it all seemed very reminiscent
of the hype that ODBC got when it was new). I'll look further, thanks
for the "heads up".

Yup, it's unfortunate that the SQL side of things is what's gained the
most attention. I wouldn't like to try to describe it in just a few
sentences - I'm sure you'll have more joy investigating it properly :)

Jon

[Hendrik Schober]

Re: C# vs. C++

Daniel James wrote:

In article news:<utZpg981I HA.6096@TK2MSFT NGP06.phx.gbl>, Hendrik
Schober wrote:

>Usually iostreams are implemented using the 'printf()' family,

>
That's obviously an easy-but-naive implementation, I'd hope that as C++
continued to mature quick hacks like that would disappear.
>
Certainly the current Visual C++ (Dinkumware) runtime doesn't seem to
use sprintf.

That would have been a pleasant surprise. But outputting
an 'int' using '<<' certainly lands you in 'sprintf()'. :(

Daniel.

Schobi

[Peter C. Chapin]

Re: C# vs. C++

Daniel James wrote:

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.

Also AdaCore has recently developed a version of the GNAT Ada compiler
that targets the CLR. I haven't played with it much (yet), however.

Peter

[Andre Kaufmann]

Re: C# vs. C++

Hendrik Schober wrote:

Rudy Velthuis <newsgroups@rve lthuis.dewrote:

>Hendrik Schober wrote:
>>

>> You can always throw processing power at this problem
>> (www.xoreax.com). This worked great for a company I used

Thanks for the link.

>> to work for and turned 60mins into 12mins.

>Still a long time. <g>

>
Yes, but this was several MLoC. And usually you don't
have to compile /everything/ during writing/fixing
code.

Yes, agreed. But in a large team it's still a pain to start the build
process over and over again, because in your local project it compiled
fine but in another project some weird side effect causes a compilation
error.

Even if I use processing power, C++ still compiles way more slower than
most of the other languages do. Currently our build time is 30 minutes,
which has been 3 hours before we switched to a quad core system.

I could live with the compilation time, if the slow down would be caused
by the complex syntax of C++ only and if that would be outweighed by the
productivity increase by all the goodies of C++ (templates, RAII etc.).
But since the slow down isn't caused by the complexity, but because the
compiler has to compile code over and over again, I think it's a huge
loss of productivity for - nothing - .

I hope modules will fix the problem, at least they should if I
understood them correctly. But they have been delayed again and I think
it will need 5+ years till they will be part of the standard.

There should be IMHO something like boost is for the C++ standards
library, a fast track standard for the C++ language, which takes the
risk of changes and if the features are stable, the could be taken over
by the "stable" C++ standard. I know that GCC has taken over somewhat
this part, to see the stability of new features. But unfortunately this
doesn't help me that much, since other compilers don't support this
experimental features.

Schobi

Andre

[Andre Kaufmann]

Re: C# vs. C++

Daniel James wrote:

In article news:<uIaWQv81I HA.5140@TK2MSFT NGP02.phx.gbl>, Andre Kaufmann
wrote:

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\c rt\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.

>(doesn't mean that I don't like them).

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

>>The slides are here:
>>http://accu.org/content/conf2008/Ale...functional.pdf

>Thanks, I'll have a look at it.

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

Cheers,
Andre

[Daniel James]

Re: C# vs. C++

In article news:<uA44WQP2I HA.4492@TK2MSFT NGP02.phx.gbl>, Andre Kaufmann
wrote:

I'm sorry to say, but it does.
Have a look at the file "...VS2005\VC\c rt\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.

Took my a while to get there (I was searching for "ld" without the
quotes, which didn't help) but I see you're right.

I didn't dig deep enough before -- I got as far as the call to
_Nput_fac.put in ostream and naively assumed that that would be
implemented ... how shall I put this ... sensibly.

That explains a lot about some of those timings!

I think it is done for consistency reasons, to use the same
formatting.

Silly, really ... at the very least that call to ::sprintf_s could be
replaced by a direct call to whatever sprintf_s uses to format numbers
... no need to set up a format string and then have to run code to
interpret it!

why do I need localization for a simple integer ?

Good question ... I'm not sure whether localization covers things like
using different chars (Arabic?) for digits ...?

..NET isn't (generally) faster in large projects, because the memory
footprint is still somewhat higher - IMHO.

Yes. I've not enough .NET experience to say for certain ... but
certainly in Java projects I've noticed that the VM grabs more and more
memory as the application(s) run and the whole system gets slower and
slower -- this is apparently because garbage collection is so expensive
that the system delays it as long as possible (hoping that the app may
terminate before collection is actually needed). Memory management needs
very careful attention on server systems that have to have long uptimes
-- more so than C++ systems where memory issues are better understood
and RAII makes most aspects of its management very easy.

Didn't know that boost::format supports the printf formatting syntax
too. I used only the placeholder style: %1% %2%

It uses (something approximating) the Open Group printf syntax -- which
includes the placeholder formats.

To problem is templates aren't strong typed, in contrast to generics.

That both is and isn't true. The whole point of templates is that they
can be instantiated with arbitrary arguments (so long as that
instantiation is meaningful) but I agree that that does erode
type-safety. The answer may lie in concepts.

[on templates in other languages]

But it certainly could be done - just remove the compilation checking
from generics and you potentially would have it ;-).

I note the smiley ... there is of course much more to it than that!

Unfortunately "export" doesn't do what it's meant to be. It doesn't
separate translation units.

I don't think that's been shown conclusively. When Daveed Vandevoorde
implemented export in the EDG compiler he changed his opinion on the
usefulness of the feature ... unfortunately most people (I might say,
cynically, most of those who don't want to spend time and money
implementing the feature) still adhere to the notion that export would
not offer much advantage.

I think modules will offer more advantage, but it's not clear that
export really is as bad as most pundits seem to be saying.

But yes, I agree that templates could be supported over language
boundaries too.

That's not quite what I said ... though I do think that if two languages
had template mechanisms with identical semantics then it would be
possible to design a template intermediate format that both could be
used by compilers for both languages and which would allow
cross-labguage template support.

Notice that all-important "with identical semantics", though. In
practice I suspect it ain't gonna happen!

Cheers,
Daniel.

[Daniel James]

Re: C# vs. C++

In article news:<ueHnd9F2I HA.3884@TK2MSFT NGP05.phx.gbl>, Hendrik Schober
wrote:

Daniel James wrote:

Certainly the current Visual C++ (Dinkumware) runtime doesn't seem
to use sprintf.

>
That would have been a pleasant surprise. But outputting
an 'int' using '<<' certainly lands you in 'sprintf()'. :(

Yeah, sorry, I boobed. Andre Kauffman has pointed out elsethread that I
didn't dig deep enough into the Dinkumware code to get to the
::sprintf_s call.

That's rather disappointing ... num_put::do_put knows that what it's
printing is an int, so it passes a format string to sprintf_s and gets
it to decode that to determine something its caller already knew. Why
can't do_put directly call whatever sprintf_s calls to process ints?

Maybe the efficiency gain from doing that would be trivial, but from
where I sit it looks like the code just makes work for itself.

Cheers,
Daniel.

[Andre Kaufmann]

Re: C# vs. C++

Daniel James wrote:

In article news:<uA44WQP2I HA.4492@TK2MSFT NGP02.phx.gbl>, Andre Kaufmann
wrote:
>
Took my a while to get there (I was searching for "ld" without the
quotes, which didn't help) but I see you're right.

Sorry, my fault - single quotes have been misleading.

[...]

>why do I need localization for a simple integer ?

>
Good question ... I'm not sure whether localization covers things like
using different chars (Arabic?) for digits ...?

I don't know for sure - I only know that Romans have written them
differently. I assume that all other languages use the same digits - if
I'm not totally wrong.

>
I don't think that's been shown conclusively. When Daveed Vandevoorde
implemented export in the EDG compiler he changed his opinion on the
usefulness of the feature ... unfortunately most people (I might say,
cynically, most of those who don't want to spend time and money
implementing the feature) still adhere to the notion that export would
not offer much advantage.

I too don't think export isn't worth the time (2 man years of coding).
It would be better to put the time into modules instead.

I think modules will offer more advantage, but it's not clear that
export really is as bad as most pundits seem to be saying.

Perhaps not bad, but it doesn't offer more than modules - so IMHO there
is no need to implement both - (assuming that the code base of STL and
boost must be changed either - for export support or for modules).

Cheers,
Daniel.

Cheers,
Andre

[Angus]

Re: C# vs. C++

Anyone that thinks an operating system would be written in C# is seriously
in cloud cuckoo land.

Most operating systems I guess still have a lot of C code. But suspect some
parts being re-written in C++.

There are a ton of reasons why C++ is more flexible and powerful than C#.
Same reasons that C++ is more flexible and powerful than Java.

If you wanted to write a general purpose program with a small footprint,
with good performance then C++ is a great choice.




"RFOG" <no@mail.comwro te in message
news:8386F4EB-F3D3-4139-808F-6CBFCD5D521C@mi crosoft.com...

"Arne Vajhøj" <arne@vajhoej.d kescribió en el mensaje de noticias
news:4861b6ba$0 $90275$14726298 @news.sunsite.d k...

RFOG wrote:

Then, Alvin, next Windows will be done in C#?

Next OS from MS could very well be done in C#.

We have a phrase: "confía en Dios y no corras", that will be translated as
"be confident with God and don't run".
>
Of course, C# can deal with LDT, GDT, vector interrupts, rings, direct
hardware access and of course microprocessors executes MSIL directly(*).
>

But don't hold your breath until it hits the streets.

>
:-)
>
>

Arne

>
(*) Please, read as a irony.
--
Microsoft Visual C++ MVP
=============== =========
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
=============== =============== ==========
Cualquier problema sencillo se puede convertir en insoluble si se celebran
suficientes reuniones para discutirlo.
-- Regla de Mitchell.
>