I have generated mock_foo.h and mock_foo.c from my foo.h header using Ceedling. The problem is that in generated file there are function names the same as in foo.c. For example, foo_function() is now in both foo.c and mock_foo.c, and I have to manually add __wrap prefix so that linker doesn't complain about multiple definitions.
Is it possible to add some option in project.yml in order to generate function which already have that prefix, ie. __wrap_foo_function()?
CMock has currently no option to add a user-defined prefix (like __wrap) to function names. Such a feature has been discussed twice back in 2014 (see Issue #32) and 2017 (Issue #137), but unfortunately the discussion dried out too early to add the feature to the project.
Issue #32 even proposed a patch but I guess this will not be easily applicable anymore to the current code basis.
A possible workaround might be to write a script that generates a modified version of the modules header file foo.h by adding the __wrap prefix to all function declarations within the file. With such a modified header CMock would generate a mock_foo.c with the appropriate function names.
For Python exists the pycparser project which might be helpful for this task. Especially the func_defs.py example looks like a promising starting point.
Related
I am trying to write my first (very) small, for now only self-use, library. In the process I came across questions regarding how I should separate my headers/source code/object files in a logical way.
To be more specific, I'm writing a small templated container class, so for one I have to include the implementation of this class inside its header.
I have a directory structure like this:
include/ - "public" .hh header files included by extern projects
src/ - .cc files for implementation (+ "private" .hh header files?)
lib/ - .o compiled library files linked by extern projects
I am already not sure if this makes sense.. in my case I also wrote some helper-classes used by my templated container class, one of which is something like an iterator. So I have the following files:
container.hh
container.cc
container_helper.hh
container_helper.cc
container_iterator.cc
container_iterator.hh
While I want to have access to their functions in external projects (e.g. incrementing the iterator), it makes no sense to me that a project would specifically
#include "container_iterator.hh"
Now, since I want projects to be able to use the container class, I put "container.hh" and "container.cc" (since it must be included in "container.hh" because of the template) into the "include/" directory, which is then included by other projects.
Now my confusion arises.. the container class needs access to the helper classes, but I don't want other projects to only include the helper classes, so it seems wrong to place also the helper classes into "include/" directory. Instead, I would place them in "src/".
But if I do this, then to include these in "include/container.cc" I have to use relative filepath
#include "../src/container_iterator.hh"
But now if I "distribute" my library to an external project, i.e. I only make the "include/" directory visible to the compiler, it will not compile (?), since "../src/container_iterator.hh" does not exist.
Or do I compile the container class and put it as library into "lib/", which is then linked by other projects? But even then do I not still need to include the header "container.hh", to be able to find the function declarations, which leads to the same problem?
Basically I'm lost here.. how does the standard do this? E.g. I can
#include <vector>
, but I don't know of any header to only include std::vector::iterator, which would make no sense to do so.
At some point in my expanation I must be talking nonsense but I cannot find where. I think I understand what a header and a library is/should be, but when it comes to how to design and/or "distribute" them for an actual project, I am stuck. I keep coming across problems like this even when I started learning C++ (or any language for that matter), no course / no book ever seems to explain how to implement all these concepts, only how to use them when they already exist..
Edit
To clarify my confusion (?) more.. (this got a bit too long for a comment) I did read before to put implementation of templated classes into the header, which is why I realized I need to at least put the "container.cc" into the include/ dir. While I don't particularly like this, at least it should be clear to an external user to not include ".cc" files.
Should I take this also as meaning that it never makes sense to compile templated classes into a library, since all of it will be always included?
(So templated code is always open-source? ..that sounds wrong?)
And in this case I still wonder how STL does it, does vector declare & define its iterator in its own header? Or is there a separate header for vector::iterator I could include, it just would make no sense to do so?
Hopefully I explained my intent clearly, please comment if not.
Thanks for any help!
In my experience, the most common method to handle your problems is to have headers with the template declarations and documentation (your .hh files), which also include .inc or .tcc (your preference) files with the template definitions. I also suggest keeping all files that may be included by external projects in the same folder, but if you want to keep things clean, put your .inc/.tcc files in a folder within include called detail (or bits if you like GNU style).
Putting stuff in a detail folder,
and using a weird extension should deter users enough.
To answer your other questions:
Due to the nature of C++ templates,
either the entire source of the parts of a template you use
must be present in the translation unit (ie. #include'd),
or you can use explicit instantiation
for a finite number of arguments
(this is not generally useful for a container, though).
So, for most purposes, you have to distribute a template's source, though,
of course, (as mentioned in the comments) "open source" is about licence,
not source visibility.
As for the standard libraries, lets use <vector> as an example.
The GNU C++ Library has a vector file that (among other things) includes
bits/stl_vector.h which has the declarations & documentation,
and includes a bits/vector.tcc that has the definitions.
LLVM's libc++ just has one giant file,
but puts the declarations at the top (without documentation!)
and all the definitions at the bottom.
As a final note, there are lots of open source C++ libraries that you can take a look at for inspiration in the future!
We are mocking our code but we are having difficulties eliminating the dependency of other files the mocked file includes due to the mocked header including the original header which includes several other files.
The error we are getting below:
In file included from ../nRF5_SDK_11.0.0_89a8197/components/softdevice/s130/headers/ble_gap.h:48:0,
from ../nRF5_SDK_11.0.0_89a8197/components/softdevice/s130/headers/ble.h:52,
from ../infrastructure/microcontroller_abstraction/ble/include/ble_service.h:4,
from ../infrastructure/system_abstraction/pressure/include/pressure_service.h:15,
from ./mocks/pressure_service_mock.h:5,
from ./mocks/pressure_service_mock.c:7:
../nRF5_SDK_11.0.0_89a8197/components/softdevice/s130/headers/ble_gap.h: In function 'sd_ble_gap_address_set':
../nRF5_SDK_11.0.0_89a8197/components/softdevice/s130/headers/nrf_svc.h:66:5: error: unknown register name 'r0' in 'asm'
__asm( \
^
It is due to the following sample scenario:
lets take a sample file pressure service mock.c for example
the mock.c ---- includes ---> mock.h
the thing is, since mock.h is generated, it is including the the pressure_service.h
and since we are including the pressure_service.h , it is trying to include the ble_service.h
and then up the hierarchy of includes
the c files of the original SDK is NOT compiled
but the header files have to be included
how would we stop Cmock from including the pressure_service.h?
Please assist i believe this is a generic problem and it is the whole purpose of why one would utilize CMOCK, but we cannot seem to find the solution.
Short answer:
AFAIK there is no option for CMOCK to dismiss any of the includes of the mocked C module. It is only possible to specify additional includes.
Depending on your structure of include directories you can try to replace the obstructive header (pressure_service.h in your example) by a strip-down copy of the original header, which reduces any additional dependencies to the minimum.
Long answer:
IMHO you are not facing a generic problem of CMOCK here but a design problem of the module your are trying to mock. It is a tried and tested practice that the header of a C module should only include further header files, which are needed by the public interface of this module. Typical dependencies are type definitions, that are used for arguments and/or return values of interface functions. Since mocking a module means to provide a fake implementations of the specified interface, CMOCK needs to copy all of the original includes over to the mock implementation, in order to make it compile.
This problem can usually be solved reducing the dependencies of original header (the one to be mocked), which usually leads to a better software architecture in general. If the module to be mocked comes from a third party library, this is usually beyond reach, though. In this case, a workaround is making a copy of the original header and stripping it down to the minimum functionality required for the unit test. Of course this implies, that any change to the original interface needs to be manually transfered to strip-down copy later. In case of a stable third party module that should not be a big problem, though.
I am working on C++ project. I have a file named "version" where only 12343 like number is defined [In fact the version] in numeric form.
This "version" file is defined in Library A.
Somehow I need to assign this value to a macro in another library B file.
Is there any way to do it?
Since, the work is official, so I can't share the code here.
Neither C nor C++ has a language feature that would allow you to set the expansion text of a macro to something read at compile time from an external file. Such tasks are generally assigned to the build system, instead.
There are diverse mechanisms for the purpose, but they follow this general procedure:
An external program reads the file containing the wanted text
That program either
formats the text of a compilation option conveying the definition (e.g. -DVERSION=${what_I_read_from_the_file}), or
writes a header file containing the macro definition itself, e.g.
#define VERSION version-text-from-the-file
Either way, the obtained information is provided to the build in the appropriate manner -- the compiler option alternative proceeds by ensuring that the chosen option is passed to the compiler at build time, whereas the header alternative depends on the files that need the macro #includeing the generated header.
I've just been given my first real C++ application on the job after working through some books learning the language.
It was my understanding that your cpp source files required the cooresponding header, yet one of the libraries in my project is building fine with a number of cpp files that DO NOT include the cooresponding header. This particular cpp implements a class found in a header that has a different name and a number of other pieces of code beyond just the original class declaration.
How is it that the cpp can compile functions belonging to a class that it has no knowledge of?
Can the implementation of these functions be compiled independently and are simply called when a client application using the library (and including the header with the class declaration) calls the corresponding member function? If this is the case, how is the implementation binary referenced by the client application?
(I assume this is the linker...but I would love to have this cleared up).
I anticipate the answer may expose a misunderstanding of mine with regard to the include and compilation process, and I'd really like to learn this aspect of C++ well. Thank you!
When a c++ source file is compiled the first stage it goes through is preprocessing.
When the include directive is reached the file is found and the entire contents of the file, whatever that may be is included into the source file, as if it had been written in the source file itself.
You will be able to define any function from a class in any source file that includes the class's declaration, this is the source file "knowing" about the class / function".
There's also no requirement that the contents of a header and a source file will have any relationship. It's widely considered to be very good practise however.
The implementation of each compilation unit (a source file) is compiled independently. Any function definition could be placed in any compilation unit, and it would make not difference whatsoever. When the compilation units are linked together the usages of every declaration are matched to all the definitions.
The only other pattern that some people might use other than the 1:1 relationship between source files and header files (that I can think of) is that the header files each describe a class and each source file would implement a collection of related functionality. But this is a bad idea (in my opinion) because it would encourage the definitions of various classes to because highly coupled.
These are several questions. You should try to split these.
The name of the files where something is declared is not relavant. The compiler gets the preprocessor output independent from the files that have been read by the preprocessor. The compiler might be use some file/line information in the preprocessed file to issue more readable diagnostic messages.
When you declare a class in a header file and copy that declaration to a implementation file everything works fine as long as you don't change one of the copies of the declaration. This is bad dangerous and should be avoided. Declare anything always once.
When you compile an implementation of a class member function you get a function that the linker can link to your client program. A good tool chain is able to link only the functions that are accessed. So you can separate the interface (in the header files) from the implementation that is provided in a static library. The linker will add each object module in the library to your executable until all symbol references are resolved.
I've got a C/C++ question, can I reuse functions across different object files or projects without writing the function headers twice? (one for defining the function and one for declaring it)
I don't know much about C/C++, Delphi and D. I assume that in Delphi or D, you would just write once what arguments a function takes and then you can use the function across diferent projects.
And in C you need the function declaration in header files *again??, right?. Is there a good tool that will create header files from C sources? I've got one, but it's not preprocessor-aware and not very strict. And I've had some macro technique that worked rather bad.
I'm looking for ways to program in C/C++ like described here http://www.digitalmars.com/d/1.0/pretod.html
Imho, generating the headers from the source is a bad idea and is unpractical.
Headers can contain more information that just function names and parameters.
Here are some examples:
a C++ header can define an abstract class for which a source file may be unneeded
A template can only be defined in a header file
Default parameters are only specified in the class definition (thus in the header file)
You usually write your header, then write the implementation in a corresponding source file.
I think doing the other way around is counter-intuitive and doesn't fit with the spirit of C or C++.
The only exception is can see to that is the static functions. A static function only appears in its source file (.cor .cpp) and can't (obviously) be used elsewhere.
While I agree it is often annoying to copy the header definition of a method/function to the source file, you can probably configure your code editor to ease this. I use Vim and a quick script helped me with this a lot. I guess a similar solution exists for most other editors.
Anyway, while this can seem annoying, keep in mind it also gives a greater flexibility. You can distribute your header files (.h, .hpp or whatever) and then transparently change the implementation in source files afterward.
Also, just to mention it, there is no such thing as C/C++: there is C and there is C++; those are different languages (which indeed share much, but still).
It seems to me that you don't really need/want to auto-generate headers from source; you want to be able to write a single file and have a tool that can intelligently split that into a header file and a source file.
Unfortunately, I'm not aware of any such tool. It's certainly possible to write one - but you'd need a given a C++ front end. You could try writing something using clang - but it would be a significant amount of work.
Considering you have declared some functions and wrote their implementation you will have a .c/cpp file and a header .h file.
What you must do in order to use those functions:
Create a library (DLL/so or static library .a/.lib - for now I recommend static library for the ease of use) from the files were the implementation resides
Use the header file (#include it) (you don't need to rewrite the header file again) in your programs to obtain the function definitions and link with your library from step 1.
Though >this< is an example for Visual Studio it makes perfect sense for other development environments also.
This seems like a rudimentary question, so assuming I have not mis-read,
Here is a basic example of re-use, to answer your first question:
#include "stdio.h"
int main( int c, char ** argv ){
puts( "Hello world" );
}
Explanation:
1. stdio.h is a C header file containing (among others) the definition of a function called puts().
2. in main, puts() is called, from the included definition.
Some compilers (including gcc I think ) have an option to generate headers.
There is always very much confusion about headers and source-files in C++. The links I provided should help to clear that up a little.
If you are in the situation that you want to extract headers from source-file, then you probably went about it the wrong way. Usually you first declare your function in a header-file, and then provide an implementation (definition) for it in a source-file. If your function is actually a method of a class, you can also provide the definition in header file.
Technically, a header file is just a bunch of text that is actually inserted into the source file by the preprocessor:
#include <vector>
tells the preprocessor to insert contents of the file vector at the exact place where the #include appears. This really just text-replacement. So, header-files are not some kind of special language construct. They contain normal code. But by putting that code into a separate file, you can easily include it in other files using the preprocessor.
I think it's a good question which is what led me to ask this: Visual studio: automatically update C++ cpp/header file when the other is changed?
There are some refactoring tools mentioned but unfortunately I don't think there's a perfect solution; you simply have to write your function signatures twice. The exception is when you are writing your implementations inline, but there are reasons why you can't or shouldn't always do this.
You might be interested in Lazy C++. However, you should do a few projects the old-fashioned way (with separate header and source files) before attempting to use this tool. I considered using it myself, but then figured I would always be accidentally editing the generated files instead of the lzz file.
You could just put all the definitions in the header file...
This goes against common practice, but is not unheard of.