Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming

C++ 2011 and the Return of Native Code 616

snydeq writes with an editorial in InfoWorld about the resurgence of native code. From the article: "Modern programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net, which shield them from some of the drudgery of memory management and input validation. Others are willing to sacrifice some performance for the syntactic comforts of dynamic languages such as Python, Ruby, and JavaScript. But C++11 arrives at an interesting time. There's a growing sentiment that the pendulum may have swung too far away from native code, and it might be time for it to swing back in the other direction. Thus, C++ may have found itself some unlikely allies."
This discussion has been archived. No new comments can be posted.

C++ 2011 and the Return of Native Code

Comments Filter:
  • False dichotomy (Score:4, Interesting)

    by MrEricSir ( 398214 ) on Thursday August 18, 2011 @02:39PM (#37132758) Homepage

    Look at Objective C or Vala -- just as easy as C# or Java, but none of the headaches of a virtual machine runtime.

  • by whiteboy86 ( 1930018 ) on Thursday August 18, 2011 @03:08PM (#37133138)
    Managed code has been the single biggest disaster at least where I work, stalls, huge memory consumption, unpredictable.. the dreaded 'garbage collection', I am glad we are out of it.. and if you fear crashes then you could use C++ exceptions, then you can divide by zero or do other bad stuff and never experience a hard crash... or even better, use the complete threaded sandbox (see Chromium sandbox). that means C++ is totally safe and the fastest at the same time - best of both worlds; that is why C++ is used internally by Google, Ebay, Oracle.. etc.
  • Re:For learning (Score:4, Interesting)

    by GooberToo ( 74388 ) on Thursday August 18, 2011 @03:12PM (#37133198)

    Java has its purposes. Write-once, Run-Almost-Anywhere is a good concept.

    It is a good concept. Unfortunately, several studies (at least one was covered here on slashdot) indicate the vast majority of Java development runs on the same platform on which it was written. Furthermore, the vast majority of this Java software can not run anywhere without additional code changes because of programmer short sightedness or just simple mistakes.

    So while its a nice "have", pragmatically speaking, it doesn't apply to most Java software.

    Which means, at the end of the day, your development cycle of something like Java vs C++ isn't all too entirely different for code which actually is, "Write-one, Run-Almost-Anywhere."

  • Anecdote time! (Score:2, Interesting)

    by bberens ( 965711 ) on Thursday August 18, 2011 @03:48PM (#37133760)
    Given two developers of equal talent the developer using .NET or Java is likely to outproduce the developer using C/++ in nearly every meaningful measurement to a business. There are exceptions, of course, in places where managed languages don't fit well (or at all) such as device drivers, real time software, etc. Developers keep forgetting how expensive their time is, and more importantly their real role within the business.

    On top of that, unfortunately we'll always be working alongside poor quality developers and in spite of our arrogance will occasionally make "poor quality" code even if we're pretty good developers. Personally, I'd rather deal with the aftermath of some poorly written Java code than some poorly written C code.
  • by SoftwareArtist ( 1472499 ) on Thursday August 18, 2011 @04:07PM (#37134074)
    People tend to lump lots of things as if they were all the same thing, but they're really completely independent:

    Does the language run in a virtual machine, or is compiled down to native assembly in advance?
    Is memory management done explicitly, or is there a garbage collector?
    Does it allow direct access to memory (necessary for some parts of system programming)?
    Does it check for common errors, such as going past the ends of arrays?

    There are garbage collectors for C++. C# runs in a virtual machine, but still permits direct access to memory. STL collections in C++ check for out of bounds indices. So here is how I would categorize different languages, roughly ordered from "most native" to "most managed":

    C++: Incredibly complex, lots of bug opportunities, very verbose, very fast, suitable for system programming
    D: Some complex, some bug opportunities, some verbose, very fast, suitable for system programming
    Objective C: Some complex, some bug opportunities, some verbose, fast, suitable for system programming
    C#: Some complex, some bug opportunities, some verbose, fast, suitable for system programming
    Java: Some complex, some bug opportunities, some verbose, fast, not suitable for system programming
    Scala: Very complex, few bug opportunities, not at all verbose, fast, not suitable for system programming
    Python: Fairly simple, some bug opportunities, not at all verbose, slow, not suitable for system programming
  • by dmmiller2k ( 414630 ) <dmmiller2k.gmail@com> on Thursday August 18, 2011 @05:33PM (#37135320)

    ... to clean up non-memory resources like file handles, GDI handles, etc held within your objects.

    IMHO, it's easier to get this right using RAII with C++ than with any of the toy languages (e.g., Java, .NET), all of which require explicitly freeing, destroying, releasing (or whatever) resources from each and every code path that may exit a given scope.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...