mikrocontroller.net

Forum: PC-Programmierung Wie unterscheidet sich Standard C++ vs MFC


Autor: David_Köln (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Borislav Bertoldi (boris_b)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Du vergleichst Äpfel mit Birnen. C++ ist eine Sprache, MFC ein 
Framework.
Daher ist die Frage Quatsch ;-)

Autor: Sabberalot W. (jetztnicht)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: David_Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Borislav B. schrieb:
> Daher ist die Frage Quatsch ;-)

Sorry
das habe ich im nachhinein gemerkt aber wie ist der Einstieg in MFC?

Autor: Quatschkopp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David_Köln schrieb:
> aber wie ist der Einstieg in MFC?

Mühsam

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Quatschkopp (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Sabberalot W. (jetztnicht)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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.

Autor: db8fs (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: db8fs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sabberalot W. schrieb:
> zum
> Einen um Alternativen aufzuzeigen,

Hatte die Firma einen MFC-Programmierer oder einen Klugscheißer gesucht?

Autor: Sabberalot W. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: db8fs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: David_Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: db8fs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: db8fs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: David_Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habt ihr Erfahrungen mit diesem Tools:
http://www.codejock.com/products/chart/?2yn6s14z=zsp

Danke

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.