Re: The Case for Rust (in any system)
- In reply to: Dmitry Salychev : "Re: The Case for Rust (in any system)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 09 Sep 2024 22:15:41 UTC
Dmitry Salychev wrote in
<868qw0uafp.fsf@peasant.bootbsd.com>:
...
|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
...
|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.
...
..only to mention that somehow the order of the C++ keywords
virtual and override are bogus unless (last and only version
i truly ready aka bought the book was '98) i have been hitten by
a compiler bug. I used to use preprocessor macro things for
clarity aka "explicity", but when newer standards came the order
was reversed, i know have (horrors!) use wrapper macros to be able
to place the keyword correctly, that is
either
include/su/code.h:# define su_OVRX(X) virtual X
or
include/su/code.h:# define su_OVRX(X) X override
and thus
src/su/.main.cxx: OVRX(~a_md__sade(void)) {}
or
src/su/.main.cxx: OVRX(up property(prop prop) const){
instead of, as before the advent of override
ovrx ~a_md__sade(void){}
or
ovrx up property(prop prop) const){..}
*What a mess*!! I mean *is* override an override of virtual, then
why is it placed that [fecal]. That is just [fecal]. If they
really abolish the preprocessor at some later point, all bets are
off.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)