|
Anzeige
|
Wie unterscheidet sich Standard C++ vs MFC
Gast
#5241621
Hallo Zusammen, innerhalb der nächsten 3 Monate sprich ab 01.03.2018 werde ich eine neue Stelle antreten als MFC Programmierer. Von MFC Programmierung muss ich sagen habe ich keine Ahnung. Die letzten 10 Jahre habe ich nur Standard C++, Java, LabVIEW programmiert. Meine Frage an euch: Wie unterscheidet sich MFC VS zu Standard C++? Wie ist der Einstieg? danke in voraus Du vergleichst Äpfel mit Birnen. C++ ist eine Sprache, MFC ein Framework. Daher ist die Frage Quatsch ;-) Das MFC (Microsoft Framework ..) Framework sind die Buttons, Textfelder, Label, Icons, Slider, Statusbar, bis zu Telephonbuch, und so weiter, die eine graphische Oberflaeche ausmachen. Wahrscheinlich gehoeren auch komplexere Dinge wie Registry, Systemprozesse, usw dazu. Bin mir aber nicht sicher. Neben den sichtbaren Teilen heisst es auch auf Aktionen, dh buttonpress, Slidemove, usw zu reagieren. Das MFC ist etwas in die Jahre gekommen, ich dachte es wurde abgeloest, obwohl sich das Dot-Net als Flopp entpuppte. Man kann auf dieser Stufe viel Zeit auf trivialem Zeug verballern, die andere Konstrukte, wie zB Delphi, viel eleganter geloest haben. Trotdem viel Spass.
Gast
#5241672
Borislav B. schrieb: > Daher ist die Frage Quatsch ;-) Sorry das habe ich im nachhinein gemerkt aber wie ist der Einstieg in MFC?
Gast
#5241680
David_Köln schrieb: > aber wie ist der Einstieg in MFC? Mühsam
Gast
#5241682
MFC ist vielleicht nicht das modernste, aber durchschaubar. Es ist nur viel Historie und Windowsspezifisches drin, die Basis sind immer noch die Windows Messages und das Fenstergedöns seit Win 3.0. C++ technisch wurde da nur ein dünner Wrapper um die API gelegt, andere Frameworks wie ICLUI von IBM waren stärker Objektorientiert aber dafür sehr schwerfällig, langsam und gross. Für die Konzepte und die Arbeitsweise mit dem VS (SDI/MDI, Resourcen Editor, Codegenerator für Messagehandler usw.) sollte man unbedingt erstmal ein Buch oder ein Tutorial durcharbeiten. Konkrete Tipps habe ich nicht, habe auch schon länger nichts mehr damit gemacht, aber Tante Google findet reichlich Futter zur MFC. Nicht nur mühsam, sondern aus heutiger Sicht für Anfänger auch nicht mehr ratsam (ich arbeite seit etwa 20 Jahren mit der MFC). Ich würde zu einem plattformunabhängigeren Framework raten. wxWidgets ist von den Grundstrukturen der MFC recht ähnlich, Qt verwendet einen anderen Ansatz. Beide Frameworks sind verbreitet, Qt unter anderem wegen des Linux-Desktops KDE deutlich mehr. Wenn tatsächlich MFC gelernt werden soll, empfehle ich als Lektüre den Prosise (dürfte schon ein paar Jahre auf dem Buckel haben, aber an der MFC hat sich auch schon seit längerem nicht mehr viel geändert). Auf www.codeproject.com findet man manchmal auch ganz passable Hinweise und Tips, man muss bloß aufpassen, daß man seine Suchanfragen gut genug formuliert, da das .Net-Geraffel sich auch dort gerne in den Vordergrund drängelt. Wenn von "Windows Forms" die Rede ist, ist auch .Net gemeint. Und .Net hat weder mit der MFC noch mit C++ etwas am Hut, auch wenn MS eine .Net-Sprache namens "C++" anbietet. Das ist "Managed C++" bzw. "C++/CLI" und hat mit tatsächlichem C++ nur wenig zu tun.
Gast
#5241690
Rufus Τ. F. schrieb: > Ich würde zu > einem plattformunabhängigeren Framework raten. und du meinst er sollte als erstes seinem Chef raten, alle Software wegzuwerfen und mit einem anderen Framework anzufangen? Ich weiss nicht ob das so clever wäre. David_Köln schrieb: > innerhalb der nächsten 3 Monate sprich ab 01.03.2018 werde ich eine neue > Stelle antreten als MFC Programmierer. @TO: Mein erstes Post war etwas flapsig. Für die MFC solltest du dir erst mal ein oder zwei gute Bücher besorgen. Schau dich auf Amazon um, du hast ja noch gut 2 Monate, da musst du dich halt reinarbeiten.
Gast
#5241697
Quatschkopp schrieb: > und du meinst er sollte als erstes seinem Chef raten, alle Software > wegzuwerfen und mit einem anderen Framework anzufangen? Das wohl nicht, aber man sollte sich im Klaren sein, daß es sich um eine Stelle als Legacy-Programmierer handelt. > Das wohl nicht, aber man sollte sich im Klaren sein, daß es sich um eine
Stelle als Legacy-Programmierer handelt.
Man sollte sich auch gleich in modernere Technologien einarbeiten, zum
Einen um Alternativen aufzuzeigen, zum Anderen um die dann auch zu
haben, auch wenn man sie erst bei der naechsten Firma anwenden kann.
Gast
#5241708
Sabberalot W. schrieb: > Man sollte sich auch gleich in modernere Technologien einarbeiten, zum > Einen um Alternativen aufzuzeigen, zum Anderen um die dann auch zu > haben, auch wenn man sie erst bei der naechsten Firma anwenden kann. Wenn man sonst nix zu tun hat, kann man das machen... Meiner Erfahrung nach hat man erstmal genug damit zu tun, die übernommene Software selber zu verstehen, also Anwendungsfälle + deren Abläufe, sowie die Rahmenbedingungen der Software (nichtfunktionales) rauszukriegen. Erbt man dann noch Code, wo sich 'ne zufällige bzw. degenerierte Architektur ergeben hat - ich behaupte dann dreist, dass man da keine Zeit für Einarbeitung in andere Frameworks hat, wenn Cheffe oder Kunde mit neuen Anforderungen dahergelatscht kommt.
Gast
#5241710
Btw. sich in neue Frameworks einzuarbeiten um das für die nächste Firma zu verwenden, zeigt eher auf, dass man von Cheffe eins auf die Mütze kriegen will...
Gast
#5241727
Sabberalot W. schrieb: > zum > Einen um Alternativen aufzuzeigen, Hatte die Firma einen MFC-Programmierer oder einen Klugscheißer gesucht? Es gibt die Moeglichkeit sich von einem ploetzlichen Projektstop ueberraschen zu lassen. Oder im Voraus zu merken wann man vom toten Pferd absteigen sollte. Und zu diesem Zeitpunkt, der auch ein Stueck in der Zukunft liegen kann, hat man Alternativen oder eben nicht. Alternativen fuer sich und/oder die Firma. Ich wuerde nicht meine Zukunft auf veraltete Technologie setzen wollen. Ausser es geht um ueppig viel Geld noch vor der Rente, wie bei den Cobol Programmierern, welche den Jahr 2000 Fehler proaktiv fixen sollten. Einarbeiten in neue Technologie gehoert zum Job. Sonst seinlassen. ich vertue hier mind. 20% der Zeit um dabei zu bleiben. Und schaff's eigentlich nicht wie ich's gerne haette.
Gast
#5241789
Sabberalot W. schrieb: > Es gibt die Moeglichkeit sich von einem ploetzlichen Projektstop > ueberraschen zu lassen. Oder im Voraus zu merken wann man vom toten > Pferd absteigen sollte. Und zu diesem Zeitpunkt, der auch ein Stueck in > der Zukunft liegen kann, hat man Alternativen oder eben nicht. > Alternativen fuer sich und/oder die Firma. Interessanter Punkt, der genau an der Kommunikations-Schnittstelle Entwickler/Vorgesetzter ansetzt. Informiert dich der Vorgesetzte darüber, über die Stop-Wahrscheinlichkeit, oder merkste das erst, wenn's tot ist? Falls letzteres, dann klingt das eher so, als ob Cheffe oder dessen Cheffes gerne mal Mushroom-Management betreiben. Ansonsten solltest du imho schon deine volle Arbeitsleistung für das Projekt einsetzen und nicht parallel schon 'ne heimliche Einarbeitung in was anderes machen, was mit dem Projekt nix zu tun hat (es sei denn, du sollst das). Soll nicht heißen, dass man nicht auch mal weiter ausholen darf, z.B. eine kleine Hilfskomponente mit einer anderen Technologie schreiben. Das ist vollkommen ok. > Ich wuerde nicht meine Zukunft auf veraltete Technologie setzen wollen. Na ja, das Wissen der Firma steckt in dem Code, den du vorliegen hast. Die Technologie selber ist erstmal zweitens und eine Architekturentscheidung, die zu Beginn des Projektes getroffen wird und mit der man in der Regel leben muss. Selbst wenn die Programmiersprache z.B. 'Cobol' heißt - solange das Projekt lebt, du dafür zuständig bist und Geld dafür kriegst, kannste nicht einfach Java draus machen, es sei denn für Tools, die die Entwicklung sinnvoll unterstützen.
Gast
#5241807
Es ist mir auch schon klar, dass MFC fast gar nicht mehr bei der aktuellen Projekten eingesetzt wird. Die Idee ist eine einen dringende Erweiterung (neue Funktinalitäten muss dazu kommen) bei der MFC Projekt nötig ist. Die Chefen sind auch bewusst, dass dieses MFC Projekt unbedingt neue umgeschrieben werden muss. Meine zukunft Idee wäre, dass ganze in Qt zu migrieren. das wäre eigentlich technisch machbar oder dass man Codejock Tools "http://www.codejock.com/products/controls/?2yn6s14z=zsp"; nehmen kann, aber das ist Zukunft Musik.
Gast
#5241809
BTW: wenn ein Projektstopp möglich ist, du aber nicht der projektverantwortliche Programmierer bist, machste dich bei dem dann mit 'ner Paralleleinarbeitung in andere Technologien erst richtig beliebt.
Gast
#5241826
David_Köln schrieb: > Die Idee ist eine einen dringende Erweiterung (neue Funktinalitäten muss > dazu kommen) bei der MFC Projekt nötig ist. > > Die Chefen sind auch bewusst, dass dieses MFC Projekt unbedingt neue > umgeschrieben werden muss. Vorschlag: versuch, beim Einbauen der neuen Funktionen auch etwas Architekturarbeit zu machen (Refactoring). Also Trennungen von UI, Geschäftslogik und Persistenz herauszuarbeiten (gemäß "Law of Demeter"). Geht auch in reinen MFC Projekten. > Meine zukunft Idee wäre, dass ganze in Qt zu migrieren. > das wäre eigentlich technisch machbar oder dass man Codejock Tools > "http://www.codejock.com/products/controls/?2yn6s14z=zsp";; nehmen kann, > aber das ist Zukunft Musik. Arbeite da agil dran. Sprich: arbeite deinen Code schrittweise vom MFC-Monolithen in Libraries um, die kein MFC mehr brauchen. Wenn du das sauber und lange genug machst, ist dann der Wechsel des Frontends zu Qt unter Beibehaltung deiner Geschäftslogik und deines Persistenzcodes kein großes Ding mehr.
Gast
#5241947
MFC ist wie COBOL. Beides wird in 50 Jahren noch benutzt werden, aber richtig gut ist es nicht. Und irgendwann muß man mal anfangen, alte Programme in eine modernes Umfeld zu versetzen. Neue Programme würde ich nicht mehr mit MFC beginnen.
Beitrag #5242467 wurde von einem Moderator gelöscht.
David_Köln schrieb: > Meine zukunft Idee wäre, dass ganze in Qt zu migrieren. Das ist, da die grundlegenden Konzepte massiv abweichen, ein ziemlicher Aufwand. Einfacher dürfte eine Migration nach wxWidgets sein, das ist strukturell der MFC deutlich näher.
Gast
#5252012
habt ihr Erfahrungen mit diesem Tools: http://www.codejock.com/products/chart/?2yn6s14z=zsp Danke Nö. Allerdings finden sich auch etliche freie Lösungen, die man gegebenenfalls nur etwas anpassen muss, auf www.codeproject.com bzw. www.codeguru.com, und die haben den Vorteil, im Quelltext vorzuliegen, so daß man sie a) ändern und b) verstehen und c) debuggen kann. Kommt halt immer drauf an, was Du anstellen willst.
Beitrag #5258531 wurde von einem Moderator gelöscht.
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
