I have wrote the syntax: mock().expectNoCall("productionCode") as Cpputest.org page says. But the compiler says that mocksupport class doesn't support this type of order.
test_RFID_Drv.c:322:9: error: ‘class MockSupport’ has no member named ‘expectNoCall’mock().expectNoCall("HAL_AS393x_ReadRegisters");
How can it be used? Must I include some file at headers?
Currently I have those ones for mocking:
/*! \include <CppUTest/CommandLineTestRunner.h> */
#include <CppUTest/CommandLineTestRunner.h>
/*! \include <CppUTest/TestHarness.h> */
#include <CppUTest/TestHarness.h>
/*! \include <CppUTestExt/MockSupport.h> */
#include <CppUTestExt/MockSupport.h>
The thing is that I want to ignore one concret system call. I don't want to test it.
Eugenia, You are in a '.c' file, mock().expectXX is a syntax for '.cpp' files.
This is a working example of no expectations in a .cpp file.
If you need to use mock from .c files, include "MockSupport_c.h" and make sure you use the correct c syntax, read the header here.
If you don't want to use the syntax of the "_c" header, make your mocks file a .cpp and add the export "C" linker modifier to your mocked function, such as I did here.
Related
I am working on a project using MSP430FR6047 and there is certain header file I need to access and change parameters previously defined.
At the moment I have to flash the MCU with modified header file every time I change the parameter but I was exploring if there is another option to do theses changes without flashing the new code, preferably by UART or some other communication protocol.
So my question is how to change these parameters during runtime? Does any one know where should I start?
Thanks
A running program cannot change its source code, supposed that you mean something like #define PARAMETER 23. You need variables instead of constants.
One primitive solution is this:
Invent a global variable per parameter, declare all of them in an extra header file and define all of them in an extra source file for better maintenance.
In the new header file undefine all parameter macros and redefine them to use the variable instead of the literals.
In the using source files, include the original header file, after that include your new header file.
Initialize the variables initially, and change parameters as you wish during run time. (Initialization could be done in the new source file.)
This solution avoids heavy editing the using source files and leaves the original header file intact.
Example:
/* original.h */
#define PARAMETER 23
int f(void); /* returns PARAMETER */
/* new.h */
#if defined(PARAMETER)
#undef PARAMETER
#define PARAMETER parameter
#endif
extern int parameter;
/* new.c */
#include "new.h" /* ensures that declarations and definitions match */
int parameter = 23;
/* original.c */
#include "original.h"
#include "new.h"
int f(void) {
return PARAMETER;
}
/* main.c */
#include <stdio.h>
#include "original.h"
#include "new.h"
int main(void) {
PARAMETER = 42;
printf("%d\n", f());
}
If you like to change the original source code, feel free to get rid of all this preprocessor stuff, and directly use variables instead of constants. But then you should re-think your design and provide parameters as arguments to existing or new functions. Global variables should be avoided, reasons are left as an exercise to you.
There are 2 cases which change parameter in header file.
Case 1: Header define default value
For example, in header file you have:
#define DEFAULT_VALUE 10
then in .c file if it is using like:
if (a < DEFAULT_VALUE)
{ /* Do something */ }
If this is the case you could update as following:
Modified the original line:
if (a < var_DefaultValue)
{ /* Do something */ }
With var_DefaultValue is global variable:
int var_DefaultValue = DEFAULT_VALUE;
By default, this will work as original.
If you want to change value, you could create a thread to receive new value somewhere and then update to var_DefaultValue.
Case 2: Header file define some precompile tag. For example:
#define DEFAULT_FEATURE 1
and in .c file you refer to feature as following:
#if DEFAULT_FEATURE
/* Do Something */
#endif
For this case, it is impossible to change it by any mean.
I define a user class to hold all object. But the yacc is going to made a header file, which the yylval's type must be YYSTYPE. If I do not use %union, it will hold it as a int. But if I use %union, it will a union. and union is ugly - It cannot hold a class or a shared_ptr (can but not a good idea), It only want me to use pointer.
I just want to make YYSTYPE has a type as a user class type. How can I do it?
Don't use YYSTYPE.
With bison -- which is what you are actually using as a yacc implementation-- the correct way to define the semantic value type is
%define api.value.type { MyType }
If you require that one or more header files be included for the declaration to be valid, put them inside a %code requires block:
%code requires {
#include "MyType.h"
}
The code generated by these two directives is copied into the header file which bison produces, so other files need only include the generated header file.
Warning: Note that unless you use bison's C++ interface, the semantic value type must be trivially copyable, which will eliminate most standard C++ library types. Failing to obey this rule will produce undefined behaviour which may go undetected until you attempt to parse a sufficiently complex input. In other words, tests with simple inputs may not reveal the bug.
As you see, the source file that made by lex and yacc need the header file that made by yacc.
the header is short so we can look for some solution in it.
the part that define the type of yylval is this:
/* Value type. */
#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
typedef int YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define YYSTYPE_IS_DECLARED 1
#endif
extern YYSTYPE yylval;
so we can define YYSTYPE before we include the yacc's header file, looks like:
#include "your-header-file-that-define-the-class.h"
#define YYSTYPE your-class-type
#include "the-header-file-that-made-by-yacc.h"
Suppose in a CMake project, I have a source that is built into a library
// a.cpp
void f() { /* some code*/ }
And I have a header
// b.h
void f();
struct X { void g() { f(); } };
I have another file:
// main.cpp
#include "b.h"
int main() { X x; x.g(); }
The CMakeLists.txt contains:
add_library(A a.cpp)
add_executable(main main.cpp)
target_link_libraries(main A)
Now look at the last line of the CMakeLists.txt: I need to specify A as the dependencies of main explicitly. Basically, I need to specify such dependencies for every source that includes b.h. Since the includes can be indirect and go all the way down through a chain of includes. For example, a.cpp calls a class inline function of c.h, which in turns calls function in d.h, etc, and finally calls function from library A. If b.h is included by lots files, manually finding out all such dependencies is not feasible for large projects.
So my question is, is there anyway to specify that, for every source file that directly or indirectly includes a header, it needs to link against certain library?
Thanks.
To make one thing clear: You a.cpp gets compiled into a lib "A". That means that any user of A, will need to specify target_link_libraries with A. No way around it. If you have 10 little applications using A, you will need to specify target_link_libraries ten times.
My answer deals with the second issue of your question and I believe it is the more important one:
How to get rid of a chain of includes?
By including a.h in b.h and using its method in b.h you are adding a "implicit" dependency. As you noticed, any user of b.h needs a.h as well. Broadly speaking, there are two approaches.
The good approach:
This has nothing to do with CMake, but is about encapsulation. The users of your library (incl. you yourselves) should not need to worry about its internal implementation. That means: Don't include b.h in a.h.
Instead, move the include to a .cpp file. This way, you break the chain. E.g. something like
// b.h
void f();
struct X
{
void g();
};
// b.cpp
#include b.h
#include a.h
void X::g( )
{
f();
}
This way, the use of a.h is "contained" in the cpp file and anyone using you library need only include b.h and link to b.lib.
The alternative:
Now, there are situations where you have to accept such a "dependency" or where it is a conscious choice. E.g. when you have no control over A or when you conciously decided to create a library defined in terms of classes/structs internal to A.
In that case, I suggest you write a piece of CMake code, which prepares all the necessary include-dirs down the chain. E.g. define a variable "YOURLIB_INCLUDES" and "YOURLIB_LIBRARIES" in "YourLibConfig.cmake" and document that any user of your library should import "YourLibConfig.cmake". This is the approach several cmake-based projects take. E.g. OpenCV installs a OpenCVConfig.cmake file, VTK installs a VTKConfig.cmake and prepares a UseVTK.cmake file
In the header of the class, outside of interface declaration, I've declared global constants:
NSString * const gotFilePathNotification = #"gotFilePath";
NSString * const gotResultNotification = #"gotResultOfType";
gotResultNotification is used only in this class (yet), but I reference gotFilePathNotificaion in another class implementation. To do it, I import this header.
When I try to compile, I get a duplicate symbol linker error about gotFilePathNotification in this header. Why does it happen?
You have two identifier(s) with same name across two different compilation unit(s) at file scope. This violates One Definition Rule. Instead you need to -
Declare the global variables marking to have external linkage in a header file.
extern NSString * const gotFilePathNotification;
Now provide the definition in only one source file.
NSString * const gotFilePathNotification = #"gotFilePath";
Now where ever you need to use these variables, include the header in the source file.
You need to declare them extern in the header file and define them in implementation file. See this question for clarification. Global Variables in Cocoa/Objective-C? .
The second response provides the clarification that I will reiterate here. The default storage qualifier for variables is static. This means when you try to link two different files with the same variable, as will happen when you import your header file, the linker will construe that the variable is multiply-defined.
Also make sure you're including the h file and not the m file. This was driving me nuts.
I have a static library say "A.lib" which contains a function int foo(). I have another dll say "B.dll" which consumes A.lib and uses the function foo() and also exports some other functions. Is it possible to export the function int foo() (imported from A.lib) from B.dll so that it can be consumed in a third dll say "C.dll".
I want to know whether it is possible or not, I dont want workarounds like making A.lib available to the C.dll. Also, I am not concerned if this is a bad design or not.
Thanks very much for your patience to read this through.
I had the same requirement - just found a different solution:
Assuming that A.lib has an A.h (that is consumed by source files used to build B.dll e.g. assuming that A.h contains prototypes for functions contained in A.lib), just add the following in A.h:
#pragma comment(linker, "/export:_foo")
This will instruct the linker to export foo() when building B.dll. Note the leading underscore - it is there because that's the true name of the symbol for foo() contained in A.lib (use dumpbin /symbols A.lib | findstr foo to see it). In my example foo() was using the __cdecl calling convention, but if you use __stdcall() or compile as C++, you'll get different name decoration, so you'll have to adjust the #pragma statement above as a result.
It doesn't matter if A.h gets included by many source files in B.dll - the linker doesn't complain if the exact same definition is made multiple times.
One "advantage" to this approach is that you don't even have to use the __declspec(dllexport) specifier on foo() in A.lib ...
Yes, it's possible but any code example is language dependent.
(for example in C you may simply export a function with the same name and C.dll will see it)