Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #85968 > unrolled thread

flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ?

Back to article view | Back to comp.lang.c++

Contents

  flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? "R.Wieser" <address@not.available> - 2022-08-18 07:55 +0200
    Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Ike Naar <ike@sdf.org> - 2022-08-18 06:52 +0000
      Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? "R.Wieser" <address@not.available> - 2022-08-18 09:58 +0200
        Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Muttley@dastardlyhq.com - 2022-08-18 14:50 +0000
          Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? "R.Wieser" <address@not.available> - 2022-08-18 17:12 +0200
          Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? scott@slp53.sl.home (Scott Lurndal) - 2022-08-18 15:29 +0000
            Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-18 16:43 +0100
              Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? scott@slp53.sl.home (Scott Lurndal) - 2022-08-18 16:10 +0000
              Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? David Brown <david.brown@hesbynett.no> - 2022-08-18 21:19 +0200
                Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Manfred <noname@add.invalid> - 2022-08-19 02:57 +0200
                  Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? David Brown <david.brown@hesbynett.no> - 2022-08-19 08:29 +0200
              Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-19 08:12 -0700
            Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-08-18 16:47 +0100
              Re: flags & flagMask == flagMask can be true for flags != flagMask if Muttley@dastardlyhq.com - 2022-08-18 15:50 +0000
              Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-18 10:46 -0700
                Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-18 11:30 -0700
            Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Muttley@dastardlyhq.com - 2022-08-18 15:47 +0000
          Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-19 08:53 -0700
            Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? David Brown <david.brown@hesbynett.no> - 2022-08-19 18:00 +0200
            Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Muttley@dastardlyhq.com - 2022-08-19 16:10 +0000
              Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-19 16:45 -0700
      Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Juha Nieminen <nospam@thanks.invalid> - 2022-08-19 06:01 +0000
        Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-19 16:07 +0100
        Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-19 16:08 +0100
    Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-08-18 16:14 +0100
      Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? "R.Wieser" <address@not.available> - 2022-08-18 18:10 +0200
    Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-18 11:56 -0700
      Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? "R.Wieser" <address@not.available> - 2022-08-18 21:31 +0200
        Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-18 21:24 -0700
          Re: flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ? "R.Wieser" <address@not.available> - 2022-08-19 09:36 +0200

Page 1 of 2  [1] 2  Next page →

#85968 — flags & flagMask == flagMask can be true for flags != flagMask if flags is a superset of flagMask ?

Hello all,

I just read a post on the "thedailywtf" website where someone said (and 
someone else confirmed) :

"flags & flagMask == flagMask can be true for flags != flagMask if flags is 
a superset of flagMask"

If I translate that to assembly language (what I normally work with) it 
doesn't seem to be true :

mov eax,flags
and eax,flagmask
cmp eax,flagmask

AFAIK the last eax *cannot* have any bits set which are not present in 
flagmask.  Therefore, can somebody explain that piece of (I take it) C+ for 
me (Whats the problem with it) ?

The post itself can be found here :

https://thedailywtf.com/articles/comments/flexing-bits

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#85969

On 2022-08-18, R.Wieser <address@not.available> wrote:
> Hello all,
>
> I just read a post on the "thedailywtf" website where someone said (and 
> someone else confirmed) :
>
> "flags & flagMask == flagMask can be true for flags != flagMask if flags is 
> a superset of flagMask"
>
> If I translate that to assembly language (what I normally work with) it 
> doesn't seem to be true :
>
> mov eax,flags
> and eax,flagmask
> cmp eax,flagmask
>
> AFAIK the last eax *cannot* have any bits set which are not present in 
> flagmask.  Therefore, can somebody explain that piece of (I take it) C+ for 
> me (Whats the problem with it) ?

First, == binds stronger than & in C and C++, so

  flags & flagMask == flagMask

is interpreted as

  flags & (flagMask == flagMask)

which can be simplified to

  flags & 1

which is true if the least significant bit of flags is set.
So, for example, if flags = 1 and flagMask = 0 then
flags & (flagMask == flagMask) is true for flags != flagMask.

