Win-API für Win-Programmierung immer noch aktuell und "Pflicht" ?
-
Hallo Leute,
bin ein Neuling hier und auch ein Neuling was C++ und die damit zusammenhängende GUI-Programmierung angeht.
In den FAQ ergibt sich zwar eine grobe Richtung für meine Fragestellung, aber die Beiträge sind doch eher die "aktuältesten". In der Zwischenzeit hat sich viel getan und die Richtung könnte sich geändert haben.
Kurz zum Hintergrund:
Ich muss in den nächsten Monaten viele vorhandene kaufm. Programme von ACCESS/VBA (Frontend) in Verbindung mit diversen SQL-Datenbanken(Backend) auf "vernünftige", stabile Beine stellen. C++ erscheint mir hier nach langem Suchen als die geeignetste Sprache für diese Umstellungen und ür weitere Projekte.Um "richtige" Windowsprogrammierung (nicht VB oder VBA) habe ich mich längere Zeit erfolgreich gedrückt
.Nun ergibt sich für mich die Frage, mit was sollte ich mich in Verbindung mit C++ nun am meisten beschäftigen (zukunftssicher !):
WinAPI - auch noch "notwendig" nach DotNet 3.51 etc. ?
MFC - wenn ich richtig verstanden habe, eigentlich "nur " eine Wrapper-Class für WinAPI ? ?
dotNet - bedient sich doch bestimmt immer noch der WinAPI - oder ?Auf externe Frameworks möchte ich gerne so lange wie möglich verzichten und außerdem Verstehen, was so unter der Haube abläuft !
Die Systeme, mit denen ich am meisten in Berührung komme sind: Win 2000, 2003 und XP Professional. Vista konnte ich erfolgreich umgehen.
.Aber was is mit Windows 7 ???
.net?
WinAPI ??
MFC ??Da ich gewerbich tätig bin und nicht nur Programmiere, sondern auch noch andere kfm. Dienstleistungen anbiete, bleibt mir nich sehr viel Zeit zur Einarbeitung in diese Materie. Also muss ich mich auf das Wichtigtse beschränken.
Für Eure Meinungen und Hilfestellung wäre ich sehr dankbar.
PS: falls nicht korrektes Forum, einfach verschieben !!
-
Wenn Di rnicht so viel Zeit bleibt, dann bleibt IMHO nur C# mit WinForms übrig.
-
Jochen Kalmbach schrieb:
Wenn Di rnicht so viel Zeit bleibt, dann bleibt IMHO nur C# mit WinForms übrig.
ooch... lass mal gut sein.... zu C# krieg ich einfach keinen Bezug, ist schon sehr früh aus der "Verlosung" der Programmiersprachen rausgefallen...
Trotzdem Danke für den Tip.
dat janze scheint nach weiteren Recherchen wohl in folgende Richtung zu gehen:
die gewerblichen Projekte werden wohl dann doch mit Turbo C++ in Angriff genommen.
(weil viel Formulare, Datenbankzugriff auf SQL-DB's und eine gewisse Zeitbindung)Bei meinen privaten Projekten werd ich mich dann ins Abenteuer WIN-API stürzen !
Grüße
DerKleineProgrammierer
-
DerKleineProgrammierer schrieb:
die gewerblichen Projekte werden wohl dann doch mit Turbo C++ in Angriff genommen.
(weil viel Formulare, Datenbankzugriff auf SQL-DB's und eine gewisse Zeitbindung)Bei meinen privaten Projekten werd ich mich dann ins Abenteuer WIN-API stürzen !
Wo hast Du denn den Quark her?
Ein Großteil von Firmen setzt immer noch auf MFC und stagniert auf VC6...
WinAPI pur, macht niemand, wenn es um etwas größere Projekte geht.Ich kenne nicht ein einziges Projekt eines Softwarehauses das mit Turbo C++ abgewickelt wurde.
Aber das mag ein meiner "eingeschränkten Wahrnehmung" liegen.MFC "nur" als Wrapper Klasse für die WinAPI abzutun ist lachhaft, wenn man sich die Leistungsfähihkeit und Möglichkeiten von VC-2008 mit MFCNext ansieht.
-
Martin Richter schrieb:
Ich kenne nicht ein einziges Projekt eines Softwarehauses das mit Turbo C++ abgewickelt wurde.
Vielleicht deshalb, weil es im kommerziellen Umfeld eigentlich "C++Builder" heißt
-
DerKleineProgrammierer schrieb:
zu C# krieg ich einfach keinen Bezug, ist schon sehr früh aus der "Verlosung" der Programmiersprachen rausgefallen...
dann nimm doch VB. vielleicht geht's damit schneller, deine vorhandenen access/VBA codes zu portieren. ich mein ja nur, wenn deine zeit begerenzt ist, würde ich nicht noch 'ne c++ lernphase mit reinquetschen.
-
dann nimm doch VB. vielleicht geht's damit schneller, deine vorhandenen access/VBA codes zu portieren. ich mein ja nur, wenn deine zeit begerenzt ist, würde ich nicht noch 'ne c++ lernphase mit reinquetschen.
VB is für Dinge bis zu einem bestimmten Level ja gar nich schlecht,
aber hier ist die Grenze von VB (VB 6) erreicht, da ich bei dem vorhandenen Maschinenpark der diversen Auftraggeber auf dat .Net Framework doch gerne vrzichten möchte (zb. B. P4, Win 2000, 256 MB !! - da ändert sich auch so schnell nix !!).C++ hat nun mal allgemein und in Bezug auf OOP doch mehr Möglichkeiten. (auch ohne .Net !!)
Ein Knackpunkt bei Systemunabhängigen Sprachen ist dann aber die GUI.....
(wobei wir hier wieder bei dem Kern-Anliegen wären !! )Und wenn ich die (zugegeben erst sehr spät erkannten Möglichkeiten) der OOP
richtig nutzen möchte, komm ich nun mal nich um C++ rum. (Auch wenn ich früher C gehasst habe - Mache mal nen 5-Stufigen Gruppenwechsel in C - Viel Vergnügen !! - war mit COBOL wesentlich effezienter zu realisieren ....).. war so um 1978-86 so rum.....Ich hab mich nun mal seit Win 3.11 um die Windows-Programmierung gedrückt !! Und die ganze Programmiertätigkeit hat auch erst vor ca. 2 Jahren wieder angefangen - VBA-Scripts in EXCEL, ACCES...SQL dazu.... usw.
Jetzt kommt so allmählich der Zeitpunkt, wo dat ganze so ganz langsam in wenigstens semiprofessionelle Bahnen gelenkt werden muss.
Für zukünftige Projekte deshalb C++ (auch wenn ich in den sauren Apfel der Portierungen beissen muss..)
...und in die bittere Birne der Windows-Interna...Ach so, nur mal so zu Info wat da so ansteht:
Reklamationsmanagement-Systemchen für Versandhandel..
Bestellwesen mit Containerinformationssystemchen...(Außenhandel)
Offene Posten-System (weil die OPOS-Fähigkeiten der Buchhaltungen außer Haus in Bezug auf Fremdwährungskonten doch oftmals sehr begrenzt sind..)Ist im Moment alls noch in einer süßen kleinen MDB (gepackt ca. 32 MB) in der halt die Lagerverwaltung (und weitere Module) vom hauseigenen Programmierer drinne is. Backend is ne MySQL DB, aber in den meisten Fällen Version 4.19 oder so.... also nix mit Stored Procedures etc.
Und bei jedem modul , wat da dazu kommt spinnt ACCESS 2000 (Jawohl !!, mehr is nicht drinne !!) immer mehr.
DESHALB: C++ !!
-
audacia schrieb:
Martin Richter schrieb:
Ich kenne nicht ein einziges Projekt eines Softwarehauses das mit Turbo C++ abgewickelt wurde.
Vielleicht deshalb, weil es im kommerziellen Umfeld eigentlich "C++Builder" heißt
Ich meinte auch tatsächlich den Borland C++ Bulder 2006 !! - bei Borland nennen sich diese Versionen auch Turbo-Delphi und Turbo C++.
-
DerKleineProgrammierer schrieb:
C++ hat nun mal allgemein und in Bezug auf OOP doch mehr Möglichkeiten.
das stimmt doch garnicht. die meisten anderen OO-sprachen (C# z.b.) setzen OO und das drumherum besser um, als c++.
-
Und bei jedem modul , wat da dazu kommt spinnt ACCESS 2000 (Jawohl !!, mehr is nicht drinne !!) immer mehr.
DESHALB: C++ !!
Naja, diese schlussfolgerung is IMHO ned 100% nachvollziehbar.
C++ ist super, um Prozesse nachzubilden, automaten zu bauen, und um die Performance zu wahren. C++'s Staerke ist eigentlich die enge beziehung zu C und der trotzdem funktionierende OO Ansatz.
Wo C++ gar ned gut ist, ist bei den GUI's, da gibts um laengen bessere Alternativen. Ohne zusaetzliche Libs bleibt dir nur die winapi ... und Leute die Freiwillig winapi programmieren, die schlafen auch auf Nagelbett und peitschen sich selber
es gibt natuerlich tonnen Libs fuer c++ und guis, haben alle ihre vor und nachteile ... allein das richtige framework auszuwaehlen ist schon ne wissenschaft fuer sich ^^
Es ist durchaus gangbar GUI relevante sachen nicht in C++ zu schreiben.
WIr haben hier ne DB landschaft, wo technische daten, protokoll daten,messdaten ... gewartet werden. Und alle gaengigen Frontends sind mittlerweile nach Java portiert wurden. (frueher wars smalltalk). Die anzahl der installierten clients belauft sich auf > 1000
Java ist nur ein beispiel. Denkbar wieterhin waeren Python, Visual basic, ... u.v.mWarum werden im industriellen Umfeld so viele Oberflaechen mit C++ implementiert ?
Imho snds gar ned so viele ....
und oft muss man auf hardwernahe Sprache runter, also brauch man C/C++ programmierer ... dann macht man die gui eben auch in c++ ...Ciao ...
-
es gibt natuerlich tonnen Libs fuer c++ und guis, haben alle ihre vor und nachteile ... allein das richtige framework auszuwaehlen ist schon ne wissenschaft fuer sich ^^
Das is völlig korrekt.
Das Problem ist aber bei JAVA und vielen anderen aufgeführten Sprachen auch nich unbedingt kleiner....
Ich brauch eine Sprache, die nun mal eben sehr universell zu gebrauchen ist - von kleinen Dienstprogrammen bis zu großen Anwendungen.
Und die Unterstützung für Embedded SQL is in C/C++ ja auch nich schlecht.Dass ich mir dafür auf der anderen Seite ziemliche Mehrarbeit und Probleme bei der GUI einhandele
(zumindest am Anfang), is völlig klar....Grüße
DerKleineProgrammierer
-
Das klingt mir wieder nach der alten Diskussion "Welche Sprache ist die beste- vielseitigste- einfachste- am besten geeignete für..." Die Frage ist so nicht zu beantworten. *DIE* universelle beste Sprache gibt es nicht.
Als Profi-Progger beherrscht man meistens mehrere Sprachen, von denen man dann je nach Aufgabe die geeignetste auswählt und für den Rest Kompromisse macht. Wie Du schon selbst sagst:
Das Problem ist aber bei JAVA und vielen anderen aufgeführten Sprachen auch nich unbedingt kleiner....
Für kleine Dienstanwendungen kannst Du eigentlich jede Sprache nehmen. Für große Projekte mußt Du halt auswählen...
-
als profi progger beherschste c und c++. der rest ist wasd für gelegenheitsjobs, eignet man sich kurz an wenn man es braucht oder zu genötigt wird und gut ist.
-
Naja- WIE man sich die anderen aneignet, ist ja egal...
-
Hallo Leute,
Erstmal "villemols Merci" für eure Postings.
Da waren doch einige Denkanstöße dabei,die ich für die Zukunft gut gebrauchen kann.
Nochmals schönen Dank und Grüße
DerKleineProgrammierer
-
Na das ist doch mal eine seltsame Sicht der Dinge...
Programmiersprachen und APIs sucht man eigentlich nach ihrem Einsatzgebiet aus - nicht nach persönlichem gefallen.
So ist z.B. Java erste Wahl, wenn es um Plattformunabhängigkeit geht, aber nicht zu tief in die Hardware gegriffen werden muss. Ganz nebenbei lassen sich solche Applikationen auch noch in kürzester Zeit entwickeln.
Geht es z.B. um Treiberentwicklung, ist nach wie vor C _die_ Sprache.
Insgesamt bin ich aber der Meinung, das neue Projekte, bei denen Java nicht verwendet werden kann/soll, in jedem Fall auf ein portables Toolkit wie wxWidgets oder QT aufsetzen sollten. Software, die sich auf eine betriebssystemtechnische Einbahnstraße begeben haben und nur darauf warten, von flinkeren Konkurrenten auf anderen Plattformen abgelöst zu werden gibt es schließlich genug.
Ach ja...wofür C# gut sein soll, weiß ich übrigens beim besten Willen nicht: Es hat die gleichen Einschränkungen wie Java, ist dafür aber auch noch auf Windows beschränkt (komme mir jetzt bitte keiner mit Mono, das funktioniert nicht wirklich zufriedenstellend).
-
TomoT schrieb:
Na das ist doch mal eine seltsame Sicht der Dinge...
Das sagt der Richtige
TomoT schrieb:
Software, die sich auf eine betriebssystemtechnische Einbahnstraße begeben haben und nur darauf warten, von flinkeren Konkurrenten auf anderen Plattformen abgelöst zu werden gibt es schließlich genug.
Sehr einseitige Perspektive. Plattformunabhängigkeit ist längst nicht alles.
TomoT schrieb:
Ach ja...wofür C# gut sein soll, weiß ich übrigens beim besten Willen nicht: Es hat die gleichen Einschränkungen wie Java
Ganz offensichtlich kennst du C# nicht.
TomoT schrieb:
(komme mir jetzt bitte keiner mit Mono, das funktioniert nicht wirklich zufriedenstellend).
Sagt wer? Beleg?
-
Sehr einseitige Perspektive. Plattformunabhängigkeit ist längst nicht alles.
Richtig. Ich schrieb jaauch "Portabilität"
Was nützen dir irgend wann eine Million ganz tolle Codezeilen, wenn das zugehörige Betriebssystem nicht mehr aktuell ist oder sich der Markt zusätzlich zu anderen Systemen hin bewegt hat? DER Aufwand, das alles zu portieren ist mörderisch - wer clever ist und von anfang an die richtige Entscheidung trifft, hat praktisch gar keinen Mehraufwand.
[quot]Ganz offensichtlich kennst du C# nicht.[/quote]
Doch. Und auch Mono. Ich habe lange genug für ein kommerzielles Projekt darum herumevaluiert. Der Aspekt "plattformunabhängig" ist einfach nicht gegeben.
-
"Plattformunabhängigkeit" ala Java ist die überbewerteste Sache seit Objektorientierung.
-
TomoT schrieb:
wer clever ist und von anfang an die richtige Entscheidung trifft, hat praktisch gar keinen Mehraufwand.
Das ist leider pure Utopie, einerseits wegen "write once, debug everywhere", andererseits, weil du die Produktivitätsvorteile plattformspezifischer Frameworks vernachlässigst.
TomoT schrieb:
Doch. Und auch Mono. Ich habe lange genug für ein kommerzielles Projekt darum herumevaluiert. Der Aspekt "plattformunabhängig" ist einfach nicht gegeben.
Natürlich sind deine Anwendungen nicht wunschgemäß plattformunabhängig, wenn du ein Windows-Programm mit .NET schreibst. Aber es gibt durchaus Szenarien, wo Mono hinreichend mithalten können soll, z.B. ASP.NET.
Abgesehen davon hast du natürlich Recht - .NET ist oftmals noch kein adäquater Ersatz für Java, wenn Portabilität wirklich eine Rolle spielt.
