PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Das ist das Ende von C++!


Gast
2007-01-04, 15:18:09
http://www.heise.de/newsticker/meldung/83145

Stone2001
2007-01-04, 15:22:11
Vorerst definitiv nicht!

Coda
2007-01-04, 15:44:19
Solange es keinen industrieweiten Support gibt ist das so gut wie tot für große Projekte.

Xmas
2007-01-04, 15:49:15
Und ich dachte schon es ginge um etwas neues...

D hat sich bisher kaum durchgesetzt, und ich sehe nicht warum es das nun plötzlich mit der Version 1.0 sollte. Dafür kommt es einfach einige Jahre zu spät. Nicht dass es gegenüber C++ keine Vorteile hätte, aber nicht genug um es abzulösen.

MadMan2k
2007-01-04, 15:51:50
Solange es keinen industrieweiten Support gibt ist das so gut wie tot für große Projekte.
für die OSS frickler wirds genügen und das sie sind die die Trends vorgeben... (Python, Ruby)
Dass C++ uns noch Jahrzente in irgendwelchem legacy code beglücken wird ist jedoch klar.

@Xmas:
das GNOME Projekt ist derzeit komplett In C/Gobject geschrieben und hat deswegen Probleme genug Contributer zu finden. C++ wär kein zu großer Fortschritt, da heutzutage da auch keiner Bock drauf hat. Hier kommt D wie gerufen...

Coda
2007-01-04, 16:41:59
Gibt's da schon Pläne, oder wie kommst du drauf?

MadMan2k
2007-01-04, 16:44:38
Gibt's da schon Pläne, oder wie kommst du drauf?
nö, keine pläne - aber so viel Auswahl haben die für die systemnahen Sachen wie gtk nicht:
Einerseits wollen dei Maintainer kein C++ und verweisen auf Qt andererseits gibts nicht genug Maintainer für gtk.
Die neuen Applikationen werden eh jetzt schon in python/c# geschrieben.

Coda
2007-01-04, 17:05:16
Naja wenn D offiziell in GCC enthalten ist vielleicht... Und was an gescheit geschriebenem C++ schlecht sein soll ist mir auch nicht ganz klar. Nur weil der Hype inzw. auf andere Sprachen übergegangen ist heißt das noch lange nicht dass C++ schlecht ist. Das Ding war seiner Zeit weit voraus.

Gast
2007-01-04, 17:35:28
Auch die Trennung des Quelltextes in Header- und Quelldateien ist nicht mehr notwendig.
Haha.
Uebersichtlichkeit ist damit nicht mehr vorhanden.

Wahrscheinlich ist Mehrfachvererbung auch noch verboten. X-D
Warum sollte man nicht stattdessen einfach auf CLI umsteigen?

tokugawa
2007-01-04, 17:37:15
Was immer vergessen wird:
C++ hält sich ja nicht deswegen weil es das beste überhaupt wäre. Neue Sprachen sind durchaus eleganter.

Aber in einem kann keine andere Sprache mit C++ mithalten: den industrieweiten Support auf jeder möglichen Plattform (jede Plattform kommt erstmal mit einem C++ Compiler).

Allein das sowie die Tatsache dass Libraries ebenfalls meistens zuerst für C++ kommen (und oftmals man entweder selbst mühsam Bindings für andere Sprachen machen müsste), ist ebenfalls der Grund, warum C++ Industriestandard ist.

Es ist ja nicht so dass C++ eine problemfreie Sprache ist; es gibt glaub ich kaum eine Sprache mit der man sich so in den Fuß schießen kann wie bei einigen C++-Konstrukten.

Aber hier zählt halt Pragmatismus: es wäre für viele Plattformen mühsamer mit anderen Sprachen, sich eine Codebasis aufzubauen die man auch wiederverwenden kann.

Ich spreche hier dediziert etwa von Entwicklung von Konsolen- und PC-Spielen, wo man oft versucht dieselbe Codebasis (zumindest für den Asset-Teil) zu verwenden, bzw wo auf den Plattformen sowieso nur C/C++ Compiler zur Verfügung stehen.

The_Invisible
2007-01-04, 17:49:56
nö, keine pläne - aber so viel Auswahl haben die für die systemnahen Sachen wie gtk nicht:
Einerseits wollen dei Maintainer kein C++ und verweisen auf Qt andererseits gibts nicht genug Maintainer für gtk.
Die neuen Applikationen werden eh jetzt schon in python/c# geschrieben.

ja, python/c# zusammen mit wxwidgets/sdl ist ganz nett. plattformunabhängig, man muss (fast) nicht auf die besonderheiten eines OSs achten und für 99% aller anwendungen schnell genug, von produktivität gar nicht zu reden.

ergo etwas neues muss mal her, was natürlich die hardcore c/c++ freaks garnicht freuen wird

mfg

tokugawa
2007-01-04, 19:52:07
ja, python/c# zusammen mit wxwidgets/sdl ist ganz nett. plattformunabhängig, man muss (fast) nicht auf die besonderheiten eines OSs achten und für 99% aller anwendungen schnell genug, von produktivität gar nicht zu reden.

ergo etwas neues muss mal her, was natürlich die hardcore c/c++ freaks garnicht freuen wird


Das hat mit "Freaks" nicht zu tun. Wenn man neue besser Tools für den Task findet, ist das schon ok.

Für viele ist das vernünftig und pragmatisch gesehen halt nicht sinnvoll. Es macht keinen Sinn etwa bei uns die Codebase auf C#, Python, oder was auch immer umzustellen, wenn die einzige sinnvolle Möglichkeit, auf DS/PS2/PS3/Xbox/Xbox360/Wii/GC/GBA zu programmieren (mit Wiederverwendung der Codebase) in C++ ist.

Das ist ja der Hauptgrund warum C++ immer noch der Industriestandard ist. Für Teilbereiche wo man keine solche "extremen" Plattformen hat, sind andere Sprachen sicher zielführender.

Coda
2007-01-04, 19:53:26
Ich werd für mein nächstes Projekt mal C++/CLI anschauen und die Oberfläche wohl mit C# coden.

tokugawa
2007-01-04, 20:00:09
Ich werd für mein nächstes Projekt mal C++/CLI anschauen und die Oberfläche wohl mit C# coden.

Dann könntest ja die Oberfläche gleich auch in C++/CLI machen, oder?

Demirug
2007-01-04, 20:07:28
Dann könntest ja die Oberfläche gleich auch in C++/CLI machen, oder?

Für C++/CLR gibt es aber keinen Form Designer. Eigentlich nimmt man C++/CLR primär um Wrapper für unmanaged Code zu schreiben.

Demirug
2007-01-04, 20:17:08
Für viele ist das vernünftig und pragmatisch gesehen halt nicht sinnvoll. Es macht keinen Sinn etwa bei uns die Codebase auf C#, Python, oder was auch immer umzustellen, wenn die einzige sinnvolle Möglichkeit, auf DS/PS2/PS3/Xbox/Xbox360/Wii/GC/GBA zu programmieren (mit Wiederverwendung der Codebase) in C++ ist.

In den höheren Schichten ziehen aber auch in der Games Branche vermehrt modernen Sprachen ein. Da ich jedoch ganz unten in der Kette bin führt aus den genannten Gründen bei mir kein Weg an C++ vorbei. Da ist sogar teilweise noch Assembler gefragt.

Trap
2007-01-04, 20:48:00
Es macht keinen Sinn etwa bei uns die Codebase auf C#, Python, oder was auch immer umzustellen, wenn die einzige sinnvolle Möglichkeit, auf DS/PS2/PS3/Xbox/Xbox360/Wii/GC/GBA zu programmieren (mit Wiederverwendung der Codebase) in C++ ist.
Jak and Dexter ist ein ziemlich erfolgreiches Gegenbeispiel (wenn man den Teilsatz in Klammern weglässt).

tokugawa
2007-01-04, 20:48:38
Für C++/CLR gibt es aber keinen Form Designer. Eigentlich nimmt man C++/CLR primär um Wrapper für unmanaged Code zu schreiben.

Das stimmt seit Visual Studio 2003 nicht mehr.

Ich hab schon Editoren mit Managed C++ in Visual Studio 2003 geschrieben, die einfach den Engine-Code als native static Library verwendet haben (mit It-Just-Works statt P/Invoke), aber eine .NET Windows Forms-basierte GUI.

Dasselbe geht in Visual Studio 2005 auch mit C++/CLI, obwohl ich deutlich mehr Probleme hatte (also "It Just Works" nicht mehr ganz zutrifft).

Aber Formdesigner haben beide Versionen.



In den höheren Schichten ziehen aber auch in der Games Branche vermehrt modernen Sprachen ein. Da ich jedoch ganz unten in der Kette bin führt aus den genannten Gründen bei mir kein Weg an C++ vorbei. Da ist sogar teilweise noch Assembler gefragt.

Klar, Editoren und Minitools und ähnliches werden bei uns auch schon in C# gemacht.

Aber es macht etwa keinen Sinn, echten Game/Engine-Code für den Nintendo DS in Python zu machen. Selbst für Game-Code (den ich als höhere Schicht seh als Engine-Code) wird C++ verwendet, ganz einfach weil es für Nintendo DS auch sonst keine sinnvollen Entwicklertools gibt außer jene die C++-basiert sind.

Das gilt etwas weniger für weniger limitierte Konsolen natürlich. Bei stärkeren Konsolen kann man sich gar interpretierte Skript-Sprachen für's game-scripting leisten :)


Ganz ohne C++ geht's aber nicht (jedes Scripting in jedweder Engine braucht ja auch eine Basis), gerade bei wiederverwendbaren Codebasen für verschiedene Plattformen, daher wird C++ nicht verschwinden, was ja der Hauptpunkt meiner Ausführung war.


Jak and Dexter ist ein ziemlich erfolgreiches Gegenbeispiel.

Details, bitte.

Welche Sprache verwendet es? Verwendet es diese Sprache runter bis zur Engine? Welches DevKit/Entwicklertools wurden dafür verwendet?

