Fehler, Irrtümer, Fragen - Seite 2025

Neuer Kommentar
 

Doppelfehler bei der Ausführung

#define  XY( X, Y )      X##Y
#define  f( X )  XY( g, X )
#define  MACRO1( X )     #X
#define  MACRO2( X )     MACRO1( X )
#define  SIZE    5
void OnStart()
{
    printf( "%s", MACRO2( f( SIZE )));
}

Ergebnis: f(SIZE)

Sollte lauten: g5

 
leonerd:

Wie entferne ich die Pfeile aus dem Testvisualisierungsdiagramm? Ich beginne mit dem Test, und es sind immer noch Pfeile und Linien von Eingaben aus dem letzten Test zu sehen.

Bereinigen Sie die Vorlage tester.tpl, wahrscheinlich sind die Objekte dort vorhanden.

 
A100:

Doppelfehler bei der Ausführung

Ergebnis: f(SIZE).

Er sollte lauten: g5


Das scheint mir ein logisches Ergebnis zu sein.

 
fxsaber:
Das scheint mir ein logisches Ergebnis zu sein.

Erwartet: Zuerst Substitution des internen Makros SIZE, dann des Zwischenmakros f( X ) und schließlich des externen Makros MACRO2( X )

Das Ergebnis ist jedoch anders, auch wenn man eine unvollständige Logik verwendet:

#define  MACRO1( X )     #X
void OnStart()
{
    printf( "%s", MACRO1( f( SIZE )));
}
//Результат  :f(SIZE)
//должен быть:f( SIZE )

Zumindest liegt der Unterschied in den Zwischenräumen

 
A100:

Erwartet: Zuerst Substitution des internen Makros SIZE, dann des Zwischenmakros f( X ) und schließlich des externen Makros MACRO2( X )

Das Ergebnis ist jedoch anders, auch wenn man eine unvollständige Logik verwendet:

Zumindest liegt der Unterschied im Leerzeichen

Die Priorität der Funktionen ist natürlich von innen nach außen. Bei Makros hingegen ist es genau andersherum.

#X ist eine Zeichenkette ohne Leerzeichen. Dem kann man natürlich nicht zustimmen.

 
fxsaber:

Die Priorität der Funktionen liegt natürlich auf der Innenseite. Bei Makros hingegen ist es genau umgekehrt.

#X ist eine Zeichenkette ohne Leerzeichen. Natürlich kann man damit nicht einverstanden sein.

Aber warum sollten wir neue komplizierte Regeln mit einer alten Notation erfinden, wenn es bereits einfache alte Regeln mit einer solchen Notation gibt - einem breiten Kreis von Menschen bekannt und seit Jahrzehnten etabliert? Wenn die Regeln neu sind, dann sollten auch die Bezeichnungen neu sein

 
A100:

Doppelfehler bei der Ausführung

Ergebnis: f(SIZE)

Sollte lauten: g5

Ich habe vor einem Jahr eine ähnliche Anfrage an den Kundendienst geschickt (#1600034), die immer noch nicht beantwortet wurde. Es scheint, dass sie sich nicht um all diese "Geek"-Bugs kümmern. Und im Allgemeinen hat die Sprache nicht die Absicht, sich zu verbessern, wenn man nach dem Urteil aller geht. Nur große Fehler werden behoben, mehr nicht.
 
A100:

Warum neue, komplizierte Regeln mit alten Bezeichnungen erfinden, wenn es bereits einfache, alte Regeln mit solchen Bezeichnungen gibt - die einer Vielzahl von Menschen bekannt sind und sich über Jahrzehnte bewährt haben? Wenn die Regeln neu sind, sollten auch die Bezeichnungen neu sein.

Worüber genau sprechen wir? Wie sollte es sein?

 
fxsaber:

Worüber genau sprechen wir? Und wie sollte es sein?

#X ist die Zeichenkette so, wie sie ist - d.h. mit Leerzeichen (falls vorhanden). Und siehe obiges Beispiel von f( SIZE ) -> g5. Ich habe diese Regeln nicht selbst erfunden - so machen es die C++-Compiler

 
Alexey Navoykov:
Ich habe vor einem Jahr eine ähnliche Anfrage an den Servicedesk geschickt (#1600034), und immer noch keine Antwort erhalten. Es scheint, dass sie sich nicht um all diese "Geek"-Bugs kümmern. Und im Allgemeinen hat die Sprache nicht die Absicht, sich zu verbessern, wenn man nach dem Urteil aller geht. Sie beheben nur größere Fehler, mehr nicht.

Ich bin erst gestern zufällig darauf gestoßen und war überrascht, wie gut das in Verbindung mit

template<typename T, int n>

Aus mehreren Dutzend Codezeilen sind buchstäblich eine oder zwei (!) geworden. Deshalb habe ich es geschrieben - auf den ersten Blick mag es eine Lappalie sein. Wieder einmal bin ich davon überzeugt, dass es in C++ keinen Unsinn gibt.

1...201820192020202120222023202420252026202720282029203020312032...3184
Neuer Kommentar