C++ 2011 and the Return of Native Code

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

Comments

For learning

[mehrotra.akash]

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

[ccguy]

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

[Moryath]

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.

Re:For learning

[mehrotra.akash]

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

[NoOneInParticular]

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

[GooberToo]

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

[bberens]

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

[lgw]

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

[lehphyro]

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

[GooberToo]

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

[GooberToo]

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

[inasity_rules]

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

[SuricouRaven]

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/

Re:For learning

[GooberToo]

Which entirely validates my point. And "always" is not true. The simple fact is, if you design and code with portability in mind, its just as easy to do so with C/C++ as it is with Java. And if you fail to do so, its the same like-minded changes required in either case.

Re:For learning

[Anonymous Coward]

But it's still not going to run on windows without a minor change, because it tries to store a temporary file in /tmp/

Lack of cross-platform portability in that case is a failure of the programmer, not the language. The stdio functions tmpfile() and tmpnam() are designed explicitly for that purpose.

Re:For learning

[lgw]

Sure,of course. But how many people in the wide world learn assembly coding first in this day and age? The world has changed, and most people start with Facebook apps or some such nonsense.

Re:For learning

[Lord_Naikon]

You're simplifying things. Most importantly Java has actually all the tools necessary to communicate with the operating system while C/C++ have almost none of them (for instance networking, graphics are missing). Plain C/C++ is not usable as a cross development platform _unless_ you restrict yourself to only use portable (3rd party) libraries. On the other hand, 99% of the Java libraries out there are already completely portable, so every Java program in Java can be made portable with a minimum of changes even if it wasn't designed for that initially, or in simple cases will just work out of the box.

So I wouldn't say it is as easy in C/C++ as in Java. This has obviously more to do with the standard libraries than the language itself.

Re:For learning

[GooberToo]

I'm not simplifying anything. You're simply not doing an apples to apples comparison. In an apples to apples comparison, I'm spot on.

The simple fact of the matter is, writing portable application code in C++ is no harder than is doing the same in Java.

Re:For learning

[inasity_rules]

Electronic engineering students. While C++ is taking over the world, I know of at least one course where understanding microprocessor design (let alone assembly language) is a requirement. Unless the course has changes in the short 2 years since I took it...

Re:For learning

[Lord_Naikon]

Unless your "application" consists only of business logic that is simply not true. You must interface with the real world. You can do that in Java by default. In C++ you must find non standard libaries who can do that for you. That is definitely more work and so it is not as easy in Java.

Re:For learning

[Anonymous Coward]

I've been developing enterprise Java software since it was possible to do so (coming up on 15 years now), and usually develop on Windows and deploy to *nix, as do most all the developers I've worked with, so that's completely false.

And I hope you're not saying that developing C++ apps can be done in anywhere as fast as equivalent Java apps, because that's just laughable.

Re:For learning

[Anonymous Coward]

When you manage to run a java application using SOAP on ARM7, come and let me give you $1000. I am serious.

Re:For learning

[Lord_Naikon]

*as easy _as_ in Java. :-).

I'd like to add that the added cost in C/C++ is because of the need to port 3rd party libraries, not your own software because that was obviously designed with portability in mind!

Re:For learning

[JonySuede]

Java started into the microchip. When I was in college around 1995 in a course named "New technology in Automated System", we programmed some 68HC11 with a VM from a vendor I don't remember and a compiler from sun named OAK.

Re:For learning

[GooberToo]

Not surprisingly you posted anonymously.

The fact I have to point out the plural of anecdote is not data. You then compound your stupidity with a completely unrelated, red herring troll.

Re:For learning

[nschubach]

Isn't that what environment variables are for?

Re:For learning

[GooberToo]

What planet are your from? You mean those non-standard libraries which are almost always written in C/C++/Fortran, all of which can be directly used from C/C++. And perhaps you have no clue what you're talking about or being extremely sarcastic, but interfacing to the real world is almost always error prone, slow, difficult to debug, and a major, major pain in the ass. This reason alone is one of the reasons why so many prefer Python+C/C++/libs rather than Java.

Re:For learning

[GooberToo]

There are endless C/C++ libraries designed with portability in mind. These days, creating portable C++ code is as easily as Java. And where its not, they both suffer from the same types of developer stupidity and short sightedness.

Re:For learning

[Lord_Naikon]

Why is it so hard to understand that Java, a language DESIGNED for portabilty, is more suitable for cross platform development than C++? You can throw any number of well designed cross platform C++ libraries at C++, it is still NOT part of the language, not part of the standard development platform and therefore it is harder to do cross platform C++ development than in Java. I can not comprehend why you think otherwise. Yes, the disparity in cross platform developement ease between the two may slowly fade in time, especially in the light of the new C++ release which makes a lot of features that you need from an API standard (threads for instance), but to say they are on par is simply an outrageous claim and definitely not a "simple fact".

Allow me to demonstrate some practical problems with C/C++ cross development between Windows & Unix)
- Non standard build system (make / vc++), different systems used for different libraries.
- Different linking process (.so vs .dll/.lib)
- Wildly differing implementations of the standard C library (stdio in VC++ is severely broken).
- No network API, so we will have to deal with either manual compatibily shims (more work) or 3rd party library (more work)
- No GUI API, same as above

The uniformity in Java is what makes cross platform development such an easy task:
- Everything is .JAR, build tools the same for all platforms (granted, you still need a Make equivalent, say ant, but the result of the build process is portable)
- Linking is just throwing a bunch of JARs together
- There is only one implementation of the standard library that everyone uses.
- Network API is standard
- GUI API is standard.

Now please enlighten me how exactly C++ crossplatform development is just as easy as in Java.

Re:For learning

[Anonymous Coward]

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

I honestly don't mean this as an insult, but it probably seems that way because you don't use much C++. I don't know of anything in Java as advanced or complex as partial template specialization, template metaprogramming, preprocessor metaprogramming, the interesting intersection of template and preprocessor metaprogramming, type-punning legally with unions, or the use of virtual inheritance to resolve diamond problems in multiply-inheriting hierarchies.

And yes, I am a professional C++ dev, and yes my codebase does in fact include all of these language features. Java was explicitly designed to be a less complicated C++. I understand and agree with the argument that it is simple to learn "enough" C++, but of all the languages I've ever known, C++ most magnifies the gap between novices and advanced users.

Re:For learning

[Z00L00K]

Personally I would say that C++ is a lot more cryptic than Java, even though I'm very familiar with C.

But for native coding I would say that it may be useful to look at other languages too - like Fortran.

Re:For learning

[Alef]

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.

I would rather say about the opposite -- C++ is far down the list of languages I recommend to people that want to start learning programming. I've learnt most programming languages that I use myself in a matter of days or weeks, but it took me several years to master the ins and outs of C++. And you really need to know it well to avoid shooting yourself in the foot all the time.

C++ is a very powerful and useful language, and I like the possibility to get zero runtime cost abstractions, but were it designed today it would be a very different language. The meta-programming features for example could most appropriately be described as "design by accident".

Re:For learning

[luis_a_espinal]

What planet are your from? You mean those non-standard libraries which are almost always written in C/C++/Fortran, all of which can be directly used from C/C++. And perhaps you have no clue what you're talking about or being extremely sarcastic, but interfacing to the real world is almost always error prone, slow, difficult to debug, and a major, major pain in the ass. This reason alone is one of the reasons why so many prefer Python+C/C++/libs rather than Java.

Examples please.

Re:For learning

[Cryacin]

You haven't worked in banking, have you?

Re:For learning

[mwvdlee]

Having started out with C++, I found Java quite easy to learn. In fact most languages are pretty easy compared to C++ (mind you, I'm not talking about messy API's which seem to be rampant in modern languages).
The difficulty with C++ is that it can do a lot more than most languages, some of it very weird and complex.
Stuff like multiple inheritance, partial template specialization, overloading, the curiously recurring template pattern and ofcourse the turing-complete preprocessor are just some of the features that make some... "unconventional" programming techniques possible, not counting the low-level stuff inherited from C.

Re:For learning

[mwvdlee]

The problem here is that mixing different languages is a bit difficult.
It would be great if you could do UI stuff in some high-level language like Java, C# or VB and do the heavy problem-solving stuff in ASM, C/C++ or Fortran.
It's not impossible to mix languages, but it's certainly not made easy.

Re:For learning

[mwvdlee]

Only few of these (http://www.top500.org/list/2011/06/100) run on Windows.
I guess it depends on the definition of "large" ;)
There's quite a difference between small companies with only a few dozen servers, to a few hundred, several thousand and real large deployments beyond that.
It also depends on the definition of "server". I've developed for z/OS, Himalaya and AIX systems in the past, none of which could be even remotely matched by Windows servers at the time. Windows has dramatically improved on servers since then, but I doubt it's grown to the level where it can compete with big-iron. If we're only talking about webservers or small business servers, Windows definitely has a significant precence in that area.

Re:For learning

[badboy_tw2002]

They take that before a CS101 class? Seems like almost every engineering program has that in its first semester these days.

Re:For learning

[BeforeCoffee]

Your trolling is legendary, sir, you've won and now I'm responding.

Java's better than C++. It's more popular. It's better looking. It's more important.

That's not gloating, that's not religion, it's just the market who decided that years ago. You can get angry about it. Fight it if you want. But at the rate you're going with the smug dismissals, you're not gaining any converts.

I'm going to paste all of Lord_Naikon's retort, as what he said is just the tip of the Java iceberg:

Why is it so hard to understand that Java, a language DESIGNED for portabilty, is more suitable for cross platform development than C++? You can throw any number of well designed cross platform C++ libraries at C++, it is still NOT part of the language, not part of the standard development platform and therefore it is harder to do cross platform C++ development than in Java. I can not comprehend why you think otherwise. Yes, the disparity in cross platform developement ease between the two may slowly fade in time, especially in the light of the new C++ release which makes a lot of features that you need from an API standard (threads for instance), but to say they are on par is simply an outrageous claim and definitely not a "simple fact".

Allow me to demonstrate some practical problems with C/C++ cross development between Windows & Unix)
- Non standard build system (make / vc++), different systems used for different libraries.
- Different linking process (.so vs .dll/.lib)
- Wildly differing implementations of the standard C library (stdio in VC++ is severely broken).
- No network API, so we will have to deal with either manual compatibily shims (more work) or 3rd party library (more work)
- No GUI API, same as above

The uniformity in Java is what makes cross platform development such an easy task:
- Everything is .JAR, build tools the same for all platforms (granted, you still need a Make equivalent, say ant, but the result of the build process is portable)
- Linking is just throwing a bunch of JARs together
- There is only one implementation of the standard library that everyone uses.
- Network API is standard
- GUI API is standard.

Now please enlighten me how exactly C++ crossplatform development is just as easy as in Java.

I tried to write a cross-platform C++ open source library once and be one of the good guys in your book. You know what a treacherous, expensive, and painful process that was? All the compilers did templates differently, it was a delicate dance on fiery coals to get my code working for all my users on all platforms.

The best cross-platform build system I could find at the time should give a clue on just how shallow the C++ ecosystem is: java running ant with a C++ compiler exec helper plugin. The C/C++ community couldn't even offer me one decent cross-platform build system that didn't require a master's degree to run. There's nothing there there in the C++ world, no promotion nor adherence to any standards.

Where's C++'s TCK? Where's its JCP? I know you don't care about those things, but I thought I might ask!

Re:For learning

[SplashMyBandit]

I disagree (after using C++ for a decade and Java for another decade). Try writing any large multi-threaded, networked program in C++ and spend as much time on the configuration management as when doing the same in Java. Basically in C++ you can't, you spend time buggering around with your Makefiles and libraries (assuming you can use g++ everywhere, otherwise you have to also frig around with compiler options and the interpretation of C++ that each compiler has). C++ just ain't portable; ain't friendly when used in large teams/very large projects; ain't fast to compile; ain't fast to build large systems in. C++ does have advantages to Java in some respects (very low memory footprint, deterministic memory management for non-threaded programs etc), it just turns our portability is not one of them.

Re:For learning

[tompaulco]

In my case, I learned C and C++ back when Java was an island in Indonesia. C was very natural to pick up. C++ I never really got the hang of, and just did what I needed to get by. Then for a long time, I did no programming at all. When I came back to programming, I learned Java, and the OO principles that seemed so unintuitive in C++ suddenly made sense because I was not trying to learn OO and a tricky language at the same time. So much so, in fact, that I recently have taken up C++ again, and this time around, it is making a great deal more sense.
In tune with the article, we use C++ because we use OCR, which is a processor dependent task, and the C++ libraries are much faster than a java implementation would be. Our main application, though, is in Java, so I have written a JNI wrapper to control the C++ code that I wrote to interface directly with the engine.

Re:For learning

[cowboy76Spain]

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

I find this affirmation akin to teaching mountain climbing and saying "If you start practicing on Mt. Everest instead on the small hill outside town, you will learn the basics and to deal with ice walls and frostbite and lack of oxygen... if you do not die while doing it". A learner should not have extra challenges, he should have less challenge so he can move forward.

Now you can argue that Java extensive API is also challenging and feel that something else is better, but C++? Never in life.

Re:For learning

[c0lo]

Try writing any large multi-threaded, networked program in C++ and spend as much time on the configuration management as when doing the same in Java.

For writing: things slowly change, see Boost.

For makefiles or whatnot: if your project is indeed complex, the economy of time will still show a very small percentage being directed in makefiles (as you noted, with most of the time will be spent in compilation).

Other than that, yes, I agree, C++ doesn't yet have the edge of cross-platform portability (and, at the rate the C++ standardization committee works, I lost hopes that I'll see it during my lifetime. Maybe my grandchildren?)

Re:For learning

[tompaulco]

Hmm, my memory is fuzzy, but I think we had Fortran and Pascal first year, and then assembly second year, along with a Programming Language Design class in which we learned about two languages a week, and another class where we had about two weeks of C inexplicably stuck at the end of a hardware architecture class, and an assembly for microcontrollers class, which was fun.
By the third year, you were expected to either already know all the languages (including C,of which you had had two weeks) that you needed, or be clever enough to figure it out as you went. Thanks to that second year, learning to learn was very well ingrained, so when they through Pspice or some other application specific scripting language at you, you were able to get by,

Re:For learning

[Anonymous Coward]

Maybe for programmers that suck and run their production software on Windows. Those are also the type of programmers who have enough free time to fill out those surveys.

We'd be laughed at if we ran our production site on Windows by our clients (brokerages/investment firms). Solaris FTW in this scenario.

Yet, we code on Windows due mainly to the convenience of available tooling

Re:For learning

[c0lo]

The problem here is that mixing different languages is a bit difficult. It would be great if you could do UI stuff in some high-level language like Java, C# or VB and do the heavy problem-solving stuff in ASM, C/C++ or Fortran.

Spot on! The very reason I started to learn Java about 12 years ago: the UI stuff. Boy, even now I can't be bothered again with MFC or widgets.

It's not impossible to mix languages, but it's certainly not made easy.

For my own experience: JNI takes about 1-2 days to understand and 1-2 months to adjust your mind and habits in using it. I'd say, not that hard either. (see also JNA)

Re:For learning

[c0lo]

Personally I would say that C++ is a lot more cryptic than Java, even though I'm very familiar with C.

But for native coding I would say that it may be useful to look at other languages too - like Fortran.

Doing a fair bit of Fortran in the past, I'm seeing no reason to do it if you come from a C++ background - the compiled C++ will be equally fast as a compiled Fortran that expresses the same computations.

Re:For learning

[ObsessiveMathsFreak]

and get toy programs working with just STL stuff, worry about pointers and memory leaks later on.

But by then it will be far too late!

Re:For learning

[Anonymous Coward]

Every language has it's beauty and dark side. Or to rephrase it, C++ has just as much crap in it's latest language specification as e.g. Java.
The only thing that most people seem to have forgotten is that all the fancy language constructs and bloated features do come at a cost.
The amount of crap a compiler spits out for just a simple task is just amazing these days.
When approached for an interesting position at software company for investment bank software I got the honest reply that 'it was so convenient to use the internal C# compiler for evaluating fields with arithmetic input' on their high performance platform.

Re:For learning

[antifoidulus]

But as a tradeoff you have to deal with infinitely more complicated syntax, an incoherent mish-mash of ideas, and perhaps the most (imo needlessly) complicated programming language on the planet.

The great thing about C++ is that it incorporates a lot of good ideas, the shitty thing about C++ is that it incorporates a lot of bad ideas. C++ is the CORBA of the programming languages world, a noble idea that got corrupted by trying to satisfy everyone by taking a union of features.

C certainly has its faults(its 2011 god damnit, standardize #pragma once...I hate fucking header guards!), but at least it is more coherent than C++.

My recommendation is to teach students any language BUT C++.

Re:For learning

[ConceptJunkie]

This explains the trend I've noticed of more and more Java apps simply being distributed with their own JREs. It's gotten pretty ridiculous really. "Write Once, Run Almost Anywhere But Only On The Exact Same Version of the JRE" is closer to the truth.

Re:For learning

[murdocj]

I strongly disagree. In C you can "see" what is going on. In C++ you have ALL the same problems as in C, plus many more cute little traps (default assignment operators, etc). The traps are carefully hidden away under the covers, but they are still there. For example, what C++ laughingly calls a reference isn't what anyone else would call a reference, it's a pointer with a little syntactic sugar layered on top, and it can become invalid, just a like a pointer can become invalid. And don't get me started on templates...

Re:For learning

[siride]

The .NET languages are probably the best for native integration (certainly better than Perl, shudder). Sure, there are warts (just look at this Mono description of the problem: http://www.mono-project.com/Interop_with_Native_Libraries), but a lot of the problems are on the part of the platform developers, not the end developers. If you are calling C functions from C#, it's really quite trivial. You write your C function like usual and then you put a "public static extern void foo(int x);" declaration in some C# class with a DllImport attribute and you are pretty much done. You can call it in C# like a normal C# function and in C it acts like a normal C function. It's only weird if you want to be able to use managed types in C, in which case you have to jump through some hoops.

Re:For learning

[HornWumpus]

More or less the same as my experience. We got assembly for microcontrollers rolled into digital control systems, one day in class, 'here is the manual', assumed you would figure it out. By then you'd had a year of assembly and processor design theory. Only crossover to CS was later and optional. Data structures and discreet math courses IIRC, GPA padding. CS students didn't like us.

Re:For learning

[shutdown -p now]

Pretty much no one uses "C++ by itself" in practice. Normally it's C++ and Qt, or C++ and Boost etc. These cover much of the same ground as Java libraries, and take at most half an hour extra to integrate with your build process.

You can reuse build systems between platforms. GNU make runs on Windows and can just as well exec cl.exe. And you can use Mono's XMake on Unix.

What's wrong with VC++ stdio?

Re:For learning

[armanox]

You didn't go to Capitol College, did you? They require microprocessors and assembly (M68K IIRC) for quite a bit of the majors (including some CS related ones).

Re:For learning

[kmoser]

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

Easy to say, but not so easy to do when you're either hamstrung by corporate policy or entrenched systems that you can't change due to politics or money.

Re:For learning

[inasity_rules]

As it happens, no. I went to university in Africa. We did a lot of stuff from the fancy 32bit pics, to the humble 6800. And we had to design every part of the one in logic gates..., but thankfully not build it. It was fun though.

Re:For learning

[Anonymous Coward]

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

This is STILL better than in the early days of Java, when the JVMs weren't as solid, and the situation could best be described as "write-once, debug-everywhere".

Re:For learning

[Anonymous Coward]

Java for Windows works on Wine, and I'd rather disassemble and patch a Java binary then have to do the same for assembly language...

Re:For learning

[Lord_Naikon]

Yes, I agree with you, and I too use Qt and boost to ease porting. It's still not as easy as Java though :P

What's wrong with VC++ stdio?

_snprintf() and _vsnprintf() do not conform to the C99 standard: they do not guarantee NUL termination of the buffer while they should and return the wrong value if the buffer was too small. The former was a mistake of epic proportions if you ask me.
Microsoft tried to fix that with the non-standard _snprintf_s() and _vsnprintf_s() but these still return the wrong value in case of a buffer overrun.
I guess they prefix everything with _ because they are unable to implement conforming procedures.

Re:For learning

[Meski]

THe way half the class didn't understand what pointers were. And the other half were in awe at what they could do with them.

Re:For learning

[Lord_Jeremy]

This is why I love developing in Objective-C (for iOS and OS X). The application I just finished writing is effectively a USB HID interface written in C (using the CoreFoundation framework) with a simple window-based GUI that I whipped up in Objective-C (Foundation framework). The Apple Objective-C model is designed so that the CoreFoundation (pure C) types and API calls are almost entirely compatible with the Foundation (Objective-C) stuff. This makes it incredibly easy to merge C underpinnings with Cocoa/UIKit and the other Mac OS X/iOS-specific Objective-C user interface libraries.

Re:For learning

[Xest]

I don't think that's really a fair comment, because there are also plenty of places where Java has succesfully been used in a cross platform way with no need for modification. But it really just goes back to what the GP was saying - use the right tool for the job, and the fact that Java has failed in it's original goals in a lot of cases merely reiterates that perhaps Java wasn't the right tool for the job in those cases. I thinkt he GP is right and that's that it IS a good concept, but it's not a perfect concept, and it doesn't work universally, but that doesn't mean it isn't the right tool for the job still in some scenarios.

I understand your point in your final paragraph, but I think something needs to be clarified to people who may misinterpret it. Java has other advantages too- better security by default, and easier to produce software with a lower amount of defects like memory leaks. Not to mention that development is inherently faster when you don't have to worry about some things like memory management. If all you're doing is a simple UI front end to access a database then Java really is the right tool for the job, because you'll get it done quicker, safer, with less potential problems than with C++ - and such an application likely will be at least Windows/Linux cross platform to boot.

Really it just goes right back to what the GP was saying- use the right tool for the job, with the only caveat arising from your comment being, that all too often people have used Java where it probably wasn't the right tool for the job, not that Java isn't sometimes the right tool for the job, which was the GPs point.

Re:For learning

[Anonymous Coward]

Not to mention that it has little to with cross-platform. Hardcoded /tmp is just wrong even on Linux/Unix.
I've been cursing more that a few times programs that failed to use the proper temp dir (/tmp can be noexec which might not work for the program, or it might simply temporarily be unavailable or ...).

Re:For learning

[Anonymous Coward]

Uh, with how many compilers and runtimes did you try to run your Java program?
Back when I tried it more than half the Java programs wouldn't work with gcj, about 1 in 4 wouldn't work with IBM's Java implementation.
If you want to use different, incompatible compilers for C++, well that's kind of your choice, you could make the same choice for Java (though you would have less of a choice, however I can't see that speaking for Java much).
And GNU make is rather universal and simple really. Though cmake might be a bit fancier/nicer.
There's also scons for those who like Python for that kind of stuff, though I'd avoid it.
Though I also found ant rather unpleasant compared to make, so honestly I think most people are just unwilling and find it painful to use a build system they aren't used to.

Re:For learning

[tehcyder]

Electronic engineering students. While C++ is taking over the world, I know of at least one course where understanding microprocessor design (let alone assembly language) is a requirement. Unless the course has changes in the short 2 years since I took it...

I think that is one of those cases where the exception proves the rule.

It's like saying that not many humanities graduates know Latin and Ancient Greek these days, and being told that there are people who study Classics in the original languages. Well, yes...

Re:For learning

[Pragmatix]

This reminds me of a client I had where the in-house developer was unhappy with my choice to remove his homegrown database abstraction middle-ware from a simple internal application I was tasked with enhancing. I added a ton of new features and cut down the code base by about 80%, but all I ever heard from him is "but what if we decide to switch to ORACLE?!?"

Re:For learning

[GooberToo]

Did you know time moves linearly forward? Obviously not since you posted.

Re:For learning

[GooberToo]

Holy shit you're stupid. No joke. Pull your head from your ass and take a look around you. JAVA itself is NOT fucking written in Java. Ponder that for a second while you're pulling your head from your ass.

Holy shit people on /. are stupid.

Re:For learning

[GooberToo]

Perhaps you should learn about programming in C++ and then you'll have what is an extremely obvious answer. The fact you have to ask and worst, wrote such a long post to what is obvious, says a lot.

Re:For learning

[b4dc0d3r]

The biggest difference is C++ typically uses a different compiler on a different system. I started playing with Java when I took a week off from work, and I was surprised that I didn't have compiler errors, missing libraries, and all the usual problems.

When I download a C++ project, I usually cringe and fire up a browser so I can resolve the ensuing pile of error messages just to get the code built. With this project, I just downloaded the code, used the JDK I already had, installed ant, and it worked the first time. That has only happened 3 times with C++ over the past 15 years for me. I agree one example is not a good study, but you can't argue that even the most widely used C++ compilers will accept just about every project out there.

My point is, if the code is cross platform, you don't have to fight the compiler. Yes, Java does have its own quirks about having libraries available and such, but if you have to modify the code to get it working something is seriously wrong.

Re:For learning

[shutdown -p now]

That is kinda by design in a sense that VC++ simply does not support C99, and is never advertised as such - it is strictly a C90 and C++03 (with bits of C++11) compiler. Hence underscores - the general rule for the standard library is that if a function is not defined in some standard that is explicitly implemented, it is underscored to highlight non-portability and/or non-standard behavior.

Unfortunately, TR 24731 does not properly define anything like snprintf_s, but only the rather pointless sprintf_s.

Re:For learning

[Anonymous Coward]

++

Re:For learning

[purpledinoz]

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.

So what? If you don't require the performance of C++, there is nothing wrong with writing software in Java. Having garbage collection on your side makes things easier, which means faster development times, which means lower costs.

Re:For learning

[jeremyp]

Microsoft C does not claim to be C99 compliant and it probably never will be. They more or less gave up at C89 to concentrate on C++

Re:For learning

[Bengie]

I find a "back and forth" between high and low level has helped me.

Issue 1) Harder to write good low level code unless you can see the big picture
Issue 2) Harder to create a good design(aka big picture) unless you know how things work on the low level

