Date: Mon, 11 Nov 2024 23:04:33 -0500
On 11/11/24 01:26, Thiago Macieira via Std-Discussion wrote:
> On Sunday 10 November 2024 21:02:25 Pacific Standard Time Phil Bouchard via
> Std-Discussion wrote:
>> This mailing list is not "proposals" but general discussions and
>> sometimes we need to step back because on another note some government
>> agencies might dismiss non-memory safe languages also:
>> https://www.theregister.com/2024/09/16/safe_c_plusplus/
>
> Not exactly. This is about discussions about the standard (current or maybe
> upcoming). Can you relate your thoughts about power with the C++ Standard? Is
> it a property of the language or the Standard Library that it will consume
> less power (or more)? Is it a design goal that supposed to be a goal of the
> standard language and library authors to think about power and performance? Or
> should the standard only worry about performacne, leaving the power aspect
> QoI?
Well performance and power consumption are inversely proportional.
On another hand, memory management is one topic it needs to worry about.
Whether:
- C++ compilers become stricter;
- C++ compilers finally can make the difference between an iterator and
a pointer;
- Usage of external static code analysis tools;
- Possibility of integrating a garbage collector, memory pools or
commercial memory managers;
Back in 2004, I did try integrate a free memory manager into the Boost
library but it turns out it required changing the code so it can't be
used as a simple header library.
So I ultimately think if there would be a way to add implicit function
parameters and class members then we wouldn't need commercial static
code analysis tools and we could integrate serious memory managers freely.
We don't have a lot of options left if we care about the lifetime of C++.
> On Sunday 10 November 2024 21:02:25 Pacific Standard Time Phil Bouchard via
> Std-Discussion wrote:
>> This mailing list is not "proposals" but general discussions and
>> sometimes we need to step back because on another note some government
>> agencies might dismiss non-memory safe languages also:
>> https://www.theregister.com/2024/09/16/safe_c_plusplus/
>
> Not exactly. This is about discussions about the standard (current or maybe
> upcoming). Can you relate your thoughts about power with the C++ Standard? Is
> it a property of the language or the Standard Library that it will consume
> less power (or more)? Is it a design goal that supposed to be a goal of the
> standard language and library authors to think about power and performance? Or
> should the standard only worry about performacne, leaving the power aspect
> QoI?
Well performance and power consumption are inversely proportional.
On another hand, memory management is one topic it needs to worry about.
Whether:
- C++ compilers become stricter;
- C++ compilers finally can make the difference between an iterator and
a pointer;
- Usage of external static code analysis tools;
- Possibility of integrating a garbage collector, memory pools or
commercial memory managers;
Back in 2004, I did try integrate a free memory manager into the Boost
library but it turns out it required changing the code so it can't be
used as a simple header library.
So I ultimately think if there would be a way to add implicit function
parameters and class members then we wouldn't need commercial static
code analysis tools and we could integrate serious memory managers freely.
We don't have a lot of options left if we care about the lifetime of C++.
-- Fornux Logo <https://www.fornux.com/> *Phil Bouchard* LinkedIn Icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> Founder & CEO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 320-345 de la Gauchetière Ouest| Montréal (Qc), H2Z 0A2 Canada The Best Predictable C++ Memory Manager <https://static.fornux.com/c-superset/> 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 2024-11-12 04:04:39