I'm not arguing that. But if indeed gcc fails to support the syntax...
I'm not arguing that. But if indeed gcc fails to support the syntax...
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.
OK, well, I've attached a workaround that can be used with broken compilers in the meantime. Here's a sample test program:
EDIT: Had to add .txt extension to uploadCode:#include <iostream> #include <iterator> #include <algorithm> #include "broken_new_default_initialization_workaround" using namespace std; int main( void ) { size_t length = 32; double* data = new double[ length ]( ); copy( data, data + length, ostream_iterator< double >( cout, "\n" ) ); delete [ ] data; }
EDIT#2: Whoops, had set 'BROKEN_NEW_DEFAULT_INITIALIZATION_WORKAROUND_ALIG NMENT' to an arbitrary value for debugging purposes and forgot to reset to 0. Fixed.
EDIT#3: Fixed throw specification bug.
EDIT#4: Removed exception specification altogether.
EDIT#5: Reinstated exception specification, added nothrow variants.
Last edited by Sebastiani; 09-06-2009 at 04:46 PM.
Oops, slight brain fart there, but kudos as well. std::unexpected never seems to get any coverage, even if it is indirectly here. The last mention on these boards seems to have been 2007 so either exception specifications are less popular than Simon Cowell's Teletubby back catalogue or teaching material does an excellent job of explaining them.Code:void* allocate( size_t size ) throw( ) { ... if( data == 0 ) throw std::bad_alloc( );
Yeah. Should be a null pointer instead. Or the admission of bad_alloc in the exception specification. Both cases will be Standard-friendly.
But well done, Sebastiani.
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.
Why use exception specifications ever? They do nothing useful and spread like a virus in code that uses them.
"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
erm... because you can?
Originally Posted by ISO-IEC 14882-2003(E), 3.7.3-2, pag. 47I could ask what's so wrong about exception specifications anyway. But I'd rather not.Originally Posted by ISO-IEC 14882-2003(E), 18.4.1.2, pag. 345
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.
To my knowledge throw() behaves differently in VC++. It will not call std::unexpected(), but calls terminate(). throw(T) works just fine, although it does the same thing in case another exception is thrown.
In any case, following the standard, you can't avoid an exception specification for the redefinition of the alloc functions.
Meanwhile a debate on exception specifications can be found here: GotW #82: Debate #1 - Exception Safety and Specifications: Are They Worth It?, The point 4 is, to me , pretty obvious in it's usage of words like "generally" and "not always". You can't at least avoid exception specifications were they are required.
Last edited by Mario F.; 09-06-2009 at 01:30 PM.
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.
If they are required, then they are required, true, but for everywhere else, I'd avoid them like the plague, since that's what they are. Compile-time errors for throws might have been better.
Also, Visual C++ does ignore them (except throw()), as pointed out here.
Furthermore, according to MSDN, the compiler will generate code that ignores exceptions if you use throw(), which may lead to undefined behavior if exceptions are thrown (Source). It will not call std::unexpected or std::terminate. Or at least don't rely on it.
throw(T) is handled the same as throw(...), meaning it can throw anything.
The page is specified to VS2005, but I believe it will carry over to 2008, as well since not much changed between them.
"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
It seems that MS quite often interprets standards (including their own) as mere 'suggestions'. Try parsing a PE file correctly, for example - not only will you find undocumented layouts but ones that clearly *contradict* the specs.
MS: "Standards? We don't need no stinking standards!"
Weird. I didn't know about this either. Had to test just to be sure.
But I'm not so sure the loss of std::undefined() is a desirable thing. Definitely this affects portability and no matter what one may think or not of the feature, it is a non-standard implementation.
I also yet to see a convincing argument for the removal of exception specifications. Other than the usual because it's evil. Riight.
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.
Ok, well, considering what everyone has pointed out here, I've decided to remove the exception specifications from the implementation. Done.