Chicken and the Egg issue.

Solution, Get experience in both areas

Re:For learning

[zeroshade]

Unless you're dealing with high levels of scientific calculations and massive amounts of math, C/C++ will always be better than Fortran. Surprisingly, many math libraries for Fortran are faster than their equivalents in C/C++.

Re:For learning

[polymeris]

..._unless_ you restrict yourself to only use portable (3rd party) libraries. On the other hand, 99% of the Java libraries out there are already completely portable...

I suspect the number of portable C/C++ libraries exceeds the total number of Java libraries, though.

Qt alone, covers most of what the standard Java libs do, for example.

Re:For learning

[Anonymous Coward]

Exactly why I never cared for Java as a language. Everything must be coded in Java's concept of OOP. The notion of "pure OOL" stupidly limits you to a smaller toolbox for no real gain. The entire language is designed around the "one right tool for all" mentality.

Is there a reason why the VM must be so tightly bound to the Java language? Instead of cross compiling your Fortran/Ada/Pascal/C/Java to a the VM only Java should be used because it's the one right tool (Not really but the Java overlords think so and they also think you should pay dearly for it).

Java is more about pigeonholing you than it is about being a useful tool.

Re:For learning

[xouumalperxe]

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.

That it may be. But "the vast majority" doesn't mean "the totality". I personally develop software on OSX, targeting mostly windows and linux. Yes, I do keep banging my head against the wall over the "run almost anywhere" aspect of it. But, in the vast majority of cases, the fixes to make the code truly portable are tiny.

Re:For learning

[rgviza]

The problem is the configuration files for the beans. They are proprietary. You can't deploy a jar written for jboss (or websphere, or BEA) anywhere but the type of app server it was written on. You can cut and paste the code into the gui for another app server, yes. However it's not write once run anywhere. It's write once, run on this app server only. The app server can run on any platform. In that respect it is write once run anywhere, as long as the app server runs on the "anywhere".

Re:For learning

[SomeStupidNickName12]

What?? Please indicate which studies?

I am a java programmer by trade and 95% of java development I see is developed on a windows desktop and deploy on a linux server. No rewrite, no it doesn't work on that platform. Write on windows, deploy to linux.

Re:For learning

[Anonymous Coward]

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.

still converting you short-sighted java code into 100% pure java is less of a pain than doing something similar in C++

Yikes

[XanC]

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

[Desler]

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

[CadentOrange]

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

[gbjbaanb]

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

[Desler]

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

[AuMatar]

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

[Desler]

Yes, because managed code has no memory leaks.

Yes, and managed code never has need for manual memory management. Oh wait...

Re:Yikes

[Cutting_Crew]

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

[Anrego]

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

[ka9dgx]

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

[Desler]

Yes, of course it does.

Re:Yikes

[Anonymous Coward]

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

[Desler]

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

[HaZardman27]

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

[Joce640k]

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

[Unknown Lamer]

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 and implementing processor instructions to make GC easier and support things like runtime type checking. ARM has ThumbEE 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

[Anonymous Coward]

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

[Tsingi]

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

[Joce640k]

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

[ka9dgx]

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

[Artraze]

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

Re:Yikes

[Anonymous Coward]

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

[ShakaUVM]

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

[inasity_rules]

I maintain professional (though ancient) C++ code, and actually, the whole new/delete and raw pointers seems rather elegant to me... Or perhaps (horror of horrors), I am being slowly transformed into an ancient Unix nerd...

But I have to admit there is one bug that I am struggling with. Somewhere someone is deleting an object during shutdown too quickly and causing a crash(and visual C 6.0 doesn't help me trace this easily).... So your way is possibly better...

Re:Yikes

[vux984]

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

Your counterpoint misses the point.

Pretending the problem doesn't exist doesn't make it go away.

Nobody is pretending the problem of resource management doesn't exist.

Car analogy:

Your argument comes across as saying drivers shouldn't use automatic transmissions to reduce the effort they need to spend to maintain proper control of a car because they still have to steer and work the gas.

Programmers still need to be focused on resource management, just as drivers still need to be focused on controlling the vehicle. Garbage collection, like automatic transmissions just reduces the effort required.

Re:Yikes

[skids]

Just wait a couple more years and we won't be feeling the hardware pinch even on phones.

You will always feel the hardware pinch, because every level of abstraction gets people thinking about how to make new levels of abstraction over it. So something even more bloaty will surely come along to soak up your "faster CPU" or occupy your "more memory."

Phones will always only be as fast as the market will bear. As soon as Joe sixpack, who has no idea that it should not take ten seconds to save a calander entry to his personal organizer app, is happy, the phone will ship.

Re:Yikes

[DalDei]

C++ and Objective C co-existly about as cleanly as any two languages can. XCode natively supports both even intermixed within the same expression. In fact really OC is really C++ - some things + some things ... I find writing iPhone code much easier (and more efficient) when I stick to C++ for everything except where I have to communicate with the native OS API's ... Building, Debugging, Running ... all seamless ... as long as you follow a few constraints like not putting C++ objects directly in an OC class. ( pointers to C++ objects yes, actual objects no). A few other gotchas but very easy to deal with.

Re:Yikes

[danieltdp]

I believe you have been dealing with class diagrams that are quite to the simpler side of things.

Re:Yikes

[Anonymous Coward]

Mod parent up, best post in recent memory.

Re:Yikes

[danieltdp]

The fact you only have 9 or so deletes doesn't say much about the quality of your code. One could argue that the less deletes you have, more are the chances you have that there is a memory leak...

Re:Yikes

[Desler]

Or, you know, he is actually competent at using the language features that make manual memory management mostly unneeded? Naaah, can't be that.

Re:Yikes

[Desler]

What does the IDE have to do with the language?

I don't know, honestly. The person I replied to was the one who brought up the IDE which I can only assume was Visual Studio.

Re:Yikes

[afidel]

Whatever, the real battle is in making parallelism easy enough to use that we can actually take advantage of all of the cores that will be available in the next decade. Even cellphones are headed for many cores in that timeframe.

Re:Yikes

[bberens]

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

I can't speak for other managed languages but in Java two objects that reference each other but nothing else references them will still be garbage collected.

Re:Yikes

[Anonymous Coward]

Oh God... I highly recommend that you use "valgrind" it will show you how wrong you are.

The delete statement is a must and should be executed to avoid your memory leaks, I created an example for you:

void testMemory() {
        std::string* s = new std::string();
        s->append("sample");
}

void testLoop() {
        for (int x = 0; x 100000; x++) {
                testMemory();
        }
}

int main(int argc, char *argv[])
{
        testLoop();
        getchar();
}

if you loop 1 time the memory consumed is 344k if you loop it for 100000 the memory goes to 5344k and it's not released until close,

Memory leak is a real problem, but, as someone else said, it force you to have a cleaner design, java has a lot of problems with memory too, the double references and undetected null pointers force the garbage collection to hold an object forever, we had to work very hard to solve problems of memory consumption in java just because we dont have the very useful "delete" function.

Re:Yikes

[Desler]

One could argue that the less deletes you have, more are the chances you have that there is a memory leak...

Yes, one could. This person is most likely an idiot, though. When you take full advantage of C++'s built-in memory management features or tools like boost, you will almost NEVER need to use new/delete.

Re:Yikes

[Desler]

This just in: If I create a program specifically to leak memory it will... LEAK MEMORY!!! Seriously, who is actually writing code like that? And why the fuck would you be creating the string with "new" anyway? Your code makes absolutely no fucking sense and appears to have been written intentionally to be crappy.

Re:Yikes

[Desler]

Now the program when written the correct way as:

void testMemory() {
                std::string s();
                s.append("sample");
}

void testLoop() {
                for (int x = 0; x 100000; x++) {
                                testMemory();
                }
}

int main(int argc, char *argv[])
{
                testLoop();
                getchar();
}

Will not leak memory. Imagine that. If I don't write the program in a stupid way it won't actually behave stupidly! AMAZING!

Re:Yikes

[Anonymous Coward]

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.

This is non-sense. Garbage Collectors were created precisely to handle this type of situation. Even the most primitive GC can handle cyclical structures just fine.

On the other hand, reference counters CAN'T handle this type of situation.

Managing memory is manual labor, that's why the memory should be handled by the computer and not humans.

Re:Yikes

[Desler]

But seriously. Who writes a loop that does nothing but allocate objects on the free store and then does nothing with them? If this is actual code you are writing in a production environment you need to be fired.

Re:Yikes

[Bob the Super Hamste]

Even well written C code shouldn't be making use of tons of mallocs and frees. The C code I at work that I most frequently work with with has a few mallocs in it but most of those are for some global storage arrays that are initialized at program run up and can be of arbitrary size. The rest are a where memory is malloced so it can be passed to a new thread where it gets cleaned up once the thread is finished running. I think the total number of malloc and free pairing in the program is 5 or so as the program is meant to run continuously and never exit so the global arrays never get freed.

Re:Yikes

[Xtifr]

One could argue that the less deletes you have, more are the chances you have that there is a memory leak...

<grammar_nazi> fewer </grammar_nazi>

One could argue that, it's true, but it would most likely be evidence that the person arguing was utterly ignorant of anything that's happened in C++ since the early nineties. Between the container classes of the STL and Boost, and the RAII model, having very few deletes is generally a very good sign, since it shows you're not resorting to too much error prone manual memory management. If the few deletes you have are all in destructors, that only makes it more clear. (And even there, using autoptr or sharedptr is generally vastly superior to trying to figure out when you can issue a manual delete.)

In modern C++, you can manage vast amounts of memory properly without ever once using delete. In fact, you're more likely to be managing your memory properly if you don't.

Re:Yikes

[Anonymous Coward]

so what you're saying is your team is incompetent?

Re:Yikes

[Desler]

Most likely. This person is probably the team lead.

Re:Yikes

[GooberToo]

Memory management in C++ is a myth perpetuated by C hackers who can't be bothered to educate themselves.

And Java developers who want baseless stones to throw. Or Java developers who are too lazy to learn what is both a more powerful and complex language.

Re:Yikes

[danieltdp]

Then you are doing boost, not C++. It's like saying you can live in your car because you atatched a trailler on its back. You are living in the trailler. Not in the car

Re:Yikes

[danieltdp]

You ARE using delete. But it was coded by someone else who did not coded the language itself

Re:Yikes

[Desler]

This time, actually read my entire statement.

When you take full advantage of C++'s built-in memory management features or tools like boost, you will almost NEVER need to use new/delete.

And notice how I said you could use those "built-in features" OR boost. Seriously, the sentence isn't that hard to read.

Re:Yikes

[VGPowerlord]

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.

Not anymore. It does require you to get the resource in a special block, just like C#.

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.

That was an intentional language decision. From what I've heard it's because Sun thought the majority of programmers who tried to use multiple inheritance in C++ used it wrong. Instead, Java and C# only allow multiple inheritance of completely abstract classes (dubbed interfaces) plus one non-completely abstract class.

Re:Yikes

[Desler]

Epitomized by posts such as this. Yeah, who cares about doing stupid shit like closing file handles? Yeah, actually being a competent program is so dumb.

Re:Yikes

[danieltdp]

So I want me to ignore read all of it and ignore the second half (about boost)?

Re:Yikes

[Anonymous Coward]

Your counterpoint misses the point.

What a stunning rebuttal! Oh wait, it's not.

Nobody is pretending the problem of resource management doesn't exist.

Actually most people try to pretend this. Hell even the original white paper for Java was trying to claim this.

Your argument comes across as saying drivers shouldn't use automatic transmissions to reduce the effort they need to spend to maintain proper control of a car because they still have to steer and work the gas.

No, my argument is nothing of the sort. My argument is that if you are using C++ you should *gasp* use the built-in automatic memory management features. So actually my argument is nothing like your strawman at all.

Programmers still need to be focused on resource management, just as drivers still need to be focused on controlling the vehicle. Garbage collection, like automatic transmissions just reduces the effort required.

Yes, and so does smart pointers and the use of RAII to automatically manage memory in C++. So, what exactly is your point other than beating on strawmen?

Re:Yikes

[Anonymous Coward]

No, I don't want you to ignore anything. As I said, you could use the built-in features OR boost. Yes, if you use boost you are writing boost. Wow, so insightful! Otherwise if you don't want to use boost *gasp* use the built-in features that will do automatic memory management for you as well. Seriously, this fucking nitpick argument is lame as shit if that's the best you've got.

Re:Yikes

[Joce640k]

Luckily for me I built some counters into the objects which increment/decrement when they get constructed/destructed and made it beep at me if I quit the program when one of the counters isn't zero.

The fact that I don't remember the last time it beeped disproves your theory...

Re:Yikes

[bonch]

The big secret about automatic memory management schemes like garbage collection is that you still have to manage and think about the memory. You can even create leaks! Shh, don't tell anyone.

Re:Yikes

[gbjbaanb]

or reference counted smart pointers

Re:Yikes

[Joce640k]

It does require you to get the resource in a special block

Not really automatic then, is it?

That was an intentional language decision.

I know that...Java left out many features to try to prevent bad programmers from using them. The result was that Java became less useful to good programmers and the bad programmers just found more creative ways to write bad code.

Re:Yikes

[Joce640k]

Then you are doing boost, not C++.

Nope, I don't use boost...

Re:Yikes

[Joce640k]

I created an example for you:

void testMemory() {

        std::string* s = new std::string();

        s->append("sample");
}

LOL! I hope you're only trolling. Seriously. If not you should try another profession.

Re:Yikes

[gbjbaanb]

some languages pretty much require an IDE, think writing a WPF application in C# without Visual Studio. In fact, why not have a go just for fun - see if you *can* write a simple c#/WPF app in notepad.

Re:Yikes

[petermgreen]

Not anymore [oracle.com]. It does require you to get the resource in a special block

mmm, better than it used to be though IMO still not as good as C++

Also their example doesn't make it clear whether only the bufferedreader will be autoclosed or whether the filereader will be as well.

Re:Yikes

[Terrasque]

I use Python for most things, c/c++ when I feel the need for speed/power.

And today PyPy released version 1.6 of their python interpreter :) More python speed!

Re:Yikes

[gangien]

Yes, because managed code has no memory leaks.

Of course this is true.

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.

Then the android platform is a piece a crap. Or your developers suck. Neither of which is very relevant when discussing whether managed code is or isn't a good thing, as there are plenty of good platforms.

Quite frankly, memory management is not hard.

Not much in programming is hard. But anything you have to think about is bug prone. Including manual memory management.

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

I think you are just being stubborn or displaying false bravado.

Re:Yikes

[petermgreen]

A lot depends on what the code is trying to do.

If you know the maximum size of everything up front then as you say you can allocate all your memory upfront and mostly forget about managing it. Of course this only works for certain types of application.

On the other hand in C if you don't know the sizes of stuff upfront then you will need to allocate memory for them as you go along and manually keep track of that memory so you can free it at the appropriate time. C++ gives you tools to automatically keep track of that memory and free it when appropriate. Java sidesteps the problem of needing to keep track of memory allocations by using GC (of course GC opens a huge can of worms of it's own)

Re:Yikes

[petermgreen]

Managing memory is manual labor, that's why the memory should be handled by the computer and not humans.

So why does java unlike virtually every programming langauge i've dealt with impose an arbitary memory limit on programs by default?

I believe the reason is that the GC can't be trusted to clean up memory in a timely manner unless it's forced into an out of memory situation. So they put an arbitary memory limit on there to make sure the vm doesn't drive the machine into swap death before the GC bothers to clean up.

I don't think GC is a fundamentally bad idea but I DO think doing it properly requires hooks in the OS so applications can be informed of memory pressure not just within their own application but between applications.

Re:Yikes

[vux984]

Hell even the original white paper for Java was trying to claim this.

Nobody seriously thought resource management was going to go away. The idea is absurd on its face.

My argument is that if you are using C++ you should *gasp* use the built-in automatic memory management features

They aren't built in to C++
Smart pointers are a library not a language feature.
RAII is a best practice not a language feature.

Re:Yikes

[AuMatar]

If you think managed code has no leaks, you've either never written anything beyond hello world or you're completely oblivious. It's trivial to leak memory in Java and C#. In fact, if you don't program defensively to avoid it your programs leak like a sieve.

Re:Yikes

[brantondaveperson]

Somewhere someone is deleting an object during shutdown too quickly and causing a crash

void DoShutdown()
{
    ExitProcess(0);
}

Problem solved :)

But seriously. Use auto_ptr or scoped_ptr or shared_ptr. Change all your code over to do this today. You will not regret it. We didn't.

Re:Yikes

[Xtravar]

Solution: Use Objective C. It's a better language. It makes more sense. It has a better design philosophy. There is usually only one or two correct ways to do something, rather than C++ where you have a million options and a hundred third party libraries and each has its own object model.

Re:Yikes

[SplashMyBandit]

Who cares how much code *you* have written - one person simply doesn't write enough code to make a difference on a huge project. It is when you are part of a two dozen developer team or larger that the sorting of the 'men from the boys' happens with technologies. In this case C++ is very hard to get right (when you program is multi-threaded and very non-deterministic with its resources).

Re:Yikes

[SplashMyBandit]

I can tell you that my 'managed code' has no memory leaks - despite being very heavily asynchronous and multi-threaded in many projects. Just because some developers suck doesn't mean the tech sucks. There is no substitute for competence.

Re:Yikes

[gangien]

He was being sarcastic. So i was acknowledging that sarcasm, but that wasn't apparent in the quote.

Re:Yikes

[SplashMyBandit]