Und: Ist es ein Multiplattformspiel bei dem eine Codebasis wiederverwendet wurde (die überwiegende Mehrheit in heutigen Studios, da man sich's nicht wirklich leisten kann, alles von Grund auf neu zu schreiben für jedes einzelne Projekt)?

Demirug
2007-01-04, 21:06:27
Das stimmt seit Visual Studio 2003 nicht mehr.

Ich hab schon Editoren mit Managed C++ in Visual Studio 2003 geschrieben, die einfach den Engine-Code als native static Library verwendet haben (mit It-Just-Works statt P/Invoke), aber eine .NET Windows Forms-basierte GUI.

Dasselbe geht in Visual Studio 2005 auch mit C++/CLI, obwohl ich deutlich mehr Probleme hatte (also "It Just Works" nicht mehr ganz zutrifft).

Aber Formdesigner haben beide Versionen.

OK, in dem Fall nehm ich das zurück. Ich bin mir aber sicher das irgendwas da nicht richtig funktioniert hat und ich deswegen die Finger davon gelassen haben.

Klar, Editoren und Minitools und ähnliches werden bei uns auch schon in C# gemacht.

Aber es macht etwa keinen Sinn, echten Game/Engine-Code für den Nintendo DS in Python zu machen. Selbst für Game-Code (den ich als höhere Schicht seh als Engine-Code) wird C++ verwendet, ganz einfach weil es für Nintendo DS auch sonst keine sinnvollen Entwicklertools gibt außer jene die C++-basiert sind.

Das gilt etwas weniger für weniger limitierte Konsolen natürlich. Bei stärkeren Konsolen kann man sich gar interpretierte Skript-Sprachen für's game-scripting leisten :)


Ganz ohne C++ geht's aber nicht (jedes Scripting in jedweder Engine braucht ja auch eine Basis), gerade bei wiederverwendbaren Codebasen für verschiedene Plattformen, daher wird C++ nicht verschwinden, was ja der Hauptpunkt meiner Ausführung war.

Ja, die „Kleinen“ sind was die Toolauswahl angeht ja noch eine Generation hinter den großen Konsolen die ja schon gegenüber dem PC zurück liegen.

Derzeit habe ich aber nur den PC am Hals. Vielleicht kommt noch eine große Konsole dazu aber im Moment ist noch so viel für den PC zu machen das dafür gar keine Zeit ist.

The_Invisible
2007-01-04, 21:08:52
Das hat mit "Freaks" nicht zu tun. Wenn man neue besser Tools für den Task findet, ist das schon ok.

Für viele ist das vernünftig und pragmatisch gesehen halt nicht sinnvoll. Es macht keinen Sinn etwa bei uns die Codebase auf C#, Python, oder was auch immer umzustellen, wenn die einzige sinnvolle Möglichkeit, auf DS/PS2/PS3/Xbox/Xbox360/Wii/GC/GBA zu programmieren (mit Wiederverwendung der Codebase) in C++ ist.

Das ist ja der Hauptgrund warum C++ immer noch der Industriestandard ist. Für Teilbereiche wo man keine solche "extremen" Plattformen hat, sind andere Sprachen sicher zielführender.

da kann ich leider nicht viel sagen, da es hier aber sicher auf maximale geschwindigkeit ankommt ist eine interpretierte sprache sicher nicht erste wahl

bzw http://furryland.org/~mikec/bench/

ist zwar älter, aber wird sich wohl nicht viel verändert haben (interessant wäre noch python mit psyco modul, bringt oft nen schönen schub)

mfg

Gast
2007-01-04, 21:12:45
Das stimmt seit Visual Studio 2003 nicht mehr.
Seit WPF stimmt das nun temporär auch mit VS 2005 wieder.
Allerdings kann man sich drumrum mogeln oder externe XAML Designer benutzen, die dafür noch wesentlich besser sind.

Ansonsten sehe ich keinen Grund der für C#, aber nicht für CLI spricht.
Es ist einfach eine schöne Sprache.

No.3
2007-01-04, 21:13:08
Das ist ja der Hauptgrund warum C++ immer noch der Industriestandard ist.

und genau deswegen quälen sich noch viele Firmen mit Fortran o.ä. rum und haben ständig irgendwelchen Ärger damit...

Trap
2007-01-04, 21:13:44
Details, bitte.

Welche Sprache verwendet es? Verwendet es diese Sprache runter bis zur Engine? Welches DevKit/Entwicklertools wurden dafür verwendet?
Alles selbstentwickelt

http://franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003798.html
http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003789.html

Multiplattform ist es aber nicht, vom Konzept her wäre das allerdings auch auf Multiplattform-Titel übertragbar.

MadMan2k
2007-01-04, 22:48:15
Was immer vergessen wird:
C++ hält sich ja nicht deswegen weil es das beste überhaupt wäre. Neue Sprachen sind durchaus eleganter.
mir ist jetzt bis auf D keine andere Sprache bekannt die irgendwie besser als C++ wäre und gleichzeitig für Systemprogrammierung geeignet wäre. Java, C#, Python - alles schön, aber wegen der VM ungeeignet.
C/Gobject, ObjectiveC - schnell genug, aber nicht wirklich besser als C++ - höchstens anders ;)

Coda
2007-01-04, 22:48:45
Über die Zurechnungsfähigkeit von Leuten, die Lisp bevorzugen, lässt sich sehr streiten.

Lässt sich das über Programmierer nicht generell sagen? :D

No.3
2007-01-04, 22:57:39
mir ist jetzt bis auf D keine andere Sprache bekannt die irgendwie besser als C++ wäre und gleichzeitig für Systemprogrammierung geeignet wäre. Java, C#, Python - alles schön, aber wegen der VM ungeeignet.
C/Gobject, ObjectiveC - schnell genug, aber nicht wirklich besser als C++ - höchstens anders ;)

was verstehst Du unter "System"-programmierung? Ein Betriebsystem? Da rulerz Assembler ;) oder noch besser BPCL :biggrin:

The_Invisible
2007-01-04, 22:59:20
was verstehst Du unter "System"-programmierung? Ein Betriebsystem? Da rulerz Assembler ;) oder noch besser BPCL :biggrin:

ich meine er meint hardwarenahe programmierung

mfg

No.3
2007-01-04, 23:05:39
ich meine er meint hardwarenahe programmierung

mfg

in diesem Fall ist C++ sicherlich nicht besser als C oder eine andere ähnliche Hochsprache sei es nun Pascal, Modula, Oberon, etc

Coda
2007-01-04, 23:06:07
Was soll denn BPCL sein?

in diesem Fall ist C++ sicherlich nicht besser als C oder eine andere ähnliche Hochsprache sei es nun Pascal, Modula, Oberon, etc

Wieso nicht?

No.3
2007-01-04, 23:09:37
Was soll denn BPCL sein?

versuchs mal mit Buchstabendreher ;)

-> BCPL


Wieso nicht?

hab mich bislang immer um C++ gedrückt, was macht C++ denn systemnaher?

Trap
2007-01-04, 23:12:50
mir ist jetzt bis auf D keine andere Sprache bekannt die irgendwie besser als C++ wäre und gleichzeitig für Systemprogrammierung geeignet wäre. Java, C#, Python - alles schön, aber wegen der VM ungeeignet.
VM ist nur eine Variante der Sprachimplementierung. Schreib ne andere und du kannst auch Systemprogrammierung mit machen, siehe z.B. http://research.microsoft.com/os/singularity/

Coda
2007-01-04, 23:37:48
hab mich bislang immer um C++ gedrückt, was macht C++ denn systemnaher?

Nichts. Aber sie ist dafür trotzdem geeigneter auf Grund von besseren Sprachfeatures.

MadMan2k
2007-01-04, 23:42:30
Schreib ne andere und du kannst auch Systemprogrammierung mit machen
schon klar, aber hier ist mir bis jetzt nur gcj bekannt. Und da sieht man dass es mit dem schreiben alleine nicht getan ist. Wenn die Sprache einen GC vorraussetzt verbraucht man automatisch mehr Speicher als mit C++.

Gast
2007-01-04, 23:44:45
was verstehst Du unter "System"-programmierung? Ein Betriebsystem? Da rulerz Assembler ;) oder noch besser BPCL :biggrin:

Alle aktuell bekannten Systeme sind in C, zumindest Kernel, System API usw. Natürlich verwendet man dort auch Inline Assembler, aber ein System in puren Assembler ist doch Quark, da nicht praktikabel (Aufwand, Wartung, Kapselung usw.).

del_4901
2007-01-04, 23:48:34
Alle aktuell bekannten Systeme sind in C, zumindest Kernel, System API usw. Natürlich verwendet man dort auch Inline Assembler, aber ein System in puren Assembler ist doch Quark, da nicht praktikabel (Aufwand, Wartung, Kapselung usw.).

Inline ASM sollte man auch da nicht nutzen. Die einzige Stelle in einem OS wo man um ASM nicht drum rumkommt, ist ein Contextwechsel. Und hier handelt es sich um 5-10 Befehle.

Trap
2007-01-05, 00:00:08
Wenn die Sprache einen GC vorraussetzt verbraucht man automatisch mehr Speicher als mit C++.
Zu manueller Speicherverwaltung gegenüber GC gibt es einige Studien. Programme verbrauchen etwas mehr Speicher (ganz grob 50%) und minimal mehr CPU-Zeit (5-10%) wenn man sie ohne konzeptionelle Änderungen von manuellem Management auf einen aktuell üblichen GC (wie Böhm) umstellt.

Nichts dramatisches also, mit etwas angepasstem Programmierstil kann man das großteils kompensieren.

Coda
2007-01-05, 00:45:40
Böhm ist nicht aktuell üblich, sondern großer Bullshit. Das Ding ist konservativ - musste ich auch erst raffen.

Coda
2007-01-05, 00:47:28
Inline ASM sollte man auch da nicht nutzen. Die einzige Stelle in einem OS wo man um ASM nicht drum rumkommt, ist ein Contextwechsel. Und hier handelt es sich um 5-10 Befehle.

Also zumindest bei x86(-64) muss man den Startup-Code und noch andere Dinge (MTRR und son Kram) schon mit Assembler erledigen.

Trap
2007-01-05, 00:57:55
Böhm ist nicht aktuell üblich, sondern großer Bullshit. Das Ding ist konservativ - musste ich auch erst raffen.
Das kann man auch weniger dogmatisch sehen, praktisch macht das selten einen Unterschied. Ist halt ein Kompromiss den man eingehen muss um ohne Änderungen am Compiler einen GC für C++ zu bekommen. Ist eine bewusste Designentscheidung, kein Fehler.

In allen anderen Eigenschaften ist Böhm ein aktueller GC und solange man in den Testfällen nicht größere Mengen an Speicher durch konservatives Verhalten verliert, sind die Ergebnisse die man mit Böhm bekommt auch auf andere GCs übertragbar.

rotalever
2007-01-05, 12:10:20
da kann ich leider nicht viel sagen, da es hier aber sicher auf maximale geschwindigkeit ankommt ist eine interpretierte sprache sicher nicht erste wahl

bzw http://furryland.org/~mikec/bench/

ist zwar älter, aber wird sich wohl nicht viel verändert haben (interessant wäre noch python mit psyco modul, bringt oft nen schönen schub)

