The thing is, of all the languages I code in C++ is my favorite. It is the most performant (using C where necessary), and is as easy to code in as JavaScript IMO. C++14 (and higher) feels like coding in Go or Python.

I feel most people don't actually have experience enough with modern C++ and are trying to use the 90's version of C++. The 90's version is awful, and even the modern has a few quirks. However, when you need performance and something less than C it's amazing.

There are no channels, there are no lightweight/green threads, there's no standard HTTP library, no standard crypto libraries, no standard test framework. For certain classes of applications this makes Go significantly more productive and significantly less bug/error prone. Not to mention compile times.

Even the nicest things in C++14 suffer from backwards-compatility-ism i.e. awkward syntax, and endless incomprehensible garbage output from the compiler when you make an error e.g. inside some complex templated code. As C++ devs we manage to live with that stuff but it still sucks.

Even if your code uses some nicer subset with standard libraries you typically need to interface to a whole range of things that do not comply with that subset. Be that something like a Cassandra driver that uses libuv or OpenSSL with its native C interface. Any C++14 beauty that may have existed is gone and your code is now subject to all those subtle memory management, buffer overflow, and concurrency issues.

I used to think garbage collection was garbage but I've start to appreciate how much simpler it makes my life (Even over RAII smart pointers) for very little cost in Go.

Python, Ruby and Javascript are a completely different kind of language so I'm not sure it's worthwhile comparing those to C++. There are many things you can do in Python that you can't do in C++ and that's mostly a good thing ;)

That said there are certainly some classes of applications where there's no substitute to C++. It's also much nicer than it used to be. But it shows its age.

I usually build embedded systems, desktop apps, and even some higher end computing applications. I use QT in conjunction when I need most of that stuff you mentioned, as that framework makes it easy. Also,

> there's no standard HTTP library

I mean, there isn't a standard library, but cURL is easy to use.

I've used C++ with Qt in building embedded applications and my experience was mostly good. Then again Qt had its own types which were incompatible with C++ and a fair bit of work was getting more or less standard C++ mated with Qt. I remember writing a lot of glue code that used Boost.Signals2 ...

On one hand it's true that people who still see C++ as C with classes and don't use things like lambdas, algorithms, smart pointers, STL data structures, are contributing to some hate/misunderstanding of C++. On the other hand, C++ developers who do use the modern features get used to all the quirks and don't understand why others don't see what we see ;) So we just maybe std::move, or inherit from enabled_share_from_this without thinking twice and know the difference between && and & and the new lambda syntax but really, as a developer, most of the time, why should I care? To some extent a camel can't see its own hump.

What you're saying is basically exactly what I would have said 2 years ago before I started using Go more heavily. Now it's mostly C++ because I have to and Go because I want to... Not that Go is perfect but the stuff that it does well it also does easy.

By all means, if your developers are unwilling to learn modern C++, use Go - it's easier to learn. I agree that's it particularly well geared for any network IO-heavy server. C++ can give you better performance, but it probably requires 5 times the effort.

I'm pretty sure the gp was instead suggesting that you should use libcurl, which is the library that powers curl-the-command-line-utility.

The fact that there is a nice subset of C++ which works well is not a valid argument, in practice. As you say, you are forced to include in your projects a lot of libraries, each assuming its own definition of what this subset is, and the union of those subsets can be a monster.

So for some sanity, I always spent some days writing sane, type safe, C++ wrappers.

But this always fails flat when working in teams that don't share the same quality goals, without directives from above.

Thought-trough, modern C++ code is IMHO quite often more readable, elegant and generally more pleasant than anything I've seen in C# or Java so far. But it's all hampered by the poor code some people ham-fisted in before or afterwards...

So, at least for me, C++'s biggest drawbacks are many of its users, not the language itself. Interestingly, that's something thad e.g. the Python community seems to have way more success managing, although Python as a language checks almost all boxes that should - in theory - foster quick hacks...

There are a few things that I'm still not quite happy with.

* It's still incredibly cumbersome to set up a project

* Setting up a proper build system is tedious, especially if you're targeting multiple platforms.

* I'm missing some "functional" methods attached to the collections, e.g. find, filter, map, some, each, ... Afaik some of them exist as functions that take 2 iterators and a lambda but that's just plain ugly and unreadable. Instead of

    std::find_if(list.begin(), list.end(), condition});

    list.find(condition);

If you already have a compiler installed, you can go from nothing to knowing how to build a library, executable and an installer for multiple platforms in just a couple of hours with the CMake tutorial: https://cmake.org/cmake-tutorial/

If I want to use an external library in a C++ project, I need to:

* download it from the website / GitHub

* build it from source

* add the library into my CMake file.

Whereas in Gradle, I add a single line to one file and the library is installed on my next build attempt. Full stop. There are no more steps.

C++ makes it searingly painful to get a project going. I'm honestly afraid to add any new libraries to my projects because I know that (at minimum) that means I'm sacrificing an afternoon to resolving new errors.

That you have to compile anything yourself is a byproduct of the fact that different platforms have different ABIs, combined with the lack of proper package management on platforms like Windows.

