Date: Wed, 28 Sep 2022 00:42:04 -0400
On 9/27/22 12:39, Jason McKesson via Std-Proposals wrote:
>
> Give us a 3 paragraph summary of what exactly you want changed in the
> C++ standard. No links, no off-ML resources. Just state plainly the
> exact thing you want changed in the C++ standard. I'm not asking for
> standardese; I'm asking for the specific thing you want the language
> to do.
What I am proposing here is to create a framework to allow the addition of:
- implicit parameters;
- implicit class members;
- implicit function variable instances;
- implicit compound statement variable instances;
- implicit file-scope static variable instances.
For "local" (non-system) files that are being compiled for a local project.
The goal is to standardize the addition of:
- deterministic memory managers (such as root_ptr:
https://github.com/philippeb8/root_ptr);
- any other alternative memory manager;
- portable backtraces;
- compile-time profilers.
For example it could add the following:
1) Class members for top-level classes (classes with no parent):
class A
{
protected:
boost::node_proxy & __y;
...
2) Implicit parameters and compound statement instances:
boost::root_ptr<test> foo(boost::node_proxy & __y)
{
boost::node_proxy & __z = __y();
{
boost::node_proxy & __x = __y();
boost::stack_node_proxy __y(__FILE__, __func__, __LINE__, __x());
...
3) ...
I know this works because I already tested it with the C++ Superset. But
like Sebastien was stating, this would aim the C++32 or the C++26
standards or hopefully before that.
The framework is not defined yet but that's the big idea. This would
allow to recompile legacy code correctly as well and forget about 70% of
the cybersecurity issues caused by memory bugs.
Thank you,
>
> Give us a 3 paragraph summary of what exactly you want changed in the
> C++ standard. No links, no off-ML resources. Just state plainly the
> exact thing you want changed in the C++ standard. I'm not asking for
> standardese; I'm asking for the specific thing you want the language
> to do.
What I am proposing here is to create a framework to allow the addition of:
- implicit parameters;
- implicit class members;
- implicit function variable instances;
- implicit compound statement variable instances;
- implicit file-scope static variable instances.
For "local" (non-system) files that are being compiled for a local project.
The goal is to standardize the addition of:
- deterministic memory managers (such as root_ptr:
https://github.com/philippeb8/root_ptr);
- any other alternative memory manager;
- portable backtraces;
- compile-time profilers.
For example it could add the following:
1) Class members for top-level classes (classes with no parent):
class A
{
protected:
boost::node_proxy & __y;
...
2) Implicit parameters and compound statement instances:
boost::root_ptr<test> foo(boost::node_proxy & __y)
{
boost::node_proxy & __z = __y();
{
boost::node_proxy & __x = __y();
boost::stack_node_proxy __y(__FILE__, __func__, __LINE__, __x());
...
3) ...
I know this works because I already tested it with the C++ Superset. But
like Sebastien was stating, this would aim the C++32 or the C++26
standards or hopefully before that.
The framework is not defined yet but that's the big idea. This would
allow to recompile legacy code correctly as well and forget about 70% of
the cybersecurity issues caused by memory bugs.
Thank you,
-- Email Signature Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> CTO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 1188 rue Saint-Louis| Gatineau (Qc), J8T 2L8 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2022-09-28 04:42:06