![\"serial](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/04\/serial-160834_1280.png\")
<\/p>\nThe organization of source files is a topic quite seldom addressed in C++. With C++20, we will get modules, but until then, we should distinguish between our code’s implementation and interface.<\/p>\n
<\/p>\n
<\/p>\n
The C++ Core Guidelines make their point to source files quite clear: “Distinguish between declarations (used as interfaces) and definitions (used as implementations). Use header files to represent interfaces and to emphasize logical structure.” Consequently, there are more than ten rules to source files. The first eleven rules deal with interface files (*.h<\/span>-files)<\/span> and implementation files (*.cpp-<\/span>files), and the last three with namespaces.<\/p>\n Let me start with the rules for the interface and implementation files. Here are the first seven:<\/p>\n I will not write about each rule in full depth, but I want to make a readable story out of the first rules by just quoting the rule.<\/p>\n Okay, SF.1: Use a Of course, I often saw other conventions for header and implementation files. Here are a few I have in mind:<\/p>\n I assume you know various other conventions.<\/p>\n If your header file contains an object definition or a definition of a non-inline function, your linker may complain. This is the reason for the second rule SF.2: A ODR stands for the One Definition Rule and says in the case of a function.<\/p>\n In modern compilers, the keyword inline<\/span> is not about inlining functions anymore. Modern compilers almost wholly ignore it. The more or less use-case for inline<\/span> is to mark functions for ODR correctness. In my opinion, the name inline<\/span> is nowadays quite misleading. <\/p>\n Let me see what my linker says when I try to link a program breaking the one-definition rule. The following code example has one header file header.h and two implementation files. The implementations file includes the header files and breaks the one definition rule because of two definitions of func<\/span> exit.<\/p>\n <\/p>\n <\/p>\n <\/p>\n The linker complains about the multiple definitions of func<\/span>:<\/p>\n The following two rules are evident from the readability and maintainability point of view: SF.3: Use Rule 5 is more interesting: SF.5: A Assume I had a bad day. I defined a function func<\/span> that gets an int<\/span> and returns an int.<\/span><\/p>\n <\/p>\n <\/p>\n My mistake was that I declared this function in the header file impl.h<\/span> getting an int<\/span> but returning a std::string<\/span>.<\/p>\n <\/p>\n <\/p>\n I include the header in the main<\/span> program because I want to use this function there.<\/p>\n <\/p>\n <\/p>\n\n
.cpp<\/code> suffix for code files and .h<\/code> for interface files if your project doesn\u2019t already follow another convention<\/a><\/li>\n.h<\/code> file may not contain object definitions or non-inline function definitions<\/a><\/li>\n.h<\/code> files for all declarations used in multiple source files<\/a><\/li>\n.h<\/code> files before other declarations in a file<\/a><\/li>\n.cpp<\/code> file must include the .h<\/code> file(s) that defines its interface<\/a><\/li>\nusing namespace<\/code> directives for transition, for foundation libraries (such as std<\/code>), or within a local scope (only)<\/a><\/li>\nusing namespace<\/code> at global scope in a header file<\/a><\/li>\n<\/ul>\n.cpp<\/code> suffix for code files and .h<\/code> for interface files if your project doesn\u2019t already follow another convention <\/a>about consistency. When you have a C++ project, header files should be called *.h<\/span> and implementation files *.cpp. <\/span>Convention beats this rule if you already have another policy in our project. <\/p>\n\n
\n
\n
.h<\/code> file may not contain object definitions or non-inline function definitions. <\/a>To be more specific, we have the One Definition Rule in C++:<\/p>\n<\/p>\nODR<\/h3>\n
\n
\n\/\/ header.h<\/span>\r\n\r\nvoid<\/span> func<\/span>(){}\r\n<\/pre>\n<\/div>\n\n\/\/ impl.cpp<\/span>\r\n\r\n#include \"header.h\"<\/span>\r\n<\/pre>\n<\/div>\n\n\/\/ main.cpp<\/span>\r\n\r\n#include \"header.h\"<\/span>\r\n\r\nint<\/span> main<\/span>(){}\r\n<\/pre>\n<\/div>\n![\"odr\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/04\/odr.png\")
<\/p>\n.h<\/code> files for all declarations used in multiple source files<\/a> and SF.4: Include .h<\/code> files before other declarations in a file.<\/a><\/p>\n.cpp<\/code> file must include the .h<\/code> file(s) that defines its interface<\/a>. The interesting question is: What would happen if you don’t include the *.h<\/span> file in the *.cpp file and there is a mismatch between the interface file *.h<\/span> and the implementation file *.cpp<\/span>?.<\/p>\n\n\/\/ impl.cpp<\/span>\r\n\r\n\/\/ #include \"impl.h\" <\/span>\r\n\r\nint<\/span> func<\/span>(int<\/span>){\r\n return<\/span> 5<\/span>;\r\n}\r\n<\/pre>\n<\/div>\n\n\/\/ impl.h<\/span>\r\n\r\n#include <string><\/span>\r\n\r\nstd::<\/span>string func(int<\/span>);\r\n<\/pre>\n<\/div>\n\n\/\/ main.cpp<\/span>\r\n\r\n#include \"impl.h\"<\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n auto<\/span> res =<\/span> func(5<\/span>);\r\n \r\n}\r\n<\/pre>\n<\/div>\n
![\"linker\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/04\/linker.png\")
<\/p>\n![\"compiler\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2019\/04\/compiler.png\")
<\/p>\n