First, remember a smart_ptr instance is a full-fledged object whose class often has methods or fields.
In contrast, a raw ptr instance is monolithic — not an instance of a class. Its pointee can often be an instance of a class with members, and you can access them like rawPtr->pointeeMethod2().
Since the counter is in the pointee object, an intrusive_ptr object needs no state. An intrusive_ptr do need methods. (Look, if a class has no, including inherited, field or method, then it’s useless.) Therefore, minimum members of an intrusive_ptr are
– internal pointer to the pointee object
– no other field
– ctor, dtor …
– no virtual functions
If an intrusive_ptr class uses no virtual function, then its size can be the size of the internal pointer, i.e. 32 bit, smaller than sizeof shared_ptr can’t. A shared_ptr object needs
– internal pointer to the pointee object
– some pointer that (indirectly) references the ref counter object somewhere in memory
Therefore, at least 64 bits, assuming a 32-bit machine.
For a beginner to intrusive_ptr, we won’t be too far off to remember that a pointee class could (not required) implement a java-style interface with 2 public methods addRef and delRef(). The pointee class typically uses these methods to change a private field refCount.
In Boost, the intrusive_ptr actually uses 2 stipulated free functions, but they could (and often do) call methods of the pointee class, like our 2 methods.
To understand the wide variety of C++ variables, consider…
— about the object —
1) Heap (=>pointer) ^ stack
2) Primitives ^ class types
— about the variable —
3) Pointer(and ref) ^ nonref types
4) locals ^ fields — globals are rare
First 3 dimensions make 8 types
* Pointer/ref to Heap primitive
* pointer/ref to Heap class type
* pointer/ref to anything on stack is questionable
* class type on heap but not accessed by pointer? impossible
* class type on stack and not accessed by pointer
* primitive on heap but not accessed by pointer? impossible
* primitive on stack and not accessed by pointer
 but how about simple c-strings. I used many of them without malloc(). Some arrays do live on the stack!
Nonref types can be pbclone or pbref. Pointers should be passed as …pointers.
Vast majority of variables are local variables or fields. By default locals live on the stack, but a local ptr can point to a heap object. After out-of-scope, the heap leaks….;)
Q: Why the world “intrusive” in intrusive_ptr?
A: because this pointer manipulates state of the pointee object. Typically the pointee object provides/allocates/embeds the ref counter. When an intr pointer joins the “club” of intr pointers, the pointer initiates a call to increment the counter.
A: because the more common smart pointers don’t mess with the state of pointee object. Therefore, the intrusiveness is a defining characteristic of this type of pointer.
 intrusive_ptr_add_ref(). P33 [[beyond the c++ standard library]] says that ==often== this function calls a *member* method of the pointee class, in order to manipulate the counter *field*. I feel this is a common solution.
a payload-class, or pointee-class or “managed-class” is fully aware of the intrusive_ptr instances, like a warrant, where the issuer (say IBM) is aware of how many warrants are out there.
a managed-class is unaware of the shared_ptr instances circling around like sharks (ready to KILL it), a bit like an option — IBM doesn’t know how many IBM options are out there.
shared_ptr is also like a Fan club for a celebrity — celebrity doesn’t know about the fans.
“Payload” is clearer in a phone conversation.
This is yet another blog post on vtbl, RTTI, dynamic_cast, type_info…
We won’t be too far off if we imagine that all RTTI operations work their magic by following the vptr.
Remember each polymorphic class has a distinct vtbl. If there are 521 polymorphic classes in memory, then there are exactly that many v-tables in memory. Each polymorphic object holds a 32-bit vptr seated at the vtbl of the “real” class. Recall that during subclass instantiation, the vptr first gets seated at the parent vtbl, then reseated at the subclass vtbl.
Now you see that if there’s no virtual function among base and subclasses, then there’s no vtbl/vptr, and RTTI can’t “follow the vptr”.
* packages? There are. See the book on large scale c++ system
* interfaces? Well, the pure abstract base class in c++ is the best practice for MI.
* VM? i think c++ app runs in a runtime environment just like a Perl script.
* VM threads? i think only the standard OS threads are available? Wrong. See the c++ thread book.
* reflection? RTTI is limited in feature. Python has significantly richer reflection features than compiled languages.
Primary usage of dynamic_cast is down-cast
* base/derived class must have vptr, or you get compile-time error
* original and target types must be ptr/ref, or you get compile-time error 
* there’s just one object involved, not 2
** That one object must be a complete and full Derived object, otherwise you get runtime (not compile time) failure, indicated by 1) null ptr or 2) exception (during reference down-cast)
*** boost polymorphic_cast adds uniformity by throwing exception for both
 static_cast can cast nonref.
 static_cast doesn’t incur the overhead to check that
