Slashdot Mirror


C/C++ Back On Top of the Programming Heap?

Drethon writes "On this day in 2008, a submission was posted that C/C++ was losing ground so I decided to check out its current state. It seems that C has returned to the top while Java has dropped by the same amount, VB and PHP have dropped drastically, C++ is holding fast but now in third place and Objective-C and C# have climbed quite a bit. 2008 data thanks to SatanicPuppy: 1. Java (20.5%); 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."

97 of 611 comments (clear)

  1. Re:Because of Windows by i+kan+reed · · Score: 2

    I'm not sure what you mean by "whole os". The entire kernel is basically C, but technically C++ like Microsoft likes. Substantial amounts of things that come on a windows disc these days are written in C#.

  2. When will people learn... by wpi97 · · Score: 4, Insightful

    C and C++ are two separate and very different languages.

    1. Re:When will people learn... by wpi97 · · Score: 4, Insightful

      Yes, for the most part... Except when you write in C++ as though it is C, you get really bad C++ code. C++ has a different philosophy and a very different set of idioms.
      Remember, a good Fortran programmer can write good Fortran code in any language. But that doesn't mean that every language is like Fortran.

    2. Re:When will people learn... by UnknownSoldier · · Score: 5, Interesting

      > except when you write in C++ as though it is C, you get really bad C++

      Total nonsense. Almost every game these days is written in C++ and while they all vary in the amount of applied OOP and generic meta programming, the fastest ones use a data driven approach because OOP is SLOW - raw C++ makes dealing with ONE type of object easy, but it doesn't help dealing with performance issues when you have MANY objects. I.e. Template Bloat, lack of virtual dead stripping, and inflated deep hierarchies, to start with.

      C is a good language because it forces one to think about runtime performance. When you have some junior coder sticking a virtual function call inside a for loop because he doesn't the three levels of pointers being applied the problem is not the language per say, but programmers who don't understand enough of the hardware to know "There Is No Such Thing As A Free Lunch"

      Higher level languages tend to help minimize *developer* time, at the expense of run-time.

    3. Re:When will people learn... by robthebloke · · Score: 5, Interesting

      Except when you write in C++ as though it is C, you get really bad C++ code.

      When you write C++ as though it were C++, you get really bad, terribly inefficient code. If you need to extract maximum performance from your code, a C-with-classes approach to SIMD & multi-core optimisations tends to lead to better results imho. It's very difficult to adhere to what most people refer to 'good C++', because 'good C++' implies nicely encapsulated objects. This doesn't really work so well when you have 256bit wide SIMD registers. Suddenly you find your C++ classes are actually maintaining the state of 8+ objects, and then some of the idioms start unravelling. OOP is currently being stabbed to death by concurrency & parallelism, and there is nothing anyone can do to save it.

    4. Re:When will people learn... by Black+Parrot · · Score: 3, Informative

      Higher level languages tend to help minimize *developer* time, at the expense of run-time.

      If you're really interested in run time, you should be more concerned with asymptotic ("big-O") performance rather than basic code efficiency.

      Also, no amount of speed-up makes up for code that is wrong. The proper reason for choosing a higher-level language is that its readability contributes to correctness.

      --
      Sheesh, evil *and* a jerk. -- Jade
    5. Re:When will people learn... by Desler · · Score: 2

      Ok. Co-routine libraries for C and C++ which list nearly a dozen implementations. I await the imminent 'but those aren't real co-routines' response. Did you even spend 2 seconds to Google this before shooting of your mouth?

    6. Re:When will people learn... by Megane · · Score: 2

      When you have some junior coder sticking a virtual function call inside a for loop

      If that function really needed to be virtual, it's a lot better than sticking a switch statement into EVERY for loop that uses it, with each branch calling the special function for that class type. (Not to mention needing to update every one of those switch statements when you add another subclass!) Or creating yet another function with that switch statement so you can keep it in one place. Or you could put a proc pointer in the struct, which is essentially the same thing as a virtual function call, only with uglier syntax.

      Not to mention that the vtable entries are effectively const, so even when using a virtual function, if you're doing multiple operations on the same object, the vtable access can be kept in a register for multiple calls.

      And if that function really didn't need to be virtual, simply not declaring it virtual will cause C++ to compile a static call. That's what sets C++ apart from other object-oriented languages, though it can bite you in the ass if you don't understand it.

      If you're going to complain about "junior coders" doing something, at least complain about something sensible. The real problem of C++ isn't speed, it's size, due to code bloat from excessive template use, with some degree of "write-only code" due to templates.

      (I use C++ in an embedded systems environment, so templates, exceptions, RTTI, and non-placement new are right out. But "C with classes" works great where you would have to do switch statements or proc pointers. The win is in code that's easier to understand, if you do it right.)

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    7. Re:When will people learn... by Zaphod+The+42nd · · Score: 2

      Almost all Windows AAA games are written in C++.
      Fixed that for you.
      First, they're mostly written in C++ because you don't prematurely optimize. Its the root of all evil, as Knuth said. Then, you go back, and you find your extremely critical sections, your bottlenecks, and THOSE you write specific libraries in C to optimize. But even then, lots of your work is going to be done by existing windows or directx libraries. Those DirectX libraries are written in C, sure, as are drivers... but that amounts to a pretty TINY amount of code.

      If anything, we're moving the other direction, even in mainstream games. Games like Rage, which while running in an engine of C++, have scripting languages running ON TOP of them. Those scripting languages are FAAAAR less efficient than compiled OOP C++, so if that was such a concern, why would they use scripting languages?
      Because for your non-bottlenecks, IT DOES NOT MATTER. Most of the game development just needs to get done as fast as possible, with as little effort as possible, and more and more major game developers are turning to inefficient scripting engines to handle the actual game logic. They only do the absolute bare minimum in hard C.

      So, yeah. C++ is backwards compatible with C, but if you're writing C code in C++, you're almost 100% guaranteed to be doing it wrong. Backwards compatible doesn't mean equivalence.

      --
      GCS/MU/P d- s:- a-- C++++$ UL++ P+ L++ E+ W++ N o K- w--- O M+ V- PS+++ PE Y+ PGP t+ 5- X R++ tv+ b++ DI++ D++ G+ e++ h-
    8. Re:When will people learn... by kraut · · Score: 2

      Except when you write in C++ as though it is C, you get really bad C++ code.

      When you write C++ as though it were C++, you get really bad, terribly inefficient code. If you need to extract maximum performance from your code, a C-with-classes approach to SIMD & multi-core optimisations tends to lead to better results imho. It's very difficult to adhere to what most people refer to 'good C++', because 'good C++' implies nicely encapsulated objects. This doesn't really work so well when you have 256bit wide SIMD registers. Suddenly you find your C++ classes are actually maintaining the state of 8+ objects, and then some of the idioms start unravelling. OOP is currently being stabbed to death by concurrency & parallelism, and there is nothing anyone can do to save it.

      Surely it can be beyond your wit to write array classes to apply SIMD operations efficiently and cleanly on arrays of numbers?

      --
      no taxation without representation!
    9. Re:When will people learn... by Joce640k · · Score: 2

      The closer to the hardware you get, the more the lines blur between the CS ideal (Big O) and the hardware reality (registers and bandwidth and machine code interleaving). You really can't optimize for one without optimizing for the other.

      Sure ... and C++ is just as good at this as C.

      OTOH C++ is good at the big-picture stuff. C isn't.

      --
      No sig today...
    10. Re:When will people learn... by s73v3r · · Score: 2

      Writing modern C++ doesn't mean you have to use OOP. You don't. You can do data driven quite easily.

      However, modern C++ means to take advantage of modern constructs, like smart pointers, and modern containers, instead of using unsafe and non-bounds checked arrays.

    11. Re:When will people learn... by s73v3r · · Score: 3, Funny

      When you write C++ as though it were C++, you get really bad, terribly inefficient code.

      [Citation Needed]

  3. Good news! by 19thNervousBreakdown · · Score: 2

    My two favorite languages aren't dying!

    Whatever anyone else thinks, I think they're not only extremely solid languages that have stood the test of time, but they're both really fun to program in. I know it's at least somewhat subjective, and right tool for the job and all, but that doesn't mean you can't have preferences and it's good to see the "Yankees" of programming not headed into obscurity.

    --
    <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    1. Re:Good news! by goombah99 · · Score: 5, Funny

      My two favorite languages aren't dying!

      Yes, Perl and Ruby combined have twice the share of python. It's really more like 20 times, since you can get ten times as much done in a single line of perl.

      --
      Some drink at the fountain of knowledge. Others just gargle.
    2. Re:Good news! by Hentes · · Score: 2

      Programming is fun when it poses a challenge. So while I agree that C++ coding is fun, it's inefficient for a lot of purposes.

    3. Re:Good news! by Desler · · Score: 3, Interesting

      They were never dying. C and C++ underpin all OSes, the Internet, pretty much the multimedia apps you use, the vast majority of games/game engines, etc. and they are the implementation languages of all the 'hip' fad languages.

    4. Re:Good news! by spatley · · Score: 4, Funny

      ...since you can get ten times as much done in a single line of perl.

      Yes and you will be the only human on earth that knows what it does.

    5. Re:Good news! by zero.kalvin · · Score: 2

      And you forgot scientific programs as well. In our collaboration most of the Monte Carlo simulators were written in FORTRAN, which is not bad, but the problem is finding someone who knows FORTRAN to maintain them. And only recently we have moved to C ( last couple of years). However I noticed that most scientists below the age of 35 use C. Python is used, but only for scripting purpouses ( as it should ). Ps, my domain is astrophysics/astroparticles.

    6. Re:Good news! by Robert+Zenz · · Score: 3, Funny

      That's called "increasing job security".

    7. Re:Good news! by Black+Parrot · · Score: 4, Funny

      ...since you can get ten times as much done in a single line of perl.

      Yes and you will be the only human on earth that knows what it does.

      That's why we call it a "write-only" programming language.

      --
      Sheesh, evil *and* a jerk. -- Jade
  4. Java dropped by the same amount by TaoPhoenix · · Score: 3, Interesting

    Will Java drop even further because of the whole Oracle mess?

      I guess I am surprised that Python is ahead of C#, and that Ruby is so low given its underground buzz.

    --
    My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
    1. Re:Java dropped by the same amount by Theophany · · Score: 4, Insightful

      Probably has something to do with it's buzz being 'underground' and its benefits being widely refuted?

    2. Re:Java dropped by the same amount by capnchicken · · Score: 2

      Python was ahead of C# , what's listed in the summary is the 2008 index, the 2012 index has C# about three and a half points ahead of python.

      Ruby is a hype machine, you can tell by the huge spikes and valleys when you see its popularity graphed out individually over the years. It's seemed to have relegated itself now to about a point and a half now.

      http://www.tiobe.com/index.php/paperinfo/tpci/Ruby.html

      --
      A libertarian shat on my carpet once. Claimed the free market would sort it out. -Ford Prefect(8777)
    3. Re:Java dropped by the same amount by cjcela · · Score: 4, Insightful

      My impression is that Java will eventually relegated purely to in-house software, for large companies that are heavily invested in Oracle. Most of the goodness of Java comes from the Java API's, and these are on a legal battle. Most OS's are already not including the platform by default. At the end, for independent software companies, and specially for small shops, it feels too risky to invest one's time in learning or keeping up with a language that is controlled by a suing-happy company. As much as I despise Microsoft's ways of polluting languages (remember J++?), I think they are orders of magnitude more trustworthy than Oracle.

    4. Re:Java dropped by the same amount by Bigby · · Score: 4, Insightful

      It isn't just Oracle. IBM is more heavily invested in Java than the owner themselves. Google too. Between those 3, you can't possibly avoid Java or think that it will continue to drop in the Enterprise space. Just not going to happen.

  5. Re:Eh? by i+kan+reed · · Score: 4, Funny

    So is Lisp in some sort of state of perpetual undeath then?

  6. PHP at #4 by TheNinjaroach · · Score: 2

    That's interesting to me that PHP is more popular than a language like C#. But I guess when you include VB and all of its legacy, then the whole ".NET" stack is quite a bit more popular.

    --
    I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
  7. Opinion by degeneratemonkey · · Score: 4, Interesting

    Of this list, C#, Ruby, and Python are clearly the best languages as far as I'm concerned.

    The C++ longevity is expected. Every engineer worth his weight in salt should be able to write C++ code. (get off my lawn etc.)

    I am curious abobut where the C growth is coming from. Embedded stuff? Native libraries for the increasing volume other higher level languages? ;)

    1. Re:Opinion by gnasher719 · · Score: 2

      Addendum: Every engineer worth his weight in salt should be able to write Lisp/Scheme code as well.

      I just had to check this. According to what local councils in the UK pay for salt for gritting streets, my weight in salt is worth less than £2.

    2. Re:Opinion by Raenex · · Score: 3, Interesting

      Every engineer worth his weight in salt

      You're mixing up the phrase "worth its weight in gold" with "worth his salt".

  8. Popularity Contest by Anonymous Coward · · Score: 2, Insightful

    The Tiobe index is a popularity contest - a pageant for programming languages - so, you get the trend on what's hot, but that is just part of the IT business.

    I challenge you to find 5 banks whose core are not built with Cobol, for example.

    My point is that real use != trending languages

  9. Windows kernel is C by Comboman · · Score: 4, Informative

    The Windows OS kernel is mostly in C with some assembly (just like Unix/Linux/BSD/OSX). The Windows GUI is mostly C++ (but so is KDE).

    --
    Support Right To Repair Legislation.
    1. Re:Windows kernel is C by chuckinator · · Score: 2, Insightful

      KDE technically isn't C++. It's written in Qt, which is a set of bastardized extensions to C++ (see meta object compiler) that produce generated C++ code. It's unfortunate that Nokia (who bought Trolltech way back when) invested so much time and effort into something the is effectively obsoleted by Boost.

    2. Re:Windows kernel is C by Viol8 · · Score: 3, Insightful

      Except that Boost is an unholy mess designed by students who threw in everything they thought would be cool without a decent overall approach. If it disappeared overnight I wouldn't shed any tears.

    3. Re:Windows kernel is C by Anonymous Coward · · Score: 2

      That was my concern when I started to use Qt.
      But now, after a couple of years, I find the Qt approach just OK: everything is handy when you are building the GUI. You can focus on GUI development without having to build complex functionality in first place.

      The QString, for instance, I do not see it as a replacement of std::string anymore. I use std::string for methods which do nothing with the GUI, but I use the QString flexibility to provide a message or whatever quickly, at the GUI side. It is easier to write:

      QString something = QString("blah %1 out of %2").arg(i).arg(n);

      than:

      ofstringstream oss;
      oss "blah " i " out of " n;
      string something = oss.str();

      You may use the std:: way when you are concerned about efficiency (or even use char*), but the QString approach is just fine for the GUI. Well, I've not tested QString performance against std::string - perhaps it is comparable or faster or slower- it is quick enough for the GUIs.

    4. Re:Windows kernel is C by suy · · Score: 2

      KDE technically isn't C++. It's written in Qt, which is a set of bastardized extensions to C++ (see meta object compiler) that produce generated C++ code.

      This is the worst description I've seen of Qt and the MOC in a long time. Qt is perfectly valid and normal C++. It just requires that you link against some generated code. Big deal. However, since the code generator (Meta Object Compiler) has the word "compiler" in it, either fools some people into thinking that requires some special tool, or is used to spread some FUD.

      Breaking news: the XML files that Qt Designer creates are used to generate C++ code.

    5. Re:Windows kernel is C by ardor · · Score: 4, Insightful

      Some parts of boost are excellent, some are crap. Your comment reeks of ignorance.
      Some excellent libraries are: optional, bind, any, lexical_cast, multi-index container, graph (documentation is awful though), xpressive, shared_ptr, asio.

      --
      This sig does not contain any SCO code.
    6. Re:Windows kernel is C by Tough+Love · · Score: 2

      It is the approach that matters, not the particular library. There is no great trick to Boost signals/slots, I coded a servicable one myself using libsigslot to get the basic idea. The thing is, once you have done so the whole misbegotten MOC mess becomes irrelevant and you can integrate your signal/slot code with, for example, your project templates.

      I keep seeing these elaborate explanations full of bafflegab about introspection and scripting support to justify QT's big design mistake with MOC, but the arguments just don't hold water. You can do all the introspection you need without any preprocessor pass.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    7. Re:Windows kernel is C by Tough+Love · · Score: 2

      QT MOC is the opposite of elegant, it is an abomination. But it has no shortage of apologists.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    8. Re:Windows kernel is C by GuidoW · · Score: 2

      I disagree whole-heartedly. I've been using Boost for a number of years, and although it's been a bit hard to get into at times, and although I've barely scratched the surface of the available libraries, it has made my life a lot easier. Many of the available libraries complement the standard C++ library very nicely. No matter what parent post says, it's also fairly well accepted, to the point that it is not a long shot to expect a random competent C++ code to be able to work with it.

      Personally, I'm pretty much treating it as an extended standard library these days.

      --
      If it's so secret, then how come I've never heard of it?
    9. Re:Windows kernel is C by loufoque · · Score: 3, Interesting

      I'll give you my opinion as an experienced C++ developer, Boost contributor and C++ standards committee member.

      Boost is a set of C++ libraries written by a lot of different people. Some is good, some is bad. Some is old and works with ancient compilers, some is new and requires the latest bleeding edge implementations.The good thing it has about it compared to average code is that it was written by people with a relatively good understanding of the C++ programming language, which is very complex. This typically means that not only it is of better quality than average, but also that it can do more advanced things than what an average developer could think of As such, it is very good for educational purposes, and just reading through the code or the documentation can make people discover very interesting software design. Of course, some libraries have very tedious implementations and are very mature (like PP or MPL), so there is no point in rewriting them yourself: just use them directly.

      The fact that it is advanced is however a double-edged sword: to use software in production, you must be able to easily diagnose problems and bugs, even if the code is not yours. Doing that with advanced language constructs can require some non-elementary skills, therefore using those libraries can require a steep learning curve and should thus be seen as an investment.

      It's all a matter of studying the library for your needs, evaluating the risks, and making your choice.

    10. Re:Windows kernel is C by c++0xFF · · Score: 2

      Oh really? Look at most of TR1 for plenty of examples of Boost libraries that are now part of the C++ standard.

      Boost is a proving ground for many concepts that have since been adopted into the language as part of C++11. Some Boost libraries are no longer needed because of native language support rather than a library (BOOST_FOREACH is now a syntax feature, not to mention lambda expressions), and these language features are often clearly designed after the Boost equivalent (as far as I can tell). Others were imported with not much more than a namespace change (shared_ptr, anyone?). Then largest import was probably the threading library, followed by the random number generators and regular expressions.

      Stack Overflow has a great list to get you started.

      The amount of Boost in C++11 is quite amazing.

  10. Re:Eh? by PhilHibbs · · Score: 2

    Because the linked article is about the current state, the Slashdot article is about the comparison with 2008 and so includes the missing information that the linked article does not.

  11. NXT-G ? by godrik · · Score: 2

    The 20th language is NXT-G. What the fuck is that? Is it really lego's programming language for robots as wikipedia indicates (http://en.wikipedia.org/wiki/NXT-G) ? And that is more popular than bash or matlab?

    1. Re:NXT-G ? by flabordec · · Score: 2

      Because programming LEGOs is awesome! Really, take a look at some of these videos. There are also a lot of competitions for middle level school children and there is a big push to get it into computer science classes at elementary and middle school level, so it is being used a lot by younger kids.

      --
      "I see undead people" Warcraft III - Necromancer
  12. Not a ranking of the best or the most by Relayman · · Score: 5, Insightful

    From the article: "Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written." [Emphasis added]

    It's a survey, no more, no less. Using it to make decisions about your career is foolhardy at best.

    --
    If I used a sig over again, would anyone notice?
  13. The TIOBE index is *ABSOLUTELY MEANINGLESS* by Anonymous Coward · · Score: 5, Interesting

    It's unbelievable that people still pay any attention whatsoever to it. Some company comes up with a ridiculous 'methodology' to gauge the popularity of languages, and people assume that it's actually related in any way to reality.

    Further reading:

    The best place to start is at TIOBE's own methodology description page: http://bit.ly/h3ftBa
    No need to go much beyond that, to figure out that it's a meaningless index. To save you the reading, it more or less boils down to this:

    ---
    The ratings are calculated by counting hits of the most popular search engines. The search query that is used is

    +" programming"
    ---

    That's all.

    Still need some more convincing:

    Why TIOBE isn't all that useful (mild): http://bit.ly/IeG0yA
    The TIOBE index is being gamed: http://bit.ly/IeGnt1

    It's no short of ridiculous. Time to stop paying attention to it, move along!

    1. Re:The TIOBE index is *ABSOLUTELY MEANINGLESS* by Anonymous Coward · · Score: 2, Interesting

      Agree. A better methodology would be to count references in the top job sites monster, dice, careerbuilder, etc. This will give you the languages that are hot now. You'll see a lot more java than C/C++, for one thing.

  14. Re:Buffer overflow by KGBear · · Score: 4, Insightful

    Sure. As soon as someone comes up with a language that produces code that runs half way as fast as C on any OS, and that at least pretends to integrate with the rest of the OS. You know, make it nice for everybody else other than developers. Oh, here's a though: how about developers get their heads out of their butts and learn how to be programmers, instead of whining that real languages don't do everything for them?

  15. Pascal but no Delphi by doconnor · · Score: 2

    What compiler are Pascal developers using that isn't Delphi. Aren't most Pascal compilers capable of handling Delphi's Object Pascal anyway?

    Shouldn't the Pascal and Delphi be combined into one grouping the way that all the different C++ are combined?

  16. On the subject of comparison... by Twinbee · · Score: 5, Interesting

    A shout goes out to this site which actually does a pretty good job of comparing all the languages on 'subjective' attributes such as "I find it easy to write efficient code in this language" (C being top here), or "Code written in this language tends to be verbose" (Cobol and Assembler are worst here, but Java is 3rd place, and that's bad considering it's meant to be a modern higher level language).

    You can even click each language and see what comment it is best for. For example, Haskell is top for "This language has a strong static type system" and "When I write code in this language I can be very sure it is correct". Meanwhile, something like PHP is top for "I am sometimes embarrassed to admit to my peers that I know this language" and "This language has many features which feel "tacked on"".

    --
    Why OpalCalc is the best Windows calc
  17. It is good that java loses ground to C/C++ by ctrl-alt-canc · · Score: 2

    Java floating point management is flawed by design. Using java for controlling anything serious opens up a Pandora box: just look at this (and look here if you don't know dr. Kahan)

  18. Re:Eh? by FrootLoops · · Score: 5, Informative

    The site was loading very slowly so I scraped the 2012 rankings for the curious but impatient:

    1 - C - 17.555%
    2 - Java - 17.026%
    3 - C++ - 8.896%
    4 - Objective-C - 8.236%
    5 - C# - 7.348%
    6 - PHP - 5.288%
    7 - (Visual) Basic - 4.962%
    8 - Python - 3.665%
    9 - JavaScript - 2.879%
    10 - Perl - 2.387%
    11 - Ruby - 1.510%
    12 - PL/SQL - 1.373%
    13 - Delphi/Object Pascal - 1.370%
    14 - Visual Basic .NET - 0.978%
    15 - Lisp - 0.951%
    16 - Pascal - 0.812%
    17 - Ada - 0.783%
    18 - Transact-SQL - 0.760%
    19 - Logo - 0.652%
    20 - NXT-G - 0.578%

  19. Re:Buffer overflow by evil_aaronm · · Score: 2

    Because we can't trust programmers to be smart enough to avoid these conditions...?

    My pocket knife can be used in a completely safe manner. It can also be used in a completely unsafe manner. How it's used it up to me. Because it can be used dangerously doesn't mean that we shouldn't have pocket knives.

  20. Re:Buffer overflow by The+Evil+Atheist · · Score: 2

    Yes. It's called the Standard Template Library. C++ has them and should be used. There's hardly any excuse not to use them, especially now that C++ will get move semantics which can increase performance of the containers by an order of magnitude.

    --
    Those who do not learn from commit history are doomed to regress it.
  21. Re:64 bit porting? by vlm · · Score: 3, Interesting

    I would expect that a lot of companies are probably working on importing their legacy systems to work for the new 64 bit systems.

    a good amount of legacy systems are written in C, and most of those C written programs are fairly optimized for their platform they were designed to run, and we are starting to switch to 64 bit and multi-core architecture.

    You're more or less paraphrasing an email I recall from Linus back in '94 when the 64 bit Digital Alpha port was just beginning. Of course that's 18 years ago not anything new. I think we still have many more years of the "64 bits is new" meme left. With more GOOG effort I could probably find that email. Or it might have been an old Linux Journal article about the alpha port rather than an email. Hmm.

    I was pretty late to the conversion to 64 bits compared to most people in the biz. I don't think the debian amd64 port was released until 2007 ish, I think as part of Debian 4.0/etch, although I was using the amd64 port as "testing" (before it became "etch") for at least a year or two earlier.

    Some of our amd64 hardware at work is considered legacy now, just because its so old.

    I remember in the early years of the 32/64 bit conversion, like half a decade ago, running legacy non-free software like the 32 bit flash player on a 64 bit OS was a pretty interesting problem, but it was all solved a long time ago, so its not interesting anymore. I would imagine someday in the future the windows folks will have similar interesting experiences when they catch up to linux, as they always eventually do.

    --
    "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
  22. In Other News... by Anonymous Coward · · Score: 3, Funny

    Home Depot has reported that the hammer has moved up 2 places in the rankings overtaking the Phillips head screwdriver and pliers as the most widely used hand tool. Also moving up in the ranks were the flashlight and the crescent wrench, precipitating the further decline of the Allen wrench and the drill bit in the rankings.

    Haha, who still uses the Allen wrench? Clearly the Phillips head screwdriver is superior. Newbs.

    1. Re:In Other News... by vlm · · Score: 4, Funny

      Hammer - Obviously perl. Technically, you can do absolutely anything with it, but sometimes the results will look like hell. Swiss-Army Chainsaw makes a good second tool choice for perl.

      Phillips screwdriver - Obviously Ruby. The mythology is both came from Japan, although phillips doesn't sound very Japanese, in ye olden days stuff made in America had slot screws and stuff made in Japan had philips screws, so obviously phillips came from Japan. Also more ruby is probably being written outside Japan than within, now a days, but I still hear people claim Ruby is japanese.

      Just fill out a physical plant request form in triplicate and get your boss/mom to sign and your bosses boss to notarize - Obviously the hyperverbose business languages like cobol and java where hello world takes 3 pages and an hour of explanation.

      Plumbers helper / plunger - Obvious GDB reference

      Table saw - Obvious assembly language reference. Works great and fast, until you cut your hand off and it makes a mess of the project.

      Having trouble finding analogies for the rototiller and the roofing nailgun. Please advise...

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
  23. Re:Buffer overflow by Artraze · · Score: 5, Insightful

    Given the prevalence of SQL injection attacks, which could be prevented with a single function call, I have to say that buffer over-(and under-) flows are really a red herring. Unless a language makes it literally impossible to write insecure code, lazy and bad programmers will find a way.

  24. Re:Buffer overflow by cowdung · · Score: 4, Insightful

    A pocket knife doesn't implicitly create objects or fail to cleanup if you forget to make your destructor virtual.

    C++ has very complex rules that take years to hone and understand correctly, and even then mistakes are easy to make. The proof is that even today when you go to C++ forums people are still asking about obscure language rules while in Java forums the conversation has moved on to issues of design. Nobody needs to discuss the meaning of language constructs in Java because they are obvious.

    It isn't however obvious that an error in your cannonical class definition could cause this code to create a memory leak:

    a = b;

    Clearly proper use of a tool is important. But tools without safety features are more likely to cause accidents.

  25. Re:Eh? by azalin · · Score: 3, Funny
    I would rather suggest it to be the gate to the underworld.

    “Through me you pass into the city of woe:
    Through me you pass into eternal pain:
    Through me among the people lost for aye.
    Justice the founder of my fabric moved:
    To rear me was the task of Power divine,
    Supremest Wisdom, and primeval Love.
    Before me things create were none, save things
    Eternal, and eternal I endure.
    Abandon all hope, ye who enter here.”

  26. Readable C? by waterbear · · Score: 2

    C is awesome incarnate: lean, readable and full of low level goodness.

    C can be readable .... if the programmer has kept to a reasonable kind of discipline and order in the coding, that is. (FTFY)

    Obfuscating C can be as hard to read as old 'spaghetti Fortran', I think.

    -wb-

  27. Re:Buffer overflow by Imagix · · Score: 4, Informative

    now that C++ will get move semantics

    Not will, _has_ move semantics. As of last August.

  28. Re:Buffer overflow by Junta · · Score: 5, Insightful

    Might as well start off writing it all in assembly, since compilers don't always produce the fastest possible code.

    Actually, things are advanced to the point where with very rare exception a human writing assembly is almost certainly not going to produce the optimal approach anymore. First, compliers represent the result of the best and brightest and trial and error for optimizing code structures into streams of assembly that are frequently counter-intuitively faster than a person is likely to think of on their own. Secondly, prcossor manufacturers tend to get their latest and greatest instruction sets into compilers, and trying to keep up with those dynamics would be implausible for a human writing special purpose code.

    So manually writing in assembly is no longer always faster in practice and in fact usually slower. I don't think the same claim can be made of any particular managed language compared to C/C++.

    Although I will agree that language choice *usually* matters far less than algorithmic choices and occasionally people jump to a language change in a project to alleviate slowness only to end up not significantly better than they started because of glaring design problems that dwarf the language performance concerns.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  29. Re:Buffer overflow by KGBear · · Score: 2

    No matter what the question is, "switch to a different OS" is never the correct answer. People should be able to pick the best OS for the job, as well as the best language for the job. C# and .NET integrate well with Windows because they don't run on anything else. I would rather have options. And the term "premature optimization" is a good example of the kind of idiot that writes code these days. Not doing what you call "premature optimization" is what I call being sloppy. Being lazy. Do it right in the first place so you don't have to do it again.

  30. Java is poor for memory-intensive codes by j.+andrew+rogers · · Score: 5, Interesting

    There is definitely movement away from Java and toward C/C++ for some types of software. Applications bottlenecked by memory performance, like databases and high-performance codes, will often be faster than a language like Java by integer factors. When people assert that Java is about as fast as C/C++ they are talking about code like tight, CPU-bound loops. However, Java is wasteful of memory and CPU cache lines in a way that C/C++ is not under normal circumstances which has a significant adverse impact on the performance of some codes.

    On recent processors, memory performance is a bigger bottleneck than CPU performance for performance-sensitive codes. The throughput of CPUs has grown faster than our ability to keep those CPUs fed from memory. In the supercomputing world this started to become evident years ago; memory benchmarks like STREAM became more closely correlated with real-world performance than CPU benchmarks like LINPACK for a great many algorithms. The resurgence of C/C++ is partly driven by this reality since it makes memory optimization relatively straightforward and you can receive large gains relative to Java for modest effort.

    A smaller but also important driver away from Java is the GC. The increasing focus on "real-time" and predictable latency for applications like analytics and database engines is complicated when Java's garbage collector is inserted in the middle. This is a chronic point of pain for some applications.

    I developed Java for years but my latest project (a real-time analytical database engine) is being written in C++ for the above reasons, among others. Writing high-performance applications of this type is actually pretty painful in Java because you end up doing unnatural things in the language to even approach the efficiency of conventional C++. Anecdotally, many of our C++ developers were doing Java until recently so the statistic does not surprise me.

    1. Re:Java is poor for memory-intensive codes by dkf · · Score: 2

      The days where we could just say "it's ok, buy a bigger server" or "next year we'll have enough computing power" are over. We now have to do more with what we've got, and that means more efficient programming.

      The days of the hardware being trivially the source of all speedups required are long gone. Also long gone are the massive shared memory machines; they really didn't scale without the use of enormous amounts of money and that never really changed (the real cost of supercomputers back at around 2000 was in the funky backplane interconnect). Now, we have to learn to do more with message passing (that scales far better, in many ways) and we need to learn to only pass around the data that's necessary (because such communications cost).

      The "downside" of this is that all those programmers who decided that parallel programming was all about throwing shared memory and threads at a problem before sprinkling in locks to stop things crashing, well those programmers' skills are pretty low value now. The tech they picked can't ever scale up or out. People used to network programming are in a better position; after all, that's clearly about true asynchronous coding...

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    2. Re:Java is poor for memory-intensive codes by Tyler+Durden · · Score: 2

      Until you're stuck trying to debug the memory leak in your C/C++ code because the server won't run more than 2 hours without barfing.

      And if you hire the right developers, that never happens in the first place. Don't believe me? Consider all of the countless OS kernels, embedded devices and games developed in C or C++ that run without a hitch.

      Hell the only places where C/C++ coded servers barf in 2 hours are in the fevered imaginations of Java programmers who think managing your own memory is soooooooooo hard.

      --
      Happy people make bad consumers.
  31. Re:Buffer overflow by Dishevel · · Score: 2, Interesting

    A pocket knife doesn't implicitly create objects or fail to cleanup if you forget to make your destructor virtual.

    C++ has very complex rules that take years to hone and understand correctly, and even then mistakes are easy to make

    I am not sure why you do not understand this but....
    Idiot programmers are idiots.
    We need good programmers. Programming IS complex. It needs to be. There is not a language that is flexible, powerful, fast and will wipe your fucking ass.
    Pointing out that your experience in forums is crap.
    What you see in C++ forums is what you are looking for. Same with Java.
    Java doesn't have obscure commands because it can not do anything obscure.
    Just because you are comfortable in Java and are clueless when it comes to C++ says nothing about the languages.
    When you start working on some real machines in environments that just get shit done you will see C, C++, Perl, Assembly and shell scripts.
    Then you will start looking around and notice PHP shit and Java and bits of shit all over.
    In all of that you will see crap coding and good coding. If you can not code well you can go play with with languages that are weak and slow but may allow your shit code to run. But when someone else looks at your code they will still see that it is in fact, Shit.

    --
    Why is it so hard to only have politicians for a few years, then have them go away?
  32. Re:Eh? by BasilBrush · · Score: 2

    The interesting one is Objective-C has nearly overtaken C++. It'll probably be passed in the next couple of months.

    In fact if the trend continues, Objective-C will be the most popular language in about 3 years.

    http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png

  33. Re:iOS, games, etc ... by w_dragon · · Score: 2

    That's only if you recompile in 64 bits. If you take the 32-bit executable and just run it on the 64-bit OS it should work fine. You can even continue compiling in 32-bit mode on a 64-bit OS if you want, so long as you don't want more than 2GB of memory everything should be fine.

  34. Re:Buffer overflow by JAlexoi · · Score: 2

    Java is not exactly issue-free as well. For example lack of comparison operator for strings forces a programmer to abandon an intiutive ways of doying things and to always remember to follow the language obscure rules.

    String is an object. All objects are to be compared using equals method. It's not obscure by far. Compare that most C++ queries.
    If you want a good obscure Java language requirement, it's the fact that arrays are objects and essentially don't have a functional equals method(you have to use java.util.Arrays).( So next time you post this, at least you'll have a good example)

  35. Re:Eh? by timeOday · · Score: 2
    Nice graph.

    Just speculating here, but I expect Objective-C to level off since it's essentially bound to one company, Apple.

    Java, sadly, seems to be in decline as it transitions form a real programming language to a vendor-specific one. (Granted C# is still enjoying a very long-term, steady rise, but Oracle isn't Microsoft...)

  36. Re:Eh? by tibman · · Score: 3, Interesting
    --
    http://soylentnews.org/~tibman
  37. Re:Because of Windows by Bengie · · Score: 2

    Windows is written in C with C++ wrappers to the APIs. All of the Win32 APIs may be accessed via C. There is a limited amount of .Net applications in Windows because most services/etc, must be able to function with a barebones install. I saw an interview with an MS devel who wanted to use C# for the interface to the Windows Media Player for Vista/Win7, but they were not allowed to use .Net as it cannot be assumed installed in all cases.

  38. Re:Buffer overflow by Waffle+Iron · · Score: 4, Insightful

    ...And as with most language standards standards, that actually means that a developer can safely begin to use the new feature in portable code starting around the year 2025.

  39. Re:Buffer overflow by rev0lt · · Score: 2

    Errors != security issues. Buffer overflow and underrun errors are serious issues (mostly mitigated by modern libraries and safer coding practices), but security issues that arise from them are mainly the OS fault. 1:1 mapping of code and data segments is dumb securitywise. It's not we were lacking in linear address space in popular architectures all these years (today maybe). Long story short - the shortcomings of a given language are only a part of the shortcomings of the whole system.

  40. Re:Eh? by rezalas · · Score: 2

    That depends on the method used to gather the information. If you consider the percentage to be the ratio of software titles released to a language and the number of companies advertising the applications that are generated when compared to the market, I'm kind of suprised that the iPhone hasn't driven that number much higher. Mind you, they aren't basing these stats on lines of code, or even the real strength of the language within the programming community: they are basing it on popularity at the moment. FTA "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. ".

    From what I can tell the numbers are highly inflated by ads, increased numbers of classes for "non-programmers" trying to make it big in the app world, and small businesses advertising for short term contract work to build a simple app. Personally I think these language numbers are skewed too heavily and too easily to hide the truth. C/C++ (of which I don't program in professionally right now) are both extremely popular and have been for a long time. I don't see that changing any time soon, just as I don't see most established languages being replaced (Cobol programmers right now are at a premium).

  41. Re:Buffer overflow by Imagix · · Score: 2

    Get reasonably recent compilers. GCC 4.3 already had some of the C++11 stuff implemented, as did Visual Studio 2010. Move up to GCC 4.7 and Visual Studio 11, and you get more complete C++11 implementations (as well as Clang).

  42. Re:Buffer overflow by sympletun_1997 · · Score: 3, Interesting

    For the record, this has been true for a couple of decades. There are only a small number of cases where writing assembly can produce better code, and most of those have to do with application-level semantics that can harness register data to get better results. One example of this is bignum math, where it's frequently useful to sample the carry flag to optimize sequential addition. Even here, however, this effect is usually achieved by compiling the C code to assembly and then hand-optimizing only the smallest portion of the code to use the carry/borrow flag.

  43. Re:Eh? by jones_supa · · Score: 2

    As I see your message twice now, I assume it can be seen in 3D using some special glasses.

  44. Re:Because of Windows by Richard_at_work · · Score: 3, Informative

    It depends what you are doing with it - in the server space, .Net is used all over the place (Dynamics CRM, SharePoint, SQL Server, Exchange - all have a dependency on .Net these days).

  45. more to 64-bit than that by Chirs · · Score: 3, Interesting

    Moving to 64-bit may be a recompile away *for perfectly written code*. In the real world, a lot of 32-bit code assumes you can store pointers in ints, assumes that alignment and packing rules of pointers and ints are the same, prints out pointers using int formatting, uses algorithms that don't scale beyond ~16GB of memory, etc.

  46. Re:Buffer overflow by Creepy · · Score: 3, Interesting

    Wow... I haven't touched assembly since about 15 years ago. Trying to program your assembly to outperform a compiler with out-of-order instruction execution on the CPU takes a mad genius. You probably would get about 10x the speed boost by rewriting code to use GP-GPU instead.

    In defense of the grandparent, I'm fluent in C++, program it every day, and find it a mindbogglingly complex set of bolted on features that keep expanding and some that overlap each other. From a design perspective, elegant would be the last word I'd use for it, and it really was never a well designed extension on top of C IMO. Objective-C is a MUCH cleaner object extension to C, but it ties you to Apple (yeah, I know about GNUStep, but Apple drives the development of the language). In addition, many C++ features were so poorly implemented that they are rarely used, like try-throw-catch (I have yet to see professional code that uses them - hell, I've seen more code that uses the taboo GOTO for error handling than try-throw-catch). Templates are extremely powerful in C++, but often lead to ugly, obfuscated code. Multiple inheritance has also caused me many headaches compared to interfaces (like Java and Objective-C). C++11 only adds to the feature bloat, but some of the features are more "finally" for me like lambda functions and native multithreading. I've wanted native multithreading since I first started thread programming back in 1991, having to use 4 different thread libraries for 4 platforms (I believe pthreads, Windows threads, MacOS9 threads, and BeOS threads at that time - this was all student programming and I was still learning C++ and very self-motivated). D seems to have cleaned up a lot of the issues I have with C++, but wasn't ready for prime time when I tried it last (several years ago).

    I have a love hate relationship with perl, too (another language I use practically every day). It gets the job done, but really, I never needed objects in perl, and haven't used any new features since about perl 3. That said, it is the best cross platform shell language that I've found, and I can write and run quick powerful cross platform scripts.

  47. Ah, TIOBE again. by Millennium · · Score: 3, Insightful

    TIOBE makes for an interesting toy measure. But for truly reliable conclusions, particularly those related to the health of our favorite technologies, we must instead ask: does NetCraft confirm it?

  48. Aburd nonsense. by warrax_666 · · Score: 2

    Make the insecure code hard to write and make the secure code easy to write. Problem 99% solved.

    --
    HAND.
  49. Re:Eh? by Cinder6 · · Score: 2

    Maybe you should try understanding the language? Objective-C is dynamic. That means it won't do type checking the way other languages will. You have to be a little more careful than with other languages, but it does have its benefits--some of which are described here.

    Also, Xcode will definitely spit out a warning if you try something like that, and you can always turn on "treat warnings as errors". You act like it will merrily leave you clueless as to your mistake, which is untrue unless you suppress warnings. (You can also use forwardInvocation: or exception handling if you have no way of avoiding the situation.)

    --
    If you can't convince them, convict them.
  50. Headline is misleading by Bill_the_Engineer · · Score: 2

    Actually 'C' is the "top dog" whereas 'C++' is #3 behind Java.

    C recently had its standard updated and the uptick could be a reflection of this. Not to mention the increased exposure that C is getting from objective-C.

    --
    These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
  51. Re:Buffer overflow by s73v3r · · Score: 2

    C++11 only adds to the feature bloat

    What feature bloat? If you don't use the new features, you don't incur any cost. No bloat.

    And many of the new features that you really should be using (smart pointers) have very little, if any overhead.

  52. Re:Buffer overflow by KGBear · · Score: 2

    Sorry, maybe I'm old, but I don't believe in systems designed to think for people.

  53. No Groovy? by sapgau · · Score: 2

    What no Groovy? Oh well, I should follow the masses mindlessly without considering the right tool for the job.

  54. Re:Buffer overflow by Darinbob · · Score: 3, Insightful

    Because too many of these programmers don't program anymore. They just tie together modules and libraries with function calls and templates.

    The reason C is still big is because there's just so much stuff out that that is not a PC. On a PC you can get away with being unskilled and sloppy, because memory is getting cheaper, CPUs are getting faster, and users are becoming less discerning. Most computers in the world though are not PCs, they're small things hidden inside of devices and they don't run Windows. Some may be slow, some may be fast, but most have resource constraints of some form. Quite a lot of them come with no third party OS or run time library either. And someone has to write all that stuff in something that's reasonably efficient and portable and C and C++ are pretty much the common choices.

  55. Comment removed by account_deleted · · Score: 4, Informative

    Comment removed based on user account deletion

  56. Re:Buffer overflow by Darinbob · · Score: 3, Insightful

    For a lot of functions it is not difficult to write if more efficiently than some good compilers. It's a trick to optimize it the way you need to for certain resource constraints. You wouldn't want to do that for everything, it would take too long. But it's doable for key functions in run time libraries (ie, writing a memcpy that knows how to use your cache instructions).

    The "average case" is fine most of the time but quite often there are exceptions. I've seen people who rely on this stuff too much, who argue until they're blue in the face that STL maps are "proven optimal by people smarter than you".

  57. Automatic cleanup by Dcnjoe60 · · Score: 2

    Without automatic cleanup, it was only a matter of time before C/C++ rose to the top of the heap.

  58. Re:Eh? by dkf · · Score: 2

    How on earth can you think that malloc()/free()/strcat()/strdup() and raw pointers is good programming practice?

    It's pretty horrible, but it doesn't have the deployment horrors that C++ does. (I've worked with a few programs that were C++ and building redistributable binaries of them was always a pain; when the developer switched to using C, the problems went away.)

    The real problem of C++ (apart from its half-assed-ness in the OO department, from a Smalltalk perspective :-)) is that it tends to bind consumers of interfaces very closely to the implementations of those interfaces. Yes, this makes the object code fast, but the cost is that it also makes it much more brittle. Having to recompile the world (a slow business with C++, unlike most other languages) just because of the addition of a private variable to a class definition is not a winning strategy, and PIMPL is a band aid. (It also tempts programmers into writing inline methods to "simplify" access to the implementation fields and methods, all of which is heading rapidly back into the hell of tight binding.)

    --
    "Little does he know, but there is no 'I' in 'Idiot'!"