Warum verwenden numerische STL-Algorithmen 'op' statt 'op ='?

Dies ist im Standard definiert ...

Der Standard wird in + definiert, nicht in += :

  

26.7.2 Akkumulieren [accumulate]

%Vor%      

Effekte: Berechnet das Ergebnis, indem der Akkumulator acc mit dem Anfangswert init initialisiert und anschließend mit acc = acc + *i oder cc = binary_op(acc, *i) für jeden Iterator i im Bereich geändert wird    [first,last) in der Reihenfolge.

Gleiches gilt für andere numerische Algorithmen.

... und der Standard basiert auf STL ...

Aber das ist der Grund, warum sie heutzutage so implementiert werden . Um jedoch etwas über den ursprünglichen Grund zu erfahren, muss man weiter ins Kaninchenloch gehen :

  

Anforderungen an Typen

     

Für die erste Version, die zwei Argumente akzeptiert:

     

• InputIterator ist ein Modell des Eingabe-Iterators.
  
• T ist ein Modell von Assignable.
  
• Wenn x ein Objekt vom Typ T ist und y ein Objekt von InputIterator 's value type ist, dann ist x + y definiert.
  
• Der Rückgabetyp von x + y ist in T konvertierbar.
  

... und die AWL wurde erstellt von ...?

Also, warum ist das? Fragen wir Alexander Stepanov, den Kopf hinter STL:

  

[A] Benutzer hat vor zwei Tagen eine [Frage] zu StackOverflow gestellt   die Implementierung und Formulierung von numerischen Algorithmen wie    accumulate oder inner_product , die in + definiert sind   anstelle von += (Abschnitt 26.7 in ISO C ++ 11).

     

Ich habe versucht, eine Begründung für die Entscheidung zu finden, aber auch die   Die Version auf der SGI-Seite erwähnt diesbezüglich nichts   besondere Wahl des Betreibers.

     

War die Wahl des Operators (a = a + b statt a + = b) nur   basierend auf Ihren persönlichen Vorlieben, wie einige Kommentare annehmen? War a + b   die natürlichere Art, die Operation damals zu schreiben? Oder war es   einfach eine Frage der Symmetrie zwischen a = a + b und a = bin_op (a, b)?

     

- [Zeta]

Nun, bevor Sie seine Antwort gelesen haben, denken Sie daran, dass er vor ungefähr 30 Jahren begann, eine generische Bibliothek zu schreiben, und sein und Meng Lees anfängliches Dokument Die Standard-Vorlagenbibliothek wird im Oktober dieses Jahres ihr zwanzigjähriges Bestehen feiern. Ohne weitere Umschweife stelle ich seine Antwort vor:

  

Ich vermute, dass es eine Frage der Symmetrie zwischen a = a + b und a = bin_op (a, b) war, aber ich kann mich nicht erinnern. Ich hätte ein Grundlagendokument schreiben sollen, das alle Überlegungen zwischen verschiedenen Designwahlen in STL aufführt, aber das habe ich nicht getan. Entschuldigung.

^{(Wenn Stepanov das zufällig liest: Danke nochmal für Ihre Antwort!)}

Ich persönlich glaube, dass die Inspiration durch Common Lisps reduce ein weiterer Faktor war, aber das ist nur Spekulation.

Was kann man daraus lernen?

Manchmal basiert die Entscheidung in einem Standard auf persönlicher Vorliebe und Eleganz. Zum Beispiel, wenn Stroustrup die STL geschrieben hätte, hätte er "die Verwendung von a + = b als direkter Ausdruck der Absicht und in der Regel schneller als a = a + b" vorgezogen. Allerdings muss ich zugeben, dass die Symmetrie zwischen a = a + b und a = bin_op (a, b) ihre eigene Schönheit hat.

Das heißt, diese a+=b und a=a+b Kontroverse wird Herausforderungen fördern:

  

Dieses Problem wird sehr wichtig werden, wenn wir Standardkonzepte definieren, und ich weiß nicht, wie es gelöst wird. [Stroustrup; auch danke an ihn für die Beantwortung meiner Frage!]

Das ist alles, ich hoffe, Sie haben die Fahrt durch ein bisschen C ++ - Geschichte genossen.

Es könnte effizienter sein und wäre deutlich weniger ausführlich.

Der übliche Grund dafür ist, die Anforderungen an den zugrunde liegenden Typ zu minimieren. Wenn Sie += verwendet haben, müsste der zugrunde liegende Typ += unterstützen. Für etwas wie int , das ist trivial und bereits vorhanden, aber für eine Klasse, die Sie definieren, wäre es durchaus möglich, + und = zu definieren, aber nicht die Verbindung += (in diesem Fall Code, der += verwendet würde offensichtlich scheitern).

Meiner Meinung nach liegt der Hauptgrund darin, dass Sie das Standardfunktionsobjekt std::plus verwenden und das gleiche Ergebnis wie bei operator + genauso erhalten können wie operator < und das Standardfunktionsobjekt std::less in Sortieralgorithmen wie%. co_de%.

Es gibt viele Gründe für die Verwendung von + anstelle von + =.

A. Weil es der richtige Weg ist. Accumulate is fold , ein Funktor (eine Funktion, die Funktionen Funktionen zuordnet), die auf + wirkt, nicht + =. Warum + statt + =? Weil + = keine mathematische Funktion ist.

B. Es ist effizienter (auf modernen Compilern, auf allen primitiven Typen und gut entworfenen Objekten). + = könnte für Compiler vor 30 Jahren schneller sein, aber + ist jetzt schneller, es sei denn, was du anhäufst, ist ein monströses Objekt mit zu viel OO. Die Analyse der Objektlebensdauer ist einfacher für Const-Objekte als für Referenzen.

C. Es ist klarer. Dieser Grund unterscheidet sich nicht wesentlich von (A). + ist klarer als + =. Klarheit übertrumpft Ausführlichkeit.

Die Wahrheit ist, denke ich, Wiederverwendung. Der Rest der STL verwendet binäre Operatoren , während += eine Aktion ist. Also gibt es plus , multiplies , usw., aber keine add_action (sagen wir). Operatoren und Aktionen sind vollkommen symmetrisch, aber wenn Sie mehr als 90 Algorithmen implementieren, müssen Sie irgendwann nicht mehr neue Konzepte hinzufügen und es versenden.

Alex hat gesagt, dass er nie beabsichtigt hat, dass seine STL das Ende aller STL-Entwicklung sein wird, besonders bei der STL. da die standardisierte Version nur einen Bruchteil dessen enthält, was er ursprünglich vorgeschlagen hat. Dies ist eine offensichtliche Erweiterung.