was heisst ->

A. K. schrieb:

> p->m ist in C nur eine vereinfachte Schreibweise von (*p).m

Vereinfacht... Harhar...

In jeder vernünftigen Programmiersprache schreibt man einfach "p.m", 
weil der Compiler an dieser Stelle natürlich schon selber weiss, das er 
den Zeiger dereferenzieren muss.

Nur dieser unsägliche Makroassembler namens "C" ist zu doof, das alleine 
herauszufinden...

c-hater schrieb:
> n jeder vernünftigen Programmiersprache schreibt man einfach "p.m", weil
> der Compiler an dieser Stelle natürlich schon selber weiss, das er den
> Zeiger dereferenzieren muss

Natürlich. Es ist aber dadurch lesbarer weil man sofort erkennt, dass es 
sich um einen Zeiger handelt.

Nicht alles was ein Compiler einem abnehmen könnte ist gut.

Grüsse,
René

c-hater schrieb:
> In jeder vernünftigen Programmiersprache schreibt man einfach "p.m",

Oha, welche Compiler Sprache unterscheidet denn noch Pointer auf 
Strukturen/Klassen von "direkten" Werten, aber braucht keine explizite 
Dereferenzierung? C++ und Pascal schon mal nicht.

in Pascal
wird auch unterschieden.
PlayFile^.filename
wenn ich nicht irre.

Dr. Sommer schrieb:
> c-hater schrieb:
>> In jeder vernünftigen Programmiersprache schreibt man einfach "p.m",
>
> Oha, welche Compiler Sprache unterscheidet denn noch Pointer auf
> Strukturen/Klassen von "direkten" Werten, aber braucht keine explizite
> Dereferenzierung? C++ und Pascal schon mal nicht.

D. Was will man will mit p.m (p → Pointer) sonst erreichen?

Überschüssiges "will" bitte ignorieren.

ROLF schrieb:
> Was wird hiermit zum Ausdruck gebracht
>
> PlayFile->filename

Nun ja, in C ist gar manches nicht wirklich logisch gemacht, sondern 
fast immer nach dem Motto "das ist hier eben so, basta!"

Also, wenn du in C eine Variable in einer Struktur ansprechen willst, 
dann schreibst du
MeinStruct.MeinMember = irgendwas;

Wenn du aber einen Zeiger auf deine Struktur vorliegen hast, dann mußt 
du
das so schreiben:
ZeigerAufMeinStruct->MeinMember = irgendwas;
Das mußt du dir einfach merken, da hilft nix.

Laß dich von dem C versus Pascal Gerede nicht durcheinander bringen. In 
klassischem Pascal ist das alles wirklich systematischer, da würde man 
schreiben
MeinStruct.MeinMember:= irgendwas;
ZeigerAufMeinStruct^.MeinMember:= irgendwas;

Mit dem neueren (alternativen) Objektmodell in Pascal, wie es bei Delphi 
gebräuchlich ist, könnte man bei Objekten auch
MeinObjekt.MeinMember:= irgendwas;
schreiben, denn dabei erkennt der Compiler von selbst, daß MeinObjekt 
ein Zeiger auf ne Referenz zu einem entsprechend instantiierten Objekt 
ist, aber du hast ja explizit nach etwas aus der C-Ecke nachgefragt.

W.S.

A. K. schrieb:
> Ist C nicht schön? ;-)

Ja, richtig. C ist nicht schön.

A. K. schrieb:
> NB: Wer p-> nicht mag kann auf 0[p]. ausweichen. Ist C nicht schön? ;-)

Jetzt wollte ich Dich gerade fragen, was Du denn geraucht hast?
Also nochmals überlegt, natürlich hast Du recht. Auf so eine schräge 
Idee wäre ich nie gekommen.

Frisst das der Compiler?

Grüsse,
René

A. K. schrieb:
> René H. schrieb:
>> Frisst das der Compiler?
>
> Natürlich.

Das geht dann unter, wie treibe ich meine Kollegen in den Wahnsinn :).

Grüsse,
René

Einer schrieb:
> D. Was will man will mit p.m (p → Pointer) sonst erreichen?

Ah, mit C kenn ich mich nicht aus. Na, ob c-hater D mit "vernünftige 
Programmiersprache" meinte? Man weiß es nicht.

Marc V. schrieb:
> Und warum dann nicht gleich P1.P2.P3.P4 ?
In C ist vieles hässlich/unnötig eingeschränkt. Der -> Operator ist da 
noch das kleinste Problem. Zum Glück wird niemand gezwungen C zu 
verwenden - das machen die meisten freiwillig weil alles andere böse 
ist, oder so.

In C++ ist der -> Operator übrigens gar nicht so blöd, weil man den 
überladen kann und damit z.B. Smart Pointer implementieren kann.

Marc V. schrieb:

>  Aber wenn ich schon eine Struktur deklariert habe, dann sollte doch
>  Struktur.Member reichen, oder ?

Genau so ist das. Hochsprachen sind ja schließlich dafür da, die Details 
vor ihrem Benutzer möglichst weitgehend zu verbergen. Und wenn das 
tatsächlich das Ziel ist, dann sollte an dieser Stelle der Punkt zur 
Notation reichen.

