Hacker News new | comments | show | ask | jobs | submit login

I really think the final nail in C++'s coffin is going to be its refusal to play ball in a polygot world. Most languages let you drop down into C pretty easily but C++'s weird name mangling, exceptions and complex, usually nonstandard ABI makes interfacing with C++ a major PITA. In the days when C++ was used soup-to-nuts this wasn't such a big deal but these days you almost always want some kind of higher level language on top.

Just look at all the contortions WinRT has to go through to expose its APIs versus the clean Foundation/Cocoa layering you see in iOS/OS X for a great example.

I agree. In fact, this is what I would have expected to read in the article.

The only single major issue in creating infrastructure in C++ is the enormous added complexity in the final library and dependencies.

While you can avoid mangling and support a "C" api by using ``extern "C"'' declarations, this mostly imposes a "c" like, no-oop API that doesn't really save much work compared to a "C" api.

Certainly in my own projects I have found that going OCaml<->C<->C++ with extern is infinitely more fun than trying to go OCaml<->C++ with SWIG.

+1. My thoughts exactly. One of the factors I reject C++ library for my pet projects is that I can't interface them easily with FFI (LuaJIT, Common Lisp CFFI, Python CTypes, etc.).

And one think that I love about ZeroMQ, is that even being C++ it exposes the stuff with extern "C" and makes life easier. I wish Qt, wxWidgets were easier to expose this way (okay, there is SWIG, or some other tools luabind, etc. - but they produce additional DLL/.so files that are sometimes as big as the library they are wrapping (if not bigger)).

At least with clang/llvm and gcc you now have binary compatibility between two competing compilers.

You can take a .o built with gcc (g++) and link it with a .o generated by clang (clang++) without issues. Same name mangling, same everything. This means that I on my system at least don't care anymore whether the project is built with GCC or with clang and I can use either or for my own projects.

The thing though is that the C++ standard doesn't have a default ABI, so saying that it is non-standard isn't even the case, that we get any compatibility is nice at all, and I understand that complaint.

The biggest issue I've ran into is that even with the same compiler on the same platform (using MSVC 2008) setting different compiler flags generated completely different code and memory layouts for std::vector that caused me to not be able to link against a DLL. At least some consistency exists with other compilers and different flags don't necessarily change compatibility.

I don't think it is entirely fair to compare WinRT with Foundation/Cocoa. WinRT has an entirely different goal than what Foundation/Cocoa provide, and Foundation/Cocoa provide none of the same things that WinRT provides such as a object model that can be used across different programming languages fairly easily. Mac OS X has nothing that even comes close to COM.

Mac OS X has nothing that even comes close to COM.

Because it doesn't need something like COM. As is so often the case, Apple has made some radical simplifications. ObjC has its faults but the C/ObjC/ObjC++ stack covers a lot of ground with minimal mental overhead.

COM can be used by any language and allows software components, object based, to be "easily" shared among languages.

How does it work in Mac OS X?

You either write to the underlying C API or you use ObjC.

Right, but Apple once thought it needed OpenDoc.

Name mangling is pretty common in any high level language, although people only bash on C++.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup

Can you name some other examples?

Ada, Modula-2, Modula-3, Oberon, Haskell, ML...

I cannot give specific examples, but I am pretty sure that you'll have a hard time trying to combine modules generated from different compiler vendors.

Already the first hurdle is that each vendor has its own language runtime that is only compatible its own implementation.

Second, not all languages define a binary ABI on the language specification.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact