I am a self taught newbie in C/C++ with some holes in my knowledge. I am looking for advice on how to structure my headers for a C/C++ project that I am working on in VS2008. I would like to port some of the code to another CPU architecture, probably ARM so portability is an issue. For this reason the portable code is written in C with the GUI diagnostics written in C++/MFC.
Your advice about how you structure your headers would be appreciated.
Thank you laserlight for your response. How many of the rules do you think are based upon the precept of hiding the data structures and code? I would be interested in your opinion.
Most of these are good guidelines. The second (header guards) could be replaced by using "#pragma once" if it is supported on all target compilers. This avoids the hassle of having to come up with unique identifiers for each header.
The first guideline ("Each module with its .h and .c file should correspond to a clear piece of functionality.") can be interpreted quite differently depending on the programming paradigm being followed. In this sense, it is important to realize that there is no "C/C++" language. C and C++ are different languages with different rules and guidelines. In C++, when predominantly using an OOP style, this guideline can often be interpreted as "one struct/class definition per header file (not counting nested structs/classes)". In C obviously, global functions are needed and often a more functional/procedural programming style is followed, thus one would group sets of related functions in header files.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
I have been thinking about the differences that result from as you mentioned C++ which is OOP and C which is function based. In C++ it makes good sense to hide internal structures and procedures and only expose the public methods of the class because the "class" encapsulates not only the code but the data.
In C it's a bit different as long as you are not writing a LIB or DLL, in which you only expose the public functions. But in a C project, one for internal use rather than public, you tend to have unrestricted access to all functions and data. For an embedded project this can greatly speed up the code as you are not restricted to a class I/O function. I am probably not expressing this as fully as I would like nor as accurately but I hope you can discern my meaning.
I have been thinking about the differences that result from as you mentioned C++ which is OOP and C which is function based. In C++ it makes good sense to hide internal structures and procedures and only expose the public methods of the class because the "class" encapsulates not only the code but the data.
C++ is not just object oriented; it's multi-paradigm. Procedural and generic programming is also fully supported by C++. There are many C++ libraries that are header-only, notably the Boost libraries. When you make heavy use of templates, the guidelines for header use change. That's why I said the interpretation depends on the programming paradigm being used, rather than the programming language being used.
Originally Posted by moffy
In C it's a bit different as long as you are not writing a LIB or DLL, in which you only expose the public functions. But in a C project, one for internal use rather than public, you tend to have unrestricted access to all functions and data. For an embedded project this can greatly speed up the code as you are not restricted to a class I/O function. I am probably not expressing this as fully as I would like nor as accurately but I hope you can discern my meaning.
In C, it is also possible to emulate the use of public/private functions by hiding a struct definition from the header file.
Code:
// header file
struct Example;
Example* CreateExample(int a); // emulate c'tor
void ReleaseExample(Example* pThis); // emulate d'tor
int ExampleFoo(Example* pThis, int b); // emulate member function
// .c file
struct Example
{
int a;
};
Example* CreateExample(int a)
{
Example* p = (Example*)malloc(sizeof(Example));
p->a = a;
return p;
}
// etc.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
In C it's a bit different as long as you are not writing a LIB or DLL, in which you only expose the public functions. But in a C project, one for internal use rather than public, you tend to have unrestricted access to all functions and data.
I would dare to disagree. It highly depends on the way how you design data types and interfaces. Please consider the plain C sample (monolithic, not a LIB or DLL) attached.
Thank you for your advice.
1.D_ Drmmr: I have been doing something similar in C to the constructor/destructor you illustrated. Very handy when it comes to cleaning up memory structures. If you change the structure you only need to modify 2 places. Only need to debug 2 pieces of code, very handy.
2. Igor thank you for the example. I am aware that whatever you can do in C++ you can do in C, I guess the C++ compiler was originally written in C. It's more a matter of style rather than potential I was referring to. But point taken and thanks again.
Thank you for all your advice. I am in the middle of a rewrite and have found the rules listed in post#2 valuable. I pretty much have to agree with them all. I especially like the forward declaration e.g. "struct blog_t;" and then using pointers e.g. blog_t *, to access it. Nice.
I have one further question. What do you do with your general macros like MAX(a,b), MIN(a,b). My inclination is to create a single macro.h file and include that.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.