Actually I did a decade of C++ followed by a decade of Java. I would never start a new project in C++ unless memory constraints were absolutely tiny - although for most embedded systems I've worked on these days even Java fits in nicely. Basically my consulting rate is so expensive that by using C++ and its longer development time I would be negligent in using it rather than the massively more productive Java (and its unparalleled tools like JVisualVM, that let you profile and optimize code that was not compiled for profiling and is running live in a production environment. Unfortunately I often come across people who believe C++ is 'l33t', which I find laughable. As I got more experience I realized that among the reasons C++ was worse than Java (and there are plenty) was the fact it was generally harder for the same functionality (which you seem to think makes you a 'real developer') which means slower development times and more expensive projects for the same features - this does not make good business sense for my customers, and they know it (in the Enterprise/government space few projects are started with C++ unless there is some very good reason for it - which there almost never is). I've been able to write systems from complex embedded ones to Internet-scale ones (as part of a large team), including doing it on my MacBook Pro or Linux and deploy to whatever the customer had (Win Server, Solaris, HP-UX, Linux) without porting issues. In short your (C++) "more powerful and complex language" could well from a lack of exposure to all the aspects of development *including the commerical and time-critical ones*. IMHO if you use C++ because you think it makes you l33t then to me you demonstrably are not (and regrettably you can't even grok why).

Re:Yikes

[c0lo]

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.

Hmmm... I think you aren't aware of what seems to be a law of the nature: "When a new generation of hardware breaks the bottlenecks of memory/speed, it takes almost no time for the next generation of incompetent programmers to reinstate them".

Examples:
a. "640 kB should be enough for everybody" - said once the "lead architect" who's last major project was Vista
b. "The art of computer programming" is taught on MiX and it's a jewel on concerning the algo complexity analysis. Nowadays, very few programmers feel the need to even choose the right basic algorithms for the code they are scribbling by the fucktonne.

Re:Yikes

[larry bagina]

you can put a c++ object into an objective C object if it has a default constructor. I do it all the time (even with templated or stl objects).

Re:Yikes

[larry bagina]

auto_ptr is fine unless you're a retard and try to stick auto_ptr into a collection. For c++11, unique_ptr should probably be used instead.

Re:Yikes

[cowboy76Spain]

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.

Ok that's true.

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

Because when I am driving and thinking of how the pistons work in the engine up and down I am so more focused in driving that I am driving better? Having to thing in these things means an opportunity for failure, too. C people seem to overlook that, somehow the people that makes mistakes is always "some other guy".

Hey, if what you said was true we would be still using C or assembler (outside of the very specialized fields where it is still used).

Re:Yikes

[Anonymous Coward]

The virtual destructor is what will bite you.
In any case there a few easy well documented rules and it's very clean

Re:Yikes

[Anonymous Coward]

Try using Java without the massive collection of 'library' classes, or python without modules, or C# without .Net.

Boost is a C++ library. How is that not C++?

You're trolling.

Re:Yikes

[larry bagina]

If the c++ class is inline in the Objective C class, the compiler knows what the class is, if there's a destructor,  and will auto-generate a .cxx_destruct method to clean it up.  Since it knows the class and the class can't change, it calls the destructor directly, without the virtual table lookup.

$ cat test.mm
#include <Foundation/Foundation.h>
#include <stdio.h>

class base {
public:
  virtual ~base();
};

class child : public base
{
public:
  virtual ~child();
};

base::~base()
{
    printf("~base\n");
}
child::~child()
{
    printf("~child\n");
}

@interface MyClass : NSObject {
  child _child;
}
@end

@implementation MyClass
@end

int main(int argc, char **argv)
{
  MyClass *c;
  c = [MyClass new];
  [c release];
  return 1;
}

$ g++ -framework Foundation test.mm -o test
$ ./test
~child
~base

Re:Yikes

[menkhaura]

Because when I am driving and thinking of how the pistons work in the engine up and down I am so more focused in driving that I am driving better?

I had to bite this one, because it shows some degree of competence in another uncorrelated field. If you think of how the pistons work in the engine, or how much fuel is drawn in, or just at what distance from piston top to valve the explosion ocurred, or when the gas will get expelled, well, you're thinking in terms of assembly language or even a bit lower, into the 0's and 1's; that's where the carburetor or the EFI will help you, with you or the computer (in both cases) will do part of the job for you.

However, if you dose the throttle pressure, applying just the right torque to your wheels, neither over-revving your engine nor burning your tires, neither over- nor under-steering, breaking neither too early or too soft nor too late or too hard, that's what will get you ahead. That's what it means when men are separated from the boys, that men have the control, they know what it takes, while the boys still have their training wheels attached.

Why be a SUV driver when you can be a bicycle rider?

Re:Yikes

[smellotron]

RAII is a best practice not a language feature.

RAII is an idiom based on the language feature of deterministic destruction. It relies on this language feature: .finalize() and similar don't cut the mustard. It is also the primary purpose for the language feature to exist: there is no reason to have a destructor unless it is cleaning up resources. Arguing that RAII is not a language feature is sophistry.

Re:Yikes

[inasity_rules]

Unfortunately the code is massive, so changing today won't be easy. Though I am planning a rewrite from the ground up. While decent (this code runs fine on anything from NT4 to windows 7 64bit, which for something that old is impressive), the code isn't quite as flexible as it needs to be.

Re:Yikes

[smellotron]

void testMemory() {
std::string s();
s.append("sample");
}

Ack! You've just rediscovered the most vexing parse. This code won't compile, because you've declared a local function s that takes no parameters and returns a std::string by value. I imagine this sidebar isn't going to win any more fans for C++...

Re:Yikes

[brantondaveperson]

Oblig

(Sorry)

I'm sure your case is an exception, but I couldn't resist. The one time I felt like the only option was a rewrite, it turned out to be the right decision and the result was a huge improvement and a success. I wish you the same luck with yours.

Re:Yikes

[inasity_rules]

No worries, it is a good valid point, but in this case, I need to start supporting newer standards. While possibly I could get OPC UA or WCF into visual studio 6, and possibly I could increase the flexibility of the system and a whole do a whole lot of enhancements, the system has some fundamental limitations that fixing will amount to rewriting the code( for example the ability to run high levels of redundancy). Additionally I need to start supporting 64bit (windows unfortunately) operating systems natively, as some customers may end up using >2.5Gb of RAM on the larger systems. Thanks though! Speaking of which, I must get on with it!

Re:Yikes

[cowboy76Spain]

That's what it means when men are separated from the boys, that men have the control, they know what it takes, while the boys still have their training wheels attached.

LOL. A bitter over-emocional about your language, aren't you? Or is it just your ego talking? Hey, if what you want is to brag better switch to whitespace, or brainfuck.

If there is a problem with torque, steering or breaking, then I know about it to manage it. But if the car can take care of that for me so I can get to concentrate in the things the car can't do, it is just a win-win.

Obviously you will say "but what if you have to drive in a 70's car (without ABS, assisted steering and so on) on a snowy road by night?" Then it will be a ride different to what I am used to, and I'll go slower. But given how little I have to do that, I think that the improved performance of not having to deal with petty details is worth it. If I find I must it often, then I'll learn to do it quickly.

Simple as that.

Re:Yikes

[LizardKing]

Also their example doesn't make it clear whether only the bufferedreader will be autoclosed or whether the filereader will be as well.

If you were familiar with the Java IO classes, then you'd know that passing a stream to the constructor of another stream means that it will close the wrapped stream on being closed itself. To make it clearer, on closing the BufferedReader in the linked example, it will close the FileReader - hence why the example code itself doesn't need to keep a reference to the FileReader.

Re:Yikes

[LizardKing]

std::string s();

That needs to be:

std::string s;

But it does succinctly capture why Stroustrup is a fucking idiot.

Re:Yikes

[master_p]

but I've written commercial C++ code for years and I've not had memory management issues.

I can attest to that with some numbers: I am the only developer in a C++ realtime defense application that has 250K lines of code, and I don't have a single issue with memory from 2008 when I started using smart pointers. And the application does quite a lot of complicated things (at one point, more than 30 different threads are running at the same time).

Really, the difference smart pointers make is enormous.

Re:Yikes

[owlstead]

Yep, and it is one of those things that stop being a problem once you are used to it. It will take some time though. It's one of the things you can see converted C++ programmers doing wrong (trying to work around problems not covered in initial design). That and the use of _, confusing chars and bytes, not keeping to Java coding practice and forgetting that Java strings are immutable (actually supported by the platform, toUpperCase() really is a misnomer).

Anyway, for business applications inheritence is not such a useful tool, and for data containers you might as well specify a bunch of interfaces from the start.

Re:Yikes

[danieltdp]

The difference is that the massive collection of classes in java are built in the language itself. You don't happen to bump on a Java deployment without them. When you plan a large scale deployment on an heterogeneous base, these kind of stuff matters a lot.

Anyway. It seems that some people took a nice opportunity to talk about differences and threw it away, feeling personally attacked by my point of view. I even got my (first) enemy. Hows is that? As this is not my intention, I will stop replying to this thread.

As a proof that it is not my intention to troll. I kept replying under my id to the end, which is not the case for some other people. The way this thread when is why I spent much less time on Slashdot and its comment session.

Re:Yikes

[DrVxD]

Quite frankly, memory management is not hard.

Indeed - it's no harder than borrowing a book from a library; you ask for some memory, and when you've finished with it, you give it back.

Re:Yikes

[Desler]

They aren't built in to C++

Constructors, destructors and the standard library aren't built into C++? Since when? What use is a C++ implementation that doesn't include the most vital part of the language?

Smart pointers are a library not a language feature.

*facepalm* The standard library IS a part of the language.

RAII is a best practice not a language feature.

When did I say RAII was a "language feature"? RAII is a idiom UTILIZING language features which is use your constructor to initialize your resources and your destructor to clean them up.

Re:Yikes

[jeremyp]

The difference is that the massive collection of classes in java are built in the language itself.

No they are not. They are in jar files like every other Java library.

You don't happen to bump on a Java deployment without them.

That's true. Oh, wait, no, it isn't

The thing is that "part of the language" means a very specific thing: It means it's part of the syntax and of the language definition. The Java SE API implementation is not part of the language, it is, however, part of the Java SE implementation and its API and semantics are tightly specified, so you can pretty much guarantee it's there on any implementation.

Re:Yikes

[menkhaura]

LOL. A bitter over-emocional about your language, aren't you? Or is it just your ego talking? Hey, if what you want is to brag better switch to whitespace, or brainfuck.

Been there, done that, got the t-shirt. Kids these days... My e-dick big enough?

If there is a problem with torque, steering or breaking, then I know about it to manage it.

That's the very core of the question. People are forgetting about how to think about what's happening under the hood, it's all a black box where everything magically happens and you don't care how it's done, about resources laid to waste ("just buy more hardware" doesn't cut it), and if there's an error in the framework itself (JVM, .Net CLR, the Python or PHP or Perl interpreters), less and less people are able to see it for what it is and work around the issue. That's what I'm talking about. Old timers used to say about LISP programmers that they knew "the value of everything and the cost of nothing", and I think that applies to today's managed code; thankfully hardware nowadays is cheap and powerful, but Moore's law has a limit, and people will have to think better about managing their resources.

But given how little I have to do that, I think that the improved performance of not having to deal with petty details is worth it.

So very true, and very wise too, but not having to deal with "petty" details doesn't mean you may ignore even in general terms what happens under the hood.

If I find I must it often, then I'll learn to do it quickly.

I sincerely hope so.

Good luck.

Re:Yikes

[menkhaura]

Way to ruin a good post.

The correct link is http://gbf.sourceforge.net/

Umm - mod article down

[Intron]

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

Re:Umm - mod article down

[tomhudson]

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

[neokushan]

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.

Re:Umm - mod article down

[tepples]

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

"

Or maybe we're not. Maybe we'll end up with devices that can't run third-party native code, like BlackBerry phones, phones running Windows Phone 7, Chromebook, etc. Or we'll end up with devices that can run two tiers of applications: those by the largest developers that are allowed to use native code and those by "second-class citizen" developers that are stuck in a managed-only sandbox, like Xbox 360.

Re:Umm - mod article down

[LWATCDR]

Mod yourself down. You do know that many applications are written in c and c++ don't you.
I don't like c++ because it is nothing but c with object tacked on. I can use it but I don't like it. Objective C has IMHO a much better object model as does Java.
But guess what sparky you are probably using apps write now written in c or c++ like maybe your browser.

Re:Umm - mod article down

[bonch]

You apparently aren't aware that C++ is used for application programming. You most likely posted your comment in a web browser written in C++.

Re:Umm - mod article down

[tomhudson]

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

Or maybe we're not. Maybe we'll end up with devices that can't run third-party native code, like BlackBerry phones, phones running Windows Phone 7,

At the rate WP7 market share is declining, it will be a rounding error. It's already down to half what it was last year, now at 1%.

However, I wasn't thinking of smartphones, but of server farms, desktops, and laptops. There are big energy savings to be had by making code faster, and native is the way to do it.

But you have a point - if your two-class divide comes about, people are going to shun the small guy or gal because his or her code will eat into their battery life.

Re:Umm - mod article down

[Anonymous Coward]

But guess what sparky you are probably using apps write now written in c or c++ like maybe your browser.

And that doesn't stop the damn thing from leaking more memory than any managed program I've ever used.

Never went away

[i ate my neighbour]

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

Re:Never went away

[SmurfButcher Bob]

Sure it did. Why do you think a Native HTML5 browser had to be created? :)

Re:Never went away

[Darinbob]

And C++ is not the first spot you turn to for performance and efficiency. Especially not the style of C++ that tries to emulate a very high level style. It tries to straddle two worlds, that of efficient system languages and that of high level mostly interpreted object oriented languages, and so doesn't quite feel at home in either world.

I like C++ though, don't get me wrong. I just like to stick with the simpler parts of it, the "better C than C" side of it with the advantage of some higher level code organization features.

Re:Never went away

[Anonymous Coward]

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

Yes, well, I can't help wishing it was prioritized more often.

For example, a lot of the system tools on Fedora Linux are written in Python, which I'm sure has great benefits in terms of delivering new features faster and so on. But you have a problem when, as was the case for me the other day, a user can literally download and install a program by compiling it from source code in less time than it takes your Python-based package manager to find out whether a prebuilt package even exists.

Seriously. That happened. It was quite a small program, so it did compile pretty quickly, but even so, the combination of Google and autotools should never be quicker than the OS-level package installation system. That is just inexcusable.

Re:Never went away

[HiThere]

Native is excellent. Unfortunately, C/C++ has some very bad failings...basically due to pointer arithmetic, but also due to being able to cast pointers to integers and vice versa.

FWIW, I consider garbage collection to be almost essential in a decent language, and the conversion of pointers (and pointer arithmetic) mean that it cannot be efficiently done in C/C++ style languages. There are also other reasons why this is a bad idea, but that's the, for me, primary one.

Note that before I started using Object Oriented Programming I didn't worry about garbage collection. Now that I use it I find the lack of it in C/C++ to be a constant pain. The compiler should be able to determine at any point which objects are still "live" (i.e., reachable) and reclaim those that aren't. Unfortunately in C/C++ this is impossible, as they could be stored on disk files as integers. Generally this is "worked around", partially by saying "You should be smart enough not to do that", but also by guessing whether certain integers in RAM are or are not pointers in disguise. It generally works, but it imposes a tremendous overhead that usually isn't worth the cost.

