DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 3 FirstFirst 123
Results 31 to 35 of 35

Thread: Re: Is C# going to take over? Or is MS going to continue their VC++

  1. #31
    Rodney Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "James" <cplus.@127.0.0.1> wrote:
    >
    >Danny Kalev <dannykk@inter.net.il> wrote:
    >>
    >>
    >>James Curran wrote:
    >>>
    >>> "Danny Kalev" <dannykk@inter.net.il> wrote in message
    >>> news:3CA9BED6.376AF47B@inter.net.il...
    >>> >
    >>> > I wonder how all these "benchmarks" always prove that a very carefully
    >>> > crafted obfuscated code that runs under very specific settings appears
    >>> > to be faster than native assembly. Seriously, do you believe C#, which
    >>> > is built on top of C++ can be faster than C++? Let's be realistic.

    We've
    >>> > heard exactly the same claims from Java buffs for seven years, and

    still
    >>> > Java is s-l-o-w.
    >>>
    >>> It no great mystery. The author published the source code. Let see,

    >for
    >>> Object Instantiation, here's the C++ code
    >>>
    >>> int i, j, iTest = 0;
    >>> clsPerfTest *clsTest;
    >>>
    >>> tmrStartStop = new Timer();
    >>> for(i = 0; i < 10000; i++)
    >>> {
    >>> for(j = 0; j < 10000; j++)
    >>> {
    >>> clsTest = new clsPerfTest();
    >>> delete(clsTest);
    >>> }
    >>>
    >>> And here's the C# code (which ran in 1/7th the time)
    >>> int i, j, iTest = 0;
    >>>
    >>> clsPerfTest clsTest;
    >>>
    >>> tmrStart = System.DateTime.Now;
    >>> for(i = 0; i < 10000; i++)
    >>> {
    >>> for(j = 0; j < 10000; j++)
    >>> {
    >>> clsTest = new clsPerfTest();
    >>> clsTest = null;
    >>> }
    >>> }
    >>>
    >>> Pretty much the same right? But appearances may be deceiving.
    >>>
    >>> First of all, the C++ object is being created on the heap, when it would
    >>> have been just as useful created on the stack -- except it would be much
    >>> faster from the stack.

    >
    >Are you suggesting applications should only ever use stack objects? Look
    >at the bigger picture and compare like with like.
    >
    >>> Further, the C++ clsPrefTest has a virtual dtor,
    >>> while the C# version has an implied dtor. The C# compiler to allowed

    >to
    >>> notice that the dtor is empty and elide it, but since the C++ version

    >is
    >>> virtual the C++ compiler is specifically prevented from doing that (if

    >the
    >>> C++ dtor were implied, it could).

    >
    >Not a huge impact, if any.
    >
    >
    >>> Further, none of the C++ clsPerfTest
    >>> members are inlined. If we inlined them, they'd be much faster.

    >
    >In this case may be (or may be not) but to what degree i.e. what is ‘much
    >faster’? It is also worth noting that ‘inlining’ can actually make code

    execution
    >slower.
    >
    >>> In other words, if you don't use the features in C++ that were put

    >there
    >>> to make it fast, it can be just as slow as any other language.

    >
    >No, remember that for like for like tests C# is faster, using the ‘the features
    >in C++ that were put there to make it fast’ only serves to bring C++ closer
    >to the performance of C#.
    >
    >
    >>Adding to that, the underlying machinery of Managed code ensures slower
    >>execution time. First of all, it uses JIT compilation of Intermediate
    >>Language (which isn't very different from Java's bytecode). Unlike in
    >>Java, the compiled IL code is cached so subsequent calls of the same
    >>methods don't incur the JITting overhead. Alas, the compiled code is
    >>transient. Every time you launch the application or reboot the system,
    >>it must be repeated *for every method* called. Imagine how annoying it
    >>would be if every morning you'd have to recompile the entire Office
    >>suite or your Web browser... Although it's possible to pre-JIT and
    >>entire application and avoid all this nuisance, this nullifies the
    >>so-called portability of .Net IL code.

    >
    >Depends on the application and deployement environment. But such a big issue,
    >unlike C, you have a choice in C#. Indeed one suspects that in future it
    >will be possible for it to be compiled one only and disk cached.
    >
    >>Put differently, C# could be an improvement over Java (which frankly,
    >>isn't that difficult. Even VB performs better than Java) but it cannot
    >>compete with properly written C/C++ compiled to native code.

    >
    >Compete where? In application development it can and will surpass anything
    >C++ can offer. Why are C++ programmers so fixated with raw processing speed.
    >Why do you always fail to see the bigger picture?
    >
    >This is why you are being relagated to system development and specialist
    >component building (for the present); thats fine for us VB developers we
    >get to do all the exciting development and integration stuff!
    >
    >Anyway, I though we agreed no more posts!
    >
    >>Danny
    >>>
    >>> --
    >>> Truth,
    >>> James Curran
    >>> www.NJTheater.com (Professional)
    >>> www.NovelTheory.com (Personal)

    >


    "The Reports of My Death...Have Been Greatly Exaggerated!"

    Actually, it is not only in "raw processing speed" that C++ is superior to
    C#, Java, and VB. Just as important, if not more so, is the superiority of
    C++ in regard to the breadth and depth of the programming constructs that
    can be expressed in the language. Support for generic programming is but
    one example; however, there are many others.

    By the way, when was the last time you walked into a COMPUSA and purchased
    a software product written in VB or Java? Why do you think so many of them
    are written in C and/or C++. The argument that C/C++ has been relegated to
    the role of systems programming is absurd, give the undisputed success of
    commerical applications developed in C++ (name ONE commerically successfull
    application developed in VB or Java).

    C++ is still the professional programmer's ultimate power tool.






  2. #32
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "Rodney" <RodneyAdams@EarthLink.net> wrote:
    >
    > ...
    >
    >"The Reports of My Death...Have Been Greatly Exaggerated!"
    >
    >Actually, it is not only in "raw processing speed" that C++ is superior

    to
    >C#, Java, and VB. Just as important, if not more so, is the superiority

    of
    >C++ in regard to the breadth and depth of the programming constructs that
    >can be expressed in the language. Support for generic programming is but
    >one example; however, there are many others.
    >
    >By the way, when was the last time you walked into a COMPUSA and purchased
    >a software product written in VB or Java? Why do you think so many of them
    >are written in C and/or C++. The argument that C/C++ has been relegated

    to
    >the role of systems programming is absurd, give the undisputed success of
    >commerical applications developed in C++ (name ONE commerically successfull
    >application developed in VB or Java).
    >
    >C++ is still the professional programmer's ultimate power tool.
    >


    Now, now!

    Let us not have a voice of reason to be the final word on this subject.
    Besides with the temporary "down-sizing" going on at the moment I believe
    the better strategy is to encourage as many people as possible to shun C++
    and learn only Java. (Throwing in a promise of riches and employment forever.)

    As for a commercially successful "application" - if you will count the CDs
    that come with the "Learn <Java/VB> in 21 Days" and "Secrets of <Java/VB>"
    books. Then I would have to say they have been very $ucce$$ful.


  3. #33
    Bryan Pietrzak Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "James" <cplus.@127.0.0.1> wrote:

    >For new application development on Windows platforms, C/C++ is dead!



    This is all some kind of April Fools joke right?

    You are just kidding right?

    I mean do you *really* think the next version of Maya, Word, Photoshop, Acrobat,
    FreeHand, Excel, Visual Studio, and so on are going written in C#? No way.
    Not unless they don't want to sell any copies.

    Now, will the next corporate time input tool be in C#? Sure. Lots of enterprise
    tools that have used VB will move to C#, but they'll still be slow, ugly
    and awkward to use. I'm not sure that I've ever seen a VB app that was designed
    with an understand of user experience. But, that could just be due to the
    fact that our in-house VB guys aren't good. And of course, that could be
    because they're not "real" programmers in the sense that they've *studied*
    their craft. They may have taken a two week VB course and called themselves
    programmers.

    Bryan

  4. #34
    Scott Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "James" <cplus.@127.0.0.1> wrote:
    >I never said that C/C++ would be replaced completely. I accept that there
    >is a time and place for the language. What I wrote was that C# (and other
    >.NET languages) would replace C/C++ for APPLICATION DEVELOPMET.
    >
    >Why do I have to keep writing this? Why can't C/C++ comprehend the difference
    >be system and application development?
    >
    >For new application development on Windows platforms, C/C++ is dead!
    >


    Yes, and Danny keeps having to say that he, this "c++.general" board, the
    original question and c++ programmers in general don't care about application
    development because it is simplistic and boring. We don't care to limit
    ourselves to this narrow domain. Why is it that every time he says this
    you respond with "But in application development..."?

    Scott

    p.s. That's a rhetorical question, I don't really care about the answer.


  5. #35
    Daryl Shockey Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    I'm going blind reading this thread and in light of what I'm reading, I wanted
    to shed some balanced thoughts on the whole thing. This will be a little
    long (and for that I apologize) but I think worth the read.

    First of all, to those people who think that VB and C/C++ are simply different
    but equal when it comes to coding, let me first state that VB has favored
    verboseness over conciseness in its syntax. Let me point out some example
    of this difference in syntax style:

    Situation: I have an array with an unknown number of elements. I want to
    loop through all of its possible values. Assuming "iCount" is an integer
    variable containing the number of elements, the following loop would work
    well in C/C++: (and C#)

    for(int x = 0; x < iCount; x++)
    {
    <loop code here>
    }

    VB uses a more English-like notation in its "For" loop. Your code would
    read like this:

    Dim x As Long
    For x = 0 To iCount - 1
    <loop code here>
    Next

    Unfortunately, this would not always work. If the possibility exists that
    the array could have zero (0) elements, then the VB code shown here would
    break. Zero minus 1 is equal to -1, thus the loop would begin cycling for
    values of 0, 1, 2, 3, 4, etc. until it eventually arrived at -1. If the
    last statement seemed illogical, it's because it is. A runtime error would
    occur before the condition was met. So instead, you would need to accomodate
    the situation with code like this:

    Dim x As Long
    If iCount > 0 Then
    For x = 0 To iCount - 1
    <loop code here>
    Next
    End If

    Which of these (C/C++ v. VB) needs to be more verbose? I could cite at least
    half a dozen *common* coding statements in which VB favors a verbose code
    syntax over small and concise. As a developer, I've turned to VB many times
    for it's RAD features. I've used it to build Windows Apps and ActiveX controls
    for web pages. Likewise, for a long time I've wished a RAD version of C/C++
    existed.

    Different languages serve different purposes. (Always remember that.) If
    I want to write an ActiveX control for a web page and performance is not
    critical, I make it in VB. If I need to take a data dump and massage or
    otherwise manage the information, I turn to Perl. If I'm writing a system
    utility, I turn to C. There is no single language that is best for all situations.
    C# and the entire .Net infrastructure will by no means replace C/C++ because
    they're not designed for the same situations.

    C# is largely about two things:
    1.) Enabling RAD development in a language syntactically similar to C.
    2.) Having code run in a managed environment. (this applies to .Net in
    general)

    The latter of the two is very significant for many people, especially web
    developers. Does anybody out there remember how tedious it has been to check
    bounds on all arrays that exist in the stack? Any time that data from an
    untrusted source would be stored on an array on the stack you always had
    to conduct bounds checks as you read in the information. In a managed environment,
    concern over bounds checking can be alleviated by the notion of managed memory
    access. In C#, if something occurs at runtime that would cause a boundary
    violation, the managed runtime will trigger an exception and interrupt code
    execution. Making your code bulletproof against buffer overflows becomes
    much more feasible. (You still want to do bounds checks to avoid the runtime
    error, but this is far preferable to having a hacker run code of their choice
    on your system.)

    In addition, a managed environment means that the system now has *awareness*
    of what memory allocations have been made and what is currently in use.
    Those of us already familiar with the concept of scope in C/C++ (and now
    C#) understand that when a variable or reference to an object passes out
    of scope, we can't access it anymore. The system, knowing the same thing,
    can as needed invoke the garbage collector and automatically clean out objects
    that were at one time referenced but have since had all references pass out
    of scope. Again, this helps address another low-level coding issue that
    has nipped at the heels of C/C++ developers since the beginning of time:
    memory leaks. Are there scenarios where tighter control of memory is appropriate?
    Absolutely. But for every one time when control is beneficial, there are
    probably 5 times where it's just plain tedious and could be just as well
    handled by the system.

    Does a managed environment impact performance? Yes. But in any environment
    for which you are developing, two questions need to be asked:
    1.) Will the performance capabilities of the system ever be approached
    in the real world? (If not, then performance doesn't matter.)
    2.) If so, what will prove to be the bottleneck?

    What difference does it make how efficient code is if the performance bottleneck
    lies in the 10 Mb/s internet link? What about if the bottleneck is the time
    it takes getting the database to respond to a complicated but necessary query?
    In either of these scenarios, making the code more efficient won't yield
    any palpable benefit. That essentially eliminates the performance/benefit
    tradeoff associated with a managed environment. (The benefit is free.)
    I'm not trying to downplay the fact that performance takes a hit. The point
    is that the hit doesn't matter *if that's not where the performance bottleneck
    lies.* If I didn't have anything to lose by employing managed code, I'd
    prefer it any day over unmanaged code.

    I'm not a Microsoft junkee and I was one of the first to criticize the garbage
    collector that Java employed. Nevertheless, I am fully convinced that managed
    code has a place and time in the world of software development. It's certainly
    not a silver bullet that will cure all ills. But nothing is. Like I said
    earlier, you use the tool that best suits the situation. Keep that in mind
    as the debate rages on about "will C# replace C/C++". I think the point
    is moot. C# (and .Net) is just another tool that helps fill a spot that's
    been needing filled for some time now.

    That's my two cents.

    --> Daryl

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center