Your assembly code suggests that you have the priorities of & and ==
reversed, but even in that case, for flags = 1 and flagMask = 0,
-->  flags is a superset of flagMask
-->  flags != flagMask
-->  ((flags & flagMask) == flagMask)  equals  ((1 & 0) == 0)
                                       equals  (0 == 0)
                                       equals  true

[toc] | [prev] | [next] | [standalone]

#85970

Ike,

> First, == binds stronger than & in C and C++

Yep, thats the part that I missed.

>  flags & flagMask == flagMask
>
> is interpreted as
>
>  flags & (flagMask == flagMask)
>
> which can be simplified to
>
>  flags & 1
>
> which is true if the least significant bit of flags is set.

IOW, while that "superset" is technically true, its also confusing the
matter by being unspecific.

but even in that case, for flags = 1 and flagMask = 0,
> -->  flags is a superset of flagMask
> -->  flags != flagMask
> -->  ((flags & flagMask) == flagMask)  equals  ((1 & 0) == 0)
>                                       equals  (0 == 0)
>                                       equals  true

As far as I understood that was exactly what they where aiming for.

Thanks for the precedence heads-up.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#85972

On Thu, 18 Aug 2022 09:58:59 +0200
"R.Wieser" <address@not.available> wrote:
>Ike,
>
>> First, == binds stronger than & in C and C++
>
>Yep, thats the part that I missed.
>
>>  flags & flagMask == flagMask
>>
>> is interpreted as
>>
>>  flags & (flagMask == flagMask)
>>
>> which can be simplified to
>>
>>  flags & 1
>>
>> which is true if the least significant bit of flags is set.
>
>IOW, while that "superset" is technically true, its also confusing the
>matter by being unspecific.
>
>but even in that case, for flags = 1 and flagMask = 0,
>> -->  flags is a superset of flagMask
>> -->  flags != flagMask
>> -->  ((flags & flagMask) == flagMask)  equals  ((1 & 0) == 0)
>>                                       equals  (0 == 0)
>>                                       equals  true
>
>As far as I understood that was exactly what they where aiming for.
>
>Thanks for the precedence heads-up.

If in doubt just use brackets. They're free.

[toc] | [prev] | [next] | [standalone]

#85973

Muttley,

> If in doubt just use brackets. They're free.

It looks that who wrote it wasn't in any doubt - or gambled in the wrong 
direction. :-)

But yes, when it removes doubt or even just improves readability I do that.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#85975

Muttley@dastardlyhq.com writes:
>On Thu, 18 Aug 2022 09:58:59 +0200

>>As far as I understood that was exactly what they where aiming for.
>>
>>Thanks for the precedence heads-up.
>
>If in doubt just use brackets. They're free.

Parentheses work even better.   Unless bracket [] is UK
for parentheses ()?

[toc] | [prev] | [next] | [standalone]

#85976

scott@slp53.sl.home (Scott Lurndal) writes:

> Muttley@dastardlyhq.com writes:
>>On Thu, 18 Aug 2022 09:58:59 +0200
>
>>>As far as I understood that was exactly what they where aiming for.
>>>
>>>Thanks for the precedence heads-up.
>>
>>If in doubt just use brackets. They're free.
>
> Parentheses work even better.   Unless bracket [] is UK
> for parentheses ()?

Yes, in the UK "brackets" are somewhat generic (i.e. any matched pair of
symbols used to convey some extra meaning could be called brackets), but
the default meaning is "()".  The pair "[]" are "square brackets" and
"{}" are "curly brackets", though "braces" has taken hold as the name
for "{}" among computer programmers.  For completeness, "<>" are usually
called "angle brackets".

"Parentheses" is a well-understood term here, but sounds a tiny bit
pretentious!

