Forgot your password?
typodupeerror
Programming

C++ 2011 and the Return of Native Code 616

Posted by Unknown Lamer
from the natives-are-revolting dept.
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:
  • For learning purposes, I find C++ to be a very good language.

    Its confusing enough that most people not up to it will leave once you cover the basics of pointers, yet not so difficult or complicated that it would take too long to learn.

    For instance, Java takes forever to understand as compared to C++, and no playing around with pointers either

    • by ccguy (1116865)

      For instance, Java takes forever to understand as compared to C++

      I can only find this to be true for people coming from certain backgrounds. I don't think anyone without previous programming experience would agree that C++ is easier to understand.
      Well, maybe it's easier to reach the point where one thinks he understand, then definitely easier to realize that nothing is actually understood even if somehow things worked :-)

      • To get into java you need a good understanding of OOP concepts and alteast basics of exception handling

        You can dive into C/C++ knowing maybe just the absolute basics of OOP, and learn as you progress

        Similarly, C++ gives you the opportunity to learn about memory management, overflows, errors you can encounter when not careful with types. Java handles all that for you

        • To get into java you need a good understanding of OOP concepts ...

          Yes, and then forget all about OOP, and learn Java.

          • by GooberToo (74388)

            Yes, and then forget all about OOP, and learn Java.

            You're both right.

            I tried to teach Java to my son. It quickly got stuck because of OO concepts. We went to Python. Life was good. And as you rightly point out, the OO taught by Java is crappy at best. If you really want OOP, Java isn't a good choice for that either.

      • by bberens (965711)
        I think most people view C++ as C with mystical object-y things. C (imho) is really easy to get. C++, that is, *real*, modern C++ is quite complex to use and isn't something "any decent programmer could read a book and understand it in a few weeks." Of course, I don't feel that way about Java either and it appears the /. crowd still views Java as a toy.
        • Re:For learning (Score:4, Insightful)

          by lgw (121541) on Thursday August 18, 2011 @02:22PM (#37133350) Journal

          I disagree about C being easier to get into. The stuff you do in toy programs, playing with strings and arrays and such, is difficult and alien in C if you've never seen pointers, or manual memory management. In C++ you can start with string and vector, and get toy programs working with just STL stuff, worry about pointers and memory leaks later on.

          • Depends if you're coming from native x86 assembly language or not...

            I did, and all those objects were a pain until I learned how to use them properly....

    • Re:For learning (Score:5, Insightful)

      by Moryath (553296) on Thursday August 18, 2011 @01:44PM (#37132822)

      The larger picture is fucking use the right tool for the job already.

      Java has its purposes. Write-once, Run-Almost-Anywhere is a good concept. Likewise, some of the other tools in other managed frameworks make certain things really simple.

      And when you need power and speed at the expense of having to do things a lot more exact yourself, then go to a language that'll work that way.

      The problem is not that one or the other is "bad." The problem is that too many programmers are golden-hammer morons who think their favorite tool is the only correct way to do everything on the goddamn planet, which is why you get Java applications running a chip on little mini kids games to do something that could have been done with a 5-cent microchip [xkcd.com].

      • Re:For learning (Score:4, Interesting)

        by GooberToo (74388) on Thursday August 18, 2011 @02: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."

        • There is always something that needs changing. For example, I recently wrote an experimental compression program. Everything is plain, common C. No libraries beyond the common ones. No use of OS-specific APIs. Nothing but stdio and stdlib. But it's still not going to run on windows without a minor change, because it tries to store a temporary file in /tmp/
  • Never went away (Score:5, Insightful)

    by i ate my neighbour (1756816) on Thursday August 18, 2011 @01:37PM (#37132738)

    Native was never away. It always has its place. It is just that performance/efficiency is not always top priority.

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

    So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain? It's not as if you don't still have to do memory management in say .NET especially since the IDisposable pattern is needed all over the place in user-written code to clean up non-memory resources like file handles, GDI handles, etc held within your objects.

    • by m50d (797211)

      So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain?

      Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.

      It's not as if you don't still have to do memory management in say .NET especially since the IDisposable pattern is needed all over the place in user-written code to clean up non-memory resources like file handles, GDI handles, etc held within your objects.

      I can't speak for .net, but in Java you have very little need for it. It's better to close your files and connections, but they'll be garbage-collected for you if you don't.

      • by Duhavid (677874) on Thursday August 18, 2011 @02:21PM (#37133316)

        I can speak for vb.net ( may be true in c#.net, not sure ), but you can leak memory as well as other resources.
        I bought into the "garbage collection handles it" mindset, until it was rudely pushed into my face that some UI elements have to have dispose called, or they stay in memory ( IIRC, forms will not collect, so incompetent programmers that put properties on their forms can come later and get those properties from the form after it is closed, other things like that ).

      • by Joce640k (829181)

        Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.

        If you're creating cycles then you didn't understand RAII. The objects in your cycle don't 'own' each other.

        If you're typing lots of angle brackets then maybe you need to learn about typedef.

        It's better to close your files and connections, but they'll be garbage-collected for you if you don't.

        You seem to be saying that after I save a file I have to wait for the garbage collector to run before I can open the file in another application or move it somewhere else on the disk. How will I know when the garbage collector has run (assuming it runs at all...)? Am I supposed to quit your application to force it to cl

      • and in java 7 with the try-with-resources it is handled for you.

      • by alexo (9335)

        I can't speak for .net, but in Java you have very little need for it. It's better to close your files and connections, but they'll be garbage-collected for you if you don't.

        Not according to the Java documentation [oracle.com]:

        Some applications interact with garbage collection by using finalization and weak/soft/phantom references. These features can create performance artifacts at the Java programming language level. An example of this is relying on finalization to close file descriptors, which makes an external resour

  • Last I checked you could use .NET in C++. So use .NET for the gui and networking frameworks and use C++ to do hardcore number crunching. Also there are native data structures in .NET and Java you can use in your program if you need performance. Most amature programmers never look in the math or collections libraries.

    • Last I checked you could use .NET in C++.

      No. You can use .NET only in MSVC++.

    • by Anonymous Coward on Thursday August 18, 2011 @01:52PM (#37132904)

      Managed C++ combines the streamlined elegance of native C++ with the high performance, execution stack transparency and platform/vendor flexibility of .NET.

    • by whiteboy86 (1930018) on Thursday August 18, 2011 @02: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.
      • by GooberToo (74388)

        You should look at the coding guidelines Google uses for C++. They only use a subset of C++. For them a of their guidelines make sense where they don't for 99% of the programming world. There is literally only a handful of companies which have the issues of scale Google must contend. As such, Google is rarely a good example to look at anything for general purpose computing.

        • Re: (Score:3, Informative)

          by Desler (1608317)

          You should look at the coding guidelines Google uses for C++.

          I don't recommend that. Anyone reading the Google coding guidelines will get a very wrong picture of how C++ is supposed to be done. Hell, their guidelines specifically disallow the use of RAII which is one of the dumbest things ever.

          • by GooberToo (74388)

            I don't recommend that.

            That was my point. I completely agree with you.

            I just had a falling out with another developer because he told me I was doing things dumbly because it didn't comply with Google's coding guidelines or Linus' irrational hatred of C++; amongst many other insanely stupid and completely irrational justifications. Of course, the falling out was caused by me politely explaining to him that coding standards have significantly progressed in the last several decades, followed by inviting him to join me. in at least t

    • Last I checked you could use .NET in C++. So use .NET for the gui and networking frameworks and use C++ to do hardcore number crunching. Also there are native data structures in .NET and Java you can use in your program if you need performance. Most amature programmers never look in the math or collections libraries.

      Managed C++ in MSVC is simply C#.
      Unmanaged C++ in MSVC is actual C++.

      As to the native data structures in .NET and Java - you incur performance penalties when you want to use them directly as you have to thunk back and forth between the managed and unmanaged portions of the system. I think Java is better about it than .NET, but its a pain nonetheless. It's easier, and more performance, to just stay in either unmanaged or managed code all the time.

  • Carmack (Score:3, Informative)

    by bonch (38532) * on Thursday August 18, 2011 @01:39PM (#37132754)

    Carmack remarked about this on his Twitter account today: "iOS did a lot to 'save' native code on mobile platforms. Prior, there was a sense that only Neanderthals didn’t want a VM."

    Apple is even backing down on Cocoa garbage collection with their new Automatic Reference Counting feature, in which the compiler determines object lifetimes and inserts the needed memory management calls. ARC will be the default for new Xcode projects. I think there was a hope that computing power would catch up and make VMs a competitive alternative to native code.

    • by Kostya (1146)

      With ARC, there really isn't a need for a garbage collector. I've used both, and the only things that happen in ARC that bite you are things that happen in Java, et al. I.e. you can still use a null pointer and such and get an error.

      The only place I have been truly surprised is that some of the Foundation stuff can perform weird or unexpectedly. That's more that ARC is fully Cocoa ready and that you need to tread carefully when using toll-free stuff. But then ARC warns you, and then you need to just fol

    • Re:Carmack (Score:5, Insightful)

      by Jthon (595383) on Thursday August 18, 2011 @02:01PM (#37133016)

      I think there was a hope that computing power would catch up and make VMs a competitive alternative to native code.

      While you're right there's a computing power issue here, the issue is battery life not lack of CPU cycles. VMs add overhead, as you add overhead you'll run longer and burn more power on the CPU. If you want to squeeze all you can out of a limited battery you need to optimize your code and in the end that's going to mean native code with very explicit memory management. VMs just don't play well in embedded environments.

    • i was under the impression that iOS tablets do not support garbage collection and that you had to manually use retain counts. Are you saying I will not need to use retain counts and rely on ARC instead?
      • As far as I understand, objects will still have their retain counts, but the compiler will analyze your code, then add the release calls for you. If you try and make your own release calls, you'll get a compiler error. Crazy stuff.
        • well last night i did have an Xcode4.1 update waiting for me in the app store - although i don't recall anything about this topic. Has this been pushed out already to XCode developers?
    • Apple really did 'save', but their own ass. We all remember iOS (iPhone OS at the time) with the web apps only, these were limited and terrible. Then the moment came when Jobs&Co. decided to release the real native SDK for iOS.. and from that point forward the iOS went batman.
    • by Joce640k (829181)

      Garbage collectors have some problems which can't be fixed:

      a) Garbage collection only works for RAM, it doesn't release resources like files, network connections, etc. in a timely fashion.

      b) When RAM is low and you start swapping to disk a garbage collector which scans/compacts the entire heap every few seconds will cause massive disk thrashing.

      Given that freeing resources is mostly a non-issue in C++, why would anybody want a garbage collector?

    • by harl (84412)
      <quote>I think there was a hope that computing power would catch up and make VMs a competitive alternative to native code.</quote>

      I've never understood this position. It always reads as, "Since we have more power we can be inefficient with it."
  • False dichotomy (Score:4, Interesting)

    by MrEricSir (398214) on Thursday August 18, 2011 @01: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.

    • Java is the only one of those 3 languages that uses a virtual machine. Not sure why you lumped C# in with Java.
    • I always quit learning Objective C because I think the syntax is ugly as hell. Smalltalk was also disgusting (especially those If constructs), and Erlang is one yucky language too (Erlangers acknowledge this and even tell you to suck it up on the homepage). One of the best thing C and C++ had is a somewhat aesthetical syntax (although there are messups like "=" and "=="). Pascal is really pleasant to read, and so is ALGOL (I've never programmed in it and I can understand it, although the "OD" is awkward). P

    • by sco08y (615665)

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

      Objective C doesn't have a runtime? I wonder why Apple decided to write a manual for it [apple.com].

  • Using native code was never something which contradicted using scripting languages (in my case: python, perl, matlab, tcl) or java. Mixing them in the right way does the trick.

    My approach was: use whatever tool is suitable. Write native what needs to be done native (and preferably use ANSI C for it), write guis in (preferably java or tcl).

  • by giuseppemag (1100721) <.giuseppemag. .at. .gmail.com.> on Thursday August 18, 2011 @01:48PM (#37132864)

    ...choose the tool that's best for the job, don't choose the job that's best for the tools you know already.

    Game developers, for instance, are among the guys who write the most performance sensitive code out there, and they use a mix of C, C++, C#, Lua/Python for the various parts of the game. Usually the inner, tight loop is written in C/C++, higher level modules are written in C# and designer/modder scripts are written in a very high level language such as Lua. There is no best language in general, and whoever says otherwise is often an idiot.

  • >>Modern programmers have increasingly turned away from native compilation

    Uh, not me.

    I never saw the benefit, only the pain.

    The so-called "managed" environments solved a problem I didn't have while adding complexity I didn't need.

  • I very much doubt that C++11 heralds any kind of new interest in native code. Rather, native code in general has been getting more attention recently and C++11 just happened to be finalized around the same time. (Disclaimer: C++ is my second-favorite language. I want it to be liked and used, but I'm realistic.)

    Nearly off-topic in the article is this gem of a paragraph:

    But the most important thing to remember is to always choose the right tool for the job. No one wants to go back to the bad old day

    • (Disclaimer: C++ is my second-favorite language. I want it to be liked and used, but I'm realistic.)

      I'm curious. What's your favorite?

  • But does anyone know if or when there's going to be a book (you know, one of those paper things that you physically hold in your hands and actually have to turn pages to read instead of looking glaze-eyed into the glow of a computer monitor) that covers C++11 fairly exhuastively, such as how, for comparison, Stroustrup's "C++ Programming Language" covered the previous standardized version relatively thoroughly?

    Thanks.

    • by jejones (115979)

      There probably will be a dead tree book--but I seriously doubt that you will be able to physically hold it in your hands for a significant interval unless you're a world-class bodybuilder. Note that the special edition of The C++ Programming Language is over 1,000 pages, and it's over a decade old!

  • C++ got a very bad reputation, Do to the helpless little script kiddies, That thinks memory management is something a real programmer is concerned about. And now you tell me that; these dime a' dozen script kiddies are coming back! ARGH! :(

  • by Animats (122034) on Thursday August 18, 2011 @02:08PM (#37133140) Homepage

    The article perpetuates the myth that native code has to be "unsafe". That's an artifact of C and C++. It's not true of Pascal, Ada, Modula, Delphi, Eiffel, Erlang, or Go.

    Nor does subscript and pointer checking have to be expensive. Usually, it can be hoisted out of loops and checked once. Or, for many FOR loops, zero times, if the upper bound is derived from the array size.

    One of the sad facts of programming is that there should have been a replacement for C/C++ by now. But nothing ever overcame the legacy code base of the UNIX/Linux world. Every day, millions of programs crash and millions of compromised machines have security breaches because of this.

    • by master_p (608214)

      The crashes are solely due to using C++ as C, i.e. manual memory management, C casts, pointer arithmetic and C arrays. If none of the C features are used, then C++ is as safe as the languages you mention.

  • Is there anyone these days writing applications in one language in exclusion to any other? I'm feeling old. I wrote applications in ASM because it was exclusive. Then I wrote applications in Fortran because it was easy. Then basica because it was way easer. Then Pascal because it was the shiznit. But then applications became more complex because of these GUI things and stuff. That is when the OO languages like C++ kicked ass. Now days it is so "normal" to write something that communicates with the a

  • ... never distinguished between "native" and "managed" code.

    Write the damn code according to the rules and idioms of the language in use, let the language implementation deal with the rest. If you're an application developer and care about *how* your code is being run, you're doing it wrong.

  • by SoftwareArtist (1472499) on Thursday August 18, 2011 @03: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

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Working...