I suppose that this isn't a "native code vs. interpreter" comment, but it's relevant given that the example they chose for a native language is C++. (Reasonable as it's quite a popular language.)

Re:Never went away

[Anonymous Coward]

Performance and efficiency are always a top priority. Its just they are relative terms, and coding in c++ for a few nanoseconds of performance is a retarded trade off when you're building a friend feed.

Re:Never went away

[zeroshade]

Native is excellent. Unfortunately, C/C++ has some very bad failings...basically due to pointer arithmetic, but also due to being able to cast pointers to integers and vice versa.

Pointer arithmetic allows extremely efficient and simple code to be written. While pointers in and of themselves can be confusing to someone learning the language, to someone with an understanding of pointers, pointer arithmetic is an essential thing.

FWIW, I consider garbage collection to be almost essential in a decent language, and the conversion of pointers (and pointer arithmetic) mean that it cannot be efficiently done in C/C++ style languages.

Garbage collection requires an extra overhead that C/C++ allows the programmer to avoid by manually managing their own memory. For a low-level systems language it's essential to have the ability to manage your memory yourself, especially when you start talking about embedded systems. FWIW, extremely efficient garbage collection libraries exist for C/C++ which renders your idea of pointer conversion and arithmetic making it impossible. Also, what do you mean by "C/C++ style languages"? Do you mean native languages in general? Languages that allow pointers and memory management? Or just the syntactic style?

The compiler should be able to determine at any point which objects are still "live" (i.e., reachable) and reclaim those that aren't.

Even in managed languages, the compiler cannot figure this out. It's the runtime environment that does. The idea that the compiler could always figure this out is ridiculous. There are definitely many situations where a compiler might be able to do it, but the only way to figure it out would be to run the compiled code with every possible input and trace all the memory, which is not something a compiler should be doing.

Re:Never went away

[tolkienfan]

They call it "multi-paradigm".

Then learn the language better, stupid

[Desler]

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

[m50d]

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

[Desler]

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

[Desler]

To quote from here:

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

[m50d]

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

[Desler]

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

[roothog]

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

[Duhavid]

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

Re:Then learn the language better, stupid

[Joce640k]

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 close the file before I can safely email it to somebody?

Re:Then learn the language better, stupid

[lgw]

While true, I've had that problem maybe once in 20ish years of coding. Non-trivial cyclic data structures don't seem to pop up that often (but maybe that's just systems programming).

Re:Then learn the language better, stupid

[m50d]

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 close the file before I can safely email it to somebody?

If you care about when the file gets closed then you explicitly close it yourself. But if you don't want to care about it then you don't have to - you can leave it to the garbage collector and it'll take care of it.

Re:Then learn the language better, stupid

[Desler]

You don't have that right, and you're probably writing code with memory leaks.

Actually, I'm not.

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.

Okay, so my knowledge of boost is rusty, but again it has an object to handle what the person was complaining about. C++0x also has something to address that as well.

Re:Then learn the language better, stupid

[Desler]

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 close the file before I can safely email it to somebody?

Exactly. A program that isn't closing files or disposing of native handles is just plain lazy and thus is probably the reason this person has C++ code that leaks so much memory or resources. Even IF the GC would take care of it for you you shouldn't be relying on it to do so (which in .NET the GC won't).

Re:Then learn the language better, stupid

[Desler]

If you care about when the file gets closed then you explicitly close it yourself.

What do you mean "if you care"? You should ALWAYS care. Leaving files opened for no good reason is the sign of being lazy.

But if you don't want to care about it then you don't have to - you can leave it to the garbage collector and it'll take care of it.

Translation: If you want to be a lazy and shitty programmer you can just leave it to the GC to close the file whenever it feels like it. It's not as if the user might want to open that file in another application or maybe reload it again, right? No, that never happens. One can only hope that you aren't responsible for writing critical software with such shitty standards for writing software.

Re:Then learn the language better, stupid

[Desler]

BTW, I'm laughing at the managed code "programmer" who is modding down my posts as flamebait and overrated as a way to try to hurt my karma. Seriously, is that the best you got?

Re:Then learn the language better, stupid

[Anonymous Coward]

Not to mention that bugs in .NET force you to use try-catch everywhere.

Re:Then learn the language better, stupid

[m50d]

What do you mean "if you care"? You should ALWAYS care. Leaving files opened for no good reason is the sign of being lazy.

The whole craft of programming is applied laziness. Sometimes it matters when a file gets closed. Most of the time it doesn't - just like sometimes it matters what's in that list you're sorting, but most of the time it doesn't. Knowing when is what makes you a good programmer.

Re:Then learn the language better, stupid

[GooberToo]

For most projects, the risk is related to the number of containers, not the number of resources.

Re:Then learn the language better, stupid

[JonySuede]

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

Re:Then learn the language better, stupid

[m50d]

If you're separating concerns correctly only a tiny proportion of your code will be holding GDI handles, file handles, database connections or whatever.

Re:Then learn the language better, stupid

[alexo]

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:

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 resource (descriptors) dependent on garbage collection promptness. Relying on garbage collection to manage resources other than memory is almost always a bad idea.

Also, for the fun of it, look at:
http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java

Re:Then learn the language better, stupid

[Joce640k]

If you have cycles of pointers which are claiming "ownership" of each other then maybe you need to revisit your design, re-read the chapter on RAII.

Re:Then learn the language better, stupid

[Joce640k]

But if you don't want to care about it then you don't have to - you can leave it to the garbage collector and it'll take care of it.

...this is the level of programmer who thinks he's able to criticize another programming language?

Re:Then learn the language better, stupid

[m50d]

What you quoted doesn't contradict what I said. Yes you "should" close your files and connections. And the part I guess I should've mentioned, yes there can be performance implications if you don't. But it won't break.

And I think the stack overflow thread makes my position stronger rather than weaker. Yes, it's possible to cause a memory leak in java. But it's difficult, a lot more difficult than in C++, even if you're following good C++ practices.

Re:Then learn the language better, stupid

[dmmiller2k]

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

Re:Then learn the language better, stupid

[alexo]

What you quoted doesn't contradict what I said.

OK, let's spell it out then. You said: It's better to close your files and connections, but they'll be garbage-collected for you if you don't.

Now, riddle me this: what guarantee do you have that the GC will run at all?
If the GC decides that your program has enough available memory it may never run, it will just sit there waiting for some threshold while your program merrily consumes scarce resources that it knows nothing about.

Re:Then learn the language better, stupid

[alexo]

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

Sounds luke the C# using statement and the corresponding IDispose interface.

Which is a bass akwards way of doing things, as it makes proper object cleanup the responsibility of the object's user.

Re:Then learn the language better, stupid

[JonySuede]

it is not that backward look at http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization , what do you propose instead ?

Re:Then learn the language better, stupid

[alexo]

it is not that backward look at http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

RAII does not require the consumer of a class to wrap the object in a try block.

what do you propose instead ?

How should I know? I use C++ for my day job, not Java.

Re:Then learn the language better, stupid

[JonySuede]

I am curious, since my c++ is quite rusted, how do you acquire a resource that can throw upon initialization in c++ ? Or is checked exception usage is discouraged in c++ ?

Re:Then learn the language better, stupid

[snemarch]

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.

Oh, and angle brackets are SO scary? It's not like you don't need them all over the place in Java when you use collections... and (finally!) with C++11, we have type inference, lowering the need for those angle brackets substantially.

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.

They might get garbage-collected... eventually... once the non-deterministic garbage collector feels like it. If you're not putting a lot of pressure on the GC, doyc knows when that's going to happen. Programming Java without calling the correct disposal methods (which means a lot of try/catch/finally goob) is really bad practice, just as not using the IDispoable pattern (and littering code with 'using') in C#.

C++? Deterministic destruction, even in face of exceptions, by use of RAII.

Re:Then learn the language better, stupid

[Lemming Mark]

Python, at least, has the ability to pull off similar behaviour using its "with" statement. Whether the extra explicit blocks required to do this are good or bad probably depends on point of view, although it's probably rather forced on them by not being a original design feature.

Re:Then learn the language better, stupid

[alexo]

I am curious, since my c++ is quite rusted, how do you acquire a resource that can throw upon initialization in c++ ?

You use a try .. catch block. However, that is completely unrelated to specifying the life-time of the object and can be set at a higher level, possibly even in main().

Or is checked exception usage is discouraged in c++ ?

There are no checked exceptions in C++. There are exception specifications but they were a bad idea that got deprecated in C++11.

Re:Then learn the language better, stupid

[Anonymous Coward]

Huh? Don't think so. You'd better close your file handles.

Re:Then learn the language better, stupid

[Just Some Guy]

Ah, I see the problem: you're a Windows programmer. You must be. No other platform cares nearly so much about whether a file is closed before allowing another process to open it. Yes, it's good practice to close files when you're done with them. No, there's no practical difference on most systems if you don't. In general, the worst that can happen is that you'll create an enormous, partition-filling file that the filesystem can't unlink because you still have an open handle to it.

That's assuming you're not still actively writing to a file, but if you're at the point in your program where the file could be closed anyway, that's not likely to be an issue.

Finally, Python lets you write code like this:

with open('foo.txt') as inputfile: process(inputfile)

which explicitly garbage-collects inputfile as soon as it falls out of scope. If you use that pattern you'll never need to close the file (and it would in fact be a pretty dumb thing to do).

Re:Then learn the language better, stupid

[c0lo]

There are no checked exceptions in C++. There are exception specifications but they were a controversial idea that got deprecated in C++11.

FTFY.

Java seems to have a way doing the opposite.

Re:Then learn the language better, stupid

[cowboy76Spain]

Translation: If you want to be a lazy and shitty programmer you can just leave it to the GC to close the file whenever it feels like it. It's not as if the user might want to open that file in another application or maybe reload it again, right? No, that never happens. One can only hope that you aren't responsible for writing critical software with such shitty standards for writing software.

Sometimes you care, sometimes you don't. It is simple as that. An user document file? You care. A log file? You do not. This is not hard to understand.

I am worried that you call yourself a programmer with so little comprension ability. How do you get to interpret the customer requirements? Or you just write the program what you feel like writting and hope that it fits your customer needs? Sorry, but no amount of proficiency in any technology can compensate for this.

Re:Then learn the language better, stupid

[JonySuede]

no, it just that most Java programmer sucks... You are supposed to close your resource, log and throw the exception up if you can't recover from it correctly. You can wrap it if you need to convoy additional context but that's all you need to do at a low level. You will catch everything back later into the main or into the event handling thread of your framework (like Swing, JSF, AWT...).

Re:Then learn the language better, stupid

[JonySuede]

I when I said your resource I meant the resources that the object allocated.

And yes you get method signature like, int Motror.rampUpRevolution(int) throw NetworkException,SecurityException,OilExauhstion,LowBattery, that's the point of checked exception.

Re:Then learn the language better, stupid

[Homburg]

If you're creating cycles then you didn't understand RAII.

So, what you're saying is, I have to artificially complicate my design in order to deal with a limitation of the language? Neat (actually, you can use garbage collection with C++, and C++0x provides limited support for this).

Re:Then learn the language better, stupid

[siride]

It was mentioned above, but the using() statement in C# (and Using in VB) plus the IDisposable pattern make it nearly trivial. You don't have to write special code for each code path. You use ONE using() statement and everything else is taken care of.

I find it funny that there is so much ire towards GC. Yes, it has performance problems and can definitely be made better. With more help from the compiler and better rules about when allocation and deallocation happens, it could probably be made deterministic without requiring explicit allocation and freeing from the programmer. But aside from that, I find the accusations of laziness to be, well, baseless and nearly luddite. Isn't the whole *point* of computers to be lazy? If you really want to, you can calculate all this stuff by hand, but we built these machines to do it for us and faster. The same thing with using assembly mnemonics instead of raw machine code. Same thing with compilers. And so on. If you are spending a lot of time managing memory, something that a computer should be good at, by the way, that's time you aren't spending doing other things, like fixing bugs and adding needed features. Why do the computer's job? If the computer can handle memory management, let it handle memory management. Let the programmer focus on things the computer can't do, like come up with ideas for programs, or translate contradictory customer requests into sane and orthogonal requirements, and so on.

Re:Then learn the language better, stupid

[shutdown -p now]

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

Not all relations between objects have clear ownership semantics. There's nothing fundamentally wrong with cycles when they correctly model your domain.

And this has nothing to do with RAII. Sure, traditional C++ style RAII makes cycles hard to deal with, but the flaw is with the technique, not the pattern. It is silly to let your tool dictate too much how you model things - if you compromise a lot, it's a good sign that you need a better tool for this particular task.

Re:Then learn the language better, stupid

[shutdown -p now]

C++/CLI implements full featured RAII for .NET objects on top of IDisposable, merely by mapping Dispose() to destructor, and applying normal C++ rules for that.

Re:Then learn the language better, stupid

[devent]

No, this is the level of programmer who reads the whole statement and is not picking something out of context. m50d clearly stated that if you want a file to be closed at a specific time, you just close it. But if you don't care when the file is closed, then leave it to the GC. Anyway, the GC is about memory management and not about resource management. Even in C++ you need (or should) to close a resource right after you finished to use it, otherwise the OS can't reclaim the resource. There is no difference between managed and native languages.

Re:Then learn the language better, stupid

[smellotron]

If you have cycles of pointers which are claiming "ownership" of each other then maybe you need to revisit your design, re-read the chapter on RAII.

I agree; the biggest problems I have had with trying to "retrain" people used to GC is that memory management is all about ownership in C++. If you can't identify ownership as a DAG, chances are that something in the design is wrong already, regardless of the language. Once the ownership is there, the memory management just falls into place.

Re:Then learn the language better, stupid

[smellotron]

Ah, I see the problem: you're a Windows programmer. You must be. No other platform cares nearly so much about whether a file is closed before allowing another process to open it.

File I/O matters on every platform. If you have a file open, you are using OS resources. If the contents of your file are buffered, you are further gambling with race conditions due to human interaction. Windows merely "enhances" these costs and risks.

Re:Then learn the language better, stupid

[smellotron]

Not all relations between objects have clear ownership semantics. There's nothing fundamentally wrong with cycles when they correctly model your domain.

If the domain is modeled by cyclical references that do not express ownership, then use plain old boring pointers. But those pointers are pointing to dynamic memory, you say? Well, something else must own them (for the sake of RAII). Heck, a simple vector-of-shared-pointers solves the ownership and cleanup problem. Chances are there is some reasonable place where you could squirrel away the ownership obligation without mucking up the domain model.

Re:Then learn the language better, stupid

[tokencode]

So true, if you expect garbage collection to do all the work you will be severly disappointed. If you're using .NET so that you do not have to worry about clean-up you're using it for the wrong reason. All languages offer a trade-off, and I think the real reason nativecode has never really gone away AND is coming to the forefront is really dictated by the hardware. We're back in a world LIMITED hardware specifications with the mobile devices so you HAVE to be efficient. The same is true in consoles where you have identical, limited hardware you need to make the most of. In the business world (and in the gaming world, take it from John Carmack himself) ram performance doesn't always matter. If I can program something in 1/2 the time and I need twice the horse-power because its inefficient, sometimes thats an ok trade-off to make. I believe id software switch their render farm from CUDA to x86, even though the x86 was much less effiecient and they needed more equipment, because it was simpler to write the code. Faster isn't always better when it comes at the cost of time itself.

Re:Then learn the language better, stupid

[GauteL]

"Finally, Python lets you write code like this:

with open('foo.txt') as inputfile: process(inputfile)

which explicitly garbage-collects inputfile as soon as it falls out of scope. If you use that pattern you'll never need to close the file (and it would in fact be a pretty dumb thing to do)."

This is actually what most (all?) C++ File I/O libraries do and certainly the standard fstream libraries. As long as you create your file stream on the stack (and I can't think of a reason not to), the file handles will be taken care of by RAII. As soon as it goes out of scope, the destructor will be called, which will close the file handle.

This Tutorial actually explicitly closes the file handle, but I wish it didn't, or at least made it explicitly clear that it isn't necessary as long as you use scope efficiently.

Instead you have to make do with this statement.
"In case that an object is destructed while still associated with an open file, the destructor automatically calls the member function close()."

Re:Then learn the language better, stupid

[dwpro]

I don't understand this criticism. Explicitly doing something that will be done automatically is more code, more chance for errors, more bulk. If it truly does not matter, then your criticism is unfounded. I think your issue is probably that it most likely does matter if you have an open file handle out there, and I would agree.

Re:Then learn the language better, stupid

[Just Some Guy]

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

If an object is still in scope and referenced such that you can still access its properties, then there's no way it can be collected anyway.

Re:Then learn the language better, stupid

[benhattman]

I'm a fan of GC, but I worry when I read most of the comments about it. It's a great tool for ensuring memory correctness of your program. The fact that when something goes haywire in my java program, I can immediately skip the "dangling pointer/orphan pointer/buffer overrun" angles to debug the program is fantastic. Equally great is that when I read someone else's junky code, I don't have to verify they are releasing memory correct.

That said, the assumption that it's appropriate to completely ignore those problems now is galling. This isn't like the move from assembly to C where you can trust the compiler unless you really really really care about performance (is this loop taking 18 cycles or 17?). Ignoring resource allocation and deallocation can cause true execution errors, even when the memory itself is not being corrupted.

Re:Then learn the language better, stupid

[zeroshade]

If your resource is throwing upon initialization in C++ then you probably have an exceptional situation that you need to handle. If your resource might throw, then you either put it in a try...catch block or just let it take the program down, depending on what would be better based on the situation that could cause a throw.

If the resource is throwing just for a failure to acquire or some other common case, then you have a badly written library. The overuse of exceptions is something I hate about Java. You should throw only in an exceptional situation, that's why it's called an "exception". Throwing because of a common error (ie. throwing for a failure to open a file) is just stupid.

Re:Then learn the language better, stupid

[warrax_666]

Instead you have to make do with this statement.
"In case that an object is destructed while still associated with an open file, the destructor automatically calls the member function close()."

What if "exceptions" is set and the file cannot be closed? Will the close() call throw in that case?

If so, the program just terminated() because it couldn't close a handle. But hey, at least it's not entered "undefined behavior" territory, eh?

Re:Then learn the language better, stupid

[rgviza]

I learned this in 1997.

There hasn't been a GC invented that does what it's supposed to. I had a MS engineer (that helped write IIS) tell me at a MS conference on campus in Redmond : "Don't ever rely on garbage collection; _explicitly_ clean up your objects. The GC is nothing but a marketing tool to sell product. It doesn't really work."

You ever work somewhere where the NT/2000 servers needed to be rebooted daily? The code was written by sloppy programmers. It wasn't the operating system.

Re:Then learn the language better, stupid

[Duhavid]

"If an object is still in scope and referenced such that you can still access its properties, then there's no way it can be collected anyway."

True. I do know we had memory leaks, though. We ended up buying a leak detection program and using it to get rid of them.

Why is C++ unmanaged?

[Billly Gates]

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?

[maxwell demon]

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

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

Re:Why is C++ unmanaged?

[Anonymous Coward]

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

Re:Why is C++ unmanaged?

[Anonymous Coward]

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?

[whiteboy86]

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?

[Anonymous Coward]

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?

[maxwell demon]

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?

[GooberToo]

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:Why is C++ unmanaged?

[lgw]

Google types C code into cpp files. It's hideous. No wonder they love Python.

Re:Why is C++ unmanaged?

[GooberToo]

Not far from the truth.

Any time I find a developer who wants to blindly adopt Google's coding guidelines, very rarely have I not found a poor developer.

Just because it makes sense for GM to have an assembly line of robots doesn't mean it means sense for your grandmother to make her up upside down pineapple cake using the same equipment. And yet, that's exactly what these programmers are recommending. They never seem to be bothered to think WHY Google might have those restrictions and/or guidelines.

Re:Why is C++ unmanaged?

[Anonymous Coward]

Isn't Java the dominant language at Google, eBay, Oracle, etc?

Re:Why is C++ unmanaged?

[Desler]

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.

Re:Why is C++ unmanaged?

[GooberToo]

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 this decade, accompanied with references to modern methodologies and development guidelines. He thought very poorly of me and the corrections. This isn't an exaguration.

Re:Why is C++ unmanaged?

[Desler]

That's what is always funny. The most outspoken critics of C++ are usually those most ignorant of the language. Hence why we have all sorts of people in this discussion whining about having to do manual memory management in C++ whilst being pig ignorant of the built-in features and design patterns that basically eliminate most of this burden.

Re:Why is C++ unmanaged?

[TemporalBeing]

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.

Re:Why is C++ unmanaged?

[gbjbaanb]

their guidelines specifically disallow the use of RAII

they do what? no really, what? what?!

seriously?

do you have a link, I can't even imagine such a nonsense being used by my company, let alone a supposedly technically excellent one like Google.

Re:Why is C++ unmanaged?

[lamber45]

Not strictly true. First of all, you can use Mono instead. Secondly, if managed code is exposed as a COM object, you can interact with them from native code compiled with some other compiler (such as Borland or Intel or g++). Finally, if you're feeling really adventurous, you could try dynamically loading mscoree.dll and invoking CLRCreateInstance, similar to creating a Java runtime for JNI or an embedded perl instance.

Re:Why is C++ unmanaged?

[joaommp]

Isn't it possible with Mono and the upcoming version of Codegear's C++ Builder?

Re:Why is C++ unmanaged?

[SplashMyBandit]

Your point is correct. Also note that mixing managed and unmanaged code in C++.NET is awkward to say the least (I've had to do it on occasion).

Re:Why is C++ unmanaged?

[SplashMyBandit]

If you allow your code to divide by zero (or pass any other shitty data from the receiving interfaces to the internals) then you *suck* as a programmer. Always validate your preconditions and handle the issue early. Incidentally Google uses a of languages, including a huge amount of Java (because they need to get stuff done quickly, and can always parallelize to more machines for performance [although well-written Java running in server mode often beats C++ and C, just not FORTRAN, betcha didn't know that]).

Re:Why is C++ unmanaged?

[larry bagina]

LCC can generate .net code (that's c, not c++). It may be deprecated and removed now, but LLVM used to generate .net CLR assembly (which would, in theory, work with any front end, from gcc to clang to brainfuck).

Re:Why is C++ unmanaged?

[tibman]

I still printf in c++... Come at me bro

Re:Why is C++ unmanaged?

[shutdown -p now]

So, pray tell, what exception type do you catch in standard C++ to handle division by zero?

Re:Why is C++ unmanaged?

[shutdown -p now]

It's not quite true. You can take almost any standard C++ code, and compile it to a managed assembly with VC++. You can also use C++/CLI language extensions to access .NET class libraries, but you don't have to do so. And C++/CLI is similar to C# in many aspects - largely due to sharing the same CLR object model - but it has many important differences, e.g. Full fledged RAII.

Re:Why is C++ unmanaged?

[smellotron]

The most outspoken critics of unpopular things are usually those most ignorant of the thing.

FTFY. Somehow this now reminds me of grade school.

Re:Why is C++ unmanaged?

[maxwell demon]

Not strictly true. First of all, you can use Mono instead.

Does Mono come with a C++/CLI compiler now?
Not that C++/CLI were C++, anyway (although Microsoft will tell you differently). It's a language based on C++, just like C++ is based on C.

Secondly, if managed code is exposed as a COM object, you can interact with them from native code compiled with some other compiler (such as Borland or Intel or g++).

Of course. But that's not using .NET from C++, that's interfacing with .NET code from C++. That's a very different thing. Also, does COM work on any non-Windows platform?

Finally, if you're feeling really adventurous, you could try dynamically loading mscoree.dll and invoking CLRCreateInstance, similar to creating a Java runtime for JNI or an embedded perl instance.

Yeah, and I could also "simply" implement C++/CLI based on g++, or something like that ... at some point, the options become more of theoretical nature, unless you have tons of free time to spend.

Re:Why is C++ unmanaged?

[maxwell demon]

OK, that is new to me. I haven't looked much into LLVM. So all they are lacking is a C++/CLI front end.

Re:Why is C++ unmanaged?

[DrVxD]

I suspect you'll find that the OP meant ".Net is available only to people using MSVC++ (as opposed to other C++ compilers)".

Re:Why is C++ unmanaged?

[insane_coder]

SIGFPE. You can do some trickery to make your signal handler turn that into an exception somewhere.

Re:Why is C++ unmanaged?

[shutdown -p now]

Given how limited signal handlers are in what they are allowed to do, can you describe said trickery? I'm pretty sure you can't just throw right from the handler. What other portable solutions are there?

Re:Why is C++ unmanaged?

[Desler]

Here you go. Relevant piece:

In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method.

Yes, let's not do our work in the constructor, let's make it so that the user has to know to call an Init() method to not get an object in a bad state. So basically they have some really lame justifications for this and yet all this does is make the code more error prone since you have to know to call an extra method just to get your object constructed properly which is fucking dumb.

Re:Why is C++ unmanaged?

[Desler]

Why would you not be checking your divisors for being zero before doing division? Why are you waiting for an exception to happen instead? I'm not seeing any reason other than laziness to not make sure you aren't doing bad operations before you do them. And before you say "for performance" or some nonsense, that exception handling causes a far larger performance hit than just simply checking that your divisor isn't zero.

Re:Why is C++ unmanaged?

[gbjbaanb]

so call Init() inside your constructor :)

Re:Why is C++ unmanaged?

[shutdown -p now]

As well, SIGFPE is non-portable for divide-by-zero handling, since ISO C does not guarantee it to be raised at all. Here's what the ISO spec says pertaining to SIGFPE:

An implementation need not generate any of these signals, except as a result of explicit calls to the raise function. ... The complete set of signals, their semantics, and their default handling is implementation-defined;

and man signal in Linux:

Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal.

Re:Why is C++ unmanaged?

[larry bagina]

I don't see the MSIL code in the svn, so it may be gone now. Anyhow, llvm 2.6 (on my debian machine) still supports MSIL as an output format.

llvm-g++ -c -emit-llvm file.cpp
llc -filetype=asm -march=msil -o test.s test.o

Will generate .net assembly code. No idea if it works beyond that.

Re:Why is C++ unmanaged?

[lgw]

There's a special dispensation for printf. Even the Pope uses printf, for it is holy.

Re:Why is C++ unmanaged?

[shutdown -p now]

I don't know - I was merely replying to a post up above in this thread which has stated:

if you fear crashes then you could use C++ exceptions, then you can divide by zero or do other bad stuff

which is plainly not correct.

In context of managed vs native safety (which is where the thread began), this is somewhat relevant in that if you forget to check for div-by-zero explicitly, in native code this is undefined behavior, while in managed this is a well-defined exception. In practice, this is not particularly relevant because, as you rightly note, you wouldn't ever catch such an exception; and in native, all platforms I've seen will immediately terminate the process (or raise a signal, with default handler also terminating the process), so the behavior is defined in practice and provides no vector for exploits (unlike out-of-bounds pointers etc).

Re:Why is C++ unmanaged?

[Anonymous Coward]

That would be interesting, do you have a link? They've been trumpeting 64-bit Delphi, but other new RAD Studio XE2 features (particularly C++Builder features) are not as prominently advertised, at least as far as I've seen.

- T

Re:Why is C++ unmanaged?

[Anonymous Coward]

Are you kidding?

The syntax of C++ is a horrible mess of shit.
The speed of Haskell, OCAML and many great languages is between C and C++, so C++ is slower,
and why slap even more shit on top of that upside-down pyramid that is C++, when you can have a proper language that is not a PITA to even look at do it right from the start?

C++: All the disadvantages of C and Java combined!

After coming from BASIC and Pascal as a beginner, and Java, JavaScript and Python for my first job, I went straight to Haskell... Avoiding the whole damn mess of C-like languages.

C can stay because of its usefulness for low-level code. Kinda like the Assembler of today.
But C++ can no longer can, and some (like me) might argue never could, be considered a serious language.

Conclusion: Elegance, speed and freedom are not mutually exclusive. So get yourself some modern serious language, kid!

Re:Why is C++ unmanaged?

[rgviza]

Actually Linus has no issues with C++, as long as it's not used in the kernel. C++ is too slow for kernel development because of all the object marshaling.

He says for userland coding it's fine. The negative side of OOP is magnified in a kernel making it too slow.

User programs spend almost all of their time waiting for input.

Your co-worker needs to read the entire article/email instead of stopping at what he wants to hear. Maybe he wouldn't be so irrational.

Carmack

[bonch]

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.

Re:Carmack

[Jthon]

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

[lehphyro]

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

[Cutting_Crew]

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

[Anonymous Coward]

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

Re:Carmack

[WankersRevenge]

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

[Cutting_Crew]

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

[whiteboy86]

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.

Re:Carmack

[bill_mcgonigle]

VMs just don't play well in embedded environments.

Yet, Android seems to be doing just fine.

Re:Carmack

[Joce640k]

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?

Re:Carmack

[Amorya]

It's in Xcode 4.2, which is still in beta.

Re:Carmack

[mini me]

http://clang.llvm.org/docs/AutomaticReferenceCounting.html

The simple version is that the compiler knows when you need to release your object, so now it automatically inserts the code for you, instead of you doing it manually. The result is code that looks like garbage collected code, but without the overhead of real garbage collection.

Re:Carmack

[0123456]

Another issue, at least in Java, is the need to allocate a fixed size chunk of RAM to the application rather than have it increase and decrease as memory is used and freed. Even if the application is only really using a quarter of that memory and the rest is just temporary variables that should have gone on the stack.

Re:Carmack

[harl]

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

I've never understood this position. It always reads as, "Since we have more power we can be inefficient with it."

Re:Carmack

[0123456]

I've never understood this position. It always reads as, "Since we have more power we can be inefficient with it."

If managed code halves your development time while increasing the CPU load from 5% to 10% when it's running, then that's a big win in most cases. And, in general, C++ development is most definitely slower than Java if only due to the verbosity and compile times.

Re:Carmack

[Anonymous Coward]

Sure, as long as you can ignore performance and battery life.

Re:Carmack

[mmcuh]

Except that Android phones have abysmal battery life most of the time.

Re:Carmack

[Desler]

Great. So that means you can't do much more than trivial little programs. Woohoo?

Re:Carmack

[Lunix Nutcase]

If managed code halves your development time

Then you are dealing with incompetent programmers.

while increasing the CPU load from 5% to 10% when it's running

You are in some cases many orders of magnitude off. 5% to 10% is ridiculously underestimating the overhead.

And, in general, C++ development is most definitely slower than Java if only due to the verbosity and compile times.

This is a joke right? Complaining about C++ being verbose and then trying to hold up Java as a counterexample? Really?

Re:Carmack

[Darinbob]

I disagree with (b). Garbage collectors 30 years ago may have had these features. But modern garbage collectors are very efficient and can be more efficient than manual/semi-automatic memory management. A garbage collector that scans/compacts the entire heap every few seconds or which causes disk thrashing is either using an archaic design or you've got an application that is not well suited to GC (or even standard malloc).

Re:Carmack

[lehphyro]

No, that means that virtual machines could and did dominate mobile platforms since the start of mobile computing in cellphones and things like that.

Re:Carmack

[surgen]

but is the VM overhead responsible for the battery life issue?

Re:Carmack

[harl]

Those are some completely unrealistic numbers. They do however prove your point so I guess they're good for that if nothing else.

Re:Carmack

[bonch]

No, its battery life and performance are not doing fine.

Re:Carmack

[bonch]

Correct. Cocoa's memory management conventions have been made an official part of the Objective-C language, and so the ARC compiler can add the memory management calls for you.

Re:Carmack

[bonch]

Well, you don't write assembly language, do you? We use higher-level compilers because we have the computing power to do so.

Re:Carmack

[HiThere]

???
Garbage doesn't, and is not intended to, release in a timely fashion. OTOH, it will release anything that has a delete method (as defined by the language).

You do, in certain circumstances, need to be able to disable a garbage collector. So what? You don't always use enums either.

And "freeing resources is mostly a non-issue in C++"??? I'm sorry, but this just sounds too strange to understand.

OTOH, the structure of the C/C++ language does make garbage collection extremely inefficient, because it's impossible to determine whether some integer will turn out to hold a pointer. This means that huge amounts of extra analysis need to be undertaken. (Personally, I think that C/C++ should have standard garbage collector that can be turned off either for sections of code or for the entire program. And that it should immediately disable itself if an integer is ever cast to a pointer.)

But "smart pointers" of various flavors are, to speak as favorably as I can about them, hideous kludges. They don't really solve the problem, though they certainly reduce it.

Re:Carmack

[Homburg]

But with the added overhead of reference counting, which is an additional method call every time an object pointer is copied or passed or returned from a function. This is a bit of a problem in C++, where method calls can be inlined; with Objective-C's more heavyweight method calls, I would think this would be a fairly big overhead. I'm sure it's a much larger overhead than real garbage collection (although it does have the advantage of being deterministic).

Re:Carmack

[bill_mcgonigle]

Except that Android phones have abysmal battery life most of the time.

I have a Nook Color that lasts for several days on a charge. Bigger screen than any phone too.

I don't have an Android phone because, indeed, the battery life tends to suck (my LG 'feature-phone' lasts 4 days) and hardware encryption is just barely coming out, but I don't think you can blame a VM for the power budget of radio sets.

Re:Carmack

[Arker]

Actually you can do a hell of a lot in 32k. My first computer only came with 2k!

You just cant do much if you are relying on the absurdly wasteful programming environments that are so popular today. In fact it appears to me that yearly increases in computer power have been used almost exclusively to shield todays programmers from the need to actually learn to program. Excluding video/graphics stuff that would have required absurdly expensive specialty hardware at the time, I did pretty much the same things with that computer that I do today with a computer that has one million times as much RAM, and similar improvements on all the other specs, and it worked just fine.

Re:Carmack

[YoopDaDum]

It doesn't look like it. On my Android handset the display dominates power consumption by far, then the various radios (wifi and cell). The first app is far below at a couple percents only. I don't use games thought, and games can be taxing. But I would assume heavy games are the first users of the native toolkit. If it's typical then the JVM impact is small.

The poor battery performance of a lot of Android phones comes more from a focus on the latest big screens and fast SoCs, and not much low-level hardware/software optimization (time to market is more important that slow and labor intensive platform optimization) than on the JVM impact IMHO.

Re:Carmack

[Lord_Jeremy]

FWIW I've heard from friends inside Apple that a real SDK was intended all along, but the logistics took a while to settle on. Also, I've been told that as a product concept, the "iPad" effectively existed way before the iPhone. As early as 2001 Apple was toying with the concept of a highly portable computing device geared toward media consumption and communication, as opposed to just about every PDA or tablet-like device that had existed up to that point. It was decided that the technologies and consumer interest didn't exist to make such a device viable yet. Eventually, the concept was mutated into the development of the iPhone.

Re:Carmack

[Lord_Jeremy]

I've always found it so amusing that Java IDEs have refactoring functions designed for spawning getters/setters and the like. I like objective-c's solution: getters/setters are required, but type a pair of lines and the compiler generates them for you. The way it's actually invoked also makes an object's public interface a little easier to grasp.

Re:Carmack

[AmiMoJo]

I've never understood this position. It always reads as, "Since we have more power we can be inefficient with it."

Inefficient in terms of resources, but very efficient in terms of code re-use and rapid development.

Re:Carmack

[harl]

Apples and oranges.

Assembly is lower level than either C++ or Java.

C++ and Java are the same level.

Re:Carmack

[harl]

You're saying inefficiency is good because we can build an even greater number of inefficient objects? That just makes the problem worse. It's a downward spiral.

Re:Carmack

[badkarmadayaccount]

More like, non-optimized implementations. Tell me, how many implementations are cache and superscalar aware?

Re:Carmack

[FooBarWidget]

A garbage collector can compact memory in order to fight memory fragmentation.

False dichotomy

[MrEricSir]

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

[EraserMouseMan]

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

[fusiongyro]

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

Re:False dichotomy

[Anonymous Coward]

Wow, you're dumb. What do you think CLR is?

Re:False dichotomy

[Anonymous Coward]

Um? C# certainly does. I sure hope you aren't a C# developer... sigh... thats whats wrong with coders today.

Re:False dichotomy

[elsurexiste]

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). Python is pure bliss.

I expect a lot of bashing because of this "form over function" stuff I'm saying (in Slashdot, no less!), but I think that programming languages are languages nonetheless, and therefore can be beautiful or ugly. We have moved from "anything goes" into "if I don't like reading it, I don't like using it". Why should we use a language that causes eye bleeding?

Re:False dichotomy

[Anonymous Coward]

No it's not. The application is compiled to CLR at compile time and at run time it's compiled to native code for the platform in which it's running.

Re:False dichotomy

[Palshife]

Yes. CIL is JIT compiled by the CLR. Just like the JVM does with Java bytecode.

The CLR is a VM. You can't ask the machine to load CIL. It has to be interpreted by the CLR first.

Re:False dichotomy

[Palshife]

Eyesores fade with continued use, in my opinion. When I first started using Python I swore up and down that I couldn't stand whitespace indentation to denote code blocks, but now it's as natural as can be.

I'll give it to you though. Objective C has a very wide mishmash of syntax paradigms. It feels so much like metaprogramming (I guess that's not too off the mark since it's effectively a runtime on C with macros and code preprocessing). I still like it though. It lends a certain elegance.

Re:False dichotomy

[Anonymous Coward]

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

Hahahahaha

It's clear from that statement that you haven't actually done development in Objective C or C#/Java - and, based on the latter half of the comment, I'm guessing it's C#/Java.

Re:False dichotomy

[MtHuurne]

I've never used Vala, but Objective C is certainly not as easy as Java. Especially if you target iOS, where you don't have garbage collection. The main difference is that bugs are much easier to spot in Java: much is checked at compile time and if something goes wrong at run time you get a stack trace that is at least semi-informative. In Objective C, a lot of problems only show up at run time and then you might get useless stack traces, especially if the top of the stack is in a library of which you don't have the source code (again, iOS). Even calling a non-existing method is a run time error; for a direct call you do get a warning from the compiler, but if you call via @selector, one ":" too many or too little only is the difference between running fine and a crash.

I do think (hope?) you're right in theory, but Objective C vs Java is not a valid example in my opinion.

Re:False dichotomy

[HarrySquatter]

The CLR is a VM. You can't ask the machine to load CIL. It has to be interpreted by the CLR first.

CIL is never interpreted. It is always JIT compiled.

Re:False dichotomy

[MrEricSir]

Especially if you target iOS, where you don't have garbage collection.

Yes, you do. It may not be mark and sweep as in Java, but refcounting is garbage collection nonetheless.

Re:False dichotomy

[Anonymous Coward]

The CLR is not a JVM.

The JVM is a bytecode interpreter. It reads bytes of bytecode and runs them within its own process space. That's why it's "slow".

The CLR is a memory manager and JIT compiler. Everything is compiled to its own process space, cached as necessary, and run as a native executable. It's basically a build/run automation environment. Once things are fully compiled in .Net and are cached (or are properly installed into the GAC), they're much faster than Java because they're basically native.

The .Net CLR runs things through a JIT MSIL compiler during the load library operation and spawns a process space for the newly-generated native executable objects(think .o files, not OO source objects). Then it links that native executable against its dependencies (the runtime libraries, mostly the .Net framework). Then it executes everything (natively!) as it normally would. As new pieces are called, they're JIT-ed and dumped into the in-memory process, then called as native code. Once these objects are built, they can be cached as native code (which is why the first load of a new .aspx page is slow, then later it's fast). Commonly used libraries that are installed system-wide are in the Global Assembly Cache (the dreaded GAC), which is a big-ass persisted cache of pre-compiled-to-native memory-managed libraries.

Re:False dichotomy

[Anonymous Coward]

I do not know the details of the CLR; I am pretty sure your description is correct. On the other hand, memory management for .NET still uses a garbage collector and overall has a pretty similar language runtime to Java's. Also, the JVM JIT-compiles methods. It only interprets when it is faster to do so (i.e. code that only gets run once is not worth compiling). I believe the "server"/"client" VM selection changes how aggressively it compiles code.

Re:False dichotomy

[sco08y]

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.

Re:False dichotomy

[HiThere]

Vala is a probably incomplete language with definitely incomplete documentation. Whenever I tried to look up how to do something, the documentation didn't cover it.

Objective C is quite interesting, but also suffers from poor documentation. Lots better than Vala, but ... well, poor. Possibly this isn't true if you're programming on an Apple machine. (I *am* quite interested in Objective C, but the last time I tried to use it the examples wouldn't compile for reasons that I couldn't determine. OTOH, at that same time C++ was throwing fits, so it may just have been Debian Sid breaking things.)

Re:False dichotomy

[Anonymous Coward]

CIL is never interpreted. It is always JIT compiled.

By the VM.

Re:False dichotomy

[SplashMyBandit]

LOL, quite a fail dude.

Re:False dichotomy

[Anonymous Coward]

Virtual machine runtime, asshole. Not simply "runtime"

Thanks for not reading,

Re:False dichotomy

[Anonymous Coward]

And you don't know the difference between a runtime and a vm

Re:False dichotomy

[Anonymous Coward]

...because the CLR is a virtual machine? It's an abstract execution environment that provides as much, of not more, than the JVM.

Re:False dichotomy

[Anonymous Coward]

And by headaches you mean "literally nothing" I suppose, for 99% of use cases.

Re:False dichotomy

[Anonymous Coward]

Learn to read. Parent poster specifically said "virtual machine runtime". Objective C is normally compiled to native code. The Objective C runtime is its runtime library, which handles language features which can't sensibly emitted as assembler instructions, like e.g. dynamic method resolution. In that sense, it is similar to the C++ runtime library, although the latter does different things since the languages are after all different.

Re:False dichotomy

[larry bagina]

Apple documents the Objective C language and their runtime quite well.  If your example involved GNUStep, GNUStep is probably to blame.  The last time I looked at it, compiling and linking were fairly painful.

Let's see if this is lame or not...

$ cat hello.m
#include <stdio.h>
#include <objc/Object.h>
@interface Hello : Object
+(void)world;
@end

@implementation Hello
+(void)world
{
  printf("Hello, World\n");
}
@end

int main(int argc, char **argv)
{
  [Hello world];
  return 1;
}
$ gcc hello.m -l objc -o hello
$ ./hello
Hello, World

Re:False dichotomy

[MakinBacon]

No it's not. The application is compiled to CLR at compile time and at run time it's compiled to native code for the platform in which it's running.

Which is almost identical to Java on the JVM.

Re:False dichotomy

[IWannaBeAnAC]

all languages have a runtime environment, but it isn't necessarily a virtual machine!

The runtime environment for C++ is often fairly simple, it handles the operating system program entry point and passing arguments to the main() function, as well as initializing parts of the standard library.

The runtime environment for Java is a bit more complicated, it usually involves a bytecode interpreter.

But that is mostly a choice of the implementation. Native compilers for Java exist, and so do C++ interpreters.

Re:False dichotomy

[siride]

Except for how it doesn't really at all. .NET is really more of a fat runtime than a VM, despite claims to the contrary. The code is compiled to native either in a separate step with NGen or during program start up (and then cached for later startups). The managed stack is the same as the real stack. You can have unmanaged frames on that stack without problems. There is a separate heap for managed objects, but what's the difference between that and, say, a memory pool implemented in C++? .NET also doesn't really care much for abstracting away the underlying OS APIs. WinForms is a thin (and crappy) wrapper around Win32 (which you can call directly from .NET if you want to). So since there is no interpreted code, no isolation, no emulation...what, exactly makes .NET a VM?

Re:False dichotomy

[siride]

He said "virtual machine runtime" not "runtime" by itself.

Re:False dichotomy

[MrEricSir]

Most of Vala's documentation is incomplete, but so what? It's all just bindings, you can find docs for the underlying calls in Gtk, Glib, etc. docs.

And if you want more details on the bindings, you can always look up what you need on Valadoc:
http://valadoc.org/

Re:False dichotomy

[phantomfive]

lol this is a hilarious comment, because for the first 10 years of the existence of C, on the primary criticisms against it was the ugly syntax. What's with the ugly braces everywhere? What's wrong with BEGIN and END? How can you use a single '=' to mean assignment, and '==' comparison (of course, a real language would use :=)? You can't hardly call a function without looking like you're swearing. It goes on and on, but really, you only like it because it's your preference, not because it's actually more beautiful.

Re:False dichotomy

[Palshife]

What's your point? The CLR loads CIL and craps out native code at runtime. It's a host environment without which CIL cannot execute. You're splitting hairs to say that it isn't a VM.

Re:False dichotomy

[elsurexiste]

Heh, as a friend of mine told me, beauty and ugliness are relative concepts, not intrinsic. C's syntax is beautiful... compared to some other crap I read through my life. I liked Pascal's begin/end and the "for" construct, but eventually I grew tired of writing so much text. COBOL took verbosity to the extreme. C offered instead small yet functional constructs. The braces were part of that simplicity. The "=" and "==" issue is idiotic, agreed. As to my preference, that's the eternal question... Is stuff beautiful because you like it? Or do you like stuff because it's beautiful? :)

Re:False dichotomy

[Anonymous Coward]

It does not have virtual machine runtime.

Re:False dichotomy

[Anonymous Coward]

Hopefully you understand the difference between a runtime and a virtual machine after at least reading the introduction on the page you pointed out? Objc is not interpreting bytecode or abstracting the hardware in any way (say, emulating registers). It's only providing the basic service you need for features compiled languages lack, like relocating/relinking code after loading a class from disk, adding methods to classes (or replacing them, aka swizzling) and stuff like that.

Re:False dichotomy

[Carewolf]

Just-in-time compilation is a form of interpretation. It is not a compiler, it just does some compiler-things internally. Anyway, whatever you may think, C# and Java are identical in that fashion. Their interpreters all use just-in-time compilation. In-fact even javascript-interpreters in webbrowsers use just-in-time compilation these days.

Re:False dichotomy

[Lord_Jeremy]

As an experienced Obj-C programmer, I grappled with some of your complaints a long time ago. It's not the job of the language to protect you from careless mistakes. Moreover, Obj-C and Java have two very different philosophies and goals. Complaining about getting a run-time error when you've effectively mangled a function pointer is meaningless when comparing the language with Java, which has nothing even resembling performSelector or function pointers. The main difference between those two languages is not the usefulness of the stack trace (or more likely exception report with Java - practically everything throws exceptions) but that one is being interpreted and the other is more or less native.

Re:False dichotomy

[MtHuurne]

In Objective C you have to manually retain and release, unlike for example Python where the refcounting is done by the language itself (Python has mark-and-sweep too, but you can disable it at runtime and break reference cycles manually). Recently automatic reference counting support was added to Clang, if that is transparent enough to the user I think it would be valid to call that a form of garbage collection, but I haven't been in a situation where I could use it yet.

Re:False dichotomy

[MtHuurne]

I'm somewhere between beginner and experienced myself. Most of the time retaining and releasing is an automatism, but there are tricky cases, such as discarding an object on an observer notification from that same object, that still require being careful. Also, every once in a while I do still make mistakes such as forgetting to unregister a delegate before it's deallocated and it can take a while before I notice that I'm looking at bogus data in the debugger. In Java I spent less time debugging because there are less mistakes you can make and if you do make a mistake, the error report you get is at a higher level and therefore easier to interpret. You don't have to wonder whether you're looking at a real object of type X or just a bunch of random bytes pointed to by an X-pointer.

Java's reflection can do things similar to performSelector, but its syntax is very verbose, so in practice you'll end up declaring explicit interfaces for everything that you would handle with an implicit interface in Objective C. This is the main drawback of Java in my opinion: in order to get the "no unpleasant surprises" benefit you have to spell everything out for the compiler. In my ideal language the compiler would detect the implicit interfaces you are using and make a fuss if you pass something that doesn't fulfill the required interface ("argument of type X is not guaranteed to provide method M").

The original poster claimed that Objective C is as easy as Java without requiring a VM, so I think that makes the comparison meaningful in this context. It might be possible to get most of the benefits from languages like Java by having a smarter compiler instead of a VM, but I haven't seen it happen yet.

Re:False dichotomy

[Anonymous Coward]

He said *virtual machine* runtime.

Re:False dichotomy

[benhattman]

CLR == Common Language Runtime ~= Common Language Virtual Machine

Re:False dichotomy

[badkarmadayaccount]

No cycle detection - no GC.

Re:False dichotomy

[HiThere]

The so what is, it's basically unapproachable unless you are coming from a C/glib background. And the last time I checked the documentation didn't even tell you how to build a struct, or why you should want to. (I presume for the same reason that you would want to in C, but that's a guess!)

As for the bindings.... Some of them are decently documented, and other times you are left with the name of a function, and NO description of what it does, why you might want to use it, or when you definitely shouldn't use it. So you trace them back to try to find things out and...well, eventually you end up at C code. That's poorly documented in the code. (Yes, that is the authoritative source. but this doesn't make it an "easy read" when you're trying to decide if this is the function you need.)

I'm sorry. Compare this with Java, Python, C, C++, D, or even Lisp documentation
OTOH, Vala doesn't claim to have reached the 1.0 version yet. Last I checked it was 0.12. So that the documentation should be incomplete isn't surprising, but it does mean that it's MUCH too soon to start pushing the language.

Re:False dichotomy

[HiThere]

It's not slick, but it's not bad either. However if Objective-C couldn't handle "Hello World" reasonably, I wouldn't consider it at all interesting.

My interest if more along the lines of converting back and forth between utf-8 strings and ubyte arrays, reading and writing contiguous areas of memory to disk files at defined initial byte offsets, allocation and initialization of instance variables in classes, syntax of passing class items between routines, garbage collection independent of GnuStep/AppleStep/Cocoa/etc. (I.e., language facilities for garbage collection, not that of libraries that presume classes that require features that interfere with what I'm doing. Etc.

FWIW, after reading the documentation that I could find on NSString I couldn't decide on whether I could get a C array of unsigned bytes out of it. Did it try to convert the multi-byte characters or not? Etc. (I could have gone digging, but I preferred to switch to a language where it was easier to figure out how to do what I wanted. D. But D lacks easy two-way access to C libraries, so at some point I'll need to convert it to Ada, C, Objective-C, Vala, or something I haven't figured out. Because of the heavy use of class instance variable, C is implausible. (I also don't like the x->y syntax, but I suppose I could adapt to (*x).y, even though it *is* incredibly ugly.) Ada is verbose, Vala is too beta, so Objective-C is something I'm strongly considering. But my classes would descend from Object, not from NSObject, unless I come to a radically different understanding than I currently have. Does Objective-C, as opposed to NSObject, have something similar to smart-pointers and weak-pointers? If not, I'll need to look into how easy they would be to port. Real garbage collection is probably impractical in any C descendant language, due to the ability to convert pointers back and forth between integers, but smart-pointers combined with weak-pointers could suffice for my purposes (if they have usable syntax).

Re:False dichotomy

[sco08y]

all languages have a runtime environment, but it isn't necessarily a virtual machine!

The runtime environment for C++ is often fairly simple, it handles the operating system program entry point and passing arguments to the main() function, as well as initializing parts of the standard library.

Even an assembler will link in those libraries that you're talking about. Objective C clearly has a runtime that is deeply involved with the application, and imposes a runtime model that C doesn't have, and that C++ doesn't have unless you use RTTI.

The runtime environment for Java is a bit more complicated, it usually involves a bytecode interpreter.

But that is mostly a choice of the implementation. Native compilers for Java exist, and so do C++ interpreters.

But you still have to have a runtime to handle dynamic method dispatch, especially if you use reflection, making the Java and ObjC runtime requirements about equivalent. (They both have, in their present incarnations, garbage collection, for example.)

Re:False dichotomy

[IWannaBeAnAC]

Even an assembler will link in those libraries that you're talking about.

Assembler has a main() function? That must be new, didn't have one back when I used to do a bit of assembly. In the old days, the loader simply used to jump to a specific address in the executable and then you were on your own.

Even an assembler will link in those libraries that you're talking about. Objective C clearly has a runtime that is deeply involved with the application, and imposes a runtime model that C doesn't have, and that C++ doesn't have unless you use RTTI.

Your point is? The runtime can be a substantial piece of code (eg a VM) or it can be simple (eg in C), or it can be entirely non-existent (nothing more than a loader, as in old-style machine code). So what?

But you still have to have a runtime to handle dynamic method dispatch, especially if you use reflection, making the Java and ObjC runtime requirements about equivalent. (They both have, in their present incarnations, garbage collection, for example.)

Again, so what? You could use a garbage collector with C++, for example (eg the popular Boehm collector). And you can implement your own dynamic method dispatch in C++, if you wanted to go to the trouble. Dynamic dispatch (with a bounded set of types) is way different to a full-blown VM. But they are still part of the runtime environment. I don't understand the point of your post, you seem to be saying basically the same thing I said, but you've written it in a way that makes it look like you disagree. Exactly what do you disagree with?

For me.

[drolli]

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.

[Desler]

write guis in (preferably java or tcl).

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

Re:For me.

[daem0n1x]

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

Re:For me.

[JeremyMorgan]

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

Re:For me.

[Desler]

Really? I didn't realize this tool 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.

[SomeKDEUser]

I agree. But tcl is even worse ;)

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

Re:For me.

[Anonymous Coward]

You're a clueless idiot.

Re:For me.

[Short Circuit]

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.

[Anonymous Coward]

You're not very bright are you? Look into SWT or the myriad of apps written using it. One of them just happens to be Eclipse.

Re:For me.

[lgw]

Riiiiigt. Java isn't slow, it's just this amazing coincidence that all the Java applications I use are slow. Java isn't ugly, it's just that all the Java applications I use look like ass.

If Java isn't slow and ugly, then I must be using the product of a whole host of terrible Java programmers!

Re:For me.

[Anonymous Coward]

Really dude? Are you seriously that ignorant? Ever hear of SWT? Maybe Eclipse?

Re:For me.

[ThatMegathronDude]

You're not winning any brownie points here. Eclipse is a UI disaster.

Re:For me.

[Desler]

Ever hear of SWT?

Yes, but most Java GUIs do not use it so that's mostly irrelevant.

Re:For me.

[drolli]

Yes. But if you need to make a quick tool which generates a litttle of customized source to copy into a file, then tcl can be very practical (which is why it appears in many toolchains).

Re:For me.

[LordKronos]

Many of them do, yes, but that's not because of java as much is it is that people take the easy way out and don't put any effort into the look. It's the same way that most visual basic apps look like crap. Even though VB uses the exact same controls as other windows apps, people put no real effort into making it look nice. They leave things at the default (like not adjust the button height, so all your buttons are plump) and just throw things together without giving it much thought.

It is possible to have nice looking java GUIs. For example, look at Eclipse:
http://www.eclipse.org/screenshots/images/SDK-RedFlag_Linux.png

Eclipse was built using SWT:
http://www.eclipse.org/swt/

Re:For me.

[LordKronos]

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

Not always. Please try spotting that "look" here:
http://www.eclipse.org/swt/

or here:
http://www.eclipse.org/screenshots/images/SDK-RedFlag_Linux.png

Re:For me.

[drolli]

Because real artists ship.

Smart people know already...

[giuseppemag]

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

[Anonymous Coward]

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

Re:Smart people know already...

[Joce640k]

There is no best language in general

I can't think of a job that C++ would be useless for, I can think of plenty of jobs that Lua/Python/etc would be completely useless for (you mentioned some yourself).

Is C++ the best choice for everything? No ... but overall it's definitely the best language. You'll never run into something it can't do.

Re:Smart people know already...

[lgw]

C++ has one major flaw: lack of reflection. That makes GUI code a royal pain, and simple DB framework interaction, well, unsimple. If all you're making is a one-off UI frontend for a DB backend, C++ is a terrible tool for that job.

You can do anything with any Turing-complete language, of course, but C++ sucks where the easy answer is to construct/interpret new types at runtime.

Re:Smart people know already...

[mini me]

Unity 3D, which uses C# extensively, claims support for the Xbox and Playstation. Not being a game developer, maybe you cannot use C# code when targeting those platforms, but given Unity 3D on iOS supports C#, I find this unlikely. C# is also an officially supported language on the Wii.

Re:Smart people know already...

[0123456]

C++ has one major flaw: lack of reflection. That makes GUI code a royal pain, and simple DB framework interaction, well, unsimple.

It also makes those huge piles of unmaintainable, mind-boggingly complex Java reflection code rather more difficult to write.

Re:Smart people know already...

[lgw]

Sure, but that stuff belongs in libraries. Nothing can touch C++ template code (also Turing complete!) for mind-bogglingly complex crap, but it's great as library code.

Re:Smart people know already...

[VGPowerlord]

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

Actually, it does. That is rather the point of XNA.

Re:Smart people know already...

[giuseppemag]

Why should a language that is not the *best choice* for everything be the *best language*?

Suppose you have a very tight budget and little time and need to design an algorithm that must be correct or else you will incur in a grave penalty: C++ would be a very poor choice, and Haskell might probably be a better idea. Need to build a simple invoice management application for a hairdresser for 1500$? Go with Java or C#. Need to build an indie game to sell on Steam, the XBox and the iPad? Again, go with C# and XNA/Unity/MonoTouch.

The *best language* does not exist. The *best language for the job* does exist, and it is not just one.

Re:Smart people know already...

[Joce640k]

Yeah, that's probably worst-case for C++...

Re:Smart people know already...

[giuseppemag]

.Net runs in the xbox thanks to XNA, and Unity brings C# (through Mono, not .Net) to Wii, PS3, iOS and Xbox.

You are an idiot.

Re:Smart people know already...

[Anonymous Coward]

...and then you try to switch job and the first thing the recruiter asks you is if you have 5 years in a particular language.

Re:Smart people know already...

[feandil]

Game developers use C# to write their pipeline tools (level editors, particle editors, AI editors, etc.), not the game itself. except for XBLA indies, all major console games are pretty much 100% C++.
some also include scripting languages like lua or python for higher level, non time critical processes (like level scripting), but if you want your game to run fast (and you do, as faster=more stuff on the screen at the same time) you use a visual tool that internally generates C++ code.
as long as C++ is the fastest, closest to the machine language it's never going to go away.
and don't talk to me about managed code, when you have 64MB of ram to run a game on the wii I can tell you you better know exactly how you use your memory at any given point in time. you ban dynamic allocations and make sure all objects are placed in a nice contiguous way (to avoid cache misses) in your memory pools.

Re:Smart people know already...

[Anonymous Coward]

Not with Borland C++ Builder... That stuff is s snap.

Re:Smart people know already...

[lennier]

I can't think of a job that C++ would be useless for

How about guaranteeing 100% provable lack of buffer overflows? As far as I can see C++ is pretty useless at that.

And no, "but real programmerz r smrt enuff to nevr make mitsakes!!!" is not an answer. If you can't algorithmically prove that your code is 100% free of 0day exploits, it's darn near 100% guaranteed that it contains them. And if you don't find them before you ship, the black hats will.

Re:Smart people know already...

[zbobet2012]

Game developer do not have to write some of the most performance sensitive code out there, kernel developers do. There is a reason [i]every[/i] kernel in major use today is written almost purely in C. Same goes with high performance web caches and servers, almost all done in pure C. The speed and memory overhead differences of C++ are large and noticeable. As others have mentioned googles mainly uses C for there applications as well, for simple performance reasons. Game developers have always thought they wrote the most performance sensitive code, but when you look at stuff like kernel code and retail game code the differences are stark and slightly disturbing, especially since game developers have not, and still largely do not have a great grasp of how to handle truly high levels of parallelism (1000+ core operating systems for example).

Re:Smart people know already...

[martin-boundary]

as long as C++ is the fastest, closest to the machine language it's never going to go away.

Well, C is closer to the machine language and much simpler than C++ (implies optimization is easier). So C isn't going away either. But C++ is a better fit for object oriented design and has a nicer standard library, which trumps raw performance in many cases.

Re:Smart people know already...

[Anonymous Coward]

when you look at stuff like kernel code and retail game code the differences are stark and slightly disturbing, especially since game developers have not, and still largely do not have a great grasp of how to handle truly high levels of parallelism (1000+ core operating systems for example).

Yeah, but game developers write shit that hundreds of millions of people use directly on a regular basis.

Re:Smart people know already...

[The Car]

Don't forget ASSEMBLY for those super duper inner tight loops!

Re:Smart people know already...

[shutdown -p now]

You forget about everything running on any version of Unreal engine, where all game logic (even some pretty low level stuff) is written in UnrealScript.

Re:Smart people know already...

[Tomato42]

As if .NET languages or Java protect you from 0day exploits...

Programming is hard, people that don't understand what they are doing, shouldn't do it.

Re:Smart people know already...

[giuseppemag]

Sims 3 used mono http://en.wikipedia.org/wiki/Mono_(software)

You are saying a bunch of crapload. Ignorance is less excusable if you are also aggressively pulling falsehood out of your ass.

The days when performance was extremely sensitive forcing you to stay close to the metal are over, and we live in a blessed day where a variety of tools can be used together. Gamedevs are among the last ones to make this transition *partially* away from C/C++ and this is a gargantuan step for a very technologically-conservative industry. Yes, C/C++ still has an important place in gamedev. No, you can (and will) use other languages as well in the final game. Designers do not program in C/C++, they never have and they never will, but you cannot hire a frigging dev to code for every designer you have; and so you use LUA, Python and C#.

And by the way, in C# you can easily use contiguous blocks of memory (arrays) where you do your own allocation, and you pass around value types that act as pointers and that nicely access the "custom heap" with appropriate properties. At that point the speed difference between C# and C++ becomes almost negligible (5%). So spare me your bullshit.

Asshole.

Re:Smart people know already...

[Anonymous Coward]

I think it is best to clarify the game engines are C++ and the external tools can be in C#/C++ or whatever.

In game scripting is usually lua or the like run in the game engine interpreter which is C++ also. So you don't natively run C# on the console as such.

{I worked in the games industry for the last 15 years on game engines for consoles.}

Re:Smart people know already...

[cpghost]

The speed and memory overhead differences of C++ are large and noticeable.

Speaking of kernels, it IS possible to write efficient and fast ones in C++ too, e.g. L4Ka::Pistachio. You only have to know C++ very well to avoid its weaknesses.

Re:Smart people know already...

[Anonymous Coward]

Asshole? o_O

I am an AI programmer on a AAA project at one of the top 3, I use C++ for my code and the tools are use for AI are C# editors running on top of the C++ engine.
Even the people using Unreal use unreal script only for high level decisional processes, the heavy stuff is always written in C++ and optimised for the platform. You'll tell me how you write SPU optimised code using a managed language, asshole

Re:Smart people know already...

[badkarmadayaccount]

Wanna try it against Common Lisp or Ada?

Re:Smart people know already...

[zeroshade]

If you ever think that your code is 100% free of 0day exploits, then you have no idea what you're talking about.

Native code for enterprises is stupid

[backslashdot]

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

[Short Circuit]

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

Re:Native code for enterprises is stupid

[Anonymous Coward]

"If your application is mainly implementing business logic, then choose a managed come environment."

A managed WHAT environment????? Business logic, knew I didn't want to be a businessman.

Re:Native code for enterprises is stupid

[Joce640k]

What about code delivery? If your code is to be used by the general public then your managed environments are going to make program support very costly.

Re:Native code for enterprises is stupid

[lgw]

I've worked in shops where the team was a bunch of guys with 10+ years experience and one young guy. C++ can work well there. A bunch of new college grads and one older guy - not so much.

I think part of the resurgence of native code is that the field is finally starting to mature - only during exponential growth will it be true that the majority of programmers at the majority of shops have 5 or fewer years of experience, and I think we're past that stage now, if not quite to the point where yu see an even distribution between 1 and 40 years experience as you migh see in other engineering fields.

Re:Native code for enterprises is stupid

[Short Circuit]

I've worked in shops where the team was a bunch of guys with 10+ years experience and one young guy. C++ can work well there.

Sounds like my first programming job. :)

Re:Native code for enterprises is stupid

[tepples]

How exactly does a managed environment on Windows, BlackBerry, Windows Phone 7, Xbox Live Indie Games, or Android (without NDK) make program support any more costly than a native environment on Windows, Mac OS X, iOS, or Android (with NDK)?

Looks like I was right

[MpVpRb]

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

Re:Looks like I was right

[Anonymous Coward]

Amen! I've tried Java and C#. I never cared for the penalty performance. I like it when my customers comment that my programs are fast. Some here would counter that it took me longer to write the app. Not true. There are many frameworks that provide equivalent functionality of managed languages.

Doubt

[Lord Grey]

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

[Short Circuit]

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

Re:Doubt

[Lord Grey]

I'm curious. What's your favorite?

Common Lisp is my favorite language. I learned it a very long time ago. It was a struggle at first, but once I understood The Lisp Way Of Doing Things there was no turning back.

I'm waiting for the same epiphany with Erlang, but so far it's eluded me.

Re:Doubt

[Short Circuit]

We've got a fair amount of tasks over on Rosetta Code that could use your attention, I suspect.

Re:Doubt

[Anonymous Coward]

11 actually adds a bunch of standard library features that C++ has been missing that other languages have been holding over its head. It's these features that are trivial, yet not present in the C++ standard, that have compelled rapid development teams to chose other languages where those type of features could be readily taken advantage of to churn out applications. These simple additions to the C++ standard will help cross platform compatibility immensely. Threading, regular expressions, and smart pointers in an actual standard, that from here on forth can be taught one way and be expected to work across all platforms, can only serve as a huge leap in base functionality and mass application of the language - when it already is so powerful to begin with. To be honest though, I do not like type inference. I think it is a bad thing. It's the only feature that I would discourage people to use.

I really don't think people realize how big of an advancement this is for the standard though. I'm really excited.

Re:Doubt

[Anonymous Coward]

Ada. Really. There is nothing better for fast, native code if bug-avoidance and maintainability are priorities. Its also scalable fron very small to very big projects.

Slightly OT... I apologize...

[mark-t]

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

[jejones]

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

[Anonymous Coward]

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.

Re:Slightly OT... I apologize...

[Anonymous Coward]

But don't forget, Bjarne's book is also AWFUL for learning the language. As a reference for C++ it's hard to beat but for teaching the language it's the pits.

ARC

[Kostya]

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.

I'm sticking with mono

[cod3r_]

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

Re:I'm sticking with mono

[rubycodez]

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.

[malsbert]

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.

[Desler]

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.

Re:Return of the script kiddies.

[Short Circuit]

Want a scare? Do an "emerge -e world" on Gentoo, and run a script on the output to count how many "result unused on function declared with 'warn on unused result'" messages you see.

Doesn't have to be unsafe if native

[Animats]

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.

Re:Doesn't have to be unsafe if native

[jandrese]

The biggest failing of C IMHO is that there is no way to do a "heap check" on any particular pointer you are passed to see how much space it has to work with. Had that functionality existed, then it would be possible to write a safe gets() function or any function. It's not like the machine doesn't know either, free() doesn't require you to pass in the size. It may be relatively expensive to do, but the logic is there.

Re:Doesn't have to be unsafe if native

[0123456]

It's not like the machine doesn't know either, free() doesn't require you to pass in the size.

Uh, what if that buffer wasn't allocated by malloc()? What if it's on the stack? What if it's part-way through a buffer allocated with malloc(), e.g. a string inside a structure?

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

Runtime checks catch only a small number of security holes (& trivial ones to detect & fix to begin with).

Re:Doesn't have to be unsafe if native

[drb226]

there should have been a replacement for C/C++ by now

Well it's certainly not for lack of options. It's just as you said, legacy code has this evil property of long overstaying its welcome, and the need for backwards compatibility will forever haunt us.

Re:Doesn't have to be unsafe if native

[jandrese]

The machine should know the length of the buffers on the stack too. If the machine can't figure out it for some reason, then the function can return an error code saying as much.

Re:Doesn't have to be unsafe if native

[0123456]

The machine should know the length of the buffers on the stack too.

My pointer is eight bytes into a buffer allocated on the stack six functions above this one. How much work do you expect the system to do before it gives up?

If the machine can't figure out it for some reason, then the function can return an error code saying as much.

And then what do you do?

Re:Doesn't have to be unsafe if native

[ka9dgx]

Manage code solves the wrong problem... here's a story that I hope explains why.

Imagine this bizarre scenario:

    You get to the check out counter, with the bottle of coke you wish to purchase.
    You put yourself into suspension so that the clerk can...
            Find your wallet, get money out, put all but $2.15 of it back in
            Prepare your reciept
            Wake you back up
            Hand you the receipt

Imagine that you grew up in a world where this was normal behavior. Sure there were some dishonest clerks, but those were few and far between. Enough people eventually complained that they started a list of bad clerks, so you could check to see if the clerk was on the list before you decided to make a purchase.

Problem solved, right? WRONG...

What if someone tricks the clerk while you're in suspension?
What if they make a mistake?
What if they have an accident?
What if they just decided to turn evil?

This bizzarro world is almost precisely how we do things with computers. Instead of ourselves, it's our computer account, and instead of the clerk, it's a program we're about to run.

Now... look at how we do things in the real world...

When you buy a coke at the 7-11, you hand over some amount of payment, and get change. It's a limited amount to risk.
    The worst you can do is to not get the right change back. The side effects are limited BEFORE you decide to make the payment.
    It's immediately obvious if you have completed the transaction.
    There is no possibility of bizarre side effects, like having your living room painted a Slurpee Blue because of 7/11 decided to offer a new feature.

Why not have the operating system do it's job and enforce a scenario like this...

You have a program you'd like to run
    You make a list of the files and other resources it should have, and the types of access
    You hand that list to the program, which uses the operating system to access them, strictly limited to the items on the list.

This prevents unwanted side effects, and removes the bizarre (to me) need to trust programs at all.

I hope that story helps convince you that you should never have to trust applications, only the operating system kernel.

Re:Doesn't have to be unsafe if native

[Twinbee]

How dare you want that functionality. May you work with Javascript forever as a suitable punishment.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

I work at a company that is running 15+ year old code on pentium 4 machines - not that this is a big concern. The concerns lie in the fact that it is some of the most important code we have, they have never updated it, it only works on NT, the design documents and manuals are missing, the people who were around when it was first brought into the company are long gone and never passed along their knowledge so no one knows everything it does or how it does it, oh and we can not get approval to investigate the code base because according to the PHB it would cost too much.

Meanwhile all the PHB have brand new high end laptops for shits and giggles.

Re:Doesn't have to be unsafe if native

[ratboy666]

Of COURSE is must be unsafe if its native code. Unless you mean native code on a new architecture that doesn't support pointers to arbitrary memory.

Think about it -- unless the code can be fully tested, how do you know that the COMPILER generated the correct code? And, the compiler is just another program -- a lemma of the stored program computing we have.

So, the only way to guarantee a native code program on current machines is... equivalent to solving the halting problem. Because it has to be COMPLETELY simulated.

Which brings us back to the architecture. If the architecture had either no pointers, or constrained typed memory, we could do it.

Since the x86 has deprecated segmentation (which could be used for this), we are stuck with an "arbitrary memory pointer" model.

The JVM and other intermediate machines attempt to use another "non pointer" model, and then convert the code into native code safely (if you trust the intermediate machine coding). This is doable without being stuck trying to solve the unsolvable.

Re:Doesn't have to be unsafe if native

[Animats]

You have a program you'd like to run.
You make a list of the files and other resources it should have, and the types of access
You hand that list to the program, which uses the operating system to access them, strictly limited to the items on the list.

This prevents unwanted side effects, and removes the bizarre (to me) need to trust programs at all.

You've just described IBM mainframe Job Control Language:

//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=OLDFILE,DISP=SHR
//SYSUT2 DD DSN=NEWFILE,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(40,5),RLSE),
// DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN DD DUMMY

Classic JCL tells the program what files, etc. to access, and the program is limited to the resources the JCL gives it. The syntax is clunky, but there's something to be said for the concept. If phone apps worked that way, they'd be much easier to control and limit.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

And that is why we should all be using Fortran!

Re:Doesn't have to be unsafe if native

[sconeu]

So your web browser would have to know *IN ADVANCE* the names of all the files you are going to download?

May I introduce you to IBM JCL?

Re:Doesn't have to be unsafe if native

[m50d]

The point is that you can take a safe language (i.e. one without pointers to arbitrary memory, among other things), and compile it to native code. Of course there can be bugs in the compiler, but guess what, there can be bugs in the JVM too.

Re:Doesn't have to be unsafe if native

[LWATCDR]

Pascal was often run on a VM back in the day. It was called the P machine.
VM have their place and frankly JIT compilers make them very usable. The thing is that I feel that mainstream OSs have missed a great opportunity to be CPU independent by not using VMs.
Now they way that I would use would be to replace the JIT compiler with a Load time compiler. When an Executable loads for the for the first time it compiles the code and stores it in a Mass storage based cache. When you run it again it loads the cache version of the code. You could modify the concept to do the compile at install from your ideal virtual machine as well. IBM has used this system in the Model 38/AS400/ Series I/ whatever they call it now http://en.wikipedia.org/wiki/IBM_System_i#Instruction_set
With it you could run any software on any CPU.
With that you could have the performance of native code and the portablity of a VM. Oh and you can have managed native code. I mean there are GCs for C for goodness sakes.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

Just for the record, Erlang is not native (though there have been attempts to make it run native, but those failed to gain speed)

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

First, just put a reasonable limit on the depth of function calls, say, 5.
And then if you can't determine a buffer's allocated size, then produce an exception, obviously. Ever heard of Java?

Re:Doesn't have to be unsafe if native

[TemporalBeing]

The biggest failing of C IMHO is that there is no way to do a "heap check" on any particular pointer you are passed to see how much space it has to work with. Had that functionality existed, then it would be possible to write a safe gets() function or any function. It's not like the machine doesn't know either, free() doesn't require you to pass in the size. It may be relatively expensive to do, but the logic is there.

Well, how to do you differentiate between Heap and Stack pointers? Your program could be loaded any where in memory, your heap may be randomly located somewhere else (possibly lower than your stack) for security, so how do you tell which one you're in?

Sure, the code could keep track of the pointers (at the cost of performance and overhead), but you still run into a problem with verifying every pointer. glibc does have function to that can verify heap allocated pointers, but there's still nothing you can do about the stack pointers.

And to note, Pascal, Ada, etc have the same problem. It's harder to write "unsafe" code in them, but not impossible. This is a fundamental issue for software in general regardless of the language - even Java.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

This is also the approach used by Bifrost, the OLPC security model. The creator of Bifrost now works for Google and is incorporating similar techniques into upcoming versions of Android.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

s/Bifrost/Bitfrost/

Re:Doesn't have to be unsafe if native

[BetterThanCaesar]

Those who don't understand pointers are doomed to expect them to be managed.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

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.

I don't know, flash and java are doing a bang-up job becoming the exploited languages of choice.

Re:Doesn't have to be unsafe if native

[petermgreen]

Well it's certainly not for lack of options

Ok name a language that

1: allows both RAII and close to bare metal coding to coexist as appropriate for each peice of the code in question without having to resort to the mess of mixing languages
2: Has a high quality FOSS implementation
3: Is widely ported

Re:Doesn't have to be unsafe if native

[jandrese]

And then what do you do?

Then your function has the choice of either trusting the input (the status quo) or rejecting it. If you're dealing with something where security is a concern, then you would reject those and insist that people pass in a verifiable memory chunk. I bet you could get this to work more often than not without having to go to extremes or incurring that much of a performance hit if you were willing to only cover the common cases. There would undoubtedly be some extra memory overhead, but this isn't 1985 anymore, we don't need to scrimp every single last bit.

Re:Doesn't have to be unsafe if native

[lennier]

I hope that story helps convince you that you should never have to trust applications, only the operating system kernel.

I'm sorry, you have described a perfectly sensible, common-sense, solution to a security problem which solves the issue at the correct level. This will never succeed in today's software marketplace because (check all that apply):

[x] DOS didn't do it that way
[x] Unix doesn't do it that way
[x] NT/Win32/Win64/.NET/Win8 doesn't do it that way
[x] Angry Birds OS doesn't do it that way
[ ] There is no possible way anyone could ever invent an operating system better than what we have now
[ ] It's not physically/mathematically feasible

In addition, the following social issues may apply:

[x] It doesn't create enough "computer repair" jobs
[x] Antivirus vendors don't like it
[x] It doesn't give Google enough ad revenue
[x] Apple are too busy trying to figure out how to remove even the power button from i-devices
[x] This was a solved problem in the mainframe era, ergo, it must be reinvented from scratch every decade in the PC world

and this is what I think of you:

[ ] You are a stupid person and this is a stupid idea
[ ] Sorry, but I just don't think it will fly
[x] This is an awesome idea and you should be given a billion dollars to build it
[x] This idea is too threatening to the status quo and you will probably be assassinated if you build it

Re:Doesn't have to be unsafe if native

[lennier]

Of COURSE is must be unsafe if its native code. Unless you mean native code on a new architecture that doesn't support pointers to arbitrary memory.

Isn't that precisely what memory management units were invented for?

Re:Doesn't have to be unsafe if native

[SplashMyBandit]

Shit, even Java optimises bounds-checks away ahead-of-time in most cases.

Re:Doesn't have to be unsafe if native

[codegen]

The Euclid project back in the early 80s included a simple theorem prover in the compiler that was used to determine if bounds on arrays and pointers could be checked at compile time or run time. It also used a collection model for dynamic memory (which, in turn, was mapped on top of a traditional heap). As a result, they were able to reduce the overhead for full checking down to less than 10%. The language was straight forward and elegant and was designed for systems programming. However, the freedom to cast a pointer to whatever you pleased in C proved to be too attractive and the cowboys won. As a result we continue to pay the penalty with humans trying to determine when it is safe to check a pointer and when a pointer contains a valid value.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

The myth is backwards actually. The myth is that managed code and virtual machines make code 'safe' when all they do is provide for universal attack vectors. Especially when you have people running older versions with known security holes. Flash, PDF files, JavaScript, Java Applets, etc all have problems with security. and people run version with well known holes.

Thus note the trend to sandbox browser plug-ins running untrusted code Point is, if you can sandbox the flash plugin on a browser, you can sandbox native code too. And native code will execute faster, especially for complex tasks.

Re:Doesn't have to be unsafe if native

[master_p]

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.

Re:Doesn't have to be unsafe if native

[shutdown -p now]

Last I checked, you can crash just as well when e.g. a vector iterator becomes invalid as with raw pointers.

C++ is an unsafe language by design. This applies not only to the language itself, but also to its libraries, even new ones. Performance is paramount, and therefore default is no safety checks unless explicitly asked.

Heck, just count the number of times "undefined behavior" appears in the spec.

Re:Doesn't have to be unsafe if native

[Animats]

So, the only way to guarantee a native code program on current machines is... equivalent to solving the halting problem.

Which isn't that hard for most useful programs. The Microsoft Static Driver Verifier, used on all signed Windows 7 drivers, can decide safety about 97% of the time within its standard time limit. If your driver's memory safety is undecidable, or even hard to decide, it's broken.

Since the x86 has deprecated segmentation (which could be used for this)...

That's how the Google Native Client works, and that's why it supports 32-bit x86 code only.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

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.

This isn't true. Consider the class Foo that has a member function Foo &add(int x) that returns a reference to itself (a common C++ idiom). Then,
Foo &f = Foo(); f.add(0); f.add(1);
and
Foo().add(0).add(1);
are completely valid (the first is valid because of temporary lifetime extension with the reference), but the behaviour of
Foo &f = Foo().add(0); f.add(1);
is undefined, because the lifetime of the Foo temporary is not extended, because the object that f is bound to is returned as a reference from a function.

And don't say "don't do that", because, like playing with pointers, it's easy to get wrong. This is just one (of many) examples of dangerous C++ features not inherited from C.

(P.S. Delphi is partially unsafe as well. It has no garbage collection or scope-bound resource management for normal class instances, only for arrays and strings, and, strangely enough, reference counting for COM objects.)

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

For those who don't know, in common implementations of C and C++, "undefined behaviour" results in anything from no problem at all to subtly broken program execution, an abortion or a segmentation fault. The example the parent gave would most likely result in subtly or very broken program execution or a segmentation fault.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

Crashes are solely due to programmers not properly using a language. No language is inherently 'unsafe'.

Re:Doesn't have to be unsafe if native

[Anonymous Coward]

In all fairness, like Pascal can be made fast, C++ can be made safe. There is no technical reason that bars C++ compilers from doing bounds checks either. C++ pointers can be implemented as machine pointers plus bounds. We don't need a new language for that.

Why isn't it done? Probably because there's no market for it. Idiomatic C++ just doesn't have that many buffer issues anyway. C does, but anyone choosing C today doesn't even want the minimal overhead of an unsafe C++ implementation let alone that of a bounds-checked. C++

Re:Doesn't have to be unsafe if native

[AmiMoJo]

C++ is still prone to errors, mainly because it is not a fully managed environment that hand holds and many programmers don't know enough about the underlying system to debug it properly. A lot of people seem to know the OO stuff inside and out but actually implementing it when you still have to deal with non-OO stuff like data files or complex structures in memory they are lacking.

Re:Doesn't have to be unsafe if native

[master_p]

Last I checked, you can crash just as well when e.g. a vector iterator becomes invalid as with raw pointers.

That is a choice made by STL. It's not the language that's at fault. There are (or can be) other collection libraries that are safe.

Heck, just count the number of times "undefined behavior" appears in the spec.

Most of the undefined behavior cases are corner cases and do not affect 99% of development, especially when libraries take care of the details.

Re:Doesn't have to be unsafe if native

[master_p]

Being a fully managed environment has nothing to so with being error prone or not. You can have a fully managed environment, and your application may stop working (either by a deadlock or an exception), and vice versa.

The actual scope of knowledge required to write safe C++ is small. It's mostly to use shared pointers and iterators properly. It can be comparable to the Java set of knowledge, where one needs to know how the collector finalizes objects in order to avoid deadlocks or null pointer exceptions.

Re:Doesn't have to be unsafe if native

[shutdown -p now]

Well, you said that C++ is a safe language if no C features are used. But what's commonly meant by this is that, instead of e.g. pointers + malloc for dynamic containers, you use STL containers. And STL is covered by the same standard document as the language itself.

Corner cases? Not really. What about things such as uninitialized variables of POD types? Unless you never use e.g. int directly, but only a zero-initializing wrapper, it's very easy to forget to init a field.

Or, say, signed overflow?

Re:Doesn't have to be unsafe if native

[badkarmadayaccount]

Whats wrong with it? Note:Don't point to the DOM, and don't point to crappy dynamic implementations, lack of proper AOT compiler is not the language's fault.

Re:Doesn't have to be unsafe if native

[badkarmadayaccount]

Ada.

Re:Doesn't have to be unsafe if native

[djnewman]

More to the point of using native code vs high(er) level languages, the usual complaint here is garbage collection that takes arbitrary amounts of time and possible stalls the applications. I think the real issue is not language, but compiler design. With current multiprocessor systems threading can cover up a ton of garbage collection and make high(er) level languages APPEAR to be more efficient. Compilers should take care of this for us. From a developer quality standpoint, the developer that can churn out high quality code (no bugs, does what was intented) in the shortest time is the winner. What language is used or is currently popular depends on speed to develop with and how slow the application can be to still run acceptably. That's whay better compilers and run time libraries are expensive. The rest of us get lowest common denominator systems from M$ and open source, and have slow, memory hogging and leaking applications to show for it. As developers we should be aware of what we are doing, try to use the right tool and bitch like crazy to language and compiler developers that we need better tools.

Re:Doesn't have to be unsafe if native

[flargleblarg]

There is no possibility of bizarre side effects, like having your living room painted a Slurpee Blue because of 7/11 decided to offer a new feature.

LOL :-)

Re:This isn't auto mechanics!

[Moryath]

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.

It's funny! Laugh!

[Anonymous Coward]

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)

[Anonymous Coward]

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?

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:exploits

[0123456]

Even almost perfect native code can expose massive security holes.

Indeed. Just look at all the security holes in the JVM.

Managed code is an improvement security-wise, but you're still exposed to the hazards of bad native coding.
.

Re:exploits

[HarrySquatter]

What about blah blah blah poorly written managed code doesn't expose remote code execution,

Big deal. No need to exploit your program when I can just exploit your VM instead. The JVM has been a great source of security exploits. You'd think the people who are trying to protect people from the *gasp* horrors of native code would be competent enough to not write a program full of security holes, no?

Re:This isn't auto mechanics!

[smelch]

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.

Exclusive to one language? D2

[sgt scrub]

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?

"Modern programmers" who have any clue...

[NNKK]

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

Re:"Modern programmers" who have any clue...

[TemporalBeing]

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

Incorrect - especially when you have to - in the same program - switch between managed and unmanaged. Yes, all VM's have to do that at some point, and someone has to write that code. Have a complex enough problem and you may have to do it as well - for example, to access hardware to get data.

Re:"Modern programmers" who have any clue...

[NNKK]

Apparently you missed the word "application". Application developers don't and shouldn't care about hardware, nor should they be writing the VM. That's for systems developers to worry about.

Some developers may do both application and systems development, that does not mean they are the same discipline.

Re:"Modern programmers" who have any clue...

[TemporalBeing]

Apparently you missed the word "application". Application developers don't and shouldn't care about hardware, nor should they be writing the VM. That's for systems developers to worry about.

Some developers may do both application and systems development, that does not mean they are the same discipline.

Some applications still access hardware directly. For example, Xine accesses the cdrom as a raw device and then decodes the DVDs on its own, not relying on the hardware to do so. Similarly, some applications may for other purposes access the hardware directly, yet they are not systems stuff - e.g. OS.

Further, VMs typically operate in application space, and anything that needs to interact with the non-VM - e.g. libraries, etc. - also have to do that switch. So, for example, if you wanted to access Qt from the VM (e.g. Python, Perl, Java) then you still have to write a thunking wrapper to switch between VM and non-VM modes. You may still be entirely in the application space - even without having to deal with hardware - but you still have to mix the two managed and unmanaged modes.

Re:"Modern programmers" who have any clue...

[NNKK]

You appear to be conflating "user space" with a poorly-defined term "application space", they have no relationship. I can run a kernel in "user" space, and I can run a text editor in "kernel" space. The kernel is not hacked on by application programmers, and the text editor is not hacked on by systems programmers.

VMs are largely a systems issue. People building the applications end-users use are largely not the people building VMs, and the people building VMs actually _do_ have to have a rather close understanding of hardware issues. Libraries like Qt straddle the gap between systems and applications, being strictly neither. Their interaction with VMs they are not themselves running on top of is definitely a systems issue, however, as you are trying to bridge two unrelated systems (the VM, and the host it happens to be running on top of, or possibly even another VM on the same or a different host).

You are also conflating access to the equivalent of "/dev/cdrom" with "direct hardware access". This is also a fallacy. Xine is accessing a special file, not a raw hardware device, and there are several layers of indirection between Xine and the hardware, and you could easily substitute another file and Xine would neither know nor care. Xine isn't what's fiddling with hardware registers and the like, the drivers are. Xine is an application running on top of abstractions others have built.

Re:"Modern programmers" who have any clue...

[TemporalBeing]

You are also conflating access to the equivalent of "/dev/cdrom" with "direct hardware access". This is also a fallacy. Xine is accessing a special file, not a raw hardware device, and there are several layers of indirection between Xine and the hardware, and you could easily substitute another file and Xine would neither know nor care. Xine isn't what's fiddling with hardware registers and the like, the drivers are. Xine is an application running on top of abstractions others have built.

While that was one example, it is still in merit as there are applications that do that that are not "systems" programs - one component of a system I work on does exactly that. Generally you are right but there are still the exceptions and more numerous they are than you realize.

Right tool for the job

[Anonymous Coward]

From the article;
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 the most important take away from the article. There are times when native languages will solve a problem far better than scripted/interpreted languages while other problems are not. I've been programming for just over 25 years and there has always been a crowd that insists we all use cause it's the greatest new thing in the world of computing when really it's a break though for a particular situation that doesn't fit with the previous set of tools. I always disagreed arguing there should be tons of tools and languages to suit each need. Does a handy man have only one tool in his belt? A mechanic only one size wrench? No, and the same is true for developers. Each language/platform has benefits and draw backs. Each is suited for a given problem. There should be a rule that the next time some one talks about how is the greatest solution to all our problems and we should all convert now, the rest of us get to beat that person senseless with two by fours with protruding rusty nails. It really is OK if we all do our own thing.

Oo isn't all there is

[bytesex]

I think a replacement 'native' language should focus less on academic correctness and fads, and more on things that make scripting languages nice to work with. I don't *mind* OO features, but I find their exclusiveness in java, for example, a litlle limiting. And in C++ a little overbearing. Rather, I'd see C extended with supple string handling and regexes, for example. On top of a class model, obviously.

Re:Oo isn't all there is

[Un pobre guey]

I'd see C extended with supple string handling and regexes, for example. On top of a class model, obviously.

You mean like C++ with Boost?

Anecdote time!

[bberens]

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.

Re:Anecdote time!

[gbjbaanb]

and there's more to the simplified example of developers using inefficient frameworks to create apps quicker (though the cost/performance tradeoff isn't quite as clear cut as they'd have you think - 1 dev taking twice as long to create a great app is a minor cost compared to the thousands of users using a bad app, and uncounted cost of those users stopping using the app when one better comes along. The cost of dev is pretty small all things considered).

Today its not CPU or IO performance that matters so much, its battery life.

Re:Anecdote time!

[SplashMyBandit]

Battery life? only on the desktop (sigh, are you one of the guys who think computers are the things the users see rather than the real computing which is invisible [embedded, and the hordes of servers that run the Interwebs and government]). Actually, it is development cost (not just developers but project management, testers, admins deploying, infrastructure monkeys, etc. all the folks who go into making something work) that matters. Without the dollars nothing gets built - irrespective of the tech. In many applications (although not all) tech that allows something 'good enough' to be built will be the winner (hence all the Visual Basic junk still out there running the companies). This is why Java (and to a lesser extent C#, by a factor of around 5:1) are used in far more new projects than C++. Arguably Java and the Java-esque C# (read the history sometime about the intermediate language 'Cool' from Java which came to be C#) are the better technology but even if they weren't their development speed is sufficiently higher that C++ will never displace them again from an overall market perspective.

Re:Anecdote time!

[cowboy76Spain]

and there's more to the simplified example of developers using inefficient frameworks to create apps quicker (though the cost/performance tradeoff isn't quite as clear cut as they'd have you think - 1 dev taking twice as long to create a great app is a minor cost compared to the thousands of users using a bad app, and uncounted cost of those users stopping using the app when one better comes along. The cost of dev is pretty small all things considered).

Today its not CPU or IO performance that matters so much, its battery life.

Maybe you should think a little before posting ideas so categorically.

So my wildly inefficient framework means that the user needs 10s more every time they read a newspaper. Who gives a shit? The user will spend at least several minutes with it, so it will not even notice the extra time. Price (down because I am using the framework) and UI are what will decide the user to buy/use it.

Or when the user wants to check what time is it, my inefficient framework forces the user to wait 5 seconds before showing it. As the user expects this operation done in 1 second, then the user dislikes the app and won't buy it even if it is almost free.

Not everything is the same, not everyone is only obsessed with performance, and acceptable performance is highly subjective.

Re:Anecdote time!

[Alex Belits]

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.

A person stupid enough to use .Net or Java for the task that can be implemented in C or C++ would be indeed more productive using .Net or Java than in C or C++. That's because he is fucking stupid. What also guarantees that all his applications, regardless of language, are fundamentally wrong. He will never actually complete his task, it can only asymptotically approach a working state as fucking stupid programmer will be messing with it.

Better developers (ones who wouldn't even think of touching .Net at all, or Java for something that can be made without it) would write superior software in C or C++, in time less than it would take them to fix the product of the above mentioned fucking stupid programmer.

Re:Anecdote time!

[LizardKing]

Twat

Re:Anecdote time!

[ifrag]

the developer using .NET or Java is likely to outproduce the developer using C/++ in nearly every meaningful measurement to a business

Maybe, but I think some of this may be that C programmers tend to over-optimize and fine tune things which already have plenty sufficient performance to start with. It's so easy to fall into that trap with such a powerful language. With some good libraries and sufficiently advanced developers, ones that really have the ability to work with both, I don't think the divide is nearly as big as people claim it is.

Case in point: the Nintendo Wii

[DeadCatX2]

Nintendo dropped the ball big time when they used a string comparison function for evaluating the digital signature hash. String functions terminate early (with success!) for strings where the first byte is null. All an attacker had to do to fakesign a Wii application is brute force change some random unused byte until it caused the first byte of the hash to be 00.

think of the children

[Anonymous Coward]

...yes, BUT - with superphones and super computers - who cares about optimizing? the sad truth is (much like with Flash), the solution for a slow, hiccup-py technology (like virtual machines and ...again... Flash) has been and IS: faster computers!!

  it's ridiculous that it took a 1.2 GHZ dual core processor in a "phone" to get rid of lag in browsing and just traversing device menu... that's Java for you :( so very sad.

Growing Sentiment?

[the eric conspiracy]

You can't just throw out some outlandish statement like this without providing evidence.

So I call bullshit.

the year of C++

[Un pobre guey]

Believe it or not, 2011 could be the year of C++.

Starting in August? Maybe we can also make it the Year of the Linux Desktop starting, say, on Christmas.

Re:the year of C++

[Anonymous Coward]

I suspect that that week, in particular, would be a very bad time to declare the Year of the Linux Desktop.

Backlit

[tepples]

VMs add overhead, as you add overhead you'll run longer and burn more power on the CPU.

A lot of applications running on smartphones are limited by the speed of the connection to the Internet or by the speed of the user, not by the speed of the CPU. For these, I'm told the LCD backlight uses far more power than the CPU. Or by "embedded", did you mean an environment even smaller than a phone?

Confusing lots of issues

[SoftwareArtist]

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

Re:Confusing lots of issues

[Anonymous Coward]

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 only for Windows programming

Java: Some complex, some bug opportunities, some verbose, slow, 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

Re:Confusing lots of issues

[Anonymous Coward]

So where do you put LISP in all this.

Re:Confusing lots of issues

[Anonymous Coward]

C# isn't run in a virtual machine. It's JITed to machine code.

Re:Confusing lots of issues

[HiThere]

You left out:
C: Fairly simple, lots of bug opportunities, very verbose, very fast, suitable for system programming

I suppose you could argue with the "very verbose" part. It depends on how you analyze things. If you're doing the same thing in C and C++ I guess "incredibly verbose" would be a better way to put it.

Also:
C# is suitable for systems programming? I find it quite a questionable assertion that ANY language running in a virtual machine is suitable for systems programming...except, perhaps, on that same virtual machine.

Re:Confusing lots of issues

[SoftwareArtist]

Oops! Silly me for leaving out C! Thanks for catching it.

Being suitable for system programming is certainly one of Microsoft's original stated goals for C#. That's why they included the ability to manipulate pointers, call native functions, etc. I'm not saying it's a good language for the purpose, just as I'm not saying C++ is a good language for... well, much of anything. :) But you can certainly do system programming in C#, whereas it would be basically impossible in Java or Python.

Re:Confusing lots of issues

[Chuck Messenger]

If C++ is programmed well, then there are few bug opportunities. Probably about comparable to Java (assuming, again, that Java is programmed well). Except that in some ways, C++ is superior to Java (i.e. fewer bug opportunities). The reason is that Java insists that you use its own garbage collector framework, whose properties can be unsuitable for your task, C++ gives you total control.

I'm not saying that any-old programming language, if programmed well, provides few bug opportunities. A counter-example would be C. If you program C++ like C, then you'll have alot of bug opportunities. What I'm saying is that C++ allows for very low-bug programming.

I'll also agree that other programming languages (not including Java) allow for even fewer bugs than C++ - for example, ML. But there are many disadvantages to using a language like ML (e.g. few available programmers, few available API's, speed, to a degree, etc).

Even better is to develop meta-programming frameworks, specific to your task - built on top of C++. This can reduce your bug opportunities even more...

Re:Confusing lots of issues

[Anonymous Coward]

where does Haskell stand there?

Re:Confusing lots of issues

[SoftwareArtist]

I agree there's some judgement involved in measuring bug opportunities, but I was basically considering three factors: what sort of mistakes the language either makes impossible or catches early, verbosity (because the more code you have to write, the more mistakes you're likely to make), and readability (because the harder your code is to read, the less likely you are to spot the mistakes). I think C++ does worse than Java on all three counts. It's quite a bit more verbose, and I think most people would agree it's less readable (though this is clearly a matter of personal judgement). And there are a lot of mistakes that are possible in C++ but not in Java. It doesn't have bounds checking on arrays. (It does on STL collections, but those checks get removed if you compile with optimizations.) It has pointers, which are a huge bag of worms. (A good C++ programmer tries to avoid pointers when possible, but sometimes you can't.) It's weakly typed, allowing you to make all sorts of mistakes that would be impossible in Java. And so on.

Yes, if you know what you're doing you can work around these problems, but it takes a lot of experience and discipline. There is, so far as I know, exactly one way to do memory management well in C++, and about a hundred ways to do it badly.

Re:Confusing lots of issues

[Anonymous Coward]

Java: Some complex, some bug opportunities, some verbose, fast, not suitable for system programming

1 sec while I maintain my mirth ..

Re:Confusing lots of issues

[master_p]

You are wrong on quite a lot of points.

C++ does not have any garbage collections. Boehm's collector is unusable from C++ due to preprocessor tricks.

STL collections do not do bounds checking in the array operators or iterator ownership checking.

Re:Confusing lots of issues

[martin-boundary]

LISP is the strange attractor to which all languages gravitate eventually - and badly ...

Re:Confusing lots of issues

[Anonymous Coward]

fixed it for you, idiot.

C#: Not complex, Lots of bug opportunities, some verbose, SLOW, NOT suitable only for Windows programming

Re:Confusing lots of issues

[Chuck Messenger]

Once I figured C++ out, I found that my bug rate went way, way down. It's quite rare for me to get any memory reference errors. When it happens, it tends to be within some new library I've written - so when I solve the problem, it's solved generally. Pointers are quite rare - and when they happen, it tends to be buried in some library framework. They're definitely not used willy-nilly. On the other hand, they can be very useful when needed. Typically, they get encapsulated in a smart pointer.

It comes down to making heavy use of the STL. Array reference errors? You can turn on debugging for that, if you want. For some reason, I just find random array references to be rare. It's common to iterate thru an array, but that's a low-bug kind of operation.

C++11 has some really nice features to make for even lower-bug coding. Can't wait...

Re:Confusing lots of issues

[Anonymous Coward]

As I read this I'm procrastinating on writing python code for a class that was spawned for one designed in C++. I have become enlightened as to my hidden motivations.

Re:Confusing lots of issues

[Moondevil]

As well as Java. Who do you think converts the bytecode into native language, the OS?!

Re:Confusing lots of issues

[aaaaaaargh!]

Two more you've left out:

Ada: Some complex, few bug opportunities, very verbose, very fast, suitable for system programming
Racket: Fairly simple, some bug opportunities, not at all verbose, fast, not suitable for system programming

Re:Confusing lots of issues

[Anonymous Coward]

Languages DO NOT specify the implementation.

Java does not HAVE to always be run in a VM, a compiler could be written that runs these things without a VM.

Re:Confusing lots of issues

[Anonymous Coward]

And what about using C wrappers on high-level languages ? Do you see lot of realtime libs having and API for Python (i.e. opencv, etc...). I develop mostly for Python language and am extremely thankful of ctypes module, swig, and the lot of ported libs for that language. I think it is an excellent approach. I basically use Python + opencv (for realtime image processing, etc...), ctypes for low-level access to SDK's and libs, javascript for integration with web apps, etc... The applications developped are extremely stable, use low memory, are easilly maintainable and run really fast.

Xbox Live Indie Games are 100% pure .NET code

[tepples]

I'm pretty sure not even the xbox runs .net code

Xbox Live Indie Games are 100% pure .NET code. Native code won't even load in the sandbox where Indie Games run.

Platforms that limit which languages may be used

[tepples]

There is no best language in general

Unless your platform limits which languages may be used. For example, languages that compile to native code (such as standard C++) or rely on Reflection.Emit (such as IronPython) won't run in Xbox Live Indie Games. This limits such games to pretty much just C# and languages with pure C# interpreters such as the XNua dialect of Lua.

But for learning programming, what's recommended?

[Anonymous Coward]

I took C++ up to Data Structures. I'd like to pick up again, but learn real programming concepts before learning a language's syntax. What would you recommend for this route?

Re:This isn't auto mechanics!

[rthille]

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

I doubt there is a C compiler for this chip, possibly not even an assembler, given that the chip was designed to implement Forth.
http://www.ece.cmu.edu/~koopman/stack_computers/sec4_5.html

Re:False dichotomy -- Smalltalk Disgusting?

[ratboy666]

Smalltalk was an experiment -- can everything be done with message passing?

The answer is "yes". (but, of course, this may not be desirable).

Conditionals ("if") fall out of sending messages to boolean objects.

boolean is sent message "if" with argument "a block of code".

IF the boolean is the "true" instance, return the value of evaluating the code block. IF the boolean is the "false" instance, return NULL.

If tail recursion is added, WHILE becomes just as easy.

Which means that the syntax degenerates to "send message to object with arguments", and "define a code block".

A pleasant result -- there is no special syntax to IF/WHILE or anything else.

The Smalltalk compiler may, of course, optimize this stuff (and usually does).

But, the NICE effect of this is that "boolean" and control structures are NOT CONCEPTUALLY PRIMITIVE -- they are defined in terms of "OOP" or message passing, giving the possibility of defining your own control structures. If the C do/while is not available in a Smalltalk implementation, it is easy to add, and (sharing a trait with LISP) the implementation looks the same as the "default" control structures.

doWhile method for "false" - execute code block and return.

doWhile method for "true" -- execute code block, evaluate condition code block, if "true", recurse, else return (and, please note that the conditional is a message sent to the boolean result of the conditional code block).

Of course, you got me on "boolean instance". Since code can only be put into a class, the "true" and "false" instances are actually subclasses of a boolean class.

Of course LISP is yet simpler... But I agree, Python gives almost the ideal balance for most programmers (personally, I like the LISP approach though -- I think Gambit-C SCHEME with "six" syntax is better than Python, but that's just me).

Re:This isn't auto mechanics!

[Bengie]

It's not only about being easier, but also proven. I would rather use a lockless thread-safe multi-reader/writer queue than implement it myself only to have a possible race-condition. It would be fun to learn it some day when I have free time, but enterprise code? No Way. I'll let engineers with PHDs and tons of testing figure out the hard stuff.

Unmanaged code: I don't trust you

[BeforeCoffee]

We don't have passengers in the cockpit flying our commercial airline planes. We have expert pilots flying our planes who have thousands of hours logged training. It's too important to have just anyone flying planes, lives are at stake.

When it comes to software, it's nonstop amateur hour. There is hardly any urgency about the lives at stake when it comes to software.

In my estimation, there is very little robust native code, written large, in the world. QNX, the JVM, maybe Apache HTTP (although that seems creaky to me and the config system is a hot mess.)

The linux kernel seems robust to me based on how it's maintained, but I am not an expert. All of the browsers have some varying degree of swiss cheese holes to them, with giant attack surfaces, and poorly written plugins (including Java's.) I pity the security teams on those products.

I don't trust your native code. I hear people tout their soup du jour language/vm as robust, sane, battle hardened. The more shared libraries and DLL's your code relies on, the less I believe you. If your favorite system easily/readily/commonly links in more native code as it rolls along, then I hope you understand that your battle hardened tank has cheese cloth armor that should never go to war.

I don't trust Microsoft code, especially their new products - a permanent bullseye is tattooed on their hineys. Yes, they've made security advances in recent years, they're still horribly vulnerable due to the legacy baggage which is core to their business. Microsoft code is bubbly poison at its deep, dark, dank core. IE is terrifying to me.

When it comes to me, I consider the code I write to have my name attached to it. Why wouldn't I give myself every opportunity to look good? A crash bug in native code to me is the most serious form of professional failure.

Maybe a lot of you just tinker and love your micro-optimizations in C and Assembly. Good for you, go spin that propeller on the beanie on your head, very neat. If you write for games or embedded systems and need the speed of native code, fair enough, but I'm dubious C# or Java isn't fast enough for most of that. Otherwise, please, PLEASE stay out of the native code cockpit when it comes to commercial/professional work unless you've got your thousands of hours of flight training. Lives are at stake.

Re:This isn't auto mechanics!

[Anonymous Coward]

Which will cause your company to lose money as customers want computational efficiency.

Hello buffer overflows

[Anonymous Coward]

We've missed you.

My career is going this way too

[shadowrat]

I've done years of Java, .Net, then the past few years have been mostly objective-c. Now i'm about to take a job that is all c++.

Re:My career is going this way too

[Anonymous Coward]

My condolences to your family.

Two-word pointers

[tepples]

My pointer is eight bytes into a buffer allocated on the stack six functions above this one.

Perhaps the thinking is that pointers should be stored as two separate machine words: the pointer to the start of a buffer, and the offset into that buffer. That's how managed languages handle iterators.

And then what do you do?

Unwind stack until you catch the exception.

Re:Two-word pointers

[badkarmadayaccount]

Bitfields and pointer compression ought to do the trick faster.

A folder is a resource too

[tepples]

So your web browser would have to know *IN ADVANCE* the names of all the files you are going to download?

No, but it should know *IN ADVANCE* the name of the folder to which they will be downloaded (for example, /home/pino/Downloads) and how much space in that folder is available.

Re:But for learning programming, what's recommende

[TemporalBeing]

C++.

Yes, you get a little bruised when it comes to pointers, but that is very much worth it in the long run.

Students that don't learn about pointers and such early on (e.g. got Java first) tend to have a harder time in the upper classes where lower level languages are required. So, you can either "man up" and get the hard stuff learned early when it won't interfere with the classwork, or have your upper level classes being diverted in order to teach the stuff they should have learned earlier on and then not get to learn as much of the upper level material as they should have.

Google Native Client

[tepples]

The JVM and other intermediate machines attempt to use another "non pointer" model, and then convert the code into native code safely (if you trust the intermediate machine coding).

So do things like Google Native Client. The program is compiled to bytecode that's a verifiably memory-safe subset of x86 instructions. The (trusted) verifier uses a "non pointer" model, and after that's done, the bytecode executes on the CPU.

Is the cache the only difference?

[tepples]

The CLR is a memory manager and JIT compiler.

So is the HotSpot implementation of the JVM. Perhaps the only substantial difference is the cache of the JIT compiler's output.

Re:Platforms that limit which languages may be use

[giuseppemag]

Yes, but still, "in general" applies here. In this case C# and F# are the best choices (I have used both for XBLIG games and they can be fast at runtime and cheap in terms of dev time).

In other cases/platforms you will have other best choices.

In game development, the idea is this:
If you have 20+ devs, 3 years of dev time and 5+ million dollars, then great, go with C++.
If you have 3 devs, 3 months of dev time and 5 dollars to buy snacks every other day, go with C#.

They're both called iOS

[tepples]

Why not just make a new user account that has access only to those resources that a given program may access, and then run the program as that user? That's what iOS for iPhone and IOS for Wii do, I've read.

My boss sent me this link a few weeks ago

[GodfatherofSoul]

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

The demise of native programming has been greatly exaggerated.

Re:Platforms that limit which languages may be use

[tepples]

So what if I have 3 devs, 3 months, and I want to release on both Xbox 360 and Mac? Or Xbox 360 and Android (assuming the game design is flexible to allow for both touch- and gamepad-based input processing)? Sometimes, different platforms have disjoint sets of preferred languages.

Broadway

[tepples]

At the rate WP7 market share is declining, it will be a rounding error.

Are BlackBerry phones also headed toward rounding error? Flash and HTML5 JavaScript are managed environments; are they likewise headed toward rounding error?

But you have a point - if your two-class divide comes about, people are going to shun the small guy or gal because his or her code will eat into their battery life.

So how are small guys supposed to get promoted without leaving their support network of friends and family behind to move to, say, southern California or Washington to seek a job with the big guys? As CronoCloud put it, "if you want to be a star on Broadway, you're going to have to go to New York City."

Re:Broadway

[tomhudson]

Are BlackBerry phones also headed toward rounding error?

Their manufacturer, RIM, is doing the Nortel thing, so quite possibly. More likely, they'll be bought out.

Flash and HTML5 JavaScript are managed environments; are they likewise headed toward rounding error?

What does that have to do with my observation that WP7, which is an operating system, not a programming language or environment, is already dead? We're already hearing the usual suspects chanting "just wait for Windows 8 on the smartphone!"

Considering that Nokia is now in death-spiral mode. They lost $692 million in the last 3 months alone. At that rate of cash burn, they are out of cash in another 6 quarters - and their cash requirements are only going to rise as they try to launch WP7 phones - it costs a lot to fill the channel, promote, etc.

The billion they got from Microsoft to go with WP7 instead of Android is gone, and they're still half a year away from selling a WP7 phone. Microsoft, having burned through several billion trying to get a foot in the smartphone ecosystem, is going to have to keep the cash flowing.

Considering that 2 out of 3 WP7 phones that were shipped are still sitting unsold on store shelves, it looks like there are now almost as many Android smartphone activations every day as all the WP7 phones ever sold - and Android daily activation rates are increasing by about 5.5% a month.

The only joke bigger than WP7 in the mobile space is Steve Ballmer and the Microsoft Board of Directors. WP7 isn't even on the radar in terms of being a threat to anyone.

can i haz citations?

[luis_a_espinal]

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.

Citations for the studies please. I've been working on Java (mostly) since 1998, from implementing custom network stacks with it, to CORBA, to almost every stuff under the enterprisey umbrella, in 7 different companies in different industries (healthcare, finance, re-insurance, manufacturing and defense), from the very small (a 5-pple medical dictation automation startup) to the very large (40k multinational).

What lehphyro described pretty much matches what I've seen in my line of work. So either the studies are faulty, or you are misrepresenting them.

Talking about studies (and insisting in a reply on the same studies) without providing at least one reference, that's just weasel words and hand waving.

Also, regarding this:

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

That's an oxymoron. Such a condition is an indictment on the programmers' part, not on the concept. That's like saying OOP, the concept, is flawed just because people keep writing procedural spaghetti with OOP languages. I mean, c'mon, it is possible to write many types of non-trivial systems in C or C++ in a manner that is portable. Unfortunately, for that class of systems, C/C++ programmers fail miserable because they make mistakes and due to human short sightedness. Does that mean that C or C++ (the languages when used under a specific type of constrains) are not portable?

Same with Java. In 13 years of working with Java, I've only come across (first-hand experience) with two systems that were not portable:

1) a java implementation of the DNP protocol stack that I had to write moons ago using the javax.comm serial communication API. That stuff can only work on three platforms (Solaris, Linux and Windows) out of the many others that the JVM run. It won't work (and probably never will) if you drop it in a HP-UX hosted jvm for instance.