Are the terms used in the USA absolutely fixed and unambiguous?
I.e. are "brackets" always "[]" even to a linguist?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#85981

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Muttley@dastardlyhq.com writes:
>>>On Thu, 18 Aug 2022 09:58:59 +0200
>>
>>>>As far as I understood that was exactly what they where aiming for.
>>>>
>>>>Thanks for the precedence heads-up.
>>>
>>>If in doubt just use brackets. They're free.
>>
>> Parentheses work even better.   Unless bracket [] is UK
>> for parentheses ()?
>
>Yes, in the UK "brackets" are somewhat generic (i.e. any matched pair of
>symbols used to convey some extra meaning could be called brackets), but
>the default meaning is "()".  The pair "[]" are "square brackets" and
>"{}" are "curly brackets", though "braces" has taken hold as the name
>for "{}" among computer programmers.  For completeness, "<>" are usually
>called "angle brackets".
>
>"Parentheses" is a well-understood term here, but sounds a tiny bit
>pretentious!
>
>Are the terms used in the USA absolutely fixed and unambiguous?
>I.e. are "brackets" always "[]" even to a linguist?

That has been my experience in the computer field.

However, https://en.wikipedia.org/wiki/Bracket_(mathematics),
indicates the term can be used generally rather than specifically.

In programming the distinction matters.

[toc] | [prev] | [next] | [standalone]

#85985

On 18/08/2022 17:43, Ben Bacarisse wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> 
>> Muttley@dastardlyhq.com writes:
>>> On Thu, 18 Aug 2022 09:58:59 +0200
>>
>>>> As far as I understood that was exactly what they where aiming for.
>>>>
>>>> Thanks for the precedence heads-up.
>>>
>>> If in doubt just use brackets. They're free.
>>
>> Parentheses work even better.   Unless bracket [] is UK
>> for parentheses ()?
> 
> Yes, in the UK "brackets" are somewhat generic (i.e. any matched pair of
> symbols used to convey some extra meaning could be called brackets), but
> the default meaning is "()".  The pair "[]" are "square brackets" and
> "{}" are "curly brackets", though "braces" has taken hold as the name
> for "{}" among computer programmers.  For completeness, "<>" are usually
> called "angle brackets".
> 
> "Parentheses" is a well-understood term here, but sounds a tiny bit
> pretentious!
> 

That matches my understanding (also UK).

> Are the terms used in the USA absolutely fixed and unambiguous?
> I.e. are "brackets" always "[]" even to a linguist?
> 

The etymology of "brackets" is a fun story.  Brackets (the square ones) 
were introduced to typography in the early days of Guttenberg's press, 
used to support the lines of type.  Given their function and appearance 
was similar to the "brackets" used to support the walls of Gothic 
cathedrals, they inherited that name.  The cathedral supports got their 
name because someone thought they reminded him of Henry VII's rather 
exaggerated codpiece - and codpieces were sometimes called "brackets" 
meaning "little trousers", the word being a bastardisation of a Breton 
word for "trousers" (which no self-respecting Frenchman or Englishman 
would ever wear at that time) and a French suffix meaning "little".

So if we want to be entirely clear, we should refer to the array 
subscript operator in C as "little trousers", or perhaps codpieces!

[toc] | [prev] | [next] | [standalone]

#85988

On 8/18/2022 9:19 PM, David Brown wrote:
> On 18/08/2022 17:43, Ben Bacarisse wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Muttley@dastardlyhq.com writes:
>>>> On Thu, 18 Aug 2022 09:58:59 +0200
>>>
>>>>> As far as I understood that was exactly what they where aiming for.
>>>>>
>>>>> Thanks for the precedence heads-up.
>>>>
>>>> If in doubt just use brackets. They're free.
>>>
>>> Parentheses work even better.   Unless bracket [] is UK
>>> for parentheses ()?
>>
>> Yes, in the UK "brackets" are somewhat generic (i.e. any matched pair of
>> symbols used to convey some extra meaning could be called brackets), but
>> the default meaning is "()".  The pair "[]" are "square brackets" and
>> "{}" are "curly brackets", though "braces" has taken hold as the name
>> for "{}" among computer programmers.  For completeness, "<>" are usually
>> called "angle brackets".
>>
>> "Parentheses" is a well-understood term here, but sounds a tiny bit
>> pretentious!
>>
> 
> That matches my understanding (also UK).
> 
>> Are the terms used in the USA absolutely fixed and unambiguous?
>> I.e. are "brackets" always "[]" even to a linguist?
>>
> 
> The etymology of "brackets" is a fun story.  Brackets (the square ones) 
> were introduced to typography in the early days of Guttenberg's press, 
> used to support the lines of type.  Given their function and appearance 
> was similar to the "brackets" used to support the walls of Gothic 
> cathedrals, they inherited that name.  The cathedral supports got their 
> name because someone thought they reminded him of Henry VII's rather 
> exaggerated codpiece - and codpieces were sometimes called "brackets" 
> meaning "little trousers", the word being a bastardisation of a Breton 
> word for "trousers" (which no self-respecting Frenchman or Englishman 
> would ever wear at that time) and a French suffix meaning "little".

