Die Mathe-Redaktion - 15.11.2019 16:55 - Registrieren/Login
Auswahl
ListenpunktHome
ListenpunktAktuell und Interessant ai
ListenpunktArtikelübersicht/-suche
ListenpunktAlle Links / Mathe-Links
ListenpunktFach- & Sachbücher
ListenpunktMitglieder / Karte / Top 15
ListenpunktRegistrieren/Login
ListenpunktArbeitsgruppen
Listenpunkt? im neuen Schwätz
ListenpunktWerde Mathe-Millionär!
ListenpunktFormeleditor fedgeo
Schwarzes Brett
Aktion im Forum
Suche
Stichwortsuche in Artikeln und Links von Matheplanet
Suchen im Forum
Suchtipps

Bücher
Englische Bücher
Software
Suchbegriffe:
Mathematik bei amazon
Naturwissenschaft & Technik
In Partnerschaft mit Amazon.de
Kontakt
Mail an Matroid
[Keine Übungsaufgaben!]
Impressum

Bitte beachten Sie unsere Nutzungsbedingungen, die Distanzierung, unsere Datenschutzerklärung und
die Forumregeln.

Sie können Mitglied werden. Mitglieder können den Matheplanet-Newsletter bestellen, der etwa alle 2 Monate erscheint.

Der Newsletter Okt. 2017

Für Mitglieder
Mathematisch für Anfänger
Wer ist Online
Aktuell sind 645 Gäste und 22 Mitglieder online.

Sie können Mitglied werden:
Klick hier.

Über Matheplanet
 
Zum letzten Themenfilter: Themenfilter:
Matroids Matheplanet Forum Index
Moderiert von matph
Informatik » Programmieren » C: Output anders als erwartet
Druckversion
Druckversion
Autor
Schule J C: Output anders als erwartet
Ex_Mitglied_50518
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Themenstart: 2019-05-26


Hi!
Ich stelle 2 kurze Übungsaufgaben rein, bei denen der Output bzw. Lösung anders ist, als ich es erwartet hätte:



Wieso ist a nicht 92?


Wieso ist der Output hier nicht B (also 11 als Hexadezimalzahl)?

Lg,
Zrebna



  Profil  Quote  Link auf diesen Beitrag Link
Buri
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 02.08.2003
Mitteilungen: 45989
Aus: Dresden
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.1, eingetragen 2019-05-26


2019-05-26 16:48 - Zrebna im Themenstart schreibt:
Wieso ist der Output hier nicht B (also 11 als Hexadezimalzahl)?
Hi Zrebna,
wenn du B als Ausgabe haben willst, musst du ++a schreiben und nicht a++.
Gruß Buri



  Profil  Quote  Link auf diesen Beitrag Link
DerEinfaeltige
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 11.02.2015
Mitteilungen: 2139
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.2, eingetragen 2019-05-26


Der ++ - Opertor hinter der Variable bedeutet, dass der Wert zurückgegeben wird, den die Variable VOR dem Inkrement besaß.



[Die Antwort wurde vor Beitrag No.1 begonnen.]


-----------------
Why waste time learning when ignorance is instantaneous?
- Bill Watterson -



  Profil  Quote  Link auf diesen Beitrag Link
Fabi
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.03.2002
Mitteilungen: 4503
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.3, eingetragen 2019-05-26


Hallo Zrebna,

Wenn man sich anschaut, wie Post-Increment ++ (d.h. b++ anstelle des Pre-increments ++b) funktioniert und welche Priorität ++ und * haben, kann man den Code auch so schreiben:
C
int main(void) {
     int a=40, b=50, c=80;
     float d = a/c;
     int *pa = &a;
     *pa += b;
     b = b+1;
     *(pa++); //Tut nichts außer pa zu verändern - zumindest ist das die Intention des Aufgabenstellers...
     c = b; b=c;
}

Dann bekommt man das gewünschte Resultat (jedenfalls ist das die Intention, aber siehe unten). Allgemeine Regel beim Programmieren: An jeder irgendwie unklaren Stelle Klammern setzen, um die Ordnung der Befehle zu fixieren, und sich nicht auf das verlassen, was der Compiler tut - das ist zwar wohldefiniert, aber oft eher obskur und kann lustige Bugs verursachen. Den Code würde ich so bei uns auf der Arbeit nicht durchs Codereview kommen lassen.

