[C++] Applicatie: VisualC++ 6 --> Visual Studio.NET troubles

[MaxxMark]

Ik zit sinds september vorig jaar aan een wat groter projectje te coden en heb dat tot nu toe gedaan met VisualC++ 6.0.

(Coden gaat me altijd wel ok af, alleen (goed) met een debugger omgaan en hem goed begrijpen (vooral die van visual studio) gaat/ging me nooit goed af, iemand goeie hints/tips waar ik meer duidelijke info/howto's kan vinden over de debugger van vstudio? vind de msdn niet echt 'duidelijk')

Dat is altijd goed gegaan tot ik een threadje op tweakers zag over VisualStudio.NET en zijn features, en dacht, hey coole features die het leven een stuk makkelijker kunnen maken!

Dus ik vrolijk visual studio geinstalleerd en inderdaad hele coole features in die ik graag wil gebruiken.

Het project openen in vs.net ging prima en na de settings goed gezet te hebben alle includes op de goeie plaats te zetten was ik ready to go.. dacht ik....

De applicatie begint in debug mode al vaak te zeuren om dingen waar in visual c++ 6.0 nooit over geklaagt werd.

met in output window:
HEAP[application.exe]: Invalid Address specified to RtlFreeHeap( 00E70000, 00E88D58 )
Unhandled exception at 0x77f767cd in application.exe: User breakpoint.

Opzich kon ik die nog wel ignoren en dan ging de applicatie gewoon verder, maar netjes is anders

On exit een gelijkwaardig probleem.

Negeer ik het alles en compile ik em in release mode en voer ik em dan uit, dan doet ie et prima totdat ik exit. Dan geeft ie een vette crash error gevolgt door het bekende "send"en"dont send" window. Waarna ie nog een error geeft met:
"Instruction at 0x10012ab7 referenced by memory at "0x00ea8608" the memory could not be 'read' klik ok to terminate."

Als ik in debug mode break, dan gooit ie me naar:
crtexe.c, en volgens de source is dat dus:
/***
*crtexe.c - Initialization for console EXE using CRT DLL
...

Het lijkt mij niet dat daar een foutje inzit natuurlijk.. Maar waar ik het wel moet zoeken geen idee.

Sowiso vind ik het nog altijd een beetje wazig dat een in VC++6 gemaakt project het in VS.NET niet goed doet.

Iemand enige hints/tips/suggesties ?


(Ik las nog in een andere thread dat et misschien kon liggen aan optimalisatie's, maar het lijkt me dat dat alleen van toepassing is als het alleen in release mode fout gaat (waar wel optimalisaties gedaan worden))

[edit]
ik heb toch wat gekut met optimalisaties, leverde niet veel op.. alleen een extra Assertion fault

[ Voor 8% gewijzigd door MaxxMark op 10-01-2003 16:44 ]

[Verwijderd]

Ik heb t idee dat je hier en daar wat pointers verziekt? Die errors geeft ie niet voor niets natuurlijk dat ie doorgaat houd niet in dat het een 'zeur' melding is.

[MaxxMark]

Natuurlijk is het geen zeur melding, mijn mood was gewoon naar een dermate nivo gezakt dat ik het niet meer zag zitten toen ik de post maakte. Loop al een hele tijd met het probleem te kutten.

Kans is inderdaad groot dat het een pointer is waar ie op fout loopt. Dat was ook een vermoede bij mij. Maar zoals ik zei, kweet bar weinig van de debugger, en zou dus geen idee hebben hoe ik weet waar het ongeveer zit. (ik weet dat je var's kan watchen enzo, maar hoe enzo...)

Maar het gaat mij er ook een beetje om dat het in vc++6.0 wel goed gaat (nou ja goed, waarschijnlijk gaat het daar ook niet goed, maar daar werd het 'geaccepteerd')

[.oisyn]

misschien heb je hier niets aan, misschien ook wel, moet je maar even kijken

Heb je je project compleet gerebuild? En link je met de nieuwe runtimes (dus niet de oude van vs6)? En gebruik je nog aditionele libs die met vs6 zijn gebouwd? Als je daar de source van hebt, rebuild ze dan eens met vs.net

[MaxxMark]

Ik heb alles eerst gerebuild ja, dat was wat in eerste instantie de meeste problemen oploste
Verder gebruik ik zover ik weet geen libs die met vs6 gebuild zijn.

Dus helaas, maar thnx voor het advies

[Verwijderd]

Eerst even uitsluiten of het probleem in je eigen code zit: dus even door de VC6 codewizard heenklikken en een 'kaal' project even in .NET compileren en kijken wat er gebeurd.

[MaxxMark]

Heb even wat zitten schuiven met code..
Duidelijk wat pointers gedelete en bij een aantal classes expliciet de destructor aangeroepen. En nu lijkt het te werken

Nu hopen dat het blijft werken, want ik heb al een keer gehad dat het in visual studio (met f5 of ctrl-f5) wel werkt , en als ik em release en hem "los" run dat ie opeens weer met een error komt

Maargoed het werkt for now! dus ik ben blij
Kan ik eindelijk rustig met visualstudio.net gaan werken

(nu nog een beetje duidelijke how to/help ofzo vinden over de debugger)

[ Voor 3% gewijzigd door MaxxMark op 10-01-2003 20:45 ]

[MSalters]

't Klint also je erg veel loopt te hacken. Expliciet de dtor aanroepen is bijvoorbeeld onwaarschijnlijk zeldzaam. Ik roep zelfs delete nauwelijks meer aan. Zelf proberen al je delete's en dtors op de goede plek te krijgen is een ramp; RAII aanhouden is extreem veel effectiever.

[curry684]

Verwijderd schreef op 10 January 2003 @ 16:52:
Ik heb t idee dat je hier en daar wat pointers verziekt? Die errors geeft ie niet voor niets natuurlijk dat ie doorgaat houd niet in dat het een 'zeur' melding is.

VS.net checkt idd op veel meer 'zeurderige dingen' waardoor een upgrade van VS 6 -> 7 je een hoop trubbels op kan leveren. Good point is dat het wel allemaal nuttige zeurderige dingen zijn die je anders wellicht spontane crashes op zouden kunnen leveren...

[MaxxMark]

't Klint also je erg veel loopt te hacken. Expliciet de dtor aanroepen is bijvoorbeeld onwaarschijnlijk zeldzaam. Ik roep zelfs delete nauwelijks meer aan. Zelf proberen al je delete's en dtors op de goede plek te krijgen is een ramp;

Met dit in gedachte heb ik nog eens naar mijn code gekeken. En wat zitten puzzelen. En wat blijkt, de deletes en destructor calls die ik had staan waren niet nodig! Ofwel ik heb ze mooi weg gehaald, en toen werkte het nog steeds.

Waarom het nu wel werkt kan ik ook niet precies zeggen, maar ik zou zelf denken/speculeren dat juist doordat ik de destructor aanroep, er dingen gedaan werden met geheugen wat al vrijgegeven was op een eerder punt.

RAII aanhouden is extreem veel effectiever.

Ik heb daar eens even naar gegoogled en kom dus op het onderwerp:
"Resource Acquisition Is Initialization"

Het concept er van snap ik; release alle door de class gebruikte geheugens/handle's e.d. zodra de class out of scope raakt.

Maar uh, is dat dan iets wat je "extra" gebruikt? Want ik was toch gewoon onder de indruk dat dat standaard gebeurt? De destructor word impliciet aangeroepen (dus zodra ie out of scope raakt). Of zit ik even helemaal verkeerd?

[edit]
Zoals ik begrijp is het dus een methode die je volgt. En als je die volgt zit het goed zegmaar

[ Voor 7% gewijzigd door MaxxMark op 11-01-2003 17:52 ]