|
Prev: How to return a reference to a derived object
Next: Search a web page which offers nifty little test questions and solution about programming C++
From: Tim Frink on 19 Dec 2007 05:23 Hi, I've a design question: I've implemented a static program analysis (for C programs) which currently does not support the data type float and double in the output program. My question is now how to react when the user provides a C source code with floats as input which cannot be analyzed. Since the analysis is embedded in a larger project and its results are not mandatory, an assertion when float/doubles detected is not acceptable. My ideas are: 1) When creating an object to my program analysis, its constructor runs an internal method to check if the input program contains any unsupported data types. If so, the analysis will be not performed (it will do nothing) when run by the user. So, the user need not to take care if the program analysis succeeded. 2) I add a public function which checks if the input program can be analyzed and return either true of false. In this scenario, the user must first create an object to the program analysis, then run the public check-method and if true was returned, the actual analysis can be started. The advantage here is that the information if the analysis is feasible is not hidden to the user but on the other hand the user must always take care that he starts the check-method in advance. Forgetting it might lead to problems. In my eyes, both approach are not really perfect and I'm looking for a better solution. How would you handle such an issue? Best regards, Tim
From: Bart van Ingen Schenau on 19 Dec 2007 13:53
Tim Frink wrote: > Hi, > > I've a design question: I've implemented a static program > analysis (for C programs) which currently does not support > the data type float and double in the output program. > > My question is now how to react when the user provides a C > source code with floats as input which cannot be analyzed. > Since the analysis is embedded in a larger project and its > results are not mandatory, an assertion when float/doubles > detected is not acceptable. My ideas are: > 1) When creating an object to my program analysis, its constructor > runs an internal method to check if the input program > contains any unsupported data types. If so, the analysis > will be not performed (it will do nothing) when run by the > user. So, the user need not to take care if the program > analysis succeeded. > 2) I add a public function which checks if the input program > can be analyzed and return either true of false. In this > scenario, the user must first create an object to the program > analysis, then run the public check-method and if true was > returned, the actual analysis can be started. The advantage > here is that the information if the analysis is feasible is > not hidden to the user but on the other hand the user must always > take care that he starts the check-method in advance. Forgetting > it might lead to problems. > > In my eyes, both approach are not really perfect and I'm looking > for a better solution. How would you handle such an issue? > > Best regards, > Tim It is not entirely clear from your description, but I am assuming that your tool performs a lint-like analysis of a C program. First of all, a simple textual scan for the keywords 'float' and 'double' is not sufficient to determine if a file contains floating-point operations. The keywords might be hidden with some macro, or they might appear in a context that should not be processed (such as a comment or #if 0-ed section). It is also possible to use floating point operations without using the keywords 'float' and 'double' at all. The best you can do is to add floating-point support to the tool. Initially, this could be such that the lexer recognises (and accepts) the floating point constructs, but no further checking is performed on them. Bart v Ingen Schenau -- a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq c.l.c FAQ: http://c-faq.com/ c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/ |