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

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

Simultaneous read and write on a variable in C++

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

Contents

  Simultaneous read and write on a variable in C++ Novice Coder <extngg1@gmail.com> - 2012-01-11 09:08 -0800
    Re: Simultaneous read and write on a variable in C++ Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-11 12:28 -0500
      Re: Simultaneous read and write on a variable in C++ Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-12 13:07 -0500
        Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 10:11 -0800
          Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 18:46 +0000
            Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 11:18 -0800
              Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 19:28 +0000
                Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 19:41 +0000
                  Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 11:46 -0800
                Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 11:44 -0800
                  Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 19:46 +0000
                    Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 19:53 +0000
                      Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 12:01 -0800
                        Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 20:10 +0000
                          Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 12:13 -0800
                            Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 20:31 +0000
                        Re: Simultaneous read and write on a variable in C++ scott@slp53.sl.home (Scott Lurndal) - 2012-01-13 18:12 +0000
                Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 11:37 -0800
                  Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 19:56 +0000
                    Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 11:58 -0800
                      Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 20:04 +0000
                Re: Simultaneous read and write on a variable in C++ Juha Nieminen <nospam@thanks.invalid> - 2012-01-13 06:34 +0000
    Re: Simultaneous read and write on a variable in C++ SG <s.gesemann@gmail.com> - 2012-01-11 13:11 -0800
    Re: Simultaneous read and write on a variable in C++ Calum <spambox@calumgrant.net> - 2012-01-11 13:18 -0800
    Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 03:11 -0800
      Re: Simultaneous read and write on a variable in C++ "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2012-01-12 16:35 +0100
        Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 08:06 -0800
      Re: Simultaneous read and write on a variable in C++ gwowen <gwowen@gmail.com> - 2012-01-12 07:48 -0800
        Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-12 07:55 -0800
          Re: Simultaneous read and write on a variable in C++ Gareth Owen <gwowen@gmail.com> - 2012-01-12 19:36 +0000
            Re: Simultaneous read and write on a variable in C++ Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-12 16:31 -0500
      Re: Simultaneous read and write on a variable in C++ Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-13 02:05 -0800
      Re: Simultaneous read and write on a variable in C++ Goran <goran.pusic@gmail.com> - 2012-01-13 04:24 -0800
        Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoonsaurav.nit@gmail.com> - 2012-01-13 04:52 -0800
    Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 12:39 +0000
    Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 12:50 +0000
      Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 12:58 +0000
        Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoon@parallocity.com> - 2012-01-12 05:55 -0800
          Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 13:59 +0000
            Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoon@parallocity.com> - 2012-01-12 06:14 -0800
              Re: Simultaneous read and write on a variable in C++ Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 14:30 +0000
              Re: Simultaneous read and write on a variable in C++ Juha Nieminen <nospam@thanks.invalid> - 2012-01-12 14:34 +0000
      Re: Simultaneous read and write on a variable in C++ Prasoon Saurav <prasoon@parallocity.com> - 2012-01-12 05:54 -0800
    Re: Simultaneous read and write on a variable in C++ BCFD36 <bcfd36@cruzio.com> - 2012-01-14 01:52 -0800

Page 1 of 3  [1] 2 3  Next page →

#13246 — Simultaneous read and write on a variable in C++

Here is the code

int main()
{
    char *p;
    char a[]={"Hello"};
    (p=a)[0]; // This line
    return 0;
}

Is the behaviour of this code undefined in C++?

[toc] | [next] | [standalone]

#13248

On 1/11/2012 12:08 PM, Novice Coder wrote:
> Here is the code
>
> int main()
> {
>      char *p;
>      char a[]={"Hello"};
>      (p=a)[0]; // This line
>      return 0;
> }
>
> Is the behaviour of this code undefined in C++?

Yes, AFAIK.  There is no intervening sequence point between the 
assignment and indexing.  Even though there are parentheses, it is not 
guaranteed that the compiler isn't going to "optimize" it and use the 
previous value of 'p' (undefined) for dereferencing it.  If you need to 
introduce a sequence point, use the comma:

     p=a,p[0]; // no problem

V
-- 
I do not respond to top-posted replies, please don't ask

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

#13291

On 1/11/2012 12:28 PM, Victor Bazarov wrote:
> On 1/11/2012 12:08 PM, Novice Coder wrote:
>> Here is the code
>>
>> int main()
>> {
>> char *p;
>> char a[]={"Hello"};
>> (p=a)[0]; // This line
>> return 0;
>> }
>>
>> Is the behaviour of this code undefined in C++?
>
> Yes, AFAIK. There is no intervening sequence point between the
> assignment and indexing. Even though there are parentheses, it is not
> guaranteed that the compiler isn't going to "optimize" it and use the
> previous value of 'p' (undefined) for dereferencing it.

I think now that I was wrong there.  The expression in parentheses has 
the value the same as 'a', and *that* is used to dereference the pointer 
(the indexing is adding the index and then dereferencing).  The relevant 
portion of the Standard (using the latest Draft):

<<The assignment operator (=) and the compound assignment operators all 
group right-to-left. All require a modifiable lvalue as their left 
operand and return an lvalue referring to the left operand. The result 
in all cases is a bit-field if the left operand is a bit-field. In all 
cases, the assignment is sequenced after the value computation of the 
right and left operands, and before the value computation of the 
assignment expression.>>

The last sentence is important, I believe.  "Sequenced" is the key word.

 > If you need to
> introduce a sequence point, use the comma:
>
> p=a,p[0]; // no problem
>
> V

V
-- 
I do not respond to top-posted replies, please don't ask

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

#13292

On Jan 12, 11:07 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>
>
>
>
>
>
>
>
>
> > On 1/11/2012 12:08 PM, Novice Coder wrote:
> >> Here is the code
>
> >> int main()
> >> {
> >> char *p;
> >> char a[]={"Hello"};
> >> (p=a)[0]; // This line
> >> return 0;
> >> }
>
> >> Is the behaviour of this code undefined in C++?
>
> > Yes, AFAIK. There is no intervening sequence point between the
> > assignment and indexing. Even though there are parentheses, it is not
> > guaranteed that the compiler isn't going to "optimize" it and use the
> > previous value of 'p' (undefined) for dereferencing it.
>
> I think now that I was wrong there.  The expression in parentheses has
> the value the same as 'a', and *that* is used to dereference the pointer
> (the indexing is adding the index and then dereferencing).  The relevant
> portion of the Standard (using the latest Draft):
>
> <<The assignment operator (=) and the compound assignment operators all
> group right-to-left. All require a modifiable lvalue as their left
> operand and return an lvalue referring to the left operand. The result
> in all cases is a bit-field if the left operand is a bit-field. In all
> cases, the assignment is sequenced after the value computation of the
> right and left operands, and before the value computation of the
> assignment expression.>>
>
> The last sentence is important, I believe.  "Sequenced" is the key word.
>
>  > If you need to
>
> > introduce a sequence point, use the comma:
>
> > p=a,p[0]; // no problem
>
> > V
>
> V
> --
> I do not respond to top-posted replies, please don't ask

