Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: two's complement idea Date: Fri, 10 Jan 2020 20:44:18 -0800 Organization: A noiseless patient Spider Lines: 108 Message-ID: <8636cm4n6l.fsf@linuxsc.com> References:

<86tv7dcfxr.fsf@linuxsc.com> <8636e7bvog.fsf@linuxsc.com> <86o8wk3zef.fsf@linuxsc.com> <8ef21e91-6984-44d1-8585-568b245c5924@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="a658bb27d1b88b897660621da5fe7a9e"; logging-data="25741"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19K4FSNpTKN6UJPxXxdLInkDAVegV/nSTU=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:X0VgDFoIxSf8NN/iYT348c+OlrU= sha1:XaJGTKYi+lVm8XqBIcvYI39OVGo= Xref: csiph.com comp.lang.c++:71272 Öö Tiib writes: > On Saturday, 7 December 2019 17:53:56 UTC+2, Tim Rentsch wrote: > >> "Alf P. Steinbach" writes: >> >>> On 28.11.2019 21:19, Tim Rentsch wrote: >>> >>>> <> Tiib writes: >>>> >>>>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote: >>>>> >>>>>> "Alf P. Steinbach" writes: >>>>>> >>>>>>> On 05.11.2019 03:55, Siri Cruise wrote: >>>>>>> >>>>>>>> In article , >>>>>>>> Bonita Montero wrote: >>>>>>>> >>>>>>>>> What would realls speak against that numieric_limits would >>>>>>>>> {} include >>>>>>>>> a flag whether a type has a two's complement and maybe another flag >>>>>>>>> {} that >>>>>>>>> says that a type has a two's complement wrap-around? >>>>>>>> >>>>>>>> #define ONESCOMPLEMENT (-1==~1) >>>>>>>> #define TWOSCOMPLEMENT (-1==~0) >>>>>>> >>>>>>> Nice idea. >>>>>>> >>>>>>> But please use `constexpr` or `const` declarations, not macros. >>>>>>> >>>>>>> Using macros conveys the idea that macros are a reasonable solution to >>>>>>> the problem of naming a compile time constant. >>>>>> >>>>>> Why do C++ fans hate the C preprocessor so much? >>>>> >>>>> It is not hate. We prefer to use macros when what these do can not >>>>> be done as simply by using inline functions, templates or constants. >>>>> >>>>> Reasons are that macros are names that ignore scope and work on >>>>> textual substitutions. Macros are harder to debug and cause >>>>> unanticipated effects and confusion in clumsy hands. However for >>>>> teams that manage to hire members with godly hands macros are >>>>> fine. :D >>>> >>>> [snip] here, the shortcomings [of macros] don't apply? >>> >>> They do. >>> >>> For example, regarding what was mentioned about scope, you generally >>> can't have two libraries that both define `ONESCOMPLEMENT`. Perhaps >>> library A defines it as above but library B defines it to produce a >>> one's complement. >> >> A macro may be defined in places other than public libraries. Or >> if it is defined in a public library, and a possible ambiguity is >> important to remove, it's easy enough to prefix the macro name >> with the namespace used for the library. Would you have the same >> objection to using a macro if the macro were not defined in a >> public library? > > The authors of libraries are often competitors and so do not like > that you pick and integrate best of breed from their products. > The bigger ones seemingly even enjoy introducing such conflicts > and contradictions. Sometimes even with standard library. Anyone > targeting Windows had sooner or later to look up what to do with > min and max macros in windows.h. > >>> Perhaps both define it as above but using library B you get a >>> redefinition warning. >> >> I don't know why you think that. Giving several identical >> definitions for a macro is allowed in C90, C99, C11, C++98, >> C++03, C++11, C++14, and C++17. Testing with gcc, clang, g++, >> and clang++ gave no diagnostics even with -Wall and -Wextra. > > Libraries next to never define macro identical to letter and so > tests show opposite: > > What you suggest to do with these annoying warnings? Silence? > Branch library code? Get the authors to cooperate? > >>> And for example, regarding the so far not mentioned visual >>> impact, the shouting uppercase is an annoying eyesore. >> >> But that has nothing to do with the macro processor. You are >> perfectly free to choose a name that is not all uppercase, or >> even all lowercase, if you'd rather. What you said might be an >> argument about how to name a macro but it is not an argument >> about whether to use a macro. > > I agree. We can just configure our tools and text editors to show > macros with different color if we for some reason want these to stand > out visually at all. However lot of coding standards have those rules > in and so majority of macros that we face are in SCREAMING_CAPS. > >> Taking all of these together, the objections given sound more >> like rationalizations trying to justify an overarching dislike of >> macros than objectively reasoned conclusions. > > Sure, if you dismiss all problems (that we have tired of facing in > practice) with claim that those do not exist then answering to your > question why we avoid macros is impossible. Your comments are not really about macros but about how various people misuse macros. Any language feature can be misused. My question is about macros, not about people who misuse them.