Slashdot Mirror
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."
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
Native was never away. It always has its place. It is just that performance/efficiency is not always top priority.
Modern programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net, which shield them from some of the drudgery of memory management and input validation.
So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain? It's not as if you don't still have to do memory management in say .NET especially since the IDisposable pattern is needed all over the place in user-written code to clean up non-memory resources like file handles, GDI handles, etc held within your objects.
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.
http://saveie6.com/
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.
Look at Objective C or Vala -- just as easy as C# or Java, but none of the headaches of a virtual machine runtime.
There's no -1 for "I don't get it."
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.
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).
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.
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.
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!
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.
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++.
I still have more fans than freaks. WTF is wrong with you people?
...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.
My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
>>Modern programmers have increasingly turned away from native compilation
Uh, not me.
I never saw the benefit, only the pain.
The so-called "managed" environments solved a problem I didn't have while adding complexity I didn't need.
I very much doubt that C++11 heralds any kind of new interest in native code. Rather, native code in general has been getting more attention recently and C++11 just happened to be finalized around the same time. (Disclaimer: C++ is my second-favorite language. I want it to be liked and used, but I'm realistic.)
Nearly off-topic in the article is this gem of a paragraph:
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.
Yes, because managed code has no memory leaks.
Yes, and managed code never has need for manual memory management. Oh wait...
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.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
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.
File under 'M' for 'Manic ranting'
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.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
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?
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).
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.
if C# goes down.. i'm going down with it
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! :(
"Men will never be free until the last king is strangled with the entrails of the last priest." - Denis Diderot.
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.
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.
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.
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.
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.
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.
While this is true and can be very attractive, there has to be someone with native code experience to write the virtual machines, right?
Apparently wizard is not a legitimate career path, so I chose programmer instead.
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.
No sig today...
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?
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
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.
If I can just reach out with my words and touch a butthole, just one, it will all be worth it.
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.)
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.
No sig today...
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?
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]"...
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?
Having to work for a living is the root of all evil.
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++."
tasks(723) drafts(105) languages(484) examples(29106)
>>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.
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...
I have determined that my sig is indeterminate.
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.
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.
Someone had to do it.
... 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.
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.
I believe you have been dealing with class diagrams that are quite to the simpler side of things.
-- dnl
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...
-- dnl
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.
Religion is what happens when nature strikes and groupthink goes wrong.
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.
Check out my lame java blog at www.javachopshop.com
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.
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.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
... 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.
Check out my lame java blog at www.javachopshop.com
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.
No sig today...
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.
:(){
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.
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.
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.
Socialism: a lie told by totalitarians and believed by fools.
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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
You can't just throw out some outlandish statement like this without providing evidence.
So I call bullshit.
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.
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!
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?
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.
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.
Time to offend someone
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
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
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.
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.
Most likely. This person is probably the team lead.
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.
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. :)
tasks(723) drafts(105) languages(484) examples(29106)
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.
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
-- dnl
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
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
You ARE using delete. But it was coded by someone else who did not coded the language itself
-- dnl
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.
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.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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).
Just another "Cubible(sic) Joe" 2 17 3061
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.
So I want me to ignore read all of it and ignore the second half (about boost)?
-- dnl
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.
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.
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...
No sig today...
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++.
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)?
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.
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.
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.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
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.
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++.
or reference counted smart pointers
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.
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#.
My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
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.
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.
No sig today...
Then you are doing boost, not C++.
Nope, I don't use boost...
No sig today...
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.
No sig today...
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.
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.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
The demise of native programming has been greatly exaggerated.
I swear to God...I swear to God! That is NOT how you treat your human!
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.
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."
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
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!
It's The Golden Rule: "He who has the gold makes the rules."
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.
Science advances one funeral at a time- Max Planck
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.
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)
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
incompetent and/or lazy programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net
I've fallen off your lawn, and I can't get up.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
Don't worry he'll write one.
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
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.
Buckle your ROFL belt, we're in for some LOLs.
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).
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.
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.
He was being sarcastic. So i was acknowledging that sarcasm, but that wasn't apparent in the quote.
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).
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.
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.
Questions raise, answers kill. Raise questions to stay alive.
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).
Do you even lift?
These aren't the 'roids you're looking for.
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.
Do you even lift?
These aren't the 'roids you're looking for.
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).
Why can't
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.
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?
http://airex.tksc.jaxa.jp/pl/dr/19930073399
one example of many.
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.
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.
For most of us, the framework is more important than the language.
.NET. Finally, a complete framework that handled everything, or nearly everything.
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
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.
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.
./test
$ 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
$
~child
~base
Do you even lift?
These aren't the 'roids you're looking for.
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?
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
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.
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.
I have determined that my sig is indeterminate.
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++...
Unity, which uses C# and works greatly on all platforms.
Apparently (my experience as well) LLVM does a great optimizing compiling final step.
My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
and sometimes they dont: http://xamarin.com/ .
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.
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!
I have determined that my sig is indeterminate.
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.
Why can't
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.
That needs to be:
But it does succinctly capture why Stroustrup is a fucking idiot.
What's your point?
HAND.
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.
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.
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.
I have used C++ with the Qt framework from Nokia ( formely Trolltech ) and it's a JOY to program in.
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.
-- dnl
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.
Not everything that can be measured matters; Not everything that matters can be measured.
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.
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.
Damn the failure of my google-fu :-)
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
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.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
Divide by one, divide by zero. WRT your sig.
Writers imply. Readers infer.
Been there, done that, got the t-shirt. Kids these days... My e-dick big enough?
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.
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.
I sincerely hope so.
Good luck.
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
Way to ruin a good post.
The correct link is http://gbf.sourceforge.net/
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog