vc6/7 und dev c++ probleme

hallo!
ich habe zur zeit ein paar probleme
1. vc6 meldet zur zeit immer einen fehler, wenn ich eine bestimmte include datei einbinden will, der compiler meldet einen internen fehler und zwar dass zu wenig heap reserviert werde. in der msdn nachgeschaut habe ich herausgefunden, dass das problem daran liegt,dass ich zuviele include dateien habe bzw. zu viele deklarationen. mit /Zm kann ich anscheinend die große des heaps passend machen, aber ich weiß nicht welchen wert ich nun /Zm geben soll. zum testen habe ich also einfach eine sehr hohen wert verwendet aber leider ohne erfolg und vc7 funktioniert alles ohne probleme.

2. unter vc6 funktioniert dieser code

if(!pRend->GetShader() || !pRend->GetShader()->GetPass(0))
	{
		//Standard Material verwenden
		pShr = ShaderManager::GetSingleton().GetBlankShader();
	}
	else
	{
		pShr = pRend->GetShader();
	}

der kompiler springt wenn GetShader NULL zurückliefert sofort in die else anweisung, aber vc7 überprüft noch den rückgabe wert von GetPass, weil aber das objekt nicht existiert kommt klarerweise bei GetPass eine speicherverletzung, welcher kompiler hat jetzt "recht" od. ist dieses verhalten bei vc7 viell. nur im debug modus?!?

3. ich wollte jetzt einmal einen anderen compiler versuchen und hab mir die c++ ide von bleedsheet (dev c++) heruntergeladen. die ide und compiler etc. wirken auch sehr ansprechend, was mir außerdem gefallen hat, ist das mögliche importieren von vc, aber unterstützt die ide wirklich nur einfache projekte und keine workspaces? weil ich habe keine option gefunden mit der man einen solchen machen könnte?!

danke schon mal!
stefan

groovemaster

stefan-guest schrieb:

der kompiler springt wenn GetShader NULL zurückliefert sofort in die else anweisung, aber vc7 überprüft noch den rückgabe wert von GetPass

Bist du dir wirklich sicher, dass deine Beobachtungen stimmen? Kann ich mir irgendwie nicht vorstellen. Lass dir doch mal den Rückgabewert von pRend->GetShader() ausgeben.

Hi

zu 2. wenn pRend->GetShader() NULL zurückliefern könnte, sollte der 2te teil der oder anweisung in eine seperate if anweisung. du kannst nicht sicher sein, in welcher reihenfolge der compiler das würklich abarbeitet.

Das verhalten von vc6 kann ich bestätigen. liefert eine Teilbedingung einen wert zurück, der die ganze bedingung nicht mehr erfüllbar macht, wird die verarbeitung abgebrochen und ggf in den else zweig gesprungen.

wenn du die möglichkeit hast mit vc7 zu arbeiten dann tu das. vc6 hat noch ein paar ganz andere übele bugs. z.B. geht das nicht obwohl es gehen sollte.

class test 
{
   public:
     static const int MAXCOUNT = 13; 
};

und wenn jetzt jemand sagt ich solle ein #define nehmen. grrr ich hasse defines für sowas. enum zur lösung geht noch. ist aber auch ne krücke die nicht sauber implementiert ist.

class Test
{
  public:
    enum {A1,A2,A3};
};

...

int i3 = Test::A1; // geht auch wobei das warscheinlich die richtige ist.
int i4 = (Test::A1); // geht auch
int i1 = Test.A1; // geht wieso auch immer :confused: 
int i2 = (Test.A1); // teht nicht er will vor dem . eine ) haben. :confused:

gruss

danke erstmal.
mein problem ist, dass ich vc7 nur in der schule habe und zuhause nicht, weil ich da "nur" win98 (jaja *ggg*) und ich da das visual studio 7 nicht installieren kann...

und die anderen 2 probleme (1./3.) ?

groovemaster

Termite_ schrieb:

zu 2. wenn pRend->GetShader() NULL zurückliefern könnte, sollte der 2te teil der oder anweisung in eine seperate if anweisung. du kannst nicht sicher sein, in welcher reihenfolge der compiler das würklich abarbeitet.

Doch, kannst du. Hier liegt eine left-to-right evaluation vor.

Termite_ schrieb:

Das verhalten von vc6 kann ich bestätigen. liefert eine Teilbedingung einen wert zurück, der die ganze bedingung nicht mehr erfüllbar macht, wird die verarbeitung abgebrochen

Das wird wohl jeder Compiler so machen. Da bei einer logischen Oder-Verknüpfung aber alle Ausdrücke getestet werden müssen, wenn auf false geprüft wird, kann ich mir nicht vorstellen, dass ein Compiler bereits nach einem Ausdruck in den else Zweig springt, auch der MSC 6 nicht. Und sollte dem tatsächlich so sein, würde ich mir auf jeden Fall einen anderen Compiler besorgen.

Termite_ schrieb:

vc6 hat noch ein paar ganz andere übele bugs. z.B. geht das nicht obwohl es gehen sollte.
class test 
{
   public:
     static const int MAXCOUNT = 13; 
};

Hast du dir mal angeschaut wann der Compiler rauskam und wann der aktuelle C++ Standard verabschiedet wurde.

@stefan-guest
Wenn du einen guten, relativ Standard konformen Compiler haben willst, dann benutz den MSC 7.1, den findest du auf der Microsoft Homepage und ist nochmal ein ganzes Stück besser als Version 7.0.