C/C++ Forum :: Wie wird in C gekapselt?

cppfrager Mitglied 18:55:52 20.08.2010 Titel:

Hallo liebe C-Gemeinde,

ich lerne zwar C++ aber mich würde mal interessieren wie ihr denn in C eure Daten und Funktionen dazu kapselt? Macht ihr das nur über Namenpre- oder postfixe oder wie haltet ihr die vielen Funktionen auseinander, ich glaube es gibt ja nicht mal Namensräume oder?

/rant/ Mitglied 19:15:56 20.08.2010 Titel:

Richtig, es gibt keine Namensräume. Das letzte mal, als ich wirklich reines C programmiert habe, habe ich mit Präfixen arbeiten müssen; dabei habe ich allerdings eine Art OOP genutzt, bei dem die Funktionen als Zeiger in structs zur Verfügung gestellt wurden...

Tim Mitglied 20:14:41 20.08.2010 Titel:

/rant/ schrieb:

dabei habe ich allerdings eine Art OOP genutzt, bei dem die Funktionen als Zeiger in structs zur Verfügung gestellt wurden...

Das hat mit OOP eigentlich nichts zu tun. Das ist nur Resourcen verschwendet. Es ist lediglich Syntax-Zucker, denn ob man nun...

C/C++ Code:
object.method(par);

C/C++ Code:
object.method(par);

C/C++ Code:
object.method(par);

oder...

C/C++ Code:
method(object, par);

C/C++ Code:
method(object, par);

C/C++ Code:
method(object, par);

schreibt...

Unregistrierter

Wenn ich mit C Libs arbeite bspw. die GNOME-Libraries, sind diese öfters so aufgebaut:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	1 2 3 4 5 6 7 8 9 10 11 12 13 14	struct privObjekt // Darf nur intern von der Library benutzt werden. { // Attribute }; struct Objekt // Darf nur vom Kunden angewendet werden. { privObjekt priv; // Darf nur von der Library intern benutzt werden. // Attribute die der Kunde benutzen darf. int x; int y; double width; double height; };

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	struct privObjekt // Darf nur intern von der Library benutzt werden. { // Attribute }; struct Objekt // Darf nur vom Kunden angewendet werden. { privObjekt priv; // Darf nur von der Library intern benutzt werden. // Attribute die der Kunde benutzen darf. int x; int y; double width; double height; };

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14	struct privObjekt // Darf nur intern von der Library benutzt werden. { // Attribute }; struct Objekt // Darf nur vom Kunden angewendet werden. { privObjekt priv; // Darf nur von der Library intern benutzt werden. // Attribute die der Kunde benutzen darf. int x; int y; double width; double height; };

Und in der Dokumentation wird nur dieser Teil erwähnt und erklärt:

C/C++ Code:
struct Objekt { int x; int y; double width; double height; };

C/C++ Code:
struct Objekt { int x; int y; double width; double height; };

C/C++ Code:
struct Objekt { int x; int y; double width; double height; };

Die Library zeigt nicht, dass 'Objekt' eine weitere Struktur in sich hat. Sie erwähnt nur, dass man die Struktur 'privObjekt' nicht nutzen sollte.

Meintest du sowas?

Wutz Mitglied 21:02:23 20.08.2010 Titel:

Überlicherweise geschieht eine Kaspelung durch Auslagerung in einzelne C-Module, wo dann über den Speicherklassen-Spezifizierer "static" gesteuert wird, was an Daten/Funktionen nach außen sichtbar ist oder nicht. Zum Einsatz für den dynamischen Zugriff kommen dann u.a. auch Callbacks.

DrGreenthumb Mitglied 21:04:22 20.08.2010 Titel:

Tim schrieb:

/rant/ schrieb:

dabei habe ich allerdings eine Art OOP genutzt, bei dem die Funktionen als Zeiger in structs zur Verfügung gestellt wurden...

Das hat mit OOP eigentlich nichts zu tun. Das ist nur Resourcen verschwendet. Es ist lediglich Syntax-Zucker, denn ob man nun...

C/C++ Code:
object.method(par);

C/C++ Code:
object.method(par);

C/C++ Code:
object.method(par);

oder...

C/C++ Code:
method(object, par);

C/C++ Code:
method(object, par);

C/C++ Code:
method(object, par);

schreibt...

Der Sinn von Funktionszeigern in structs ist auch nicht das man object.method() schreiben kann (müsste in C eh object.method (object) sein), sondern dass man eben die Methoden aufruft, die das Objekt zur Verfügung stellt.
Das ist schon ein wichtiger Aspekt von OOP.

supertux Mitglied 00:29:10 21.08.2010 Titel:

meine Meinung nach ist das immer noch Syntax-Zucker. Ich mache immer so:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	typedef struct objA { ... } objA; objA objA_create(void); void* objA_free(objA obj); int* objA_set_xyz(objA obj, ...); int* objA_do_this(objA obj); int* objA_do_that(objA obj); ... typedef struct* objB { ... } objB; objB objB_create(void); void* objB_free(objB obj); int* objB_set_xyz(objB obj, ...); int* objB_do_this(objB obj); int* objB_do_that(objB *obj);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	typedef struct objA { ... } objA; objA objA_create(void); void* objA_free(objA obj); int* objA_set_xyz(objA obj, ...); int* objA_do_this(objA obj); int* objA_do_that(objA obj); ... typedef struct* objB { ... } objB; objB objB_create(void); void* objB_free(objB obj); int* objB_set_xyz(objB obj, ...); int* objB_do_this(objB obj); int* objB_do_that(objB *obj);

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	typedef struct objA { ... } objA; objA objA_create(void); void* objA_free(objA obj); int* objA_set_xyz(objA obj, ...); int* objA_do_this(objA obj); int* objA_do_that(objA obj); ... typedef struct* objB { ... } objB; objB objB_create(void); void* objB_free(objB obj); int* objB_set_xyz(objB obj, ...); int* objB_do_this(objB obj); int* objB_do_that(objB *obj);

da ist auch ganz klar, dass objB_do_that() nur für objB-Objekte gültig ist und vom objB angeboten wird.

DrGreenthumb Mitglied 00:38:14 21.08.2010 Titel:

supertux schrieb:

meine Meinung nach ist das immer noch Syntax-Zucker.

was? funktionszeiger in structs?

supertux Mitglied 01:35:57 21.08.2010 Titel:

genau

DrGreenthumb Mitglied 01:54:27 21.08.2010 Titel:

dann hast du auch nicht verstanden wieso da funktionszeiger drin sind. Das hat nichts mit Syntax-Zucker zu tun.

