Just a matter of style.. [modified]
-
Thanks L. That's cool and I like it. What about something like this though....again I'll loosely use Direct(whatever) as an example... SetupDirect____() { create com object instance if (succeeded) create com object instance if (succeeded) create com object instance if (succeeded) ... } If any creates fail, then all the previously created objects need to be released. I always struggle on a good way to code this... Thoughts, examples, advice? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
Thoughts, examples, advice?
If each object is interdependant upon the creation of the later object then I have no other way of writing it. You are using the naturally stacked architecture of the compiler to build and release objects. Given I am self-taught, others may offer better solutons. Assuming no additional processing needs to be applied you simply write in the form of
setup()
{
create object1
if (success)
{
create object2
if (success)
{
.... (final statements evaluates total success)
}
cleanup object2
}
cleanup object1
return evaluaton of total success
}the clincher is when the algorithm requires post processing before cleanup. evaluatng if/else for every single object is bulky and time-consuming, and looks too busy to follow. But I have a few of those monsters I am not proud of. I will admit it. Others I have stopped and said, "can I define this differently? can I redefine it sideways/backwards or however?" redefining the problem sometimes helps. Sorry, I can't help you there.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Hey guys, I encountered this code at one great CP article.
BOOL CAESEncRegKey::SetKey(const BYTE *cbKey, UINT nLength)
{
BOOL bResult = FALSE;ASSERT( CryptoPP::AES::DEFAULT\_KEYLENGTH == nLength ); ASSERT( NULL != cbKey ); if( CryptoPP::AES::DEFAULT\_KEYLENGTH == nLength && NULL != cbKey ) { \_EncKey = cbKey; bResult = TRUE; } return bResult;}
I just wonder whether rewriting it in the following style, looks better ?
BOOL CAESEncRegKey::SetKey(const BYTE *cbKey, UINT nLength)
{
if( CryptoPP::AES::DEFAULT_KEYLENGTH != nLength || NULL == cbKey )
{
ASSERT(FALSE);
return false;
}\_EncKey = cbKey; return true;}
What do you think ? Any comments.. -- modified at 15:08 Thursday 4th October, 2007
I'm late getting in, but I just now read it. Two viewpoints: First: Scanning code, looking for a quick idea of what's happening. In this context, definitely the second format. Without spending 15 seconds to readjust my glasses, and beginning to mentally parse thru each symbol in the function, I couldn't make heads or tails of the first format. Second: When you KNOW this function has an issue, and you simply MUST trace thru it. Then perhaps the first format, although I didn't get that deep. I stopped after 15 seconds (since I'm not getting paid for looking thru that code). I TRY to write code knowing that non-programmers (but smart folk nonetheless) will be picking thru my code at some point in the future, and I try to write as literarily as possible. Non-literary symbols (the standard C++ operators like &, *, ::, etc.) can make the code difficult to read, even for me, and I do this stuff 8 hours/day! By the way; excellent discussion on exit points. Thanks to the contributors. David