new standard

This is a discussion on new standard within the C++ Programming forums, part of the General Programming Boards category; Does anyone know how definitive the new C++ standard is? C++0x - Wikipedia, the free encyclopedia Is this what it ...

  1. #1
    Registered User
    Join Date
    Jan 2007
    Posts
    330

    new standard

    Does anyone know how definitive the new C++ standard is?

    C++0x - Wikipedia, the free encyclopedia

    Is this what it will be or is it still moving?

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    It's likely to not change much, but until it's been ratified (all parties have signed it), there's still a potential that something will change. The way standards works is that most of the changes to a standard happens early on. C++0x is supposed to be ratified this year [we hope, otherwise it will be 1x?], so the timeframe in which changes may be introduced is very small.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    Some features are already set in stone (or implementors wouldn't start implementing them).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    The first round of national body comments has passed. Now there is a round of fixing the problems pointed out. There won't be much more changes, unless serious problems are discovered.

    One rather big change that may yet get in is an example of this, a serious exception-safety problem caused by rvalue references.
    Rvalue References and Exception Safety
    So we may yet get the noexcept specifier.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    ok, so things like concepts, axioms and all that will be added. Its good knowing that, makes studying the feature much more useful
    I understand that small things might change but that doesnt matter, I just wanted to know if those features would be added

  6. #6
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    Quote Originally Posted by CornedBee View Post
    The first round of national body comments has passed. Now there is a round of fixing the problems pointed out. There won't be much more changes, unless serious problems are discovered.

    One rather big change that may yet get in is an example of this, a serious exception-safety problem caused by rvalue references.
    Rvalue References and Exception Safety
    So we may yet get the noexcept specifier.
    Thanks for that, it was a really good read!
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  7. #7
    Registered User
    Join Date
    Jun 2005
    Posts
    6,531
    Quote Originally Posted by CornedBee View Post
    One rather big change that may yet get in is an example of this, a serious exception-safety problem caused by rvalue references.
    Rvalue References and Exception Safety
    So we may yet get the noexcept specifier.
    Strikes me as overkill, I must admit. rvalue references were introduced as a means of providing an alternative to common abuses (eg using a cast to work around poor use of const specifiers in a set of functions). And then it is necessary to add other constraints to prevent other problems.....

    My personal prediction is that rvalue references will be actively avoided by a lot of serious programmers.

    With the noexcept specifier, I consider it would have been better to turn exception specifications into static compile-time checks, rather than run-time checks. Then a "throw ()" specification would become equivalent to the proposed noexcept specifier. Since there is talk of deprecating throw() specifications anyway, there would be little loss in reusing the syntax.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy in reply to you, it is likely you deserve it. Suck it up, sunshine, and read this, this, and this before posting again.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    My personal prediction is that rvalue references will be actively avoided by a lot of serious programmers.
    Perhaps in direct use of their own. Not their effect entirely, since that can't be avoided if you use the standard library.

    I don't think it will happen, though.

    Then a "throw ()" specification would become equivalent to the proposed noexcept specifier.
    I think the paper had a very good rationale for not doing that.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    Registered User
    Join Date
    Jun 2005
    Posts
    6,531
    Quote Originally Posted by CornedBee View Post
    I think the paper had a very good rationale for not doing that.
    The paper listed the arguments for deprecation of exception specifications (and the underlying concern is that they are not checked statically). However, the focus of the paper was actually on fixing concerns associated with move constructors - essentially by specifying they will not throw - not on fixing wider concerns with exceptions.

    The paper also noted that variants of throw specification are an alternative. On one hand, throw specifications are already discouraged and relatively rarely used (that's the core of the argument for their deprecation). Given that, the argument of "having too many syntactic similarities confuses the semantics of the two features in a way that is likely to cause problems for programmers" is a rather weak argument against overhaul of the semantics of exception specifications. Particularly when the "two features" are both related to exception handling.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy in reply to you, it is likely you deserve it. Suck it up, sunshine, and read this, this, and this before posting again.

  10. #10
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Their going to add garbage collection and weak typing.

  11. #11
    Registered User
    Join Date
    Jun 2005
    Posts
    6,531
    Quote Originally Posted by Perspective View Post
    Their going to add garbage collection and weak typing.
    Not my understanding.

    As I understand it, features are proposed that will make garbage collection easier to implement, but there is no proposal to actually support it. That strikes me as consistent with the philosophy of C++ as a "general purpose multi-paradigm" language - garbage collection is suitable for some purposes/paradigms, but not others.

    I don't recall any serious consideration of weak typing. Which is hardly surprising: one of the cornerstones of the C++ type system has always been strong typing.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy in reply to you, it is likely you deserve it. Suck it up, sunshine, and read this, this, and this before posting again.

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Garbage collection was planned (as optional, of course), but got thrown out due to time constraints. As a compromise the notion of "safely derived" pointers was introduced, which defines the restrictions on a program that wants to work with a library-based garbage collector without having the GC collect live objects.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #13
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    Quote Originally Posted by grumpy View Post
    The paper listed the arguments for deprecation of exception specifications (and the underlying concern is that they are not checked statically). However, the focus of the paper was actually on fixing concerns associated with move constructors - essentially by specifying they will not throw - not on fixing wider concerns with exceptions.

    The paper also noted that variants of throw specification are an alternative. On one hand, throw specifications are already discouraged and relatively rarely used (that's the core of the argument for their deprecation). Given that, the argument of "having too many syntactic similarities confuses the semantics of the two features in a way that is likely to cause problems for programmers" is a rather weak argument against overhaul of the semantics of exception specifications. Particularly when the "two features" are both related to exception handling.
    It is one thing to discourage people from using throw declarations, it is another to replace it with something else. The latter will break some existing code; the former will not.

    Perhaps, if they depreciate throw declarations now, then ten years time it will make sense to replace it with something else, but no sooner.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  14. #14
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,370
    My personal prediction is that rvalue references will be actively avoided by a lot of serious programmers.
    Define "serious programmers" as you've intended it?! O_o

    I mean, a lot of "serious programmers" still avoid C++. (Or at least they seem to think that they are "serious programmers"... I have other opinions.)

    My prediction is that programmers who understand the intent and capabilities of "rvalue references" will always use them. (Providing at least move assignment and move construction operators for anything not trivially copied.)

    I don't think it will happen, though.
    Can you elaborate... or clarify? No matter how I try to read that I can't figure out what you're saying you think will not happen.

    Soma

  15. #15
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Quote Originally Posted by CornedBee View Post
    Garbage collection was planned (as optional, of course), but got thrown out due to time constraints. As a compromise the notion of "safely derived" pointers was introduced, which defines the restrictions on a program that wants to work with a library-based garbage collector without having the GC collect live objects.

    wow, I'm surprised, my last comment was just a joke.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Standard efficiency
    By Jorl17 in forum C Programming
    Replies: 3
    Last Post: 06-18-2009, 12:48 PM
  2. Bug in iterator comparison in C++ standard?
    By steev in forum C++ Programming
    Replies: 14
    Last Post: 07-12-2008, 01:02 AM
  3. Abstract Base Class and References
    By Thantos in forum C++ Programming
    Replies: 9
    Last Post: 10-13-2004, 02:35 PM
  4. im extreamly new help
    By rigo305 in forum C++ Programming
    Replies: 27
    Last Post: 04-24-2004, 12:22 AM
  5. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 04:49 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21