The term sequenced before/after and value computation are part of C+
+11 and not of C++03. In C++11 the expression has well defined
behavior. In C++03 it is not.

P.S

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

#13294

On 12/01/2012 18:11, Prasoon Saurav wrote:
> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>  wrote:
>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
>>>> Here is the code
>>
>>>> int main()
>>>> {
>>>> char *p;
>>>> char a[]={"Hello"};
>>>> (p=a)[0]; // This line
>>>> return 0;
>>>> }
>>
>>>> Is the behaviour of this code undefined in C++?
>>
>>> Yes, AFAIK. There is no intervening sequence point between the
>>> assignment and indexing. Even though there are parentheses, it is not
>>> guaranteed that the compiler isn't going to "optimize" it and use the
>>> previous value of 'p' (undefined) for dereferencing it.
>>
>> I think now that I was wrong there.  The expression in parentheses has
>> the value the same as 'a', and *that* is used to dereference the pointer
>> (the indexing is adding the index and then dereferencing).  The relevant
>> portion of the Standard (using the latest Draft):
>>
>> <<The assignment operator (=) and the compound assignment operators all
>> group right-to-left. All require a modifiable lvalue as their left
>> operand and return an lvalue referring to the left operand. The result
>> in all cases is a bit-field if the left operand is a bit-field. In all
>> cases, the assignment is sequenced after the value computation of the
>> right and left operands, and before the value computation of the
>> assignment expression.>>
>>
>> The last sentence is important, I believe.  "Sequenced" is the key word.
>>
>>   >  If you need to
>>
>>> introduce a sequence point, use the comma:
>>
>>> p=a,p[0]; // no problem
>>
>>> V
>>
>> V
>> --
>> I do not respond to top-posted replies, please don't ask
>
> The term sequenced before/after and value computation are part of C+
> +11 and not of C++03. In C++11 the expression has well defined
> behavior. In C++03 it is not.

Nonsense.

