C++ Anfänger(C# Umsteiger)braucht Stein des Anstosses! (GUI bzw Steuerelement);)

Artchi

derkollo schrieb:

@artchi
Das hätte passieren können...
Ich merk schon, ich muss unbedingt eine Relasebare Version des Programm rausbringen...
"Vorallem werden doch die ersten Programme von dir eh nicht komplex sein"
Wenn du dich da mal nicht täuscht. Mein Programm nach 4 Monaten C# überfordert sogar schon manche C# Kenner! Was aber auch daran liegen mag, weil man musikalisches Verstädniss dafür haben muss. Man muss vor allem wissen was ein 4/4 Takt ist und was MIDI-Befehle sind.
Ich versuche mal, eine releasbare Version zu erstellen, dann können Interessierte dort mal reinschauen.

OK, d.h. du hast in C# eine größere Anwendung in der Mache, die schon eine komplexere GUI besitzt?

derkollo schrieb:

Ich arbeite dort bereits Klassenvererbung, Datenbankanbindung, Polymorphisums (oder wie sich dat schimpft ;), XML Datenspeicherung...
Deswegen bin ich vielleicht stellenweise wirklich ein wenig vermessen, denn was ich mit C# in der kurzen Zeit schaffen konnte, machte mich selbst stutzig!

Ich sehe schon. Genau da liegt der Hund begraben. Wie gesagt, C++ ist sehr komplex. Und auch die Tools dazu. Es gibt auch in C++ Fallstricke, ganz klar. Du wirst auch viel umdenken müssen.

derkollo schrieb:

Und selber programmieren wollte ich die Dinger doch eh! Deswegen ja meine Frage!
Ich möchte quasi wie bereits geschrieben, eine optische Oberfläche "malen", weil man direkt sieht, ob es gut aussieht oder nicht. Bei einer reinen Programmierung muss man jedesmal kompilieren und starten.

Gut, hier muß man wieder eine Anmerkung machen, was in diesem Topic nicht klar wurde: wenn hier alle von "Konsole", "selber Machen" usw. schreiben, geht es immer um das Lernen. Bleiben wir bei deinem Beispiel. Du hast eine komplexe GUI. Du kannst natürlich diese coden aber auch im Designer zusammen klicken. Das zusammen klicken ist hier ja nicht "verboten". Es geht ja nur darum, das du als C++-Anfänger nicht klicken sollst. Und man geht davon aus, das ein Anfänger "kleine Beispielprogramme" schreibt. Denn nur so kann ein Anfänger das System überschauen.

Für gewöhnlich sagt man sich irgendwann: ich verstehe jetzt C++ soweit ganz gut. Ich kann jetzt ein größeres Projekt angehen, und kann auch einen Designer benutzen. Weil ich schon meinen "Gesellenbrief" habe.

Wenn jemand eine Werkzeugmechaniker-Ausbildung anfängt, wird man ihm zu erst eine Feile und einen Metallblock in die Hand drücken. Und dann soll er erstmal machen! Selbst wenn er im Berufsleben fast nie eine Feile benutzen wird. Und wenn er mit der Feile umgehen kann, wird man ihn an die großen Maschinen lassen. Die, die wirklich in der Produktion eingesetzt werden. Weil er dann aus der Erfahrung mit der Feile weiß, wie und was die Maschine macht. Er wird sie viel besser bedienen können und Fehler in der Produktion einfacher finden.

Programmieren ist auch nur ein handwerk. C++ ist ein Tool.

Ich selber benutze auf Arbeit einen GUI-Designer für komplexe Apps. Nur der Unterschied ist, ich weiß, was der GUI-Designer am Ende für Code ausspuckt. Ich kann es sogar vorhersagen!

Niemand will dich davon abbringen, deine GUIs zu designen. Aber besonders bei C++ ist es wichtig, die Basics zu können. Weil die Fehler und Fehlermeldungen manchmal echt "krass" sein können.

EDIT: zu dem immer wieder Kompilieren, wenn man die GUI coded und nicht zusammen klickt. Richtig erkannt. Aber bei Übungsaufgaben ist das ja irrelevant, weil diese ja immer so klein sind. Du hast Recht, das wenn du sehr komplexe GUIs hast, das es da günstiger ist, alles live im Designer zu gestalten. Deshalb haben ja auch die meisten GUI-Libs einen grafischen Designer.

derkollo

th69

Hehe, danke direkt 2 mal. Einmal für die Gute Wünsche und dann noch für die Anmerkung zu dem Disput!
Das bestätigt doch die alte Weisheit: Disput tut gut.

@artchi

Eine größere Sache würde ich es auf jeden Fall nennen. Allein durch die gegebene und ausbaufähige Komplexität. Stichwort Reason (Musikprogramm) Jedoch nutze ich keine Klangerzeugung, sondern lediglich MIDI. Also eine Instrumentsteuerung.
Man kann in einem oder mehreren StepSequencern Takte programieren und die an externe Instrumente senden. In Echtzeit natürlich. 4 mögliche Takte pro Pattern, 32 Pattern pro Gerät. Automatische Patternwechsel, Wiederholungen, Start- Stoppunkte, Aufnahmemöglichkeit, etc etc...
Komplexe GUI? Hmm... viele Buttons und ChecBoxes, fallst du das meinst.
Sich wiederholende Elemente habe ich in Benutzersteuerelemten zusammengefasst.
Aber alles rein VisualC# style...

Ich weiß, dass es bei der Konsole ums Lernen geht. Doch wie du siehst, kann ich mit der Feile schon umgehen.

Wie gesagt, ich wollte keinen seitenlangen Hintergrund schreiben, nur um die Konsole mE gerechtfertig Ablehnen zu können.

Und wie du schreibst, man muss wissen, was bei einem GUI Editor an Code rauskommt! Und darum geht es mir!
Ich muss es für meine Zwecke wissen. Gegenbenfalls muss ich den Code auch anpassen. Alles bewusst und gewollt.

Aber ich möchte nicht für jeden Schritt meinen Code erneut kompilieren müssen, um zu sehen ob alles dort sitzt wo es gut aussieht.

So, ich muss jetzt leider los. (Abendschule, denn man bildet sich ja nicht nur auf einem Gebiet weiter!

Wenn du interesse hast, kann ich dir ja mal den Code von meinem Programm zukommen lassen. Aber natürlich nur mit der dringenden Bitte, dass der Code nicht plötzlich im Netz auftaucht. Ich habe mich noch nicht 100% für ein OpenSourceProjekt entschieden!

asc

derkollo schrieb:

Ich verstehe, was du meinst mit Grundlagen. Es tut mir leid, dass ich als Grundlagen eben direkt etwas optisches brauche. Der Unterschied ist minimal.

Unter C# vielleicht, aber da bei C++ keine Standard-UI existiert, und sich die Programmierung der diversen UI-Frameworks teilweise auf grundsätlich unterschiedliche Paradigmen stützen, sollte man zumindest schon einmal erste Schritte mit C++ ohne diese Probleme gemacht haben.

Davon abgesehen sollte - wenn man ein sinnvolle Projektgliederung vornimmt - ein Großteil des Codes zwischen Console und Klicki-Bunti austauschen lassen. Unter C++ lässt sich vieles auch schneller ohne UI testen, wenn man gerade etwas experimentiert.

derkollo schrieb:

Oder sehe ich das falsch? Ich habe gute Bücher zum coding hier. Aber leider nur zum Coding.

Weil alle Bücher (zumindest die guten) die sich mit UI unter C++ beschäftigen, schon gewisse Grundlagen voraussetzen. Selbst in den Büchern, die einen Einstieg in C++ und die UI-Programmierung geben wollen, habe ich selten UI-spezifisches in der ersten Hälfte des Buches gesehen.

derkollo schrieb:

Den Tip mit dem Konsolenprogramm, kann ich gut verstehen. Aber entschuldigt, dass ich denke, dass man Grundlagen auch an einer grafischen Oberfläche lernen kann.

Wie gesagt sehe ich dies sprachabhängig (Aber selbst in C#, Java und Co würde ich zumindest die absoluten Grundlagen ohne UI erwarten), in C++ mangelt es halt daran, das sich kein UI-Framework wirklich in die Sprache integriert (wo andere Sprachen dies als Bestandteil ihrer Sprachbibliothek integrieren, und sich dieser Teil auch als "Sprachbestandteil" anfühlt).

derkollo schrieb:

Und warum denkst du, dass ich die Grundlagen gänzlich ignoriere? Weil ich keine HelloWorld Programm schreiben möchte? Weil ich keine Animal BaseClass erstellen möchte, in der ich dann virtuelle Funktionen erstelle um sie an meine CatClass zu vererben?

In C++ muss man auch Pointerarithmetik verstehen und man sollte sich vielleicht auch die Sprachkonzepte ansehen, die C++ von C# unterscheidet (z.B. welche Konzepte die Standardbibliothek abbildet, und wie in etwa diese funktioniert - da hier andere Paradigmen gelten als z.B. beim .Net Framework).

derkollo schrieb:

Natürlich ist der Umgang mit Alloc usw aber absolutes Neuland für mich, da in C# nicht nötig.

Wenn du in einen C++ Buch "alloc" siehst, ist es wahrscheinlich eher ein "C mit Klassen"-Buch. Die meisten C++ Bücher sind in der Qualität eher ... mässig, und waren schon zum Zeitpunkt der Veröffentlichung veraltet.

Falls du aber wirklich schnell, schnell, schnell in UI-Programmierung einsteigen willst, wäre wohl der C++ Builder etwas für dich. Dieser ist aber a) recht teuer und b) hat er einige Probleme mit der Sprache... Die kostenlose Variante (ich glaube Turbo C++ 2006 oder so) ist leider sehr mangelhaft, wenn es darum geht einigermaßen aktuelle C++ Bibliotheken zu verwenden (wie Boost).

derkollo

@asc

Danke auch dir nochmal für die ausführliche Antwort. Mittlerweile wurde mir auch bewusst, das meine Art auf jeden Fall etwas zu blauäugig wirkte.

Andererseits fühle ich mich in meinem Denken bestärkt, denn wenn eine GUI maßgelblich mitentscheidend für den Programmierstil ist, sollte man doch direkt von Anfang an schauen, dass man in "die richtige Richtung" lernt. Richtig?

Es bringt einem ja nichts nach Bequemlichkeit zu gehen. Und das passiert, wenn man mit "kleinen" Sachen anfängt. Man gewöhnt sich unter Umständen an Programmiertechnicken, die in größeren Projekten dann wieder eher kontraproduktiv wirken können. Zum Beispiel hat mich ein "simples" Array in meinem Projekt viel Zeit gekostet, da ich alle Daten in Arrays abgelegt habe, welche beim Patternwechsel zu timingproblemen führten. Auf jeden Fall habe ich mir dann ein DataSet geschnappt und gemerkt wie angenehm das Handling von sich wiederholenden Arrays sein kann....

Ich versuche ja schon mir den optimalsten Weg zu suchen. Und damit meine ich nicht den den leichtesten Weg....

Ich denke aber, bei den Büchern eine gute Wahl getroffen zu haben:

- Maximum MIDI - Music Applications in C++ (zwar fast so alt wie die Sprache, aber immer noch eine Referenz in Sachen MIDI-Programmierung)

- Die C++ Programmiersprache von Stroustrup (Als mächtiges Nachschlagewerk und für Hintergrundwissen)

Und - Moderne C++ Programmierung (günstiges Schnäppchen)

Darüberhinaus blättere ich online in Thinking in C++.
Auch wenn sich Anfangs viel überschneidet, stehen halt in einem Informationen die im anderen außen vor gelassen werden.

Angesichts dieser recht guten "Grundausrüstung" war ich ja auch so erstaunt über das Minimum an Infos über UI-Programmierung.
Das wiederum, war Anlass zu meinem Post hier.

Wo ich speziell das alloc gelesen habe, kann ich dir spontan nicht sagen. Aber ich glaube es kam in der Tat, nach dem Pointer der ebenfalls für mich neu ist.

Und AHHHHH schnell, schnell, schnell, will ich hier schon mal garnichts!
Habe ich nie behauptet! Ich habe behauptet, dass ich (aufgrund meiner verdrehten Art, die keinen hier etwas angeht ) effektiver lernen kann, wenn ich mit der Programmierung einer UI anfange. Einer simplen kleinen UI mit 16 harmlosen Lämpchen, deren einzige Funktion sein soll, gewünschtes Lämpchen "leuchten" zu lassen. Oder einer Reihe von CheckBox ähnlichen Buttons...
Diese UI hätte ich dann nutzen können um direkt optisch meinen Code zu testen.
Nach und nach, hätte ich dann Stück für Stück, das aufbauen können, was ich als Ziel vor Augen habe...

Ich wollte mir niemals Arbeit ersparen, oder eine rein bequeme Möglichkeit finden!
Ich möchte nur wissen, in welche Richtung ich arbeiten muss, um mein Ziel qualitativ umzusetzen! Würde es mir um eine andere Geschwindigkeit als die der Laufzeit meines Programmes geben, hätte ich die 0815-Elemente von VisualC++ genommen und damit auf biegen und brechen mein Ding durchgezogen!
Nein, garnicht wahr. Ich wäre bei C# geblieben!

Auch wenn ich mein "UI-Ergebnis" gerne in der ToolBox gesehen hätte, dann nicht um es mit wenigen Klicks irgendwo einfügen zu können, sondern um:
1. Eine langfristig gute Übersicht über die in meinem Projekt verwendeten UI-Elemente zu behalten (Es werden ca 10-20 einzelne Elemente)
2. Ein gewisses Gefühl von "Professionalität" zu haben. Denn auch wenn per Code eingefügte Elemente das selbe Ergebnis liefern, macht sich ein Karteireiter mit eigens erstellten Elementen in der ToolBox doch um einiges netter.

Es war nie geplant, dass als "Abkürzung" zu nuzten, sondern um das Ganze angemessen abzurunden. Denn was nutzt der beste Code, wenn die UI wie ein 0815 Windowsfenster aussieht? Fast jeder User wird ein Programm mit "gepimpter" Optik, aber minimal schlechterem Code, einem schlecht aussehendem Programm vorziehen. Zumindest die meisten Nutzer. Nur HardcoreFrickler mögen natürlich minimale Optik und wissen den mächtigen Code zu schätzen.

Also, für mich erstmal abschließend, Danke für die Aufklärung!!

Meine ursprünglichen Fragen sind definitv fürs erste geklärt.

Wenn der Prototyp vorzeigbar ist, werde ich das Ding hier einmal posten. Ich wäre dann wirklich für eure Tipps und Ratsschläge dankbar, wie ich das Ganze am besten in C++ realisiere...
Allein schon in Bezug auf Performance....

Aber das alles zu seiner Zeit.

Grüße

asc

derkollo schrieb:

Andererseits fühle ich mich in meinem Denken bestärkt, denn wenn eine GUI maßgelblich mitentscheidend für den Programmierstil ist, sollte man doch direkt von Anfang an schauen, dass man in "die richtige Richtung" lernt. Richtig?

Nach meiner Meinung sollte man sich nie zu sehr von einem UI-Framework abhängig machen (sinnvolle Schichtentrennung), da nach meiner Erfahrung am ehesten der UI-Teil ersetzt wird (sei es durch eine Migration auf ein anderes Betriebssystem, falls man ein OS spezifisches Framework gewählt hat, sei es weil der Support eingestellt wird...).

Logik - wenn sinnvoll getrennt - ist meist weitgehend portabel.

derkollo

asc schrieb:

Nach meiner Meinung sollte man sich nie zu sehr von einem UI-Framework abhängig machen (sinnvolle Schichtentrennung), da nach meiner Erfahrung am ehesten der UI-Teil ersetzt wird (sei es durch eine Migration auf ein anderes Betriebssystem, falls man ein OS spezifisches Framework gewählt hat, sei es weil der Support eingestellt wird...).

Logik - wenn sinnvoll getrennt - ist meist weitgehend portabel.

Ok, dass klingt logisch. Den Aspekt der Portabilität habe ich bis jetzt noch nicht genug bedacht... Ich werde mich wohl echt erst noch ein paar Wochen durch diverse Artikel und Tutorials lesen müssen, bevor ich ernsthaft daran denken kann, mein Programm in C++ umzusetzen...

derkollo schrieb:

Denn was nutzt der beste Code, wenn die UI wie ein 0815 Windowsfenster aussieht? Fast jeder User wird ein Programm mit "gepimpter" Optik, aber minimal schlechterem Code, einem schlecht aussehendem Programm vorziehen.

nö, von mir aus kann ein programm 'ne super-schäbige gui haben, hauptsache es ist stabil und macht immer was es soll. und gerade bei GUIs ist weniger mehr. sinnvoll angebrachte und funktionierende steuerelemente etc. sind besser als künstlich aufgeblähter grafischer firlefanz. bunt, kitschig sinnlose animationen usw. verwirren nur und bringen überhaupt nix. mit webseiten ist es genauso.

asc

;fricky schrieb:

nö, von mir aus kann ein programm 'ne super-schäbige gui haben, hauptsache es ist stabil und macht immer was es soll.

Ausnahmsweise etwas wo unsere Meinungen mal relativ nah beieinander liegen.

Wobei ich persönlich Programme besser finde, die zumindest eine gewisse "Grundoptik" haben. Damit meine ich das sie Optisch zumindest grundlegend zu dem OS-üblichen optischen Umfeld passt, und auch die Steuerung sollte sich möglichst ähnlich anfühlen.

Wobei Optik erst nach Stabilität (\flamewar=on Warum ich C++, C vorziehe ;p \flamewar=off) kommt.

cu André

asc schrieb:

Wobei Optik erst nach Stabilität (\flamewar=on Warum ich C++, C vorziehe ;p \flamewar=off) kommt.

ah, endlich ist er da, der flamewar *fg*
wie kann C++ stabiler sein als C? bei beiden sprachen sorgt fast ausschliesslich der programmierer für stabilität oder instabilität. dass C++ code im verhältnis zu C robuster oder sicherer ist, ist nichts als ein hartnäckiges gerücht. ich behaupte sogar, dass die chance, schlechte software zu basteln, mit C++ weitaus grösser ist, als mit C.

nachteule schrieb:

Ja, willkommen in der C++ Community. Im Gegensatz zu anderen Programmierer-Communitys ist man hier fest davon überzeugt die Krone der (Programmierer-)Schöpfung zu sein, und dementsprechend ist hier auch der Ton der Mitglieder, denen ich dringend empfehlen würde mal in ein anderes Forum zu blicken, denn es geht auch anders. Ich weiß leider auch nicht woran das liegt, vielleicht sind die alle so gefrustet weil sie mit miesen IDEs arbeiten müssen, damit schließt sich der Kreis wieder

Es liegt am Smily.