Why not over-parameterize in C++
This article mainly introduces "Why not over-parameterization in C++". In daily operation, I believe many people have doubts about why not over-parameterization in C++. The editor consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubt of "Why not over-parameterization in C++"! Next, please follow the editor to study!
T.61: do not over-parameterize members (SCARY)
Reason (reason)
A member that does not depend on a template parameter cannot be used except for a specific template argument. This limits use and typically increases code size.
Members that do not depend on template parameters cannot be used, except for specific template parameters. This limits usage and usually increases the size of the code.
Example, bad (negative example)
Template
/ / requires Regular & & Allocator
Class List {
Public:
Struct Link {/ / does not depend on A
T elem
T * pre
T * suc
}
Using iterator = Link*
Iterator first () const {return head;}
/ /...
Private:
Link* head
}
List lst1
List lst2
This looks innocent enough, but now Link formally depends on the allocator (even though it doesn't use the allocator). This forces redundant instantiations that can be surprisingly costly in some real-world scenarios. Typically, the solution is to make what would have been a nested class non-local, with its own minimal set of template parameters.
The code looks correct enough, but now Link formally depends on the allocator (even if it doesn't use the allocator). This can lead to redundant illustrations, which can be surprisingly costly in some real-world processes. The usual solution is to make the original nested category non-local, while its members have only the least number of template parameters.
Template
Struct Link {
T elem
T * pre
T * suc
}
Template
/ / requires Regular & & Allocator
Class List2 {
Public:
Using iterator = Link*
Iterator first () const {return head;}
/ /...
Private:
Link* head
}
List lst1
List lst2
Some people found the idea that the Link no longer was hidden inside the list scary, so we named the technique SCARY. From that academic paper: "The acronym SCARY describes assignments and initializations that are Seemingly erroneous (appearing Constrained by conflicting generic parameters), but Actually work with the Right implementation (unconstrained bY the conflict due to minimized dependencies)."
Some people will find that Link is no longer hidden by list, so we call this technology SCARY. According to the university paper: "the abbreviation SCARY describes the assignment and initialization of some seemingly incorrect (seemingly conflicting parameter constraints) but actually works with the correct implementation (which is not limited by conflicts due to minimized dependencies)."
Enforcement (implementation recommendations)
Flag member types that do not depend on every template argument
Tags do not depend on members of any template parameters
Flag member functions that do not depend on every template argument
Marks the member function of a member that does not depend on any template parameters.
At this point, the study of "Why not over-parameterization in C++" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!