Das Herumreiten des Aufgabenerstellers auf Sprachdetails wird übrigens dadurch vollkommen ad absurdum geführt, dass *(pa++); undefined behavior ist (niemand garantiert, dass hinter a irgendwas im Speicher liegt) und daher das Programm im Prinzip machen kann, wozu der Compiler gerade lustig ist.

vG,
Fabi


-----------------
"There would be the mathematical equivalent of worldwide rioting." (P.C.)

Willst du Hamburg oben sehen, musst du die Tabelle drehen.



  Profil  Quote  Link auf diesen Beitrag Link
Ex_Mitglied_50518
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.4, vom Themenstarter, eingetragen 2019-05-31


2019-05-26 16:56 - DerEinfaeltige in Beitrag No. 2 schreibt:
Der ++ - Opertor hinter der Variable bedeutet, dass der Wert zurückgegeben wird, den die Variable VOR dem Inkrement besaß.



[Die Antwort wurde vor Beitrag No.1 begonnen.]

Ah ok, das klärt die Sache auf - danke^^



  Profil  Quote  Link auf diesen Beitrag Link
Ex_Mitglied_50518
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.5, vom Themenstarter, eingetragen 2019-05-31


2019-05-26 18:32 - Fabi in Beitrag No. 3 schreibt:
Hallo Zrebna,

Wenn man sich anschaut, wie Post-Increment ++ (d.h. b++ anstelle des Pre-increments ++b) funktioniert und welche Priorität ++ und * haben, kann man den Code auch so schreiben:
C
int main(void) {
     int a=40, b=50, c=80;
     float d = a/c;
     int *pa = &a;
     *pa += b;
     b = b+1;
     *(pa++); //Tut nichts außer pa zu verändern - zumindest ist das die Intention des Aufgabenstellers...
     c = b; b=c;
}

Dann bekommt man das gewünschte Resultat (jedenfalls ist das die Intention, aber siehe unten). Allgemeine Regel beim Programmieren: An jeder irgendwie unklaren Stelle Klammern setzen, um die Ordnung der Befehle zu fixieren, und sich nicht auf das verlassen, was der Compiler tut - das ist zwar wohldefiniert, aber oft eher obskur und kann lustige Bugs verursachen. Den Code würde ich so bei uns auf der Arbeit nicht durchs Codereview kommen lassen.

Das Herumreiten des Aufgabenerstellers auf Sprachdetails wird übrigens dadurch vollkommen ad absurdum geführt, dass *(pa++); undefined behavior ist (niemand garantiert, dass hinter a irgendwas im Speicher liegt) und daher das Programm im Prinzip machen kann, wozu der Compiler gerade lustig ist.

vG,
Fabi

Alles klar, danke - Post hat sehr geholfen!

@letzten Absatz:
Sicher hast du recht und unser Prof in theoretischer Informatik hat sogar gemeint, dass ein guter Programmierer maximal bei "Punkt vor Strich" nicht klammert, sonst aber zur Sicherheit überall.
Aber ja, was soll man als Student machen - man beugt sich dem Willen der Vorgaben xD

*pa++ hat also nicht den dereferenzierten Wert erhöht, auf den der Pointer zeigt, sondern erhöht die Adresse des Zeigers selbst  - hier um 4 Bytes, da es ein int_Pointer ist?




  Profil  Quote  Link auf diesen Beitrag Link
ligning
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 07.12.2014
Mitteilungen: 2808
Aus: Berlin
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.6, eingetragen 2019-05-31


2019-05-31 12:28 - Zrebna in Beitrag No. 5 schreibt:
Sicher hast du recht und unser Prof in theoretischer Informatik hat sogar gemeint, dass ein guter Programmierer maximal bei "Punkt vor Strich" nicht klammert, sonst aber zur Sicherheit überall.
Es hat sicher einen guten Grund, dass er sich in theoretischer Informatik spezialisiert hat. Sorry für OT.



  Profil  Quote  Link auf diesen Beitrag Link
Ex_Mitglied_50518
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.7, vom Themenstarter, eingetragen 2019-05-31


2019-05-31 13:28 - ligning in Beitrag No. 6 schreibt:
2019-05-31 12:28 - Zrebna in Beitrag No. 5 schreibt:
Sicher hast du recht und unser Prof in theoretischer Informatik hat sogar gemeint, dass ein guter Programmierer maximal bei "Punkt vor Strich" nicht klammert, sonst aber zur Sicherheit überall.
Es hat sicher einen guten Grund, dass er sich in theoretischer Informatik spezialisiert hat. Sorry für OT.

