Advice on structured header use
Hello,
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.:confused:
Re: Advice on structured header use
Re: Advice on structured header use
Looks fine, though what the author calls "structure type declarations" are actually structure definitions (which admittedly are also declarations).
Also, in the case of C++, the use of an unnamed namespace is preferred to declaring helper functions static.
Re: Advice on structured header use
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.
Re: Advice on structured header use
Quote:
Originally Posted by
moffy
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.
Re: Advice on structured header use
Thank you D_Drmmr for your advice.
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.
Just a thought.
Re: Advice on structured header use
Quote:
Originally Posted by
moffy
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.
Quote:
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.
1 Attachment(s)
Re: Advice on structured header use
Quote:
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.
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.
Re: Advice on structured header use
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.
Re: Advice on structured header use
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.