Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Reasoning about IO types #1407

Closed
chadbrewbaker opened this issue Jan 26, 2017 · 3 comments
Closed

Reasoning about IO types #1407

chadbrewbaker opened this issue Jan 26, 2017 · 3 comments

Comments

@chadbrewbaker
Copy link

Haskell and OCAML have an edge on C++ tooling in that they can reason about side effects with the operating system.

This is especially important in compiling C++ to newer architectures like FPGAs where IO can be very costly, or when reasoning about program security.

 std::experimental::decl_io(expr)

It would return an operating system defined struct. The struct could be as simple as an enum of {PURE, IMPURE, UNKNOWN}; or detailed information of which files/memory locations could be modified.

Another thing the C++ standard could do is define a format for linker metadata files similar Haskell's ".hi" files, so side effects can be reasoned about across precompiled libraries without recompilation; or a standard interface to such a file so operating systems can decide their own linker metadata formats.
@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 26, 2017 •
edited

This issue list is for editorial defects in the current working draft. For proposals to change the language itself, please visit www.isocpp.org, and https://isocpp.org/std in particular.

@tkoeppe tkoeppe closed this as completed Jan 26, 2017
@chadbrewbaker
Copy link
Author

Thank you for the clarification. Know of any work on formal verification of the declytype() specification? Throwing https://embed.cs.utah.edu/csmith/ expressions into decltype() may yield some very interesting edge cases.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jan 26, 2017

@chadbrewbaker: I'm afraid that a) I don't know anything about that, and b) this is not a good forum for this at all, since nobody really comes here looking for those kind of discussions. I recommend the mailing lists referred from the isocpp website I mentioned above; those seem like a good place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@chadbrewbaker @tkoeppe