Wie wird in C gekapselt?

*john 0

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.

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

supertux schrieb:

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

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.

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.

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.

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

Was bist du denn fürn Arsch, wo trolle ich denn rum und vor allem gegen was oder wen? 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.

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?

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 0

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 0

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.

~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

Hi

@john

lowbyte

pointercrash**

~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

@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**

Daß ich das mal sage : Kann mal jemand *bitte* den Thread schließen?
Danke!

DrGreenthumb

pointercrash() schrieb:

Daß ich das mal sage : Kann mal jemand *bitte* den Thread schließen?
Danke!

das geht mit dem kleinen X in der Fensterecke.

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:

/* --- 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)

/* --- 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:

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

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