Could there be any relation with the word "breeches"?

> 
> So if we want to be entirely clear, we should refer to the array 
> subscript operator in C as "little trousers", or perhaps codpieces!
> 

I am missing something on the Gothic cathedral part, though. As far as 
my memory for historic architecture goes, one of the distinctive 
features of those buildings were the so-called "flying buttresses", 
which are in fact curved in nature. Do you mean some other kind of wall 
support?

[toc] | [prev] | [next] | [standalone]

#85994

On 19/08/2022 02:57, Manfred wrote:
> On 8/18/2022 9:19 PM, David Brown wrote:
>> On 18/08/2022 17:43, Ben Bacarisse wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Muttley@dastardlyhq.com writes:
>>>>> On Thu, 18 Aug 2022 09:58:59 +0200
>>>>
>>>>>> As far as I understood that was exactly what they where aiming for.
>>>>>>
>>>>>> Thanks for the precedence heads-up.
>>>>>
>>>>> If in doubt just use brackets. They're free.
>>>>
>>>> Parentheses work even better.   Unless bracket [] is UK
>>>> for parentheses ()?
>>>
>>> Yes, in the UK "brackets" are somewhat generic (i.e. any matched pair of
>>> symbols used to convey some extra meaning could be called brackets), but
>>> the default meaning is "()".  The pair "[]" are "square brackets" and
>>> "{}" are "curly brackets", though "braces" has taken hold as the name
>>> for "{}" among computer programmers.  For completeness, "<>" are usually
>>> called "angle brackets".
>>>
>>> "Parentheses" is a well-understood term here, but sounds a tiny bit
>>> pretentious!
>>>
>>
>> That matches my understanding (also UK).
>>
>>> Are the terms used in the USA absolutely fixed and unambiguous?
>>> I.e. are "brackets" always "[]" even to a linguist?
>>>
>>
>> The etymology of "brackets" is a fun story.  Brackets (the square 
>> ones) were introduced to typography in the early days of Guttenberg's 
>> press, used to support the lines of type.  Given their function and 
>> appearance was similar to the "brackets" used to support the walls of 
>> Gothic cathedrals, they inherited that name.  The cathedral supports 
>> got their name because someone thought they reminded him of Henry 
>> VII's rather exaggerated codpiece - and codpieces were sometimes 
>> called "brackets" meaning "little trousers", the word being a 
>> bastardisation of a Breton word for "trousers" (which no 
>> self-respecting Frenchman or Englishman would ever wear at that time) 
>> and a French suffix meaning "little".
> 
> Could there be any relation with the word "breeches"?

That sounds likely - though in etymology, such things can be misleading 
coincidences.

(I have read about etymological derivations of some words and phrases, 
because it's fun and interesting, but it's not a subject I have studied 
at all.)

> 
>>
>> So if we want to be entirely clear, we should refer to the array 
>> subscript operator in C as "little trousers", or perhaps codpieces!
>>
> 
> I am missing something on the Gothic cathedral part, though. As far as 
> my memory for historic architecture goes, one of the distinctive 
> features of those buildings were the so-called "flying buttresses", 
> which are in fact curved in nature. Do you mean some other kind of wall 
> support?

You can probably imagine the correlation between curved flying 
buttresses and Henry VIII's rather large "little trouser".  The 
evolution of these curved supports towards the straighter and more 
upright "brackets" came gradually in architecture, perhaps from repair 
and strengthening of existing buildings as much as for new ones.

