Umfrage für Programmierer

Hier kann alles mögliche diskutiert werden. Themen zu Purebasic sind hier erwünscht.
Flames und Spam kommen ungefragt in den Mülleimer.
Benutzeravatar
freedimension
Admin
Beiträge: 1987
Registriert: 08.09.2004 13:19
Wohnort: Ludwigsburg
Kontaktdaten:

Beitrag von freedimension »

remi_meier hat geschrieben:jaPBe 4ever!
Es wird bestimmt auch eine Nach-jaPBe-Zeit geben ;)

Zum Rest: Klar erlaubt C/C++ viel, aber genau dass ist der Vorteil dieser Sprachen. Das macht sie so erfolgreich und flexibel. Du kannst sie für fast alles einsetzen, angefangen bei der Treiber- und Betriebssystemprogrammierung bis hin zum einfachen Texteditor.

Wie schon weiter oben gesagt, du kannst auch C++ auf einen ebenso transparenten Level bringen wie z.B. PureBasic, es hängt nur von den verwendeten Libraries ab.
Das einzige was ich an C/C++ immer gehasst habe: Sourcecodes die ich irgendwo gefunden habe liefen so gut wie nie ohne weitere Änderungen und Anpassungen in den Einstellungen :(
Beginne jeden Tag als ob es Absicht wäre!
Bild
BILDblog
Benutzeravatar
remi_meier
Beiträge: 1078
Registriert: 29.08.2004 20:11
Wohnort: Schweiz

Beitrag von remi_meier »

Ok recht haste :wink:
Nachteile von PB:
- Stringtypenprüfung (wobei das für LowLevel-Programmierer nützlich ist) fehlt z.T.
- Variablendefinitionen: A.l ist weniger übersichtlich als int A
- Structure mit Pointern: *pointer muss man als \pointer aufrufen, was in Konflikt kommt mit ev. pointer.l in Strukturen
- Nicht nötig Variablen zu definieren (ich weiss Streitpunkt, aber ich wills optional!)
- Keine Warnung bei Typencasting (Geschmackssache...)

Da gibts wahrscheinlich schon noch so einiges, aber für mich sind die Nachteile von Cpp wichtiger....

cu
Remi :)

EDIT: Jo flexibel ist gut für mich, schlecht für andere... (Stringtypenprüfung)
Benutzeravatar
125
Beiträge: 1322
Registriert: 19.09.2004 16:52
Wohnort: Neu Wulmstorf (Hamburg)
Kontaktdaten:

Beitrag von 125 »

gerade .typ finde ich gut ich finde eher das int ... zeugs doof.
Xin
Beiträge: 10
Registriert: 11.03.2005 02:10
Wohnort: http://sascha.atrops.com

Beitrag von Xin »

Froggerprogger hat geschrieben:
Variable Ausdrücke machen den 'Switch' kaputt
Da könnte man überlegen, ob man im Fall, dass eine Variable in switch vorkommt, diesen ganzen switch-Block einfach nur wie eine if-else-Struktur compilieren möchte. [..] Ist dann für diesen Fall zwar wieder ein bißchen langsamer als ein echter switch, aber der Programmierer hätte dann trotzdem diese Strukturmöglichkeit.
Ähh... nein, definitiv dagegen.
switch heißt switch und nicht "switch oder if". Darum heißt es switch.
Hat sich der Programmierer für switch entschieden und das durch "switch" festgelegt, bekommt er auch mindestens ein switch, aber definitiv nichts schlechteres. Läßt er sich auf ein if-else-if... ein, so soll er das auch klar aussagen.
Froggerprogger hat geschrieben: Allerdings bleibt dann immernoch das Problem mit 'goto case', dass man sich festlegen muss, ob man die Wahrheitswerte der variablen switch-cases innerhalb von cases ändern kann, oder nicht, (was ziemlich chaotisch werden könnte, wenn das möglich wäre).
Würde man den Wahrheitswert von Switch ändern, wäre es ein while-if-else-if...else-Konstruktion...
Hehehe... ich suche vorrangig einfache Konzepte, komplizierte Operatoren habe ich schon. ;-)
Froggerprogger hat geschrieben: Wo wir schon bei Weihnachten sind:
Die Kurzform für bedingte Zuweisung
var = <Bedingung> ? <Ausdruck1> : <Ausdruck2>;

