Re: .NET Umgebung mit MFC von Visual C 6 nutzbar?

Hallo Martin!

>> Das stimmt allerdings, den Compiler vermisse ich in einigen Details
>> wirklich. Aber ansonsten hab ich noch nich das Killerargument für VS
>> 2002 (und spätere Versionen) gefunden, wenn man nur mit C++ und MFC
>> arbeitet. Ich glaub es waren sogar ein paar richtig fiese Bugs in
>> der MFC 7.x drin, erinner mich da an Verrenkungen mit dem
>> CFileDialog.
> Sag bitte nichts was Du nicht weißt. Zu glauben das es irgendwo Bugs
> gibt ist eine Sache, es zu wissen ist etwas anderes.
> Was hast Du für Probleme mit mit CFileDialog? Das ab MFC 7 auch der
> neue Dialogstil angezeigt wird war doch längst überfällig. Das es
> hierbei zu Änderungen kam ist kein Bug!
> Niemand hat gesagt das bei einem Umstieg keine Änderungen notwendig
> sind.

Nene, ich weiss das es den Bug gab :-) Ich musste ihn jetzt nur noch
rauskramen, leider bekomm ich das Projekt von damals (2 Jahre oder so ist
das her) nicht unter VS7 kompiliert, und hab jetzt auch nicht die Zeit mich
damit rumzuärgern. Ich glaub es hing damit zusammen das als größe für die
interne Stuktur immer die Struktur für W2k aufwärts genutzt wurde, was
unter NT4 und 9x zum absturz (?) führte. Okay, das konnte man noch relativ
einfach durch eine Versionsabfrage zur Laufzeit lösen welche in
m_ofn.lStructSize die richtige größe reinpackte.

Der zweite Fehler war die Behandlung von vielen ausgewählten Dateinamen.
Der interne Buffer war nicht groß genug und so returnte DoModal() mit IIRC
IDCANCEL oder ähnlichem. Da behalf ich mir mit einer CFileDialogEx Klasse,
wobei ich jetzt garnicht mehr sagen kann wo ich die gefunden hab (irgendwo
auf CodeProject o.ä. bestimmt), die Instanz der Klasse musste aber wegen
obigen Fehler auf dem Heap erstellt werden, und beim delete knallte es
fürchterlich. Diese CFileDialogEx Klasse vergrößerte den internen Buffer
für die Dateinamen so das alle Dateinamen mit Pfad reinpassten.

Nachdem ich diese Fehler hatte bin ich dann kurzerhand wieder auf VS6
umgestiegen bzw. geblieben, dort funktionierte der Code den ich hatte da
ich nicht noch mehr Zeit mit diesen Bugs verschwenden wollte.

Ich weiss alles recht wage und nicht sehr detailiert, leider bekomm ich das
Projekt von damals nicht mehr unter VS7 kompiliert. Wenn ich mal etwas mehr
Zeit und Ruhe hab werd ich mich da wieder reinwühlen.

>> Und die IDE war IMHO
>> größer vom Speicherverbrauch und dadurch langsamer, das hab ich auf
>> meinem (zugegeben älterem Rechner) dann doch gemerkt :-( Aber ich
>> lass mich gern umstimmen :-)
> Ich wiederhole mich: Du hast wahrscheinlich nicht mit VS6 gearbeitet
> auf der damaligen Rechnergeneration als es veröffentlicht wurde.
>
> Programme die auf einem 386 passabel liefen laufen heute natürlich im
> "haste nicht gesehen" Modus.

Hmm, wann ist VS6 rausgekommen? 98/99 oder so um den Dreh? Da hatte ich
allerdings kein 386er mehr, etwas schneller waren die Rechner damals schon
;-)

>> Wie ist das eigentlich, wofür braucht man den Compiler soviel mehr
>> wenn man relativ "normale" Sachen macht und keine exotischen wie
>> Templates und ähnliches? Ist da so nen großer Unterschied von V6 auf
>> V7.x?
> Warum entwickelst Du eigentlich in C++ statt in C? Wer relative
> normale Sachen macht braucht kein C++!
> Was ist bitte normal?
> Ich wusste gar nicht, dass ich exotisch bin weil ich Templates
> verwende? SCNR

Falsch ausgedrückt ;-) Ich hab in meinen bisherigen Projekten eigentlich
nie mit Compilerfehlern zu tun gehabt, oder ich hab nur nich gemerkt das es
ein Compiler-/Optimizer-Fehler war *g*

> Der Compiler macht endlich mal was er soll, oder sagen wir: ziemlich
> viel. Verglichen mit C6 ist das Ding um Lichtjahre besser. Mich haben
> Optimizer Bugs und Haken im Compiler mehr Zeit gekostet, als ich in
> irgend einem Classwizard zugebracht habe...
>
> Allein die for-Loop Katastrophe ist ein Ding, das sich wahrscheinlich
> noch durch die nächsten Jahre durch den Code fressen wird.

Von den Optimizier Bugs hab ich schon einiges gehört, aber lohnt sich der
Optimizier denn überhaupt? Wenn ich ein Projekt hab das nicht zeitkritisch
ist und "nur" GUI benutzt? Von dieser for-Loop Katastrophe hab ich noch
nichts gehört, hab ich da was verpasst?

Gruss,
Sebastian


.

Relevant Pages

  • Re: compiler bugs
    ... well known verification techniques? ... think of the kind of bugs you experience. ... (Most compiler code is ... many of the subtle bugs come from using grey-areas, ...
    (comp.compilers)
  • Re: Perform Thru/Go to vs. Perform - Compile Speed
    ... >>and customers with such large programs must sometimes do what is ... a thing" is irrelevant when it comes to what a compiler encounters. ... the bugs being mentioned were "not an infrequent ... restictions -- it's difficult to support a rewrite just on accounta it looks ...
    (comp.lang.cobol)
  • Re: future C standards
    ... You asked me the reason for my "prejudice" against lcc-win, and that "disagreement" is a key part of it. ... surprising is that the bugs existed because of a failure to understand ... confidence in the quality of your compiler. ... so it would apply equally well to C90 as to C99. ...
    (comp.std.c)
  • Re: Whats more important optimisations or debugging?
    ... aiming to make high level debugging as accurate and complete as ... oriented debug chain is appropriate. ... But in either case, barring chip and compiler bugs, the bugs ...
    (comp.arch.embedded)
  • CFileDialog with PPC
    ... Does anyone know how to set filters for use with CFileDialog in Pocket PC. ... I've created a TCHAR szFilters.... ... but the compiler does not like this in the CFileDialog creation function. ...
    (microsoft.public.pocketpc.developer)
Loading