My main reference here, for those that are interested (and want this and 
other stories told more accurately and eloquently!) is this book:

<https://en.wikipedia.org/wiki/The_Etymologicon>

[toc] | [prev] | [next] | [standalone]

#86002

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Muttley@dastardlyhq.com writes:
>>
>>> On Thu, 18 Aug 2022 09:58:59 +0200
>>>
>>>> As far as I understood that was exactly what they where aiming for.
>>>>
>>>> Thanks for the precedence heads-up.
>>>
>>> If in doubt just use brackets.  They're free.
>>
>> Parentheses work even better.   Unless bracket [] is UK
>> for parentheses ()?
>
> Yes, in the UK "brackets" are somewhat generic (i.e. any matched pair of
> symbols used to convey some extra meaning could be called brackets), but
> the default meaning is "()".  The pair "[]" are "square brackets" and
> "{}" are "curly brackets", though "braces" has taken hold as the name
> for "{}" among computer programmers.  For completeness, "<>" are usually
> called "angle brackets".

Sometimes I refer to "<>" as "pointy brackets".

> "Parentheses" is a well-understood term here, but sounds a tiny bit
> pretentious!

To me "parentheses" sounds natural and not at all pretentious.

> Are the terms used in the USA absolutely fixed and unambiguous?
> I.e. are "brackets" always "[]" even to a linguist?

Speaking as someone who has grown up and lived almost all of his
life in a culture and environment that uses American English
almost exclusively (and yes that is the United States), I feel
confident in saying that "brackets" always means "[]", and vice
versa.  Of course in certain contexts people will qualify the
word "brackets" (round brackets, square brackets, curly brackets)
in order to disambiguate different kinds of enclosing symbols.
But for the most part "brackets" without any additional context
means square brackets.

Many years ago there was even a Peanuts cartoon where "brackets"
was used to refer to the [ and ] characters.

[toc] | [prev] | [next] | [standalone]

#85977

On 18/08/2022 16:29, Scott Lurndal wrote:
> Muttley@dastardlyhq.com writes:
>> On Thu, 18 Aug 2022 09:58:59 +0200
> 
>>> As far as I understood that was exactly what they where aiming for.
>>>
>>> Thanks for the precedence heads-up.
>>
>> If in doubt just use brackets. They're free.
> 
> Parentheses work even better.   Unless bracket [] is UK
> for parentheses ()?
> 

I would describe both () and [] as types of brackets (round and square respectively, with round 
being assumed if unqualified).

I'm a UK person.  Wikipedia suggests "In most English-speaking countries, an unqualified 'bracket' 
refers to the round bracket; in the United States, the square bracket.".  Probably the C++ standards 
specify the correct C++ terms?


Mike.

[toc] | [prev] | [next] | [standalone]

#85979 — Re: flags & flagMask == flagMask can be true for flags != flagMask if

On Thu, 18 Aug 2022 16:47:17 +0100
Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>On 18/08/2022 16:29, Scott Lurndal wrote:
>> Muttley@dastardlyhq.com writes:
>>> On Thu, 18 Aug 2022 09:58:59 +0200
>> 
>>>> As far as I understood that was exactly what they where aiming for.
>>>>
>>>> Thanks for the precedence heads-up.
>>>
>>> If in doubt just use brackets. They're free.
>> 
>> Parentheses work even better.   Unless bracket [] is UK
>> for parentheses ()?
>> 
>
>I would describe both () and [] as types of brackets (round and square
>respectively, with round 
>being assumed if unqualified).
>
>I'm a UK person.  Wikipedia suggests "In most English-speaking countries, an
>unqualified 'bracket' 
>refers to the round bracket; in the United States, the square bracket.". 

Even when talking about English prose "brackets" has always meant () , eg
putting something in brackets. I can't imagine why in the USA it would mean
[]. But then american english can be a bit strange sometimes.

[toc] | [prev] | [next] | [standalone]

