C / C++ / MFC

led mike4-Oct-07 9:43

led mike

4-Oct-07 9:43

I agree. Now please give me a link to your solution that is superior so I can start using it.

Maximilien4-Oct-07 9:55

Maximilien

4-Oct-07 9:55

why ?

Maximilien Lincourt
Your Head A Splode - Strong Bad

marc.bellario4-Oct-07 10:32

marc.bellario

4-Oct-07 10:32

essentially, in the early 90's C++ was standardized
over most platforms - closely enough that going
from one compiler to the next was a reasonable
option and C++ resources worked fairly uniformly -

There is so much unique to .net now ( and I'm
still not really sure what that it )

and so much unique to the environment that
it's hard to know - what is right and
wrong - as far as approaches to problem
solving ------

It's more of a personal thing I think sort of
a nostalgia mostly -

I mean in the 90's there were still people
around who thought that C++ was a mistake -
and that C was really the best way to go ....

But - it's about writting code - that can
hang in there ....

I mean - there's also the group that says -
heh ------- we don't need no stinking C++
because Java is okay for everthing -

It's really mostly nostalgia .....

Hamid_RT4-Oct-07 10:09

Hamid_RT

4-Oct-07 10:09

And your question?

ThatsAlok4-Oct-07 19:21

ThatsAlok

4-Oct-07 19:21

Hamid. wrote:
And your question?

is still a question?

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture

cheers,
Alok Gupta
VC Forum Q&A :- I/IV
Support CRY- Child Relief and You

marc.bellario5-Oct-07 4:52

marc.bellario

5-Oct-07 4:52

You know, I didn't realize that the nature of
this board was mainly questions and answers -

So I guess I made an inappropriate entry -

My last word is this however -

I think that what VC++ today is really
a dialect of C++ ( i believe )....

And I think that's an important point of view -
since there is such a huge amount of C++
floating around ....

And I guess from my point of view it's kind of
sad that the language has become this fragmented.

Sorry ...........

Just a matter of style.. [modified]

ThatsAlok4-Oct-07 19:21

ThatsAlok

4-Oct-07 19:21

marc.bellario wrote:
there was some intergalactic force

hope they arrive soon.. i am fed up of process!

cheers,
Alok Gupta
VC Forum Q&A :- I/IV
Support CRY- Child Relief and You

bigdenny2004-Oct-07 8:36

4-Oct-07 8:36

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

Maximilien4-Oct-07 8:54

Maximilien

4-Oct-07 8:54

more efficient ? probably not; it's basically the same code, keep in mind that in the debug version, the first version will do additional comparisons, but we really don't care about efficiency in debug version.

more readable ? who can say ? is it tomato or tomato ?

Maximilien Lincourt
Your Head A Splode - Strong Bad

bigdenny2004-Oct-07 9:09

4-Oct-07 9:09

which one do you like more ?
Smile | :)

just asking..

Mark Salsbery4-Oct-07 9:17

4-Oct-07 9:17

I bet most will like the first better.

One exit point.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

bigdenny2004-Oct-07 9:32

4-Oct-07 9:32

Hi Mark,

Mark Salsbery wrote:
One exit point.

Can you give an explanation why is that good?

thanks

David Crow4-Oct-07 10:21

David Crow

4-Oct-07 10:21

When debugging, you only have to set one breakpoint. Otherwise, you have to set one on each return statement.

With older compilers, if you returned from a function that was in the middle of a for/while loop, the stack was not properly cleaned up. That's not the case anymore.

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

bigdenny2004-Oct-07 10:38

4-Oct-07 10:38

>> "When debugging, you only have to set one breakpoint. Otherwise, you have to set one on each return statement."

That's valid. But in this case, ASSERT's help.

led mike4-Oct-07 9:42

led mike

4-Oct-07 9:42

bigdenny200 wrote:
Can you give an explanation why is that good?

Don't tell him unless he knows the secret handshake

Mark Salsbery4-Oct-07 9:47

4-Oct-07 9:47

Hehe just in time....I was just about to reply! Smile | :)

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

bigdenny2004-Oct-07 10:11

4-Oct-07 10:11

So where is the reply Big Grin | :-D

Mark Salsbery4-Oct-07 10:22

Re: Just a matter of style.. [modified]

4-Oct-07 10:22

Heh. Where's the secret handshake.

This came up recently in a discussion here.

I actually argued that if I can see all the exit points in a function
easily then I don't mind. That doesn't mean it's good practice on my part.

Most (if not all) others that commented stated they prefer a single exit
point.

(The discussion was about nested "if"s versus multiple exit points.)

A problem occurs in changes later - any cleanup of new objects may
need to be done at every exit point. What if you miss one?

I looked at my code and found many places I used multiple returns
in a function. Mostly wordy initialization stuff like DirectX. Nested ifs
get too deep for my liking. I guess a goto to a common exit point
works, but who likes gotos? What's the alternative, a try block
using an exception handler as the common exit point? I dunno...
that's a glorified goto Smile | :)

Personally, in your posted code example, I thought the first one just looked
better and was easier to read. I have no need to save whitespace or to
minimize line count. I have plenty of harddisk space.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

bigdenny2004-Oct-07 10:39

4-Oct-07 10:39

"..was easier to read. "

I agree with that. Smile | :)

.
// Not anymore Smile | :)

) After I looked at it once again

Just, for me the second looks more compact.

-- modified at 17:31 Thursday 4th October, 2007

El Corazon4-Oct-07 10:51

El Corazon

4-Oct-07 10:51

Mark Salsbery wrote:
A problem occurs in changes later - any cleanup of new objects may
need to be done at every exit point. What if you miss one?

I have no manditory rules on this, though I do try to have a single exit point for just those cleanup reasons, I do have multiple exit points for culling determination. For instance checking a sensor for operations:

sensor()
{
if outside range return;
if outside azimuth field of view return;
if outside elevation field of view return;
allocate variables;
process;
cleanup;
return;
}

in this case there are multipe exit points, but the idea is to reduce the processed data before the allocation of process overhead. Therefore the resources are reduced by the previous exit points, and only one exit point has to worry about cleanup. I consider that a single exit point. It could be rewritten as a single exit point:

sensor()
{
if (inside range && inside azimuth && inside elevation)
{
allocate variables;
process;
cleanup;
}
return;
}

but when the list of checks grows significantly inside the if statement it still becomes difficult to read. In the case of the sensor comparisons, there are more checks going on there I can't show, and the list did get too lengthy, so I used the culling paradigm instead. Even in debugging it is easier to follow than a single long if.

_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

Mark Salsbery4-Oct-07 11:00