- lib_xxxx_vz.h, including "lib_xxxx_vz.interface" and "lib_xxxx_vz.dep"
- lib_xxxx_vz.c, body, calling #include "lib_xxxx_vz.private"
- lib_xxxx_vz.interface public interfaces
- lib_xxxx_vz.private private interfaces
lib_xxxx_vz.dep dependencies with other modules
You will probably make your life much easier, wrt "standard tools" if you name the files with a .h extension, even if that means
"lib_xxxx_vz_interface.h", "lib_xxxx_vz_private.h", etc. (hopefully your compiler supports long filenames.)
Do you actually need something different than the dependency files that the compiler (most compilers) will generate for you automatically?
i also looking forward if any such app to make reverse engineering or understanding ossw code easier
i made my own very simple "inter-files dependency only" library manager (capture attached)
to make things easier by searching #include keyword, to make inter-functions things can get too difficult to code, there will be too much to parse and generate. if i'm not mistaken, doxygen only generates comments (explanation) for each subroutines which is something i usually do myself and more effective for my need, no?
obvious are conditional preprocessor directives, and macros.
obvious are conditional preprocessor directives, and macros.
why ?
- interfaces dependencies do not require the preprocessor
- typedef dependencies might require the preprocessor, but we (in the team) are not allowed by the boss to use any #define with typedef, and it makes him pissed off if he sees a an abuse of #define, and our code must also pass a lot of "code-validators" in order to make the commit accepted in the repository (our final customers want that way)
but in case of need, I have no trouble to "add" a "preprocessor" that expands macros and #defines, I have already coded a working one and I can integrate into my tools.
to tell you the truth, we have a special include file in our projects, it's called "types.h", it's located at the top of our libraries path and it's a mixture of #define and typedef, but mainly typedef is used to (re)define things like uint32_t, fp_IEEE_754 _t , fxp32_t (fixed point, used by our soft core, VHDL), etc, while #define is used to (re)define the language, e.g. we are NOT allowed to use "==" in the if-then-else statement, so we have to use "isEqualTo", and we can't use "&" to get the address of an entity, we must use "get_address()", which are both #defines
- "it's boring and pedantic, but it makes sense" - I was told by my boss, even if I am still too young to understand why?
What I Know is that our sources need to pass a super-set of MISRA checks, I mean our customers give us their "code validators" and we have to apply them to our sources. These "code validators" are extremely pedantic and also apply special rules from DO178/A-B, plus other constraints, e.g. for each module the maximal McCabe Cyclomatic Complexity must be < 7, which is not "C", and it's not MISRA, it's an additional rule imposed by our customers.
I am not in the development squad, I am the testing-boy, unfortunately, because of my junior-profile, against their senior-profile, so often I am asked to care about the full documentation, which I have to provide written in Microsoft Word (puuaahhh, I hate it, but I MUST use), plus an other document produced by Stood. A part of this documentation is related to the dependencies, so I have to fill a big matrix {1..n,1..n} in where I have to enumerate all the modules from 1---to--n and then, for each 1={1..n} I have to indicate which module is in dependency by which module, with both direct and inverse matrix.
Stood should be able to provide all of these informations, but ... it's an other story, like having the full version released only for SunOS, with the licence expired since a while, problems to get a new license (never understood the Why-on-the-Why(1)?), and a demo version for Windows installed on our desks, which is cool and free but with a lot of features disabled (including the dependency matrix ) ....
(1) about the Why-on-the-Why
I guess, because a job in avionics must not be fun
i also looking forward if any such app to make reverse engineering or understanding ossw code easiertry Understand by SciTools, shoot a PM to me for a few tricks
i made my own very simple "inter-files dependency only" library manager (capture attached)it looks very good, do you have a tokeners ? a parser ?
$1K tag?
i wish i have "inter-subroutines or inter-functions" dependency as well, but that is too complex for me to code
so any tool with price tag greater than $50 is cough cough for me.
Isn't it time for C to grow up and do away with all these stupid forward declarations and header files ?
Why is that needed anyway ? all the compiler has got to do is go over all your source files once , collect all globals and functions and build a map. and then start compiling.
All the misery with headers that don't match the actual routines , all the extra keyboard pounding .. it all goes away. Huge time and misery saver.
C is an archaic language full of restrictions and idiosyncrasies because the original code parser was severely limited in what it could handle.
book "Safety Critical Programming in C" starts off by saying, "don't use C"
dev-lang/gnat-gcc
SRC_URI="ftp://gcc.gnu.org/pub/gcc/releases/gcc-${PV}/gcc-core-${PV}.tar.bz2
ftp://gcc.gnu.org/pub/gcc/releases/gcc-${PV}/gcc-ada-${PV}.tar.bz2
amd64? ( https://dev.gentoo.org/~george/src/gnatboot-${BOOT_SLOT}-amd64.tar.bz2 )
sparc? ( https://dev.gentoo.org/~george/src/gnatboot-${BOOT_SLOT}-sparc.tar.bz2 )
x86? ( https://dev.gentoo.org/~george/src/gnatboot-${BOOT_SLOT}-i686.tar.bz2 )"
ppc? ( mirror://gentoo/gnatboot-${BOOT_SLOT}-ppc.tar.bz2 )
The way to make intermodule dependencies easier to understand is simply to create fewer of them, which means making the modules reasonably large and simplifying the whole project structure/design as much as possible. The worst are multi-file projects where each file contains a dozen or so lines of actual code at most.
don't use C, use something else.
(void)memcpy(dst, src, (size_t) sizeof(some_var)); // some people on our team think that this is a great solution... read below...
Isn't it time for C to grow up and do away with all these stupid forward declarations and header files ?C is indeed a terrible language which should not be used for any serious programming. Unfortunately everyone does!
Way back when C started becoming popular, I thought "this is a terrible language, it will get superseded soon" but 30+ years later, there are better languages, but people don't use them.
ask them what "a[ i ] = i++;" should do, according to the C standard.
a[i] = i;
i = i + 1;
its perfectly valid What is hilarious, is all those projects claiming to be "safety critical" but still writing in C
Even the book "Safety Critical Programming in C" starts off by saying, "don't use C"
I have seen IDE's for C where you can simply define a function and the IDE will create the forward declaration for you. i think it is called Cide ( short for C-IDE).