What I find the most enervating about CMake is that somehow everyone agreed (at least to some degree) to use the worst cross-platform build tool in existence. Instead of a build system based on solid principles we got a "hack your own build" starter kit in which you have to look for dependencies yourself ^1 combined with a build script language that is worse than the languages it set out to replace. How can anyone honestly be happy when switching from makefiles to this monstrosity?

^1 And no, the FindX scripts never work properly everywhere.

I have been in places where demanding python just wouldn't work. Either a specific version was needed for something else and managing the dependencies was a pain or we were already reliant on other scripting languages. I think this kills any other language as a build tool.

There are zealots for every IDE and some IDEs require special project files. If your build system doesn't seamlessly integrate most then it couldn't have made it. Scons never worked with IDEs I liked, Know how to get it cowkring with QtCreator? Other will demand vs2015r3 integration, how do you do that?

Then then there are the build systems you didn't mention, but the minimalistic ones. There was even one that was entirely stateless, but it was also too inflexible for most real builds.

CMake very carefully walked a thin line that dodged all these issues and the fact it is a giant pile of global mutable shared state simply doesn't for all but the largest builds.

Really? I feel the opposite. At least when I write makefiles by hand I understand them fully.

Cmake just confuses me, I'm not sure it's such and improvement.

- automatically collects executables to build from the .cpp files in two distinct directories

- uses the CPP preprocessor to only link in the object files in the rest of the project associated to headers used directly or indirectly by the executable .cpp files

- allows me to select the compiler using an environment variable

- allows me to pre-define some common options for the three supported compilers (e.g. to disable specific warnings with ICPC and increase the template instantiation depth for Clang)

- allows me to specify whether I want to rebuild everything or just a single executable and whether this should be copied into the external directory contained in my $PATH

