Ich habe das durchgemacht Artikel
und es gibt eine Aussage in Punkt 3, die besagt
// C++98
rectangle w( origin(), extents() ); // oops, vexing parse
Wie ist das obige eine äußerst ärgerliche Analyse. Wenn ich so etwas mache
struct origin
{
};
struct Rectangle
{
Rectangle(const origin& s)
{
}
};
Die Aussage
Rectangle s(origin());
funktioniert gut und ähnelt keiner lästigen Analyse. Warum hat der Autor gesagt, dass es eine ärgerliche Analyse ist. Ist das ein Tippfehler oder übersehe ich etwas?
Siehe Abschnitt 1(b) des Dokuments, es erklärt diese ärgerlichen Analysen.
– Barmar
22. Juli 2015 um 21:53 Uhr
Wieso sagst du
Rectangle s(origin());
ähnelt nicht einer ärgerlichen Analyse? Es ist das kanonische Beispiel für die ärgerlichste Analyse. Was ist Ihrer Meinung nach die ärgerlichste Analyse, wenn nicht das?– Benjamin Lindley
22. Juli 2015 um 21:56 Uhr
Die Deklaration funktioniert einwandfrei. Versuchen zu benutzen
s
und sehen was passiert.– molbnilo
22. Juli 2015 um 21:58 Uhr
Ich verstehe, dass es einer ärgerlichen Analyse ähnelt. Ich habe jedoch den Eindruck, dass eine ärgerliche Analyse zu einem Kompilierzeitfehler führen würde. zum Beispiel für eine Klasse foo, die es wie verwendet
foo a();
würde beim Kompilieren einen Fehler geben und es ist eine Form der ärgerlichsten Analyse. Was ich also bekomme, ist, dass eine Anweisung einer ärgerlichen Analyse ähneln und gleichzeitig ohne Probleme kompilieren könnte. Eine ärgerliche Analyse von dem, was ich verstehe, ist eine Aussage, die einer Funktion ähneln könnte.<Return type> functionName (parameters..)
– James Franco
22. Juli 2015 um 22:34 Uhr
Der Grund, warum wir es nennen ärgerlich liegt an der Deklaration nicht einen Kompilierzeitfehler verursachen. Es verursacht erst später im Programm einen Fehler Wenn Sie verwenden die Funktion.
– Aaron McDaid
22. Juli 2015 um 22:36 Uhr