Date: Mon, 09 Sep 2024 16:58:43 +0200 From: Dmitry Salychev <dsl@FreeBSD.org> To: Jan Knepper <jan@digitaldaemon.com> Cc: David Chisnall <theraven@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, ske-89@pkmab.se, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <868qw0uafp.fsf@peasant.bootbsd.com> In-Reply-To: <256401bf-1b46-467a-a44e-42fc14d20ebf@digitaldaemon.com> References: <202409091304.aa20239@berenice.pkmab.se> <202409091124.489BOWk2082765@critter.freebsd.dk> <B8AEE93C-6431-4ED2-B1C6-7945A9A41AD0@FreeBSD.org> <202409091332.489DWNmO084207@critter.freebsd.dk> <C992AC0F-6EA4-4B67-BC0C-702209039586@FreeBSD.org> <256401bf-1b46-467a-a44e-42fc14d20ebf@digitaldaemon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jan Knepper <jan@digitaldaemon.com> writes: > On 9/9/24 10:05, David Chisnall wrote: > > On 9 Sep 2024, at 14:32, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > David Chisnall writes: > > On 9 Sep 2024, at 12:24, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > What might that subset be? > > Initially it will be "better C compiler", but then we will gradually > allow more and more of C++ to be used. > > In my experience, the worst C++ code is written by people thinking in C. > The second worst is written by people thinking in Java (or Smalltalk). > > I dont disagree :-) > > But it's either a gradual approach or "never" because a rewrite in toto wont happen. > > I agree, incremental change is always better. I just don’t want to encourage anyone to write C++ that looks like C, > because that’s going to combine the frustrations people have with C and C++. A gradual approach needs a simple step > 1, but it also needs a step 2, and then a step 3, and so on. > > Second. I've mentioned MISRA C++:2023 already, but would like to elaborate on my idea behind it. It forms a subset of ISO/IEC 14882:2017 (C++17) by introducing guidelines which are "directives" or "rules". At the same time each guideline falls into one of the "mandatory", "required" or "advisory" category. For example, there's a rule 13.1.1 which prohibits classes to be inherited virtually, but it's in the "advisory" category at the same time. Rule 13.3.1 states that user-declared member functions shall use the virtual, override and final specifiers appropriately. It should be less time consuming to analyze existing guidelines prepared by MISRA C++:2023 and form steps simple enough to be adopted by the project, I think. Regards, Dmitry -- https://wiki.freebsd.org/DmitrySalychev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?868qw0uafp.fsf>