intrusive_ptr is 32-bit; shared_ptr is at least 64-bit

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.

intrusive_ptr and java interface

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.

##varieties of c++ variables — 4 dimensions

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[1]
* 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

[1] 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….;)

intrusive ptr — intrusive access to pointee state

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[1] 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.

[1] 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.

intrusive/shared_ptr — warrants/options/fan-club

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.

##y c++has no Java features like …

* 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.

up and down casting nonref/ref/ptr

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 [1]
* there’s just one object involved, not 2
** That one object must be a complete and full[2] 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

[1] static_cast can cast nonref.
[2] 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. .. down cast a reference

Q: down-cast a base ptr (or 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: legit but less common than ptr. See post on virtual^redefining

top 3 layout managers by importance

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 [2]. 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.

[2] 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.

perl subroutine – pass by ref

J4: pbref is common in some perl code bases

–based on
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
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.

## swing – sources of events (brief list)

Swing supports semantic events and low-level events — 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
– 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]]