(p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are 
confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.

/Leigh

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

#13295

On Jan 12, 11:46 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 18:11, Prasoon Saurav wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>  wrote:
> >> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>
> >>> On 1/11/2012 12:08 PM, Novice Coder wrote:
> >>>> Here is the code
>
> >>>> int main()
> >>>> {
> >>>> char *p;
> >>>> char a[]={"Hello"};
> >>>> (p=a)[0]; // This line
> >>>> return 0;
> >>>> }
>
> >>>> Is the behaviour of this code undefined in C++?
>
> >>> Yes, AFAIK. There is no intervening sequence point between the
> >>> assignment and indexing. Even though there are parentheses, it is not
> >>> guaranteed that the compiler isn't going to "optimize" it and use the
> >>> previous value of 'p' (undefined) for dereferencing it.
>
> >> I think now that I was wrong there.  The expression in parentheses has
> >> the value the same as 'a', and *that* is used to dereference the pointer
> >> (the indexing is adding the index and then dereferencing).  The relevant
> >> portion of the Standard (using the latest Draft):
>
> >> <<The assignment operator (=) and the compound assignment operators all
> >> group right-to-left. All require a modifiable lvalue as their left
> >> operand and return an lvalue referring to the left operand. The result
> >> in all cases is a bit-field if the left operand is a bit-field. In all
> >> cases, the assignment is sequenced after the value computation of the
> >> right and left operands, and before the value computation of the
> >> assignment expression.>>
>
> >> The last sentence is important, I believe.  "Sequenced" is the key word.
>
> >>   >  If you need to
>
> >>> introduce a sequence point, use the comma:
>
> >>> p=a,p[0]; // no problem
>
> >>> V
>
> >> V
> >> --
> >> I do not respond to top-posted replies, please don't ask
>
> > The term sequenced before/after and value computation are part of C+
> > +11 and not of C++03. In C++11 the expression has well defined
> > behavior. In C++03 it is not.
>
> Nonsense.
>
> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.
>
> /Leigh

Instead of using words like "bullshit", "nonsense" why don't you take
help of the Standard to prove yourself correct. Which statement of
mine do you think is incorrect and why? If you have some counter-
argument please make it.

P.S

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

#13297

On 12/01/2012 19:18, Prasoon Saurav wrote:
> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>    wrote:
>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>>
>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
>>>>>> Here is the code
>>
>>>>>> int main()
>>>>>> {
>>>>>> char *p;
>>>>>> char a[]={"Hello"};
>>>>>> (p=a)[0]; // This line
>>>>>> return 0;
>>>>>> }
>>
>>>>>> Is the behaviour of this code undefined in C++?
>>
>>>>> Yes, AFAIK. There is no intervening sequence point between the
>>>>> assignment and indexing. Even though there are parentheses, it is not
>>>>> guaranteed that the compiler isn't going to "optimize" it and use the
>>>>> previous value of 'p' (undefined) for dereferencing it.
>>
>>>> I think now that I was wrong there.  The expression in parentheses has
>>>> the value the same as 'a', and *that* is used to dereference the pointer
>>>> (the indexing is adding the index and then dereferencing).  The relevant
>>>> portion of the Standard (using the latest Draft):
>>
>>>> <<The assignment operator (=) and the compound assignment operators all
>>>> group right-to-left. All require a modifiable lvalue as their left
>>>> operand and return an lvalue referring to the left operand. The result
>>>> in all cases is a bit-field if the left operand is a bit-field. In all
>>>> cases, the assignment is sequenced after the value computation of the
>>>> right and left operands, and before the value computation of the
>>>> assignment expression.>>
>>
>>>> The last sentence is important, I believe.  "Sequenced" is the key word.
>>
>>>>    >    If you need to
>>
>>>>> introduce a sequence point, use the comma:
>>
>>>>> p=a,p[0]; // no problem
>>
>>>>> V
>>
>>>> V
>>>> --
>>>> I do not respond to top-posted replies, please don't ask
>>
>>> The term sequenced before/after and value computation are part of C+
>>> +11 and not of C++03. In C++11 the expression has well defined
>>> behavior. In C++03 it is not.
>>
>> Nonsense.
>>
>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.
>>
>> /Leigh
>
> Instead of using words like "bullshit", "nonsense" why don't you take
> help of the Standard to prove yourself correct. Which statement of
> mine do you think is incorrect and why? If you have some counter-
> argument please make it.

You said '*--p' is UB which disagrees with the draft standard:

24.4.1/5
"...
*first++ = *--last;
..."

So you clearly do not know what you are talking about in this area and I 
still suspect you of being a troll.

/Leigh

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

#13299

On 12/01/2012 19:28, Leigh Johnston wrote:
> On 12/01/2012 19:18, Prasoon Saurav wrote:
>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk> wrote:
>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
>>>> The term sequenced before/after and value computation are part of C+
>>>> +11 and not of C++03. In C++11 the expression has well defined
>>>> behavior. In C++03 it is not.
>>>
>>> Nonsense.
>>>
>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which
>>> is UB.
>>>
>>> /Leigh
>>
>> Instead of using words like "bullshit", "nonsense" why don't you take
>> help of the Standard to prove yourself correct. Which statement of
>> mine do you think is incorrect and why? If you have some counter-
>> argument please make it.
>
> You said '*--p' is UB which disagrees with the draft standard:
>
> 24.4.1/5
> "...
> *first++ = *--last;
> ..."
>
> So you clearly do not know what you are talking about in this area and I
> still suspect you of being a troll.

And if you claim again that this is a fix in C++11 here is a very old 
line of code from "The C Programming Language":

5.5
"
val = *--p; /* pop top of stack into val */
"

So again you clearly do not know what you are talking about.

/Leigh

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

#13310

On Jan 13, 12:41 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 19:28, Leigh Johnston wrote:
>
>
>
>
>
>
>
>
>
> > On 12/01/2012 19:18, Prasoon Saurav wrote:
> >> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk> wrote:
> >>> On 12/01/2012 18:11, Prasoon Saurav wrote:
> >>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
> >>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
> >>>> The term sequenced before/after and value computation are part of C+
> >>>> +11 and not of C++03. In C++11 the expression has well defined
> >>>> behavior. In C++03 it is not.
>
> >>> Nonsense.
>
> >>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
> >>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which
> >>> is UB.
>
> >>> /Leigh
>
> >> Instead of using words like "bullshit", "nonsense" why don't you take
> >> help of the Standard to prove yourself correct. Which statement of
> >> mine do you think is incorrect and why? If you have some counter-
> >> argument please make it.
>
> > You said '*--p' is UB which disagrees with the draft standard:
>
> > 24.4.1/5
> > "...
> > *first++ = *--last;
> > ..."
>
> > So you clearly do not know what you are talking about in this area and I
> > still suspect you of being a troll.
>
> And if you claim again that this is a fix in C++11 here is a very old
> line of code from "The C Programming Language":
>
> 5.5
> "
> val = *--p; /* pop top of stack into val */
> "
>
> So again you clearly do not know what you are talking about.
>
> /Leigh

So let me tell you what I have been talking so far. In C the behavior
is well defined because the result of '--' is an rvalue. In C++03 the
behavior is undefined, I have given the reason why. In C++11 the
behavior is well defined (refer to my stackoverflow answer).

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

#13300

On Jan 13, 12:28 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 19:18, Prasoon Saurav wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
> >> On 12/01/2012 18:11, Prasoon Saurav wrote:
>
> >>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>    wrote:
> >>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>
> >>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
> >>>>>> Here is the code
>
> >>>>>> int main()
> >>>>>> {
> >>>>>> char *p;
> >>>>>> char a[]={"Hello"};
> >>>>>> (p=a)[0]; // This line
> >>>>>> return 0;
> >>>>>> }
>
> >>>>>> Is the behaviour of this code undefined in C++?
>
> >>>>> Yes, AFAIK. There is no intervening sequence point between the
> >>>>> assignment and indexing. Even though there are parentheses, it is not
> >>>>> guaranteed that the compiler isn't going to "optimize" it and use the
> >>>>> previous value of 'p' (undefined) for dereferencing it.
>
> >>>> I think now that I was wrong there.  The expression in parentheses has
> >>>> the value the same as 'a', and *that* is used to dereference the pointer
> >>>> (the indexing is adding the index and then dereferencing).  The relevant
> >>>> portion of the Standard (using the latest Draft):
>
> >>>> <<The assignment operator (=) and the compound assignment operators all
> >>>> group right-to-left. All require a modifiable lvalue as their left
> >>>> operand and return an lvalue referring to the left operand. The result
> >>>> in all cases is a bit-field if the left operand is a bit-field. In all
> >>>> cases, the assignment is sequenced after the value computation of the
> >>>> right and left operands, and before the value computation of the
> >>>> assignment expression.>>
>
> >>>> The last sentence is important, I believe.  "Sequenced" is the key word.
>
> >>>>    >    If you need to
>
> >>>>> introduce a sequence point, use the comma:
>
> >>>>> p=a,p[0]; // no problem
>
> >>>>> V
>
> >>>> V
> >>>> --
> >>>> I do not respond to top-posted replies, please don't ask
>
> >>> The term sequenced before/after and value computation are part of C+
> >>> +11 and not of C++03. In C++11 the expression has well defined
> >>> behavior. In C++03 it is not.
>
> >> Nonsense.
>
> >> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
> >> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.
>
> >> /Leigh
>
> > Instead of using words like "bullshit", "nonsense" why don't you take
> > help of the Standard to prove yourself correct. Which statement of
> > mine do you think is incorrect and why? If you have some counter-
> > argument please make it.
>
> You said '*--p' is UB which disagrees with the draft standard:
>
> 24.4.1/5
> "...
> *first++ = *--last;
> ..."
>
> So you clearly do not know what you are talking about in this area and I
> still suspect you of being a troll.
>
> /Leigh

One more thing whether *--p; invokes UB or not depends on whether 'p'
is a user defined type or not.


C++03

*--p; if p is a user defined type with overloaded -- and * then the
behavior is well defined (function calls introduce sequence points).
For primitive types like what we have in the opening post the behavior
is undefined.

P.S

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

#13301

On 12/01/2012 19:44, Prasoon Saurav wrote:
> On Jan 13, 12:28 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 12/01/2012 19:18, Prasoon Saurav wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>    wrote:
>>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>>
>>>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>      wrote:
>>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>>
>>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
>>>>>>>> Here is the code
>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> char *p;
>>>>>>>> char a[]={"Hello"};
>>>>>>>> (p=a)[0]; // This line
>>>>>>>> return 0;
>>>>>>>> }
>>
>>>>>>>> Is the behaviour of this code undefined in C++?
>>
>>>>>>> Yes, AFAIK. There is no intervening sequence point between the
>>>>>>> assignment and indexing. Even though there are parentheses, it is not
>>>>>>> guaranteed that the compiler isn't going to "optimize" it and use the
>>>>>>> previous value of 'p' (undefined) for dereferencing it.
>>
>>>>>> I think now that I was wrong there.  The expression in parentheses has
>>>>>> the value the same as 'a', and *that* is used to dereference the pointer
>>>>>> (the indexing is adding the index and then dereferencing).  The relevant
>>>>>> portion of the Standard (using the latest Draft):
>>
>>>>>> <<The assignment operator (=) and the compound assignment operators all
>>>>>> group right-to-left. All require a modifiable lvalue as their left
>>>>>> operand and return an lvalue referring to the left operand. The result
>>>>>> in all cases is a bit-field if the left operand is a bit-field. In all
>>>>>> cases, the assignment is sequenced after the value computation of the
>>>>>> right and left operands, and before the value computation of the
>>>>>> assignment expression.>>
>>
>>>>>> The last sentence is important, I believe.  "Sequenced" is the key word.
>>
>>>>>>     >      If you need to
>>
>>>>>>> introduce a sequence point, use the comma:
>>
>>>>>>> p=a,p[0]; // no problem
>>
>>>>>>> V
>>
>>>>>> V
>>>>>> --
>>>>>> I do not respond to top-posted replies, please don't ask
>>
>>>>> The term sequenced before/after and value computation are part of C+
>>>>> +11 and not of C++03. In C++11 the expression has well defined
>>>>> behavior. In C++03 it is not.
>>
>>>> Nonsense.
>>
>>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
>>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.
>>
>>>> /Leigh
>>
>>> Instead of using words like "bullshit", "nonsense" why don't you take
>>> help of the Standard to prove yourself correct. Which statement of
>>> mine do you think is incorrect and why? If you have some counter-
>>> argument please make it.
>>
>> You said '*--p' is UB which disagrees with the draft standard:
>>
>> 24.4.1/5
>> "...
>> *first++ = *--last;
>> ..."
>>
>> So you clearly do not know what you are talking about in this area and I
>> still suspect you of being a troll.
>>
>> /Leigh
>
> One more thing whether *--p; invokes UB or not depends on whether 'p'
> is a user defined type or not.
>
>
> C++03
>
> *--p; if p is a user defined type with overloaded -- and * then the
> behavior is well defined (function calls introduce sequence points).
> For primitive types like what we have in the opening post the behavior
> is undefined.

