Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Kein return -> Compiler sagt nix?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
16.01.2009, 10:44 Uhr
~uffob
Gast


Hallo,

ich wundere mich über folgendes: Wenn ich in einer Funktion die einen wert zurückgeben soll kein return angebe meckert der compiler gar nicht. Erst wenn ich das flag -Wall eintippe kommt ein warning. Müsste das nicht ein error sein? Warum ist das so?

hier ein minimalbeispiel welches aber durchaus auch kleiner hätte sein können.
In der fun2() fehlt das return:


C++:
#include <iostream>

class A
{
  public:
        double fun(const double & val)
        {
                m_value = fun2();
        }

        double fun2()
        {
                double val2 = 0.56;

                val2;
        }

        double m_value;

};

int main()
{
        A A_C;

        double val = 3.14;

        A_C.fun(val);

        std::cout << "Test of m_value: " << A_C.m_value << std::endl;

        double test = A_C.fun2();

        std::cout << "test: " << test  << std::endl;
}


 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
16.01.2009, 11:05 Uhr
ao

(Operator)


Interessant - welcher Compiler leistet sich sowas?

Und da es ja offensichtlich irgendwie läuft - was ist das Ergebnis von fun2?
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
16.01.2009, 11:12 Uhr
~uffob
Gast


Hallo,

ich dachte mir schon dass es seltsam ist wollte mir noch eine Meinung einholen:

Der Wert von test und der membervariable wird mit NaN ausgegeben.
Der Compiler ist der normale gcc 4.1.2:

Code:
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2 p1.1)

 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
16.01.2009, 15:19 Uhr
0xdeadbeef
Gott
(Operator)



Zitat von C++-Standard 6.6.3 (2):

A return statement without an expression can be used only in functions that do not return a value, that is, a function with the return type void, a constructor (12.1), or a destructor (12.4). A return statement with an expression of non-void type can be used only in functions returning a value; the value of the expression is returned to the caller of the function. The expression is implicitly converted to the return type of the function in which it appears. A return statement can involve the construction and copy of a temporary object (12.2). Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.


(Markierung von mir) Es erzeugt also undefiniertes Verhalten. Neuere gccs beschweren sich auch darüber, wenn mich gerade nicht alles täuscht.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 16.01.2009 um 15:20 Uhr von 0xdeadbeef editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
16.01.2009, 16:20 Uhr
ao

(Operator)


Wow. Also ist der gcc im Recht.

Aber warum wurde das so festgelegt? Warum hat man das nicht als Syntaxfehler definiert? Es kann doch eindeutig vom Compiler erkannt werden.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
16.01.2009, 16:38 Uhr
rapso




Zitat von ao:
Wow. Also ist der gcc im Recht.

Aber warum wurde das so festgelegt? Warum hat man das nicht als Syntaxfehler definiert? Es kann doch eindeutig vom Compiler erkannt werden.

weil es sein kann, dass du weisst, dass du nie zum ende kommst und deswegen keinen code dort generieren willst.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
16.01.2009, 16:48 Uhr
ao

(Operator)


Endlosschleife?

Aber warum soll eine Funktion, die nie zurückkehrt, einen Rückgabetyp (!= void) haben?

Oder, andersrum, was hindert mich, hinter einer Endlosschleife einfach ein "return 0;" zu schreiben, das nie ausgeführt wird?
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
16.01.2009, 17:28 Uhr
0xdeadbeef
Gott
(Operator)


Ich nehme an, weil es die Syntax stark verkompliziert hätte. Man hätte zwei Funktionsspezifikationen - eine für void, eine für andere Rückgabetypen - die sich nur unwesentlich unterscheiden, schreiben und pflegen müssen. Ein Semantikfehler wäre denkbarer, aber...der Funktionsfluss ist semantisch gar nicht so einfach zu erfassen. Nimm zum Beispiel

C++:
int foo() {
  if(irgendwas()) {
    return 1234;
  } else {
    return 5678;
  }
}


...da muss der Compiler schon schlau sein. Oder

C++:
int bar() {
  if(das_ist_immer_wahr()) {
    return 0;
  }
}


...und wie verhält es sich mit exceptions?

C++:
void foo() {
  throw std::runtime_error("Ha, ha!");
}

int bar() {
  if(irgendwas()) {
    return 1234;
  }

  foo();
}


Ich denke, es ist schon sinnvoll, das einfach undefiniert zu lassen; hier alle Fälle erschlagen zu wollen, scheint mir nahezu unmöglich.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: