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)