From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gabriel Dos Reis To: egcs@egcs.cygnus.com Cc: "E. Robert Tisdale" Subject: Re: Named Return Value Extension Proposal Date: Mon, 22 Mar 1999 16:59:00 -0000 Message-id: In-reply-to: "E. Robert Tisdale"'s message of "Mon, 22 Mar 1999 13:07:13 -0800" References: <36F6B101.2441947C@netwood.net> X-SW-Source: 1999-03/msg00731.html >>>>> «ERT», E Robert Tisdale wrote: ERT> My egcs-2.90.29 980515 (egcs-1.0.3 release) compiler ERT> does not always elide copy constructors as permitted ERT> by the ANSI C++ standard so I propose an extension ERT> to the C++ language similar to named return values ERT> which the C++ programmer can use to help the compiler ERT> identify names which reference the return value. [...] ERT> Function X f2(int) illustrates the named return value extension ERT> as currently supported by my egcs compiler. See the GCC manual at ERT> http://egcs.cygnus.com/onlinedocs/gcc_5.html#SEC102 ERT> The current extension is very old now and it seems unlikely to me ERT> that it will ever be adopted as part of the ANSI C++ standard. ERT> It solves the problem that the egcs compiler has with function X f1(int) ERT> but the function definition is entirely incompatible with ANSI C++ and ERT> it cannot solve the problem that the compiler has with function X g0(X). [...] I don't know what will be decided, but let me throw my 0.02 euros there. I certainly don't minimize the inmportance of compiler level optimizations. But it's my opinion that there are ISO C++ language features--not optimizations--that need to be fixed or implemented in the compiler. That already is a lot of work to do. I'm not particulary interested in seeing a lot of work spent in implementing non-stantdard features, that will probably badly interact with ISO C++, whereas there are more fundamental topics waiting to be addressed. So my proposal will be: let's first catch up the Standard, then we'll address optimizations issues. Not just a particular optimization is _permitted_ that it means the compiler *should* implement it, particullary when the compiler is trying hard to get semantics right. just my 0.02 euros. -- Gaby From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gabriel Dos Reis To: egcs@egcs.cygnus.com Cc: "E. Robert Tisdale" Subject: Re: Named Return Value Extension Proposal Date: Wed, 31 Mar 1999 23:46:00 -0000 Message-ID: References: <36F6B101.2441947C@netwood.net> X-SW-Source: 1999-03n/msg00736.html Message-ID: <19990331234600.5B1gETdvgHuPpdoA_1Nu3juQWjgEoJrrwFLul_xhbuI@z> >>>>> «ERT», E Robert Tisdale wrote: ERT> My egcs-2.90.29 980515 (egcs-1.0.3 release) compiler ERT> does not always elide copy constructors as permitted ERT> by the ANSI C++ standard so I propose an extension ERT> to the C++ language similar to named return values ERT> which the C++ programmer can use to help the compiler ERT> identify names which reference the return value. [...] ERT> Function X f2(int) illustrates the named return value extension ERT> as currently supported by my egcs compiler. See the GCC manual at ERT> http://egcs.cygnus.com/onlinedocs/gcc_5.html#SEC102 ERT> The current extension is very old now and it seems unlikely to me ERT> that it will ever be adopted as part of the ANSI C++ standard. ERT> It solves the problem that the egcs compiler has with function X f1(int) ERT> but the function definition is entirely incompatible with ANSI C++ and ERT> it cannot solve the problem that the compiler has with function X g0(X). [...] I don't know what will be decided, but let me throw my 0.02 euros there. I certainly don't minimize the inmportance of compiler level optimizations. But it's my opinion that there are ISO C++ language features--not optimizations--that need to be fixed or implemented in the compiler. That already is a lot of work to do. I'm not particulary interested in seeing a lot of work spent in implementing non-stantdard features, that will probably badly interact with ISO C++, whereas there are more fundamental topics waiting to be addressed. So my proposal will be: let's first catch up the Standard, then we'll address optimizations issues. Not just a particular optimization is _permitted_ that it means the compiler *should* implement it, particullary when the compiler is trying hard to get semantics right. just my 0.02 euros. -- Gaby