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.

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

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.

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

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++ !!

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++.

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.m

Warum 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

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...

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

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).

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.

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.

Das ist leider pure Utopie, einerseits wegen "write once, debug everywhere"

Das stimmt natürlich, einen gewissen Debuggingaufwand hast du in jedem Fall. Dennoch sehe ich den Aufwand, eine Applikation komplett zu portieren immer noch als wesentlich größer an, als eine bisher vernachlässigte Plattform nachträglich noch zu debuggen/die notwendigen kleinen Anpassungen vorzunehmen. Clevere Programmierung natürlich vorausgesetzt - wenn du einen Entwickler im Team hast, der dann doch irgend welche systemspezifischen Krämpfe verwendet, bist du eh im Ar***

Einen positiven Nebenaspekt gibt es allerdings auch, wenn du auf verschiedenen Plattformen compilierst: der Code wird _wesentlich_ sauberer, da die unterschiedlichen Compiler sich in dem, was sie akzeptieren und was nicht, doch immer noch ein wenig anders verhalten. Und sauberer Code hat der Stabilität noch nie geschadet.

Aber es gibt durchaus Szenarien, wo Mono hinreichend mithalten können soll

Mono hat seine Nische, ganz klar. Nur ist es eben so, dass gerade hier mit Java eine sehr starke Referenz existiert. Und wer beide Welten kennt, stellt sich sicher irgend wann die Frage, warum er mit .NET/Mono auf einen so kleinen gemeinsamen Nenner setzen soll, wenn es doch auch anders geht. Speziell unter dem Aspekt betrachtet, das Projekte gerne mal aus dem Ruder laufen und sich die ursprünglich mal ganz scharf umrissenen Requirements plötzlich explosionsartig vermehren. Da kann dieser "kleinste gemeinsame Nenner" sehr schnell und vor allem unvorhersehbar zu einem "zu kleinen gemeinsamen Nenner" werden.

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.

Ich bezweifle, dass wir hier noch den Tag erleben werden, an dem Linux Windows auf dem Desktop abgelöst hat. Und so portabel zu programmieren, dass die Möglichkeiten des einen Betriebssystems so ausgenutzt werden, ohne das andere zu vernachlässigen, ist auch nicht ganz einfach. Meistens läuft es hier nämlich auf den kleinsten gemeinsamen Nenner hinaus. Also lieber eins richtig unterstützen als mehrere nur halbherzig.