Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Bjarne Stroustrup Previews C++0x 741

Posted by ScuttleMonkey from the tired-of-the-word-committee dept.
Szplug writes "Bjarne Stroustrup has a sneak peek at the additions to C++ that he expects will be completed (hopefully) by 2009. Included are language-defined threads, optional garbage collection, some automatic type deduction, and template concepts. From the article: 'The list of current proposals is still quite modest and not anywhere as ambitious as I'd like. However, more proposals are being considered and more libraries will appear either as part of the C++0x standard itself or as further committee technical reports.'"
This discussion has been archived. No new comments can be posted.

Bjarne Stroustrup Previews C++0x More

Bjarne Stroustrup Previews C++0x

Comments Filter:

  • Comment removed (Score:4, Interesting)

    by account_deleted ( 4530225 ) on Tuesday January 03, 2006 @07:40AM (#14383612)
    Comment removed based on user account deletion

  • Should've just done it in Python/Ruby anyways (Score:4, Interesting)

    by psavo ( 162634 ) <psavo@iki.fi> on Tuesday January 03, 2006 @07:53AM (#14383653) Homepage

    What I started to hate in C++/Java/C# is that there's no easy and standard-conforming way to express complex data 'inline'. Yeah, it's cleaner to make it XML and load it runtime, but there's no simple+quick way to do that either.

    Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.

  • I'd just like to point out - we own it (Score:4, Funny)

    by Anonymous Coward on Tuesday January 03, 2006 @07:54AM (#14383657)
    "And C++ programming languages, we own those, have licensed them out multiple times, obviously. We have a lot of royalties coming to us from C++."

    http://techupdate.zdnet.com/techupdate/stories/mai n/0,14179,2877578,00.html [zdnet.com]

    You know where to send your royalty checks.

    Thanks
    Darl McBride

  • Comment removed (Score:3, Funny)

    by account_deleted ( 4530225 ) on Tuesday January 03, 2006 @07:56AM (#14383668)
    Comment removed based on user account deletion

    • Re:Lisp (Score:4, Funny)

      by Lostie ( 772712 ) on Tuesday January 03, 2006 @09:57AM (#14384247)
      And how will that be pronounced: Thee Pluth Pluth?

    • In size, maybe... (Score:5, Insightful)

      by alispguru ( 72689 ) <bob.bane@me.PLANCKcom minus physicist> on Tuesday January 03, 2006 @11:18AM (#14384788) Journal
      But:

      They don't have writers the caliber of Guy Steele or Kent Pitman, so it'll still read like gargling razor blades

      Their legacy syntax straightjacket will insure the code stays verbose and hard to read. Compare:

      struct ltXMLCh {
              bool operator() (const XMLCh* s1, const XMLCh* s2) const
              {
                  return XMLString::compareString(s1, s2) 0;
              };
          };

      with

      #'string<

      or (comparing apples to apples):

      (lambda (s1 s2) (declare (string s1 s2)) (string< s1 s2))

  • Adding new features is not always an improvement (Score:5, Insightful)

    by Frans Faase ( 648933 ) on Tuesday January 03, 2006 @07:57AM (#14383681) Homepage
    The art of making a programming language lies in giving it just enough features to make everything possible that you want without making thing possible that you want. I feel that at the moment C++ already allows to much "wierd" things that you do not really need in practice. I am affraid that adding new features and new language constructs only will make things worse, not better.

    I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass. In this respect I would like C++ be more like Java (or TurboPascal for the matter) where interface declarations and compiled code are unified. At the moment moving around code from one DLL to another is a lot of work, while in my perception, it could have been completely transparent from the users point of view.

    I do realize that keeping backwards compatibility was one of the design features of C++, and that it also determined the success of C. But as many C++ tools are now able to make use of precompiled headers, it seems that the problem should be able to be done away with.

    • I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass.

      Even though headers and libraries are the most common problem I come across from day to day, it wasn't until now that I thought about it as an implementation problem.

      I'm not sure about the preprocessing bit. ifdefs and includes to get prototypes an

  • More features - is that what C++ really needs? (Score:5, Insightful)

    by JackDW ( 904211 ) on Tuesday January 03, 2006 @07:58AM (#14383683) Homepage
    I'm a long-time fan of C and C++, but I've been converted to Python recently. Endlessly copying the C model is a bad idea. C++ did it, Perl did it, then Java copied C++, and all are perfectly servicable languages, but they are not clean, simple or pretty.

    If we want to write complex and secure programs quickly, we need better languages, and more features does not mean better.

  • C++09??? (Score:3, Funny)

    by mwvdlee ( 775178 ) on Tuesday January 03, 2006 @07:59AM (#14383687) Homepage
    The work on C++0x has entered a decisive phase. The ISO C++ committee aims for C++0x to become C++09.
    C++ octal-9???

  • Slashdot interview? (Score:5, Interesting)

    by nyri ( 132206 ) on Tuesday January 03, 2006 @08:03AM (#14383710)
    How about having a slashdot interview about C++0x with Strousrup? I think it would be a good forum to gain more insights about C++ and a fine possibility to allow a community (in this case the slashdot readers) to make and to vote on feature proposals.

  • This has brought out the C++ haters (Score:5, Insightful)

    by MeridianOnTheLake ( 691931 ) on Tuesday January 03, 2006 @08:03AM (#14383711)
    This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++). There is a reason for this; it is because C++ is both incredibly effective and extremely efficient. Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++. But when they want flexibility they go for Ruby or Python or something similar. If you want outstanding applications, you use an outstanding language like C++. If you want average applications, you use an average language like Java.
    • This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++).

      And the guys who write those apps are the very ones who hate C++.

      You have to use C++ for a couple of years to truly, honestly hate the language.

      • Re:This has brought out the C++ haters (Score:5, Insightful)

        by MORB ( 793798 ) on Tuesday January 03, 2006 @09:36AM (#14384125)
        "And the guys who write those apps are the very ones who hate C++."

        Not all of them. I've worked for 6 years as a game developer, and I've seen (and written myself) some pretty horrible stuff.
        Yet I actually love C++ now, even though I hated it at first.

        What I hate are people not thinking thing through before they code and hence writing monstruous code.
        And most of these monstruosities are not C++ specific. A programmer who is not able to figure out what to put in a separate function or how to make a proper class hierarchy won't magically do better in Java, C#, Python or whatever else.
      • You have to use C++ for a couple of years to truly, honestly hate the language.

        Whereas Perl only takes a few minutes. Such efficiency!

  • Lots of detractors here (Score:4, Interesting)

    by Dante Shamest ( 813622 ) on Tuesday January 03, 2006 @08:05AM (#14383717)
    But considering that lots of OSS projects like Firefox and KDE still use C++, not to mention commercial games like World of Warcraft, C++ probably does have some saving merits.

  • My wish-list for c++ (Score:4, Insightful)

    by Eternal Annoyance ( 815010 ) on Tuesday January 03, 2006 @08:05AM (#14383718)
    property keyword: Used that in object-pascal (the language sucks otherwise). Just define a read and write function, make a property which calls those functions and you can go ahead. Very simple in use (less bug prone), fast to implement and nice on the compiler. While you can achieve the same in c++ it's not as clean and friendly on the compiler.

    interface and implementation (both are keywords, comes from pascal) section: lets get rid of seperate header and code files. The idea is aged, inefficient and doesn't help clarity nor ease of coding.

    Bit-arrays: yesyes, I know. Boost contains a class which does that. But I think it would be so much nicer if the language had that feature.

    • Properties are worthless and good at hiding side effects.

      Interface/Implementation split is good- Objective-C does that. Maybe you should consider that.

      Bit arrays are dead simple in C, and boost::'s version is complicated as hell. What exactly did you have in mind?
  • In my opinion, many people are trying too hard to be clever and advanced.

    I was advanced once, but unfortunately it just left me waiting for everyone else to catch up.
  • What I'd really like is a fully vertical programming environment that's more humane, lets me get to the bare metal if I want to, or be very lazy and high level, if I want to, it would do assembler, C, C++, and higher than C++ level, a set of languages where I know what each statement expands to in the lower level, where the compiler sort of holds my hand, and shows me what's going on, and I'd rather have a more plain english compiler output even if it's not optimized, or if it's optimized and difficult to f

  • The GUI. (Score:3, Insightful)

    by nighty5 ( 615965 ) on Tuesday January 03, 2006 @08:29AM (#14383798)
    I was pleased to notice that Bjarne Stroustrup has acknowledged that they won't be pursuing to include a GUI framework into the new C++ standard.

    Although this might be considered a disappointment, his citing the fact of low resources, time and money are best spent in other areas. Lets get something out the door that we can use now instead of waiting for the GUI. I'm no C++ expert, as a matter of fact I'm only into about 400 pages of my first teaching book ;)

    Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed. Its probably good to have commerical interest in the GUI space, since the desktop is forever evolving faster than a C++ committee could handle.

    • Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed.

      Using a procedural, compiled programming languague for GUI's is a fundamentally flawed concept to begin with. If you want to create a user interface, just use HTML, XUL, XAML whatever. 300+ lines of Visual C++ code just to display hello world is indicative of an underlying problem.

      • Re:The GUI. (Score:4, Insightful)

        by trollable ( 928694 ) on Tuesday January 03, 2006 @09:00AM (#14383933) Homepage
        300+ lines of Visual C++

        If you're right, WTF would you want to use a MS product? You can do a hello world in C++ with just 3 lines (TUI) or 12 (GUI with QT).

        Concerning XML-based GUI descriptors, it is in general not smaller. It is smaller to define and place the components but things goes wrong when you have to manage events. In fact, from my experience, a GUI in HTML+JS, C++/QT and Java/Swing has more or less the same number of SLOC.

    • Re:The GUI. (Score:3, Insightful)

      by ivec ( 61549 )
      There are many C++ GUI libraries, but I'm afraid that they all share a common weakness: the lack of reliance on the standard C++ library. Except maybe gtkmm, but how well is this library supported?

      All the frameworks I know tend to use their own string class, their own containers, etc -- and obviously as well their own threading library.

  • Threads Cannot be Implemented as a Library (Score:4, Interesting)

    by putko ( 753330 ) on Tuesday January 03, 2006 @08:33AM (#14383813) Homepage Journal
    It is good for a language to have threads "built in". As mentioned in this paper, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-20 9.pdf [hp.com]

    if you do threads in a library, you run into problems with semantics or performance. Semantic problems == compiler breaks your multithreaded program. Performance problmes == compiler does naive translation of program, terrible performance.

  • what's in a name (Score:3, Funny)

    by Claire-plus-plus ( 786407 ) on Tuesday January 03, 2006 @08:41AM (#14383836) Journal
    they should call it ++C, so then the "shouldn't you iterate the language BEFORE you use it" jokes can go away.

  • C++x0r (Score:3, Funny)

    by CharAznable ( 702598 ) on Tuesday January 03, 2006 @09:13AM (#14384000)
    I think he means to call it C++x0r. Cause the type safety makes you ub4r.

  • what is he taking OUT? (Score:3, Interesting)

    by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Tuesday January 03, 2006 @09:16AM (#14384013) Homepage
    It's much more interesting to me to hear about what Barne will be taking OUT of C++. Adding features is the easy, wimpy part of the job. Removing them is the part that takes cohones.
    -russ

  • Is the C++ standards committee serious? (Score:5, Insightful)

    by master_p ( 608214 ) on Tuesday January 03, 2006 @09:28AM (#14384078)

    Why do they want so many years to decide on so simple things that are other languages take for granted for more than 15 years now? Let's see what they have in store:

    1. the using declaration for making type aliases. First of all, template typedefs are there for the exact same reason. Secondly, C++ lacks the ability of making strong types out of other ones, templates or not; a feature present in Ada 83, for example. We programmers need the ability to define strong types out of anything, primitive, template or not.
    2. sequence constructors; what an utterly hopeless idea! it will introduce more problems than anyone ever thought. The correct thing would be to make the expression {2.3, 1.2, 6.7, 4.5}, and any expression contained in curly brackets, a composite literal! Just like an integer can be written as {0, 1, 0, 1 ... 1, 0, 0, 0, 1}, i.e. a sequence of bits, so should any other data structure. Array syntax would be more than enough for accessing the individual elements of a composite literal. For example: auto x = {1, 2, 3}; auto sum = x[0] + x[1] + x[2];
    3. template concepts; correct solution, but why they say it is difficult to implement? The problem with templates was that the type system was applied after template substitution. In fact, templates were little more than C macros. Languages that implement generics correctly (Haskell, Ml, Erlang, Ada, etc) have sold these problems many moons ago. Applying a type in compile time is nothing more than executing the program at compile time. Currently C++ templates are turing complete, so I just do not see 'big problems' with concepts.
    4. type deduction using the auto keyword. C++ already does type deduction, so where is the problem? And why should we wait 4 years for compilers to adopt those things?
    5. .

    But what makes the most negative impression is the willingness to recognize that the programming language world has made huge steps in the last few years, and C++ is light years behind. Here are some of the negative points, in random order:

    • No garbage collection. Come on C++ guys! how many times have we got to beg for C++ having garbage collection? it's the easiest thing to do, and you can put it there as an option! no, the Boehm gc does not cut it, because it does not take advantage of type information, so it is much slower and much more complicated than what it needs to be. C++ designers, please stop telling us how garbage collection will mess up C++, because it will not! Microsoft already has managed C++, and then there is the programming language D which offers garbage collection! Of course gc goes hand-in-hand with strong and weak pointers.
    • the bias towards systems programming . Come on guys! in the world that Java is used for handheld devices, no one really cares about C++ being used in a few embedded controllers anyway. No one has used C++ for any major operating system, and no one has used C++ for any hardcore military project. Where is C++ used as for system programming? nowhere. C++ is mainly used in application programming, because of compatibility with C without an FFI.
    • the lack of import declarations. In the year 2006, we still have to duplicate code between header and source files, we still have to take care of includes, we still have to make decisions if we should place code in header files or in implementation files in order to make code inlined or not.
    • no static virtual methods. It is dead easy to do, and sometimes it is badly needed. For example, the pattern factory heavily depends on it.
    • no properties. For example, GUI libraries have 100s of widgets, yet we still have to write getFoo(), setFoo(), isFoo() etc. By using properties, code would be greatly simplified, and there would be no run-time overhead since properties is about syntactic sugar.
    • no variable argument li

    • Re:Is the C++ standards committee serious? (Score:5, Informative)

      by DoofusOfDeath ( 636671 ) on Tuesday January 03, 2006 @10:30AM (#14384464)
      ... and no one has used C++ for any hardcore military project.

      I'm surprised that you feel qualified to make this statement, since it would require you to have the rare combination of having top secret clearange (in order to know about all military projects) and have a "need to know" about each one of them and be in the habit of posting what you know to Slashdot.

      But you're simply incorrect in your statement.

      • I'm surprised that you feel qualified to make this statement, since it would require you to have the rare combination of having top secret clearange (in order to know about all military projects) and have a "need to know" about each one of them and be in the habit of posting what you know to Slashdot.

        I disagree since if you knew of a reasonable sample of declassified or public military projects and none of them used language X, there's no reason to assume that secret or top secret projects are going to be m

    • Re:Is the C++ standards committee serious? (Score:5, Insightful)

      by tchernobog ( 752560 ) on Tuesday January 03, 2006 @10:33AM (#14384487)

      If these are your points, then use another language, like Java.
      I don't want C++ to look like Java.
      I want C++ to solve a different kind of problems in an easy way.

      Frankly _none_ of your points would be something that I'd like to see added to the language; it would be likely to introduce complexity and confuse users even more, instead of helping them; and maybe it would also break compatibility with old C++ programs. It seems that the ISO committee agrees with this idea.

      Some of your points debated:

      • Garbage collection: making this the default would be utterly insane. GC has to run on another thread, thus making a program unpredictable.
      • the lack of import declarations: thanks God we don't have them! Keeping headers and implementation in two different files is a wonderful idea; and I can ship to the user directly my clean and documented header files. No Java-style cluttered and bloated source files. Btw, Java is different because it's compiled in bytecode. C++ isn't, so implementing an import semantic would break C++ ABI (yet) another time.
      • no standard GUI library: different systems get this done in different way. What would be the point of laying out a framework in the C++ standard when nobody would use this because they already do it their own way? We're talking about graphical toolkits with millions of users and bindings in a lot of different languages. Changing the way they do things without breaking binary compatibility for library users is just impossible.
      • No closures: I don't know if I understood your example correctly, but with Gtkmm + sigc++ I do what you said without particular problems.
      • No initialization of an object's fields at the point of their declaration: yes, this is left as a boulder for the programmer. No harm in that, you're just speaking about syntactic sugar.
      • properties: mark a member public if you want to spare some typing. Else use an IDE that generates accessors for you. All in all, it's just laziness...
      • No true message passing: use a library that provides them. As simple as that.

      So please: change programming language and don't complain non-sensically trying to look cool because you can speak a little jargon.

      • Re:Is the C++ standards committee serious? (Score:4, Informative)

        by master_p ( 608214 ) on Tuesday January 03, 2006 @12:25PM (#14385238)

        If these are your points, then use another language, like Java.

        But I never said that C++ should look like Java. All that I want can easily fit in the C++ style, and they can be optional.

        Garbage collection: making this the default would be utterly insane. GC has to run on another thread, thus making a program unpredictable

        Nope, not at all. First of all, GC does not need to run in a separate thread. I have programmed several GCs, some of them naive, some of them hardcore, and sent them to Stroustrup. None of them required a separate thread. Secondly, you shouldn't talk about predictability and C++ in the same sentence, since C/C++ pointers can easily make a program unpredictable. And if you want "predictability", as you mean it, then be aware that GC can be optional.

        the lack of import declarations: thanks God we don't have them! Keeping headers and implementation in two different files is a wonderful idea

        It makes code management difficult. I have to type the same things twice. I have to decide if a piece of code goes in the header or implementation file.

        I can ship to the user directly my clean and documented header files. No Java-style cluttered and bloated source files. Btw, Java is different because it's compiled in bytecode.

        First of all, you do not need to ship source files. Take a look at programming language D, in which the compiler produces symbol files to be directly imported to programs. Secondly, it is totally irrelevant that a language is in bytecode or not. There are bytecode compilers for C, for example.

        C++ isn't, so implementing an import semantic would break C++ ABI (yet) another time.

        Importing a file it is just another way of accessing declarations between programs. The difference is that imports are already pre-compiled in compiler format, and therefore faster to compile. As for compatibility between compilers, just define a standard (like D does).

        What would be the point of laying out a framework in the C++ standard when nobody would use this because they already do it their own way? We're talking about graphical toolkits with millions of users and bindings in a lot of different languages.

        But new projects will not use the existing graphical toolkits, but the standard one.

        Changing the way they do things without breaking binary compatibility for library users is just impossible.

        Nobody said "stop using the other libraries". But the other libraries are a pain in the a$$ to use. Qt requires MOC, GTK sucks, wxWidgets sucks more, Motif sucks even more. Swing is nice though.

        No closures: I don't know if I understood your example correctly, but with Gtkmm + sigc++ I do what you said without particular problems.

        Nope, you did not. What you are referring to is a callback framework. I am talking about closures. See Smalltalk's blocks, or lambda functions of Haskell/Perl for examples.

        No initialization of an object's fields at the point of their declaration: yes, this is left as a boulder for the programmer. No harm in that, you're just speaking about syntactic sugar

        properties: mark a member public if you want to spare some typing. Else use an IDE that generates accessors for you. All in all, it's just laziness...

        Yes, syntactic sugar, but a very important one: it will save much reduntant work.

        No true message passing: use a library that provides them. As simple as that.

        Obviously, you have no idea.

    • One of the main design goals of C++, from the very beginning, is that "you don't pay for what you don't use"--in other words, if you write a C++ program that doesn't use the language's OO or generic-programming features, it should be just as fast as the equivalent C program. I'm not sure how you could extend C++ to include all of your desired features (particularly GC) without throwing out that goal.

      (I think "you don't pay for what you don't use" is a fundamental design flaw of the language, but if you dis

    • Disagree (Score:5, Informative)

      by everphilski ( 877346 ) on Tuesday January 03, 2006 @11:22AM (#14384815) Journal
      No one has used C++ for any major operating system,

      Windows XP, NT, 9x. See: http://public.research.att.com/~bs/applications.ht ml [att.com]

      and no one has used C++ for any hardcore military project.

      I'd beg to differ.

      -everphilski-

      • Re:Disagree (Score:3, Informative)

        by diegocgteleline.es ( 653730 )
        Windows XP, NT, 9x

        Those kernels are mostly written in C. They allow you to use C++ for drivers but they even "discourage" it in the documentation. Userspace is another matter.

        As a linux kernel hacker said: "a language where '+' is allowed to do something that it's not really '+' is not a good choice for a kernel"

      • Re:Disagree (Score:3, Informative)

        by master_p ( 608214 )
        No, all the code in the kernel and major libraries is written in straight C. Microsoft uses the Visual Studio C++ product, but all the APIs are in C.

        As for military projects, I know since I work in that sector. Ada is the primary language in these 'hardcore' military projects.

  • How fascinating (Score:3, Insightful)

    by Weedlekin ( 836313 ) on Tuesday January 03, 2006 @09:37AM (#14384138)
    Bjarn says he wants to make C++ an even better systems programming language. The way to do this is apparently by adding features to a language already groaning under the last batch, far from all of which have been consistently implemented in all (or even a majority of) compilers. None of these features seem to address the fact that as a systems programming language, C++ has most of the same shortcomings as C, while adding a few of its own:

    1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.

    2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.

    3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).

    4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.

    It is thus not (as Bjarn claims) a "better C", at least in a systems programming context, because nearly everything it adds is largely superfluous to systems programmers, and comes at a cost that they are unwilling to pay. This is especially true in what is by far the largest segment of systems programming, i.e. embedded systems, many of which are programmed in _significantly simplified_ versions of C, not the goya-esque monster that is modern C++.

    NB: it is very difficult to design a single language that is equally useful for both high-level applications programming and low-level systems programming because they have fundamentally different requirements. Systems programmers require precise control of minutiae, whereas applications programmers want something that lets them churn build quality end-user systems with a minimum of pissing around. C++ falls between these two stools, adding nothing useful to C's systems programming capabilities, while being so concerned with nit-picking minutiae that writing high-level applications in it is like scrubbing a very big floor with a very small toothbrush. It is IMO well-suited to only one notable application domain: games development, which is unusual in requiring a mixture of both low and high level code.

  • I like some of the proposals for C++0x (Score:3, Interesting)

    by jonwil ( 467024 ) on Tuesday January 03, 2006 @09:45AM (#14384178)
    Here are some things I personally would like to see (some of which have been mentioned elsewhere as possible inclusions). Not all of them are 100% appropriate for something like C++ and the C++ standard library but all of them are things that seem (to me) to be usefull things to have as compiler and library provided functionality.

    language provided thread support. This would need to provide the following (at least):
    1.Proper thread safety at the language level (including mandates that the standard library is thread safe)
    2.Thread-local storage (i.e. a way to say "this variable is local to this thread")
    3.A way to say "this block of code should only be accessed by one thread at once" or "this variable should only be accessed by one thread at once" (something like a critical section on win32 I guess)
    Plus of course ways to create threads and such.

    Complete compatibility with C99 (i.e. any valid C99 program is also a valid C++0x program and will compile and run)

    something similar to (and compatible with) fstream/ifstream/ofstream except that it reads from a block of memory instead of a disk file

    A nice sane cross-platform way to detect memory leaks (i.e. the compiler implements the standards-specific memory leak detection in the implementation of new and delete and then the progammer would enable it e.g. with a new #paragma or something. (this goes with the garbage collector idea mentioned elsewhere)

    Complete unicode support throughout the C++ language and standard library (although I think this is already mostly there)

    New classes or functions (e.g. a new string class and new/improved collection classes) designed such that they help prevent or miinimize buffer overflows and memory corruption and the resulting effects (sort of like how compiler vendors like microsoft have started to add "safe" string functions only standardized)

    Standardized definitions for constants like pi (plus more math functions as standard)

    A standard library to do data compression and uncompression (perhaps an implementation of what is defined in RFC 1950, RFC 1951 and RFC 1952 i.e. the algorithim and format used in gzip, pkzip and zlib would be appropriate). Further to this, a new fstream/ifstream/ofstream derivitive that will compress data when writen out and uncompress it when read back in (without the programmer having to do anything).

    I like the idea for a standard library way to do directory and file manipulation and the idea for a standard sockets library although (like the compression idea I have above), I do wonder if they are really appropriate for C++ or if they are better provided by third party libraries.

  • From a former C++ fan (Score:5, Informative)

    by fionbio ( 799217 ) on Tuesday January 03, 2006 @10:44AM (#14384567)

    Sorry for rather long and muddled post, and also for my poor English... Also, if you have allergic reaction to Lisp advocacy, don't read any further.

    Some years ago when I had some spare time I was struggling a lot trying to make C++ a better language. I was trying to reinvent reflection, easy serialization, extend metaprogramming facilities and so on. My hopes were mostly in http://www.boost.org/ [http]">Boost C++ libraries.

    At some point I've decided to try to write some extended metaobject generator, like Qt's moc, but friendlier to "modern C++", using GCCXML [gccxml.org]. In addition to generating reflection info, I was thinking of generating proxy classes and other stuff like this.

    Among other things I've tried to do some of XML translation work using XSL (i.e. XML AST from GCCXML -> some more AST convenient XML representation -> (transformation) -> resulting metaobject AST. I've discovered some interesting things about XSL, e.g. that it's possible to "emulate" iteration (which is somewhat lacking in XSL) with recursion. Nevertheless after a few days of fighting with XSL I've decided to try some language which is more suited for processing various trees. Of course, when C++0x is ready, I thought, it will be the best language in all respects, including tree stuff, but as of now, STL+boost::lambda+whatever is still somewhat quirky (for instance, look at those 10 pages long error messages when you make a typo). So, although I was heavily influenced by standard myth-based mindset concerning Lisps (slow, interpreted, purely academic, "lost in a sea of parenthesis" and so on) I've decided to give Scheme a try, as I've heard that it can be used as a better XSL [okmij.org].

    After playing with Scheme for a while, I've found out (to my surprise) that the language can be used for many other purposes besides list (tree) processing and simple scripting (as in Gimp). As an example, there are wonderful things like Scsh [scsh.net]. It's possible to write Web applications, many Schemes can do OO. My deep respect to C++ (The Most Powerful Language Ever) began to fade, albeit slowly.

    So I've begun to try to do some real things in Scheme. Disillusionment has come rather quickly due to the fact that a lot of critical stuff in Scheme (e.g. OO and packages) is not standardized and thus is 100% non-portable between implementations. Moreover, every implementation has its bugs and limitations, and when you come to the point when you need to change your implementation you discover that most of your code needs to be rewritten from scratch.

    I was nearly ready to continue developing my "metaobject generator", pushing Scheme's role back to "better XSL". But something made me try Common Lisp before doing so.

    What quickly became apparent to me from my CL experience is that most of problems Boost guys are fighting against are just plain nonexistent for Lispers. Look at this, for example: variant.hpp [boost.org]. A good workaround for C++ typing model. What do we have in Common Lisp?

    (let ((x 5))
    ....
    (setf x "abc") ;; no problems with types!
    ....)

    (sorry for mangled indentation)

    Now look at this beauty: boost::lambda [boost.org]. Don't forget error messages it produces when you mistype something or stumble across a bug. CL example?

    (mapcar #'(lambda (x)
    ;; any code you want
    ...)
    my-list)

    Not to mention Lisp's GC versus boost::shared_ptr.

    OK, these are areas where dynamic languages like Perl, Python and Ruby, and even statically typed like C# or Java are catching up to some degree. Now let's look at some CL's more-or-less unique features.

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close