When implementing a new highly independent function in the project that participated in the development, I would like to keep the following points in mind.
At this point, use a combination of language and library that makes it easy to verify the algorithm.
In my case, I often use interpreter languages such as MATLAB and python. It is important to have enough libraries to graphically verify that the algorithm behaves as intended, and the code to show that the behavior is what you expect, rather than the algorithm itself that you actually implement. Is overwhelmingly more.
It is not used at the port destination, and the functions for testing and operation check do not have to be ported.
In my case, I often use an interpreter language such as python, a batch, or a shell script as a tool that makes verification easier by performing only the implemented algorithm in the target development language. For example, create a function that processes one file so that it receives command line arguments and processes it, and then operates it with the system () function in the interpreted language. In this way, the source code in the target development language can be simplified so that the source code is not unnecessarily tampered with and the reliability of the code is not compromised.
Do not forcibly port the verification process, which is not necessary for the production implementation, to the target language.
By making it an independent file, it becomes a separate file for each purpose, so it becomes clear in SVN when and who updated the highly independent function. In addition, the location of the division of each file becomes clear.
In the prototype implementation, while actually confirming the usefulness of the algorithm, we will refactor the prototype implementation so that it is easy to maintain. In the initial version of the prototyping implementation, the code for verifying the operation and the algorithm itself are mixed. Separate it and eliminate unnecessary library imports and #includes. Then you can see what is a highly independent process and how to design it. After that. Implement the design verified by refactoring the prototyping implementation in the target language. By doing so, you can proceed with the design with confidence rather than suddenly designing in the target language.
In the C ++ language, add the const modifier to the function argument. Variables passed as arguments are passed by reference. Passing by value results in a large amount of unnecessary copies of data, so pass by reference. Passing by pointer requires more careful coding than passing by reference, so when passing by reference is sufficient, it is often passed by reference.
In interpreted languages like MATLAB and Python, functions can return multiple variables. Therefore, it is possible to code the input value as an argument and the output value as a return value. In the C / C ++ language, the return value of a function or method is limited to a single data structure, so the output value is often received as an argument of the function or method by passing a pointer or by reference. Even so, receiving the output as the return value of a cv :: Mat type function has many advantages that make it easier to write the code to use. cv::Mat somefunc(const cv::Mat &img); Declared in cv::imwrite("junk.png ", somefunc(cv::imread("lena.jpg ")); It becomes possible to describe like. By that amount, the content of the processing in one line becomes richer, and the code becomes easier to understand. You will be less aware of the memory allocation and release part, and you can concentrate on the algorithm.
In the case of the conventional IplImage, when the pointer variable of IplImage type is declared, if the pointer of IplImage type is NULL, the area is reserved, or the value is set in the area, it is already. In some cases, it is a reference to an existing IplImage type, and if the processing is distributed around the program, a pattern that forgets to release the IplImage type area may occur.
Using a unique namespace prevents identifiers from colliding with other source code. Do not write using namespace; on both the side that uses the added module and the module itself.
Narrow down the interfaces that additional modules expose. Add a static declaration to functions that are only called within that file.
In my case, I write documentation comments using Doxygen.
In addition to the main program for normal operation, create a project file that generates a test program. Allow a small program to test whether the additional implementation's functionality behaves as intended. It may not always appear in the unit testing framework represented by CppUnit at first, but even so, it is easier to test the program because it can be tested with a small test program that is different from the normal operation program.
Let's take a closer look at the source code of the port to find out which part of the source code of the port to use the additional functions. If you don't have a smooth interface, one function may be doing too much and needing "extract function".
By doing this, I want to implement additional functions without any trouble.
--