Warum Trennung zwischen Integers und Quads?

[Deeem2031]

vieleicht kommts ja für pb 5.0.net

Warum sollen wir denn bei .Net mit 5.0 anfangen? Ist doch ganz was anderes...

[Zaphod]

ich hätte auch schreiben können pb 5.0 2010 ultra mega hyper pro edition... ich wollte keine vorausage treffen wann pb .nettig wird.

[remi_meier]

Er spielt auf was an

[Zaphod]

was ich eigentlich ausdrücken wollte, fred und die anderen haben jetzt erstmal viele andere dinge zu erledigen: pb4 release, dokumentation, portierung nach linux, entscheidung wie mit dem osx cpu debakel umgegegangen werden soll, nach osx ppc portieren, evtl nach osx x86 portieren.

ich glaube es wird eine weile dauern, bis wir wieder mit feature requests nerven dürfen

[Lebostein]

>>Andre: ... eine universelle Funktion müsste vorher immer erst den korrekten Variablentyp ermitteln.
Und ? Ist das schwierig ?
Das kann doch der Compiler während der Kompilierung...

In FreeBasic und QBasic scheint das ja auch kein Problem zu sein. Da kommt man mit einer einzigen Funktion aus:

Code: Alles auswählen

test1$ = Str(2.67896543322678)
test2$ = Str(345.23)
test3$ = Str(201)
test4$ = Str(12147483647)

print test1$ ' 2.67896543322678
print test2$ ' 345.23
print test3$ ' 201
print test4$ ' 12147483647

sleep

Wenn dann noch ein optionaler "Anzahl der Stellen"-Parameter dran wäre, dann wäre das ganze sehr clever....
Wie gesagt, an der Stelle finde ich PureBasic alles andere als pure. Schaut euch an, was man hier für einen Aufwand treiben muss:

Code: Alles auswählen

test1$ = StrD(2.67896543322678)
test2$ = StrF(345.23)
test3$ = Str(201)
test4$ = StrQ(12147483647)

Debug test1$ ; 2.678965
Debug test2$ ; 345.230011
Debug test3$ ; 201
Debug test4$ ; 12147483647

Und dann sind die Ergebnisse im Vergleich zu FB grauenhaft. Bei den Floats werden einfach Stellen hinzugefügt, bei den Doubles einfach Stellen abgeschnitten. Das sollte ohne den optionalen Stellen-Parameter eigentlich nicht passieren...

[Froggerprogger]

Wenn man das Überladen von Prozeduren einbaut, sollte man auch die Möglichkeit des expliziten Type-Cast haben, um im Falle einer überladenen Prozedur die Möglichkeit zu haben, die auszuführende explizit zu bestimmen. Hier ist bei PB halt eine Design-Entscheidung gegen das Überladen gefallen, wahrscheinlich um PB's Compiler-Komplexität im Zaum zu halten. Explizites typecasting und überladene Prozeduren machen die Auswertung von Ausdrücken nochmals um einiges schwieriger - und da hat PB sowieso immer wieder einige Bugs.

Code: Alles auswählen

Procedure TuWas(l.l)
Debug "L"
EndProcedure

Procedure TuWas(f.f)
Debug "F"
EndProcedure

Test(2/4) ; Ausgabe L
Test(2.0/4) ; Ausgabe F
Test( (long) (2.0/4) ) ; sowas müßte dann auch machbar sein: caste 2.0/4 explizit nach long => Ausgabe L

[Deeem2031]

Code: Alles auswählen

test1$ = Str(2.67896543322678)
test2$ = Str(345.23)
test3$ = Str(201)
test4$ = Str(12147483647)

print test1$ ' 2.67896543322678
print test2$ ' 345.23
print test3$ ' 201
print test4$ ' 12147483647

sleep

Das sieht aber eher so aus als wenn das zur Zeit der Compilierung übersetzt wurde, bzw. dort werden Strings für die Zahlen benutzt. Kann mir sonst nich vorstellen wie man da auf 2 Nachkommastellen kommen will. (print test2$ ' 345.23)