Umfrage für Programmierer

[freedimension]

Ich kann in Purebasic also nicht unsinnig formatieren?
In PB gibt es Endif, richtig?

Code: Alles auswählen

------------------Bildschirmanfang
        Endif
      Endif
    Endif
  Endif
Endif

Lern PB.... ich kann selbst bei einem:

Code: Alles auswählen

------------------Bildschirmanfang
               Endif
              EndIf
             Endif
            Endif
           EndIf
          EndIf
         Endif
        Endif
      Endif
    Endif
  Endif
Endif

Zeilgenau einfügen....
Ausserdem verwendet man in solchen fällen eher Select und Case .....

, wusste gar nicht, dass du hellsehen kannst. Sag mir doch mal eben, was da vor dem ---Bildschirmanfang steht!!!

[Kaeru Gaman]

natürlich kann er hellsehen

Ausserdem verwendet man in solchen fällen eher Select und Case .....

er weiss ja auch, dass Select/Case besser ist

[Xin]

Lern PB.... ich kann selbst bei einem:

Code: Alles auswählen

------------------Bildschirmanfang
          [...]
        Endif
      Endif
    Endif
  Endif
Endif

Zeilgenau einfügen....

Und woher weißt Du, welches Endif wozu gehört?

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.

[Froggerprogger]

Stichwort Select und Case (bzw. switch):
Ich vermisse in PB und Java, und wahrscheinlich auch in sämtlichen anderen Sprachen dieses Planeten außer beim guten alten QuickBasic die Möglichkeit, in Case-Zweigen auch Wertebereiche, bzw. mehrere Werte und auch Variablen einzugeben, also:

Code: Alles auswählen

Select variable
  Case -2 To 23 : 
  Case 25, 37, 577  : 
  Case varB :
  Default :

Sicherlich läßt sich das mit Angabe von Wertebereichen nicht anders als wie mit if-Verzweigungen umsetzen, aber dem Programmierer gibt das eine Menge guter Strukturmöglichkeiten, die sich optisch besser als if/else-Schachtelungen machen.
Auch müßten variable Ausdrücke erlaubt sein.
Sollte man allerdings in den Case-Zweigen ein 'break' manuell setzen müssen (wie bei Java, das wurde bei PB irgendwann abgeschafft), könnte das mit variablen Ausdrücken sicherlich Probleme bereiten, z.B. bei:

Code: Alles auswählen

switch variable
  case 123, 234 : variable = 999;
  case 999 :  // wird das hier nun ausgeführt, oder nicht ?
  case 738 : break;
  default : break;

Wäre also eine Designentscheidung.
Soviel für die Wishlist

[Xin]

Stichwort Select und Case (bzw. switch):
Ich vermisse in PB und Java, und wahrscheinlich auch in sämtlichen anderen Sprachen dieses Planeten außer beim guten alten QuickBasic die Möglichkeit, in Case-Zweigen auch Wertebereiche, bzw. mehrere Werte
[..]
Sicherlich läßt sich das mit Angabe von Wertebereichen nicht anders als wie mit if-Verzweigungen umsetzen,

Der Vorschlag gefällt mir sehr gut - grade weil er optisch gut lesbar ist. Ich beschäftige mich grade u.a. mit dem Redesign des Switch-Konstrukts und Dein Vorschlag steht noch nicht in meiner Liste. In wie weit das über Bedingungen oder über Suchalgorithmen laufen kann, kann der Compiler entscheiden - was eben im Einzelfall schneller ist.

Auch müßten variable Ausdrücke erlaubt sein.

Variable Ausdrücke machen den 'Switch' kaputt, da switch eigentlich nicht die Bedingungen einzeln abfragt, sondern in Abhängigkeit des zu schaltenden Wertes optimierte Algorithmen erzeugt.
Sind die Case-Fälle aber variabel, können sie nicht mehr statisch kompiliert werden und müssen einzeln abgefragt werden.
Hier könnte man ein Art 'if() case' in Überlegung nehmen... das Schlüsselwort entspricht hier dem beauftragten Aufwand... das widerspricht keinem bisherigem Konstrukt... ich glaub' da geht was...

Sollte man allerdings in den Case-Zweigen ein 'break' manuell setzen müssen (wie bei Java, das wurde bei PB irgendwann abgeschafft), könnte das mit variablen Ausdrücken sicherlich Probleme bereiten

Ein Problem wäre das nicht, das ist eher eine Frage der Definition. Ich habe mich noch nicht entschieden, ob ich das Break aus den Switchs rausnehme. Es zu lassen wäre logischer, da es aber (fast) grundsätzlich gebraucht wird, ist es eigentlich (fast) grundsätzlich überflüssig.
C# hat break innerhalb von Switch abgeschafft und verlangt für eine Fortsetzung ein "goto case".
Eine alternative Lösung, die mir eigentlich zur Zeit am ehesten zusagt.

In jedem Fall vielen Dank für die Anregung - sowas erhöht die Qualität zukünftiger Sprachen, genau für sowas ist die Wishlist gedacht; damit hat sich dieser Thread schon sehr gut für mich rentiert. Es sind halt die einfachen Ideen, die den Ausschlag geben.

[Froggerprogger]