(Naja, ich hatte da aber noch wesentlich drastischere Ergebnisse. Zwar hab ich C statt C++ verwendet, aber ein C Programm, welches dem Python Programm (welches sogar schon unter hinzunahme von Arrays:Numeric/Numarray/Numpy), exakt bis auf den Syntax glich war mehr als den Faktor 100 schneller! Teilweise hatte ich auch einmal in anderen Bereichen den Faktor 1000 locker drin (ohne sonstige Optimierung). Da sieht man dass Python und solche Sprachen ja ganz nett sind, aber wenn große Datenmengen etc. verarbeitet werden kann man es einfach vergessen. Wohl ein Grund warum die meisten heutigen Programme immer in C/C++ geschrieben worden sind.)

Edit: Hmm, hatte wohl die anderen Spalten in der Tabelle übersehen.... Wobei die Programme etwas kurz sind, die Frage ist, ob das C Programm überhaupt so ausgeführt wird, da ja nicht wirklich etwas berechnet wird, könnte auch sein, dass der Compiler die Schleife wegoptimiert....

aths
2007-01-05, 12:22:56
http://www.heise.de/newsticker/meldung/83145
Es wäre guter Stil, zu einer Überschrift nicht nur einen Link zu posten, sondern auch noch in eigenen Worten kurz zu beschreiben, worum es geht.

Trap
2007-01-05, 13:55:20
da kann ich leider nicht viel sagen, da es hier aber sicher auf maximale geschwindigkeit ankommt ist eine interpretierte sprache sicher nicht erste wahl

bzw http://furryland.org/~mikec/bench/
Aktuelle Benchmarks zwischen den verschiedenen Sprachimplementierungen gibt es z.B. da:
http://shootout.alioth.debian.org/

Corrail
2007-01-05, 14:21:16
mir ist jetzt bis auf D keine andere Sprache bekannt die irgendwie besser als C++ wäre und gleichzeitig für Systemprogrammierung geeignet wäre.

Ich muss ehrlich sagen, ich hab mich mit D nur oberflächlich beschäftigt, aber wo soll D besser sein als C++ (Syntaktik ausgenommen)?

MadMan2k
2007-01-05, 16:41:35
Ich muss ehrlich sagen, ich hab mich mit D nur oberflächlich beschäftigt, aber wo soll D besser sein als C++ (Syntaktik ausgenommen)?
also fehlender präprozessor und keine header dateien reichen mir eigentlich schon. Ich mein man kann auch C Objektorientierung über den Präprozessor beibringen, womit C++ bis auf die Syntax nicht besser wär - aber will man das?

Coda
2007-01-05, 17:24:06
also fehlender präprozessor und keine header dateien reichen mir eigentlich schon.

Mir nicht. Ich muss den Präprozessor ja nicht verwenden außer für die Header - und die stören mich nicht. Ganz im Gegenteil eigentlich.

Ich mein man kann auch C Objektorientierung über den Präprozessor beibringen, womit C++ bis auf die Syntax nicht besser wär - aber will man das?

Will sehen wie du multiple inheritance über macros hinbekommst. Viel Spaß.

Corrail
2007-01-05, 19:18:09
Objektorientierte Programmierung mit Makros in C? Da wäre ich vorsichtig...
Und wie schauts mit Templates aus? Ob du die soweit nur mit Makros hinbekommst, dass du echt meta- und funktional programmieren wage ich zu bezweifeln...

MadMan2k
2007-01-05, 19:26:17
Objektorientierte Programmierung mit Makros in C? Da wäre ich vorsichtig...
Und wie schauts mit Templates aus? Ob du die soweit nur mit Makros hinbekommst, dass du echt meta- und funktional programmieren wage ich zu bezweifeln...
falls es dich interessiert, findest du hier mehr darüber:
http://de.wikipedia.org/wiki/GObject

No.3
2007-01-05, 19:39:49
Nichts. Aber sie ist dafür trotzdem geeigneter auf Grund von besseren Sprachfeatures.

hm, kay, kann ich mir nur schwer vorstellen

andereseits hab ich nicht die Zeit und die Lust mich näher mit C++ zu beschäftigen, drum belasse ich es einfach mal.

Aber D werd ich mir trotzdem mal anschauen, vielleicht bringt das mal ein wenig Wind in die verstaubten Programmiersprachen.

FlashBFE
2007-01-05, 20:12:02
Was mich am meisten stört ist, dass schonwieder diese scheußliche C-Syntax in eine weitere Programmiersprache gewandert ist. Diese (){;;;}-Ich-Schreibe-Ein-Buch-Voller-Sonderzeichen-Syntax ist ist ein tierischer Produktivitätskiller (für mich).
Ich hab mich erst gefreut, als ich "keine Headerdateien", "elegantere Programmierung" und "keine Altlasten" gelesen habe. Dann hab ich bei denen auf die Website geguckt und war doch wieder enttäuscht: Der gleiche Käse wie schon gehabt.

Wenn die schon ganz vorne anfangen, warum dann nicht auch bei der Syntax?

Ganon
2007-01-05, 20:17:39
Sieht ganz Interessant aus. Werde ich im Auge behalten. Da es aber bisher nicht wirklich ausgereifte IDEs dafür gibt, noch irgendwie offizielle Librarays oder Bindings, warte ich erst mal noch, bis das Ganze etwas reifer geworden ist.

tokugawa
2007-01-05, 20:29:43
OK, in dem Fall nehm ich das zurück. Ich bin mir aber sicher das irgendwas da nicht richtig funktioniert hat und ich deswegen die Finger davon gelassen haben.


Ich kann mir denken wieso... sobald die Form etwas mehr Controls hat, wird der Formdesigner beim rumspringen zwischen Code und Designer extrem langsam (braucht lang um den C++ Code zu parsen und auf Änderungen zu reagieren). Zumindest flutscht es nicht so wie in C#.


Ja, die „Kleinen“ sind was die Toolauswahl angeht ja noch eine Generation hinter den großen Konsolen die ja schon gegenüber dem PC zurück liegen.

Derzeit habe ich aber nur den PC am Hals. Vielleicht kommt noch eine große Konsole dazu aber im Moment ist noch so viel für den PC zu machen das dafür gar keine Zeit ist.

Jo, bei uns ist es so dass wir eine bestimmte Codebasis haben die in jedem Projekt verwendet wird. Sowas muß natürlich in C++ geschrieben werden, weil sprachlich ist C++ quasi der gemeinsame Nenner aller Plattformen. Ich kann mir denken dass viele Multiplattform-Entwickler ähnliche Strategien verfolgen.

Bei Titeln für einzelne Plattformen hat man dann natürlich mehr Auswahlfreiheit. Für ein reines PC-Projekt etwa (oder gar PC-Xbox360) tät ich sogar C# erwägen (zumindest sobald C#/XNA für die Xbox360 etwas extensiver nutzbar ist).

da kann ich leider nicht viel sagen, da es hier aber sicher auf maximale geschwindigkeit ankommt ist eine interpretierte sprache sicher nicht erste wahl


Ja, und es ist auch ähnlich wie eine Reihe an Domino-Steinen... wenn eine Plattform quasi C++ aufgrund der Performance-Charakteristik erfordert, und man aber die Codebasis wiederverwendet, müssen folglich auch die "größeren" performanteren Plattformen ebenfalls über C++ programmiert werden.

Das war quasi mein Hauptpunkt: es gibt gar nicht so wenige Entwickler, die eine Codebasis haben die auf mehreren Plattformen funktionieren muß. Und oft ist C++ der gemeinsame Nenner dieser Plattformen. Daher glaube ich nicht dass C++ in nächster Zeit verschwinden wird.


Alles selbstentwickelt

http://franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003798.html
http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003789.html

Multiplattform ist es aber nicht, vom Konzept her wäre das allerdings auch auf Multiplattform-Titel übertragbar.

Das klingt sehr danach als wär die Grund-Engine trotzdem in C/C++/Assembler, und Lisp quasi als Scripting/Control-Sprache verwendet für diverse Aufgaben wie Animation. Ah ja, der zweite Link spricht eh von einer Integration mit Assembler.

Klarerweise kann man dieses Beispiel nicht allgemein übertragen; welches Entwicklerstudio kann sich schon leisten komplett eigene Compiler, Debugger, usw. zu schreiben?

Zumal idealerweise auch diese Compiler/Linker/Debugger auch verbindet mit dem DevKit - also dass das Debugging über DevKit einfach möglich ist (die meisten DevKits heutzutage haben etwa Visual Studio-Integration).

Also ist das wohl eher ein Exotenbeispiel als etwas was sich auf andere Studios übertragen lässt. Letztendlich wollen wir ja Spiele entwickeln, und nicht Compiler schreiben.

Das ganze multipliziert sich nochmals wenn man das auf Multiplattform überträgt (Compiler, Linker, Debugger, DevKit-Integration für jede Plattform).

mir ist jetzt bis auf D keine andere Sprache bekannt die irgendwie besser als C++ wäre und gleichzeitig für Systemprogrammierung geeignet wäre. Java, C#, Python - alles schön, aber wegen der VM ungeeignet.
C/Gobject, ObjectiveC - schnell genug, aber nicht wirklich besser als C++ - höchstens anders ;)

Ich meinte ja auch allgemein als Sprache an sich. Klar dass C++ seinen ganz eigenen Stellenwert in der Systemprogrammierung hat. Trotzdem liegt die Stärke von C++ meiner Ansicht nach am meisten in der Verbreitung auf jeder Plattform. Das "Codebasis einmal schreiben, und man kann ihn für viele Plattformen verwenden"-Paradigma wird zwar oft durch Compiler-Seltsamheiten sabotiert, aber in der Mehrzeit trifft es trotzdem zu und ist durchaus ein Argument für C++ als Industriestandard.

Ich muss ehrlich sagen, ich hab mich mit D nur oberflächlich beschäftigt, aber wo soll D besser sein als C++ (Syntaktik ausgenommen)?

Darum geht's ja. Die Syntax (und Semantik) ist durchaus wichtig. Bei C++ kann man sich in extrem vielen Varianten in den Fuß schießen dass es nicht mehr schön ist.

The_Invisible
2007-01-05, 20:43:10
Was mich am meisten stört ist, dass schonwieder diese scheußliche C-Syntax in eine weitere Programmiersprache gewandert ist. Diese (){;;;}-Ich-Schreibe-Ein-Buch-Voller-Sonderzeichen-Syntax ist ist ein tierischer Produktivitätskiller (für mich).
Ich hab mich erst gefreut, als ich "keine Headerdateien", "elegantere Programmierung" und "keine Altlasten" gelesen habe. Dann hab ich bei denen auf die Website geguckt und war doch wieder enttäuscht: Der gleiche Käse wie schon gehabt.