2) a web application hosted on WebLogic 8 SP2 that we could not deploy on WebLogic 8 SP4 and up. It contained a weird dependency on apache xerces that was also colliding with any version of WL 8 SP4 and up. I never stuck around long enough to find out if it was a problem with apache xerces itself, with WL 8 SP2 (or SP4 and up) or with the application (even after we did a serious code audit on it.)

The former out of necessity due to dealing with native libraries. The later due to a programming error somewhere. That's it. In 13 years, that's all I've ever seen. Yes, you can create a web application with dependencies to vendor-specific libraries in a web/ee container that will stop you from deploying it in another vendor's container. But then again, that's a programmer's error, not an indictment on the portability provided by the technology in question.

Re:can i haz citations?

[GooberToo]

Citations for the studies please.

Pull your head out of your ass - I stated at least one of those studies was covered here. So clearly you're too stupid to understand annecdote is not data and too stupid to be bothered to search /. - exactly as I would be required to do. And since I'm not stupid, I don't have a need to do your research to validate what was previously reported. Holy shit people are stupid.

Re:can i haz citations?

[jeremyp]

Citations for the studies please.

Pull your head out of your ass - I stated at least one of those studies was covered here.

That's not a citation. A lot of stuff goes through Slashdot, so saying it covered a study about Java once doesn't help much.

