In the previous article Breaking the Access Control Mechanism of C++ Classes, we briefly mentioned that the member access control of C++ classes (public/protected/private) only limits the accessibility of member names, rather than their visibility. This article mainly analyzes the consequences of this property and how to avoid them.
It is well known that class members in C++ can have three access specifiers: public, protected, and private:
[ISO/IEC 14882:2014] A member of a class can be
From the standard’s intention, it aims to hide implementation details and underlying data of a class, which is encapsulation. However, we can also bypass access restrictions through some special means.
Separate an article; previously scattered book reviews were scattered in notes and tweets, and not collected in one place, making indexing inconvenient. In the future, after reading technical books, I will write some comments and put them all here. Since the subjects of the reviews are technical books, mere phrases cannot describe all the technical details. The intent of this article is not “technical notes,” but rather “book reviews,” so I won’t delve too deeply into the technical details described in the books. Instead, I will share my own reading experiences and tips as an ordinary reader. If I express any opinions about certain books, they are my personal evaluations of the books with no intention of demeaning the authors.
In C++ programming, one of the most frustrating things is that the compiler does too much behind the backs of programmers. This article compiles various situations and actual behaviors of six special member functions: default constructor, copy/move constructor, copy/move assignment operator, and destructor, as outlined in the C++ Standard ([ISO/IEC 14882:2014]). It can serve as supplementary material for “Inside The C++ Object Model,” enhancing the understanding of compiler implementations through standard descriptions.
Additionally, “Inside The C++ Object Model” mainly describes things from the perspective of “compiler implementation,” but from the “C++ standard” perspective, many things in the book are dependent on compiler implementation. For example, the virtual function table; the standard does not specify how the compiler should implement polymorphic behavior, thus it cannot describe details about the virtual function table.
Moreover, many ambiguous interpretations related to the behavior of “compiler-generated” can be addressed here, which is part of the joy of reading the C++ standard—regardless of whether it’s good or bad, the standard specifications cannot be wrong; all implementations that do not adhere to the standard descriptions are unstandard.
Unlike class templates, which can have explicit specializations and partial specializations, function templates do not have the concept of “partial specializations”; they only have explicit specializations and overloads.
“Pointers to members” is a feature in C++ that is not commonly used. However, the use of the term “pointer” is somewhat inaccurate here, as they do not contain an address, and their behavior is not like pointers. This article will analyze how “pointers to class members” are implemented in clang through LLVM-IR, alongside some definitions from the C++14 standard and related LLVM-IR syntax.
In the previous article (C/C++ Compilation Model Analysis), the reasons and methods for compilation and linking in C and C++ were introduced. Following the issues discussed in the previous article, this article starts with extern "C" to analyze the differences and causes in the compilation and linking models of C and C++, focusing primarily on function overload, function signatures, and name mangling.
C and C++ both use separate compilation to support a multi-source file modular mechanism, but why this is done and how it is achieved is a topic worth exploring. This article is not about the syntactic rules that create different linking in C and C++, but rather analyzes how C/C++ compilers implement the compilation and linking model.
I looked at the usage of Array of length zero in C, and I feel quite inspired. However, from a standard perspective (as opposed to compiler extensions), this feature only exists in the C language (after C99) and does not exist in C++. Let’s dig into it.
Consider this question: Is it possible to pass the address of an object from process A to process B (where there is no relationship between A and B) through a pipe (fifo), and thus access the object of process A from process B?