Hallo,
ich habe ein Programmiertutorial zum Thema Programmierfallen erstellt und auf YouTube veröffentlicht:
https://youtu.be/1U-v84M-1t0
Gibt es noch weitere Themen, wo ihr noch ein Tutorial dieser Art sucht?
Hallo,
ich habe ein Programmiertutorial zum Thema Programmierfallen erstellt und auf YouTube veröffentlicht:
https://youtu.be/1U-v84M-1t0
Gibt es noch weitere Themen, wo ihr noch ein Tutorial dieser Art sucht?
Vielen Dank für die Erleuchtung, so Leute bräuchte es viel mehr. Das Video kann ein Jahrzehnt grübeln einsparen.
Dachte das wäre nur bei SPS Simatic so und deshalb nervig, weil z.B. Ausgänge nur einmal belegt werden können.
Jetzt find ich es genial und habs auch verstanden. Ein Irrweg dorthin war Logikmodul LOGO!
Betreff objektorientierte Programmierung ist mir z.B das Herausarbeiten welche Daten (oder Zustände) ich den
Eigenschaften oder Methoden() und set() get() zuordne ein weiterer Hemmschuh.
- - - Aktualisiert - - -
Ja und für welche Problemstellung ist objektorientierte Programmierung unumgänglich?
gar nichts ist hier unumgänglich, auch C++ wurde ja als Erweiterung von C alleine mit den C-Bordmitteln möglich, also kann man es z.B. auch selber ohne die ++ Erweiterung alleine mit ANSI C (C99) schaffen. Java hat dann C++ nur von Grund auf neu erfunden (ohne historischen C-Ballast, sogar main() ist hier eine OOP-Methode).Zitat von ces
OOP (C++, Java, Pascal/Delphi, C#,...) macht aber vieles sehr viel einfacher, wenn man eine große Anzahl gleichartig oder ähnlich funktionierender Funktionsstrukturen hat (=> mehrere Instanzen derselben Basis-Objekts), und wenn einige davon sich nur in wenigen Details von anderen unterscheiden (=> Vererbung).
Beispiele:
- Fensterobjekte mit gleichartigen Grundsteuerungen sowie optionalen Menüs und Gadgets in GUI-Applikationen
- Simulationsspiele mit-zig Spielfiguren, die dort alle gleichartige oder ähnliche Grundeigenschaften und Funktionsfähigkeiten haben (Age of Empires, Civilization, Siedler, Fifa, MarioCart, Lemminge, ...)
- Softwaredriver für mehrere Implementierungen von gleichartigen Hardware-Devices (gleichartige Grundobjekte für verschiedene Displays wie bei Adafruit GFX mit identischer API, mehrere Instanzen derselben Device-Objekte, wenn nicht nur 1, sondern viele davon parallel betrieben werden sollen,...)
Es geht auch hier sicher ohne OOP, aber mit OOP muss man nicht immer wieder das Rad neu erfinden.
Naja, ein paar Designentscheidungen, die sich bei C++ als häufige Fehlerquelle erwiesen haben, wurden schon besser gelöst. Keine Mehrfachvererbung, und Pointer mußte man in Java auch noch niemandem erklären. Oder gar Pointerarythmetikfehler beheben. Oder das Überschreiben fremder Speicherbereiche.
Ganz genauso ist es. Ich möchte noch anfügen, daß sich die Realität objektorientiert oft sehr einfach beschreiben läßt. Und manche sehr komplexe Problemstellung läßt sich objektorientiert wunderbar elegant lösen, wenn man sich mal ein paar Entwurfsmuster ansieht. Das Dekoratormuster ist da so mein Lieblingsbeispiel:
https://www.philipphauer.de/study/se.../decorator.php
Man kann sowas natürlich auch prozedural lösen, sogar in Assembler...aber warum will man das, wenn es auch anders geht?
Kurze Frage noch bevor ich mich mich mal versuche.
Es gibt für dieselbe Problemstellung immer nur eine einzig richtige Beschreibung und Entwurfsmuster?
Jeder z.B. C++ Programmierer würde zum selben Ergebnis kommen und es dann "einfach" innerhalb der Methoden etwas anders umsetzen?
- - - Aktualisiert - - -
Ach ja und ist es Plicht sich um Garbage Collector und Exceptions (sieht man selten) explizit zu kümmern?
Bin am Buch "Java in 21 Tagen" kläglich gescheitert. Habe genau 0 verstanden, Java gewählt weil kein GC notwendig.
- - - Aktualisiert - - -
Mein Hello World das ich mir immer aussuche ist meine Waschmaschiene:
Anhang 34404
Konkrete "Basisgerichte"
Pumpen Abpumpen Heizen Waschen Spülen Schleudern
Konkrete "Beilagen"
Temperatur Umdrehungszahl Optionen ExtraSpülen
Danke für das Feedback. Tatsächlich ist C++ formal nicht einfach nur eine Erweiterung von C, sondern gilt als eigenständige Programmiersprache. Es gibt Konstrukte, die nur in C funktionieren, aber nicht in C++.
Ich denke auch die Unterschiede von objektbasierter (C) und objektorientierter (C++) Programmierung könnten interessant für einen Beitrag sein.
Das Gesetz von Demeter ist sicher auch Interessant.
die Fälle, in denen C-Konstrukte nicht sofort in C++ funktionieren, kann man an 1 Hand abzählen - meist liegt es daran, dass z.B. C gewisse Ungenauigkeiten zulässt, die bei C++ nicht direkt funktionieren, weil es reservierte Keywords sind oder man Statements präzisieren muss, z.B. :
Das ist aber derart ausgesucht, dass es IMO vernachlässigbar ist.1) new is a keyword in C++ so can't be used as a variable name.
2) C++ doesn't allow automatic pointer conversion.
3) C++ doesn't allow you to call undeclared functions.
4) in C++ struct and typedef have the same scope so the same identifier can't be used for each, in C they are separate.
5) ISO C++ forbids converting a string constant to ‘char*’ )
Tatsächlich ist C++ definierbar als {C plus Objekte plus Stream plus Überladung}, und von daher ist C durchaus eine Untermenge von C++.
C würde ich als prozedural vs. C++ = objektorientiert definieren - C++ lässt aber auch weiterhin rein prozedurales Programmieren zu oder Mischformen (weil es die vormalige C-Syntax samt ihrer Möglichkeiten ebenfalls noch zulässt), anders als andere rein objektorientierte Sprachen wie Java.
Viele meiner prozeduralen C-Programme (mit wiringPi, openVG und pthread auf dem Raspi) lassen sich sowohl mit GCC (C99 oder C11 usw.) als auch - völlig unverändert - mit g++ (C++11/14) kompilieren und starten, und wenn man dann Objekte hinzunimmt, läuft alles nach wie vor mit C++ weiter (aber dann ntl nicht mehr mit ANSI-C).
Geändert von HaWe (28.09.2019 um 18:38 Uhr)
Das ist die Entwicklung die ich bedauert habe.Da mein Programm aber auf normalen PCs/Laptops läuft ist es mir egal ob da jetzt ein paar hunderttausend Taktzyklen mehr bei der Ausführung benötigt werden und ob das Programm jetzt mit 30MB oder 50MB im Speicher rumliegt.
ja, auch ich finde, dass OOP ein gutes Thema ist für Tutorials.
Allerdings ist die Umsetzung so stark PL-abhängig, dass ein sinnvolles Tutorial PL-spezifisch sein sollte (höchstens eine SEHR kurze Einfühung mit Flowcharts) - andernfalls versteht man nur, wie es grundsätzlich funktionieren KÖNNTE, scheitert aber bereits beim PL-spezifischen Objektdesign und erst recht dann bei der korrekten Implementierung von Methoden und der späteren Instanziierung.
Da hier im Forum wesentlich mehr Leute C++ als irgendwas anderes nutzen dürften (allein schon alle Arduino-Nutzer, aber auch auf dem Pi ist C++ verbreiteter als z.B. Java), würde ich zumindest konkrete Beispiele in C++ empfehlen.
Wichtig fände ich es auch, dass man (zumindest fast) alle Resourcen zum Tutorial in Schriftform downloaden kann (pdfs und Sourcecode, am einfachsten über github!)
Entwurfsmuster an sich kann man schon sehr allgemein erklären, da gibt es nur sehr wenig was programmiersprachenspezifisch ist (z.B. Vererbungsbäume kreuzen erlaubt ja/nein). Aber die meisten OO-Sprachen haben, was ihren Funktionsumfang angehe, doch eine recht große Schnittmenge. Die Bezeichnungen für ein und dasselbe sind vielleicht unterschiedlich.
Ich habe, als ich mich mit OOP befasst habe, mal das Buch Entwurfsmuster von Kopf bis Fuß durchgearbeitet (sehr gutes Buch). Da wurde alles mit Java-Code erklärt mit dem Hinweis, daß alles in C++ genauso funktioniert. Bis auf ein Detail, die in C++ umsetzbar ist, in Java aber nicht wegen der verbotenen Kreuzvererbung.
Da man mit Java auf Mikrocontrollern aber leider nicht allzuweit kommt wäre C++ vielleicht wirklich nicht schlecht, aber besser wäre m.E. wenn das programmiersprachen- und problemunabhängig wäre. Damit können Systematiken besser in den Vordergrund gerückt werden und es artet weniger in stumpfem Nachmachen aus.
Ist das ein Witz, den ich nur nicht verstehe? Richtiger ist doch viel mehr "Viele Wege führen nach Rom".
Berechtigungen
Zitieren
Lesezeichen