Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: why use static_cast ? Date: Wed, 02 Nov 2022 17:54:42 -0700 Organization: A noiseless patient Spider Lines: 45 Message-ID: <861qqkhn71.fsf@linuxsc.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="6b01656592aeeb6f93d9ba417445f98f"; logging-data="1360051"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LuqLibH1O+kO4YttBKLkGLgn38ZqJvQo=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:9ZDJAkOVD0qdKlOtHw4dFIJr4Ac= sha1:ZXnXwgGAJh6xAOno0M0E3fcQWQY= Xref: csiph.com comp.lang.c++:87204 Manfred writes: > On 10/20/2022 8:21 PM, Lynn McGuire wrote: > >> On 10/20/2022 8:55 AM, Scott Lurndal wrote: >> >>> Lynn McGuire writes: >>> >>>> I put the following cast into my code and one of my programmers wants me >>>> to use static cast. Why ? >>>> https://en.cppreference.com/w/cpp/language/static_cast >>>> >>>> longint nfac [8]; >>>> fem::str <8> * nfac_str = (fem::str <8> *) nfac; >>>> >>>> fem::str <8> is an 8 character object that acts like a Fortran >>>> character*8. longint is a long long. >>> >>> Young C++ programmers don't understand C, so they think >>> that static_cast*> is more "readable". Heh. >> >> The programmer in question is 39 and has been writing C and C++ >> since he was 13 or 14. >> >> His actual comment was that static_cast's are easier to grep which I >> find hard to believe. > > If by grep you mean grep(1), then yes, static_cast is definitely > easier to grep than a C-style cast. > However, the advantage of reinterpret_cast (static_cast wouldn't work) > is not that it is more readable. It is that it hurts the eye. > > Depending on which compiler you use, I'd verify that what you intend > to do actually works. As far as the standard is concerned, at least > one necessary condition is that fem::str<8> is effectively an unsigned > char[8]. > Otherwise it's UB unless your compiler says otherwise (although it > probably Just Works on any of them, in practice.) If a construct is described by the standard as being undefined behavior, said construct is still undefined behavior no matter what the implementation does. The condition of being undefined behavior is only a statement of what is mandated (or not) by the standard; it has nothing to do with whether something "defines" the behavior.