Python vs C++

[Michael Torrie]

On 08/22/2014 02:06 PM, Marko Rauhamaa wrote:
> I tend to think the opposite: C++ barely has a niche left. I definitely
> wouldn't want to use C++ very far from its (very narrow) sweet spot.

I agree that it's niche is narrowing.  But it's still pretty wide and
widely used.  Many adobe products are C++, for example.  OpenOffice and
LibreOffice is C++.  You could argue that's because they are old
projects and were started in C++. But honestly if you were
reimplementing OpenOffice today what would you choose?  Python would be
appropriate for certain aspects of OO, such as parts of the UI, macros,
filters, etc.  I certainly wouldn't want to use Java (contrary to
popular belief OO is not written in Java; it's definitely C++).  Go is
quite young but promising except that unicode is all UTF-8 byte strings,
so string operations are going to be a bit slow.  C# never lived up to
its promise as the next app development language, even on Windows.  So
at this moment I'd still do it in C++ I think.  Apple chose to use C++
to build clang and llvm in, rather than C.

> My disillusionment with C++ came from the language's inability to
> represent callbacks. C can do it (void *), C# can do it (delegates),
> Java can do it (anonymous inner classes), Python can do it (methods),
> Scheme can do it (closures).

C++ can do it quite well, actually.  Maybe not quite as nicely as
Python.  But boost and libsigc++ both offer nice, type-safe ways to
implement signals and slots.  You can pass references to a callback
around in an easy, safe way.

> Qt needs callbacks ("signals" IIRC). It doesn't use C++ to express them.
> It uses a fricking metacompiler for them.

This is only partially true.  The actual, original, .cpp files with Qt
macros in them compile directly on the C++ compiler.  moc runs on the .h
file to generate some supporting code to help with event dispatching.
There's no such thing as Qt C++.  It's all standard C++, with macros to
help when defining things such as signals.

Macros were chosen instead of templates because at the time, not all C++
compilers supported templates.  Now if it was done all over again,
they'd do something like libsigc++, or boost.

> And Stroustrup's thick book didn't even seem to be aware of callbacks as
> a paradigm and thus didn't show any examples of dealing with them. Too
> bad Stroustrup wasn't aware of C#'s delegates; C++ should have defined
> function pointers as delegates.

Maybe the language doesn't need to implement them as keywords because
it's already possible to do safely with templates.  libsigc++ is a great
implementation that works really well (and it's quite fast at
dispatching events).  libsigc++ has an advantage over Qt in that the
signals are actual type-safe template objects.  Qt's signals are
actually strings under the hood, and I've had weird name clash issues in
the past when I didn't realize that.  Can't remember the circumstances
or the details now.  Basically something that should have been caught at
compile time became a runtime error.

Doing event-driven programming with Gtkmm and libsigc++ is actually
pretty darn nice and is right at home in C++.

> There is one big advantage C++ has over C: virtual method dispatching.
> However, I have been able to come up with C idioms that make practical
> method dispatching relatively painless.

Seems like Vala might fit this niche pretty well.