Solved

How do I create two codes from one source?

Posted on 2000-02-19
6
191 Views
Last Modified: 2010-04-02
I want to maintain a debug code and a production code within one file.  Performance is critical and hence
I don't want the production code cluttered with
conditional statements.  In C I would use #defines,
but my understanding is that there are more elegant
solutions in C++..

To be specific, the debug code will maintain a second
array and return an additional output.  I don't want the
second array to even exist in the production code.

Ideally I would like to be able to link the debug and prodcution codes in the same executable so that
I can run both codes and assert that they both
produce the same answers.

Thanks,
  Ken
0
Comment
Question by:klopter
  • 3
  • 3
6 Comments
 
LVL 22

Accepted Solution

by:
nietod earned 100 total points
ID: 2538113
>> In C I would use #defines, but my
>> understanding is that there are more
>> elegant  solutions in C++..
For most things C++ provides more "elegant" solutions than C.  But not this one.  You wantto use conditional compilation to remove your debuging code from the source and the only way to do that is with the pre-processor (#ifdef...#endif, or that type of thing.)

However, if you have an optimizing compiler--and you probably do, you can be reasonabley sure that the compiler will strip out unreachable code, so if you define a boolean that indicates if it is a debug/release version you can probably place if()s in the code that contain debug tests and the test will be removed by the optimizer so they won't appear in the release verison.  For example

const bool DebugVersion = true

  *  *  *

if (DebugVersion)
   if (ArrayIndex > ArraySize)
      cout << "Error: array index too large.";

Check this with a few tests on you compiler by looking at the assembly output.  but there is a good chance that all that code will be removed when DebugVersion is false.

>> To be specific, the debug code will maintain a
>> second array and return an additional output.  
>> I don't want the second array to even exist
>> in the production code.
That sounds like a job for conditional compilation (#if)

>> I would like to be able to link the debug and
>> prodcution codes in the same executable so that
>> I can run both codes and assert that they both
>> produce the same answers.
At the same time?  What do you mean by this?  
0
 

Author Comment

by:klopter
ID: 2538135
>> I would like to be able to link the debug and
>> prodcution codes in the same executable so that
>> I can run both codes and assert that they both
>> produce the same answers.
                At the same time?  What do you mean by this?  

I mean:
#ifdef DEBUG
#define routinename debugroutine
#else
#define routinename productionroutine
#endif

..
..
..






And in the code that calls this routine:

debugresult = debugroutine( ... ) ;
productionresult = productionroutine( ... ) ;
assert( debugresult == productionresult ) ;



The point being that the debugroutine and
the production routine actually use
slightly different logic and hence
could get different answers.

In any case, if cpp is the answer, I
know how to munge my code and Makefile
to get what I want.

Thanks,
  Ken
0
 

Author Comment

by:klopter
ID: 2538144
One more question:  

If I trust the compiler to get rid of the debug
code as you suggest, I will get compiler warnings
about unreachable code.  One option is to
turn off those warnings by figuring out which -Wno_...
flag to set on the gcc command line.

Is there a way that I can tell gcc (or better yet
all compilers) that I know that this code might
be unreachable?

I make a lot of mistakes that compiler warnings
catch, so I like to keep my compiler output clean.

Ken
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 22

Expert Comment

by:nietod
ID: 2538177
I don't know what the

#define routinename debugroutine

does for you, since you want to have both version in your code and will be calling each by their unique names.


But let me suggest an alternative.

Just do this with one function.  In the debug version this one function include the both the regular and the special algorithms and should test the result before it finishes.  In the release version it contains only the regular algorithm, for example

int SomeFunction()
{
#ifdef DEBUG
   int Debug_Result = ????; // debuf algorithm.
#endif
  int Result = ???? // regular algorithm.

#ifdef DEBUG
   if (Debug_result != Result) ....
#endif
}

This sort of approach keeps the debug and relase versions more similar and  it simplifies the debugging procedure.  i.e the code that uses the procedure doesn't have to "remember" to perform the test.
0
 
LVL 22

Expert Comment

by:nietod
ID: 2538181
>> Is there a way that I can tell gcc (or better yet
>> all compilers) that I know that this code might
>> be unreachable?
No, this is very compiler-specific.  (Soem compilers might not even give such a warning and some might produce it byt not have an option to turn it off.)  I don't know gcc, so I can't give you any help there.  What VC does is have a #pragma you can use to turn of any warning/error message based on its warning/error number.
0
 

Author Comment

by:klopter
ID: 2538338
I agree that your one routine solution is
cleaner.  

Thanks,
  Ken
0

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Often, when implementing a feature, you won't know how certain events should be handled at the point where they occur and you'd rather defer to the user of your function or class. For example, a XML parser will extract a tag from the source code, wh…
IntroductionThis article is the second in a three part article series on the Visual Studio 2008 Debugger.  It provides tips in setting and using breakpoints. If not familiar with this debugger, you can find a basic introduction in the EE article loc…
The viewer will be introduced to the technique of using vectors in C++. The video will cover how to define a vector, store values in the vector and retrieve data from the values stored in the vector.
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question