So clearly you're too stupid to understand annecdote is not data and too stupid to be bothered to search /. - exactly as I would be required to do.

You made the claim, you provide the evidence.

And since I'm not stupid, I don't have a need to do your research to validate what was previously reported. Holy shit people are stupid.

Stupidity is being asked to provide citations for studies you claim exist, going off on a rant instead of providing them and not realising that your actions look like evasion possibly because the said studies are a figment of your imagination (at least that's what everybody else is thinking).

Re:can i haz citations?

[williamfrench4]

Citations for the studies please.

Pull your head out of your ass...

This is a group discussion. Isn't it better if you provide the citation, rather than every other interested person having to hunt it down for themselves, and possibly not finding the exact studies you have in mind?

Re:This isn't auto mechanics!

[Cryacin]

Actually, they want something better than they have now as fast as possible. Although I love and admire computationally efficient software, if the choice is a slow software application, or nothing at all, I'll take slow thanks and then complain until they fix it with a new version.

Working programmers don't have time to hype.

[Anonymous Coward]

An important thing to remember is that those who are actually getting stuff done usually don't have a lot of time left over to be hyping their preferred technology online and in magazines. They're just too damn busy using C++ to implement the important native apps that are generating real wealth, for example.

The only reason we hear so much about Ruby, JavaScript, NoSQL and other crap like that is because its advocates are, well, often very, very unemployed. Being unemployed, they have lots of time to sit around and write articles about how great their technologies are, although nobody is willing to actually pay them to use these technologies!

you are doing it wrong

[luis_a_espinal]

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.

Your point about the nuances of releasing resources other than memory (.ie. a network connection) are dead on. It is one of the main weaknesses of Java.

Your second point on multiple inheritance, however, makes no sense. You rarely come up with a valid need for multiple inheritance in C++. The majority of cases for modeling require single inheritance and that's it. And that's equally covered rather well in both C++ and Java. For the rare cases of using multiple inheritance (last time I ever saw it was for implementing multiple CORBA interfaces in Java 10 years ago) one simply uses a "tie", a delegation/composition mechanism using typical design patterns.

If you find yourself copy/pasting code for implementing multiple inheritance in a language that does not supports it, you are doing it wrong. Don't blame the language, blame yourself. In the general case, composition over inheritance, specially multiple inheritance. We have known this for quite some time.

TFS: FTFY

[fyngyrz]

incompetent and/or lazy programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net

Re:TFS: FTFY

[cowboy76Spain]

No. There are incompetent and lazy programmers everywhere. Many of them consider themselves competents and even speak badly of others because they do not follow their follies or manias.

Managed code means that you can spend less time thinking about the system inner mechanics and take for granted* that they just work, and concentrate in the real productive work.

*Ok, everything is buggy. The question is if the framework is more or less buggy than would be the average program without the framework, and then take into account the improvement in work/time needed to complete a project.

Re:TFS: FTFY

[siride]

I dunno, I kind of like having an exception-handing system that works properly and built-in object and type metadata, among other things. GC is meh for me, but I know it's a big deal for some other people.

Re:TFS: FTFY

[The Master Control P]

There's a place for both.

I'm in the process of writing a (real, not proof-of-concept toy) MHD code to run on GPUs that starts in Matlab. I really like that I get to do "stupid little things" in Matlab without having to allocate and deallocate every stupid little string and even more importantly that debugging as it runs is not only possible but easy and friendly.

Then when it's time to perform some complex operation involving a dozen 20 million element arrays in under a tenth of a second, I invoke the compiled CUDA C.

Then I run around my terminals in circles trying to decrypt the object-oriented horror that's not updating something right.

Re:TFS: FTFY

[Creepy]

Yes - and picking the better solution does not equal lazy - NASA was set on their mainframes for years when a Beowulf cluster of Linux boxes did a better job in less time - just because the technology was relevant yesterday doesn't mean it still is today. At least C++11 is finally adding features I have believed were desperately needed 20 years ago - native threading being one. On the minus side, many memory access issues are still not addressed and Microsoft will probably continue to list numerous functions as "deprecated" or possibly not support them at all, fragmenting the language. C++ threads are also incompatible with Microsoft's Windows native threads (as far as I can tell), so I probably still will need to fragment my code for Windows and other OS's like I do now (currently Windows threads and pthreads are managed separately - I can change pthreads to C++ threads).

  I currently work on a client written in .NET silverlight, and despite my personal aversion for Microsoft proprietary products, it was written in about 1/2 the time of our java client (and far, far less than our C++ client) and is definitely less buggy (and yes, I DO have metrics). I suspect we'll move to html5 eventually, especially if MS moves that way, but for at least the short term we're sticking with silverlight and we baseline on 3 even though 4 is out and mono supports it (which is important for iPad support).

Re:This isn't auto mechanics!

[wmbetts]

Don't worry he'll write one.

I Miss Destructors

[Anonymous Coward]

It's a been a while since I've written much C++. What I miss most are destructors. I loved know that when scope is lost for a local variable I could depend on a dtor. I didn't have to worry about cleaning up in finally blocks and so many other cases. Predictably knowing that my dtor would be there to free up mutexes, close sockets and every other resource recovery task I needed was great.

Alt+255

[Pseudonym Authority]

Haskell or Scheme are both good choices. Also, Lisp. Go read a book called Structure and Interpretation of Computer Programs, which is free on the MIT site.

Finally

[Anonymous Coward]

Is this the year of C++ on the desktop?

Re:Platforms that limit which languages may be use

[SplashMyBandit]

In that case write in Java and compile to native with gcj (which can go everywhere C goes for non-gui stuff). If your requirements include the word 'portability' then Java is usually the hammer you should reach for first.

That's harsh

[Anonymous Coward]

Life in prison seems less harsh than forced to program in Javascript for eternity.

Javascript's position is worse than C++'s

[Anonymous Coward]

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.

I'd say that Javascript as still the sole programming language for client side web applications is worse than C/C++. If the programmer goes down to C/C++ level, they are presumably going up against complexity in pursuit of performance. Web applications are supposed to be easy to program, but resource consuming. Javascript should be an easy language, with built in limitations for the lower skilled programmer. Regrettably, the former is not true.

GUI API in Java is that good native apps use it

[Latent Heat]

The GUI API in Java is that good with respect to performance, portability, and features that there are native C/C++ programs that use Java Swing instead of Qt/wxWindows/what have you 3rd party native GUI library.

Yep, you read that right, there are native code apps that use the Java GUI for portability. These apps have names like things like "Matlab", "Maple", and "Mathematica."

Don't believe me? Why do you think Matlab has such a long launch time? It is because the GUI Command Windows is a JFrame that has to class load Swing on startup that makes the launch so pokey. It sometimes divulges its "secret identity" by showing the Java coffee cup icon on the Windows Taskbar when this is going on. Don't think Matlab is anything like a 100% Java app. My guess is the most of it is native code written in some semi-portable C/C++ -- they are just using Java for the GUI.

J# on 360

[tepples]

In that case write in Java and compile to native with gcj (which can go everywhere C goes

How easily does Java go to platforms that only run the CLR? Does J# use anything not supported on the Xbox 360?

for non-gui stuff)

And even for GUI stuff, as long as I write the front-end in each platform's preferred language, correct?

Re:J# on 360

[giuseppemag]

C# and Unity would have been a better choice, btw.

Re:This isn't auto mechanics!

[cwebster]

http://airex.tksc.jaxa.jp/pl/dr/19930073399

one example of many.

throw students in the deep end

[OeLeWaPpErKe]

That's not actually true for learning. I find I learn by far the fastest if thrown in to a problem, and then have someone critique what I come up with. Climbing small mountains first has the effect of solidifying *wrong* information in my brain, which takes ages to get back out. In your metaphor, the reality simply is that mount Everest exist. Training on a molehill where oxygen masks don't matter will lead to forgetting them in basecamp, then dying, utterly convinced of how competent you are.

Throw students on mount everest, make sure to have evacuation options. That's how sherpa's do it (starting with 3-year-olds), and nobody beats them at rock climbing. There, metaphor taken too far ... check.

Besides, small-scale training just doesn't prepare you for the reality. You want to learn how to write every last imperative language there is ? Learn C++ ... then figure out which parts to drop so it becomes C/Java/Pascal/C#/F#/Python ... Learn functional programming (only const functions and objects) ... Monads (think about adding return this to every void member function) ... Learn dynamic typing (always lookup your functions in a map, don't directly call them) .... Learn java (autopointer everything, then look into more advanced garbage collection) ...

