CodeGuard best practice?

[Aris Mednis]

In the old days, life was simple. You pounded the keyboard creating your
C/C++ masterpiece, and after many hours of testing and debugging it
compiled and ran without any error reports. Then you ran Lint over the
source, and tidied up loose ends in the code. After these steps you had
a program that would run reliably for years...

Now we live in a much more complex programming world, and our tools have
grown in complexity and capability.

I spent many happy years with BCB4 and am a relative newcomer to
C++Builder 2007.

My question is aimed at the project creation and development phase in
the life of a project. Is it better or preferable to run CodeGuard
continuously from the start and correct as you go along, or leave it as
a one off exercise after completion?

I appreciate that there is an element of personal preference here, but
there may also be good technical reasons for one approach or the other.

Aris

[JohnC]

Personally, what I do is during the development stage, I leave Codeguard on
with all options selected.
Until ...
I start noticing prolonged delay in the running of the application as I add
features. Then I turn it off and just use it intermittently.
I will always use it prior to creating the final release. The final release
should be generated with codeguard off.
John

[Aris Mednis]

John,

Post by JohnC
Until ...
I start noticing prolonged delay in the running of the application as I add
features.

Good point, thanks. That's the kind of tip I was looking for.

Aris

[dhoke]

I would tend to agree with JohnC in principle, except, that with bds2006,
we've found CodeGuard pretty unreliable.

[slightly OT]
It has tended to cause us as many problems, well actually more, than its
found for us. To the point that we abandoned principle, and occasionally
try it just in case it may find something without causing us grief.

I tried the trial 2007 versions, and it was better, but still not completely
without problems.
[end OT]

If you have any code that involves passing allocations across .dll(package?)
boundaries where a memory allocation may have occurred on one side of a
boundary, and a re-allocation/free occur on the other side of the boundary,
everything on all sides of the boundary need to be compiled with Codeguard,
or everything not. (In particular, beware any string [or other] datatypes
that hide their buffer management. I'm pretty sure this has bitten me with
one third party library that provides a library specific string datatype
with a fair number of inline methods, some of which can involve string
definitions that might be allocated inside one set of walls, with that
allocation being changed inside another set of walls.)

So, to be safe, you can't just apply it to a specific application under
development. (At least we haven't been able to.) If you have your own
libraries/dlls, (or third party) which may in and of themselves be stable,
they too still need to be compiled with CodeGuard, if your main application
is, just to eliminate possible boundary-crossing issues.

Further, regarding principle, if your development structure involves
separate development/QC staff, I would recommend developers always run with
it on, but builds generated for QC/testing be done without it. (And of
course if QC finds an issue you can't reproduce on the developer's machines,
remember this difference in the builds could be a factor.)

While we are not in this position currently, I suppose tossing in an
occasional (predictably known/scheduled) CodeGuard build for QC to run
standard automated/canned tests against, might be a good thing as well, if
your testing structure includes automated tests. Running both ways without
problems is probably a good thing, given that the CodeGuard build might
reveal some things not evident (if your version of CodeGuard is reliable) in
normal builds - and for automated tests the time expense would presumably be
largely machine time that's probably in greater abundance than people time.

My question is aimed at the project creation and development phase in the
life of a project. Is it better or preferable to run CodeGuard
continuously from the start and correct as you go along, or leave it as a
one off exercise after completion?
Aris

[Aris Mednis]

Post by dhoke
I would tend to agree with JohnC in principle, except, that with bds2006,
we've found CodeGuard pretty unreliable.
[slightly OT]
It has tended to cause us as many problems, well actually more, than its
found for us. To the point that we abandoned principle, and occasionally
try it just in case it may find something without causing us grief.
I tried the trial 2007 versions, and it was better, but still not completely
without problems.
[end OT]

Thanks for the very helpful heads up. My question was prompted in part
by a few puzzling and unexpected CodeGuard reports on a project migrated
from BDS2006 to C++Builder 2007. I put it down to CodeGuard becoming
slightly more pedantic with a move closer to the ANSI standard - but was
never sure that that was a complete explanation.

Aris