RotsiserMho

It's disturbing that this is considered normal. I would never work for a company that required this of me.

Mackup (https://github.com/lra/mackup) is a great tool for this. Beware, however, that it creates symlinks in place of your existing files. So if you decide you don't like it, run the uninstall command before removing the Mackup folder or bad things will happen (I learned from experience).

True, but a lot of that functionality can be gained using boost::signals2 and a simple cross-thread queue. (though some may question the wisdom of trading one dependency for another, I prefer my dependencies decoupled from each other). Still, as I said, lambdas are enough for my simple application.

My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I want to use another GUI framework I'd have to refactor that code. Most other build steps occur before or after compilation and are far less intrusive. In short, it's too tightly-coupled to application code.

It's an incredibly fast moving target. Just look at the GTK mess, let alone keeping a wrapper toolkit up to date with other vendors' OS updates. Plus for operating systems like Windows it's not really clear which GUI technology to wrap. All the wrappers I've seen so far wrap the old school Win32 API but many modern applications are written in WPF or WinRT. Supporting all three would be difficult.

Also OS X is a somewhat different beast in terms of human interface guidelines and form layouts so it's really tough to come up with a unified abstraction layer that both supports new operating system features (and UI paradigms) and still provides a reasonably-sized API.

hiro (https://gitlab.com/higan/higan/tree/master/hiro) by byuu (http://byuu.org) is similar to libui in that it wraps native controls. It isn't quite stable but it's very interesting. I love the simplicity of the API.

I avoided Qt for a long time due to what I'd heard about moc being required. However recent versions support connecting lambdas to slots which is sufficient for my relatively simple application to avoid using moc to set up signals/slots.

The low road at that. Nice catch.

Heh

I drive an FRS (Toyota 86) for this reason. It's an absolute joy to drive.

Protection != prevention

I was disappointed to see that concurrency support won't be in Swift 3.0.

Me too. Is something similar available in Rust? I'm familiar with smart pointers in C++ but I love that Swift manages a lot of that mess for me.

As a C++14 programmer, I disagree. for..in syntax is so much clearer and being able to simply specify the range without having to manually increment makes more sense to me. I would love to see something like Swift's stride in C++.

I think the discussion such an article generates has value. I've learned about some nice C++ tools in this thread that I may not have otherwise.

No, all are equally prone to errors if a bit in RAM is unexpectedly flipped. My understanding is that ZFS requires more RAM and possibly more CPU than other filesystems and those costs aren't worth it if you're going to use RAM that can't detect errors anyway.

I've used parts of boost extensively on embedded platforms and cross-platform projects without ever encountering painful runtime bugs. What issues did you have?

This can be avoided by using CMake as QtCreator supports it as a project type. CMake isn't exactly a bastion of simplicity however.

Couldn't that have been found by turning on the signed-to-unsigned conversion warning?

Maybe. No one really wants to make a new C++ without being careful not to make something as convoluted as C++.

Someone mentioned using an initializer list, which is a pretty good option if you don't want to be explicit. However, writing a small helper function or class to automatically (and using constexpr, at compile time) convert between different kinds of points can achieve the same thing without losing the contextual benefits.

Depending on your perspective, this can be a strength of C++. It is flexible enough to be used differently as appropriate for each project.

You just described std::shared_ptr and std::weak_ptr. I recommend doing some more reading on the subject.

In my experience in the embedded world it is at least recognized that RAII should be used. It is fast becoming the exception not to use RAII and now that smart pointers are in the standard, the same goes for them.

There's a proposal to include it in C++17. See also: https://www.justsoftwaresolutions.co.uk/cplusplus/standardiz...

I would just like to say that I love boost. I believe it leads credibility to a project such as this to know that the wheel wasn't reinvented. I seriously don't understand why there's such an aversion to it. Most of it is header-only and the especially useful bits are tiny.

I so wish it were.

I had the same thought and found they have a section of the website devoted to this. Very nice. https://www.touchdevelop.com/docs/creatinginteractivetutoria...

I believe the intent is to sync state between Macs, e.g. a MacBook and an iMac.

That's not modern C++. This is much less noisy:

    #include <memory>
    #include <vector>
    // ...
    // circle and shape are user-defined types
    auto p = make_shared<circle>( 42 );
    auto shapes = load_shapes();
    
    for (auto s : shapes) {
        if( s && *s == *p )
            cout << *s << " is a match\n";
    }

Not sure what MS is thinking.