Überladen / Überschreiben von Funktionen in C möglich?

[+fricky]

Dravere schrieb:

Wurden ja schon genannt: Referenzen, Überladung.

wurde auch schon genannt: referenzen sind sinnlos, wo es pointer gibt. über überladung kann man geteilter meinung sein. ich bin der meinung, dass überladung mehr schaden anrichten kann, als dass es hilft.

Dravere schrieb:

Templates, Standardbibliothek (ein std::vector oder sowas dürfte auch in der prozeduralen Programmierung sehr hilfreich sein).

std::vector, stl und der ganze template-bloat ist in umgebungen, wo heute C eingesetzt wird, oft nicht erwünscht. leg' auf 'nem embedded system ein paar stl-instanzen an und der speicher ist voll. C ist dagegen wesentlich ressourcenschonender.

Dravere schrieb:

Und vor allem, wieso tun sich die C Programmierer sich immer mit ihrer untypisierten Sprache herumschlagen...

C ist genau so gut (oder schlecht) typisiert wie C++.

Dravere schrieb:

... wo eine Liste zur reinsten Qual wird.

macht du witze? unter C kann man sogar komplette SQL-datenbanksysteme (die selber in C geschrieben sind) in den eigenen code einbetten. und du meinst, 'ne liste wäre eine echte schwierigkeit?

Dravere schrieb:

Du kannst in C++ genauso prozedural programmieren, aber die Hilfsmittel von C++ dazu nehmen. Was spricht dagegen?

diese vermeintlichen 'hilfsmittel' helfen überhaupt nicht. der einzige vorteil von C++ gegenüber C ist die eingebaute objektorientierung. aber selbst wenn man OO nutzen möchte, stellt sich die frage, ob man überhaupt C++ verwenden sollte. ich meine, es gibt *immer* bessere alternativen als C++.

[pointercrash**]

+fricky schrieb:

diese vermeintlichen 'hilfsmittel' helfen überhaupt nicht. der einzige vorteil von C++ gegenüber C ist die eingebaute objektorientierung. aber selbst wenn man OO nutzen möchte, stellt sich die frage, ob man überhaupt C++ verwenden sollte. ich meine, es gibt *immer* bessere alternativen als C++.

Jetzt habt ihr meinen letzten Post "overflamed" (S.6u), was haltet ihr von Objective C? Sieht doch auf den ersten Blick netter aus als C++ - oder?

[Dravere]

@supertux,
Ich hatte gefragt, wo es ausser in der ABI und in subjektiven Meinungen Nachteile gibt.

@fricky+,
Überzeugt mich nicht wirklich, was du da schreibst. Liest sich mehr, wie jemand der eine Abneigung gegen C++ hat
Was wirklich interessant wäre, sind Testberichte von Leuten, welche es ernsthaft versucht haben. Sowas muss es doch geben irgendwo im weiten Netz? Irgendwann hat sich doch sicher ein Student oder jemand anderes dies probiert? Es kommt mir nämlich wie mit der Programmierung von Treibern oder Betriebsystemen vor. Seit ich an der Uni bin, sagt mir jeder Professor, dass dies nur in C möglich sei und in C++ ein Ding der Unmöglichkeit. Wenn ich nachfrage wieso und ob es jemand denn schon mal probiert hätte, dann bekomme ich nur irgendwelche pauschalen Antworten. Bisher habe ich schlicht das Gefühl, dass es noch nie jemand ernsthaft versucht hat, sondern alle haben immer von vornherein aufgegeben.

Grüssli

[Gast]

pointercrash() schrieb:

Hmm, was haltet ihr von Objective C?

Ich persönlich finde die Sprache interessant und irgendwie sympatisch. Für laufzeitkritische Anwendungen (bzw. Programmteile) aber wahrscheinlich nicht wirklich interessant (Stichwort immer dynamic dispatch bei message passing).

pointercrash() schrieb:

Leider habe ich im embedded- Bereich keinen freien, brauchbaren Compiler dafür gefunden