Hier mal ein Beispiel-Ausschnitt wie ich mich in C an OOP versucht habe:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58	struct sexp_type_info { const char* name; void (free) (struct* sexp); bool* (eq) (struct* sexp, struct* sexp); void* (write) (struct* sexp, void* (f) (const char, void*), void* fx); void** (string_rep) (struct* sexp, char dest, size_t max); struct** sexp* (copy) (struct* sexp); }; struct* sexp { // Basisklasse struct sexp_type_info* type_info; }; struct sexp_number_t { // Abgleitet1 struct sexp exp; int number; }; struct sexp_pair_t { // Abgleitet2 struct sexp exp; struct sexp* first; struct sexp* rest; }; void sexp_free (struct sexp* e) { // EDIT: diese funktion ist Syntax-Zucker if (e) e->type_info->free (e); } void pair_type_free (struct sexp* e) { if (e) { sexp_free (SEXP_FIRST (e)); sexp_free (SEXP_REST (e)); free (e); } } struct sexp* sexp_pair (struct sexp* first, struct sexp* rest) { static struct sexp_type_info type_info_pair = { "PAIR", pair_type_free, pair_type_eq, pair_type_write, pair_type_string_rep, pair_type_copy, }; struct sexp_pair_t* n = malloc (sizeof (n)); if (!n) return* error (err_out_of_memory); n->exp.type_info = &type_info_pair; n->first = first; n->rest = rest; return SEXP (n); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58	struct sexp_type_info { const char* name; void (free) (struct* sexp); bool* (eq) (struct* sexp, struct* sexp); void* (write) (struct* sexp, void* (f) (const char, void*), void* fx); void** (string_rep) (struct* sexp, char dest, size_t max); struct** sexp* (copy) (struct* sexp); }; struct* sexp { // Basisklasse struct sexp_type_info* type_info; }; struct sexp_number_t { // Abgleitet1 struct sexp exp; int number; }; struct sexp_pair_t { // Abgleitet2 struct sexp exp; struct sexp* first; struct sexp* rest; }; void sexp_free (struct sexp* e) { // EDIT: diese funktion ist Syntax-Zucker if (e) e->type_info->free (e); } void pair_type_free (struct sexp* e) { if (e) { sexp_free (SEXP_FIRST (e)); sexp_free (SEXP_REST (e)); free (e); } } struct sexp* sexp_pair (struct sexp* first, struct sexp* rest) { static struct sexp_type_info type_info_pair = { "PAIR", pair_type_free, pair_type_eq, pair_type_write, pair_type_string_rep, pair_type_copy, }; struct sexp_pair_t* n = malloc (sizeof (n)); if (!n) return* error (err_out_of_memory); n->exp.type_info = &type_info_pair; n->first = first; n->rest = rest; return SEXP (n); }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58	struct sexp_type_info { const char* name; void (free) (struct* sexp); bool* (eq) (struct* sexp, struct* sexp); void* (write) (struct* sexp, void* (f) (const char, void*), void* fx); void** (string_rep) (struct* sexp, char dest, size_t max); struct** sexp* (copy) (struct* sexp); }; struct* sexp { // Basisklasse struct sexp_type_info* type_info; }; struct sexp_number_t { // Abgleitet1 struct sexp exp; int number; }; struct sexp_pair_t { // Abgleitet2 struct sexp exp; struct sexp* first; struct sexp* rest; }; void sexp_free (struct sexp* e) { // EDIT: diese funktion ist Syntax-Zucker if (e) e->type_info->free (e); } void pair_type_free (struct sexp* e) { if (e) { sexp_free (SEXP_FIRST (e)); sexp_free (SEXP_REST (e)); free (e); } } struct sexp* sexp_pair (struct sexp* first, struct sexp* rest) { static struct sexp_type_info type_info_pair = { "PAIR", pair_type_free, pair_type_eq, pair_type_write, pair_type_string_rep, pair_type_copy, }; struct sexp_pair_t* n = malloc (sizeof (n)); if (!n) return* error (err_out_of_memory); n->exp.type_info = &type_info_pair; n->first = first; n->rest = rest; return SEXP (n); }

Unregistrierter

igitt rtti :die:

berniebutt Mitglied 11:29:08 21.08.2010 Titel:

C kannte nur die Kapselung von Daten (Zuständigkeitsbereiche), nicht die von Funktionen. Funktionsüberlagerungen nach Typen oder Parametern wurden erst mit C++ eingeführt zusammen mit OOP. Danke an die Entwickler von C++!

Besser gleich C++ einsetzen als selbstgestricktes IGITT in C. Selbst wenn es läuft, ist es wenig übersichtlich!

DrGreenthumb Mitglied 13:00:28 21.08.2010 Titel:

äh ja, am besten gleich C++ einsetzen und C abschaffen

aber ansonsten ist das so erstmal kein "IGITT", sondern gängige Praxis.

Unregistrierter

Zitat:

äh ja, am besten gleich C++ einsetzen und C abschaffen

player424 Mitglied 13:22:24 21.08.2010 Titel:

Oder C für das einsetzen wofür es auch geschaffen wurde. Ist doch klar, dass OOP in C schrecklich aussieht. Deswegen sollte man in C auch nicht Objektorientiert programmieren. Das scheint ihr zu vergessen.

DrGreenthumb Mitglied 13:28:47 21.08.2010 Titel:

So ein Blödsinn.

player424 Mitglied 13:30:15 21.08.2010 Titel:

Meinst du meinen Beitrag. Warum sollte der Blödsinn sein? Argumente?

DrGreenthumb Mitglied 13:34:35 21.08.2010 Titel:

Ja deinen Beitrag. Was soll denn das sein, "wofür C geschaffen wurde"? Hello-World-Programme die nicht über 1000 Zeilen groß werden?

Im übrigen sieht das auch nicht schrecklich aus.

player424 Mitglied 13:52:45 21.08.2010 Titel:

C ist für Funktionale Programmierung geschaffen worden.
Und dementsprechend sollte man es auch benutzen. Da in diesem Forum immer wieder gerne Analogien benutzt werden, werde ich dies auch mal tun: Ich beschwere mich ja auch nicht darüber, dass ich mit meinem Toaster nicht gut Kuchen backen kann.

DrGreenthumb Mitglied 13:57:43 21.08.2010 Titel:

player424 schrieb:

C ist für Funktionale Programmierung geschaffen worden.

ja nee is klar

btw: Es gibt auch Pizza und Schnitzel für den Toaster. Da sollte Kuchen doch auch gehen. Aber da passt die Analogie noch weniger.

volkard Moderator 13:59:33 21.08.2010 Titel:

Nein. Man sollte auch in C oo programmieren.
Wie zum Beispiel die ganzen f-Dinge http://home.fhtw-berlin.de/~junghans/cref/FUNCTIONS/fopen.html
Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.

player424 Mitglied 14:02:05 21.08.2010 Titel:

Ich hoffe dir ist schon klar, dass die Funktionale Programmierung eine eigene Vorgehensweise darstellt, die nur wenig mit OOP zu tun hat (auch wenn in OOP etwas der Grundgedanke der funktionalen Programmierung steckt).
Ansonsten kann ich zu deinem Beitrag nur folgendes sagen:

try
{

DrGreenthumb schrieb:

player424 schrieb:

C ist für Funktionale Programmierung geschaffen worden.

ja nee is klar

btw: Es gibt auch Pizza und Schnitzel für den Toaster. Da sollte Kuchen doch auch gehen. Aber da passt die Analogie noch weniger.

}
catch (NullArgumentException& exception)
{
}

Zeus Mitglied 14:04:13 21.08.2010 Titel:

http://de.wikipedia.org/wiki/Funktionale_Programmierung

Da du selbst c als funktional bezeichnest, ist die Verwirrung komplett.

DrGreenthumb Mitglied 14:12:08 21.08.2010 Titel:

volkard schrieb:

Nein. Man sollte auch in C oo programmieren.
Wie zum Beispiel die ganzen f-Dinge http://home.fhtw-berlin.de/~junghans/cref/FUNCTIONS/fopen.html
Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.

gerade bei FILE wünsche ich mir oft, man könnte davon ableiten um wenigstens mal einen string stream zu haben.

player424 Mitglied 14:17:04 21.08.2010 Titel:

Ich weiss nicht was du erreichen willst. Du beschwerst dich darüber, dass eine rein Funktionale Sprache kein OOP beherrscht. Niemand zwingt dich dazu C zu benutzen.

DrGreenthumb Mitglied 14:18:26 21.08.2010 Titel:

player424 schrieb:

Ich weiss nicht was du erreichen willst. Du beschwerst dich darüber, dass eine rein Funktionale Sprache kein OOP beherrscht. Niemand zwingt dich dazu C zu benutzen.

ja, du weißt vieles nicht. Lies doch wenigstens mal den Link von Zeus. Dann vielleicht noch was über OOP. Ich hab mich übrigens gar nicht beschwert.

player424 Mitglied 14:23:56 21.08.2010 Titel:

Dieser Beitrag hat dich jetzt bei mir komplett disqualifiziert. Wenn man keine Argumente hat einfach beleidigen. Nun weiss ich, dass du keine fachliche Kompetenz besitzt, und hier nur schreibst um zu flamen.

Zeus Mitglied 14:25:48 21.08.2010 Titel:

player424 schrieb:

Dieser Beitrag hat dich jetzt bei mir komplett disqualifiziert. Wenn man keine Argumente hat einfach beleidigen. Nun weiss ich, dass du keine fachliche Kompetenz besitzt, und hier nur schreibst um zu flamen.

Falls du mit dem Thread zuvor meintest, dass C eine rein funktionale Programmiersprache ist, dann bist du schon längst disqualifiziert.

player424 Mitglied 14:28:02 21.08.2010 Titel:

Dann halt imperativ. Jedenfalls sehe ich hier keine sinnvolle Disskussionsgrundlage mehr.

DrGreenthumb Mitglied 14:33:37 21.08.2010 Titel:

player424 schrieb:

Dann halt imperativ. Jedenfalls sehe ich hier keine sinnvolle Disskussionsgrundlage mehr.

Die hast du von Anfang an nicht geboten: Es geht um OOP in C, du schreibst das soll man nicht machen. Dein Argument dafür: C sei eine Funktionale (mittlerweile "imperative") Programmiersprache.

Das sollte auch keine Beleidigung sein. Ich weiß auch vieles nicht. Aber in diesem Thread hast du mit deinem Unwissen etwas genervt

Zeus Mitglied 14:33:49 21.08.2010 Titel:

player424 schrieb:

Dann halt imperativ. Jedenfalls sehe ich hier keine sinnvolle Disskussionsgrundlage mehr.

Gut und die meistens Objektorientierte Programmiersprachen sind auch imperativ, wie
C++
D
Java
Object Pascal (Delphi)
Ruby
Python
Objective C/ Objective C++
...

player424 Mitglied 14:34:47 21.08.2010 Titel:

Was willst du damit jetzt sagen?

volkard Moderator 14:36:18 21.08.2010 Titel:

player424 schrieb:

Dieser Beitrag hat dich jetzt bei mir komplett disqualifiziert...Nun weiss ich, dass du keine fachliche Kompetenz besitzt, und hier nur schreibst um zu flamen.

Ähm. Und das vom Autor von "C ist für Funktionale Programmierung geschaffen worden." :eek:

player424 Mitglied 14:39:25 21.08.2010 Titel:

Toll weil ich funktional mit imperativ verwechselt hab. Kommst du dir toll vor wenn du gleich drauf rumreiten kannst wenn andere mal einen Fehler machen?

Zeus Mitglied 14:45:53 21.08.2010 Titel:

player424 schrieb:

Was willst du damit jetzt sagen?

Ich wollte damit deine Sicht korrigieren.

Zitat:

Ich hoffe dir ist schon klar, dass die Funktionale Programmierung eine eigene Vorgehensweise darstellt, die nur wenig mit OOP zu tun hat (auch wenn in OOP etwas der Grundgedanke der funktionalen Programmierung steckt).

OOP ist meistens ein Konzept, dass in der Sprache selbst ergänzt bzw erweitert, aber nicht etwas totales gegensätzliches ist wie dein Zitat es belegt, dass du so denkst.

Zitat:

Toll weil ich funktional mit imperativ verwechselt hab. Kommst du dir toll vor wenn du gleich drauf rumreiten kannst wenn andere mal einen Fehler machen?

Wer austeilt, muss auch einstecken!

berniebutt Mitglied 18:41:07 21.08.2010 Titel:

Meine Tante Puhvogel in Schleswig-Holstein hat immer gesagt: "Jung, diene Sorgen un Otje sien Geld!"

Hattu C++? Muttu nehmen, wenn du kapseln willst! :eek:

Wer es will kriegt OOP auch mit reinem C hin. Versucht das aber mal mit einem alten BASIC-Interpreter nur mit gotos. :cool:

Oder anders gefragt: "Hat da jemand den Schuss nicht gehört?" :confused:

Unregistrierter

DrGreenthumb schrieb:

player424 schrieb:

C ist für Funktionale Programmierung geschaffen worden.

ja nee is klar

btw: Es gibt auch Pizza und Schnitzel für den Toaster. Da sollte Kuchen doch auch gehen. Aber da passt die Analogie noch weniger.

Zumindest aber kann man Kuchen im Kühlschrank backen. :o)

player424 Mitglied 19:05:15 21.08.2010 Titel:

berniebutt schrieb:

Meine Tante Puhvogel in Schleswig-Holstein hat immer gesagt: "Jung, diene Sorgen un Otje sien Geld!"

Hattu C++? Muttu nehmen, wenn du kapseln willst! :eek:

Wer es will kriegt OOP auch mit reinem C hin. Versucht das aber mal mit einem alten BASIC-Interpreter nur mit gotos. :cool:

Oder anders gefragt: "Hat da jemand den Schuss nicht gehört?" :confused:

Besser hätte man es kaum formulieren können

DrGreenthumb Mitglied 05:05:38 22.08.2010 Titel:

player424 schrieb:

berniebutt schrieb:

Meine Tante Puhvogel in Schleswig-Holstein hat immer gesagt: "Jung, diene Sorgen un Otje sien Geld!"

Hattu C++? Muttu nehmen, wenn du kapseln willst! :eek:

Wer es will kriegt OOP auch mit reinem C hin. Versucht das aber mal mit einem alten BASIC-Interpreter nur mit gotos. :cool:

Oder anders gefragt: "Hat da jemand den Schuss nicht gehört?" :confused:

Besser hätte man es kaum formulieren können

also nochmal zusammengefasst: In C kann man nicht kapseln oder OOP'en und man soll gefälligst eine andere Sprache nehmen. :live:

Unregistrierter

Wenn man gar mit Assembler OOP-Konzepte umsetzen kann, sollte das mit C auch möglich sein. So ähnlich wurde C++ damals vor etwa 20 Jahren auch entwickelt.

Man hatte C und man kannte damals schon andere OOP-Sprachen.

Erst hat man versucht mit C die OOP nachzubilden und war nicht ganz glücklich.
Dann hat man Zusatztools entwickelt, die es ermöglichten mit einem C-Compiler einfacher C++ Quelltext zu übersetzen.
Kurz danach oder etwa zur gleichen Zeit kamen auch die erste C++ Compiler ( Zortech ? ) auf den Markt.
Etwa 10 Jahre hat es dann gebraucht bis dann C++ nicht nur eine Erweiterung von C war. Ob das nun mangelnde Absprache der Normenkommitees war oder Absicht, wer weiss

Kurz vor der Jahrtausendwende begannen dann die ersten C++ Gurus von einer eigenständigen Sprache C++ zu sprechen.

MfG f.-th.

volkard Moderator 10:03:51 22.08.2010 Titel:

f.-th. schrieb:

Wenn man gar mit Assembler OOP-Konzepte umsetzen kann, sollte das mit C auch möglich sein.

Ja.

f.-th. schrieb:

So ähnlich wurde C++ damals vor etwa 20 Jahren auch entwickelt.

Vor 30 Jahren.

f.-th. schrieb:

Man hatte C und man kannte damals schon andere OOP-Sprachen.

[ironie]Oh ja, sehr viele. [/ironie]Simula und Smalltalk. Aber Struppi kannte Simula.

f.-th. schrieb:

Erst hat man versucht mit C die OOP nachzubilden und war nicht ganz glücklich.

Ein Satz, den ich so stehen lassen kann.

f.-th. schrieb:

Dann hat man Zusatztools entwickelt, die es ermöglichten mit einem C-Compiler einfacher C++ Quelltext zu übersetzen.

Naja. Nein. Er hat einen Präprozessor geschrieben, der aus C++-Code C-Code macht. Oder meinstest Du das mit deinem sprachlichen Konstrukt?

f.-th. schrieb:

Kurz danach oder etwa zur gleichen Zeit kamen auch die erste C++ Compiler ( Zortech ? ) auf den Markt.

Ja, zwei Jahre oder so.

f.-th. schrieb:

