Um ehrlich zu sein, ich kenne die Antwort auf Ihre Frage nach keiner Spezifikation. Das Problem, das ich bei Ihrem Ansatz sehe, ist jedoch, dass Sie Ihre Implementierung an Implementierungsdetails in der Bibliothek binden, die Sie verwenden.
Wenn Sie Ihre Implementierung an die Schnittstellen binden, die von den von Ihnen verwendeten Bibliotheken verfügbar gemacht werden, ist es weniger wahrscheinlich, dass der verwendete Code durchbrochen wird, wenn sich die Implementierung dieser Bibliotheken ändert. Dies ist in diesem speziellen Fall möglicherweise nicht sehr relevant, da sich das Speicherlayout eines Arrays in naher Zukunft nicht ändern wird, aber wenn dies der Fall ist, könnte der Entwickler der Laufzeitbibliothek auch die Implementierung der Iterationsfunktionen entsprechend ändern, wenn dies der Fall ist Wenn Sie die offen gelegten Funktionen verwenden, sollte Ihr Code weiterhin wie erwartet funktionieren. Wenn Ihr Code jedoch von Implementierungsdetails der Bibliotheken abhängt, müssen Sie möglicherweise alle Ihre Anwendungsfälle durchgehen und sie entsprechend ändern.
EDIT:
Es tut mir leid, ich glaube nicht, dass ich mich ausgedrückt sehr klar; Ich spreche nicht über Ihren Code, sondern über Ihren Ansatz. Einer der Vorteile der Kapselung besteht darin, dass Code-Komponenten geschrieben werden können, die ihre jeweiligen Aufgaben hervorragend erfüllen, und dann Anwendungen, indem die von mehreren Code-Komponenten bereitgestellten Funktionen kombiniert werden. Mehrere Abstraktionsebenen ermöglichen es uns, die oberen Ebenen zu gestalten, ohne uns um die kleinen Details in den unteren Ebenen kümmern zu müssen.
Wenn die verschiedenen Komponenten, aus denen die gesamte Anwendung besteht, voneinander isoliert sind, können die Komponenten problemlos aktualisiert werden, ohne die Kompatibilität zu beeinträchtigen, solange die Komponenten ihre minimale Schnittstelle beibehalten und sich ihre Implementierung korrekt verhält. Wenn die verschiedenen Komponenten voneinander abhängig gemacht werden, werden Upgrades viel schwieriger, da Änderungen unter Berücksichtigung der internen Strukturen der beteiligten Komponenten vorgenommen werden müssen. Eine scheinbar harmlose Modifikation in einer Komponente auf niedrigerer Ebene (wie das Einfügen einer neuen Elementvariablen zwischen zwei ältere) kann völlig unvorhergesehene Konsequenzen in einem vollständig nicht verwandten Codeabschnitt haben, der "clever" auf der internen Struktur der Komponente beruht. In der Programmierkunst können Sie die Ressourcen verwenden, die Sie finden, um Ihre Eingaben in Ihre Ausgaben zu verwandeln, aber das bedeutet nicht, dass alle Möglichkeiten die gleichen Auswirkungen haben. Wenn Sie sich Sorgen über die Ausführungszeit machen und der Aufwand für den Aufruf einer Funktion inakzeptabel ist, können Sie zusätzliche Zyklen erzielen, indem Sie einen objektorientierten Ansatz überspringen und Ihr Array nach Index iterieren. Wenn die Ausführungszeit nicht so kritisch ist, dass ein Aufruf einer öffentlichen Methode an einer Schnittstelle möglich ist, erhalten Sie kleinere Upgrade-Albträume.
Die Standardcontainerbereichskonstruktoren sind Vorlagen, keine Konvertierung ist beteiligt. – user657267
Beiseite: '& Array [0] + 1' ist legal. So ist das noch einfachere "Array + 1". – Hurkyl
Das ist eine gute Frage. Ich bin * gar nicht * sicher, ob '& array [n]' legal ist (im Gegensatz zu 'array + n' oder' & array [0] + n', die legal sind). Es ist unabhängig von Iteratoren Ich denke: Die Frage ist nur, ob der Ausdruck & Array [n] 'legal ist. -> Und hier ist die Q + A: http://stackoverflow.com/questions/988158/take-the-address-of-a-one-past-the-end-array-element-via-subscrip-legal-by -die –