Yes, putting this together was a bit of work (208 lines for the Makefile, 34 for the dependency generator and 15 for the script which puts the current output of `git diff` into a CPP #define), but now it only rebuilds the things needed, only links in the object files needed and allows me to quickly test multiple compilers. Getting all this with CMake seemed extremely difficult when I last looked at it.

Addendum: I should add that my only external dependency is Boost and LAPACK and I essentially ask the user to point me at their Boost base directory and plug in their LAPACK link line -- this works well for the target audience (fellow physicists who are used to all sorts of horrible toolkit installation processes), but I understand it may be annoying to the more general public (or if you have more external dependencies).

Do you mean that you, then, have to rebuild your project from scratch?

Also, you can do stuff like auto blah = with( list ) << sort( ) << filter( predicate ); now. It's not in the std lib but it is doable

First, there are containers that do have a find() method, std::map, for example (although not on a condition). It could be a wrong impression, but to me this tells something. Perhaps, if I intend to do a search, I might be better off using a different structure (rather than a list) that is more suitable for searching, or maybe a different - more efficient - algorithm (such as binary_search(), if applicable).

Second, if you use a container as a part of your own class, defining a find() method is trivial.

I have no doubt that there are other, more technical reasons for the standard library being the way it is, for example, the idea of separation of algorithms from containers by means of iterators.

And functions like map (apply function to each element of a collection), filter (return new collection with all elements that match a condition) and possibly some others have to be applied to all elements in a collection anyway.

> Second, if you use a container as a part of your own class, defining a find() method is trivial.

It is, but I'd rather not have to define 20 trivial things when I start a new project.

There is a tool called waf (https://github.com/waf-project/waf) which is getting way too little love, but is really the perfect build system for C and C++ projects:

    from glob import glob
    def options(ctx):
        ctx.load('compiler_cxx')
    def configure(ctx):
        ctx.load('compiler_cxx')
    def build(ctx):
        ctx.program(source = glob('src/*.cpp'), target = 'your-program')

1. Developers trying to use Waf never realized that they were supposed to check-in the python BLOB into the repository rather than using a system package. Consequently developers would find a lot of regressions in the syntax for builds.

2. Developers had to add the root of the project to their ${PATH} for it to work properly. This may not seem like much... but if you don't know better, it takes people by surprise.

3. Build scripts simply broke between Waf versions too often. Perhaps you can blame this on package mantainers... or maybe distribution maintainers.

4. There was never an overwhelmingly compelling case for `waf configure`. `cmake CMakeLists.txt` borrowed syntax from the C preprocessor which people were comfortable with. `autotools` had thousands of recipes for `./configure`. And adding configuration options to `scons` via command line options always worked just fine.

5. Using the Python language encouraged developers to implement actions which were not idempotent resulting in changes which were not properly tracked by Waf.

6. The code provided no obvious benefits to SCons aside from a little speed, and it was light years slower than CMake, autotools, or simple GMake.

2. Either run "chmod +x waf ./waf build" or "python waf build" Adding directories to $PATH isn't necessary.

4. I think the use case for configuring and building with the same tool is very compelling. Like:

    def configure(ctx):
        ctx.check_cfg(package='gtk+-2.0',
                      args='--cflags --libs',
                      uselib_store = 'GTK-2.0')
    def build(ctx):
        ctx.program(source = 'blah.c', 
                    target = 'blah', 
                    use = 'GTK-2.0')

Because it is all in one tool, it is very easy. Other build systems complicates it by keeping configure and build separate.

5. True, but I prefer more power over less.

6. Tomas Nagy published some benchmarks here: http://www.freehackers.org/~tnagy/bench.txt Waf was 12 times faster than SCons and about 20% slower than make.

CMake was much easier for me to understand. Sure, the language is hot garbage, but the mental model of how it functions is simpler. I did something similar to the above and it took an afternoon of learning.

I don't want to diminish your experience, but I think you might be doing something wrong there. It doesn't need to be torture.

https://github.com/Akagi201/learning-cmake

    random_device rd;   // non-deterministic generator
    mt19937 gen(rd());
    uniform_int_distribution<> dist(4, 18);

    // for testing purposes, produce byte stream that from lines of text
    auto bytes = range(0, 10) |
        flat_map([&](int i){
            auto body = from((uint8_t)('A' + i)) |
                repeat(dist(gen)) |
                as_dynamic();
            auto delim = from((uint8_t)'\r');
            return from(body, delim) | concat();
        }) |
        window(17) |
        flat_map([](observable<uint8_t> w){
            return w |
                reduce(
                    vector<uint8_t>(),
                    [](vector<uint8_t> v, uint8_t b){
                        v.push_back(b);
                        return v;
                    }) |
                as_dynamic();
        }) |
        tap([](vector<uint8_t>& v){
            // print input packet of bytes
            copy(v.begin(), v.end(), ostream_iterator<long>(cout, " "));
            cout << endl;
        });

    //
    // recover lines of text from byte stream
    //

    auto removespaces = [](string s){
        s.erase(remove_if(s.begin(), s.end(), ::isspace), s.end());
        return s;
    };

    // create strings split on \r
    auto strings = bytes |
        concat_map([](vector<uint8_t> v){
            string s(v.begin(), v.end());
            regex delim(R"/(\r)/");
            cregex_token_iterator cursor(&s[0], &s[0] + s.size(), delim, {-1, 0});
            cregex_token_iterator end;
            vector<string> splits(cursor, end);
            return iterate(move(splits));
        }) |
        filter([](const string& s){
            return !s.empty();
        }) |
        publish() |
        ref_count();

    // filter to last string in each line
    auto closes = strings |
        filter(
            [](const string& s){
                return s.back() == '\r';
            }) |
        Rx::map([](const string&){return 0;});

    // group strings by line
    auto linewindows = strings |
        window_toggle(closes | start_with(0), [=](int){return closes;});

    // reduce the strings for a line into one string
    auto lines = linewindows |
        flat_map([&](observable<string> w) {
            return w | start_with<string>("") | sum() | Rx::map(removespaces);
        });

    // print result
    lines |
        subscribe<string>(println(cout));

C++ 11 and 14 don't do anything in terms of build times AFAIK -- they probably make them worse. I'm hopeful that modules will make a difference, but at first glance they seem awfully complex.

And also metaprogramming. In Python, I use Python for metaprogramming. In C++ I have to switch to this weird template language. I'm a template user, and they are mostly great to use, except for build times. Template authors are a completely different kind of C++ programmer.

This was added in C++11.

In the header you state something like:

    template <typename _Tp>
    class Example {
    };

    extern template class Example<int>;

    template class Example<int>;

https://msdn.microsoft.com/en-us/library/by56e477.aspx

> Note: The extern keyword in the specialization only applies to member functions defined outside of the body of the class. Functions defined inside the class declaration are considered inline functions and are always instantiated.

[0] https://root.cern.ch/cling

I understand what you are saying but for a newcomer it's hard to discern the differences as in "oh thats a very 90s way or thats a very C++ revision xx way of doing things." I think this is part of what makes it so overwhelming to learn. The scope of the language is already quite large and then when you pile the different versions on top of that.

I am curious if you could share any advice on that for a newcomer to C++?

Is it practical to only learn the most recent revision/standard? I would thing its good to know the good and bad if only to understand what rev or style you are looking at without being confused. But maybe that's not necessary or practical?

These were already possible even before C++98 got released.

- Code new work or updates in as little time as possible

- Let a large group of devs of varying skills produce a high quality code base with the least amount of overhead/rules/babysitting

- Achieve the the best defect rate/quality given finite time

- Require the lowest cognitive load to reason about things

- Performance is high enough to meet a point of diminishing returns given the problem at hand

In my opinion, no existing language satisfies these two simultaneously:

> - Let a large group of devs of varying skills produce a high quality code base with the least amount of overhead/rules/babysitting

> - Performance is high enough to meet a point of diminishing returns given the problem at hand

For me personally, a few things seem broken, but there are work-arounds. Some things are very confusing for me, and I might get past those.

However, I work with some really smart people (Masters and PhDs in math, physics, engineering), and very few of them have patience for programming language complexity. They can mostly get by with a subset of C++, but it's not optimal. Rust is just not simple enough, and the "overhead/rules/babysitting" would be pretty hefty. I wish that was not the case.

Do people "enjoy" C++ because they weighed the important concerns and thought it was the best objective choice for their work overall? If so I understand it, otherwise we're talking about a hobby language.

Again, I only see how subjective judgments are relevant for hobby projects, which is fine when nothing is at stake.

What do you mean by "most performant"? Is there some meaningful difference between that phrase vs. "fastest"?

C++17 is so full of good stuff I'm considering beta compilers just to get it. Soon Python and Ruby won't have any advantages left in writing beautiful, clear, correct, bug-free, and easy to read code and C++ will still run 200x faster.

Structured bindings are going to be amazing! Yea we didn't get modules, but I for one am psyched about this feature alone.

If only they were faster to upgrade compilers at work...

Come on, it's not like they've added garbage collection.

The clever combination of declarative management for common cases and reference counting for complicated cases looks like the winner in the long run.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

Reference counting is definitely a method of garbage collection.

So if your program allocated less than available, doing nothing would be a valid GC strategy as your program never hit an upper bound in what it can allocate.

I found that an interesting way to think about the problem because it's more concerned with what GC enables instead of what it strictly does. The former is always the same, no matter the GC implementation, but the latter can vary considerably (doing nothing, reference counting, mark-and-sweep, full concurrent and compacting GC, ...).

Interestingly, this is also the description of Virtual Memory. https://en.wikipedia.org/wiki/Virtual_memory

GC is an abstraction that can work well but can also interfere with how a developer thinks.

Yep, this is a big issue.

Another good example is copying arrays of primitive types with for loops instead of using intrisics like System.arrayCopy().

Or using lists instead of arrays.

Sure there are many situations where there is no another way other than step out of the JVM into C++, but many could be avoided with better code as well.

http://gchandbook.org/

Chapter 5.

One of the best CS references in GC algorithms.

I can post links to 70's papers if you wish, specially ones related to Lisp research.

See page 6, remark 7 in 'Uniprocessor garbage collection techniques', Paul Wilson:

http://scholarworks.rit.edu/cgi/viewcontent.cgi?article=1322...

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267...

Also, there are the C++/CLI and C++/CX that support GC at language level.

Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler.

We're talking about garbage-collected languages (and "language" traditionally includes the standard library), not garbage-collected-only languages.

I mean, by your definition, C# also doesn't count, because it has unmanaged pointers in it.

In C#, GC is part of the language semantics and its interaction with unmanaged pointers is well defined in the language semantics standard, including how the memory is pinned when unmanaged pointers need to access GC allocated memory.

If reference counting is a kind of GC, and the standard library offers reference counting, then the language offers a kind of GC - same as if the language itself had a built-in refcounted pointer. There's simply no practical difference here.

It only makes sense to talk like that, if the language semantics define a relationship between the language and library requiring the library to always exist as a form of runtime and how the use of that runtime relates to language constructs.

If I can just throw away the library and replace it by something else where those types aren't available and still make use of 100% of the language features, this relationship doesn't exist.

There's a single document defining what is ISO C++. It defines both the language and the standard library. Therefore, to "write in C++", by default, means to write code that uses and relies upon both the language semantics and the standard library functionality. Which means that std::shared_ptr etc is readily available, and is the standard way to use refcounting-based GC in C++.

Hence, ISO C++ is a language with optional refcounting-based GC.

Then you also shouldn't say that Swift is garbage collected.

C++ language definition doesn't give any special treatment tostd::*_ptr<> types regarding compiler semantics. They could be be something else.

Library types like std::shared_ptr don't really count to say that a language has a GC, because their use, specially their correct use, is not enforced by the compiler.

http://gchandbook.org

Although, there are conservative GCs for C that replace malloc () and make fre () a nop, they cannot release all memory properly due to C semantics.

You'd have to elaborate on that an awful lot to be at all persuasive.

> Rust and Swift

You were comparing C++ to Python and Ruby. We're talking two different paradigms here.

I mean we have destructors which handle so much more than garbage memory.

Close files, release mutexes, close sockets, cleanup thread pools, manage the lifetime of anything. One time I opened a web browser in the constructor and closed it in the destructor, and I had full confidence that no matter what crap happened in the middle my app never leaked whole browsers.

Firstly, what exactly is the difference between make_unique and plain old unique_ptr? Why do I need to include a separate template to use the former?

A related issue I faced today. Say I want to create a std::vector of objects. From what I understand, I have three options.

1) Use raw pointers, but be sure to cleanup using delete.

2) Use shared_ptr, which will ensure that your object is safely deleted once no one is referencing it.

