It's a bit disappointing C seems to be getting left behind in some areas. It's simpler to compile, which in theory should mean that it's more portable.

No it is not.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Many equate "C == what my compiler does", but just like any standardized technology with holes open to implementers to decide upon, portability isn't as people think.

I read Chris Lattner's posts. There are definitely things the standards don't specify that people take for granted (twos-complement for example). C is still an order of magnitude easier to parse than C++ though (especially modern). In theory, implementing and maintaining a compiler for it for a platform should be simpler.

Implementing an effective compiler is another concern entirely, but I would still argue that there tend to be more incompatibilities between C++ implementations than C.

Yes, parsing is way harder because C++ requires the context aware grammar.

However many C++ incompatibilities are actually caused by C compatibility and the goal of having higher constructs that are copy paste compatible with C but with additional semantics, e.g. structs.

So in both cases, to achieve your portability goal the languages would have to be fully specified.

C and C++ are admittedly different languages, but I would think more than less of the code for compiling both languages should be the same. I personally can't see how one language would impede the other.

As a C/C++ user, I'm honestly still not sure why a number of C features have yet to be formalized in C++ (e.g. restrict).

> Thankfully the C++ committee is changing that with C++17.

Which C++17 feature are you referring to? Modules?

The work being done by the SG

https://isocpp.org/std/status

Filesystems, networking, concurrency, ....

Sadly databases died out apparently.

Looks like they're doing what they should've done some time ago and what helped many competing languages get ahead. Between that and recent standards, C++ programming might get really interesting again. Even I might take a stab at it eventually.

Even though I hardly use it at work (JVM/.NET), it was my to go to language after Turbo Pascal. So I still enjoy following and dabbling with it.

Some of the issues C++ had were:

- C compilers were still catching up with ANSI C89 and it was a mess

- C++ being in the process of becoming standardise was even worse. It was quite hard to find out what were the working common features between compiler vendors, specially in terms of semantics

- The C culture that prevented many nice frameworks to succeed, because they were too high level, hence why MFC is such a thin wrapper over Win32.

- Lack of standard ABI in an age people only shared binary libraries.

C++14 and C++17 look really nice, but I doubt C++ will recover its place at the enterprise, beyond performance critical libraries/modules.