And if you want garbage collection to "just work" ... C++ can do that fine. A lot of programs are actually simpler in C++ than in java. They're certainly shorter, although that's hardly a contest when we're talking about java.

Re:throw students in the deep end

[Bengie]

"That's not actually true for learning. I find I learn by far the fastest if thrown in to a problem, and then have someone critique what I come up with." (see "work" learning)

Here's how I learn the best for school:
1) Text book learn something new
2) Use newly learned knowledge to solve a problem
3) See correct way to solve problem; Compare and Contrast benefits and pitfalls between your way and the proper way
4), Win

Here's how I typically learn at work:
1) See problem and identify all major points
2) Design own solution
3) Look for similar solutions and Similar problem points
4) Compare and Contrast mine and others
5) Research benefits and pitfalls
6) Stumble upon proper pattern
7) Win

The school learning is nice because I brings up common issues and proper patterns. Fast and efficient.

The work learning is more rewarding because it involves more research and more intimate knowledge about the issue as a whole, which allows better incorporation of newly gained knowledge. Less efficient, but better results for most common cases. I make the assumption that whatever I come up with, someone has done before, and probably better. MSDN has a pattern for almost everything.

C++ is still the best

[Anonymous Coward]

Good old C++ is still the best language for writing commercial applications. Here are some of the reasons:

* Vendor indpendent. It's the only widely used and supported modern language that doesn't belong to a single entity. There's always a choice of compilers on any platform. If one company decides C++ is not cool anymore and abandons it you are not going to be screwed - just switch to another compiler. That's a very nice way to protect your investment in technology.
* Portable and platform independent. Although porting is not as simple as in Java, it's very much possible - take a look at modern browsers. Libraries such as Qt and Boost can make porting as easy as in Java.
* High quality optimizing compilers that can produce code that's faster than hand written assembly.
* Native code is much harder to reverse engineer or crack. It's an important consideration for commercial software to prevent stealing code and bogus patent claims. Java and .NET can be easily reverse engineered even after obfuscation.
* C++ is fairly high level and is easy to code with good libraries. It's not as modern as C# for example but it's not ancient either.

Runtime matters

[OeLeWaPpErKe]

However there's also the downside. I recently implemented a text parser for certain configuration file checking. Now granted we have huge configs, but :

Python parsing a 3.2 megabyte config file : 50 sec
C++ parsing that same file, same operations, same grammaer : 0.05 sec

(most of the code was parsing code anyway so there wasn't much to rewrite, also 90+% of dev time was spent getting that grammar to work)

This made the difference between the tool being used, and not used. Runtime matters. I participated in google code jam last year only with python, and the runtime is ... distracting. I don't deny the advantages of python : simply don't check for number overflows, simply don't care. But the disadvantages include a 20x slowdown for basic calculations. When problem runtimes for C++ code start exceeding 5-10 seconds, python is no longer an option. The time difference is actually so big that C++ O(n^2) algorithms would beat O(n log n) python algorithms on the large dataset in some cases.

Next year, I'll be using C++ in google code jam. Python is good for shell scripting and basic website operations.

Re:Runtime matters

[GooberToo]

You rant is illogical and seemingly uninformed. You do realize you can combine languages and get the best of both worlds?

And your last statement pretty much says it all - you're either ignorant/dumb or purposely trolling.

It's the framework more than the language

[Tony Isaac]

For most of us, the framework is more important than the language.

Once upon a time, Borland C++ was the best Windows development language out there. OWL made dealing with the complexities of Windows messages and common dialog boxes much easier than standard C++ (not that Microsoft even had a C++ compiler at the time). Microsoft came back with MFC, and then WTL. Both were big improvements over OWL.

But then came .NET. Finally, a complete framework that handled everything, or nearly everything.

Frankly, I don't really care which language I use most of the time. I just want a good framework to provide the gears and wheels, so I can spend my time doing what I really want to accomplish, instead of being forced to create my own widgets.

Re:Platforms that limit which languages may be use

[giuseppemag]

Unity, which uses C# and works greatly on all platforms.

Apparently (my experience as well) LLVM does a great optimizing compiling final step.

Re:Platforms that limit which languages may be use

[Paradigma11]

and sometimes they dont: http://xamarin.com/ .

Die C++ Die

[Anonymous Coward]

I hate C++ syntax. Unintuitive rubbish designed by retarded monkeys.

Object Pascal (Delphi) is a far superior dev environment than this obsolete crap that is a nightmare to code in and maintain.

C++ weinees

[Anonymous Coward]

Is the C++ crowd starting to sound a little like the Lispers? Maybe they've been feeling slighted these past 15 years when half their brethren jumped ship to Java and managed code. But at least it wasn't Smalltalk. Don't think they could have handled that insult.

Python doesn't have a JIT

[warrax_666]

What's your point?

Re:Python doesn't have a JIT

[Moryath]

Python is good for shell scripting and basic website operations.

Then why were you using it for a heavy-duty, huge-config operation?

Re:Python doesn't have a JIT

[Anonymous Coward]

Because creating, changing and analyzing configs is what I normally use shell scripting for.

Oh, nuts, they mentioned Google "Go"

[owlstead]

The most immature PL out there. No exception handling, everything done with (multiple) return values, a very immature API (without modules of any kind, just one big thing that Java is *trying* to get rid off). They've made sure it *compiles* really fast. Now that's nice for a PL that you really really really don't want to create a large system with. And did they really decide on a name that you cannot really google? Yes, they did :)

I see it as a hobby project of some programmers trying to get into language design, nothing more, nothing less.

C++ + Qt

[monzie]

I have used C++ with the Qt framework from Nokia ( formely Trolltech ) and it's a JOY to program in.

C++ and Qt

[Anonymous Coward]

I find C++ together with Qt almost unbeatable :)

Few understand C++

[Anonymous Coward]

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.

The /vast/ majority of professional C++ programmers do not understanding everything about the language. It is a complex mess. Most people get used to a particular subset, and tear their hair out when they stumble across a gotta.

Re:But for learning programming, what's recommende

[T.E.D.]

Well, if the "pointer bruising" bothers you, you could always use one of the myriad of other "native" compiler languages that doesn't rely on error-prone pointers for every damn little thing like C++ does. Ada, Delphi, and Eiffel spring to mind.

Re:This isn't auto mechanics!

[rthille]

Damn the failure of my google-fu :-)

So much comments...

[Anonymous Coward]

588 comments... like bjarne said: "There are only two kinds of languages: the ones people complain about and the ones nobody uses"

Re:Platforms that limit which languages may be use

[zeroshade]

Which means that you have a choice which would be the best language for that situation, which would be different if your situation was different.

Re:This isn't auto mechanics!

[Inthewire]

Divide by one, divide by zero. WRT your sig.

Re:This isn't auto mechanics!

[Anonymous Coward]

This would be the most badass language ever. Just call it "Non-Diplomatic C"

C/C++ is the man

[Anonymous Coward]

The authority thinks it's brilliant and evolutionary to mix up EVERYTHING. I think it is FUCKING STUPID IDEA to mix all sorts of DECLARATION among C, C++, AND OBJECT-C and whatever they called... It mess up the beauty of codes / styles and gets people more troubles to encounter more syntax mistakes.