Slashdot Log In
Are C and C++ Losing Ground?
Posted by
Soulskill
on Thu Apr 24, 2008 03:33 PM
from the lots-of-ground-to-lose dept.
from the lots-of-ground-to-lose dept.
Pickens writes "Dr. Dobbs has an interesting interview with Paul Jansen, the managing director of TIOBE Software, about the Programming Community Index, which measures the popularity of programming languages by monitoring their web presence. Since the TIOBE index has been published now for more than 6 years, it gives an interesting picture about trends in the usage of programming languages. Jansen says not much has affected the top ten programming languages in the last five years, with only Python entering the top 10 (replacing COBOL), but C and C++ are definitely losing ground. 'Languages without automated garbage collection are getting out of fashion,' says Jansen. 'The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.'"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
C/C++ is dying! (Score:5, Funny)
Re:C/C++ is dying! (Score:5, Funny)
No, but Stroustrup himself is reputed to have apologized for C++ as far back as 1998.
"It was only supposed to be a joke, I never thought people would take the book seriously." :)
- From the lost tapes of the legendary IEEE interview [nao.ac.jp] of 1998
Parent
Re:C/C++ is dying! (Score:5, Informative)
2. C........14.7%
3. VB.......11.6%
4. PHP......10.3%
5. C++.......9.9%
6. Perl......5.9%
7. Python....4.5%
8. C#........3.8%
9. Ruby......2.9%
10. Delphi...2.7%
The other 10 in the top 20 are:
JavaScript, D, PL/SQL, SAS, Pascal, Lisp/Scheme, FoxPro/xBase, COBOL, Ada, and ColdFusion
Parent
Python+Fortran or JAVA+Groovy (Score:5, Insightful)
This of course is not the match made in heaven for everyone but numerical scientists should look hard.
What's so good?
Utility:
Well there's a strong base of numeric libraries in Python that are fortran array freindly so there's a good base to grow off of.
Second F2PY, which creates python modules out of fortran subs works so well it's almost transparent and painless. Even cooler is that because fortran compiles are ludicrously fast compared to C++, you can generate fortran code in the python compiler at run time and compile it one the fly for creating modules optimized to your problem.
Given you are wrapping in python, the availability of groovy C++ libs is not really very enticing at all given the pain you will pay for having to write the whole program in C++.
Practical:
Fortran as a stand alone language kinda blows for versatility and modern program architectures. But if all you are doing is writing a function then it's a sweet language because it's language syntax is so tight that it's harder to make a syntax error that compiles, and hard to logic errors seem to be less evasive than in C. (e.g. using i++ instead of ++i or doing I=4 instead of i==4 are not possible in fortran's limited syntax).
Thus you write functions and let python deal with all the memory management, human interface, file management, command line arg parsing and all the messy bits that end up being a lot bigger than the function where the program spends all it's time.
Fortran is also very optimization friendly since things like matrix multiplies and out-of-order loops are part of the core language.
This is debatable but I find that fortran seems to have a more logical memory order in 2-d arrays. Namely if you take a sub-array you get elements that are consecutive in memory and thus for most microprocessors will all get pulled into the cache on the same page. Slices of C-arrays have consecutive elements spaced by the row width apart in memory. One can of course find cases where one is preferred over another.
I do however which python had some way of optionally typing variables that was less cumbersome and slow than decorators or explicit run-time type checking. I virtually never write python that takes advantage of introspection or dynamic typing so the ability not to have some protection--optionally and just to debug--by type checking is annoying.
But If I were starting from scratch and did not have a compelling need for all those wonderful fortran numeric libs, I think the optimal choice in the future is going to be
Java+ Groovy.
basically you learn one syntax and get the best of both interpreted and compiled languages. Develop it in groovy then migrate the slow bits to JAVA. import all the great JAVA libs.
And since it's nearly the same syntax it's easy to read.
Parent
Re:C/C++ is dying! (Score:5, Interesting)
Delphi and Pascal are other puzzlers. Pascal is great as a teaching language, but there are later iterations of that family of languages - Modula-2 and Modula-3 - that arguably provide better rigor if rigor is what you are after. And I see no obvious reason to use Pascal or related languages if you're not after truly rigorous code.
C seems to be holding ground, the slight loss seems to be within the fluctuations other languages that are holding steady are seeing. It's too powerful, too close to bare-metal programming and too close to the actual machine architecture to fade for some time yet. C++ might genuinely be losing ground - C# and D provide a lot of the power and object-orientedness of C++ but make an effort to learn from the complexity of C++. Personally, I suspect D might stand a better chance as C# is still very much tied to a single vendor in people's minds. I don't see C++ vanishing, rather I see them reaching some common point and staying there.
VB is quick-n-dirty, and it's popular because it's so easy to write something in it. If it ever became unlawful to have a website that was dangerously insecure or a hazard to Internet traffic (in much the same way cars have to be inspected every so often in some places to ensure it meets certain minimum safety standards) I imagine Visual Basic would lose appeal. Well, that or the EU eventually raising the fines to the point of driving Microsoft out of international competition.
Given that so much new scientific code is still produced in Fortran, whereas not much is really written in COBOL although a lot of legacy code is maintained in it, I'm surprised COBOL is there and Fortran is not. (Fortran is popular enough that there are TWO competing front-ends for GCC for it. There are open-source COBOL compilers, but as far as I know, all work has stopped on all of them. To me, that says something about the level of interest and serious usage.)
Parent
Re:C/C++ is dying! (Score:5, Insightful)
Popular as in people using it, or popular as in lots of people writing about it?
Personally, I'm not convinced AJAX is that popular on the people-using-it count. It's a very useful technique for a particular niche, but it is only a niche.
Parent
Re:C/C++ is dying! (Score:5, Insightful)
Parent
Re:C/C++ is dying! (Score:5, Funny)
1. Java
2. C
4. PHP
5. C++
6. Perl
7. Python
8. C#
9. Ruby
10.Delphi
Please note, there is no language in the 3rd position this year. Seriously.
Parent
Re:C/C++ is dying! (Score:5, Interesting)
Parent
Always be there (Score:5, Insightful)
That's a broken way to think of it (Score:5, Insightful)
Anyway, C is going to stick around because it is the most superb assembly language developed by man. C++ will of course stay around as well, but by modern standards it fails as a "high-level" language. The ceiling got a lot higher in the intervening 20 years; other languages reach much higher in a very useful way. I'd be happy to see less C++.
Parent
Re:That's a broken way to think of it (Score:5, Insightful)
Mind you, I don't think anything else is really set up for it either (Erlang?) but that's going to be the next big challenge.
Parent
Re:That's a broken way to think of it (Score:5, Insightful)
Whatever it is, its compiler and low-level libraries will be written in C.
Parent
Re:That's a broken way to think of it (Score:5, Informative)
I think the parent was implying that C often directly maps into assembly language, and he's right. As an embedded programmer, one of the benefits of C is that, other than register selection, I can often tell you exactly what assembly statements will be emitted by a chunk of C code. Often I do use C as a shorthand for assembly.
Nobody who knows the term "assembly language" will think that C is one. But it's a lot closer than you might think.
Parent
Re:That's a broken way to think of it (Score:5, Insightful)
Is an int 32 or 64 bits? I had better compile a test program and fire up a debugger to find out. OK, since there's no C standard type for "32 bit int", what works on this compiler? Maybe INT32 is defined somewhere?
And don't get me started on implicit conversion.
Parent
Re:That's a broken way to think of it (Score:5, Informative)
C99 fixed that: #include <stdint.h>, then use either uint32_t or int32_t.
Parent
Re:Yes it is (Score:5, Funny)
Best laugh of the day - thank you. =)
Hey, you've given me an idea though. You know what would be even faster? Now...don't stop me until you hear me out, okay?
If Java is faster than C, we should rewrite the Java VM...in Java! Interpreted code running in an interpreter...that is *also* interpreted!
Just think of the speed increase! It would be like using uranium to fuel the space shuttle! Awesome multiplied by awesome.
Parent
Re:Always be there (Score:5, Insightful)
C is perfectly capable of extremely high-quality memory management with significant ease-of-use. However, you get to create that facility, or of course you can utilize someone else's design if you can locate one that fits your API needs, budget and time frame.
For instance, years ago I faced this issue and wrote a module that ensures there are no leaks in any part of an application I write; I also get over-run and under-run detection, named segments, dual-free attempt capture, memory usage reporting, and more. I have debug and end-user levels for the code so that during development, I get enormous detail, while the end user doesn't see that unless I specifically turn it on for them.
I have both pool and chunk level management; I have both pool and individual "free" levels; all of this in very few K indeed.
C is the perfect language to implement memory management in, in fact, because it has perfect fine-grained control over memory.
That goes for other things as well; C is highly capable if you need to build in certain types of OO; objects with built-in methods and variables can be crafted in seconds, with no waste at all; uniform list handling can be crafted (and is an interesting and useful programming exercise.)
C *could* go away as a result of a generation of programmers who really don't know how to deal with such things, but I think it would be a real loss if it happened. The up side is that it'll take a while. There's a whole generation of us who know C quite well, and we're nowhere near dead yet. ;-)
Parent
Re:Always be there (Score:5, Insightful)
However, you get to create that facility
s/get to/must/
Seriously, most people want to sit down and write the logic for their application, not invent (or even copy-paste) memory management schemes.
Parent
Re:Always be there (Score:5, Insightful)
Yes, I understand that perfectly. I'm a huge fan of Python for that very reason.
However, in C, writing memory management only needs to be done once; while writing the "logic for the[ir] application" is done many times. Consequently, the apparent load of writing memory management is much lighter than one might initially recognize. Or to put it another way, once it's done, it's done and represents no load at all.
Further, there are huge advantages to having 100% control over the memory management of your application; speed advantages, fewer wasted/tied-up resources, and all the downhill consequences of those things -- if you don't waste resources, they're available for the user, or for other aspects of your programs. Likewise, if you get things done faster, more CPU is available elsewhere.
Another thing: Depending on an external agency to manage your resources is a two-edged sword. If there are bugs in *your* code, you can fix them as fast as you are competent to do so. Considering you wrote it in the first place, the presumption that you are competent to fix it is usually on target.
If there are bugs in an external agency, you typically get to report them... and wait, bugs happily chewing on the users of your applications, until said external agency gets around to fixing whatever it was. If indeed they ever do.
Same thing goes for list management, etc. Write it once, learn all about it (which is interesting AND increases your Leet Skillz) and now you have a generally useful tool that is as fast as you can make it, totally amenable to fixes and updates, and invulnerable to the ass-draggery of outside influences. I have used my list management module in AI apps, ray tracers, image processing, file management, and even in dialogs to control layer types in various (what I think are) clever ways. I have huge confidence in it, but, should it turn out to be broken... I could fix it in minutes. At which point every app I've written gains ground, all my customers win, etc.
There's something else that has always remained in the back of my mind. As languages get more sophisticated, there is a trend for them to generate much larger and much slower resulting applications. It isn't uniform, and it depends on what you're doing, compilers as compared to interpreters, etc., but the trend itself is pretty clear. For instance, a Python app seems small, until you realize that the Python interpreter is loaded for your one-liner. C++ apps tend to be huge compared to C apps. And so on.
This trend - basically - tracks the increasing availability of memory and CPU power. Seems reasonable enough. But the funny thing is, if you take an app that was designed to run at adequate speed on hardware from, say, 1992, keep the technology behind the app the same if you update it - that is, keep writing efficient C and so on - then the increase in memory and CPU resources serve to turn the app into some kind of blistering miracle implementation instead of the run of the mill performance you get from depending on the latest and greatest HLL with garbage collection, the implicit inclusion of module after module of object-oriented processing and modeling, data hiding, etc., etc.
Directly related to this is the fact that if you attempt a modern task - such as an image manipulation system - in a modern language, you, as the programmer, can be significantly enabled by the language; that is, you can be done sooner, and you can have a lot of things done, too, many coming along for the ride, for "free." Garbage collection / memory management being one such thing. But if you approach the task using C, which is basically capable of creating as fast an application as you are capable of writing, it is so close to assembly, while we can certainly agree up front it'll take you longer, the end result coul
Parent
Re:Always be there (Score:5, Insightful)
Agreed 100 percent. If you write it in C, you can make it run faster with lower resources, but you will spend a lot more time creating, debugging and maintaining it.
Most software simply doesn't need to be that fast. The performance sensitive pieces of code are in database queries (C code), or disk operations (C code), or math operations (C code). Modern garbage collectors also are proven, they're fast, they're reliable. It doesn't make sense for the majority of classes of software, from a cost vs. gain perspective, to use C for the job.
Parent
Re:Always be there (Score:5, Insightful)
That doesn't mean it will be particularly popular, or very likely that you can get a job in doing nothing but assembly programming.
Really, with C especially, just about every advantage it has over more modern languages are advantages that C itself has over assembly. Assembly is still needed, but no one in their right mind would, say, write an entire OS in assembly.
The day is coming when no one in their right mind will write an entire OS in C or C++, or even an entire OS kernel -- depending on your definition of "kernel".
Parent
Re:Always be there (Score:5, Funny)
Parent
Re:not so.. (Score:5, Insightful)
Parent
Re:not so.. (Score:5, Funny)
Parent
Re:not so.. (Score:5, Informative)
C for the kernel
Embedded C++ for the drivers (IO Kit)
But many of the applications that make up OS X however are written in Objective-C.
Parent
Re:Always be there (Score:5, Funny)
Parent
Visual Basic at #3? (Score:5, Funny)
But did anyone else find Visual Basic rising two spots to #3 past PHP & C++ to be a sure sign of the apocalypse?
Re:Visual Basic at #3? (Score:5, Funny)
Parent
Managed code is the way to go (Score:5, Interesting)
Re:Managed code is the way to go (Score:5, Insightful)
I'm not sure why you feel you need to "track memory" in C++. I did an analysis of all the code I've written a year or so ago, and I found that there is approximately one usage of a pointer in every 5700 lines of code (the way I write it, at least).
We have this great stuff called containers and RAII. And for when you absolutely must, must use a pointer, you have boost::scoped_ptr and boost::shared_ptr. I have not coded a memory leak or buffer overrun in C++ in over six years.
The best way to not leak memory is to never allocate it in the first place. The best way to avoid overflowing raw buffers is to not use raw buffers. Use the containers. When you think you can't, think harder.
Parent
Hammers and screwdrivers (Score:5, Insightful)
That says nothing about those languages. All that says anything about is your job.
I write drivers, so I could make the opposite statement. Doesn't say anything about the relative merits of one language versus another though. All it says is that I'm in an environment where C makes more sense.
In summary: A hammer is best when your problem is a nail, and a screwdriver is best when your problem is a screw.
Parent
Re:Hammers and screwdrivers (Score:5, Funny)
I also find screwdrivers to be a very good solution when my problem is sobriety, and maybe Vitamin C deficiency.
Parent
Dying...not hardly (Score:5, Insightful)
What about desktop presence? (Score:5, Insightful)
For performance-critical code there is no choice (Score:5, Insightful)
Besides, measuring the popularity of a language by the size of its web presence is the worst kind of fallacious reasoning.
Re:For performance-critical code there is no choic (Score:5, Insightful)
Yes, some things need to be done in assembly or C in order to `stay competetive' or even just to remain within the realm of the possible. How much that is depends on your application and your platform.
So, systems programmers, you need not worry, your skills are always going to be needed for something.
But let's be honest here, 80% of the applications you can code entirely in Haskell or Prolog or Python or whatever fancy high-level language you may personally have come to love. And of the remaining 20%, you can usually still code 80% of the application in your favourite language and optimise the core 20% in C. (After profiling. Let me repeat that, AFTER profiling.)
Will it run faster and in less memory if you do it all in C? If you do it properly, sure. But that's not the question to ask. If you work commercially, ask for `what will be most profitable in the long run, while remaining ethical'. If you work free software projects, ask for `what will benefit people the most'.
Don't confuse the above questions with `what will satisfy my C(++) hacker ego the most'. And remember that it's not just about getting the code working and making it fast, it's about making the code robust; and in many cases it's also about making the code readable for whoever will maintain it after you.
Apologies for this rant; feel free to mod it down if you so desire, but you, dear fellow programmers, have had it coming for quite a while, as did I.
Parent
C and C++ might die at different rates. (Score:5, Insightful)
Statistics (Score:5, Insightful)
Different markets - different requirements (Score:5, Interesting)
What I love about such studies is that they can confirm any theory you want.
Truth remains that every particular market has requirements which dictate selection of languages.
I doubt that telecom industry (as it is right now) would ever get over C or C++. Just like kernel or system libraries in anything else but C.
If you look at rise of Web - and pleiades of supporting it languages - then both C/C++ are out of question of course. Though again I can hardly imaging Apache or MySQL or PHP being written in anything else but C or C++.
Market for system and telecom programming is definitely shrinking - and consequently their languages. Other markets are now blooming - and their languages are becoming more popular.
My point is that the languages are complementing - they are not competing. After all you have to write hardware, firmware and OS first. Only then your beloved automated garbage collection has possibility to kicks in.
Absolutely (Score:5, Funny)
Yes, but on the bright side, they lose ground about 1.5x faster than Java in most applications.
We've replaced C/C++ with Python wherever possible (Score:5, Interesting)
In practice the speed difference doesn't matter for almost every application we've run into - we have a high speed network load tester in Python, which sounds ridiculous, but it works and it makes it insanely easier to add new tests or behaviors. If we ever hit a bottleneck, we just write a small C extension module and call that from the Python.
I'm saying Python here, but insert your higher level language of choice.
bandwagonism (Score:5, Insightful)
Meanwhile, other segments of the pie are expanding, and few of these new applications are coded in C or C++. Does that mean C and C++ are losing ground?
There is no language out there that serves as a better C than C, or a better C++ than C++. The people who carp about C++ reject the C++ agenda, which is not to achieve supreme enlightenment, but to cope with any ugly reality you throw at it, across any scale of implementation.
For those who wish to gaze toward enlightenment, there is always Java. Enlightenment is on the other side of a thick, protective window, but my isn't the view pretty? I've yet to encounter an "enlightened" language that offers a doorway rather than a window seat. I would be first in line if the hatch ever opened.
The problem with C/C++ has long been that the number of programming projects far exceeds the number of people who have the particular aptitudes that C/C++ demand: those of us who don't need (or wish) to be protected from ourselves (or the guy programming next to us).
It's not economically practical to force programmers who don't have that temperament to begin with to fight a losing battle with self-imposed coding invariants. I'm glad these people have other language choices where they can thrive within the scope of their particular gifts. I don't feel my role is diminished by their successes.
For those of us who have gone to the trouble to cultivate hardcore program correctness skills, none of the supposed problems in the design of C or C++ are progress limiting factors, not within the zone of applications that demand a hardcore attitude toward program correctness.
It's the natural order of things that hardcore niches are soon vacated by those unsuited to thrive there, leaving behind a critical core of people who specialize in deep-down nastiness.
For example, it's not just anyone who maintains a root DNS server. I can say with some assurance that the person who does so did not earn his (or her) grey hairs by worrying about whether the implementation language supported automatic GC.
Let's take a metaphor from the security sector. Ten years ago, a perimeter firewall was considered a good security measure. This measure alone eliminated 99% of TCP/IP based remote exploits.
These days, most exploits are tunneled through http, or maybe I'm behind the times, and the true threat is now regarded to be some protocol tunneled within http.
Then some genius comes along and says "in the security sector, TCP/IP defenses are losing ground". Quoi? Actually, no one is out there dismantling their TCP/IP based perimeter firewall. It's continuing to do the same essential job as ever.
It's only the bandwagon that has picked up and moved camp. Yes, garbage collection and deep packet inspection are now all the rage. So it goes.
Why not go around saying that sexual reproduction is all the rage these days? Would that imply we could eliminate all the organisms that reproduce asexually, and the earth's ecology would continue to function? Hardly.
These new languages are soaking up much of the new code burden because these language are freed from having to cope with the nastiness at the extremes (small and large) that C/C++ have already taken care of.
I would almost say that defines a success criteria for a programming language: if it removes enough nastiness from the application space, that the next language that comes along is free to function on a higher plane of convenience. C/C++ have both earned their stripes. Which of these new languages will achieve as much?
So what? (Score:5, Insightful)
Even Perl isn't as popular as it used to be, now that other languages have started to fill its niche.
Times change, and it should be unsurprising that the dominant programming languages change along with it. Some day, Java, PHP, Visual Basic, Python, and Ruby will all be obsolescent as well. Thirty years ago, computers were vastly different than they are now. In another thirty years, there will have been another quantum leap (intended) in computing. Why should the languages we program them with remain the same?
Natively-compiled languages (Score:5, Interesting)
I don't even mean hardcore real-time mechanical nano-second control of knife-wielding deathbots, just simple, This Must Run As Fast or Faster Than The Rate At Which It Will Be Converted To Analog. Python and Java still don't replace C in this area. (Mainly audio, video, and high-speed mechanical control.) And when it gets complex and you need to get into object oriented models to simplify the programming, there is unfortunately no real alternative other than C++. Combine this with that fact that there are a bunch of great libraries out there written in C++ that would be very difficult to replace, and you're stuck with it.
(I sort of oscillate between liking C++ and hating it, but I'm preferring straight C more and more these days. But like I said, I don't always have the luxury of choice, depending on what libraries I need to use.)
All these other languages mentioned (Java, Python, Ruby, PHP, Perl, etc) do not compile to native code, and all do dynamic memory management. Hell, that's exactly what makes them *good*. But unfortunately they're not so good for real-time tasks.
For real-time, you need deterministic memory management, and native speed. I've been looking at some other languages that compile to native code these days, like D [digitalmars.com], or Vala [gnome.org], but I haven't really decided yet whether I can start using them on serious projects.
I'd really like to learn more about functional programming in this area, too, but there seem to be very few functional languages that are designed for real-time. FAUST [sourceforge.net] is one, but it's only for audio.
Anyone know any other good natively-compiled languages that actually have well-implemented modern features?
I wish it were possible to have a compiled version of Python, for example, but there are many dynamic features it depends on. (Some stuff could be done in Pyrex, which is a pretty cool little project, but so far I've only used it to make bindings to C libraries.)
The C/C++ language space needs to evolve (Score:5, Interesting)
The current generation of managed code VMs clearly have some benefits. But but they fall far short on some of the key properties that make C and C++ so powerful. Even if I grant you that the JVM and
C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.
.NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment
That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2 [pavlov.net], and took some very smart people a lot of work to address.
What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.
I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.
Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and
Re:so what? (Score:5, Insightful)
That being said, I agree with you otherwise. The first thing I thought of when I read the summary was 'lazy coders' when garbage collection was cited as a driving factor. That's the sad fact; many of the kids being cranked out of schools today can't code their way out of a paper bag without a compiler/interpreter that does most of the dirty work for them.
Yeah I know. Get off my lawn.
Parent
That's what's missing from my angry-old-man rants! (Score:5, Interesting)
And before I started up my 80x25 terminal window, I tied an onion to my belt, which was the style at the time.
Yeah. Much better.
Parent
Re:C++ is as good as C# _if_ used correctly. (Score:5, Insightful)
GC is available for C++, but IMHO inappropriate. One of the great advantages of C++ is that the construction/destruction mechanism, along with automatic variables, gives you absolute control of the lifetime of every single resource. Whereas a garbage collected language like Java gives you absolutely no control over when (if ever) an object is destructed. I think it is a little wacky to give up this total control of object lifetimes in return for such a puny benefit, a benefit which could easily be achieved through C++ resource management techniques like RAII.
And anyway, garbage collection is irrelevant if you never "new" anything in the first place.
Parent
Re:C++ is as good as C# _if_ used correctly. (Score:5, Informative)
Programs which use STL containers instead of manual memory management are "trivial?" This is news to me.
Avoiding the use of "new" is not the same as avoiding dynamic allocation. You simply let the containers handle it for you. Yes, there are pointers flying around, but they are out of sight, and managed by code that actually does things properly for you.
Parent