Wann man Beschränkungen verwenden sollte und wann nicht

Ich habe ein allgemeines Verständnis von restrict aber ich hoffe, einige Feinheiten zu klären. Ich habe eine Funktion, die eine nullterminierte Zeichenfolge aus einem Puffer liest und eine URL-codierte Version in einen anderen Puffer schreibt. Die Funktion hat diese Signatur (derzeit ohne restrict):

char const *StringUrlEncode(char const *unencoded, 
                            char *encoded,
                            char *encodedEnd);

unencoded ist meine nullterminierte Quellzeichenfolge. Der Zielpuffer wird dargestellt durch encoded und encodedEndwo encoded weist auf den ersten hin char im Puffer u encodedEnd zeigt auf das erste Zeichen nach der Puffer, dh die Funktion schreibt chars bis zu aber nicht inklusive der Ort, auf den gezeigt wird encodedEnd – Das ist Ihre Basis begin/end Iteratorpaar, wenn Sie mit C++-STL-Konventionen vertraut sind.

Wenn ich hinzufüge restrict zu dieser Funktion, sollte sie nur auf die ersten beiden Parameter angewendet werden:

char const *StringUrlEncode(char const *restrict unencoded, 
                            char *restrict encoded,
                            char *encodedEnd);

oder gibt es einen Vorteil, den ich nicht verstehe, wenn ich ihn allen drei Parametern hinzufüge?

Ich kann sehen, dass die Eingabe- und Ausgabepuffer erstellt werden restrict hilft dem Compiler zu wissen, dass sie sich nicht überschneiden. Aber seit dem letzten Parameter encodedEndwird nur verwendet, um das Ende des Ausgabepuffers zu markieren, denke ich restrict würde dem Compiler hier nicht wirklich helfen (obwohl ich annehme, dass es nicht schaden würde, außer unnötiges Rauschen zur Funktionsdeklaration hinzuzufügen).

Versuchen Sie Mike Actons Artikel hier (alter Link). Restrict ist beängstigend, sowohl wegen der Auswirkungen auf die Leistung, wenn es nicht verwendet wird, als auch wegen der Folgen einer falschen Verwendung.

In Ihrem Fall klingt es so, als könnten Sie alle drei Zeiger sicher einschränken, da keiner denselben Speicherbereich aliasiert. Es wird jedoch wenig bis gar keinen Leistungsvorteil geben, wenn Sie es für den dritten Zeiger verwenden.

In diesem speziellen Fall spielt es keine Rolle, ob kodiertEnde einschränken oder nicht; Sie haben dem Compiler versprochen, dass niemand einen Alias ​​verwendet unverschlüsselt und codiertsodass sich die Lese- und Schreibvorgänge nicht gegenseitig stören.

Der eigentliche Grund, warum die Beschränkung in diesem Fall wichtig ist, ist, dass der Compiler ohne sie nicht wissen kann, ob er durchschreibt codiert wirkt sich nicht auf das Durchlesen aus unverschlüsselt. Zum Beispiel, wenn

encoded == unencoded+1

dann jeder anschreiben codiert würde sich auf jeden nachfolgenden Lesevorgang auswirken unverschlüsselt, sodass der Compiler das Laden nicht planen kann, bis der Schreibvorgang abgeschlossen ist. Einschränken verspricht dem Compiler, dass die beiden Zeiger nicht denselben Speicher betreffen, sodass er Ladevorgänge weit genug im Voraus planen kann, um Pipeline-Stalls zu vermeiden.

Ich denke du hast recht, dass es nicht schaden würde. Ihr Schleifenzeiger (nennen Sie ihn p) entspricht encodedEnd am Ende der Schleife. Aber nach der Schleife muss auf nichts zugegriffen werden (entweder von p oder encodedEnd), also sollte das kein Problem sein. Ich glaube auch nicht, dass es helfen wird, weil nichts jemals von encodedEnd geschrieben oder gelesen wird, also gibt es nichts zu optimieren.

Aber ich stimme Ihnen zu, dass die ersten beiden Beschränkungen wirklich helfen sollten.