In this case the example from the standard is for an iterator which can 
be a pointer (i.e. a primitive type) so you are still wrong.

/Leigh

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

#13303

On 12/01/2012 19:46, Leigh Johnston wrote:
> On 12/01/2012 19:44, Prasoon Saurav wrote:
>> On Jan 13, 12:28 am, Leigh Johnston<le...@i42.co.uk> wrote:
>>> On 12/01/2012 19:18, Prasoon Saurav wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk> wrote:
>>>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>>>
>>>>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid> wrote:
>>>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>>>
>>>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
>>>>>>>>> Here is the code
>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> char *p;
>>>>>>>>> char a[]={"Hello"};
>>>>>>>>> (p=a)[0]; // This line
>>>>>>>>> return 0;
>>>>>>>>> }
>>>
>>>>>>>>> Is the behaviour of this code undefined in C++?
>>>
>>>>>>>> Yes, AFAIK. There is no intervening sequence point between the
>>>>>>>> assignment and indexing. Even though there are parentheses, it
>>>>>>>> is not
>>>>>>>> guaranteed that the compiler isn't going to "optimize" it and
>>>>>>>> use the
>>>>>>>> previous value of 'p' (undefined) for dereferencing it.
>>>
>>>>>>> I think now that I was wrong there. The expression in parentheses
>>>>>>> has
>>>>>>> the value the same as 'a', and *that* is used to dereference the
>>>>>>> pointer
>>>>>>> (the indexing is adding the index and then dereferencing). The
>>>>>>> relevant
>>>>>>> portion of the Standard (using the latest Draft):
>>>
>>>>>>> <<The assignment operator (=) and the compound assignment
>>>>>>> operators all
>>>>>>> group right-to-left. All require a modifiable lvalue as their left
>>>>>>> operand and return an lvalue referring to the left operand. The
>>>>>>> result
>>>>>>> in all cases is a bit-field if the left operand is a bit-field.
>>>>>>> In all
>>>>>>> cases, the assignment is sequenced after the value computation of
>>>>>>> the
>>>>>>> right and left operands, and before the value computation of the
>>>>>>> assignment expression.>>
>>>
>>>>>>> The last sentence is important, I believe. "Sequenced" is the key
>>>>>>> word.
>>>
>>>>>>> > If you need to
>>>
>>>>>>>> introduce a sequence point, use the comma:
>>>
>>>>>>>> p=a,p[0]; // no problem
>>>
>>>>>>>> V
>>>
>>>>>>> V
>>>>>>> --
>>>>>>> I do not respond to top-posted replies, please don't ask
>>>
>>>>>> The term sequenced before/after and value computation are part of C+
>>>>>> +11 and not of C++03. In C++11 the expression has well defined
>>>>>> behavior. In C++03 it is not.
>>>
>>>>> Nonsense.
>>>
>>>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
>>>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which
>>>>> is UB.
>>>
>>>>> /Leigh
>>>
>>>> Instead of using words like "bullshit", "nonsense" why don't you take
>>>> help of the Standard to prove yourself correct. Which statement of
>>>> mine do you think is incorrect and why? If you have some counter-
>>>> argument please make it.
>>>
>>> You said '*--p' is UB which disagrees with the draft standard:
>>>
>>> 24.4.1/5
>>> "...
>>> *first++ = *--last;
>>> ..."
>>>
>>> So you clearly do not know what you are talking about in this area and I
>>> still suspect you of being a troll.
>>>
>>> /Leigh
>>
>> One more thing whether *--p; invokes UB or not depends on whether 'p'
>> is a user defined type or not.
>>
>>
>> C++03
>>
>> *--p; if p is a user defined type with overloaded -- and * then the
>> behavior is well defined (function calls introduce sequence points).
>> For primitive types like what we have in the opening post the behavior
>> is undefined.
>
> In this case the example from the standard is for an iterator which can
> be a pointer (i.e. a primitive type) so you are still wrong.

Aside: I can find many instances of *++p and *--p in Microsoft's 
implementation of the C++ standard library.

So if you are to be believed the C++ standard is wrong; Microsoft is 
wrong and the seminal "The C Programming Language" is wrong.

Admit you are wrong and move on.

/Leigh

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

#13307