...könnte man ausbauen auf eine generelle Kurzschreibform für if:
<Bedingung> ? <Anweisungsblock1> : <Anweisungsblock2>;
Du übersiehst hier eine wichtige Kleinigkeit, die korrekte Form ist:
<Bedingung> ? <Ausdruck1> : <Ausdruck2>
Das bedeutet, dass Ausdruck1 vom gleichen Typ wie Ausdruck2 sein muss und dass ein Ausdruck nicht vom Typ "Nichts"(void) sein darf.
Den gleichen Datentyp kann man durch eine Konvertierung auf Bool leicht erreichen, dann ist das in C/C++ möglich.
Nur, wenn nichts zurückgegeben wird, wird unpassend, aber man kann es ansonsten benutzen.
Und weils durch die ganze Konvertiererei unleserlich wird, kann man auch if benutzen... ;-)

---------------------------------------------------------------------
125 hat geschrieben:
Xin hat geschrieben:
125 hat geschrieben:Ausserdem verwendet man in solchen fällen eher Select und Case .....
Wenn ich das als PureBasic-Unkundiger grade richtig verstehe, erscheint mir "Hoecker... Sie sind raus!" als passende Antwort. ;-)
Also:

Code: Alles auswählen

 If Bla=1
  ;Tu das
  If Bla2=1
   ;Tu Auch das huer
    If Bla3=3
     ;Das dann bitte auchnoch
    EndIF
  EndIf
 EndiF  
Durch die Vormatierung sieht man welches IF zu welchem End If gehört....
Dann bin ich mal gespannt, wie Du das Programm dazu bringt "das dann bitte auch noch" über ein Select zu realisieren.

Wo unterscheidet sich Deine Endif-Lösung zu der Lösung in C?
Keiner weiß, worum es geht. Da helfen nur große Monitore mit hoher Auflösung. Das Problem kann KEINE Programmiersprache lösen und die Lösungen, die über IDE möglich sind, hat scheinbar noch keiner geschrieben.

---------------------------------------------------------------------

Eine Sache nochmals zu dem Unsinn der Formatierung.

Syntaxregeln ": = Zeilenumbruch" usw.
Ich sehe es überhaupt nicht ein, eine Diskussion darüber zu führen, ob die Programmsprache schuld ist, wenn der Programmierer möglichst unleserliche Programme schreibt.
Wer unleserliche Programme schreiben will, kann das in allen Sprachen.
Wer unleserliche Programme schreiben will, will keine leserlichen Programme schreiben.
Wer leserliche Programme schreiben will, kann das in allen Sprachen.

Diese Diskussion ist so dermaßen obsolete, wer dies als Argument für oder gegen eine Sprache setzt, sucht keine Argumentation, sondern wünscht sich mit allen Mitteln Recht zu bekommen. Wer unbedachte Scheinargumente für seine Argumentation verwenden muss, disqualifiziert sich für eine qualifizierte Argumentation.
Unqualifizierte Argumentation ist keine Argumentation, ohne Argumentation, keine produktive Diskussion. Damit wären wir wieder bei dem Punkt, wo die Diskussion obsolete wird.
--
Mit freundlichen Grüßen
Sascha 'Xin' Atrops

It's a kind of fun to do the impossible.
(Walt Disney)
Benutzeravatar
Froggerprogger
Badmin
Beiträge: 855
Registriert: 08.09.2004 20:02

Beitrag von Froggerprogger »

Ne Idee für das "EndIf - Problem"
Das könnte mit dem Editor gelöst werden, indem einfach automatisch nach der schließenden Klammer ein Kommentar mit der gegenwärtigen Bedingung unterhalten wird.
Also z.B.

Code: Alles auswählen

