Initial commit

Author: goldsborough

`auto`-type-deduction.md

@@ -0,0 +1,93 @@
+# `auto`-type-deduction
+
+The type deduction rules for auto are largely the same as for templates.
+In an expression like this:
+
+const auto x = 5;
+
+auto takes the role of T in template type deduction and the _type
+specifier_ (const auto) takes the role of the parameter type Type.
+
+Thus all these cases will be the same as for template type deduction:
+
+    auto x = 5; // auto deduces to int
+
+    const auto& rx = x; // auto deduces to int, the specifier to const int&
+
+    auto&& urx1 = x; // auto deduces to int&, the specifier too
+
+    auto&& urx2 = 27; // auto decues to int, the specifier to int&&
+
+    auto* px = &x; // auto deduces to int, the specifier to int*
+
+    int arr [2] = {1, 2};
+
+    auto a = arr; // auto deduces to int* (array decays)
+
+    auto& ra = arr; // auto deduces to int (&) [2]
+
+    void f(int, std::string);
+
+    auto g = f; // auto deduces to void (*) (int, std::string)
+
+    auto& g = f; // auto deduces to void (&) (int, std::string)
+
+There is __one__ important difference, regarding initializer-lists:
+template-type deduction for a brace-initialized sequence fails, while
+auto will deduce it as an std::initializer_list<T> after T has been
+deduced from the elements in the list (if possible, i.e. if all elements
+in the list have a single type, else fails too). Examples:
+
+    auto a = 5;     // auto -> int
+    auto b(5);      // auto -> int
+    auto c = {5};   // auto -> std::initializer_list<int>
+    auto d{5};      // auto -> std::initializer_list<int> or int -- CAREFUL!
+    auto e = {5, 1.0};   // fails (not only one type)
+
+Special care must be taken for d. As of now, this does initialize an
+std::initializer_list. To ensure uniform initialization capabilities,
+however, this will _very soon_ change to initialize an integer and many
+compilers already implement it while others warn about it. So if you
+want to store an initializer list in an auto variable, use = {...} and
+not {...}.
+
+Why does auto differ from template type deduction for initializer lists?
+Because template type deduction never implicitly converts anything.
+Consider this case:
+
+    template<typename T>
+    void assign(T& target, const T& source);
+
+    std::vector<int> v;
+
+    assign(v, {1, 2, 3});
+
+In this case, were {1, 2, 3} automatically deduces to be
+std::initializer_list<int>, this method call would fail because the
+types for T would differ. Without this automatic deduction (currently in
+place), T is deduces to be std::vector<int> and {1, 2, 3} initializes
+the source vector correctly.
+
+The fact that auto automatically deduces a brace-list as an
+std::initializer_list is a polarizing topic and there exist proposals
+also to ban it.
+
+A last note about auto in lambdas or return types: there, template type
+deduction rules apply and not auto type deduction rules:
+
+    template<typename Function>
+    void f(Function function)
+    {
+        // Fails, template type deduction does not automatically
+        // deduce this as std::initializer_list
+        function({1, 2, 3});    
+    }
+
+    auto g()
+    {
+        // Also fails for same reasons as above.
+        return {1, 2, 3};
+    }
+
+    // Initializes a valid std::initializer_list
+    auto list = {1, 2, 3};

`decltype`-deduction-rules.md