On Jan 13, 12:53 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 19:46, Leigh Johnston wrote:
>
>
>
>
>
>
>
>
>
> > On 12/01/2012 19:44, Prasoon Saurav wrote:
> >> On Jan 13, 12:28 am, Leigh Johnston<le...@i42.co.uk> wrote:
> >>> On 12/01/2012 19:18, Prasoon Saurav wrote:
>
> >>>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk> wrote:
> >>>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>
> >>>>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid> wrote:
> >>>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>
> >>>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
> >>>>>>>>> Here is the code
>
> >>>>>>>>> int main()
> >>>>>>>>> {
> >>>>>>>>> char *p;
> >>>>>>>>> char a[]={"Hello"};
> >>>>>>>>> (p=a)[0]; // This line
> >>>>>>>>> return 0;
> >>>>>>>>> }
>
> >>>>>>>>> Is the behaviour of this code undefined in C++?
>
> >>>>>>>> Yes, AFAIK. There is no intervening sequence point between the
> >>>>>>>> assignment and indexing. Even though there are parentheses, it
> >>>>>>>> is not
> >>>>>>>> guaranteed that the compiler isn't going to "optimize" it and
> >>>>>>>> use the
> >>>>>>>> previous value of 'p' (undefined) for dereferencing it.
>
> >>>>>>> I think now that I was wrong there. The expression in parentheses
> >>>>>>> has
> >>>>>>> the value the same as 'a', and *that* is used to dereference the
> >>>>>>> pointer
> >>>>>>> (the indexing is adding the index and then dereferencing). The
> >>>>>>> relevant
> >>>>>>> portion of the Standard (using the latest Draft):
>
> >>>>>>> <<The assignment operator (=) and the compound assignment
> >>>>>>> operators all
> >>>>>>> group right-to-left. All require a modifiable lvalue as their left
> >>>>>>> operand and return an lvalue referring to the left operand. The
> >>>>>>> result
> >>>>>>> in all cases is a bit-field if the left operand is a bit-field.
> >>>>>>> In all
> >>>>>>> cases, the assignment is sequenced after the value computation of
> >>>>>>> the
> >>>>>>> right and left operands, and before the value computation of the
> >>>>>>> assignment expression.>>
>
> >>>>>>> The last sentence is important, I believe. "Sequenced" is the key
> >>>>>>> word.
>
> >>>>>>> > If you need to
>
> >>>>>>>> introduce a sequence point, use the comma:
>
> >>>>>>>> p=a,p[0]; // no problem
>
> >>>>>>>> V
>
> >>>>>>> V
> >>>>>>> --
> >>>>>>> I do not respond to top-posted replies, please don't ask
>
> >>>>>> The term sequenced before/after and value computation are part of C+
> >>>>>> +11 and not of C++03. In C++11 the expression has well defined
> >>>>>> behavior. In C++03 it is not.
>
> >>>>> Nonsense.
>
> >>>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
> >>>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which
> >>>>> is UB.
>
> >>>>> /Leigh
>
> >>>> Instead of using words like "bullshit", "nonsense" why don't you take
> >>>> help of the Standard to prove yourself correct. Which statement of
> >>>> mine do you think is incorrect and why? If you have some counter-
> >>>> argument please make it.
>
> >>> You said '*--p' is UB which disagrees with the draft standard:
>
> >>> 24.4.1/5
> >>> "...
> >>> *first++ = *--last;
> >>> ..."
>
> >>> So you clearly do not know what you are talking about in this area and I
> >>> still suspect you of being a troll.
>
> >>> /Leigh
>
> >> One more thing whether *--p; invokes UB or not depends on whether 'p'
> >> is a user defined type or not.
>
> >> C++03
>
> >> *--p; if p is a user defined type with overloaded -- and * then the
> >> behavior is well defined (function calls introduce sequence points).
> >> For primitive types like what we have in the opening post the behavior
> >> is undefined.
>
> > In this case the example from the standard is for an iterator which can
> > be a pointer (i.e. a primitive type) so you are still wrong.
>
> Aside: I can find many instances of *++p and *--p in Microsoft's
> implementation of the C++ standard library.
>
> So if you are to be believed the C++ standard is wrong; Microsoft is
> wrong and the seminal "The C Programming Language" is wrong.
>
> Admit you are wrong and move on.
>
> /Leigh

I already said that the behavior is only undefined in C++03. It is
fine in C, I have given the reason why. It is fine in C++11, Victor
already gave the reason.

Yes C++03 standard had many defects, don't you know? :P This might be
one of them. No comments on Microsoft's implementation. The C
Programming Language is correct.

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

#13308

On 12/01/2012 20:01, Prasoon Saurav wrote:
> On Jan 13, 12:53 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 12/01/2012 19:46, Leigh Johnston wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 12/01/2012 19:44, Prasoon Saurav wrote:
>>>> On Jan 13, 12:28 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>>>>> On 12/01/2012 19:18, Prasoon Saurav wrote:
>>
>>>>>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>>>>>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>>
>>>>>>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>  wrote:
>>>>>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>>
>>>>>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
>>>>>>>>>>> Here is the code
>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> char *p;
>>>>>>>>>>> char a[]={"Hello"};
>>>>>>>>>>> (p=a)[0]; // This line
>>>>>>>>>>> return 0;
>>>>>>>>>>> }
>>
>>>>>>>>>>> Is the behaviour of this code undefined in C++?
>>
>>>>>>>>>> Yes, AFAIK. There is no intervening sequence point between the
>>>>>>>>>> assignment and indexing. Even though there are parentheses, it
>>>>>>>>>> is not
>>>>>>>>>> guaranteed that the compiler isn't going to "optimize" it and
>>>>>>>>>> use the
>>>>>>>>>> previous value of 'p' (undefined) for dereferencing it.
>>
>>>>>>>>> I think now that I was wrong there. The expression in parentheses
>>>>>>>>> has
>>>>>>>>> the value the same as 'a', and *that* is used to dereference the
>>>>>>>>> pointer
>>>>>>>>> (the indexing is adding the index and then dereferencing). The
>>>>>>>>> relevant
>>>>>>>>> portion of the Standard (using the latest Draft):
>>
>>>>>>>>> <<The assignment operator (=) and the compound assignment
>>>>>>>>> operators all
>>>>>>>>> group right-to-left. All require a modifiable lvalue as their left
>>>>>>>>> operand and return an lvalue referring to the left operand. The
>>>>>>>>> result
>>>>>>>>> in all cases is a bit-field if the left operand is a bit-field.
>>>>>>>>> In all
>>>>>>>>> cases, the assignment is sequenced after the value computation of
>>>>>>>>> the
>>>>>>>>> right and left operands, and before the value computation of the
>>>>>>>>> assignment expression.>>
>>
>>>>>>>>> The last sentence is important, I believe. "Sequenced" is the key
>>>>>>>>> word.
>>
>>>>>>>>>> If you need to
>>
>>>>>>>>>> introduce a sequence point, use the comma:
>>
>>>>>>>>>> p=a,p[0]; // no problem
>>
>>>>>>>>>> V
>>
>>>>>>>>> V
>>>>>>>>> --
>>>>>>>>> I do not respond to top-posted replies, please don't ask
>>
>>>>>>>> The term sequenced before/after and value computation are part of C+
>>>>>>>> +11 and not of C++03. In C++11 the expression has well defined
>>>>>>>> behavior. In C++03 it is not.
>>
>>>>>>> Nonsense.
>>
>>>>>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
>>>>>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which
>>>>>>> is UB.
>>
>>>>>>> /Leigh
>>
>>>>>> Instead of using words like "bullshit", "nonsense" why don't you take
>>>>>> help of the Standard to prove yourself correct. Which statement of
>>>>>> mine do you think is incorrect and why? If you have some counter-
>>>>>> argument please make it.
>>
>>>>> You said '*--p' is UB which disagrees with the draft standard:
>>
>>>>> 24.4.1/5
>>>>> "...
>>>>> *first++ = *--last;
>>>>> ..."
>>
>>>>> So you clearly do not know what you are talking about in this area and I
>>>>> still suspect you of being a troll.
>>
>>>>> /Leigh
>>
>>>> One more thing whether *--p; invokes UB or not depends on whether 'p'
>>>> is a user defined type or not.
>>
>>>> C++03
>>
>>>> *--p; if p is a user defined type with overloaded -- and * then the
>>>> behavior is well defined (function calls introduce sequence points).
>>>> For primitive types like what we have in the opening post the behavior
>>>> is undefined.
>>
>>> In this case the example from the standard is for an iterator which can
>>> be a pointer (i.e. a primitive type) so you are still wrong.
>>
>> Aside: I can find many instances of *++p and *--p in Microsoft's
>> implementation of the C++ standard library.
>>
>> So if you are to be believed the C++ standard is wrong; Microsoft is
>> wrong and the seminal "The C Programming Language" is wrong.
>>
>> Admit you are wrong and move on.
>>
>> /Leigh
>
> I already said that the behavior is only undefined in C++03. It is
> fine in C, I have given the reason why. It is fine in C++11, Victor
> already gave the reason.
>
> Yes C++03 standard had many defects, don't you know? :P This might be
> one of them. No comments on Microsoft's implementation. The C
> Programming Language is correct.

