You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[SUGGESTION] Question/Code Review Request: Simple implementation provider in cpp2 #604
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.
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.
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?
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.
Reacted by jazn
Repository owner locked and limited conversation to collaborators on Aug 30, 2023
Activity
JohelEGP commentedon Aug 19, 2023
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-constrainedtemplates instead,for what would be interface requirements enforced by the
@interfacefeature.jazn commentedon Aug 20, 2023
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?
JohelEGP commentedon Aug 20, 2023
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 usingfinal thisparameters when implementing the interface.