Forum: PC-Programmierung Nach C: Python oder C++


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ruediger (Gast)


Lesenswert?

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

von Johannes S. (Gast)


Lesenswert?


von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Thomas (Gast)


Lesenswert?

Ruediger schrieb:
> Ebenfalls
> objektorientiert, stelle ich mir die Data Science und Neural Network
> Features ...

Wird hier jetzt bald Bullshit-Bingo gespielt?

von Sven B. (scummos)


Lesenswert?

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.

von Patrick C. (pcrom)


Lesenswert?

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

von Karl (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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

von Robert K. (Firma: Zombieland) (rko)


Lesenswert?

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?

von Robert K. (Firma: Zombieland) (rko)


Lesenswert?

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
von Experte (Gast)


Lesenswert?

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.

von Freddy (Gast)


Lesenswert?

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.

von db8fs (Gast)


Lesenswert?

Objective-C

von Gerald K. (geku)


Lesenswert?

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
von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.
von db8fs (Gast)


Lesenswert?

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

von Sheeva P. (sheevaplug)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Christoph M. (Gast)


Lesenswert?

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"

von P. S. (namnyef)


Lesenswert?

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.

von Mach beides gleichzeitig (Gast)


Lesenswert?

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.

von db8fs (Gast)


Lesenswert?

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.

von Dieter H. (kyblord)


Lesenswert?

python is besser. da gibtsgarbage collector ^^

von db8fs (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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

von Sheeva P. (sheevaplug)


Lesenswert?

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.