(Anti-)Programmierwettbewerb

otze

Berniebutt. Eventuell sind solche Wettbewerbe interessant, weil sie austesten wie gut die Compikler, von denen unglaublich viel auf unseren Systemen abhängt, überhaupt getestet sind. Jeder gefundene Bug erhöht die Sicherheit.

Aber bei dir habe ich eh den Eindruck, dass dich Informatik als Solche nicht sonderlich interessiert :).

pyhax

hustbaer schrieb:

camper schrieb:

hustbaer schrieb:

aber erlaubt isses (Deklaration die nix deklariert).

Ich bin ziemlich sicher, dass das nicht erlaubt ist. Es gibt ein paar Fälle, wo die Deklaration selbst keinen Bezeichner einführt, dann gehört dazu aber immer noch etwas anderes, das das tut (bei anonymen unions mindestens ein Member; und unbenannte Bitfelder sind immer Teil einer Klasse).

Hm. OK
Crasht der Code noch wenn man nen Deklarator dranschreibt? Wenn ja wäre ja alles in Butter.

Ja, der crasht noch. Aber es sollte doch kurz sein (Und ich hatte es auch erst mit Variadic templates, habe dann aber rausgefunden das es auch ohne geht. BTW: Wenn man als Funktionspointertype int(*)(int) nimmt, crasht es nicht. Ebenso wenn man den Cast durch einen C-style cast ersetzt, reinterpret_cast crasht aber :D)

berniebutt

otze schrieb:

... Eventuell sind solche Wettbewerbe interessant, weil sie austesten wie gut die Compikler, von denen unglaublich viel auf unseren Systemen abhängt, überhaupt getestet sind. Jeder gefundene Bug erhöht die Sicherheit ...

Welche Sicherheit soll denn erhöht werden? Ihr sucht Möglichkeiten einen Compiler zum Abschmieren zu bringen. Wird schwer: der Compiler interpretiert nur Text und versucht nach vorgegebenen Regeln daraus ein ausführbares Programm zu machen. Weil Compiler auch programmiert sind können diese sicher nicht jeden Unsinn erkennen oder abfangen. Die Umsetzung zur exe gelingt oder gelingt nicht.

Bitte zeigen, wie man schon den Compiler mit einem simplen Sourcecode zum Crash führt!

berniebutt schrieb:

Weil Compiler auch programmiert sind können diese sicher nicht jeden Unsinn erkennen oder abfangen. Die Umsetzung zur exe gelingt oder gelingt nicht.

Die Theorie des Compilerbaus ist sehr gut verstanden. Die Aussage, dass ein Compiler "nicht jeden Unsinn" erkennen kann, ist somit Quatsch. C++ kratzt an den Grenzen des derzeit praktisch machbaren ob der Komplexität des Standards und einen Compiler zum abschmieren zu bringen ist also sehr wohl interessant.

Wenn man kein Interesse hat, einfach mal die Fresse halten.

Sone

berniebutt schrieb:

Bitte zeigen, wie man schon den Compiler mit einem simplen Sourcecode zum Crash führt!

Siehe mein Code. Oder Pyhax'.

hustbaer

@berniebutt

Also hier extra für dich ein schönes Beispiel mit dem schönen (gerade noch) aktuellen MSVC 2010:

http://stackoverflow.com/questions/9044061/lambda-function-does-not-compile-in-visual-studio-2010

Bzw. google auch selber gerne nach MSVC C1001 oder C1001 ICE.

berniebutt

Ich habe die Antworten verstanden: Die Compilerbauer hinken der Komplexität theoretischer Anforderungen gelegentlich hinterher oder schaffen einiges einfach nicht so schnell, was sich theoriebessene Fuzzies ausdenken. Was heisst das nun für die Programmierung? Meine Antwort: Immer auf klare ausgereifte Standards setzen und nur bugfreie Dinge verwenden. War schon immer so!

Wer sein eigenes Programm wegen eines Bugs im Compiler nicht zum laufen bringt ist arm dran und verdient mit seiner Arbeit kein Geld. Der Kunde will ein lauffähiges Programm und nur dafür zahlt er!

hustbaer

@berniebutt
Niemand sagt dass wir bzw. andere Leute die Compiler-Bugs finden unsere/ihre Programme nicht zum Laufen bekommen. Du erfindest hier ein Szenario das einfach nicht real ist.

Was bitte ist schlecht daran Compiler-Bugs zu suchen? Wenn man sie findet kann man sie reporten, und dann können sie gefixt werden.

Das hat auch nichts damit zu tun dass man irgendwelchen total krassen bekloppten Code schreibt, oft stolpert man da einfach so drüber.

Es gibt nunmal einen C++ Standard, und die Compiler sollten sich daran halten. Wenn man mit korrektem Code einen Compiler zum Crashen bringt, dann ist nicht der Programmierer fehlerhaft sondern der Compiler.
Und selbst wenn man mit inkorrektem Code einen Compiler zum Crashen bringt, ist der Compiler fehlerhaft bzw. zumindest minderwertig: er sollte eine (idealerweise verständliche) Fehlermeldung abliefern anstatt einfach nur zu crashen.

Moin!
mein gcc 4.5.1 (und der von ideone) stürzen ab:

#include <vector>

int main(){
  std::vector<int>{int};
}

War das Produkt einer Kompilierung, bevor ich meinen Gedanken fertig geschrieben habe...

Ich denke nicht dass das wirklich Compilerübergreifend ist. Da ist doch wohl ein Syntaxfehler. Comeau online gibt sich auch keine Blöße.

Was sagen denn Eure Compiler so? Besonders neuere gcc.
Wenn es noch nicht gefixt wurde könnte man dem ja auf den Grund gehen...

Sone

GCC 4.8 developer release schrieb:

C:...\C(++) Saves\TEMPS\TEMP.cxx||In function 'int main()':|
C:\...\C(++) Saves\TEMPS\TEMP.cxx|4|error: no matching function for call to 'std::vector<int>::vector(<brace-enclosed initializer list>)'|
C:\...\C(++) Saves\TEMPS\TEMP.cxx|4|note: candidates are:|
.....

Na das ging ja fix...