Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Latest Proposals for C++0x 911

CodeDemon writes "It looks like the ISO/IEC JTC1/SC22/WG21 working group has made some headway in reviewing new proposals for the C++ language. The long anticipated upgrade for C++, C++0x, may be just around the corner. Head on over to check out the proposals yourself."
This discussion has been archived. No new comments can be posted.

Latest Proposals for C++0x

Comments Filter:
  • Re:Whatever. (Score:3, Informative)

    by addaon ( 41825 ) <(addaon+slashdot) (at) (gmail.com)> on Friday July 11, 2003 @01:12PM (#6416690)
    Um... C is C(\+)*.
  • by bluethundr ( 562578 ) * on Friday July 11, 2003 @01:13PM (#6416704) Homepage Journal
    And I thought the next version of C would be +++... and then ++++

    Well, since there was never a "C+" language, and you increment variables by one with "++" (hence the inherent joke in the name "c++"..."c incremented by one") a more logical construct would be (c++)++
  • by Joe Decker ( 3806 ) on Friday July 11, 2003 @01:13PM (#6416708) Homepage
    Language revs are often referred to by the year of the completion of their standardizatioin (e.g., C++98.) The next C++ would presumably be somewhere in this decade, e.g., C++05 or so, but of course nobody is sure what year the work would be completed in, ergo C++0x.
  • by the_2nd_coming ( 444906 ) on Friday July 11, 2003 @01:13PM (#6416709) Homepage
    ummm...no.

    C++98
    C++0x.....the x will be replaced by a numberal for the year that the standard will finaly be ratified.
  • Re:Great... (Score:2, Informative)

    by kannibal_klown ( 531544 ) on Friday July 11, 2003 @01:14PM (#6416716)
    Version 6 sucked A$$, but Vis c++ .Net is actually pretty good. And wtf are you talking about, I've used templates before with .Net (2002 and 2003) and had no problem.
  • Re:C++0x? (Score:3, Informative)

    by Randolpho ( 628485 ) on Friday July 11, 2003 @01:15PM (#6416740) Homepage Journal
    Already done!

    D Programming Language [digitalmars.com]
  • Vaporware? (Score:2, Informative)

    by cybermint ( 255744 ) * on Friday July 11, 2003 @01:20PM (#6416830)
    We got the first c++ compiler to handle the whole language just a little over a year ago. (article [slashdot.org]) I wonder how many decades it will be until we get a compliant compiler for c++r0x0rz.
  • Boost and STL (Score:2, Informative)

    by Homology ( 639438 ) on Friday July 11, 2003 @01:21PM (#6416844)
    Note that parts of Boost library is suggested as part of the new standard :

    N1450 03-0033 A Proposal to Add General Purpose Smart Pointers

    I've used parts Boost quite alot myself (www.boost.org), and found it very useful even when using Visual Studio.

  • Re:Great... (Score:2, Informative)

    by Homology ( 639438 ) on Friday July 11, 2003 @01:27PM (#6416921)
    The main difference is partial template specialization, apart from some speed optimizations.

    However, alot of code breaks when moving to VC .NET 2003 : for some reason they decided to remove classic headers, giving us _days_ of work. I've never had so much problems with a compiler as with VC .NET 2003 when trying to just build projects that have worked fine since VC 6.0.

  • by vidarh ( 309115 ) <vidar@hokstad.com> on Friday July 11, 2003 @01:27PM (#6416923) Homepage Journal
    Sigh... C descended from BCPL, hence the long standing joke from before C++ of whether the next language would be called D or P. However C++0x isn't a new language, it is the working name for the next version of the C++ standard, just as previous C standards are nicknamed C89 and C99 after the language and year they were completed, and the previous version of the C++ standard is often referred to as C++98. The "0x" is meant to reflex that the new version of the standard is likely to be done sometime this decade, without tieing anyone down to a specific year.

    So the "right around the corner" in the article is perhaps a little bit optimistic - they've just barely started working on the new version.

  • by td ( 46763 ) on Friday July 11, 2003 @01:30PM (#6416968) Homepage
    B didn't come from anything called A, but from a language called bon, named for Ken Thompson's wife Bonnie. (At least, that's what Ken says, but he's famous for pulling the legs of people who drool over stupid trivia from his past.) The inspiration for bon was Martin Richards' BCPL, a stripped version of Christopher Strachey's [et al] CPL (Combined Programming Language, I think; the B in BCPL is for Bootstrap or Basic, sources differ.) It doesn't stretch the truth too far to think of B as an even-more stripped down BCPL.
  • by WC as Kato ( 675505 ) on Friday July 11, 2003 @01:34PM (#6417021)
    How can SCO own the language? I can see them owning an implementation of the compliler and libraries but the actual language? Come on, that doesn't compute, especially since it has been ANSI standardized.
  • Re:why not... (Score:4, Informative)

    by Tony Hoyle ( 11698 ) <tmh@nodomain.org> on Friday July 11, 2003 @01:36PM (#6417051) Homepage
    B actually existed... it was the language that predated C.

    I've no idea if there was an A though.
  • by Tony Hoyle ( 11698 ) <tmh@nodomain.org> on Friday July 11, 2003 @01:46PM (#6417209) Homepage
    Smart pointers are relatively trivial to implement using templates, and don't slow things down much (small overhead as the pointer struct is 8 bytes + a trivial copy constructor every time you pass it). You only need a GC to cope with things like loops (a points to b which contains a pointer back to a, which means their reference counts will never be zero). If your careful you can get away without one at all.

    I don't think it impacts memory footprint much... if you remember to set pointers to null when you've finished with them they'll free at roughly the same places as if you did it manually... with the advantage they won't leak if you forget.
  • Re:Great... (Score:3, Informative)

    by be-fan ( 61476 ) on Friday July 11, 2003 @01:47PM (#6417222)
    2003 is a great deal better than 2002. The version number of VC++ was only bumped to 7.1 from 7.0, but it was more of a 7.0 to 8.0 increase in compatibility. 7.1 is now on a par with GCC in terms of compatibility.
  • Re:why not... (Score:4, Informative)

    by mattdm ( 1931 ) on Friday July 11, 2003 @01:51PM (#6417280) Homepage
    The B programming language stemmed from one called BCPL. Therefore, the logical successor is P, not D.
  • by be-fan ( 61476 ) on Friday July 11, 2003 @01:52PM (#6417283)
    Smart pointers are pretty fast and cheap, because they're reference counted. Basically, there are the following costs:

    1) Creating a smart pointer involves an extra heap allocation to allocate a counter. This is necessary because boost's smart pointers (which are the basis of the standard) are non-intrusive --- they don't require giving the target object a special counter. This overhead, can be eliminated by using intersive_ptr, which allows you to put the counter inside the object itself, and provide functions to increment/decrement it.
    2) Copying a smart pointer involves an atomic increment of a counter.
    3) Having a smart pointer go out of scope involves an atomic decrement of a counter.
    4) When the last smart pointer is destructed, an extra heap free is needed to free the counter.
  • by Anonymous Coward on Friday July 11, 2003 @01:58PM (#6417363)
    You should read Herb Sutter's article on Compilation Firewalls [www.gotw.ca] (aka the Pimpl Idiom). It basically solves exactly your problem.
  • Re:c += 2 (Score:3, Informative)

    by BlueWonder ( 130989 ) on Friday July 11, 2003 @02:02PM (#6417422)

    The expression ++c++ is equivalent to ++(c++). Since the postfix increment operator yields an rvalue (unlike the prefix increment operator, which yields an lvalue), ++c++ is not a valid expression in C++.

  • by be-fan ( 61476 ) on Friday July 11, 2003 @02:19PM (#6417601)
    You shouldn't set smart pointers to null. That could lead to a bug if you accidentally access it afterwords. Just let the destructor do the work, and make sure you don't create a smart pointer whose scope is much larger than it needs to be. Heck, that's good advice even for regular pointers.
  • by mstorer3772 ( 526790 ) on Friday July 11, 2003 @02:20PM (#6417612) Homepage
    Boost (www.boost.org) has crossplatform libraries for both sockets and threads.

    You're welcome. ;)
  • by Quietust ( 205670 ) on Friday July 11, 2003 @02:42PM (#6417823) Homepage
    If you're using a Microsoft compiler, you can already do that; don't know if any other compilers have implemented that extension, though...
  • Re:hehe.. sorta (Score:4, Informative)

    by IthnkImParanoid ( 410494 ) on Friday July 11, 2003 @02:44PM (#6417841)
    Why in the world would you want access to matrix3 from the plus operator???

    To fill the matrix (which we assume is large enough to make copying the values expensive) directly, instead of copying it into a temporary matrix with the overloaded '+' operator then copying it over with the overloaded '=' operator. You could do

    MatrixAdd(const matrix& m1, const matrix& m2, matrix& result);

    but then what's the point of overloaded operators?
  • Re:~bs (Score:3, Informative)

    by IWannaBeAnAC ( 653701 ) on Friday July 11, 2003 @02:50PM (#6417910)
    Porting a compiler to a given platform is not just a matter of re-targetting the assembly or object format. Usually there is a ABI, supplied by the vendor, which specifies such things as calling conventions, sizes of data types, and in the Windows case, it also specifies such things as layout of virtual tables (for COM compatability) and more.

    The hard part is not in taking a compiler and getting it to construct Windows executables. The hard part is getting it to cooperate with the existing ABI well enough that you can integrate with the other compilers for the platform. This is much harder to do for Windows than it is for, say, *nix.

    In other words, if Microsoft wanted to make it easy to make 3rd party compilers for the Windows platform, then they could have done so. I am claiming that they instead did the opposite, and made it difficult to construct and maintain a 3rd party compiler. I think even Borland would agree with me on this.

    Is it Sun's fault that MS doesn't have a VB compiler for Solaris?

    No, but in this hypothetical situation, if MS had investigated making a VB compiler for Solaris but gave up because of difficulties imposed by Sun, then some of the blame must go towards Sun.

  • by jdennett ( 157516 ) on Friday July 11, 2003 @02:54PM (#6417949)
    Yes, it's C++0x for 2000-and-something, because we hope to get the next major revision of the C++ Standard out before 2010. A minor revision is going through the process of being published around now, but that just fixes defects in C++98, as the original ANSI/ISO/IEC 14882:1998 standard is informally know.
  • by jdennett ( 157516 ) on Friday July 11, 2003 @03:00PM (#6418020)
    The original C++ is informally known as C++98, because it is defined by the International Standard ISO/IEC 14882:1998 (also adopted by ANSI).

    A minor update to that standard will be published very shortly, depending on how the ISO machine works. That won't be what we're calling C++0x, it'll just be fixes for errors in C++98.

    C++0x is the name given to the next major version of the C++ Standard, and it's some years away yet: expect 'x' to be large! Between now than and then there will be a "technical report", proposing extensions to the C++ library. It is likely to be widely supported, but a "technical report" (often abbreviated to TR) doesn't have the weight of a full ISO standard.

    I really ought to update the comp.std.c++ FAQ to cover this...
  • by mystran ( 545374 ) on Friday July 11, 2003 @03:14PM (#6418161)
    Uum... ElectricFence [perens.com] is a library that implements malloc, that check that you don't go over any bounds in dynamically allocated variables. Does a few other checks too (like double free). Link it with your project (or use LD_PRELOAD) and that's it.

    Works for C, but probably can be made to work with C++ too by writing an operator new that uses malloc() internally. Not sure if glibc actually does that.

  • by SamBeckett ( 96685 ) on Friday July 11, 2003 @03:26PM (#6418277)
    My C++ compiler (g++ 3.1 20020420 (prerelease)) allows this (it is called anonymous unions, structures), etc.

    Thus I can do this:

    class Foo {
    union {
    char bob;
    struct {
    unsigned frank : 4;
    unsigned jim : 4;
    }
    };
    Foo bar;
    and access bob, frank and jim via: bar.bob, bar.frank and bar.jim. :-)
  • Who cares? (Score:5, Informative)

    by KalvinB ( 205500 ) on Friday July 11, 2003 @03:26PM (#6418280) Homepage
    The extra bloat in Visual Basic is forced into my projects wether I use it or not.

    C++ on the other hand can have all the extra stuff it wants and it doesn't affect my project. If I don't wan to use templates or whatever, I don't have to. And the compiler won't force me to include anything.

    Whining about C++ having too many features is like bitching that Baskin Robbins has too many flavors. Nobody is forcing you to buy them.

    Ben
  • Re:More on D (Score:2, Informative)

    by fitten ( 521191 ) on Friday July 11, 2003 @03:29PM (#6418301)
    Yeah, we need a java-like syntax so you too can create lots of debug info in programs with 'if (global_debug==1) ' rather than the infinitely more efficient #ifdef DEBUG.

    Except that with the former, you can debug any time you need to, without using/loading a new (and different) executable. In addition, if you do it right, you can turn debugging on/off in a system without shutting it down (a feature that can be invaluable at times).

    Using #ifdef DEBUG, you, by definition, change the executable, which can change the properties of the execution of the code (things like timing). Ever had a program that worked in debug mode but not -O2 mode? Ever put a printf() into the code that caused it to work but not having it there caused the program to crash? (not talking about using variables before a value is assigned or stack corruption)

    Granted, #ifdef DEBUG can remove code that has cache destroying calls/code in it. However, just because #ifdef DEBUG can be more efficient does not mean that it is always the best approach to the problem.
  • by jdennett ( 157516 ) on Friday July 11, 2003 @03:31PM (#6418325)
    You'll be glad to know that the committee is aware of these issues and gives them more weight than you might believe. C++ doesn't evolve quickly; changes made in the last 6 years are nothing more than fixing defects, and the next standard is probably close to 6 years away.

    The committee is generally not interested in adding features for the sake of adding features. New proposals are expected to fix a documented problem, and to show that they are valuable enough to justify the lack of stability they cause.

    There is also clear recognition among the committee that C++98 was too inventive, and that anything significant that goes into C++0x should do so only after real-world experience with it has been obtained and reviewed. Hence the intention to publish a "technical report" on new library features -- it is likely that this TR will form the basis of much that will end up in C++0x, but its initial publication will not be in the form of an official standard.

  • Re:Cool (Score:2, Informative)

    by stonecypher ( 118140 ) <stonecypher@gm[ ].com ['ail' in gap]> on Friday July 11, 2003 @03:47PM (#6418455) Homepage Journal
    lambdas and metafunctions: boost [boost.org] and spirit [sf.net]. However, I agree with you that they should become core langauge fetaures. Notably, that's what Boost is - a group that's working on implementing, in a rigorous and standard-friendly fashion, potential extensions. it's droolworthy; I'd say even moreso than Loki [sourceforge.net], though visible policies make other people's code far less painful. (Yay, Phoenix!)

    As far as type inference, I disagree.

    cParentClass * foo = new cChildClass();

    what's the redundancy of cFoo = new Foo(); ? You specify the type of the thing and then identify the creator and pass it information. Because you always have matched types and creators simply says that your code doesn't require some of the more complex leveraging of the language.

    Auto seems convenient at first, but consider the potential for problems. And really, what does it gain you? Five or six keystrokes, in the greater scheme of things, really just isn't that important. Predictability and specificity are, in my opinion, far more important.

    If you're so hard up for horizontal space that you can't make a single definition, stop tabbing 8 spaces, put a using or two in place, or get a bigger monitor. Jeez.
  • Re:SCO (Score:2, Informative)

    by Q Who ( 588741 ) on Friday July 11, 2003 @05:01PM (#6419330)

    That's about Cfront, not ANSI C++ Standard. But I am sure you knew that, and are just karma-whoring.

  • Re:More on D (Score:3, Informative)

    by etymxris ( 121288 ) on Friday July 11, 2003 @05:32PM (#6419711)
    Well, there are people who don't like the preprocessor and have been coding for quite a while. I've been coding C++ for 7 years and as time goes on I like the preprocessor less and less. The main reason is that it is an obstacle to tools that help development. One common example is the debugger--not even Microsoft's Visual C++ could render macros transparent.

    Another problem is tools that do automatic code-folding have a much more difficult job with macros. I was using jGRASP because it does a great job of code-folding. The only problem is that it couldn't handle macros. So a macro that expands with a semi-colon to make a complete statement would be seen instead as the first token of the next statement. Now you may fault the programmer for not figuring out how to do code-folding with macros, but I believe the difficulty is inherent in the language itself. In order to handle macros properly, it would have to have a built-in preprocessor.

    The third problem is code I'm reading or writing. It is often infuriating to try to figure out syntax problems that involve macros. The macros are supposed to make things easier, but instead they just make them opaque. One of the worst offenders is MFC, with macros like IMPLEMENT_DYNAMIC and AFX_*.

    It seems problematic that to figure out the proper syntax of the language a preprocessor must be run first. The existence of the preprocessor has many advantages, but it has many detriments too. It invites API programmers to create macro-shortcuts that hide the syntax. These attempts at abstraction introduce all the problems of abstract languages (opaque-ness) while avoiding all the benefits of abstract syntax (safety, simplicity).
  • by Q Who ( 588741 ) on Friday July 11, 2003 @05:54PM (#6419933)

    Sounds like you guys need to look at ACE. Multiple platform and implements all sorts of design patterns!

    du -ks /usr/local/ACE_wrappers-5.2.4
    652640 /usr/local/ACE_wrappers-5.2.4

    Just to warn the innocent... (Yes, I know that one can selectively use features, but this gives a perspective, don't you think?)

  • Re:remove export (Score:3, Informative)

    by Ben Hutchings ( 4651 ) on Friday July 11, 2003 @06:55PM (#6420412) Homepage
    I think that by "EDG comments" you are referring to the paper "Why We Can't Afford Export". This was not actually written by EDG. There was a thread on comp.std.c++ [google.com] recently which discussed this. You'll need to look at the whole of the first article as it refers to export only in a footnote.

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Working...