OpenLLM-France/wikimedia huggingface dataset:
# Barton-Nackman trick
### Intent

Support overloaded operators without relying on namespaces or function template overload resolution.

### Also Known As

The inventors originally referred to it as Restricted Template Expansion, though this term has never been widely used.

### Motivation

John Barton and Lee Nackman first published this idiom in 1994 in order to work around limitations of the C++ implementations available at the time. Though it is no longer necessary for its original purpose, the current standard retains support for it.
At the time Barton and Nackman originally developed the idiom, C++ did not support overloading of function templates and many implementations still didn't support namespaces. This caused problems when defining operator overloads for class templates. Consider the following class:
The most natural way to define the equality operator is as a non-member function at namespace scope (and since compilers at the time didn't support namespaces, therefore at global scope). Defining operator== as a non-member function means that the two arguments are treated symmetrically, which doesn't happen if one argument is a this pointer to the object. Such an equality operator might look like this:
However, since function templates couldn't be overloaded at the time, and since putting the function in its own namespace wouldn't work on all platforms, this would mean that only one class could have such an equality operator. Doing the same thing for a second type would cause an ambiguity.

### Solution and Sample Code

The solution works by defining an operator in the class as a friend function:
Instantiating the template now causes a non-template function to be injected into global scope with the argument types being concrete, fixed types. This non-template function can be selected through function overload resolution the same way as any other non-template function.
The implementation can be generalised by providing the friend functions as part of a base class that is inherited from via the Curiously Recurring Template Pattern:

### Known Uses

* Boost.Operators library

### Related Idioms

* Curiously Recurring Template Pattern

### See also

* Barton-Nackman trick on Wikipedia.

### References

* ↑ Barton, John J.; Nackman, Lee R. (1994). Scientific and Engineering C++: An Introduction with Advanced Techniques and Examples. Addison-Wesley. ISBN 0-201-53393-6.
# Address Of
### Intent

Find the address of an object of a class that has an overloaded unary ampersand (&) operator.

### Also Known As

This idiom has no known alias.

### Motivation

C++ allows overloading of the unary ampersand (&) operator for class types. The return type of such an operator need not be the actual address of the object. Intentions of such a class are highly debatable, but the language allows it nevertheless. The address-of idiom is a way to find the real address of an object irrespective of the overloaded unary ampersand operator and its access protection.
In the example below, the main function fails to compile because the operator & of the class nonaddressable is private. Even if it were accessible, a conversion from its return type double to a pointer would not have been possible or meaningful.

### Solution and Sample Code

The Address-of idiom retrieves the address of an object using a series of casts.

#### C++11

In C++11 the template std::addressof, in the <memory> header, was added to solve this problem. Since C++17 the template is also marked constexpr.

### Known Uses

* Boost's addressof utility.

### References

* ↑ "The template std::addressof".
* ↑ "Boost addressof utility".
# Base-from-Member
### Intent

To initialize a base class from a data-member of the derived class.

### Motivation

In C++, base classes are initialized before any member of the derived class. The reason for this is that members of a derived class may use the base part of the object. Therefore, all the base parts (i.e., all base classes) must be initialized before members of the derived class. Sometimes, however, it becomes necessary to initialize a base class from a data member that is available only in the derived class. It sounds contradictory to the rules of C++ language because the parameter (a member of derived class) that is passed to the base class constructor must be fully initialized. This creates a circular initialization problem (an infinite regress).
The following code, obtained from the Boost libraries, shows the problem.
The above code snippet shows a case where the programmer is interested in customizing the std::streambuf class. They do so in fdoutbuf by inheriting from std::streambuf. The fdoutbuf class is used as a member in fdostream class, which is a kind of std::ostream. The std::ostream class, however, needs a pointer to a std::streambuf class, or its derived class. The type of pointer to buf is suitable but passing it makes sense only if buf is initialized. However, it won’t be initialized unless all base classes are initialized. Hence the infinite regress. The base-from-member idiom addresses this problem.

### Solution and Sample Code

This idiom makes use of the fact that base classes are initialized in the order they are declared. The derived class controls the order of its base classes, and in turn, controls the order in which they are initialized. In this idiom, a new class is added just to initialize the member in the derived class that is causing the problem. This new class is introduced in the base-class-list before all other base classes. Because the new class comes before the base class that needs the fully constructed parameter, it is initialized first and then the reference can be passed as usual. Here is the solution using base-from-member idiom.
The fdostream_pbase class is the newly introduced class that now has the sbuffer member. The fdostream class inherits from this new class and adds it before std::ostream in its base class list. This ensures that sbuffer is initialized before std::ostream and the pointer can be safely passed to it's constructor.

### Known Uses

* Boost Base from Member

### References

* ↑ "Boost Utility".
# Comoros

* Previously administered as part of the French territory of Madagascar, in 1947 Comoros became a separate French territory that included the island of Mayotte. In 1975 the Comoros Islands, less Mayotte, gained independence and became the Islamic Federal Republic of the Comoros. Although the United Nations in 1979 declared Mayotte to be under Comoros sovereignty, in all practical terms the island remains a French territory and is cataloged separately under MAYOTTE.
* The earliest meter seen with “COMOROS” in the frank is from 1972.
* The stamps are divided into two groups based on the political status:
       A - French territory
       B - Islamic Federal Republic

## GROUP A: Issues of French territorial period. Frank inscribed “TERRITOIRE DES COMORES or COMORES”

A1. Satas “J” (MV), 1972. [$25]
    Small upright frank with simulated-perforation border.
    Inscribed “TERRITOIRE/ DES COMORES” at top, "POSTES" above meter number at bottom.
    M# with “SJ” prefix.
    Date figures tall.
    TM: SC
    V/F: 00
A2. Satas “P” (MV). [$7.50]
    Similar to Type A1 but inscribed “COMORES” alone at top.
    Hour figure between TM and frank.
    M# with “SP” prefix.
    Date figures tall.
    TM: SC
    V/F: 000
                                                    a. Used in Mayotte (SP 912 and 913) [$20]

## GROUP B: Issues of the Federal Islamic Republic.

B1. Neopost “Electronic” (MV). [$10]
    Upright frank inscribed "R.F.I. COMORES" at top.
    “POSTES” straight at bottom.
    Without M#.
                                                    A. Without M#
                                                    B. With M#, with “SG” prefix
                                                 TM: SC
                                                 V/F: ≋000
B2. Neopost “Electronic” (MV), 2004.
    Horizontal frank inscribed "UNION DES COMORES" at bottom.
    Profile of fish at top and "Le Coelacanthe" above country name at bottom.
    Without M#
    TM: SC
    V/F: 0000
# Christmas Island

Only two meters are known to have been used with Christmas Island identification. Both are quite rare.
1. Pitney Bowes-GB “6300” series (MV). [Extremely rare, value unknown]
    Australia Type EB1 with town mark: “CHRISTMAS ISLAND / 6798"
    Meter number: P.B. 632879
    Used by the Christmas Island Administration from 1986 to 1991.
    TM: SC
    V/F: 000
2. “Postal Services Unit” (MV). [Extremely rare, value unknown]
    Post Office stamp.
    Label with dotted line at top and bottom. Top line with 6-digit number at right.
    Sequence of inscriptions from top:
                                           “POSTAGE PAID”
                                           “CHRISTMAS ISLAND”
                                           “AUSTRALIA”
                                           value figures
                                           date, time, machine and transaction identification numbers
    V/F: $00.00
# Cocos Islands

Meter stamps from this adhesive-stamp issuing entity have not been reported.
# Non-copyable Mixin
### Intent

To prevent objects of a class from being copy-constructed or assigned to each other.

### Motivation

Many times it makes sense to prevent copying of objects of a class. For example, a class that encapsulates network connections. Copying can't be meaningfully defined for such classes. So it should be explicitly prevented without relying on guidelines or discipline on the programmer's part. The intent should also be easily identifiable just by looking at the declaration of a class to improve readability.

### Solution and Sample Code

A class called non-copyable is defined which has a private copy constructor and copy assignment operator.
CantCopy objects can't be copied because the copy constructor and copy assignment operators of the private base class NonCopyable are not accessible to the derived class. The traditional way to deal with these is to declare a private copy constructor and copy assignment, and then document why this is done. But deriving from noncopyable is simpler and clearer, and doesn't require additional documentation. private members of NonCopyable need not be defined. NonCopyable can also be categorized as a mixin-from-above because it defines a reusable module that "mixes-in" the feature of "non-copyability" into the derived class from "above". A CRTP based solution is given below. (This allows for Empty Base Optimization with multiple inheritance [see the Discussion page].)
Explicit copy-constructor
It is worthwhile to note that C++ allows one more way to control copy-construction. An explicit copy-constructor will prevent the compiler from calling a copy-constructor implicitly. I.e., passing an object by value and returning an object by value will be disabled for the class having an explicit copy-constructor. However, making explicit copies is allowed. On gcc, use -fno-elide-constructors option to disable copy-elision. This option is useful to observe (actually not observe!) the effects of Return Value Optimization. It is generally not recommended to disable this important optimization.

### Known Uses

boost::noncopyable

### Related Idioms

Curiously Recurring Template Pattern

### References

* ISO/IEC 14882:2003 C++ Standard §12.8/4, §12.8/7
# Nifty Counter
### Intent

Ensure a non-local static object is initialized before its first use and destroyed only after last use of the object.

### Also Known As

Schwarz Counter

### Motivation

When static objects use other static objects, the initialization problem becomes more complex. A static object must be initialized before its use if it has non-trivial initialization. Initialization order of static objects across compilation units is not well-defined. Multiple static objects, spread across multiple compilation units, might be using a single static object. Therefore, it must be initialized before use. One example is std::cout, which is typically used by a number of other static objects.

### Solution and Sample Code

The "nifty counter" or "Schwarz counter" idiom is an example of a reference counting idiom applied to the initialization of static objects.
The header file of the Stream class must be included before any member function can be called on the Stream object. An instance of the StreamInitializer class is included in each compilation unit. Any use of the Stream object follows the inclusion of the header, which ensures that the constructor of the initializer object is called before the Stream object is used.
The Stream class' header file declares a reference to the Stream object. In addition this reference is extern, meaning it is defined in one translation unit and accesses to it are resolved by the linker rather than the compiler. The implementation file for the Stream class finally defines the Stream object, but in an unusual way: it first defines a static (i.e. local to the translation unit) buffer. This buffer is both properly aligned and big enough to store an object of type Stream. The reference to the Stream object defined in the header is then set to point to this buffer. This buffer workaround enables fine-grained control of when the Stream object's constructor and destructor are called. In the example above, the constructor is called within the constructor of the first StreamInitializer object, using placement new to place it within the buffer. The Stream object's destructor is called when the last StreamInitializer object is destroyed.
This workaround is necessary because defining a Stream variable within Stream.cpp - be it static or not - would define it after the StreamInitializer, which is defined by including the header. Then, the StreamInitializer's constructor would run before theStream's constructor, and even worse, the initializer's destructor would run after the Stream object's destructor. The buffer solution above avoids this.

### Known Uses

Standard C++ <iostream> library std::cout, std::cin, std::cerr, std::clog.

### Related Idioms

* Reference Counting

### References

* http://www.petebecker.com/js/js199905.html
# Named Loop
### Intent

To partially simulate the labeled loop feature found in other languages.

### Also Known As

Labeled loop

### Motivation

Some languages, such as Java and Perl, support labeled looping constructs. In these languages, break and continue keywords can optionally specify a previously-defined loop label to control the flow of the program. A labeled break brings the control-flow out of the specified loop and similarly, a labeled continue starts with the next iteration. Labels allow breaking and continuing not just the innermost loop, but any outer loop that is labeled. Labeled break and continue can improve the readability and flexibility of complex code which uses nested loops. Named loop idiom in C++ provides partial support for this feature.

### Solution and Sample Code

The named loop idiom is implemented using gotos. Macros are used to hide the explicit use of gotos, which is often frowned upon. Only labeled break statements can be simulated using the following two parameterized macros.
The named(X) macro defines two goto labels X and X_skip. The break macro is a simple goto to the X_skip label. An example follows.
The gotos do not interfere with the proper construction and destruction of objects as confirmed by the output of the above program.
test::test::t1
test::test::t2
test::test::t3
test::test::t4
~test::t4
~test::t3
test::test::t3
~test::t3
~test::t2
~test::t1
# Multi-statement Macro
### Intent

To write a multi-statement (multi-line) macro.

### Motivation

Sometimes it is useful to group two or more statements into a macro and call them like a function call. Usually, an inline function should be the first preference but things such as debug macros are almost invariably macros rather than function calls. Grouping multiple statements into one macro in a naive way could lead to compilation errors, which are not obvious at first look. For example,
would fail in an if statement if a semi-colon is appended at the end.
The above statement expands to
giving a compiler error. Therefore, people came up with a widely used idiom for multi-statement macros, which is based on a do-while loop.

### Solution and Sample Code

Here is an example of the multi-statement macro idiom.
When the caller appends a semicolon, this expansion becomes a single statement regardless of the context. Optimizing compilers usually remove any dead tests, such as while(0). This idiom is not useful when macro is used as a parameter to a function call. Moreover, this idiom allows return statement.

### Known Uses

ACE_NEW_RETURN, ACE_NEW_NORETURN macros in Adaptive Communication Environment (ACE).

### References

* What's the best way to write a multi-statement macro?
# Named Constructor
### Intent

* To have a readable and intuitive way of creating objects of a class
* To impose certain constraints while creating objects of a class

### Motivation

In C++, constructors are distinguished from each other only based on the type, the order and the number of parameters. Of course when a class has multiple constructors, each constructor has a different purpose. However, in C++ it is hard to capture that "semantic" difference in the interface of the class because all the constructors have the same name and only parameters can distinguish between them. Reading code with lots of constructor calls only differing in the type/order/number of parameters is quite unintuitive except for the original developer of the class. Named constructor idiom addresses the problem.

### Solution and Sample Code

The named constructor idiom uses a set of static member functions with meaningful names to create objects instead of constructors. Constructors are either private or protected and clients have access only to the public static functions. The static functions are called "named constructors" as each unique way of creating an object has a different intuitive name. Consider the example below:
Without using the named constructor idiom in the class above, it is difficult to convey the meaning of what Game(1) and Game(0) means. The idiom makes it loud and clear! Additionally, it is possible to put certain constraints on the object creation process using this idiom. For example, named constructors could always create an object dynamically using new. In such a case, Resource Return idiom could be helpful.

### Related Idioms

Resource Return

### References

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.8
# Metafunction
### Intent

* To encapsulate a complex type computation algorithm
* To generate a type using compile-time type selection techniques

### Motivation

Templates are a powerful feature of C++, which can be used to perform arbitrary computations at compile-time, which is known as template metaprogramming. Some of the basic examples of the computations performed at compile-time are: (1) selection of a type based on compile-time constants or (2) computing factorial of a number. As a matter of fact, C++ templates is a turing complete sub-language of C++. Metafunction idiom is the principal way of writing compile-time algorithms in C++.
Algorithms -- compile-time or run-time -- should be encapsulated so that they are easier to use and reuse. Conventionally, run-time algorithms are encapsulated in functions that are invoked, obviously, at run-time. Metafunctions, on the other hand, are compile-time analogs of run-time functions. Traditional functions accept values/objects as parameters and return values/objects. However, metafunctions accept types and compile-time constants as parameters and return types/constants.

### Solution and Sample Code

A metafunction, contrary to its name, is a class template. Implementation of metafunctions is often based on template specializations. For example, consider the following IF metafunction, which is compile-time equivalent of run-time if statement. Depending upon the value of the first parameter, IF metafunction yields either an int or a long in the example below.
Factorial metafunction below is another example showing how a recursive factorial computation algorithm can be encapsulated using C++ templates. This metafunction yields an integral value rather than a type.
Metafunction and Type Generator
Metafunction is a more general idiom than the type generator idiom. The intent of the metafunction idiom is to encapsulate compile-time computation whereas, type generator simplifies specification of a type. Metafunctions that produce type(s) as a result of a compile-time computation are type generators, but not every metafunction is a type generator. For example, the Factorial metafunction shown before produces an integral value, not a type. Metafunctions are often implemented using compile-time control structures or other metafunctions.
Libraries such as Boost.MPL provide a large collection of metafunctions and compile-time data structures to simplify C++ template metaprogramming.
Higher order metafunctions
These are metafunctions that accept other metafunctions as parameters and use them during computation. This is conceptually similar to a function accepting a pointer to another function or a function object as a parameter at run-time. The only difference is that metafunctions exist only at compile-time. boost::mpl::transform is an example of such a higher order metafunction.

### Known Uses

Boost.MPL

### Related Idioms

* Type Generator

### References

A Deeper Look at Metafunctions -- David Abrahams and Aleksey Gurtovoy
# Named Parameter
### Intent

Simulate named (key-value pair) parameter passing style found in other languages instead of position-based parameters.

### Also Known As

Method chaining, Fluent interface

### Motivation

When a function takes many parameters, the programmer has to remember the types and the order in which to pass them. Also, default values can only be given to the last parameters, so it is not possible to specify one of the later parameters and use the default value for former ones. Named parameters let the programmer pass the parameters to a function in any order and they are distinguished by a name. So the programmer can explicitly pass all the needed parameters and default values without worrying about the order used in the function declaration.

### Solution and Sample Code

Named parameter idiom uses a proxy object for passing the parameters. The parameters of the function are captured as data members of the proxy class. The class exposes set methods for each parameter. The set methods return the *this object by reference so that other set methods can be chained together to set remaining parameters.

### Known Uses

* bgl_named_params template in the Boost Graph Library (BGL)
* boost::parameter

### Related Idioms

* Named Template Parameters

### References

* Named Parameter Idiom, Marshal Cline