Re: GCC's statement expression extension

Re: GCC's statement expression extension

[Mike Stump]

> Date: Thu, 3 Aug 2000 19:55:01 +0200
> From: Jamie Lokier <egcs@tantalophile.demon.co.uk>
> To: Mike Stump <mrs@windriver.com>

>   printf("%s", toupper((a+b).c_str()[0]));

Nope, not a problem.  You need one that takes and returns the same
char *, ah, answered my own question:

printf("%s", strcat((a+b).c_str(), ""));

But even in this case, strcat I bet isn't a macro, and even it it
were, I bet it would not abuse SEs, and even if it did, catting in ""
wouldn't make any sense.

Re: GCC's statement expression extension

[Jamie Lokier]

[Mark: the toupper example is not correct]

Mike Stump wrote:
> >   printf("%s", toupper((a+b).c_str()[0]));
> 
> Nope, not a problem.  You need one that takes and returns the same
> char *...

You are right, but the macro doesn't have to return the same char * for
there to be a problem.

If the macro had the form ({ char * s = (arg); do_something_with(s); })
then it would break because arg, being (a+b).c_str(), would be destroyed
after s was assigned and before evaluating do_something_with(s).

Here is an example using Glibc's <bits/string2.h> implementation of
strcmp.  (Work through the mass of __builtin_constant_p to the
__strcmp_cg call).

  printf ("%s", (!strcmp ("yes", (a+b).c_str())) ? "equal" : "not equal");

enjoy,
-- Jamie

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Jamie" == Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:

    Jamie> [Mark: the toupper example is not correct]

Why not?

I have:

  # define __tobody(c, f, a) 
    (__extension__							      
     ({ int __res;							      
	...						      
	__res = a[(int) (c)];						      
	__res; }))

If `c' is `(a + b).c_str()[0]' then a temporary will be created for `a
+ b' when `c' is used as an array index.  That temporary will be
destroyed at the end of the statement:

  __res = a[(int) (c)];

inside the statement expression, which is earlier than the end of the
enclosing full expression.

I'm happy to change the documentation, but I'm confused as to why you
think your original example doesn't illustrate the problem.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Jamie Lokier]

Mark Mitchell wrote:
> Why not?

>   # define __tobody(c, f, a) 
>     (__extension__							      
>      ({ int __res;							      
> 	...						      
> 	__res = a[(int) (c)];						      
> 	__res; }))
> 

> If `c' is `(a + b).c_str()[0]' then a temporary will be created for `a
> + b' when `c' is used as an array index.  That temporary will be
> destroyed [...] inside the statement expression, which is earlier than
> the end of the enclosing full expression.

In this case, the observed behaviour is the same though isn't it?

If the string's destructor changes the current locale it might be
observable (I'm not sure if locales affect toupper), but if you put
that in the documentation it's going to look obscure.

-- Jamie

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Jamie" == Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:

    Jamie> In this case, the observed behaviour is the same though
    Jamie> isn't it?

But, if you said something like:

  printf ("%c", (toupper..)), (a1 + b1);

you'd get the destruction order in the wrong order. 

In any case, I've removed the specific example, and vaguified the
text.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Suggestion re GCC's statement expression extension

[suckfish]

Hi,

From the recent discussion of statement expressions, it seems that the
most significant use of these is to introduce named temporary
variables within an expression.

Why don't we introduce an explicit construct for this, something like:

__let__ int x = foo() __in__ (x * x).

which would be an expression that assigns foo() to x, and then yields
the value (x*x).  The name x should only be visible within the
__let__...__in__... expression, but the lifetime of the variable
should be determined just like the lifetime of any other (unnamed)
temporary introduced in an expression.

(Perhaps a more C-like syntax could be used, though.)

Ralph.

Re: Suggestion re GCC's statement expression extension

[Mark Mitchell]

>>>>> "suckfish" == suckfish  <suckfish@ihug.co.nz> writes:

    suckfish> Why don't we introduce an explicit construct for this,
    suckfish> something like:

I would argue against adding anything like this in the C++ front-end.

There is simply no need for such functionality.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com