Empfehlungsungswerte Tools bzgl Speichermanagement

Ponto

valgrind ist das beste Tool, das ich in diesem Bereich kenne. Dieses läuft zur Zeit ausschließlich unter x86 Linux. Mitte des Jahres soll es auch auch auf AMD64 Linux laufen.

BoundsChecker ist besser.

Ponto

Zu BoundsChecker finde ich im WWW nur Marketinggeschwätz. Gibt es eine Seite, die genau angibt, was dieses Werkzeug überprüft, und wie es das macht?

groovemaster schrieb:

int a[10];
a[10] = bla; // hier koennte man theoretisch einen Compiler Fehler bringen

meines wissens ist a ein pointer auf das erste element des arrays. wenn man nun schreibt 'a[10]' dann nimmt der compiler die adresse, welche in a gespeichert ist, zählt 10*sizeof(int) dazu, und greift auf das element an dieser stelle zu. das ist meiner ansicht nach absolut zulässig, wenn auch unangenehm (der speicher könnte ja schon belegt, und durch einen aufruf wie a[10] = bla; überschrieben werden). wie auch immer sehe ich keinen grund, warum der compiler an so einer stelle einen fehler ausgeben sollte. der programmierer WOLLTE es ja so.

picocat

audacia schrieb:

Mir ist, als hätten viele hier Vorurteile gegen Borland-Compiler. Warum? C++Builder kann ich halbwegs verstehen (weil er eine Anfängerfalle ist), aber hier geht es um den Compiler! Du mußt ja nicht den Builder, sondern nur den Compiler verwenden, und der ist
- schneller als MSVC und GCC (in Compilezeit)
- von MSVC und GCC am performantesten in der Codeerzeugung (jedenfalls bei meinen Programmen)
- kostenlos

ok, dann sage ich jetzt mal, dass bei mir der
- gcc in der compilezeit schneller ist als der bcc
- gcc auch sehr performanten code erzeugt
- gcc ebenfalls kostenlos ist.

weiterhin
- gibt der bcc bei mit verbugte versionen von laufenden programmen aus (sprich: mit gcc kompiliert -> läuft; mit bcc kompiliert -> läuft nicht)
- baut bcc irgendwie grafik-bugs in der konsole ein, wo es todsicher ist, dass sie nicht auftreten dürften.

außerdem hat doch jeder seinen compiler, den er gerne hat und dem er vertraut, nicht? aber das ganze soll ja nicht in eine compilerdiskussion ausarten

Ringding

bcc ist der einzige Compiler, bei dem mir jemals ein Compilerbug aufgefallen ist (falscher Code). Und nicht nur einer. Die sind auch nicht so exotisch, dass sie eh nie auftreten. Ich ärgere mich regelmäßig damit herum.

Zur Speicher- und sonstiger Ressourcenverwaltung (im Zusammenhang mit Exceptions v.a.) kann ich nur ScopeGuard empfehlen.

audacia

Ringding schrieb:

bcc ist der einzige Compiler, bei dem mir jemals ein Compilerbug aufgefallen ist (falscher Code). Und nicht nur einer. Die sind auch nicht so exotisch, dass sie eh nie auftreten. Ich ärgere mich regelmäßig damit herum.

LOL, schon mal MSVC gesehen?
Außerdem, welche Version? Und worum geht es genau?

otze

audacia schrieb:

Ringding schrieb:

bcc ist der einzige Compiler, bei dem mir jemals ein Compilerbug aufgefallen ist (falscher Code). Und nicht nur einer. Die sind auch nicht so exotisch, dass sie eh nie auftreten. Ich ärgere mich regelmäßig damit herum.

LOL, schon mal MSVC gesehen?
Außerdem, welche Version? Und worum geht es genau?

deer neueste msvc hat kaum bugs.

groovemaster

savage_dog schrieb:

meines wissens ist a ein pointer auf das erste element des arrays

Nein, a ist kein Zeiger. a ist und bleibt ein Array.

savage_dog schrieb:

wenn man nun schreibt 'a[10]' dann nimmt der compiler die adresse, welche in a gespeichert ist, zählt 10*sizeof(int) dazu, und greift auf das element an dieser stelle zu. das ist meiner ansicht nach absolut zulässig

Erstens ist in a keine Adresse gespeichert, und zweitens sind nur Elementzugriffe von a[0] bis a[9] zulässig. Alles darüber hinaus erzeugt undefiniertes Verhalten.

savage_dog schrieb:

wie auch immer sehe ich keinen grund, warum der compiler an so einer stelle einen fehler ausgeben sollte

Den sehe ich schon. Der Typ ist zur compile-time bekannt (int[10]), und der Index ist eine Konstante (10). Ob es jetzt ein Fehler sein muss oder eine Warnung, darüber kann man streiten.

picocat

groovemaster schrieb:

zweitens sind nur Elementzugriffe von a[0] bis a[9] zulässig. Alles darüber hinaus erzeugt undefiniertes Verhalten.

siehe signatur...
im schlimmsten falle kann das ja zu systemabsturz führen.

aber meiner meinung nach macht der compiler aus

a[10]

das hier:

*(a+10)