@@ -0,0 +1,63 @@
+# `decltype`-deduction-rules
+
+The great thing about decltype is that it (almost) does not have any
+fancy rules regarding what types it deduces (returns). In 99% of all
+cases, the type you get from decltype(x) is the type with which you
+declared x:
+
+    // decltype(i) = const int
+    const int i = 0;
+
+    // decltype(object) = const T&
+    // decltype(f) = bool(const T&)
+    tempalte<typename T>
+    bool f(const T& object);
+
+    // decltype(obj) = Object
+    Object obj;
+
+    f(obj); // decltype(f(obj)) = bool
+
+    template<typename T>
+    class Foo
+    {
+        /* ... */
+    };
+
+    // decltype(foo) = Foo<int>
+    Foo<int> foo;
+
+Known corner case: decltype(object.member)
+
+Normally, accessing an object's member either using dot-notation
+(object.member) or using arrow-notation with pointers (object->member)
+yields a reference to the member, i.e. if the member is an int the type
+of object.member will be int&. However, this expectation does not
+reflect in the result of a call to decltype for this scenario:
+
+    Object object;
+
+    decltype(object.member); // yields type of member, not type&
+
+    decltype((&object)->member); // also type&
+
+The solution introduces the second peculiarity for decltype(), that
+decltype(x) can differ from decltype((x)). More specifically, in all
+cases but the above, calling decltype with a name prodcuces the type of
+that name, while wrapping that name in parantheses gives you an
+_expression_. An expression is more complicated than a name and _almost
+always_ produces a reference to the type of the name:
+
+    int x = 5;
+
+    decltype(x); // int
+
+    decltype((x)); // int&
+
+This solves the problem for above (member access):
+
+    Object object;
+
+    decltype(object.member); // type
+
+    decltype((object.member)) // type&

abort()-and-exit().md

@@ -0,0 +1,34 @@
+# abort()-and-exit()
+
+There are two standard ways to terminate a program: std::abort() and
+std::exit()
+
+std::abort() stops the program at this point and does not call any
+destructors of any object, it literally halts the program at that point
+in time, with not a single line of code executed further. Moreover,
+std::abort() sends a SIGABRT signal.
+
+std::exit(int) also does not call destructors on automatic objects /
+temporary objects, that are destructed when they go out of scope, but
+does destruct static and globally scoped data. Moreover, you can
+register a specific function / handler that is called when std::exit is
+called. This function is set via std::atexit:
+
+// Allocate some memory
+int* p = new int(5);
+// Will be called upon std::exit() call
+void foo()
+ {
+     std::cout << "foo called" << std::endl;
+    
+     delete p;
+ }
+int main(int argc, char * argv [])
+ {
+     // Register the exit handler
+     std::atexit(foo);
+    
+     // another code for std::exit(int) is EXIT_FAILURE
+     std::exit(EXIT_SUCCESS);
+
+}

abstract-classes-without-pure-virtual-methods.md

@@ -0,0 +1,25 @@
+# abstract-classes-without-pure-virtual-methods
+
+If you want a class without pure virtual functions to be solely an
+abstract class, make the destructor pure virtual:
+
+class Base
+
+{
+
+public:
+
+     void do(){ }
+
+     virtual ~Base() = 0;
+
+};
+
+I.e.: you want a base class for inheritance/polymorphism but don't want
+the base class to be instantiateable. 
+
+That way, giving it a pure virtual function makes it an abstract class.
+However, you must implement that destructor somewhere, as the compiler
+will call it when a derived class’ destructor is called. 
+
+

accessing-the-global-scope.md

@@ -0,0 +1,4 @@
+# accessing-the-global-scope
+
+use ::member to access global members
+

algorithms-that-expect-sorted-ranges.md

@@ -0,0 +1,31 @@
+# algorithms-that-expect-sorted-ranges
+
+BINARY_SEARCH (true false if element in sequence, using bs)
+
+EQUAL_RANGE (returns two iterators denoting start and end of a range of
+equal elements)
+
+UPPER_BOUND (returns first element not greater, i.e. equal or less)
+
+LOWER_BOUND (return first element not less, i.e. equal or greater)
+
+SET_UNION (copies to a destination all elements contained in one or both
+ranges, for two ranges)
+
+SET_DIFFERENCE (copies to a destination all elements from one range
+which are not contained in another range)
+
+SET_INTERSECTION (copies to a destination all elements contained in both
+ranges)
+
+SET_SYMMETRIC_DIFFERENCE (copies to a destination all elements contained
+in one or the other range (XOR))
+
+MERGE (one pass of the mergesort algorithm)
+
+INPLACE_MERGE (one pass of the inplace-mergesort algorithm)
+
+INCLUDES (whether or not all elements from one range are also included
+in another range)
+
+UNIQUE (removes all duplicates of any value)

alignof.md

@@ -0,0 +1,8 @@
+# alignof
+
+To get the alignment requirements of a type use the alignof keyword or
+std::alignment_of<Type>::value.
+
+std::alignment_of<Base>::value == alignof(Base);
+
+