Wenn die schon ganz vorne anfangen, warum dann nicht auch bei der Syntax?

wie hättest du es den gern? python like?

wobei ich mich nicht entscheiden kann was besser ist, c syntax oder python syntax.

ich bekomm oft das haare raufen wenn ich python code zwischen verschiedenen editoren kopiere und auf einmal die ganzen einrückungen nicht mehr stimmen, vor allem bei >1000 zeilen code.

da gönn ich mir schnell ne tasse kaffee um mich zu beruhigen :D

mfg

No.3
2007-01-05, 20:47:27
Was mich am meisten stört ist, dass schonwieder diese scheußliche C-Syntax in eine weitere Programmiersprache gewandert ist. Diese (){;;;}-Ich-Schreibe-Ein-Buch-Voller-Sonderzeichen-Syntax ist ist ein tierischer Produktivitätskiller (für mich).

jou, das ist so mit der allernervigste Punkt an C - leyder wurde E nie richtig gross und für den PC portiert

Coda
2007-01-05, 21:07:46
Auf der englischen Tastatur sind das eben keine Sonderzeichen...

Coda
2007-01-05, 21:10:16
Das klingt sehr danach als wär die Grund-Engine trotzdem in C/C++/Assembler.

Nope. Ist alles GOAL.

No.3
2007-01-05, 21:10:41
Auf der englischen Tastatur sind das eben keine Sonderzeichen...

aber bestimmt auch keine Sprachzeichen

Coda
2007-01-05, 21:37:37
Macht doch nix solang man sie ohne Shift erreicht :|

Also mir ist { tausend mal lieber als BEGIN oder son Müll.

FlashBFE
2007-01-05, 21:42:02
wie hättest du es den gern? python like?

wobei ich mich nicht entscheiden kann was besser ist, c syntax oder python syntax.

ich bekomm oft das haare raufen wenn ich python code zwischen verschiedenen editoren kopiere und auf einmal die ganzen einrückungen nicht mehr stimmen, vor allem bei >1000 zeilen code.

Von mir aus könnt ihr jetzt mit Steinen schmeißen, aber ich mache VB.NET. Auch aus Überzeugung. Und das nachdem ich jeweils mehr oder weniger mit Delphi, VBA, verschiedenen C-Dialekten, Assembler, C++, Java und C# gearbeitet habe. Vor allem im direkten Vergleich zwischen VB.NET und C# sehe ich, wieviel schneller ich alleine beim Tippen bin (VS2005 hilft da auch stark mit). Dass VB wesentlich leichter zu lesen und zu lernen ist, brauche ich glaube ich nicht extra betonen.

Die optimale Programmiersprache wurde aber noch nicht erfunden, wahrscheinlich auch, weil dahinter zuviele Ideologien stecken.

Gauron Kampeck
2007-01-05, 21:54:59
Also mir ist { tausend mal lieber als BEGIN oder son Müll.
Volle Zustimmung. Je schneller und kürzer die Kontrollstrukturen und Schlüsselwörter in einer Sprache, desto flüssiger kann man darin schreiben. Ok - es muss nicht unbedingt so kurz wie Brainfuck sein:wink: - aber Programmieren in Pascal/Delphi ist meiner Meinung nach ziemlich zäh. Die C-Syntax hat, wie ich finde, dort den besten Mittelweg gefunden. Dass eine Programmiersprache einfacher zu verstehen wäre, wenn die Syntax sich der normalen Gebrauchssprache annähert, ist ein großer Irrtum, da man dann oft den Wald vor Bäumen nicht mehr sieht, sprich der eigentliche Algorithmus in einem Schlüsselwortmeer ertrinkt...

Coda
2007-01-05, 22:11:29
Dass VB wesentlich leichter zu lesen und zu lernen ist, brauche ich glaube ich nicht extra betonen.

Ist es nicht. C# und VB.NET sind praktisch nur unterschiedliche Semantik für die gleiche Sache. Und wie Gauron schon sagte: Es ist ein Vorteil "{" statt "BEGIN" zu schreiben, wenn man sich erstmal daran gewöhnt hat. Schneller zu schreiben und hebt sich vom restlichen Code viel besser ab.

Ich kenne keine neue Sprache mehr die so eine Prosa-Syntax wie VB hat. Schreibt eure Programme doch gleich in COBOL X-D

Was aber z.B. ultra-nervig ist ist das $ bei den PHP-Variablen. Da könnt ich durchdrehen.

AlphaTier@work
2007-01-05, 22:12:20
Macht doch nix solang man sie ohne Shift erreicht :|

Also mir ist { tausend mal lieber als BEGIN oder son Müll.

Das kann ich so unterschrieiben!

Solln die C-Syntax-Hasser doch in VB.net oder Object-Pascal programmiern.
*nackenhaareaufstell*

tokugawa
2007-01-05, 22:19:34
Naja ich würd sagen das ist Ansichtssache/Geschmackssache.

Ich präferiere die C-like Syntax auch, obwohl C/C++ Code schon unglaublich unlesbar sein kann. Man kann sie aber auch leserlich schreiben.

Dasselbe gilt für Pascal/Delphi auch (man kann es etwa auch so tippen dass sich begin...end-Blöcke gut abheben). Und man kann darin auch schnell schreiben.

Ist alles Gewohnheitssache, wirklich. Und es gibt auch innerhalb einer Sprache verschiedene Coding Styles, die sich wie Nacht und Tag unterscheiden (obwohl das letztendlich Konventionssache im Projektteam sein wird).

Ganon
2007-01-05, 22:26:38
Das Begin/End in Pascal/Delphi kann ich echt nicht leiden. Wenn man dann mal so ein paar "komplexere" Methoden hat, dann kann man sich vor Begin und Ends gar nicht mehr retten. Zu allem Überfluss stellt die Delphi-IDE die Wörter auch noch fett dar.

Xmas
2007-01-05, 22:27:04
Gut lesbaren Code zu erzeugen sollte Sache der IDE sein.

Aber was ist an Header-Dateien gut?

tokugawa
2007-01-06, 00:12:21
Gut lesbaren Code zu erzeugen sollte Sache der IDE sein.


Da gibt's ja wieder zwei Ebenen (analog zu Syntax und Semantik). Einerseits wie man die Zeichen setzt (Einrückungen, usw.). Das schaffen IDEs bzw. "Prettyfier" einigermaßen.

Aber was ich auch meine ist Lesbarkeit in der Semantik des Codes, das enthält Dinge wie Symbol-Benennungen, Coding Style, Strukturierung, usw. Auch das gehört zu "lesbaren Code erzeugen".

The_Invisible
2007-01-06, 00:24:49
Was aber z.B. ultra-nervig ist ist das $ bei den PHP-Variablen. Da könnt ich durchdrehen.

hehe, da fällt mir immer ein "ich seh den code vor lauter $ nicht mehr" :biggrin:

mfg

No.3
2007-01-06, 00:37:40
Macht doch nix solang man sie ohne Shift erreicht :|

Also mir ist { tausend mal lieber als BEGIN oder son Müll.

begin und end kann man sich genau so sparen wie { und }

ist beides gleich idiotisch

Coda
2007-01-06, 00:41:52
begin und end kann man sich genau so sparen wie { und }

Kommt drauf an. Pures Einrücken hat auch seine Nachteile, aber im Prinzip stimme ich dir da sogar zu.

Aber was ist an Header-Dateien gut?

Man sieht die ganze Klasse auf einen Blick. Ich finde das angenehm.

hehe, da fällt mir immer ein "ich seh den code vor lauter $ nicht mehr" :biggrin:

Vor allem muss ich mich grad mit dem Scheiß wieder rumschlagen. Das krankeste ist sowas wie "for($i=0;$i<10;++$i)"... Omg...

Gast
2007-01-06, 00:54:36
Kommt drauf an. Pures Einrücken hat auch seine Nachteile, aber im Prinzip stimme ich dir da sogar zu.


Was soll denn an Einrücken gut sein? Dann muss man wohlmöglich noch aufpassen, dass man in seinem Code keine Umbrüche, Einrückungen oder andere Strukturen zur Übersichtlichkeit hat, nur damit der Compiler Anfang/Ende kapiert.


Man sieht die ganze Klasse auf einen Blick. Ich finde das angenehm.


Ist trotzdem noch wesentlich unflexibler als partielle Klassen.


Vor allem muss ich mich grad mit dem Scheiß wieder rumschlagen. Das krankeste ist sowas wie "for($i=0;$i<10;++$i)"... Omg...

Habe mich mit PHP schon Ewigkeiten nicht mehr beschäftigt (warum sich auch mit den Scheiß rumärgern?), aber AFAIK ist das mit $ nur bei untypisierten Variablen. Du kannst das AFAIK auch typisiert lösen und bei neueren PHP Versionen sollte ja das Zugreifen auf POST/GET Variablen über $... sowieso nicht mehr gehen?!

No.3
2007-01-06, 00:57:22
Kommt drauf an. Pures Einrücken hat auch seine Nachteile, aber im Prinzip stimme ich dir da sogar zu.

lol, weil ich es gerade in der Zwischenablage habe:

WHILE enterWord()=TRUE
IF recurseWord()=FALSE
printFailed()
ENDIF
ENDWHILE

das ist E. Sieht aus wie Basic, ist aber so leistungsfähig wie C (++) oder Pascal, o.ä.

der Compiler verkraftet es auch wenn man sehr langen Code über mehrere _eingerückte_ Zeilen verteilt!


wrks - kann man hier "schützte Leerzeichen" eingeben damit der Code eingerückt bleibt ?

Coda
2007-01-06, 00:58:36
Äh? Da gibt's doch wieder ENDIF statt }? Was soll daran so toll sein?

Und das es "so leistungsfähig" wie C++ ist glaube ich jetzt mal eher nicht. Das ist nämlich keine imperative Sprache von den Features her (abgesehen von Garbage Collection):

Gast
2007-01-06, 00:59:45
lol, weil ich es gerade in der Zwischenablage habe:

WHILE enterWord()=TRUE
IF recurseWord()=FALSE
printFailed()
ENDIF
ENDWHILE

das ist E. Sieht aus wie Basic, ist aber so leistungsfähig wie C (++) oder Pascal, o.ä.

der Compiler verkraftet es auch wenn man sehr langen Code über mehrere _eingerückte_ Zeilen verteilt!


wrks - kann man hier "schützte Leerzeichen" eingeben damit der Code eingerückt bleibt ?

Das musst du mir erklären, was das mit Einrücken zu tun haben soll? Warum sonst sollte es ein ENDWHILE/ENDIF geben, wenn nicht zur Terminierung der Anweisung?

No.3
2007-01-06, 01:07:51
Äh? Da gibt's doch wieder ENDIF statt }? Was soll daran so toll sein?

man könnte durchaus sagen, dass ENDIF statt } ist. C hat aber ein if UND ein { ;)
andererseits IF - ENDIF kommt einer "Sprache" wesentlich näher als ein IF { }

IF
FOR
WHILE
ENDWHILE
ENDFOR
ENDIF

nun mach das mal mit C oder Pascal. Wenn Du eine schliessende Klammer vergisst, oder ein end, dann viel Spass in einem längeren komplexen Code die fehlende Klammer zu finden. Hab meinen Bruder da oft genug über C fluchen hören...


Das musst du mir erklären, was das mit Einrücken zu tun haben soll? Warum sonst sollte es ein ENDWHILE/ENDIF geben, wenn nicht zur Terminierung der Anweisung?

uhm? wie meinen ?

Gast
2007-01-06, 01:15:43
man könnte durchaus sagen, dass ENDIF statt } ist. C hat aber ein if UND ein { ;)
andererseits IF - ENDIF kommt einer "Sprache" wesentlich näher als ein IF { }


ENDWHILE sind 8 Zeichen gegen zwei Klammern. Was ist wohl vorteilhafter? Und in deinem Fall bräuchte man in C sowieso keine Klammern da jweils immer nur ein Befehl steht. Also

while(enterWorld())
if(recurseWorld)
printFailed();


Wenn Du eine schliessende Klammer vergisst, oder ein end, dann viel Spass in einem längeren komplexen Code

Das ist bei heutigen IDEs mit automatischer Einrückung usw. sowas von unwichtig. Ich bin zumindest nie über solche Fehler gestoßen, trotz komplexer Anweisungen. Mir ist auch schleierhaft warum sich die Leute mit Klammern immer so schwer tun.

ScottManDeath
2007-01-06, 02:55:07
Aber was ist an Header-Dateien gut?

Nichts ;)

Es bereitet mir erheblichen Sackgang dass ich wenn ich eine Methodensignatur ändere, (und dass passiert oft, beim anfänglichen Coden oder Refaktorisieren) das an zwei Stellen synchron halten muss. Vor allem, da es mit Copy & Paste eben nicht getan ist; Ja, default parameter oder const Methoden ich rede mit euch ;) Das führt dann dazu, dass ich den Großteil direkt im .h schreibe und mir sage, irgendwann, wenn der Code stable ist, wirds aufgeteilt =) Und da C++ nicht einfach zu Parsen ist, kann man es auch schlecht automatisieren, dass der Code entsprechend verteilt wird.

