1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Freier Pascal-Compiler in…
  6. Thema

Nachteile von Pascal gegenüber C/C++

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Niklaus Wirth meint ...

    Autor: Modula 11.09.07 - 16:29

    IngJKi schrieb:
    -------------------------------------------------------
    > Aber macht nicht´s, wenn die C-Gurus Spucken und
    > speien.
    > Es gibt genug nahmhafte Firmen wie zB. ESA / NASA
    > uvm.
    > bei denen C verpönt ist und die nur!!
    > Pascal/Delphi (und Ähnliches) einsetzen. Und für
    > Micro-Controller und DSP's gibt es ja
    > auch noch Micro-Pascal u.& .
    > Denn bei dem, zu meist unübersichtlichen
    > C-Geschmiere
    > würde man ja Birnen-Krebs bekkommen!!

    Auch das ist meiner Meinung nach, knapp vorbeigeschossen.

    Ich bin davon überzeugt, daß es Wirth gar nicht um die syntaktischen Unterschiede zwischen C/C++ und Pascal ging, als er sich so negativ darüber äußerte. Auch ein Dr. Wirth muß sehen, daß es doch eigentlich gar keinen so großen Unterschied macht, ob ich ein Konstrukt in einem BEGIN...END-Block oder in geschweiften Klammern definiere. Nein, ich glaube, daß Wirths Kritik an C auf etwas ganz anderes abzielte.

    Wirths Sprachdesign (Pascal/Modula/Oberon) ist die praktische Umsetzung seiner Theorien über "Algorithmen und Datenstrukturen". Wer Wirth kennt, der weiß, daß für ihn die Programmiersprache eher zweitrangig ist - zweitrangig nach den Datenstrukturen, die für ihn das Fundament der Programmierung darstellen.
    In C und C++ sind wilde Type-Casts und untypisierte Zeigeroperationen an der Tagesordnung und werden sogar von vielen C-/C++-Entwicklern als fortschrittliche Programmierung angesehen.
    Genau das ist aber in Pascal oder Oberon verpönt und ich stimme mit Wirth überein, daß genau hier die große Stärke dieser Hochsprachen liegt. Denn der anarchische Umgang mit Variablen wie bei C und C++ führt dazu, daß der Entwickler gelegentlich die Übersicht über seine Datenstrukturen verliert. Das Ergebnis sind Null-Pointer-Exceptions, oder ähnliche Fehler, die wir von schlecht getesteten Programmen zur genüge kennen.

    Ich habe selbst sowohl in C, C++, als auch in Pascal entwickelt. Tatsächlich habe ich in Pascal meist mehr Zeit für Coding gebraucht, da ich sehr viel Aufwand in das Design meiner Datentypen gesteckt hab. Ich bin aber fest davon überzeugt, daß ich diese Zeit beim Debugging immer wieder locker reingeholt hab.
    Ich habe C und C++ übrigens dann eingesetzt, wenn es darum ging, bereits bestehenden Code fortzuentwickeln. Dabei habe ich immer wieder festellen müssen, daß auch die Fehler der Kollegen, die zuvor an dem Projekt arbeiteten, fast immer durch schlampigen Umgang mit Datenstrukturen begründet waren.

    Selbstverständlich kann man in Pascal auch mit Zeigern arbeiten und in den frühen Anfängen von Pascal verstießen wir z.B. mit varianten Records gelegentlich auch gegen Wirths "reine Lehre" aber im Großen und Ganzen bin ich davon überzeugt, daß die Methodik wie heutzutage in C und C++ entwickelt wird, ganz gut erklärt, warum es an der Qualität und Stabilität der Software manchmal hapert.



  2. Re: Nachteile von Pascal gegenüber C/C++

    Autor: TheRealMarv 11.09.07 - 16:34

    Die 10% die dir fehlen kannst ja dann in C/C++ coden und dann in dein Delphi Projekt einbinden (mittels Librarys/DLLs). Dann haste auch deine 90% Delphi, 10% C Lösung.

  3. Re: Niklaus Wirth meint ...

    Autor: Frickeln ade 11.09.07 - 18:31

    absolutely ACK!

    Modula schrieb:
    -------------------------------------------------------
    > IngJKi schrieb:
    > --------------------------------------------------
    > -----
    > > Aber macht nicht´s, wenn die C-Gurus Spucken
    > und
    > speien.
    > Es gibt genug nahmhafte
    > Firmen wie zB. ESA / NASA
    > uvm.
    > bei denen
    > C verpönt ist und die nur!!
    > Pascal/Delphi
    > (und Ähnliches) einsetzen. Und für
    >
    > Micro-Controller und DSP's gibt es ja
    > auch
    > noch Micro-Pascal u.& .
    > Denn bei dem, zu
    > meist unübersichtlichen
    > C-Geschmiere
    >
    > würde man ja Birnen-Krebs bekkommen!!
    >
    > Auch das ist meiner Meinung nach, knapp
    > vorbeigeschossen.
    >
    > Ich bin davon überzeugt, daß es Wirth gar nicht um
    > die syntaktischen Unterschiede zwischen C/C++ und
    > Pascal ging, als er sich so negativ darüber
    > äußerte. Auch ein Dr. Wirth muß sehen, daß es doch
    > eigentlich gar keinen so großen Unterschied macht,
    > ob ich ein Konstrukt in einem BEGIN...END-Block
    > oder in geschweiften Klammern definiere. Nein, ich
    > glaube, daß Wirths Kritik an C auf etwas ganz
    > anderes abzielte.
    >
    > Wirths Sprachdesign (Pascal/Modula/Oberon) ist die
    > praktische Umsetzung seiner Theorien über
    > "Algorithmen und Datenstrukturen". Wer Wirth
    > kennt, der weiß, daß für ihn die
    > Programmiersprache eher zweitrangig ist -
    > zweitrangig nach den Datenstrukturen, die für ihn
    > das Fundament der Programmierung darstellen.
    > In C und C++ sind wilde Type-Casts und
    > untypisierte Zeigeroperationen an der
    > Tagesordnung und werden sogar von vielen
    > C-/C++-Entwicklern als fortschrittliche
    > Programmierung angesehen.
    > Genau das ist aber in Pascal oder Oberon verpönt
    > und ich stimme mit Wirth überein, daß genau hier
    > die große Stärke dieser Hochsprachen liegt. Denn
    > der anarchische Umgang mit Variablen wie bei C und
    > C++ führt dazu, daß der Entwickler gelegentlich
    > die Übersicht über seine Datenstrukturen verliert.
    > Das Ergebnis sind Null-Pointer-Exceptions, oder
    > ähnliche Fehler, die wir von schlecht getesteten
    > Programmen zur genüge kennen.
    >
    > Ich habe selbst sowohl in C, C++, als auch in
    > Pascal entwickelt. Tatsächlich habe ich in Pascal
    > meist mehr Zeit für Coding gebraucht, da ich sehr
    > viel Aufwand in das Design meiner Datentypen
    > gesteckt hab. Ich bin aber fest davon überzeugt,
    > daß ich diese Zeit beim Debugging immer wieder
    > locker reingeholt hab.
    > Ich habe C und C++ übrigens dann eingesetzt, wenn
    > es darum ging, bereits bestehenden Code
    > fortzuentwickeln. Dabei habe ich immer wieder
    > festellen müssen, daß auch die Fehler der
    > Kollegen, die zuvor an dem Projekt arbeiteten,
    > fast immer durch schlampigen Umgang mit
    > Datenstrukturen begründet waren.
    >
    > Selbstverständlich kann man in Pascal auch mit
    > Zeigern arbeiten und in den frühen Anfängen von
    > Pascal verstießen wir z.B. mit varianten Records
    > gelegentlich auch gegen Wirths "reine Lehre" aber
    > im Großen und Ganzen bin ich davon überzeugt, daß
    > die Methodik wie heutzutage in C und C++
    > entwickelt wird, ganz gut erklärt, warum es an der
    > Qualität und Stabilität der Software manchmal
    > hapert.
    >
    >


  4. Re: Nachteile von Pascal gegenüber C/C++

    Autor: Fragrüdiger 11.09.07 - 18:38

    ch schrieb:
    -------------------------------------------------------
    > Was die Vorteile von Free Pascal sind, habe ich
    > auf der Webseite nachgelesen.

    Die sind aber auch irgendwie etwas weit hergeholt:

    "Very clean language" -- Das ist sehr Subjektiv. Ich kann auch ordentlichen C-Code gut lesen.

    "No Makefiles" -- Die braucht man bei kleineren C-Programmen auch nicht. gcc *.c (und evtl. weitere Parameter) reicht da auch aus. Bei größeren Programmen möchte man evtl. mehrere Targets und mehr Kontrolle haben. Da braucht man ohnehin Makefiles o.ä.

    "Pascal compilers are Fast with a big F" -- Wenn ich mit GCC ohne Optimierung kompiliere, ist er auch verdammt schnell. Der kompilierte FreePascal-Code ist vermutlich in der Ausführung auch nicht schneller als mit GCC kompilierter C-Code ohne Optimierung.

    "Each unit has it's own identifiers" -- Das kann ein Vorteil sein. Bei C++ gibt es auch Namespaces. Bisher hatte ich aber auch bei C noch nie Probleme damit.

    "High speed, low memory use" -- Da kann C absolut locker mithalten.

    Die folgenden Punkte gelten ebenso für C/C++.

  5. Re: Niklaus Wirth meint ...

    Autor: Fragrüdiger 11.09.07 - 18:40

    nixda schrieb:
    -------------------------------------------------------
    > „C ist keine ‘high level programming
    > language’. C ist ein mit Syntax verzuckerter
    > Assembler.“

    Stimmt. Genau deswegen mag ich C. Insbesondere die Flexibilität im Umgang mit Zeigern, die andere Sprachen möglichst zu verstecken zu versuchen, macht C für mich zu einer sehr effektiven Programmiersprache.

  6. Re: Niklaus Wirth meint ...

    Autor: Hello_World 11.09.07 - 23:06

    Modula schrieb:
    -------------------------------------------------------
    > In C und C++ sind wilde Type-Casts und
    > untypisierte Zeigeroperationen an der
    > Tagesordnung und werden sogar von vielen
    > C-/C++-Entwicklern als fortschrittliche
    > Programmierung angesehen.
    Damit antworte ich mal mit einem Zitat von Bjarne Stroustrup:
    "C/C++ - [...] a mythical language referred to by people who cannot or do not want to recognize the magnitude of differences between the facilities offered by C and C++ or the significant differences in the programming styles supported by the two language."
    In C muss man casten, das ist richtig. In C++ kommt das dank Templates fast nie vor; außerdem gibt es noch die typsicheren Cast-Operatoren. Pascal dagegen unterstützt m. W. in der von Wirth spezifizierten Version keine Generics oder Templates.
    > Denn
    > der anarchische Umgang mit Variablen wie bei C und
    > C++ führt dazu, daß der Entwickler gelegentlich
    > die Übersicht über seine Datenstrukturen verliert.
    Dass Du überhaupt nicht zwischen C und C++ differenzierst, zeigt, dass Du entweder nur in C programmiert oder C++ wie "C mit Klassen" verwendet hast.
    > Das Ergebnis sind Null-Pointer-Exceptions, oder
    > ähnliche Fehler, die wir von schlecht getesteten
    > Programmen zur genüge kennen.
    Ein C- oder C++-Programm stürzt mit einem Speicherzugriffsfehler ab, wenn man einen Null-Pointer dereferenziert. Etwas äquivalentes passiert aber in jeder Sprache, ein Java-Programm wirft z. B. eine nullpointer-Exception.
    Der Unterschied liegt also nicht in den Abstürzen, sondern an einer ganz anderen Stelle, nämlich ungültigen nicht-NULL-Pointern. In Java hat man hier den Vorteil, dass eine Referenz entweder gültig oder null ist. Das geht in C++ aber ganz genauso, z. B. mit den Smart-Pointern der Boost-Bibliothek (http://boost.org/libs/smart_ptr/smart_ptr.htm), die bald in die C++-Standardbibliothek aufgenommen werden. Man kann über Operatorüberladung denken, was man will, aber hier ist sie ausgesprochen nützlich, da man die Smartpointer-Templates bis auf die Deklaration (shared_ptr<T> statt T*) genauso nutzen kann wie normale Pointer.
    > Ich habe selbst sowohl in C, C++, als auch in
    > Pascal entwickelt.
    Wenn ich das in Zusammenhang mit dem betrachte, was Du oben über die Typsicherheit von C++ geschrieben hast, will ich wirklich nicht Deinen C++-Code sehen.
    > Tatsächlich habe ich in Pascal
    > meist mehr Zeit für Coding gebraucht, da ich sehr
    > viel Aufwand in das Design meiner Datentypen
    > gesteckt hab.
    Mich würde wirklich einmal interessieren, was Dich in C++ davon abhält. Wie gesagt, Typsicherheit ist in C++ überhaupt kein Ding, genauso wenig wie Sicherheit bei Speicherzugriffen (wozu gibt es std::vector & Co.?).
    > Ich habe C und C++ übrigens dann eingesetzt, wenn
    > es darum ging, bereits bestehenden Code
    > fortzuentwickeln. Dabei habe ich immer wieder
    > festellen müssen, daß auch die Fehler der
    > Kollegen, die zuvor an dem Projekt arbeiteten,
    > fast immer durch schlampigen Umgang mit
    > Datenstrukturen begründet waren.
    In C oder C++? In C lässt sich schlampiger Umgang kaum vermeiden, in C++ sehr wohl.
    > Selbstverständlich kann man in Pascal auch mit
    > Zeigern arbeiten
    Eine Sprache, in der man nicht mit Zeigern arbeiten kann, wäre auch reichlich sinnlos. Letzten Endes sind die "Referenzen" in Java, C# usw. auch nur Pointer, nur sind sie im Gegensatz zu richtigen Pointern eben opak und erlauben keine Pointerarithmetik (was durchaus von Vorteil sein kann).
    > und in den frühen Anfängen von
    > Pascal verstießen wir z.B. mit varianten Records
    > gelegentlich auch gegen Wirths "reine Lehre" aber
    > im Großen und Ganzen bin ich davon überzeugt, daß
    > die Methodik wie heutzutage in C und C++
    > entwickelt wird, ganz gut erklärt, warum es an der
    > Qualität und Stabilität der Software manchmal
    > hapert.
    Was ist denn bitte "die" Methodik? "Die" Methodik gibt es nicht, es gibt aber sehr wohl Methoden, wie man auch in C++ zuverlässige Software schreiben kann. Gute Werkzeuge (Valgrind u. ä.), Code Policies, gegenseitiger Code-Review, Verwendung geeigneter Utility-Funktionen und -Klassen (z. B. Boost), Refactoring-Tools usw. sind da nur einige Vorschläge. Und in den Softwareentwicklungsprozess spielen nicht zuletzt noch Teamwork, ein intelligentes Design und andere menschliche Faktoren hinein, die m. W. wesentlich wichtiger sind als die Sprache, in der entwickelt wird.
    Übrigens finde ich in Deinem Beitrag praktisch keine Hinweise für Pascal-Eigenschaften, die das Nachdenken über Datenstrukturen und Algorithmen fördern, und ich kann mir auch nicht vorstellen, dass Pascal C++ da wirklich etwas relevantes voraus haben soll.

  7. Re: Nachteile von Pascal gegenüber C/C++

    Autor: Hello_World 11.09.07 - 23:45

    ufas schrieb:
    -------------------------------------------------------
    > gewisse Leute finden das ein Block mit Begin und
    > End zu mühsam zu schreiben ist.
    Ja, und sie haben recht. {} ist aber auch noch zu viel, die einzige Sprache, wo Blöcke richtig markiert werden, ist Python, wo die Blöcke durch die Einrückung begrenzt werden. Sowas kann damit nicht passieren:

    if(blablubber);
    machwas();

    statt

    if(blablubber)
    machwas();

    Außerdem ist der Programmierer gezwungen, lesbaren Code zu schreiben.

  8. Re: Nachteile von Pascal gegenüber C/C++

    Autor: Hello_World 11.09.07 - 23:50

    byti schrieb:
    -------------------------------------------------------
    > ch schrieb:
    > --------------------------------------------------
    > -----
    > > Was die Vorteile von Free Pascal sind, habe
    > ich
    > auf der Webseite nachgelesen. Das
    > klingt
    > überzeugend. Ich frage mich nun, wo
    > die
    > *technischen* Nachteile von Free Pascal
    > (nicht dem
    > alten Urpascal) gegenüber von
    > C/C++ sind, also
    > *außer* den
    > offensichtlichen, dass C/C++ eben
    >
    > Quasi-Standard ist und es daher viel
    > einfacher
    > ist, damit an vorhandenen Code
    > anzuschließen.
    >
    > Eigentlich ganz einfach. :)
    >
    > C => is am schnellsten,
    C ist nicht wesentlich schneller als Pascal. http://shootout.alioth.debian.org/gp4/pascal.php
    > am Hardwarenähesten,
    > aber am komplexesten, emfindlich für versteckte
    > fehler
    > VB => is am langsamsten, "weit weg von der
    > Hardware" (Interpreter), aber saueinfach, und
    > schluckt fast jeden scheiß
    VB wird nicht interpretiert (VB.NET verwendet einen JIT-Compiler).
    > Pascal/Delhpi => mitten drin, ist schell,
    > erzeugt "richtigen" Maschinencode, relativ
    > übersichtlich, relativ unempfindlich gegen Fehler,
    > eine GUI-Anwendung is schnell erstellt (Lazarus,
    > Delphi)
    Das hat exakt gar nichts mit der Sprache zu tun, GUI-Designer gibt's auch für C (z. B. Glade) oder VB.
    > Pascal/Delphi hat halt nur das Problem... es kann
    > nur 90% sag ich immer. Man fängt was an.. und
    > merkt wenn man fast fertig ist.. mist.. die
    > (teilweise minimale funktion) gibts ned... =>
    > krückenlösung.
    Wenn man so etwas behauptet, sollte man es belegen (oder einfach aufhören, hier solchen Humbug zu verbreiten).

  9. Re: Nachteile von Pascal gegenüber C/C++

    Autor: Hello_World 12.09.07 - 00:17

    # schrieb:
    -------------------------------------------------------
    > Ich selbst
    > sehe das aber überhaupt nicht so, weil gerade Free
    > Pascal hat - wie du es wohl selbst schon auf
    > dessen Website gelesen hast - wesentliche Vorteile
    > gegenüber C/C++ und macht es auch durch die
    > Verfügbarkeit auf diversen Plattformen und
    > Prozessortypen für mich interessant.
    Hm? C-Compiler gibt es für so ziemlich alles, was Einsen und Nullen unterscheiden kann. FreePascal unterstützt dagegen "nur" x86(-64), PowerPC und SPARC. Gerade 68k, ARM usw. wären aber durchaus interessant, da sehr verbreitet im embedded-Bereich. Nach oben fehlen u. a. POWER und Itanium bzw. IA64.
    > Ich habe es
    > bei C/C++ immer als Nachteil angesehen, dass dort
    > viel mit Pointern gearbeitet wird statt mit
    > sauberen Deklarieren von Variablen (wie das z.B.
    > bei Pascal zwingend ist),
    Bitte was? Was hat die Deklaration von Variablen mit der Verwendung von Pointern zu tun? Abgesehen davon muss man Funktionen und Variablen natürlich auch in C und C++ deklarieren. Und wenn Du nicht willst, musst Du bei C++ praktisch nie Pointerarithmetik betreiben, gerade die STL (bzw. Templates allgemein) nimmt einem da viel Arbeit ab.
    Desweiteren kann man schon simpelste Datenstrukturen (z. B. verkettete Listen) nicht ohne Zeiger implementieren (und wenn jetzt jemand mit Java usw. kommt: Referenzen sind auch nur Pointer. Schonmal drüber nachgedacht, warum das Teil NullPOINTERException heißt?).
    > wodurch viele
    > Sicherheitslücken überhaupt erst entstehen.
    Ja, wenn man C++ wie C programmiert und z. B. strings in statisch allokierte Puffer einliest die dann überlaufen. Da kann man nur auf Stroustrup verweisen:
    "There is no language called "C/C++". The phrase is usually used by people who don't have a clue about programming (e.g. HR personnel and poor managers). Alternatively, it's used by people who simple do not know C++ (and often not C either)."
    > Als Nachteil von Pascal könnte man höchstens
    > ansehen, dass Pascal ursprünglich als Lehrsprache
    > entwickelt wurde und dadurch einige Einsatzgebiete
    > eher sporadisch implementiert sind. Dies kann man
    > aber zum Glück bei Bedarf durch Units
    > "nachrüsten".
    Eine Programmiersprache wäre auch komplett sinnlos, wenn man fehlende Funktionen nicht nachrüsten könnte (und zugegebenermaßen ist die Unterstützung für Modularisierung in C und C++ ziemlicher Mist).

  10. Re: Niklaus Wirth meint ...

    Autor: Hello_World 12.09.07 - 00:20

    Fragrüdiger schrieb:
    -------------------------------------------------------
    Du meinst die "Flexibilität", dass man praktisch nicht generisch programmieren kann und deswegen für alles mögliche void-Pointer verwendet? Na wem's gefällt...

  11. Re: Nachteile von Pascal gegenüber C/C++

    Autor: byti 12.09.07 - 08:58

    > C ist nicht wesentlich schneller als Pascal.

    Hab ich das behauptet? Ich weis wie schnell Pascal is... und es kommt auf das Programm an. Ok.. ich mit "ein bischen schneller" hätte ich es genauer getroffen. Gibt sogar Sachen die sind mit Pascal schneller... oder mit C 5mal Schneller. Im schnitte kannst sagen das C 10-30% schneller is.. aber hängt wie gesagt vom Programm ab. Aber das is eine "religiöse" Diskussion die schon 1000fach geführt wurde. Gibt’s hunderte von Tests und Charts im Netz.

    > Das hat exakt gar nichts mit der Sprache zu tun,
    > GUI-Designer gibt's auch für C (z. B. Glade) oder
    > VB.

    Ok... ich geht da jetzt eher von der MS-Fraktion und GUI Anwendungen aus. Hast du schon mal versucht ein VC-Programm zu schreiben? Ich mein.. mittlerweile geht’s einigermaßen.. aber vor ein paar Jahren war das ein Drama. C selber is ja einigermaßen Übersichtlich.. die Grundlagen der Programmiersprachen sind ja alle sehr ähnlich. Aber das gefuddel mit VC++ z.b. bis man da mal eine Stabile Anwendung hatte. Die ganze Zeigerei... pha.. Delphi ... klickklick.. 5 Zeilen und ich hab das was ich wollte. Ohne großartige Vorkenntnisse. (Grundlagen Programmieren vorausgesetzt) Und ich bekomm doch ne relativ schnelle EXE. Und bei Glade... musst auch wider Hand anlegen.

    > Wenn man so etwas behauptet, sollte man es belegen
    > (oder einfach aufhören, hier solchen Humbug zu
    > verbreiten).

    Lern erstmal Quoten. Was behauptet? Das Delphi... bzw. Pascal teilweise einen nicht ganz fertigen Eindruck macht? Muss ich garned, kannst alles nachgooglen. Arbeite mal mit Arrays, Threads und Netzwerkverbindungen... dann weist was ich mein. :) Ich weis auch garnicht was die Motzerei soll. Das sind allgemein bekannte Zustände. Das ganze is ja eh so komplex das man es nie richtig komplett wiedergeben kann. Deswegen die vereinfachte Aussage. Hilft dem Kerl nix, wenn ich ihn mit Parametern zudröhne.. der wollte ne Quick Info, mehr ned.

  12. Re: Nachteile von Pascal gegenüber C/C++

    Autor: byti 12.09.07 - 09:11

    > Die 10% die dir fehlen kannst ja dann in C/C++
    > coden und dann in dein Delphi Projekt einbinden
    > (mittels Librarys/DLLs). Dann haste auch deine 90%
    > Delphi, 10% C Lösung.

    Schon klar.. aber das is wieder eine Brückenlösung und kostet Zeit. Und ich hasse es Zeit beim Programmieren zu verschwenden. Geht doch auch anders.

    PHP zb. find ich ziemlich komplett. Ok.. das is jetzt kein richtiger vergleich PHP is ja vom Zweck und aufbau ganz was anderes. Aber da find ich immer das was ich brauch. Man merkt halt das die OpenSource Comunnity funktioniert. Lücken werden nach und nach gefüllt. Das fehlt mir bei Pascal/Delphi ein wenig.

  13. Re: Nachteile von Pascal gegenüber C/C++

    Autor: Hello_World 12.09.07 - 20:53

    byti schrieb:
    -------------------------------------------------------
    > Hab ich das behauptet?
    Ja, Du sagtest:
    "C => is am schnellsten," was einfach nicht stimmt, da man in Pascal alles machen kann, was ich C auch geht.
    > Hast du schon mal
    > versucht ein VC-Programm zu schreiben?
    Nein, aber schlechte Werkzeuge haben exakt gar nichts mit der Sprache zu tun. Fakt ist, dass es vernünftige GUI-Toolkits für praktisch alles Sprachen gibt.
    > Die ganze
    > Zeigerei... pha.. Delphi ... klickklick.. 5 Zeilen
    > und ich hab das was ich wollte.
    Das geht in C++ ganz genauso (in C habe ich nie GUI-Applikationen entwickelt).
    > Ohne großartige
    > Vorkenntnisse. (Grundlagen Programmieren
    > vorausgesetzt) Und ich bekomm doch ne relativ
    > schnelle EXE. Und bei Glade... musst auch wider
    > Hand anlegen.
    Hand anlegen muss man immer, wenn man programmieren will. Auch wenn einige Leute das zu denken scheinen, nehmen einem auch die besten Werkzeuge nicht das Programmieren ab.
    > Lern erstmal Quoten.
    Ich habe genau das zitiert, was ich zitieren wollte.
    > Was behauptet?
    Daß Delphi nur eine 90%-Lösung sei. Und genau das habe ich auch zitiert.
    > Das Delphi...
    > bzw. Pascal teilweise einen nicht ganz fertigen
    > Eindruck macht? Muss ich garned, kannst alles
    > nachgooglen.
    Mit anderen Worten: Du kannst es nicht belegen, weil es Blödsinn ist.
    > Arbeite mal mit Arrays, Threads und
    > Netzwerkverbindungen...
    Ähm, Arrays? Arrays sind in C nichts anderes als verkappte Pointer. In Pascal dagegen wird bounds-checking durchgeführt. Auch kann man in Pascal ein Array mz. B. mit dem Index 1 statt 0 beginnen lassen, was in C nicht geht. Threads und Sockets sind in der Laufzeitbibliothek enthalten, wobei sich das API nicht großartig vom C-Socket-API bzw. dem pthread-API unterscheidet.
    > Das ganze is
    > ja eh so komplex das man es nie richtig komplett
    > wiedergeben kann.
    Das ist eine verdammt schlechte Ausrede. Eine komplette Darstellung hat nie jemand gefordert, aber dennoch sollte man ein paar handfeste Vor- und Nachteile oder Unterschiede der Sprachen darstellen, wenn man schon so einen Vergleich ziehen will. Zwei dieser Unterschiede (bzgl. Arrays) habe ich ja oben schon genannt, aber es sind noch genug für Dich übrig.
    > Deswegen die vereinfachte
    > Aussage. Hilft dem Kerl nix, wenn ich ihn mit
    > Parametern zudröhne.. der wollte ne Quick Info,
    > mehr ned.
    Es hilft noch viel weniger, hier irgendwelches Gesülze zu schreiben, das erstens komplett jeder argumentativen Grundlage entbehrt und zweitens einfach falsch ist.

  14. Re: Nachteile von Pascal gegenüber C/C++

    Autor: byti 13.09.07 - 10:26

    >> Hab ich das behauptet?
    > Ja, Du sagtest:
    > "C => is am schnellsten," was einfach nicht stimmt,

    LANGSAM mein Freund. Nix verdrehen hier. Ich hab NICHT behauptet das C(++) WESENTLICH schneller ist wie Pascal (wie du versuchst mir in den Mund zu legen), sondern im Schnitt ein bischen schneller, abhängig von Code. Und ich weis jetzt auch nicht das der Käse soll. Das is schon 1000 mal durchgekaut worden. Es wurden Testkonstrukte mit gleicher/ähnlicher Funktion entworfen, auf alles Sprachen kompiliert und auf Geschwindigkeit getestet. Liest du keine Zeitschriften? Raus kommt immer das gleiche. Jeder Compiler hat seine Stärken und Schwächen, genaue Aussage nicht möglich. Auge mal PI.. C is am schnellsten, Pascal/Delphi kurz hinten dran, wesentlich langsamer is VB. Analog dazu is VC++ das komplizierteste, VB einfach.. Delphi eine mischung aus beiden. BTW.. ich red rein von Windowsumgebungen. Anderes BS .. andere voraussetzungen. Aber das deckt sich alles mit meinem Persönlichen Beobachtungen.

    > da man in Pascal alles machen kann, was ich C auch geht.

    Wos? Reden wir jetzt von geschwindikeit oder Features??!?!

    >> VC-Programm zu schreiben?
    > Nein,

    :) is jetzt ein Scherz. Du tust hier als währs der große Gott des Programmierens... und hast noch ned mal was mit VC compiliert?!?!?

    > aber schlechte Werkzeuge haben exakt gar nichts mit der Sprache zu tun.

    Ja sach mal.... Desto komplexer die Sprache, desto komplizierter die Werkzeuge. Das geht garned anders. Verknüpf mal in VC++ eine kompliziertere Form mit einem größeren stück Code. Der Editor kann dir nicht die ganzen Entscheidungen abnehmen die VC++ braucht.

    > Fakt ist, dass es > vernünftige GUI-Toolkits für praktisch alles
    > Sprachen gibt.

    Ja schöner Fakt.. hab ich was anders behauptet?

    >> Die ganze Zeigerei... pha.. Delphi ...
    >> klickklick.. 5 Zeilen und ich hab das was ich
    >> wollte.
    > Das geht in C++ ganz genauso (in C habe ich nie
    > GUI-Applikationen entwickelt).

    So.. mit was genau arbeitest du... bzw redest du? BS, Compiler, Toolkits.

    >> Und bei Glade... musst auch wider
    >> Hand anlegen.
    > Hand anlegen muss man immer, wenn man
    > programmieren will.

    Jesus... aber des is doch ein Unterschied wenn ich einen Button
    mit 2 Klicks zeichne Doppelklicke und msgbox("Hello World") reinschreibe und es geht.. oder wenn ich noch 20 zeilen Code und 10 Parameter einstellen muss.. wso jeder 2 Kritisch ist und die Andwendung abschmieren lassen könnte. C is halt ein Versuch Assembler verdaulich zu machen, und das merkt man ganz deutlich. Ned Umsonst heist es in Softwarefirmen, das ein VC++ entwickler mindestens 1 Jahr braucht "damit der Eier in der Hose hat." (Zitat einen entprechenden Abteilungsleiters)

    > Ich habe genau das zitiert, was ich zitieren
    > wollte.

    =:-o soviel zum Thema Nettiquette

    > Mit anderen Worten: Du kannst es nicht belegen,
    > weil es Blödsinn ist.

    Ich werd jetzt ned meine Zeit verblödln und dir x Beispiele weiterreichen, das mus reichen
    => http://de.wikipedia.org/wiki/Pascal_(Programmiersprache)#Nachteile
    => http://www.bernd-leitenberger.de/pascal-und-c.shtml

    >> ja eh so komplex das man es
    >> nie richtig komplett
    >> wiedergeben kann.
    > Das ist eine verdammt schlechte Ausrede.

    Ausrede für was?!?! Sag mal.. bist du irgendwie unsausgeglichen? Du versuchst mit aller Gewalt meine Posts zu zerpflücken, obwohl ich nur eine relativ Pauschale aussage gemacht hab. Es gibt zigtausend Variablen, die alles wider ganz anders aussehen lassen können. Betriebssystem, Codeaufbau, anforderungen an die Sicherheit, Einsatztzweck, portierbarkeit. Soll ich hier eine Dr.Arbeit draus machen?!?

    > und Nachteile oder Unterschiede der Sprachen
    > darstellen, wenn man schon so einen Vergleich
    > ziehen will.

    Ich soll jemand der ned mal den Grundlegenden Unterschied zwichen C und Pascal kennt, mit Zeiger, Typdeklarationen, Compilerdetails zuknallen? Ich hab auf SEINEN Post geantwortet, und nicht mit dir geredet. Bist a bisl sehr Ich-bezogen und eingenommen von dir selbst kann das sein?

    > Es hilft noch viel weniger, hier irgendwelches
    > Gesülze zu schreiben, das erstens komplett jeder
    > argumentativen Grundlage entbehrt und zweitens
    > einfach falsch ist.

    Sagt jemand der noch nie.. ned mal Testhalber einen VC++ Compiler angeworfen hat. :) FAKT ist
    * Assembler is sauschnell, extrem aufwendig, einfach Hardcore
    * C is sehr schnell aber komplex, (insbesondere C++ unc VC++)
    * Deplhi, Pascal is schnell aber guter Kompromiss zu Lernzeit/Ergebniss
    * VB is ziemlich einfach... und frist auch die unmöglichsten sachen, aber halt langsam (aber bei den CPUs heutzutage wohl eher nebensächlich)

    Die ganzen anderen Punke.. Portierbarkeit.. etc.. bitte bitte sparen wir uns das.


  15. Pointer und FreeBasic

    Autor: BastetFurry 30.09.07 - 15:43

    (Keine Direkte Antwort auf den OP...)

    Ich lese hier immer was von Pointern und Parameterübergabe durch Pointer und was auch immer und was da für Sch* bei passieren kann.

    Wieso meine ich das genau das in der, unter Profis, verpöhntesten Programmiersprache überhaupt am besten gelöst ist?

    Ich habe die Wahl, ich kann jedwede Art von Variable und Struktur als Pointer (ByRef) oder direkt als Wert (ByVal) übergeben, ich brauch also eigentlich garnicht mit Pointern arbeiten wenn ich nicht will.

    Das einzige was irgendwie gegen Basic spricht, ist sein Ruf.
    Bei den meisten Leuten steckt wohl immernoch
    10 PRINT "FOO!"
    20 IF A = B THEN GOSUB 30000
    30 GOTO 10
    fest.
    Völlig unberechtig.

    Und da ich grad dabei bin:
    "Wahh, Spagethicode!" <- GOTO und GOSUB nutzt keiner mehr. DO:LOOP, SELECT CASE. SUB, FUNCTION, etc. Alles was man von einer Modernen Programmiersprache gewohnt ist.

    "Wahh, wilde Variablen!" <- Schon mal was von OPTION EXPLICIT gehört? Ist in FB standardmäßig an und lässt sich nur in QB Kompatibilitätsmodus ausschalten ;)

    "Wahh, Interpreter! Knüppellahm!" <- FreeBasic, PowerBasic, BlitzBasic, ...... alles echte Compiler ohne Netz und doppelten Boden, der Erste auf der Liste arbeitet sogar mit GCC-Bibliotheken zusammen.

    Gebt Basic eine Chance, probierts aus und sagt dann was euch fehlt.
    In meinen Augen gibt es einfach keine schönere Programmiersprache als wie Basic.

  16. Re: Pointer und FreeBasic

    Autor: Dot 06.10.07 - 16:31

    Sorry, wenn ich uralte Postings auskrame, aber beim Stöbern muss ich hier doch noch einen Kommentar abgeben, weil ich es so nicht stehen lassen kann:


    BastetFurry schrieb:
    -------------------------------------------------------
    > Wieso meine ich das genau das in der, unter
    > Profis, verpöhntesten Programmiersprache überhaupt
    > am besten gelöst ist?

    Du sprichst von Basic, nicht wahr? Basic ist dafür ausgelegt, möglichst einfach zu sein und sich nicht mit Details auseinander setzen zu müssen. Was hier für Anfänger von Vorteil ist, lässt einem besonders bei größeren Projekten schnell an die Grenzen von Basic stoßen. Mehr dazu weiter unten.


    > Ich habe die Wahl, ich kann jedwede Art von
    > Variable und Struktur als Pointer (ByRef) oder
    > direkt als Wert (ByVal) übergeben, ich brauch also
    > eigentlich garnicht mit Pointern arbeiten wenn ich
    > nicht will.

    Das brauchst du glaube ich bei keiner Sprache, wenn du nicht willst.


    > Das einzige was irgendwie gegen Basic spricht, ist
    > sein Ruf.

    Nein, ich habe jahrelang selbst in (Q/Quick/Free)Basic programmiert, um sagen zu können, dass Basic vielen Anforderungen nicht gerecht werden kann. Klar, einfache Konsolenprogramme, die weder besonders schnell noch besonders komplex sein sollen, kann man genauso in Basic schreiben. Aber für alles andere wird es schnell unübersichtlich und/oder zu aufwändig. Zudem neigt Basic auf Grund seiner Syntax immer zu Spaghetticode, auch wenn es SUBs und FUNCTIONs kennt.


    > Und da ich grad dabei bin:
    > "Wahh, Spagethicode!" <- GOTO und GOSUB nutzt
    > keiner mehr. DO:LOOP, SELECT CASE. SUB, FUNCTION,
    > etc. Alles was man von einer Modernen
    > Programmiersprache gewohnt ist.

    ^-- siehe Absatz weiter oben


    > "Wahh, wilde Variablen!" <- Schon mal was von
    > OPTION EXPLICIT gehört? Ist in FB standardmäßig an
    > und lässt sich nur in QB Kompatibilitätsmodus
    > ausschalten ;)

    Das Problem bei Basic ist mehr, dass Variablen nicht zwingend spezifischen Datentypen zugeordnet sein müssen, d.h. im Extremfall kann a ein Byte, ein Long Integer oder gar ein String sein - und das macht es für den Compiler nahezu unmöglich, Fehler in den Variablenzuweisungen zu entdecken. Zudem ist OPTION EXPLICIT eine FreeBasic-spezifische Option, die du vermutlich in den meisten anderen Basic-Dialekten nicht finden wirst. Und ich weiß jetzt garnicht, ob Basic überhaupt Konstanten kennt.


    > "Wahh, Interpreter! Knüppellahm!" <- FreeBasic,
    > PowerBasic, BlitzBasic, ...... alles echte
    > Compiler ohne Netz und doppelten Boden, der Erste
    > auf der Liste arbeitet sogar mit GCC-Bibliotheken
    > zusammen.

    Es stimmt schon, Basic ist den meisten durch das bei DOS damals mitgelieferte QBasic als interpretierte "Scriptsprache" in Erinnerung geblieben, obwohl es durch QuickBasic, FreeBasic und ähnlichem sehr wohl Compiler gibt.

    Jedoch habe ich selbst schon konkret den Vergleich zwischen QuickBasic, FreeBasic und FreePascal machen können: Ein kompiliertes FreeBasic-Programm ist schon schneller als ein kompiliertes QuickBasic-Programm, jedoch sind nach FreePascal portierte Programme nochmal eine ganze Ecke schneller (in meinem Fall sogar etwa 8-10x so schnell). Entweder hatte ich damals in Basic so schlecht programmiert, oder es liegt an den Compilern (wobei der FreeBasic-Compiler angeblich Assembler-optimiert sein soll).


    > Gebt Basic eine Chance, probierts aus und sagt
    > dann was euch fehlt.

    Meiner Meinung nach im Prinzip alles, was Pascal ausmacht :)

    Es geht ja schon los, wenn ich übergebene Parameter abfragen will: Unter Basic müsste ich einen eigenen Parser schreiben, der die $COMMAND auseinanderpflückt, während ich unter Pascal bequem mit ParamCount und ParamStr arbeiten kann ... nur mal so als Beispiel ...

  17. Re: Pointer und FreeBasic

    Autor: BastetFurry 06.10.07 - 17:42

    Dot schrieb:
    > Das brauchst du glaube ich bei keiner Sprache,
    > wenn du nicht willst.

    Oh doch, wenn ich unter C mit Strings arbeite muss ich penibelst drauf achten Pointer zu schicken... soll das doch gefälligst der Compiler für mich machen, wofür hab ich diesen den? :)

    > > "Wahh, wilde Variablen!" <- Schon mal was
    > Das Problem bei Basic ist mehr, dass Variablen
    > nicht zwingend spezifischen Datentypen zugeordnet
    > sein müssen, d.h. im Extremfall kann a ein Byte,
    > ein Long Integer oder gar ein String sein - und
    > das macht es für den Compiler nahezu unmöglich,
    > Fehler in den Variablenzuweisungen zu entdecken.

    Öhm...
    Was ist an DIM a AS SHORT nicht spezifisch?
    Ok, es gibt ein DIM a AS ANY PTR, das ist aber dann in C ein void *a;
    Und brauchen tut man das nur für Dateipointer die nicht #1,#2,#... heißen und für die gfxlib als Bildpuffer.
    Übrigänse kann man seid, ich glaub, 0.15 direkt auf Bildpuffer zeichnen.

    DIM MyPic AS ANY PTR
    SCREENRES 800,600,32
    MyPic = IMAGECREATE(100,100)
    PSET MyPic,(15,15),RGB(255,255,255)
    PUT 30,30,MyPic
    DO:SLEEP 1:LOOP UNTIL INKEY <> ""

    Das SLEEP 1 sorgt dafür das FB die Kontrolle an das OS übergibt, ansonsten kommt das OS nur noch im Interrupt zum Zuge.

    > Zudem ist OPTION EXPLICIT eine
    > FreeBasic-spezifische Option, die du vermutlich in
    > den meisten anderen Basic-Dialekten nicht finden
    > wirst. Und ich weiß jetzt garnicht, ob Basic
    > überhaupt Konstanten kennt.

    VB hat das auch und man sollte es tunlichst auch an machen.
    Überdies ist es ab 0.17 in FB immer an.

    > Jedoch habe ich selbst schon konkret den Vergleich
    > zwischen QuickBasic, FreeBasic und FreePascal
    > machen können: Ein kompiliertes FreeBasic-Programm
    > ist schon schneller als ein kompiliertes
    > QuickBasic-Programm, jedoch sind nach FreePascal
    > portierte Programme nochmal eine ganze Ecke
    > schneller (in meinem Fall sogar etwa 8-10x so
    > schnell). Entweder hatte ich damals in Basic so
    > schlecht programmiert, oder es liegt an den
    > Compilern (wobei der FreeBasic-Compiler angeblich
    > Assembler-optimiert sein soll).

    Das Problem an FB ist das Konsolenausgabe Knüppellahm ist, was aber daran liegt das diverse QB45 Quirks simuliert werden müssen und die Bibliothek dann noch für 3 verschiedene Systeme rausgeben muss. DOS, Windows und Linux.
    Alles andere kann ohne Probleme mit diversen anderen Sprachen mithalten.
    Kannst ja mal ein SDL Testprogramm bauen, in FB und in FP, mal schaun wie weit dann der Unterschied ist.

    > Meiner Meinung nach im Prinzip alles, was Pascal
    > ausmacht :)

    Details bitte ;)

    > Es geht ja schon los, wenn ich übergebene
    > Parameter abfragen will: Unter Basic müsste ich
    > einen eigenen Parser schreiben, der die $COMMAND
    > auseinanderpflückt, während ich unter Pascal
    > bequem mit ParamCount und ParamStr arbeiten kann
    > ... nur mal so als Beispiel ...

    Und wie das geht!
    Ok, kein ParamCount, da muss man halt ziehen bis kein String mehr kommt, aber das ist doch wohl egal ob man jetzt nen FOR t = 1 TO ParamCount oder DO:LOOP UNTIL Parameter = "" macht.

    Siehe:
    http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgCommand

  18. Re: Pointer und FreeBasic

    Autor: Dot 06.10.07 - 18:46

    BastetFurry schrieb:
    -------------------------------------------------------
    > Oh doch, wenn ich unter C mit Strings arbeite muss
    > ich penibelst drauf achten Pointer zu schicken...
    > soll das doch gefälligst der Compiler für mich
    > machen, wofür hab ich diesen den? :)

    Ich bin jetzt kein C-Programmierer, aber dass man für Strings mit Pointern arbeiten muss, lese ich jetzt zum ersten Mal. Aber das soll mich nicht jucken :)


    > Was ist an DIM a AS SHORT nicht spezifisch?

    Ich habe nicht gesagt, dass man keine Variablen dimensionieren kann, sondern dass es in Basic nicht zwingend notwendig ist und demzufolge vom Compiler nicht nachprüfbar ist. Als ich mit Pascal angefangen hatte, war ich überrascht, was der Compiler alles feststellen konnte.


    > Das Problem an FB ist das Konsolenausgabe
    > Knüppellahm ist, was aber daran liegt das diverse
    > QB45 Quirks simuliert werden müssen und die
    > Bibliothek dann noch für 3 verschiedene Systeme
    > rausgeben muss. DOS, Windows und Linux.

    Ja, das ist mir auch aufgefallen, aber das bremst auch nur, wenn tatsächlich was ausgegeben wird. Aber selbst bei reinen Berechnungen ohne Konsolenausgabe waren FreeBasic-Programme deutlich langsamer als entsprechende FreePascal-Programme. Vielleicht lag es auch an der konkreten Implementierung.

    Davon abgesehen, was gibt es denn bei einer Konsolenausgabe zu "simulieren"? Entweder es lässt sich auf der Konsole abbilden oder nicht. FreePascal beherrscht die gleichen Konsolenausgaben (sogar mit den gleichen Farbcodes) und ist da deutlich schneller - und das auf wesentlich mehr Plattformen.

    Versteh mich nicht falsch, ich will dir FreeBasic nicht ausreden oder gar niedermachen. Aber das sind einfach meine Beobachtungen.


    > Und wie das geht!
    > Ok, kein ParamCount, da muss man halt ziehen bis
    > kein String mehr kommt, aber das ist doch wohl
    > egal ob man jetzt nen FOR t = 1 TO ParamCount oder
    > DO:LOOP UNTIL Parameter = "" macht.

    Oh, dann hat man das also inzwischen bei FreeBasic nachgerüstet. Als ich es zuletzt ausprobiert hatte, gab es nur den aus DOS-Zeiten bekannte $COMMAND-String, den man selber auseinanderpflücken musste.

  19. Re: Pointer und FreeBasic

    Autor: BastetFurry 06.10.07 - 19:56

    Dot schrieb:
    > > Was ist an DIM a AS SHORT nicht spezifisch?
    > Ich habe nicht gesagt, dass man keine Variablen
    > dimensionieren kann, sondern dass es in Basic
    > nicht zwingend notwendig ist und demzufolge vom
    > Compiler nicht nachprüfbar ist.

    Wie gesagt, FB verweigert die Annahme von nicht deklarierten Variablen.

    > Als ich mit Pascal
    > angefangen hatte, war ich überrascht, was der
    > Compiler alles feststellen konnte.

    Das hatte mich an Pascal als 11-jähriges Kiddie genervt, aber man wird ja älter und meist reifer ;)

    > Aber selbst bei reinen Berechnungen ohne
    > Konsolenausgabe waren FreeBasic-Programme deutlich
    > langsamer als entsprechende FreePascal-Programme.
    > Vielleicht lag es auch an der konkreten
    > Implementierung.

    Schick mal bei $PASTEDIENST nen Beispiel hoch, könnte das DevTeam von FB interessieren.

    > Versteh mich nicht falsch, ich will dir FreeBasic
    > nicht ausreden oder gar niedermachen. Aber das
    > sind einfach meine Beobachtungen.

    Ich würd auch nie jemanden FP madig machen wollen, aber ohne konkrete Beispiele kann man sich nicht an die Optimierung setzen.

    Mal schaun was das gibt mit dem GCC-C Frontend was da grade entwickelt wird damit FB endlich so fast alle Plattformen beglücken kann.
    Ich werd dann wohl mal testen in wie weit das ganze dann AVR-ATMega tauglich ist. Die RTLib ausschalten und ab gehts :)

    > Oh, dann hat man das also inzwischen bei FreeBasic
    > nachgerüstet. Als ich es zuletzt ausprobiert
    > hatte, gab es nur den aus DOS-Zeiten bekannte
    > $COMMAND-String, den man selber
    > auseinanderpflücken musste.

    Schau mal auf die Versionsnummer, das Teil ist zwar jetzt schon für Produktivarbeiten einsetzbar, aber bis zur 1.0 wird da noch sehr viel passieren und noch ne Menge bei kommen.
    OO ist Beispielsweise erst seid zwei Versionen offiziell mit dabei.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Produktmanager Enterprise IAM Services (m/w/d)
    Helios IT Service GmbH, Berlin-Buch
  2. IT-Einkäufer (m/w/d)
    Swiss Steel Edelstahl GmbH, Düsseldorf
  3. Netzwerkadministrator (m/w/d) Security
    Nürnberger Baugruppe GmbH + Co KG, Nürnberg
  4. IT-Sachbearbeitung (m/w/d)
    Niedersächsischer Landtag Landtagsverwaltung, Hannover

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 15,99€
  2. (u. a. Age of Empires Definitive Collection für 17,99€, Age of Empires Definitive Collection...
  3. 14,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de