Ich weiss nicht ob du die gcc als brauchbar ansiehst, aber da sollte neben dem C-compiler auch ein objC-Compiler mit rausfallen (wenn er denn mitgebaut wird, woran es wohl scheitert...).

[+fricky]

pointercrash() schrieb:

was haltet ihr von Objective C? Sieht doch auf den ersten Blick netter aus als C++ - oder?

ja, ist 'ne ziemlich runde sache. leider braucht's 'ne laufzeitumgebung, um die messages durch die gegend zu scheuchen, was auf unserem anwendungsgebiet zuviel ressourcen schlucken könnte.

Dravere schrieb:

Liest sich mehr, wie jemand der eine Abneigung gegen C++ hat

das war ja auch nicht schwer zu erraten.

Dravere schrieb:

Es kommt mir nämlich wie mit der Programmierung von Treibern oder Betriebsystemen vor. Seit ich an der Uni bin, sagt mir jeder Professor, dass dies nur in C möglich sei und in C++ ein Ding der Unmöglichkeit.

ach, möglich isses schon. kennste singularity? das ist sogar in C# geschrieben (auf unterster ebene mit etwas C und assembler). zeig das mal deinem prof.

Dravere schrieb:

Wenn ich nachfrage wieso und ob es jemand denn schon mal probiert hätte, dann bekomme ich nur irgendwelche pauschalen Antworten.

ich kenne einige beispiele aus der praxis, in der leute mit C++ schnell an die grenzen ihrer hardware kamen. meine persönlich faustformel lautet: ab etwa 1MB RAM und 1MB ROM könnte man es mit C++ wagen. ich würde es aber trotzdem nicht tun (siehe oben, abneigung und so).

[DEvent]

_matze schrieb:

Dravere schrieb:

Was sind die Vorteile von C bei der prozeduralen Programmierung gegenüber C++?

Ich möchte kurz anmerken, dass man natürlich auch in C objektorientiert programmieren kann (man muss halt nur auf Dinge wie Vererbung usw. verzichten). Ansonsten ist das aber eine interessante Frage und ich bin auf die Antworten gespannt.

Erstmal, seit wann muss man auf Vererbung in C verzichten?

Und zweitens, welchen Vorteil bringt es prozedural zu programmieren? Bis auf den Code in den Methoden habe ich schon seit 10 Jahren nicht prozedural programmiert.

Aber mal eine Frage in die Runde, wieso ist Ueberladung immer nur Funktionsparameter und nicht auch noch der Rueckgabetyp? Also z.B.:

void f(float x) { }

float f(float x) { }

string f(float x) { }

f(5.0f);
float y = f(5.0f);
string str = f(5.0f);

[+fricky]

DEvent schrieb:

Erstmal, seit wann muss man auf Vererbung in C verzichten?

was willste in C vererben? structs in structs packen oder wie?

DEvent schrieb:

Und zweitens, welchen Vorteil bringt es prozedural zu programmieren?

den vorteil, dass man sicht nicht mit oop-konzepten rumschlagen muss, wo es nicht nötig ist.

[DEvent]

+fricky schrieb:

DEvent schrieb:

Erstmal, seit wann muss man auf Vererbung in C verzichten?

was willste in C vererben? structs in structs packen oder wie?

DEvent schrieb:

Und zweitens, welchen Vorteil bringt es prozedural zu programmieren?

den vorteil, dass man sicht nicht mit oop-konzepten rumschlagen muss, wo es nicht nötig ist.

struct Base {
       ...
    }

    struct Derived {
       struct Base parent;
       ...
    }

Gibt auch noch bessere Beispiele, auch mit Kapselung, Ctors, Dtors usw.

Man kann oft auf inheritance oder polymorphism verzichten, die anderen features sind immer praktisch, auch fuer kleine Projekte.

[+fricky]

DEvent schrieb:

die anderen features sind immer praktisch, auch fuer kleine Projekte.

ach quark. oop ist für viele kleinen sachen einfach nur overkill.

[Bashar]

DEvent schrieb:

struct Base {
       ...
    }
    
    struct Derived {
       struct Base parent;
       ...
    }