You are a troll for sure; gtfo.

/Leigh

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

#13309

On Jan 13, 1:10 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 20:01, Prasoon Saurav wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 13, 12:53 am, Leigh Johnston<le...@i42.co.uk>  wrote:
> >> On 12/01/2012 19:46, Leigh Johnston wrote:
>
> >>> On 12/01/2012 19:44, Prasoon Saurav wrote:
> >>>> On Jan 13, 12:28 am, Leigh Johnston<le...@i42.co.uk>  wrote:
> >>>>> On 12/01/2012 19:18, Prasoon Saurav wrote:
>
> >>>>>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
> >>>>>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>
> >>>>>>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>  wrote:
> >>>>>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>
> >>>>>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
> >>>>>>>>>>> Here is the code
>
> >>>>>>>>>>> int main()
> >>>>>>>>>>> {
> >>>>>>>>>>> char *p;
> >>>>>>>>>>> char a[]={"Hello"};
> >>>>>>>>>>> (p=a)[0]; // This line
> >>>>>>>>>>> return 0;
> >>>>>>>>>>> }
>
> >>>>>>>>>>> Is the behaviour of this code undefined in C++?
>
> >>>>>>>>>> Yes, AFAIK. There is no intervening sequence point between the
> >>>>>>>>>> assignment and indexing. Even though there are parentheses, it
> >>>>>>>>>> is not
> >>>>>>>>>> guaranteed that the compiler isn't going to "optimize" it and
> >>>>>>>>>> use the
> >>>>>>>>>> previous value of 'p' (undefined) for dereferencing it.
>
> >>>>>>>>> I think now that I was wrong there. The expression in parentheses
> >>>>>>>>> has
> >>>>>>>>> the value the same as 'a', and *that* is used to dereference the
> >>>>>>>>> pointer
> >>>>>>>>> (the indexing is adding the index and then dereferencing). The
> >>>>>>>>> relevant
> >>>>>>>>> portion of the Standard (using the latest Draft):
>
> >>>>>>>>> <<The assignment operator (=) and the compound assignment
> >>>>>>>>> operators all
> >>>>>>>>> group right-to-left. All require a modifiable lvalue as their left
> >>>>>>>>> operand and return an lvalue referring to the left operand. The
> >>>>>>>>> result
> >>>>>>>>> in all cases is a bit-field if the left operand is a bit-field.
> >>>>>>>>> In all
> >>>>>>>>> cases, the assignment is sequenced after the value computation of
> >>>>>>>>> the
> >>>>>>>>> right and left operands, and before the value computation of the
> >>>>>>>>> assignment expression.>>
>
> >>>>>>>>> The last sentence is important, I believe. "Sequenced" is the key
> >>>>>>>>> word.
>
> >>>>>>>>>> If you need to
>
> >>>>>>>>>> introduce a sequence point, use the comma:
>
> >>>>>>>>>> p=a,p[0]; // no problem
>
> >>>>>>>>>> V
>
> >>>>>>>>> V
> >>>>>>>>> --
> >>>>>>>>> I do not respond to top-posted replies, please don't ask
>
> >>>>>>>> The term sequenced before/after and value computation are part of C+
> >>>>>>>> +11 and not of C++03. In C++11 the expression has well defined
> >>>>>>>> behavior. In C++03 it is not.
>
> >>>>>>> Nonsense.
>
> >>>>>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
> >>>>>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which
> >>>>>>> is UB.
>
> >>>>>>> /Leigh
>
> >>>>>> Instead of using words like "bullshit", "nonsense" why don't you take
> >>>>>> help of the Standard to prove yourself correct. Which statement of
> >>>>>> mine do you think is incorrect and why? If you have some counter-
> >>>>>> argument please make it.
>
> >>>>> You said '*--p' is UB which disagrees with the draft standard:
>
> >>>>> 24.4.1/5
> >>>>> "...
> >>>>> *first++ = *--last;
> >>>>> ..."
>
> >>>>> So you clearly do not know what you are talking about in this area and I
> >>>>> still suspect you of being a troll.
>
> >>>>> /Leigh
>
> >>>> One more thing whether *--p; invokes UB or not depends on whether 'p'
> >>>> is a user defined type or not.
>
> >>>> C++03
>
> >>>> *--p; if p is a user defined type with overloaded -- and * then the
> >>>> behavior is well defined (function calls introduce sequence points).
> >>>> For primitive types like what we have in the opening post the behavior
> >>>> is undefined.
>
> >>> In this case the example from the standard is for an iterator which can
> >>> be a pointer (i.e. a primitive type) so you are still wrong.
>
> >> Aside: I can find many instances of *++p and *--p in Microsoft's
> >> implementation of the C++ standard library.
>
> >> So if you are to be believed the C++ standard is wrong; Microsoft is
> >> wrong and the seminal "The C Programming Language" is wrong.
>
> >> Admit you are wrong and move on.
>
> >> /Leigh
>
> > I already said that the behavior is only undefined in C++03. It is
> > fine in C, I have given the reason why. It is fine in C++11, Victor
> > already gave the reason.
>
> > Yes C++03 standard had many defects, don't you know? :P This might be
> > one of them. No comments on Microsoft's implementation. The C
> > Programming Language is correct.
>
> You are a troll for sure; gtfo.
>
> /Leigh

I used to troll at stackoverflow(here is my trolling profile:
http://stackoverflow.com/users/165520/prasoon-saurav)  and now I am
trolling here. :-) Now just stfu.

