Date: Fri, 17 May 2019 06:13:20 +0000
Hi Andrew,
I saw your post about Handles on the forum, but I think the list is no longer available. You may need to refer to Herb's announcement (https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/C-jBaB00QaE) and subscribe the new Std-Proposals list.
Here are some comments about your proposal:
1. I agree that the motivating example have certain practical significance for improving engineering experience. However, I do not think that automatic runtime GC should be the best choice, because it is not adequately representative since GC is more than a "single thread" issue.
As for the motivating example, the sample implementation tries to allocate redundant memory to simplify the algorithm. On the one hand, it does not seem to be so difficult to deallocate the memory manually or avoid redundant allocation, and may potentially have higher performance than using GC. On the other hand, when extendibility is much more important than performance, we may design a library to save our time.
For example, the term "deletable" could be defined as: a "deletable" value is rather:
- a pointer `p` to a value obtained directly via "new" and has not been deleted; if `p->get_related_pointers()` is well-formed, the return value shall also be deletable, or
- a generic container (including user-defined containers) of deletable values, or
- a generic tuple (including `std::tuple`, `std::pair` or `std::array`) of deletable values.
template <class T, class U>
void instant_gc(T&& all, U&& useful)
Requires: `all` and `useful` are deletable.
Effects: delete the pointers and related pointers in `all` except for the pointers and related pointers in `useful`.
template <class T>
void instant_gc(T&& all)
Requires: `all` is deletable.
Effects: Equivalent to `instant_gc(std::forward<T>(all), std::tuple<>{})`.
A rough implementation for the library is available at: https://github.com/wmx16835/my-stl/blob/f6bebe469fcba2c2d3f759b5a57a857487132664/src/test/applicable-template/instant_gc.h#L98-L110
And I also redesigned the implementation for your motivating example with the library above (it compiles with latest GCC/LLVM/MSVC): https://github.com/wmx16835/my-stl/blob/master/src/test/applicable-template/test_instant_gc.cc#L29-L53
I think the solution above could be more readable, maintainable and potentially have higher performance because:
- It does not require new language features or redesigning the standard containers, and
- `std::vector<std::vector<Room*>> room` has clearer semantics than:
std::vector<Room> rooms_mat(N*N);
auto rooms = [&](size_t x, size_t y) -> Room& {
return rooms_mat[x*N+y];
};
- `test::instant_gc` could have higher performance than automatic GC.
However, I do not think either automatic GC or the library above is robust enough to go into the standard since it will become difficult to use allocators, and we may easily get higher performance if redundant memory allocation could be avoided.
2. Theoretically, although automatic runtime GC could potentially save some code, it may have significant influence on performance. In many other GC-based languages, like Java, every single object is derived from a unified polymorphic base class ("java.lang.Object" in Java), and GC also runs polymorphically. In my proposal P0957 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0957r1.pdf), a more generic solution for polymorphism, the PFA, was proposed, that could help users build polymorphic program without GC and provide more usability, extendibility and potentially higher performance than using "virtual" plus "new/delete".
Thanks,
Mingxin Wang
From: std-proposals_at_isocpp.org <std-proposals_at_[hidden]>
Sent: Thursday, May 16, 2019 6:11 AM
To: Abridged recipients <std-proposals_at_isocpp.org>
Subject: [std-proposals] Abridged summary of std-proposals_at_[hidden] - 1 update in 1 topic
std-proposals_at_[hidden]<%20%20https:/nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%23!forum%2Fstd-proposals%2Ftopics&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720732035&sdata=T4i1Invy1jeDPBeYNo1xEST0OMuda%2Fg30z5uIX5iSxE%3D&reserved=0>
Google Groups<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%2F%23!overview&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720732035&sdata=d%2Fnlite18XvPDF6zGA4uDPLSoGmIFr5r4qK07ai4Gwg%3D&reserved=0>
[http://www.google.com/images/icons/product/groups-32.png]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%2F%23!overview&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720742308&sdata=rm7ErxkqVWBWgr3st3ESM2v4PkdryOoEDYyyBo88NZ8%3D&reserved=0>
Today's topic summary
View all topics<%20%20https:/nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%23!forum%2Fstd-proposals%2Ftopics&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720742308&sdata=32XsdqHp%2FINXTDoCuery3Dhmp%2FE4pspv78CkLI8Ee7Y%3D&reserved=0>
ยท Proposal of Handles (draft 2) - 1 Update
Proposal of Handles (draft 2) <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fgroup%2Fstd-proposals%2Ft%2F62b6709ec816113b%3Futm_source%3Ddigest%26utm_medium%3Demail&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720742308&sdata=Xnvgksf7Y5sZDJgyZE7P9%2F%2BA%2FDVAm8%2BLlZd3QhFfvWk%3D&reserved=0>
Andrew Tomazos <andrewtomazos_at_[hidden]<mailto:andrewtomazos_at_[hidden]>>: May 15 09:20PM +1000
Please find attached a working draft of:
Proposal of Handles
Feedback appreciated.
Regards,
Andrew.
...more<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fgroup%2Fstd-proposals%2Fmsg%2F3e354363b3047%3Futm_source%3Ddigest%26utm_medium%3Demail&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720752052&sdata=QjMXZgKTt4UPXepuTHtYP%2FXteE8YzJVL9myrpP%2BPVVY%3D&reserved=0>
Back to top
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page<%20%20https:/nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%23!forum%2Fstd-proposals%2Fjoin&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720762064&sdata=w172%2Fpek%2Bso8h%2ByzeI3cFEbaSbEcQN5sLd3goOEgq1E%3D&reserved=0>.
To unsubscribe from this group and stop receiving emails from it send an email to std-proposals+unsubscribe_at_[hidden]<mailto:std-proposals+unsubscribe_at_[hidden]>.
I saw your post about Handles on the forum, but I think the list is no longer available. You may need to refer to Herb's announcement (https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/C-jBaB00QaE) and subscribe the new Std-Proposals list.
Here are some comments about your proposal:
1. I agree that the motivating example have certain practical significance for improving engineering experience. However, I do not think that automatic runtime GC should be the best choice, because it is not adequately representative since GC is more than a "single thread" issue.
As for the motivating example, the sample implementation tries to allocate redundant memory to simplify the algorithm. On the one hand, it does not seem to be so difficult to deallocate the memory manually or avoid redundant allocation, and may potentially have higher performance than using GC. On the other hand, when extendibility is much more important than performance, we may design a library to save our time.
For example, the term "deletable" could be defined as: a "deletable" value is rather:
- a pointer `p` to a value obtained directly via "new" and has not been deleted; if `p->get_related_pointers()` is well-formed, the return value shall also be deletable, or
- a generic container (including user-defined containers) of deletable values, or
- a generic tuple (including `std::tuple`, `std::pair` or `std::array`) of deletable values.
template <class T, class U>
void instant_gc(T&& all, U&& useful)
Requires: `all` and `useful` are deletable.
Effects: delete the pointers and related pointers in `all` except for the pointers and related pointers in `useful`.
template <class T>
void instant_gc(T&& all)
Requires: `all` is deletable.
Effects: Equivalent to `instant_gc(std::forward<T>(all), std::tuple<>{})`.
A rough implementation for the library is available at: https://github.com/wmx16835/my-stl/blob/f6bebe469fcba2c2d3f759b5a57a857487132664/src/test/applicable-template/instant_gc.h#L98-L110
And I also redesigned the implementation for your motivating example with the library above (it compiles with latest GCC/LLVM/MSVC): https://github.com/wmx16835/my-stl/blob/master/src/test/applicable-template/test_instant_gc.cc#L29-L53
I think the solution above could be more readable, maintainable and potentially have higher performance because:
- It does not require new language features or redesigning the standard containers, and
- `std::vector<std::vector<Room*>> room` has clearer semantics than:
std::vector<Room> rooms_mat(N*N);
auto rooms = [&](size_t x, size_t y) -> Room& {
return rooms_mat[x*N+y];
};
- `test::instant_gc` could have higher performance than automatic GC.
However, I do not think either automatic GC or the library above is robust enough to go into the standard since it will become difficult to use allocators, and we may easily get higher performance if redundant memory allocation could be avoided.
2. Theoretically, although automatic runtime GC could potentially save some code, it may have significant influence on performance. In many other GC-based languages, like Java, every single object is derived from a unified polymorphic base class ("java.lang.Object" in Java), and GC also runs polymorphically. In my proposal P0957 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0957r1.pdf), a more generic solution for polymorphism, the PFA, was proposed, that could help users build polymorphic program without GC and provide more usability, extendibility and potentially higher performance than using "virtual" plus "new/delete".
Thanks,
Mingxin Wang
From: std-proposals_at_isocpp.org <std-proposals_at_[hidden]>
Sent: Thursday, May 16, 2019 6:11 AM
To: Abridged recipients <std-proposals_at_isocpp.org>
Subject: [std-proposals] Abridged summary of std-proposals_at_[hidden] - 1 update in 1 topic
std-proposals_at_[hidden]<%20%20https:/nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%23!forum%2Fstd-proposals%2Ftopics&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720732035&sdata=T4i1Invy1jeDPBeYNo1xEST0OMuda%2Fg30z5uIX5iSxE%3D&reserved=0>
Google Groups<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%2F%23!overview&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720732035&sdata=d%2Fnlite18XvPDF6zGA4uDPLSoGmIFr5r4qK07ai4Gwg%3D&reserved=0>
[http://www.google.com/images/icons/product/groups-32.png]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%2F%23!overview&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720742308&sdata=rm7ErxkqVWBWgr3st3ESM2v4PkdryOoEDYyyBo88NZ8%3D&reserved=0>
Today's topic summary
View all topics<%20%20https:/nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%23!forum%2Fstd-proposals%2Ftopics&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720742308&sdata=32XsdqHp%2FINXTDoCuery3Dhmp%2FE4pspv78CkLI8Ee7Y%3D&reserved=0>
ยท Proposal of Handles (draft 2) - 1 Update
Proposal of Handles (draft 2) <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fgroup%2Fstd-proposals%2Ft%2F62b6709ec816113b%3Futm_source%3Ddigest%26utm_medium%3Demail&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720742308&sdata=Xnvgksf7Y5sZDJgyZE7P9%2F%2BA%2FDVAm8%2BLlZd3QhFfvWk%3D&reserved=0>
Andrew Tomazos <andrewtomazos_at_[hidden]<mailto:andrewtomazos_at_[hidden]>>: May 15 09:20PM +1000
Please find attached a working draft of:
Proposal of Handles
Feedback appreciated.
Regards,
Andrew.
...more<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fgroup%2Fstd-proposals%2Fmsg%2F3e354363b3047%3Futm_source%3Ddigest%26utm_medium%3Demail&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720752052&sdata=QjMXZgKTt4UPXepuTHtYP%2FXteE8YzJVL9myrpP%2BPVVY%3D&reserved=0>
Back to top
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page<%20%20https:/nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fforum%2F%3Futm_source%3Ddigest%26utm_medium%3Demail%23!forum%2Fstd-proposals%2Fjoin&data=02%7C01%7Cmingxwa%40microsoft.com%7C0f2120928eef4911892e08d6d9823c52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935550720762064&sdata=w172%2Fpek%2Bso8h%2ByzeI3cFEbaSbEcQN5sLd3goOEgq1E%3D&reserved=0>.
To unsubscribe from this group and stop receiving emails from it send an email to std-proposals+unsubscribe_at_[hidden]<mailto:std-proposals+unsubscribe_at_[hidden]>.
Received on 2019-05-17 01:16:34