Etwa 10 Jahre hat es dann gebraucht bis dann C++ nicht nur eine Erweiterung von C war. Ob das nun mangelnde Absprache der Normenkommitees war oder Absicht, wer weiss

Kurz vor der Jahrtausendwende begannen dann die ersten C++ Gurus von einer eigenständigen Sprache C++ zu sprechen.

Nö, gar nicht. Aber schwierig zu belegen. Ich such mal.

Unregistrierter

Man sollte nicht versuchen in C OOP zu machen dafür gibt es C++. Wenn der letzte Mikrocontroller auch C++ kann hat sich das mit C eh erledigt. Ausser zur Pflege von alter Software wird C dann nicht mehr benötigt. ja selbst GPUs verstehen schon C++. Der Trend hin weg von C zu C++ ist also auch für die kleinsten Chips zu erkennen. Mal ehrlich vermissen wird es niemand, jede Sache die mit C geht geht auch in C++ wenn man es denn unbedingt braucht, nur das man hier wieder den Vorteil hat es richtig gut kapseln zu können.

Unregistrierter

Na, ohne viel nachzusehen ging das doch mit der Trefferquote im vorigen Beitrag

Weiss nicht ob ich das Tool noch hab und das Medium noch lesbar ist, das dem C-Compiler von Microsoft ( ? ) etwa 1990 zu C++ verhelfen sollte. Hab damals aber nicht viel oder gar nicht damit gespielt.

MfG f.-th.

Tim Mitglied 00:02:41 23.08.2010 Titel:

volkard schrieb:

Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.

signed.

berniebutt Mitglied 13:26:04 23.08.2010 Titel:

Es ist gerade die hervorragende Leistung der Entwickler von C++, die weitere Einsatzfähigkeit von C voll beibehalten zu haben - auch gemischt! :live:

Also nimmt man Kapseln und OOP von C++ und - wenn man will - anderes von C.

Unregistrierter

Hi

Also wen man schon OOP will, sollte man doch gleich C++ nehmen.
Klar kann man soetwas in C auch realisieren (OOP), doch man muss doch nicht gleich das Rad neu erfinden.
Mit Beiden Programmiersprachen kann man alles erreichen, das sollte ja klar sein.
Doch geht es ja hier um OOP und Kapselung. Und wen man jetz ein reines C Project etwicklen will, das dazu noch recht gross wird, und ein OOP aufbau haben soll, dann ist die Sprache C definitiv das falsche. Da es schnell unübersichtlich wird und viel zu viel Code entsteht der durch die erreichung von OOP Code in C erreicht werden will.
Meine Ansichten sind daher, wer OOP programmieren will soll auch eine Sprache lernen oder einsetzen die OOP mit sich bringt. C++ / oder was auch immer.
Ich selber bin ein C nar. und nur weil man mit C nicht OOP programmieren kann ( wer nicht einen eigenen objektorientierten Ansatz programmieren will) heisst das noch lange nicht das man C verbannen soll ! Oder hat jemand von euch schon mal einen microcontroller mit C++ angesteuert ? Ausser Symbian und ... kenne ich auch kein OS das in C++ geschriben wurde. Sondern mit C und Assembler. Von wegen C verbannen. Und zum schluss... C++ wurde auch mit C und Assembler entwickelt ... mit was sonnst!

lowbyte

pointercrash() Mitglied 17:28:07 23.08.2010 Titel:

Tim schrieb:

volkard schrieb:

Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.

signed.

Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?

In eine struct functionpointer und Datenblock (als union of structs z.B) zu packen, ist ja durchaus probat, erfüllt einen gewissen Kapselungsanspruch, aber auch andere Kennzeichen der OOP. Kann man viel drumrum stricken, ohne das Schema in seiner Konsistenz zu stören. Sieht als ASM aufgelöst nicht viel anders aus, als "echte OOPs" (hab' allerdings zuletzt Delphi vor 10 Jahren zerlegt, weiß nicht, wie's bei aktuellem Zeug ausschaut), in der Source differiert's deutlicher, meist mehr Schreibarbeit auf C- Basis.

Der Vorteil für mich besteht darin, daß ich damit Sachen bauen kann, die sich mit minimalem Aufwand portieren lassen, solange ich bei C89 bleibe, wobei ich zugeben muß, daß ich mich normalerweise nicht um die OS- Basis schere, sondern auf Lib- Basis auf Controllerhardware zugreife. Die Erfahrungen, die ich da mit C++ gesammelt habe, waren eher abschreckend, weil das Einstiege in Mixprojekte C/C++ waren. Meist hatten sich da wohl schon zwei oder drei Entwickler zuvor erschossen.

Naja, und die Abdeckung von C++- Compilern für kleine Embeddeds ist wirklich noch nicht toll.

Also, was soll dagegen sprechen, sich mit C sowas zurechtzuschnitzen und wo zieht ihr die Grenze?

berniebutt schrieb:

Es ist gerade die hervorragende Leistung der Entwickler von C++, die weitere Einsatzfähigkeit von C voll beibehalten zu haben - auch gemischt! :live:

Sowas hatte ich befürchtet :rolleyes:

Bashar Mitglied 18:04:55 23.08.2010 Titel:

Ich glaube hier erliegen einige einem Denkfehler. Wenn man in C ein Objektsystem baut, dann nähert man sich nicht unbedingt an C++ an. Der Einwurf, man solle doch gleich C++ nehmen, gilt natürlich nur, wenn das Objektsystem dem von C++ ähnelt.

pointercrash() Mitglied 18:34:30 23.08.2010 Titel:

Bashar schrieb:

Ich glaube hier erliegen einige einem Denkfehler. Wenn man in C ein Objektsystem baut, dann nähert man sich nicht unbedingt an C++ an. Der Einwurf, man solle doch gleich C++ nehmen, gilt natürlich nur, wenn das Objektsystem dem von C++ ähnelt.

Das ist schon sehr "fielosofisch" oder wie Garfield das mal sagte. Letzlich kommen ASM- instructions raus, also ein Prozessor weiß davon gar nix.

Ich halte mich nichtmal bewußt von C++ fern, sondern nur des Gedankens wegen, daß ich für kleinere MCUs nichtmal gegen viel Geld einen Compi kriege. Dafür kann ich in fast alle C- Compis mit ein paar #ifdef s meinen Kram unterbringen.

So, what should be wrong with it :confused:

Unregistrierter

Du willst nicht ernsthaft damit argumentieren das eh alles nur ASM wird. Ja wieso legen wir nicht gleich den Maschinencode im Speicher ab sind doch eh alles nur 0 und 1. *kopfschlag

In C gut zu kapseln ist wohl weit mehr ein Krampf als in C++ was ähnliches zu entwickeln. Vergiss nicht du kannst auch C mit Klassen programmieren wenn du es unbedingt brauchst, es ist nicht schön aber durchaus vom Erfinder der Sprache auch so gewollt.

In C was zu entwickeln macht halt nach einer gewissen Größe bei weiten nicht so viel Spaß wie mit C++. C++ ist nicht umsonst immer noch extrem verbreitet, gelle? Und keiner wird freiwillig ein Projekt in C hochziehen wenn auch C++ genommen werden könnte, denn das wäre ja schön blöd und ein schönes Armutszeugnis als Entwickler.

Unregistrierter

Hi

@basahr

Zitat:

Ich glaube hier erliegen einige einem Denkfehler. Wenn man in C ein Objektsystem baut, dann nähert man sich nicht unbedingt an C++ an. Der Einwurf, man solle doch gleich C++ nehmen, gilt natürlich nur, wenn das Objektsystem dem von C++ ähnelt.

Das ist natürlich klar... Doch ich glaube du wirst hier nicht einer finden, der sich seinen eigenen vollständigen OO Ansatz Programmiert.
Vieleicht ein Teil, oder dort wo es sich zumindest lohnt.

Schlussendlich wie Pointercrash schrieb : :live:

... wie Garfield das mal sagte. Letzlich kommen ASM- instructions raus, und nur das versteht ein Prozessor.

lowbyte_

Tim Mitglied 20:50:03 23.08.2010 Titel:

pointercrash() schrieb:

Tim schrieb:

volkard schrieb:

Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.

signed.

Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?

Beginnen tun sie für mich z.B. bei http://de.wikipedia.org/wiki/GLib
Das ist natürlich nicht unbedingt "privat" weil ein großes un bekanntes Projekt. Aber wenn sich nun jeder zweite C-Programmier nun seine glib bauen würde...
Anderes Beispiel sind Leute die sich zur Lebensaufgabe gemacht haben C-Programmierern mit Lisp/Scheme-Ansätzen auf den Sack zu gehen und am liebsten jedes dreckige Skalar in eine Liste packen, es könnten ja mal zwei werden und dann müsste man den Code an drei Stellen ändern...

pointercrash() schrieb:

In eine struct functionpointer und Datenblock (als union of structs z.B) zu packen, ist ja durchaus probat, erfüllt einen gewissen Kapselungsanspruch, aber auch andere Kennzeichen der OOP. Kann man viel drumrum stricken, ohne das Schema in seiner Konsistenz zu stören.

Fürs Protokoll: Den ASM-Teil gelöscht.

pointercrash() schrieb:

Der Vorteil für mich besteht darin, daß ich damit Sachen bauen kann, die sich mit minimalem Aufwand portieren lassen, solange ich bei C89 bleibe, wobei ich zugeben muß, daß ich mich normalerweise nicht um die OS- Basis schere, sondern auf Lib- Basis auf Controllerhardware zugreife. Die Erfahrungen, die ich da mit C++ gesammelt habe, waren eher abschreckend, weil das Einstiege in Mixprojekte C/C++ waren. Meist hatten sich da wohl schon zwei oder drei Entwickler zuvor erschossen.

Naja, und die Abdeckung von C++- Compilern für kleine Embeddeds ist wirklich noch nicht toll.

Das klingt für mich soweit nach C. Abstrahierung von HW-Spezifika um die "User"-Software einheitlich zu halten. Sollte gängige Praxis sein, ist es leider nicht.

DrGreenthumb Mitglied 21:00:12 23.08.2010 Titel:

Tim schrieb:

pointercrash() schrieb:

Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?

Beginnen tun sie für mich z.B. bei http://de.wikipedia.org/wiki/GLib
Das ist natürlich nicht unbedingt "privat" weil ein großes un bekanntes Projekt. Aber wenn sich nun jeder zweite C-Programmier nun seine glib bauen würde...

also glib an sich ist ok, solange es nicht zu viele leute nachprogrammieren?

Zitat:

Anderes Beispiel sind Leute die sich zur Lebensaufgabe gemacht haben C-Programmierern mit Lisp/Scheme-Ansätzen auf den Sack zu gehen

hast du wirklich jemals so ein Programm gesehen (ich jedenfalls nicht), oder sagst du das nur weil du in meinem geposteten Beispiel das böse Wort "sexp" gelesen hast?

Tim Mitglied 21:20:33 23.08.2010 Titel:

DrGreenthumb schrieb:

Tim schrieb:

pointercrash() schrieb:

Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?

Beginnen tun sie für mich z.B. bei http://de.wikipedia.org/wiki/GLib
Das ist natürlich nicht unbedingt "privat" weil ein großes un bekanntes Projekt. Aber wenn sich nun jeder zweite C-Programmier nun seine glib bauen würde...

also glib an sich ist ok, solange es nicht zu viele leute nachprogrammieren?

O.K. im Sinne von grenzwertig akzeptabel. Ich hätte mich dagegen gesträubt sowas (mit)zuentwickeln. Man könnte ja auch gleich ObjC nehmen. Aber es ist grenzwertig akzeptabel weil ein bekanntes Projekt in das ich mich mit ausreichend Resourcen aus Internet und Buch einarbeiten kann. Wenn jeder sich ein derartiges System aufbaut ist letzteres einfach nicht mehr gegeben und es bleibt, sorry, einfach nur Hirnsuppe nach Gusto übrig.

DrGreenthumb schrieb:

Tim schrieb:

Anderes Beispiel sind Leute die sich zur Lebensaufgabe gemacht haben C-Programmierern mit Lisp/Scheme-Ansätzen auf den Sack zu gehen

hast du wirklich jemals so ein Programm gesehen (ich jedenfalls nicht), oder sagst du das nur weil du in meinem geposteten Beispiel das böse Wort "sexp" gelesen hast?

Ich habe ausreichend Leute _hier_ gesehen um zu wissen, dass es sie gibt. In der beruflichen Praxis hab ich sowas nicht gesehen, aber auch hier blieb mir, Gott sei Dank, die "ich bin soviel geiler als glib"-glib erspart.

Unregistrierter

Es hat schon seinen Gründe warum keine großen Projekte mehr mit reinem C gemacht werden, es sei denn es gibt nur C für die Plattform.

berniebutt Mitglied 10:57:50 24.08.2010 Titel:

Da haben wir offensichtlich wieder so eine Purismus-Debatte C vs. C++. Muss nicht sein und bringt wenig!

"Möglichst C++ einsetzen, weil sicherer und transparenter" ist klar. Aber, für viele einfache Zwecke sind z.B. die alten C-Strings und deren Funktionen oft genauso gut oder sogar besser als std::string. Wer WinApi ohne MFC, VCL, ... einsetzt, bleibt ohnehin sehr nahe an C, wird aber für eigene Teilaufgaben C++ nehmen.

daddeldu! - ich habe fertig!

pointercrash() Mitglied 16:31:18 24.08.2010 Titel:

rogerpilco schrieb:

Du willst nicht ernsthaft damit argumentieren das eh alles nur ASM wird. Ja wieso legen wir nicht gleich den Maschinencode im Speicher ab sind doch eh alles nur 0 und 1. *kopfschlag

Schon ein wenig, aber eigentlich wollte ich darauf hinaus, daß es im Prinzip beliebig ist, von welcher Ebene man aus eine andere Form der Abstraktion zu erreichen versucht.

rogerpilco schrieb:

In C gut zu kapseln ist wohl weit mehr ein Krampf als in C++ was ähnliches zu entwickeln.

C bietet etliche Mechanismen, um Daten zu kapseln und Funktionspointer gehören zu den Basistypen. Da ist kein Krampf bei, sondern ich finde es sogar übersichtlicher.

rogerpilco schrieb:

Vergiss nicht du kannst auch C mit Klassen programmieren

Das wäre mir aber neu.

rogerpilco schrieb:

... es ist nicht schön aber durchaus vom Erfinder der Sprache auch so gewollt.

"C mit Klassen" ist eine Mißbrauchsmethode eines C++ Compilers. Das sind so die Projekte des Grauens, wenn C- Programmierer anfangen und erstmal eine abstrakte Klasse anlegen und dann so alles reinwerfen, was ihnen einfällt.

rogerpilco schrieb:

In C was zu entwickeln macht halt nach einer gewissen Größe bei weiten nicht so viel Spaß wie mit C++.

Das ist doch blanker Humbug. Es ist genauso möglich, in C++ chaotische Klassenwüsten aufzuziehen, wie in C ein paar gepflegte Libs anzulegen. Das ist kein Sprachmerkmal, sondern eine Frage der persönlichen Methodik.

rogerpilco schrieb:

Und keiner wird freiwillig ein Projekt in C hochziehen wenn auch C++ genommen werden könnte, denn das wäre ja schön blöd und ein schönes Armutszeugnis als Entwickler.

Ach ja? Selbst, wenn Du mehrere C++- Compiler findest, die Portierungsfalle STL verdirbt den Spaß. C++ ohne STL, da fehlt dann schon recht viel und was überbleibt, brauch' ich nicht unbedingt.

Tim schrieb:

Beginnen tun sie für mich z.B. bei http://de.wikipedia.org/wiki/GLib
Das ist natürlich nicht unbedingt "privat" weil ein großes un bekanntes Projekt. Aber wenn sich nun jeder zweite C-Programmier nun seine glib bauen würde...

Ja, der Umgang mit den GObjects sieht schon recht merkwürdig, zumindest unhandlich aus. Insofern wundere ich mich eher, daß es nicht mehr "ich mach's toller als GLib"- Typen gibt.

Objective-C sieht da wirklich netter aus, aber das Problem ist die allgemein nicht vorhandene Compilerunterstützung.

Unregistrierter

Pass mal auf du Maulheld,

wenn irgendwas an deinem Gebrabbel dran wäre dann nenne doch mal die ach so großen neuen Projekte wo die Entwickler lieber C anstelle von C++ einsetzten?

Ich bin mal sehr gespannt auf die Liste.

Unregistrierter

pointercrash() schrieb:

Ach ja? Selbst, wenn Du mehrere C++- Compiler findest, die Portierungsfalle STL verdirbt den Spaß. C++ ohne STL, da fehlt dann schon recht viel und was überbleibt, brauch' ich nicht unbedingt.

lol. bitte bleib bei c und laber nicht blöd vor dich hin.

Unregistrierter

Hi

Ich gebe pointercrash() recht !
Ich beschreibs mal so... wenn ich faul bin benütze ich C++ ,wen ich Programmieren will und dabei noch was lernen kann, kann ich auf OOP verzichten.
Ich selber mag OOP nicht. Abstraktion möchtegern kapselung.. abgesehen von der übersicht. Wie pointercrash() gesagt hat auch in C kann ein Project übersichlich gestaltet werden, und sogar noch besser.

@maulheld

Zitat:

Pass mal auf du Maulheld,

wenn irgendwas an deinem Gebrabbel dran wäre dann nenne doch mal die ach so großen neuen Projekte wo die Entwickler lieber C anstelle von C++ einsetzten?
Ich bin mal sehr gespannt auf die Liste.

nanah ..

Zum bsp. Linux - Unix - Windows. Das sind riesige Projekte, zwar nicht zu 100% in C geschrieben, do sicher zu 80%.

Wenn du schon dein Maul aufreisst, dann bitte mit deinem Nick.

lowbyte

Unregistrierter

lowbyte_ schrieb:

Ich gebe pointercrash() recht !

bei allen argumenten die er in seinem letztem post geschrieben hat?

Unregistrierter

Hi

Nein das habe ich nicht geschriben !

lowbyte

Unregistrierter

Hi

Noch was, richtiger Hardcore C++ Code sieht in meinen Augen sehr unübersichtlich aus ! Da schreibe ich lieber ein bisschen mehr, und verstehe was hinter her abgeht.

lowbyte

pointercrash() Mitglied 18:48:42 24.08.2010 Titel:

~Maulheld schrieb:

wenn irgendwas an deinem Gebrabbel dran wäre dann nenne doch mal die ach so großen neuen Projekte wo die Entwickler lieber C anstelle von C++ einsetzten?

OK, momentan werden die meisten Projekte in C (Platz 1) und Java (Platz 2) umgesetzt, in der Statistik kommt allerdings die Projektgröße nicht zur Geltung.
Ungeachtet dessen spielt die LOC- Größe immer noch keine Rolle, wie die iX- Kernels zeigen. Thorvalds hat sich mehrfach begründet dagegen verwehrt, auch nur eine Zeile C++ in den Kernel zu lassen, das finde sogar ich zu kategorisch.

omfg noob schrieb:

lol. bitte bleib bei c und laber nicht blöd vor dich hin.

Ich hab einen Tasking- Compiler und einen GCC auf zwei Brettchen geworfen, die ich gerade in der Schublade hatte (eins war ein SH8, anderes weiß ich nicht mehr). Das konnte ich gerade mal parallel ein paar hundert Zeilen weit compilieren, dann war das vorbei, weil ich mir was aus der STL gepflückt hatte, was unter Extension lief und der andere Compiler nichtmal bearbeiten wollte. Das war zwar nur exemplarisch, aber ich hab's überprüft und nicht vertieft, sondern drauf gepfiffen und bin bei C geblieben - bist Du jetzt glücklich?

Unregistrierter

Hi

@pointercrash()

Zitat:

Thorvalds hat sich mehrfach begründet dagegen verwehrt, auch nur eine Zeile C++ in den Kernel zu lassen, das finde sogar ich zu kategorisch.

Warum C++ hat in einem Kernel nix verloren.

SideWinder Moderator 20:03:35 24.08.2010 Titel:

Zitat:

Warum C++ hat in einem Kernel nix verloren.

Warum nicht? Wenn man RTTI, Exceptions, etc. mal außen vorlässt?

MfG SideWinder

pointercrash() Mitglied 20:07:32 24.08.2010 Titel:

lowbyte_ schrieb:

Warum C++ hat in einem Kernel nix verloren.

Naja, aber seine Begründungen dagegen sind z.T. schon etwas hanebüchen.
Ich bin ein gebranntes Kind in Sachen Compilerbugs und erfahrungsgemäß macht man sich um so abhängiger von dem, was ein Compiler macht, je höher dessen Abstraktionsgrad ist. Insofern ist mir eine C-Lib lieber, die ich selber durchforsten kann, als mich blind darauf zu verlassen, daß die Blackbox wirklich das Richtige aus meiner Source bastelt.
Wäre meine Argumentation, aber ja, richtig, C++ im Kernel eher nicht, v.A., weil ich keine Notwendigkeit dafür sehe.

Da fällt mir ein, was macht denn unsere PrettyOS- Crew gerade, ich glaube, die haben C++ genommen oder täusche ich mich da?

Unregistrierter

Hierfür wird C aktuell eingesetzt alles andere sind Hobbyprojekte oder dient dem Lernen. Keiner würde auf die Idee kommen mit C eine mittlere bis große Desktopanwendung zu programmieren.

Wenn es wirklich anders sein sollte dann ist es ja wohl kein Problem für die "Maulhelden" hier den Wikieintrag zu ändern. Also entweder daß so hinnehmen oder Wiki ändern mit stichhaltigen Argumenten.

Und los ihr Schaumschläger http://de.wikipedia.org/wiki/C_%28Programmiersprache%29#Verwendung

Tim Mitglied 21:07:00 24.08.2010 Titel:

Schaumschläger schrieb:

Hierfür wird C aktuell eingesetzt alles andere sind Hobbyprojekte oder dient dem Lernen. Keiner würde auf die Idee kommen mit C eine mittlere bis große Desktopanwendung zu programmieren.

Dein Problem ist, dass du ausser "Desktop" einfach nichts kennst.

_matze Mitglied 22:05:26 24.08.2010 Titel:

Es muss ja bei mittelgroßen bis großen Projekt nicht die Entscheidung 'nur C' oder 'nur C++' getroffen werden. Bei uns ist es so, dass der ganze UI-Kram in C++ (MFC) geschrieben ist (und leider auch noch viel LabView), die ganze Basis aber größtenteils in C. Das sind dann Dinge wie Bildverarbeitung, sonstige mathematische Funktionen, verschiedene Geräteansteuerungen usw. Bei uns müssen Daten möglichst performant in kleinen Zeitfenstern verarbeitet werden, und damals wurden Vergleichsmessungen angestellt, die ergeben haben, dass der C-Compiler unter bestimmten Umständen einfach performanteren Code ausgespuckt hat. Ob das heute immer noch so ist, weiß ich nicht. Das war vor meiner Zeit in der Firma und vermutlich so ca. 5-10 Jahre her (so lange also auch wieder nicht). Da wir die SW bald umstrukturieren werden (u.a. wird LabView endlich rausfliegen

), werden solche Tests vermutlich wieder stattfinden. Aber egal, worauf ich hinaus will, ist dass es durchaus auch in Desktopanwendungen eine Daseinsberechtigung für C geben kann, da logischerweise keine Desktopanwendung nur aus UI-Code besteht (Hello World mal ausgenommen). Von unseren 500.000 LOC (+ mehrere tausend VIs) ist ein beträchtlicher Teil in C geschrieben. Damit hätten wir also schon mal eine mittelgroße Desktop-Anwendung mit großem C-Anteil. These widerlegt!

