Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
mir ist gerade eben aufgefallen, das bei einer Impliziten Typkonvertierung von gleich großen Variablen von Codesys keine Warnung ausgegeben wird
Bsp.:
test_uint:=test_int;
Mir ist jetzt schleierhaft, wieso in diesen Fällen keine Warnung ausgegeben wird. Meinem Verständnis nach müsste der Compiler sogar einen Fehler melden, wenn man versucht, eine INT-Variable ( -32768 -- 32767) UINT-Variable (0 -- 65535) auf eine zu schreiben.
Wenn ich das Beispiel mit test_int := -32000 durchspiele, hat test_uint nachher einen Wert von 33536!
Muss man eine solche Prüfung erst einschalten oder ist solch eine Gefährliche Funktion erwünscht?
Sowas kann zu den "lustigsten" Fehlern innerhalb eines Programmes führen.
MFG
Benjamin
verwendet wird XSoft von Möller in Version 2.3.3.14.[/i]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aber solch ein Fehler muss der Kompiler meiner Meinung nach Abdecken.
Für mich ist das nämlich überhaupt kein "Anfängerfehler"!
Wenn ich mich ständig mit der Systembedingten Mängeln rumärgern wollte würde ich in C programmieren... aber das nur am Rande
Wie sieht es aus, wenn du nach 5 Jahren ein Projekt überarbeitest oder du ein Projekt von einem andere weiterführst.
Ich persönlich verwende nie unsigned Variablen, sondern greife einfach auf DINT zurück. Kollegen und viele andere sehen das anders...
Wie schon erwähnt ich finde es wichtig, dass der Kompiler solche offensichtlichen Fehler anmeckert. Wenn man weiß was man tut, kann mann ja immer noch die explizite Konvertierung verwenden.
MFG
Benjamin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jo das mit der Aussentemperatur kommt mir sehr bekannt vor. Weiß einer den unterschied zwischen word und uint ? wenn man int meint und auf ne word variable schreibt, dann unterstellt der compiler dem wert auch, dass er wohl nen word ist. Ich benutz für festpunktzahlen immer nur int und word, das ist wenigstens optisch ein wenig verschiedener...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gumpi hat geschrieben:
Jo das mit der Aussentemperatur kommt mir sehr bekannt vor. Weiß einer den unterschied zwischen word und uint ? wenn man int meint und auf ne word variable schreibt, dann unterstellt der compiler dem wert auch, dass er wohl nen word ist. Ich benutz für festpunktzahlen immer nur int und word, das ist wenigstens optisch ein wenig verschiedener...
servus,
habe grad noch mal nachgeschaut:
datentypen wie WORD, sind für Bitfolgen gedacht und sollen (!) z.B. mit "16#FFFF" initialisiert werden. INT (etc.) sind für ganze zahlen gedacht (wer hätte das gedacht!).
aber keine ahnung wo nu der "sinnvolle" oder nützliche teil dieser unterscheidung im praktischen sein soll...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sowohl die Tabelle als auch die Art der Variablenbeschreibung (ungarische Notation) sind mir bekannt.
Das erklärt allerdings immer noch nicht, wieso die impliziten Typzuweisungen nicht als Fehler oder Warnung angemerkt werden, wie man es von einem Kompiler erwarten kann.
Es wäre nett, wenn sich jemand von 3S auch zu diesem Thema melden könnte. Auch wenn es unter Umständen nicht von der Norm vorgeschrieben ist, so wäre eine solche Implementation für die allermeisten Anwender sehr hilfreich.
MFG
Benjamin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-07-19
Originally created by: Bernhard Werner
Hallo Benjamin,
hier ist jemand von 3S, und ich gebe Ihnen im Prinzip recht. Es wäre kein Problem hier eine Warnung oder einen Fehler auszugeben.
Wir wollen aber nicht, und das aus zwei Gründen:
In der Norm sind implizite Konvertierungen überhaupt nicht vorgesehen. Also jede Zuweisung von INT -> DINT müsste eigentlich explizit konvertiert werden. Das ist natürlich lästig, daher haben wir uns überlegt, welche impliziten Konvertierungen man denn zulassen sollte.
Als Vorlage haben wir uns an C gehalten, dass sehr viele implizite Konvertierungen erlaubt, insbesondere ist dort die Zuweisung von unsigned auf signed und umgekehrt bei gleich grossen Datentypen anstandslos möglich.
Wir können so ein grundlegendes Verhalten kaum noch ändern. Unsere Kunden akzeptieren in der Regel nicht, dass ein laufendes Programm bei upgrade auf eine neue Version neue Meldungen beim Übersetzen liefert.
Bernhard Werner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In der Norm sind implizite Typkonvertierungen also nicht vorgesehen. Zu recht, denn diese Konvertierungen sind sehr gefährlich und sollten unbedingt vermieden werden. In C kämpft man ständig damit, das der Compiler unsinnige Zuweisungen nicht anmerkt und kommentarlos akzeptiert.
Man könnte sogar soweit gehen und sagen, dass die Norm eine implizite Typkonvertierung ! Wie du ja selbst sagst:>Zitat:
INT -> DINT müsste eigentlich explizit konvertiert
Wieso geht 3S also hin und baut wieder alle Vernunft eine solche "Funktion" in seine Software? Ich kann das einfach nicht verstehen.
Zitat:
Wir können so ein grundlegendes Verhalten kaum noch ändern.
Wieso kann man an diesem Verhalten nichts mehr ändern? Wenn man eine große Dummheit begangen hat, muss man schließlich in de sauren Apfel beißen und die Konsequenzen tragen.
Für den Anfang würde es ja auch reichen einen Kompatibilitätsmodus einzuführen. Hilfreich wäre auch wenn ein solcher Fehler zumindest als Warnung angezeigt wird (In neueren C-Compilern (Keil, GCC) die ich kenne wird einen implizite Konvertierung schließlich auch als Warnung angezeigt).
Gruß
Benjamin
Wieso C jetzt nicht unbedingt als Referenz dient nur dieses
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-07-20
Originally created by: Bernhard Werner
Hallo Benjamin,
Zur Norm: die Norm sagt nicht explizit, ob implizite Upcasts erlaubt sind
oder nicht. Es wird nichts über implizite casts gesagt, daher kann man der
Meinung sein, es gäbe sie nicht.
Benjamin hat geschrieben:
Wieso geht 3S also hin und baut wieder alle Vernunft eine solche "Funktion" in seine Software? Ich kann das einfach nicht verstehen.
Viele Leute begrüßen diese Funktionalität. Es kann bei Upcasts ja auch
nichts schlimmes passieren. Warum soll es dann nicht einfach gehen?
Grenzfälle sind die von dir angesprochenen signed nach unsigned
und umgekehrt. Und ein Grenzfall ist auch DINT nach REAL. Alle anderen
impliziten casts, die wir erlauben, sehe ich als unkritisch.
Im Grunde genommen gehören diese casts zu einer Reihe von anderen
Problemen über die wir auch schon viele Diskussionen hatten:
- Überläufe und Unterläufe ?
- Ungültige Pointer
- Arrayzugriffe ausserhalb des Bereichs
etc.
Wir entschärfen das Problem in unserem eigenen (C++/C#)-Code dadurch, dass wir jeder Variable ein Typkürzel vorsetzen:
iTemp := wTemp;
fällt dann auf.
Benjamin hat geschrieben:
Wieso kann man an diesem Verhalten nichts mehr ändern? Wenn man eine große Dummheit begangen hat, muss man schließlich in de sauren Apfel beißen und die Konsequenzen tragen.
Naja zunächst mal müssten wir uns darüber einig sein, dass das eine grosse Dummheit ist. Und zum zweiten können wir kein Update von
CoDeSys machen, dass beim Kunden neue Fehlermeldungen oder eine
grosse Anzahl von Warnungen zur Folge hat.
Das wird einfach nicht akzeptiert. Auch eine Warnung hilft nicht viel, weil viele die Vorschrift haben, dass keine Warnungen im Programm sein
dürfen.
Für die Version 3.0 und höher können wir nochmal über den Punkt reden.
Ich verstehe deinen Standpunkt, da spricht auch vieles dafür. Aber du musst auch sehen, dass andere (~1 Mrd C-Programmierer) diesen Punkt
anders sehen.
Bernhard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich glaube damit haben wir beide unsere Standpunkte dargelegt und können diese Diskussion abschließen.
Ich hoffe wirklich darauf, dass die kommende Version zumindest eine Warnung herausgibt ("downcast" sollten aber auf jeden Fall angemerkt werden).
Einen kleinen Seitenhieb kann ich mir aber nicht verkneifen.
Zitat:
~1 Mrd C-Programmierer
Gehen wir von einer geschätzten Weltbevölkerung von 6,4Mrd aus (Quelle: Wikipedia, Artikel über Erde). Ich kann mir zwar vorstellen, dass in einer Softwarefirma im Allgäu eine überproportional hohe Dichte an Programmieren herrscht, dass man dadurch aber meint 15% aller Menschen der Erde könnten programmieren....Weiß nicht, ob ich das so unterschreiben würde.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-07-21
Originally created by: Bernhard Werner
Ok, war eine grobe Schätzung.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo Zusammen,
mir ist gerade eben aufgefallen, das bei einer Impliziten Typkonvertierung von gleich großen Variablen von Codesys keine Warnung ausgegeben wird
Bsp.:
Mir ist jetzt schleierhaft, wieso in diesen Fällen keine Warnung ausgegeben wird. Meinem Verständnis nach müsste der Compiler sogar einen Fehler melden, wenn man versucht, eine INT-Variable ( -32768 -- 32767) UINT-Variable (0 -- 65535) auf eine zu schreiben.
Wenn ich das Beispiel mit test_int := -32000 durchspiele, hat test_uint nachher einen Wert von 33536!
Muss man eine solche Prüfung erst einschalten oder ist solch eine Gefährliche Funktion erwünscht?
Sowas kann zu den "lustigsten" Fehlern innerhalb eines Programmes führen.
MFG
Benjamin
verwendet wird XSoft von Möller in Version 2.3.3.14.[/i]
Dieses tolle Phänomen habe ich auch schon festgestellt... und dann auch noch bei Temperaturen grummel
Anstatt Minuswerte hatte ich dann plötzlich 32650°C Aussentemperatur... Anfängerfehler...
Der Compiler meldet aber keinen Fehler, weil er davon ausgeht, dass du weißt welchen Wertbereich die Variablentypen haben.
Aber solch ein Fehler muss der Kompiler meiner Meinung nach Abdecken.
Für mich ist das nämlich überhaupt kein "Anfängerfehler"!
Wenn ich mich ständig mit der Systembedingten Mängeln rumärgern wollte würde ich in C programmieren... aber das nur am Rande
Wie sieht es aus, wenn du nach 5 Jahren ein Projekt überarbeitest oder du ein Projekt von einem andere weiterführst.
Ich persönlich verwende nie unsigned Variablen, sondern greife einfach auf DINT zurück. Kollegen und viele andere sehen das anders...
Wie schon erwähnt ich finde es wichtig, dass der Kompiler solche offensichtlichen Fehler anmeckert. Wenn man weiß was man tut, kann mann ja immer noch die explizite Konvertierung verwenden.
MFG
Benjamin
Jo das mit der Aussentemperatur kommt mir sehr bekannt vor. Weiß einer den unterschied zwischen word und uint ? wenn man int meint und auf ne word variable schreibt, dann unterstellt der compiler dem wert auch, dass er wohl nen word ist. Ich benutz für festpunktzahlen immer nur int und word, das ist wenigstens optisch ein wenig verschiedener...
servus,
habe grad noch mal nachgeschaut:
datentypen wie WORD, sind für Bitfolgen gedacht und sollen (!) z.B. mit "16#FFFF" initialisiert werden. INT (etc.) sind für ganze zahlen gedacht (wer hätte das gedacht!).
aber keine ahnung wo nu der "sinnvolle" oder nützliche teil dieser unterscheidung im praktischen sein soll...
beim nachlesen noch über folgendes gestolpert:
http://www.3s-software.com/se_data/_filebank/home/caatws/ergebnisse/Regelkatalog.pdf
=> siehe Tabelle 3.2 - Variablennamen
Sowohl die Tabelle als auch die Art der Variablenbeschreibung (ungarische Notation) sind mir bekannt.
Das erklärt allerdings immer noch nicht, wieso die impliziten Typzuweisungen nicht als Fehler oder Warnung angemerkt werden, wie man es von einem Kompiler erwarten kann.
Es wäre nett, wenn sich jemand von 3S auch zu diesem Thema melden könnte. Auch wenn es unter Umständen nicht von der Norm vorgeschrieben ist, so wäre eine solche Implementation für die allermeisten Anwender sehr hilfreich.
MFG
Benjamin
Originally created by: Bernhard Werner
Hallo Benjamin,
hier ist jemand von 3S, und ich gebe Ihnen im Prinzip recht. Es wäre kein Problem hier eine Warnung oder einen Fehler auszugeben.
Wir wollen aber nicht, und das aus zwei Gründen:
Als Vorlage haben wir uns an C gehalten, dass sehr viele implizite Konvertierungen erlaubt, insbesondere ist dort die Zuweisung von unsigned auf signed und umgekehrt bei gleich grossen Datentypen anstandslos möglich.
Bernhard Werner
Nur damit ich das richtig verstehe.
In der Norm sind implizite Typkonvertierungen also nicht vorgesehen. Zu recht, denn diese Konvertierungen sind sehr gefährlich und sollten unbedingt vermieden werden. In C kämpft man ständig damit, das der Compiler unsinnige Zuweisungen nicht anmerkt und kommentarlos akzeptiert.
Man könnte sogar soweit gehen und sagen, dass die Norm eine implizite Typkonvertierung ! Wie du ja selbst sagst:>Zitat:
INT -> DINT müsste eigentlich explizit konvertiert
Wieso geht 3S also hin und baut wieder alle Vernunft eine solche "Funktion" in seine Software? Ich kann das einfach nicht verstehen.
Für den Anfang würde es ja auch reichen einen Kompatibilitätsmodus einzuführen. Hilfreich wäre auch wenn ein solcher Fehler zumindest als Warnung angezeigt wird (In neueren C-Compilern (Keil, GCC) die ich kenne wird einen implizite Konvertierung schließlich auch als Warnung angezeigt).
Gruß
Benjamin
Wieso C jetzt nicht unbedingt als Referenz dient nur dieses
Originally created by: Bernhard Werner
Hallo Benjamin,
Zur Norm: die Norm sagt nicht explizit, ob implizite Upcasts erlaubt sind
oder nicht. Es wird nichts über implizite casts gesagt, daher kann man der
Meinung sein, es gäbe sie nicht.
Viele Leute begrüßen diese Funktionalität. Es kann bei Upcasts ja auch
nichts schlimmes passieren. Warum soll es dann nicht einfach gehen?
Grenzfälle sind die von dir angesprochenen signed nach unsigned
und umgekehrt. Und ein Grenzfall ist auch DINT nach REAL. Alle anderen
impliziten casts, die wir erlauben, sehe ich als unkritisch.
Im Grunde genommen gehören diese casts zu einer Reihe von anderen
Problemen über die wir auch schon viele Diskussionen hatten:
- Überläufe und Unterläufe ?
- Ungültige Pointer
- Arrayzugriffe ausserhalb des Bereichs
etc.
Wir entschärfen das Problem in unserem eigenen (C++/C#)-Code dadurch, dass wir jeder Variable ein Typkürzel vorsetzen:
iTemp := wTemp;
fällt dann auf.
Naja zunächst mal müssten wir uns darüber einig sein, dass das eine grosse Dummheit ist. Und zum zweiten können wir kein Update von
CoDeSys machen, dass beim Kunden neue Fehlermeldungen oder eine
grosse Anzahl von Warnungen zur Folge hat.
Das wird einfach nicht akzeptiert. Auch eine Warnung hilft nicht viel, weil viele die Vorschrift haben, dass keine Warnungen im Programm sein
dürfen.
Für die Version 3.0 und höher können wir nochmal über den Punkt reden.
Ich verstehe deinen Standpunkt, da spricht auch vieles dafür. Aber du musst auch sehen, dass andere (~1 Mrd C-Programmierer) diesen Punkt
anders sehen.
Bernhard
Ich glaube damit haben wir beide unsere Standpunkte dargelegt und können diese Diskussion abschließen.
Ich hoffe wirklich darauf, dass die kommende Version zumindest eine Warnung herausgibt ("downcast" sollten aber auf jeden Fall angemerkt werden).
Einen kleinen Seitenhieb kann ich mir aber nicht verkneifen.
Gehen wir von einer geschätzten Weltbevölkerung von 6,4Mrd aus (Quelle: Wikipedia, Artikel über Erde). Ich kann mir zwar vorstellen, dass in einer Softwarefirma im Allgäu eine überproportional hohe Dichte an Programmieren herrscht, dass man dadurch aber meint 15% aller Menschen der Erde könnten programmieren....Weiß nicht, ob ich das so unterschreiben würde.
Originally created by: Bernhard Werner
Ok, war eine grobe Schätzung.