Value initialization using an empty pair of parentheses

This is a discussion on Value initialization using an empty pair of parentheses within the C++ Programming forums, part of the General Programming Boards category; Yup. And you just made it non-standard....

  1. #31
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Yup. And you just made it non-standard.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #32
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Oh - so the standard mandates that operator 'new' has an exception specification? Ok, well I'll just undo that then.

    EDIT:

    I see, post #22.
    Last edited by Sebastiani; 09-06-2009 at 05:13 PM.

  3. #33
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Hmm, come to think of it, I guess I need to implement a nothrow version as well, right?

  4. #34
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Yup. And don't forget that exception specifications are part of the function interface. So, removing them actually doesn't redefine the standard global functions. It creates a new unrelated function.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #35
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Ok, thanks. And what about delete? Do you know if it requires an exception specification?

    EDIT: Ah, found it. Yes, it does.
    Last edited by Sebastiani; 09-06-2009 at 05:32 PM.

  6. #36
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Ok, so I've reverted back to using exception specifications, and also added the nothrow variants. Hopefully, everything is kosher now.

  7. #37
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Mario F. View Post
    I also yet to see a convincing argument for the removal of exception specifications. Other than the usual because it's evil. Riight.
    Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
    Unfortunately the web version of the book seems to be down, so I don't have a link.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  8. #38
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by cpjust View Post
    Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
    Unfortunately the web version of the book seems to be down, so I don't have a link.
    Sounds interesting. Is that a pretty good read, besides what you mentioned?

  9. #39
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Quote Originally Posted by cpjust View Post
    Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
    Unfortunately the web version of the book seems to be down, so I don't have a link.
    I'm aware of those issue. I linked to this before. Check some posts back. But I need to ask...

    Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?

    Sounds interesting. Is that a pretty good read, besides what you mentioned?
    One of the most important books in best code practices, Sebastiani. It's a must-have in my opinion.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #40
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Mario F. View Post
    Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?
    No, not with VC++ at least:
    Quote Originally Posted by MSDN
    The C++ Standard requires that unexpected is called when a function throws an exception that is not on its throw list. The current implementation does not support this.
    set_unexpected (<exception>)
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  11. #41
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Mario F. View Post
    I'm aware of those issue. I linked to this before. Check some posts back. But I need to ask...

    Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?
    I think that in a mission critical application, exception specifications lead to undesired coupling between code units. A unit of code must be aware of all possible contexts in which it could be called and guarantee that no exception would be thrown that could propagate through a function with an exception specification that bars that exception. To me this seems to defeat the purpose of code modularity while providing no real design benefit.

    The purpose of the exception specification, ostensibly, is to prevent propagation of exceptions that can't be correctly handled. But what actually occurs when this happens is a program abort -- so no problem has actually been solved.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  12. #42
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Quote Originally Posted by brewbuck View Post
    The purpose of the exception specification, ostensibly, is to prevent propagation of exceptions that can't be correctly handled. But what actually occurs when this happens is a program abort -- so no problem has actually been solved.
    Should probably had had an addendum to my post. To better clarify the question.

    It's perfectly plausible to want a program abort in some mission critical scenarios where an unhandled exception is met. One example that occurs to me is that of PTA databases. I'd be hard pressed to believe that it isn't acceptable to design a system that, having designed its own exception hierarchy, doesn't want to take advantage of exception specifications to immediately abort execution on unhandled exceptions in certain scenarios. A condition that may guarantee the safety or consistency of data in real-time. Or simply to use exception specifications to expose exception or error handling rules in some middle-tier library.

    An unhandled exception is by definition a problem that usually can't be solved. The standard makes this definition evident by calling std::unexpected() which by default calls std::terminate(). This is a language feature. And one that I can find useful on certain scenarios. More importantly because it didn't forget to give me the means to alter this behavior.

    ...

    The alternative is not to use it. And we are given that option too. So, where exactly is the need to remove it from the standard? (note I refuse to use the obvious argument of backwards compatibility. We can ignore that for the sake of argumentation. I'm hoping for a more involving discussion).

    This is what a exception specification does:

    Code:
    //for something like void func() throw (X, Y);
    
    void func() {
    
        try {
            //something
        }
        catch (X) { throw; }
        catch (Y) { throw; }
        catch (...)  { std::unexpected(); }
    }
    There's an advantage in having moved to the function interface information that may be relevant to its user, instead of having it hidden away in the function definition. The disadvantages on the other hand are well known and documented (and on this thread too). So to deny there is never going to exist a scenario where exception specifications may be a useful and elegant solution is pretty much the C++ Never Argument, that we know very well is only true in one situation: Never say never.

    This is particularly important to me, because I've found useful scenarios for exception handling that go beyond the conventional and too often alluded approach. It's, for instance, quite acceptable to me to want to use the exception infrastruture and semantics for error handling, instead of (or in addition to) exception handling. As long as there's a clear separation between the too, as long as I'm aware of he implications, as long as any performance hits are well within acceptable ranges, and as well as I guarantee a clear interface, just why not? It's just another idiom. I don't expect to do it often, I don't even expect to do it at all. But the option is there and it is very visible. I'd be a fool not to take it if the opportunity arises, simply because I'm told I shouldn't do it.

    In contrast, by removing it from the implementation as VC++ has done (although I suspect I can recover it through the eh.h header), I'm removed of a language feature. For better and for worst. Doesn't strike me wise at all.

    EDIT: hmm, this probably should be split...
    Last edited by Mario F.; 09-07-2009 at 10:30 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #43
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Well what I actually meant was exception specifications should be removed from all standard functions, so that it's:
    Code:
    void* operator new( std::size_t _Count );
    instead of:
    Code:
    void* operator new( std::size_t _Count ) throw( bad_alloc );
    If people want to add them to their own code, they can go right ahead (although I still see no reason why they'd want to).

    If exception specifications worked like they do in Java, then they'd be worth using.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  14. #44
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Quote Originally Posted by cpjust View Post
    Well what I actually meant was exception specifications should be removed from all standard functions
    Possibly. Although this time is for me to wonder what you could possible want to throw other than bad_alloc in a function of this nature

    I's exactly one example where the usage of an exception specification carries with it 2 obvious advantages, and no disadvantage:

    - It exposes its exception handling semantics to the user.
    - It enforces those semantics.

    The alternative, no exception specification, can certainly be achieved without prejudice to the throw(std::bad_alloc). It's my guess you want to do that because you expect to throw something else other than bad_alloc. So, it's acceptable to conclude you want to do something else other than just allocate room. Probably some bookkeeping? Well, you have this mechanism at your disposal by encapsulating the allocator function in your own class.


    If exception specifications worked like they do in Java, then they'd be worth using.
    Hmm... I suppose you mean the static checking.
    This is what Sutter has to say, this time about Java exceptions:

    Quoting it here too:

    Essentially, exception specifications are a wonderful idea in basic principle, but no one really knows how to design them.
    There are two major approaches, and both have serious problems. Java chose static enforcement (at compile time, as suggested above), and C++ chose dynamic enforcement. Interestingly, I see Java people ask "why not enforce these dynamically?" about as often as I see C++ people ask "why not enforce these statically?"
    Briefly:
    When you go down the Java path, people love exception specifications until they find themselves all too often encouraged, or even forced, to add throws Exception, which immediately renders the exception specification entirely meaningless. (Example: Imagine writing a Java generic that manipulates an arbitrary type T…)
    When you go down the C++ path, people love exception specifications until they discover that violating one means invoking terminate, which is almost never what you want.
    Even more interesting is this article were checked and unchecked exceptions are discussed in great detail. Here too there's a clear case against static checking.

    EDIT: Quite curious. Because I copy-pasted a quote from Sutter's blog, a script on his page added this thread to his blog comments list, without my intention and without informing me.
    Last edited by Mario F.; 09-07-2009 at 01:34 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Regarding const array initialization
    By codegeru in forum C++ Programming
    Replies: 7
    Last Post: 07-19-2009, 11:55 AM
  2. Help with binary file c++
    By lucky_mutani in forum C++ Programming
    Replies: 4
    Last Post: 06-05-2009, 10:24 AM
  3. Polynomials and ADT's
    By Emeighty in forum C++ Programming
    Replies: 20
    Last Post: 08-19-2008, 09:32 AM
  4. Writing my own stl container
    By curos in forum C++ Programming
    Replies: 10
    Last Post: 12-18-2005, 04:33 AM
  5. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 07:39 AM

Tags for this Thread


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