Und auch in C kann man übersichtlich programmieren und kapseln, wie schon erwähnt wurde.

Auf den Wiki-Eintrag zu verweisen, in dem ja höchstens vage eine Tendenz dargelegt wird, ohne irgendwelche konkreten Zahlen o.ä., und dann ganz selbstverständlich zu behaupten, dass natürlich "keiner auf die Idee kommen würde", finde ich jedenfalls arm.

Unregistrierter

hi
sehr gut ausgedrück. das ergänzt meine ansichten.
wie matze gesagt hat..wer sich immer auf wiki verlässt..dem kann ich nicht helfen. und für ein argument (juhu ich habe bei wiki etwas fefunden das deine posts widerlegt) finde ich arm.

lowbyte

Unregistrierter

Sagt mal könnt ihr nicht lesen :confused:

Es darum wenn man eine NEUE Anwendung mittleren bis größerem Umfangs entwickeln will was nichts mit Systemprogrammierung oder embedded zu tun dann würde Niemand auf die Idee kommen heute noch dafür C einzusetzen und diese These unterstützt auch der Wikieintrag. Alle sehen es also so ausser die Fanboys hier, is doch mal wieder komisch. Es ging auch nie um ein paar ausgelagerte Berechnungen hier zählt der Großteil der Software. Ob das nun Desktop- oder Serversoftware ist spielt keine Rolle.

Ok, welche großen Anwendungen sind denn neu mit C realisiert worden die nicht Systemprogrammierung und nicht für embedded sind? Laut eurem Getrolle müssen das ja schon eine ganze Menge sein, ich bin gespannt auf die bekannten Namen *lach Ich wette nicht mal 10% von der C++ Software wird das sein, wenn überhaupt.

Und jetzt kommen wieder das rumgedruckse ich lach mich jetzt schon krumm.

Unregistrierter

Hi

Das sind deine Ansichten ... und weil du einfach keine Argumente mehr hast, auser deinem Wiki Eintrag (du Fanboy), musst du gleich mit Beleidigungen um dich schwingen !? Du tust mir echt leid ...

Zitat:

Alle sehen es also so ausser die Fanboys hier, is doch mal wieder komisch. Es ging auch nie um ein paar ausgelagerte Berechnungen hier zählt der Großteil der Software. Ob das nun Desktop- oder Serversoftware ist spielt keine Rolle.

Es ging hauptsächlich mal um :Wie wird in C gekapselt ?
Aber dazu müsste man schon lesen können.

(Wen du schon alles so genau nehmen willst !)

TOR(The Onion Router) ist zu bsp. ein grosse Projekt, und das ist in C geschrieben.

lowbyte

_matze Mitglied 08:26:47 25.08.2010 Titel:

_-)_-)_-) schrieb:

Sagt mal könnt ihr nicht lesen :confused:

Wir schon.

Zitat:

Es darum wenn man eine NEUE Anwendung mittleren bis größerem Umfangs entwickeln will

Definiere 'neu'. Darf die Entwicklung vor maximal 2 Jahren begonnen haben? Oder 5? 10? Wenn jetzt irgendein Programm in einer neuen Version 10 rauskommt, ist das dann neu oder zählt die erste Version von '89?

Zitat:

Es ging auch nie um ein paar ausgelagerte Berechnungen hier zählt der Großteil der Software.

In meinem Beispiel (darauf beziehst du dich ja) geht es nicht um ein paar ausgelagerte Berechnungen, sondern locker 50% der ganzen SW. Reicht das oder postest du gleich, dass mindestens 60% Anteil erforderlich ist, um den C-Anteil des Projekts gelten zu lassen?

Zitat:

Ok, welche großen Anwendungen sind denn neu mit C realisiert worden die nicht Systemprogrammierung und nicht für embedded sind?

Sicher nicht so viele. Da wird C++ deutlich vor C kommen. Bei reinen Klickibunti-Desktop-Anwendungen kann man auch sehr gut gegen C++ argumentieren. Da gibt es mittlerweile gute Alternativen wie C# (wenn es Windows ist und nicht portabel sein muss). Aber es ging doch hier um Kapselung, und die kann natürlich auch in den von dir ausgeklammerten Bereichen vorkommen und wichtig sein. Im Übrigen habe ich mich nur dagegen gewehrt, dass "keiner auf die Idee kommt". Hatte ich auch genauso geschrieben. Wie kann man das falsch verstehen? Kannst du nicht lesen??

Zitat:

Alle sehen es also so ausser die Fanboys hier

Ich bin kein Fanboy. Ich bin sogar ziemlich froh, wenn wir bald viel C- und vor allem LabView-Kram loswerden und C++- und C#-lastigeren Code haben. Ich wollte nur loswerden, dass sowohl Kapselung in C als auch damit (teils oder ganz) realisierte Desktopanwendungen möglich sind.

Unregistrierter

Hi

Da stimme ich ja auch zu.. dass C++ sicher in Zukunft, und schon vor ein paar Jahre für grosse Projekte bevorzugt wird, für zumindest den grössten Teil der SW.
Aber du kannst nicht abstreiten das auch grosse Projekte in C aufgezogen werden können. Ich denke einfach das sich eine App für klick-bunti-Desktopanwendung in C++ viel leichter realisieren lässt, durch abstraktheit, weniger Programmierfehler (Bufferoverflow stack,heap), manche sagen durch die übersicht durch OOP, Team(arbeit) etc.. etc.

Im gegensatz zu C++ sehe ich bei C den performanteren Machinen-Code den ein C Compiler je nach hersteller generieren kann, (wovon wir mal von einem optimalen Source-Code ausgehen) und genau das ist der nachteil der abstrahierung/kapselung genauer gesagt der OOP.
Wie pintercrash() schon mal sagte. Ich hänge mich lieber in eine Library, anstat mich darauf zu verlassen das die Blackbox das schon hinbiegen wird.

Es lässt sich auch nicht abstreiten das in manchen Bereichen einfach C Pflicht ist, und andere Programmiersprachen nichts verloren haben (wenn es den auch möglich wäre). Und dazu gehört ne Menge !

Aber ich schweife hier schon wider mächtig vom Thema ab. Deshalb ist für mich der Thread closed. Ich denke, jede Sprache hat seine vor und nachteile. Keine Sprache ist somit wegzudenken ....

lowbyte

Unregistrierter

lowbyte_ schrieb:

Hi

Da stimme ich ja auch zu.. dass C++ sicher in Zukunft, und schon vor ein paar Jahre für grosse Projekte bevorzugt wird, für zumindest den grössten Teil der SW.

richtig

lowbyte_ schrieb:

Aber du kannst nicht abstreiten das auch grosse Projekte in C aufgezogen werden können.

Können schon, macht aber keiner mehr.

lowbyte_ schrieb:

Ich denke einfach das sich eine App für klick-bunti-Desktopanwendung in C++ viel leichter realisieren lässt, durch abstraktheit, weniger Programmierfehler (Bufferoverflow stack,heap), manche sagen durch die übersicht durch OOP, Team(arbeit) etc.. etc.

korrekt

lowbyte_ schrieb:

Im gegensatz zu C++ sehe ich bei C den performanteren Machinen-Code den ein C Compiler je nach hersteller generieren kann, (wovon wir mal von einem optimalen Source-Code ausgehen) und genau das ist der nachteil der abstrahierung/kapselung genauer gesagt der OOP.

Das ist absoluter Humbug, da von OOP nach dem Kompilieren nix relevantes übrig bleibt.

lowbyte_ schrieb:

Wie pintercrash() schon mal sagte. Ich hänge mich lieber in eine Library, anstat mich darauf zu verlassen das die Blackbox das schon hinbiegen wird.

Wer heute alles selbst mach hat verloren, dazu ist die IT zu komplex geworden.

lowbyte_ schrieb:

Es lässt sich auch nicht abstreiten das in manchen Bereichen einfach C Pflicht ist, und andere Programmiersprachen nichts verloren haben (wenn es den auch möglich wäre). Und dazu gehört eine Menge !

Eher eine kleinere Teilmenge der ganzen produzierten Software und halt in den Nischen Embedded, System und paar kleine Bibliotheken.

lowbyte_ schrieb:

Aber ich schweife hier schon wider mächtig vom Thema ab. Deshalb ist für mich der Thread closed. Ich denke, jede Sprache hat seine vor und nachteile. Keine Sprache ist somit wegzudenken ....

richtig

Unregistrierter

Hi

bewertung schrieb:

lowbyte_ schrieb:

Im gegensatz zu C++ sehe ich bei C den performanteren Machinen-Code den ein C Compiler je nach hersteller generieren kann, (wovon wir mal von einem optimalen Source-Code ausgehen) und genau das ist der nachteil der abstrahierung/kapselung genauer gesagt der OOP.
Das ist absoluter Humbug, da von OOP nach dem Kompilieren nix relevantes übrig bleibt.

Ich will dir nicht zu nahe treten, doch weisst du von was du da sprichst ?
Nah gut ich nehme das mal so hin, doch das trift nicht in jeder (Situation) zu.
Ich habe meine Satz vorhin auch nicht direkt auf die OOP bezogen.

bewertung schrieb:

lowbyte_ schrieb:

Wie pintercrash() schon mal sagte. Ich hänge mich lieber in eine Library, anstat mich darauf zu verlassen das die Blackbox das schon hinbiegen wird.
Wer heute alles selbst mach hat verloren, dazu ist die IT zu komplex geworden.

Da bin ich getrennter Meinung. Die Library muss ja nicht von mir sein.
Mir passt das Wort BLACKBOX einfach nicht

lowbyte

~john Mitglied 09:54:11 26.08.2010 Titel:

pointercrash() schrieb:

Ich halte mich nichtmal bewußt von C++ fern, sondern nur des Gedankens wegen, daß ich für kleinere MCUs nichtmal gegen viel Geld einen Compi kriege.

Wundersame These: Den Comeau Compiler bekommt man zu vertretbaren Preisen auf beliebige Plattformen portiert, wenn es dafür einen C-Compiler gibt.

pointercrash() Mitglied 15:40:40 26.08.2010 Titel:

~john schrieb:

pointercrash() schrieb:

... daß ich für kleinere MCUs nichtmal gegen viel Geld einen Compi kriege.

Wundersame These: Den Comeau Compiler bekommt man zu vertretbaren Preisen auf beliebige Plattformen portiert, wenn es dafür einen C-Compiler gibt.

Aha, den kannte ich noch nicht. Hast Du schon Erfahrungen damit gemacht, ob die Ports wirklich ohne Federlesens auf verschiedenen Plattformen identisch funktionieren? Und wie sieht der erzeugte C- Code aus, kann man den noch halbwegs debuggen?
Dann wär' das durchaus eine erprobenswerte Option.

lowbyte_ schrieb:

Da bin ich getrennter Meinung. Die Library muss ja nicht von mir sein.
Mir passt das Wort BLACKBOX einfach nicht

Mir ging's um die Komplexität von Compilern und deren Drumherum. Da ist C leichter überprüfbar und profitiert davon, daß Libs (= ausgelagerte Komplexität) eigentlich immer als Source vorliegen. Natürlich schreibe ich die Libs nicht alle selbst, aber wenn mal was nicht so klappt wie gedacht, kann ich das selber debuggen.

