Wie kann man „Skalare Parameter“ definieren? Ich meine hier nicht den mathematischen Begriff, sondern in Programmiersprachen.
steffi
Wie kann man „Skalare Parameter“ definieren? Ich meine hier nicht den mathematischen Begriff, sondern in Programmiersprachen.
steffi
Hallo.
Das scheint von der Programmiersprache abzuhängen: http://www.google.de/search?hl=de&q=%22Skalare+Param…
-> http://www3.informatik.uni-erlangen.de/Staff/knbucha…
HTH
mfg M.L.
das meine ich nicht. Ich kann mit dem Wort „skalar“ nichts anfangen. Sind das nicht veränderbare Parameter also wie Konstanten??
Das scheint von der Programmiersprache abzuhängen:
http://www.google.de/search?hl=de&q=%22Skalare+Param…
->
http://www3.informatik.uni-erlangen.de/Staff/knbucha…HTH
mfg M.L.
Hallo,
das meine ich nicht. Ich kann mit dem Wort „skalar“ nichts
anfangen. Sind das nicht veränderbare Parameter also wie
Konstanten??
Skalare Datentypen werden auch „einfache Datentypen“ genannt. Welche dort dazugehören ist abhängig von der Programmiersprache, jedoch gehören normalerweise Ganzzahlen, Strings, Fließkommazahlen und boolsche Werte dazu.
In Java z.B. sind solche Datentypen keine Objekte, im Gegensatz zu komplexen Datentypen.
Ein Skalarer Parameter einer Funktion ist also z.B. eine Integer-Variable.
mfg
deconstruct
Wie kann man „Skalare Parameter“ definieren? Ich meine hier
nicht den mathematischen Begriff, sondern in
Programmiersprachen.steffi
Hallo Steffi,
Im Prinzip kann das jeder Erfinder einer Sprache handhaben wie er will, i.A. sind aber Typen gemeint, die als Parameter direkt übergeben werden (z.B. word als 2 Byte, integer als 4 Byte) und nicht indirekt über einen Zeiger. Ab welcher Grösse oder Komplexität Zeiger verwendet werden, ist unterschiedlich, solange der Compiler die Details verbirgt, kann einem das auch weitgehend egal sein.
Bei alten Sprachen ist es aber oft so, dass eine Funktion nur skalare Typen als Ergebnis haben kann; zwingend ist das allerdings nicht, in Delphi kann eine Funktion string als Ergebnis haben, in altem, striktem Pascal nicht. Wie der Compiler das dann regelt ist seine Sache. So gesehen hat die Einteilung in skalare und nichtskalare Typen keine grosse Bedeutung mehr.
Gruss Reinhard
Hallo,
Compiler das dann regelt ist seine Sache. So gesehen hat die
Einteilung in skalare und nichtskalare Typen keine grosse
Bedeutung mehr.
Das würd ich nicht sagen. In objektorientierten Sprachen sind skalare Typen normal keine Objekte und bilden damit eine Ausnahme von den „normalen“ Datentypen. Aber gerade wenn es auf Performance ankommt, verwendet man eigentlich immer zum Rechnen skalare Typen. Wenn man z.B. das Traveling Salesman Problem in Java einmal mit int und int[]-Arrays implementiert und einmal mit Objekten die den Graphen viel schöner umsetzen können, dann dürfte ersteres um ein vielfaches schneller sein, wobei zweiteres übersichtlicher und schöner zum Umsetzen ist. Je nachdem was man will, können also skalare Typen auch heute noch eine große Bedeutung haben.
mfg
deconstruct
danke!! o.T:
…
Hallo,
Das würd ich nicht sagen. In objektorientierten Sprachen sind
skalare Typen normal keine Objekte und bilden damit eine
Ausnahme von den „normalen“ Datentypen. Aber gerade wenn es
auf Performance ankommt, verwendet man eigentlich immer zum
Rechnen skalare Typen. Wenn man z.B. das Traveling Salesman
Problem in Java einmal mit int und int[]-Arrays implementiert
und einmal mit Objekten die den Graphen viel schöner umsetzen
können, dann dürfte ersteres um ein vielfaches schneller sein,
wobei zweiteres übersichtlicher und schöner zum Umsetzen ist.
Je nachdem was man will, können also skalare Typen auch heute
noch eine große Bedeutung haben.mfg
deconstruct
Hallo,
soweit es um Objekte geht, hast du sicher recht, auch wenn du dir damit unter den Verfechtern von OO keine Freunde schaffst. Ich fand es auch Overkill, dass in den ersten strengen OO-Sprachen der Typ boolean (1bit) nur als Objekt implementiert war (mir fällt nicht einmal mehr der Name der Sprache ein, obwohl ich einiges Geld dafür bezahlt habe, aber das war noch in den 80igern).
Allerdings hat deine Argumentation einen Schönheitsfehler: int ist sicher skalar, arrays sind es ziemlich sicher nicht.
Gruss Reinhard
Hallo,
soweit es um Objekte geht, hast du sicher recht, auch wenn du
dir damit unter den Verfechtern von OO keine Freunde schaffst.
Nunja, es gibt sicher Hardcore-OOler, welche alles als Objekt haben wollen. Aber man muss eben auch die Nachteile sehen, wenn es um solch simple Strukturen geht. Deswegen gibt es in Java, C# usw ja auch jeden skalaren Typ noch als Objekt, man kann also genau entscheiden, wo es sinnvoll ist, ein Objekt oder den Skalar zu verwenden. Aber es macht halt so gut wie keinen Sinn (aus der ideologischen Genugtuung keinen Skalar verwendet zu haben) z.B. eine Schleifenvariable als Objekt zu implementieren. Wem Ideologie wichtiger ist, als Vernunft, der muss das dann eben mit Objekten machen
Ich fand es auch Overkill, dass in den ersten strengen
OO-Sprachen der Typ boolean (1bit) nur als Objekt
implementiert war (mir fällt nicht einmal mehr der Name der
Sprache ein, obwohl ich einiges Geld dafür bezahlt habe, aber
das war noch in den 80igern).
Das dürfte vermutlich Smalltalk gewesen sein, zumindest ist das dort so und die Zeit würde auch stimmen. Smalltalk war ja vom Konzept der OO sehr gut, nicht umsonst haben fast alle modernen OO-Sprachen viele wesentliche Dinge von Smalltalk übernommen.
Allerdings hat deine Argumentation einen Schönheitsfehler: int
ist sicher skalar, arrays sind es ziemlich sicher nicht.
Das Array ist aber eben auch kein Objekt, es hat keine weiteren Eigenschaften oder Methoden, genau wie ein Skalar
mfg
deconstruct