ref2const object — everywhere

C++ uses the r2c idiom in many strategic areas — note-worthy

* typeid operator returns a ref to a constant type_info object
* catch(……) often uses a r2c exception object, _BUT_ shows a non-const usage
* op<<
* cvctor
* operator-overload-converters
* op=
* copy ctor — if u drop the “&” you get infinite recursion and stack overflow

essential pseudo-containers in STL

* arrays
* string — class template
* stream family — class templates

These are *extremely* essential utility containers.

For each pseudo-container, please answer these questions

Q: Provides iterators? I think so.
Q: Can use STL algo? yes if iterable, since STL algo only “cares about” iterators
Q: Allocator? not arrays or streams. Google search returns none

python class !! based@C struct

Java, c# and c++ classes are based on C struct, but Python class is more of a dictionary, or rather … A python class instance is more of a dictionary instance. (Cf javascript)

Telltale sign — You can instantiate a python class and subsequently add fields to it.

Even bolder, an instance myObj of class MyClass can introduce a new method m() that’s completely missing in MyClass. As a result, python run-time dispatch algo will search
1) the instance’s private registry
2) the class’s registry
3) base class’s registry

I think the registry is an internal dictionary (“idic”). As stated in P302 [[Programming Python]], classes are just dictionaries that inherit from other dictionaries; each instance is a new dictionary. All these run-time searches hit the dictionaries.

I feel python introspection is more sophisticated and more comprehensive than c++/c#/java.

Note this applies to method resolution only. Fields? Probably similar but i’m not sure yet.

new-expression calls op-new — implicitly

op-new is officially a function, and always requires 1 or more arguments.

– new MyType implicitly calls qq/…operator new(sizeof(MyType)) /
– new (2,f) MyType calls qq/..operator new(sizeof(MyType), 2,f) / — Note the (2,f) are placement arguments. See

– if arguments come After “MyType”, then they are ctor arguments, like qq/ new int(7) /

– new MyType implicitly calls qq/ C::operator new(sizeof(MyType)) / if any, and qq/ ::operator new(sizeof(MyType)) / otherwise

c++ pure-abstract-class == java interface

In C++ we generally separate a class into two modules: a .h module and a .cc module. The .h module contains the definition of the class, and the .cc module contains the definition of that class’s member functions. The definition of a class, in the .h module, contains declarations of all the member functions and member variables of the class.

This information goes beyond simple interface.

All the utility functions and private variables needed by the class are also declared in the .h module. These utilities and private variables
are part of the implementation of the class, yet they appear in the module that all users of the class must depend upon (via #include). Thus, in C++, implementation is not automatically separated from pure interface.

This lack of separation between pure interface and implementation in C++ can be dealt with by using purely abstract classes. A purely abstract class is a class that contains nothing (no fields) but pure virtual functions (ending in “=0”). Note Forward class declaration in effC++ can have fields, so those classes are usually not PAC.

c++ purely-abstract-class (PAC) == Java interface. SUN saw the value of PAC and made it a first class citizen in java.
c++ class definition + method definition == java class definition
c++ class with at least one pure virtual method == java abstract class

c++ forward class declaration == java no such thing
c++ regular class header file (without method definition) == java no such thing

In terms of compile-time dependency, java favors dependency-on-interface. In c++, you usually depend on *.h files, which is “thicker” than java interfaces. I feel there are 2 ways to reduce this tight coupling

* Forward class declaration

In java, as a “client” class, we can be completely oblivion of the actual type responding to OUR message. That actual type could be unknown at compile time. No recompile required when the actual type changes, since we depend on the interface only. I feel this is the dream of c++ developers.