![\"Lego](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/07\/Lego_dimensions.svg.png\")
<\/p>\nInterfaces are a contract between a service provider and a service consumer. The C++ Core Guidelines have 20 rules to make them suitable because “interfaces is probably the most important single aspect of code organization”.<\/p>\n
<\/p>\n
<\/p>\n
I wrote in my last post<\/a> <\/a>about the first ten rules. Today I will finish my job and write about the remaining ten rules.<\/p>\n Let’s dive directly into the details.<\/p>\n There is a conceptual issue with this code.<\/p>\n <\/p>\n Who deletes the pointer X? There are at least three alternatives to deal with the ownership problem:<\/p>\n What is the semantic difference between the three variations of the following function length<\/span>?<\/p>\n <\/p>\n The intention of variations two and three of length<\/span> is quite apparent. The second variation accepts only a non-null pointer; the third accepts a nullptr<\/span>. You may have already guessed it. not_null<\/span> if from the GSL.<\/p>\n Passing arrays as a single pointer is quite error-prone.<\/p>\n <\/p>\n What will happen if n<\/span> is too big? Right: undefined behavior. The GSL offers a solution called spans.<\/p>\n <\/p>\n Spans deduce their number of arguments.<\/p>\n<\/p>\n Global objects provide a lot of fun. For example, their initialization order is not defined if they are in different translation units. The following code snippet has undefined behavior.<\/p>\n There is a simple rule: one function should do exactly one job. If that is the case, the number of function arguments automatically becomes low, making the function easy to use.<\/p>\n The New Parallel Algorithms of Standard Template Library<\/a>, such as std::transform_reduce<\/a>, <\/span> often break this rule.<\/p>\n What are the source and the destination of the following copy_n<\/span> function? Any educated guess?<\/p>\n <\/p>\n I often have to look for documentation.<\/p>\n Of course, that is an evident and long-established rule for object-oriented design. The guidelines provide two reasons for this rule.<\/p>\n ABI stands for A<\/strong>pplication B<\/strong>inary I<\/strong>nterface.<\/p>\n This is a strange rule in C++ guidelines. The reason is that “Different compilers implement different binary layouts for classes, exception handling, function names, and other implementation details.”. On some platforms, common ABIs are emerging. Using a single compiler, you can stick to the full C++ interface. In this case, you have to recompile the code.<\/p>\n Pimpl stands for a pointer to implementation and is the C++ variation of the bridge pattern<\/a>. The idea is that a non-polymorphic interface holds the pointer to its implementation. Therefore, modification of the implementation doesn’t require recompilation of the interface.<\/p>\n Here is an example from the C++ Core Guidelines:<\/p>\n <\/p>\n The pimpl<\/span> is the pointer that holds the handle to the implementation.<\/p>\n For an in-depth discussion of this C++ idiom, read the GOTW #100<\/a> article by Herb Sutter. GotW stands f\u00fcr Guro of the Week.<\/p>\n Sometimes code is ugly, unsafe, or error-prone because of various reasons. Put the code in one place and encapsulate it with an easy-to-use interface. That is called abstraction, which you sometimes have to do. I have no problem with that code if the internal code is stable and the interface only lets you use it correctly.<\/p>\n\n
Expects()<\/code> for expressing preconditions<\/a><\/li>\nEnsures()<\/code> for expressing postconditions<\/a><\/li>\nT*<\/code>)<\/a><\/li>\nnot_null<\/code><\/a><\/li>\nI.11: Never transfer ownership by a raw pointer (T*)<\/strong><\/h4>\n
\nX*<\/span> compute<\/span>(args) \/\/ don't<\/span>\r\n{\r\n X*<\/span> res =<\/span> new<\/span> X{};\r\n \/\/ ...<\/span>\r\n return<\/span> res;\r\n}\r\n<\/pre>\n<\/div>\n\n
I.12: Declare a pointer that must not be null as not_null<\/strong><\/h4>\n
\nint<\/span> length<\/span>(const<\/span> char<\/span>*<\/span> p); \/\/ it is not clear whether length(nullptr) is valid<\/span>\r\n\r\nint<\/span> length<\/span>(not_null<<\/span>const<\/span> char<\/span>*><\/span> p); \/\/ better: we can assume that p cannot be nullptr<\/span>\r\n\r\nint<\/span> length<\/span>(const<\/span> char<\/span>*<\/span> p); \/\/ we must assume that p can be nullptr<\/span>\r\n<\/pre>\n<\/div>\nI.13: Do not pass an array as a single pointer<\/strong><\/h4>\n
\nvoid<\/span> copy_n<\/span>(const<\/span> T*<\/span> p, T*<\/span> q, int<\/span> n); \/\/ copy from [p:p+n) to [q:q+n)<\/span>\r\n<\/pre>\n<\/div>\n\nvoid<\/span> copy<\/span>(span<<\/span>const<\/span> T><\/span> r, span<<\/span>T><\/span> r2); \/\/ copy r to r2<\/span>\r\n<\/pre>\n<\/div>\nI.22: Avoid complex initialization of global objects<\/strong><\/h4>\n
\n\/\/ file1.c<\/span>\r\n\r\nextern<\/span> const<\/span> X x;\r\n\r\nconst<\/span> Y y =<\/span> f(x); \/\/ read x; write y<\/span>\r\n\r\n\/\/ file2.c<\/span>\r\n\r\nextern<\/span> const<\/span> Y y;\r\n\r\nconst<\/span> X x =<\/span> g(y); \/\/ read y; write x<\/span>\r\n<\/pre>\n<\/div>\nI.23: Keep the number of function arguments low<\/strong><\/h4>\n
I.24: Avoid adjacent unrelated parameters of the same type<\/strong><\/h4>\n
\nvoid<\/span> copy_n<\/span>(T*<\/span> p, T*<\/span> q, int<\/span> n); \r\n<\/pre>\n<\/div>\nI.25: Prefer abstract classes as interfaces to class hierarchies<\/strong><\/h4>\n
\n
I.26: If you want a cross-compiler ABI, use a C-style subset<\/strong><\/h4>\n
I.27: For stable library ABI, consider the Pimpl idiom<\/strong><\/h4>\n
\ninterface (widget.h)\r\nclass<\/span> widget<\/span> {\r\n class<\/span> impl<\/span>;\r\n std::<\/span>unique_ptr<<\/span>impl><\/span> pimpl;\r\npublic:<\/span>\r\n void<\/span> draw<\/span>(); \/\/ public API that will be forwarded to the implementation<\/span>\r\n widget(int<\/span>); \/\/ defined in the implementation file<\/span>\r\n ~<\/span>widget(); \/\/ defined in the implementation file, where impl is a complete type<\/span>\r\n widget(widget&&<\/span>) =<\/span> default<\/span>;\r\n widget(const<\/span> widget&<\/span>) =<\/span> delete<\/span>;\r\n widget&<\/span> operator<\/span>=<\/span>(widget&&<\/span>); \/\/ defined in the implementation file<\/span>\r\n widget&<\/span> operator<\/span>=<\/span>(const<\/span> widget&<\/span>) =<\/span> delete<\/span>;\r\n};\r\n\r\nimplementation (widget.cpp)\r\n\r\nclass<\/span> widget<\/span>::<\/span>impl {\r\n int<\/span> n; \/\/ private data<\/span>\r\npublic:<\/span>\r\n void<\/span> draw<\/span>(const<\/span> widget&<\/span> w) { \/* ... *\/<\/span> }\r\n impl(int<\/span> n) :<\/span> n(n) {}\r\n};\r\nvoid<\/span> widget::<\/span>draw() { pimpl-><\/span>draw(*<\/span>this<\/span>); }\r\nwidget::<\/span>widget(int<\/span> n) :<\/span> pimpl{std::<\/span>make_unique<<\/span>impl><\/span>(n)} {}\r\nwidget::~<\/span>widget() =<\/span> default<\/span>;\r\nwidget&<\/span> widget::<\/span>operator<\/span>=<\/span>(widget&&<\/span>) =<\/span> default<\/span>;\r\n<\/pre>\n<\/div>\nI.30: Encapsulate rule violations<\/strong><\/h4>\n
What’s next?<\/h2>\n