Moin, habe mittlerweile C ganz gut drauf und schaue mich jetzt nach einer weiteren Programmiersprache um. Bin Elektro-Ingenieur und arbeite im Energiesektor. Würde eine weitere Programmiersprache sowohl als berufliche Kompetenz als auch für privates Vergnügen lernen wollen. Welche Sprache macht nach C am meisten Sinn? Überlege mit C++ weiter zu machen. Sie baut ja quasi auf C auf und bringt die Aspekte der Objektorientierten Programmierung mit rein. Auf die reduzierte Möglichkeit von Pointern und Hardwarenaher Programmierung kann ich auch verzichten, da man das ja bereits in C bekommt. Andererseits begeistert mich Python schon seit langem. Ebenfalls objektorientiert, stelle ich mir die Data Science und Neural Network Features dieser Sprache sehr nützlich aber auch spaßig vor. Oder auf lange sich gar alle drei Sprachen? (C, C++, Python) Auf Java hab ich gar keine Lust, ebenfalls Sprachen wie Javascript oder völlige Nischensprachen interessieren mich eher weniger. Was würdet ihr empfehlen? Gruß, Rüdiger
Ruediger schrieb: > Moin, Moin Moin, > Überlege mit C++ weiter zu machen. Sie baut ja quasi auf C auf und > bringt die Aspekte der Objektorientierten Programmierung mit rein. Auf > die reduzierte Möglichkeit von Pointern und Hardwarenaher Programmierung > kann ich auch verzichten, da man das ja bereits in C bekommt. C++ ist eine Obermenge von C. Alles was Du in C machen kannst, kannst Du auch in C++ machen. C++ ist eine sehr große Sprache und bietet nicht nur OOP. Um C++ wirklich sinnvoll einsetzen zu können, braucht es viel Zeit. Man kann aber auch anfangen seine C Software mit einem C++ Compiler zu übersetzen und dann langsam die neuen features von C++ zu nutzen. > Andererseits begeistert mich Python schon seit langem. Ebenfalls > objektorientiert, stelle ich mir die Data Science und Neural Network > Features dieser Sprache sehr nützlich aber auch spaßig vor. Ich würde Dir daher zu Python raten. > Oder auf lange sich gar alle drei Sprachen? (C, C++, Python) Ich verwende beruflich C++ jeden Tag. Wenn Du C++ kannst Du auch C. Neben einer Sprache wie C oder C++ ist eine Skriptsprache immer sehr hilfreich. Python scheint sich da im E-Technik-Umfeld durchgesetzt zu haben (Alternativen wären z.B. Ruby oder JavaScript). Wenn Du die Zeit / Lust hast, dann guck Dir C++ nach dem Du Python gelernt hast. Sprachen lernen ist ja auch kein Thema, das man endgültig abgeschlossen hat. Ich muss auch täglich immer wieder Sachen nachschlagen. Einfach mal ein Problem in einer Sprache lösen! :-) schöne Grüße, Torsten
Ruediger schrieb: > Ebenfalls > objektorientiert, stelle ich mir die Data Science und Neural Network > Features ... Wird hier jetzt bald Bullshit-Bingo gespielt?
Torsten R. schrieb: > Man kann aber auch anfangen seine C Software mit einem C++ Compiler zu > übersetzen und dann langsam die neuen features von C++ zu nutzen. Kann man machen, C++ lernt man dadurch aber eher nicht. Besser, man vergisst alles, was man ueber C weiss und faengt von vorn an -- C++ ist konzeptuell eine voellig andere Sprache.
Ruediger schrieb: > Welche Sprache macht nach C am meisten Sinn? Ich nehme an du benutzt C fuer Programmierung von Microcontrollers. Vertiefe dich mal in eine Programmiersprache fuer den PC, zB C#. Dann kann man die programmierte controller mit PC reden lassen und das zB schoene grafiken machen. Das oeffnet eine ganz neue welt. Patrick aus die Niederlaende
Ich würde zu Python raten. Wenn du C und Python beherrschst, wird C++ auch kein Problen sein, wenn du es mal brauchst. Python hat halt umfangreiche Bibliotheken wie NumPy, scipy, matplotlib, diverse GUIs ... . Aber auch im Standard sind schon viele Sachen wie Reguläre Ausdrücke, Lambdafunktionen und oder auch Docstrings hunderte andere interessante Sachen enthalten.
Thomas schrieb: > Ruediger schrieb: >> Ebenfalls >> objektorientiert, stelle ich mir die Data Science und Neural Network >> Features ... > > Wird hier jetzt bald Bullshit-Bingo gespielt? Nö, sind einfach nur englische Begriffe, wie sie halt im Bereich Computer - äh Verzeihung, elektronische Rechenmaschinen - häufig vorkommen. Patrick C. schrieb: > Ruediger schrieb: >> Welche Sprache macht nach C am meisten Sinn? > > Ich nehme an du benutzt C fuer Programmierung von Microcontrollers. > Vertiefe dich mal in eine Programmiersprache fuer den PC, zB C#. > Dann kann man die programmierte controller mit PC reden lassen und das > zB schoene grafiken machen. Das oeffnet eine ganz neue welt. Das (und zwar beides) geht auch mit C++.
Ruediger schrieb: > Oder auf lange sich gar alle drei Sprachen? (C, C++, Python) > > Auf Java hab ich gar keine Lust, ebenfalls Sprachen wie Javascript oder > völlige Nischensprachen interessieren mich eher weniger. > > Was würdet ihr empfehlen? Bleib doch bei C und versuche Dich in SDL oder GTK+ reinzuarbeiten, damit bekommst Du dann die Klickibunti-Grafiken und Fenster von C++ ebenfalls hin. Der Vorteil von C++ ist keiner, weil man dann auch gleich auf Java springen kann. Python weiß ich leider nicht. Wenn dann macht Java von den genannten Sprachen noch Sinn, denn Java ist als einzige Sprache systemunabhängig - kommt darauf an was Du erreichen willst?
Torsten R. schrieb: > Ich verwende beruflich C++ jeden Tag. Wenn Du C++ kannst Du auch C. eine krasse Fehlaussage - ein guter C++ Programmierer ist kein guter C Programmierer und das gilt auch umgekehrt! Du glaubst nur C zu beherrschen, weil Du es irgendwann früher mal gehabt hast - das ist wahrscheinlich? lange her und wenn Du beruflich sowieso nur noch C++ machst, kannst Du es eben nicht mehr ... und die erweiterten Möglichkeiten dank GTK+ und SDL sagen Dir wahrscheinlich sowieso nichts.
:
Bearbeitet durch User
Ruediger schrieb: > Welche Sprache macht nach C am meisten Sinn? Was willst Du denn mit der Sprache machen? KI-Zeug? Server-Sachen, Handy-Apps, CLI-Tools? Klassische Windows-Anwendungen? Moderne Cross-Plattform-Apps? > Überlege mit C++ weiter zu machen. Naja, C++, Java, C# und mit Vorbehalt C: Kennst Du eine davon, kennst Du alle vier. Vergeudete Lebenszeit. Die Gruppe dieser drei oder vier Sprachen ist alles das gleiche, nur anders verpackt. Klar, wer nur C++ und C etc. kennt, wird gleich wieder um die Ecke gekrochen kommen und darauf pochen, dass C++ gar nix mit C zu tun hat usw. Ist aber auch verständlich: Wenn jemand nur Sprachen aus dieser Vierer-Gruppe kennt, denkt er, dass seine Lieblingssprache der Stein der Weisen sei. Es gibt so viele interessante Sprachen die Dich dagegen weiterbringen: Rust, Typescript, Python, Haskell, etc., da lernst Du was neues.
Hi, Ich bin Elektronikentwickler und alle drei Sprachen haben ihre daseinsberechtigung. In C programmiere ich kleine Tools oder auch mittelgroße Mikrocontroller. In C++ zusammen mit Qt5 grafische Tools die ich in der Entwicklung benötige. Python ist ganz cool für einfache Messautomatsierung oder mal eben für ne Messauswertung (MATLAB Lizenzen sind bei uns rar, Octave ist eine Alternative, aber in letzter Zeit nutze ich immer mehr Python hierfür). Ich würde aber nicht behaupten, dass ich eine der Sprachen perfekt beherrsche. Insbesondere bei C++ nutze ich es vermutlich mehr als C mit Klassen. Da gibt es ganz viele sprachkonstruke wie Vererbung, überladene Funktionen, die ich nur ganz selten nutze. Was ich aber empfehlen kann, ist sich mit Software Architektur zu beschäftigen. Je größer dein Tool wird und je mehr man es nachträglich erweitert, fällt einem das auf. Auch das Wissen von bewährten Konzepten wie Fifo, Ringbuffer, State Maschines, einfache Parser ist nie verkehrt. In C++ vielleicht etwas eleganter als in C wo man schnell auch mal mit Function-Pointern arbeiten muss. Auch sich mit Unittest beschäftigen ist sinnvoll.
Ich würde mit Python beginnen und dort die Konzepte der objektorientierten Programmierung kennen zu lernen. Dies erweitert auch die C++ Kenntnisse. Python ist auf Plattformen wie Raspberry Pi sehr gebräuchlich.
:
Bearbeitet durch User
Robert K. schrieb: > Bleib doch bei C und versuche Dich in SDL oder GTK+ reinzuarbeiten, > damit bekommst Du dann die Klickibunti-Grafiken und Fenster von C++ > ebenfalls hin. Das ist im Falle von GTK+ ein Fall von "poor man's oo" und... echt jetzt? > Der Vorteil von C++ ist keiner, weil man dann auch gleich auf Java > springen kann. C++ ist heute ähnlich plattformunabhängig wie Java, aber deutlich schneller und ressourcenschonender, und man kann nativ auch C-Libraries nutzen, ohne über das lahme JNI zu gehen -- und man muß sich nicht mit dem dummen Garbage Collector herumprügeln... > Python weiß ich leider nicht. Ist halt nochmal technisch eine ganz andere Nummer, und hat eine unglaublich große und leistungsfähige Infrastruktur. > Wenn dann macht Java von den genannten Sprachen noch Sinn, denn Java ist > als einzige Sprache systemunabhängig - kommt darauf an was Du erreichen > willst? Angesichts der unklaren Lizenzsituation ist das ein sehr unsicherer Kandidat für die Zukunftssicherheit. Und nach den jüngsten Änderungen in Java ist es heute sogar so, daß etliche Programme ihre eigene Java-Umgebung mitdeployen... Wow.
Experte schrieb: > Naja, C++, Java, C# und mit Vorbehalt C: Kennst Du eine davon, kennst Du > alle vier. > > Vergeudete Lebenszeit. Die Gruppe dieser drei oder vier Sprachen ist > alles das gleiche, nur anders verpackt. Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist aufwändig, fehleranfällig und häßlich.
Beitrag #6736308 wurde von einem Moderator gelöscht.
Beitrag #6736391 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar > Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist > aufwändig, fehleranfällig und häßlich. Warum ist das häßlich? Solange man höchstens 1 Objekt braucht isses doch erträglich. static-Variablen sind eh privat aus der Sichtbarkeit fürn Linker, warum die Dinger nicht als private Member nutzen. Und öffentliche Symbole werden halt per extern im Header geshared. Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das ganze Ableitungsgeraffel. Für viele ganz einfache Anwendungen auf Microcontrollerbasis doch vollkommen ausreichend. Mit FunctionPointern kann man auch Observer bauen und DI/IoC realisieren. Mehr Schreiberei mags vielleicht sein, aber nur schlecht ist das nicht, schließlich verstecken/überdeckt so manche andere Sprache auch gerne mal implizit vom Compiler übernommene Sachen. Verglichen mit Python isses freilich kompliziert, aber ist halt C und kein Python.
1 | // HausController.h |
2 | |
3 | bool Haus_setLight(bool); |
4 | bool Haus_getLight(); |
5 | float Haus_getTemperature(); |
6 | float Haus_getHumidity(); |
7 | |
8 | void Haus_update(); // berechnet zustand und benachrichtigt obs über zustandsänderungen |
9 | |
10 | void Haus_addObserver( void(*obs)() ); |
11 | void Haus_removeObserver( void(*obs)() ); |
1 | // HausController.c |
2 | |
3 | // |
4 | static void(*sObservers)()[5] = { NULL, NULL, NULL, NULL, NULL};
|
5 | |
6 | static float sHumidity=0.f; |
7 | static float sTemperature=0.f; |
8 | static bool sLight=false; |
9 | |
10 | static void notify() |
11 | {
|
12 | for( int i=0; i<5; ++i) |
13 | {
|
14 | if( sObservers[i] != NULL ) |
15 | {
|
16 | sObservers[i](); |
17 | } |
18 | } |
19 | } |
20 | |
21 | void Haus_update() |
22 | {
|
23 | bool change=false; |
24 | |
25 | // query sensors |
26 | float val=Humidity_getValue(); |
27 | |
28 | if( val != sHumidity) |
29 | {
|
30 | sHumidity = val; |
31 | change=true; |
32 | } |
33 | |
34 | // ... temp, light, usw. |
35 | |
36 | if(change) |
37 | {
|
38 | notify(); |
39 | } |
40 | } |
41 | |
42 | |
43 | // usw |
Irgendwie so, von der Idee her
db8fs schrieb: > Sheeva P. schrieb: >> Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar >> Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist >> aufwändig, fehleranfällig und häßlich. > > Warum ist das häßlich? Schon wegen der Namensräume. Schau Dir Deinen Code an: jede Funktion hat dafür extra ein eigenes Präfix. Und, bitte entschuldige... void-Pointer zu übergeben ist doch recht fehleranfällig und wenig typsicher, oder siehst Du das anders? > Solange man höchstens 1 Objekt braucht isses doch erträglich. Naja, Dein Beispiel ist ein Beispiel, nicht mehr, aber... also ich habe hier im Haus durchaus mehrere Sensoren, mehrere Lichtquellen, ... und da sind wir dann schon bei mehreren Objekten. > Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das > ganze Ableitungsgeraffel. Für viele ganz einfache Anwendungen auf > Microcontrollerbasis doch vollkommen ausreichend. Mit FunctionPointern > kann man auch Observer bauen und DI/IoC realisieren. Mehr Schreiberei > mags vielleicht sein, aber nur schlecht ist das nicht, schließlich > verstecken/überdeckt so manche andere Sprache auch gerne mal implizit > vom Compiler übernommene Sachen. Klar, man kann. Aber muß man, obwohl doch eine einfache Möglichkeit zur Verfügung steht, das Ganze wesentlich eleganter, ausdrucksstärker, und auch wiederverwendbarer zu gestalten? Warum? Okay, ich weiß: dieses "Vererbungsgeraffel" ist für viele gestandene C-Leute ein echtes Hindernis und ein Grund für eine tief, sehr tief sitzende Abneigung. Aber wenn man das einmal verstanden hat, und so kompliziert ist es gar nicht (es wird nur oft sehr schlecht und kompliziert erklärt), kann das extrem nützlich sein -- und zwar, ja, auch bei einfachen Mikrocontrolleranwendungen. Es ist halt einfach wesentlich schöner und lesbarer, etwas zu schreiben wie:
1 | #include "hal.hpp" |
2 | |
3 | int main(void) { |
4 | Motor motor (PINDEF(B, PB1)); |
5 | Beleuchtung beleuchtung (PINDEF(B, PB2)); |
6 | |
7 | Startknopf startknopf (PINDEF(D, PD1)); |
8 | Bremse bremse (PINDEF(D, PD2)); |
9 | |
10 | Getriebe gang (PINDEF(D, PD3)); |
11 | |
12 | |
13 | while(1) { |
14 | if (startknopf.gedrueckt()) { |
15 | beleuchtung.ein(); |
16 | if (gang.eingelegt() and bremse.gedrueckt()) { |
17 | motor.ein(); |
18 | }
|
19 | } else { |
20 | motor.aus(); |
21 | beleuchtung.aus(); |
22 | }
|
23 | }
|
24 | }
|
als
1 | #include <avr/io.h> |
2 | |
3 | /* outputs */
|
4 | #define MOTOR PB1
|
5 | #define BELEUCHTUNG PB2
|
6 | |
7 | /* inputs */
|
8 | #define STARTKNOPF PD1
|
9 | #define BREMSE PD2
|
10 | #define GANG PD3
|
11 | |
12 | int main(void) { |
13 | |
14 | DDRB |= ((1 << MOTOR) | (1 << BELEUCHTUNG)); |
15 | |
16 | while(1) { |
17 | if(PIND & (1 << STARTKNOPF)) { /* startknopf.gedrueckt */ |
18 | PORTB |= (1 << BELEUCHTUNG); /* beleuchtung.ein */ |
19 | /* gang.eingelegt + bremse.gedrueckt */
|
20 | if( (PIND & (1 << PD3)) && (PIND & (1 << PD2)) ) { |
21 | PORTB |= (1 << MOTOR); /* motor.ein */ |
22 | }
|
23 | } else { |
24 | PORTB &= ~(1 << MOTOR); /* motor.aus */ |
25 | PORTB &= ~(1 << BELEUCHTUNG); /* beleuchtung.aus */ |
26 | }
|
27 | }
|
28 | }
|
Also, klar, ich kann da nur für mich sprechen, aber beim ersten Code sehe ich ohne Kommentare, was er tut. Klar, beim C-Code könnte man das auch noch nett in Funktionen verpacken und dann vielleicht ähnlich lesbar sein, aber... da würden diese Funktionen halt meistens nicht wiederverwendbar sein. Und am Ende habe ich für den ersten Code nichtmal Templates oder Vererbung benutzt, und die Kompilate sind -- waren: das habe ich 2017 gemacht -- tatsächlich sogar identisch! Schau, ich bestreite keinesfalls, daß man alles, was in C++ geht, auch in C und auch in Assembler machen kann, wenn man es kann. Das ist nicht der Punkt. Für mich als jemand, der jeden Tag Code liest, analysiert, schreibt, ist es aber ein wesentliches Merkmal einer Programmiersprache, wie lesbar der Code ist -- oder, wie lesbar ich ihn bei gleichzeitiger Wiederverwendbarkeit gestalten kann. Aus solchen Erwägungen heraus bin ich vor 10+ Jahren von meiner damaligen Lieblingsskriptsprache Perl zu meiner neuen, Python, gewechselt. Und ja, ich konnte sauberen und lesbaren objektorientierten Code in Perl schreiben, aber dafür mußte ich mir Mühe geben und diszipliniert sein. Heute in Python muß ich mir Mühe geben, um schlecht lesbaren Code zu schreiben. Und das macht für mich einen sehr, sehr wesentlichen und wichtigen Unterschied aus. (Mal von anderen Erwägungen wie Infrastruktur etc ganz abgesehen...) > Verglichen mit Python isses freilich kompliziert, aber ist halt C und > kein Python. Ist halt ne andere Sprachfamilie und insofern nach meinem Dafürhalten gar nicht direkt vergleichbar, kein Problem insoweit. ;-)
db8fs schrieb: > Sheeva P. schrieb: >> Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar >> Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist >> aufwändig, fehleranfällig und häßlich. > > Warum ist das häßlich? Solange man höchstens 1 Objekt braucht isses doch > erträglich. Dann würde ich aber nicht von objektorientierter Programmierung sprechen. > Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das > ganze Ableitungsgeraffel. Aber gerade das ist eigentlich der Kern der Objektorientierung. Also klar kann man in C auch ganz gut objektorientiert programmieren, solange man alles weglässt, was objektorientierte Programmierung ausmacht.
db8fs (Gast) 24.06.2021 19:32 >Sheeva P. schrieb: >> Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar >> Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist >> aufwändig, fehleranfällig und häßlich. >Warum ist das häßlich? Hier eine Sichtweise auf die Schönheit von C++ : Beitrag "Re: Informationen zu C vs C++ / aka Futter für die Diskussion"
Wenn du C++ beruflich erst mal nicht benötigst, würde ich zunächst zu Python tendieren. Alleine schon um gewisse lästige Dinge automatisieren zu können.
Schau dir ein Programmpaket wie Blender oder TensorFlow an. Wenn du auf Geschwindigkeit optimieren musst, schreibst du das Modul in C++. Alles andere in Python. Wenn du mehrere Sprachen in einem Programm verwendest, lernst du ganz nebenbei, wie man saubere objektorientierte Schnittstellen konzipiert. Ob sich Python und C++ halten? Sieht so aus. In diesen alten Sprachen haben sich so einige Fehlentscheidungen angesammelt. Gab schon mehre Versuche mit neuen Sprachen ohne diese alten Macken. Aber keine hat sich durchgesetzt.
Sheeva P. schrieb: > db8fs schrieb: >> Sheeva P. schrieb: > Schon wegen der Namensräume. Schau Dir Deinen Code an: jede Funktion hat > dafür extra ein eigenes Präfix. Und, bitte entschuldige... void-Pointer > zu übergeben ist doch recht fehleranfällig und wenig typsicher, oder > siehst Du das anders? Och, na ja, kommt halt drauf an. Sollten ja eigentlich Funktionspointer auf void-Funktionen mit Rückgabe-void und keinen Argumenten sein. War nur ein Draft hier. Aber grundsätzlich geb ich Dir recht, typesafe und fehler - klar, haste halt bei C. Dafür isses schön kompakter Code. > Naja, Dein Beispiel ist ein Beispiel, nicht mehr, aber... also ich habe > hier im Haus durchaus mehrere Sensoren, mehrere Lichtquellen, ... und da > sind wir dann schon bei mehreren Objekten. Stimmt. Hängt halt vom Design des jeweiligen Controller-Objektes (z.B. Haus) ab, was alles rübergegeben wird. Ich sag ja nicht, dass C eine Programmiersprache ist, die Objektorientierung explizit durch vom Sprachdesign her unterstützt. Aber wählt man die anzulegenden Objekte richtig, kann man es zumindest gut in die Richtung annähern. OO-Design kann man also auch mit C machen. Anderer Ansatz wäre es, zusammengesetzte Datentypen (Structs/Arrays) als Objekte zu sehen (ginge in Richtung C++-Objektmodell), siehe EFL-Libraries. > Klar, man kann. Aber muß man, obwohl doch eine einfache Möglichkeit > zur Verfügung steht, das Ganze wesentlich eleganter, ausdrucksstärker, > und auch wiederverwendbarer zu gestalten? Warum? Weil ich glaube, dass die Eleganz bei der Entwicklung im SW-Design und nicht in der Wahl der Programmiersprache liegen sollte. Klar, man kann in Python schön einen Draft machen und einen Wrapper um C-Funktionen bauen. Wie sollte man denn den Wrapper machen? Für volle Multiplizität auslegen, oder sähe es nicht eleganter aus, wenn man nur ein Objekt im Python bräuchte, dass nur ein Singleton-C-'Objekt' bedienen müsste? Gerade bei Low-Level-Libraries fände ich das ein schöneres API-Design als irgendwelche HANDLEs über Programmiersprachengrenzen hinaus teilen/wrappen zu müssen. > Okay, ich weiß: dieses "Vererbungsgeraffel" ist für viele gestandene > C-Leute ein echtes Hindernis und ein Grund für eine tief, sehr tief > sitzende Abneigung. Aber wenn man das einmal verstanden hat, und so > kompliziert ist es gar nicht (es wird nur oft sehr schlecht und > kompliziert erklärt), kann das extrem nützlich sein -- und zwar, ja, > auch bei einfachen Mikrocontrolleranwendungen. Ey, ich bin C++'ler, aber bei reinen C-Projekten, die eher strukturiert/prozedural orientiert angelegt sind, wünscht man sich tatsächlich manchmal eine bessere Zuordenbarkeit, welches Modul jetzt für was zuständig ist. Da glaub ich, dass der obige Ansatz bissl in die Richtung geht, sagen zu können, unter dem Modul 'Haus' gruppiere ich alles, was funktional dazugehört. Ändere ich was am 'Haus' bzw. möchte was davon wissen, greif ich genau auf das Objekt zu. Und leg mir nicht ne potentielle Objekt-Reihenhaussiedlung an, wovon dann nur ein einziges genutzt wird. Wirds dann mal mehr als ein Haus, benennt man den Controller 'Haus' halt zu 'Haeuser' um und modifiziert nach Gusto. Mit Code arbeiten muss man als Programmierer so oder so, ob man will oder nicht. > Es ist halt einfach wesentlich schöner und lesbarer, etwas zu schreiben > wie: > #include "hal.hpp" > int main(void) { > Motor motor (PINDEF(B, PB1)); > Beleuchtung beleuchtung (PINDEF(B, PB2)); > Startknopf startknopf (PINDEF(D, PD1)); > Bremse bremse (PINDEF(D, PD2)); > > Getriebe gang (PINDEF(D, PD3)); > > while(1) { > if (startknopf.gedrueckt()) { > beleuchtung.ein(); > if (gang.eingelegt() and bremse.gedrueckt()) { > motor.ein(); > } > } else { > motor.aus(); > beleuchtung.aus(); > } > } > } > > als > #include <avr/io.h> > /* outputs */ > #define MOTOR PB1 > #define BELEUCHTUNG PB2 > /* inputs */ > #define STARTKNOPF PD1 > #define BREMSE PD2 > #define GANG PD3 > int main(void) { > DDRB |= ((1 << MOTOR) | (1 << BELEUCHTUNG)); > while(1) { > if(PIND & (1 << STARTKNOPF)) { /* startknopf.gedrueckt */ > PORTB |= (1 << BELEUCHTUNG); /* beleuchtung.ein */ > /* gang.eingelegt + bremse.gedrueckt */ > if( (PIND & (1 << PD3)) && (PIND & (1 << PD2)) ) { > PORTB |= (1 << MOTOR); /* motor.ein */ > } > } else { > PORTB &= ~(1 << MOTOR); /* motor.aus */ > PORTB &= ~(1 << BELEUCHTUNG); /* beleuchtung.aus */ > } > } > } > Findeste? Aus deiner Modellierung käme für mich z.B. überhaupt nicht der strukturelle Zusammenhang zwischen Motor, Beleuchtung, Startknopf, Bremse und Gang hervor. Wenn man das in C abbilden wollte, müsste man structs zusammmensetzen, z.B. sturct Fahrzeug oder so. Wie gesagt, mein obiger Ansatz ist was Controllerobjekte, nicht für Daten. > Also, klar, ich kann da nur für mich sprechen, aber beim ersten Code > sehe ich ohne Kommentare, was er tut. Klar, beim C-Code könnte man das > auch noch nett in Funktionen verpacken und dann vielleicht ähnlich > lesbar sein, aber... da würden diese Funktionen halt meistens nicht > wiederverwendbar sein. Und am Ende habe ich für den ersten Code nichtmal > Templates oder Vererbung benutzt, und die Kompilate sind -- waren: das > habe ich 2017 gemacht -- tatsächlich sogar identisch! Jo, gut. > Schau, ich bestreite keinesfalls, daß man alles, was in C++ geht, auch > in C und auch in Assembler machen kann, wenn man es kann. Das ist nicht > der Punkt. Für mich als jemand, der jeden Tag Code liest, analysiert, > schreibt, ist es aber ein wesentliches Merkmal einer Programmiersprache, > wie lesbar der Code ist -- oder, wie lesbar ich ihn bei gleichzeitiger > Wiederverwendbarkeit gestalten kann. Klar, Wahl der richtigen Mittel. Oft ist bei bestehenden Projekten diese Wahl bereits getroffen - was willsten machen? Alles auf der neu schreiben? Hast halt die einen Fehler dann nicht mehr und dafür dann andere. > Aus solchen Erwägungen heraus bin ich vor 10+ Jahren von meiner > damaligen Lieblingsskriptsprache Perl zu meiner neuen, Python, > gewechselt. Und ja, ich konnte sauberen und lesbaren objektorientierten > Code in Perl schreiben, aber dafür mußte ich mir Mühe geben und > diszipliniert sein. Heute in Python muß ich mir Mühe geben, um schlecht > lesbaren Code zu schreiben. Und das macht für mich einen sehr, sehr > wesentlichen und wichtigen Unterschied aus. (Mal von anderen Erwägungen > wie Infrastruktur etc ganz abgesehen...) Python ist vom Sprachkonzept her, sehr gut durchgedacht. Musst halt potentiell oft die Laufzeitumgebungen, Packages und Gedöns pflegen - den Overhead haste in C/C++ nicht so, wenn du nicht immer den neuesten Kram verwendest.
Rolf M. schrieb: >> Warum ist das häßlich? Solange man höchstens 1 Objekt braucht isses doch >> erträglich. > > Dann würde ich aber nicht von objektorientierter Programmierung > sprechen. Hab ich ja auch nicht :) Nur davon, dass man Objekte auch in C ganz gut abbilden kann. >> Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das >> ganze Ableitungsgeraffel. > > Aber gerade das ist eigentlich der Kern der Objektorientierung. Na ja, auch. Eigentlich wird ja immer empfohlen explizit vor implizit. Was macht Polymorphie? Implizit alle Eigenschaften übertragen, die der Abgelittene nach Liskov auch zwingend beibehalten müsste. Was macht der Compiler? Überträgt die Basisobjekt quasi als 'Feld' in das abgeleitete Objekt - implizit. Da kann ich die Basisklasse mir auch als Member halten, ohne abzuleiten. > Also klar kann man in C auch ganz gut objektorientiert programmieren, > solange man alles weglässt, was objektorientierte Programmierung > ausmacht.
db8fs schrieb: > Was macht Polymorphie? Es bietet mir die Möglichkeit, eine Funktion aufzurufen, und es wird dann automatisch zur Laufzeit die zum Objekt passende Implementation gewählt (dynamic dispatch). Der Rest ist syntaktischer Zucker, insbesondere: > Implizit alle Eigenschaften übertragen, die der Abgelittene nach Liskov > auch zwingend beibehalten müsste. Was macht der Compiler? Überträgt die > Basisobjekt quasi als 'Feld' in das abgeleitete Objekt - implizit. Da kann > ich die Basisklasse mir auch als Member halten, ohne abzuleiten. Und dann behandle ich alle abgeleiteten Klassen in einem switch/case? Das ist zwar explizit, dafür aber unflexibel und erzeugt unnötige Abhängigkeiten.
db8fs schrieb: > Sheeva P. schrieb: >> db8fs schrieb: >>> Sheeva P. schrieb: > Stimmt. Hängt halt vom Design des jeweiligen Controller-Objektes (z.B. > Haus) ab, was alles rübergegeben wird. Ich sag ja nicht, dass C eine > Programmiersprache ist, die Objektorientierung explizit durch vom > Sprachdesign her unterstützt. Aber wählt man die anzulegenden Objekte > richtig, kann man es zumindest gut in die Richtung annähern. OO-Design > kann man also auch mit C machen. Klar kann man das tun. Aber wie Du schon absolut richtig sagst: C unterstützt das nun einmal nicht nativ, und man muß alles selbst machen, während C++ dafür aus dem Stand eine hervorragende Unterstützung bietet. Warum sollte ich etwas selbst machen, das es woanders schon fertig gibt und das nichts kostet? Sogar der (ohnehin einmalige) Aufwand, OO zu lernen, wird bei C++ viel kleiner sein. ;-) Nebenbei bemerkt ist die OO ja nicht zuletzt auch aus dem entstanden, was bei prozeduralen ohnehin schon guter Stil war. Sehr schön kann man das in dem Buch "Making Embedded Systems" von Elecia White lesen (O'Reilly). > Weil ich glaube, dass die Eleganz bei der Entwicklung im SW-Design und > nicht in der Wahl der Programmiersprache liegen sollte. Naja, ich glaube, daß die Eleganz einer Software nicht nur in ihrem Design, sondern auch in ihrer Implementierung liegt. In beiden Fällen erscheint mir C++ aber dann schon deswegen im Vorteil, wenn es mehr Paradigmen unterstützt und somit eine größere Auswahl hinsichtlich der verfügbaren Designs bietet. > Klar, man kann > in Python schön einen Draft machen und einen Wrapper um C-Funktionen > bauen. Wie sollte man denn den Wrapper machen? Für volle Multiplizität > auslegen, oder sähe es nicht eleganter aus, wenn man nur ein Objekt im > Python bräuchte, dass nur ein Singleton-C-'Objekt' bedienen müsste? > Gerade bei Low-Level-Libraries fände ich das ein schöneres API-Design > als irgendwelche HANDLEs über Programmiersprachengrenzen hinaus > teilen/wrappen zu müssen. Jaaaa... und nein. Python ist (meistens) eine interpretierte Skriptsprache und somit eine gänzlich andere Sprachfamilie. Von den technischen Unterschieden, die hier sicherlich jedem bekannt sind, einmal abgesehen, ist das letztlich nur eine ökonomische Frage, ob man C++ oder Python verwendet. Trotzdem kann es sinnvoll sein, Teile einer Software in schnellem und ressourcensparendem C oder C++ zu entwickeln, und diese Teile dann in eine interpretierte Skriptsprache wie Python einzubetten. Dazu habe ich sogar ein sehr konkretes Beispiel aus meiner eigenen jüngeren praktischen Vergangenheit. In den letzten Wochen habe ich ein bisschen mit Natural Language Processing und Machine Learning experimentiert mit dem Ziel, Trolle und andere Störer in einer Echtzeit-Kommunikation (think IRC, Webchat, Messenger, ...) automatisiert zu erkennen. Python bietet mit dem NLTK, scikit-learn und andere eine herausragende Infrastruktur für so etwas. Andererseits geht es um Echtzeitkommunikation, das muß also gewisse zeitliche Beschränkungen einhalten, und schon die Aufbereitung der Texte (Tokenizing, Lemmatisierung / Stemming, Umformung in eine Bag Of Words, Erzeugung von N-Grammen, ...) ist ziemlich aufwändig, sowohl im Hinblick auf den Ressourcen-, als auch den Zeitbedarf. Also habe ich diesen Teil in einer kleinen C++-Klasse implementiert und sie mit Boost::Python in mein Python-Programm eingebaut. Trotzdem kann ich sie zusammen mit der erwähnten Python-Infrastruktur zur Lösung des Problems nutzen, das geht ganz wunderbar und zudem extrem performant. Auf diese Weise bekomme ich das Beste aus beiden Welten: die extreme Flexibilität und Infrastruktur von Python und die extrem hohe Performance von C++. >> Okay, ich weiß: dieses "Vererbungsgeraffel" ist für viele gestandene >> C-Leute ein echtes Hindernis und ein Grund für eine tief, sehr tief >> sitzende Abneigung. Aber wenn man das einmal verstanden hat, und so >> kompliziert ist es gar nicht (es wird nur oft sehr schlecht und >> kompliziert erklärt), kann das extrem nützlich sein -- und zwar, ja, >> auch bei einfachen Mikrocontrolleranwendungen. > > Ey, ich bin C++'ler, Okay, dann gilt das nicht für Dich, aber in anderen Fällen sieht das leider ein bisschen anders aus, fürchte ich. ;-) > aber bei reinen C-Projekten, die eher > strukturiert/prozedural orientiert angelegt sind, wünscht man sich > tatsächlich manchmal eine bessere Zuordenbarkeit, welches Modul jetzt > für was zuständig ist. Bitte verzeih', aber inwieweit hat das Deiner Meinung nach mit dem jeweiligen Paradigma oder der verwendeten Sprache zu tun? > Da glaub ich, dass der obige Ansatz bissl in die > Richtung geht, sagen zu können, unter dem Modul 'Haus' gruppiere ich > alles, was funktional dazugehört. Naja, ich würde das halt... objektorientiert machen. Ich habe dann also ein Haus, und dieses Haus hat beliebig viele Sensoren und Aktoren. > Ändere ich was am 'Haus' bzw. möchte > was davon wissen, greif ich genau auf das Objekt zu. Und leg mir nicht > ne potentielle Objekt-Reihenhaussiedlung an, wovon dann nur ein einziges > genutzt wird. Wirds dann mal mehr als ein Haus, benennt man den > Controller 'Haus' halt zu 'Haeuser' um und modifiziert nach Gusto. Mit > Code arbeiten muss man als Programmierer so oder so, ob man will oder > nicht. Bitte versteh' mich nicht falsch, ich möchte hier keinem Overengineering das Wort reden, aber: mein Haus-Objekt als eigenständige Einheit kann am Ende in vielen verschiedenen Inkarnationen auftreten, obwohl es immer dasselbe Haus ist. Mein Haus kann also ein einfaches Einfamilienhaus, ein Bestandteil zweier getrennter Doppelhaushälften, oder auch ein Bestandteil einer Reihenhaussiedlung sein. Und egal, was ich damit verwalten oder steuern will: es ist immer dasselbe Haus, das ich nur ein einziges Mal schreiben muß. Ich bin ein Anhänger von Larry Walls vier Kardinaltugenden des Programmierers, besonders der Faulheit. ;-) >> Es ist halt einfach wesentlich schöner und lesbarer, etwas zu schreiben >> [...] > > Findeste? Ja, unbedingt! > Aus deiner Modellierung käme für mich z.B. überhaupt nicht der > strukturelle Zusammenhang zwischen Motor, Beleuchtung, Startknopf, > Bremse und Gang hervor. Wenn man das in C abbilden wollte, müsste man > structs zusammmensetzen, z.B. sturct Fahrzeug oder so. Wie gesagt, mein > obiger Ansatz ist was Controllerobjekte, nicht für Daten. Was hinderte mich denn, das in C++ genauso zu machen, und Motor, Beleuchtung, Startknopf, Bremse und Gang in eine Klasse "Fahrzeug" zu packen und die kleine Logik aus der main()-Funktion in eine Methode dieser Klasse? Genau, nichts, das muß ich Dir doch nicht erklären. Und trotzdem bleibt es ebenso offensichtlich, was der Code tut. >> die Kompilate sind -- waren: das >> habe ich 2017 gemacht -- tatsächlich sogar identisch! > > Jo, gut. Deine etwas... knappe Antwort darauf finde ich, Pardon, jetzt schon ein wenig unbefriedigend, denn das ist in den meisten Diskussionen zum Thema OOP, die ich hier im Forum verfolgen durfte, einer der wichtigsten Hauptpunkte: daß OOP so schrecklich groß und aufgebläht und teuer sei. Das ist aber gar nicht so, wenn man einige einfache Regeln einhält, und deswegen spricht in der Sache auch rein gar nichts gegen C++, sondern stattdessen vieles dafür. > Klar, Wahl der richtigen Mittel. Oft ist bei bestehenden Projekten diese > Wahl bereits getroffen - was willsten machen? Alles auf der neu > schreiben? Hast halt die einen Fehler dann nicht mehr und dafür dann > andere. Das kann natürlich nicht die Idee sein, und das habe ich auch nicht behauptet. Allerdings ist die Abwärtskompatibilität mit C eine der wichtigsten Stärken von C++ (allerdings hie und da auch eine der größten Schwächen ;-)). Insofern kann ich -- und habe ich schon häufig -- einfach vorhandenen C-Code in C++ genutzt, meistens funktioniert das wunderbar. > Python ist vom Sprachkonzept her, sehr gut durchgedacht. Musst halt > potentiell oft die Laufzeitumgebungen, Packages und Gedöns pflegen - den > Overhead haste in C/C++ nicht so, wenn du nicht immer den neuesten Kram > verwendest. Für soetwas gibt es in Python das "virtualenv" und in neueren Versionen das Modul "venv". Damit erstelle ich mir eine in sich geschlossene Umgebung mit ihrem eigenen Interpreter und ihren eigenen Modulen, die ich wahlweise auf bestimmte Versionen festzurren und auch jederzeit aktualisieren kann, ganz unabhängig von der Systemumgebung und -Installation -- "pip install -U -r reqirements.txt" reicht dazu vollkommen aus, und schon ist alles aktuell. Dabei erstelle ich die betreffende Datei einfach mit "pip freeze > requirements.txt", und wenn ich die dabei verwendeten Modulversionen benutzen müchte, lasse ich beim ersten Befehl einfach den Schalter "-U" weg... einfacher geht's kaum. ;-)
db8fs schrieb: > Rolf M. schrieb: >>> Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das >>> ganze Ableitungsgeraffel. >> >> Aber gerade das ist eigentlich der Kern der Objektorientierung. > > Na ja, auch. Eigentlich wird ja immer empfohlen explizit vor implizit. Äh, eigentlich kenne ich das nur aus dem Zen Of Python (PEP20)... > Was macht Polymorphie? Implizit alle Eigenschaften übertragen, Nein, explizit. Ich gebe ja bei meiner Klasse explizit an, wovon sie erbt, womit dann auch explizit klar ist, was sie erbt... ;-) > die der > Abgelittene nach Liskov auch zwingend beibehalten müsste. Nicht die Eigenschaften, sondern die Schnittstelle. > Was macht der > Compiler? Überträgt die Basisobjekt quasi als 'Feld' in das abgeleitete > Objekt - implizit. Da kann ich die Basisklasse mir auch als Member > halten, ohne abzuleiten. ... was ohnehin viel öfter eine gute Idee ist, als manche Vererbungsfanatiker wahrhaben wollen. ;-)
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.