Is C++ obsolete?

Discussion in 'Computer Science & Culture' started by Greg Bernhardt, Dec 23, 2001.

Thread Status:
Not open for further replies.
  1. Porfiry Nomad Registered Senior Member


    err, yes, you're absolutely right.

    Please Register or Log in to view the hidden image!

  2. Google AdSense Guest Advertisement

    to hide all adverts.
  3. kmguru Staff Member

    While helping out my kids COBOL class last semester, I realized, COBOL can come back too...only if the I/O and syntax is improved.

    Hey, if Apples fancy OS is FreeBSD, anything is possible. Even QDOS or RTDOS can comeback.

    What we need is a new language (called English) that you could talk to it....
  4. Google AdSense Guest Advertisement

    to hide all adverts.
  5. Rick Valued Senior Member

    Are you talking about 4GLS and 5GLS?

  6. Google AdSense Guest Advertisement

    to hide all adverts.
  7. Deus Seeker of Truth Registered Senior Member

    The bulk of my training in programming has been in C++. I'll graduate in 1.5 years and as far as I know there is no plan to move most of the CompSci courses here to Java.

    I wonder how you came to the conclusion that C will last longer than C++. Anything you can do in C you can do in C++, to my knowledge. Why would C++ die out before C? Especially since C++ provides more ability to be object-oriented than C and everyone is talking about how programming should be object-oriented.

    I predict that C++, and to a smaller extent C, will be around for quite awhile. A lot has been written in them, and considering that the major OSs are written in C or C++ insures that there will be a need for the languages for some time in the future. Personally, I don't consider Java to be good enough for powerful computing. It's nice to use if you want to distribute one set of files on the web, but it takes too long to compile and execute, and as far as I've seen, there is no way to have a java application compiled into a stand-alone executable that you can just double-click on.
  8. Rick Valued Senior Member

    Somewhere in this forum(sciforums as whole)someone asked once wether machines would be programmers in future...

    i just learned that Applications of 4GLS is used for such a purpose,
    all you have got to do is provide relevent data.

    (*note:this is different from SQL and other query languages.)

  9. Rick Valued Senior Member

    Java, doesnt make use of pointers!!(am i right Porf?)

    how boring...???!!!

  10. Porfiry Nomad Registered Senior Member

    Err.. since C++ is a superset of C, if C++ is around then C is around. But my point is that there are other, better, supersets of C (Objective-C) that are around and just coming into prominence. Also, those programmers interested in non-crippled object-oriented programming will flock from C++ to real object-oriented languages (C#, Java, Objective-C) as their performance overhead becomes trivial (on faster machines).

    Java is actually quick to compile, simply because it doesn't have to go all the way to machine code.

    Blame Windows for the double-clicking idiocy. Is there any way to write a normal MFC program that doesn't spew .dlls everywhere on your computer? On Mac OS X, everything app (including Java programs) is a single-file object that can be dragged around like any file.

    That's a total misconception. The only real use of pointers is as a reference to dynamic memory. In Java, almost everything is a (opaque) reference to dynamic memory. No, you can't traverse a data structure by incrementing a pointer (since the reference is opaque), but I've never done that in reality in C, and it's pretty bad form to do so.
  11. Deus Seeker of Truth Registered Senior Member

    What I meant was that I think that supersets of C will be used in new development longer than basic C will be. Where do you get the idea that object-oriented programming in C++ is crippled? Just because C++ doesn't force you to program in the OO paradigm doesn't mean that it's crippled. Not everything that needs software will be running a 1GHz processor, you know, so you can't assume that the overhead associated with Java and the like will just disappear because of fast processing.

    I don't know about MFC, but I know that I can write programs that stand by themselves in C++, and every program I've seen written in Java requires you to have Java to run it. That's like writing QBasic programs, where you need QBasic to run them.

    Please Register or Log in to view the hidden image!

    Besides, you can blame Windows all you want, but if you want to write an application for the bulk of users, you need something they can just double-click on, because the bulk of users out there right now aren't very sophisticated.
  12. Rick Valued Senior Member

    I have compiled the information from the following site that may clarify...notice about explicit pointers.

    the above info was taken from the following site:
    Memory Allocation and Garbage Collection

    True confession time: my web pages serve several purposes. One of these is to act as a notebook that I will have access to where ever I have a computer and an Internet connection. This page is under construction. In the short term the purpose of this page is to provide a draft of an article on memory and to provide links to garbage collection sources. In the longer term I hope to provide a polished article that will be of interest to other software engineers. This page was prompted by J.D. Marrow, who kindly sent me a reference to Hans-J. Boehm's Web page on garbage collection.

    Dynamically Allocated Data Structures
    Dynamicly created data structures like trees, linked lists and hash tables (which can be implemented as arrays of linked lists) are key to the construction of many large software systems. For example, a compiler for a programming language will maintain symbol tables and type information which is dynamically constructed by reading the source program. Many modern compilers also read the source program (e.g., parse it) and translate it into an internal tree form (commonly called an abstract syntax tree) that is also dynamically created. Graphics programs, like 3D rendering packages, also make extensive use of dynamic data structures. In fact it is rare to find any program that is larger than a couple of thousand lines that does not make use of dynamically allocated data structures.

    Problems with Dynamic Allocation
    To avoid consuming vast amounts of virtual memory and destroying performance through page swapping, many programs that use dynamic allocation also dynamically deallocate memory when the programmer believes it is no longer needed. This leads to a number of problems including:

    Poor performance. The openGL graphics library supports "display lists" which describe the 3D polygons that make up a shape. A complex scene may have a large number of display lists. Deallocation of a display list, one element at a time, can be very time consuming and can have a large impact on program performance. This can be avoided using a block based memory allocator, where the display list elements are allocated from large memory blocks. When a display list is no longer needed, a pool of blocks can be deallocated. While this technique is effective, designing, implementing and debugging a good block allocator is time consuming.

    Memory leaks. A memory leak takes place when memory is allocated but never deallocated. A major computer manufacturer had a subtle memory leak in one of the window types for their window system. One group of users would run large test programs over night and then expect to scroll back through the windows buffer. The buffer was not infinite and only buffered a certain number of lines. The software displaying this scrolling buffer had a memory leak. It would recover most, but not all of the memory allocated as the window scrolled. As the test ran over night, the window software used up more and more memory, until the entire virtual memory was consumed. The window would then crash, destroying the test run information the user wanted. Tools like purify where not available at the time and this bug tool a huge amount of effort to track down and fix.

    Pointers to deallocated memory. When memory is deallocated there may still be pointers in use to the deallocated memory. The deallocated memory will be recovered by the memory allocation system and reused. Since it may now have two pointers to it (e.g., the live pointer to the old deallocated data structure and the pointer to the newly allocated data structure) the program behavior may be bizzare, running correctly sometimes and getting the wrong result in others.

    Even carefully crafted code written by experienced software engineers tends to suffer from problems with memory leaks and references to deallocated memory. Products like like purify (for UNIX) and BoundsChecker (for Windows NT) are literally worth their weight in gold when trying to track down these errors.

    Java and Garbage Collection
    There are a variety of reasons that the Java programming language seems to be popular. Some of these reasons actually involve software engineering issues, rather than hype and religion. Java does not support explicit pointers (which are a source of a lot of complexity in C and C++) and it supports garbage collection. This can greatly reduce the amount programming effort needed to manage dynamic data structures. Although the programmer still allocates data structures, they are never explicitly deallocated. Instead, they are "garbage collected" when no live references to them are detected. This avoids the problem of having a live pointer to a dead object. If there is a live pointer to an object, the garbage collection system will not deallocate it. When an object is no longer referenced, its memory is automaticly recovered. So, in theory, Java avoids many of the problems listed above. The cost, however, is in performance. Automatic garbage collection is usually not as efficient as programmer managed allocation and deallocation. Also, garbage collectors tend to deallocate objects from a low level, which can hurt performance (e.g., deallocating an openGL display list at the element level). There is a rich body of work on garbage collector architecture and garbage collection algorithms (stemming largely from LISP runtime support, which makes heavy use of garbage collection). A lot of this work is aimed at avoiding the more severe pitfalls of garbage collection.

    C/C++ and Garbage Collection
    Many garbage collection systems rely on compiler support to help the system determine when a pointer goes out of scope, so the object the pointer points to can be deallocated. However, most C and C++ compilers don't support garbage collection. There are several packages that support garbage collection for C and C++. See, for example, Hans-J. Boehm's Web page on the Boehm-Demers-Weiser conservative garbage collector. Another version of the web page on the Hoehm-Demers-Weiser garbage collector is also available at a site hosted by Xerox PARC. This garbage collector is designed to be a replacement for malloc in C and new in C++. The Web pages also provides a reference list. So far I have not looked into the pros and cons of this software (as I mentioned above, this Web page is still under construction).

    Pool Allocation
    In pool allocation, objects are allocated from a pool of large blocks. When a point in the program is reached where this memory is no longer needed, the entire pool can be deallocated at once. For a discussion of pool allocation of C++ objects see Overloading New in C++.

    Other Web pages
    Jamie Zawinski's argument for garbage collection vs. ad hoc memory management (or no memory management and memory leaks).

    The Hoard Memory allocator

    Hoard is not a garbage collecting allocator. However, it does very fast multiprocessor memory allocation for multithreaded software. Accross multiple processors with a threaded application the authors of Hoard claim that they have very close to linear allocator performance. Hoard would be an excellent platform on which a garbage collecting allocator could be built.

    Ian Kaplan
    Last updated, December, 2001
  13. malisha Registered Senior Member

    No Java is never going to replace C/C++ and neither will C#, no chance.

    Not unless the new computers of the future will be using java byte code as the native language for the cpu.

    Java cant access memory directly and it has a slow start up time plus you need the virtual machine just like C#.

    C and C++ will always be used for time critical applications.
  14. Rick Valued Senior Member

    Exactly,Explicit pointers are not used in Java...

  15. sunflow Guest

    Well from c++ and c develops all of our applications, i'm not an expert though i can program but i think that c++ is already obsolete because to do the things that you do simply with Visual c++, or Visual Basic you need a lot of time programming the same things knowing calls to the api windows functions.

    I have built a software using entirely C and i have sepnt a lot fo time, energy and i have get my mind exausted when after i rebuilt the same thing with Visual Basic, it seemed a game for children.

    Visual is the future, c is the past
  16. Rick Valued Senior Member

    Design an OS with VB...????

    never heard of that.anyway,Joe are you hearing this?
    they"re what you call the crowd who are doing that...

  17. malisha Registered Senior Member

    Hehe thats right, or try to write an embeded system with vb. You cannot directly access memory with any language BUT c/c++ or assembler and i would rather code in c++, hell even c then in assembler.

    Your thinking of the application world here, yes C# and VB and delphi are ok for that, but dont forget the bios that is built into your mother board needs to be programmed before you can even start writing applications on the comp and that requires C/C++ or assembler.

    Hell even assembler still has its uses even today.
    And if speed is of the utmost importance then you will never ever choose C# (because its just like java it needs a VM) java or any other language which needs a runtime.

    Plus if you code in ansi standard C or C++ your code is relativly(minor changes) portable to other platforms, unlike vb or C# that is why C and C++ will never be obsolete ever, don think in the application world, think in lower levels hardware, i mean without hardware thats working correctly controlled by fast running C code we wont have any use for those other languages because the computer will be just a very expensice paper weight.

    The only, only way that c and c++ will become obsolete is if they decide that the new processors will run on java byte code or C# bytecode which i think is very unlikely.

    These applications below are only codeable in C or C++
    - real-time systems
    - operating systems
    - embedded systems
    * car electrnoic injection systems
    * your microwave
    * fridge
    * washing machine
    all either use C,C++ or assembler
    - games for pc and console
    * all C++ C and assembler
    To my knowledge there has never been a game written in java besides those tiny online games.

    Even those watches you see which can be programed in java have an OS underneath that which is written in yes C /C++ and/or assembler.
    And this is just a few i can think of right now, there are more.

    Java is nice for writting applications that need to span multiple systems with different os but have you ever ran a windows application written in java, compare the speed at which it runs to a normal c++ program and you will see the difference.

    Yes C++ is a little harder then some of the other languages and its 00 is not as nice as java's (most people say) but thats a matter of opinion, you can program C in 00 style if you wanted even though it isnt an 00 language it depends who's using the language really, but the truth is there is no other language which can do EVERYTHING possible on a computer but C/C++ and assembler.
    Last edited: Feb 9, 2002
  18. Bowser Namaste Valued Senior Member

    I spent a year learning C++ and MFC. I still fall back on C, however. I think C/C++ will be around for many years. I know people who still earn a living writing code in FORTRAN and PASCAL.
  19. Greg Bernhardt Registered Senior Member

    how could you make a living learning pascal? good grief
  20. Rick Valued Senior Member

    That Good Grief expression...made me do this:

    2.)Fell chair...

  21. Ender Registered Senior Member


    Currently at my HIghschool, they are offering C++ and an AP C++ calss. I think that yes the launage will surly die out. It won't we for a long time. Once many software developers decide to not program anything in it, then the everyday programmer will have to say weither it is dead or not. Once all the major corperations have finished develpoing software, then the individual programmer will have a much broader market, and it will thrive with coders. But sonn it will die out.
  22. GRO$$ Registered Senior Member

    Im in HS. I'm talking Honors C++ this year, 1st year its availible. In 2 years the course is planned to be replaced by Honors Java

    Please Register or Log in to view the hidden image!

    Teacher says that Java is more for Application Development while C++ is business-oriented. Just my 2 cents.
Thread Status:
Not open for further replies.

Share This Page