allocators.md

@@ -0,0 +1,74 @@
+# allocators
+
+Allocators are special template classes used by the standard containers
+to allocate and deallocate memory. If you want to define your own,
+follow this advice:
+
+-   Make your allocator a template, with the template parameter T
+    representing the type of objects for which you are
+    allocating memory.
+-   Provide the internal typedefs ‘pointer' and ‘reference’, but always
+    have ‘pointer’ be T* and ‘reference’ be T&.
+-   Never give your allocators 'per-object state’, i.e. do not let them
+    have non-static data (all allocators of one type should be
+    the same).
+-   Provide a nested re-bind template struct to make it possible to use
+    the same allocator but for a different type.
+
+The last point refers to the fact that all node-based (associative)
+containers in the standard do not use the allocator you pass to it (e.g.
+Allocator<int> for list<int>) but actually need to use the same
+allocator type, but for its private ‘node’ types (that hold the ’next’
+and ‘previous’ pointers for a linked list). I.e.:
+
+template<typename T>
+struct Custom_Allocator
+ {
+typedef T value_type;
+typedef T* pointer;
+typedef T& reference;
+ T* allocate(std::size_t numberOfObjects);
+void deallocate(T* ptr, std::size_t numberOfObjects);
+// There is no such thing as a templated
+// typedef or using declaration, so you
+// provide this nested struct that is
+// itself templated and that just provides
+// the typedef to have access to the allocator
+// class but for a different type. If there
+// were no rebind struct there would be no way
+// to access the un-templated type of an allocator
+// passed to a container or so, since an instance
+// of a template class for a certain type is entirely
+// unaware that it is an instance of a template class
+// (since it is simply an instance of the statically,
+// compiler-generated version of the class for type T)
+template<typename U>
+struct rebind
+ {
+typedef Custom_Allocator<U> other;
+ };
+ };
+template<typename Alloc>
+void foo(const Alloc& allocator)
+ {
+// Alloc has no idea that it is actually of
+// type Custom_Allocator<T>
+typename Alloc::template rebind<std::string>::other
+allocator_for_string;
+// bla
+ }
+int main(int argc, char * argv[])
+ {
+Custom_Allocator<int> allocator_for_int;
+foo(allocator_for_int);
+
+}
+
+Note also the differences in signature between ‘operator new’ and
+the ‘allocate’ method of the Allocator:
+
+void* operator new(std::size_t numberOfBytes);
+
+T* Allocator<T>::allocate(std::size_t numberOfObjects);
+
+

always-have-comparison-functions-return-false-for-equal-values.md

@@ -0,0 +1,45 @@
+# always-have-comparison-functions-return-false-for-equal-values
+
+Associative containers work with equivalence, i.e. you pass them one
+comparison function for a < b and it then determines whether two values
+are _equivalent_ (similar to equal) by testing if !(a < b) && !(b < a).
+It does so more precisely by using the function you pass as a predicate,
+i.e. ! pred(a, b) && ! pred(b, a). This predicate MUST RETURN FALSE FOR
+EQUAL VALUES. Else you corrupt the container. The reason why is that
+when you insert a value into an associative container, it needs to check
+if the value already exists:
+
+std::set<int> set{1};
+ set.insert(1);
+
+print(set.size()); // 1
+
+If you now were to pass a predicate that returns true for equal values,
+the set would go ahead and test if:
+
+!(a<=b) && !(b<=a)
+
+if now a and be are equal, this yields:
+
+!true && !true
+
+which is
+
+false && false
+
+which ultimately evaluates to false. In explanation, this means that if
+you try to insert a value into a set that already exists in that set,
+the set would determine that the value is not yet present (because the
+equivalence check failed for all values) and thus insert it again,
+making the set not a set but something ugly.
+
+int main(int argc, char * argv[])
+ {
+auto predicate = [&] (int a, int b) { return a <= b; };
+std::set<int, decltype(predicate)> set({1}, predicate);
+ set.insert(1);
+print(set.size()); // 2
+
+}
+
+Therefore don’t ever do it!