Scott Meyers

10 Cool Things in C++ -- Plus Something Wicked
  What follows is a slightly-sanitized copy of the notes I used for my "10
  Cool Things in C++ -- Plus Something Wicked" talk I gave at Software
  Development in 1997.  Questions?  Comments?  Suggestions?  Feel free
  to send me mail.

  Scott
  smeyers@aristeia.com
  http://www.aristeia.com

  What is a "cool" thing?  Cool things should be novel, interesting, and
  useful in solving different types of problems; they typically reveal
  insights into novel applications of language features.  Ideally, they're
  all three (novel, interesting, useful), but a very heavy weighting in
  one category alone suffices.  For example, a technique with no utility
  but great novelty and interest can qualify, just as useless -- but
  interesting -- art can qualify as being "cool."

    - Barton's/Nackman's Dimensional Analysis
  
      John J. Barton and Lee R. Nackman, "Dimensional analysis," C++
      Report, January 1995.  Based on section 16.5 of their "Scientific
      and Engineering C++:  An Introduction with Advanced Techniques and
      Examples," Addison-Wesley, 1994.


    - Double Application Of Smart Pointers
  
      Can be used to automate thread control in non-thread-safe classes,
      though Stroustrup's comments on pp. 464-5 in his C++PL/2E indicate
      that using this technique for concurrency control may be
      counterproductive.  Care must be taken to ensure a thread doesn't
      block itself.

      Can also be used to confirm class invarients before and after calls.
      Is there a way to extend it to checking function
      precondition/postconditions? 

      This posting shows the same idea, though I originally got the idea
      from Tony Davis based on a class he taught.

        [ Begin Posting ]
	  
        Newsgroups: comp.lang.c++
        From: jimad@microsoft.com (Jim ADCOCK)
        Subject: Re: A really good way to do this is?
        Date: 13 Apr 92 20:57:16 GMT
	  
        |The problem at hand is I'd like to be able to define a general
        |class which I can inherit from that has a the following property:
        |each time a member function is called a hidden member function,
        |eg. an access function, is called and when the member function
        |exits a `deaccess' function is called.  This is similar to, but not
        |really the same, as the constructor/destructor pair for an
        |object, but I wish for it to happen on each access.
	  
        I don't believe C++ offers a "good" solution to this problem
        [although adding operator dot would be a partial set in the right direction]
        See the below "not-too-good" example which illustrates some of the issues
        and associated problems:
	  
        class X;
	  
        class dispatch
        {
           X& xref;
        public:
           dispatch(X& x);
           ~dispatch();
           X* operator->();
        };
	  
        class X
        {
           char name;
        public:
           X(char c) : name(c) { }
           void doSomething() { printf("doSomething with %c\n", int(name)); }
           void lock() { printf("lock %c\n", name); }
           void unlock() { printf("unlock %c\n", name); }
           dispatch operator->() { return *this; }
        };
	  
        dispatch::dispatch(X& x) : xref(x) { xref.lock(); }
        dispatch::~dispatch() { xref.unlock(); }
        X* dispatch::operator->() { return &xref; }
	  
        main()
        {
           X x('x');
           printf("++++++\n");
           x->doSomething();
           printf("------\n");
           x.doSomething();
           return 0;
        }     

        [ End Posting ]


    - Coplien's Reading Of Network Objects

      James O. Coplien, "Advanced C++:  Programming Styles and Idioms,"
      Addison-Wesley, 1992, pp. 148-159.


    - Detlef's Discriminated Unions

      See discriminated-unions.txt.


    - Koenig's/Moo's Function Composition
  
      Andrew Koenig and Barbara Moo, "Ruminations on C++,"
      Addison-Wesley, 1997, chapter 21.
  

    - Traits
  
      Nathan Myers, "A New and Useful Template Technique:  Traits," C++
      Report, June 1995, also available at 
      http://www.cantrip.org/traits.html; Klaus Kreft and Angelika Langer,
      "Iterators in the Standard Library," C++ Report, November-December
      1996;  Pete Becker, "Questions and Answers:  Traits to the Rescue,"
      C/C++ Users Journal, November 1996.
	
      Traits are basically compile-time else-if-thens: the unspecialized
      template is the else clause, the specializations are the if clauses.  I
      think traits can be used to determine whether a template parameter is a
      built-in type.  Also whether a template parameter inherits from a given
      base class.  The trick is to create a template generating code that
      won't compile, then provide specializations that *will* compile for the
      special cases that are allowed.  Did Myers invent this?


    - Template Metaprogramming and Expression Templates

      Todd Veldhuizen, "Using C++ template metaprograms," C++ Report, May
      1995;  Todd Veldhuizen, "Expression templates," C++ Report, June
      1995; Todd Veldhuizen and Kumaraswamy Ponnambalam, "Linear Algebra
      with C++ Template Metaprograms," Dr. Dobb's Journal, August 1996.
      See the Blitz Project home page, http://monet.uwaterloo.ca/blitz/.
	
      Apparently discovered independently by Todd Veldhuizen and Daveed
      Vandevorde (the latter of whom apparently called it "static
      expressin trees" and who used it in the implementation of his
      valarray template (available at
      http://www.cs.rpi.edu/pub/vandevod/Valarray/)). 
	
      Has other applications, e.g., Carlo Pescio's "Binary Constants Using
      Template Metaprogramming," C/C++ Users Journal, February 1997. 


    - Skaller's Use Of A Local Class In Class Factories

      See my notes on mixins, but check this first: don't all class names
      have external linkage?


    - Hickey's Callbacks.
  
      Rich Hickey, "Callbacks in C++ Using Template Functors," C++
      Report, February 1995.  Article and code available at his home page,
      http://ourworld.compuserve.com/homepages/RichHickey/.

      See also callback.txt file in C++ directory. 


    - Fujinami's Run-Time Code Generation
  
      Nobuhisa Fujinami, "Automatic Run-Time Code Generation in
      Object-Oriented Languages," submitted to COOTS 97.  Available in
      postscript at http://www.aristeia.com/fujinami.ps. 


    - Ted Clancy's implementation (which turns out to be MY
      implementation) of a NULL object via member templates
      for type conversions.


    - The GOF's Visitor Pattern

      Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides,
      "Design Patterns:  Elements of Reusable Object-Oriented Software,"
      Addison-Wesley, 1995, pp 331-344.  See also John Vlissides' article
      in the September 1996 C++ Report.  It describes an extension to
      Visitor that relaxes the restriction that the initial hierarchy be
      unmodifiable.  See also below on the wicked thing. 


    - The Standard Template Library
  
      David R. Musser and Atul Saini, "STL Tutorial and Reference Guide,"
      Addison-Wesley, 1996.  There are lots of on-line resources -- a
      good place to start is http://www.sgi.com/Technology/STL/.
	

  The wicked thing:

    - Lakos' Long-Distance Friendship Hole
  
      John Lakos, "Large-Scale Software Design," Addison-Wesley, 1996,
      section 3.6.2.

      Why did this give me the same "cool" kind of feeling as the above ideas,
      even though it's wicked?  Could it be for the same reason that
      psychology tells us we sometimes confuse fear and passion: the
      physiological effects are similar?  (An "emotional illusion.") Danger
      and exhileration are linked in our minds.  If we let f(n) = "Friday the
      13th, Part n", can we infer that the reason behind the success of the
      series is that the limit of f(n) as n goes to infinity is love?  Maybe
      that's why this is such a popular series with the teenage set: get them
      scared enough, and they'll think they like you :-). [The preceding is
      not supposed to be philosophical, it's supposed to be funnily tongue in
      cheek.]

      One "cool" aspect of long-distance friendship is that it solves the
      problem introduced by the Visitor pattern: Visitors are fake virtual
      functions, but they have no more than public access to the objects
      they're acting virtual on.  LDF also solves a similar problem with the
      fake-vtbl solution to the double-dispatching problem.