Empfehlungsungswerte Tools bzgl Speichermanagement

Hi,
erstma thx für die Antworten

Du baust für Debug Zwecke einen Überlauf in dein Programm ein? Nettes Hobby was du da hast.
Eigentlich baut man für Debug Zwecke Abfragen ein, ob ein Überlauf stattgefunden hat.

Ähm ne so war das nicht gemeint Der Array war da um Zwischenergebnisse zu überprüfen, und den hab ich einfach mal auf eine feste Grenze gesetzt, und gar nicht daran gedacht, dass da ein Überlauf stattfinden könnte.

Aktuelle MSC haben zB eine Option für "Buffer Security Checks". Mit der "Verschachtelung in structs" hat das übrigens nichts zu tun.

Stimmt der MSC Compiler gibt nie einen Error aus, wenn man einen festen Array überläuft, Compiler Option /Ge hab ich drin, trotzdem führt weder Lesen noch Schreiben über das Array hinaus zu einem Fehler, d.h.

int a[2], b;
b=a[a];
a[2]=b;

Beides führt zu keiner Fehlermeldung beim Kompilieren, warum?

Borland? Naja, wenn schon umsteigen werden, dann wohl doch eher auf gcc - aber mal sehen.

Von Containerklassen hab ich in einem tut schon was gelesen, von Smart Pointern bis jetzt noch nicht - muss mich mal näher mit sowas beschäftigen, wenn ich wieder ein C++ Projekt anfange.

rabbit

groovemaster

RabbitsDad schrieb:

Stimmt der MSC Compiler gibt nie einen Error aus, wenn man einen festen Array überläuft

Hab mir mal das angeschaut. Offensichtlich wird da nur überprüft, ob die Rücksprungadresse überschrieben wird. Also was bei Hackerangriffen so beliebt ist. Eine generelle Buffer-Overrun Detektion hat man damit leider auch nicht.

RabbitsDad schrieb:

Compiler Option /Ge hab ich drin, trotzdem führt weder Lesen noch Schreiben über das Array hinaus zu einem Fehler

Seltsam, ich bekomm da zumindest ein

Run-Time Check Failure #2 - Stack around the variable 'foo' was corrupted.

RabbitsDad schrieb:

int a[2], b;
b=a[a];
a[2]=b;
Beides führt zu keiner Fehlermeldung beim Kompilieren, warum?

Bei mir schon. Liegt aber daran, dass der Code grundsätzlich falsch ist. Dass du keine Fehlermeldungen für Buffer-Overruns beim Kompilieren bekommst, sollte auch klar sein. Das ist kein MSC Problem, sondern liegt einfach daran, dass der Index ja erst zur Laufzeit feststeht. Und ich bin mir nicht sicher, ob es Compiler gibt, die zumindest Fehler bei Konstanten bringen, zB

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

btw:
"MSC Compiler" ist redundant - das hiesse ja praktisch Microsoft Compiler Compiler

Green_Ghost

RabbitsDad schrieb:

int a[2], b;
b=a[a];
a[2]=b;
Beides führt zu keiner Fehlermeldung beim Kompilieren, warum?

Borland? Naja, wenn schon umsteigen werden, dann wohl doch eher auf gcc - aber mal sehen.

Einen GCC kann ich dir als Compiler nur empfehlen.

audacia

RabbitsDad schrieb:

Borland? Naja, wenn schon umsteigen werden, dann wohl doch eher auf gcc - aber mal sehen.

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

Moritz

groovemaster

audacia schrieb:

- kostenlos

Ist aber kein Unterschied zu den beiden anderen erwähnten Compilern.

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)