Hallo,

Ihr werdet es nicht glaube, ein C++ - Entwickler hat sich hierhin verirrt

Ich hoffe Phobeus liest das hier!

Ich musste mich hier einfach anmelden, um paar Dinge richtig zu stellen.
Es betrifft die im Titel angegebene Lektion von Phobeus, er will ja auch Feedback haben
Was mich verärgert hat ist der Vergleich zwischen Delphi und C++.
Ich hab selbst mit Basic angefangen, dann Turbo Pascal, dann Delphi, C++, C++Builder, Java.

So nun zum Vergleich:
Delphi ist erstmal nicht wie C++ eher wie C++Builder von Borland, denn Delphi ist eine Rapid Application Development (RAD) - Umgebung.
D.h. man kann sich seine Fenster zusammenklicken (ich habe nichts gegen diese Art von Entwicklungsumgebung).
Wenn man schon Delphi mit C++ vergleichen will, dann muss man Pascal mit C++ vergleichen, denn Delphi verwendet Pascal als Programmiersprache.
Das C++ - Gegenstück zu Delphi ist wie schon erwähnt der C++ Builder.

Und weiter geht’s:
Warum muss man bei C++ hinter jedem Funktionsaufruf immer Klammern schreiben?
Ganz einfach, es dient dazu eine klare Syntaxstruktur zu waren.
Durch diese Klammern erkennt man immer, dass es sich um einen Funktionsaufruf handelt.
Ich finde es im Gegensatz zu Pascal (Delphi) so viel besser.
Wenn man wie in Pascal(Delphi) die Klammer hinschreiben oder auch weglassen kann, da kann man nicht mehr erkennen, ob es sich nun um eine Funktion oder eine Fehlgeleitete Variable handelt.