Xmas
2007-01-06, 03:04:06
Aber was ich auch meine ist Lesbarkeit in der Semantik des Codes, das enthält Dinge wie Symbol-Benennungen, Coding Style, Strukturierung, usw. Auch das gehört zu "lesbaren Code erzeugen".
Gute Namen kann eine IDE natürlich nicht automatisch erzeugen, aber ich denke da durchaus an etwas mehr als nur einen "Prettifier".

Man sieht die ganze Klasse auf einen Blick. Ich finde das angenehm.
Dafür habe ich eine IDE mit Klassenansicht und Code Folding. Header-Dateien sind lediglich redundante Fehlerquellen.

tokugawa
2007-01-06, 06:06:31
Gute Namen kann eine IDE natürlich nicht automatisch erzeugen, aber ich denke da durchaus an etwas mehr als nur einen "Prettifier".


Ich weiß nicht. Ich würd trotzdem immer noch eher einem menschlichen Selbstverständnis trauen (oder auch nicht trauen, wenn's ein hochnäsiger Programmierer ist, der sich dem Firmen-Coding-Style nicht anpassen will...).



Zu der Diskussion über Einrückungen, begin, {, was auch immer: alles Ansichtssache und Gewohnheitssache.

"Idiotisch", wie es jemand geschrieben hat ist höchstens jemand, der die Gewohnheit von anderen als "idiotisch" bezeichnet und seine eigene Gewohnheit über die aller anderen stellt.

maximAL
2007-01-06, 11:55:28
herrlich, es wird von alternativer syntax gesprochen und die C++ experten mosern über begin / end.
na, wenns schon dort aufhört, ist eh nichts mehr zu retten :rolleyes:

The_Invisible
2007-01-06, 12:29:45
Ich weiß nicht. Ich würd trotzdem immer noch eher einem menschlichen Selbstverständnis trauen (oder auch nicht trauen, wenn's ein hochnäsiger Programmierer ist, der sich dem Firmen-Coding-Style nicht anpassen will...).



Zu der Diskussion über Einrückungen, begin, {, was auch immer: alles Ansichtssache und Gewohnheitssache.

"Idiotisch", wie es jemand geschrieben hat ist höchstens jemand, der die Gewohnheit von anderen als "idiotisch" bezeichnet und seine eigene Gewohnheit über die aller anderen stellt.

naja, über die formatierung des codes gibts ja die wildesten streitereien

schreibt man


if(foo=='bar') {
// do something
}


oder


if(foo=='bar')
{
// do something
}


oder (einzige anweisung)


if(foo=='bar')
// do something


dazu kommt noch ob man leerzeichen zwischen zuweisungen / vergleichen macht oder nicht. wo ist der duden für programmierer?

mfg

clm[k1]
2007-01-06, 12:34:49
wo ist der duden für programmierer?


Da: http://java.sun.com/docs/codeconv/
:biggrin:


clm[k1]

Gast
2007-01-06, 13:12:25
Es bereitet mir erheblichen Sackgang dass ich wenn ich eine Methodensignatur ändere, (und dass passiert oft, beim anfänglichen Coden oder Refaktorisieren) das an zwei Stellen synchron halten muss.
Meine IDE hat ein "change signature".
Wenn deine das nicht hat, würde ich sagen, dein Chef hat an der falschen Stelle gespart.
Header Dateien bieten eine schnellen strukturierten Überblick, den mir die IDE Tools bisher nicht so bieten können.
Würde man hier die Diskussion nur auf Leute beschränken die in der Woche >40 Stunden coden müssen, sähe es durchschnittlich besser für C++ aus.

Wenn ich Features für eine Wunschsprache hätte, wäre es die Möglichkeit manche Dinge in Prosa angeben zu können.
Solche Sachen wie "bau mir eine Listbox mit Inhalt xy" "ich hätte gern ein Fenster mit Auswahlmöglichkeiten für die folgenden Parameter" sind einfach nur stupide, vom Rechner lösbar und in keiner Programmiersprache vernünftig gelöst.

No.3
2007-01-06, 13:27:10
ENDWHILE sind 8 Zeichen gegen zwei Klammern. Was ist wohl vorteilhafter? Und in deinem Fall bräuchte man in C sowieso keine Klammern da jweils immer nur ein Befehl steht. Also

while(enterWorld())
if(recurseWorld)
printFailed();


wie gesagt, IF ENDIF ist wie Sprache, { und } ist, uhm, nun, dann kannst Du gleich in Maschinensprache arbeiten, auser 0 und 1 gibts da nichts ;)


Das ist bei heutigen IDEs mit automatischer Einrückung usw. sowas von unwichtig. Ich bin zumindest nie über solche Fehler gestoßen, trotz komplexer Anweisungen. Mir ist auch schleierhaft warum sich die Leute mit Klammern immer so schwer tun.

vor 15 Jahren gab es solche IDEs nicht ;)

da war der Compiler jedesmal eine zeitlang beschäftigt bis er mehrere 1000 Zeilen Code durchforstet hat, Fehler korrigieren, Compiler wieder 1000de Zeilen durchnudeln lassen, verdammt, einen Fehler falsch korrigiert, Fehler suchen und korrigieren, wieder 1000de Zeilen durchackern lassen... usw. Tjo, das waren halt noch Zeiten, früher ;) (ich hab noch von Diskette weg auf Diskette, mit Compiler und dessen Include Dateien etc auf Diskette gearbeitet - die jungen Leute heutzutage sind doch von 3 GHz, 1 GB und Raid 0 total verwöhnt ;) )

Code-Teile verschieden farbig hervorheben automatisch einrücken etc alles gut und schön, macht die Sache einfacher und komfortabel, in der Tat.

Die eine oder andere IDE die ich mir angesehen habe ist sehr langsam gewesen, der Windows Editor z.B. Scroll nen Source-Code in Highspeed durch, ne IDE mit farbigen Text scrollt teilweise wie ein dickes Word Dokument.

Die Variante Code durch z.B. farbige Hervorhebungen von Schlüsselwörtern o.ä. besondere Hervorhebung von verschachtelten { und } sind im Prinzip auch nur Krückstöcke, dies wäre im Prinzip nicht notwendig, wenn der Syntax einer Programmiersprache nicht so kryptisch wäre.

Gast
2007-01-06, 13:32:34
Die Variante Code durch z.B. farbige Hervorhebungen von Schlüsselwörtern o.ä. besondere Hervorhebung von verschachtelten { und } sind im Prinzip auch nur Krückstöcke, dies wäre im Prinzip nicht notwendig, wenn der Syntax einer Programmiersprache nicht so kryptisch wäre.
Warum benutzt man in natürlichen Sprachen dann Überschriften, Fettschrift, Rekursivschrift usw. um Dinge hervorzuheben und eine schnellere Übersicht zu ermöglichen?
Sind natürliche Sprachen auch zu kryptisch?

Ganon
2007-01-06, 13:35:26
wenn der Syntax einer Programmiersprache nicht so kryptisch wäre.

Objective-C :up:

Nur tippst du dir da ohne Code-Vervollständigung einen Wolf :D

No.3
2007-01-06, 13:40:18
Warum benutzt man in natürlichen Sprachen dann Überschriften, Fettschrift, Rekursivschrift usw. um Dinge hervorzuheben und eine schnellere Übersicht zu ermöglichen?
Sind natürliche Sprachen auch zu kryptisch?

eine Zeile Code mit Hervorhebungen kann bunt werden wie ein Regenbogen. Dann blickt man weniger durch als mit ohne Hervorhebungen.

Du liest wohl nur weniger Bücher, oder? Überschrift gibts nur alle paar Seiten wenn ein neues Kapitel kommt, sonst gibts da keine grafischen Stilmittel. Das würde nur ablenken und das Lesen erschweren.

Ich Lehrbüchern z.B. kommt durchaus Farbe und Fettdruck uns Spiel um wichtige Begriffe o.ä. hervorzuheben. Aber auch das darf man nur mit Bedacht machen. Zuviel davon hat dann einen kontraproduktiven Effekt.

Trap
2007-01-06, 14:12:18
vor 15 Jahren gab es solche IDEs nicht ;)

