Re: Position of MS regarding the future C++ Standard

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



William DePalo [MVP VC++] wrote:
"Nemanja Trifunovic" <ntrifunovic@xxxxxxxxxxx> wrote in message
news:1160273999.316942.288020@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
William DePalo [MVP VC++] wrote:
what you get is a world in which it is not likely that C++
to be the first choice for new projects.


IMHO, there is still no replacement for C++. People who are
abandoning it for C#/VB/Java/whatever were simply using C++ for
wrong kind of projects (mostly internal or "enterprise" data centric
applications). For system programming, real-time apps, high
performance computing, CAD,... C++ is still the language of choice.

I agree with you. Had I written "most new projects" as I should have,
I think we might be in agreement as I don't think that the types of
applications that you mention amount to most of them.

It depends on who's writing them. A new geometry modelling system,
no matter when you start it, will not really be feasible to write in
C#, trust me. And it's not because C# is incapable of it (although
I just don't know whether it in fact is), it's mostly because those
who are going to write a new geometry modeling system don't give
a damn about C#. They know C and C++ and they're not going to bail
out and switch to a fad language all of a sudden.

As for utilities, plug-ins, web nonsense, ten years ago it was Java,
five years ago it was Python, now it's C#... It will be another one
in five years to talk about, mark my word. I am not saying C# will
vanish into oblivion (with MS backing it's hard to imagine that it
might happen), but it'll become "just one of them", and there will be
something new and shiny and everybody will start asking these questions
again.

Besides "most new projects" is just as nebulous as saying nothing.
Most new projects *I* create (including web nonsense or utilities or
plug-ins) are in C++, simply because I am most comfortable in C++.

On the other hand if Intel can really manage to get 80 core machines
to go mainstream

http://news.com.com/Intel+pledges+80+cores+in+five+years/2100-1006_3-6119618.html

then it will hardly matter how much more performant C++ is over C#.

You'd like to think that, wouldn't you? In fact, applications that
have already been written to work on many CPUs will work just as well,
and the means to create parallel code (and the compilers) will also
develop with the rise of multi-core processors. The number of CPUs
does not really control how fast operations are performed. It all
depends on what operations there are and how many of them there are.
Scalability is essential, but it doesn't matter what language you use,
it matters how you use it.

If multithreading is not used properly, applications written in C#
will simply collect garbage 79 times faster on 80 CPUs than on 1 CPU.
Is there any gain in that? Definitely. Is it substantial?

What I'm afraid the most is that the OS has to be made capable of
handling many CPUs, and if it isn't done right, all the time will be
spent pushing the thread around between processors, like balls in
a pinball machine, and it won't matter what language your program
is written it, they all will work slow (instead of all working at the
same relative speed as before, as they should).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


.



Relevant Pages

  • Re: Notating out old code in Access Database
    ... Applications" referenced by MSAccess take rather different paths. ... language is identical, ... figured it was a matter of release dates or some weird compatibility issue ... IMDB told me the basic outline, though, so I see what you were referring to. ...
    (microsoft.public.vb.general.discussion)
  • Re: Intel Quad Core performance on CentOS 5.2 is slower
    ... you won't see any significant speed up no matter how many cores or cpus ... applications to make use of the multi-core cpu. ...
    (comp.os.linux.hardware)
  • Re: How to speed up ruby and make it as fast as possible
    ... real world applications. ... be suitable for Ruby. ... language developers, but to better convey the extent of interest in such ... But it doesn't matter if someone comes along ...
    (comp.lang.ruby)
  • Re: End of the Free Lunch of Hardware
    ... I guess thats what makes Haskell slow... ... concepts I've learned in my short time with the language. ... > Create the logic such that everything can respond to TICKS. ... and that won't take advantage of multiple CPUs ...
    (alt.lang.asm)
  • Re: Linux to support Massive Multi-Threading (or dies)!
    ... SMP was in the kernel ... The expectation, therefore, is that applications have to spawn Plenty ... REALITY is that researchers have been working on multiprocessing ... CPUs, but actually there are plenty of cases already where they will. ...
    (alt.os.linux)