C
SeppJ schrieb:
Shade Of Mine schrieb:
camper schrieb:
Der Compiler "denkt" in impliziten Nebenbedingungen.
Ok, ich kann mir vorstellen wie du das theoretisch meinst - ich tue mir lediglich schwer an sowas in der Praxis zu glauben. Denn es setzt ein ziemlich starkes reorganisieren des codes voraus. (ohne dabei performance gewinn zu haben)
Vor allem sind da gleich mehrere, in der Regel externe, Funktionsaufrufe drin, an denen der Compiler nicht vorbei kommen kann. Ja, man kann sich einen eigenen Stream schreiben, bei dem alles inline ist, dann greift wieder Shade Of Mines Einwand.
So viel muss man da gar nicht inlinen: (gcc 4.6.3)
template<typename _CharT, typename _Traits>
basic_istream<_CharT, _Traits>&
operator>>(basic_istream<_CharT, _Traits>& __in, _CharT& __c)
{
typedef basic_istream<_CharT, _Traits> __istream_type;
typedef typename __istream_type::int_type __int_type;
typename __istream_type::sentry __cerb(__in, false);
if (__cerb)
{
ios_base::iostate __err = ios_base::goodbit;
__try
{
const __int_type __cb = __in.rdbuf()->sbumpc();
if (!_Traits::eq_int_type(__cb, _Traits::eof()))
__c = _Traits::to_char_type(__cb);
else
__err |= (ios_base::eofbit | ios_base::failbit);
}
__catch(__cxxabiv1::__forced_unwind&)
{
__in._M_setstate(ios_base::badbit);
__throw_exception_again;
}
__catch(...)
{ __in._M_setstate(ios_base::badbit); }
if (__err)
__in.setstate(__err);
}
return __in;
}
Es genügt diesen Operator zu inlinen. __c ist garantiert alias-frei (weil es eine lokale automatische Variable des Aufrufers ist), damit spielt es für das Problem keine Rolle, was evtl. aufgerufene externe Funktionen tun.
Dennoch sollte man es fixen.
Das würde ich als einen Fehler ansehen. Der Code wird unter allen Umständen korrekt funktionieren. Man würde also einen kleinen Performanceverlust einbauen, bloß um eine Warnung in einem externen Programm los zu werden. Das richtige Vorgehen wäre wohl eher, eine weitere Ausnahme zu valgrind hinzu zu fügen. Es gibt schließlich schon genügend unterdrückte Warnungen für die Standardbibliothek.
Die Fehlermeldung ist lediglich Anlass, nicht Grund für die Behebung. Es ist schlicht nicht beweisbar, dass dieser Code immer funktionieren wird, und es kann ein Modus angegeben werden, mit dem er fehlschlagen könnte. Die notwendige Korrektur ist einfach und überschaubar. Das sollte als Änderungsgrund reichen. Und Performance muss dabei nicht zwingend verloren gehen.
/edit pumuckl: fehlernder quote-Tag