As far as I understand it, Microsoft creates their own standards if there''s any standards (regarding C# or Java ). And definitely doesn''t care for existing standards (But any compiler needs time to evolve ). In special I mean using the scope operator in a C++ class declaration which isn''t in any C++ specification

To CodyVa:

You cant''t compare a variable to a value if it is not declared and as menationed earlier you can''t access a variable outside you''re scope but the global scope.

Your code:

if (x != null) { ++x;} //if x is declared increment
else {int x = 0;} //if not declare it


For the compiler, this is like: compare the global variable x to zero and increment its value if it is so.
else declare a new variable x. Because the new variable is declared in a block, it is only valid and accesible in the block itself.

I think you can make it with a static variable, but then you should be aware to decrement the variable again when returning from the function. Because you never would be able to call the function again.

Another approach would be to use a function like this:

void func (int maxiterations)
{
if ( maxiterations > 0 )
if (somethinggoeswrong)
func(maxiterations-1);
}


Hope this helps

Personally, I love exceptions, but you''ve really got to use them properly. First lesson is that they are NOT meant for flow-control, they''re meant for exceptional situations (thus the name). There''s a cost associated with entering a try block and percolating an exception up the stack is not as fast as normal code (which isn''t a big deal if they only happen ocasionally). Second lesson is that exception specifications are of questionable merit. The "why" is a tad involved but I would reccommend checking item 14 of Scott Meyers'' "More Effective C++": "Use exception specifications judiciously." Basically, they''re more trouble than they''re worth. Finally, never throw an exception out of a destructor. Bad Things (tm) happen (like your program crashing).

Why are exceptions so great? Instead of filling your code with error recovery routines you can centralize them. Also, rather than checking the return value of every function call, you can assume that it was successful if an exception was not thrown. This doesn''t work for every situation, but it''s nice not have to put every function call in a "if" block. Another handy way to manage things (either as an alternative to exceptions or in addition to them) is to put some error checking and recovery code in an inline function. It''s much safer than macros but expands to effectively the same thing. Something like the following:

inline void Try( int retval ) {
if( retval ) {
// something went wrong
}
}

Try( MyFunc( param1, param2 ) );

A pretty handy way to code error stuff once but use it all over. I do this in situations where I don''t want to throw exceptions or at times when I need to examine a retval a bit more closely before determining whether to throw or not (like network code where some error values actually represent a success condition).