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?
The size of a container refers to the number of elements in the container; the capacity of a container refers to the number of elements that the container can hold before reallocating more memory. When resizing or changing capacity, the elements may move to new storage locations. This means that iterators (as well as pointers or references) pointing to the elements may become invalid (i.e., point to the old element locations).
Iterators pointing to elements of associative containers only become invalid when the pointed element is removed from the container (erased). In contrast, iterators pointing to elements of sequential containers may become invalid when memory is reallocated (resize()/reverse() or push_back()) or when the pointed element moves within the container (such as by performing an erase() or insert() at its previous position).
IR code is the Intermediate Code generated by LLVM. By analyzing the IR code, we can understand how the compiler parses and executes the code we write, making the analysis of code semantics clearer. The syntax and semantics of the IR code can be referenced in the LLVM Language Reference Manual.
In *UNIX, multi-process programming can be implemented using fork/vfork. Here is a summary of the relevant knowledge.
Some examples in C++ that can be confusing or have peculiar usages are recorded.