-
Notifications
You must be signed in to change notification settings - Fork 7
Fix format + Make project buildable #3
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
Changes from 6 commits
c534433
a463033
5650c6b
d705cdc
2c64e3e
e419df0
ca7d280
1a55b42
7208ca9
cc8f4bd
7bf9fb0
478754e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,7 +10,13 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | |
|
|
||
| # Overview | ||
|
|
||
| During the C++20 cycle [P0052 Generic Scope Guard and RAII Wrapper for the Standard Library](https://wg21.link/P0052) added 4 types: `scope_exit`, `scope_fail`, `scope_success` and `unique_resource` to [LTFSv3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/n4908#scopeguard). In the intervening time, two standard libraries have implemented support as well as Boost. With the imperative for safety and security in C++ developers need every tool in the toolbox. The authors believe it is time to move this facility into the standard. The paper will re-examine the five year old design and any learning from deployment of the LTFSv3. | ||
| During the C++20 cycle [P0052 Generic Scope Guard and RAII Wrapper for the Standard Library](https://wg21.link/P0052) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As I expressed in discourse I believe this change should be reverted and the linter line length restriction removed.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm approving, and if this isn't reverted when you merge I'll fix it in the next PR :)
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. alright |
||
| added 4 types: `scope_exit`, `scope_fail`, `scope_success` | ||
| and `unique_resource` to [LTFSv3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/n4908#scopeguard). | ||
| In the intervening time, two standard libraries have implemented support as well as Boost. | ||
| With the imperative for safety and security in C++ developers need every tool in the toolbox. | ||
| The authors believe it is time to move this facility into the standard. | ||
| The paper will re-examine the five year old design and any learning from deployment of the LTFSv3. | ||
|
|
||
| For discussions of this library see: | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,6 +3,35 @@ | |
| #ifndef BEMAN_SCOPE_HPP | ||
| #define BEMAN_SCOPE_HPP | ||
|
|
||
| namespace beman::scope {} // namespace beman::scope | ||
| namespace beman::scope { | ||
|
|
||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This now makes the example not runnable -- before it was ok on 2 major compilers. Please see this post for a path forward -https://discourse.bemanproject.org/t/scope-library/315/14?u=jeff-garland If BEMAN_USE_SCOPE_TS3 is set experimental will be included and beman::scope will just be using's in for experimental. For now BEMAN_USE_SCOPE_TS3 should default to true. This allows us to write tests and examples with no further development.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I checked your post linked, I don't quite understand what you mean here. I believe you are referencing:
Are we providing an implementation here? Or are we just compare-contrasting current implementations? Or are you proposing we do: namespace beman::scope {
using scope_exit = std::experimental::scope_exit;
}And in future PRs, expand it to: namespace beman::scope {
#if BEMAN_USE_SCOPE_TS3
using scope_exit = std::experimental::scope_exit;
#elif BEMAN_USE_SCOPE_BOOST
using scope_exit = boost::scope::scope_exit;
#endif
}What do you mean by not runnable here, do you mean we are unable to compile it, or do you mean it like segfault or do you mean its behavior is incorrect? Current implementation is a no-op TODO so that the examples compiles with upcoming beman implementations.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note the scope of this PR is just so the project passes CI and is build-able. I am not intending to provide a useable implementation here. We should implement
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, the proposal is as you said. It's a fair point, however, about not providing a usable implementation in this PR -- fine with that, but I think it'll be pretty trivial to do and will keep the examples/tests actually running code instead of a stub. Aim high :) Effectively 2 #includes and 4 using statements -- noting that the example that was there was buildable and runnable. As it stands it's only buildable. As for providing our own implementation here, I expect that will eventually happen -- but at first I'm more interested in developing tests/examples the push the TS implementations and explore the design space. It's my educated guess that no users know about the TS implementations and so there's whatever tests the developers wrote and not much real world usage.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, I didn't know what you were expecting here, I was not comfortable implementing this whole thing and I wasn't aware you were only looking for an alias. I can implement the switch in another PR.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have implemented a "rough" version, to make the example work: This needs lots of work, but it makes the example work.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hey @robert-andrzejuk , thanks for the gist. Let's do this in another PR. I want to keep the scope managable. I will just do the using alias.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @JeffGarland I think we should move forward with this PR as is.
This needs non-trivial work to our infrastructure and docs. It does not make sense to update them in this PR.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's fine -- I'd like to move past this PR -- but I think you're overthinking this :)
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. alright! |
||
| // TODO: Implement | ||
| struct scope_exit { | ||
| template <typename F> | ||
| scope_exit(F) {} | ||
| ~scope_exit() { | ||
| // TODO: Cleanup | ||
| } | ||
| }; | ||
|
|
||
| // TODO: Implement | ||
| struct scope_fail { | ||
| template <typename F> | ||
| scope_fail(F) {} | ||
| ~scope_fail() { | ||
| // TODO: Cleanup | ||
| } | ||
| }; | ||
|
|
||
| // TODO: Implement | ||
| struct scope_success { | ||
| template <typename F> | ||
| scope_success(F) {} | ||
| ~scope_success() { | ||
| // TODO: Cleanup | ||
| } | ||
| }; | ||
|
|
||
| } // namespace beman::scope | ||
|
|
||
| #endif // BEMAN_SCOPE_HPP | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,3 @@ | ||
| // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
|
|
||
| #include <beman/scope/identity.hpp> | ||
| #include <beman/scope/scope.hpp> |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,8 @@ | ||
| # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
|
|
||
| #add_executable(beman.scope.tests.identity) | ||
| #target_sources(beman.scope.tests.identity PRIVATE identity.test.cpp) | ||
| add_executable(beman.scope.tests.scope) | ||
| target_sources(beman.scope.tests.scope PRIVATE scope.test.cpp) | ||
|
|
||
| target_link_libraries(beman.scope.tests.scope PRIVATE beman::scope) | ||
|
|
||
| add_test(NAME beman.scope.tests.scope COMMAND beman.scope.tests.scope) |
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| int main() { | ||
wusatosi marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| // TODO: Add tests | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't we decide to flatten these directories to TOP/tests and TOP/src -- if we didn't we should. Only for headers do we need the distinction. And yes, I wouldn't be surprised if exemplar if wrong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it is not flattened, exemplar is correct here. This is codified in the beman standard, see here.
I believe this is so that we can do a giant beman build, basically merging all beman projects together and check if they can compile together as a single library.
We decided to not flatten
examplesdirectory.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Boost does a giant build and doesn't require this -- we should rediscuss this point.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the directory structure is not negotiable here. You will have to change the beman standard.
Feel free to bring it up at the next sync.
Note that it might be a little bit too late to change this, all current projects follow this folder structure. You will have to update a lot of current projects if you want to change this rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's never too late to change things