Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70089 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2019-11-28 12:19 -0800 |
| Last post | 2020-02-18 18:46 +0100 |
| Articles | 20 on this page of 113 — 20 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:19 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-29 00:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 09:15 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-29 10:58 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 12:49 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-07 07:53 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-12-07 08:22 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:44 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-10 23:44 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:08 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:42 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:09 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:14 -0800
Re: two's complement idea Daniel <danielaparker@gmail.com> - 2020-01-21 13:08 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-22 00:07 -0500
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-21 23:21 -0800
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 01:51 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-22 11:28 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 11:52 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-22 04:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:19 -0700
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:07 -0700
Re: two's complement idea boltar@nowhere.org - 2020-01-21 16:44 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-21 20:01 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-22 11:26 +0000
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2020-01-22 20:04 +0100
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 11:30 -0800
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 19:57 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:24 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-24 07:29 +1300
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-23 10:09 +0100
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:29 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:08 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-24 12:27 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:06 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 10:07 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 11:36 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-24 17:34 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2020-01-24 17:57 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 12:19 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 14:19 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 14:11 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:26 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 17:35 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 22:27 +0200
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:21 -0500
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 11:06 +1300
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 22:12 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:24 -0500
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 09:04 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 04:15 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 19:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 00:05 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 01:19 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 19:50 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 11:57 +0000
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-25 13:42 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 14:58 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:58 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:34 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 12:41 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 16:08 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 02:20 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-27 15:03 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 06:44 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-06 10:18 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:05 -0700
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 20:03 +0300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:37 -0700
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:45 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 19:56 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 09:49 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 21:33 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:00 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 22:23 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:46 +1300
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 10:55 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-26 03:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:28 -0800
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 22:22 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-25 18:24 -0500
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 12:54 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 12:44 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 14:58 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 14:53 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 19:10 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:20 -0600
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 20:51 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 21:02 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-26 19:06 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 18:50 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 14:18 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-27 22:13 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 21:38 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 19:37 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-27 19:15 -0800
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-28 11:45 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 16:31 +1300
Re: two's complement idea Manfred <noname@add.invalid> - 2020-01-26 18:50 +0100
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-26 18:57 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 20:46 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:14 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 22:15 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 21:06 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-28 13:08 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:50 -0800
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 08:21 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:12 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 07:48 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-18 18:46 +0100
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-28 12:19 -0800 |
| Subject | Re: two's complement idea |
| Message-ID | <8636e7bvog.fsf@linuxsc.com> |
Öö Tiib <ootiib@hot.ee> writes: > On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote: > >> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >> >>> On 05.11.2019 03:55, Siri Cruise wrote: >>> >>>> In article <qppva0$cbj$1@news.albasani.net>, >>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> >>>>> What would realls speak against that numieric_limits<type> 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 This doesn't answer my question. I understand that macros have shortcomings in some applications. The question is why do C++ fans hate using macros even when, like here, the shortcomings don't apply?
[toc] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2019-11-29 00:14 +0100 |
| Message-ID | <qrpkc3$47r$1@dont-email.me> |
| In reply to | #70089 |
On 28.11.2019 21:19, Tim Rentsch wrote: > Öö Tiib <ootiib@hot.ee> writes: > >> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote: >> >>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>> >>>> On 05.11.2019 03:55, Siri Cruise wrote: >>>> >>>>> In article <qppva0$cbj$1@news.albasani.net>, >>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>> >>>>>> What would realls speak against that numieric_limits<type> 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. Perhaps both define it as above but using library B you get a redefinition warning. And for example, regarding the so far not mentioned visual impact, the shouting uppercase is an annoying eyesore. - Alf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-29 09:15 +0100 |
| Message-ID | <qrqk3b$7ac$1@dont-email.me> |
| In reply to | #70098 |
On 29/11/2019 00:14, Alf P. Steinbach wrote:
> On 28.11.2019 21:19, Tim Rentsch wrote:
>> Öö Tiib <ootiib@hot.ee> writes:
>>
>>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote:
>>>
>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>
>>>>> On 05.11.2019 03:55, Siri Cruise wrote:
>>>>>
>>>>>> In article <qppva0$cbj$1@news.albasani.net>,
>>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>>
>>>>>>> What would realls speak against that numieric_limits<type> 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. Perhaps both define it as above but using library B
> you get a redefinition warning.
>
> And for example, regarding the so far not mentioned visual impact, the
> shouting uppercase is an annoying eyesore.
>
To be fair, you don't have to use all-caps for macros. Personally, I
only use all-caps for macros if the fact that it is a macro is
important. So I would write:
#define noOfWotsits 10
just as I would write
enum { noOfWotists = 10 };
static const int noOfWotsits = 10;
const int noOfWotsits = 10; // C++ only
depending on the language (C, C++, or compatible with both) and what I
want to be able to do with it. Disregarding scoping, these will all
have the same effect in almost all sensible uses - I see no earthly
reason to insist that one version should be written in all-caps and the
others in your favourite multi-word style (snake, camel, etc.).
But if I had written this macro (which I would not do - it's just an
example):
#define SQUARE(x) ((x) * (X))
then I would use all-caps, because it is important to understand that it
is a macro.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-11-29 10:58 +0100 |
| Message-ID | <h4c8ecFq8ljU1@mid.individual.net> |
| In reply to | #70140 |
On 2019-11-29 at 09:15, David Brown wrote:
> On 29/11/2019 00:14, Alf P. Steinbach wrote:
>> On 28.11.2019 21:19, Tim Rentsch wrote:
>>> Öö Tiib <ootiib@hot.ee> writes:
>>>
>>>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote:
>>>>
>>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>>
>>>>>> On 05.11.2019 03:55, Siri Cruise wrote:
>>>>>>
>>>>>>> In article <qppva0$cbj$1@news.albasani.net>,
>>>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>>>
>>>>>>>> What would realls speak against that numieric_limits<type> 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. Perhaps both define it as above but using library B
>> you get a redefinition warning.
>>
>> And for example, regarding the so far not mentioned visual impact, the
>> shouting uppercase is an annoying eyesore.
>>
>
> To be fair, you don't have to use all-caps for macros. Personally, I
> only use all-caps for macros if the fact that it is a macro is
> important. So I would write:
>
> #define noOfWotsits 10
>
> just as I would write
>
> enum { noOfWotists = 10 };
> static const int noOfWotsits = 10;
> const int noOfWotsits = 10; // C++ only
>
> depending on the language (C, C++, or compatible with both) and what I
> want to be able to do with it. Disregarding scoping, these will all
> have the same effect in almost all sensible uses - I see no earthly
> reason to insist that one version should be written in all-caps and the
> others in your favourite multi-word style (snake, camel, etc.).
>
> But if I had written this macro (which I would not do - it's just an
> example):
>
> #define SQUARE(x) ((x) * (X))
>
> then I would use all-caps, because it is important to understand that it
> is a macro.
>
The problem is still that macros defies the use of scopes and namespaces.
Unlike you are one of the "members with godly hands" referred to above,
a slight mistake might break the next version of the standard library.
Note that the appendix "Index of library names" has grown from 35 to 70
pages between C++14 and C++20. None of these may be #define'ed.
Just try
#define general "Patton"
to break floating-point formatting, or
#define Init 0
to get odd compile errors from most I/O, or try
#define a 'a'
to disable <random> numbers.
And the library reserved names use all versions of lower_case,
UPPER_CASE, and Mixed.
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-29 12:49 +0100 |
| Message-ID | <qrr0kg$n68$1@dont-email.me> |
| In reply to | #70145 |
On 29/11/2019 10:58, Bo Persson wrote:
> On 2019-11-29 at 09:15, David Brown wrote:
>> On 29/11/2019 00:14, Alf P. Steinbach wrote:
>>> On 28.11.2019 21:19, Tim Rentsch wrote:
>>>> Öö Tiib <ootiib@hot.ee> writes:
>>>>
>>>>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote:
>>>>>
>>>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>>>
>>>>>>> On 05.11.2019 03:55, Siri Cruise wrote:
>>>>>>>
>>>>>>>> In article <qppva0$cbj$1@news.albasani.net>,
>>>>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> What would realls speak against that numieric_limits<type> 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. Perhaps both define it as above but using library B
>>> you get a redefinition warning.
>>>
>>> And for example, regarding the so far not mentioned visual impact, the
>>> shouting uppercase is an annoying eyesore.
>>>
>>
>> To be fair, you don't have to use all-caps for macros. Personally, I
>> only use all-caps for macros if the fact that it is a macro is
>> important. So I would write:
>>
>> #define noOfWotsits 10
>>
>> just as I would write
>>
>> enum { noOfWotists = 10 };
>> static const int noOfWotsits = 10;
>> const int noOfWotsits = 10; // C++ only
>>
>> depending on the language (C, C++, or compatible with both) and what I
>> want to be able to do with it. Disregarding scoping, these will all
>> have the same effect in almost all sensible uses - I see no earthly
>> reason to insist that one version should be written in all-caps and the
>> others in your favourite multi-word style (snake, camel, etc.).
>>
>> But if I had written this macro (which I would not do - it's just an
>> example):
>>
>> #define SQUARE(x) ((x) * (X))
>>
>> then I would use all-caps, because it is important to understand that it
>> is a macro.
>>
>
> The problem is still that macros defies the use of scopes and namespaces.
>
They do - and when considering "what is the clearest, simplest, most
maintainable, most efficient choice" for a fixed value or re-usable
sequence of code or characters, then that counts against macros.
Whether these count as "problems" or not will depend on the code, and
where they are defined. Macros within an implementation file are rarely
an issue for scoping - if they are, your implementation file is probably
too big, or you have too little imagination in naming your identifiers.
But macros in headers can have wider implications.
> Unlike you are one of the "members with godly hands" referred to above,
> a slight mistake might break the next version of the standard library.
That's a risk, certainly. I am a big fan of specifying exactly what
standard I want for my code - I don't change versions of the standard
library willy-nilly. There are many things that can be badly affected,
not just because of macros.
> Note that the appendix "Index of library names" has grown from 35 to 70
> pages between C++14 and C++20. None of these may be #define'ed.
>
> Just try
>
> #define general "Patton"
>
> to break floating-point formatting, or
>
> #define Init 0
>
> to get odd compile errors from most I/O, or try
>
> #define a 'a'
>
> to disable <random> numbers.
>
>
> And the library reserved names use all versions of lower_case,
> UPPER_CASE, and Mixed.
>
Perhaps you misunderstood my post. I didn't say "use lots of macros",
or "macros are risk-free", or "macros are better than const". I simply
said that when I choose to use a macro, I don't give it a shouty name
unless I really need it to shout "I am a macro". Your points are all
good reasons to prefer something other than macros (templates, const,
inline functions, etc.) where practical, and I don't disagree with any
of them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-12-07 07:53 -0800 |
| Message-ID | <86o8wk3zef.fsf@linuxsc.com> |
| In reply to | #70098 |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: > On 28.11.2019 21:19, Tim Rentsch wrote: > >> <<D6 F6 [05b6]>> Tiib <ootiib@hot.ee> writes: >> >>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote: >>> >>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>>> >>>>> On 05.11.2019 03:55, Siri Cruise wrote: >>>>> >>>>>> In article <qppva0$cbj$1@news.albasani.net>, >>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>>> >>>>>>> What would realls speak against that numieric_limits<type> 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.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-07 08:22 -0800 |
| Message-ID | <8ef21e91-6984-44d1-8585-568b245c5924@googlegroups.com> |
| In reply to | #70336 |
On Saturday, 7 December 2019 17:53:56 UTC+2, Tim Rentsch wrote: > "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: > > > On 28.11.2019 21:19, Tim Rentsch wrote: > > > >> <<D6 F6 [05b6]>> Tiib <ootiib@hot.ee> writes: > >> > >>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote: > >>> > >>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: > >>>> > >>>>> On 05.11.2019 03:55, Siri Cruise wrote: > >>>>> > >>>>>> In article <qppva0$cbj$1@news.albasani.net>, > >>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: > >>>>>> > >>>>>>> What would realls speak against that numieric_limits<type> 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: <http://coliru.stacked-crooked.com/a/65fc657ef88c80fa> 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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 20:44 -0800 |
| Message-ID | <8636cm4n6l.fsf@linuxsc.com> |
| In reply to | #70337 |
Öö Tiib <ootiib@hot.ee> writes:
> On Saturday, 7 December 2019 17:53:56 UTC+2, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>
>>> On 28.11.2019 21:19, Tim Rentsch wrote:
>>>
>>>> <<D6 F6 [05b6]>> Tiib <ootiib@hot.ee> writes:
>>>>
>>>>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote:
>>>>>
>>>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>>>
>>>>>>> On 05.11.2019 03:55, Siri Cruise wrote:
>>>>>>>
>>>>>>>> In article <qppva0$cbj$1@news.albasani.net>,
>>>>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> What would realls speak against that numieric_limits<type> 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:
> <http://coliru.stacked-crooked.com/a/65fc657ef88c80fa>
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-10 23:44 -0800 |
| Message-ID | <70e7d1bf-c994-49f4-bad4-15f386b8adca@googlegroups.com> |
| In reply to | #71272 |
On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote:
> 嘱 Tiib <ootiib@hot.ee> writes:
>
> > On Saturday, 7 December 2019 17:53:56 UTC+2, Tim Rentsch wrote:
> >
> >> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> >>
> >>> On 28.11.2019 21:19, Tim Rentsch wrote:
> >>>
> >>>> <<D6 F6 [05b6]>> Tiib <ootiib@hot.ee> writes:
> >>>>
> >>>>> On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote:
> >>>>>
> >>>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> >>>>>>
> >>>>>>> On 05.11.2019 03:55, Siri Cruise wrote:
> >>>>>>>
> >>>>>>>> In article <qppva0$cbj$1@news.albasani.net>,
> >>>>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> What would realls speak against that numieric_limits<type> 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:
> > <http://coliru.stacked-crooked.com/a/65fc657ef88c80fa>
> > What you suggest to do with these annoying warnings? Silence?
> > Branch library code? Get the authors to cooperate?
Crickets chirping? No answers?
> >>> 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.
Programmer who is ordered to write software for platform where he
can not avoid wasting workdays into dealing with that misuse of
feature by platform vendors still can not avoid disliking the
feature that allows such annoying misuses. Especially in places
where usage of inline functions, templates or constants would
be as simple but would not cause the issues existence of whose
you dismiss.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-14 07:08 -0800 |
| Message-ID | <86imlegjnx.fsf@linuxsc.com> |
| In reply to | #71277 |
Tiib writes: > On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: [...] >> 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. > > Programmer who is ordered to write software for platform where he > can not avoid wasting workdays into dealing with that misuse of > feature by platform vendors still can not avoid disliking the > feature that allows such annoying misuses. Especially in places > where usage of inline functions, templates or constants would > be as simple but would not cause the issues existence of whose > you dismiss. That may be interesting but it doesn't address the question I was asking.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-14 08:42 -0800 |
| Message-ID | <ab3b7fcc-39f8-4baf-9f64-9d111c7d4901@googlegroups.com> |
| In reply to | #71339 |
On Tuesday, 14 January 2020 17:08:45 UTC+2, Tim Rentsch wrote: > Tiib writes: > > > On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: > > [...] > > >> 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. > > > > Programmer who is ordered to write software for platform where he > > can not avoid wasting workdays into dealing with that misuse of > > feature by platform vendors still can not avoid disliking the > > feature that allows such annoying misuses. Especially in places > > where usage of inline functions, templates or constants would > > be as simple but would not cause the issues existence of whose > > you dismiss. > > That may be interesting but it doesn't address the question > I was asking. Your question was "Why do C++ fans hate the C preprocessor so much?".
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-21 02:09 -0800 |
| Message-ID | <86muahjf37.fsf@linuxsc.com> |
| In reply to | #71343 |
Tiib writes: > On Tuesday, 14 January 2020 17:08:45 UTC+2, Tim Rentsch wrote: > >> Tiib writes: >> >>> On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: >> >> [...] >> >>>> 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. >>> >>> Programmer who is ordered to write software for platform where he >>> can not avoid wasting workdays into dealing with that misuse of >>> feature by platform vendors still can not avoid disliking the >>> feature that allows such annoying misuses. Especially in places >>> where usage of inline functions, templates or constants would >>> be as simple but would not cause the issues existence of whose >>> you dismiss. >> >> That may be interesting but it doesn't address the question >> I was asking. > > Your question was "Why do C++ fans hate the C preprocessor so much?". Yes, and your responses don't speak to that question. They do explain why you don't like how some people use macros, but nothing about the macros themselves. My question is about reactions to the preprocessor (and macros in particular), not about reactions to how people might misuse it. Do you not understand the difference?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-21 05:14 -0800 |
| Message-ID | <276f4fb9-bf3e-4e61-aee1-43afd7466630@googlegroups.com> |
| In reply to | #71481 |
On Tuesday, January 21, 2020 at 5:09:42 AM UTC-5, Tim Rentsch wrote: > Tiib writes: > > > On Tuesday, 14 January 2020 17:08:45 UTC+2, Tim Rentsch wrote: > > > >> Tiib writes: > >> > >>> On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: > >> > >> [...] > >> > >>>> 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. > >>> > >>> Programmer who is ordered to write software for platform where he > >>> can not avoid wasting workdays into dealing with that misuse of > >>> feature by platform vendors still can not avoid disliking the > >>> feature that allows such annoying misuses. Especially in places > >>> where usage of inline functions, templates or constants would > >>> be as simple but would not cause the issues existence of whose > >>> you dismiss. > >> > >> That may be interesting but it doesn't address the question > >> I was asking. > > > > Your question was "Why do C++ fans hate the C preprocessor so much?". > > Yes, and your responses don't speak to that question. They do > explain why you don't like how some people use macros, but > nothing about the macros themselves. My question is about > reactions to the preprocessor (and macros in particular), not > about reactions to how people might misuse it. Do you not > understand the difference? Do you don't understand that he considers that the way they invite misuse, might be precisely the thing that he finds objectionable about macros? That is a problem that involves both the macros and their users, but you can't change the way most people behave, so it's fair to level such a criticism against macros themselves. That certainly seems to me to be the obvious interpretation of his words. I say this without implying that I share that opinion.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2020-01-21 13:08 -0800 |
| Message-ID | <7995159b-043d-48da-a452-f8b2b855888e@googlegroups.com> |
| In reply to | #71485 |
On Tuesday, January 21, 2020 at 8:14:33 AM UTC-5, James Kuyper wrote: > > Do you don't understand that he considers that the way they invite > misuse, might be precisely the thing that he finds objectionable about > macros? What is there in C++ that _doesn't_ invite misuse? Even features introduced comparatively late collide with each other, e.g. uniform initialization and initializer lists, or with features of the world, e.g. `std::error_category::operator==` and DLL's and shared libraries. It is in the nature of the language. Daniel
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-22 00:07 -0500 |
| Message-ID | <r08la2$q67$2@dont-email.me> |
| In reply to | #71495 |
On 1/21/20 4:08 PM, Daniel wrote: > On Tuesday, January 21, 2020 at 8:14:33 AM UTC-5, James Kuyper wrote: >> >> Do you don't understand that he considers that the way they invite >> misuse, might be precisely the thing that he finds objectionable about >> macros? > > What is there in C++ that _doesn't_ invite misuse? Somethings invite misuse more strongly than others. He was expressing his judgement that macros invite abuse too strongly.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-21 23:21 -0800 |
| Message-ID | <93b11a6e-f41c-4ac7-9d08-d2510789e13e@googlegroups.com> |
| In reply to | #71495 |
On Tuesday, 21 January 2020 23:08:36 UTC+2, Daniel wrote: > On Tuesday, January 21, 2020 at 8:14:33 AM UTC-5, James Kuyper wrote: > > > > Do you don't understand that he considers that the way they invite > > misuse, might be precisely the thing that he finds objectionable about > > macros? > > What is there in C++ that _doesn't_ invite misuse? Even features introduced > comparatively late collide with each other, e.g. uniform initialization and > initializer lists, or with features of the world, e.g. `std::error_category::operator==` and DLL's and shared libraries. It is in the nature of the language. Unfortunately yes, there are piles of bear traps in C++. Loose initialization semantics was what I felt to be worst about C++11 (that was otherwise great progress). But the issue is local to concrete initialization of variables óf concrete type. Macros like "min()" and "max()" from windows.h however screw up any min and max. It does not matter if it is std::max(), std::numeric_limits<int>::max() or thatlib::suchstruct::max(). Now and then someone trying to run some (perfectly well-formed and portable) code on windows wastes some time with that nuisance, globally, ... and there are nothing to do about it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-22 01:51 -0800 |
| Message-ID | <87zhef7r9e.fsf@nosuchdomain.example.com> |
| In reply to | #71497 |
Öö Tiib <ootiib@hot.ee> writes:
[...]
> Macros like "min()" and "max()" from windows.h however screw up any
> min and max. It does not matter if it is std::max(), std::numeric_limits<int>::max() or thatlib::suchstruct::max().
> Now and then someone trying to run some (perfectly well-formed
> and portable) code on windows wastes some time with that
> nuisance, globally, ... and there are nothing to do about it.
You mean nothing other than
#undef min
#undef max
?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-22 11:28 +0100 |
| Message-ID | <r0983i$idi$1@dont-email.me> |
| In reply to | #71500 |
On 22/01/2020 10:51, Keith Thompson wrote: > Öö Tiib <ootiib@hot.ee> writes: > [...] >> Macros like "min()" and "max()" from windows.h however screw up any >> min and max. It does not matter if it is std::max(), std::numeric_limits<int>::max() or thatlib::suchstruct::max(). >> Now and then someone trying to run some (perfectly well-formed >> and portable) code on windows wastes some time with that >> nuisance, globally, ... and there are nothing to do about it. > > You mean nothing other than > #undef min > #undef max > ? > That would work, unless there is something in the code that uses these macros. (Presumably there is some reason for them being in windows.h in the first place, and some code uses them.) But it must surely be possible to include "windows.h", then any other windows-specific headers (that might rely on the windows.h definition of the macros), then do the undef's, then include standard C++ headers, application headers, and the main code. It might be a bit ugly - personally I dislike anything that forces a particular ordering on include files - but I can't think off hand of any reason it wouldn't work.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-22 11:52 +0100 |
| Message-ID | <r099h0$rid$1@news.albasani.net> |
| In reply to | #71505 |
>> You mean nothing other than >> #undef min >> #undef max >> ? >> > That would work, unless there is something in the code that uses these > macros. (Presumably there is some reason for them being in windows.h in > the first place, and some code uses them.) > > But it must surely be possible to include "windows.h", then any other > windows-specific headers (that might rely on the windows.h definition of > the macros), then do the undef's, then include standard C++ headers, > application headers, and the main code. It might be a bit ugly - > personally I dislike anything that forces a particular ordering on > include files - but I can't think off hand of any reason it wouldn't work. If you include <Windows.h> and don't want min / max to be defined you have to #define NOMINMAX before including <Windows.h>.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-22 04:47 -0800 |
| Message-ID | <b0f47584-1b5c-44f7-8898-3bfe1dddc230@googlegroups.com> |
| In reply to | #71505 |
On Wednesday, 22 January 2020 12:28:11 UTC+2, David Brown wrote: > On 22/01/2020 10:51, Keith Thompson wrote: > > Öö Tiib <ootiib@hot.ee> writes: > > [...] > >> Macros like "min()" and "max()" from windows.h however screw up any > >> min and max. It does not matter if it is std::max(), std::numeric_limits<int>::max() or thatlib::suchstruct::max(). > >> Now and then someone trying to run some (perfectly well-formed > >> and portable) code on windows wastes some time with that > >> nuisance, globally, ... and there are nothing to do about it. > > > > You mean nothing other than > > #undef min > > #undef max > > ? > > > > That would work, unless there is something in the code that uses these > macros. (Presumably there is some reason for them being in windows.h in > the first place, and some code uses them.) > > But it must surely be possible to include "windows.h", then any other > windows-specific headers (that might rely on the windows.h definition of > the macros), then do the undef's, then include standard C++ headers, > application headers, and the main code. It might be a bit ugly - > personally I dislike anything that forces a particular ordering on > include files - but I can't think off hand of any reason it wouldn't work. Issue is manifesting as obscure compiler error messages in some standard library implementation file included by <limits> that most programmers who use C++ are not skilled enough to write themselves. Figuring out that it is because of #include <windows.h> in header (that they also likely did not write) takes some time, swapping the header files, adding #undefs or adding -D NOMINMAX to command line is trivial. Therefore macros can be used and are used in practice by major platform vendor to make things painful here, nuisance there and sucky at third place. Motivation of platform vendor is understandable, it wants to herd programmers to use C# on their platform. But why should it cause love towards macros to grow among C++ programmers?
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web