Q: up-casting a nonref??
A: no casting operator required, but you get sliced. qq/ myB = myD; /
A: by the way, no such thing in java, since java doesn’t use “nonref”
Q: down-casting a nonref??
A: impossible in dynamic_cast. “dynamic_cast can be used only with pointers and references to objects”
Q: down-casting a ptr (to a polymorphic object only)?
A: dynamic_cast. May return NULL. java has a similar feature.
A: see also boost polymophic_cast
Q: down-casting a ref (to a polymorphic object only)?
A: dynamic_cast. Never returns NULL. See post on new-and-dynamic_cast-exceptions
A: see also boost polymophic_cast
Q: down-cast a base ptr/ref to a derived object but no vtbl/vptr no virt func?
A: impossible. dynamic_cast won’t compile.
Q: up-cast a ptr?
A: common in c++ and java. everyday virtual function scenario. no operator required.
Q: up-cast a ref?
A: less common than ptr. See post on virtual^redefining
1) border layout — the default for the the content pane (jpanel) of a jframe. A
country with a border and 4 neighbours.
2) flow layout — the default in JPanel . Tend to be the simplest layout. Good for simple apps.
3) grid bag — last resort if you want more (almost absolute) control than available in other layouts, but I feel there’s a simpler alternative — nested-layout ie nested subpanels each with a layout manager.
 However, the jpanel in jrootpane gets a BorderLayout
In numerous current textbooks, the top 4 layouts are border, flow, grid and box. Most of them mention grid bag as a last option. Few mention card, spring etc.
J4: pbref is common in some perl code bases
–based on http://www.tek-tips.com/faqs.cfm?fid=427
an example that describes how you can pass references to a subroutine, and use those references in the subroutine to change the values of the variables that those references point to
–based on http://www.troubleshooters.com/codecorn/littperl/perlsub.htm
You can modify the original variable without creating references. (compare c# ref-parameters)
This 7-page tutorial shows how to pass scalar, list or hash as input-only or input/output args to a sub.
You know a compiler implicitly invokes either a conversion ctor (cvctor) or an operator-overload conversion (OOC). A few aspects of OOC —
– a conversion function must be a method ie a member function. See [[c++ primer]]
– no return type, since the method must return the type specified between “operator” and “()”
– no argument
Swing supports semantic events and low-level events — http://tech.stolsvik.com/2009/03/awt-swing-event-pumping-and-targeting.html. Most of the “visible” events that litter our source code are semantic, so that’s the focus of most app-developer. However authors often include low-level events when “swing event” is mentioned in literature.
We mostly care about events on the EDT. Nothing stops a swing app from using any number of events on some independent thread unrelated to the EDT, but anything that affects the display must use EDT, unless the method is marked “thread-safe”. Here are some common sources of events.
– UI events — from mouse and keyboard. It’s possible to write many small swing apps with no other events than UI events.
– MOM events — A swing app often has MOM listeners that can fire events that affect the UI.
– timer events — Always en-queue to EDT. Often affects UI.
– property change events — example? See Action.java
– UI model change events — model is always, always attached to a UI component, so the change usually affects some UI. Additionally, a change can affect other UI components. Example? Say a table model should update jtable + some row-counter + background color to indicate new data in the jtable.k
** TableModel changes can occur due to user actions — P449 [[Java cookbook]]