>  Wobei ich Struktur->Member sogar besser finde als Struktur.Member,
>  vor allem da es klar ist, dass es sich um Pointer handelt.

Das könnte man als zusätzliches Feature sicher auch implementieren. 
Nämlich für den Fall, dass der Programmierer EINFLUSS auf die 
Dereferenzierung bekommen können soll, wie z.B. in dem Beispiel von "Dr. 
Sommer" hier im Thread (C++). Bei den "smart pointers" wird zwar nicht 
die eigentliche Dereferenzierung angefasst, aber man kann immerhin auf 
die Tatsache reagieren, dass auf den referenzierten Speicherblock 
zugegriffen werden soll. Das ist immerhin etwas, was durchaus sehr 
nützlich sein kann.

Nur leider: dieser unsägliche C-Dreck hat hier (im Gegensatz zu C++) 
einen Operator, der dem Programmierer absolut keinen Nutzen bringt. Er 
wird nur völlig sinnlos gezwungen, ihn und seine Bedeutung zu erlernen. 
Genau deswegen existiert dieser Thread. Der TO war halt an dem Punkt, wo 
er durch diesen C-Dreck gezwungen wurde, etwas zu lernen, was er niemals 
zu seinem Vorteil verwenden können wird. Jedenfalls nicht, so lange er 
bei C bleibt...

Rufus Τ. F. schrieb:
> Vielen Dank für..

Ach, laß mal. Er hat gelegentlich eine etwas besondere Ausdrucksweise, 
aber im Grunde kommt aus seinen Worten durchaus die notwendige Besorgnis 
heraus, was die Sprache C und ihren Werdegang betrifft.

C ist zwar benutzbar, aber durchaus nicht schön und pädagogisch 
fragwürdig, da in vielen Teilen zu unlogisch und recht unglücklich 
konzipiert. Obendrein sieht man seit Jahren sehr deutlich die Mankos, 
wenn man das Thema Objekte und grafische Oberflächen für Programme 
betrachtet. C ist tatsächlich veraltet, man kann es eigentlich nur noch 
für Kommandozeilenprogramme benutzen, ohne dabei allzu unproduktiv zu 
werden. Klar, es geht ja im Prinzip, hab mich selber mit EVC jahrelang 
herumgeplagt, aber das ist heutzutage alles viel niedriges Niveau - 
jedenfalls auf dem PC. Auf dem µC sieht das ganz anders aus, da reicht C 
wohl noch eine ganze Weile - jedenfalls für das Zeugs, was man auf 
PIC's, AVR's und kleineren ARM's so zusammenprogrammiert.

Dennoch: im Grunde fühlt es wohl jeder schon seit Jahren, daß da 
irgendwann mal was Neues kommen muß, auch auf dem µC. Dummerweise sind 
all diejenigen, die zumeist nur in C programmieren, bereits so auf C 
eingestellt, daß sie mental mit etwas anderem, das eben nicht wie C 
aussieht, nicht mehr zurechtkommen. Deshalb sehen alle bisherigen 
Neuentwürfe eben wie durchgeknetetes C aus und haben die Geburtsfehler 
von C mehr oder weniger übernommen - auch die Abneigung gegen alles, was 
wie Pascal aussieht. Ist schon komisch: Pascal in Form von aktuellem 
Delphi hat sich weiterentwickelt, hat alte Beschränkungen beseitigt und 
ist für aktuelles Programmieren auf dem PC topfit, aber sämtliche 
Versuche, bei C etwas ähnliches hinzukriegen, sind an der 
Starrköpfigkeit der Leute gescheitert.  Im Rückblick kann man sich nur 
wundern, daß damals das ANSI-C tatsächlich gegen den alten K&R 
erfolgreich durchgepeitscht worden ist.

Jetzt sollte man nicht Java und C# zitieren, interpretiertes Zeugs ist 
was Anderes - und man sieht ja, wohin das bei Android geführt hat: Für 
alles, was man mit nativem Code erreichen kann, braucht man dort das 
doppelte oder noch mehr - sowohl an RAM als auch an MHz als auch 
dringend an fetten Grafikprozessoren.

W.S.

S. R. schrieb:
> Delphi durfte ich auch mal lernen und empfand es - verglichen mit VB6! -
> als ziemlich nervig.

Delphi versus Basic? Uch..

Also, aus meiner Perspektive ist Delphi überhaupt nicht nervig, egal ob 
als Embarcadero oder Lauzarus. Und es ist mächtig, mächtiger als Basic 
und C++ zusammen. Kein Vergleich zu VB - egal welche Generation.

Aber ich verstehe das schon, daß Leute, die mental auf C ausgerichtet 
sind, eine Aversion gegen Pascal entwickelt haben. Wieso auch immer. 
Nach den Beweggründen zu fragen, hab ich mir abgewöhnt. Fragt man mal 
dediziert nach, dann outen sich die Leute als horizontbeschränkt. Ist 
eben so.

