LazyState

[stiff garden]

It should in theory help defer to the last minute the computation of whatever state you want... (nots supposed to multithread yet)

template<typename T>
struct LazyState
{
    using value_type = T;

    // Default constructor: initialize with default values.
    inline LazyState()
        : mUpdateCb(nullptr), mbUpdated(false) {}

    // Constructor with an initial state.
    inline explicit LazyState(const T& initialState)
        : mState(initialState), mUpdateCb(nullptr), mbUpdated(false) {}

    // Constructor with an initial state and an update callback.
    inline LazyState(const T& initialState, std::function<bool(T&)> updateCallback)
        : mState(initialState), mUpdateCb(updateCallback), mbUpdated(false) {}

    // Constructor with an update callback only.
    inline explicit LazyState(std::function<bool(T&)> updateCallback)
        : mUpdateCb(updateCallback), mbUpdated(false) {}

    inline void MarkOutdated()
    {
        mbUpdated = false;
    }

    inline T& Access(bool bUpdateIfNeeded = true)
    {
        if (bUpdateIfNeeded && !mbUpdated && mUpdateCb)
            mbUpdated = mUpdateCb(mState);
        return mState;
    }

    inline T& operator*()
    {
        T& state = Access(true);
        if (mbUpdated)
            return state;
        throw std::exception("Fail State Update");
    }

    std::function<bool(T&)> mUpdateCb;
    std::atomic<bool> mbUpdated;
private:
    T mState;
};

[abstract swan]

Ok, so a couple of comments from my PoV:

• The whole thing could be a class since it has behavior and is not just an aggregate, but that's debatable and barely changes anything
• If you put this definition into an .hpp, no need to add the extra inline keyword since the compiler will try to inline it automatically
• having a function that accepts a bool parameter calls for splitting it into two separate functions. Especially since the function has default argument, which kind of obscures what happens and what to expect from the function.
• do mUpdateCb and mbUpdated necessarily need to be public, since as far as I can see, they are primarily managed as an internal state ?

[stiff garden]

The whole thing could be a class since it has behavior and is not just an aggregate, but that's debatable and barely changes anything Fair point... matter fact i used it for whatever reason... but if it makes sense to put it as a class then why not...

If you put this definition into an .hpp, no need to add the extra inline keyword since the compiler will try to inline it automatically well... i noticed that sometime.. if not inline is added... the behavior will be that when included multipel places... guess what... double syumbol definition.. which is not fun.. to avoid those type of errors... explicit inline is what worked well

having a function that accepts a bool parameter calls for splitting it into two separate functions. Especially since the function has default argument, which kind of obscures what happens and what to expect from the function. i belive you refer to the Access() function... it is there... so users can View? the State without updating it.. if they want to... the operator* will always try to update the state... which is not cool if we just tryin to look at it

_
do mUpdateCb and mbUpdated necessarily need to be public, since as far as I can see, they are primarily managed as an internal state ? You absolutely right on this one.... honeslty... i wasnt botherin much on it... In fact... i usually dont even touch the visibility specifiers unless is critically important like in the case of mState where is kinda strict the access it must have.... with others i just left them as default o visible... this is more like a pattern (maybe a bad behavior, not necesarily best practice) i learnt in the past... where i was trying to go for maximum efficiency... see.. if you put all private.. sometimes... for whatever reason it was needed to inspect or test or whatever with the internal state externally again for whatever reason (not necesaryly productions reason... just whatever reasons say prototyping or whatever) well i found out that this slowed me down... becouse fo the fact that i needed to proactively do getters and setters
for everything... which wasnt cool.. it was llike a type of overhead... that i just simply bypassed this way... by leaving everything like this public unless dead critical like that mState ....

[stiff garden]

having a function that accepts a bool parameter calls for splitting it into two separate functions. Especially since the function has default argument, which kind of obscures what happens and what to expect from the function. did you meant here to create maybe another function for clarity... say UpdateAccess() + Access()?

[abstract swan]

Double symbol definition is most likely due to lack of #pragma once

I'm not sure about automatic inlining function where you put declaration in .hpp and definition in .cpp - then the inline might be needed