Achja, und nochwas fällt mir ein. Der Vorteil von C++ soll ja sein, daß man sich Behandlungsroutinen, die identisch sind, mehrfach instanziiert. Toll, klappt auch gut. Unter C hatte ich per Macros die Funktionsnamen redefined und den gleichen Kram mehrfach includiert - geht auch, wenn auch deutlich umständlicher. Zur Runtime war aber das C- Compilat etwa achtmal schneller, als sein C++- Bruder. Beides mit dem gleichen GCC für den SH8 gebencht. Ob das in anderen Anwendungsfällen auch so ist, weiß ich nicht. Aber Komfort kostet Rechenzeit.

Unregistrierter

OMG

kwt

Unregistrierter

pointercrash() schrieb:

Aber Komfort kostet Rechenzeit.

Da hast du im allgemeinen Recht, dies trifft aber nicht auf das OOP von C++ zu, da dieses nicht mehr existiert sobald du kompiliert hast. Lass dir das mal von den Profis hier genauer erklären. Wenn du sowas produziert hast dann liegt das nicht an C++ sondern eher daran dass du anscheinend extrem schlecht programmiert hast.

Wenn du weiter bei der Meinung bleibst das C++ wegen OOP x mal langsamer ist als C oder nur doppelt so langsam werden sie dich hier fachlich auseinander nehmen. Bitte beschäftige dich ein wenig wie OOP in C++ umgesetzt wurde und die wirst sehen das davon unterm Strich nichts übrig bleibt also auch keine große Performance kostet, tut mir leid.

pointercrash() Mitglied 20:15:33 26.08.2010 Titel:

oppcpp schrieb:

Lass dir das mal von den Profis hier genauer erklären. Wenn du sowas produziert hast dann liegt das nicht an C++ sondern eher daran dass du anscheinend extrem schlecht programmiert hast.

Davon gehe ich auch aus, aber mir fiel nichts Besseres ein, war aus einem C++- Lehrbuch abgepinselt.

Aber eigentlich war mir gar nichts am c vs. cpp gelegen, klar kann man in cpp besser kapseln und wie man in C kapselt, ist ausreichend erörtert - viel mehr gibt's ja nicht.

~john Mitglied 20:43:34 26.08.2010 Titel:

pointercrash() schrieb:

Aha, den kannte ich noch nicht. Hast Du schon Erfahrungen damit gemacht, ob die Ports wirklich ohne Federlesens auf verschiedenen Plattformen identisch funktionieren?

Der Comeau Compiler gilt als der Compiler, der der ISO Norm am nächsten kommt bzw. diese komplett umsetzt. ISO C++ Code sollte daher auf jeder Plattform problemlos übersetzt werden. Ich selbst habe den Compiler noch nicht für Projekte genutzt, aber er gilt in der C++ Community als faktische Referenz Implementation der ISO Norm.

pointercrash() schrieb:

Und wie sieht der erzeugte C- Code aus, kann man den noch halbwegs debuggen?

Es werden "#line" Directiven genutzt, darüber hinaus ist das Name Mangling komplett verschieden. Das Debugging ist ergo nicht so einfach, wie mit einem reinem C++ Compiler mit passenden Debugger.

pointercrash() schrieb:

Dann wär' das durchaus eine erprobenswerte Option.

Zum Testen muß man sich den Compiler kaufen, da die online Tryout Variante effektiv nur dazu taugt zu testen, ob der Compiler einen bestimmten Code verarbeitet. Für die verbreiteten Plattformen kostet eine Lizenz US$50.

P.S. C99 unterstützt der Compiler ebenfalls.

~john Mitglied 21:16:21 26.08.2010 Titel:

pointercrash() schrieb:

Davon gehe ich auch aus, aber mir fiel nichts Besseres ein, war aus einem C++- Lehrbuch abgepinselt.

Bei so etwas ist es extrem wahrscheinlich, daß der Code nicht wirklich dasselbe getan hat, sondern nur das gleiche Ergebnis produziert hat.

Unregistrierter

C ist doch nur was für Fickler.

Unregistrierter