for (int i=0; i<12; i++)
{
  ...
  ...
  ...
} // for (int i=0; i<12; i++) //
Der bereich 'da hinten' wird dann automatisch geupdatet. Außerdem kann dahinter ein eigener Kommentar gesetzt werden, der erhalten bleibt.
Das könnte man für sämtliche if / for / while / switch - Anweisungsblöcke einsetzen.
In PB wäre das dann z.B. sowas:

Code: Alles auswählen

If var1 > 23 And var1 < 23
  ...
  ...
  ...
Endif ; var1 > 23 And var1 < 23
Naja, zumindest als Idee.



Apropos Idee... und nochwas:
Gerade bei dem Beispiel fiel es mir wieder ein:
"var1 > 23 And var1 < 23" ist dermaßen blöde zu schreiben, das nervt mich gerade als Mathematiker super oft.
Ich vermisse die simple Intervallschreibweise:

Code: Alles auswählen

If var in [0, 23]
...
else if var in [-23.2, 2322e4]

var in [a, b]
var notin ]0, 22*pi^3 -12b]
var in ]0, ..]
var notin ].., 12e-12[

auch:

var in {123, 343, 21, -23, 2.0, 2.4}
(Ich glaube, ist klargeworden ? ;-) )
Also:
geschlossene Klammer heißt inklusive Randelement, '..' heißt unbegrenzt, offene Klammer heißt ohne Gleichheitsbedingung auf Randelement, und so weiter (logo).
notin heißt einfach nicht im Intervall.
Jeder PreCompiler kann das als eine seiner leichtesten Übungen umsetzen, und z.B. "var in ]..,4]" übersetzen in "var <= 4" bzw.
var in [4, 12*b[ übersetzen in "var >= 4 And var < 12*b
Ungültige Intervalle, z.B. ]6, -2[ könnten einfach als ]0,0[ compiliert werden.
Mengenklammern führen bei z.B. bei
"var in {12, 23, 54, 3*x}"
zu
"var = 12 OR var = 23 OR var = 54 Or var = 3*x"
Gäbe es sowas, würde ich die Sprache gleich nutzen ! :allright:

P.S.: Und jetzt sag nicht in C++ geht sogar "-14 < var <= 123" ???
solche Ungleichungsketten wären natürlich auch der Hammer.
Form: <constantExpr> <Opr> <VariableExpr> <Opr> <constantExpr>


... und nochwas (es wird spät, da werde ich einfallsreich, oje...):
Arrays mit Startwerten definierbar:
Dim A.l() = {1,2,3,4,5}
ist ein alter Hut, ebenso im mehrdimensionalen
Dim A.l() = {{12, 23, 0}, {123, 34, 9}}
aber wirklich cool wäre was mit Bildungsgesetzen:
Dim A.l(10) = {n | 24*n - 23.0/1.0}
Wieder einfach etwas, was ein PreCompiler mit Textersetzungen durchführen könnte. Letzteres z.B. durch:
Dim A.l(10) = {n | 24*n - 23.0/1.0}

wird zu

Dim A.l(10)
For n=0 To 10 ; in PB gilt Arraysize inkl. Rand
A(n) = 24*n - 23.0/1.0
Next
Form also sowas wie (in PB):
Dim Arrayname.Typ(size) = { localvarname | <expression> }
wobei localvarname von 0 bis size rennt.

Es gibt da noch einige ähnliche Dinge mehr, die eine Programmiersprache in meinen Augen extrem aufwerten würden, und wahrscheinlich jeden Mathe-Interessierten vom Hocker hauen würden, aber für jetzt reichts erstmal ;-)
!UD2
MARTIN
Beiträge: 454
Registriert: 08.09.2004 14:03
Wohnort: Kiel

Beitrag von MARTIN »

freedimension hat geschrieben:Du kannst sie für fast alles einsetzen, angefangen bei der Treiber- und Betriebssystemprogrammierung bis hin zum einfachen Texteditor.
Nicht zu vergessen die ganzen elektronischen Geräte die zwar keine Computer im herkömlichen Sinne sind aber einen Microkontroler oder Microprozessor haben, z.B. ein Kopierer.
Für diese Geräte ist auch Software nötig und wenn sie etwas komplexer ist, wird sie auch in C geschrieben.
Amilo 1667|Suse Linux 10.1_64bit/WinXP |PB 4.00/3.94
Xin
Beiträge: 10
Registriert: 11.03.2005 02:10
Wohnort: http://sascha.atrops.com

Beitrag von Xin »

Gratuliere, Froggerprogger...
Ich muss mir schon wieder eine Mail an mich selber schreiben (ich lagere dort in einem Ordner die Ideen zum Compiler)
Froggerprogger hat geschrieben:Ne Idee für das "EndIf - Problem"
Das könnte mit dem Editor gelöst werden, indem einfach automatisch nach der schließenden Klammer ein Kommentar mit der gegenwärtigen Bedingung unterhalten wird.
Das wäre eine Möglichkeit, die die IDE betrifft, aber nicht die Sprache. Nichtsdestotrotz ist die Idee gut. Ich habe einige Ideen, um derartiges durch Compiler prüfen lassen zu können. In Kombination mit der Verarbeitung durch die IDE, könnte das direkt deutlich Klammerungsfehler darstellen.
Froggerprogger hat geschrieben:Apropos Idee... und nochwas:
Gerade bei dem Beispiel fiel es mir wieder ein:
"var1 > 23 And var1 < 23" ist dermaßen blöde zu schreiben, das nervt mich gerade als Mathematiker super oft.
Ich vermisse die simple Intervallschreibweise:

Code: Alles auswählen

If var in [0, 23]
...
else if var in [-23.2, 2322e4]

var in [a, b]
var notin ]0, 22*pi^3 -12b]
var in ]0, ..]
var notin ].., 12e-12[

auch:

var in {123, 343, 21, -23, 2.0, 2.4}
(Ich glaube, ist klargeworden ? ;-) )

