Effective C++ (55 Specific Ways)

1: View C++ as a federation of languages

• Rules for effective C++ programming vary, depending on the part of C++ ( (C, Object Oriented C++, Template C++, STL) you are using.

2: Prefer consts, enums, and inlines to #defines

• For simple constants, prefer const objects or enums to #defines.
• For function-like macros, prefer inline functions to #defines.

3: Use const whenever possible

• Declaring something const helps compilers detect usage errors. const can be applied to objects at any scope, to function parameters and return types, and to member functions as a whole.
• Compilers enforce bitwise constness, but you should program using conceptual constness.
• When const and non-const member functions have essentially identical implementations, code duplication can be avoided by having the non-const version call the const version.

4: Make sure that objects are initialized before they're used

• Manually initialize objects of built-in type, because C++ only sometimes initializes them itself.
• In a constructor, prefer use of the member initialization list to assignment inside the body of the constructor. List data members in the initialization list in the same order they're declared in the class.
• Avoid initialization order problems across translation units by replacing non-local static objects with local static objects.

5: Know what functions C++ silently writes and calls

• Compilers may implicitly generate a class's default constructor, copy constructor, copy assignment operator, and destructor.

6: Explicitly disallow the use of compiler-generated functions you do not want

• To disallow functionality automatically provided by compilers, declare the corresponding member functions private and give no implementations. Using a base class like Uncopyable is one way to do this.

7: Declare destructors virtual in polymorphic base classes

• Polymorphic base classes should declare virtual destructors. If a class has any virtual functions, it should have a virtual destructor.
• Classes not designed to be base classes or not designed to be used polymorphically should not declare virtual destructors.

8: Prevent exceptions from leaving destructors

• Destructors should never emit exceptions. If functions called in a destructor may throw, the destructor should catch any exceptions, then swallow them or terminate the program.
• If class clients need to be able to react to exceptions thrown during an operation, the class should provide a regular (i.e., non-destructor) function that performs the operation.

9: Never call virtual functions during construction or destruction

• Don't call virtual functions during construction or destruction, because such calls will never go to a more derived class than that of the currently executing constructor or destructor.

10: Have assignment operators return a reference to *this

• Have assignment operators return a reference to *this.

11: Handle assignment to self in operator=

• Make sure operator= is well-behaved when an object is assigned to itself. Techniques include comparing addresses of source and target objects, careful statement ordering, and copy-and-swap.
• Make sure that any function operating on more than one object behaves correctly if two or more of the objects are the same.

12: Copy all parts of an object

• Copying functions should be sure to copy all of an object's data members and all of its base class parts.
• Don't try to implement one of the copying functions in terms of the other. Instead, put common functionality in a third function that both call.

Item 13: Use objects to manage resources.

• To prevent resource leaks, use RAII objects that acquire resources in their constructors and release them in their destructors.
• Two commonly useful RAII classes are TR1::shared_ptr and auto_ptr. tr1::shared_ptr is usually the better choice, because its behavior when copied is intuitive. Copying an auto_ptr sets it to null.

Item 14: Think carefully about copying behavior in resource-managing classes.

• Copying an RAII object entails copying the resource it manages, so the copying behavior of the resource determines the copying behavior of the RAII object.
• Common RAII class copying behaviors are disallowing copying and performing reference counting, but other behaviors are possible.

Item 15: Provide access to raw resources in resource-managing classes.

• APIs often require access to raw resources, so each RAII class should offer a way to get at the resource it manages.
• Access may be via explicit conversion or implicit conversion. In general, explicit conversion is safer, but implicit conversion is more convenient for clients.

Item 16: Use the same form in corresponding uses of new and delete.

• If you use [] in a new expression, you must use [] in the corresponding delete expression. If you don't use [] in a new expression, you mustn't use [] in the corresponding delete expression.

Item 17: Store newed objects in smart pointers in standalone statements.

• Store newed objects in smart pointers in standalone statements. Failure to do this can lead to subtle resource leaks when exceptions are thrown.

Item 18: Make interfaces easy to use correctly and hard to use incorrectly

• Good interfaces are easy to use correctly and hard to use incorrectly. Your should strive for these characteristics in all your interfaces.
• Ways to facilitate correct use include consistency in interfaces and behavioral compatibility with built-in types.
• Ways to prevent errors include creating new types, restricting operations on types, constraining object values, and eliminating client resource management responsibilities.
• TR1::shared_ptr supports custom deleters. This prevents the cross-DLL problem, can be used to automatically unlock mutexes (see Item 14), etc.

Item 19: Treat class design as type design

• Class design is type design. Before defining a new type, be sure to consider all the issues discussed in this Item.

Item 20: Prefer pass-by-reference-to-const to pass-by-value

• Prefer pass-by-reference-to-const over pass-by-value. It's typically more efficient and it avoids the slicing problem.
• The rule doesn't apply to built-in types and STL iterator and function object types. For them, pass-by-value is usually appropriate.

Item 21: Don't try to return a reference when you must return an object

• Never return a pointer or reference to a local stack object, a reference to a heap-allocated object, or a pointer or reference to a local static object if there is a chance that more than one such object will be needed. (Item 4 provides an example of a design where returning a reference to a local static is reasonable, at least in single-threaded environments.)

Item 22: Declare data members private

• Declare data members private. It gives clients syntactically uniform access to data, affords fine-grained access control, allows invariants to be enforced, and offers class authors implementation flexibility.
• protected is no more encapsulated than public.

Item 23: Prefer non-member non-friend functions to member functions

• Prefer non-member non-friend functions to member functions. Doing so increases encapsulation, packaging flexibility, and functional extensibility.

Item 24: Declare non-member functions when type conversions should apply to all parameters

• If you need type conversions on all parameters to a function (including the one pointed to by the this pointer), the function must be a non-member.

Item 25: Consider support for a non-throwing swap

• Provide a swap member function when std::swap would be inefficient for your type. Make sure your swap doesn't throw exceptions.
• If you offer a member swap, also offer a non-member swap that calls the member. For classes (not templates), specialize std::swap, too.
• When calling swap, employ a using declaration for std::swap, then call swap without namespace qualification.
• It's fine to totally specialize std templates for user-defined types, but never try to add something completely new to std.

Item 26: Postpone variable definitions as long as possible.

• Postpone variable definitions as long as possible. It increases program clarity and improves program efficiency.

Item 27: Minimize casting.

• Avoid casts whenever practical, especially dynamic_casts in performance-sensitive code. If a design requires casting, try to develop a cast-free alternative.
• When casting is necessary, try to hide it inside a function. Clients can then call the function instead of putting casts in their own code.
• Prefer C++-style casts to old-style casts. They are easier to see, and they are more specific about what they do.

Item 28: Avoid returning "handles" to object internals.

• Avoid returning handles (references, pointers, or iterators) to object internals. It increases encapsulation, helps const member functions act const, and minimizes the creation of dangling handles.

Item29: Strive for exception-safe code.

• Exception-safe functions leak no resources and allow no data structures to become corrupted, even when exceptions are thrown. Such functions offer the basic, strong, or nothrow guarantees.
• The strong guarantee can often be implemented via copy-and-swap, but the strong guarantee is not practical for all functions.
• A function can usually offer a guarantee no stronger than the weakest guarantee of the functions it calls.

Item 30: Understand the ins and outs of inlining.

• Limit most inlining to small, frequently called functions. This facilitates debugging and binary upgradability, minimizes potential code bloat, and maximizes the chances of greater program speed.
• Don't declare function templates inline just because they appear in header files.

Item31: Minimize compilation dependencies between files.

• The general idea behind minimizing compilation dependencies is to depend on declarations instead of definitions. Two approaches based on this idea are Handle classes and Interface classes.
• Library header files should exist in full and declaration-only forms. This applies regardless of whether templates are involved.

Item 32: Make sure public inheritance models "is-a."

• Public inheritance means "is-a." Everything that applies to base classes must also apply to derived classes, because every derived class object is a base class object.

Item 33: Avoid hiding inherited names

• Names in derived classes hide names in base classes. Under public inheritance, this is never desirable.
• To make hidden names visible again, employ using declarations or forwarding functions.

Item 34: Differentiate between inheritance of interface and inheritance of implementation

• Inheritance of interface is different from inheritance of implementation. Under public inheritance, derived classes always inherit base class interfaces.
• Pure virtual functions specify inheritance of interface only.
• Simple (impure) virtual functions specify inheritance of interface plus inheritance of a default implementation.
• Non-virtual functions specify inheritance of interface plus inheritance of a mandatory implementation.

Item 35: Consider alternatives to virtual functions

• Alternatives to virtual functions include the NVI idiom and various forms of the Strategy design pattern. The NVI idiom is itself an example of the Template Method design pattern.
• A disadvantage of moving functionality from a member function to a function outside the class is that the non-member function lacks access to the class's non-public members.
• tr1::function objects act like generalized function pointers. Such objects support all callable entities compatible with a given target signature.

Item 36: Never redefine an inherited non-virtual function

• Never redefine an inherited non-virtual function.

Item 37: Never redefine a function's inherited default parameter value

• Never redefine an inherited default parameter value, because default parameter values are statically bound, while virtual functions — the only functions you should be overriding — are dynamically bound.

Item 38: Model "has-a" or "is-implemented-in-terms-of" through composition

• Composition has meanings completely different from that of public inheritance.
• In the application domain, composition means has-a. In the implementation domain, it means is-implemented-in-terms-of.

Item 39: Use private inheritance judiciously

• Private inheritance means is-implemented-in-terms of. It's usually inferior to composition, but it makes sense when a derived class needs access to protected base class members or needs to redefine inherited virtual functions.
• Unlike composition, private inheritance can enable the empty base optimization. This can be important for library developers who strive to minimize object sizes.

Item 40: Use multiple inheritance judiciously

• Multiple inheritance is more complex than single inheritance. It can lead to new ambiguity issues and to the need for virtual inheritance.
• Virtual inheritance imposes costs in size, speed, and complexity of initialization and assignment. It's most practical when virtual base classes have no data.
• Multiple inheritance does have legitimate uses. One scenario involves combining public inheritance from an Interface class with private inheritance from a class that helps with implementation.

Item 41: Understand implicit interfaces and compile-time polymorphism

• Both classes and templates support interfaces and polymorphism.
• For classes, interfaces are explicit and centered on function signatures. Polymorphism occurs at runtime through virtual functions.
• For template parameters, interfaces are implicit and based on valid expressions. Polymorphism occurs during compilation through template instantiation and function overloading resolution.

Item 42: Understand the two meanings of typename

• When declaring template parameters, class and typename are interchangeable.
• Use typename to identify nested dependent type names, except in base class lists or as a base class identifier in a member initialization list.

Item 43: Know how to access names in templatized base classes

• In derived class templates, refer to names in base class templates via a "this->" prefix, via using declarations, or via an explicit base class qualification.

Item 44: Factor parameter-independent code out of templates

• Templates generate multiple classes and multiple functions, so any template code not dependent on a template parameter causes bloat.
• Bloat due to non-type template parameters can often be eliminated by replacing template parameters with function parameters or class data members.
• Bloat due to type parameters can be reduced by sharing implementations for instantiation types with identical binary representations.

Item 45: Use member function templates to accept "all compatible types."

• Use member function templates to generate functions that accept all compatible types.
• If you declare member templates for generalized copy construction or generalized assignment, you'll still need to declare the normal copy constructor and copy assignment operator, too.

Item 46: Define non-member functions inside templates when type conversions are desired

• When writing a class template that offers functions related to the template that support implicit type conversions on all parameters, define those functions as friends inside the class template.

Item 47: Use traits classes for information about types

• Traits classes make information about types available during compilation. They're implemented using templates and template specializations.
• In conjunction with overloading, traits classes make it possible to perform compile-time if...else tests on types.

48: Be aware of template metaprogramming

• Template metaprogramming can shift work from runtime to compile-time, thus enabling earlier error detection and higher runtime performance.
• TMP can be used to generate custom code based on combinations of policy choices, and it can also be used to avoid generating code inappropriate for particular types.

49: Understand the behavior of the new-handler

• set_new_handler allows you to specify a function to be called when memory allocation requests cannot be satisfied.
• Nothrow new is of limited utility, because it applies only to memory allocation; subsequent constructor calls may still throw exceptions.

50: Understand when it makes sense to replace new and delete

• There are many valid reasons for writing custom versions of new and delete, including improving performance, debugging heap usage errors, and collecting heap usage information.

51: Adhere to convention when writing new and delete

• operator new should contain an infinite loop trying to allocate memory, should call the new-handler if it can't satisfy a memory request, and should handle requests for zero bytes. Class-specific versions should handle requests for larger blocks than expected.
• operator delete should do nothing if passed a pointer that is null. Class-specific versions should handle blocks that are larger than expected.

52: Write placement delete if you write placement new

• When you write a placement version of operator new, be sure to write the corresponding placement version of operator delete. If you don't, your program may experience subtle, intermittent memory leaks.
• When you declare placement versions of new and delete, be sure not to unintentionally hide the normal versions of those functions.

53: Pay attention to compiler warnings.

• Take compiler warnings seriously, and strive to compile warning-free at the maximum warning level supported by your compilers.
• Don't become dependent on compiler warnings, because different compilers warn about different things. Porting to a new compiler may eliminate warning messages you've come to rely on.

54: Familiarize yourself with the standard library, including TR1

• The primary standard C++ library functionality consists of the STL, iostreams, and locales. The C99 standard library is also included.
• TR1 adds support for smart pointers (e.g., tr1::shared_ptr), generalized function pointers (tr1::function), hash-based containers, regular expressions, and 10 other components.
• TR1 itself is only a specification. To take advantage of TR1, you need an implementation. One source for implementations of TR1 components is Boost.

55: Familiarize yourself with Boost.

• Boost is a community and web site for the development of free, open source, peer-reviewed C++ libraries. Boost plays an influential role in C++ standardization.
• Boost offers implementations of many TR1 components, but it also offers many other libraries, too.

Trading Strategies Involving Options

Unlike other derivatives (future, forward, swap), options provides flexibility (right to buy or sell an underlying instrument) in trading without any obligation. However, that’s flexibility comes with a cost. There are various techniques to estimate this cost, in other words price an option. I mentioned some of them in my previous blogs (Black Scholes, Monte Carlo, and Binomial Trees). In this blog, I will address on trading methods involving options. These methods are explained in great details in Options, Futures, and Other Derivatives by J. Hull and Derivatives Demystified by Andrew M. Chisholm.

Combination of Single Option and Stocks

This is the simplest strategies involving single option and underlying stock at same time. Please not in this text; we use European option in examples and these ideas can be used for American options too.

For example, a portfolio consists of a long position in an underlying and a short position in the call option, which is called as “writing covered call” (Figure 1-a). This portfolio protects against sudden rise in underlying stock, which affects payoff short call in a negative way. Similarly, a portfolio with short position in underlying and long call (Figure 1-b) protects against sharp rises in short underlying.

Other common single option strategy involves put options such as “protective put” (Figure 1-c) which consists of short underlying and put option. Short put option is protected with a short underlying. Long put option with long underlying (Figure 1-d) is used against sharp decline in the underlying.

Spreads

This strategy involves of two or more options of same types and aims to profit from spreads caused by various combinations of strikes, maturity date and economical factors.

Bull Spreads

If an investor would like to take advantage of increase in an underlying, this strategy would be used. Bull spreads employ two call options on same underlying with two different strike price (K1 and K2) . While option with higher K1 strike is shorted, other call option with lower K2 strike is longed in anticipation that in a bull market, the spread between K1 and K2 strike generates a profit. Table 1 and figure shows payoff from a bull spread strategy.

Bear Spreads

Unlike bear spread, if an underlying has potential to go down, bear spreads can be used. A short put option with lower K1 strike together with a long put option with higher K2 strike are used for bear spreads. Table 2 and figure 3 summarize the pay-off for bear spreads. Upside profit potential and downside risk is limited. Maximum payoff is K2-K1 spread when underlying price is less than K1.

Box Spreads

This is a strategy used by arbitrage trader if an arbitrage opportunity occurs. Box spreads involves of bull and bear spreads with same K1 and K2 strike prices which generates always K2-K1 payoff, as table 3 illustrates. Therefore price of a box spread should be present value the payoff ((K2-K1)*exp(-rT)), if an arbitrage opportunity for investor is not wanted.

Butterfly Spreads

In bear and bull spreads, investor positions himself/herself according to a potential upward or downward movement in underlying. On the other hand, in generic butterfly spread, investor positions himself/herself according to not volatile and moving underlying. In another words, if an investor thinks an underlying won’t go down nor up, he can buy butterfly spreads. Three different strike price with four call options are used: A long call with lower K1 strike price, and again a long call with higher K3 strike price and two short call with K2 strike (between K1 and K3, generally close to current underlying price (K3+K1)/2). As table 4 shows, if stock price stay close to around K2 a profit can be made. Butterfly spreads requires a small amount of cash investment at the beginning.

Butterfly spreads can be created with also put options: Two long put options with lower strike price K1 and higher strike price K3 and two short put options with strike price K2 which is between K1 and K3. If European put options are used, result will be same as call option’s butterfly spread.

One last point, butterfly spreads can be shorted or sold if it is thought an underlying goes either up or down but not sure which direction, which produces modest payoff if there is a major movement in any direction.

Calendar Spreads

So far, in all spreads, the variant element was strike price and expire date was same. In calendar spreads, variant element is expire date and strike price is constant for all options. For example, a short call option with short-maturity and a long call option with relatively longer-maturity can be used to create a calendar spreads. Since, longer-maturity call option will cost more than short call option, an initial cash flow out happens. When short-maturity short option expires, long call option is sold. Similar to butterfly spreads, if underlying price stay close to strike price, investor will make profit. Otherwise, a loss is incurred.

Similar to butterfly spreads, put options can be used to construct calendar spreads. Strike price in a calendar spread is chosen according to trend of underlying. In bullish and bearish sentiment, higher and lower strike price is chosen, respectively.

Diagonal Spreads

In this strategy, options with different strike and expiration date are used. Analyzing outcome of these strategies is more complex than other spread strategies. Advanced models are used to estimate payoff.

Combinations

In this strategy, put and call options are used at same time with same underlying.

Straddle

In this common strategy, a put and call option are purchased with same strike and expiration date. Unlike butterfly strategy, if a significant movement in underlying price happens in any direction, this strategy produces a significant profit. Table 5 and Figure 6 depict payoff of straddle.

A reverse straddle can also be created selling put and call option with same strike price and expire date which is highly risky, if price of underlying changes significantly. On the other hand, similar to butterfly spreads, significant profit can be made if price of underlying is around strike price.

Strips and Straps

As mentioned above, straddle is good if we are not certain about direction of movement in underlying. But if we have stronger tendency about direction of movement in one way but still not sure about direction like in straddle, strips and straps can be used. Strips and straps are kind of biased straddles. A strip consists of long call and two put options on same underlying with same strike price and expiry date. Similarly, a strap consists of long put and two call options on same underlying with same strike price and expiry date.

Strangles

In a strangle, an investor buys a put and call option with same expiration date with different strike prices. The strike price of put option (K1) is lower than the strike price of call option. This strategy is similar to straddles which bets on significant movement in underlying price(Figure 8). But in strangle, further movement is required for profit. But risk is lesser compare to straddle. Risk can be adjusted with strike prices K1 and K2. The further they are apart, the less the downside risk and the farther the underlying price has to move to make a profit.