Skip to content

split redev Server and Client classes #34

@jacobmerson

Description

@jacobmerson

In the coupler I found that splitting up the server and client into separate classes had some nice advantages like a more obvious interface where functions are only available as appropriate on the server or client side. Another benefit with the coupler is that on the client side we don't need to link against all of the libraries that are needed for the internal data structures (Omega_h).

I think it would be worth thinking about if we should do the same type of split in Redev. This could be accomplished either by two completely separate classes, or via a template (use the process type enum as a NTTP).

Here's an outline of what that could look like:

template <ProcessType PT>
class Redev {
    // most methods we can just change the if statements to "if constexpr"
    void SomeMethod() {
        if constexpr(PT == ProcessType::Server) {
            // do server calcs
        }
        else {
            // do client calcs
        }
    }
    // only a few methods are only on client or only on server, so we can just SFINAE them out
    // if we have a lot of functions that are only on server or client we can completely split the client server class definitions
    
    // use dummy template argument since SFINAE only works in deduced context
    template <ProcessType Dummy=PT>
    std::enable_if_t<Dummy==ProcessType::Server,void> ServerOnlyMethod() {
        // do computation that only makes sense on server
    }
};

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions