[IshKebab]

Compile times aren't that slow, and the language is barely less complex than this insane hack. In fact C++'s complexity allows libraries to make their use a lot simpler. Consider string concatenation in C++ and C. Which is really simpler?

The main reason I can think not to use C++ is that C has a simple stable ABI so you can easily use C libraries from many languages and compilers. But you can always wrap C++ libraries in a C API so that's not a huge concern. Just a pain.

[kbwt]

> Compile times aren't that slow

I beg to differ. C++ encourages placing more code than strictly necessary into header files. Even the standard headers such as <algorithm> add considerably to the compile time, and they keep getting larger with every revision of the standard. When you are making incremental changes, it accumulates to a lot of time spent waiting.

[gruez]

use precompiled headers?

[comex]

Precompiled headers never worked well due to a variety of limitations.

C++ modules, on the other hand, will be like precompiled headers done right. If they ever get standardized. They didn't make it into C++17, and the prototype implementations in Clang and MSVC are incompatible with each other, but I guess it'll happen someday…

[maccard]

> Precompiled headers never worked well due to a variety of limitations.

We use precompiled headers on a large project, we've never had any issue with them (MSVC and GCC)> Care to elaborate on the limitations?

[gruez]

>Precompiled headers never worked well due to a variety of limitations.

want to elaborate? i use MSVC's implementation and never encounter any problems with it. then again, i also don't work on large projects, so i would like some insight.

[wruza]

C++ libraries often add new semantics to the language, and that is not so obviously a benefit. Recently I explored Kiwi project (constraint solver). It is easy to use if you solve specific cases, e.g.:

  Variable x, y, z;
  solver.add(x <= y);
  solver.add(z >= x - y);

But if you need it in meta-way (and I always do, I rarely write non-meta code), you have to unwind all the sources[-in-headers] to find out what Expression is, how does one construct one, write dynamic expression builder, etc. Sources do consist mostly of one-line helper methods/getters/constructors that are nested and intercalled 10-15 times per operation. LPSolve was much simpler in API, since you don't mess with variables and add constraints directly as matrix values.

  double row[size+1] = { };

  /* ...fill row... */
  add_constraint(solver, row);

  /* ...fill row... */
  add_constraint(solver, row);

In the end of the day, both libraries involve identical usage pattern, but for C++ I have to create a convenience unwrapper. This 'convenience' swamp is SO popular in C++. Once you say "++", you have to deal with it all the time, unless you write something really dumb and straightforward. Not to mention most libraries have huge header-only parts due to template obsession. Qt, yeah. It takes forever to compile 20 modules on reasonably priced laptop even with fine-tuned prefix header and -j9.

From the employment point of view, C++ is a nightmare. No one really knows it, and everyone thinks he does. Experienced developers can't tell what explicit constructor is, are confused with move semantics, blink hopelessly on "what is RVO". You actually employ python programmers for sky prices, while all they know is easiest part of C++/stl magic, which is effectively beginner-grade python with low-level bugs and UBs.

>wrap C++ libraries in a C API

Together with "ecosystem" such as std::cool_ptr<std::map<std::bar,std::baz>>. That's a concern.

When I want nice bridgeable object model above C, I use Objective-C or simple embedded language with proper features. Personally, I'm really tired of C++ everywhere.

[favorited]

To be pedantic, the C standard doesn't define an ABI[1] – it just seems that way because implementations follow the platform they're building for.

[1] http://stackoverflow.com/questions/4489012/does-c-have-a-sta...