Nem, nem lehet a fordítóba beletenni határellenőrzést (eleve, ha lehetne, akkor már rég beleteték volna...) Mert a tömb csak egy cím, a mérete nem utazik vele, semmi nem kényszeríti ki, hogy jelen kell lennie egy változóban és a compilernek tudnia kell, hogy melyik az.
Bele lehetne tákolni talán egy szabályt, hogy mindig passzolgatjuk a méretet egy mintának megfelelően, amit lehet statikusan ellenőrizni programmal, hogy be van-e tarva, csak akkor már pont ott fogunk tartani mintha eleve egy memóriát biztosan kezelő nyelvet választottunk volna, és főleg fontos, hogy a meglévő millió kódbázisra nem lehet utólag rákényszeríteni ilyen szabályokat.
A memóriabiztos nyelvekben ezzel szemben minden pointerhez tudja a fordító a méretét és többnyire a típusát is. (És ezért már nem is hívja pointernek, de attól a referencia az az, vagy legalábbis olyasmi.)
>Persze ha [] helyett a modern C++ iterációs módszereit használjuk a kódunk gyors lesz, még a kód is olvashatóbb lesz, de más logikával kell dolgozni.
Nem lesz gyors, az index szerint memóriában ugrálva iterálásnál nem találtak fel gyorsabbat és nem is lehet (kivéve a párhuzamosságot, de az egy másik végtelen problémakör és csak nagyon nagy méreteknél válik hatékonnyá). A méretellenőrzés overheadje viszont a legtöbb esetben elhanyagolható, mert a compiler felismeri a mintákat, és valójában nem ellenőriz minden iterációban például, mert tudja, hogy a határ fix értékű úgyis. De ha mégis kell ellenőrizni, akkor az ellenőrzés tök olcsó, mert a méret a pointerrel együtt utazik, egyazon cache line-ban van, a betöltése nem okoz szinte semmi plusz költséget. Vagy ha egymás után sokszor kell, akkor a compiler beteszi a határt egy regiszterbe és egy másik utasítással átlapoló módon futtathatja a processzor az ellenőrzést kb fél CPU órajel alatt.
Az indexeléssel szemben az objektumokon iteráló dolgokkal könnyen előfordulhat, hogy nem egy cache sorban vannak, ugrálni kell a RAM-ban olvasáskor és akár csak emaitt többszörös lassúság lehet a vége funkcionálisan ekvivalens kódnak.