Doch, natürlich gab es solche IDEs auch vor 15 Jahren. Sogar vor 20. Das was du meinst ist 30-40 Jahre her.


Wenn ich Features für eine Wunschsprache hätte, wäre es die Möglichkeit manche Dinge in Prosa angeben zu können.
Solche Sachen wie "bau mir eine Listbox mit Inhalt xy" "ich hätte gern ein Fenster mit Auswahlmöglichkeiten für die folgenden Parameter" sind einfach nur stupide, vom Rechner lösbar und in keiner Programmiersprache vernünftig gelöst.
Ich versteh dein Problem nicht. Die Programmiersprachen erlauben dir alle eine Funktion doWhatIMean zu schreiben die bei
doWhatIMean("bau mir eine Listbox mit Inhalt xy");
das macht was du haben möchtest.

Wenn man auf den Prosa-Aspekt verzichtet kann man das in ein paar Sprachen sogar so definieren, dass es komplett zu Compilezeit aufgelöst wird.

No.3
2007-01-06, 14:22:56
Doch, natürlich gab es solche IDEs auch vor 15 Jahren. Sogar vor 20. Das was du meinst ist 30-40 Jahre her.

Du meist z.B. so was wie Borland Pascal ? (der konnte farbig, Turbo Pascal war einfarbig wenn ich mich recht entsinne). Kenne aber auch (teure) C Compiler von 1985-1990 die keine solche farbige IDE mitbrachten.

Gast
2007-01-06, 14:27:45
wie gesagt, IF ENDIF ist wie Sprache, { und } ist, uhm, nun, dann kannst Du gleich in Maschinensprache arbeiten, auser 0 und 1 gibts da nichts ;)


Den Satz musst du noch einmal umformulieren, ich habe nämlich erhlich gesagt nichts verstanden.


Die eine oder andere IDE die ich mir angesehen habe ist sehr langsam gewesen, der Windows Editor z.B. Scroll nen Source-Code in Highspeed durch, ne IDE mit farbigen Text scrollt teilweise wie ein dickes Word Dokument.


Habe ich noch nie erlebt. Selbst auf einem P3 900 konnte ich früher mehrere tausend Zeilen Source Code Dateien problemlos in Visual Studio durchscrollen.
Der reine Source Code wohl gemerkt, irgend ein Designer braucht i.d.R. schon wesentlich mehr Performance.


Die Variante Code durch z.B. farbige Hervorhebungen von Schlüsselwörtern o.ä. besondere Hervorhebung von verschachtelten { und } sind im Prinzip auch nur Krückstöcke, dies wäre im Prinzip nicht notwendig, wenn der Syntax einer Programmiersprache nicht so kryptisch wäre.

Ich versthe den Zusammenhang zwischen generell farbl. markierten Schlüsselwörtnern und speziell Gültigkeitsbegrenzer wie { } nicht. Das eine ist unabhängig vom anderen und farbl. Markierung von Schlüsselwörtern ist nie verkehrt. Eine Gültigkeitsbegrenzung durch Klammern ist für mich wesentlich Übersichtlicher als eine bloße Einrückung. Beides Zusammen ist für mich noch besser. Noch optimaler wäre dann eine farbl. Markierung (z.B. Hintergrundfarbe) in dem Gültigkeitsbereich. Aber genau das bieten ja aktuelle IDEs sowieso alle von Haus aus.

Trap
2007-01-06, 14:41:57
Du meist z.B. so was wie Borland Pascal ? (der konnte farbig, Turbo Pascal war einfarbig wenn ich mich recht entsinne). Kenne aber auch (teure) C Compiler von 1985-1990 die keine solche farbige IDE mitbrachten.
Wieso farbig? Hervorheben kann man auch durch Blinken oder Fettschrift. Ich dachte eigentlich es ging dir hauptsächlich um automatisches Einrücken und zusammengehörige Klammern markieren.

Wie auch immer, Emacs bzw. Varianten davon konnten das Mitte der 80er.

Xmas
2007-01-06, 14:50:42
Meine IDE hat ein "change signature".
Wenn deine das nicht hat, würde ich sagen, dein Chef hat an der falschen Stelle gespart.
Header Dateien bieten eine schnellen strukturierten Überblick, den mir die IDE Tools bisher nicht so bieten können.
Wenn deine IDE das nicht kann, würde ich sagen dein Chef hat an der falschen Stelle gespart. ;)

wie gesagt, IF ENDIF ist wie Sprache, { und } ist, uhm, nun, dann kannst Du gleich in Maschinensprache arbeiten, auser 0 und 1 gibts da nichts ;)
Das ist jetzt ja wohl ziemlich weit hergeholt. IF/ENDIF oder {} dienen der Strukturierung, und eindeutige Symbole wie {} sind dabei für viele leichter zu erkennen als Schlüsselwörter, die ja auch Symbolnamen sein könnten. Die beste Art der Strukturierung ist aber immer noch grafisch.

No.3
2007-01-06, 15:03:11
Das ist jetzt ja wohl ziemlich weit hergeholt. IF/ENDIF oder {} dienen der Strukturierung, und eindeutige Symbole wie {} sind dabei für viele leichter zu erkennen als Schlüsselwörter, die ja auch Symbolnamen sein könnten. Die beste Art der Strukturierung ist aber immer noch grafisch.

nun, in allen Sprachen ist zumindest das IF immer noch ein Befehl, bei ENDIF kann man sich von mir aus auf Strukturierung einigen (ENDIF ist schlussendlich kein Befehl den die CPU abarbeitet).

Für das menschliche Auge ist Struktierung immer noch am besten, in der Tat. Doch dem Compiler muss noch gesagt werden wo der IF Block aufhört. Das über das Einrücken zu machen ist eher nicht machbar, da braucht es schon extra Schlüsselwörter sei es nun { } oder eben ENDIF.


zu weiter oben, dass ENDIF 5-Buchstaben seien und } eben nur ein Zeichen:

IF
ELSEIF
ELSEIF
ELSE
ENDIF

und schon musst Du 3 Tasten weniger drücken wenn man {} nicht benötigt ;)


Nun denne, letztenendes ist es irgendwo die Frage, was ist nun besser, Deutsch, Französisch oder vielleicht doch Chinesisch ?

Gast
2007-01-06, 15:05:20
Wenn deine IDE das nicht kann, würde ich sagen dein Chef hat an der falschen Stelle gespart. ;)
Womit geht es denn?
Jetzt komm mir nicht mit Standard-VS 2005.
Dessen Übersichten sind ein Hohn gegen eine gut dokumentiere Headerdatei.

Gast
2007-01-06, 15:16:43
Womit geht es denn?
Jetzt komm mir nicht mit Standard-VS 2005.
Dessen Übersichten sind ein Hohn gegen eine gut dokumentiere Headerdatei.

"Jetzt komm mir nicht mit..." ist leider kein Argument. Wenn du dir ein Überblick über die Klassenstruktur bilden möchtest, erstellt dir jede brauchbare aktuelle IDE ein Diagramm, sei es UML oder etwas eigenes.

Xmas
2007-01-06, 15:59:36
Womit geht es denn?
Jetzt komm mir nicht mit Standard-VS 2005.
Dessen Übersichten sind ein Hohn gegen eine gut dokumentiere Headerdatei.
Inwiefern? Was bietet eine gut dokumentierte Header-Datei mehr als eine gut dokumentierte Quelldatei mit Class View und Code Folding?

Gast
2007-01-06, 16:33:48
Inwiefern? Was bietet eine gut dokumentierte Header-Datei mehr als eine gut dokumentierte Quelldatei mit Class View und Code Folding?
Neben der umständlichen Navigation fehlt mir der logische Aufbau der Header Datei. Dort kann man Methoden etc. in logischen Blöcken zusammenfassen und mit einer ausführlichen Dokumentation versehen. Ein sortByCode wäre für die ClassView schonmal ein richtiger Segen...

Nach dem Einwand eben mit dem UML hab ich mich noch etwas umgeschaut und festgestellt, dass etwas wie ObjectIF für mich wahrscheinlich Header Dateien gut ersetzen und die Produktivität noch stark steigern könnte. (bei >3000€ pro Lizenz wird aber wohl der Chef ablehnen).
Wenn da jemand etwas günstigeres in der Richtung kennt bitte melden. :)
Ein einfaches Tool für C++ -> UML in VS integriert wäre schon nett.

Man sollte aber bedenken, dass Header auch ohne aufwendige IDEs eine entsprechende Übersicht bieten. Da gibt es auch noch sehr sehr viele Entwickler, die ohne größere IDE arbeiten.

Coda
2007-01-06, 18:29:45
Hat halt alles seine Vor- und Nachteile. Im Endeffekt kommt man mit der Zeit eh mit allem klar. Und ich glaube eh nicht dass der Produktivitätgewinn von Syntax sooo hoch ist - abgesehen von Trivialitäten.

Ich bin eh die meiste Zeit mit überlegen beschäftigt bevor ich dann auf einmal riesige Teile Code runterschreib. Das geht dann aber echt fix - egal in welcher Sprache.

Xmas
2007-01-06, 18:36:06
Neben der umständlichen Navigation fehlt mir der logische Aufbau der Header Datei. Dort kann man Methoden etc. in logischen Blöcken zusammenfassen und mit einer ausführlichen Dokumentation versehen. Ein sortByCode wäre für die ClassView schonmal ein richtiger Segen...
Deswegen dazu auch Code Folding. Bei VC++ ist das noch nicht ganz so schön, aber wenn ich C#-Code schreibe klappe ich einfach die Methoden ein, dann sieht es fast so aus wie eine Header-Datei. #region ist auch ziemlich praktisch zum Gruppieren. Jedenfalls habe ich Header-Dateien in anderen Sprachen noch nie vermisst.

Natürlich ginge es noch besser, dafür müsste man sich aber von ein paar heute leider noch üblichen Paradigmen lösen.

Man sollte aber bedenken, dass Header auch ohne aufwendige IDEs eine entsprechende Übersicht bieten. Da gibt es auch noch sehr sehr viele Entwickler, die ohne größere IDE arbeiten.
Das mag sein (leider). Nur gibt es jene bei anderen Programmiersprachen genauso, und da kommt keiner auf die Idee von den IDE-Benutzern zu fordern dass sie eine Klassenübersicht warten welche der Rechner genausogut automatisch erzeugen könnte.

tokugawa
2007-01-06, 20:16:29
naja, über die formatierung des codes gibts ja die wildesten streitereien

dazu kommt noch ob man leerzeichen zwischen zuweisungen / vergleichen macht oder nicht. wo ist der duden für programmierer?


Es ist Geschmackssache.

