Wenn ich den Debugger anwerfe ist die Variable direkt nach dem Konstruktor false. Die anderen Variablen die ich auf True gesetzt habe bleiben auf true.

Der Konstruktor:

Application::Application()
{
	uimanager	= new TUIManager();
	programPath	= NULL;
	kamera		= new Kamera();
	karusell	= new Karusell(this);

	f_FPS		= true;
	f_Smooth	= true;
	f_Wire		= false;
	f_ZTest		= true;
	f_PProj		= false;
	f_Licht		= true;
	f_Ambient	= true;
	f_2Seitig	= false;
	f_LocalV	= false;
	f_Texturing 	= true;         //<---- Diese hier
	f_Light[0]	= true;
	f_Light[1]	= false;
	f_Light[2]	= false;
	f_Light[3]	= false;
	f_Light[4]	= false;
	f_Light[5]	= false;
	f_Light[6]	= false;
};

Application ist eine globale Variable im Programm, es wird also nicht impliziet der Konstruktor aufgerufen.

Im Debugger kann ich beobachten dass:

- Beim start der Anwendung (wenn der Debugger beim eintritt in main anhält) ist Application komplett genullt, d.h. alle Member sind false. (so wie sich das gehört)
- Mach ich einen schritt weiter, haben alle variablen den korrekten Wert außer f_Texturing.

Was läuft hier verkehrt? Ich hab auch schon mal mein Projekt gecleant und frisch erstellt. (Eclipse3.1 + CDT3.0 + MinGW)

Ich denke es liegt am Compiler. Hab gerade folgendes probiert:

- Eine andere neue Member Variable test, direkt hinter Texturing initialisiert. -> Keine Änderung. Test wird korrekt initialisiert.

- Texturing ans ende des Konstruktors verschoben -> Initialisierung geht

- Variable wieder zurückverschoben -> Fehler ist wieder da.

Scheint also ein Fehler im Compiler zu sein.

Ach ich ahne es schon: C/C++ is nunmal nicht typsicher. Wenn C/C++ das wäre, währe die Sprache richtig gut - und unsere Betriebssysteme um einiges Sicherer (Buffer-Overflows ade) *träum*

Danke

Ach ich ahne es schon: C/C++ is nunmal nicht typsicher.

Das hat mit Typsicherheit nichts zu tun.

Wenn C/C++ das wäre, währe die Sprache richtig gut - und unsere Betriebssysteme um einiges Sicherer (Buffer-Overflows ade) *träum*

Man kann C++ so benutzen, dass so etwas nicht passieren kann. Es liegt eigentlich nur an dir.

Wenn stillschweigend Arraygrenzen überschritten werden ist das Typsicher?

Wenn du ohne Gurt mit dem Auto fährst, ist das Safer Sex?
Das hat mit Typsicherheit nichts zu tun.

Anfänger06 schrieb:

Aber wieso meckert da der Compiler net? (GCC)

compiler(r) schrieb:

Aber sowas könnte doch zur Compilezeit schon entdeckt werden.

Man könnte argumentieren, dass die primäre Aufgabe eines Compilers die ist, das Programm zu übersetzen, nicht Fehler darin zu entdecken. Es gibt durchaus Erweiterungen bei einigen Compilern, bei denen die Abwesenheit dieser Prüfung bewusst ausgenutzt wird. Die WinAPI z.B. ist voll von Strukturen, die am Ende ein Array mit einem Element haben, das für Daten variabler Länge benutzt wird.

Aber sowas könnte doch zur Compilezeit schon entdeckt werden.

es könnte, aber das ist in c/c++ nicht wünschenswert. viele c-programmiere machen zb folgendes:

struct node
{
  struct node *next;
  unsigned size;
  char data[1];
} *n;

n=malloc(sizeof(struct node)-1+100);
n->size=100;

da wäre eine überlaufprüfung ärgerlich.

C hat mit funktionen wie strcpy() das gesamte sicherheitskonzept von MS unterhöhlt. Bufferoverflows sind damit vorprogrammiert. Unser Prof. hat uns in der Uni mal aufgezeigt wie sowas zu stande kommt. Und das läßt vermuten, dass solange Windows (und somit auch Unix das auf der selben Sprache basiert) nicht komplett neu geschrieben wird, Bufferoverfloas, niemals vermieden werden können. Die Sicherheit fängt da bei der Sprache an. Mit einer Typsicheren sprache die overflows von arrays einfach nicht erlaubt und entsprechend streng ist macht zwar dem eingefleischten C-Programmierer die Arbeit weniger spass, aber dem Hacker am anderen Ende gehts genauso.

das mit dem "bufferoverflows koennen mit so einer sprache niemals vermieden werden" ist unsinn. man muss beim programmieren nur wissen, was man tut. etwa das array in eine klasse stecken und bei jedem zugriff die grenzen ueberpruefen oder aehnliches.