Currently we have to disconnect the slot ourselves when its not needed. This is a bit error prone as we might forget to disconnect a slot in some cases leading to use after frees and invalid reads.

This change proposes ScopedConnectionHandle which is a thin wrapper over ConnectionHandle. It automatically disconnects on scope exit.

As @jm4R noted in #24, because a Property emits the moved signal when moved, its move constructor cannot promise noexcept.

This also warrants a minor version bump to v1.0.1

This PR closes #24

The move constructor of Property is marked noexcept, but - as long as it emmits public moved signal - it can throw from any slot. Simple example:

TEST_CASE("Nothrow move")
{
    try {
        std::set_terminate([] {
            std::cerr << "TERMINATED" << std::endl;
        });
        Property<int> p;
        p.moved().connect([&] { throw 0; });

        Property<int> p2 = std::move(p);
    } catch (int) {
    }
}

The program will call std::terminate as it throws from noexcept function.

Note: Requires all doxybook output to be in the same folder. However, now links from the /latest/ version will always also point to /latest/. Furthermore we can set all canonical links to point to /latest/. This should improve our SEO for all pages where we have multiple versions.

As the links for our subpages have now changed, we should check that we don't have any outside links pointing to specific classes (i.e. in our blog posts) or set up redirects for any Classes/, Namespaces/, Examples/ sub-links.

This might also warrant a change in the Minor version number, so that all old links to 1.0.0 docs still work.

The moved Signal is problematic, as we can no longer guarantee noexcept move behavior of Properties, if anyone is allowed to connect a slot to the moved Signal. (See #24)

By making the moved Signal private within KDBindings, we can have control over what code is executed by it. This allows us to keep the noexcept guarantee on the Property move constructor/assignment.

This also warrants a version bump to v1.0.1

Note: I had to remove a test from tst_property.cpp which needed access to the moved Signal. However, this is fine as the only behavior that the moved Signal can now influence is the observation by a PropertyNode. This is tested in tst_node.cpp.

Closes #24

This change uses CMake's "configure_file" command to enter the current KDBindings version number into the baseUrl used by mkdocs as well as doxybook2.

This should fix the links for on docs.kdab.com.

When T is an aggregate type, eg struct Rect { int x; int y; int width; int height; }

It would be great to be able to access members of Property, i.e that:

Property<Rect> r;
auto widthProp = makeBoundProperty(r.width);

This slightly overlaps with what @lemirep is asking about in #28, except in my case the aggregate does not contain Property<> members. The desired behaviour can be done using a function argument to makeBoundProperty : the question is whether some overload of operator-dot (and ->, presumably) could synthesise the access.

At the moment I cannot use a const Property in a binding.

const Property<float> someValue = makeBinding(someExpression);
Property<float> boundValue = makeBinding(someValue); // This does not compile

A const Property means it cannot be assigned to again but its value still might change (if the value of the const property is a binding). Therefore, being able to use a const Property in a binding would make sense.

Often, I have to deal with a Property<T*> p where T itself contains properties. Given the property p is using a pointer type, I cannot binding directly to p->someProperty given p might be null. Therefore I would need to have a way to create a binding to a function that can itself return binding to another property or a value depending on whether p() is null.

// GIVEN
struct TypeA {
Property<float> value { 1.0f };
};

struct TypeB {
Property<TypeA *> a { nullptr };
};

// WHEN
TypeB myB;

// In a perfect world I would do Property<float> v = makeBinding(myB.a->value);
// Except I can't if myB.a is null

// THEN
CHECk(myB.a() == nullptr);

// WHEN
Property<float> v = makeBinding([] (TypeA *a) { 
                                    if (a)
                                       return makeBinding(a->value);
                                    return 0.0f; // or a binding to a default property
                                }, myB.a);

// THEN -> Returns default value
CHECK(v() == 0.0f);

// WHEN
TypeA myA;
myB.a = &myA;

// THEN -> Return bound value
CHECK(v() == 1.0f);

Having the ability to control when a connection is emitted could be advantageous, especially in a multi-threaded context, where a worker thread might emit a signal, but the slot should be called in an event loop on a GUI thread.

To control when exactly a connection is evaluated, implement a ConnectionEvaluator, similar to the BindingEvaluator, that can control when exactly a slot is called.

Add a function connectDeferred (or similar) that takes a ConnectionEvaluator as the first argument, then takes the same arguments as the normal connect function. This slot would then queue the actual function to be called in the ConnectionEvaluator. The queued functions in the ConnectionEvaluator could then be called at any time, similar to how evaluateAll works on the BindingEvaluator. The difference here would be that connections might actually be emitted multiple times between calls to the evaluator, so these calls would then also need to be emitted multiple times.

Use Thread 1 with normal signal evaluation to mark a binding as dirty.

Then have all the dependent properties associated with a BindingEvaluator. This binding evaluator would then be evaluated by Thread 2 (typically GUI Thread), so the evaluation actually happens on a separate thread.

For this to work the following would need to be thread-safe:

1. Marking of a binding as dirty.
2. Reading from a Property & updating the bindings internal cache
3. Disconnecting/Connecting of Signals when creating a Binding

A single shot connection could possibly be implemented by creating a binding that captures its own ConnectionHandle and disconnects it when the signal is emitted.

Open question: How to capture the ConnectionHandle in the slot itself?