Und außerdem: in jeder ordentlichen Firma sollte für genau sowas ein Coding Styleguide existieren.

Deswegen dazu auch Code Folding. Bei VC++ ist das noch nicht ganz so schön, aber wenn ich C#-Code schreibe klappe ich einfach die Methoden ein, dann sieht es fast so aus wie eine Header-Datei. #region ist auch ziemlich praktisch zum Gruppieren. Jedenfalls habe ich Header-Dateien in anderen Sprachen noch nie vermisst.


Das Methodeneinklappen gibt's doch in VC++ auch? Und "#pragma region" ist ein C++/CLI Äquivalent zu #region.


Natürlich ginge es noch besser, dafür müsste man sich aber von ein paar heute leider noch üblichen Paradigmen lösen.

Das mag sein (leider). Nur gibt es jene bei anderen Programmiersprachen genauso, und da kommt keiner auf die Idee von den IDE-Benutzern zu fordern dass sie eine Klassenübersicht warten welche der Rechner genausogut automatisch erzeugen könnte.

Hier muß ich wieder Pragmatismus und Praktikabilität einbringen. Prinzipiell hast du recht, aber meistens ist man nicht aufgrund von "Einsparungen" auf eine IDE gebunden, sondern aufgrund von anderen Dingen. Um's als Beispiel zu nennen in der Konsolenentwicklung etwa gibt's meistens Bindings für eine bestimmte IDE (Visual Studio oder CodeWarrior, usw.), und es ist extrem zäh hier einfach eine andere IDE einzusetzen.




Ach ja, und da hier schon teilweise recht heftig diskutiert wird (und sehr oft immer die "eigene" Variante als die einzig richtige angesehen wird):
Wieso sind Programmierer eigentlich immer so eitel und sehen ihren eigenen Weg als den einzig richtigen an?

FlashBFE
2007-01-06, 21:21:20
Wieso sind Programmierer eigentlich immer so eitel und sehen ihren eigenen Weg als den einzig richtigen an?

Weil sie/wir Angst haben, dass es eine Welt hinter dem Tellerrand gibt?! :D

del_4901
2007-01-06, 21:41:35
IF
ELSEIF
ELSEIF
ELSE
ENDIF

und schon musst Du 3 Tasten weniger drücken wenn man {} nicht benötigt ;)


Nun denne, letztenendes ist es irgendwo die Frage, was ist nun besser, Deutsch, Französisch oder vielleicht doch Chinesisch ?

Sowas löse ich grundsätzlich mit switch.

Xmas
2007-01-06, 22:58:55
Das Methodeneinklappen gibt's doch in VC++ auch? Und "#pragma region" ist ein C++/CLI Äquivalent zu #region.
Ja, Code Folding funktioniert in VC# allerdings besser (unter anderem in Bezug auf Leerzeilen und Kommentare). #pragma region ist mir bekannt, allerdings hatte ich damit schon das Problem dass Folding für den Code dazwischen nicht mehr ging.

Hier muß ich wieder Pragmatismus und Praktikabilität einbringen. Prinzipiell hast du recht, aber meistens ist man nicht aufgrund von "Einsparungen" auf eine IDE gebunden, sondern aufgrund von anderen Dingen. Um's als Beispiel zu nennen in der Konsolenentwicklung etwa gibt's meistens Bindings für eine bestimmte IDE (Visual Studio oder CodeWarrior, usw.), und es ist extrem zäh hier einfach eine andere IDE einzusetzen.
Ich bin mir nicht ganz sicher worauf sich das jetzt bezieht.

Gast
2007-01-07, 00:25:22
Sowas löse ich grundsätzlich mit switch.

Naja... Ich weiß zwar, was du meinst, aber in einem else if() Zweig kann man etwas komplexere Abfragen machen als bei einem einfachen case Zweig, weil man da nur auf einen einzigen Wert überprüfen kann.

del_4901
2007-01-07, 00:45:01
Naja... Ich weiß zwar, was du meinst, aber in einem else if() Zweig kann man etwas komplexere Abfragen machen als bei einem einfachen case Zweig, weil man da nur auf einen einzigen Wert überprüfen kann.

Ja, das hab ich mir danach auch gedacht, ich hab nur gehofft das es keinem auffällt. ;)

No.3
2007-01-07, 00:53:53
Ja, das hab ich mir danach auch gedacht, ich hab nur gehofft das es keinem auffällt. ;)

ownd ;) - in diesem Sinne, Gute Nacht :wave:

del_4901
2007-01-07, 01:02:20
ownd ;) - in diesem Sinne, Gute Nacht :wave:


Du musst doch aber zugeben das in über 90% aller Fälle ein switch die bessere Lösung währe.

HajottV
2007-01-07, 11:57:57
Es ist Geschmackssache.

in jeder ordentlichen Firma sollte für genau sowas ein Coding Styleguide existieren.

Wieso sind Programmierer eigentlich immer so eitel und sehen ihren eigenen Weg als den einzig richtigen an?

Nana, erst gegen die Eitlen wettern aber selber den eigenen Weg als den (einzig) ordentlichen bezeichnen? :rolleyes:

Ich gehöre selber zu denen, die massiv gekotzt haben, als bei uns die Coding Conventions durchgedrückt wurden. Und ich muß sagen, daß ich mich auch nur zum Teil dran halte. In Klassen, bei denen ich davon ausgehen muß, daß sie von anderen Leuten beackert werden, halte ich mich dran, in meinen "privaten" Klassen, nehme ich noch immer meine Konvention.

Der Grund ist folgender: Ich habe meinen Stil über Jahre verfeinert und für meine Bedürfnisse optimiert. Ich kann meinen Stil hervorragend lesen - ob andere das können, lasse ich jetzt mal außen vor. Tatsache ist aber, daß ich 75% meiner Zeit in meinem Code arbeite und dort einfach so effizient arbeiten möchte wie möglich. Nehme ich eine andere Konvention bin ich (geschätzt) 5-10% weniger effizient, und das müßte ich durch noch mehr (unbezahlte) Überstunden (sprich meine Freizeit) kompensieren, um das gleiche Arbeitsresultat zu erzielen. Das sehe ich schlicht und einfach nicht ein! Und das hat nichts mit mangelndem Engagement zu tun: Ich habe inzwischen so viele unbezahlte Überstunden angehäuft - wenn ich die jetzt abfeiern könnte, würde mich meine Firma erst im Herbst wieder sehen.

Gruß

Jörg

PS: Eine andere Erklärung dafür, daß Entwickler ihren Programmierstil so verteidigen, könnte sein, daß es das einzige in ihrem Leben ist, wo sie überhaupt Stil haben. ;)

RMC
2007-01-07, 12:26:06
Ich gehöre selber zu denen, die massiv gekotzt haben, als bei uns die Coding Conventions durchgedrückt wurden.

Ist aber leider notwendig in ordentlichen Firmen.


Der Grund ist folgender: Ich habe meinen Stil über Jahre verfeinert und für meine Bedürfnisse optimiert. Ich kann meinen Stil hervorragend lesen - ob andere das können, lasse ich jetzt mal außen vor.

Klar, jeder hat irgendwie seinen eigenen Stil, mit dem er effizient zurecht kommt. Aber gerade dass andere ihn auch lesen können ist wichtig.


Und deshalb: es gibt ja auch in diversen, vernünftigen IDEs austauschbare Codestile, wo man auf Knopfdruck einfach zwischen den Stilen umschalten kann. Dann kann das ja auch kein so großes Problem sein.

Ganon
2007-01-07, 12:32:16
Hier wird immer von "meine IDE kann das" und "diverse IDEs können das" und "es gibt auch IDEs die das können".

Diese "IDE"s haben doch sicherlich auch Namen, oder? Wäre toll wenn diese mal genannt werden. ;)

pajofego
2007-01-07, 12:45:58
boah ei Leute...ich bekomme das Gefühl ihr schreibt nur noch Programme runter die fehlerfrei sind. Also mir ist die Syntax erst einmal egal...obs sie jetzt begin end oder lauter {} oder $% hat ist mir sowas von egal notfalls schreibe ich auch in chinesich...solange der Debugger saugut ist und der compiler nicht stundenlang compilieren muss. Ich muss die meiste Zeit damit verbringen bei mir meine code zu debuggen. So ca. 70% davon ist nur reine Fehlerbeseitigung...das schreiben von Code bzw. der Syntax ist irrelevant dagegen. Ein schneller Delphicompiler mit von mir aus der C Syntax mit dem MS Debugger...ja da hätte ich meinen Partner gefunden. Naja so bleibe ich halt bei VS2005 isch halt der saugeile Debugger der mich immerwieder erfreut...

Gast
2007-01-07, 12:46:32
Hier wird immer von "meine IDE kann das" und "diverse IDEs können das" und "es gibt auch IDEs die das können".

Diese "IDE"s haben doch sicherlich auch Namen, oder? Wäre toll wenn diese mal genannt werden. ;)

Was denn jetzt genau?

No.3
2007-01-07, 13:06:59
Du musst doch aber zugeben das in über 90% aller Fälle ein switch die bessere Lösung währe.

kommt ein wenig drauf an. Sofern es nur um IF a=1 ELSEIF a=2 ELSE ENDIF geht, kann es durchaus sein, dass ich IF verwende (hat "optische Gründe") wenn es dann aber um IF a=1 ...... a=10 geht, dann nehm ich auch Switch. C ist schon zu lange her (IIRC ging es da nichtm vielleicht bei C++), meine most favourite Programmiersprache kann bei switch auch

switch
case 1,3-5,9
case 2,6
case 7,8
default


Ich muss die meiste Zeit damit verbringen bei mir meine code zu debuggen. So ca. 70% davon ist nur reine Fehlerbeseitigung...das schreiben von Code bzw. der Syntax ist irrelevant dagegen.

autsch - ich bin ja "nur" Hobbieprogrammierer, aber eher 70-80% der Zeit bin ich am Proggen

pajofego
2007-01-07, 13:24:15
autsch - ich bin ja "nur" Hobbieprogrammierer, aber eher 70-80% der Zeit bin ich am Proggen

Den Vogel habe ich einmal in meiner Diplomarbeit abgeschossen...! Ich habe 4 Wochen am Stück mein Shader Code - dank MS Shader Debugger in VS 2003 erfolgreich - debuggen müssen...das war so ein pupsiger kleiner Fehler, der erst nach ein paar Berechnungsschritten auftraf. Ohne den Shader Debugger wäre ich aufgeschmissen gewesen bzw. ich hätte in mühsehliger kleinarbeit a la writeln die Texturen auslesen müssen. Ne ne du...also IDE bzw. Debugger ist mir wichtiger als die Syntax selbst!