3) Create a stack allocated object, then push that onto the vector. The vector will create a shallow copy of the object, and the original copy will be deleted at the end of the current scope.

In this scenario, I wouldn't be able to use unique_ptr, because that would mean that both the vector and the local scope have pointers to that object. Am I correct?

Are there other options for achieving this that I don't know of? Also, which one is the best approach for the general case? I ended up using shared_ptr and it seems to be working fine... I think.

The make_unique function uses variadic templates to take the arguments to your constructor:

    auto oldway = std::unique_ptr<Foo>(new Foo(1, 2));
    auto newway = std::make_unique<Foo>(1, 2);

> I wouldn't be able to use unique_ptr, because that would mean that both the vector and the local scope have pointers to that object.

Yeah, if you're using unique_ptr, the pointer is uniquely owned in at most one place at a time. For your situation, I think the vector should probably own the objects, and you borrow them with references, iterators, or pointers (via the get() method). Be wary of holding on to those references though (the Rust fans will be quick to point out the dangers here).

A fourth option, which you should consider unless your objects are expensive to copy, is to make your objects copyable and not use unique_ptr or shared_ptr at all. I think it's much simpler to reason about objects as values than it is to reason about objects as smart pointers or (dumb) references.

> I ended up using shared_ptr and it seems to be working fine... I think.

