Hallo, Was wird hiermit zum Ausdruck gebracht PlayFile->filename[ sizeof(PlayFile->filename) -6 ] = destime.minute/10 + '0'; mir gehts speziell um PlayFile->filename. Was wird hiermit gemacht -> Vielleicht köönte mir das kurz jemand erklären. mfg
:
Verschoben durch Admin
PlayFile ist ein Handle auf eine Dateistruktur und 'filename' ist eine der 'Properties' dieser Struktur. Das '->' greift auf dieses Mitglied der Struktur zu.
ROLF schrieb: > Hallo, > > Was wird hiermit zum Ausdruck gebracht > > PlayFile->filename[ sizeof(PlayFile->filename) -6 ] = destime.minute/10 > + '0'; > > mir gehts speziell um PlayFile->filename. > Was wird hiermit gemacht -> Welche Sprache? Haskell?
ROLF schrieb: > Was wird hiermit gemacht -> Falls C: auf der linken Seite dieses Operators ist ein Pointer. Mit dem -> Operator wird auf ein Element der Struktur zugegriffen, auf die der Pointer zeigt. Ich empfehle hier, ein x-beliebiges C-Buch durchzuarbeiten (also nicht nur drin rumblättern...).
:
Bearbeitet durch Moderator
p->m ist in C nur eine vereinfachte Schreibweise von (*p).m
:
Bearbeitet durch User
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: > Nur dieser unsägliche Makroassembler namens "C" ist zu doof, Lass doch einfach Dein dämliches Getrolle sein. Das ist überflüssig, und Du stellst damit nur Deine gelegentlich beeindruckende Ahnungslosigkeit zur Schau.
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.
Den Operator -> gibt es auch nur deshalb, weil die Dereferenzierung in C leider ein Präfix-Operator ist, kein Suffix-Operator wie in Pascal. Was ein paar hässlichen Folgeeffekte mit sich brachte, darunter auch die umständliche Schreibweise (*p).m, aber auch die verwirrende Deklarationsweise. NB: Wer p-> nicht mag kann auf 0[p]. ausweichen. Ist C nicht schön? ;-)
:
Bearbeitet durch User
A. K. schrieb: > NB: Wer p-> nicht mag kann auf 0[p]. ausweichen. Ist C nicht schön? ;-) Müsste das nicht p[0]. heißen?
Michael K. schrieb: > Müsste das nicht p[0]. heißen? x[y] ist per Definition *(x+y). Und da das + kommutativ ist, sind 0[p] und p[0] ein und dasselbe.
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?
Stefan E. schrieb: > Michael K. schrieb: >> Müsste das nicht p[0]. heißen? > > x[y] ist per Definition *(x+y). Und da das + kommutativ ist, sind 0[p] > und p[0] ein und dasselbe. Macht Sinn. 0[p] liest sich imo ziemlich seltsam...
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: > 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é
Rufus Τ. F. schrieb: > c-hater schrieb: >> Nur dieser unsägliche Makroassembler namens "C" ist zu doof, > > Lass doch einfach Dein dämliches Getrolle sein. Das ist überflüssig, und > Du stellst damit nur Deine gelegentlich beeindruckende Ahnungslosigkeit > zur Schau. Trotzdem stimmt seine Bemerkung, zumindest was die Bemerkung von A.K. betrifft: A. K. schrieb: > p->m ist in C nur eine vereinfachte Schreibweise von (*p).m p->m ist für mich in Ordnung, aber (*p).m bestimmt nicht und darauf bezog sich seine Bemerkung.
:
Bearbeitet durch User
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é
Marc V. schrieb: > und darauf bezog sich seine Bemerkung. Nein, das tat sie nicht. Er war in seiner trolligen Art der Ansicht, daß doch bitte der Compiler erkennen möge, wenn links vom .-Operator ein Pointer steht und er daraus automagisch eine Pointerdereferenzierung anstellen solle, weil das "andere" (aber ungenannt gebliebene) Programmiersprachen ja hinbekämen. Lies Dir einfach den Trollbeitrag von heute, 11:00, nochmal durch.
Rufus Τ. F. schrieb: > Lies Dir einfach den Trollbeitrag von heute, 11:00, nochmal durch. Habe ich, nochmal. Was ich auch dazu sage, es artet wahrscheinlich in einen neuen Streit über Sprachen. Aber wenn ich schon eine Struktur deklariert habe, dann sollte doch Struktur.Member reichen, oder ? Bei Pointern auf Funktions oder bei cast mag das noch einen Sinn ergeben, aber bei einfachen Strukturzugriffen ? Warum sollte der Compiler das nicht automatisch dereferenzieren ? Wobei ich Struktur->Member sogar besser finde als Struktur.Member, vor allem da es klar ist, dass es sich um Pointer handelt. (*(*(*P1).P2).P3).P4 ist doch dasselbe wie: P1->P2->P3->P4 - welches ist aber verständlicher ? Und warum dann nicht gleich P1.P2.P3.P4 ?
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.
W.S. schrieb: > 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. Wie jede andere Sprache auch, hat C durchaus Stärken und Schwächen. Das ist eben so, eine wirkliche Alternative gibt es nicht. Das fängt bei den vorhandenen Tools schon an. Gib mir mal eine andere Sprache (außer C++) mit Toolchains vergleichbarer Qualität und Verbreitung. W.S. schrieb: > Obendrein sieht man seit Jahren sehr deutlich die Mankos, > wenn man das Thema Objekte und grafische Oberflächen für Programme > betrachtet. Funktionale oder sogar Logikprogrammierung gehen mit C auch nicht besonders gut. Das kann man jetzt C ankreiden, oder einfach dem Fakt, dass irgendjemand nicht gelernt hat, zwischen Schraubenzieher und Hammer zu unterscheiden. Grafische Programmierung in C ist durchaus möglich (zumindest empfand ich GTK+ nicht als unangenehm). Objektorientierte Programmierung ist nur in Ansätzen möglich, aber das ist ein Fall von "falsches Werkzeug", nicht von "schlechte Sprache". W.S. schrieb: > 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. Delphi durfte ich auch mal lernen und empfand es - verglichen mit VB6! - als ziemlich nervig. Deren Einsatzzweck sehe ich heute hinreichend von Python und anderen Scriptsprachen abgedeckt, nicht von C. Wieder eine Frage des richtigen Werkzeugs. Im Gegensatz zu Java, C#, Go, Delphi, Python usw. ist C eine sehr kleine Sprache. Da kann man nicht so viel dran rumbauen, ohne die Kompatiblität aufzugeben oder in Feature-Bloat erschlagen zu werden. Trotzdem entwickelt es sich weiter - K&R ist nicht mehr Stand der Dinge.
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: > Und es [Delphi] ist mächtig, mächtiger als Basic und C++ zusammen. Naja, das möchte ich bezweifeln. Nach Turing sind sie erstmal allesamt gleich mächtig, und mit Lazarus eine C-Bibliothek langfristig kompatibel anzusteuern, scheint hinreichend schwierig (ich hab das einmal mit libavcodec durch - nie wieder). W.S. schrieb: > Aber ich verstehe das schon, daß Leute, die mental auf C ausgerichtet > sind, eine Aversion gegen Pascal entwickelt haben. Ich kann dir versichern, dass ich in meiner Object-Pascal/Delphi-Zeit mental nicht auf C ausgerichtet war, da ich mit C erst mehrere Jahre später in Berührung gekommen bin. Aber Vorurteile muss man ja pflegen, ne? Die letzten Jahre habe ich hauptsächlich mit C, Assembler und Perl verbracht, und ein bisschen Python. Pascal empfand ich nie als angenehm. W.S. schrieb: > 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). Der Unterschied ist mir durchaus klar. Sowohl Delphi als auch VB6 waren annehmbare RAD-Tools. Aber Object Pascal machte mir damals weniger Spaß als Visual Basic, und die Syntax empfinde ich nach wie vor als "stellenweise furchtbar nervig". Das habe ich aber an anderer Stelle schon ausgeführt. Pascal außerhalb von Delphi/Lazarus habe ich bisher nicht nennenswert in freier Wildbahn gesehen; die CP/M-und-DOS-Ära mit Turbo-Pascal lasse ich mal außen vor, denn die war lange vor meiner Zeit.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.