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.
--
https://mail.python.org/mailman/listinfo/python-list