Go with what works for you, but shared_ptr makes additional promises about thread safety and interactions with weak_ptr that increase its runtime costs. I wish shared_ptr was simple by default and that there was yet another smart pointer type for when you need those additional features.

    // definition
    foo(std::unique_ptr<bar>, std::unique_ptr<baz>);

    // call
    foo(std::unique_ptr<bar>(new bar), std::unique_ptr<baz>(new baz));

1. new foo 2. new bar 3. unique_ptr ...

Now, if constructor of bar throws, you've leaked foo.

With make_unique, construction and smart pointer acquisition is a single atomic operation - if it throws, everything gets cleaned up.

I think technically you could use unique_ptr and transfer ownership (move) when pushing into the vector, but the underlying "bad pattern" here is that you almost never want to have a vector of (smart) pointers. The vector should own the objects directly.

make_unique is just a convenience function for creating a unique_ptr without having to write "new" yourself. It returns a unique_ptr.

Vectors already own their contents, so there is no need to use unique_ptr here. The objects will be allocated on the heap either way, and you don't need a stack object either. Just push or emplace the object into your vector and be done with it. When the vector is deleted, so will its contents, automatically.

Is there any overhead (e.g., copying or moving), or potential for memory leaks?

But don't use new. Just push/emplace it into the vector. Perhaps ask more on stackoverflow.

> The objects will be allocated on the heap either way, and you don't need a stack object either. Just push or emplace the object into your vector and be done with it. When the vector is deleted, so will its contents, automatically

I guess what you mean to say is that emplace_back will do the allocation and lifetime management. But using push_back on a stack-allocated object is going to result in a copy.

push_back with a stack object will copy the object, yes. Emplace_back with a stack object will also, they are not much different. But if you emplace by creating the object inside the emplace call itself, then there is no copy.

see the examples here:

http://en.cppreference.com/w/cpp/container/vector/emplace_ba...

Then with RAII you can clean up any kind of resource. Most languages have pretty rudimentary tools for closing files and worse for releasing mutexes. These tasks are almost easy to get right in modern C++.

    int main() {
        with_open_file_for_writing("foo.dat", [](FILE* fp) {
            fprintf(fp, "old style I/O, automatically closed\n");
        });

        return 0;
    }

So it's totally doable in library without cost to those that do not need it.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#reference-c...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#asynchronou...

Exaggerated, I know, but it's not like your post was particularly nuanced.

Reference counting is safe with a DAG (not just a tree), but I get your point. For the times I've needed an arbitrary graph data structure, I used an adjacency matrix to store it.

Does that mean C++17 will finally get support for the generator pattern?

Boost.asio provides stackless generators [1] implemented purely in C++, by (ab)using the preprocessor and the switch statement.

[1] http://www.boost.org/doc/libs/1_62_0/doc/html/boost_asio/ove...

But there will be books, and good ones. Next year probably. The compilers aren't even ready yet.

IMO, C++ has both a lot of necessary complexity (due to its lofty goals) and a lot of unnecessary complexity (mostly due to the C back-compat). I think this is the root of a lot of the "C++ sucks!"/"C++ is great!" arguments; when people only see one half or the other.

My bottom line with C++ is that it tries and mostly succeeds to do a lot of hard things, but has questionable design decisions that make these things even harder than they need to be. For a while we just had to live with that because if you wanted a language that was both fast and high-level, C++ was the only game in town. I think that's no longer true, which is why I'm such a cheerleader for Rust: I see it as trying to have all the good things (necessary complexity) of C++ without the baggage.

C++ is more like an ecosystem of about a dozen languages. You can divide it into 4 languages chronologically. You can add a lot more by categorizing by use. If you pick and choose properly, you can set up a subset of C++ that makes it a great language. Half the computer programming managers out there have below average taste, however.

This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs).

Which describes my current work situation. However, this would seem to imply that a startup or a small project would be able to set up a C++ project with a beautiful, cohesive subset of C++. Your point is something that people who are serious about language design for programming "in the large" should definitely pay attention to.

This is one reason why I doubt adding more features to C++ (making it 5) is going to make the language any more pleasant to use (outside toy, one person programs).

How do you distinguish between one, two, three, or four person projects? Can you really make such a blanket statement about all the different possible codebases that exist? Methinks you exaggerate.

(And I say this as a former dyed-in-the-wool minimalist Smalltalker!)