P.S

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

#13311

On 12/01/2012 20:13, Prasoon Saurav wrote:
> On Jan 13, 1:10 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 12/01/2012 20:01, Prasoon Saurav wrote:
>>>>>>>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
>>>>>>>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which
>>>>>>>>> is UB.
>>
>>>>>>>>> /Leigh
>>
>>>>>>>> Instead of using words like "bullshit", "nonsense" why don't you take
>>>>>>>> help of the Standard to prove yourself correct. Which statement of
>>>>>>>> mine do you think is incorrect and why? If you have some counter-
>>>>>>>> argument please make it.
>>
>>>>>>> You said '*--p' is UB which disagrees with the draft standard:
>>
>>>>>>> 24.4.1/5
>>>>>>> "...
>>>>>>> *first++ = *--last;
>>>>>>> ..."
>>
>>>>>>> So you clearly do not know what you are talking about in this area and I
>>>>>>> still suspect you of being a troll.
>>
>>>>>>> /Leigh
>>
>>>>>> One more thing whether *--p; invokes UB or not depends on whether 'p'
>>>>>> is a user defined type or not.
>>
>>>>>> C++03
>>
>>>>>> *--p; if p is a user defined type with overloaded -- and * then the
>>>>>> behavior is well defined (function calls introduce sequence points).
>>>>>> For primitive types like what we have in the opening post the behavior
>>>>>> is undefined.
>>
>>>>> In this case the example from the standard is for an iterator which can
>>>>> be a pointer (i.e. a primitive type) so you are still wrong.
>>
>>>> Aside: I can find many instances of *++p and *--p in Microsoft's
>>>> implementation of the C++ standard library.
>>
>>>> So if you are to be believed the C++ standard is wrong; Microsoft is
>>>> wrong and the seminal "The C Programming Language" is wrong.
>>
>>>> Admit you are wrong and move on.
>>
>>>> /Leigh
>>
>>> I already said that the behavior is only undefined in C++03. It is
>>> fine in C, I have given the reason why. It is fine in C++11, Victor
>>> already gave the reason.
>>
>>> Yes C++03 standard had many defects, don't you know? :P This might be
>>> one of them. No comments on Microsoft's implementation. The C
>>> Programming Language is correct.
>>
>> You are a troll for sure; gtfo.
>>
>> /Leigh
>
> I used to troll at stackoverflow(here is my trolling profile:
> http://stackoverflow.com/users/165520/prasoon-saurav)  and now I am
> trolling here. :-) Now just stfu.

stackoverflow is just a random website and I view its "reputation 
points" with a pinch of salt.

So your claim is that '*++p' is well defined (and therefore correct) in 
ANSI C which pre-dates both C++03 and C++11; is undefined behaviour (and 
therefore incorrect) in C++03 (which, along with C++98, borrows from C) 
and well defined (and therefore correct) in C++11?  Is it just me or 
does anyone else think that this claim is a tiny bit absurd?

I have been programming in C and C++ since the early 90s and not once 
have I seen the claim that '*++p' is UB until now.

/Leigh

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

#13348

Prasoon Saurav <prasoonsaurav.nit@gmail.com> writes:
>On Jan 13, 12:53=A0am, Leigh Johnston <le...@i42.co.uk> wrote:

>> Aside: I can find many instances of *++p and *--p in Microsoft's
>> implementation of the C++ standard library.
>>

> No comments on Microsoft's implementation. 

Aside from the fact that since microsoft created VC++, the behavior
in their library code of *--p is very well-defined to them even if it
is undefined in some version of the C++ standard.

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

#13302

On Jan 13, 12:28 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 19:18, Prasoon Saurav wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
> >> On 12/01/2012 18:11, Prasoon Saurav wrote:
>
> >>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>    wrote:
> >>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>
> >>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
> >>>>>> Here is the code
>
> >>>>>> int main()
> >>>>>> {
> >>>>>> char *p;
> >>>>>> char a[]={"Hello"};
> >>>>>> (p=a)[0]; // This line
> >>>>>> return 0;
> >>>>>> }
>
> >>>>>> Is the behaviour of this code undefined in C++?
>
> >>>>> Yes, AFAIK. There is no intervening sequence point between the
> >>>>> assignment and indexing. Even though there are parentheses, it is not
> >>>>> guaranteed that the compiler isn't going to "optimize" it and use the
> >>>>> previous value of 'p' (undefined) for dereferencing it.
>
> >>>> I think now that I was wrong there.  The expression in parentheses has
> >>>> the value the same as 'a', and *that* is used to dereference the pointer
> >>>> (the indexing is adding the index and then dereferencing).  The relevant
> >>>> portion of the Standard (using the latest Draft):
>
> >>>> <<The assignment operator (=) and the compound assignment operators all
> >>>> group right-to-left. All require a modifiable lvalue as their left
> >>>> operand and return an lvalue referring to the left operand. The result
> >>>> in all cases is a bit-field if the left operand is a bit-field. In all
> >>>> cases, the assignment is sequenced after the value computation of the
> >>>> right and left operands, and before the value computation of the
> >>>> assignment expression.>>
>
> >>>> The last sentence is important, I believe.  "Sequenced" is the key word.
>
> >>>>    >    If you need to
>
> >>>>> introduce a sequence point, use the comma:
>
> >>>>> p=a,p[0]; // no problem
>
> >>>>> V
>
> >>>> V
> >>>> --
> >>>> I do not respond to top-posted replies, please don't ask
>
> >>> The term sequenced before/after and value computation are part of C+
> >>> +11 and not of C++03. In C++11 the expression has well defined
> >>> behavior. In C++03 it is not.
>
> >> Nonsense.
>
> >> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
> >> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.
>
> >> /Leigh
>
> > Instead of using words like "bullshit", "nonsense" why don't you take
> > help of the Standard to prove yourself correct. Which statement of
> > mine do you think is incorrect and why? If you have some counter-
> > argument please make it.
>
> You said '*--p' is UB which disagrees with the draft standard:
>
> 24.4.1/5
> "...
> *first++ = *--last;
> ..."
>
> So you clearly do not know what you are talking about in this area and I
> still suspect you of being a troll.
>
> /Leigh

Which draft are you quoting from, n3290? Each of my comment is from C+
+03 point of view. In C++11 *++p; is well defined. I am still not sure
whether it is well defined in C++03
See my this answer : http://stackoverflow.com/a/4183735/165520

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

#13304

