"Balog Pal" <pasa@lib.hu> wrote in
news:3b21fdfd@andromeda.datanet.hu:

>
> "Marco Manfredini" <marco@technoboredom.net> wrote in message
> news:Xns90BAA2C1B175marcotechnobore@technoboredom.net...
>
>
> That is not part of the question -- see my other post. Believe me,
> I'm completely aware what is going on and why, just I'm interested
> whether an internal compiler error is justified for the situation
> or not. (Btw msvc 5 compiles the code without a slighest problem.)
>

Haha. I don't think that an internal compiler error is a justifiable
reaction to program code. But I might be wrong and will look up the
STANDARD for that, for it may possibly define that "a program that
contains unreasonable or funny code shall provoke an unreasonable
reaction from the compiler"

Seriously, my observation is, that references to temporaries &
complicated template issues have the power to demonstrate quality of
implementation issues.

For example:

struct A
{
};

struct B : public A
{
};

int x()
{
 for (const A& a=B();;) {}
}

will break gcc 2.95 on Linux and cause gcc 2.95.2 on cygwin to -hang
forever-!! (But it's fixed now, AFAIC)

--
Marco

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Marco Manfredini" <marco@technoboredom.net> wrote in message news:Xns90BAA2C1B175marcotechnobore@technoboredom.net...

> > Foo & Bar()
> > {
> >     assert (false);
> >     return Foo();   // returns bullshit, but we never should get
> >     here
> > }

> (1) <return Foo();> returns a r-value - that is, Bar must be <const Foo
> &>, since rvalues cannot be bound to non-const references (at least
> officially, many compilers allow it, if you toggle the right switches)

BAH! You're completely right, the original situation had const Foo & as return type, I just somehow left it out.

> (2) assert doesn't mean anything to the compiler.

That is not part of the question -- see my other post. Believe me, I'm completely aware what is going on and why, just I'm interested whether an internal compiler error is justified for the situation or not. (Btw msvc 5 compiles the code without a slighest problem.)

> Most of the time the
> macro will expand to something like:

Instead of the assert I could write throw, exit(), abort(), anything, that really prevents reaching the return statement. The compoiler still requires a return on all paths, including dead ones.

> (3) returning the reference should make the compiler issue a warning
> about returning a reference to a temporary/stack-object in this case
> (its proveable for him that you return one). But you shouldn't expect
> such wisdom:

it correctly does so, for

const Foo & Bar()
   { Foo dummy; return dummy;}

but return Foo(); hits an internal assert in the compiler.

Paul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Sef Campstein" <sef@campst.tmfweb.nl> wrote in message news:9fr0ui$7f7$1@cyan.nl.gxn.net...

> Why are you returning a reference too a temporary?

Let's see a better example:

const Foo & Bar(int param)
{
    const int remainder = param % 3;
    if(remainder == 0)
        return ObtainFoo0();
    else if(remainder == 1)
        return ObtainFoo1();
    else
    {
        AbortExecution("domain error in Bar(int): remainder not 0 or 1");
        return ???;
    }
}

AbortExecution is some terminating funtion which will never return. So anything after it is logically unreachable code, but the compiler has no way to know that, and require some return on all paths in order to compile Bar.

Returning Foo() lookd like the lightest way to provide it, if that object has an empty ctor it cost nothing. Alternative solutions could use a static Foo() using up space, or return new Foo() using a few bytes in the code segment.

If the first solution exploits undefined behavior, certainly the those costs are justified, but not without that. So I still want to know whether it is or not.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Balog Pal (mh) <pasa@lib.hu> wrote:

> class Foo {...};
>
> Foo & Bar()
> {
>     assert (false);
>     return Foo();   // returns bullshit, but we never should get here
> }

and later in the other message:

> In the real situation it was a virtual function of the root base class
> working in a chain manner: if the argument is within its range, the class
> returns a relevant element, if not, calls the parent to do so. The root
> class has nothing to offer, so the function can't be called. If it is,
we're
> doomed anyway. Normally it would be a pure firtual, just the base class in
> this case is not abstract. All its functions work well to the spec,
> including the one under discussion, as it has a defined domain, and that
is
> empty for the case.

you might consider throwing an exception from the Bar():

Foo& Bar()
{
  throw std::logic_error("Bar(): we never should get here");
}

--
Pavel Kuznetsov
mailto:pavel_kuznetsov@no.spam.users.sourceforge.net
remove "no.spam." from e-mail address



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Balog Pal (mh)" <pasa@lib.hu> wrote in message
news:<3b1fc470@andromeda.datanet.hu>...

> I want to know if the following code is undefined behavior *even if
> never executed*.

> class Foo {...};

> Foo & Bar()
> {
>     assert (false);
>     return Foo();   // returns bullshit, but we never should get here
> }

The code isn't legal, because it binds a temporary to a non-const
reference.  This isn't undefined behavior; it requires a diagnostic.
Because once in the distant past, it was legal to bind a temporary to
a non-const reference, a lot of compilers will only give you a
warning, and generate the code anyway.

If the return type were a const reference, it would only be undefined
behavior if the caller attempts to use the returned reference; even
calling the function is legal.

> The reason I ask is that MSVC6 got me a '1001 internall error -- compiler
> confised call the support'.  A plenty of different rearrangements make the
> call compile like
> Foo dummy; return dummy;

The error message is obvious, I think.  You have encountered an error
in the compiler.  Do as the message says: call support.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote in message ...

>>Foo & Bar()
>>{
>>    assert (false);
>>    return Foo();   // returns bullshit, but we never should get here
>>}
>
>Even when NDEBUG is defined? :)


