Google hat mal wieder eine Betriebsstörung?
Crazy H. schrieb:> Was bedeutet das | zwischen 0x28 und vol?
Bitweises Oder.
Crazy H. schrieb:> Write_Instruction((0x10|(add>>4)));
Add wird um 4 Bitpositionen nach rechts geshiftet.
Crazy H. schrieb:> Was bedeutet das | zwischen 0x28 und vol?
0x28 = 0b0010 1000, die ODER-Verknüpfung mit 'vol' setzt in 'vol die
Bits, die in 0x28 eine '1' haben; die anderen Bits von 'vol' bleiben auf
dem alten Wert. Z.B. aus vol=0b1111 0001 wird dann 0b1111 1001.
Crazy H. schrieb:> Was bedeutet add>>4?
Wurde gesagt: schiebt die Bits von 'add' um vier Stellen nach rechts. In
dem Fall wird das obere Nibble zum unteren, das untere verschwindet im
Nirwana.
Also aus 0b1100 0011 wird 0b0000 1100.
Ist mathematisch gesehen eine Ganzzahldivision durch 16 (dezimal).
Martin schrieb im Beitrag #6864300:
> Immerhin habe ich sinnvoll geantwortet und die Bedeutung erklärt.
Ja, das hast du. Ich habe noch Beispiele ergänzt, weil das einem
Anfänger vielleicht noch besser hilft.
Hallo Harry
Crazy H. schrieb:> void Write_Instruction(unsigned char idata cmd)> {> unsigned char idata i;
Für mich sieht dies nicht nach einem guten Beispielcode aus.
Im Funktionskopf werden normalerweise durch Komma getrennte Patrameter
übergeben. Du hast da idata und cmd stehen.
Da idata nicht in Richtung Typ geht, wird dies m.M.n. nicht compilieren.
Desweiteren frage ich mich warum idata im Funktionskopf definiert ist
und dann nochmal als lokale Variable (die evtl. den Übergebenen Wert im
Kopf überschreibt.) angelegt wird, die aber nirgends in der Funktion
benutzt wird.
Ich würde empfehlen wenn du dich mit C beschäftigen willst, nimm keinen
Code von irgend wem als Beispielcode, sondern such dir bitte eine
vernünftige Quelle und versuche den Code dort zu verstehen.
Es gibt leider eine Art von Programmierern, die versucht möglichst
unleserlichen Code zu schreiben, so dass jeder der daraufschaut sofort
verzweifelt und vermeintlich den programmierer bewundert, weil der sowas
komplexes versteht. Dem ist aber nicht immer so. Manchmal entsteht
solcher Code auch aus Unwissenheit/Unfähigkeit heraus.
Wenn du guten Code betrachtest, ist das "halb so schlimm".
Ich bin mir im klaren, mit deiner Frage wolltest du etwas anderes
erreichen aber vlt. findest du einen anderen/besseren Beispielcode für
dein Problem.
Nichts für ungut
Chris Tian
Chris Tian schrieb:> Für mich sieht dies nicht nach einem guten Beispielcode aus.> Im Funktionskopf werden normalerweise durch Komma getrennte Patrameter> übergeben. Du hast da idata und cmd stehen.>> Da idata nicht in Richtung Typ geht, wird dies m.M.n. nicht compilieren.>> Desweiteren frage ich mich warum idata im Funktionskopf definiert ist> und dann nochmal als lokale Variable (die evtl. den Übergebenen Wert im> Kopf überschreibt.) angelegt wird, die aber nirgends in der Funktion> benutzt wird.
idata wird wohl irgendein non-Standard-Attribut des Compilers sein,
vielleicht um anzugeben, in welchem Teil des RAM die Variable liegen
soll oder sowas.
Hallo und Danke an die Erklärbären :-)
Zur Aufklärung, ja ich habe Google bemüht, aber zu der Pipe | nichts
gefunden und nein ich will mich nicht mit C befassen. Das stammt aus
einem Beispielcode für die Initialisierung eines Displays vom
Displayhersteller. Ich habe zwar schon andere Displays mit diesem
Controller (ST7565R) verwendet, aber dieses Mal hat es nicht
funktioniert. Das Wieso versuchte mit dem Beispielcode heraus zu finden.
Und ja, das Display funktioniert inzwischen. Seltsamerweise darf ich
aber den Kontrast nur auf max. 6 stellen (Datenblatt sagt 16 als
Mittelwert), ansonsten ist das Display nur schwarz.
Gruss
Harry
Crazy H. schrieb:> aber zu der Pipe | nichts gefunden
Das wäre allerdings verwunderlich. Andererseits ist es natürlich schwer,
in Suchmaschinen Erklärungen für derartige Zeichen direkt zu finden; man
hätte wohl nach sowas wie "C operators" suchen müssen.
Ist übrigens auch keine Pipe, die gibt's nur in einem ganz anderen
Zusammenhang. ;-)
> und nein ich will mich nicht mit C> befassen
Naja, wenn man sich mit hardwarenaher Programmierung befasst, ist es
zumindest hilfreich, wenn man ein bisschen C lesen kann. Man muss die
Sprache ja deshalb nicht mögen und auch nicht selbst schreiben können.
Weiß nicht, was du sonst machst, aber bspw. Pascal hat meiner Erinnerung
nach gar keine standardisierte Möglichkeit für Bitoperationen. C
unterscheidet halt zwischen bitweisem ODER (|) und logischem ODER (||),
gleichfalls für bitweises UND (&) vs. logisches UND (&&).
Harry schrieb:> meines Wissens wird das Zeichen | Pipe genannt, egal wie es jetzt im> speziellen verwendet wird.
›Vertical bar‹, oder auch ›vertical broken bar‹.
Pipe nennt man es wenn es für 'ne pipe verwendet wird. ;-)
Teo D. schrieb:> War mir auch neu und habs mal gegockelt:> https://www.google.com/search?q=pipe+zeichen
Im Wikipedia-Ergebnis steht dann aber u.a. "In Shells bezeichnet ein
senkrechter Strich eine Pipe." Nur in dem Kontext sollte man den
senkrechten Strich als Pipe bezeichnen.
Genau so gut steht er für das logische ODER in mehreren
Programmiersprachen. Und für viele andere Bedeutungen auch noch.
Allgemein ohne Kontext ist es eben ein senkrechter Strich oder 'vertical
line'.
Chris Tian schrieb:> du hast Recht, ich geb es ungern zu, aber es ist nunmal so ;-)
das idata ist ein memspecifier beim Keil C51 Compiler und hier im
Funktionskopf völlig wirkungslos, da es keine Zeiger var ist.
Der Keil Compiler benutzt für die Parameter Übergabe von bis zu 3
Parametern Register (in diesem Fall R7). Auch das zweite idata ist
grenzwertig würde nur dann einen Effekt zeigen wenn das Modul im large
mode übersezt wird. Lässt man das weg wird die lokale Variable bei
dieser einfachen Funktion vermutlich auch in einem Register gehalten.
Jörg W. schrieb:> Weiß nicht, was du sonst machst, aber bspw. Pascal hat meiner Erinnerung> nach gar keine standardisierte Möglichkeit für Bitoperationen. C> unterscheidet halt zwischen bitweisem ODER (|) und logischem ODER (||),> gleichfalls für bitweises UND (&) vs. logisches UND (&&).
Ähem... Naja, in Pascal hat man den Datentyp 'boolean' und damit sind
sämtliche logischen Operationen möglich.
Daß es in C überhaupt eine Unterscheidung zwischen bitweisem un
logischem Operator gibt, liegt nur daran, daß es in C keinen Datentyp
'boolean' gibt und deswegen so eine Regel zu den Grundfesten von C
gehört, daß 0 eben false und alles andere deshalb eben true ist.
So eine 'ordre de mufti' gibt es in Pascal nicht. Deswegen sind logische
Operationen in Pascal eben IMMER in der Bitbreite der Variablen und
bitweise, also wenn A=$0F ist und B= $F0 ist dann ist A or B eben $FF
und A and B ist da eben 0. Ganz einfach und logisch, alle logischen
Operatoren wie 'and', 'or' usw. sind in Pascal eben immer bitweise und
bei boolean Argumenten kommen eben logische Ergebnisse dabei heraus.
Man braucht keine derartige Unterscheidung wie in C. Für Logik ist
boolean zuständig. Das ist alles.
Naja, schau dir mal den Datentyp 'set' an, da wirst du als C
Programmierer noch ein wenig verdutzter dreinschauen.
W.S.
W.S. schrieb:> Ähem... Naja, in Pascal hat man den Datentyp 'boolean' und damit sind> sämtliche logischen Operationen möglich.
Um die ging es aber eben gerade nicht.
> Daß es in C überhaupt eine Unterscheidung zwischen bitweisem un> logischem Operator gibt, liegt nur daran, daß es in C keinen Datentyp> 'boolean' gibt
Deine C-Unkenntnis musst du uns nicht erneut beweisen.
Einen solchen Datentyp gibt es seit mehr als 20 Jahren in C.
> So eine 'ordre de mufti' gibt es in Pascal nicht. Deswegen sind logische> Operationen in Pascal eben IMMER in der Bitbreite der Variablen und> bitweise, also wenn A=$0F ist und B= $F0 ist dann ist A or B eben $FF> und A and B ist da eben 0.
Wo steht im Pascal-Standard etwas von "Bitbreite" eine
Boolean-Variablen?
Davon abgesehen, $F0 AND $0F sollte halt logisch "true" sein, denn
beide Werte sind nicht "false". Nur bitweise ist es eben $00.
Genau daher die Unterscheidung.
> Naja, schau dir mal den Datentyp 'set' an, da wirst du als C> Programmierer noch ein wenig verdutzter dreinschauen.
Ich habe lange genug Pascal programmiert um zu wissen, dass die
SET-Datentypen so sehr implementierungsabhängig waren, dass man sie in
portablem Code praktisch nicht nutzen konnte.
Jörg W. schrieb:> Deine C-Unkenntnis musst du uns nicht erneut beweisen.>> Einen solchen Datentyp gibt es seit mehr als 20 Jahren in C.
Also Jörg, schreibe nicht so einen albernen Quatsch. Ob es nun ein
Schlüsselwort gibt oder nicht, sagt rein garnix aus darüber, ob es den
Datentyp gibt oder nicht. Du weiß es ja selber, daß es die von mir
genannte Regel bzw. 'ordre de mufti' nur in C gibt. Das Ansehen von
numerischen Werten als Ausdruck eines boolean Zustandes ist rein C
typisch. Und das hat sich mit dem Einführen eines Schlüsselwortes nicht
geändert.
Jörg W. schrieb:> Davon abgesehen, $F0 AND $0F sollte halt logisch "true" sein, denn> beide Werte sind nicht "false". Nur bitweise ist es eben $00.
Nein. Du referierst hier wieder mal über C und das gilt in Pascal eben
nicht, da die o.g. Regel nur in C existiert. Sowas wie $F0 und $0F sind
keine boolean Größen, also sind sie weder true noch false. Sie ergeben
schlichtweg eben einen numerischen Datentyp, weil dieser aus einer
bitweisen Verknüpfung zweier numerischer Daten entsteht.
Dein genereller Denkfehler ist hierbei, daß du das C-typische
Durcheinanderwerfen von verschiedenen Datentypen als Normalität
ansiehst.
Jörg W. schrieb:> Ich habe lange genug Pascal programmiert um zu wissen, dass die> SET-Datentypen...
Wieder ein NÖ von mir. Wie nun die SET-Typen implementiert sind, ist
eigentlich egal. Deine Bedenken kommen wieder mal her aus dem Wunsch,
die Sets auf der Zielhardware in anderem Datentyp verwenden zu wollen.
Das ist eben auch der o.g. Denkfehler.
Und ich glaube dir eben nicht, daß du "lange genug Pascal programmiert"
hast. Zeitlich mag das wohl sein, aber da du mir Unkenntnis in C
andichtest, muß es mal gesagt werden, daß du ganz offensichtlich recht
wenig Erinnerungen hast an Pascal oder andere algolartige Sprachen. Ich
will das ja nicht so kraß ausdrücken wie du gegenüber mir.
W.S.
W.S. schrieb:> Also Jörg, schreibe nicht so einen albernen Quatsch. Ob es nun ein> Schlüsselwort gibt oder nicht, sagt rein garnix aus darüber, ob es den> Datentyp gibt oder nicht.
Es ist halt mehr als ein Schlüsselwort – ob du das nun wahrhaben willst
oder nicht. Es ist ein eigenständiger Datentyp.
> Wieder ein NÖ von mir. Wie nun die SET-Typen implementiert sind, ist> eigentlich egal.
Solange man nicht mehr als deren Grenzen braucht. Wenn die
Implementierung dann halt nur maximal soundsoviele Elemente in einem SET
unterstützt, ist es ganz schnell nicht mehr egal, und man programmiert
dann doch wieder drumrum.
Ob du mir nun glaubst, dass ich lange in Pascal programmiert habe oder
nicht, ist mir ziemlich egal ;-), denn ich weiß, dass ich das mehrere
Jahre lang getan habe.
Jörg W. schrieb:> Es ist halt mehr als ein Schlüsselwort – ob du das nun wahrhaben willst> oder nicht. Es ist ein eigenständiger Datentyp.
Dann müßte die o.g. Regel (0=false, alles andere=true) offiziell
zurückgezogen worden sein. Ist aber nicht. Also: du hast das Ganze
falsch verstanden (um kein härteres Wort für deine falsche Aussage zu
wählen).
W.S.
Jörg W. schrieb:> denn ich weiß, dass ich das mehrere> Jahre lang getan habe.
Schon wieder eine unpassende Aussage deinerseits. Ich hatte das ja
bereits gesagt: "Zeitlich mag das wohl sein..."
Immer wieder diese sachlichen Unexaktheiten. Allerdings ist es für dich
tröstlich, daß andere C-Programmierer genauso sind.
W.S.
W.S. schrieb:> Dann müßte die o.g. Regel (0=false, alles andere=true) offiziell> zurückgezogen worden sein.
Nein, du hast nur keine Ahnung von _Bool (bzw. bool, falls man
<stdbool.h> inkludiert hat). *)
Das kennt lediglich die Werte 0 und 1, eine Variable dieses Typs kann
nur einen dieser beiden Werte annehmen.
*) Das ist auch nicht verwunderlich, da du C nicht groß benutzt, aber
dann stelle doch bitte keine Aussagen dazu auf.
Yalu X. schrieb:> @W.S.:> Du hast den Unterschied zwischen> - Gleichheit zweier Datentypen und> - impliziter Konvertierbarkeit zwischen zwei Datentypen> nicht verstanden.
Klar versteht er das nicht, denn in Pascal gibt's halt keine
Konvertierungen. Nichtmal Arrays unterschiedlicher Länge sind
kompatibel, weswegen man den Datentyp "String" in irgendwelchen
Headerfiles versteckt mit einer festen maximalen Länge definiert hat.
Zu Zeiten, als ich noch aktiv Pascal genutzt habe, hatte ich mir immer
gewünscht, dass in dem Bereich, den wir heute "embedded" nennen, sich
mal Ada durchsetzt, als so eine Art "Pascal, aber aus den
Fehlern/Unterlassungen von Pascal gelernt". Vermutlich wäre uns im
Vergleich zu C einiges an Bugs erspart geblieben und auch so ein Krempel
wie MISRA wäre nicht nötig gewesen.
Hat sich aber nicht durchgesetzt, und nun gibt es ein gut
standardisiertes C und einen de-facto-Pascal-Standard – der offizielle
Pascal-Standard kennt halt gar keine Bitoperationen auf Ganzzahlen,
sondern nur auf Boolean, und wie gerade genannt, auch nur wenige
Typkonvertierungen (Integer <-> Real).
Jörg W. schrieb:> Vermutlich wäre uns im> Vergleich zu C einiges an Bugs erspart geblieben und auch so ein Krempel> wie MISRA wäre nicht nötig gewesen.
Man kann träumen ... aber auch in dieser alternativen Realität würden
viele Menschen nur das absolute Minimum lernen und es würden andere
Fehler gemacht werden.
Ich habe mit Pascal angefangen, und als Lehrsprache ist es gerade wegen
des strikten Typensystems durchaus gut. Aber als ich dann auf C
umgestiegen bin, habe ich der Eingewöhnung Pascal keine Träne mehr
nachgeweint. Das war, als wenn man beim Fahrrad die Stützräder abgelegt
hat.
Jörg W. schrieb:> Nein, du hast nur keine Ahnung von _Bool (bzw. bool, falls man> <stdbool.h> inkludiert hat). *)>> Das kennt lediglich die Werte 0 und 1, eine Variable dieses Typs kann> nur einen dieser beiden Werte annehmen.
Tja, das ist es eben. Wenn man die Worte 'true' und 'false' (jedoch
nicht deren angenommene Bedeutung) auf die auf 0 und 1 engeschränkte
Teilmenge der numerischen Typen abbildet, dann hat man genau dadurch den
Datentyp "boolean" eliminiert und durch einen Teil der numerischen Daten
ersetzt. Alles andere ist lediglich Kosmetik. Begreife das mal.
Im übrigen bin ich kein Freund von Diskussionen, wo als letzter Notanker
mit Antworten wie "Nein, du hast nur keine Ahnung" hantiert wird. Das
ist lediglich kindischer Trotz. Wir bleiben lieber bei sachlichen
Argumenten.
Also noch einmal: Wenn man Festlegungen trifft wie "false ist 0 und
nicht false ist alles andere, so z.B. auch 1", dann hat man damit zwar
ein Mittel geschaffen, um bei den in (wohl fast) jeder
Programmiersprache notwendigen Vergleichen und logischen Verknüpfungen
zurecht zu kommen, aber man hat damit keinen Datentyp 'Boolean'
geschaffen, sondern Vergleichsergebnisse und logische Zustände auf den
numerischen Raum transportiert. Wenn man das also beibehalten will, dann
ist ein eigenständiger Datentyp 'boolean' nicht möglich, sondern als
'boolean' gilt der Teilbereich 0 bis 1 der Integerzahlen. Wenn man
hingegen einen Datentyp 'boolean' schaffen will, dann muß man diese
Zuordnung komplett aufgeben und den Datentyp als etwas Selbständiges
begreifen und nicht wie du argumentieren "Das kennt lediglich die Werte
0 und 1". Das wäre nämlich nichts anderes als die in C übliche Weise,
die Zustände als numerische Werte anzusehen.
Aber man ist von C ja noch ganz andere Korken gewöhnt, z.B. daß ein char
ebenfalls auf den numerischen Wert seiner ASCII-Darstellung (oder ANSI,
sofern nur 8 bittig) abgebildet wird und man deshalb Textzeichen lustig
mit Zahlen mischen darf.
Bleib sachlich, mein Lieber. Und überlege gelegentlich, was logisch ist
und was lediglich eine Festlegung (bzw. ein 'ordre de mufti') ist. Ich
bin der Ansicht, daß man das auseinander halten können sollte, um die
Orientierung nicht zu verlieren.
W.S.
Nop schrieb:> Yalu X. schrieb:>> @W.S.:>> Du hast den Unterschied zwischen>> - Gleichheit zweier Datentypen und>> - impliziter Konvertierbarkeit zwischen zwei Datentypen>> nicht verstanden.>> Klar versteht er das nicht, denn in Pascal gibt's halt keine> Konvertierungen. Nichtmal Arrays unterschiedlicher Länge sind> kompatibel, weswegen man den Datentyp "String" in irgendwelchen> Headerfiles versteckt mit einer festen maximalen Länge definiert hat.
Ihr beide seht das Ganze in einem sehr schrägen Licht, um das mal so zu
sagen.
Also:
Eine Gleichheit zweier Datentypen gibt es nicht, der Volksmund sagt
kurzerhand dazu: Äpfel mit Birnen zu vergleichen.
Wenn Gleichheit, dann derselbe Datentyp, aber nicht zwei Gleiche.
Eine implizierte Konvertierbarkeit gibt es nur in Ausahmefällen, wo der
sich ergebende Typ in der Lage ist, den zu konvertierenden Typ
vollständig aufzunehmen, wo also mathematisch gesehen der zu
konvertierende Typ eine Untermenge des Zieltyps darstellt. So ist z.B.
ein Integer implizit in einen Float konvertierbar, umgekehrt jedoch
nicht. Und einen Char kann man nicht implizit in eine Zahl konvertieren,
dazu ist eine explizite Konvertierung nötig, wie z.B. ord(MeinChar) -
und diese Konvertierung darf dann nach eigenen Regeln arbeiten (z.B.
nach ASCII oder nach EBCDIC oder nach etwas anderem).
Und solche Sprüche wie "in Pascal gibt's halt keine Konvertierungen"
zeugen nur von einem tiefsitzenden Unverständnis. Und Headerfiles gibt
es in Pascal ebenfalls nicht.
Leute! Mein Rat an euch beide wäre: Schaut aus eurer Furche mal heraus
und glaubt nicht, daß die Regeln von C überall gelten.
Kopfschüttel.
W.S.
W.S. schrieb:> Wenn man die Worte 'true' und 'false' (jedoch nicht deren angenommene> Bedeutung) auf die auf 0 und 1 engeschränkte Teilmenge der numerischen> Typen abbildet, dann hat man genau dadurch den Datentyp "boolean"> eliminiert und durch einen Teil der numerischen Daten ersetzt.
Auch Pascal kann doch an dieser Stelle nur mit Wasser kochen, was
anderes als 0 und 1 haben sie auch nicht zur Verfügung. Ob nun das
Fehlen einer (impliziten) Typkonvertierung zwischen integer und boolean
ein Vor- oder ein Nachteil ist, mag dann mal jeder für sich selbst
entscheiden.
Aber lassen wir das, bringt eh nichts, und dem TE erst recht nicht. Wir
wissen nicht einmal, in welcher Sprache er "normalerweise" hantiert.
W.S. schrieb:> Und Headerfiles gibt es in Pascal ebenfalls nicht.
Das Äquivalent dazu gibt es sehr wohl, nur habe ich nach 30 Jahren mal
vergessen, wie es noch gleich heißt. Das Kernargument mit der festen
Stringlänge aufgrund des starren Typsystems gilt nach wie vor. Übrigens
gilt das auch für andere Listen mit variabler Länge, sofern man nicht
auf verkettete Listen mit unterirdischer Performance ausweicht.
Jörg W. schrieb:> Auch Pascal kann doch an dieser Stelle nur mit Wasser kochen,
Ja. Das kann keiner. Aber wir haben hier nicht über die eine oder andere
reale Implemetierung diskutiert, sondern über die Sprachdefinitionen und
über Logik versus Daiktatorik (aka 'ordre de mufti').
Wobei man sich an die Diktatorik auch gewöhnen kann, wie ich hier in
diesem Forum allzu oft sehen kann. Die Kehrseite davon ist, daß man sich
dabei das logische Denken abgewöhnt - und auch das sieht man hier allzu
oft, wo Leute nicht weiter kommen in ihren Vorhaben, weil sie erstmal
drauflos schreiben anstelle des vorherigen Durchdenkens. Und dann wird
hier geklagt, daß etwas nicht funktioniert.
Und ob sowas wie "implizite Typkonvertierung" nun als gut oder schlecht
angesehen werden, ist ne Ansichtssache. Wenn einer seine Tastendrücke
zählt und über jeden Tastendruck weint, den er bei anderer
Sprachgestaltung hätte einsparen können, dann ist das ne andere Ansicht
als die eines Lesers, der einen Fehler im Quellcode eines Anderen suchen
muß.
Ich denke mal, daß jedem Leser jetzt die Angelegenheit klar geworden ist
- sofern selbiger gewillt ist, die Beiträge verstehend zu lesen.
Aber dem TO scheinen noch viel weiter "unten" angesiedelte Dinge auf das
'verstanden werden' zu warten. Das sehe ich auch so wie du. Also Diskurs
beendet.
W.S.
W.S. schrieb:> sondern über die Sprachdefinitionen und> über Logik versus Daiktatorik
Wir nicht, du.
Es ist eingentlich ganz einfach: Wer in irgend einer Programmiersprache
progammieren will, muß die a) kennen und b) mit der zurechtkommen, wie
sie ist, oder c) es einfach lassen. Wer das Diktatorik nennt, hat auch
genrell Probleme mit dem realen Leben.
C besteht unbestritten aus einem Haufen historisch gewachsener
Unzumutbarkeiten. Der Nachfolger D, der alles viel besser machen wollte
((?), hat sich aber irgendwie nicht durchgesetzt. So ist das halt.
Oliver
Wer ruft mich hier eigentlich dauernd? Ich habe keine Anweisungen
gegeben! Also beschwert euch nicht.
Und wer ist überhaupt dieser Pascal?
Der Mufti
P.S: Korrektes Französisch wäre "par ordre d*u* mufti"
Nop schrieb:> Das Äquivalent dazu gibt es sehr wohl,...
Nö. Das gibt es nach wie vor nicht.
Allerdings ahne ich, woran du dich schwach erinnerst: an das Modulsystem
des heutigen Pascals. Da wird strikt unterschieden, was von einem Modul
den anderen Moduln bekannt gegeben werden soll und was nicht. Stichworte
'interface', 'implementation' und 'uses'.
Das ist ne ganz andere Nummer als die Headerfiles in C.
Und bei deiner Bemerkung über die Stringlänge sehe ich auch nur einen
Stand von vor 30..40 Jahren. Aus meiner Praxis sehe ich Stringlängen im
MB Bereich und mit 8 oder 16 Bit breiten Zeichen, wenngleich es den
kurzen String mit bis zu 255 Zeichen zu je 8 Bit noch immer gibt.
Kurzum: Du referierst über einen Stand der Dinge, der mehr als 30 Jahre
zurückliegt und dir nur noch schwach erinnerlich ist. OK, dann sollte
ich bei dir mich auch auf die originale Notation nach K&R beziehen, die
ist so etwa gleichaltrig.
W.S.
W.S. schrieb:> Und bei deiner Bemerkung über die Stringlänge sehe ich auch nur einen> Stand von vor 30..40 Jahren.
Das war und ist nunmal ISO-Pascal, und die Typdefinition von String war
ein Array fester Länge, versteckt irgendwo im Äquivalent eines
Headerfiles. Die Wurzel des Übels war und ist das Typensystem, das
Arrays desselben Typs, aber unterschiedlicher Länge als verschiedene
Typen behandelt.
Damit kann man auch keine z.B. Sortieralgorithmen schreiben, bei denen
die Arraylänge als Parameter übergeben wird.
Daß jeder Pascal-Compiler dann sein eigenes, zu nichts kompatibles
Süppchen gekocht hat, weil ISO-Pascal eine unbrauchbare Spielzeugsprache
standardisiert hat, macht es nicht besser, sondern diese Balkanisierung
war ein wesentlicher Grund für den Niedergang von Pascal.
W.S. schrieb:> ich bei dir mich auch auf die originale Notation nach K&R beziehen, die> ist so etwa gleichaltrig.
Der Unterschied: bei C gab es seitdem weitere ISO-Standards wie C99 und
C11.
W.S. schrieb:> Tja, das ist es eben. Wenn man die Worte 'true' und 'false' (jedoch> nicht deren angenommene Bedeutung) auf die auf 0 und 1 engeschränkte> Teilmenge der numerischen Typen abbildet
Was ist daran böse, die beiden Elemente einer zweielementigen booleschen
Algebra mit 0 und 1 zu bezeichnen? Das ist in der Mathematik gängige
Praxis:
https://de.wikipedia.org/wiki/Boolesche_Algebra#Zweielementige_boolesche_Algebrahttps://en.wikipedia.org/wiki/Boolean_algebra#The_prototypical_Boolean_algebraW.S. schrieb:> Eine Gleichheit zweier Datentypen gibt es nicht, der Volksmund sagt> kurzerhand dazu: Äpfel mit Birnen zu vergleichen.> Wenn Gleichheit, dann derselbe Datentyp, aber nicht zwei Gleiche.
Dann ersetze halt in meiner Aussage "Gleichheit" durch "Selbigkeit". Das
ändert aber nichts an ihrem Inhalt.
W.S. schrieb:> Eine implizierte Konvertierbarkeit gibt es nur in Ausahmefällen,
In Wirths Pascal gab es überhaupt keine impliziten Konvertierungen. Die
Sprache war zwar für die Praxis unbrauchbar, aber wenigstens konsequent
in ihren Prinzipien. Die reine Lehre (auch in vielen anderen Aspekten)
wurde aber spätestens mit dem Erscheinen von Turbo Pascal mehr und mehr
verwässert. Ich persönlich finde das nicht schlimm, aber im Sinne Wirths
ist das ganz sicher nicht.
> wo der sich ergebende Typ in der Lage ist, den zu konvertierenden Typ> vollständig aufzunehmen, wo also mathematisch gesehen der zu> konvertierende Typ eine Untermenge des Zieltyps darstellt.
Schönes Beispiel hierzu:
1
var
2
i16: int16;
3
i32: int32;
4
5
begin
6
i32 := 1000000;
7
i16 := i32;
8
writeln(i16) // -> 16960
9
end.
FPC meldet hier keinen Fehler, nicht einmal eine Warnung. Das Verhalten
ist hier also genau wie in C. Überhaupt scheint Pascal immer mehr wie C
sein zu wollen. Man beachte bspw. das Symbol für den Zeilenkommentar im
obigen Beispiel, das der FPC anstandslos schluckt :)
W.S. schrieb:> Im übrigen bin ich kein Freund von Diskussionen, wo als letzter Notanker> mit Antworten wie "Nein, du hast nur keine Ahnung" hantiert wird.
Viel besser ist es als Beweis einen ominösen Sozobon-Compiler aus dem
Hut zu zaubern bei dem alles anders ist, bestimmt auch bei der
Initialiserung von globalen und statischen Variablen.
Das passt in die Reihe von 'Auswertungsreihenfolge ist Compilersache'.
Im Gegensatz dazu erfolgt bei bool wenigstens eine sinnvolle
Typkonvertierung: wenn ich einer bool-Variablen eine 42 zuweisen will,
hat sie hernach den Wert 1. ;-)
Allerdings ersetzen natürlich alle Programmiersprachen nicht das Gehirn
des Programmierers …
[Edit: bezog sich auf Yalus Beispiel]
Yalu X. schrieb:> Was ist daran böse, die beiden Elemente einer zweielementigen booleschen> Algebra mit 0 und 1 zu bezeichnen?
Irgendwie klingt bei dir alles gleich: char ist ein numerischer Typ, int
sowieso, boolean ebenso. Bloß eben alles mit unterschiedlicher Anzahl
von Bits. Und bezeichnen kannst du das im Prinzip mit Worten deiner Wahl
(Ottokar und Emil zum Beispiel) - Hauptsache die anderen verstehen dich.
Aber auf den eigentlichen Umstand, daß ein Boolean kein Rechenwert ist,
hast du nicht geachtet.
DoppeltWahr = true + true;
NieNimmer = false - false;
Oder wie?
W.S.
Jörg W. schrieb:> Im Gegensatz dazu erfolgt bei bool wenigstens eine sinnvolle> Typkonvertierung: wenn ich einer bool-Variablen eine 42 zuweisen will,> hat sie hernach den Wert 1. ;-)
Grrmpf...
1
MyBool=42;
So etwa? Das ist (auch bei deinem Smiley) doch eher Unsinn, den so
offensichtlich keiner schreibt. Hältst du das für einen Fall für eine
Typkonvertierung? Allerdings sehe ich die Variante, daß jemand so etwas
schreibt:
1
MyBool=NeVariable;
und damit meint:
1
MyBool=NeVariable!=0;
Naja, das hängt eben alles an der C-eigenen Definition von Boolean.
W.S.
W.S. schrieb:> Allerdings sehe ich die Variante, daß jemand so etwas> schreibt:>> MyBool = NeVariable;>> und damit meint:>> MyBool = NeVariable != 0;>> Naja, das hängt eben alles an der C-eigenen Definition von Boolean.
Da geschieht genau dasselbe wie wenn du in Pascal schreibst
1
MyBool := boolean(NeVariable);
0 wird zu false konvertiert, alle anderen Zahlen zu true. Der einzige
Unterschied besteht darin, dass in C die Konvertierung implizit, in
Pascal explizit stattfindet.
W.S. schrieb:> DoppeltWahr = true + true;
Hier werden die beiden trues implizit zu 1 konvertiert, die Summe ist
also 2. Man wird so etwas zwar selten schreiben, aber die Auswertung in
dieser Weise ist nur konsequent.
Sind b1, b2 und b3 vom Typ bool, dann bildet
1
b3=b1+b2;
die Oder-Verknüpfung und
1
b3=b1*b2;
die Und-Verknüpfung. Auch die Verwendung von + und * als boolesche
Operatoren ist in der Mathematik gängige Praxis. Aber auch das wird man
in der C nicht so schreiben, da es dort die speziell dafür vorgesehenen
Operatoren && und || gibt, die zusätzlich noch die Kurzschlussauswertung
und die definiert Auswertereihenfolge beinhalten (sofern man diesen
Eigenschaften vertraut ;-)).
W.S. schrieb:> Allerdings sehe ich die Variante, daß jemand so etwas schreibt:> MyBool = NeVariable;> und damit meint:> MyBool = NeVariable != 0;
Sofern MyBool vom Typ bool ist, ist das äquivalent.
> Naja, das hängt eben alles an der C-eigenen Definition von Boolean.
Nein, das hängt daran, dass in C die Konvertierung implizit ist.
Thread beobachten
Seitenaufteilung abschalten