Woebei, das hast du falsch verstanden und/oder ich hab es missverständlich geschrieben xD

Denke der TI-Prof sieht es so wie Fabi: Zur Sicherheit einfach quasi überall klammern...

Unser Programmier-Prof denk ich hat halt gewisse Lehrplanvorgaben und muss sich teils daran halten und evtl. macht es doch irgendwo auch meist Sinn, den ich halt als Anfänger noch nicht erschließen kann...




  Profil  Quote  Link auf diesen Beitrag Link
ligning
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 07.12.2014
Mitteilungen: 2808
Aus: Berlin
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.8, eingetragen 2019-05-31


2019-05-31 14:39 - Zrebna in Beitrag No. 7 schreibt:
Woebei, das hast du falsch verstanden und/oder ich hab es missverständlich geschrieben xD

Denke der TI-Prof sieht es so wie Fabi: Zur Sicherheit einfach quasi überall klammern...
Oder ich hab es missverständlich geschrieben? Dann nochmal explizit: Die Sprachsyntax zu beherrschen ist eine absolute Grundfertigkeit. Irgendwann weiß man, wie es funktioniert. Irgendwann müssen die Stützräder ab. Überall "zur Sicherheit" Klammern zu setzen ist ein Zeichen von Unsicherheit. Bei jemandem der das macht, würde ich eher nochmal genauer hingucken, ob da noch andere elementare Dinge nicht verstanden wurden.



  Profil  Quote  Link auf diesen Beitrag Link
Ex_Mitglied_50518
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.9, vom Themenstarter, eingetragen 2019-05-31


@ligning

2019-05-26 18:32 - Fabi in Beitrag No. 3 schreibt:
Hallo Zrebna,

 Allgemeine Regel beim Programmieren: An jeder irgendwie unklaren Stelle Klammern setzen, um die Ordnung der Befehle zu fixieren, und sich nicht auf das verlassen, was der Compiler tut - das ist zwar wohldefiniert, aber oft eher obskur und kann lustige Bugs verursachen. Den Code würde ich so bei uns auf der Arbeit nicht durchs Codereview kommen lassen.

vG,
Fabi

Dann sieht es Fabi und mein TI-Prof einfach anders, als du?
Oder ich missverstehe Fabi?

Ich persönlich hab hier noch gar keine Meinung, da ich noch absoluter Beginner bin und hier noch gar keine Meinung, basierend auf Erfahrung haben kann...
Scheint aber zumindest schon mal unterschiedliche Standpunkte bzgl. diesem Punkt zu geben.



  Profil  Quote  Link auf diesen Beitrag Link
DerEinfaeltige
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 11.02.2015
Mitteilungen: 2139
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.10, eingetragen 2019-06-02


Das entscheidende Stichwort dürfte "unklar" sein.

Code sollte gut lesbar sein und Klammern können dazu beitragen.
Sie können bei exzessiver Nutzung allerdings ebenso die Lesbarkeit des Codes verschlechtern.
Überall Klammern zu setzen ist daher unsinnig.
Auf jede formal unnötige Klammer zu verzichten halte ich beim Programmieren hingegen für genauso zweifelhaft.

Programmiert man viel in C/C++, so werden bestimmte Vorrangregeln beim Umgang mit Pointern in Fleisch und Blut übergehen. Entsprechend ist das Stichwort "unklar" auch ein wenig relativ.


-----------------
Why waste time learning when ignorance is instantaneous?
- Bill Watterson -



  Profil  Quote  Link auf diesen Beitrag Link
Ex_Mitglied_50518 hat die Antworten auf ihre/seine Frage gesehen.
Ex_Mitglied_50518 hat selbst das Ok-Häkchen gesetzt.
Neues Thema [Neues Thema]  Druckversion [Druckversion]

 


Wechsel in ein anderes Forum:
 Suchen    
 
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001-2019 by Matroids Matheplanet
This web site was made with PHP-Nuke, a web portal system written in PHP. PHP-Nuke is Free Software released under the GNU/GPL license.
Ich distanziere mich von rechtswidrigen oder anstößigen Inhalten, die sich trotz aufmerksamer Prüfung hinter hier verwendeten Links verbergen mögen.
Lesen Sie die Nutzungsbedingungen, die Distanzierung, die Datenschutzerklärung und das Impressum.
[Seitenanfang]