Prev: Const char* query..
Next: What does Ctor::Ctor prototype mean?
From: nmm1 on 30 Jul 2010 05:18
In article
<a0b72182-a53e-4ee7-9c24-83c90e073f52(a)j8g2000yqd.googlegroups.com>,
Goran Pusic <goranp(a)cse-semaphore.com> wrote:
>On Jul 29, 9:01 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
>wrote:
>>
>> Sorry, this is nonsense. The above code produces undefined
>> behavior, see 6.6.3/2:
>>
>> "Flowing off the end of a function is equivalent to a return with
>> no value; this results in undefined behavior in a value-returning
>> function."
>
>Whoops... So this only worked on implementations I tried (blushes).
>BTW, is the situation the same for C language?

No. It's undefined only if the value is then used. This is documented
in the C++ standard, under C compatibility. As that says, it is poor
C coding style and easy to fix.


Regards,
Nick Maclaren.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Daniel Krügler on 30 Jul 2010 05:18
On 30 Jul., 16:04, Goran Pusic <gor...(a)cse-semaphore.com> wrote:
> On Jul 29, 9:01 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
> wrote:
>
>
>
> > On 29 Jul., 17:05, Goran Pusic <gor...(a)cse-semaphore.com> wrote:
>
> > > Also, note that at the call site, you are not required to use return
> > > value, so ultimately e.g. this:
>
> > > int f(int g)
> > > {
> > > if (g==5)
> > > return 7;
> > > // and else?
> > > }
>
> > > int main(int, const char*[])
> > > {
> > > int i = f(5);
> > > f(6); // don't care about result, nor is there one, too!
> > > }
>
> > > will work.
>
> > Sorry, this is nonsense. The above code produces undefined
> > behavior, see 6.6.3/2:
>
> > "Flowing off the end of a function is equivalent to a return with
> > no value; this results in undefined behavior in a value-returning
> > function."
>
> Whoops... So this only worked on implementations I tried (blushes).
> BTW, is the situation the same for C language?

It seems that C does support this situation, because this deviation of
specification is mentioned in the list of compatibility differences
between C and C++:

Change: It is now invalid to return (explicitly or implicitly) from a
function
which is declared to return a value without actually returning a value

Rationale: The caller and callee may assume fairly elaborate return-
value mechanisms for the return of class objects. If some flow paths
execute a return without specifying any value, the implementation
must embody many more complications. Besides, promising to
return a value of a given type, and then not returning such a value,
has always been recognized to be a questionable practice,
tolerated only because very-old C had no distinction between void
functions and int functions.

> > > void strcpy(char* dest, const char* src)
> > > {
> > > while (*dest++ = *src++);
> > > }
>
> > > into their C book, but he who wrote this today would probably be
> > > called code red on in a code review. ;-)
>
> > I don't see anything wrong with that code.
>
> Syntactically and functionally, me neither ;-). But my point was, to
> be explicit, this is an exercise in term evaluation and operator
> precedence that's IMO better left out of production code.

I meant my question serious, because I don't consider the
code-style used above as in any way harmful.

But I don't want to start a code-style war here, so I won't
participate in follow-ups of this particular point ;-)

HTH & Greetings from Bremen,

Daniel Kr�gler


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jens Schmidt on 30 Jul 2010 05:18
Goran Pusic wrote:

> On Jul 29, 9:01 pm, Daniel Krügler <daniel.krueg...(a)googlemail.com>
> wrote:
>> On 29 Jul., 17:05, Goran Pusic <gor...(a)cse-semaphore.com> wrote:

> BTW, is the situation the same for C language?
>
>> > void strcpy(char* dest, const char* src)
>> > {
>> > while (*dest++ = *src++);
>> > }
>>
>> > into their C book, but he who wrote this today would probably be
>> > called code red on in a code review. ;-)
>>
>> I don't see anything wrong with that code.
>
> Syntactically and functionally, me neither ;-). But my point was, to
> be explicit, this is an exercise in term evaluation and operator
> precedence that's IMO better left out of production code.

I wouln't let it through in a code review too, but for a different
reason: This code is already available in the standard library under the
same name. So that should be used and not reinvented.
Also, the data structure could need a change. It it not C++-like to use
a sentinel value, a special iterator should better be used.

This special pattern for copying is so common that every C/C++ programmer
should know its function on sight, without any reasoning about evaluation
and precedence. So I see no problem there.

BTW: K&R didn't write this. Unlike some other well known environment,
in the beginning there was no void in C. :-)
--
Greetings,
Jens Schmidt


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Goran Pusic on 2 Aug 2010 03:48
> This special pattern for copying is so common that every C/C++ programmer
> should know its function on sight, without any reasoning about evaluation
> and precedence. So I see no problem there.

Indeed, people do recognize the meaning of that snippet __without
thinking__.

But here's the thing: IMO, they do recognize it mostly because it's
such a high-profile snippet and they know it by heart. But there is
operator precedence where "C way" in particular is not all that good.

When reading overall code, you want to be able to realize, through
cursory glance, what happens under what conditions. At that point, you
don't want to think about details of operator precedence. That's
simply a suboptimal way to write readable code. On a more abstract
level, it's this: poor mix of abstraction levels.

Goran.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: James Kanze on 4 Aug 2010 11:07
On Jul 30, 9:18 pm, Jens Schmidt <Jens.Schmidt...(a)gmx.de> wrote:
> Goran Pusic wrote:
> > On Jul 29, 9:01 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
> > wrote:
> >> On 29 Jul., 17:05, Goran Pusic <gor...(a)cse-semaphore.com> wrote:
> > BTW, is the situation the same for C language?

> >> > void strcpy(char* dest, const char* src)
> >> > {
> >> > while (*dest++ = *src++);
> >> > }

> >> > into their C book, but he who wrote this today would
> >> > probably be called code red on in a code review. ;-)

[...]
> This special pattern for copying is so common that every C/C++
> programmer should know its function on sight, without any
> reasoning about evaluation and precedence. So I see no problem
> there.

I've a certain amount of experience, but I still have to scratch
my head about it. It's just not readable.

> BTW: K&R didn't write this. Unlike some other well known environment,
> in the beginning there was no void in C. :-)

K&R did have a very similar example in their first edition.
With a comment to the effect that it was questionable, but that
since you're likely to see it...

I guess I've just been lucky, but I haven't seen it that often.

--
James Kanze


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Const char* query..
Next: What does Ctor::Ctor prototype mean?