Du weißt wahrscheinlich selbst, dass das keine Vererbung (is-a), sondern Komposition (has-a) ist. Ein bisschen mehr Unterfütterung würde deiner Argumentation sicher nicht schlecht bekommen.

[Tachyon]

DEvent schrieb:

[...
Aber mal eine Frage in die Runde, wieso ist Ueberladung immer nur Funktionsparameter und nicht auch noch der Rueckgabetyp? Also z.B....

Weil in C der Rückgabetyp nicht zur Signatur gehört. Der Grund hierfür liegt darin, dass man beim Aufruf einer Funktion den Rückgabetyp nicht auswerten muss.
Beispiel:

int f();
float f();
my_crazy_struct * f();

//...

f(); //Aufruf in der Form soll möglich sein, aber welches a soll aufgerufen werden?

In anderen Sprachen wird hier klar zwischen Funktionen (haben Rückgabewert) und Prozeduren (haben keinen Rückgabewert) unterschieden.
Beispiel Ada:

function f return Integer;
function f return Float;

f; --Fehler

Number : Integer := f; //ruft die erste Funktion auf

[Metatron]

Wird reines 'C' heutzutage eigentlich noch zur Anwendungsprogrammierung eingesetzt, oder nimmt jeder nur noch C++/Java dazu her ?
Man kann doch auch mit 'C' ziemlich gut objektorientiert programmieren?

Anstelle von private Variablen kann ein Modul z.B. static Variablen verwenden und den Zugriff darauf nur über entsprechende Funktionen bereitstellen.
Mit Callback Funktionen lässt sich alles (und noch mehr) machen, was man mit virtuellen Funktionen auch tun kann. Callback Funktionen erlauben sogar einen noch höheren Abstraktionsgrad als virtuelle Funktionen (die Callback wird eine x-beliebige Funktion, die z.B. einen void*-Wert entgegennimmt und einen float-Wert zurückliefert, aufrufen, wenn das z.B. ihr Parameter sein sollte. Das erlaubt dem Programmierer eine schier unbegrenzte Flexibilität bezüglich der konkreten Implementierung des Paramters der Callback-Funktion, wie man sie mit virtual Methoden gar nicht hätte).

In einer Programmiersprache, in der man nicht auch prozedural programmieren kann, könnte man schon gar nicht objektorientiert programmieren. Umgekehrt lässt sich mit einer 'prozeduralen' Programmiersprache (wie z.B. C) ohne weiteres objektorientiert programmieren (wenn es notwendig erscheint) - die Handhabung der Objekte ist nur geringfügig anders. Um als Beispiel die WINAPI zu bemühen (ein C-Interface):
Man erzeugt dort z.B. mit HWND hwnd = CreateWindow() ein Fenster, und bekommt eine ID für sein Fenster zurückgeliefert, mit dem sich dann alle weiteren Funktionen, die mit diesem Fenster zu tun haben, nutzen lassen - ohne dass man deshalb genau wissen müsste, welche private Elemente das Fenster hat oder wie die Fensterklasse seitens der WINAPI genau implementiert wäre - man bedient sich der Funktionalität genauso nur über die Schnittstellen, die es gibt, wie man es z.B. bei C++ Objekten tun würde. Es ist doch nur ein geringfügiger syntaktischer Unterschied, ob ich jetzt

('unechte' OOP - Variante)

ShowWindow(hwnd, SW_SHOW);

oder (vergleichbare 'echte' OOP - Variante)

hwnd.ShowWindow(SW_SHOW);

schreiben müsste. In beiden Fällen müsste ich der Funktion mitteilen, mit WELCHEM Objekt WAS getan werden soll. In beiden Fällen bleibt es dem Programmierer nicht erspart, zu überlegen, was er da eigentlich tut. Mag sein, dass man der zweiten Variante intuitiv leichter ansieht, was hier passiert, als der ersten. -> Jedenfalls ist das ziemlich subjektiv und zweifellos von Person zu Person verschieden, was jetzt verständlicher ist und was nicht.

Mehr als ein winziger Unterschied in der Notationsweise der Anweisung besteht nicht, in beiden Fällen braucht es mich nicht zu interessieren, warum die Funktion funktioniert und wie die Klasse 'intern' aussieht.

Um wieder zum Anfang zurück zu kommen:
(Bei mir war die Entwicklung umgekehrt, habe zuerst C++ gelernt, und erst danach die scheinbar nicht mehr zeitgemäße Sprache C, und bin zu dem Schluss gekommen, dass mir C viel mehr Flexiblität in die Hand gibt, und ich außerdem mehr Kontrolle darüber habe, wie sich meine Programme im Detail verhalten sollen.)
Ich finde, dass sich C eigentlich noch sehr gut zur Anwendungsentwicklung eignet, wenn man den Mehraufwand nicht scheut. Zur Umsetzung 'maßgeschneiderter' Programme scheint mir keine Sprache besser geeignet zu sein, als 'C'.

<- Der Text spiegelt nur meine persönliche Meinung wieder

mfg

[+fricky]

Metatron schrieb:

Ich finde, dass sich C eigentlich noch sehr gut zur Anwendungsentwicklung eignet, wenn man den Mehraufwand nicht scheut.

man scheut ihn, deshalb sind ja gerade Java, C#, und andere dicke dinger so beliebt. die haben riesige, fertige bibliotheken integriert, die 99% der 0815-programmierprobleme abdecken.

Metatron schrieb:

Zur Umsetzung 'maßgeschneiderter' Programme scheint mir keine Sprache besser geeignet zu sein, als 'C'.

da haste recht, obwohl die meisten anwendungen auch ohne viel liebe zum detail auskommen. im grossen und ganzen stimme ich dir aber zu.

[Tachyon]

Metatron schrieb:

[...]Anstelle von private Variablen kann ein Modul z.B. static Variablen verwenden und den Zugriff darauf nur über entsprechende Funktionen bereitstellen.[...]

Das ist aber nicht das Gleiche. Das entspricht eher private static Variablen, und nicht private Variablen.

Metatron schrieb:

[...]Mit Callback Funktionen lässt sich alles (und noch mehr) machen, was man mit virtuellen Funktionen auch tun kann. Callback Funktionen erlauben sogar einen noch höheren Abstraktionsgrad als virtuelle Funktionen (die Callback wird eine x-beliebige Funktion, die z.B. einen void*-Wert entgegennimmt und einen float-Wert zurückliefert, aufrufen, wenn das z.B. ihr Parameter sein sollte. Das erlaubt dem Programmierer eine schier unbegrenzte Flexibilität bezüglich der konkreten Implementierung des Paramters der Callback-Funktion, wie man sie mit virtual Methoden gar nicht hätte).[...]

Der Sinn vin Interfaces ist aber nicht, dem Programmierer ein eierlegendeswollmich-Callback an die Hand zu geben. Auch in C kannst Du nichts x-beliebiges im Callback erwarten. Der Caller gibt schließlich irgendwas sehr konkretes an die Funktion, und man muss sinnvoll darauf reagieren. Man hat nur sehr viel mehr Möglichkeiten, Schrott zu produizieren, weil man das, was an den void-Pointer gegeben wurde auch als Auto interpretieren kann, obwohl es eigentlich ein Flugzeug war. Ob es gut ist, Autos wie Flugzeuge zu behandeln, sei man dahin gestellt.

Metatron schrieb:

[...]In einer Programmiersprache, in der man nicht auch prozedural programmieren kann, könnte man schon gar nicht objektorientiert programmieren. Umgekehrt lässt sich mit einer 'prozeduralen' Programmiersprache (wie z.B. C) ohne weiteres objektorientiert programmieren (wenn es notwendig erscheint) - die Handhabung der Objekte ist nur geringfügig anders. Um als Beispiel die WINAPI zu bemühen (ein C-Interface).[...]

"Ohne weiteres" würde ich nicht sagen. Schau Dir mal dieses PDF an. Viele Konstrukte, die OO-Sprachen von Haus aus liefern, müssen mühevoll nachprogrammiert werden, und die Benutzung der herauskommenden Konstrukte ist extrem fehleranfällig.
Prozedural zu programmieren ist auch mit den gängigen imperativen OO-sprachen einfach möglich. In Java wird eine Klasse dann zum Package, in dem sich static-Methoden befinden...

Metatron schrieb:

[...]Man erzeugt dort z.B. mit HWND hwnd = CreateWindow() ein Fenster, und bekommt eine ID für sein Fenster zurückgeliefert, mit dem sich dann alle weiteren Funktionen, die mit diesem Fenster[...]

Ich kann aber nicht einfach von hwnd ableiten, und dann das abgeleitete Ding in allen Funktionen benutzen, die auch ein hwnd erwarten. Mit der Erweiterbarkeit ist das so eine Sache. Mal ganz davon abgesehen, ist Deine "'unechte' OOP - Variante" in vielen OO-Sprachen völlig normal. Nur Dein Horizont ist, was OO-Sprachen betrifft, sehr eingeschränkt. In Ada (95) werden Memberfunktion genau so aufgerufen. Dabei bieten sie aber alles, was OO-Sprachen eben bieten sollten.

Metatron schrieb:

[...](Bei mir war die Entwicklung umgekehrt, habe zuerst C++ gelernt, und erst danach die scheinbar nicht mehr zeitgemäße Sprache C, und bin zu dem Schluss gekommen, dass mir C viel mehr Flexiblität in die Hand gibt, und ich außerdem mehr Kontrolle darüber habe, wie sich meine Programme im Detail verhalten sollen.)[...]

Das ist verwunderlich, da Du mit C++ alles machen kannst, was Du auch mit C machen kannst. Dazu aber noch etwas mehr...

Insgesamt sieht mir das eher nach einer fundamentalistischen Versteifung auf eine bestimmte Sprache aus. Gut ist sowas nicht. Man sollte am besten die Sprache für ein Problem nehmen, die zur Lösung am besten geeignet ist.

[supertux]

Metatron schrieb:

('unechte' OOP - Variante)

ShowWindow(hwnd, SW_SHOW);

oder (vergleichbare 'echte' OOP - Variante)

hwnd.ShowWindow(SW_SHOW);

wenn du OOP dadurch definierst, ob man obj.property(val) aufruft, oder obj_property(obj, val) aufruft, dann hast du vielleicht OOP nicht ganz verstanden.

[Fred vom Jupiter]

Tachyon schrieb:

Metatron schrieb:

[...](Bei mir war die Entwicklung umgekehrt, habe zuerst C++ gelernt, und erst danach die scheinbar nicht mehr zeitgemäße Sprache C, und bin zu dem Schluss gekommen, dass mir C viel mehr Flexiblität in die Hand gibt, und ich außerdem mehr Kontrolle darüber habe, wie sich meine Programme im Detail verhalten sollen.)[...]

Das ist verwunderlich, da Du mit C++ alles machen kannst, was Du auch mit C machen kannst. Dazu aber noch etwas mehr...

Mir ging es auchso. Erst C/C++ angefangen dann nur noch C. Vor einem Jahr habe ich wieder C++ versucht, weil mir Freunde dazu geraten haben, aber aufgegeben. Mir ist klar welche Vorteile C++ hat, Klassen und Vererbung. Für mich sind das absolut keine. C++ sind zu überladen und kompliziert, das brauche ich nicht deshalb bleibe ich bei C. Ich programmiere Tools unter Linux und Mikrokontroller

[Tachyon]

Fred vom Jupiter schrieb:

[...]

Wir haben hier auch solche Leute (oft ältere Kollegen, aber nicht immer). Die haben vor 25 Jahren mit Ada 83 auf der VAX angefangen.
Diese Kollegen weigern sich krampfhaft, was anderes zu lernen. Argumente:

• Ada ist gut.
• Mit Ada kann ich alles machen
• C (Beispiel) ist mir zu kompliziert (!)
• C ist zu unsicher (okay)
• weitere fadenscheinige Argumente

Das die Kollegen C zu kompliziert finden, ist in sofern verwunderlich, als dass Ada eine sehr blumige und reichaltige (komplizierte) Syntax hat und mit SIcherheit deutlich komplizierter ist.
Im Großen und Ganzen haben die Kollegen einfach nur keine Lust, sich mit was anderem zu beschäftigen, als mit ihrer kleinen Welt.
Das es schwer ist, Entwickler zu finden die nicht erst monatelang eingearbeitet werden müssen, oder das Kunden bestimmte Anforderungen stellen, ist den Kollegen dabei egal.

PS: Ich musste mich aufgrund von Altlasten selbst in Ada einarbeiten, und finde die Sprache durchaus gut und durchdacht. Ich bin also keine Ada-Hasser. Ich finde nur die Argumente einiger Kollegen sehr fadenscheinig.

[+fricky]

Tachyon schrieb:

Fred vom Jupiter schrieb:

[...]

Wir haben hier auch solche Leute (oft ältere Kollegen, aber nicht immer). Die haben vor 25 Jahren mit Ada 83 auf der VAX angefangen.
Diese Kollegen weigern sich krampfhaft, was anderes zu lernen. Argumente:

• Ada ist gut.
• Mit Ada kann ich alles machen
• C (Beispiel) ist mir zu kompliziert (!)
• C ist zu unsicher (okay)
• weitere fadenscheinige Argumente

sicherlich gibts leute, die sich standhaft weigern, was neues zu lernen (so einer wird fred bestimmt nicht sein). aber wenn ADA und C gleichsam auf einem system verfügbar sind, braucht man handfeste gründe, C zu lernen, wenn man ADA schon kann. gibt natürlich freaks, die möglichst viele programmiersprachen lernen wollen, weil sie's einfach geil finden.

[Tachyon]

+fricky schrieb:

[...]aber wenn ADA und C gleichsam auf einem system verfügbar sind, braucht man handfeste gründe, C zu lernen, wenn man ADA schon kann. gibt natürlich freaks, die möglichst viele programmiersprachen lernen wollen, weil sie's einfach geil finden.

Der Grund liegt darin, dass die Leute, die Ada können immer weniger werden. Neue Projekte werden von diesen Leuten aber nach wie vor in Ada geschrieben. Neue Kollegen müssen dann erstmal in die Sprache eingearbeitet werden, und dann auch noch in den Code verstehen (der als Ada-Anfänger oft nur schwer zu verstehen ist (und sich manchmal auch dem Fortgeschrittenen nicht erschließt) ). Weiterhin müssen viele Dinge mühsam von Hand implementiert werden, für die es in anderen Sprachen bereits fertige und leistungsfähige Bibliotheken gibt. Das Rad wird ständig neu erfunden.
Ich habe vergessen zu erwähnen, dass die besagten Kollegen mitnichten nur auf dem i860 (wofür die VAX die Entwicklungsplattform ist) ihr Ada propagieren. Das wäre nachvollziehbar. Nein, auch auf modernen MPP muss es Ada sein.

[+fricky]

Tachyon schrieb:

Der Grund liegt darin, dass die Leute, die Ada können immer weniger werden. Neue Projekte werden von diesen Leuten aber nach wie vor in Ada geschrieben. Neue Kollegen müssen dann erstmal in die Sprache eingearbeitet werden, und dann auch noch in den Code verstehen (der als Ada-Anfänger oft nur schwer zu verstehen ist (und sich manchmal auch dem Fortgeschrittenen nicht erschließt).

du tust ja so, als wäre Ada völlig veraltet. warum gibt es immer weniger ada-programmierer? ist ada nicht das mittel der wahl, wenn programme möglichst stabil und fehlerfrei sein und trotzdem direkt auf der hardware rennen sollen? die kombination: 'extrem sicher und trotzdem für low-level anwendungen geeignet', wäre fast schon ein alleinstellungsmerkmal. d.h. Ada hat seinen festen platz im werkzeugkasten der softwareentwickler. C wär jedenfalls kein ersatz, wegen der vielen unsicheren konstrukte, die damit möglich sind.