My Most Important C++ Aha Moments (2006)

The Visitor Pattern doesn't provide multiple dispatch.

The Visitor Pattern relies on multiple dispatch, and so it provides a form of it to itself.

The Visitor Pattern doesn't go away in a language with multiple dispatch; its boiler plate code is just reduced.

What the Visitor Pattern is about is to bring together the benefits that arise from a cluster of ideas: first class functions, and generic functions.

In the Common Lisp object system, OOP functions are "generic functions" which stand alone and are not tied to classes. If we have a "frobosity" method and a list of objects, we can map that list easily to get every object's frobosity: (mapcar 'frobosity objlist). That is to say, we have visited each object in objlist. Each object has effectively "accepted" a "visit" from the frobosity function.

Now what we might want is instead of using generic function, to use a "funcallable object". let's use mapc instead of mapcar, since we don't need to collect the results into a list. The visitor-object itself can do something useful along those lines:

  (mapc visitor-object objlist)

since we don't have funcallable objects standard Lisp we can borrow the dispatch kernel of the Visitor Pattern:

  (mapc (lambda (list-obj) (accept visitor-object list-obj)) objlist)

If we have that real double dispatch, it's just more convenient to write the rest of this cruft. It's just a simple, linear bunch of definitions like:

  (defmethod accept ((visitor this-class) (obj that-class))
     ;; handle this-class + that-class combination
    )

I find it to be the case with most languages.

> Even template metaprogramming alone is gigantic area of ongoing research -- the stuff you can do with it is mind-bending and unavailable in nearly all other languages.

Your are being a bit hyperbolic. Meta-programming is not necessarily a hard thing to do, but in some languages, like C++ it was made impractical at first. Then, templates introduced some metaprogramming aspects with another layer of Turing-completeness. I can appreciate the usefulness of C++ and how templates contribute to it, though.

> Templates are, after all, one of very very few wholly functional, immutable languages out there.

XSLT too ;-)

> And template instantiation is the underlying force behind many of the modern features like lambdas that allow you to access that power without actually knowing templates well.

Lambdas roamed the earth long before templates.

> ... and if you can accept that you will never know the entire language and can just use those bits that make things easier, it is possible to have a healthy relationship with the language.

Agree.

Um, no. C++ can be safer than C (which is an incredibly low bar) but only if you carefully constrain yourself to certain subsets of the language, which is why the web is chock-a-block with byzantine "C++ coding standards" documents describing all the rules you have to follow in order to avoid shooting yourself in the foot.

As a developer responsible for understanding what everyone else is doing on the same project, no I cannot accept that.

This is a problem with vocabulary types. C tends to do a good job of providing them. C++ tends not to, though there has been some progress in the standard lately in defining classes like unique_ptr and string_view.

C tends to fall down by providing raw memory (an int and a char) to represent fairly subtle relationships (the int represents the size of the string pointed to by the char... what happens when the int is negative?). So C libraries don't 'reinvent the whole stack', but this sort of bookkeeping logic tends to cause bugs (at least security bugs).

...but I get confused by the people who do that, and then turn around to embrace C, the circus where people juggling the chainsaws of "faking templates with macros", "terrible build times", "yet more security vulnerabilities resulting from undefined behavior", "no C-standard defined threading / async support until C1X", and more.

It's common, but I don't get it.

  // Things.h
  namespace Foo { class A { C* c; }; }
  namespace Bar { class B { C* c; }; }

  // TU1.cpp
  class C {};

  // TU2.cpp
  namespace Foo { class C {}; }
  namespace Bar { class C {}; }

  // TU3.cpp
  class C {};
  namespace Foo { class C {}; }
  namespace Bar { class C {}; }

Ahh - all three are in the same program. Just pretend they #included <c.h>, <foo/c.h>, and <bar/c.h>. Having A::c's type be different in different contexts is a violation of the "One Definition Rule", for which the punishment is undefined behavior.

Although you can still recreate the above scenarios by just #including <Things.h> after <c.h> and company, but you're a bit more likely to have Things.h #include what it needs to clarify the situation. Hopefully. So maybe we can get away with it!

  void foo() { D * d; }

  void bar() { E < 42 > e; }

  void baz() { F < (42) > f; }

  void he_comes() { G < (42) > g(); }

  v̹̊̈́̇ͦ̌ͭ͂ͅo̅̉̀ͪ̚ī̵̠̘̋d̸͚̪̝̹͙͆͛̿ ͉̜̳ͪͬ́ͣ̌ẑ̸̹̹̩̩a̡̰ͣͭ̄͒ͫ̇̚l̛̹̫͓̣͖͈̐ͬg̢͕̘͙o̪͆̏ͥ͟(̖̭̟̱̰ͩ)̘̬͉̺̉̓ ̦͆́̚{ ̶̪͙̹͈ͮͧ̋ͪͤͅĜ͔̙̉͢ ̝̯ͭ̈́͘<̨͊̂͋̎ ̤͇̼̝͔͇ͯ̑̋ͫ̾͐̚(ͨͪͦ̈̈́ͥ4͍͗̆2̲̞̦̳̖͡)͖͇̟̥ͮ͘ ̺̖͙̘̳͛̐̊͊>̼͍̘̦͖̎ ̧̘̻̭͉̺g̟͓̑ͦ̌̃(̪ͬͪͤ̎̉͘ȉ̮̥͖́n̸̝̪̗̯͇̓̈́̀̔̄̍́t͓̟͍ͨͪ(̰͈̻͎̣͉̀̿̈͑)̝͚̆̃̇)̠̃;̺͎̙̰̈́̏̚͘ ̶̜͍̠̼ͬ}̡̤̰̮̳͈̌͛ͤ̈́

   // file: A.h
   class B;
   class A {
     B* _b; // or any of the other variants.
   };

  // file: A.h
  class B;

  class A {
    B* _b;
  };

  // file: B.h
  class B {
    A* _a;
  };

    class B;
    class A {
      B* _b;
    };