Throughout the codebase, there are places where a numeric literal is used to create a value of a specified type, using `static_cast<wanted_type>(literal)` syntax. I suppose this is not a correct semantically, since static_cast is to cast some existing value of a different type into wanted other type; while when literals are involved, what happens is *creation* of a new value of specified type. In my opinion, it's better to use function-style (ctor-style) cast syntax here, like `wanted_type(literal)`. To see the examples of this (like `static_cast< sal_Int64 >(1)` in [1], which should become simply `sal_Int64(1)` in this task), grep for static_cast\s*<[^>]+>\s*\(\s*-?\d+\.?\d*\s*\) which gives around 2000 matches currently. [1] https://opengrok.libreoffice.org/xref/core/sal/rtl/math.cxx?r=1782810f#285
Moving to NEW
(In reply to Mike Kaganski from comment #0) > I suppose this is not a correct semantically, since static_cast is to cast > some existing value of a different type into wanted other type; while when > literals are involved, what happens is *creation* of a new value of > specified type. In my opinion, it's better to use function-style > (ctor-style) cast syntax here, like `wanted_type(literal)`. Semantically, both static_cast and functional cast are fine there, and have the exact same meaning. Syntactically, functional cast can only be used if wanted_type is a simple-type-specifier (e.g., it cannot be used if wanted_type is "unsigned long"). Apart from that, I at least have no clear preference for either (functional cast is less verbose, though), and am not sure whether such a cosmetic clean-up is worth it and wanted.
(In reply to Stephan Bergmann from comment #2) > Semantically, both static_cast and functional cast are fine there, and have > the exact same meaning. Well, from C++ language PoV; while I rather meant intended usage (having read the rationale for choosing those long and awkward names like "static_cast" and "reinterpret_cast" to show explicit intention to change type of something, which is usually a sign of a low-level manipulation, a legacy code, or may be possibly implemented better). > Syntactically, functional cast can only be used if > wanted_type is a simple-type-specifier (e.g., it cannot be used if > wanted_type is "unsigned long"). Works fine for me with unsigned long(9) or unsigned short(9) in VS2019, and tested to produce the results of necessary type (e.g. in templated functions with deduced params, like std::max) > Apart from that, I at least have no clear > preference for either (functional cast is less verbose, though), and am not > sure whether such a cosmetic clean-up is worth it and wanted. I personally dislike seeing those "static_casts" for what is not casting of value of one type to another type. I felt it a really easy hack for those who might want something very trivial to start. However, I don't mind closing this (and I added you to CC to learn your opinion on this).
(In reply to Mike Kaganski from comment #3) > (In reply to Stephan Bergmann from comment #2) > > Syntactically, functional cast can only be used if > > wanted_type is a simple-type-specifier (e.g., it cannot be used if > > wanted_type is "unsigned long"). > > Works fine for me with unsigned long(9) or unsigned short(9) in VS2019, and > tested to produce the results of necessary type (e.g. in templated functions > with deduced params, like std::max) Retry with a compiler that does not have such a non-standard extension, then. > > Apart from that, I at least have no clear > > preference for either (functional cast is less verbose, though), and am not > > sure whether such a cosmetic clean-up is worth it and wanted. > > I personally dislike seeing those "static_casts" for what is not casting of > value of one type to another type. I felt it a really easy hack for those > who might want something very trivial to start. However, I don't mind > closing this (and I added you to CC to learn your opinion on this). static_cast<long>(1) /is/ about casting an object of type int to an object of type long, just as much as long(1) is. I fail to see what to dislike about the former (apart from its verboseness) but not the latter. I personally would suggest closing this bug as WONTFIX.