* Re: GCC's statement expression extension
@ 2000-08-03 14:32 Mike Stump
2000-08-04 4:36 ` Jamie Lokier
0 siblings, 1 reply; 7+ messages in thread
From: Mike Stump @ 2000-08-03 14:32 UTC (permalink / raw)
To: egcs; +Cc: gcc, mark, per
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC's statement expression extension
2000-08-03 14:32 GCC's statement expression extension Mike Stump
@ 2000-08-04 4:36 ` Jamie Lokier
2000-08-04 9:04 ` Mark Mitchell
0 siblings, 1 reply; 7+ messages in thread
From: Jamie Lokier @ 2000-08-04 4:36 UTC (permalink / raw)
To: Mike Stump; +Cc: gcc, mark, per
[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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC's statement expression extension
2000-08-04 4:36 ` Jamie Lokier
@ 2000-08-04 9:04 ` Mark Mitchell
2000-08-04 9:26 ` Jamie Lokier
0 siblings, 1 reply; 7+ messages in thread
From: Mark Mitchell @ 2000-08-04 9:04 UTC (permalink / raw)
To: egcs; +Cc: mrs, gcc, per
>>>>> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC's statement expression extension
2000-08-04 9:04 ` Mark Mitchell
@ 2000-08-04 9:26 ` Jamie Lokier
2000-08-04 13:19 ` Mark Mitchell
2000-08-04 19:42 ` Suggestion re " suckfish
0 siblings, 2 replies; 7+ messages in thread
From: Jamie Lokier @ 2000-08-04 9:26 UTC (permalink / raw)
To: Mark Mitchell; +Cc: mrs, gcc, per
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC's statement expression extension
2000-08-04 9:26 ` Jamie Lokier
@ 2000-08-04 13:19 ` Mark Mitchell
2000-08-04 19:42 ` Suggestion re " suckfish
1 sibling, 0 replies; 7+ messages in thread
From: Mark Mitchell @ 2000-08-04 13:19 UTC (permalink / raw)
To: egcs; +Cc: mrs, gcc, per
>>>>> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Suggestion re GCC's statement expression extension
2000-08-04 9:26 ` Jamie Lokier
2000-08-04 13:19 ` Mark Mitchell
@ 2000-08-04 19:42 ` suckfish
2000-08-05 10:23 ` Mark Mitchell
1 sibling, 1 reply; 7+ messages in thread
From: suckfish @ 2000-08-04 19:42 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-08-05 10:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-03 14:32 GCC's statement expression extension Mike Stump
2000-08-04 4:36 ` Jamie Lokier
2000-08-04 9:04 ` Mark Mitchell
2000-08-04 9:26 ` Jamie Lokier
2000-08-04 13:19 ` Mark Mitchell
2000-08-04 19:42 ` Suggestion re " suckfish
2000-08-05 10:23 ` Mark Mitchell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).