(In theory of course your buddy could use a style and feature-set really close to your own and make it all a nice abstracted API so you don't need to look inside etc, but you get my point)

You've never worked in a small shop where there was a good coding standard and everyone stuck to it? That sort of thing actually does pay off. I've seen this in my professional life.

(And when that was out of the question, C++11 and later usually were as well)

I know C++ since the C++ARM days, it is one of the languages I like most despite its warts, teached it to first year students before C++98 happened.

Nowadays I spend my work hours in Java and .NET stacks, but still do occasionally use it, when needed.

I never worked in a company, with exception of my time at CERN, that actually followed C++ best practices.

So yeah, there are lots of companies making good use of C++, as proven by CppCon and C++Now talks, but they seem to be the minority, when you take into consideration the ones whose main business is not selling software.

At least I was pleased to see the BMW presentations at FOSDEM, where they mentioned moving from C to C++14, as a means to improve safety on car systems.

I should be more thankful about my current job, then. I guess a good heuristic for judging a language is to go to conferences and see what is portrayed there, then "dividing by 8." That will get you to about the level of the average shop.

It's dealing with an existing code-base or team that doesn't agree on what "awesome" is or supporting old compiler/platforms or 3rd-party dependencies that turns C++ into a nightmare.

Basically, C++14/17 is an awesome language when working on your own thing, in a vacuum, without any dependencies.

If the team can resolve differences, it functions. The other commenter seemed to imply his team didn't.

Rust and Haskell are complex languages (as compared to say C). And it's not clear for a lot of people that their complexity is any better than C++. But by trying to garanty an ever increasing level of correctness and safety, they booth creating a large set of computation that are conceptually easy but very hard to express in a way that is correct to the type system/borrow checker.

I actually like modern C++ well enough for the niche described here; lambdas (and the control they offer over captured variables), type deduction, ranged fors and the like make it pleasant enough to write for being as performant as it can be. I've written many more lines of C++ than Rust. But it's still apparent that language-enforced invariants are quite a different species from conventions that will enable safe programs if everyone uses them correctly at all times. You can maybe guarantee that for a team, but can you guarantee it for several teams? Can you guarantee it for every external dependency?

I can imagine plenty of pragmatic analyses today ending up with C++ as the ideal choice of language, but the monomaniacal focus on Performance ignores ecological concerns like these and also mostly doesn't grapple with the fact that there's plenty of low-hanging fruit to get to performance-wise in any project before something like a fundamental 1.2x performance penalty on Rust's part really matters, especially considering how domain-dependent that number is likely to be. Pure speed is a pretty poisonous obsession in our field, IMO, and I think we've reaped the whirlwind for it already. It's time for a more holistic outlook.

Meanwhile, there is also this tendency of software getting slower, and this other tendency of code getting trashed because it was written as a short term solution.

C++ is designed for high quality, meaning taking more time to write a better solution. It's more thought towards industrial long term quality than market quality. I guess a bad analogy would be engineering versus maintenance. There is often much less engineering to do than maintenance.

I just don't believe that at all, performance and backwards compatibility has been trumping quality throughout it's development.

Even in C++, I always had bound checking on my own classes and always make use of the validation flags in VC++.

It never mattered to the type of applications I was involved with.

Firefox now uses it in release builds (for vector-like objects) for security reasons, and IIRC there was no real performance impact.

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- C. A. R. Hoare, Turing award lecture in 1980, http://cacm.acm.org/magazines/1981/2/10949-the-emperors-old-...

We don't believe such a thing exists.

Our competitors do a bunch of code generation to accomplish the same things in Fortran that we do with templates and policy classes.

Sometimes, for shits and giggles, I'll prototype algorithms in Haskell or Common Lisp or what have you and, I have to say, the experience isn't really all that compelling, and this is without introducing MPI and all the associated headaches of working with MPI in something it doesn't support first-class.

I only use Fortran just for low-level number crunching, and I must say I have yet to miss C++ templates here for this kind of stuff. I'm curious, what is your typical use of templates in your simulation code?

Apart from templating over floating-point precision, we use templates and policy classes to do a lot of the code reuse / flow control you'd use run-time polymorphism for, but without the overhead of virtual function calls. This is pretty useful for us, because our simulation algorithm has a lot of sub-parts that can be done in different ways. Rather than having a bunch of switch statements (or virtual function calls) in inner loops, we can have that switch statement once, in a factory object, and return instances of objects templated over the correct policy class so that we don't have to branch in inner loops.

One of our main competitors is on the Fortran / Python plan. Our application has, instead, a few proprietary input formats (one XML-ish, and the other binary to be used with a GUI). This has its drawbacks (i.e. rolling and using our own Python-based macro language for use with the XML-ish input files). The CEO tells me, though, that this is actually kind of a godsend from a support perspective, because there is a point where all of the customer's simulation logic is frozen into a text file, which we can then debug (this is in contrast to the Python / Fortran approach, where the customer's simulation logic may be very tightly coupled with our own code).

Have you looked into a language like Julia or a framework like Charm++? I've seen these used in research papers, but I'm curious if these are used out in industry.

