Hi,Everyone When I read the source code of ACE. I can't understand why the define of ACE_NEW_RETURN use "while(0)"? just in line 157 of the OS_Memory.h
To ensure that we have proper version/platform/compiler information, please make sure you fill out the appropriate problem report form (PRF), which is in
in older versions of ACE+TAO. Make sure to include this information when asking any questions about ACE+TAO since otherwise we have to "guess" what version/platform/compiler/options you've using, which is error-prone and slows down our responsiveness.
I don't think there is a difference in this case - either the former or the latter code could be used just fine. If you'd like to enter a bugzilla entry about this we'll clean it up at some point.
thanks,
Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt Nashville, TN 37203 NET: d.schm...@vanderbilt.edu
> To ensure that we have proper version/platform/compiler information, > please make sure you fill out the appropriate problem report form > (PRF), which is in
> in older versions of ACE+TAO. Make sure to include this information > when asking any questions about ACE+TAO since otherwise we have to > "guess" what version/platform/compiler/options you've using, which is > error-prone and slows down our responsiveness.
>> I can't understand why the define of ACE_NEW_RETURN use "while(0)"? >> just in line 157 of the OS_Memory.h
> I don't think there is a difference in this case - either the former > or the latter code could be used just fine. If you'd like to enter a > bugzilla entry about this we'll clean it up at some point.
> thanks,
> Doug
Stefan -- ---------------------------------------------------------------------- Stefan Naewe ATLAS Elektronik GmbH Dept.: NUS T4 phone: +49-(0)421-457-1378 Sebaldsbruecker Heerstr. 235 fax: +49-(0)421-457-3913 28305 Bremen
> I don't think there is a difference in this case - either the former > or the latter code could be used just fine. If you'd like to enter a > bugzilla entry about this we'll clean it up at some point.
While in this particular case, the do-while(0) is unnecessary, it is the general idiom we use to ensure "function-like" macros expand to a single statement.
IMO, It seems more desirable for us to use the idiom consistantly, even in the cases where it's not strictly necessary, than it would be to "clean up" those that don't need it. Because if sometime down the road someone adds another statement to one of these cases and forgets to add the do-while(0) wrapper, it would be easy to introduce hard to find bugs in our users code.
But if someone decides that this is important, I'd claim that it should be done across the board instead of as each macro is encountered. That's a pretty big task, not one to be taken up lightly.
> > I don't think there is a difference in this case - either the former > > or the latter code could be used just fine. If you'd like to enter a > > bugzilla entry about this we'll clean it up at some point.
> While in this particular case, the do-while(0) is unnecessary, it is > the general idiom we use to ensure "function-like" macros expand to a > single statement.
BTW, I looked into this a bit more and we need the do/while(0) even for the try/catch case. Here's a small example that illustrates why:
----------------------------------------
int main () { if (10 > 20) try { } catch (...) { }; // Compile error if the ';' is here! else ; return 0;
}
----------------------------------------
Whereas this works fine:
----------------------------------------
int main () { if (10 > 20) do { try { } catch (...) { } } while (0); // It's fine to have the ';' here. else ; return 0;
}
----------------------------------------
> IMO, It seems more desirable for us to use the idiom consistantly, > even in the cases where it's not strictly necessary, than it would be > to "clean up" those that don't need it. Because if sometime down the > road someone adds another statement to one of these cases and forgets > to add the do-while(0) wrapper, it would be easy to introduce hard to > find bugs in our users code.
> But if someone decides that this is important, I'd claim that it > should be done across the board instead of as each macro is encountered. > That's a pretty big task, not one to be taken up lightly.