Reading through the docs, it was nice seeing that Pascal wasn't sitting still through all the these years. Generics, extension methods (class helpers) and value types - though the last features actually existed way before class, and I've extensively used it back in the day, old style objects are unsafe and were abandoned for a while without being fixed.

Too bad that memory management is still tedious and categorically unsafe with all sorts of crazy hacks like a TComponent hierarchy and reference counting that exists only for interface.

It was a reasonable trade-off for me back in the days where the best thing C++ had was auto_ptr and a bunch of incompatible vendor specific classes. Nowadays, it's a world I wouldn't want to come back to (or I would happily programming C).

> Too bad that memory management is still tedious

I don't find it onerous. It also depends which compiler you're using. Delphi uses Automatic Reference Counting for Android and iOS:

http://blog.marcocantu.com/blog/delphi_arc_android.html

http://docwiki.embarcadero.com/RADStudio/Berlin/en/Automatic...

A note about the second link's table: Free Pascal since version 3.0 does have native unicode support. In fact it has native support for any encoding and it does on-the-fly conversions between different encodings without the programmer having to pay any special attention (but you can use different string types, such as utf8string, if you want the in-memory data to be in a specific encoding).

C++ has also had native unicode support for a while now (made standard in C++11). The table complains that indexing is byte-based, but that's arguably better than the deceptive UTF-16 based indexing many languages have, since UTF-16 code units are not equivalent to unicode code points. Even UTF-32 code points are not equivalent to composed characters or visible gylphs, so character-based indexing makes very little sense unless you're using a Unicode-specific library.

I also wonder why C++ is claimed to have no instance function pointers even though std::bind was available since TR1 and boost::bind was available aeons ago. Did the author confuse C++ style function references with C function pointers? But this is like confusing the C++ std::string (which exist only as a library feature) with C-style char arrays.