Hier mal ein Beispiel was man mit C in Verbindung mit der Speicherverwaltung alles falsch machen kann.

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	1 2 3 4 5 6 7 8 9 10 11 12	unsigned char get_line(int* fd) { int i; unsigned char line; line = (char)malloc(1); for (i=1; line[i]!=’\n’ \|\| line[i]!=’;’; i++) { read(fd, &line[i], 1); line = (char*)realloc(line, 1); } return** line; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	unsigned char get_line(int* fd) { int i; unsigned char line; line = (char)malloc(1); for (i=1; line[i]!=’\n’ \|\| line[i]!=’;’; i++) { read(fd, &line[i], 1); line = (char*)realloc(line, 1); } return** line; }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12	unsigned char get_line(int* fd) { int i; unsigned char line; line = (char)malloc(1); for (i=1; line[i]!=’\n’ \|\| line[i]!=’;’; i++) { read(fd, &line[i], 1); line = (char*)realloc(line, 1); } return** line; }

Die zugehörige Dokumentation wurde nicht gelesen.
Der zugehörige Header <stdlib.h> wurde nicht angegeben.
Die daraufhin generierten Warnungen des Compilers ». . . makes a pointer from
an int . . . « wurden durch Typ-Casting weggedrückt, weil sie nicht verstanden
wurden und daher störten.
Es wurde ein falscher Typ beim Typ-Cast angegeben.
Die daraufhin erfolgten Warnmeldungen ». . . incompatible pointer types . . . «
wurden ignoriert.
Der gezwungenermaßen vom Compiler angenommene Ausweichtyp int als
Rückgabetyp kann ungeeignet sein und zu schweren Fehlern des Programms führen.
Der Typ-Cast ändert nichts daran – der repariert hier überhaupt nichts.
Auch im Aufrufer von get_line() war keine Freigabe des Speichers durch
free vorgesehen.
In keinem Fall wird die retournierte Adresse auf Fehlschlag geprüft.
Der Rückgabewert von read wird nicht geprüft.
Der Inhalt des Speicherbereiches wird auf einen bestimmten Inhalt geprüft, bevor
dieser überhaupt mit Daten gefüllt wird.
Der Index beginnt mit [i=1] und adressiert ein nichtexistierendes zweites Byte
des Speicherplatzes schon zu Beginn.
Die Schleife läuft ewig, weil || statt && verwendet wurde.
Der Aufruf von realloc ist sinnlos, da der Speicherplatz in seiner Größe von
bereits 1 Byte nicht verändert wird.
Der Index adressiert fortlaufend nichtexistierenden Speicherplatz.
Das Byte, das read() einfüllt, wird niemals geprüft, da der Index i jeweils
zuvor erhöht wird.
Ein Anfordern von nur ein Byte Speicherplatz ist grundsätzlich grober Unfug.
Die Verwendung dieser Funktionen zum Lesen einer Zeile ist Unfug, solange die
Zeilenlänge nicht wesentlich größer als 30000 Byte sein kann.

Unregistrierter

Warum braucht ihr Kapselung um OO zu programmieren?

Unregistrierter

Hi

Ficky schrieb

Zitat:

C ist doch nur was für Fickler.

Und du hast keine Ahnung ! Also labere nicht.

lowbyte

Unregistrierter

lowbyte_ schrieb:

Und du hast keine Ahnung ! Also labere nicht.

Geh doch nicht auf das Getrolle ein :rolleyes:

Unregistrierter

In C wird über da Modulkonzept gekapselt. So sind in einzelnen Übersetzungseinheiten z.B. die static Variabeln nur dort sichtbar. Das weiß man nach ein paar Tagen C lernen und ich kann nicht verstehen wie dadurch so ein riesen Thread entstehen kann?

Unregistrierter

Hi

Das entsteht dadurch:

1. Dass wie man sehen kann, die Meinungen zu Teil stark auseinander gehen. Oder man sich manchmal nicht ganz versteht.
2. Durch Wiki Helden ...
3. Durch solche die keine Ahnung haben, und den Thread voll labern.

Ich bin auch nicht perfekt... Aber so einen Thread der (fast) jeden Aspekt der OOP anschneidet verglichen mit C, sollte man nicht vollmüllen mit so miderwertigen Kommentaren wie(unten von ficky). Weil es für ein Anfänger sicher nützlich und Intressant ist sowas zu lesen.

Zitat:

Ficky schrieb
Zitat:

C ist doch nur was für Fickler.

Nah egal ... ich hoffe der Thread wird mal so stehen gelassen. Ich denke damit ist alles gesagt.

lowbyte

~john Mitglied 18:16:36 29.08.2010 Titel:

Interessenhalber schrieb:

In C wird über da Modulkonzept gekapselt.

C kennt keine Module - sondern nur Übersetzungseinheiten.

Unregistrierter

~john schrieb:

Interessenhalber schrieb:

In C wird über da Modulkonzept gekapselt.

C kennt keine Module - sondern nur Übersetzungseinheiten.

*kopfklatsch ja her Staatsanwalt, trotzdem wird in der Fachliteratur auch von Modulkonzepten gesprochen, auch wenn es im Endeffekt nur die einzelen Übersetzungseinheiten sind. Es wird übrigens auch von Headerdateien gesprochen obwohl es nur Textdateien sind mit der Endung .h, nur mal so als Tipp.

Sorry, vielleicht bist du auch noch nicht lange dabei um das zu wissen.

supertux Mitglied 23:41:20 29.08.2010 Titel:

~john schrieb:

Interessenhalber schrieb:

In C wird über da Modulkonzept gekapselt.

C kennt keine Module - sondern nur Übersetzungseinheiten.

dennoch kann man sie als Module bezeichnen und so programmieren :rolleyes:

Zeus Mitglied 23:42:28 29.08.2010 Titel:

supertux schrieb:

~john schrieb:

Interessenhalber schrieb:

In C wird über da Modulkonzept gekapselt.

C kennt keine Module - sondern nur Übersetzungseinheiten.

dennoch kann man sie als Module bezeichnen und so programmieren :rolleyes:

Nagut für C schon, in C++ geht's nicht *gg*

supertux Mitglied 23:57:04 29.08.2010 Titel:

und wir sind in ANSI C Forum und reden über Kapselung in C :confused:

~john Mitglied 09:21:04 30.08.2010 Titel:

Interessehalber schrieb:

*kopfklatsch ja her Staatsanwalt, trotzdem wird in der Fachliteratur auch von Modulkonzepten gesprochen,

Zu C gibt es viele extrem schlechte Bücher. In Zusammenhang mit C von Module zu sprechen ist eine maßlose Übertreibung. Zu einem Modulkonzept gehört mehr als nur die Sichtbarkeit von Variablen und Funktionen auf eine Übersetzungseinheit beschränken zu können. Vergleiche dies mit den Modulkonzepten von Ada, Fortran o.ä.

P.S. Sowohl K&R wie auch die ISO Norm sprechen nie von Modulen.

Unregistrierter

Ihr erzählt ja einen Quatsch. Auch wenn C nicht gerade ein supergeniales Modulkonzept hat so wird trotz alle dem davon gesprochen. Selbst in Wikipedia wird dies erwähnt. Wie das nun realisiert ist, ist doch wohl egal es wird jedenfalls davon gesprochen.

Wikipedia schrieb:

Eine Modularisierung in C erfolgt auf Dateiebene. Eine Datei bildet eine Übersetzungseinheit; intern benötigte Funktionen und Variablen können so vor anderen Dateien verborgen werden. Die Bekanntgabe der öffentlichen Funktionsschnittstellen erfolgt mit sogenannten Header-Dateien. Damit verfügt C über ein schwach ausgeprägtes Modulkonzept

Wenn das nicht stimmt könnt ihr den Artikel mit sicherheit leicht ändern. Ich schaue dann in 2 Wochen nochmal rein. Ist der Artikel nicht geändert hattet ihr unrecht.

Zeus Mitglied 10:20:14 30.08.2010 Titel:

supertux schrieb:

und wir sind in ANSI C Forum und reden über Kapselung in C :confused:

Trotzdem ist es seltsam, weil C und C++ das gleiche Modell bezüglich Übersetzungseinheit/Kompilieren/Linken etc haben.

In C++ gibst halt ein Modulekonzept, dass dem Standardkomitee als Vorschlag eingereicht würde. Dies hat mehr Semantik als eine Übersetzungseinheiten.

btw Wikipedia ist keine gute Referenz.

Unregistrierter

Schon klar das man das Modulkonzept bzw. das was in dem Zusammenhang genannt wird nicht mit denen anderer Sprachen vergleichen kann.

Wenn ihr alle immer die Weisheit mit Löffeln gefressen habt verstehe ich nicht warum die Artikel bei Wikipedia nicht von euch geändert werden? Wenn nicht von den Profis, von wem dann? Ihr habt doch auch schon bestimmt vom Wikipedia profitiert und könntet doch auch was zurückgeben, davon lebt das Lexikon ja.

Unregistrierter

Was ist denn an dem Zitat aus Wikipedia konkret falsch, dann werde ich die Änderung vorschlagen? Auf die Frage müsste ich ja auf jedenfall mindestens ein paar Antworten bekommen und zwar kein drumrumgerede, sondern Fakten.

Tim Mitglied 11:42:27 30.08.2010 Titel:

~john schrieb:

P.S. Sowohl K&R wie auch die ISO Norm sprechen nie von Modulen.

Die ISO-Norm erwähnt das in C-Kreisen überaus exotische Wort "Compiler" auch nur ein einziges Mal und das in einer Fußnote.

@Interessehalber: Troll dich.

Unregistrierter

Was bist du denn fürn Arsch, wo trolle ich denn rum und vor allem gegen was oder wen? :confused:

Ich will hier die Sache klarstellen, dass man im Zusammenhang mit C sehrwohl auch nach einem Modulkonzept sprechen kann und auch gesprochen wird. Ob das nun elegant gelöst ist oder nicht tut nix zur Sache.

Unregistrierter

Recht amüsant zu lesen wie ein Thread mit einer normalen Fragestellung wieder mal im Chaos endet. Ist aber mit 30% der Threads hier so. Die Leute hier müssen sich immer beweisen, was sie doch alles wissen und gelernt haben. Der eine liegt im Unrecht den Wiki bestätigt das nicht, der andere hingegen rechtfertigt sich dadurch das das auch nie in einer Fachliteratur erwähnt wird.

Mal ein Vorschlag .. wie wäre es wenn man mal auf die eigentlich Fragestellung eingeht ohne Klugscheissern zu wollen?

Unregistrierter

Ja das wäre mal toll aber so Leute wie SeppJ, Tim und noch drei deren Namen mir nicht einfällt machen es schon sehr schwer. Aber ich werde versuche die gefährlichen Halbwahrheiten so genannten "Experten" einfach mal zu ignorieren. Schwer wird es wenn Einsteiger von denen rund gemacht werden. Ich hasse nun mal Asoziale, aber auch hier werde ich meinen Gerechtigkeitssinn versuchen abzuschalten.

Die Qualität der Beiträge die dann ein User findet leiden schon sehr unter Leuten vom Kaliber SeppJ aber auch Leute wie ich sollten dann nicht die anderen verteidigen.

Was soll man sagen ist halt ein großer Kindergarten, es gibt aber auch eine Menge wirklicher Experten. Die durch ihrer Selbstsicherheit die Ruhe weg haben und einfach professionell zu Seite stehen und das auch vom Zwischenmenschlichen.

~john Mitglied 20:45:12 30.08.2010 Titel:

Interessehalber schrieb:

Wenn ihr alle immer die Weisheit mit Löffeln gefressen habt verstehe ich nicht warum die Artikel bei Wikipedia nicht von euch geändert werden? Wenn nicht von den Profis, von wem dann?

Das Problem an Wikipedia ist, daß sich dort eine Masse Personen tummtelt, die sich mit Kritik an ihrer Haltung schwer tun. Die Folge wäre ein Editwar mit dem Ergebnis, daß das Falsche immer noch dort stünde. Dafür ist mir meine Lebenszeit zu kostbar. Ich hatte das mal mit einer anderen Programmiersprache versucht den Autoren auf Fehler im Artikel hinzuweisen - keine Chance.

Wikipedia gilt in der Wissenschaftsgemeinde grundsätzlich als nicht zitierfähig, weil es sich ständig ändern kann und man zum Teil krude Verdrehungen dort findet. Manchmal taugt es nur als Linksammlung zu einem bestimmten Thema. Bücher und Zeitschriftenartikel sind da eindeutig besser, und in denen findet sich auf viel Müll.

~john Mitglied 20:53:09 30.08.2010 Titel:

Tim schrieb:

~john schrieb:

P.S. Sowohl K&R wie auch die ISO Norm sprechen nie von Modulen.

Die ISO-Norm erwähnt das in C-Kreisen überaus exotische Wort "Compiler" auch nur ein einziges Mal und das in einer Fußnote.

Der Vergleich hinkt, "translation unit" wird in der ISO Norm exzessiv genutzt.

Unregistrierter

~john schrieb:

Interessehalber schrieb:

Wenn ihr alle immer die Weisheit mit Löffeln gefressen habt verstehe ich nicht warum die Artikel bei Wikipedia nicht von euch geändert werden? Wenn nicht von den Profis, von wem dann?

Das Problem an Wikipedia ist, daß sich dort eine Masse Personen tummtelt, die sich mit Kritik an ihrer Haltung schwer tun. Die Folge wäre ein Editwar mit dem Ergebnis, daß das Falsche immer noch dort stünde. Dafür ist mir meine Lebenszeit zu kostbar. Ich hatte das mal mit einer anderen Programmiersprache versucht den Autoren auf Fehler im Artikel hinzuweisen - keine Chance.

Wikipedia gilt in der Wissenschaftsgemeinde grundsätzlich als nicht zitierfähig, weil es sich ständig ändern kann und man zum Teil krude Verdrehungen dort findet. Manchmal taugt es nur als Linksammlung zu einem bestimmten Thema. Bücher und Zeitschriftenartikel sind da eindeutig besser, und in denen findet sich auf viel Müll.

Na das nenne ich mal eine Erklärung. Danke für den Einblick, dass ist mal ein super konstruktiver Beitrag. Er ist informativ, nicht beleidigend oder diskreditierend :live:

Unregistrierter

Hi

@john

:live:

lowbyte

pointercrash() Mitglied 12:21:20 31.08.2010 Titel:

~john schrieb:

Das Problem an Wikipedia ist, daß sich dort eine Masse Personen tummtelt, die sich mit Kritik an ihrer Haltung schwer tun. Die Folge wäre ein Editwar mit dem Ergebnis, daß das Falsche immer noch dort stünde...

Korrekt. Sogar Trivias wie Grundbegriffe der Bearbeitungstechnik (in dem Fall Gleichlauf/Gegenlauf) bleiben ewig falsch stehen.
Nach dem mehrmonatigen Edit- Hickhack ist der Artikel gelöscht worden, obwohl er ansonsten nicht schlecht war.
Das nennt man Mitarbeitermotivation.

Sqwan Mitglied 13:40:25 31.08.2010 Titel:

@richtigso

Ich höre mir lieber SeppJ an als so nen Pseudo-Klugen wie dich, der nicht mal nen Namen hat.

"gefährlichen Halbwahrheiten" <-- ja, sehr gefährlich... Die gefahr solltest du nicht ignorieren. Eine Gefahr zu ignorieren macht sie nur noch gefährlicher.

richtigso schrieb:

Aber ich werde versuche die gefährlichen Halbwahrheiten so genannten "Experten" einfach mal zu ignorieren.

earli schrieb:

Sqwan schrieb:

Und nie mals vergessen auch vor der eigenen Tür zu kehren!

Man muss kein Sternekoch sein, um sagen zu können, wenn's wie Scheiße schmeckt.

Wie Recht du doch hattest!

Und noch mal neben bei: Wikipedia hilft schon sehr oft bei der Arbeit, auch inhaltlich. In der Uni darf ich dennoch nicht drauf verweisen!
Häufig finde ich bei Wiki behauptungen die sehr gut sind, die ich dann nur noch durch Fachliteratur beweisen muss!

pointercrash() Mitglied 16:21:40 31.08.2010 Titel:

Daß ich das mal sage :rolleyes:

: Kann mal jemand *bitte* den Thread schließen?
Danke!

DrGreenthumb Mitglied 21:47:06 31.08.2010 Titel:

pointercrash() schrieb:

Daß ich das mal sage :rolleyes:

: Kann mal jemand *bitte* den Thread schließen?
Danke!

das geht mit dem kleinen X in der Fensterecke.

Unregistrierter

Unregistrierter

Eine Möglichkeit, Typen (und insbesondere ihre 'interne' Implementierung) in C zu 'kapseln', ist die Verwendung von Handles.
Jemand, der dann mit so einem C-API arbeiten soll, bekäme dann z.B. derartige 'public' Header-Files:

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	1 2 3 4 5 6 7 8 9 10 11 12 13	/ --- PUBLIC_API_HEADER.h --- / typedef struct _tImage* hImage; typedef struct _tMesh* hMesh; typedef struct _tFont* hFont; typedef struct _tDataBase* hDataBase; /* usw. usf.: Wie das API diese Datentypen 'intern' implementiert, ist für den Verwender nicht sichtbar. Alles, was dem API-Verwender zur Verfügung gestellt wird, sind dann nur noch die Schnittstellen, über die er Instanzen dieser Datentypen erzeugen / zerstören kann, und was er sonst noch mit diesen Objekten anstellen kann, wenn sie denn mal existieren. Beispielsweise so: / hImage CreateImage(char FileName); void RotateImage(hImage ToRotate, float Angle); void** BlendImage(hImage Dest, hImage Src1, hImage Src2); / ... usw. usf. Das soll nur andeuten, wie so eine 'OOP' - C - API im Idealfall aussieht. /

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	/ --- PUBLIC_API_HEADER.h --- / typedef struct _tImage* hImage; typedef struct _tMesh* hMesh; typedef struct _tFont* hFont; typedef struct _tDataBase* hDataBase; /* usw. usf.: Wie das API diese Datentypen 'intern' implementiert, ist für den Verwender nicht sichtbar. Alles, was dem API-Verwender zur Verfügung gestellt wird, sind dann nur noch die Schnittstellen, über die er Instanzen dieser Datentypen erzeugen / zerstören kann, und was er sonst noch mit diesen Objekten anstellen kann, wenn sie denn mal existieren. Beispielsweise so: / hImage CreateImage(char FileName); void RotateImage(hImage ToRotate, float Angle); void** BlendImage(hImage Dest, hImage Src1, hImage Src2); / ... usw. usf. Das soll nur andeuten, wie so eine 'OOP' - C - API im Idealfall aussieht. /

C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12 13	/ --- PUBLIC_API_HEADER.h --- / typedef struct _tImage* hImage; typedef struct _tMesh* hMesh; typedef struct _tFont* hFont; typedef struct _tDataBase* hDataBase; /* usw. usf.: Wie das API diese Datentypen 'intern' implementiert, ist für den Verwender nicht sichtbar. Alles, was dem API-Verwender zur Verfügung gestellt wird, sind dann nur noch die Schnittstellen, über die er Instanzen dieser Datentypen erzeugen / zerstören kann, und was er sonst noch mit diesen Objekten anstellen kann, wenn sie denn mal existieren. Beispielsweise so: / hImage CreateImage(char FileName); void RotateImage(hImage ToRotate, float Angle); void** BlendImage(hImage Dest, hImage Src1, hImage Src2); / ... usw. usf. Das soll nur andeuten, wie so eine 'OOP' - C - API im Idealfall aussieht. /

Der Implementierer der Funktionalität dieser 'Handle-Datentypen' verwendet ebenfalls diesen 'öffentlich sichtbaren' Header, und kann sich dann eine geeignete 'interne' Implementierung eines struct _tImage einfallen lassen, mit der er dann die 'geforderten' Schnittstellen (die aus dem 'öffentlichen' Header ersichtlich sind) implementieren kann.
Also z.B. so: (Sichtweise des Implementierers)

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	/ --- TIMAGE_IMPLEMENTIERUNG.c --- / #include <PUBLIC_API_HEADER.h> /* Hier nun die Konkretisierung eine _tImage Datentyps: typedef struct _tImage{ void* KnownType; /* Was auch immer sonst noch an Private Members (die ebenfalls Opaque Handles sein koennen!) benoetigt wird, um die geforderten Schnittstellen zu implementieren / }tImage, hImage;

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	/ --- TIMAGE_IMPLEMENTIERUNG.c --- / #include <PUBLIC_API_HEADER.h> /* Hier nun die Konkretisierung eine _tImage Datentyps: typedef struct _tImage{ void* KnownType; /* Was auch immer sonst noch an Private Members (die ebenfalls Opaque Handles sein koennen!) benoetigt wird, um die geforderten Schnittstellen zu implementieren / }tImage, hImage;

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	/ --- TIMAGE_IMPLEMENTIERUNG.c --- / #include <PUBLIC_API_HEADER.h> /* Hier nun die Konkretisierung eine _tImage Datentyps: typedef struct _tImage{ void* KnownType; /* Was auch immer sonst noch an Private Members (die ebenfalls Opaque Handles sein koennen!) benoetigt wird, um die geforderten Schnittstellen zu implementieren / }tImage, hImage;

Der Verwender des API bekommt den öffentlichen Header + die (kompilierte) Implementierung des API, und braucht sich dann garantiert keine Gedanken mehr darüber zu machen, wie die Implementierung aussieht (da zu 100% 'unsichtbar').

Also in etwa so gelingt die 'Kapselung' in C. (Bei C++ - APIs sehe ich ja als Anwender immer den kompletten internen Aufbau der zur Verfügung gestellten Klassen (und wenn auch private: dabei steht), und die Versuchung ist dann größer, sich die bekannte (oder zumindest vermut-bare) (interne) Funktionsweise einer Klasse zu Nutze zu machen. Einem C-Handle hingegen sehe ich nicht im geringsten an, wie es funktioniert. Der Hersteller der API kann anstelle von Pointer-Handles natürlich auch unsigned-Handles anbieten, die Handles 'Intern' auf ihre Gültigkeit überprüfen usw.

Als Anwender finde ich C-Handles jedenfalls auch 'bequemer' zu handhaben, als derartig gespenstische Donaudampfschiff-Fahrts-Ausdrücke wie:

C/C++ Code:
device->getSceneManager()->getActiveCamera()->drop();

C/C++ Code:
device->getSceneManager()->getActiveCamera()->drop();

C/C++ Code:
device->getSceneManager()->getActiveCamera()->drop();

... mit denen man sich häufig bei der Verwendung von C++ - APIs herumschlagen muss und wo bei jeder Codezeile ein halbes Dutzend Null-Pointer Exceptions nicht ausgeschlossen werden kann.

Auch als Herangehens-Weise an größere Projekte (Top-Down-Methode) erweist es sich als sehr fruchtbar, erstmal mit 'Opaquen' Datentypen der höchsten Abstraktions-Ebene die 'Wunsch-' Funktionalität der nächst-niedrigeren Abstraktions-Ebene festzulegen.
Wenn dann z.B. der Implementierer vom obigen Beispiel {tImage} feststellt, dass er zur Erfüllung seines Jobs noch weitere 'Opaque' Datentypen einer noch niedrigeren Abstraktions-Ebene benoetigt, so schreibt er einen entsprechenden Header mit 'seinen' Wuensch-Funktionen & dazugehörigen Datentypen usw.
Schlussendlich gelingt es so allmählich, auch größere Projekte in ihre trivialen Teilaufgaben zu zerlegen. Erstens lässt sich dann der Umfang der Aufgabe besser abschätzen. Zweitens bereitet dann die konkrete Umsetzung keine gröberen Schwierigkeiten mehr (außer recht viel Tipp-Arbeit). Und drittens verliert man dabei das konkrete End-Ziel nie aus den Augen, da man ja von der Zielsetzung ausgegangen ist, um eine geeignete Modularisierung zu realisieren. (Das Gegenteil geschieht bei einigen C++ - APIs, wo 'auf Verdacht' dutzende abstrakte Basisklassen gebastelt werden, die man vielleicht einmal brauchen könnte, und die zwar rein 'imaginär' alles könnten, aber eben 'konkret' für gar nichts optimal zu gebrauchen sind ...

mfg

Unregistrierter

Also ist C doch für große Projekte teilweise besser geeignet als C++?

volkard Moderator 15:42:38 09.09.2010 Titel:

Prototyp3 schrieb:

...

Daten hinter Zeigern verstecken ein Geheimnis von C? Nicht wirklich. Siehe pimpl-Idiom.

Prototyp3 schrieb:

Als Anwender finde ich C-Handles jedenfalls auch 'bequemer' zu handhaben, als derartig gespenstische Donaudampfschiff-Fahrts-Ausdrücke wie:

C/C++ Code:
device->getSceneManager()->getActiveCamera()->drop();

C/C++ Code:
device->getSceneManager()->getActiveCamera()->drop();

C/C++ Code:
device->getSceneManager()->getActiveCamera()->drop();

In C schreibt halt Ausdrücke(Fahrt(Donaudampfschiff))

C/C++ Code:
drop(getActiveCamera(getSceneManager(device)));

C/C++ Code:
drop(getActiveCamera(getSceneManager(device)));

C/C++ Code:
drop(getActiveCamera(getSceneManager(device)));

, aber ist das nun besser? :o)

Prototyp3 schrieb:

Auch als Herangehens-Weise an größere Projekte (Top-Down-Methode) erweist es sich als sehr fruchtbar, erstmal mit 'Opaquen' Datentypen der höchsten Abstraktions-Ebene die 'Wunsch-' Funktionalität der nächst-niedrigeren Abstraktions-Ebene festzulegen.

"Für große Projekte muß man dies und jenes (völlig austauschbar) machen."
Da kann man nicht widersprechen, denn wer anders denkt, macht nur zu kleine Projekte.

Prototyp3 schrieb:

Das Gegenteil geschieht bei einigen C++ - APIs, wo

Ja, viele Nubes programmieren viel Zeug.

Unregistrierter

Hallo,

ich würde in C kapseln, indem ich einfach die funktionen nach sinn in einer "dem sinn" entsprechenden .c-datei einordne. das ergibt eine wunderschöne baumstruktur.
also im prinzip statt

Zitat:

class irgendeine_klasse
{
};

mit

Zitat:

#include irgendeinheader.h

und in irgendeinheader.h bzw. .c dann globale variablen, funktionen, strukturen. muß man halt ordentlich dokumentieren, wo man welche variable und welche funktion untergebracht hat.

ich hab übrigens mal von einer firma gehört, die auf die frage, wie sie das programm so schnell und schlank hinbekommen haben, angab, komplett auf objektorientierte programmierung verzichtet zu haben.

Nexus Mitglied 22:28:38 13.09.2010 Titel:

Prototyp3 schrieb:

Also in etwa so gelingt die 'Kapselung' in C. (Bei C++ - APIs sehe ich ja als Anwender immer den kompletten internen Aufbau der zur Verfügung gestellten Klassen (und wenn auch private: dabei steht), und die Versuchung ist dann größer, sich die bekannte (oder zumindest vermut-bare) (interne) Funktionsweise einer Klasse zu Nutze zu machen. Einem C-Handle hingegen sehe ich nicht im geringsten an, wie es funktioniert. Der Hersteller der API kann anstelle von Pointer-Handles natürlich auch unsigned-Handles anbieten, die Handles 'Intern' auf ihre Gültigkeit überprüfen usw.

Im Grunde ist das kein schlechter Ansatz. Nur ist man so gezwungen, die Handle-internen Daten dynamisch anzufordern oder zumindest eine Art von Indirektion aufzubauen. So viel zu "OOP in C++ ist langsam".

Deshalb könnte ich mir auch vorstellen, dass Jürgen453213s Aussage, der Verzicht auf OOP hätte zu schnellem Programmcode geführt, in C tatsächlich einen wahren Kern hat. Auch wenn es im Allgemeinen nicht sinnvoll ist, diesen Schluss zu ziehen. Denn nicht zuletzt kann man ja auch in C die privaten Daten direkt in Strukturen schreiben, und dem Benutzer durch ein Member-Präfix oder irgendeine Konvention klar machen, dass er auf diese Daten nicht zugreifen soll.

Aber abgesehen davon: Kapselung dient primär dazu, den normalen Programmierer von Fehlern zu bewahren ("Murphy"), nicht den Bösewicht aufzuhalten ("Machiavelli"). Insofern zähle ich die von dir erwähnte Versuchung nicht wirklich als Argument.

Unregistrierter

volkard schrieb:

Prototyp3 schrieb:

...

Daten hinter Zeigern verstecken ein Geheimnis von C? Nicht wirklich. Siehe pimpl-Idiom.

Unerfahrenen Programmierern mag das Konzept der Verwendung opaquer Datentypen bzw. Handles zur Kapselung der Implementierung eines API durchaus wie ein Geheimnis erscheinen - schon möglich, dass Du davon noch nie etwas gehört hast.
Im übrigen werden dadurch nicht nur vereinzelte Daten vor dem Anwender 'versteckt' bzw. 'geheim gehalten', sondern die gesamte Implementierung des API, also insbesondere die verwendeten Datenstrukturen, Algorithmen usw. - alles Dinge, von deren Existenz der Anwender des API aber auch schon gar nichts zu wissen braucht.
Opaque C-Handles sind quasi eine 'perfekte' Blackbox, vergleichbar einem Radio, bei dem der Anwender zwar an den Knöpfen zur Bedienung des Gerätes interessiert ist, nicht aber an den Drähten und anderen Interna des Gerätes - und mit der Besonderheit, dass man diese Blackbox auch niemals 'aufschrauben' kann, um an den Drähten herumzufummeln - um z.B. aus Teilen des gut funktionierenden Radios eine schlecht funktionierende Waschmaschine zu basteln (das sollte jetzt ein bildhafter Vergleich mit C++ Klassen sein, die 'im Prinzip' 'alles' können, wenn man sie nur oft genug ableitet und erweitert, um einen Datentyp zu erhalten, der 'halbwegs' das tut, was man möchte.

Der OOP-Ansatz mit Handles ist ein völlig anderer (und zugleich fehler-vorbeugender als das immer dicker werdende C++-Superobjekt, das zugleich ein Radio als auch eine Waschmaschine sein möchte.)

~john Mitglied 11:18:05 18.09.2010 Titel:

Prototyp3 schrieb:

Also in etwa so gelingt die 'Kapselung' in C. (Bei C++ - APIs sehe ich ja als Anwender immer den kompletten internen Aufbau der zur Verfügung gestellten Klassen

Das sieht man nur dann, wenn es einen Designfehler gibt. Das von Dir für C beschriebene Design würde man in C++ anderweitig umsetzen.

Variante eins:
Abstract Factory mit Rückgabe eines Smart Pointers auf eine Abstract Class. Die konkreten Klassen implementiert man dann unsichtbar von Nutzer. Nur deren Konstruktionsname, -nummer o.ä. muß man bekannt machen.
Variante zwei:
Bridge Pattern (auch Handle/Body oder Pimpl idiom genannt)
Hier wird eine Interface Klasse definiert und die Implementierung in einer separaten Klasse vorgenommen, die der Nutzer nicht sieht.