-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support rust Option
and C++ std::optional
#87
Comments
I'm trying an implementation of this, following the code patterns for Vec and CxxVector |
#44 is required for this, along with an extra
|
Most work needed for this is clear. I can follow the RustVec and CxxVector work. There is one difference between the already-supported types like So, for example, we have: Line 260 in 32439da
RustOption type that needs to be implemented?
|
We don't use Vec::as_mut_ptr. That line is calling MaybeUninit::as_mut_ptr. |
@philipcraig Are you still planning on working on this, or could you use help? I'm finding myself in a situation where I could really use Option, for a result-like type on an interface. |
Hi @sbrocket, I got stalled when I realised late on that there is not a fixed repr for Rust Option, so that we will have to copy bits. It should all be doable but my approach needs to be thrown away and re-done. In short, if you would like to tackle it, please do. My work in progress is at https://github.com/philipcraig/cxx/tree/support_option_and_std_optional. It doesn't build and has the wrong assumptions about the repr of rust Option, but some of it may be useful |
rust-lang/rust#75454 if you hadn't come across it. |
I'd be happy with a solution that always copies initially. |
I would like start the discussion again how a sharable Option type could be implemented. The problem with Rust's How about using an custom option type with #[repr(C, u8)]
pub enum CxxOptional<T> {
None,
Some(T),
} This has the advantage that it is still a rust enum but it has a defined memory layout. Moreover, it should have the same memory layout as #[repr(C)]
struct CxxOptionalRepr {
tag: CxxOptionalDiscriminant,
payload: CxxOptionalFields,
}
// This is the discriminant enum.
#[repr(u8)]
enum CxxOptionalDiscriminant { None, Some }
// This is the variant union.
#[repr(C)]
union CxxOptionalFields<T> {
None: Dummy,
Some: T
}
#[repr(C)]
struct Dummy; The corresponding C++ type looks like: struct CxxOptional{
enum class Tag {
None,
Some,
};
struct Some_Body {
T _0;
};
Tag tag;
union {
Some_Body some;
};
}; The tag field is of type What do you think about it? |
Sadly, it turns out that the fields of struct optional{
union {
T some;
};
bool _engaged;
}; |
In the midst of just trying to wrap the existing Rust types reasonably into C++ using cxx and building a temporary executable (`tmp`). It seems cxx is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for Option<T> (dtolnay/cxx#87) so, some creativity is required in writing the bridge, and I think it can safely be considered TW-specific. But, that means it can also omit all of the functionality that TW doesn't use! TODO: - Finish required functionality - put it all in one module, as multi-module support isn't good - Use it from TW - [DONE] Delete taskchampion-lib - Delete src/tc/*.{cpp,h}
In the midst of just trying to wrap the existing Rust types reasonably into C++ using cxx and building a temporary executable (`tmp`). It seems cxx is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for Option<T> (dtolnay/cxx#87) so, some creativity is required in writing the bridge, and I think it can safely be considered TW-specific. But, that means it can also omit all of the functionality that TW doesn't use! TODO: - WIP - remove ffi.h - stashed bit is getting started with replacing src/tc, but maybe throw that out - Use it from TW
In the midst of just trying to wrap the existing Rust types reasonably into C++ using cxx and building a temporary executable (`tmp`). It seems cxx is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for Option<T> (dtolnay/cxx#87) so, some creativity is required in writing the bridge, and I think it can safely be considered TW-specific. But, that means it can also omit all of the functionality that TW doesn't use! TODO: - WIP - remove ffi.h - stashed bit is getting started with replacing src/tc, but maybe throw that out - Use it from TW
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` so, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`. TODO: - See TODO's in patch - remove old/unnecessary files - Make sure error messages are still shown properly e.g., in sync - Docs updates
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`. TODO: - reference released `taskchampion 0.7.0`
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`. TODO: - reference released `taskchampion 0.7.0`
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`.
TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's `Task` type more cleanly. It also introduces the idea of gathering lists of operations and "committing" them to a replica. A consequence of this change is that TaskChampion no longer automatically maintains dependency information, so Taskwarrior must do so, with its `TDB2::dependency_sync` method. This method does a very similar thing to what TaskChampion had been doing, so this is a shift of responsibility but not a major performance difference. Cxx is .. not great. It is missing a lot of useful things that make a general-purpose bridge impractical: - no support for trait objects - no support for `Option<T>` (dtolnay/cxx#87) - no support for `Vec<Box<..>>` As a result, some creativity is required in writing the bridge, for example returning a `Vec<OptionTaskData>` from `all_task_data` to allow individual `TaskData` values to be "taken" from the vector. That said, Cxx is the current state-of-the-art, and does a good job of ensuring memory safety, at the cost of some slightly awkward APIs. Subsequent work can remove the "TDB2" layer and allow commands and other parts of Taskwarrior to interface directly with the `Replica`.
It would greatly simplify API development if automatic
Option<T>
conversion was supported.Since C++17 there is
std::optional<T>
, which would allow a more or less direct translation of supported types.I had a look at #67 and the ideas and work done by @myronahn for Vec seems to be similar to what would be needed for supporting
Option
so maybe one could build on that...The text was updated successfully, but these errors were encountered: