Wozu braucht man typedef wirklich?
Thomas Steinbach
kann mir jemand in leicht verstaendlichen Worten
erklaeren wozu man typedef wirklich gebrauchen kann?
In reinem C ist es doch einfach "nur" eine Art alias, nicht?
Ich persoenlich finde es aber doch uebersichtlicher, wenn
ich genau weiss, welches Struktur hinter einem Datentyp
steht und nicht so ein "abstrahierter" Aliasnamen.... hmmm
Gerade wenn es mehrere verschachtelte Strukturen, bzw.
Datentypen sind.
Uebersehe ich da etwas? Gibt es irgendwelche anderen
Vorteile bei typedef, ausser der angeblich besseren Lesbarkeit?
Vor Jahren hatte mal ein Lehrer bei einer Progaufgabe
verlangt er will ein typedef sehen und kein struct. Weiss
aber nicht wieso er das wollte... Kann momentan auch
absolut keinen Vorteil sehen.
Wie schaut das bei anderen Sprachen aus, Iso-C++, ObjC, etc.?
Sind das das dort auch einfach nur Aliase?
Thomas
Rainer Weikusat
> kann mir jemand in leicht verstaendlichen Worten
> erklaeren wozu man typedef wirklich gebrauchen kann?
> In reinem C ist es doch einfach "nur" eine Art alias, nicht?
Wenn man solche aliase definieren moechte. ZB die 'exact width integer
types' (uint8_t, uint16_t etc) typedef-Namen. Ein anderes Beispiel
waeren die abstrakten Systemdatentypen in UNIX(*) zB pid_t fuer
'process ID'. Generell immer dann, wenn man eine zusaetzliche
'logische Abstraktion' zwischen Quellcode und 'C Datentypen' haben
moechte.
Markus Raab
> Vor Jahren hatte mal ein Lehrer bei einer Progaufgabe
> verlangt er will ein typedef sehen und kein struct. Weiss
> aber nicht wieso er das wollte... Kann momentan auch
> absolut keinen Vorteil sehen.
Es sind halt 2 komplett verschiedene Sachen - es gibt natï¿œrlich Situationen
wo ein typedef richtig, ein neues struct aber unnï¿œtz ist (und bei dem Test
als falsch gewertet wird).
struct definiert eine neue Struktur, bzw. einen neuen Typen.
typedef hingegen fï¿œhrt nur einen neuen Namen fï¿œr einen bestehenden Typen
ein. Wofï¿œr es benï¿œtigt wird? Fï¿œr C ist es eine gute Frage, ich wï¿œsste jetzt
auch nur das Argument "schï¿œnerer und kï¿œrzerer Name".
mfg Markus
Thomas Richter
> kann mir jemand in leicht verstaendlichen Worten
> erklaeren wozu man typedef wirklich gebrauchen kann?
> In reinem C ist es doch einfach "nur" eine Art alias, nicht?
Richtig.
> Ich persoenlich finde es aber doch uebersichtlicher, wenn
> ich genau weiss, welches Struktur hinter einem Datentyp
> steht und nicht so ein "abstrahierter" Aliasnamen.... hmmm
> Gerade wenn es mehrere verschachtelte Strukturen, bzw.
> Datentypen sind.
>
> Uebersehe ich da etwas? Gibt es irgendwelche anderen
> Vorteile bei typedef, ausser der angeblich besseren Lesbarkeit?
Portabilit�t. Beispielsweise kannst Du in irgendeinem Header je nach vorhandener Architektur Dir die
Aliase korrekt zusammendefinieren, etwa Ganzzahltypen mit geeigneter Bitbreite.
> Vor Jahren hatte mal ein Lehrer bei einer Progaufgabe
> verlangt er will ein typedef sehen und kein struct. Weiss
> aber nicht wieso er das wollte... Kann momentan auch
> absolut keinen Vorteil sehen.
Bei structs gibt es IMHO selten einen Vorteil. Wenn, dann wieder nur, um bestimmte systemabh�ngige Komponenten
hinter den typedef-Namen zu verbergen. "FILE" w�re etwa so ein Kandidat.
> Wie schaut das bei anderen Sprachen aus, Iso-C++, ObjC, etc.?
Bei C++ genauso. Objective C kenne ich nicht gut genug.
Gr��e,
Thomas
Georg Bauhaus
> Hallo,
>
> kann mir jemand in leicht verstaendlichen Worten
> erklaeren wozu man typedef wirklich gebrauchen kann?
Au�er in den genannten F�llen sind typedefs n�tzlich,
wenn man mit compiler-Besonderheiten zu tun hat, z.B.
mit eingebauten Funtionen. Ein typedef stimmt
wohl einen Typ mit dem compiler ab: Objekte des
Typs werden dann in den passenden Schaltkreisen
des compilers verarbeitet.
GNU Cs Attribute:
typedef double aType __attribute__(...);
Bei Intel ist das glaube ich �hnlich.
Alexander Bartolich
> [...]
> kann mir jemand in leicht verstaendlichen Worten
> erklaeren wozu man typedef wirklich gebrauchen kann?
> In reinem C ist es doch einfach "nur" eine Art alias, nicht?
Gegenfrage:
Kannst du in leicht verstï¿œndlichen Worten erklï¿œren, wozu man
const double PI = 3.14159265;
gebrauchen kann? Ist doch einfach einfach "nur" eine Art Alias, nicht?
--
Juergen Ilse
Alexander Bartolich <alexander...@gmx.at> wrote:
> Thomas Steinbach schrieb:
>> [...]
>> kann mir jemand in leicht verstaendlichen Worten
>> erklaeren wozu man typedef wirklich gebrauchen kann?
>> In reinem C ist es doch einfach "nur" eine Art alias, nicht?
Richtig. Man kann es nutzen, um Systemabhaengigkeiten dahinter zu verstecken
(z.B. bei Dingen wie "uint16_t", was ein Typ mit *genau* 16 Bit sein soll
und dann je nach Implementierung "short int" oder "int" oder ggfs. sogar
"char" sein koennte). Ebenso, wenn man Eigenschaften einer Struktur vor
dem Programmierer verbergen moechte (weil sie ohnehin system- oder imple-
mentierungs-abhaengig sind, z.B. "FILE", was eine systemabhaengige Srtruktur
ist, deren portable Benutzung aber nicht systemabhaengig ist ...).
> Gegenfrage:
> Kannst du in leicht verständlichen Worten erklären, wozu man
>
> const double PI = 3.14159265;
>
> gebrauchen kann? Ist doch einfach einfach "nur" eine Art Alias, nicht?
Nein, das ist eine Variable, bei der es illegal ist, ihren Wert an dieser
Stelle durch eine Anweisung zu aendern (der Compiler kann sie ggfs. auch
in einem "read-only" Speicherbereich anlegen). Ein "alias" fuer den Wert
wuerde man mit einem "#define PI 3.14159265" erhalten, aber das ist gegen-
ueber der oben stehenden "const" Deklaration etwas voellig anderes, denn
man kann bei der const-Variablen durchaus ihre Adresse bestimmen, von dem
"#define" Wert jedoch nicht.
Ueberhaupt sind die Faelle nicht vergleichbar, weil es sich einmal um Typen,
das andere mal um konkrete Daten handelt.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Georg Bauhaus
> Hallo,
>
> Alexander Bartolich <alexander...@gmx.at> wrote:
>> Thomas Steinbach schrieb:
>>> [...]
>>> kann mir jemand in leicht verstaendlichen Worten
>>> erklaeren wozu man typedef wirklich gebrauchen kann?
>>> In reinem C ist es doch einfach "nur" eine Art alias, nicht?
>> Gegenfrage:
>> Kannst du in leicht verständlichen Worten erklären, wozu man
>>
>> const double PI = 3.14159265;
>>
>> gebrauchen kann? Ist doch einfach einfach "nur" eine Art Alias, nicht?
>
> Nein, das ist eine Variable, [...]
> Ueberhaupt sind die Faelle nicht vergleichbar, weil es sich einmal um Typen,
> das andere mal um konkrete Daten handelt.
Die Fälle (const decl vs typedef) scheinen mir durchaus vergleichbar.
In beiden Fällen geht es um Programmierer, die überlegen, wann, womit,
wofür, mit welchen Wirkungen ... sie Entitäten eines C-Programms
mit einem Namen versehen, wo dazu die Möglichkeit besteht.
In beiden Fällen gibts es Namen und ihre Folgen.
Die Fälle sind sogar formal vergleichbar, insofern "Name"
sowohl für typedef als auch für ein Objekt ein einschlägiges
Wort aus dem C-Standard ist.
(Oder vielmehr "Bezeichner" nach Übersetzung ins Englische,
man soll keine κορινθε vernachlässigen.)
Alexander Bartolich
> [...]
> Nein, das ist eine Variable, bei der es illegal ist, ihren Wert an dieser
> Stelle durch eine Anweisung zu aendern (der Compiler kann sie ggfs. auch
> in einem "read-only" Speicherbereich anlegen). Ein "alias" fuer den Wert
> wuerde man mit einem "#define PI 3.14159265" erhalten, aber das ist gegen-
> ueber der oben stehenden "const" Deklaration etwas voellig anderes, denn
> man kann bei der const-Variablen durchaus ihre Adresse bestimmen, von dem
> "#define" Wert jedoch nicht.
>
> Ueberhaupt sind die Faelle nicht vergleichbar, weil es sich einmal um Typen,
> das andere mal um konkrete Daten handelt.
Oh, Mann. Was bist denn du fï¿œr einer. Also extra fï¿œr dich eine
Einfï¿œhrung in die Grundlagen "sauberer" Programmierung.
Der folgende Code enthï¿œlt Redundanz:
a1 = r1 * r1 * 3.14;
a2 = r2 * r2 * 3.14;
In beiden Zeilen ist die selbe Konstante *gemeint*, es wurden aber zwei
unabhï¿œngige Konstanten geschrieben. Ein Nachteil dieser Vorgehensweise
ist, dass es zu Inkonsistenzen kommen kann. Zum Beispiel wenn die erste
Zeile auf "3.141" verbessert wird, die zweite aber nicht.
Fï¿œhrt man eine zentrale Definition der Konstanten ein, z.B:
a1 = r1 * r1 * PI;
a2 = r2 * r2 * PI;
ergeben sich einige Vorteile:
- die zentrale Definition lï¿œsst sich mit weniger Aufwand ï¿œndern als
alle Verwendungen der Definition abzuklappern
- durch "sprechende" Name wird der Code selbsterklï¿œrend
- wenn andere Konstanten, die zufï¿œllig den selben Wert haben, einen
anderen sprechenden Name bekommen, ist die Zufï¿œlligkeit nicht mehr
(so) verwirrend
Dieses Grundprinzip sauberer Programmierung gilt nun nicht nur fï¿œr
Flieï¿œkommazahlen vom Typ "double", sondern fï¿œr alle Beziehungen im
Quellcode.
int x, y, i;
for(i = 0; i < ...; i++) {
y = f(x, i);
...
Sollt man z.B. eines Tages feststellen, dass Koordinaten wie "x"
und "y" auf einer 64-bit-Plattform auch einen 64-bit-Datentyp
verwenden sollten, dann freut man sich bestimmt, wenn der Code
separate, sprechende Bezeichner dafï¿œr hat.
coordinate_t x, y;
int i;
for(i = 0; i < ...; i++) {
y = f(x, i);
...
--
Stefan Reuther
> Ich persoenlich finde es aber doch uebersichtlicher, wenn
> ich genau weiss, welches Struktur hinter einem Datentyp
> steht und nicht so ein "abstrahierter" Aliasnamen.... hmmm
> Gerade wenn es mehrere verschachtelte Strukturen, bzw.
> Datentypen sind.
Ab einer gewissen Projektgr��e willst du das nicht mehr wissen (m�ssen).
Und vor allem: du willst es �ndern k�nnen, ohne mit cut&paste durch den
Quelltext rennen zu m�ssen und dabei zu hoffen, nichts zu �bersehen.
> Wie schaut das bei anderen Sprachen aus, Iso-C++, ObjC, etc.?
> Sind das das dort auch einfach nur Aliase?
Genauso.
Stefan
Markus Wichmann
> Hallo,
>
> Alexander Bartolich <alexander...@gmx.at> wrote:
>> Thomas Steinbach schrieb:
>>> [...]
>>> kann mir jemand in leicht verstaendlichen Worten
>>> erklaeren wozu man typedef wirklich gebrauchen kann?
>>> In reinem C ist es doch einfach "nur" eine Art alias, nicht?
>
> Richtig. Man kann es nutzen, um Systemabhaengigkeiten dahinter zu verstecken
> (z.B. bei Dingen wie "uint16_t", was ein Typ mit *genau* 16 Bit sein soll
> und dann je nach Implementierung "short int" oder "int" oder ggfs. sogar
> "char" sein koennte). Ebenso, wenn man Eigenschaften einer Struktur vor
> dem Programmierer verbergen moechte (weil sie ohnehin system- oder imple-
> mentierungs-abhaengig sind, z.B. "FILE", was eine systemabhaengige Srtruktur
> ist, deren portable Benutzung aber nicht systemabhaengig ist ...).
>
typedef ist ebenso zur Abkürzung von Datentypen gedacht. Das ist vor
Allem bei Funktionspointertypen wichtig: Die POSIX-Funktion signal kann
man so hier:
void (*signal(int signum, void (*handler)(int)))(int);
oder so hier deklarieren:
typedef void (*sighandler_t)(int);
sighandler_t signal(int, sighandler_t);
(Wenn mir jetzt jemand sagen möchte, dass POSIX nicht Teil von C ist:
Danke, weiß ich selber, es ging mir um das Sprachbeispiel.)
Natürlich kann man sich mit viel Mühe auch durch die erste Deklaration
wurschteln, aber die zweite ist einfach lesbarer.
Letztlich läuft alles auf Lesbarkeit hinaus: Ich müsste nicht C
schreiben, wenn mir das egal wäre, denn ich könnte ja einfach im Kopf
kompilieren und alles in Assembler schreiben. Gut, ist nicht portabel,
aber sei es drum. Und wo wir dabei sind: Wieso Assembler benutzen, wenn
man mit der Prozessor-Doku und einem Hex-Editor den Code auch selbst
setzen kann? :-)
>> Gegenfrage:
>> Kannst du in leicht verständlichen Worten erklären, wozu man
>>
>> const double PI = 3.14159265;
>>
>> gebrauchen kann? Ist doch einfach einfach "nur" eine Art Alias, nicht?
>
> Ueberhaupt sind die Faelle nicht vergleichbar, weil es sich einmal um Typen,
> das andere mal um konkrete Daten handelt.
>
Man kann es auch _zu_ genau nehmen. Auf der Abstraktionsebene, von der
wir hier sprechen, sind die Programmzeilen
#define PI 3.14159265
und
const double PI = 3.14159265;
noch äquivalent: Sie weisen der Zeichenkette "3.14159265" eine kürzere
Zeichenkette als Bezeichner zu. Natürlich wirkt sich das "weiter unten"
anders aus, wenn man die Zeilen so weit konkretisiert hat, dass sie
nicht mehr äquivalent sind, aber so weit sind wir ja noch gar nicht.
Ähnliches macht auch
typedef void (*sighandler_t)(int);
Dieses Statement weist einer komplizierten Zeichenkette, die in diesem
Fall sogar zusammengesetzt ist, eine einfachere zu.
> Tschuess,
> Juergen Ilse (jue...@usenet-verwaltung.de)
Tschö,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
Juergen Ilse
Markus Wichmann <null...@gmx.net> wrote:
> Man kann es auch _zu_ genau nehmen. Auf der Abstraktionsebene, von der
> wir hier sprechen, sind die Programmzeilen
>
> #define PI 3.14159265
>
> und
>
> const double PI = 3.14159265;
>
> noch äquivalent:
Das sind sie *nicht* (was ich mit meinem Beitrag zu verdeutlichen versuchte).
In der zweiten Form ist der Ausdruck &PI erlaubt, in der ersten Form eben
*nicht*. Der Grund ist, dass in der zweiten Form eben tatsaechlich eine
Speicherstelle reserviert ist, in der der Wert hinterlegt ist, waehrend die
erste Form lediglich zu einer stumpfen Textersetzung im Quelltext fuehrt.
> Sie weisen der Zeichenkette "3.14159265" eine kürzere Zeichenkette als
> Bezeichner zu.
Das tut die erste from, waehrend bei der zweiten eben Speicherplatz
reserviert wird, dort der Wert abgelegt wird, und PI in dem Fall den
an dieser Stelle im Speicher liegenden wert referenziert. Dass das
ein wirklicher Unterschied ist, erkennt man u.a. daran, dass man im
zweiten Fall die Adresse von PI bestimmen kann, im ersten jedoch nicht.
> Natürlich wirkt sich das "weiter unten" anders aus, wenn man die Zeilen
> so weit konkretisiert hat, dass sie nicht mehr äquivalent sind, aber so
> weit sind wir ja noch gar nicht.
Da man in einem Fall die Adresse von PI bestimmen kann, im anderen Fall
jedoch nicht, gibt es (egal auf welcher Eben) einen recht deutlichen
semantischen Unterschied.
Thomas Koller
> Markus Wichmann <null...@gmx.net> wrote:
>> Man kann es auch _zu_ genau nehmen. Auf der Abstraktionsebene, von der
>> wir hier sprechen, sind die Programmzeilen
>>
>> #define PI 3.14159265
>>
>> und
>>
>> const double PI = 3.14159265;
>>
>
> Das sind sie *nicht* (was ich mit meinem Beitrag zu verdeutlichen versuchte).
Du hast offensichtlich das "Auf der Abstraktionsebene, von der wir hier
sprechen" im posting oben nicht gelesen.
> In der zweiten Form ist der Ausdruck &PI erlaubt, in der ersten Form eben
> *nicht*. Der Grund ist, dass in der zweiten Form eben tatsaechlich eine
> Speicherstelle reserviert ist, in der der Wert hinterlegt ist, waehrend die
> erste Form lediglich zu einer stumpfen Textersetzung im Quelltext fuehrt.
Es ist allgemein bekannt das es im Detail solche Unterschiede gibt,
das h�ttest du jetzt nicht so umst�ndlich extra beschreiben m�ssen.
(Aber ok, wenn man von der Usenetverwaltung ist ...)
Tom
Claus Reibenstein
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>
>> Markus Wichmann <null...@gmx.net> wrote:
>>
>>> Man kann es auch _zu_ genau nehmen. Auf der Abstraktionsebene, von der
>>> wir hier sprechen, [...]
>>
>> Das sind sie *nicht* (was ich mit meinem Beitrag zu verdeutlichen versuchte).
>
> Du hast offensichtlich das "Auf der Abstraktionsebene, von der wir hier
> sprechen" im posting oben nicht gelesen.
Ich wei� nicht, was Du unter "Abstraktionsebene" verstehst. Ich wei�
auch nicht, was Markus damit meint. Vielleicht definiert Ihr beiden erst
einmal diesen Begriff.
Gru�. Claus
Thomas Koller
Keine Definition, aber f�r dich vielleicht trotzdem ganz interessant:
http://www.doku.net/artikel/dieabstrak.htm
Tom
Rainer Weikusat
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> Markus Wichmann <null...@gmx.net> wrote:
>>> Man kann es auch _zu_ genau nehmen. Auf der Abstraktionsebene, von der
>>> wir hier sprechen, sind die Programmzeilen
>>>
>>> #define PI 3.14159265
>>>
>>> und
>>>
>>> const double PI = 3.14159265;
>>>
>>> noch �quivalent:
>>
>> Das sind sie *nicht* (was ich mit meinem Beitrag zu verdeutlichen versuchte).
>
> Du hast offensichtlich das "Auf der Abstraktionsebene, von der wir hier
> sprechen" im posting oben nicht gelesen.
Das vollstaendige Zitat war
,----
| Man kann es auch _zu_ genau nehmen. Auf der Abstraktionsebene, von der
| wir hier sprechen, sind die Programmzeilen
| 3.14159265
| #define PI 3.14159265
|
| und
|
| const double PI = 3.14159265;
|
| noch �quivalent: Sie weisen der Zeichenkette "3.14159265" eine k�rzere
| Zeichenkette als Bezeichner zu.
`----
Eine solche 'Abstraktionsebene' gibt es aber gar nicht: Beide Zeilen
sind zunaechsteinmal Zeichenfolgen (eigentlich Glyphen). Bedeutung
erhalten sie lediglich dadurch, dass sie in einem bestimmten Kontext
interpretiert werden. In diesem Fall ist der Kontext die
C-Sprachdefinition. Die erste definiert ein 'objektartiges Makro' und
veranlasst den Praeprozessor, jedes im Folgenden auftretende
Praeprozessor-Token 'PI' durch das Praeprozessor-Token '3.14159265' zu
ersetzen. Die zweite definiert ein konstantes Objekt vom Typ double,
auf das ein Bezeichner 'PI' mit statischer Speicherdauer und externer
Bindung verweist, dessen Wert 3.14159265 ist. Da werden nirgends
Zeichenketten anderen Zeichenketten 'zugewiesen' und, bezugnehmend auf
die urspruengliche Fragestellung, es werden auch keine Aliases fuer
irgendetwas existierendes definiert. Das Literal 3.14159265 ist etwas
anderes als das Praeprozessor-Token 3.14159265 und beide unterscheiden
sich von dem 'Objekt PI'. Fuer einen Definition a la
typedef int maeusekot;
gilt das nicht. Im Gueltigkeitsbereich dieser Definition sind 'int'
und 'maeusekot' Synonyme und die Frage, warum man, ausser um einen Leser
zu verwirren, solche Synonyme benutzen wollen koennte, ist nicht
ganz unberechtigt. Fuer Funktionszeiger gibt es uebrigens noch ein
besseres Beispiel: C kennt auch Funktionstypen und auch solchen
koennen typedef-Namen zugeordnet werden, als zB (im dasselbe Beispiel
zu nehmen)
typedef void sighandler(int);
Der signal-Prototyp saehe dann so aus:
sighandler *signal(int, sighandler *)
wodurch im Nachhinein vom Erfinder der Sprache als unguenstig
angesehene Effekte des 'definition resembles uses'-Prinzips umgangen
werden koennen ohne 'sone und solche' Zeigerdeklarationen im Code zu
haben.
Thomas Koller
Doch nat�rlich gibt es sowas. Oder bist du zur Abstraktion nicht f�hig?
W�rde mich aber wundern.
> Beide Zeilen
> sind zunaechsteinmal Zeichenfolgen (eigentlich Glyphen). Bedeutung
> erhalten sie lediglich dadurch, dass sie in einem bestimmten Kontext
> interpretiert werden. In diesem Fall ist der Kontext die
> C-Sprachdefinition.
Nein, er hat ja extra erw�hnt dass es nicht im Kontext der
C-Sprachdefinition (was nat�rlich hier erstmal default ist, daher
ist deine Verwirrung am Anfang durchaus verst�ndlich) gemeint
ist, sondern auf einer anderen Abstraktionsebene.
Du bist mit diesen Detailanalysen deutlich eine Abstraktionsebene
tiefer als der OP. Kein Wunder dass ihr aneinander vorbei redet.
Tom
Elmar Sack
>
> struct definiert eine neue Struktur, bzw. einen neuen Typen.
>
> ein. Wofür es benötigt wird? Für C ist es eine gute Frage, ich wüsste
> jetzt auch nur das Argument "schönerer und kürzerer Name".
>
(auf die Gefahr hin, mich hier zu blamieren) ich bin heilfroh, daß es das
typedef in C gibt. Wie der Name schon sagt, kann man damit neue Typen
definieren:
typedef int istatus;
typedef int imode;
und damit ist
void func_of_types(istatus status, imode mode);
erheblich sicherer als
void func_of_ints(int status, int mode);
Als ich meinen Code nach viel Ärger auf typedefs umgestellt hatte, bekam ich
große Augen, was sonst noch alles falsch implementiert war und nur durch
Zufall fehlerfrei lief.
Inzwischen habe ich mir auch angewöhnt, Funktionen wie init_istatus(),
is_valid_istatus() usw. zu benutzen. Macht das Leben erheblich einfacher.
Gruß
Elmar
Stefan Reuther
> Markus Raab wrote:
>>typedef hingegen führt nur einen neuen Namen für einen bestehenden Typen
>>ein. Wofür es benötigt wird? Für C ist es eine gute Frage, ich wüsste
>>jetzt auch nur das Argument "schönerer und kürzerer Name".
>
> (auf die Gefahr hin, mich hier zu blamieren) ich bin heilfroh, daß es das
> typedef in C gibt. Wie der Name schon sagt, kann man damit neue Typen
> definieren:
>
> typedef int istatus;
> typedef int imode;
Das Problem in C ist, dass das eben leider keine neuen Typen werden,
sondern nur neue Namen für alte Typen.
> void func_of_types(istatus status, imode mode);
Das ist 100% identisch zu 'void func_of_types(int status, int mode);'.
Das ist natürlich kein Grund, deswegen auf typedefs zu verzichten. Die
typedefs erfüllen somit immer noch den Zweck "Dokumentation".
Man kann typedefs tatsächlich nutzen, um Typkorrektheit zu prüfen,
allerdings nur mit Trick: angenommen, man hat
typedef double length_t;
typedef double area_t;
length_t length_from_metres(double d);
length_t length_add(length_t a, length_t b);
area_t area_of_rect(length_t a, length_t b);
dann kann man z.B. durch temporäres Ersetzen der Typedefs durch
typedef struct length* length_t;
typedef struct area* area_t;
den Compiler anweisen, die beiden Typen tatsächlich als verschiedene
Typen aufzufassen. Compiliert man damit den Anwendungscode, wird der
Compiler dann alle Fälle anmeckern, wo der Nutzer Längen und Flächen
mischt oder direkt manipuliert anstatt die dazu zu verwendenden
Funktionen zu benutzen. (Die Implementation der Funktionen wird man
damit sicherlich nicht compiliert bekommen.) Ich nutze diesen Trick z.B.
in einem Audiocodec, um zu prüfen, dass ich nicht z.B. Fixpunktzahlen im
Format 1.15 mit welchen im Format 4.28 mische. Oh, und außerdem kann ich
mit den Typedefs das Ding von Fixpunkt (für den DSP) auf Floating Point
(für den PC) umstellen, ohne den eigentlichen Code anzufassen.
Natürlich könnte man die Werte gleich in Strukturen packen
typedef struct { double value; } length_t;
aber an sowas explodieren die Optimierer real existierender Compiler,
die gerne mal Hemmungen haben, "echte" Strukturen in Register zu packen.
Stefan
Markus Wichmann
> Thomas Koller schrieb:
>
>> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>>
>>> Markus Wichmann <null...@gmx.net> wrote:
>>>
>>>> Man kann es auch _zu_ genau nehmen. Auf der Abstraktionsebene, von
>>>> der wir hier sprechen, [...]
>>>
>>> Das sind sie *nicht* (was ich mit meinem Beitrag zu verdeutlichen
>>> versuchte).
>>
>> Du hast offensichtlich das "Auf der Abstraktionsebene, von der wir
>> hier sprechen" im posting oben nicht gelesen.
>
> auch nicht, was Markus damit meint. Vielleicht definiert Ihr beiden
> erst einmal diesen Begriff.
>
Abstraktion ist ein Vorgang, bei dem ein Mensch bzw. ein Wesen mit
menschenähnlicher Intelligenz Eigenschaften von einem konkreten Objekt
entfernt, die in einem konkreten Zusammenhang auf eine bestimmte Art als
störend wirken.
Daraus trivialerweise folgend: Diese Abstraktion führt weder der
Compiler noch der C-Standard für dich durch, du musst schon selber
denken.
Eine Abstraktionsebene ist die Menge aller abstrakten Objekte, denen in
einem gegebenen Kontext vergleichbare Eigenschaften entfernt wurden oder
denen vergleichbare Eigenschaften übrig geblieben sind.
Natürlich weiß ich, dass ein Makro und eine
read-only-Variablen-Definition nicht das gleiche sind. Beispielsweise
ist nach
#define PI 3.1415
die Zeichenkette "2PI" ein gültiges Literal vom Typ double, auch wenn
sie etwas anderes enthält, als der Leser zunächst denken mag.
Nämliches mit einer read-only-Variable geht nicht.
Im Übrigen reservieren beide Varianten ungefähr gleich viel
Speicherplatz. Im Falle eines dummen Compilers braucht die Variante mit
dem Makro _mehr_ Speicherplatz, weil für jedes Vorkommen des Makros ein
Literal in die .rodata-Sektion kommt. Aber das ist OT.
Nein, wovon ich sprach, war dieser simple Vorgang: Einem Objekt wird ein
Name zu gewiesen. Hier ist von diesem Objekt fast alles abstrahiert,
sogar die Tatsache, dass es sich einmal um ein C-Objekt und bei dem
anderen um einen Typen handelt. Aber nichts anderes ging es. Auch
typedef int maeusekot;
weißt lediglich dem Typ "int" den Namen "maeusekot" zu. Dass int jetzt
ein atomarer Typ ist, tut ja nichts zur Sache. Natürlich ist das relativ
sinnfrei, wenn man nicht einen speziellen Zweck damit verfolgt. So kann
man auf Platformen mit den entsprechenden Eigenschaften natürlich
typedef int int32_t;
einführen. Auf anderen Maschienen gilt vielleicht auch
typedef long long int32_t;
oder auch
typedef char uint64_t;
Und gesetzt den Fall, dass jemand C auf einem UNIX schreibt, bei dem
schon das OS die von C geforderten Puffer bereitstellt, was hindert ihn
an
typedef int FILE;
?
Und auf die gleiche Weise ist
const double E = 2.71828;
genauso wie
#define E (2.71828)
auch "nur" die Definition eines Alias für ein Literal, wenn man einmal
die Details abstrahiert. Prinzipiell besteht doch überhaupt kein Bedarf
für dieses Alias, denn schließlich kann man überall, wo E steht, auch
2.7 einsetzen. Aber mit dem E versteht man die Formel vielleicht besser.
Tschö,
Markus
--
BASIC
Shoot yourself in the foot with a water pistol. On large systems,
continue until entire lower body is waterlogged.
Jens Schmidt
> Natürlich weiß ich, dass ein Makro und eine
> read-only-Variablen-Definition nicht das gleiche sind. Beispielsweise
> ist nach
>
> #define PI 3.1415
>
> die Zeichenkette "2PI" ein gültiges Literal vom Typ double, auch wenn
> sie etwas anderes enthält, als der Leser zunächst denken mag.
Implizites token pasting ist schon lange nicht mehr im Verhalten des
Preprozessors dabei. So ungefähr seit allem nach K&R.
--
Viele Grüße,
Jens Schmidt
Juergen Ilse
Markus Wichmann <null...@gmx.net> wrote:
> Natürlich weiß ich, dass ein Makro und eine
> read-only-Variablen-Definition nicht das gleiche sind. Beispielsweise
> ist nach
>
> #define PI 3.1415
>
> die Zeichenkette "2PI" ein gültiges Literal vom Typ double, auch wenn
> sie etwas anderes enthält, als der Leser zunächst denken mag.
Mein gcc ist in diesem Punkt anderer Meinung (und ich ebenfalls) ...
> Im Übrigen reservieren beide Varianten ungefähr gleich viel
> Speicherplatz.
Falsch. Beim Makro wird nicht zwingend Speicherplatz reserviert, es kann
auch bei jeder Zuweisung im Maschinencode der Wert direkt im Maschinencode
stehen. Es sind schlicht voellig verschiedene Konstrukte, die nur im Falle
einer Zuweisung den selben Wert zuweisen. Hier von "auf der und jener Ab-
straktionsebene ist es das gleiche" herumzufaseln, zeugt meiner Ansicht
nach nur von einem falschen Verstaendnis der Sprache.
> Nein, wovon ich sprach, war dieser simple Vorgang: Einem Objekt wird ein
> Name zu gewiesen.
Im falle des Macros gibt es nicht "ein Objekt" dem ein Name zugewiesen
werden koennte (nein, wirklich nicht).
> Und auf die gleiche Weise ist
>
> const double E = 2.71828;
>
> genauso wie
>
> #define E (2.71828)
>
> auch "nur" die Definition eines Alias für ein Literal, wenn man einmal
> die Details abstrahiert.
Wenn man die Unterschiede abstrahiert, ist ein Fahrrad ein Formel1-Rennwagen.
Schoen, aber bringt uns so etwas weiter? Nein, eher nicht. Es ist schlicht
Bloedsinn, in einer ernsthaften Diskussion um die Sprache C mittels Begriffen
wie "auf Abstraktionsebene sowieso" die real existierenden Unterschiede
zwischen grundverschiedenen Dingen einfach "wegdefinieren" zu wollen.
> Prinzipiell besteht doch überhaupt kein Bedarf für dieses Alias, denn
> schließlich kann man überall, wo E steht, auch 2.7 einsetzen.
Uberraschung: Bei der #define Variante passiert auch *exakt* *das* (ja, das
legt der Standard auch so fest: der Praeprozessor fuehrt diese Ersetzung
durch, bevor der Quelltext ueberhaupt zum ersten Mal fuer die Uebersetzung
angesehen wird).
Thomas Koller
> Wenn man die Unterschiede abstrahiert, ist ein Fahrrad ein Formel1-Rennwagen.
Wenn man die Unterschiede nicht abstrahiert, ist mein rotes Fahrrad was
ganz anderes als dein blaues Fahrrad. Was sollte es uns bringen
wenn ich beides als das Gleiche (ein Fahrrad) betrachte?
Ein Fahrrad wird nicht zum Formel1-Rennwagen, aber beide
werden zu Fahrzeugen und sind dann in dem Sinn auch "das Gleiche".
Wenn ich es schaffe sowas zu abstrahieren, muss
ich nicht alles f�r Fahrrad, Rennwagen, PKW, LKW, ...
extra neu erfinden, weils ja unterschiedliche Sachen sind,
sondern kann vieles einfach �bernehmen.
Oder auch beim Beispiel PI, auch nach dem define ist auf einer
tieferen Abstraktionsebene zwischen PI und 3.14 noch immer
ein Unterschied. Wie kommst dazu zu behaupten das w�re
das Gleiche?
> Schoen, aber bringt uns so etwas weiter? Nein, eher nicht.
Doch, auf jeden Fall bringt uns das weiter. Eigentlich ist es gerade
beim Programmieren ganz wichtig dass man sich solche Abstraktionsstufen
wie mit deinem Beispiel Fahrrad und Rennwagen, schafft.
Wenn man nicht abstrahieren kann w�rden Programme sehr schnell
sehr un�bersichtlich werden.
> Es ist schlicht
> Bloedsinn, in einer ernsthaften Diskussion um die Sprache C mittels Begriffen
> wie "auf Abstraktionsebene sowieso" die real existierenden Unterschiede
> zwischen grundverschiedenen Dingen einfach "wegdefinieren" zu wollen.
Du verwechselst "wegdefinieren" mit "wegabstrahieren". Um erfolgreich
programmieren zu k�nnen braucht es nicht nur die F�higkeit die
Unterschiede erkennen zu k�nnen, sondern auch Gemeinsamkeiten.
Und das ist keineswegs Bl�dsinn, sondern in meinen Augen sogar ein
ganz zentraler Punkt. Zuerst muss man ein Problem abstrahieren um dann
wieder runter ins Detail gehen zu k�nnen, bis in die Sprach C runter
und noch weiter.
Du hast auf der erw�hnten Ebene zum Beispiel nur die Vorgabe, dass du
die Zahl pi einheitlich verwenden willst. Gehst du dann in die
Ebene mplementierung von C runter, hast du mehrere M�glichkeiten diese
Abstraktion umzusetzen. Je nachdem f�r welche davon du dich entscheidest
hat das nat�rlich unterschiedliche Rahmenbedingungen die du kennen
und ber�cksichtigen solltest, aber f�r die obere Ebene sind solche
Details eher irrelevant.
>> Prinzipiell besteht doch �berhaupt kein Bedarf f�r dieses Alias, denn
>> schlie�lich kann man �berall, wo E steht, auch 2.7 einsetzen.
>
> Uberraschung: Bei der #define Variante passiert auch *exakt* *das* (ja, das
> legt der Standard auch so fest: der Praeprozessor fuehrt diese Ersetzung
> durch, bevor der Quelltext ueberhaupt zum ersten Mal fuer die Uebersetzung
> angesehen wird).
Warum sollte man das also tun, wenn man eh immer auch 2.7 schreiben
kann?
Tom
Claus Reibenstein
> Claus Reibenstein (4spame...@online.de) schrieb:
>
>> Ich weiß nicht, was Du unter "Abstraktionsebene" verstehst. Ich weiß
>> auch nicht, was Markus damit meint. Vielleicht definiert Ihr beiden
>> erst einmal diesen Begriff.
>
> Abstraktion ist ein Vorgang, bei dem [...]
Sorry, aber das ist mir _zu_ abstrakt.
Gruß. Claus
Claus Reibenstein
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>
>> Wenn man die Unterschiede abstrahiert, ist ein Fahrrad ein Formel1-Rennwagen.
Da muss man aber schon sehr weit abstrahieren.
> Wenn man die Unterschiede nicht abstrahiert, ist mein rotes Fahrrad was
> ganz anderes als dein blaues Fahrrad. Was sollte es uns bringen
> wenn ich beides als das Gleiche (ein Fahrrad) betrachte?
Die Funktion eines Fahrrades ist von seiner Farbe unabh�ngig.
> Oder auch beim Beispiel PI
Gerade hier suche ich noch den gemeinsamen Kern zum typedef (bzw. eine
geeignete Abstraktionsebene, um in Eurer Nomenklatur zu bleiben).
Gru�. Claus
Thomas Koller
> Thomas Koller schrieb:
>> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>>> Wenn man die Unterschiede abstrahiert, ist ein Fahrrad ein Formel1-Rennwagen.
>
> Da muss man aber schon sehr weit abstrahieren.
Eigentlich nicht besonders weit. Sowas macht man in unserer Gesellschaft
alle naselang.
>> Wenn man die Unterschiede nicht abstrahiert, ist mein rotes Fahrrad was
>> ganz anderes als dein blaues Fahrrad. Was sollte es uns bringen
>> wenn ich beides als das Gleiche (ein Fahrrad) betrachte?
>
> Die Funktion eines Fahrrades ist von seiner Farbe unabh�ngig.
ja und? Der Punkt ist, dass du vom konkreten Objekt Fahrrad
abstrahieren musst. Wenn du farbenblind bist, oder dir Farben
generell egal sind, dann nimm halt meinetwegen mein Mountainbike
vs. dein Stra�enrad, da hast dann auch unterschiedliche Funktion,
trotzdem sind beides Fahrr�der. Nur halt eine Stufe detaillierter
als die Unterscheidung Fahrrad und Auto.
>> Oder auch beim Beispiel PI
>
> Gerade hier suche ich noch den gemeinsamen Kern zum typedef (bzw. eine
> geeignete Abstraktionsebene, um in Eurer Nomenklatur zu bleiben).
Ich w�nsche dir, dass du es schaffst, und du nicht auf ewig �ber
Detailprobleme und -l�sungen nicht hinauskommst.
Tom
Georg Bauhaus
> Hallo,
>
> Markus Wichmann <null...@gmx.net> wrote:
>> Natürlich weiß ich, dass ein Makro und eine
>> read-only-Variablen-Definition nicht das gleiche sind. Beispielsweise
>> ist nach
>>
>> #define PI 3.1415
>>
>> die Zeichenkette "2PI" ein gültiges Literal vom Typ double, auch wenn
>> sie etwas anderes enthält, als der Leser zunächst denken mag.
>
> Mein gcc ist in diesem Punkt anderer Meinung (und ich ebenfalls) ...
>
>> Im Übrigen reservieren beide Varianten ungefähr gleich viel
>> Speicherplatz.
>
> straktionsebene ist es das gleiche" herumzufaseln, zeugt meiner Ansicht
> nach nur von einem falschen Verstaendnis der Sprache.
Von welcher falsch verstandenen Sprache sprichst du,
wenn du eine Definition von "Abstraktionsebene" Gefasel nennst?
Die formal angebbaren C-Regeln würden mich interessieren,
auf die du Strukturvalidität und Autorität deines Urteilsspruchs
stützt.
Die Begriffe, die in elementarerer nicht-C-sondern-Mensch-Semantik
verwendet werden, um Bedeutungen von Verstehens-bezogenen Fachbegriffen
einigermaßen festzugen ("Wat is ene Abstraktionsebene?"), sind,
nehme ich nach Lesen des Weiteren an, dir etwas weniger
geläufig als Markus?
> Wenn man die Unterschiede abstrahiert, ist ein Fahrrad ein Formel1-Rennwagen.
> Schoen, aber bringt uns so etwas weiter? Nein, eher nicht.
Doch, das Beispiel von Fahrrad und Formel-1-Rennwagen
bringt weiter, in angebbarer Weise: Beide sind Fahrzeuge, für
die jetzt offenbar drei verstehbare Namen genannt sind.
Jeder der Bezeichner abstrahiert genau hinreichend,
und die Ebenen der Abstraktion hast du konditional in eine
Hierarchie geordnet. Wie beschreibt man diesen gegebenen
Vorgang der Unterscheidung von Abstraktionsebenen
in C-Normbegriffen?
Näher an C:
Wenn ich nicht wissen möchte, welche wahrscheinliche
Breite eine Ganzzahl in einem C-Programm haben wird,
weil z.B. mein Programm mit den Fingern einer Hand
zu tun hat, liefert mir die folgende Schreibweise genau das:
typedef short|int|long whole_number;
Hoffentlich kann in d.c.l.c diese nur andeutende Schreibweise
einer möglichen Auswahl aus "short", "int", oder "long"
verstanden werden, auch wenn die Definition von C sie
nicht oder anders abdeckt.
> Es ist schlicht
> Bloedsinn, in einer ernsthaften Diskussion um die Sprache C
Das liegt der Hund begraben: Benamungs-Strategien werden in C nicht
gegeben, nur die Mittel dafür. Sie sind aber für C-Programme
wichtig, und wie hier diskutiert, in verschiedener Hinsicht...
Claus Reibenstein
> Claus Reibenstein <4spame...@online.de> wrote:
>
>> Thomas Koller schrieb:
>>
>>> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>>>
>>>> Wenn man die Unterschiede abstrahiert, ist ein Fahrrad ein Formel1-Rennwagen.
>>
>> Da muss man aber schon sehr weit abstrahieren.
>
> Eigentlich nicht besonders weit. Sowas macht man in unserer Gesellschaft
> alle naselang.
Also mir ist bislang noch niemand begegnet, der Fahrrad und
Formel1-Rennwagen auf eine gemeinsame Ebene abstrahiert h�tte oder
abstrahieren wollte.
>>> Wenn man die Unterschiede nicht abstrahiert, ist mein rotes Fahrrad was
>>> ganz anderes als dein blaues Fahrrad. Was sollte es uns bringen
>>> wenn ich beides als das Gleiche (ein Fahrrad) betrachte?
>>
>> Die Funktion eines Fahrrades ist von seiner Farbe unabh�ngig.
>
> ja und?
Wie "ja und"?
> Der Punkt ist, dass du vom konkreten Objekt Fahrrad
> abstrahieren musst. Wenn du farbenblind bist, oder dir Farben
> generell egal sind, dann nimm halt meinetwegen mein Mountainbike
> vs. dein Stra�enrad, da hast dann auch unterschiedliche Funktion,
Und folglich auch eine andere Abstraktionsebene.
> trotzdem sind beides Fahrr�der. Nur halt eine Stufe detaillierter
> als die Unterscheidung Fahrrad und Auto.
Das meinte ich mit "sehr weit abstrahieren".
>>> Oder auch beim Beispiel PI
>>
>> Gerade hier suche ich noch den gemeinsamen Kern zum typedef (bzw. eine
>> geeignete Abstraktionsebene, um in Eurer Nomenklatur zu bleiben).
>
> Ich w�nsche dir, dass du es schaffst, und du nicht auf ewig �ber
> Detailprobleme und -l�sungen nicht hinauskommst.
Da gibt es f�r mich nichts zu "schaffen". Ich sehe keine geeignete
Ebene, und bislang konnte mir auch niemand eine aufzeigen.
Au�erdem will _ich_ hier gar nichts abstrahieren.
Gru�. Claus
Claus Reibenstein
> Juergen Ilse schrieb:
>
>> Hier von "auf der und jener Ab-
>> straktionsebene ist es das gleiche" herumzufaseln, zeugt meiner Ansicht
>> nach nur von einem falschen Verstaendnis der Sprache.
>
> Von welcher falsch verstandenen Sprache sprichst du,
> wenn du eine Definition von "Abstraktionsebene" Gefasel nennst?
Da wir hier in dclc sind, vermute ich mal C.
Gruß. Claus
Thomas Koller
>>> Da muss man aber schon sehr weit abstrahieren.
>> Eigentlich nicht besonders weit. Sowas macht man in unserer Gesellschaft
>> alle naselang.
> Also mir ist bislang noch niemand begegnet, der Fahrrad und
> Formel1-Rennwagen auf eine gemeinsame Ebene abstrahiert h�tte oder
> abstrahieren wollte.
Nicht? Wo lebst du denn?
Zumindest hier bei mir hat das bei einer Spontanumfrage jeder auf
Anhieb verstanden, dass Fahrrad und Formel1-Rennwagen beides Fahrzeuge
sind.
Komisch wenn dir noch niemand begegnet ist, der eine Abstraktionsebene
"Fahrzeug" h�tte brauchen k�nnen.
>>>> Wenn man die Unterschiede nicht abstrahiert, ist mein rotes Fahrrad was
>>>> ganz anderes als dein blaues Fahrrad. Was sollte es uns bringen
>>>> wenn ich beides als das Gleiche (ein Fahrrad) betrachte?
>>>
>>> Die Funktion eines Fahrrades ist von seiner Farbe unabh�ngig.
>>
>> ja und?
>
> Wie "ja und"?
"ja und" im Sinn, das ist doch f�r das Beispiel irrelevant.
>> Der Punkt ist, dass du vom konkreten Objekt Fahrrad
>> abstrahieren musst. Wenn du farbenblind bist, oder dir Farben
>> generell egal sind, dann nimm halt meinetwegen mein Mountainbike
>> vs. dein Stra�enrad, da hast dann auch unterschiedliche Funktion,
> Und folglich auch eine andere Abstraktionsebene.
Richtig.
>> trotzdem sind beides Fahrr�der. Nur halt eine Stufe detaillierter
>> als die Unterscheidung Fahrrad und Auto.
> Das meinte ich mit "sehr weit abstrahieren".
Wie gesagt, wenn das f�r dich schon "sehr weit" ist, dann ist es
mit deiner F�higkeit zum abstrahieren vermutlich nicht so weit her. :-)
Aber wir k�nnen uns gern darauf einigen dass "Fahrzeug" eine weitere
Abstraktionsebene ist als "Fahrrad". "sehr" ist ohnehin ein sehr
relativer Begriff. ;-)
>>>> Oder auch beim Beispiel PI
>>>
>>> Gerade hier suche ich noch den gemeinsamen Kern zum typedef (bzw. eine
>>> geeignete Abstraktionsebene, um in Eurer Nomenklatur zu bleiben).
>>
>> Ich w�nsche dir, dass du es schaffst, und du nicht auf ewig �ber
>> Detailprobleme und -l�sungen nicht hinauskommst.
>
> Da gibt es f�r mich nichts zu "schaffen".
Nun, laut deiner Aussage suchst du sie, findest diese Abstraktionsebene
aber nicht. Wenn dir der Begriff "schaffen" daf�r nicht passt kannst
du gern einen besseren vorschlagen.
> Ich sehe keine geeignete
> Ebene, und bislang konnte mir auch niemand eine aufzeigen.
>
> Au�erdem will _ich_ hier gar nichts abstrahieren.
Du nicht, aber der OP. Wenn du seine Abstraktion nicht schaffst, dann
macht es wenig Sinn wenn du an seiner Diskussion teilnimmst, da du
dann an den anderen Diskussionsteilnehmern vorbeireden wirst.
Tom
Elmar Sack
> Natürlich könnte man die Werte gleich in Strukturen packen
> typedef struct { double value; } length_t;
> aber an sowas explodieren die Optimierer real existierender Compiler,
> die gerne mal Hemmungen haben, "echte" Strukturen in Register zu packen.
Verzeihung, da war ich mal wieder zu schnell: genauso wie von dir
beschrieben, mache ich es auch! Ich arbeite deshalb ausschließlich bei
Übergaben mit Strukturen. Wie gut der Optimierer das packt, ist mir egal.
Elmar
U. v. Bassewitz
> Also mir ist bislang noch niemand begegnet, der Fahrrad und
> abstrahieren wollte.
http://de.wikipedia.org/wiki/Fahrzeug
>>> Die Funktion eines Fahrrades ist von seiner Farbe unabhï¿œngig.
>>
>> ja und?
>
> Wie "ja und"?
Genau das ist die Abstraktion. "Rotes Fahrrad" und "blaues Fahrrad" wurden
als "Fahrrad" abstrahiert, indem Eigenschaften weggelassen wurden, die
fï¿œr das Verstï¿œndnis eines bestimmten Sachverhalt nicht benï¿œtigt werden.
> Da gibt es fï¿œr mich nichts zu "schaffen". Ich sehe keine geeignete
> Ebene, und bislang konnte mir auch niemand eine aufzeigen.
>
> Auï¿œerdem will _ich_ hier gar nichts abstrahieren.
Abstrahieren ist was ganz normales, das tust Du permanent. Bloss hier
nicht, weil Du sonst zugeben mï¿œsstest, Unrecht zu haben:-)
Gruￜ
Uz (seit langem mal wieder d.c.l.c lesend und sehr erheitert)
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
19:27:52 up 2 days, 22:01, 13 users, load average: 0.01, 0.07, 0.13
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
[...]
>> | #define PI 3.14159265
[...]
>> | const double PI = 3.14159265;
>> |
>> | noch �quivalent: Sie weisen der Zeichenkette "3.14159265" eine k�rzere
>> | Zeichenkette als Bezeichner zu.
>> `----
[...]
>> Beide Zeilen
>> sind zunaechsteinmal Zeichenfolgen (eigentlich Glyphen). Bedeutung
>> erhalten sie lediglich dadurch, dass sie in einem bestimmten Kontext
>> interpretiert werden. In diesem Fall ist der Kontext die
>> C-Sprachdefinition.
>
> Nein, er hat ja extra erw�hnt dass es nicht im Kontext der
> C-Sprachdefinition (was nat�rlich hier erstmal default ist, daher
> ist deine Verwirrung am Anfang durchaus verst�ndlich) gemeint
> ist, sondern auf einer anderen Abstraktionsebene.
Worauf ich hinauswollte war, dass es sich weniger um eine 'andere
Abstraktionsebene' handelt, sondern um einen vollkommen anderen
Bezugsrahmen und obendrein um einen, der nur aufgrund oberflaechlicher
Aehnlichkeiten im konkreten Beispiel ueberhaupt sinnvoll zu sein
scheint. ZB sind
const int PI = 3.14159265;
oder
volatile const double PI = 3.14159265;
auch gueltige Definitionen konstanter Objekte, bei denen die
'Zeichenkettensubstitionserklaerung' versagt, im ersten Fall ziemlich
deutlich (automatische Umwandlung des Literals in einen Wert mit Typ
'int'), im zweiten etwas subtiler (Wert darf nicht 'inline' benutzt
werden, weil Lesezugriffe auf das Objekt als seiteneffektbehaftet
gelten sollen).
Claus Reibenstein
> Abstrahieren ist was ganz normales, das tust Du permanent. Bloss hier
> nicht, weil Du sonst zugeben mï¿œsstest, Unrecht zu haben:-)
Womit soll ich Unrecht haben?
Gruￜ. Claus
U. v. Bassewitz
>> Abstrahieren ist was ganz normales, das tust Du permanent. Bloss hier
>> nicht, weil Du sonst zugeben mï¿œsstest, Unrecht zu haben:-)
>
> Womit soll ich Unrecht haben?
Schon gut, ist klar. Wie wir alle wissen haben im Usenet immer alle
Recht:-)
Ich war bloss nach lï¿œngerer Zeit mal wieder in die Gruppe reingestolpert
und ï¿œusserst amï¿œsiert ï¿œber die Diskussion. Ich hï¿œtte mir den Kommentar
verkneifen sollen. Bin auch schon wieder weg. Nix fï¿œr ungut.
Gruￜ
Uz
P.S.: Das mit dem Fahrzeug hast Du aber jetzt verstanden, oder? :-)
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
22:35:50 up 3 days, 1:09, 13 users, load average: 0.22, 0.15, 0.15
Thomas Koenig
Should the value of PI change, ...
Sebastian Waschik
Stefan Reuther <stefa...@arcor.de> writes:
> Man kann typedefs tatsï¿œchlich nutzen, um Typkorrektheit zu prï¿œfen,
> allerdings nur mit Trick: angenommen, man hat
hï¿œufig hilft aber auch "splint". Wobei das dann gleich sehr pingelig
ist.
Viele Grￜￜe
Sebastian Waschik
Rainer Weikusat
>> volatile const double PI = 3.14159265;
>
> Should the value of PI change, ...
Der Sinn dieser Bemerkung im gegebenen Zusammenhang verschliesst sich
mir.
Thomas Koller
Nicht?
Ich dachte du w�sstest das. Ich fand die Bemerkung lustig. :-)
Aber da hier vielleicht auch C-Neulinge mitlesen, ein kleines Zitat
aus dem Standard:
"An object declared
extern const volatile int real_time_clock;
may be modifiable by hardware"
Tom
Rainer Weikusat
Und welchen Sinn hat das jetzt im Zusammenhang mit einem Text, der
urspruenglich (unter anderem) 'Definitionen konstanter Objekte in C'
zum Inhalt hatte und mehr oder minder zufaellig ein konkretes Beispiel
aus einem anderen Text uebernommen hatte? Technisch gesehen ist die
Aussage, dass ich den mir zugeschriebenen Text geschrieben haette,
schlicht falsch, denn 'Veraenderungen von als konstant definiterten
Objekten' kamen in meinem Text nicht vor.
Thomas Koller
> Thomas Koller <tko...@gmx.at> writes:
>> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>> volatile const double PI = 3.14159265;
>>>>
>>>> Should the value of PI change, ...
>>>
>>> Der Sinn dieser Bemerkung im gegebenen Zusammenhang verschliesst sich
>>> mir.
>>
>> Nicht?
>>
>> Ich dachte du w�sstest das. Ich fand die Bemerkung lustig. :-)
>>
>> Aber da hier vielleicht auch C-Neulinge mitlesen, ein kleines Zitat
>> aus dem Standard:
>>
>> "An object declared
>> extern const volatile int real_time_clock;
>> may be modifiable by hardware"
>
> Und welchen Sinn hat das jetzt im Zusammenhang mit einem Text, der
> urspruenglich (unter anderem) 'Definitionen konstanter Objekte in C'
> zum Inhalt hatte und mehr oder minder zufaellig ein konkretes Beispiel
> aus einem anderen Text uebernommen hatte?
Die Bemerkung beleuchtet das "volatile" und dass in C Konstante halt
doch nicht in jedem Fall so konstant sind wie man meinen k�nnte auf
humorvolle Weise.
> Technisch gesehen ist die
> Aussage, dass ich den mir zugeschriebenen Text geschrieben haette,
> schlicht falsch, denn 'Veraenderungen von als konstant definiterten
> Objekten' kamen in meinem Text nicht vor.
? Von welchem "dir zugeschriebenen Text" sprichst du?
Tom