C++ Logo


Advanced search

Re: [std-proposals] Safety checks at compile time

From: Phil Bouchard <boost_at_[hidden]>
Date: Tue, 14 Feb 2023 14:55:55 -0500
On 2/14/23 12:02, Roberto R via Std-Proposals wrote:
> Hi all
> I guess many of you have read articles about Microsoft, Google and NSA
> saying that it is better to stop to use C++ and use instead memory safe
> languages like Rust or Java.
> Is it possible to make C++ a memory safe language? For sure it is
> possible to make it safer, at least for new code that does not use
> legacy code.
> It needs a few extensions to the language, and to add libraries that
> privilege safety instead of performance, to be used when their
> performances are still acceptable.

I did brought up this subject a while ago... I already have a solution
that fixes all memory issues implicitly (crashes, leaks, cyclic
references, ...) and in a deterministic way but it is patented and
requires a proprietary source-to-source compiler to inject the code into
existing C++ code:

I am considering open sourcing it given the importance of the problem as
we can see with all the cybersecurity problems it involves.

We also need to fix low-level system allocators using singletons and
virtual tables so that it'll be easier to use custom memory pools.

Rust anyways has a long way to go to reach the level of C++ even if it
plagiarizes the architecture of the headers. Although it can replace C
very quickly.

Java can only be really improved with another source-to-source compiler
although it is possible to compile Java code directly (but it still
requires garbage collectors):


Logo <https://www.fornux.com/>  
*Phil Bouchard*  facebook icon
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
8 rue de la Baie| Gatineau (Qc), J8T 3H3 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 2023-02-14 19:55:57