Aus deinen Worten schließe ich jedoch, daß du zwischen Pascal als einer 
Programmiersprache und Delphi bzw. Lazarus als einem RAD-Tool nicht 
unterscheiden kannst (oder willst).

Aber darum geht es hier ja garnicht. Hier haben wir wieder einmal ein 
Verständnisproblem mit C. Verstehe das mal richtig: Die C-Anfänger 
plagen sich herum mit den ganz niedrigen Sprachproblemen von C, anstatt 
sich den wirklichen und höheren Dingen wie Algorithmen, Strategien, 
Funktionalitäten widmen zu können. Ich frag mich so oft, wozu bloß 
dieser doch erhebliche Lernaufwand für so wenig, was dabei an Nutzen 
herauskommt. Ist es das allgemeine Brett vor'm Kopf zusammen mit dem 
Lemming-Trieb oder was?

So, und jetzt noch was zur guten Nacht:
#define PDB0_MOD      (*((__IO *) 0x40036004))
versus
var
  PDB0_MOD : dword absolute $40036004;

träum was schönes..

W.S.

W.S. schrieb:
> Und es ist mächtig, mächtiger als Basic
> und C++ zusammen.

Ahaha... Es kann ja nichtmal templates. Witzig ist dieser Artikel:
https://edn.embarcadero.com/article/27603
Da werden templates mittels includes hingeschustert. Damit gehen weder 
variadische Templates noch type traits oder viele andere Dinge die in 
C++ gehen...

Move Semantics und constexpr kann es auch nicht, nach weiteren Dingen 
hab ich jetzt nicht gesucht.

W.S. schrieb:

> C ist zwar benutzbar, aber durchaus nicht schön

Geschmackssache. Ich habe mit Pascal programmieren gelernt, das war zu 
Zeiten von Turbo Pascal 3.0, ging dann weiter bis TP 5.0 (IIRC). Aber 
den Umstieg auf C fand ich sehr befreiend und habe ihn nie bereut. 
Jedenfalls kenne ich beides.

> und pädagogisch fragwürdig

Anders als Pascal ist C eben keine Lehrsprache, sondern eine 
Praxissprache. Während Wirth einfach mal so Sprachen erfunden hat, 
hatten K&R ein konkretes Projekt der Systemprogrammierung vor Augen.

Übrigens, das "Problem" aus dem OP hätte man mit Pascal ebenfalls, weil 
es eben etwas Anderes ist, ob man ein Mitglied einer Struktur anspricht 
oder einen Pointer dereferenziert. Das möchte ich auch im Quelltext 
deutlich unterschieden sehen, weil es mir das lesende Verständnis einer 
bestehenden Codebasis erleichtert.

Dein Beispiel mit dem IO ist in C auch deswegen etwas umständlicher, 
weil man im Hintergrund des typedefs auch noch volatile hat, und das 
wiederum will ich auch haben, weil der Compiler dann nämlich die 
Zugriffe auf Variablen ohne volatile besser optimieren kann.

> wenn man das Thema Objekte und grafische Oberflächen für Programme
> betrachtet.

OOP kann man in C in gewissem Maße auch haben. Grafische Oberflächen 
sind aber tatsächlich kein Spaß in C - muß auch nicht, weil C als 
Sprache zur Systemprogrammierung entworfen wurde. Sich beschweren, daß 
man mit einem Traktor auf der Autobahn schlecht aussieht, ergibt keinen 
Sinn.

Das ist mit Pascal aber genauso schlimm, und wenn man Object-Pascal 
heranzieht, dann ist der richtige Vergleich nicht mehr C, sondern C++. 
C++ kann man viel vorwerfen, aber mit Sicherheit keinen Mangel an 
Objektorientierung oder Untauglichkeit zur GUI-Programmierung.

> Dennoch: im Grunde fühlt es wohl jeder schon seit Jahren, daß da
> irgendwann mal was Neues kommen muß, auch auf dem µC.

Egal was, Hauptsache anders, neu und hipp, damit man durch Veränderung 
wenigstens die Suggestion von Fortschritt hat. Wo liegt denn das 
Problem, es kommt doch gefühlt im Wochentakt eine neue Hipstersprache 
raus?

> Dummerweise sind
> all diejenigen, die zumeist nur in C programmieren, bereits so auf C
> eingestellt, daß sie mental mit etwas anderem, das eben nicht wie C
> aussieht, nicht mehr zurechtkommen.

Es muß halt signifikant besser als C sein, sonst wird's abgelehnt, egal 
wie neu es ist. Zumal es für C eben einen riesigen Fundus an Code gibt. 
An beiden Aspekten scheitert Pascal.

Pascal ist seinerzeit geflopt, weil der Standard für realen Einsatz 
vollkommen untauglich war. Deswegen gab es zig taugliche, zu nichts 
kompatible Inseldialekte.

Einen gescheiten Standard gibt es bis heute nicht, und sich auf ein 
einziges OSS-Frickelprojekt zu verlassen ist für Hobby völlig OK, für 
mehr aber auch nicht. Der kommerzielle Zweig mit Embarcadero ist sogar 
noch schlechter aufgestellt, wenn man sich deren wirtschaftliche Lage 
vergegenwärtigt.