On 12/01/2012 19:37, Prasoon Saurav wrote:
> On Jan 13, 12:28 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 12/01/2012 19:18, Prasoon Saurav wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>    wrote:
>>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>>
>>>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>      wrote:
>>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>>
>>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
>>>>>>>> Here is the code
>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> char *p;
>>>>>>>> char a[]={"Hello"};
>>>>>>>> (p=a)[0]; // This line
>>>>>>>> return 0;
>>>>>>>> }
>>
>>>>>>>> Is the behaviour of this code undefined in C++?
>>
>>>>>>> Yes, AFAIK. There is no intervening sequence point between the
>>>>>>> assignment and indexing. Even though there are parentheses, it is not
>>>>>>> guaranteed that the compiler isn't going to "optimize" it and use the
>>>>>>> previous value of 'p' (undefined) for dereferencing it.
>>
>>>>>> I think now that I was wrong there.  The expression in parentheses has
>>>>>> the value the same as 'a', and *that* is used to dereference the pointer
>>>>>> (the indexing is adding the index and then dereferencing).  The relevant
>>>>>> portion of the Standard (using the latest Draft):
>>
>>>>>> <<The assignment operator (=) and the compound assignment operators all
>>>>>> group right-to-left. All require a modifiable lvalue as their left
>>>>>> operand and return an lvalue referring to the left operand. The result
>>>>>> in all cases is a bit-field if the left operand is a bit-field. In all
>>>>>> cases, the assignment is sequenced after the value computation of the
>>>>>> right and left operands, and before the value computation of the
>>>>>> assignment expression.>>
>>
>>>>>> The last sentence is important, I believe.  "Sequenced" is the key word.
>>
>>>>>>     >      If you need to
>>
>>>>>>> introduce a sequence point, use the comma:
>>
>>>>>>> p=a,p[0]; // no problem
>>
>>>>>>> V
>>
>>>>>> V
>>>>>> --
>>>>>> I do not respond to top-posted replies, please don't ask
>>
>>>>> The term sequenced before/after and value computation are part of C+
>>>>> +11 and not of C++03. In C++11 the expression has well defined
>>>>> behavior. In C++03 it is not.
>>
>>>> Nonsense.
>>
>>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
>>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.
>>
>>>> /Leigh
>>
>>> Instead of using words like "bullshit", "nonsense" why don't you take
>>> help of the Standard to prove yourself correct. Which statement of
>>> mine do you think is incorrect and why? If you have some counter-
>>> argument please make it.
>>
>> You said '*--p' is UB which disagrees with the draft standard:
>>
>> 24.4.1/5
>> "...
>> *first++ = *--last;
>> ..."
>>
>> So you clearly do not know what you are talking about in this area and I
>> still suspect you of being a troll.
>>
>> /Leigh
>
> Which draft are you quoting from, n3290? Each of my comment is from C+
> +03 point of view. In C++11 *++p; is well defined. I am still not sure
> whether it is well defined in C++03
> See my this answer : http://stackoverflow.com/a/4183735/165520

You are so wrong that if your wrongness had mass it would have a massive 
event horizon; see my answer follow-up else-thread and then admit you 
are wrong.

/Leigh

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

#13305

On Jan 13, 12:56 am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 12/01/2012 19:37, Prasoon Saurav wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 13, 12:28 am, Leigh Johnston<le...@i42.co.uk>  wrote:
> >> On 12/01/2012 19:18, Prasoon Saurav wrote:
>
> >>> On Jan 12, 11:46 pm, Leigh Johnston<le...@i42.co.uk>    wrote:
> >>>> On 12/01/2012 18:11, Prasoon Saurav wrote:
>
> >>>>> On Jan 12, 11:07 pm, Victor Bazarov<v.baza...@comcast.invalid>      wrote:
> >>>>>> On 1/11/2012 12:28 PM, Victor Bazarov wrote:
>
> >>>>>>> On 1/11/2012 12:08 PM, Novice Coder wrote:
> >>>>>>>> Here is the code
>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> char *p;
> >>>>>>>> char a[]={"Hello"};
> >>>>>>>> (p=a)[0]; // This line
> >>>>>>>> return 0;
> >>>>>>>> }
>
> >>>>>>>> Is the behaviour of this code undefined in C++?
>
> >>>>>>> Yes, AFAIK. There is no intervening sequence point between the
> >>>>>>> assignment and indexing. Even though there are parentheses, it is not
> >>>>>>> guaranteed that the compiler isn't going to "optimize" it and use the
> >>>>>>> previous value of 'p' (undefined) for dereferencing it.
>
> >>>>>> I think now that I was wrong there.  The expression in parentheses has
> >>>>>> the value the same as 'a', and *that* is used to dereference the pointer
> >>>>>> (the indexing is adding the index and then dereferencing).  The relevant
> >>>>>> portion of the Standard (using the latest Draft):
>
> >>>>>> <<The assignment operator (=) and the compound assignment operators all
> >>>>>> group right-to-left. All require a modifiable lvalue as their left
> >>>>>> operand and return an lvalue referring to the left operand. The result
> >>>>>> in all cases is a bit-field if the left operand is a bit-field. In all
> >>>>>> cases, the assignment is sequenced after the value computation of the
> >>>>>> right and left operands, and before the value computation of the
> >>>>>> assignment expression.>>
>
> >>>>>> The last sentence is important, I believe.  "Sequenced" is the key word.
>
> >>>>>>     >      If you need to
>
> >>>>>>> introduce a sequence point, use the comma:
>
> >>>>>>> p=a,p[0]; // no problem
>
> >>>>>>> V
>
> >>>>>> V
> >>>>>> --
> >>>>>> I do not respond to top-posted replies, please don't ask
>
> >>>>> The term sequenced before/after and value computation are part of C+
> >>>>> +11 and not of C++03. In C++11 the expression has well defined
> >>>>> behavior. In C++03 it is not.
>
> >>>> Nonsense.
>
> >>>> (p=a)[0] is perfectly fine in C++03 as is *(p=a) as is *++p2; you are
> >>>> confusing this defined behaviour with ((p=a)[0] + (p=a+1)[0]) which is UB.
>
> >>>> /Leigh
>
> >>> Instead of using words like "bullshit", "nonsense" why don't you take
> >>> help of the Standard to prove yourself correct. Which statement of
> >>> mine do you think is incorrect and why? If you have some counter-
> >>> argument please make it.
>
> >> You said '*--p' is UB which disagrees with the draft standard:
>
> >> 24.4.1/5
> >> "...
> >> *first++ = *--last;
> >> ..."
>
> >> So you clearly do not know what you are talking about in this area and I
> >> still suspect you of being a troll.
>
> >> /Leigh
>
> > Which draft are you quoting from, n3290? Each of my comment is from C+
> > +03 point of view. In C++11 *++p; is well defined. I am still not sure
> > whether it is well defined in C++03
> > See my this answer :http://stackoverflow.com/a/4183735/165520
>
> You are so wrong that if your wrongness had mass it would have a massive
> event horizon; see my answer follow-up else-thread and then admit you
> are wrong.
>
> /Leigh


LOL.
If *++p is well defined you might argue ++p =10; (for some int 'p') is
also well defined. :P

P.S

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web