Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

C++ Creator Confident About Its Future 241

Posted by Zonk from the he-loves-his-baby dept.
bonch writes "Bjarne Stroustrup is confident about the future of C++. He says there is a backlash against new languages like Java and C#, and that developers are returning to C++." From the article: "He claimed the main reason why people are not aware of this is because C++ doesn't have a 'propaganda campaign.' Sun Microsystems has touted the use of Java in the Mars Rover program, for example, but Stroustrup asserts that C++ was also used.
This discussion has been archived. No new comments can be posted.

C++ Creator Confident About Its Future More

C++ Creator Confident About Its Future

Comments Filter:

  • C++ Should Be The Only Programming Language (Score:4, Funny)

    by rqqrtnb ( 753156 ) on Saturday April 23, 2005 @12:05PM (#12323339)
    Today's Software and IT industries are plagued by programming errors. While some of these errors are the result of illegal use of non-Microsoft software on rogue networks, the majority of problems stem from difficulties in mingling code of different programming languages. Standarization on the best-of-breed programming language, C++, would undoubtedly reduce errors in software.

    In this article, I seek to dispel the myth that non-C++ languages are beneficial in proper Software Engineering. I outline how standardization on the C++ language can strengthen your corporation's bottom line. And I describe how to contact the men in Congress to have C++ use finally made legally mandatory.

    C++, a programming language invented by Lucent's Bjarney Strupstrup in 1995, has been hailed as a God-send to Computer Science since its creation. Based on Richie Kerninghan's language "C+", C++ brought several previously-theoretical programming languages features to the mainstream:

    Church-Rosser Compliance
    Known as "multiple inheritance" in the programming world and as "being Church-Rosser" in academia, C++'s compliance to this IEEE standard immediately placed it head-and-shoulders above other languages. "Churrossity" allows programmers to use blocks of code, called "objects," in place of other blocks of code ("arrays".) The layman can think of this as "allowing 'new' code to 'run' old code." This advance has not been possible in previous logic-based languages such as Ada.

    Multi-Byte Characters
    C++ allowed use of "Beaster," a subset of Microsoft's COM ("Common Object Model") windowing layer. The Beaster system allows non-English-speakers such as the Welsh to use computing technology, as it could redirect the signals used to display non-English characters on a computer's monitor screen or laser printer. It is also useful in helping the blind, who speak a specialized subset of English called "ALS."

    Pass-By-Text
    A non-recursive pass-by-text mechanism existed in Kerninghan's C+, called "macro facility." But Strupstrup did Kerninghan one better with the "String Template Loader" variable passing mechanism, which allowed text to be passed to procedures at run-time. This sped up code execution times, as code could be compiled while the user was running the program. This eliminated speed loss caused by incompatibility from obselete computer chips (Motorola and ADM.)

    The superiority of C++ over other languages should be obvious. But is switching to it from other languages possible in your corporation? Astute observers will note that the eco-terrorist group FSF produces a C++ compiler called "DJGPP." Under President Bush's War on Terror, any organization supporting a terrorist organization is recursively itself a terrorist organization.

    Corporations needn't worry. Microsoft has its own C++ offering, "Visual Studio." As an added bonus, Microsoft Visual Studio is highly standards compliant. It features a visual programming interface, and several features not found elsewhere (such as a visual debugger and an AOL instant messanger client called "Windows Messaging".)

    But these advantages can only be realized if code written in inferior languages can be kept from polluting the inter-web eco-space. When compilers for other languages are available, low-level managers are tempted to write code in them. Why? Often times, managers are brought up from the ranks of Software Engineers, and thus lack an Executive's sense for using the right tool for the job. When these managers write code in a jungled zoo of languages, code in one program is unable to interact with code from another program (churrossity.) Only by standardizing on C++ can all programs run together smoothly. Using C++ to eliminate software errors will jump-start the sagging technology industry. This will boost our economy as a whole, which in turn will help us to win the War on Terror.

    The effort to legally mandate this has been going on for a while. But it needs your

    • plagiarism (Score:5, Informative)

      by cronian ( 322433 ) on Saturday April 23, 2005 @01:37PM (#12323951)
      Isn't this copied from http://www.adequacy.org/public/stories/2002.7.4.18 3710.3582.html?
    • C++ is still far better than Java. What most people call Java benefits are truly it's drawbacks too. The least you could do is get the dates right. Here is a history of C++ [hitmill.com]. From the article:

      C++ was written by Bjarne Stroustrup at Bell Labs during 1983-1985. C++ is an extension of C. Prior to 1983, Bjarne Stroustrup added features to C and formed what he called "C with Classes". He had combined the Simula's use of classes and object-oriented features with the power and efficiency of C. The term C++

  • creator of the C++ programming language (Score:3, Interesting)

    by Atrax ( 249401 ) on Saturday April 23, 2005 @12:05PM (#12323347) Homepage Journal
    Creator?

    OK, mod me troll, but surely C++ is by definition an 'extension' of C?

    So, creator is a big word. Or perhaps the lack of context is the problem? Or maybe I'm just a language nazi?

    mod me pedant....

  • While it would be nice... (Score:5, Insightful)

    by 0x461FAB0BD7D2 ( 812236 ) on Saturday April 23, 2005 @12:16PM (#12323429) Journal
    it seems that with corporate support, Java and .NET technologies, as well as Perl, PHP and Python are the major languages for the future, not C++.

    Apart from PHP and Perl, the above languages are usually very strict in their object-oriented ways, and thus prevent loose syntax and clumsy errors. But this nannying produces only poorer developers who rely on the language rather than their own abilities to code effectively.

    A return to C++ would be nice, especially in educational institutions, as it provides all the necessities of modern languages, bar effective string-handling, while maintaining the simplicity of older languages.

    While Java and .NET may be the future for enterprise software, developers should learn C/C++ first, and not Java, as those who can program effectively in C and/or C++ tend to code better in Java and .NET, while the reverse is not true.
    • You dont hammer a nail with a screwdriver , and you dont program an OS in Java.
      C++ fills a rather difrent void and there is place for all , it really depends what you want. Right tool for the job as always applys
      • ..., and you dont program an OS in Java.
        C++ fills a rather difrent void and there is place for all

        How many operating systems are coded in C++? I know a lot that have been coded in C, but none that have been coded in C++.
        • That comment had nothing really to do with C++ other than it being another language ,it was related to the hamering a nail with a screwdriver simile.

          I probably should have said
          You dont hammer a nail witha screwdriver , and you dont program a modern "First person shoot'em'up" in java.
          But the point remains the same
          • I agree with your point that C++ fills a void. And no matter how many times I've cursed the language (I've written more lines of C++ in my professional career than any other language), I still think it was stupid that de Icaza chose C over C++.
            • C and C++ each fill a void but those two voids all too often cross over .
              Also I guess its which of the two your more comfertable with , perhaps c++ would be a better all purpose choise , but if he has more experiance with C, it can more than make up for any short-commings.
        • How many operating systems are coded in C++? I know a lot that have been coded in C, but none that have been coded in C++.

          OK, I'll play. Let's stick to current, reasonably popular operating systems to make things easier. Which do you think are written in C?

          • the BSDs, including OSX, linux, probably all commercial Unixes, Linux, probably most of Windows (from the actual source of 2000 I've seen), with some parts C++ (the original NT programmers lamented Cutler's decision to force C++ on them for the GDI)...what else..probably QNX and most other realtime operating systems. Even BeOS used C for its kernel.

            I woud say that most userspace operating system code is stil written in C over C++...even on windows.
        • I find C++ very good for machine vision software, and only OK for GUI programming.

          It's fast and has many features that give you flexibility in design (templates, multiple inheritance, operator overloads etc).

          For GUI I prefer C# or Visual Basic.
        • Symbian OS (for mobile phones) is coded in C++.

    • Re:While it would be nice... (Score:4, Insightful)

      by Chris_Jefferson ( 581445 ) on Saturday April 23, 2005 @12:57PM (#12323697) Homepage
      bar effective string-handling

      out of interest, what's wrong with std::string?

      • Re:While it would be nice... (Score:5, Insightful)

        by Lally Singh ( 3427 ) on Saturday April 23, 2005 @01:50PM (#12324018) Journal
        It's an actual C++ feature. 90% of the people on this site that say they know C++ know C with classes.
      • Actually, you are right. There isn't anything wrong with std::string. However, a regexp feature, a la Perl, would be nice.

        • Re:While it would be nice... (Score:5, Informative)

          by mobydobius ( 237311 ) on Saturday April 23, 2005 @03:03PM (#12324415) Homepage
          if you really are interested in c++ regex, you should get to know Boost [boost.org]. It is a fantastic set of libraries that play nice with the standard c++ library, and includes regexes, parser generators, threads, algebra and probability packages, serialization, custom memory handling, and more.
          • I actually like Boost, but it would be nice to have it as part of the standard itself. C++ is woefully lacking in features that newer languages likes Java and C# have by default.

            I haven't fiddled around with Boost threads though. How would you rate them against protothreads?
            • never used protothreads. im not an expert thread programmer, and i like boost::thread because i find the interface and usage pattern recommendations simple enough to follow, but not dumb enough not to do useful things with it. it doesn't aim to be a cutting edge thread library, but a library that encapsulates stable thread notions, and can be used to build higher level ideas.

              iso c++ standard moves slow to be sure. since much of boost is a proving ground for the standard, and since it has its own review
            • I've never understood this. What's with people's fascination with the libraries provided with a language? On the one hand, we have people complaining about how awful C++ is in terms of "language design" (by which they're referring to the actual grammar of the language, what you can/can't do with it) and on the other, people complaining about what libraries come with it. I always thought that, given that most languages are capable of importing any new libraries you give them, the vocabulary wasn't an issue:
              • Entirely true. However, there is a difference between languages like PHP, Java and C++: for the former two, the modules or libraries are largely centralized, while for C++, there are so many ways to do the same thing. This means that shared libraries would have to be deployed together with the application itself.

                While not everything can be included in any language, for it would truly be a behemoth to program and deploy, there are some things which all languages should have. The problem is where do you draw
              • What's with people's fascination with the libraries provided with a language? [...] I always thought that, given that most languages are capable of importing any new libraries you give them, the vocabulary wasn't an issue: if they don't provide you with function XYZ that you can imagine and want, then you just write it yourself, or find someone else who did

                Because when you're an open source programmer working on small projects, you want to pull in several different libraries and use them together. If they

            • Several of the people behind boost also sit on the C++ stand committie. They have suggested that boost is a proving grounds for things that will be in the next standard.

      • It's clunky, and something of a workaround; strings are still treated as char * types internally unless stated otherwise, so you have to jump through some hoops to get proper string manipulation. You can't, for instance, do this:

        std::string s = "Hello, " + "World";

        C++ interprets that as adding two pointers to type char together, which does nothing useful whatsoever. Instead, you have to do this:

        std::string s = (std::string)"Hello, " + (std::string)"World";

        Further, string manipulation is inconsistent

      • out of interest, what's wrong with std::string?

        A fairer question might be what's right about it. ;-)

        Seriously, the string-handling in standard C++ suffers horribly from design-by-committee.

        To give the most obvious example, there's no way to write a literal std::string, which in turn means that basic syntax like "a"+"b" doesn't work, even though the + operator is used to concatenate std::string objects.

        There are also glaring inconsistencies in usage, because of all the history using char*, and then

      • out of interest, what's wrong with std::string?

        It doesn't support Unicode well. Specifically,

        • It doesn't support variable-length character encodings like UTF-8 or UTF-16.
        • wchar_t is not a standard size. (It may be two or four bytes, depending on your platform.) So you need to define your own ucs4_t specialization to portably hold wide characters.
        • There's no decent transcoder in the standard. boost has utf8_codecvt_facet [rrsd.com], but currently it's for internal use only. (With a class like this, you could use st

      • out of interest, what's wrong with std::string?

        See http://bstring.sf.net/features.html [sf.net] for my own take on std::string and other string libraries.

        In short, its slow, it doesn't have bounds protection, has slow interopability with char * strings, has mediocre functionality (no insert, no overwrite, no find-replace, no split/join, no useful line-input). Various implementations have thread safety problems, and I don't know if it is aliasing safe.

        Of course it is possible to implement safe and powerful strin

    • "But this nannying produces only poorer developers who rely on the language rather than their own abilities to code effectively."

      I know this is shockingly off-topic, but it is interesting how stating something like that seems pretty obvious and logical when talking about computer programs. The reason I mention this is that your comment could very easily be applied to western (or at least American) culture in general. We have become a culture of safety where anything even remotely dangerous is banned or s
    • A return to C++ would be nice, especially in educational institutions, as it provides all the necessities of modern languages, bar effective string-handling, while maintaining the simplicity of older languages.

      . You may complain about Java etc. being inefficient or coddling developers, but the design of C++ is strictly a case of bolting object orientation onto a procedural language in a very crude manner, then throwing in the kitchen sink just so that it has feature xyz. It collapses of it's own weight. C
      • Personally, I believe it survives because it mixes the robustness of object-oriented languages with the minimalistic procedural approach. It survives because its design is adept at conforming to anything thrown at it.

        Java, for one, doesn't allow for RAD. It requires a structured design and systematic coding. People have invented scripting languages based on Java, and this highlights Java's serious lack of flexibility. The problems with .NET are obvious - it's tied to one platform and the framework required

      • Nice troll. (Score:5, Insightful)

        by rjh ( 40933 ) <rjh@sixdemonbag.org> on Saturday April 23, 2005 @02:07PM (#12324118)
        It is so bad that it took a decade just to get compilers that worked properly
        The C++ Standard wasn't finalized until 1998. We're seven years out from the Standard, and we've had good compilers for more than a couple of years now. GCC 3.0 is where I draw the line for "good C++ compilers", but Intel and other firms had good C++ compilers for a similarly long time.
        But C++ is an abomination--
        Most C++ enthusiasts, myself included, will agree with you. In some ways, C++ is a lot like Perl. Larry Wall said about Perl, "The language is such a mess because the problem space is such a mess." The same applies to C++.
        I can't imagine why it survives at all.
        If you can't imagine why it survives at all, that strongly suggests you've never bothered to learn why it's survived.
        no consistency of design
        You've clearly never read the C++ standard, where one design goal guides all of the C++ specification: "you don't pay for what you don't use".

        You've also clearly never done serious programming with the Standard Template Library, where the algorithms are written so generically--and so consistently across different data types--that they can be plugged together in an almost limitless number of configurations.

        • You've also clearly never done serious programming with the Standard Template Library, where the algorithms are written so generically--and so consistently across different data types--that they can be plugged together in an almost limitless number of configurations.

          Yes, 'clearly.' That always wins an argument.

          STL is a cute idea, but an abomination. I had the task of a subset of the STL. I still have nightmares about it. I know more about C++ than any man should.

  • Look! A funny. (Score:5, Funny)

    by tb3 ( 313150 ) on Saturday April 23, 2005 @12:19PM (#12323446) Homepage
    "...Stroustrup asserts that C++ was also used.
    I bet he also trys to catch all the code NASA uses.

  • C++: too complex (Score:3, Insightful)

    by Anonymous Coward on Saturday April 23, 2005 @12:20PM (#12323458)
    I never saw the point of C++.

    I've been programming a while. Familiar with Lisp, Smalltalk, etc. My first "favorite" language was C, which had a certain simplicity that appealed to me. I also liked Objective C.

    When I first saw C++ it seemed complicated and half-baked. Objective C was SO much nicer. And one C++ program would work with one compiler, but not another. The language was in a state of flux apparently. So I ignored it, thinking it would be finished later.

    By the time I looked at it again, computers were fast enough so that "scripting" languages like Python were practical for big projects, and elegant enough to write good programs in. C++ was still a gigantic clunky mess. I remember seeing those "What's wrong with this program?" ads with C++ examples and being utterly confused. And any language that "mangles" things should be avoided I think. :-)

    Also Java looked like "what C++ should've been".

    And now the programming world seems to be returning to a desire for simplicity, elegance, "Agility", and C++ just doesn't cut it. My favorite language today for practical work is Ruby, with the occasional C extension.

    So, to me, C++ is an obsolete language.

    • Re:C++: too complex (Score:4, Insightful)

      by Anonymous Coward on Saturday April 23, 2005 @12:31PM (#12323521)
      You can not match the cleaniness and performance of C++ in regular C. To do the same things you do in C++ in C while maintaining the same performance looks ugly and complex. C just doesn't have enough functionality.

      Ruby is slow even for scripting languages. It's fine for many things, but if you need performance Ruby doesn't cut it. And if you really need performance no scripting can cut it and you gotta use something better.

      Nothing can equal the power along with performance that C++ gives you. It's not perfect and has some serious issues, but it's the best we have in terms of performance combined with power.

      • Ruby is slow even for scripting languages. It's fine for many things, but if you need performance Ruby doesn't cut it. And if you really need performance no scripting can cut it and you gotta use something better.

        The ideal way of doing things is to write as much as you can in the scripting language. This is almost always faster and more efficient in terms of programmer time. Then, you go back and redo the speed critical bits and pieces in C or C++.

        When this dawned on me, I really began to appreciate T

        • The ideal way of doing things is to write as much as you can in the scripting language. This is almost always faster and more efficient in terms of programmer time. Then, you go back and redo the speed critical bits and pieces in C or C++.

          I've heard that a lot, and certainly the argument has merit.

          Where it sometimes breaks down, IMHO, is that learning a new language isn't free. It's a myth that any good programmer can learn a new language in a week. Sure, they can learn the basic syntax, and if they'r

      • C is a perfectly fine language to program even large scale projects in. I know for a fact that both MDK II (BioWare) and Halo (Bungie) were written entirely in C. (In fact, everything in Halo was statically allocated! No mallocs!)

        This quote is 15 years old, but I still think it gets to the heart of the matter:

        "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" --Tom Cargin (C++ Journal, Fall
    • > I remember seeing those "What's wrong with this program?" ads with C++ examples and being utterly confused.

      Q: "What's wrong with this program?"

      A: "It's written in C++."
    • Listen, C++ is complicated because it's a 3 paradigm language. In the hands of someone that knows what they're doing it can produce nice code.

      If you want to talk about half-baked, let's compare Gnome/Gtk+ to Qt/KDE. You have performance issues that would only be solved with something like C or C++, and when it comes to technical superiority there is no doubt that Qt and KDE are better.

      Frankly, many unix heads and others are just afraid to learn something more complicated, but much more powerful. You ca
    • I've been programming a while. Familiar with Lisp, Smalltalk, etc. My first "favorite" language was C, which had a certain simplicity that appealed to me. I also liked Objective C.

      That explains your preference of Objective C. It's a lot more like Smalltalk.


      When I first saw C++ it seemed complicated and half-baked. Objective C was SO much nicer. And one C++ program would work with one compiler, but not another. The language was in a state of flux apparently. So I ignored it, thinking it would be finish

  • C++ has a long future... (Score:5, Informative)

    by DavidNWelton ( 142216 ) on Saturday April 23, 2005 @12:27PM (#12323484) Homepage
    ...like any language that has had its time in the limelight. There are millions upon millions of lines of code written in it, and a lot of that isn't just going to be rewritten from one day to the next, no matter how much buzz and hype Sun and MS spew forth about their new languages.

    I wrote an article about the economics of programming languages that talks about this and other issues that concern the adoption and lifecycle of languages, although be forewarned that the login system is a bit fiddly:

    http://www.byte.com/documents/s=9553/byt1113845246 791/0418_welton.html [byte.com]

  • To those who have not programmed in C++ enough... (Score:5, Informative)

    by pauljlucas ( 529435 ) on Saturday April 23, 2005 @12:48PM (#12323637) Homepage Journal
    ... especially Java zealots, try reading Modern C++ Design [bookpool.com] by Alexandrescu. It'll blow your mind. Java generics don't even come close.
    • Here's a question for everyone: Which is better? An expertly designed and elegant C++ program with all the proper abstractions, frameworks, and methodologies that 1% of software developers can comprehend quickly, or a C program with a flat set of files, simple structs, and a few shell scripts to build it, which everyone understands (and can even debug)?

      Trying to answering this question tears me apart, because I so much like the _idea_ of elegant OO software design. However, I generally find that I can w

      • Re:To those who have not programmed in C++ enough. (Score:4, Informative)

        by the eric conspiracy ( 20178 ) on Saturday April 23, 2005 @01:55PM (#12324049)
        Here's a question for everyone: Which is better? An expertly designed and elegant C++ program with all the proper abstractions, frameworks, and methodologies that 1% of software developers can comprehend quickly, or a C program with a flat set of files, simple structs, and a few shell scripts to build it, which everyone understands (and can even debug)?

        The simple flat file C program that everyone can debug is also a small program. OO really comes into it's own when you get over 20,000 lines of code. Then the kiss C style starts breaking down.


        • With well-organized header files and a little documentation, I've had no problems with C up to 100K lines. The main advantage, IMO, is that C is just so damn simple to "execute" in my mind, and it is very intuitive to step through in a debugger. The only real catch for me is tracking down memory leaks at times.

          Now, for programs with millions of LOC, I don't think any language will be easier than another, just because the program's own complexity overwhelms everything else. Just ask people how quickly th

          • I can't speak for the rest, but it didn't take me long to get into KDE development. KDE is designed well enough that I don't need to know the entire project to work on it. I've submitted a couple patches here and there. I've never looked at 99% of the source code, but I don't need to, since I can quickly find the area of code I'm interested in for the patch, fix it, test and submit.

            Now KDE does need some experts who understand the entire thing, to make sure I'm not adding something that should be done

      • That is a general problem, I did most of the stuff in the last years trying to cover with good OO design and patterns, but I constantly find myself in a mess of too many classes to cover a domain, functionality which is split over several classes, which are layered. Many classlibs I have seen have similar problems, due to the fact that excessive pattern usage enforces heaps and heaps of classes covering domains, which probably could be easier covered by a few hacks within a procedural domain.

        I am not agai

      • An expertly designed and elegant C++ program with all the proper abstractions, frameworks, and methodologies that 1% of software developers can comprehend quickly, or a C program with a flat set of files, simple structs, and a few shell scripts to build it, which everyone understands (and can even debug)?

        That's a slightly loaded question, don't you think? ;-)

        Any high-level design tools are a double-edged sword. When used well, they allow you to express designs more simply and clearly. When used poorly

    • This is unreasonable. Do you know WHY template programming is so powerful? It's because the template system is a fully functional programming language in and of itself. It's like a scripting language tacked on to the back of another language. It damn well better be better than anything else out there.

      It would be like pairing Java and Python together. Absurdly powerful, but there's a lot of programmer-time overhead in learning and using the systems properly together.

  • Ruby, etc.... (Score:2, Interesting)

    by Casandro ( 751346 )
    I wonder why people bother with things like C# or Java. They don't seem to offer any big advantages over C++. On the other hand, all I've heared of C++ and all I've seen of it and learned of C basically was horrible. I mean mucking around with pointers is something that can be fun, but it definitely doesn't have the beauty you need for doing real work. However there are alternatives. Just look at Ruby, a completely object-based language. You can do thinks like "Hello World".length, or -113.abs . You do not

    • Just look at Ruby, a completely object-based language.

      Mistake number one...

      You can do thinks like "Hello World".length, or -113.abs .

      And how is this an advantage over

      length "Hello World"

      or even

      strlen("Hello World")

      in real life? Do you often find yourself taking the length of a string literal in real code anyway?

      I mean mucking around with pointers is something that can be fun, but it definitely doesn't have the beauty you need for doing real work.

      It does, however, have the practicality yo

  • The reason I don't use it (Score:3, Interesting)

    by prash_n_rao ( 465747 ) on Saturday April 23, 2005 @12:53PM (#12323675) Homepage
    I program for the PC only as a hobby. At work I use only C and program only embedded systems. My industry is strongly and almost universally prejudiced against C++ as they believe it will result in slow applications.

    The basic reason I don't use C++ is the lack of sensible libraries as part of the standard. A programmer desirous of learning cross platform GUI programming has to rely on libraries that are not a part of the standard. I haven't poked around that field for a while now, but IIRC, each system had its quirks and arcane additions. For example, MFC (not cross platform) and QT have implemented their own version of various containers, string classes, etc. MFC relies heavily on arcane macros, QT relies on a weird (from a pure C++ point of view) MOC. I understand they both had good reasons for doing that when C++ was still evolving. But today, it is just a hinderance when trying to write "clean" code.

    Another disadvantage of not having a great collection of libraries in the standard is that people won't know about them unless they dig around a lot. Introductory text books won't cover them, help files in the system won't cover them (if they do, a beginner in that field might not even know what to look for and where to look).

    Do you want a OO library for accessing the serial port? OK... which OS? Windows: use MFC. Linux: google around until you find something on sourceforge. What about some GUI and audio libraries? again, similar method. Fine... now the application has used various libraries from various places. The source now looks like it was done by a person with multiple personality disorder, with each library having its own design and coding approach. Now that you have built an application with ten different sources of libraries, you have to keep track of all of them for bug-fixes, performance enhancementes. Each with its own quirky impact on your application. I went through all this, and eventually gave up C++ in favour of Java.

    And this is just the beginning of my woes with C++.

    • Re:The reason I don't use it (Score:4, Insightful)

      by Jordy ( 440 ) * <jordanNO@SPAMsnocap.com> on Saturday April 23, 2005 @03:14PM (#12324475) Homepage
      You know, you don't have to use a C++ GUI library when writing a C++ application.

      Seems sort of silly to state that C++ doesn't have a good set of libraries when you can use any C library you wish. I do it all the time. There is no reason to create a C++ resolver library when a simple one exists in C already.

      C++ has a very simple philosophy, you don't pay for what you don't use. You can write C and occassionally use std::string if you want to. Nothing stops you from doing it. There is no rule that says, "thou shalt use operator overloading."

      • C++ has a very simple philosophy, you don't pay for what you don't use.

        My ass. The whole point of object oriented programming is abstraction and encapsulation. Try working with two different C++ systems at once. Say, anything and OmniORB. One library might use RTTI, while another might be working on a KISS base class. Another library may be throwing all kind of exception shit. One library may be using std::except, the other might be throwing ints. Or worse, the library implementor may have not read the

        • One library might use RTTI, while another might be working on a KISS base class. Another library may be throwing all kind of exception shit. One library may be using std::except, the other might be throwing ints. Or worse, the library implementor may have not read the 3 lb. "The C++ Programming Language" (try fitting that in a PDF), and is using catch (...) {throw runtime_except()} instead of just 'throw', obliterating any exceptions that you're trying to throw through it.

          So in other words, if you don't

    • A week ago, Bjarne Stroustrup was giving a talk about the work on the next C++ standard.

      One interesting thing that he mentioned, was that C++ was quite popular for embedded programming. Templates is a very nice way to make the compiled code small and run fast (if you got a good C++ compiler of course).

  • I've always liked C++ (Score:5, Insightful)

    by renehollan ( 138013 ) <{ten.eriwraelc} {ta} {nallohr}> on Saturday April 23, 2005 @01:07PM (#12323766) Homepage Journal
    I've coded in various assembly languages, scripting languages (though I forget Perl as fast as I decide that it's appropriate for some piece of glue and am constant relearning it), C, C++, C#, and yes, even COBOL in the dim past (using COBOL to provide indexed file support to Pascal applications via COMPASS trampolines on an old Cyber 835 running NOS was, well, a scizophrenic programming experience). I tend to like the richness of C++.

    However, it's a double-edged sword. It has been said that C lets you shoot yourself in the foot. C++ provides a dozen ways to shoot yourself in both feet and your own back, simultaneously. Be carefull.

    Many have tried to design languages to protect the programmer from themselves, i.e. by providing native garbage collection, disallowing bald pointers, etc. However, this is short-sighted. It presumes what is "hard" and prevents the skilled programmer from replacing the default implementation. C++ new and delete member functions provide no-fuss custom memory management... and probably account for probably half of those ways of shooting one's self in both feet and back.

    A language that is complete in the sense of permitting the coding of fundemental facilities is seductive. It provides an assurance that one can implement "low-level" stuff like memory management, or even the bulk of an O/S kernel in it. The lack of I/O facilities in C, for example, is an intentional feature, and not an oversight. Never have to learn another language again.

    Other languages may provide the convenience of built-in capabilities that are useful for a particular task at hand: awk, perl, and the rash of modern scripting languages come to mind. When the shoe fits, the adaptable programmer will take the path of least resistance. Languages like Java and C# attempt to bridge the general-purpose languages with the protection and features offered by application-specific ones, the latter via extensive run-time libraries (.NET, anyone?). They tend to return to the pseudo-compiled small-interpreter model to provide hardware portability.

    The problem is, that one has do do things the C# "way", or the .NET "way", or the Java "way". Multiple inheritance? Oooh, it's so hard to implement right, and can be so confusing, and, admitedly can be expensive at run-time, so we'll not provide it. Mixin becomes a hack, with language keyword support. Over time, syntactic sugar in the language provides clever support for things like iterators, but binds language features to what should be artbitrary types (Lists are special in C#, for example).

    Well, I want it all.

    A programming language that will let me shoot myself in the foot any way from Sunday if I dare to try... but, with the flexibility to let me say, "Nope. No bald pointers here." Segregation of programmable expressiveness by program, not language, design.

    A programming language that is mutable, so I can invent my own brand of syntactic sugar, and the support to let me quickly find out what mutations a particular piece of code uses.

    A programming language that lets me choose when to evaluate things. Do I want this figured out at compile time? Link time? Load time? Run time? Sorry, C++ templates, though Turing-complete are about as maintainable as APL, if one uses them for anythng clever.

    It's too bad Mary2 never caught on.

    Many will argue that mutable languages result in unmaintainable code: which mutation is in force? I would counter that programs written in non-mutable languages are equally unmaintainable if one does not understand the design of the application. Sure, one can see the "trees", but not the forest: I know x = a + b adds a and b to yield x, but what is that for? The effort to undestand what mutations are in effect is likely similar to the effort to understand an application's design. Except, one has the advantage of a known meta-syntax for expressing the mutatations, instead of having to rely on a design document (which may not exist), likely poorly written or out of date

    • Have you considered Lisp? Seriously. Lisp is pretty much just lambda calculus. Generic functions, run time evaluation. Object orientation if you want. It's incredibly free form, and provides garbage collection, before and after methods, and other advanced structures.

      I know it's become a joke to suggest Lisp, but those that laugh have never used Lisp.
      • Yeah, I've considered Lisp, usually whenever I wonder at the plethora of different grouping constructs in C/C++/C#/Java: (), {}, [], and <> (templates), and question their usefulness.

        They do add syntactic and semantic sugar, of course, but really, I'd like to be the one to define the kind of syntactic sugar they add. It's also the one thing that Lisp lacks: any kind of syntactic or semantic sugar. Forth might have an edge here, but it is less formal a language.

        • They do add syntactic and semantic sugar, of course, but really, I'd like to be the one to define the kind of syntactic sugar they add.

          You may be able to do something kind of like this with Lisp reader macros, but frankly I think it's impossible, or at least near impossible.

          It's also the one thing that Lisp lacks: any kind of syntactic or semantic sugar. Forth might have an edge here, but it is less formal a language.

          I'll grant you Lisp has little syntatic sugar, but it's simplicity yet openness is a

      • I know it's become a joke to suggest Lisp, but those that laugh have never used Lisp.

        (oh (yes (we (have))))

        LISP has a lot going for it, but it also has a lot against it. The most popular programming languages in general use today have a lot of things in common with each other and not with LISP, starting with providing syntactic sugar for various common control structures and vast libraries. Sure, you *could* define your own control structures in LISP and write your own libraries, but why bother when y

        • The most popular programming languages in general use today have a lot of things in common with each other and not with LISP, starting with providing syntactic sugar for various common control structures

          If you mean they all have an algol-like syntax, then you're correct. However I don't know what you mean by "sugar for common control structures".

          and vast libraries.

          Apparently, you haven't really used Lisp, or you'd know that most things that are in standard libraries are handled internally by the lang

          • If you mean they all have an algol-like syntax, then you're correct. However I don't know what you mean by "sugar for common control structures".

            I mean something that highlights the logical structure of what's going on. The most trivial example is probably picking out sequential vs. iterative vs. conditional logic in algorithms. Of course you can do these things in LISP, via cond and such, but there's no particular emphasis on them; they just look like any other bit of LISP. I realise that this is neces

    • You're looking for a Lisp or Forth variant, I think...

      -- John.

  • Some backlash in academics as well.. (Score:5, Interesting)

    by BigZaphod ( 12942 ) on Saturday April 23, 2005 @01:22PM (#12323848) Homepage
    When I was in college for my CS degree, the focus shift away from C/C++ and towards Java was beginning. I was lucky in that my early CS programs were still in C++. However, the classes right behind me as I moved through were getting shifted over to Java one by one. I did not like that at all. It just felt wrong. I figured maybe I was just being biased since I learned C/C++ pretty much on my own without the aid of classes.

    After graduating with my BS in CS, I was out in the field for a few years. I spent some time at a C++ Windows shop which was trying to become gung-ho about C# and the various .NET technologies. The magazines all had big pushes for Java, C#, VB.NET, etc.

    I left that place and moved into a contracting position where I help admin a data center. The attitude there is much different, to say the least. :-) Everyday we have to deal with huge bloated Java web applications that melt CPUs, eat RAM, and are so slow it takes boxes with 11 CPUs just to service a few thousand customers. The distaste for Java that begins in our department has been filtering up the layers and is starting to become apparent to some of the people who build these projects. When you line up a huge app in PHP next to one written in Java, why is it that the PHP one can easily outperform it on less hardware and require less people to maintain it? That all translates to big $$$$ not to mention application stability and performance.

    I'm also now studying for a master's degree in CS. Since I had been away a few years, I was not surprised when I came back to see Java everywhere in the undergrad classes (this at a different school than before). What did surprise me is the attitude of one of my new professors. He taught a projects class where the whole point of the class is to build/do something by the end of the term. It doesn't matter what as long as it fit the basic subject area of the class. After that, you're pretty much on your own (or in a group, if you want). Since this was a different school than where I got my BS, I didn't know this professor. I had seen him wearing a Java shirt a few times, so I was prepared to have to deal with some friction when I went to suggest that I wanted to do my project with C++. One day I stayed after class to chat with him and get to know him a bit. I was shocked to discover that he had done a lot of postdoctoral research using Java and about Java and found it lacking in many very important areas (specifically in high performance scientific computing applications). As we were walking out of the building, he was asking me about my background in programming and computers, so I was giving him a mini life story sort of thing. I mentioned my C/C++ upbringing and how in my college days the Java shift had begun and I didn't quite feel comfortable with that and how I see it seemed to have happened everywhere. That's when he took a careful look around the hallway, leaned in, and said in a hushed tone, "Switching to Java for the undergrads is the worst decision this department ever made."

    I was pretty stunned to hear that from a professor considering what was going on just a few years previous. I hope that sentiment grows and CS departments take back their programs from corporate interests and marketing machines. Perhaps there is hope...
    • Sort of a sidecomment, if a java server needs 11 CPUs you definitely have a problem on your hand which is caused by poor program design.

      I have two java server installations here one serves around 2500 users with around 100.000 hits per month, almost no CPU cycles used, and basically running constantly without any crashes or bigger load on the database (although it uses an OODB/RDB mapper, but omits stuff like EJB, but uses a portlet engine). On the same app server around 10 other webapps with similar load
      • 100k per month? 2 a minute, maybe 10 a minute peek? No wonder you don't need much hardware, your load is a mere trickle. Try handling 200+ transactions per second and then tell me how many boxs you need to handle the load.
      • Sorry, but compared to the stuff we have running, that is a very, very small app. There's simply no comparison. :-) I'd quote numbers, but I never remember them, so I won't try just now. I realize that without numbers it doesn't mean much, but we have PHP apps that handle a greater load than the Java applications doing very similar things on less hardware with less developers and less downtime. This is just how I experience Java--and it ain't pretty.
    • I think that moving to Java is a terrible idea in too, but it has a lot more to do with the teaching than the actual language itself.

      Java is a fine language. I've done a lot of cool stuff in Java. Out of the box, it has libraries to handle multithreading and all sorts of neat stuff.

      The problem is that when you don't have to worry about things like memory management, you lose a huge part of your education. You don't think about things in terms of the kind of resources that you might use, you just do it.

      In a way, it may be possible to go to a purer kind of programming with Java, needing only to worry about the algorithmic complexity of the method that you're coding. In practice, however, I've seen nothing but sloppy work out of people trained from the start using Java.

      I coded in at least 6 different languages through my degree, and I did most of my work in C, not C++. I believe that when you start, you should start close to the machine, not as far away from it as possible. Start with assembly - the programs don't have to be big - and work your way up. Java is the last step you should take, after you understand what it's doing under the hood, and how to mitigate the overhead that those sorts of things will incur.
      • Yeah, learning the basics like memory management is essential, I think, to really "getting" CS. You don't need to know that stuff if you're just going to be a code monkey (although it helps). CS should be about more than just learning how to code.
    • I think you need to teach both C and some clean OO language. You would use C to introduce topics such as pointers and memory management (as part of a course on data structures for example). As for OO, I would stay away from both C++ and Java, as neither really uses OO as a consistent paradigm. Smalltalk would be a good candidate, but it is not deemed "marketable" these days... I don't know much about Ruby, maybe there's potential there?
      • I would generally agree. There should certainly be assembly in the mix, too. I'm not sure it should matter if the language is "marketable" or not to teach it in school. Not in CS, anyway. It should be about learning concepts and not about learning the language, IMO. If anything, the only part of CS that should be language related is when learning how to learn languages. With that in mind, I'd say perhaps when studying OO a course should hit C++, Java, Smalltalk, and Ruby--not just one of them. Of co

  • Id rather (Score:5, Interesting)

    by MemoryDragon ( 544441 ) on Saturday April 23, 2005 @01:44PM (#12323989)
    See objective C with GnuStep as base for the next gen C based frameworks and low level languages, than having that monster without decent classlib C++ rising again.

    Sorry, been there, done that, but the widespread usage of C++ was one of the biggest history jokes ever. A language, as bloated as a language could be, with lots of cool features on the language level, but ommitting the two most important aspects, a good standardized classlib which covers all important application scope aspects, and a language which is actually usable without having to fight with it for years before being able to master it to a certain degree. There was a reason why people flooded to java in 97-98, it was less the hype, it was more the fact, that people tried to implement big long running systems in C++ and saw it was not really feasable in a decent timeframe, due to constantly crashing problems thanks to the missing boundary checks, memory leaks thanks to the missing garbage collector, and general programming errors and unreadable code, thanks to the byzantine bloatware the language in fact really is. Add to that the compiler bugs caused by the 1200 pages of language specs and you could see why people were fleeing from C++.

    And up to date, whenever I have to talk about C++ I only can give the advice, limit yourself in the usage of features and only use a readable subset of it (which would be similar to java and C#), try to omit the C heritage entirely if possible, do not use preprocessors, do not use extensive operator overloading or templating. And check out the KDE/Qt API, they so far have been the only ones to master the language on a design level which in fact results in readable and maintainable code.

    • Re:Id rather (Score:3, Insightful)

      by neonstz ( 79215 ) *

      ...a good standardized classlib which covers all important application scope aspects

      Eh. You have no idea what C++ is used for. Programming isn't just writing nice little programs for desktop computers. C++ is used in everything from tiny microcontrollers to large clusters. Good luck writing a classlib which covers that.

      You mention KDE/Qt as examples on APIs that are good. I use Qt at work and I really like it. However, Qt covers just one (or a few) uses of C++, regular applications which run on standa

  • High School's should teach C++ (Score:5, Insightful)

    by deian ( 736923 ) on Saturday April 23, 2005 @02:21PM (#12324180) Homepage Journal
    I'v been coding in Perl, Java, C and C++ for the past few years and although I prefer using perl and bash I must say that I've learned to think like a programmer having learned C++ first.

    I also eneded up taking a C++ course in High School, and I found that many of my classmates started to think and analyze problems differently. A year later the school changed from C++ to Java ( because the CollegeBoard changed it's CS exams to Java). I also took that class and I noticed that the kids that only took Java, even after completing the course did not learn much - and especially not to think like programmers. I think that this is most likely because Java has so many libraries within that the kids never actually learn what occurs in the "back end." Many fail to understand what a string is, and the majority did not understand algorithms at all, I dont want to mention efficency. Although Java is probablly used more widely, I think that for beginners to learn to think like programmers it would be better to learn a language from which they can learn the basics behind programming, and although I would suggest PASCAL (better for learning algorithms) ,C++ should be taught before Java.

    Learning DSA with Java is a bit funny, how is having a garbage collector efficent and how will that inspire programmers to write more cautius and efficent code?

    Just my opinion, I'd like to learn more.

  • Closed-mindedness abounds (Score:4, Insightful)

    by mattgreen ( 701203 ) on Saturday April 23, 2005 @03:38PM (#12324606)
    C++ takes quite a bit of flak on here, mostly because it doesn't try to be a 'pure' language. It is obvious that people don't understand it by the comments. (Then again, if people only talked about what they understood, the net would be a very quiet place.)

    News flash: most software that I've seen and written benefits from multiple paradigms: procedural for basic algorithm implementation, OOP for the architecture, and generic programming as glue code (generic programming annihilates OOP in terms of code reuse, and you typically don't pay a performance penalty for it.) There are other paradigms, but I don't have enough experience to comment on the efficiency of them. C++ is one of the few languages that gives the aforementioned paradigms a presence and trusts the programmer to choose. You may think this is 'bloated,' but nothing is further from the truth: the overall mantra of C++ is, "you only pay for what you use."

    You can bitch all you want about the importance of language purity and point to languages like Smalltalk or Java as an example of how software should be coded. I'll ask you to point me to popular desktop software that is written in these languages. C++ is the archetype of a hardcore language - a huge learning curve, but insanely powerful in the right hands. It is also really dangerous in the wrong hands.

    Like operating systems, all programming languages suck in some way. Its up to you to choose the least sucky one for the problem at hand. I enjoy writing native, minimal dependency desktop applications in a language that has excellent tool support, can interface directly with OS APIs, and doesn't talk down to me. C++ fits the bill most closely, but I've been told I'd like O'Caml as well.

    C++ isn't going anywhere. The fact that so many people don't understand it or the place that it occupies only strengthens my resume.

  • zerg (Score:3, Informative)

    by Lord Omlette ( 124579 ) on Saturday April 23, 2005 @05:40PM (#12325223) Homepage
    C++ Guru Scott Meyers just asked people, "Why do you program in C++? [google.com]" If that's not relevant to this discussion, I don't know what is... (via Lambda the Ultimate [lambda-the-ultimate.org])
  • "The TIOBE Programming Community index gives an indication of the popularity of programming languages"

    Here is the link http://www.tiobe.com/tiobe_index/tekst.htm [tiobe.com]

    • I guess the TIOBE survey has to be run through the filter that it may reflect what PHB's think they want to hire people for, but it is one of the few public data points we have.

      What I find interesting is that Delphi is roaring back, and it is not just a temporary blip caused by the new Delphi 2005. My guess is its not so much that people love Pascal but some big problem with Microsoft's .NET and their stand on Visual Basic 6.

      If you want to do what Visual Basic 6 used to do (and still does, thank you),

Slashdot Top Deals

Trap full -- please empty.

Close