Hallo zusammen :) Direkt vorweg, ich suche nicht nach einem "Was ist die bessere Sprache, Java vs. HTML5" sondern viel mehr, welche Sprache es sich lohnt, für meine aktuellen Bedürfnisse zu lernen. Daher kurz zu meinem Backround. Ich bin Elektrotechnik-Ingenieur und befasse mich beruflich und auch privat mit der Entwicklung von eingebetteten Systemen und der hardwarenahen Programmierung. Hierfür nutze ich entsprechend C als Sprache der Wahl. Da ich privat beginne meine entworfenen Lichtansteuerungen und Sensoren über Funk (Bluetooth/WLAN) vernetzen zu wollen (Stichwort Home Automation), dachte ich mir dass es sinnvoll wäre eine zweite Programmiersprache zu lernen. Was ich machen möchte lässt sich leicht erklären: Ich möchte in der Lage sein, Desktop oder ggf. auch Smartphone Applikationen zu schreiben, um mit meinen Schaltungen über die verfügbaren Funk- oder Hardwareschnittstellen wie bspw. USB beim PC, kommunizieren und Einstellungen vornehmen zu können. Eine Idee wäre hier bspw. verschiedene Beleuchtungen über eine Desktop-App zu gruppieren und einstellen zu können. Das ganze dann über die WLAN-Verbindung oder über eine, per USB an den PC angeschlossene, Hauptstation. Zusätzlich wäre es für mich noch praktisch, wenn ich es auch beruflich eventuell einbringen könnte, indem man (Web-) Applikationen schreibt um bspw. Tests oder Betriebsmittel verwalten zu können oder Oberflächen für Testautomatisierungen zu programmieren welche als Basis auf einem Mikrocontroller laufen. Nach einer kurzen Recherche bin ich dabei auch schnell zu Java tendiert, da man hiermit, meines Wissens nach, alle diese Funktionalitäten erfüllen kann. Besonders da Java auch recht plattformunabhängig ist. Doch erinnerte ich mich, dass mir ein Kollege mal erzählte, dass man mit HTML5 in Kombination mit CSS und Javascript (HCJ ab jetzt genannt) auch viele Applikationen in diese Richtung programmieren könnte. Da HTML und CSS für mich bis dahin nur Beschreibungssprachen für Websites waren, hab ich eine tiefere Recherche durchgeführt, welche mich mit mehr Fragen hinterlässt als mir beantwortet wurden. Nach meiner Recherche ist es nämlich angeblich möglich Desktop-/ Smartphone und auch Web-Apps, welche den oben genannten Umfang erfüllen sollen, auch mittels HCJ zu entwickeln. Besonders attraktiv für mich kam mir die Möglichkeit, alle Applikationen als Web-App zu designen über welche man spielend von verschiedenen Systemen drauf zugreifen könnte und und diese ggf. über Wrapper an Native Systeme zu binden, vor. Zumindest wie ich es verstanden hatte, würde dies alle Funktionalitäten abdecken welche für mich von Interesse sind. So könnte eine Web-App entwickelt werden welche vom PC ausgeführt wird und über USB/WLAN mit den verschiedenen entwickelten Aktoren kommuniziert oder eine Smartphone-App, sei es über den Browser oder mittels Wrapper als eigenständige App, mit welcher man automatisierte Tests verwalten kann indem Daten empfangen und abgelegt werden. Das Problem dabei ist, dass ich nicht wirklich herausfinden konnte in welchem Umfang dies alles möglich ist, weswegen ich gerne hier nach Meinungen fragen möchte, ob Java oder HCJ die bessere Wahl für mich ist? Als Versuch dies herauszufinden habe ich, da ich mich auch für neuronale Netzte und Deep Learning interessiere, gesucht, ob dies über HCJ möglich wäre. Auch hier wurde ich fündig, dass Deep Learning über HCJ-Apps und passenden Libraries gar kein Problem wäre... Meine Freizeit ist leider etwas begrenzt weswegen ich nicht die zeitlichen Ressourcen habe mich in 2 Sprachen einzuarbeiten. Meine Fragen daher: 1. Welche Sprache ist für meine Anforderungen wohl besser geeignet? 2. Kann man über HCJ wirklich auch komplexe Programme mit etwas tiefgehenderen Algorithmen für bspw. neuronale Netzte entwickeln? Ich entschuldige mich für den langen Post, hoffe auf ein paar konstruktive Beiträge und freue mich auf eure Antworten. Viele Grüße Ein Gast :)
Für dich wäre für eine Webapp HTML5 und Javascript interessant. Falls du das ganze noch Stylen willst kannst du auch gerne noch zu CSS greifen.Alle Sprachen sind nicht so schwer und es gibt auch jede menge Artikel im Internet darüber.
Hallo und danke für die Antwort :) Wäre es mit diesen Tools denn auch möglich Desktop-Apps und eventuell auch ein umfangreicheres Programm für neuronale Netzte, Deep Learining, oder Messdatenverarbeitung zu schreiben? Ich möchte ja eine Applikation schreiben welche nicht nur geschlossen im Web agiert sondern mit welcher ich auch Sensoren und Mikrocontrollerschaltungen ansteuern kann (Funkkommunikation oder bspw. seriell über USB ComPort). Viele Grüße Ein Gast
Lerne erstmal programmieren. z.B. mit dem vorgeschlagenen Javascript. Wenn du programmieren kannst, ist der Wechsel von einer zu einer anderen Programmiersprache einfach. Und ja, mit Javascript+HTML kann man Desktop und Händie-Apps erstellen (-> Electron, cordova, ...) Man kann neuronale Netze trainieren (deeplearn.js/tensorflow.js) Man kann IOT-Sachen ansteuern (über MQTT, Websocket, XHR, ...) Man kann sogar µC damit programmieren (https://www.espruino.com/)
:
Bearbeitet durch User
HTML, CSS, Javascript, usw sind Websprachen, optimiert zur Darstellung. Die grad genannten sind nicht entweder-oder, sondern zwingend UND. Es gibt allerdings auch Erweiterungen, im Sinne von Libraries, die eine Kommunikation mit einem Serialport erlauben. Dazu muesste man zu den Libraries noch AJAX koennen. Dieses Alles wuerd ich mir aber nicht aufs Mal antun wollen. Dann besser die Webseite grad auf dem Controller generieren. Obwohl, dann ist man ja auch wieder bei den Websprachen. Ein Programmablauf einer Websprache ist allerdings sehr verschieden zu einem Programmablauf auf einem PC oder sonstigen computer.
Εrnst B. schrieb: > Wenn du programmieren kannst, ist der Wechsel von einer zu einer anderen > Programmiersprache einfach. > > Und ja, mit Javascript+HTML kann man Desktop und Händie-Apps erstellen > (-> Electron, cordova, ...) Hallo und Danke für die Antworten :) Also würdet ihr mir im allgemeinen schon raten die genannte Kombination aus HTML, CSS, Javascript und ggf. Ajax zu lernen, anstatt mich mit der Java-Programmierung auseinander zu setzen? Das der Ablauf verschieden zu dem Programmablauf auf dem PC ist, wäre für mich vorerst kein Hindernis. Da ich so oder so eine neue "Programmier-Denkweise" lernen müsste. Bei Java halt die Objektorientierung und bei HTML & co. den Web-Aspekt. Bin weiterhin dankbar für Antworten :) VG Ein Gast
HTML/CSS sind keine Programmiersprachen, sie dienen zur Beschreibung einer Seite zur Anzeige im Browser. Ansonsten: C. Ich wühle mich gerade in C++ rein und fühle mich wie in den Mühlen der deutschen Bürokratie ...
Aus meiner Erfahrung würde ich dir zu einem Webinterface als Oberfläche raten. Es läuft in allen Browsern und damit z.B. auch einfach auf einem Tablet. Du kannst es problemlos über LAN/WLAN verteilen und über VPN sogar übers Netz. Die Protokolle sind schon da, es ist also einfacher, als selbst etwas auf TCP/IP auszubauen. Damit bist du automatisch bei HCJ. Jetzt braucht man noch eine Gegenstelle, die die statischen Dateien der Webseite ausliefert und eine dynamische Schnittstelle für die Steuerbefehle/Abfragen bietet. Diese würden dann auf deinem Steuerrechner als Server laufen. Hier kann man im Prinzip jede Sprache verwenden, aber auch hier kann man JavaScript verwenden (node.js) und muss damit nicht noch eine weitere Sprache lernen. Ernst hatte ja hier eine paar Bibliotheken genannt. Selbst wenn du direkt am Steuerrechner arbeiten willst, kannst du auch dort einfach mit dem Browser auf localhost zugreifen. Nachdem du ja in C Programmieren kannst, würde ich an deiner Stelle mal ein JavaScript Tutorial machen. Von der Logik sind die Sprachen gar nicht so unterschiedlich, aber in JavaScript macht man es doch meistens etwas anders. Außerdem kommt dann noch die Verknüpfung mit dem HTML Dokument Baum dazu. Kleine Testprojekte kann du auch immer lokal im Browser machen, die haben in den Entwicklertools auch mittlerweile gute Debugger für JavaScript. Erst wenn du dich dort gut eingearbeitet hast, dann würde ich mich um den Serverteil mit JavaScript kümmern. Für mein bisher einziges ernsthaftes Projekt habe ich das express Framework für den Server und React für das Frontend zusammen mit npm benutzt. Man kann das auch alles selbst machen, aber mittlerweile würde ich dort immer ein Framework einsetzen, außer das Projekt soll garantiert nie fertig werden (macht ja auch Spaß :-) ).
Ich würde dir auf jeden Fall raten, ein Buch aus der Von-Kopf-Bis-Fuß-Reihe zu lesen. Es gibt sowohl für JavaScript, HTML und CSS, HTML5 sowie Java ein Buch aus der Reihe. Solltest du dich für Java entscheiden würde ich dir auch dringend Entwurfsmuster von Kopf bis Fuß dazu empfehlen.
Ein Gast schrieb: > Ich bin Elektrotechnik-Ingenieur und befasse mich beruflich und auch > privat mit der Entwicklung von eingebetteten Systemen und der > hardwarenahen Programmierung. Hierfür nutze ich entsprechend C als > Sprache der Wahl. > > Da ich privat beginne meine entworfenen Lichtansteuerungen und Sensoren > über Funk (Bluetooth/WLAN) vernetzen zu wollen (Stichwort Home > Automation), dachte ich mir dass es sinnvoll wäre eine zweite > Programmiersprache zu lernen. Auf dem Gerät, das die Hardware anspricht, würde ich bei C bleiben. Für die Bedienung ist allerdings ein Webinterface ideal. Damit eignet sich dann jedes Gerät mit Browser( also PC, Tablet oder Smartphone) als Kontroll- und Bedienelement. Ich würde dir also empfehlen, dich mit HTML, CSS und Javascript zu beschäftigen. Mit C kannst du dann Programme schreiben, die diese Dateien generieren und die Eingaben auswerten. So etwas mache ich gerade für eine Messwerterfassung und Steuerung auf einem "headless" Raspi.
Vielleicht ist auch das für dich interessant : https://www.b4x.com/b4j.html Läuft zwar auch auf JAVA raus, man hat aber viele Libraries (Serial, Bluethooth, usw.) schon dabei.
Als Ausbilder von (angehenden) Ingenieuren stellen wir uns fast jedes Semester erneut die Frage, was wir den Studenten aufgrund neuer Entwicklungen als "wichtige" Technik beibringen sollen. Dabei nimmt oft die Verunsicherung mit der Tiefe der Recherche zu, denn die Marktmacht großer Konzerne (Google, Amazon, etc.) setzt Trends und sie stellen entsprechende Möglichkeiten zur Teilnahme bereit. Hier können/dürfen wir allerdings nicht kritiklos solchen Trends folgen. Die Sprache C wird an der Hochschule Hannover (Elektro- und Informationstechnik) bereits im ersten Semester gelehrt. Für das 5./6. Semester bieten wir in der Vertiefungsrichtumg "Elektronik" Labore zur Anwendung von Mikrocontrollern an, die sich zum großen Teil an der Arduino-Umgebung orientieren und damit auf C/C++ aufsetzen. Es wird allerdings nicht verlangt, C++ zu beherrschen, sondern die Möglichkeiten der GNU-Compiler (IDE ist Eclipse) zu nutzen, mit C anzufangen und schrittweise (bei Bedarf) auf C++ zu erweitern. Da fängt man zunächst mit einfachen Klassen an und lernt in kleinen Schritten (learning by doing) dazu. Gelehrt wird ebenfalls das Zusammenspiel netzwerkfähiger Geräte (Mikrocontroller mit LAN/WLAN, Smartphones, Tablets, etc.) für sog. cyber-physische Systeme und das Internet der Dinge, wobei konkrete Anwendungen auch die Heimautomatisierung betreffen. Hier wird Android Studio zur Entwicklung von APPs eingesetzt, was im Regelfall die Sprache Java voraussetzt (Möglichkeiten zur Nutzung von C/C++ für APPs werden gerade recherchiert). In den entsprechenden Laboren wird allerdings Java auch nicht vorausgesetzt, sondern es werden von den Studenten lauffähige Beispielprogramme (identische Anwendungen in C/C++ für MC und in Java für APPs zum Vergleich) für eigene Anwendungen erweitert. Man muss hier einfach den Umstand berücksichtigen, dass zum Verstehen und Anwenden der vielfältigen (grafischen) Objekte aus der Android-Umgebung ein deutlich höherer Aufwand erforderlich ist, als zum Erlernen der Sprache Java selbst. So gesehen kommen unsere Absolventen (Elektronik) also bez. der Programmiersprachen mit den Schwerpunkten C/C++ und Java ins Berufsleben. Für typische Web-Server stehen ihnen bei den Laboren entsprechende Bibliotheken in den beiden Sprachen zur Verfügung. In diesem Rahmen kommen sie auch mit PHP in Berührung, basierend auf den Umgebungen LAMP (Linux) und XAMPP (Windows). Damit stellen wir gewissermaßen die Grundlagen zur Verfügung, um bei dem Megatrend "Digitalisierung" mit ausreichend Know-how eigene Konzepte entwickeln zu können und nicht von irgendwelchen Trends abhängig zu sein. Für die praktische Anwendung ist es wichtig, einige grundlegende Randbedingungen festzulegen, "bevor" man sich für eine Technologie entscheidet. Weil man sonst oft gar nicht mehr zurück kann und viele Kröten schlucken muss, die sich erst später offenbaren. Dazu ein paar Hinweise (für Ingenieure, die selbst Geräte programmieren): - Soll meine Anwendung vom Internet abhängig sein oder auch ohne funktionieren? - Will ich von Herstellern unabhängig sein? - Soll die Anlage dezentral arbeiten (ohne Basis-Station)? - Sollen meine Geräte auch autark arbeiten (Grundfunktionalität)? - Will ich nur eine Fernsteuerung von Geräten oder mehr (intelligente Geräte)? - etc. Wenn man also erst das Konzept seiner Anlage (z.B. Heimautomatisierung) und die zugehörigen Randbedingungen definiert und dann nach den technischen Möglichkeiten recherchiert, ist das Tohuwabohu um die Technologien schnell eingegrenzt.
Jobst Q. schrieb: > Auf dem Gerät, das die Hardware anspricht, würde ich bei C bleiben. Das würde ich pauschal nicht so sehen. Handelt es sich dabei um einen Bare-Metal Controller, dann ja. Sobald es aber eine besserer Rechner (z.B. Raspberry Pi) ist, würde ich eine höhere Sprache verwenden (Python, JavaScript, Java). Nach meiner Erfahrung kommt man damit schneller zum Ergebnis, weil man sich seine Logik aus verschiedenen Bibliotheken zusammenbauen kann und damit schneller zum Ziel kommt. Der Umstieg dahin ist allerdings erstmal anstregend. Ich fand zum Beispiel Python am Anfang schwierig, weil das ganze nicht so richtig mit den mir aus C bekannten Konzepten zusammenpasste.
M.K. B. schrieb: > Jobst Q. schrieb: >> Auf dem Gerät, das die Hardware anspricht, würde ich bei C bleiben. > > Das würde ich pauschal nicht so sehen. > > Handelt es sich dabei um einen Bare-Metal Controller, dann ja. > Sobald es aber eine besserer Rechner (z.B. Raspberry Pi) ist, würde ich > eine höhere Sprache verwenden (Python, JavaScript, Java). Das war auch nicht pauschal gemeint, sondern als Rat für den Fragesteller, bei dem ich davon ausgehe, dass er C beherrscht, andere Sprachen aber noch nicht. Es geht um den Lernaufwand und den Bezug zum Nutzen. Ein Webinterface mit HTML,CSS und Javascript ist auf jeden Fall vielseitiger,unabhängiger und zukunftssicherer als spezielle APPs, die man mit Java erstellen könnte. Solche Dateien mit C zu erzeugen, hat keine solche Komplexität, dass Java oder Python große Vorteile bringen würden. Im wesentlichen ist es eine Aneinanderreihung von fprintf-Aufrufen.
Hallo zusammen und erneut vielen Dank für die vielen und ausführlichen Antworten :) Kurz zu dem Punkt mit der Programmiersprache für die Hardware: Hier möchte ich eigentlich auf jedenfall bei C bleiben. Da ich besonder überwiegend mit den "Bare-Metal"-Controllern arbeite bietet sich C einfach ideal an :) @Robert Patzke So ähnlich sah mein Grundlagenstudium auch aus, nur dass nach der C-Programmierung und der Mikrocontroller der Fokus mehr in Richtung Hardware und nicht auf die möglichen Kommunikationsmöglichkeiten gelegt wurde. Demnach kam ich auch nicht mit den objektorientierten Programmiersprachen in Berührung. Daher soll die 2. Sprache/Sprachen mir lediglich die Möglichkeit geben auch mal eigenständige Software-Applikationen bspw. für Neuronale Netzte zu schreiben, oder halt Programme und Interfaces mit welchen ich über die zahlreichen Schnittstellen mit den Controllern kommunizieren kann. Als grobes Beispiel vielleicht ein STM Mikrocontroller welcher verschiedene Sensoren ausliest und LEDs ansteuern kann. Dieser wird mittels eines ESP-Boards in ein WLAN Netzwerk oder mittels eines seriellen USB ComPorts mit dem Desktop-PC verbunden auf welchem wiederum ein Programm läuft womit man verschiedene Parameter ändern, Werte auslesen/einspeisen kann oder Funktionsgruppen festlegen welche dann alle eingefügten Sensormodule ansprechen. Nach den bisherigen Beiträgen würde ich aktuell zu der HTML/CSS/JavaScript-Lösung tendieren da ich dort am flexibelsten aufgestellt zu sein schein. Ich werd mir, wie von euch vorgeschlagen, in meiner freien Woche mal ein JavaScript und HTML Tutorial zu Gemüte führen. Jetzt aber noch 2. Abschlussfragen: 1. Es hört sich so an als ob man alles was man aktuell in Java programmiert auch mit den entsprechenden HTML/CSS/JavaScript Frameworks realisieren könnte. Wo genau läge da dann noch der Vorteil Java zu lernen? 2. Welche Variante schätzt ihr mit mehr Gesamtaufwand ein bis man erste Prototypen und funktionsfähige Programme mittleren bis kleinen Umfangs realisieren kann? In Anbetracht der bereits bekannten Programmierkenntnisse in C. Ich bedanke mich vorab und wünsche noch ein schönes Wochenende. VG Ein Gast
Ein Gast schrieb: > Ich werd mir, wie von euch vorgeschlagen, in meiner freien Woche mal ein > JavaScript und HTML Tutorial zu Gemüte führen. Dann schau dir in dem Atemzug auch gleich das Trio Typescript/NodeJS/AngularJS an. Hat den Vorteil dass du sowohl am Server als auch am Client die gleiche Sprache hast. > Jetzt aber noch 2. Abschlussfragen: > 1. Es hört sich so an als ob man alles was man aktuell in Java > programmiert auch mit den entsprechenden HTML/CSS/JavaScript Frameworks > realisieren könnte. Wo genau läge da dann noch der Vorteil Java zu > lernen? Von C kommend? keiner ;) Auch bei Java kommst du um das HTML/CSS-Gespann nicht herum. Bleibt also nur Java versus Javascript/Typescript in den Überlegungen übrig. > 2. Welche Variante schätzt ihr mit mehr Gesamtaufwand ein bis man erste > Prototypen und funktionsfähige Programme mittleren bis kleinen Umfangs > realisieren kann? In Anbetracht der bereits bekannten > Programmierkenntnisse in C. Aus eigener Erfahrung ist der Umstieg auf Java deutlich heftiger zu bewältigen.
Andi schrieb: > Von C kommend? keiner ;) Oh je, oh je... Also ich fluche jedes Mal wenn ich in C was machen muß und wieder in diese beschissene prozedurale Denke rein muß. Objektorientiert programmiert es sich doch deutlich angenehmer.
Wühlhase schrieb: > Andi schrieb: >> Von C kommend? keiner ;) > Oh je, oh je... > > Also ich fluche jedes Mal wenn ich in C was machen muß und wieder in > diese beschissene prozedurale Denke rein muß. Objektorientiert > programmiert es sich doch deutlich angenehmer. Auch in C kann man objektorientiert arbeiten. Es erfordert zwar wesentlich mehr Disziplin und einige Klimmzüge, aber es geht. Tatsächlich gilt, was in der OOP als Datenkapselung bezeichnet wird, auch in C als guter Stil.
Das würde ich ja gerne mal sehen. OOP besteht auch, aber nicht nur, aus Datenkapselung.
Wühlhase schrieb: > Das würde ich ja gerne mal sehen. Dann schau Dir einfach GTK+ an. > OOP besteht auch, aber nicht nur, aus Datenkapselung. "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." (Dr. Alan Kay) Geht alles auch in C. Mal mehr, mal weniger aufwändig, und bei Weitem nicht so komfortabel wie in C++ und anderen Sprachen, die OOP direkt mit eigenen Sprachmitteln unterstützen, aber: es geht.
Karl Käfer wurde nicht gefragt... :-) Wen es interessiert: C im 21. Jahrhundert, O'reilly, von Ben Klemens ISBN 978-3-95561-692-2 mfg
~Mercedes~ schrieb: > Karl Käfer wurde nicht gefragt... :-) > > Wen es interessiert: > > C im 21. Jahrhundert, O'reilly, von Ben Klemens > ISBN 978-3-95561-692-2 Hab' die englischsprachige Version, sehr empfehlenswert. Das beschäftigt sich aber eher mit der Entwicklungsinfrastruktur und Werkzeugen und ist daher eher was für Leute die C schon können.
Hallo, ich kann folgende Kombination wirklich empfehlen: C am Mikrocontroller, der Rest (nicht REST) mit JavaScript, HTML und CSS. Dabei kann man mit node.js PC Anwendungen und Server mit JavaScript schreiben (auch mit Hardwareanbindung für fast alles, siehe npm). Client (Browser) seitig dann auch JavaScript, HTML und CSS. Ich habe vor ca. 2 Monaten vue.js und das quasarFramework gefunden. In Kombination kann man so extrem schnell professionelle Benutzeroberflächen erstellen. Wobei hier vue.js wirklich der Schlüssel zum Erfolg ist. Natürlich sollte man sich auch mit AJAX, HTTP Requests, Proxies usw. auch beschäftigen. Lg.
Hier noch einige Links dazu: https://nodejs.org/en/ http://quasar-framework.org/ https://vuejs.org/ Minimal Demo: http://jsfiddle.net/yyx990803/vjvMp/1/ Todo Demo: https://jsfiddle.net/ayoisaiah/v4p20ekz/ Diagramme und Zeigerinstrumente: https://ecomfe.github.io/echarts-examples/public/index.html Achtung!!! Browser mögen es nicht, wenn nicht HTML Tags wie z.B. <q .../> direkt mit /> beendet werden. Da muss man <q ...></q> schreiben. Diese Erkenntnis hat mich fast eine Woche gekostet!
Karl Käfer schrieb: > "OOP to me means only messaging, local retention and protection and > hiding of state-process, and extreme LateBinding of all things." (Dr. > Alan Kay) > > Geht alles auch in C. Mal mehr, mal weniger aufwändig, und bei Weitem > nicht so komfortabel wie in C++ und anderen Sprachen, die OOP direkt mit > eigenen Sprachmitteln unterstützen, aber: es geht. Und was ist mit Vererbung? C kriegt die Beziehung "... ist eine Art von ..." schlicht nicht hin, gerade damit werden viele Kniffe aber erst möglich (siehe Dekoratormuster). Klar kann man in C etwas formulieren dessen Kompilat dem eines richtigen C++-Programms ähnelt, mit objektorientierter Programmieren hat das meines Erachtens aber nichts zu tun.
Wühlhase schrieb: > Klar kann man in C etwas formulieren dessen Kompilat dem eines richtigen > C++-Programms ähnelt, mit objektorientierter Programmieren hat das > meines Erachtens aber nichts zu tun. Muß es das ? Ich lerne gerade C++, struct nennt sich halt jetzt Klasse. Ich schmeiß den Kram noch an die Wand ... ;(
Joachim D. schrieb: > Ich lerne gerade C++, struct nennt sich halt jetzt Klasse. Nein. Es gibt durchaus einen Unterschied zwischen struct und class
Abradolf L. schrieb: > Joachim D. schrieb: >> Ich lerne gerade C++, struct nennt sich halt jetzt Klasse. > > Nein. Es gibt durchaus einen Unterschied zwischen struct und class Klar ... ;)
Ich möchte ergänzen, dass Java (konkret OpenJDK und Oracle JDK) keine Funktionen zum Zugriff auf Hardware hat. Es gibt nur Bildschirm, Tastatur, Netzwerk und Filesystem. Für alles Weitere, insbesondere serielle Ports, benötigt man zusätzliche Libraries die in C (!) geschrieben sind. Zum Beispiel RxTx (http://rxtx.qbang.org/wiki/index.php/Download). Gleiches Gilt übrigens soweit ich weiß auch für Python, nur dass dort schon die Unterstützung einiger Hardware Schnittstellen im Lieferumfang enthalten sind. Bei Java ist das leider nicht der Fall. Anders sieht es allerdings bei Android aus. Das Android SDK enthält Java Klassen für so ziemlich jede Funktion und Schnittstelle, die von Android Geräten bereit gestellt wird.
Abradolf L. schrieb: > Joachim D. schrieb: >> Klar ... ;) > > Doch, Stichwort Default Sichtbarkeit. Ok, aber wozu ? Ich habe mal mit Maschinencode/Assembler angefangen und bin irgendwann bei C gelandet. Über teutsche Verwaltungsgläubigkeit habe ich mich schon immer aufgeregt - jetzt C++. Oha ! Der Rechner soll das machen was ich will und der Compiler das so übersetzen daß die Maschine es versteht. Da brauche ich eigentlich keine 7 Durchschläge. Ich habe jetzt 2 Tage damit verplempert damit mir G++ eine SQLite Datenbank überhaupt mal anlegt, "Callback" hurra. In C einfach, in C++ mache ich es auch so wie in C. Globale Veriable damit ich im callback drankomme. Überall im WWW wird von callback abgeraten und es werden teilweise wildeste Konstruktionen als Ersatz dafür propagiert. Echt ein Fortschritt. Grüße Joe. PS: Ich bekomme das schon irgendwie hin ;)
Wühlhase schrieb: > Karl Käfer schrieb: >> "OOP to me means only messaging, local retention and protection and >> hiding of state-process, and extreme LateBinding of all things." (Dr. >> Alan Kay) >> >> Geht alles auch in C. Mal mehr, mal weniger aufwändig, und bei Weitem >> nicht so komfortabel wie in C++ und anderen Sprachen, die OOP direkt mit >> eigenen Sprachmitteln unterstützen, aber: es geht. > > Und was ist mit Vererbung? Das ist ein Feature vieler Implementierungen von OO, aber nach Dr. Alan Kay eben kein Kernbestandteil derselben. Auch Kristen Nygaard, der Schöpfer der ersten objektorientierten Programmiersprachen Simula 1 und Simula-67, bestand zeitlebens darauf "that some OOP could be done without inheritance". Nachdem die beiden die Väter dessen sind, was wir heute "objektorientiert" nennen -- der Eine der Technik, der Andere des Namens -- sind das IHMO die ultimativen Referenzen zu dieser Frage. ;-) Andererseits ist so etwas wie Vererbung durchaus auch in C möglich, wenngleich... naja, urteile selbst [1]. ;-) [1] https://www.codeproject.com/Articles/108830/Inheritance-and-Polymorphism-in-C
Joachim D. schrieb: > Ich schmeiß den Kram noch an die Wand ... ;( Wo hakt es denn, wenn ich fragen darf?
Stefanus F. schrieb: > Ich möchte ergänzen, dass Java (konkret OpenJDK und Oracle JDK) keine > Funktionen zum Zugriff auf Hardware hat. Es gibt nur Bildschirm, > Tastatur, Netzwerk und Filesystem. > > Für alles Weitere, insbesondere serielle Ports, benötigt man zusätzliche > Libraries die in C (!) geschrieben sind. Zum Beispiel RxTx > (http://rxtx.qbang.org/wiki/index.php/Download). > > Gleiches Gilt übrigens soweit ich weiß auch für Python, nur dass dort > schon die Unterstützung einiger Hardware Schnittstellen im Lieferumfang > enthalten sind. Bei Java ist das leider nicht der Fall. > > Anders sieht es allerdings bei Android aus. Das Android SDK enthält Java > Klassen für so ziemlich jede Funktion und Schnittstelle, die von Android > Geräten bereit gestellt wird. Entschuldige bitte, aber die Standardinterpreter von Python und Java sind selbst in C bzw. C++ geschrieben -- und nutzen ausgiebig das Konzept der Shared Objects (*.so) oder Dynamic Link Libraries (*.dll):
1 | sheeva@plug:~$ file /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java |
2 | /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java: ELF 64-bit LSB executable |
3 | [...] |
4 | sheeva@plug:~$ ldd /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java |
5 | linux-vdso.so.1 => (0x00007ffe397ab000) |
6 | [...] |
7 | sheeva@plug:~$ file /usr/bin/python2.7 |
8 | /usr/bin/python2.7: ELF 64-bit LSB executable, x86-64, [...] |
9 | sheeva@plug:~$ ldd /usr/bin/python2.7 |
10 | linux-vdso.so.1 => (0x00007fffa158d000) |
11 | libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 |
12 | [...] |
Insofern verstehe ich ehrlich gesagt nicht, was Dein Punkt ist. Tatsache ist: das Java Native Interface (JNI) und die C-Schnittstellen von Python existieren und werden nicht nur für Hardwarezugriffe vielfältig genutzt. Tatsache ist auch, daß der Code egal ob in Java oder in Python irgendwie nativ auf der CPU ausgeführt werden muß, und solange es keine Java- oder Python-Implementierung in Hardware gibt, sind die Interpreter nun einmal darauf angewiesen, daß der native Code irgendwoher kommt -- der fällt ja leider nicht vom Himmel.
Joachim D. schrieb: > Ich habe jetzt 2 Tage damit verplempert damit mir G++ eine > SQLite Datenbank überhaupt mal anlegt, "Callback" hurra. Entschuldige, aber glaubst Du wirklich, daß das der Richtige Weg (tm) ist, eine neue Programmiersprache mit einem neuen Paradigma zu lernen? Tut mir leid, aber wenn Datenbankprogrammierung das Erste ist, was Du in C++ machst, wundert es mich kein bisschen, wenn das frustrierend ist. Dies nicht zuletzt auch, weil SqLite meines Wissens gar keine C++-API hat und stattdessen auch für C++ die vorhandene C-API empfiehlt.
Ich will ein Programm schreiben das funktioniert. C++ ist da ein sehr steiniger Weg ... Heraus kommt eh Maschinencode, egal wie. Brauch ich dazu unbedingt ein "Paradigma" ? Ich bekomme das schon noch raus. C lernt man auch nicht in einem Tag ;)
Wer in Java auf dem PC hardware nah programmieren möchte muss sich eher früher als später mit C und dem JNI beschäftigen. Deswegen ist es keine Zeitverschwendung, mit C anzufamgen.
Joachim D. schrieb: > Ich will ein Programm schreiben das funktioniert. C++ > ist da ein sehr steiniger Weg ... Nein, überhaupt nicht. Man muß es nur erst einmal lernen. > Heraus kommt eh Maschinencode, egal wie. Brauch ich dazu > unbedingt ein "Paradigma" ? Ja, unbedingt. Dieses andere Paradigma ist der Schlüssel zur OOP. > Ich bekomme das schon noch raus. C lernt man auch nicht > in einem Tag ;) Richtig -- und auch in C fängt man üblicherweise erst einmal an mit einem "Hello World!\n" und tastet sich dann weiter voran. Wer sich als erstes Programm in C gleich einen Datenbank-Client vornimmt, wird eine ähnliche Frustration erleben wie Du; bei manchen mündet diese Frustration sogar in eine grundsätzliche Abneigung gegen die Sprache. Dabei hat das gar nichts mit der Sprache zu tun, sondern nur mit einer Herangehensweise, die in zu kurzer Zeit zu viel erreichen will. Kurz gesagt, überforderst Du Dich selbst. Das kann und wird auf die eine oder andere Weise schief gehen: entweder gibst Du früher oder später auf, oder Du wirst die Sprache nicht richtig lernen und darum niemals richtig sicher, flüssig, produktiv und glücklich damit. Nix für ungut, nur so ein Tipp.
Sheeva P. schrieb: > Kurz gesagt, überforderst Du Dich selbst. Das kann und wird auf die eine > oder andere Weise schief gehen: entweder gibst Du früher oder später > auf, oder Du wirst die Sprache nicht richtig lernen und darum niemals > richtig sicher, flüssig, produktiv und glücklich damit. Nein. Das wird funktionieren, es wird ein Mailproxy. Das meiste funktioniert schon.
Joachim D. schrieb: > In C einfach, in C++ mache ich es auch so wie in C. Globale > Veriable damit ich im callback drankomme. Überall im WWW wird > von callback abgeraten und es werden teilweise wildeste > Konstruktionen als Ersatz dafür propagiert. Echt ein Fortschritt. Ich kann verstehen, dass man mit der Einstellung von C in anderen Sprachen aneckt. Meiner Meinung nach fehlt dann aber die Bereitschaft oder auch Zeit sich mit dem Ansatz der anderen Sprache vertraut zu machen. Zugegeben ist es am Anfang frustrierend, aber ich fand es am Ende echt interessant, wenn man feststellt, dass man ein Problem je nach Sprache anders und damit leichter oder schwieriger lösen kann. Für mich war z.B. am Anfang Python exotisch und sobald man versucht etwas wie in C zu machen wird es kompliziert. Hat man aber die Grundideen der Sprache besser verstanden, dann geht es ohne Probleme und manchmal sogar einfacher. Dein Beispiel würde ich dann sogar als Vorteil vom C -> C++ Umstieg sehen. Man kann Sachen erst mal so machen, wie man es von C gewöhnt ist und nach und nach neue Sachen in C++ ausprobieren und den alten C Code weiter nutzen.
Stefanus F. schrieb: > Wer in Java auf dem PC hardware nah programmieren möchte muss sich eher > früher als später mit C und dem JNI beschäftigen. Deswegen ist es keine > Zeitverschwendung, mit C anzufamgen. Jetzt geht es nur noch um Java, früher auch um Python. Ok, Python hat in der Boost-Sammlung natürlich Boost.Python, mit dem man C++-Binaries einfach in Python einbinden kann -- während Javas JNI zwar primär auf C zielt, aber auch mit C++ bedient werden kann. Ich wiederhole mich nicht gerne, aber: Was ist Dein Punkt?
Joachim D. schrieb: > Das wird funktionieren, es wird ein Mailproxy. Mit SqLite? Spannend. Wie handhabst Du denn da die Gleichzeitigkeit?
Joachim D. schrieb: > Sheeva P. schrieb: >> Kurz gesagt, überforderst Du Dich selbst. Das kann und wird auf die eine >> oder andere Weise schief gehen: entweder gibst Du früher oder später >> auf, oder Du wirst die Sprache nicht richtig lernen und darum niemals >> richtig sicher, flüssig, produktiv und glücklich damit. > > Nein. Das wird funktionieren, es wird ein Mailproxy. > Das meiste funktioniert schon. Wenn ich keine Ohren hätte, würde ich jetzt rundum grinsen. ;-) Sorry, aber: daß Du einen C++-Compiler benutzt, bedeutet leider nicht, daß Du tatsächlich auch OO-Code in C++ schreibst. Das war übrigens in den Anfangszeiten von C++ ein besonders "Problem": die alten C-Entwickler haben im Prinzip immer noch in C entwickelt, und das war dann aus deren Sicht C++-Code, weil sie zum Übersetzen einen C++-Compiler benutzt haben.
Joachim D. schrieb: > Ich habe jetzt 2 Tage damit verplempert damit mir G++ eine > SQLite Datenbank überhaupt mal anlegt, "Callback" hurra. Der g++ legt die Datenbank genauso wenig an wie der gcc. Vielleicht hast Du neben OO in C++ auch das Compilationsmodell nicht verstanden?
> Nein. Das wird funktionieren, es wird ein Mailproxy. > Das meiste funktioniert schon. Das sollte ein Witz sein, oder? Ich glaube, die Ironie in diesem Beitrag war nicht deutlich genug erkennbar. Außerdem wirkt es so, als ob du der TO (Ein Gast) wärst.
@Sheeva: Interessant. Ich will mir keinesfalls anmaßen den Vätern der OOP ihre Kompetenz absprechen. Allerdings frag ich mich doch, wie die beiden zu ihrer Einstellung kommen? Denn wie gesagt-ohne Vererbung würde vom Werk der GoF nicht viel übrig bleiben, aber die Möglichkeit solche Konzepte fahren zu können macht OOP doch zumindest zu einem beachtlichen Teil aus. Zumindest bei heutigen Anwendungen.
Joachim D. schrieb: > Wühlhase schrieb: >> Klar kann man in C etwas formulieren dessen Kompilat dem eines richtigen >> C++-Programms ähnelt, mit objektorientierter Programmieren hat das >> meines Erachtens aber nichts zu tun. > > Muß es das ? > > Ich lerne gerade C++, struct nennt sich halt jetzt Klasse. Structs und Klassen sind nicht annähernd dasselbe. Structs sind einfach nur selbstdefinierte Datentypen bzw. Bündel von primitiven Datentypen. Mehr als Datenhalten können die nicht. Klassen beinhalten keine Daten (zumindest ist das nicht ihr Hauptzweck), sondern bilden ein Verhalten nach. Dafür sind zwar auch interne Variablen nötig, irgendwie müssen die Zustandswerte ja gespeichert werden (und deshalb kann man die auch vor der Öffentlichkeit verbergen). Du solltest wirklich mal ein Buch über OOP lesen nicht nur über C++ als reine Sprache. In letzteren steht zwar wie man eine Klasse definiert und das man was public und private machen kann, wozu das aber gut sein soll wird eher in ersteren dargestellt.
Ich hebe jetzt Zug für Zug erstmal alles auf C++ um und lasse mir Zeit. Die ersten 2 Wochen C waren sehr viel schlimmer (da war der PC einige Male kurz vor dem Flug durchs offene Fenster). Kriterien, was ich in eine Klasse packen kann und wo es Sinn macht werden sich ergeben. Vielleicht wird das Leben dann einfacher ;) Alles braucht seine Zeit ...
Wühlhase schrieb: > @Sheeva: > Interessant. Ich will mir keinesfalls anmaßen den Vätern der OOP ihre > Kompetenz absprechen. Allerdings frag ich mich doch, wie die beiden zu > ihrer Einstellung kommen? Denn wie gesagt-ohne Vererbung würde vom Werk > der GoF nicht viel übrig bleiben, aber die Möglichkeit solche Konzepte > fahren zu können macht OOP doch zumindest zu einem beachtlichen Teil > aus. Zumindest bei heutigen Anwendungen. Das besagte Buch der GoF ist bald 25 Jahre alt. Vieles was man heute Vererbung vorziehen würde gabs damals schlichtweg nicht. Lambdas, Type-Erasure und TMP zum Beispiel... Ein meiner Ansicht nach recht großes Problem ist, dass man C++ noch lehrt wie vor 25 Jahren. Auch die Beispiele im Internet sind voll davon. "Sie erstellen eine Klasse für ein Moped und einen Kampfpanzer. Beide Klassen Erben von der Klasse der Dieselfahrzeuge, welche wiederrum von der Klasse der Landfahrzeuge erbt, die von der Klasse Fahrzeug erbt." Und dabei wollte man eigentlich nur die "fahr()" Funktion für Moped und Panzer aufrufen... Interessant diesbezüglich ist übrigens folgender Talk: https://www.infoq.com/presentations/gof-patterns-c-plus-plus-boost Wühlhase schrieb: > Structs sind einfach nur selbstdefinierte Datentypen bzw. Bündel von > primitiven Datentypen. Mehr als Datenhalten können die nicht. Das is maximal eine von dir erdachte Sichtweise. Mit der Realität hat das aber nix zu tun.
C++ Beispiele gibt es im Weltweiten säckeweise. Ist aber anscheinend so wie be Computerbüchern: Einer schreibt vom andern ab, leider incl. der Fehler.
Hallo zusammen :) Ich bedanke mich nochmal für die hilfreichen Antworten und werde mich in den nächsten Wochen mit HTML, CSS & Javascript beschäftigen. Da sich hier so langsam ein Eigenleben entwickelt, möchte ich mich an dieser Stelle ausklinken. Es hat mich gefreut so schnell konstruktive Antworten bekommen zu haben :) Ich wünsche allen noch eine schöne Restwoche. VG Ein Gast @weinga-unity Danke für die Links ich hab sie mir für später schon mal abgespeichert :)
Wühlhase schrieb: >> >> Ich lerne gerade C++, struct nennt sich halt jetzt Klasse. > Structs und Klassen sind nicht annähernd dasselbe. > > Structs sind einfach nur selbstdefinierte Datentypen bzw. Bündel von > primitiven Datentypen. Mehr als Datenhalten können die nicht. struct und class unterscheiden sich nur durch die default-access-specifier: ein struct ist eine all-public class. Mit beidem definiert man Datentypen (im Sinne eines ADT): user-defined-types (UDT). Und C++ hat ja die nette Eigenschaft, primitive DT und UDT (fast) gleich zu behandeln (einer der Unterschiede ist die default-initialisation). Und das wiederum ist die Grundlage für die Effektivität von templates.
:
Bearbeitet durch User
Wühlhase schrieb: > Structs sind einfach nur selbstdefinierte Datentypen bzw. Bündel von > primitiven Datentypen. Mehr als Datenhalten können die nicht. Sicher können sie - Funktionszeiger kann man da auch unterbringen. So ein OOP in C hab ich auch schon embedded gesehen. Im Linuxkernel wird auf diese Weise ebenfalls OOP in C gemacht. Was allerdings nicht geht: - RAII, aber das nimmt man embedded eh selten, weil dynamische Allokation an sich ungünstig ist - Zugriffsrechte (public / private).
Nop schrieb: > Wühlhase schrieb: > >> Structs sind einfach nur selbstdefinierte Datentypen bzw. Bündel von >> primitiven Datentypen. Mehr als Datenhalten können die nicht. > > Sicher können sie - Funktionszeiger kann man da auch unterbringen. So > ein OOP in C hab ich auch schon embedded gesehen. Im Linuxkernel wird > auf diese Weise ebenfalls OOP in C gemacht. So wie ich ihn verstanden hatte, meinte er C++. > Was allerdings nicht geht: > - RAII, aber das nimmt man embedded eh selten, weil dynamische > Allokation an sich ungünstig ist > - Zugriffsrechte (public / private). Selbstverständlich geht das. Die Unterschiede zwischen class und struct: Member: struct: default public class: default private Vererbung: struct: default public class: default private template-Präambel: für template-type-parameter und template-template-parameter kein struct als keyword möglich, wohl aber class oder typename
:
Bearbeitet durch User
Nein, ich meinte schon C, mit C++ hab ich mich noch nie befasst. Das man Funktionszeiger in Structs unterbringen kann hab ich völlig vergessen. Liegt wohl daran, daß ich in C nie einen Funktionszeiger genutzt habe. Es scheint in C wirklich deutlich mehr in Richtung OOP zu gehen als ich dachte-aber ich bin dennoch froh, andere Sprachen wie Java dafür zu haben. Immerhin, wieder was gelernt. Danke. :)
> Es scheint in C wirklich deutlich mehr in Richtung OOP zu gehen
Der Umgang mit Files (z.B. bei fprintf()) ist auch ein
Objektorientierter Ansatz in C.
Man hat Funktionen, die für Files geschrieben wurden. Und ihnen übergibt
man als ersten Parameter das File. In diesem Fall könnte man die
Struktur auch Objekt nennen.
Wilhelm M. schrieb: > Selbstverständlich geht das. Und wie macht man das in C, daß man die Sichtbarkeit in structs auf private bekommt? Und wie geht RAII in C-Structs?
Wühlhase schrieb: > Nein, ich meinte schon C, mit C++ hab ich mich noch nie befasst. Das man > Funktionszeiger in Structs unterbringen kann hab ich völlig vergessen. Das war für mich nicht zu erkennen, denn der Kontext war: >> Ich lerne gerade C++, struct nennt sich halt jetzt Klasse. > Structs und Klassen sind nicht annähernd dasselbe. Und dann kam noch jemand mit RAII. Daher nahm ich an, es gehe um C++.
Nop schrieb: > Wilhelm M. schrieb: > >> Selbstverständlich geht das. > > Und wie macht man das in C, daß man die Sichtbarkeit in structs auf > private bekommt? Und wie geht RAII in C-Structs? Man übersetzt sein C-Quelle mit einem C++-Compiler ;-)
Wühlhase schrieb: > @Sheeva: > Interessant. Ich will mir keinesfalls anmaßen den Vätern der OOP ihre > Kompetenz absprechen. Allerdings frag ich mich doch, wie die beiden zu > ihrer Einstellung kommen? Denn wie gesagt-ohne Vererbung würde vom Werk > der GoF nicht viel übrig bleiben, aber die Möglichkeit solche Konzepte > fahren zu können macht OOP doch zumindest zu einem beachtlichen Teil > aus. Zumindest bei heutigen Anwendungen. Die GoF hat "nur" einige Muster beschrieben, wie man die OO mit den Mitteln der verfügbaren Werkzeuge für bestimmte Standardsituationen nutzen kann. Daß die meisten verfügbaren OO-Werkzeuge die Vererbung unterstützen -- ich kenne jedenfalls keines, das das nicht tut -- führt dann im Umkehrschluß dazu, daß die GoF dieses Feature in ihren Patterns eben auch benutzen. Darin sehe ich keinen Widerspruch zu den Aussagen der Väter der OO, die die Vererbung eben nicht für zwingend notwendig halten.
Wühlhase schrieb: > Klassen beinhalten keine Daten (zumindest ist das nicht ihr Hauptzweck), > sondern bilden ein Verhalten nach. Hm... ich würde eher sagen, daß Klassen letztlich sowohl Zustände abbilden als auch das Verhalten, das diese Zustände ändert.
Stefanus F. schrieb: >> Es scheint in C wirklich deutlich mehr in Richtung OOP zu gehen > > Der Umgang mit Files (z.B. bei fprintf()) ist auch ein > Objektorientierter Ansatz in C. > > Man hat Funktionen, die für Files geschrieben wurden. Und ihnen übergibt > man als ersten Parameter das File. In diesem Fall könnte man die > Struktur auch Objekt nennen. Ja, klar, so wird das ja letztlich auch von einem C++-Compiler realisiert: man hat einen versteckten this-Zeiger. Allerdings kann man aus der Tatsache, dass man man mit C ein objektorientiertes Verhalten durch poor-man-Polymorphie nachbauen kann, noch nicht darauf schließen, dass C objektorientierte Sprachmerkmale hätte. Dann könnte man auch behaupten, dass Assembler objektorientierte Merkmale besäße. Denn schließlich kann man auch ein C++ Programm in ein reines C Programm überführen (der clang ++ hatte mal ein C-Backend).
:
Bearbeitet durch User
Sheeva P. schrieb: > Wühlhase schrieb: >> @Sheeva: >> Interessant. Ich will mir keinesfalls anmaßen den Vätern der OOP ihre >> Kompetenz absprechen. Allerdings frag ich mich doch, wie die beiden zu >> ihrer Einstellung kommen? Denn wie gesagt-ohne Vererbung würde vom Werk >> der GoF nicht viel übrig bleiben, aber die Möglichkeit solche Konzepte >> fahren zu können macht OOP doch zumindest zu einem beachtlichen Teil >> aus. Zumindest bei heutigen Anwendungen. > > Die GoF hat "nur" einige Muster beschrieben, wie man die OO mit den > Mitteln der verfügbaren Werkzeuge für bestimmte Standardsituationen > nutzen kann. Daß die meisten verfügbaren OO-Werkzeuge die Vererbung > unterstützen -- ich kenne jedenfalls keines, das das nicht tut -- führt > dann im Umkehrschluß dazu, daß die GoF dieses Feature in ihren Patterns > eben auch benutzen. Darin sehe ich keinen Widerspruch zu den Aussagen > der Väter der OO, die die Vererbung eben nicht für zwingend notwendig > halten. Ich denke, es wäre wichtig, den Unterschied zwischen Polymorphie und Vererbung klar zu machen: normalerweise möchte man Typen polymorph benutzen, ob das mit Vererbung realisiert wird, ist nur ein Detail. Oder: ohne Vererbung wäre Polymorphie noch schöner. Z.B. führt Vererbung eben zu einer Koppelung der beteiligten Typen bzw. man schafft sich "unbeabsichtigte Datenstrukturen" durch die damit verbundene Referenz-Semantik. Hier ein Talk von Bjarne, in dem er das high-level verdeutlicht (vor einem offensichtlich nicht so kundigem Auditorium): Bjarne Stroustroup: https://www.youtube.com/watch?v=xcpSLRpOMJM Hier ein Talk von Sean, der das Problem im Detail erläutert: Sean Parent: https://www.youtube.com/watch?v=QGcVXgEVMJg Mit concepts (ab g++-6.3 bzw. ab C++20) und templates wird die Bedeutung von Vererbung als Realisierungsdetail für Polymorphie weiter verringert werden.
:
Bearbeitet durch User
Wilhelm M. schrieb: > Oder: ohne Vererbung wäre Polymorphie noch schöner. Z.B. führt Vererbung > eben zu einer Koppelung der beteiligten Typen bzw. man schafft sich > "unbeabsichtigte Datenstrukturen" durch die damit verbundene > Referenz-Semantik. Spielst du auf Mehrfachvererbung an (ich kann mir deine Videos gerade nicht anschauen), so daß man mehrere Vererbungsbäume in einer Klasse zusammenwürfeln kann? Java unterstützt das nicht, da ist jede Klasse stets von der Art ihrer Superklasse. Wenn man zwei Klassen aus verschiedenen Vererbungsbäumen die gleiche Fähigkeit verleihen will gibt es dafür ein Interface und eine Methode kann prüfen, ob ein Objekt das Interface implementiert hat. Das funktioniert zwar ähnlich wie Vererbung und bringt auch alle Vorteile mit, ist aber keine Vererbung im eigentlichen Sinne. Daher werden Interfaces auch meist als ...fähig (able) benamst um auszudrücken das es eine Zusatzfähigkeit ist. Z.B. das Interface runnable wird benutzt, wenn eine Klasse in einem eigenen Thread laufen soll. Im o.g. Beispiel kann man in einer Klasse Schwimmpanzer, die man von der Superklasse Landfahrzeuge abgeleitet hat, das Interface 'schwimmfähig' implementieren. Das Ding ist nach wie vor ein Landfahrzeug-aber eben ein schwimmfähiges Landfahrzeug. Eine Methode kann jetzt Objekte entgegennehmen, die schwimmfähig sind. Das kann auch ein Wasserflugzeug (von einer Art Luftfahrzeuge) sein, solange es eben das Interface 'schwimmfähig' implementiert. Was ich damit sagen will: Das Problem von dem ich glaube daß du das meinst, hat weniger was mit Vererbung an sich, sondern eher mit der Implementierung derselben in der Sprache zu tun wobei ich allerdings nicht sicher bin, ob man bei Interfaces noch von Polymorphie im eigentlichen Sinne sprechen kann, denn mit einem Interface ist ein Objekt ja wieder typisiert. Meines Erachtens einer der entscheidenden Unterschiede zwischen C++ und Java, wobei ich mir aber sicher bin das C++ da mittlerweile auch was in der Richtung anbietet. Die Mehrfachvererbung wird C++ aber wohl nicht mehr los, jedenfalls nicht ohne abwärtskompatibel zu bleiben. Oder irre ich da?
Wühlhase schrieb: > Wilhelm M. schrieb: >> Oder: ohne Vererbung wäre Polymorphie noch schöner. Z.B. führt Vererbung >> eben zu einer Koppelung der beteiligten Typen bzw. man schafft sich >> "unbeabsichtigte Datenstrukturen" durch die damit verbundene >> Referenz-Semantik. > Spielst du auf Mehrfachvererbung an (ich kann mir deine Videos gerade > nicht anschauen), so daß man mehrere Vererbungsbäume in einer Klasse > zusammenwürfeln kann? Nein, hat damit gar nichts zu tun. > Java unterstützt das nicht, da ist jede Klasse stets von der Art ihrer > Superklasse. Wenn man zwei Klassen aus verschiedenen Vererbungsbäumen > die gleiche Fähigkeit verleihen will gibt es dafür ein Interface und > eine Methode kann prüfen, ob ein Objekt das Interface implementiert hat. Naja, in Java hat man die Mehrfachvererbung kastriert: eine Basisklasse, viele Interfaces. > Das funktioniert zwar ähnlich wie Vererbung es ist im eigentlichen Sinne Vererbung, nur hat man dort Java gegenüber C++ mal wieder vereinfacht. > und bringt auch alle > Vorteile mit, ist aber keine Vererbung im eigentlichen Sinne. Daher > werden Interfaces auch meist als ...fähig (able) benamst um auszudrücken > Was ich damit sagen will: Das Problem von dem ich glaube daß du das > meinst, hat weniger was mit Vererbung an sich, sondern eher mit der > Implementierung derselben in der Sprache zu tun wobei ich allerdings > nicht sicher bin, ob man bei Interfaces noch von Polymorphie im > eigentlichen Sinne sprechen kann, denn mit einem Interface ist ein > Objekt ja wieder typisiert. Das Problem ist die Vererbung, da sie zu einer engen Koppelung der Klassen führt. Bei Java hat man die Notlösung eingebaut, dass alles implizit von Object erbt. Damit sind alle Klassen gekoppelt. In C++ ist das nicht so: hat man fremde Klassen, so kann man sie nicht mehr einem Interface unterordnen. Man hat keine Möglichkeit, die enge Koppelung über eine Basisklasse (Interface) herzustellen. Und eigentlich will man diese enge Koppelung ja auch gar nur, man würde durch die Vererbung nur dazu gezwungen. Aber eigentlich möchte man nur ausdrücken, dass zwei Klassen eine gemeinsame Eigenschaft besitzen, etwa eine Elementfunktion draw(...) besitzen. Dass kann man mit Vererbung machen, muss man aber nicht. Also ist Vererbung nur ein Weg, Polymorphie zu realisieren. > Meines Erachtens einer der entscheidenden Unterschiede zwischen C++ und > Java, wobei ich mir aber sicher bin das C++ da mittlerweile auch was in > der Richtung anbietet. Wie immer bietet C++ hier mehr an als Java. Ich verstehe nicht genau was Du meinst, aber natürlich gibt es in C++ Interfaces und abstrakte Klassen. > Die Mehrfachvererbung wird C++ aber wohl nicht > mehr los, jedenfalls nicht ohne abwärtskompatibel zu bleiben. Oder irre > ich da? Will man ja auch gar nicht, denn man braucht sie!
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.