#85982

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
> On 18/08/2022 16:29, Scott Lurndal wrote:
>> Muttley@dastardlyhq.com writes:
>>> On Thu, 18 Aug 2022 09:58:59 +0200
>> 
>>>> As far as I understood that was exactly what they where aiming for.
>>>>
>>>> Thanks for the precedence heads-up.
>>>
>>> If in doubt just use brackets. They're free.
>> Parentheses work even better.   Unless bracket [] is UK
>> for parentheses ()?
>> 
>
> I would describe both () and [] as types of brackets (round and square
> respectively, with round being assumed if unqualified).
>
> I'm a UK person.  Wikipedia suggests "In most English-speaking
> countries, an unqualified 'bracket' refers to the round bracket; in
> the United States, the square bracket.".  Probably the C++ standards
> specify the correct C++ terms?

In my version of US English, (these) are parentheses (or parens if I'm
in a hurry), [these] are brackets, {these} are braces, and <these> are
angle brackets.  I never refer to (these) as brackets.

But I'm aware that usage differs.  I think that (parentheses), [square
brackets], {curly braces}, and <angle brackets> (or less-than
greater-than) are unambiguous.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#85983

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>> On 18/08/2022 16:29, Scott Lurndal wrote:
>>> Muttley@dastardlyhq.com writes:
>>>> On Thu, 18 Aug 2022 09:58:59 +0200
>>> 
>>>>> As far as I understood that was exactly what they where aiming for.
>>>>>
>>>>> Thanks for the precedence heads-up.
>>>>
>>>> If in doubt just use brackets. They're free.
>>> Parentheses work even better.   Unless bracket [] is UK
>>> for parentheses ()?
>>> 
>>
>> I would describe both () and [] as types of brackets (round and square
>> respectively, with round being assumed if unqualified).
>>
>> I'm a UK person.  Wikipedia suggests "In most English-speaking
>> countries, an unqualified 'bracket' refers to the round bracket; in
>> the United States, the square bracket.".  Probably the C++ standards
>> specify the correct C++ terms?
>
> In my version of US English, (these) are parentheses (or parens if I'm
> in a hurry), [these] are brackets, {these} are braces, and <these> are
> angle brackets.  I never refer to (these) as brackets.
>
> But I'm aware that usage differs.  I think that (parentheses), [square
> brackets], {curly braces}, and <angle brackets> (or less-than
> greater-than) are unambiguous.

And for what it's worth, the Unicode names are:

( 0028;LEFT PARENTHESIS
) 0029;RIGHT PARENTHESIS
[ 005B;LEFT SQUARE BRACKET
] 005D;RIGHT SQUARE BRACKET
{ 007B;LEFT CURLY BRACKET
} 007D;RIGHT CURLY BRACKET
< 003C;LESS-THAN SIGN
> 003E;GREATER-THAN SIGN

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#85978

On Thu, 18 Aug 2022 15:29:37 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Thu, 18 Aug 2022 09:58:59 +0200
>
>>>As far as I understood that was exactly what they where aiming for.
>>>
>>>Thanks for the precedence heads-up.
>>
>>If in doubt just use brackets. They're free.
>
>Parentheses work even better.   Unless bracket [] is UK
>for parentheses ()?

Curly bracket, square bracket, round bracket. Doesn't your dialect have these
terms?

[toc] | [prev] | [next] | [standalone]

#86004

Muttley@dastardlyhq.com writes:

> If in doubt just use brackets.  They're free.

If in doubt, look up the rule and remove the doubt.

[toc] | [prev] | [next] | [standalone]

#86005

On 19/08/2022 17:53, Tim Rentsch wrote:
> Muttley@dastardlyhq.com writes:
> 
>> If in doubt just use brackets.  They're free.
> 
> If in doubt, look up the rule and remove the doubt.

If in doubt then assume others reading the code might also be in doubt, 
so use parentheses (or "round brackets", if you prefer!).

[toc] | [prev] | [next] | [standalone]

#86006

On Fri, 19 Aug 2022 08:53:07 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>Muttley@dastardlyhq.com writes:
>
>> If in doubt just use brackets.  They're free.
>
>If in doubt, look up the rule and remove the doubt.

Yes, so much simpler. 

Very few people remember the precendence of all the operators so only an
arrogant fool wouldn't use brackets if there was any doubt as to what it was.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web