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: Sat, 07 Dec 2019 07:53:44 -0800 Organization: A noiseless patient Spider Lines: 77 Message-ID: <86o8wk3zef.fsf@linuxsc.com> References:

<86tv7dcfxr.fsf@linuxsc.com> <8636e7bvog.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="dc2463479761dea98da7667c87edc47e"; logging-data="7659"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dgoVkk0FBZvSPNwMREw5obTCvw5uuSPg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:vbVcwpErDLK2Yih5mI4n1PBxsYc= sha1:+tExjlfR+xW7DIYSQ/ZGpXD0f48= Xref: csiph.com comp.lang.c++:70336 "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? > 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. > 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. Taking all of these together, the objections given sound more like rationalizations trying to justify an overarching dislike of macros than objectively reasoned conclusions.