If you are looking for something like C++ in terms of performance and has a nicer syntax, you should try the D programming language. It's very nice to use, as fast as safe C++ code (you can write unsafe C++ that is faster), has stronger typing, templates, mixins, and can interface with C /C++ libraries.

I've moved my personal projects over to D, I've started writing a game with OpenGL, SDL, ASSIMP, Devil and it's much easier than C or C++.

Some links for those who are interested:

Main website: http://dlang.org/

Package manager: http://code.dlang.org/

Some interesting documentation pages:

Interfacing with C: http://dlang.org/spec/interfaceToC.html

Interfacing with C++: http://dlang.org/spec/cpp_interface.html

Templates: http://dlang.org/spec/template.html

Inline Assembler: http://dlang.org/spec/iasm.html

Status of various platforms: https://wiki.dlang.org/LDC

For instance using the json for modern c++ json parser, you can write this:

myclass c = json_node;

and it compile time statically checks that a json->myclass deserializer exists, and gives sane errors if one of the (recursive) subfields of myclass does not have a json deserializer.

This makes json processing in python look like blood letting, and is close (until runtime) to the experience I'd expect from ocaml and other functional languages.

https://github.com/nlohmann/json

But it robs a lot of much slower languages of their best value proposition. You can now do it all in C++ with correctness guarantees and still run 10x faster than most strong typed systems.

we prefer to call it type deduction not to upset type theory purists.

C++ isn't "good" or "bad", it's just OLD (and is backwards compatible with an even OLDER language).

We are continually learning which language abstractions give a lot of implementation leverage (e.g. garbage collection), and which introduce unnecessary complexity.

Any new(er) language has the benefit of incorporating those learnings into the language design.

Putting garbage collection in that basket is controversial and lately the evidence is piling up against it.

Notice how new important growing languages like Swift and Rust don't have garbage collection and programmers don't miss it. GC is more and more restricted to low performance languages like Python, Javascript, and Ruby and a few specialized highly tuned and expensively engineered exceptions like the JVM and obscure LISP engines.

And if you've ever tried to program responsive, interactive, predictable, or time-critical systems, you know that GC is ruinous and awful for those applications. Meanwhile languages like Rust, Swift, and C++ can be used for everything from systems programming to games to low power mobile apps to scripting.