Jeder PreCompiler kann das als eine seiner leichtesten Übungen umsetzen, und z.B. "var in ]..,4]" übersetzen in "var <= 4" bzw.
var in [4, 12*b[ übersetzen in "var >= 4 And var < 12*b
Ungültige Intervalle, z.B. ]6, -2[ könnten einfach als ]0,0[ compiliert werden.
Mengenklammern führen bei z.B. bei
"var in {12, 23, 54, 3*x}"
zu
"var = 12 OR var = 23 OR var = 54 Or var = 3*x"
Gäbe es sowas, würde ich die Sprache gleich nutzen ! :allright:
Die Idee mit den Mengenklammern hatte ich noch nicht, sie gefällt mir, aber ich bin nicht sicher, ob ich sie direkt umsetzen kann, da beide Klammern bereits reserviert sind. Da muss ich prüfen, ob ich das widerspruchsfrei ins Konzept einabauen kann.

Der "in" Operator wird als Schnittmenge zwischen Variable und Menge realisiert und ist bereits klar festgelegt.
Froggerprogger hat geschrieben: P.S.: Und jetzt sag nicht in C++ geht sogar "-14 < var <= 123" ???
solche Ungleichungsketten wären natürlich auch der Hammer.
Form: <constantExpr> <Opr> <VariableExpr> <Opr> <constantExpr>
Das ist nicht möglich, da sich die Datentypen ändern in Bool ändern.
Nehmen wir var als 200, so sollte die Funktion do_something() nicht ausgeführt werden:
if( -14 < var <= 123 ) do_something();
einsetzen:
if( -14 < 200 <= 123 ) do_something();
auflösen:
if( true <= 123 ) do_something();
konvertieren:
if( 1 <= 123 ) do_something();
auflösen:
if( true ) do_something();

C++ unterstützt mit ausnahme des "x ? y : z" Operators nur unäre und binäre Operatoren. Hier werden binäre Operationen der Reihe nach ausgeführt.
Ich hab' diese Schreibweise jetzt zweimal schon durchgegangen, weil mir die Schreibweise prinzipiell auch gut gefällt, bin aber zu der Überzeugung gekommen, dass die Einführung eines trinären? Operators "x < y < z" unklug erscheint, da er mit "(x < y) < z" verwechselt werden würde. Damit würde die Orthogonalität der Sprache verloren gehen, da der '<' Operator je nach Klammerung unterschiedliche Bedeutung hätte. Eine Einschränkung, dass ein Operator einen konstanten Ausdruck verlangt, ist auch nicht hinnehmbar.

Außerdem ist Abfrage durch die Schnittmenge möglich (im Falle der natürlichen Zahlen):
if( var in { -13..123 } ) do_something();

Für Floating Points sollte ich mir fürwahr was zur Mengenschreibweise überlegen...
Froggerprogger hat geschrieben:... und nochwas (es wird spät, da werde ich einfallsreich, oje...):
Arrays mit Startwerten definierbar:
Drin, aufgrund der Abstammung von C++.
Froggerprogger hat geschrieben:
Dim A.l(10) = {n | 24*n - 23.0/1.0}
Wieder einfach etwas, was ein PreCompiler mit Textersetzungen durchführen könnte. Letzteres z.B. durch:
Dim A.l(10) = {n | 24*n - 23.0/1.0}
wird zu
Dim A.l(10)
For n=0 To 10 ; in PB gilt Arraysize inkl. Rand
A(n) = 24*n - 23.0/1.0
Next
Form also sowas wie (in PB):
Dim Arrayname.Typ(size) = { localvarname | <expression> }
wobei localvarname von 0 bis size rennt.
23.0 / 1.0 == 23.0... ? höh?


Das kann ich so direkt nicht übernehmen/anbieten.
Aber auch das ist ein weitere Betrachtung wert.
Froggerprogger hat geschrieben: Es gibt da noch einige ähnliche Dinge mehr, die eine Programmiersprache in meinen Augen extrem aufwerten würden, und wahrscheinlich jeden Mathe-Interessierten vom Hocker hauen würden, aber für jetzt reichts erstmal ;-)
Deine mathematische Herangehensweise gefällt mir sehr gut, da ich als Informatiker gewissermaßen die Scheuklappen der Gewohnheit aufhabe und so auch mit gewohnten Methoden an die Sache herangehe.
Wenn Du weitere Ideen hast, würde ich mich über direkten Mailkontakt freuen. Du findest auf meiner Website meine E-Mailadresse, alternativ schau Dir die URL meiner Page an, meinen Namen, dann weißt Du auch wie meine Mailadresse lautet. ;-)
--
Mit freundlichen Grüßen
Sascha 'Xin' Atrops

