Skip to content

[SUGGESTION] Question/Code Review Request: Simple implementation provider in cpp2 #604

Description

@jazn

I started to play with cpp2 recently. I think this is great improvement in abstraction definition for C++.

I'm working on a simple rendering system and I would like to have the ability to select different implementations on different platforms.
I think that @interface is the way to go. I wonder what is the best way to select/initialize particular implementation. I use ImplementationProvider as a single point of change.

Here is a simplified example to show what I mean:

// defined in interface module
Surface: @interface type = {
    hello: (this);
}

SurfaceProvider: @interface type = {
    create_surface: (this) -> std::unique_ptr<Surface>;
}

// defined in implementation module
WVSurface: type = {
    this: Surface = ();
    hello: (this) = {
        std::cout << "Hello ." << std::endl;
    }
}
WVSurfaceProvider: type = {
    this: SurfaceProvider = ();
    create_surface: (this) -> std::unique_ptr<Surface> = {
        surf : std::unique_ptr<Surface>;
        surf = new<WVSurface>();
        return move(surf);
    }
}

// usage
main: () = {
    std::cout << "Begin." << std::endl;
    surf_prov: WVSurfaceProvider = (); // only this line need to be changed to select different implementation
    surf:_ = surf_prov.create_surface();
    surf*.hello();
}

What do you think about the code?
I'm open to suggestion about different ways to implement that function too.

Activity

  1. JohelEGP commented on Aug 19, 2023

    @JohelEGP
    Contributor

    I've heard the idea floating around of writing concrete code,
    and choosing the implementation at CMake configure time.
    Then your build system uses a concrete implementation for the configured platform.
    That makes sense, given that one such compiled program only really uses a single "provider" ever.

    So you can use concrete types with stable interfaces,
    and only their implementation changes between platforms.
    Alternatively, you can use concept-constrained templates instead,
    for what would be interface requirements enforced by the @interface feature.

  2. jazn commented on Aug 20, 2023

    @jazn
    Author

    Thank you for the answer. That gave me some additional thinking.
    I had an internal conflict with pointer for something statically available. Ant this can be a solution.
    I wonder what would be the best way for keeping many implementation in sync. I wonder if C++/cppfront can give me some help with that?

  3. JohelEGP commented on Aug 20, 2023

    @JohelEGP
    Contributor

    I wonder what would be the best way for keeping many implementation in sync. I wonder if C++/cppfront can give me some help with that?

    Depends on what you mean with keeping them in sync.
    You'll ultimately need testing to ensure execution has the expected behavior.
    For checking the interfaces of your concrete types,
    you can use concepts or @interfaces,
    except that for @interfaces, you'd be using final this parameters when implementing the interface.

  4. Repository owner locked and limited conversation to collaborators on Aug 30, 2023
  5. converted this issue into a discussion #625 on Aug 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions