--- Comment #30 from redi at gcc dot gnu dot org 2010-08-28 14:42 ---
Can we change the summary to mention references? It looks to me as though it's
talking about the address-of operator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #29 from redi at gcc dot gnu dot org 2010-08-28 14:39 ---
that's why EDG only gives a "remark" not a warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #28 from driscoll at cs dot wisc dot edu 2010-08-27 22:53
---
> Your two functions are well defined as the scope of the temp is only lost
> after going out of scope.
I see "A reference is bound to a temporary object: the temporary object is
destroyed at the end of the refer
--- Comment #27 from pinskia at gcc dot gnu dot org 2010-08-27 22:21
---
>This first one is inspired by the code I was working on:
Your two functions are well defined as the scope of the temp is only lost after
going out of scope. So there is no references to a temp escaping unlike th
--- Comment #26 from driscoll at cs dot wisc dot edu 2010-08-27 22:02
---
I was surprised to see this is not caught by a warning as well. (The discussion
of whether it should be an error is silly; it pretty clearly shouldn't be.
There's -Werror if you disagree.)
Motivation: This surfac
--- Comment #25 from manu at gcc dot gnu dot org 2009-08-05 13:21 ---
If anyone has any hint on where this could be caught, suggestions are welcome.
The explanation of Alexandre Oliva in comment #8 is totally obscure to me and
perhaps outdated given the age of this PR.
--
manu at gc
--- Comment #24 from paolo dot carlini at oracle dot com 2009-08-05 12:34
---
*** Bug 40970 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #23 from manu at gcc dot gnu dot org 2007-05-16 14:03 ---
Hi Naimu, I am not speaking in the name of the GCC community but I would like
to prevent your frustration. You exposed your point clearly. People that have a
deep knowledge of C++ and g++ don't agree with you. Repeatin
--- Comment #22 from raf2 at msux dot cjb dot net 2007-05-16 08:50 ---
Mmm... maybe I haven't explained correctly.
If you contract someone to build stairs and later he says: "As long as you
don't touch this step, everything's ok" you tell him some nasty things.
The users of our g++ pro
--- Comment #21 from bangerth at dealii dot org 2007-05-14 17:50 ---
This is getting completely off-topic, so here's my last post:
(In reply to comment #20)
> Can someone provide a program with that undefined behaviour that could not be
> considered an error?
As long as you don't touch
--- Comment #20 from raf2 at msux dot cjb dot net 2007-05-14 09:30 ---
We have talked about the undefined behaviour of having references to objects
that have been destroyed.
Can someone provide a program with that undefined behaviour that could not be
considered an error?
--
http
--- Comment #19 from chris at bubblescope dot net 2007-05-09 17:05 ---
while I agree we shouldn't produce an error here, personally I'm highly
unconvinced by your argument. If I had some code which if called would always
lead to undefined behaviour, but never called it, I would still wan
--- Comment #18 from bangerth at dealii dot org 2007-05-09 16:39 ---
(In reply to comment #17)
> Are comitee decisions (right or wrong) more important than consequences for
> people? So Borland protects people from undefined behaviours when they can,
> and
> I wonder, isn't what most p
--- Comment #17 from raf2 at msux dot cjb dot net 2007-05-09 16:27 ---
> Compilers may warn about this, but they may not issue an error.
Let's see what has to say the freely available Borland C++ 5.5.1 for Windows.
Yes, it wisely stops people from compiling the attached "main.cpp":
Erro
--- Comment #16 from bangerth at dealii dot org 2007-05-08 17:25 ---
(In reply to comment #14)
> Which was wrong, I reported the bug and a guy from MinGW kindly explained that
> if it worked then that would be purely by accident and added:
> " When you declare the argument without '&' th
--- Comment #15 from raf2 at msux dot cjb dot net 2007-05-08 17:22 ---
Created an attachment (id=13531)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13531&action=view)
File with wrong code that leads to an unexpected result
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #14 from raf2 at msux dot cjb dot net 2007-05-08 17:18 ---
I first was hit by an error using MinGW... when I compiled and executed the
first attached file, it wrote:
John drives a: "bus"
Otto drives a: "bus"
Which was wrong, I reported the bug and a guy from
--- Comment #13 from bangerth at dealii dot org 2007-05-08 15:34 ---
(In reply to comment #12)
> The summary says "g++ misses warning for & on temporary". But something that
> is
> always an error can be called a warning?
The point is that the standard doesn't call it an error, but und
--- Comment #10 from bangerth at dealii dot org 2007-05-02 22:56 ---
*** Bug 31788 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--
--- Comment #9 from bangerth at dealii dot org 2006-10-26 06:35 ---
*** Bug 29593 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-16
17:27 ---
Getting a warning to be issued is easy: initialize_ref may print it if it finds
that the call to convert_like will create a temporary, testing
conv->need_temporary_p. However, this would trigger warnings for
21 matches
Mail list logo
