Heftiger Bug in RAD Studio 2007 mit auto_ptr und Delphi-Klassen?
-
audacia|off schrieb:
Der Stackframe sollte eigentlich richtig sein, nur landest du nach einer AV meist in irgendeiner Kernel-Funktion. In diesem Fall gehe ich gewöhnlich in die erste von mir implementierte oder im Quelltext einsehbare Funktion des Stacks, setze einen Breakpoint auf die Zeile vor der markierten, lasse das Programm nochmal ablaufen und lokalisiere die AV durch Single-Stepping.
Ist er leider nicht.
Der Stacktrace sieht eigentlich immer so aus:
:200079e0 rtl100.@System@@LStrClrqqrpv + 0xc :32823b68 ; C:\\WINDOWS\\system32\\CC3280MT.DLL [ca. 8 mal] :008fab45 __ExceptionHandler + 0x1E :7c91378b ntdll.RtlConvertUlongToLargeInteger + 0x46 :7c91eafa ntdll.KiUserExceptionDispatcher + 0xe :32823cee ; C:\\WINDOWS\\system32\\CC3280MT.DLL :32825bf1 CC3280MT.@_ThrowExceptionLDTCqpvt1t1t1uiuiuipuct1 + 0x31
Das ist wie's aussieht eine Bereinigungsfunktion von AnsiString.
"LStrClr$qqrpv" (ich bekomme nicht mal demangled names... :() wird allerdings von meinentwegen A::~A -> B::~B aufgerufen, das wird aber nicht angezeigt. Auch ein Singlestep nach der Exception durchläuft diese Destruktoren nicht. Mit einem Breakpoint, wenn man weiß wo, hält der Debugger aber vor dem Absturz wieder an. Reinsteppen tut er von alleine nicht. Debug kompiliere ich natürlich immer, nur um das auszuschließen.
Ich habe mal die Option "langsame Exception-Epiloge" aktiviert, die wohl ein Inlining des Exception-Codes verhindern soll, hat allerdings nix gebracht.Selbst die Funktion, die das throw gemacht hat, erscheint nichtmal im Stacktrace, sondern ihr Aufrufer. Die IDE bleibt trotz fehlendem Eintrag im Stacktrace auf dem throw stehen - nach der AV allerdings auf dem Aufrufer der werfenden Funktion, die mit der AV nix zu tun hat. Also irgendwie garnicht hilfreich.
audacia|off schrieb:
]Versuche mal, die Runtime-Packages zu deaktivieren; das reichte in C++Builder 2006 aus. Evtl. gibt es sogar in den Projektoptionen eine Einstellung dafür (schau mal nach "Use debug DCUs" oder ähnlichem); im Zweifelsfall setze den Library-Pfad im Debug-Mode, sofern er das noch nicht ist, auf $(BDS)\lib\debug.
Runtime-Packages, ja die könnte ich mal deaktivieren. Den alten "Use debug DCUs" habe ich nicht gefunden, allerdings gibt es die Linker-Option "mit vollständigen Debug-Informationen linken", die im Debug-Build sowieso immer an ist. Der Library-Pfad im Debug-Compile enthält lib\debug ja auch schon von alleine.
-
7H3 N4C3R schrieb:
Der Stacktrace sieht eigentlich immer so aus:
:200079e0 rtl100.@System@@LStrClrqqrpv + 0xc :32823b68 ; C:\\WINDOWS\\system32\\CC3280MT.DLL [ca. 8 mal] :008fab45 __ExceptionHandler + 0x1E :7c91378b ntdll.RtlConvertUlongToLargeInteger + 0x46 :7c91eafa ntdll.KiUserExceptionDispatcher + 0xe :32823cee ; C:\\WINDOWS\\system32\\CC3280MT.DLL :32825bf1 CC3280MT.@_ThrowExceptionLDTCqpvt1t1t1uiuiuipuct1 + 0x31
Und sonst kommt nichts mehr?
Falls ja: was passiert, wenn du in _ThrowExceptionLDTC einen Breakpoint setzt und dann die gleiche Situation herbeiführst; bekommst du dann einen ausführlicheren Stacktrace mit den aufrufenden Funktionen?Weiter ist es hier möglicherweise hilfreich, die dynamische RTL zu deaktivieren, dann bekommst du im Debug-Mode AFAIK auch Symbolnamen für die RTL-Funktionen. So könntest du z.B. in _CatchCleanup() mal einen Breakpoint setzen und schauen, wo und wieso genau dein Objekt ohne Notwendigkeit destruiert wird.
-
audacia|off schrieb:
Falls ja: was passiert, wenn du in _ThrowExceptionLDTC einen Breakpoint setzt und dann die gleiche Situation herbeiführst; bekommst du dann einen ausführlicheren Stacktrace mit den aufrufenden Funktionen?
Vor _ThrowExceptionLDTC ist ein korrekter Stacktrace da (bis auf die Funktion, die die Exception wirft - die fehlt). Sorry, wenn ich da unverständlich war. (Ich meinte den Übergang von CC3280MT.DLL (__get_lock_level) zu LStrClr, die verantwortlichen Destruktoren dazwischen erscheinen nicht im Trace)
audacia|off schrieb:
Weiter ist es hier möglicherweise hilfreich, die dynamische RTL zu deaktivieren, dann bekommst du im Debug-Mode AFAIK auch Symbolnamen für die RTL-Funktionen. So könntest du z.B. in _CatchCleanup() mal einen Breakpoint setzen und schauen, wo und wieso genau dein Objekt ohne Notwendigkeit destruiert wird.
Okay, das habe ich soweit gemacht. Ich sehe nun auch die richtigen Symbolnamen. Allerdings zeigt mir der Debugger die zugehörigen Sourcen nicht an. Ich habe bereits ($BDS)\source\cpprtl\Source\except und weitere Kandidaten in den Suchpfad des Debuggers gesetzt.
Allerdings ist mir unklar, was ich sonst vielleicht noch machen muss, um den Debugger davon zu überzeugen, mir den Source anstatt des ASM-Listings anzuzeigen. Weißt du, was ich hier tun muss?
Edit 3000: Ich baue mal gerade eine Debug-Version der RTL. Anscheinend ist die garnicht per Default vorhanden...
Edit 4000: HA - mit einer händisch gebauten Debug-RTL sehe ich auch die Sourcen und kann steppen.
Anbei ein neuer Stacktrace:
:200079e0 rtl100.@System@@LStrClr$qqrpv + 0xc :0090B848 callDestructor(dst=:0012F488, dstType=:00402E28, dstFlags=0, dtorAddr=:0090F160, dtorMask=3, dtVbases=1) :0090C47B destroyOneObject(varAddr=:0012F488, varType=:00402E28, flags=1, vbFlag=0, errPtr=:0012F40C) :0090C5E8 destroyVariable(varAddr=:0012F488, varType=:00402E28, flags=0, dtorCnt=1, vbFlag=1, newBP=1242532, errPtr=:0012F40C) :0090C7DC destroyVariable(varAddr=:0012F488, varType=:0047455C, flags=0, dtorCnt=1, vbFlag=0, newBP=1242532, errPtr=:0012F40C) :0090C4F7 destroyBases(varAddr=:00000001, flags=0, nblLast=:0046EF20, nblFirst=:0046EF20, count=1242248, isVirt=0, newBP=1242532, errPtr=:0012F40C) :0090C6E9 destroyVariable(varAddr=:0012F488, varType=:0046EEE8, flags=0, dtorCnt=1, vbFlag=1, newBP=1242532, errPtr=:0012F40C) :0090CDD8 dtorCleanup(dttPtr=:00967A18, dtcMin=1, errPtr=:0012F40C, newBP=1242532) :0090C20D local_unwind(errPtr=:0012F40C, target=84) :0090DD95 ___ExceptionHandler(excPtr=:0000005C, errPtr=:0012F40C, ctxPtr=:0012E600, _dspPtr=:0012E5A0, OSEsp=1238244, =1238276, =0, =0, =0, flags=3) :00901229 __ExceptionHandler + 0x1E :7c91378b ntdll.RtlConvertUlongToLargeInteger + 0x46 :7c91eafa ntdll.KiUserExceptionDispatcher + 0xe :0090B9CE tossAnException(tpid=:004733D4, throwAddr=:24DF94B8, friendList=NULL, cctrAddr=:00473434, cctrMask=1, flags=0, throwLine=639, throwFile=:0094211D, throwPC=4665968, reThrow=0, errPtr=:0012EA38, userRegisters=:0012E9DC) :0090D889 _ThrowExceptionLDTC(tpid=:0012EEAC, throwAddr=:03415E40, friendList=:00000001, cctrAddr=:0012EC08, cctrMask=9441803, flags=9715880, throwLine=1239876, throwFile=NULL, errPtr=:24DF5AB0)
-
Was hast du nun in dieser Frage eigentlich unternommen?
Kann es außerdem sein, daß dein Problem in diesem QC-Report beschrieben wird? Falls ja, dann ist es in C++Builder 2009 behoben (wie dieser Liste zu entnehmen ist).
-
Ah, schon wieder ganz verdrängt das Thema. Work work.
Ich kann dir leider nicht sagen, ob das wirklich der Fehler ist (die Beschreibung klingt aber ziemlich danach), da ich weder über's Web noch über die QualityCentral-Anwendung an möglicherweise vorhandene Attachments komme.
Was ich unternommen habe... tja, einen unkonventionellen Workaround. Das Problem war letztendlich wie folgt:
A X::f() { // do something that may throw } ... void Y::g() { X x; A a = x.f(); ///<<< }In der kommentierten Zeile wurde der Destruktor für A aufgerufen, obwohl dort nie ein A gelebt hat.
Mein Workaround sieht jetzt so aus:
bool X::tryF() { bool result = true; try { // something that may throw } catch( ...) { result = false; } return result; } ... void Y::g() { X x; if( tryF() { A a = x.f(); } }Gruselig - funktioniert aber. Da ich nie ein reproduzierbares Minimalbeispiel zusstande bekommen habe, ist hier nix weiter passiert - da der Workaround es nun auch tut. Ich weiß, ich weiß, ganz ganz böse - aber was soll man machen, wenn es keine Aussicht auf einen Fix gibt...
-
7H3 N4C3R schrieb:
aber was soll man machen, wenn es keine Aussicht auf einen Fix gibt...
Wie gesagt, ist das Problem in C++Builder 2009 behoben. Falls ihr euer Projekt nicht gleich dorthin migrieren wollt, so sei darauf hingewiesen, daß es, anders als beim Delphi-Compiler, möglich sein könnte, den C++-Compiler (bcc32.exe und comp32x.dll) aus C++Builder 2009 in C++Builder 2007 einzusetzen. Zumindest ließ sich damals der 2007er-Compiler in C++Builder 2006 verwenden.
-
Naja, bei den Erfahrungen, die wir mit dem 2007er Builder gemacht haben, werde ich hier wohl sicherlich auf Granit beißen, mal den 2009er auszuprobieren. Außerdem müsste der dann natürlich auch erstmal angeschafft werden.
-
7H3 N4C3R schrieb:
Naja, bei den Erfahrungen, die wir mit dem 2007er Builder gemacht haben
Was war denn da noch, abgesehen von dem in diesem Thread diskutierten Bug?
-
Unter anderem war das das DBCtrlGrid, das einen Bug mit DBCheckboxen hatte bzw. hat.
Das Verhalten von AnsiString.SubString( 0, ...) hat sich geändert. Im BCB5 gab das den String zurück, im 2007er Builder war der String nun leer. Die Zeile ist sicherlich nicht die Ausgeburt von sauberem Code (ist auch nicht von mir...), allerdings hat die Suche nach diesem Problem ziemlich lange gedauert. Etwas ähnliches gab es AFAIR auch mit AnsiString.Pos.
Dazu kommt dann die miserable Hilfe. Größtenteils benutze ich noch die Hilfe vom BCB5. Ich glaube, die Beschreibung für z.B. die MaskEdit-Masken ist erst im vierten HelpUpdate hinzugekommen. Exotischere Sachen wie z.B. alles aus der TypInfo.hpp ist so allgemein geschrieben, dass ich es auch eh schon vorher wusste.
Die Abstürze des Builders werden anscheinend auch von Release zu Release schlimmer (u.A. mitten im Betrieb ohne jegliche Meldung). CodeCompletion benutze ich fast garnicht - in ca. 50% geht sie entweder garnicht erst auf oder liefert einen internen Compiler-Fehler.
Und, sie ist tierisch langsam. Natürlich ist CodeCompletion in C++ eine verdammt schwierige Sache, aber die Konkurrenz meistert das IMHO um Längen besser.Finde ich schon ziemlich enttäuschend für ein kommerzielles Produkt. Wobei ich durchaus mal gerne den 2009er ausprobieren würde. Aber nun ja.
-
7H3 N4C3R schrieb:
Dazu kommt dann die miserable Hilfe. Größtenteils benutze ich noch die Hilfe vom BCB5.
So ging es auf der Microsoftschiene einigen auch bei der MSDN (Ich hatte die vom VS6 und vom VS2005 parallel laufen).
Zudem habe ich in der Codegear Hilfe (2007) von Zeit zu Zeit in der Hilfe Fälle von "Link not found"...
7H3 N4C3R schrieb:
Die Abstürze des Builders werden anscheinend auch von Release zu Release schlimmer (u.A. mitten im Betrieb ohne jegliche Meldung).
Laut meinen Chef sind sie weniger geworden, aber ich schlage mich auch mit einigen problemen rum (Die von dir erwähnte CodeCompletion, diverse sporadische Fehlermeldungen [Gerade bei der von mir häufig verwendeten Suche, da ich das Projekt noch nicht kenne] und auch mal den ein oder anderen Absturz; In einigen Fällen war anschließend der Rechner neu zu starten damit etwas funktioniert).
7H3 N4C3R schrieb:
Natürlich ist CodeCompletion in C++ eine verdammt schwierige Sache, aber die Konkurrenz meistert das IMHO um Längen besser.
Das würde ich zwar nicht komplett behaupten (auch wenn ich Intellisense im Vergleich tatsächlich etwas besser finde), was mir aber fehlt sind auch externe Anbieter für solche Funktionalitäten (für den Visual Studio kann man notfalls das benötigte wie Refactoring, Codekomplettierung... nachrüsten - für den C++ Builder habe ich noch nichts entsprechendes gefunden, wohl zu kleiner Markt).
7H3 N4C3R schrieb:
Finde ich schon ziemlich enttäuschend für ein kommerzielles Produkt. Wobei ich durchaus mal gerne den 2009er ausprobieren würde. Aber nun ja.
Den 2009 würde ich auch gerne ausprobieren, mir kommt es aber nicht auf die "neuen" Features an (die sind zwar nett, aber für und kein Umstiegsgrund), wichtiger wären mir Veränderungen unter der Haube (Stabilität, vielleicht auch mal zumindestens ein funktionierendes Refactoring...). Nur zu solchen Änderungen habe ich leider keine Aussage gefunden (Mein Chef wäre zu einem Umstieg bereit, sieht es aber genauso wie ich, das die genannten neuen Features jetzt nicht den Preis rechtfertigen, sondern man dann doch lieber erst die darauffolgende Version wieder anschaut... Zwar einigermaßen aktuell sein, aber nicht immer jede Version mitnehmen).
Wobei ohnehin abzuwarten ist wie die Zukunft vom C++ Builder wird...
cu André
-
Das mit den neuen Features sehe ich ähnlich. Das jetzige Projekt kriegen wir eh nicht auf Unicode hochgezogen, das würde einer Neuentwicklung entsprechen.
Insbesondere die Verbesserungen und Bugfixes am Compiler und hinsichtlich Stabilität würden mich aber auch interessieren. Der 2007er Compiler ist leider immernoch ein gutes Stück von Standardkonformität weg.
Mit der SOAP-Implementierung hatten wir übrigens auch Ärger, da hat die SOAP-Runtime das Parameter-Matching der Antwort mit einem Return-Parameter und mehreren Out-Parametern nicht richtig hinbekommen. Als Workaround funktioniert zumindest das Deaktivieren des Return-Parameters.
-
7H3 N4C3R schrieb:
Dazu kommt dann die miserable Hilfe. Größtenteils benutze ich noch die Hilfe vom BCB5. Ich glaube, die Beschreibung für z.B. die MaskEdit-Masken ist erst im vierten HelpUpdate hinzugekommen. Exotischere Sachen wie z.B. alles aus der TypInfo.hpp ist so allgemein geschrieben, dass ich es auch eh schon vorher wusste.
Ja, das ist nach wie vor ein ernstes Problem. Auch wenn die C++Builder-2009-Dokumentation IMHO ein deutlicher Schritt nach vorne ist.
7H3 N4C3R schrieb:
Die Abstürze des Builders werden anscheinend auch von Release zu Release schlimmer (u.A. mitten im Betrieb ohne jegliche Meldung).
Dann mußt du auf jeden Fall den 2009er testen
7H3 N4C3R schrieb:
CodeCompletion benutze ich fast garnicht - in ca. 50% geht sie entweder garnicht erst auf oder liefert einen internen Compiler-Fehler.
Wie groß sind eure Quelldateien so im Schnitt, und wie viele Headerdateien werden eingebunden?
7H3 N4C3R schrieb:
Und, sie ist tierisch langsam.
Wenn ihr richtig mit PCHs arbeitet, also z.B. #pragma hdrstop an richtiger Stelle und ggf. mit einem Master-Header, sollte es fix gehen.
7H3 N4C3R schrieb:
Natürlich ist CodeCompletion in C++ eine verdammt schwierige Sache, aber die Konkurrenz meistert das IMHO um Längen besser.
In der Stabilität, ja, aber IntelliSense in VS ist bei weitem nicht so informativ wie Code Completion.
asc schrieb:
was mir aber fehlt sind auch externe Anbieter für solche Funktionalitäten (für den Visual Studio kann man notfalls das benötigte wie Refactoring, Codekomplettierung... nachrüsten - für den C++ Builder habe ich noch nichts entsprechendes gefunden, wohl zu kleiner Markt).
Ja, leider
7H3 N4C3R schrieb:
Das jetzige Projekt kriegen wir eh nicht auf Unicode hochgezogen, das würde einer Neuentwicklung entsprechen.
Das brauchst du auch gar nicht; der größte Teil bestehenden Quellcodes sollte ohne Probleme weiterhin einsetzbar sein. Die VCL ist zwar nun vollständig Unicode-basiert, aber AnsiString gibt es immer noch, und auch sonst wurde einiges getan, damit alter Code weiterhin funktioniert. Warum das geht, ist allerdings ein Thema für sich.
7H3 N4C3R schrieb:
Insbesondere die Verbesserungen und Bugfixes am Compiler und hinsichtlich Stabilität würden mich aber auch interessieren. Der 2007er Compiler ist leider immernoch ein gutes Stück von Standardkonformität weg.
Dafür ist die Liste der in C++Builder 2009 behobenen Fehler, auf die ich ein paar Posts vorher verwiesen hatte, ganz hilfreich
-
audacia schrieb:
Ja, das ist nach wie vor ein ernstes Problem. Auch wenn die C++Builder-2009-Dokumentation IMHO ein deutlicher Schritt nach vorne ist.
Zum Glück liegt ja für das allermeiste der Source dabei. In letzter Instanz ist das noch die ausführlichste Beschreibung.
Das finde ich übrigens sehr lobenswert.audacia schrieb:
7H3 N4C3R schrieb:
Die Abstürze des Builders werden anscheinend auch von Release zu Release schlimmer (u.A. mitten im Betrieb ohne jegliche Meldung).
Dann mußt du auf jeden Fall den 2009er testen
Mach mich nicht neugierig
audacia schrieb:
Wie groß sind eure Quelldateien so im Schnitt, und wie viele Headerdateien werden eingebunden?
Das liegt zugegebenermaßen wohl zum Teil am Projekt selbst, da historisch gewachsen fast alles alles inkludiert und die Formulare zu großen Teilen sehr monolithisch sind.
Aber auch in Teilen mit sauberen Headern und "kleinen" Formularen ist es nur wenig besser.audacia schrieb:
Wenn ihr richtig mit PCHs arbeitet, also z.B. #pragma hdrstop an richtiger Stelle und ggf. mit einem Master-Header, sollte es fix gehen.
Guter Hinweis, damit werde ich mal noch ein wenig experimentieren.
audacia schrieb:
In der Stabilität, ja, aber IntelliSense in VS ist bei weitem nicht so informativ wie Code Completion.
Wobei ich mich frage, ob das nicht zu guten Teilen daran liegt, dass vieles aus Delphi kommt. Wenn Code Completion richtig funktioniert, ist sie in der Tat hilfreich und informativ.
audacia schrieb:
Die VCL ist zwar nun vollständig Unicode-basiert, aber AnsiString gibt es immer noch, und auch sonst wurde einiges getan, damit alter Code weiterhin funktioniert. Warum das geht, ist allerdings ein Thema für sich.
Davon war ich auch stillschweigend ausgegangen.
Ich meine nur, dass die Unicode-VCL als Feature für uns kein Mehrwert wäre und kein Umstiegsgrund.audacia schrieb:
Dafür ist die Liste der in C++Builder 2009 behobenen Fehler, auf die ich ein paar Posts vorher verwiesen hatte, ganz hilfreich
Ich habe sie auch schon überflogen - aber holla die Waldfee, das ist ja wirklich jede Menge.
-
Hallo
7H3 N4C3R schrieb:
Das Verhalten von AnsiString.SubString( 0, ...) hat sich geändert. Im BCB5 gab das den String zurück, im 2007er Builder war der String nun leer. Die Zeile ist sicherlich nicht die Ausgeburt von sauberem Code (ist auch nicht von mir...), allerdings hat die Suche nach diesem Problem ziemlich lange gedauert. Etwas ähnliches gab es AFAIR auch mit AnsiString.Pos.
Das ist aber kein Fehler vom Builder 2007, sondern eher ein Fehler des Builder 5, der im 2007er behoben wurde! Denn bei AnsiString beginnt die Zählung der Elemente bei 1, eine Angabe von 0 als Index ist also grundsätzlich out of range. Damit ist die leere Rückgabe korrekter als die volle Rückgabe.
bis bald
akari
-
Ja, das sehe ich durchaus ähnlich. Allerdings gibt es auch keine Out-Of-Range Exception oder ähnliches, sondern das Verhalten wurde stillschweigend (?) geändert. Hat zumindest eine Menge Arbeit gemacht, das alles zu bereinigen.
-
Hallo
Stimmt, eine Exception wäre besser gewesen. Es gehört eigentlich zum guten Ton Parameter auf Gültigkeit zu prüfen und alles nicht zulässige möglichst nachvollziehbar abzuweisen.
bis bald
akari
-
audacia schrieb:
Wie groß sind eure Quelldateien so im Schnitt, und wie viele Headerdateien werden eingebunden?
Auch wenn das hiesige Projekt von der Codequalität noch weitgehend in Ordnung ist, sind die Dateien leider recht groß und imho auch zu viel inkludieren (Den, was wiederum "aus Übersichtlichkeit" nicht gemacht wurde, ist das auftrennen pro Klasse; auch wenn ich schon gute Argumente dagegen gebracht habe braucht alle Umstellung Zeit).
Von der Projektgröße: Die Gesamtanwendung ist im Release etwa 3MB groß...Ich kann mich "7H3 N4C3R" aber auch Anschließen: Probleme kann ich ebenso bei kleinen Projekten durchaus feststellen, wenn gleich es dort etwas besser ist.
audacia schrieb:
In der Stabilität, ja, aber IntelliSense in VS ist bei weitem nicht so informativ wie Code Completion.
Dem kann ich mich nicht anschließen, da mir zuviel abgeschnitten wird (wenn ich mehrere Sachen zur Auswahl habe, aber nichts sinnvolles mehr erkennen kann, nützt mir auch die Mehrinformation nicht. Und was ich bei der CC noch vermisse ist, das diese auch noch angezeigt wird nachdem man den ersten Parameter eingegeben hat (Ich sehe gerne auch noch die Bezeichnung der nächsten). Aber Grundsätzlich ist weder die C++ Builder- noch die Visual Studio-Lösung ausgereift.
cu André
-
7H3 N4C3R schrieb:
audacia schrieb:
In der Stabilität, ja, aber IntelliSense in VS ist bei weitem nicht so informativ wie Code Completion.
Wobei ich mich frage, ob das nicht zu guten Teilen daran liegt, dass vieles aus Delphi kommt.
Das Code Completion-Backend besteht im Wesentlichen aus comp32x.dll, also dem C++-Compiler. Lediglich die Darstellung ist in Delphi realisiert.
asc schrieb:
Dem kann ich mich nicht anschließen, da mir zuviel abgeschnitten wird (wenn ich mehrere Sachen zur Auswahl habe, aber nichts sinnvolles mehr erkennen kann, nützt mir auch die Mehrinformation nicht.
Ein gültiger Einwand, besonders für templatebasierende Klassen. Seit C++Builder 2007 wird das aber IMHO deutlich besser gehandhabt.
asc schrieb:
Und was ich bei der CC noch vermisse ist, das diese auch noch angezeigt wird nachdem man den ersten Parameter eingegeben hat (Ich sehe gerne auch noch die Bezeichnung der nächsten).
Du meinst Parameter Insight? Dann drücke doch Strg+Shift+Space
asc schrieb:
Aber Grundsätzlich ist weder die C++ Builder- noch die Visual Studio-Lösung ausgereift.
Und beide werden nie auf dem Niveau von Java- oder Delphi-CC ankommen. Leider
-
audacia schrieb:
asc schrieb:
Aber Grundsätzlich ist weder die C++ Builder- noch die Visual Studio-Lösung ausgereift.
Und beide werden nie auf dem Niveau von Java- oder Delphi-CC ankommen. Leider
Das Problem wäre wohl aber eher C++ zuzuschreiben. Für die "perfekte" Lösung bräuchte man ja immer eine vollständige Compilierung.
-
7H3 N4C3R schrieb:
Für die "perfekte" Lösung bräuchte man ja immer eine vollständige Compilierung.
Selbst für die nicht-perfekte Lösung benötigt dies der C++ Builder von Zeit zu Zeit...