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

[Dravere]

+fricky schrieb:

C++ hat redundante 'features' wie referenzen (C hat schon pointer), ...

Das kann man wohl kaum als Argument bringen, da es so subjektiv ist.

+fricky schrieb:

... doppelte dyn. speicherverwerwaltung (malloc/free vs. new/delete/delete[]), ...

Ich sage immer wieder, dass ich keinen Mischmasch meine und ihr mixt die Sache immer wieder. Wieso wollt ihr die Sprachen immer mixen?

+fricky schrieb:

... usw. funktions- und operatorüberladung, die kaum nutzen bringen, aber verwirrung stiften können.

Wieder kein Argument, da es so extrem subjektiv ist.

+fricky schrieb:

ausserdem die inkompatibilitäten zu bestehendem C-code (C|sizeof('a') != C++|sizeof('a')), ...

Man will ja auch keine Kompabilität. Es ging bei dieser Frage um, entweder rein prozedural in C oder rein prozedural in C++. Nichts dazwischen und nichts untereinander.

+fricky schrieb:

... der void* in C++ ist so ziemlich verkrüppelt, ...

Das ist höchstens ein Argument, wieso man nicht C mit einem C++ Kompiler verwenden sollte. Wobei so extrem schlimm verkrüppelt finde ich es nicht. Es werden schlicht ein paar implizite Cast nicht unterstützt.
Wenn aber, wie in der zweiten Frage, die Trennung gemacht wird, also prozedural C mit C Kompiler gegenüber prozedural C++ mit C++ Kompiler, dann ist das Argument nichtig.

+fricky schrieb:

etc. deshalb macht es keinen sinn, nur das C in C++ zu benutzen.

Finde ich nicht wirklich überzeugend. Aber du hast auch ein wenig neben meiner Frage durchgeantwortet. In meiner letzten Frage ging es um diesen Vergleich:
- prozedural C mit C Kompiler
- prozedural C++ mit C++ Kompiler

Ich hoffe es ist jetzt verständlich, was ich eigentlich meinte. Ich kann gewisse Argument verstehen, wieso man kein prozedural C mit C++ Kompiler machen möchte, aber was ist das Argument gegen prozedural C++ mit C++ Kompiler? C++ hat viel mehr Möglichkeiten, auch für das prozedurale Programmieren. Wieso wird immer noch C genommen? Nur wegen ABI? Was gibt es noch, ausser subjektive Argumente?

Grüssli

[+fricky]

Dravere schrieb:

C++ hat viel mehr Möglichkeiten, auch für das prozedurale Programmieren.

und welche?

[Dravere]

+fricky schrieb:

Dravere schrieb:

C++ hat viel mehr Möglichkeiten, auch für das prozedurale Programmieren.

und welche?

Wurden ja schon genannt: Referenzen, Überladung.
Da wir uns aber jetzt in C++ befinden und nicht mehr C unter C++, dann können wir auch diese nennen:
Namensraum, Templates, Standardbibliothek (ein std::vector oder sowas dürfte auch in der prozeduralen Programmierung sehr hilfreich sein).

Und im nächsten Standard kommen da auch viele zusätzliche Möglichkeiten. In C++ wird immer objektorientiert programmiert. Aber wieso eigentlich? Und vor allem, wieso tun sich die C Programmierer sich immer mit ihrer untypisierten Sprache herumschlagen, wo eine Liste zur reinsten Qual wird. Du kannst in C++ genauso prozedural programmieren, aber die Hilfsmittel von C++ dazu nehmen. Was spricht dagegen?

Grüssli

[supertux]

Dravere schrieb:

+fricky schrieb:

Dravere schrieb:

C++ hat viel mehr Möglichkeiten, auch für das prozedurale Programmieren.

und welche?

Wurden ja schon genannt: Referenzen, Überladung.

welchen Vorteil hast du bei Referenzen, den du bei Zeigern nicht hast? Um ehrlich zu sein, ich sehe nur Nachteile.

2. Ich wüsste nicht, wo außerhalb der Objektorientierung Überladung gut wäre. Außerdem führt in meinen Augen Überladung mehr zur Verwirrung als zur Hilfestellung, die ABI wird unnötig komplizierter, was die Kompabilität auch gefährden kann, ich denke z.b. an dem Unstig von gcc-2.x auf gcc-3.x und wieder auf gcc-4.x. Alle C++ Programme mussten neu kompiliert werden, super.

_matze schrieb:

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

und ich möchte kurz anmerken, dass Vererbung auch möglich ist. GTK+ macht es.

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