It's a kind of fun to do the impossible.
(Walt Disney)
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

Froggerprogger hat geschrieben:Es ist inkonsequent, eine strenge Syntax zu fordern, aber eine schwammige Semantik zu tolerieren.
absolut zitierwürdiger satz. :D

pack den doch in deine signatur :allright:
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Benutzeravatar
125
Beiträge: 1322
Registriert: 19.09.2004 16:52
Wohnort: Neu Wulmstorf (Hamburg)
Kontaktdaten:

Beitrag von 125 »

Das war ein schelchtes bsp. für switch und case @ Xin
Aber da würde man dann den Operator AND benutzen und hätte auch nicht das problem:

Code: Alles auswählen

If Bla=1 AND Bla2=1 AND Bla3=3
;Tu das 
;Tu Auch das huer 
;Das dann bitte auchnoch 
EndiF 
Bild
BildDas ist Tux. Kopiere Tux in deine Signatur und hilf ihm so auf seinem Weg zur Weltherrschaft.
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

125 hat geschrieben:Das war ein schelchtes bsp. für switch und case @ Xin
Aber da würde man dann den Operator AND benutzen und hätte auch nicht das problem:

Code: Alles auswählen

If Bla=1 AND Bla2=1 AND Bla3=3
;Tu das 
;Tu Auch das huer 
;Das dann bitte auchnoch 
EndiF 
aber vorher hast du geschrieben:

Code: Alles auswählen

 If Bla=1
  ;Tu das
  If Bla2=1
   ;Tu Auch das huer
    If Bla3=3
     ;Das dann bitte auchnoch
    EndIF
  EndIf
 EndiF  
...ich hoffe du merkst selbst, das es sich um zwei grundverschiedene abläufe handelt...
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Antworten