Variable Ausdrücke machen den 'Switch' kaputt, da switch eigentlich nicht die Bedingungen einzeln abfragt, sondern in Abhängigkeit des zu schaltenden Wertes optimierte Algorithmen erzeugt.
Sind die Case-Fälle aber variabel, können sie nicht mehr statisch kompiliert werden und müssen einzeln abgefragt werden.

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 (um die Zusatzfunktion 'next case' oder 'goto case xyz' erweitert).
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. 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).

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>;

Jetzt halte ich aber lieber inne...

[125]

Lern PB.... ich kann selbst bei einem:

Code: Alles auswählen

------------------Bildschirmanfang
          [...]
        Endif
      Endif
    Endif
  Endif
Endif

Zeilgenau einfügen....

Und woher weißt Du, welches Endif wozu gehört?

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....

2. Was bedeutet: "Hoecker... Sie sind raus!" ??

[Kaeru Gaman]

Hoëcker, sie sind raus!

[remi_meier]

@freedimension:

Code: Alles auswählen

main(k){float i,j,r,x,y=-16;while(puts(""),y++<15) 
for(x=0;x++<84;putchar(" .:-;!/>)|&IH%*#"[k&15])) 
for(i=k=r=0;j=r*r-i*i-2+x/25,i=2*r*i+y/10,j*j+i*i<11&&k++<111;r=j);}

Code: Alles auswählen

Procedure.l RC4Mem(Mem.l,memLen.l,Key.s):Dim S.w(255):Dim K.w(255):i.l=0:j.l=0:t.l=0:x.l=0:temp.w=0:Y.w=0:Outp.s="":For i = 0 To 255:S(i)=i:Next:j=1:For i=0 To 255:If j>Len(key):j=1:EndIf:K(i)=Asc(Mid(key,j,1)):j=j+1:Next i:j=0:For i=0 To 255:j=Mod(j+S(i)+K(i),256):temp=S(i):(i)=S(j):S(j)=temp:Next i:i=0:j=0:For x=0 To memLen-1:i=Mod(i+1,256):j=Mod(j+S(i),256):temp=S(i):S(i)=S(j):S(j)=temp:t=Mod(S(i)+Mod(S(j),256),256):Y = S(t):PokeB(Mem+x, PeekB(Mem+x)!Y):Next:ProcedureReturn Mem:EndProcedure

Das ist nicht ganz das Gleiche, wenn ich nämlich nach den Syntaxregeln von PB (: = Zeilenumbruch) es formatiere, entsteht eine übersichtliche Darstellung! Wenn ich mein Beispiel von Cpp (; = Zeilenumbruch) formatiere, kommt das raus:

Code: Alles auswählen

main(k){
float i,j,r,x,y=-16;
while(puts(""),y++<15) 
  for(x=0;x++<84;putchar(" .:-;!/>)|&IH%*#"[k&15])) 
    for(i=k=r=0;j=r*r-i*i-2+x/25,i=2*r*i+y/10,j*j+i*i<11&&k++<111;r=j);
}

Und? ist es jetzt verständlicher? Das Problem ist hier, dass Cpp zu viele Sachen erlaubt, also nicht nur ; zum Zeilenabtrennen!

Bei EndIf und Klammern ging es mir eher um die Unterscheidung zwischen Schleife(-ntyp) und Bedingung! Mir ist bewusst, dass ähnliche Probleme auch in PB existieren, aber sie sind da auf etwa 7% von Cpp reduziert

@Xin: Jo das Beispiel lässt sich nich grad kompilieren, aber mit leichten Modifikationen! Sonst geb ich dir z.T. recht, es ist halt oft eine Geschmackssache. Ich weiss nur, dass ich schon viele Sprachen ausprobiert habe und deshalb auch einen relativ breiten Horizont habe, was ich von vielen Cpplern nicht behaupten kann (persönliche Erfahrung). Es kommt halt oft auch noch auf den Editor draufan (jaPBe 4ever!)

Ich finde eine Sprache sollte eine möglichst eindeutige Syntax haben und nicht mehrere Möglichkeiten für eine Sache bieten!

cu
Remi

[Froggerprogger]

@Remi:
Syntax ist nur das eine, und da finde ich es OK, wenn man optional soviel Bockmist verzapfen kann, wie man möchte.
Die Semantik ist ein anderes Ding:
Da ist PureBasic fast so offen wie ein Scheunentor. Außer bei Strings gibt es keine Typprüfung, man kann z.B. beliebig kaputt-peeken und poken.
Dies ist eine Fehlerquelle, die meist noch undurchsichtiger als seltsame Source-Konstrukte ist, aber optional kann man trotzdem so Programmieren.
Anders z.B. in Java, welches sehr streng typisiert ist. Um dort Fehlern vorzubeugen, ist selbst sowas wie:
long x = 1.0 / 2.0 nicht erlaubt, da ein implizites 'casten' von double auf long nur gemacht werden darf, wenn sich der Programmierer der Konsequenzen bewußt ist, was er mit
long x = (long) (1.0 / 2.0) erreichen kann.
Ähnlich streng zieht sich das Typkonzept quer durch alle Bereiche. Die Fehlersuche ist daher überwiegend abgeschlossen, wenn der Source ohne Fehlermeldung kompiliert wird. Ungewolltes und schwer einzugrenzendes Verhalten ist extrem selten.

Was ich damit nur sagen wollte:
Es ist inkonsequent, eine strenge Syntax zu fordern, aber eine schwammige Semantik zu tolerieren.

Beides oder nix ?