Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

C++ 2011 and the Return of Native Code

Unknown Lamer posted about 3 years ago | from the natives-are-revolting dept.

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

cancel ×

616 comments

Sorry! There are no comments related to the filter you selected.

Fuck yeah, native code is in effect, BEEYYATCH!! (-1)

Anonymous Coward | about 3 years ago | (#37132690)

Time for a ROBOT BAR FIGHT! [youtube.com] It's on like Donkey Kong!

For learning (1)

mehrotra.akash (1539473) | about 3 years ago | (#37132716)

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

Re:For learning (1)

ccguy (1116865) | about 3 years ago | (#37132820)

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

Re:For learning (1)

mehrotra.akash (1539473) | about 3 years ago | (#37132882)

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

Re:For learning (1)

NoOneInParticular (221808) | about 3 years ago | (#37133116)

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

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

Re:For learning (2)

GooberToo (74388) | about 3 years ago | (#37133396)

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.

Re:For learning (1)

bberens (965711) | about 3 years ago | (#37133274)

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 (3, Insightful)

lgw (121541) | about 3 years ago | (#37133350)

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.

Re:For learning (1)

inasity_rules (1110095) | about 3 years ago | (#37133462)

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 (4, Insightful)

Moryath (553296) | about 3 years ago | (#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 (-1)

Anonymous Coward | about 3 years ago | (#37132946)

Yep, use the right fucking tool for the job. Sometimes it's your cock down her throat, sometimes it's your finger up her vag, sometimes it's your arm up his asshole (San Francisco!), sometimes it's a size 8 chrome butt plug up your asshole while you suck off a leather-clad twink.

This isn't auto mechanics! (-1)

Anonymous Coward | about 3 years ago | (#37133068)

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

We're talking about software - programming - NOT carpentry or auto mechanics.

Gimme an algorithm or any other job and I'll implement it in 'C' - I don't need no pussy language that makes parsing text easier (Perl) or web back ends easier (Python) or worry about the mythical write once run everywhere languages like Java.

If the hardware exists, there's a 'C' compiler for it or an assembler.

Face it, all these other OOP and procedural languages were written by dorks because they can - and to put on their resume that they wrote a language.

I'll think I'll use YACC and "write" my own language that just uses profanity and other vulgar language.

For example: x=2+2 would be "x shits 2 fucks 2".

Strings? pee like pee stream (string). Or to access an array would be "x suckme address[0]" (this moves the first element of address into 'x')

adresss PEE 20 (20 character string).

The interpreted version of it will be called Pussy and the compiled version will be called Homo.

Re:This isn't auto mechanics! (2)

Moryath (553296) | about 3 years ago | (#37133156)

Gimme an algorithm or any other job and I'll implement it in 'C' - I don't need no pussy language that makes parsing text easier (Perl) or web back ends easier (Python) or worry about the mythical write once run everywhere languages like Java.

And back in the day of the old PS2, every goddamn game development house started out their dev cycle by reimplementing mip-maps because it wasn't supported directly by the hardware. Fucking insanity. If there's a tool that has been developed for text parsing, and 99% of your program's functionality is text parsing, then use something that was DESIGNED FOR TEXT PARSING instead of having to reinvent the goddamn wheel.

Tools are made because they make life, or at least a specific task, easier. They should be used for that purpose. They should not be used for things they are not designed for. C++ was designed for low-level access to the hardware, which is fine if your program needs low-level access to the hardware, but it shouldn't be used for every task just as Java, or Perl, or Python, or any other tool shouldn't be used for things they weren't designed for.

Re:This isn't auto mechanics! (2)

smelch (1988698) | about 3 years ago | (#37133348)

Meanwhile, other people will actually ship on time and within their budget by not being a moron who thinks the only thing important in development is computational efficiency.

Re:For learning (3, Interesting)

GooberToo (74388) | about 3 years ago | (#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."

Re:For learning (1)

lehphyro (1465921) | about 3 years ago | (#37133378)

In the corporate world, the majority of programmers must use hardware provided by the company that follows strict guidelines about what can be used and that includes Windows-only for the most part. The majority of production deployments are on Linux machines, so there you have a heterogeneous environment where write-once, run-anywhere is necessary.

Re:For learning (1)

GooberToo (74388) | about 3 years ago | (#37133430)

Your contradicting several studies on the subject. I trust the studies. In your case, the studies clearly showed what you're depicting (at least at that time), is a by far a minority.

This may come as a shock to you, but believe it or not, there are large deployments of Windows servers with developers developing on Windows. Shocking - I know.

Re:For learning (1)

SuricouRaven (1897204) | about 3 years ago | (#37133480)

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/

Yikes (0)

XanC (644172) | about 3 years ago | (#37132726)

New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time? Just wait a couple more years and we won't be feeling the hardware pinch even on phones.

Re:Yikes (1)

Desler (1608317) | about 3 years ago | (#37132778)

Isn't this much better than expecting every programmer to perfectly manage his memory every time?

Yes, how dare we expect a programmer to realize the implications of the code they write! And if it's so hard, there are plenty of built-in features or features in libraries like Boost that will help you in making memory management less of a chore. Again as a counterpoint, just look how much code written in .NET has to implement IDisposable which if not done means that programmers will leak all sorts of non-memory resources such as file handles, etc. The fact of the matter is is that you still need to learn about memory management and if you don't you are still going to have memory leaks even in a managed language. Pretending the problem doesn't exist doesn't make it go away.

Re:Yikes (5, Informative)

CadentOrange (2429626) | about 3 years ago | (#37132804)

This keeps getting brought up, but I've written commercial C++ code for years and I've not had memory management issues. There have been problems with legacy 3rd party libraries, but if you religiously apply the RAII ( https://secure.wikimedia.org/wikipedia/en/wiki/RAII [wikimedia.org] ) idiom you will usually be fine. I can't remember the last time I worked with a raw pointer and had to new/delete my own memory.

Re:Yikes (1)

Desler (1608317) | about 3 years ago | (#37132842)

Yes, but you actually expect these people to understand C++? Most people like this probably don't realize that the C++ standard has had smart pointers to do automatic memory management for you for nearly a decade (and yes some of these still have issues with them which C++0x has addressed in many ways). Or ignore the boost libraries that provide smart pointers. The only time you really are doing manual memory management in C++ is when working with legacy code or if you are just pig ignorant of the features provided by the language or libraries like boost.

Re:Yikes (1)

Cutting_Crew (708624) | about 3 years ago | (#37132998)

what about if you want to use C++ within XCode? Without looking it up, does boost has libraries built for the mac environment so that Obj-C can communicate effectively?

Re:Yikes (0)

Desler (1608317) | about 3 years ago | (#37133048)

Yes, of course it does.

Re:Yikes (0)

Anonymous Coward | about 3 years ago | (#37133482)

what about if you want to use C++ within XCode? Without looking it up, does boost has libraries built for the mac environment so that Obj-C can communicate effectively?

It can communicate much more effectively than you.

Re:Yikes (2)

Joce640k (829181) | about 3 years ago | (#37133276)

Yep, I don't recall having memory management issues with C++ in the last ten years or so. Smart pointers take care of freeing RAM and the std::vector I use has bounds checking and extensive iterator checking turned on by default (even on operator[]).

Done properly C++ is as safe as Java, i.e. the only memory error is null pointer.

Java, OTOH has no stack unwinding for timely release of resources. Garbage collection is useless for anything other than RAM. Want a file or a network connection closed? You have to wrap it in a try...finally block and close it manually. Every single time, no way to automate it.

Then there's Java's brain-dead inheritance model. Get ready to do multiple inheritance manually by copying/pasting code from all the base classes. Cross your fingers that the interface never changes and you have to go and hunt down every last copy of it.

Want some "drudge"? Use Java.

Re:Yikes (2)

gbjbaanb (229885) | about 3 years ago | (#37132830)

The corollary of this is that you *need* super hardware to run the latest applications because they are so inefficient.

Instead of dumbing-down programming (which is a false economy anyway as poor devs write poor apps regardless of the ease-of-use of their programming environment), we should be increasing the skills of the developers. That means stopping from making things so easy that my manager can do it, still making a hash of it, only now thinking that any outsourced cheap developer can do my job!

Re:Yikes (5, Insightful)

AuMatar (183847) | about 3 years ago | (#37132856)

Yes, because managed code has no memory leaks. Please. I work on a mixed C++/Java Android codebase. I haven't found a memory leak on the C++ side in months. The Android framework decides to hold onto random references every new version.

Quite frankly, memory management is not hard. If you don't understand the simple idea of allocate, use, release, then you are a complete incompetent and should not be programming professionally. I'll go so far as to say it's better for a language NOT to automatically manage your memory- in general the first sign of a bad or failing architecture is that object life cycles and memory allocation start to be non-trivial. Managing your own memory catches those architecture bugs and leads to cleaner, easier to understand code. And the cost is absolutely minimal, I doubt I've spent 10 minutes in the past 2 or 3 years actually debugging memory problems in C++.

Re:Yikes (2)

Desler (1608317) | about 3 years ago | (#37132878)

Yes, because managed code has no memory leaks.

Yes, and managed code never has need for manual memory management [microsoft.com] . Oh wait...

Re:Yikes (1)

Tsingi (870990) | about 3 years ago | (#37133366)

Quite frankly, memory management is not hard.

No, it isn't. It sounds like magic in some of the messages here, but if you are creating classes/structs to do a certain thing, you know exactly how you want the memory to act. It's no biggie.

The only time you really need to manage memory is if you have objects that are liable to get extremely numerous, or get reallocated a lot. Which is exactly when you should be rolling up your sleeves and making it work exactly right anyway.

After all, there is a reason you went to a low level language in the first place. I wouldn't let my grandmother use Perl, but I use Python for most things, c/c++ when I feel the need for speed/power. (Java never, sorry, don't like it.)

Re:Yikes (2)

Joce640k (829181) | about 3 years ago | (#37133370)

I doubt I've spent 10 minutes in the past 2 or 3 years actually debugging memory problems in C++.

For a laugh I just searched for the word 'delete' in my current C++ project. There was a grand total of nine of them in 250,000 lines of code (and they were to define some new container classes).

There's no manual memory management anywhere in the rest of the code. Memory management in C++ is a myth perpetuated by C hackers who can't be bothered to educate themselves.

Re:Yikes (1)

Anrego (830717) | about 3 years ago | (#37133020)

Thing I've found with memory management is, that while it "just works" and you don't have to think of it for relatively straight forward stuff.. when you start getting into more complex OO designs, memory management actually becomes more of a pain in some situation!

Memory leaks in a managed language _are_ possible! When you start having references flying left and right.. you get into situations where two objects you are finished with are referencing each other (or themselves) and thus trick the garbage collector into keeping them around. Throw swing into the mix and the fun really starts. As a design gets more and more complicated.. you have to be very diligent (and practice good design) to ensure everything has a clean route to being dereferenced.

Compared to un-managed languages where you clean the memory yourself.. which is a pain in the ass for small, straight forward stuff.. but I've found takes a lot of the headache out of complex stuff (as backwards as that may seem).

Re:Yikes (0)

Anonymous Coward | about 3 years ago | (#37133328)

Java VMs can handle releasing objects that reference each other. the thing it does is beginning with the stack from each thread and follow references anything not found is eligble for collection.

Re:Yikes (1)

ShakaUVM (157947) | about 3 years ago | (#37133484)

>>Thing I've found with memory management is, that while it "just works" and you don't have to think of it for relatively straight forward stuff.. when you start getting into more complex OO designs, memory management actually becomes more of a pain in some situation!

Absolutely. When I tested some Java code, it ran correctly on all platforms except one obscure one (WinNT on SGI). On that platform, which was unfortunately something I had to support, it wouldn't unallocate memory correctly, it'd leak out of memory very quickly, and then run as slow as a dog as it swapped frantically.

I had to rewrite my damn code (which had nothing wrong with it) because Java's "write once run anywhere" motto is more or less a myth - when virtual machines are implemented differently, you *don't* have the guarantee of reliability and portability they promised.

Re:Yikes (1)

ka9dgx (72702) | about 3 years ago | (#37133024)

New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time?

So all that .net stuff is about garbage collection? Why not just have a standard way of letting the operating system take care of it in the background?

All this "managed code" seems to have resulted in is machines with a stack of complete ".net framework" versions numbered 1.0, 1.1, 2, 3, 3.5, and 4.

It would be nice to get rid of this multi-gigabye pile of bytecode, if it's all just to save a few K of ram here and there.

Re:Yikes (1)

Anonymous Coward | about 3 years ago | (#37133142)

Well, it's garbage collection, a metric fuckton of libraries at your disposal to make everything dead-simple and (honestly, if embarrassingly) the worlds greatest IDE.

Re:Yikes (1)

Desler (1608317) | about 3 years ago | (#37133172)

Well, it's garbage collection

Except for the cases when garbage collection will fail because you didn't implement IDisposable to manage the resources that the GC won't cleanup.

a metric fuckton of libraries at your disposal to make everything dead-simple

As opposed to the fuckton of libraries written for C and C++ programming?

and (honestly, if embarrassingly) the worlds greatest IDE.

Which can *gasp* be used to write C or C++ code as well.

Re:Yikes (1)

ka9dgx (72702) | about 3 years ago | (#37133422)

Ok,
    So it's half-assed garbage collection, 5 or so different metric tons of libraries (all incompatible), and an IDE?

What does the IDE have to do with the language?

Re:Yikes (1)

HaZardman27 (1521119) | about 3 years ago | (#37133260)

While this is true and can be very attractive, there has to be someone with native code experience to write the virtual machines, right?

Re:Yikes (1)

Unknown Lamer (78415) | about 3 years ago | (#37133320)

New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time? Just wait a couple more years and we won't be feeling the hardware pinch even on phones.

Personally I hope new machines start learning from the past [wikipedia.org] and implementing processor instructions to make GC easier and support things like runtime type checking. ARM has ThumbEE [arm.com] which is definitely a step in the right direction. Basically, I see the proliferation of "Managed" run time environments as a consequence of computer architectures remaining dangerous to write code for — we can pack a lot of transistors onto a die nowadays so why not use some of that space for features people have been implementing in software for decades?

Re:Yikes (1)

Artraze (600366) | about 3 years ago | (#37133454)

Memory management is a red herring; even managed application require it. Garbage collection will just hide poor application design and the inefficiencies that make it difficult. You can still crash on null pointers, leak references and most certainly leak external resources quite easily.

C++ just actually makes you actually have to think about these things. You actually have to pay attention to your allocations, scratch space, ownership, etc, and quite frankly applications are often better for it. Well.... were. These days you have devs that never learned how to actually design an app for a computer (basically read 'C') shoehorning their ill-advised classes and designs that worked so OK in Java, etc. into C++ and find that it doesn't work. I just love stuff like "new int[10]"...

Umm - mod article down (0)

Intron (870560) | about 3 years ago | (#37132730)

Author doesn't know the difference between languages intended for system programming and application programming.

Re:Umm - mod article down (1)

tomhudson (43916) | about 3 years ago | (#37132824)

c/c++ have always been perfectly useable for doing both system and application programming. And with the inevitable increased emphasis on energy efficiency, we're going to ask "how much energy can we save by converting [insert application of your choice] from a managed or interpreted language to a program compiled in c or c++?

For some large-scale applications, not only is it the best option, but the only option if you want to ever finish before the next [load of data/batch of requests] comes in.

Re:Umm - mod article down (1)

neokushan (932374) | about 3 years ago | (#37132886)

I presume you're referring to this:

Not that C++ really ever went away. With its older cousin C, it remains one of the most popular languages for systems programming and for applications that call for performance-intensive native code, such as 3D game engines.

I fail to see any problem with this statement, except perhaps that it implies that C++ was designed only for performance applications, when really it was designed to handle anything you throw at it (of course, other languages are better at certain things, meaning people will pick that language because of their needs, but no language is as good as C++ at absolutely everything) and handle it efficiently.

Never went away (5, Insightful)

i ate my neighbour (1756816) | about 3 years ago | (#37132738)

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

Then learn the language better, stupid (2)

Desler (1608317) | about 3 years ago | (#37132742)

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.

Re:Then learn the language better, stupid (2)

m50d (797211) | about 3 years ago | (#37132892)

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.

Re:Then learn the language better, stupid (0)

Desler (1608317) | about 3 years ago | (#37132916)

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.

Then maybe you need to look at shared_ptr from boost and the equivalent introduced in C++0x? The very classes designed for the situation you are talking about? Oh right, it's more fun to make ignorant comments!

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.

I can speak for .NET since all one has to do is do a simple Google search for IDisposable or read MSDN about it. If you do not manage your nonmanaged resources with IDisposable the GC will not clean it up and you will leak handles and with anything GUI related you will with enough time causes GDI exhaustion to happen.

Re:Then learn the language better, stupid (1)

roothog (635998) | about 3 years ago | (#37133192)

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.

Then maybe you need to look at shared_ptr from boost and the equivalent introduced in C++0x? The very classes designed for the situation you are talking about? Oh right, it's more fun to make ignorant comments!

You don't have that right, and you're probably writing code with memory leaks. From the Boost documentation: "Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed." You need to specially craft your cycle with a weak_ptr.

Re:Then learn the language better, stupid (0)

Desler (1608317) | about 3 years ago | (#37132938)

To quote from here [microsoft.com] :

The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.

So basically you are still having to manage your resources manually anyway or you are going to cause leaks. So what exactly am I gaining?

Re:Then learn the language better, stupid (1)

m50d (797211) | about 3 years ago | (#37133060)

Um, that you can only leak unmanaged resources, so you have an order of magnitude fewer possible leaks to worry about?

Re:Then learn the language better, stupid (0)

Desler (1608317) | about 3 years ago | (#37133080)

Um, that you can only leak unmanaged resources, so you have an order of magnitude fewer possible leaks to worry about?

If you are having an order more possible leaks in your C++ code, then you are doing it wrong and are most likely a shitty programmer.

Re:Then learn the language better, stupid (4, Informative)

Duhavid (677874) | about 3 years ago | (#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 ).

Why is C++ unmanaged? (2)

Billly Gates (198444) | about 3 years ago | (#37132746)

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.

Re:Why is C++ unmanaged? (2)

maxwell demon (590494) | about 3 years ago | (#37132850)

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

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

Re:Why is C++ unmanaged? (0)

Anonymous Coward | about 3 years ago | (#37132900)

Not true. I use Visual Studio 10 with Visual C++ and you can absolutely write native code using it.

Re:Why is C++ unmanaged? (0)

Anonymous Coward | about 3 years ago | (#37133242)

I believe he meant it's possible to write .Net code only when using Microsoft VS (and you can't write .Net stuff any other way).

Re:Why is C++ unmanaged? (1)

maxwell demon (590494) | about 3 years ago | (#37133268)

Nowhere did I say that you couldn't write native code with it. What I said is that only with MSVC++ (and not with other C++ compilers) you can use .NET.

Re:Why is C++ unmanaged? (4, Funny)

Anonymous Coward | about 3 years ago | (#37132904)

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

Re:Why is C++ unmanaged? (4, Interesting)

whiteboy86 (1930018) | about 3 years ago | (#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:Why is C++ unmanaged? (1)

GooberToo (74388) | about 3 years ago | (#37133298)

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.

Carmack (2, Informative)

bonch (38532) | about 3 years ago | (#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.

ARC (1)

Kostya (1146) | about 3 years ago | (#37132962)

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 follow some simple rules of thumb about giving ARC a hint about how you plan to use the Foundation object. I suspect that might get resolved later.

All in all, I am *very* impressed with ARC. It makes life so much easier, and it gets you almost all the advantages of GC--or at least all the ones that matter or people really use.

Re:Carmack (4, Insightful)

Jthon (595383) | about 3 years ago | (#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.

Re:Carmack (1)

lehphyro (1465921) | about 3 years ago | (#37133040)

From the JSR-139-CLDC (http://jcp.org/en/jsr/detail?id=139), hardware requirement: at least 32 kb of volatile memory. What were you saying about computing power catching up something again?

Re:Carmack (1)

Cutting_Crew (708624) | about 3 years ago | (#37133052)

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?

Re:Carmack (1)

WankersRevenge (452399) | about 3 years ago | (#37133410)

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.

Re:Carmack (1)

Cutting_Crew (708624) | about 3 years ago | (#37133492)

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?

Re:Carmack (0)

Anonymous Coward | about 3 years ago | (#37133234)

It's just like how Mirco Kernals were support to be the end all be all to the way operating systems were made.

False dichotomy (3, Interesting)

MrEricSir (398214) | about 3 years ago | (#37132758)

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

Re:False dichotomy (1)

EraserMouseMan (847479) | about 3 years ago | (#37132888)

Java is the only one of those 3 languages that uses a virtual machine. Not sure why you lumped C# in with Java.

Re:False dichotomy (3, Insightful)

fusiongyro (55524) | about 3 years ago | (#37132934)

Um, because it runs on the CLR in a fashion almost identical to Java on the JVM?

For me. (1)

drolli (522659) | about 3 years ago | (#37132802)

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

Re:For me. (0)

Desler (1608317) | about 3 years ago | (#37132810)

write guis in (preferably java or tcl).

Why would you write a GUI in Java? GUIs in Java look like shit.

Re:For me. (1)

daem0n1x (748565) | about 3 years ago | (#37132942)

The 90's called. They want their prejudice back.

Re:For me. (0)

Desler (1608317) | about 3 years ago | (#37133100)

Really? I didn't realize this tool [doom9.org] was written in the 90s. Coincidentally it isn't and yet still has the same shittiness of a Java GUI since the beginning.

Re:For me. (0)

Anonymous Coward | about 3 years ago | (#37133288)

You're a clueless idiot.

Re:For me. (1)

Short Circuit (52384) | about 3 years ago | (#37133394)

I coded for AWT and Swing in the 90s. The app you use to demonstrate looks a lot nicer than anything I recall seing use those toolkits back then.

Also, honestly, the app you link too looks like it has a reasonable UI for the role it performs. I would love to see current apps that work well for power users*, but which have "sleek" UIs. 90% of "good UI design" is moving 90% of advanced features and behaviors away from the first impression.

* read: "People who don't stop learning how to do the thing better"

Re:For me. (1)

JeremyMorgan (1428075) | about 3 years ago | (#37133036)

Agreed. Java GUIs always have a certain "look" to them you can spot right away.

Re:For me. (1)

SomeKDEUser (1243392) | about 3 years ago | (#37133118)

I agree. But tcl is even worse ;)

If you want GUIs and portability, there is no competition to Qt. It's Free, too.

Smart people know already... (5, Insightful)

giuseppemag (1100721) | about 3 years ago | (#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.

Re:Smart people know already... (0)

Anonymous Coward | about 3 years ago | (#37133324)

I would expect most big game producers stay away from C# because that would mean they can't use their code on a console. I'm pretty sure not even the xbox runs .net code

Native code for enterprises is stupid (0)

backslashdot (95548) | about 3 years ago | (#37132870)

General rule to be followed but not strictly:

If your code is to be maintained by junior programmers, then choose a managed code environment.
If you organization's primary business is not software production, then choose a managed code environment.
If your application is mainly implementing business logic, then choose a managed come environment.
If you are implementing a UI, then choose a dynamic language.

Only if none of the above apply should you choose native code.

Re:Native code for enterprises is stupid (1)

Short Circuit (52384) | about 3 years ago | (#37133474)

If your code is to be maintained by junior programmers, then choose a managed code environment.

With that one criterion, you may have completely struck those languages from candidacy for any project whatsoever.

All C and C++ programmers are "junior programmers" while they become proficient with the language, and nobody becomes a "senior programmer" without having learned from their own mistakes. You can't jump to C (or even C++) from languages like Python or PHP without undergoing a set of major paradigm shifts, and I'm not just talking about memory management.

One does not "simply walk into C++."

Looks like I was right (1)

MpVpRb (1423381) | about 3 years ago | (#37132872)

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

Doubt (1)

Lord Grey (463613) | about 3 years ago | (#37132874)

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 days of wrangling text data for the Web using CGI scripts written in C. On the other hand, shoehorning every application into the same interpreted language or managed code environment, irrespective of the task at hand, isn't the right way to go, either.

This is most certainly not news, but I find it refreshing to see the blindingly obvious repeated again. IT shops that "standardize" on one language (or framework, even) are simply zapping themselves with low-voltage-yet-eventually-lethal tasers. Managers, take note. Again.

Re:Doubt (1)

Short Circuit (52384) | about 3 years ago | (#37133496)

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

Slightly OT... I apologize... (1)

mark-t (151149) | about 3 years ago | (#37132896)

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.

Re:Slightly OT... I apologize... (1)

jejones (115979) | about 3 years ago | (#37133022)

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!

Re:Slightly OT... I apologize... (0)

Anonymous Coward | about 3 years ago | (#37133246)

The age of a decade is irrelevant since the last standard was from 2003 with only marginal changes as compared to the C++98.
Yes, Stroustrup is already working on an updated edition for quite a while now.

I'm sticking with mono (1)

cod3r_ (2031620) | about 3 years ago | (#37133114)

if C# goes down.. i'm going down with it

Re:I'm sticking with mono (1)

rubycodez (864176) | about 3 years ago | (#37133434)

maybe C# will be ok but Mono's future is in doubt, depends on Icaza's Xamarin company and however many developers he was able to get that were booted from Novell

Return of the script kiddies. (1)

malsbert (456063) | about 3 years ago | (#37133120)

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! :(

Re:Return of the script kiddies. (1)

Desler (1608317) | about 3 years ago | (#37133150)

That thinks memory management is something a real programmer is concerned about.

A real programmer would know how to use built-in language features in C++ to handle most of the load of memory management. The ones still having issues are most likely idiots who you should fire.

Doesn't have to be unsafe if native (3, Insightful)

Animats (122034) | about 3 years ago | (#37133140)

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.

It's funny! Laugh! (1)

Anonymous Coward | about 3 years ago | (#37133168)

I think it's funny that Stroustrup took one of the syntactically simplest computer languages, C, and turned it into one of the one of the most syntactically elaborate computer languages imaginable.

The only good thing is that you can ignore most of its esoteric features most of the time.

C++ IS FOR PUSSIES !! BRING BACK x64 ASSEMBLY(ER) (0)

Anonymous Coward | about 3 years ago | (#37133176)

And not the 32 bit shit, but pure adulterated porn-filled XXX 64-bit God-Loves-AMD assembly(er) !! Instant doubling of speed right there. So it takes 30 times long !! It is twice as FAST !!

Even thee, Slashdot? (0)

Anonymous Coward | about 3 years ago | (#37133186)

C++ is "native", huh? And here I was thinking I need a compiler for every platform I want to run it on. Silly rabbit.

exploits (1)

Anonymous Coward | about 3 years ago | (#37133208)

all I'm seeing in these comments is blah blah blah managed code memory management.

What about blah blah blah poorly written managed code doesn't expose remote code execution, while poorly written native code does.
Even almost perfect native code can expose massive security holes.

Exclusive to one language? D2 (1)

sgt scrub (869860) | about 3 years ago | (#37133460)

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 actual interface (ie. HTTPD and the browser. SMTP and the reader...). It doesn't matter what you write it in as long as it is fast and works in conjunction with some dynamic language. I like the additions 11 has brought to C++, regex, threads, pretty much anything boost has added. I'm using C++ today, despite not learning OO programing until I was in my 40's. As someone who has watched people fall in and out of love with languages I have to wonder why so little attention is payed to D2. Most of the additions to 11 are in D2. er I think. Did I mention I'm old?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>