Syntaktischer Zucker in C/C++

Ich habe mich mit Ruby beschäftigt und finde die Schlüsselwörter „until“ und „unless“ sehr interessant. Also dachte ich, was eine gute Möglichkeit wäre, ähnliche Schlüsselwörter in C/C++ hinzuzufügen. Das ist mir eingefallen:

#define until(x)    while(!(x))
#define unless(x)   if(!(x))

Ich suche hierzu ein paar Anregungen. Kann jemand eine bessere Alternative vorschlagen?

Hier ist ein Beispiel für ein Programm, das ich geschrieben habe, um zu veranschaulichen, was ich vorhatte:

#include <stdio.h>
#include <stdlib.h>

#define until(x)    while(!(x))
#define unless(x)   if(!(x))

unsigned int factorial(unsigned int n) {
    unsigned int fact=1, i;
    until ( n==0 )
        fact *= n--;
    return fact;    
}

int main(int argc, char*argv[]) {
    unless (argc==2)
        puts("Usage: fact <num>");
    else {
        int n = atoi(argv[1]);
        if (n<0)
            puts("please give +ve number");
        else
            printf("factorial(%u) = %u\n",n,factorial(n));
    }
    return 0;
}

Es wäre großartig, wenn Sie mir einige Referenzen für ähnliche Tricks nennen könnten, die in C oder C++ eingesetzt werden können.

Kann jemand eine bessere Alternative vorschlagen?

Ja. Tun Sie dies auf keinen Fall. Verwenden Sie einfach die while und if Aussagen direkt.

Wenn Sie in C oder C++ programmieren, programmieren Sie in C oder C++. Während until und unless in einigen Sprachen häufig und idiomatisch verwendet werden, sind sie nicht in C oder C++.

Die Art und Weise, wie Sie es getan haben, scheint mir die richtige zu sein, wenn Sie es überhaupt tun wollen. Denn die Erweiterung des Makros ist Also ähnlich wie Sie es erwarten würden[1]ich denke, es ist richtig, das Makro wie syntax () aussehen zu lassen, anstatt wie die normalerweise empfohlenen SCARY_UPPERCASE_MACROS(), die verwendet werden, um zu zeigen, dass dieser Code nicht der üblichen Syntax folgt und Sie ihn nur vorsichtig verwenden sollten.

[1] Der einzige Fehler ist die Unfähigkeit, Variablen zu deklarieren, was sowieso unwahrscheinlich ist und bei falscher Verwendung wahrscheinlich einen Fehler an der richtigen Stelle erzeugt, anstatt etwas Seltsames zu tun.

Darüber hinaus sind auch kleine Steigerungen der Lesbarkeit wichtig, so kann man sagen until ( Anstatt von while (! macht es wirklich einfacher, viele Schleifen zu lesen. Wenn die Endbedingung leichter als Ausnahmebedingung angesehen werden kann (unabhängig davon, ob dies der Fall ist oder nicht), erleichtert das Schreiben der Schleife in dieser Richtung das Lesen. Obwohl es also nur syntaktischer Zucker ist, denke ich, dass es Grund gibt, darüber nachzudenken.

Jedoch Ich glaube nicht, dass es das wert ist. Der Nutzen ist gering, da die meisten Programmierer ans Lesen gewöhnt sind if (! und die Kosten sind real: Jeder, der den Code liest, muss prüfen, ob es sich um ein Makro oder einen benutzerdefinierten Compiler handelt und ob er das tut, was er denkt. Und es kann Sie fälschlicherweise glauben machen, dass Sie Dinge tun können wie i=5 unless xxxx;. Solche kleinen Verbesserungen würden, wenn sie weit verbreitet wären, die Sprache fragmentieren, daher ist es oft am besten, die Dinge auf die übliche Weise zu tun und Verbesserungen langsam anzunehmen.

Es kann jedoch gut gemacht werden: Die Gesamtheit von boost und tr1, insbesondere das Zeug, das mit Templates gemacht wird, um wie Erweiterungen der Bibliothek auszusehen, beinhaltet das Erweitern von C++ auf verschiedene Arten, von denen viele nicht übernommen werden, da sie sich nicht lohnen es, aber viele davon haben eine geringe oder sehr weit verbreitete Akzeptanz, weil sie echte Verbesserungen gebracht haben.

Das erinnerte mich an etwas, das ich in jemandes Code gesehen habe:

#define R return;

Außerdem erhöhen Sie die Wartungskosten, indem Sie den Code schwer verständlich machen.

Ich schlage vor, es wäre besser, sie nicht zu verwenden.

Sie können sie nicht im Ruby-Stil verwenden

`printf("hello,world") unless(a>0);`

ist illegal.

Und für C-Programmierer wäre es schwieriger, den Code zu verstehen. In der Zwischenzeit könnte das zusätzliche Makro ein Problem sein.

Wenn Sie Makros definieren, ist es eine gute Praxis, sie wirklich hässlich aussehen zu lassen. Insbesondere sollten sie nur aus Großbuchstaben bestehen und eine Art Präfix haben. Dies liegt daran, dass es keine Namensräume und keine Koordination mit dem Typsystem oder der Überladungsauflösung von C++ gibt.

Also wenn dein Makro aufgerufen wurde BIGYAN_UNNECESSARY_MACRO_UNTIL dann wäre es nicht ganz “jenseits”.

Wenn Sie C++ mit neuen Schleifenkonstrukten erweitern möchten, sollten Sie Lambdas in C++0x untersuchen, wo Sie Folgendes zulassen könnten:

until([&] { return finished; }, [&] 
{
    // do stuff
});

Es ist nicht perfekt, aber es ist besser als Makros.

Ich denke nicht, dass Ihre Makros besonders schlecht sind, wenn sie nur in Ihrer eigenen Codebasis verwendet werden.
Dieser Artikel
könnte für dich interessant sein. Davon abgesehen sehe ich einige Nachteile in Ihren Makros, wenn wir sie in C++ verwenden.
Zum Beispiel können wir nicht schreiben als:

until (T* p = f(x)) ...
unless (T* p = f(x)) ...

andererseits können wir schreiben als:

while (T* p = f(x)) ...
if (T* p = f(x)) ...

Wie für unlesswenn wir es definieren als:

#define unless(x) if (x) {} else

dann können wir schreiben unless (T* p = f(x)) .... In diesem Fall können wir jedoch nicht hinzufügen else Klausel danach.

Gutes Beispiel für Syntaxzucker (IMHO):

struct Foo {
    void bar() {}
};
typedef std::vector<Foo*> FooVector;
typedef boost::ptr_vector<Foo> FooPtrVector;

FooVector v1;
for (FooVector::iterator it = v1.begin(); it != v1.end(); ++it)
    (*it)->bar(); // ugly

FooPtrVector v2;
for (FooPtrVector::iterator it = v2.begin(); it != v2.end(); ++it)
    it->bar(); // nice