"Never should get here" is completely independent of the assert being there,
and NDEBUG anf phases of the moon. I put the assert there just for the human
eye.

(In the real situation it was a virtual function of the root base class
working in a chain manner: if the argument is within its range, the class
returns a relevant element, if not, calls the parent to do so. The root
class has nothing to offer, so the function can't be called. If it is, we're
doomed anyway. Normally it would be a pure firtual, just the base class in
this case is not abstract. All its functions work well to the spec,
including the one under discussion, as it has a defined domain, and that is
empty for the case. )

Back to the question: should the compiler compile that code, or it is a
standard-conforming behavior it falling apart and formatting c: during
compilation?

Paul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Balog Pal (mh)" <pasa@lib.hu> wrote in
news:3b1fc470@andromeda.datanet.hu:

> I want to know if the following code is undefined behavior *even if
> never executed*.
>
> class Foo {...};
>
> Foo & Bar()
> {
>     assert (false);
>     return Foo();   // returns bullshit, but we never should get
>     here
> }
>
> The reason I ask is that MSVC6 got me a '1001 internall error --
> compiler confised call the support'.  A plenty of different
> rearrangements make the call compile like
> Foo dummy; return dummy;
>
> Paul
>

(1) <return Foo();> returns a r-value - that is, Bar must be <const Foo
&>, since rvalues cannot be bound to non-const references (at least
officially, many compilers allow it, if you toggle the right switches)

(2) assert doesn't mean anything to the compiler. Most of the time the
macro will expand to something like:

assert(x) =>
if (!(x)) assert_fail("x");

(assert does -not- throw)

since there is no way to tell the compiler that assert_fail does not
return, he has no way to see, that the return statement isn't used at
all. And if he could (like from a throw statement) this wouldn't mean
that he would literally ignore the dead code, since he still want's to
see C++ there (even if it's not used).

(3) returning the reference should make the compiler issue a warning
about returning a reference to a temporary/stack-object in this case
(its proveable for him that you return one). But you shouldn't expect
such wisdom:

class Foo
{
};

const Foo & a()
{
 const Foo &a=Foo();
 return a;
}

isn't suspicious for GCC, for example.

--
Marco

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

>
> class Foo {...};
>
> Foo & Bar()
> {
>     assert (false);
>     return Foo();   // returns bullshit, but we never should get here
> }
>

Why are you returning a reference too a temporary?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Balog Pal (mh)" <pasa@lib.hu> wrote in message
news:3b1fd6db@andromeda.datanet.hu...
> (In the real situation it was a virtual function of the root base class
> working in a chain manner: if the argument is within its range, the class
> returns a relevant element, if not, calls the parent to do so. The root
> class has nothing to offer, so the function can't be called. If it is,
we're
> doomed anyway. Normally it would be a pure firtual, just the base class in
> this case is not abstract. All its functions work well to the spec,
> including the one under discussion, as it has a defined domain, and that
is
> empty for the case. )
>
> Back to the question: should the compiler compile that code, or it is a
> standard-conforming behavior it falling apart and formatting c: during
> compilation?


The compiler should compile the code fine. I understand you need to return a
value although you don't use the function, in order for it to compile and
link warning-free.

I suggest you throw an exception, case in which most compilers, includin
MSVC, figure out you'll never return from the function:

Foo & Bar()
{
    throw "hehe";
}


Andrei

--
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I want to know if the following code is undefined behavior *even if never
executed*.

class Foo {...};

Foo & Bar()
{
    assert (false);
    return Foo();   // returns bullshit, but we never should get here
}

The reason I ask is that MSVC6 got me a '1001 internall error -- compiler
confised call the support'.  A plenty of different rearrangements make the
call compile like
Foo dummy; return dummy;

Paul





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3b1fc470@andromeda.datanet.hu>, Balog Pal (mh) <pasa@lib.hu>
writes
>I want to know if the following code is undefined behavior *even if never
>executed*.
>
>class Foo {...};
>
>Foo & Bar()
>{
>    assert (false);
>    return Foo();   // returns bullshit, but we never should get here
>}

Even when NDEBUG is defined? :)

>
>The reason I ask is that MSVC6 got me a '1001 internall error -- compiler
>confised call the support'.  A plenty of different rearrangements make the
>call compile like
>Foo dummy; return dummy;
>
>Paul
>
>
>
>
>
>---
>[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
>[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
>[              --- Please see the FAQ before posting. ---               ]
>[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
>

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]