Gast
2007-01-07, 13:29:09
Ich muss die meiste Zeit damit verbringen bei mir meine code zu debuggen. So ca. 70% davon ist nur reine Fehlerbeseitigung...das schreiben von Code bzw. der Syntax ist irrelevant dagegen.

Ist bei mir sehr ähnlich. Die meiste Zeit verbringe ich mit Denken/Ausprobieren wie man etwas realisiert und dem Debuggen. Ohne ordentlichen Debugger wäre ich ziemlich aufgeschmissen. Das Schreiben des eigentlichen Code geht - nachdem man eine genaue Vorstellung hat - recht fix. Ich bin halt ein sehr bequemer Mensch und verschwende lieber viel Zeit um darüber nachzudenken, wie ich etwas effizient/flexibel (also generisch) implementiere anstatt loszuklimpern und mir zukünftige Änderungen/Erweiterungen erschwäre.

No.3
2007-01-07, 13:36:05
Den Vogel habe ich einmal in meiner Diplomarbeit abgeschossen...! Ich habe 4 Wochen am Stück mein Shader Code - dank MS Shader Debugger in VS 2003 erfolgreich - debuggen müssen...das war so ein pupsiger kleiner Fehler, der erst nach ein paar Berechnungsschritten auftraf. Ohne den Shader Debugger wäre ich aufgeschmissen gewesen bzw. ich hätte in mühsehliger kleinarbeit a la writeln die Texturen auslesen müssen. Ne ne du...also IDE bzw. Debugger ist mir wichtiger als die Syntax selbst!

ich sage ja nicht, dass ich keinen Debugger benutze ;)

bei mir ist das ganz oldschool, benutz nen uralten (aber "programmierbaren") Editor (kann aber kein Hervorheben von Schlüsselwörtern), und starte den Compiler aus der Commando-Zeile, dito der Debugger. Und ja, so Fehler die erst 5 Schritte bemerkbar werden, sind echt lästig, kreisförmig umschliessen ahoi :biggrin:

tokugawa
2007-01-07, 18:30:39
Nana, erst gegen die Eitlen wettern aber selber den eigenen Weg als den (einzig) ordentlichen bezeichnen? :rolleyes:


Das ist nicht "mein eigener Weg", sondern der meiner Firma.

Das ist Pragmatismus; letztendlich ist Code zwischen den Programmierern eines Teams auch ein Kommunikationsmittel. Hier sollte man konsistent bleiben.

Wenn Coding-Styles einem nicht passen, sollte man das mit den anderen Programmieren bzw. dem Technical Director diskutieren, und nicht anfangen seinen eigenen Brei zu kochen und quasi einen parallelen Stil aufzubauen dass dann die Codebasis komplett inkonsistent wird.


Ich gehöre selber zu denen, die massiv gekotzt haben, als bei uns die Coding Conventions durchgedrückt wurden. Und ich muß sagen, daß ich mich auch nur zum Teil dran halte. In Klassen, bei denen ich davon ausgehen muß, daß sie von anderen Leuten beackert werden, halte ich mich dran, in meinen "privaten" Klassen, nehme ich noch immer meine Konvention.


Das würde bei uns nicht gehen, da wir regelmäßige Code Reviews durchführen, die auch in die privaten Klassen reingehen (was übrigens die Code-Qualität massiv erhöht).

Außerdem selbst dann, es ist nicht gesagt dass irgendein anderer Programmierer irgendwann einmal deinen "privaten" Codeteil auch bearbeiten muß. Das ist auch einer der Hauptpunkte.

Meiner Meinung nach wär's sinnvoller wenn du die Punkte des Firmen-Coding-Styles, die dir nicht gefallen, sinnvoll erklärst und mit deinen Kollegen und Chefs diese erläuterst. Wenn es wirklich sachlich erklärbare Dinge sind (ein Coding-Style sollte ja auf Sachlichkeit und nicht Geschmack basieren), sollte da ein Konsens machbar sein.


Der Grund ist folgender: Ich habe meinen Stil über Jahre verfeinert und für meine Bedürfnisse optimiert. Ich kann meinen Stil hervorragend lesen - ob andere das können, lasse ich jetzt mal außen vor.


Und genau das wäre der Sinn eines Corporate Coding Style. Du schreibst den Code nicht für dich allein (zumindest normalerweise).


Tatsache ist aber, daß ich 75% meiner Zeit in meinem Code arbeite und dort einfach so effizient arbeiten möchte wie möglich.
Nehme ich eine andere Konvention bin ich (geschätzt) 5-10% weniger effizient, und das müßte ich durch noch mehr (unbezahlte) Überstunden (sprich meine Freizeit) kompensieren, um das gleiche Arbeitsresultat zu erzielen.


Wenn euer Coding-Style deine "Effizienz" beeinträchtigt, dann muß entweder am Coding Style oder an dir irgendwas nicht stimmen.

Es ist schließlich Gewohnheitssache. Meiner Ansicht nach kann man sich an vernünftige Coding Styles innerhalb einer Stunde anpassen (in der man tatsächlich 10-15% weniger "schnell" arbeitet), aber danach geht das meiner Ansicht nach ziemlich ins Blut über.

Jedenfalls ist meiner Ansicht nach es nicht sinnvoll, zu sagen "ich pfeif auf den Firmen-Coding-Style". Es mag Programmierer geben die das als "Job-Absicherung" machen, damit ja kein anderer Programmierer die Codeteile jemals bearbeiten kann. Aber es mag auch Programmierer geben, die für solche Kunststücke (und die Uneinsicht warum der Coding-Style einzuhalten ist) gefeuert wurden :)

Wieso hast du "unbezahlte" Überstunden?


Das sehe ich schlicht und einfach nicht ein! Und das hat nichts mit mangelndem Engagement zu tun: Ich habe inzwischen so viele unbezahlte Überstunden angehäuft - wenn ich die jetzt abfeiern könnte, würde mich meine Firma erst im Herbst wieder sehen.


Klingt irgendwie nach Spielebranche.


PS: Eine andere Erklärung dafür, daß Entwickler ihren Programmierstil so verteidigen, könnte sein, daß es das einzige in ihrem Leben ist, wo sie überhaupt Stil haben. ;)

Hast du das nicht eben selbst gemacht :) , also deinen Stil verteidigt?


Und deshalb: es gibt ja auch in diversen, vernünftigen IDEs austauschbare Codestile, wo man auf Knopfdruck einfach zwischen den Stilen umschalten kann. Dann kann das ja auch kein so großes Problem sein.


Welche wäre das?

Ich kann mir nicht wirklich vorstellen dass das für die extensiveren Coding-Styles funktioniert, wo etwa auch Benennung von Variablen und Methoden/Funktionen geregelt sind, so wie etwa die Leerzeichensetzung. Das ist ja keine reine Zeichenersetzung, sondern da müsste man durchaus auch Semantik können, bzw. ein wenig "menschliche Logik/Vernunft" reinbringen. Da tut sich ein Programm meiner Ansicht nach schwer.

Ungarische Notation ein/ausschalten geht sicher nicht schwer, aber das allein macht ja noch keinen Coding-Style aus.

RMC
2007-01-07, 19:15:07
Hier wird immer von "meine IDE kann das" und "diverse IDEs können das" und "es gibt auch IDEs die das können".

Diese "IDE"s haben doch sicherlich auch Namen, oder? Wäre toll wenn diese mal genannt werden. ;)

Borland JBuilder hab ich gemeint. Gut, "Auf Knopfdruck" war übertrieben, man kann halt ganz normal die aktuelle Ansicht mit dem vorher definierten Style formatieren. Wäre aber nicht schlecht wenn man das Format bei der Quickformat-Funktion aussuchen könnte. Hab die freie Version, vielleicht geht das ja bei der Enterprise Edition.

MadMan2k
2007-01-07, 19:32:01
bei Eclipse geht das auch. Da kann man pro Projekt einen Style festlegen. Mit dem Auto-Formatter kann man dann prima Code "im/exportieren".

Shink
2007-01-08, 14:47:10
Wäre aber nicht schlecht wenn man das Format bei der Quickformat-Funktion aussuchen könnte.
Noch besser: Die Formatierung ist nur eine "View" auf den tatsächlichen Sourcecode, der einem ja von der Formatierung her prinzipiell egal sein kann. Der "View" kann von jedem Programmierer wie er will eingestellt werden, ohne dass er jemanden damit ärgert; abgespeichert wird immer in einem standard-View (=Codestyle). Zeilennummern in Debugs oder Traces kann die IDE dann problemlos übersetzen.
Wär doch nicht so schwierig zu machen, oder?

tokugawa
2007-01-08, 18:30:26
Noch besser: Die Formatierung ist nur eine "View" auf den tatsächlichen Sourcecode, der einem ja von der Formatierung her prinzipiell egal sein kann. Der "View" kann von jedem Programmierer wie er will eingestellt werden, ohne dass er jemanden damit ärgert; abgespeichert wird immer in einem standard-View (=Codestyle). Zeilennummern in Debugs oder Traces kann die IDE dann problemlos übersetzen.
Wär doch nicht so schwierig zu machen, oder?


Naja, wie ich schon geschrieben habe, geht Coding-Style normalerweise viel weiter als reine Formatierung.

Da geht es um Benennungs-Richtlinien, sowie teilweise sogar semantische Sachen (wie etwas programmiert werden soll und wie nicht).

Z.B. könnte man entscheiden, dass man statt


for (int i = 0; i < irgendwas; i++)


folgendes macht:

int i;
for (i = 0; i < irgendwas; i++)


aus dem einfachen Grund, weil ein bestimmter Compiler nicht mit dem obigen zurechtkommt, da es die Scopes nicht nach aktuellem C++-Standard interpretiert (was bei Multiplattformprojekten sehr gut möglich ist, da muß man quasi C++ Code schreiben der bei jedem Compiler funktioniert).

Auch das ist Teil vom Coding-Style, und hier wäre es schwer, reine "Views" zu haben. Da müsste man den Code an sich ändern.

Chris Lux
2007-01-08, 20:38:51
Da geht es um Benennungs-Richtlinien, sowie teilweise sogar semantische Sachen (wie etwas programmiert werden soll und wie nicht).

for (int i = 0; i < irgendwas; i++)


hehe, mein chef würde an der stelle auch schonwieder schimpfen, weil ++i effizienter ist (vor allem, wenn i kein pod ist). ;)

Coda
2007-01-08, 20:42:53
Wenn es POD ist, dann sollte es wohl gleich schnell sein. Ansonsten hat der Compiler echt Probleme X-D

Aber ich stimme dir zu. Es ist eine gute Gewohnheit ++i zu schreiben, damit man's bei den Iteratoren auch gleich richtig macht.