Re: Function call evaluation order


"Tom Widmer [VC++ MVP]" <tom_usenet@xxxxxxxxxxx> wrote in message
news:u5s2PA3TGHA.4236@xxxxxxxxxxxxxxxxxxxxxxx
Frederico Pissarra wrote:


And think about the standard strcpy() function... It is implemented in C
like this:

char *strcpy(char *dest, char *src)
{
char *sTemp = *dest;
while (*dest++ = *src++);
return dest;
}

if the post increments are supposed to be evaluated sequentially the
routine will never work!

Of course it will! dest and src are different objects. We're talking about
modifying the same object multiple times without intervening sequence
points.

What do you think should be printed in the following two cases:

#include <iostream>
int main()
{
std::cout << "post\n";
int i = 0;
std::cout << i++ << ' ' << i++ << ' '<< i++ << '\n';

std::cout << "pre\n";
i = 0;
std::cout << ++i << ' ' << ++i << ' '<< ++i << '\n';
}

I get different results with and without optimization on VC7.1! The point
is that precedence only imposes a *partial* ordering - beyond that
ordering (that the first thing be output before the second), everything
else can happen in any order, and because the same object is being
modified, it is undefined (as opposed to unspecified) behaviour in any
case. Again, read the C faq links I posted.

If you still don't understand after everything you've seen, never mind!

Tom

My intent isn't to make anyone angry at me here... hehe...
I'm testing every scenario you guys are posting here and trying to
understand why you consider those codes having "undefined" behaviour... What
I am seeing, as an experienced C/C++ developer, is that precedence and
associativity can explain everything here...

In the last piece of code I expected to see 0 0 0 and 3 3 3... and it is
what happen!

I can't see what is "undefined" here...

expressions using ++ or -- can be very confusing sometimes, but to me they
aren't "undefined"...

Until now all of you failed to define what "undefined" is... Igor Tandetnik
gave a nice view of "undefined" calling sequence (and that explanation I can
understand and accept)...

Please, don't be angry! :)

[]s
Fred


.

Relevant Pages

  • Re: is strncpy useful at all?
    ... > You return a pointer to the terminating null byte of 'dest'. ... char* tstrncpy; ... void runTest(FP_STRNCPY fp, char* dest, char* src, size_t maxlen, ... runTest(tstrncpy, dest, src, sizeof src - 1, DEST_SIZE); ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Function call evaluation order
    ... char *strcpy(char *dest, char *src) ... if the post increments are supposed to be evaluated sequentially the ... dest and src are different objects. ...
    (microsoft.public.vc.language)
  • Re: Function call evaluation order
    ... char *strcpy(char *dest, char *src) ... dest and src are different objects. ... int main ...
    (microsoft.public.vc.language)
  • Re: static_cast signed to unsigned
    ... that Src is deduced to char rather than char*, ... that a conversion from Src to Dest exists. ... template<class Dest, class Src> ...
    (comp.lang.cpp)
  • Re: strtok and strtok_r
    ... char *strdup(const char *str) { ... char *dest = NULL; ... bearing in mind that strdup is a system reserved name, ...
    (comp.lang.c)
Quantcast