Weil es so schön ist, geht es weiter im Text
Warum findet man oft in C++ so was wie 1.0f ?
Es hat nichts damit zutun, dass der Compiler nicht erkennen kann, welchen Typ eine Funktion als Parameter erwartet!
Dann müsste man ja keine Typen mehr definieren (das Leben währe so viel einfacher
Der C++ - Compiler erkennt es schon, ob es sich um eine float- oder double-Zahl handelt, dass sagt ja schließlich der Parameter-Typ aus.
Warum machen es einige trotzdem so?
Nun, wenn man jetzt z.B. so was schreibt: x = 1.2 * 5
Der Compiler kann nun nicht erkennen, ob es bei 1.2 um eine float oder double - Zahl handelt, hier nimmt der Compiler einfach den voreingestellten Typ für eine Fließkommazahl.
Da von Compiler zu Compiler (es gibt so einige für jede Programmiersprache) die voreingestellten Typen unterschiedlich sind, sagt man den Compiler in einem solche Fall durch 1.2f, dass er diese Zahl als eine float-Zahl behandeln soll.
Das ist sehr praktisch, da nicht unnötige Rechenzeit verloren geht, wenn der Compiler standardmäßig double nehmen würde.
Diese Art der Definition gibt es auch für andere Typen.
Wie Pascal(Delphi) es nun macht, weis ich nicht genau, vielleicht wird da wohl unnötigerweise immer der größte Typ für Fließkommazahlen genommen, weil man es offensichtlich nicht definieren kann.
Mann kann natürlich bei beiden Programmiersprachen dem Compiler durch Einstellungen vorher mitteilen, wie er Fließkommazahlen zu behandeln hat.
Standardmäßig ist aber oft double eingestellt, was bei z.B. OpenGL bzw. Spielentwicklung zu rechenintensiv ist.
Warum einige bei Funktionsaufrufen sowas machen ist mir selbst ein Rätsel.
Es ist eigentlich total unnötig, da der Wert sowieso in den Typ der Parameter umgewandelt muss und auch wird.
Ist wohl mehr so ne Sache der Gewohnheit.

Ach und noch was:
Bei C++ kann man natürlich auch Funktionen überladen!
OpenGL hat es deshalb nur so mit den verschiedenen Funktionen für die eine und selbe Aufgabe gemacht, da man so sofort sieht, welche Typen und in welcher Menge bzw. Art als Parameter erwartet werden.
Es geht nicht immer darum, dass die und die Programmiersprache das Überladen nicht unterstützt, sondern es geht mehr darum die Lesbarkeit eines Quelltextes zu erhöhen.
Ich weis, dass Delphi eine Quelltextvervollständigung hat, halt RAD, da braucht man wohl nicht zu wissen, was ne Funktion als Parameter braucht, da es einem ja angezeigt wird.
Das gibt es übrigens auch für C++ und zwar beim C++ Builder
Aber nicht jeder will und kann solche Entwicklungsumgebung benutzen, deshalb hat man solche Schreibweisen für die möglichen Funktionen in OpenGL eingesetzt.

Schlusswort:
Übrigens, es wird schon seinen Grund haben, warum Betriebssysteme und viele kommerzielle Anwendungen in C++ und nicht in Pascal(Delphi) entwickelt werden.
OpenGL ist ja selbst in C (Vorgänger von C++) entwickelt worden

Hey, dass alles hier soll keine Beleidigung oder so sein, ich wollte einfach die Behauptungen in dem genannten Tutorial klarstellen.
Wie schon erwähnt habe ich auch mal in Delphi entwickelt, bin jedoch bei C++ bzw. bei dem C++ Builder gelandet.

Ich hoffe nur, dass Phobeus diesen blöden Vergleich aus dieser Lektion entfernt!
Ansonsten finde ich die Lektionen von Phobeus echt super, nur bitte keine solche Behauptungen mehr, besonders nicht, wenn du Phobeus nicht in C++ programmiert hast (in einer Lektion steht, dass du von Basic zu Delphi gekommen bist).

Ansonsten finde ich diese Seite bzw. die Tutorials echt super!
Die OpenGL-Tutorials hier sind besser als die von NeHe, da seine mit Quelltext überladen sind und meiner Meinung nach zu wenig auf das Warum eingehen.
Da ich mal in Pascal bzw. Delphi entwickelt habe, kann ich dies Sache auch sehr gut nach C++ bzw. C++ Builder portieren.

Noch was:
API heißt übrigens "Application Programming" Interface und nicht wie in der Lektion angegeben "Advanced Programmers Interface".

Übrigens, falls ich mit meinen Behauptungen falsch liege, dann lasse ich mich mit einer Begründung gerne korrigieren

Dabei wollte ich gar nicht so viel schreiben

atomic

Ich bin zwar nicht Phobeus aber da muss ich Contra geben:

In den Fällen wo der Compiler die Auswahl zwischen mehren ähnlichen Parametern geboten wird wie etwa bei OpenGL, kann man auch gleich die ensprechende Funktion(z.b Color3f(0,0,0) statt Color(0,0,0)) benutzen.

Ansonsten git es sehr wohl einen unterschied zwischen einfachen Pascal und Delphi. Das ist in etwa so als würdest du C und C++ Builder vergleichen.

MfG
IFlo

PS:Phobues erreichst du am schnellsten per eMail.

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Seit Version 7 heißt die Sprache tatsächlich Delphi Language und nicht mehr Object Pascal.
Außer wenn man das durch die FPU Flags ändert, rechnet der Prozessor immer mit 80 Bit und daher verwendet Delphi für die Zwischenergebnisse auch den Datentyp Extended. Die Klammern sind Ansichtssache, die Erklärung für API ist natürlich falsch. Bei C kann man noch keine Funktionen überladen und deshalb wird das wohl so mit den Funktionsnamen gemacht sein. Vermutlich wurde das in dem Text verwechselt.

Ich glaube es ist nicht nötig C++ verteidigen zu wollen/müssen.

Ich dachte es sein bekannt, dass Delphi seit einiger Zeit die offizielle bezeichnung für objekt Pascal ist. Und damit ist C++ mit Delphi und C mit (Turbo) Pascal vergleichbar.

Nebenbei, dieses kindische "meine Sprache ist besser weil..." diskussionen findet man zur genüge bei z.B. chip.de . Wies zur verbreitung von Sprache XY im Bereich Z kam ist doch in verbindung mit privaten Programmieren total unerheblich. Schätze wenn Phob hier Sticheleien richtung C++ gemacht hat, dann nur als Reaktion auf selbige... Phob is sonst eigentlich net der Typ für sowas, oder!?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Es war nicht in Verbindung mit einem Funktionsaufruf gemeint, sondern wenn man jetzt z.B. einer Variable X die folgende Formel zuweist X = 1.2 * 5.
Hier setzt der Compiler den eingestellten Standardtyp für Fließkommazahlen ein, wenn man es nicht durch z.B. 1.2f vordefiniert.
Wenn man einer Funktion als Parameter eine Zahl übergibt, dann weis natürlich der Compiler genau, welcher Typ eingesetzt wird und zwar der des ensprechenden Parameters.

Ich wollte damit folgendes aufklären:


Das steht so in der Lektion.
Da denkt man, das der Compiler zu blöd währe die Zahlen in den Typ der Parameter von der Funktion glColor3f umzuwandeln, was nicht korrekt ist.
Man kann ohne Probleme folgendes schreiben: glColor3f(1, 0.5, 0.5);
Und der Compiler wird es auch in die ensprechenden Typen umwandeln.

Zusätzlich wollte ich aufklären, warum man an einigen Stellen z.B. 1.2f schreibt, deshalb das Beispiel X = 1.2f * 5 (hier wird mit float gerechnet und nicht eventuell mit double).

Kurz gesagt die schreibweise glColor3f(1f, 0.5f, 0.5f) ist blödsinn, da der Compiler sowieso die Zahlen in den benötigten Typ umwandelt.
Es wurde nur so dargestellt, als ob man unter C++ der Funktion durch Angabe von glColor3f(1f, 0.5f, 0.5f) sagen muss, dass es sich um float-Werte handelt.
Dabei erwartet die Funktion glColor3f sowieso float-Werte und keine anderen, sonst wird sowieso automatisch in float konvertiert, falls man z.B. ganze Zahlen eingibt.



Du hast es genau falsch verstanden, wie ich es gemeint habe
Ich vergleiche Delphi nicht mit Pascal, nur Delphi verwendet als Programmiersprache Pascal oder Turbo Pascal (weis nicht genau).
Delphi ist bloß ne RAD-Entwicklungsumgebung, der Compiler von Delphi ist ein Pascal-Compiler!
Es wird nämlich in der Lektion Delphi mit C++ verglichen, was man nicht machen kann.
Denn somit wird eine Entwicklungsumgebung mit einer Programmiersprache verglichen.
Wenn man schon so einen Vergleich machen will, dann muss man Delphi mit C++Bilder vergleichen, da beides RAD-Entwicklungsumgebunden für jeweils die Programmiersprachen Turbo Pascal und C++ sind.

Natürlich kommen spezifische Befehle hinzu, die halt eine grafische RAD-Entwicklungsumgebung ausmachen aber die Syntax entspricht der angegebenen Programmiersprache.

Ok, falls Delphi als eigenständige Programmiersprache anerkannt ist, dann wusste ich es nicht.
Ich arbeite ja seit längerem nicht mit Delphi und gebe euch dann in dieser Hinsicht Recht

Nur das ein RAD-System (Delphi) mit einer Programmiersprache (C++) verglichen wird, stört mich schon.

Ich möchte mich auch nicht um die beste Programmiersprache streiten, nur meiner Meinung nach ungünstige Textpassagen in der entsprechenden Lektion aufdecken

Also cool bleiben

@Delphi<->C++: Du hast anscheinen mein Posting net gelesen. EDIT: anscheinen doch....

@C++ Syntax: Die Tutorials sind ja an Delphi programmierer gerichtet und sollen keine einführung in C++ sein. Phob wollte damit nur Delphi-OpenGL anfängern erklären, wieso C++-OpenGL Code manchmal anders aussieht, als er das in Delphi tut. Ich glaube nicht, dass er C++ verunglimpfen wollte. Wenn du die anderen Tuts durchliest wirst du feststellen, dass Phob ne sehr lockere Sprache hat und solche Details die nen Delphianer net interessieren auch nur sehr flapsich behandelt. Das hat nix mit böswill zu tun.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Flash war schneller als ich mit meinem Edit der letzten Message von mir
Also die Antwort ist eine Nachricht weiter oben

Erstmal danke für die ausführliche Antwort. Ich denke Du wirst gemerkt haben, dass die viele Texte von mir einen sarkastischen Unterton haben. Genau dem scheinst Du zum Opfer gefallen zu sein. Neben Delphi bin ich durchaus auch in der Lage C/C++ zu nutzen, sowie Java und einige andere exotische Skriptsprachen. Es ist also keineswegs so, dass ich nicht wüßte, wiorüber ich schreibe. Im Herzen bin ich allerdings stehts Pascaler geblieben.

Delphi ist seit neusten der Name für OOP. Umgangssprachlich oft eben Pascal genannt. Ich spreche von mir lieber als Pascaler als von einem OOP-Programmierer. Die direkten Vergleiche zwischen Sprachen fällt daher insgesamt stehts sehr schwer. Du musst bedenken, dass diese Seite primär dadurch entstanden ist, dass es keine Pascal-Ressourcen gab und eine Angliederung an C/C++-Gemeinden nicht möglich war. Wenn Du einige alte Mailinglisten durchgehst, wirst Du bei den Begriffen "Pascal und 3D" den unheimlichsten Spott finden. "Was willst den damit machen? Excel 3D oder was?" sind da noch harmlose Auswucherungen. Einige C/C++ler sind damals dermassen arrogant gewesen, dass sämtliche falsche Fakten durchaus als Real angenommen wurde. Bis heute glauben viele, dass Pascal langsamer sei als ein C/C++-Programm. Einen objektiven und praxisnahen Test hat mir bis heute niemand gebracht. Ich persönlich halte Pascal und C/C++ gar nicht für so fremd würde sogar fast von einer "Zwillingssprache" sprechen. Gerade wenn man es wagt auch andere Sprachen hinzuziehen, wird man zwischen den beiden Sprachen viele Gemeinsamkeiten erkennen.

Die entsprechenden Passagen sind nicht dazu gedacht um C/C++ schlecht zu machen, sondern vielmehr das Ganze aus der Sicht eines Pascalers zu erklären. Und das sind die unnötigen klammern alles andere als ästhetisch oder gar Struktur fördernd. Das ist sicherlich eine Geschmacksfrage, wenn ich Pfefferminztee mit Milch trinke, bekommen die meisten auch den Brechreiz. Ich denke, wenn Du die entsprechende Passage noch einmal mit einem lächelnden Auge aus der Sicht eines Pascalers betrachtest, wird Dir auffallen, dass keineswegs versucht wurde eine andere Sprache in den Dreck zu ziehen. "Macke" wurde nicht umsonst in Anführungszeichen gesetzt. Für einen Pascaler ist es schlicht und ergreifend eine Macke, wenn er einen Code nachbearbeiten muss, weil dieser diese "f" benötigt. glColor3f(1.0,1.0,1.0); ist aus der Sicht eines Pascalers absolut eineindeutig.

Z.B. Behaupte ich auch nicht, dass es Overload in anderen Sprachen nicht gibt Es ist auch durchaus klar, dass solche Dinge notwendig sind. Immerhin gibt es OpenGL-Portationen auf Sprachen, die nicht einmal Ansatzweise so etwas wie Datentypen kennen. (ja, auch sowas gibts ja)

Das mit der API stimmt hingegen vollkommen und ich werde auch regelmässig von Deja-vu's heimgesucht. Ich glaube den Fehler habe ich bereits vor 2 Jahren das erste Mal korrigiert und lade immer wieder eine alte Datei hoch. Wie dies damals reinkommen konnte, ist mir ebenso ein Rätsel und ich gelobe heilig, mich umgehend bei der nächsten Möglichkeit selbst zu beaschen

Übrigens, nur um es noch einmal ausdrücklich zu betonen. Auch wenn wir vorwiegend Pascaler sind, gerade die Älteren erinnern sich sicherlich noch daran, wie die meisten C/C++ler uns behandelt haben. Wir werden das sicherlich nicht wiederholen und sind daher eigentlich recht offen für jede Sprache (Basic und OpenGL muss ja nicht wirklich sein, aber... ). Dennoch wirst Du feststellen, dass wir z.B. im Wiki teilweise bewußt gegen die C/C++-Syntax sträuben und die von Pascal verwenden? Warum? Ich denke, es läßt sich schwer abstreuten, dass die Pascal-Struktur dichter am berühmten "Pseudo-Code" ist als jene von C. Ein DAU der "Begin" liest, weiß meistens worum es geht bei "{" gehört schon mehr wissen dazu, auch wenn es das gleiche ist.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Hallo,

danke Phobeus für deine aufklärende Antwort
Ich gehöre nicht zu den C++ - Menschen, die andere Programmiersprachen in den Dreck ziehen.
Jede Programmiersprache hat ihre Existenzrechte
Hab jetzt mal im Lexikon nachgeschaut, Delphi ist tastsächlich eine Programmiersprache und C++Builder und auch JBuilder sollen Entwicklungswerkzeuge für diese sein.
Dann erklärt sich es auch wohl, warum beim C++Builder auch viele *.hpp - Dateien eingebunden werden

Und ich finde auch nicht, das Pascal-Code langsamer ist als der von C, es währe auch blödsinn sowas zu behaupten.
Es liegt alleine am Compiler, was dieser an Maschienencode so generieret und warum sollte dieser für die gleiche Aufgabe unter Pascal als auch unter C anders aussehen

Trotzdem liebe ich diese Seite und ihre Tutorials, lasst uns einfach Freunde sein

Ja, in den letzten Jahren hat sich da auch viel getan, wohl schlichtweg dadurch, dass es doch zahlreiche Delphi-Projekte gab, die gezeigt haben, dass auch das möglich ist. z.B. ja Delphi2Quake. Wir hatten halt früher einfach keine Header um zu zeigen, was möglich ist und alle die an Delphi dachten, hatten im Hintergrund noch das alte TP BG. Das dann mit den neueren System zu vergleichen ist eben leicht unfair, den BGI war damals wohl auch die Geißel von Turbo C.
Und selten wurde ich bisher darüber in Kenntnis gesetzt, dass wildgewordene Mitglieder dieses Forums C/C++ler gesteinigt haben ( bekomme ja ehe nichts mit ).
Haben einige C/C++ler hier unter uns, die sich aber leider meistens sehr passiv verhalten. Schade eigentlich, den gerade im Wiki versuchen wir ja auch sprachübergreifende Begriff zu erklären

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."