Welche aufbauende Programmiersprache lernen (Java/HTML5 & co)?

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

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.

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

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.

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.

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

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

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

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

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?

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.

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.

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

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

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.

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!