Regarding responsive interfaces: pure reference counting is particularly problematic for this, because an unbounded amount of work may happen every time an object's reference is decremented (because the object might be freed, which causes other objects' references to become zero, etc). If this happens inside a critical section Your Life Is Pain. At least you can control when this happens by taking and then dropping an additional reference. (See Obj-C's allocation pools.)

C++'s shared_ptr<>, BTW, is also reference counting, and suffers from the same problem. So it's technically correct (which is the best kind of correct) to say that C++ has garbage collection too.

You can twist words and say that shared_ptr means C++ has 'garbage collection' but I doubt anyone would agree with you if were were to word it like:

"C++ has a garbage collector"

Ref counting is a form of 'garbage collection' in so far as it is a way to release memory, that's about it. I certainly wouldn't consider Rust's Arc<T> a 'opt in garbage collector'.

In contrast, C's automatic storage duration for stack-allocated items ( http://en.cppreference.com/w/cpp/language/storage_duration#S... ) and Rust's system of ownership for heap-allocated items are things that I'd consider "static lifetime determination".

The term has been used that way since I first heard it back in the '80s, so it's probably not a battle worth fighting at this point.

Yes, of course, there's a formal sense under which reference counting is just an outlying position within the broader world of garbage collection, but from an engineering point of view, it's a significantly different set of tradeoffs, and reference counting doesn't really qualify as the same thing when you're deciding how to structure your program.

Wikipedia lists both tracing and reference counting as forms of GC... hell, when interviewing at Microsoft I was asked to describe the two primary families of GC, expecting tracing and ref counting.

Terminology is useful right up until it isn't. Resting on definitions rather than seeking proper descriptions is a great way to fail spectacularly.

https://www.youtube.com/watch?v=45trtAfWhYg

Not a random dude on Internet.

If you're right, you're just some guy referencing an authority. Yay you. If you're wrong, you're totally ... all over the point of what someone else is saying. Instead of trying to force us to see how you're right, why not try to see how someone else isn't wrong?

The papers of computer science, written since the field exists, speak for themselves. One just has to read them.

It's true that there can be unlimited work done in reference counting. Of course, it's true there can be unlimited work in any function of any program. [0] With reference counting a programmer can fix the amount of work to be done and when in deterministic fashion. With garbage collection, there is no such power. The gc decides when it will work and you cannot control or predict the interruption.

You cannot produce serious interactive or time sensitive control software like that. You certainly can't write system software like that.

[0] https://en.wikipedia.org/wiki/Halting_problem

Reference books in computer science, acknowledged by the experts in the field, happen to disagree.

http://gchandbook.org/

In common usage, I don't hear of languages like C++ described as a "garbage collecting language". That usually describes Java, Python, etc.

Having RC library types doesn't make a language GC, because their correct use is not enforced by language semantics.

hellofunk: Then C++ is also garbage collected.

yourself: Kind of, but only because C++11 defined a pluggable GC ABI.

This is the sort of discussion that is far more fruitful than a pedantic argument over the precise meaning of a term of art in a field that is rapidly advancing. And if the academic community really is obsessed with this, then that is unfortunate.

The algorithmic complexity of a sweeping collector is identical to that of a reference counting collector that can also break cycles. See A Unified Theory of Garbage Collection at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146....

A reference counting collector that _cannot_ break cycles (like in Swift) might have lower algorithmic complexity. I'm not sure.

The biggest bone of contention with reference counting is the constant adjustment of the reference count of objects on the stack. OTOH, the bone of contention with sweeping collectors is constantly walking all extant objects, including ones not directly on the stack.

There are various optimizations you can make to one or the other or both; many arguments about how real-world scenarios tax one or the other model; and many arguments about which is easier to optimize. But at the end of the day reference counting is no worse in terms of algorithmic complexity than sweeping. What matters most will be the quality of implementation. Is the compiler smart enough to know that an object passed 3 routines deep doesn't really escape the stack scope? If it can do that, it can elide all the cost of either approach.

I have trouble believing that behind-the-scenes escape analysis is very effective on real-world code. Look at how much painfully explicit source annotation Rust found they needed.

Like you said, need to update the reference every time it's moved.

malloc becomes much slower, compared to a GC language (with a compacting GC) where malloc is effectively just a single add instruction.

free also needs to do a lot of bookkeeping while the GC language doesn't need to do anything.

Multithreading introduces another set of issues when dealing with refcounting that is not a problem with a GC.

Reference counting is very predictable. And if you see a bottle neck you can start fixing it.

And with ARC (Swift/ObjC) you get even compiler support to optimize all ref counting administration.

Further malloc doesn't have anything to do with ref counting as ref counting sits on top if it.

Further, GC languages also need to do book keeping: Generations and Compaction.

For malloc, the benefit with a compacting GC is that the free memory will always be in a contiguous segment. Therefore, a malloc operating is similar to a stack allocation in that all you need to do is to move a single pointer. Without a compacting GC, you need to search a tree whenever you want to allocate memory.

http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

"Reference counting is a form of garbage collection"[1]

[1] https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

For me the underlying technology is not very relevant, what matters is "do I have to worry about exactly when the resource is going to be dropped". I use the resource and when I stop using it it'll probably be deleted soon-ish. At any rate it's not really my problem (at least in a perfect world).

You say "With reference counting [...] you keep track of your allocations and release them when you're done with them" but that's not really true, I don't keep track of anything, the language or library does. I can't really tell by looking at some code in isolation when or how the resource is destroyed. The GC takes care of that.

Some languages like python, Java, Go or PHP have 1st party garbage collection that's active by default and other languages like C, C++, Rust and friends have optional 3rd party GC implemented as libraries (reference counting or otherwise).

I really don't see what's so controversial about this.

Swift is using reference counting which is a form of garbage collection.

Or (hahahah!) Symbian C++?

Ah, I see, you meant C++11-without-thread_local-because-CUDA-requires-an-older-XCode. Got it!

More seriously, the large enough Noto Sans font with a hint of extra weight renders so gorgeous in Firefox (it's even bearable in Chrome!). I wish all webpages were as readable.

As for the content, well, going back to: https://eklitzke.org/c++-java-go-and-rust I think the problem of the author is that he doesn't realize it's possible to do much better than C++. Claiming Rusts' ownership and borrow checking is exactly equivalent to std::unique_ptr or that Rusts' concurrency support is comparable to std::thread betrays very deep nativity, misunderstanding or just a mindset that can't see beyond what C++ offers.

It is also essentially impossible to know that your code is well-tested: even when using something large and well-known like Boost, its authors cannot know what will happen when you substitute in 4 of your own types (my bet is “result not quite working as intended; obscure bugs added”).

I use templates but I am quite aware of code complexity and I essentially stop when the templating goes too far.

Somewhere along the line, we seem to have gotten into a mode of wanting generic code at all costs. Why? It is just fine to expose a few common specific methods when those are very helpful and clear (such as classes exposing a “string value”, “integer value” and “float value” instead of trying to provide some single partially-specialized template mess of a method that manages to still not quite work right in every scenario).

I know. Years ago I proposed a vector library for 2, 3, and 4 element vectors [1] as a standard. The immediate complaint was that it didn't use templates.

[1] http://www.animats.com/source/graphics/algebra3.h

I don't blame glm for picking the latter. Every option is painful, but templates might be a little less so.

One of the projects I'm working on could have just as easily been written in c++ instead of go.. except that in go starting the project and building it involved

  mkdir my_project
  # hack
  go build

As much of a PITA it is trying to learn rust, getting the toolchain working and starting a new project was not one of the issues I ran into.

That's a start for what you want.

https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...

cmake is pretty awesome at handling dependencies; our build process grabs dependencies from git and adds them to the project. Yes, there is more overhead and a learning curve, and if you are running a simple server there are probably better choices; we use a ton of python for these things, and wrap performant code in cython.