welche programmiersprache für Programme benutzen?
-
Hallo
Wenn man eh nur Windows als Target hat, sollte man IMHO c# mit Forms oder gleich WPF verwenden. Geschwindigkeit ist doch eh kein wirkliches Problem.
chrische
-
rapso schrieb:
hm, rein vom API her fand ich das nicht so wirklich besser als andere gui libs. zumindestens als ich es damals ausprobiert habe musste man fuer viele dinge selbst klassen anlegen und ueberall mit SetSize Set.. aufrufen anpassen.
Dann hast du die LayoutManager nicht wirklich verwendet. Denn die übernehmen das ganze Layouting und du setzt keine größen mehr sondern sagst nur welches Layout und wo was liegt, der Rest wird vom LayoutManager gemacht.
vermutlich hat wxWidgets sowas auch mittlerweile, aber gerade was dynamische Layouts betrifft ist sowas halt schon genial.
-
mdmr schrieb:
Die wenigsten wissen das MS früher einer der größten UNIX entwickler war, Xenix aus dem über Umwegen System 5 entstanden ist.
das ist ja interessant
bei wikipedia lese ich aber erstaunt, daß Xenix ursprünglich eine Portierung von System 7 mit einigen BSD-Erweiterungen war.
-
oops: ich meinte "Version 7", nicht "System 7"
-
Walli schrieb:
asc schrieb:
Und das sich Programmiertechniken im Laufe der Zeit ändern, sollte jedem bekannt sein. Was vor 15 Jahren noch als gut empfunden wurde, ist heute in der Regel schon überholt.
Sagt jemand, der sich oben noch über Inkompatibilitäten in VS2003 aufregt.
Die letzte Version in der ich (wenn auch nur kurz) was mit der MFC machen musste. Logisch das ich nicht für neuere sprechen kann (Da ich nur die Express Versionen nutze, die kein MFC haben).
-
[url]
zum Beispiel schrieb:
mdmr schrieb:
Die wenigsten wissen das MS früher einer der größten UNIX entwickler war, Xenix aus dem über Umwegen System 5 entstanden ist.
das ist ja interessant
bei wikipedia lese ich aber erstaunt, daß Xenix ursprünglich eine Portierung von System 7 mit einigen BSD-Erweiterungen war.
Stimmt [/url]http://de.wikipedia.org/wiki/Xenix[url]
Was aber nix damit zu tun hat das aus MS Xenix laut Timeline System V entstanden ist.
Versionsübersicht [Bearbeiten]
Version Datum Beschreibung / Änderungen
MS Xenix 1980 Erstes Unix von Microsoft unter Lizenz von AT&TSCO XENIX 1983 Unterstützung für IBM XT
SCO XENIX System V 1984 Weiterentwicklung auf Basis von Unix System V
SCO XENIX 286 1985 Weiterentwicklung für Intel 80286
SCO XENIX 386 Release 2.2 1986 Portierung von Unix System V auf i386, damit ist XENIX System V/386 das erste 32-Bit-Betriebssystem für x86-Computer [1]
SCO XENIX 386 Release 2.3 1989 Verbesserte Hardwareunterstützung
SCO XENIX 386 Release 2.3.4 April 1991 Letzte veröffentlichte Version
-
mdmr schrieb:
Was aber nix damit zu tun hat das aus MS Xenix laut Timeline System V entstanden ist.
wo kann man das nachlesen ?
-
Laut wiki ist die C/C++/Java Sprachfamilie die einzige, in der man keine
Ko-Routinen verwenden kann. Es gibt deshalb einige Probleme, die mit diesen Sprachen prinzipiell unlösbar sind. Deshalb nimmt man lieber eine gescheite Sprache, mit der man prinzipiell jede Aufgabenstellung lösen kann, also z.B. Ruby. Man ist mit C/C++/Java total aufgeschmissen, wenn man mehrere User-Threads gleichzeitig (kooperativ) in einem Programm verwenden möchte. Einfach nicht möglich. Also lieber Ruby verwenden!
-
Korutine schrieb:
Es gibt deshalb einige Probleme, die mit diesen Sprachen prinzipiell unlösbar sind.
Welche wären das?
-
Korutine schrieb:
Laut wiki ist die C/C++/Java Sprachfamilie die einzige, in der man keine
Ko-Routinen verwenden kann. Es gibt deshalb einige Probleme, die mit diesen Sprachen prinzipiell unlösbar sind. Deshalb nimmt man lieber eine gescheite Sprache, mit der man prinzipiell jede Aufgabenstellung lösen kann, also z.B. Ruby. Man ist mit C/C++/Java total aufgeschmissen, wenn man mehrere User-Threads gleichzeitig (kooperativ) in einem Programm verwenden möchte. Einfach nicht möglich. Also lieber Ruby verwenden!Das es weiß Gott genug Thread-Bibliotheken für C++ gibt, angefangen bei WinAPI (auch für C) bis hin zu boost::thread, ist dir bewusst? Für Java gibts die mit Sicherheit auch.
Ganz davon abgesehen fällt mir jetzt auch kein Problem ein, dass man nur mit Threads lösen kann. Und trotzdem muss man sehr blind sein, um bei der Fülle an C/C++/Java-Anwendungen der Meinung zu sein, dass keine davon mit Threads arbeitet. Außerdem würde ich nur wegen der Tatsache, dass diese nicht im Sprachkern enthalten, sondern über Bibliotheken benutzt werden müssen, vorsichtig sein, C/C++/Java als keine "gescheiten" Sprachen zu bezeichnen.
-
Korutine schrieb:
...Deshalb nimmt man lieber eine gescheite Sprache, mit der man prinzipiell jede Aufgabenstellung lösen kann, also z.B. Ruby. Man ist mit C/C++/Java total aufgeschmissen, wenn man mehrere User-Threads gleichzeitig (kooperativ) in einem Programm verwenden möchte. Einfach nicht möglich...
hab mich sicher grad verschaut als ich mir das ding (ruby) mal runter geladen hab und mir die *.c dateien förmlich entgegengesprungen sind;)
lg lolo
-
ipsec schrieb:
Das es weiß Gott genug Thread-Bibliotheken für C++ gibt, angefangen bei WinAPI (auch für C) bis hin zu boost::thread, ist dir bewusst? Für Java gibts die mit Sicherheit auch.
Ganz davon abgesehen fällt mir jetzt auch kein Problem ein, dass man nur mit Threads lösen kann. Und trotzdem muss man sehr blind sein, um bei der Fülle an C/C++/Java-Anwendungen der Meinung zu sein, dass keine davon mit Threads arbeitet. Außerdem würde ich nur wegen der Tatsache, dass diese nicht im Sprachkern enthalten, sondern über Bibliotheken benutzt werden müssen, vorsichtig sein, C/C++/Java als keine "gescheiten" Sprachen zu bezeichnen.Wer gerne komplexe Scheduler bastelt, um einer unüberschaubaren Anzahl der unterschiedlichsten (simultan ablaufenden) Teilprozesse z.B. einer 3D-Szene mit 5 computergesteuerten und 3 spielergesteuerten Akteuren + GUI-Layer (auf drei verschiedenen Rechnern in jeweils unterschiedlichem Zustand) die notwendigen Scheibchen an Rechenzeit zuzuweisen, der kann auch mit C/C++/Java das Rad neu erfinden. Ist aber viel praktischer, wenn man den einzelnen Elementen einer solchen Szene 'ihre eigenen' Ruby-Skripts anhängen kann, und die Programmiersprache von sich aus dazu in der Lage ist, die entsprechenden Scheibchen Rechenzeit geeignet zu verteilen. Ohne dass man einen komplizierten Scheduler basteln müsste, bei dem man mit der dubiosen C/C++/Java-Syntax sowieso total den Überblick verliert.
Tja, aber weiß man, auf welchem Level manche Leute gerne programmieren?
Ko-Routinen sind das Um- und Auf. Also am besten: Ruby verwenden!
-
Korutine schrieb:
ipsec schrieb:
Das es weiß Gott genug Thread-Bibliotheken für C++ gibt, angefangen bei WinAPI (auch für C) bis hin zu boost::thread, ist dir bewusst? Für Java gibts die mit Sicherheit auch.
Ganz davon abgesehen fällt mir jetzt auch kein Problem ein, dass man nur mit Threads lösen kann. Und trotzdem muss man sehr blind sein, um bei der Fülle an C/C++/Java-Anwendungen der Meinung zu sein, dass keine davon mit Threads arbeitet. Außerdem würde ich nur wegen der Tatsache, dass diese nicht im Sprachkern enthalten, sondern über Bibliotheken benutzt werden müssen, vorsichtig sein, C/C++/Java als keine "gescheiten" Sprachen zu bezeichnen.Wer gerne komplexe Scheduler bastelt, um einer unüberschaubaren Anzahl der unterschiedlichsten (simultan ablaufenden) Teilprozesse z.B. einer 3D-Szene mit 5 computergesteuerten und 3 spielergesteuerten Akteuren + GUI-Layer (auf drei verschiedenen Rechnern in jeweils unterschiedlichem Zustand) die notwendigen Scheibchen an Rechenzeit zuzuweisen, der kann auch mit C/C++/Java das Rad neu erfinden. Ist aber viel praktischer, wenn man den einzelnen Elementen einer solchen Szene 'ihre eigenen' Ruby-Skripts anhängen kann, und die Programmiersprache von sich aus dazu in der Lage ist, die entsprechenden Scheibchen Rechenzeit geeignet zu verteilen. Ohne dass man einen komplizierten Scheduler basteln müsste, bei dem man mit der dubiosen C/C++/Java-Syntax sowieso total den Überblick verliert.
Tja, aber weiß man, auf welchem Level manche Leute gerne programmieren?
Ko-Routinen sind das Um- und Auf. Also am besten: Ruby verwenden!Was ist das Problem, solchen Szenen 'ihre eigenen' C++-Funktionen (in einem Thread) zu geben? Und was hat es mit Rad neu erfinden zu tun, wenn man eine Bibliothek benutzt? Die Verteilung der Rechenzeit überlasse ich übrigens am liebsten meinem OS
-
Korutine schrieb:
Ko-Routinen sind das Um- und Auf. Also am besten: Ruby verwenden!
Klar, weil's die ja nur in Ruby gibt.
-
also ich hätte ja nach dem 1. Post mit Vielem gerechnet, nach so einer Steilvorlage für einen Trollthread, aber dass tatsächlich noch welche aus ihren Löchern gekrochen kommen, die MFC anpreisen, das hätt ich tatsächlich nicht erwartet
-
ipsec schrieb:
Was ist das Problem, solchen Szenen 'ihre eigenen' C++-Funktionen (in einem Thread) zu geben? Und was hat es mit Rad neu erfinden zu tun, wenn man eine Bibliothek benutzt? Die Verteilung der Rechenzeit überlasse ich übrigens am liebsten meinem OS
Ok, da hast Du recht, ich wollte eher darauf hinaus, dass die Entscheidung für die 'richtige' Programmiersprache hauptsächlich davon abhängt, auf welchem Abstraktionslevel man denn zu programmieren gedenkt.
Habe dabei einiges gelernt:
- Eine Schach-Engine. Die Algorithmen, Datenstrukturen etc. sind weitgehend bekannt, trotzdem ist es wichtig, sie möglichst Cache-Friendly zu implementieren (den Code kompakt zu halten), um gute Suchtiefen zu erzielen. -> Klarer Fall für C.
- Eine einfache 3D-Flieger-Simulation, bei der man über eine Landschaft fliegt. Es kommen dabei kaum Akteure/Events vor, und es existieren gute C++ Bibliotheken dafür, mit denen man mit wenig Schreibaufwand die Modelle lädt und die auch low-level Events (Tastatur-Eingabe u.ä.) bereitstellen (in meinem Fall fiel die Wahl auf Irrlicht). -> Für solche (eher kleinere) Anwendungen genügt noch C++.
- Für alles was darüber hinaus geht (mehrere Akteure, teils KI-gesteuert, teils spielergesteuert + mehrere Szenen + womöglich auch noch kompliziertere Spiel-Logik) schriebe man sich mit C++ (auch unter Zuhilfenahme entsprechender low-level Bibliotheken) schlicht die Finger wund, bevor man jemals zu einem Ergebnis käme. In solchen Fällen sind eindeutig Frameworks wie z.B. Unity, Wintermute usw. (mit ihren entsprechenden Skript-Sprachen) unumgänglich.Es sei denn, man hat die Zeit und schreibt sich erst mal im Laufe der Jahre (und Jahrzehnte!) selber so ein geeignetes Framework, wie man es für die konkrete Problemstellung gerne hätte. Tja, dann fiele wohl die Wahl widerum auf C/C++.
Nur - wer hat schon so viel Zeit? Also, entweder man begnügt sich mit den vorhandenen Frameworks, lernt die entsprechenden Skriptsprachen, und kommt damit auch in einer überschaubaren Zeit zu Ergebnissen (die aber vielleicht nicht zu 100% dem entsprechen, was man gerne gehabt hätte ...)
Oder man setzt sich ein paar Jahre hin und versucht sein Glück mit C/C++.
Aber man erwarte nicht, damit in absehbarer Zeit große Sprünge zu machen.
Schon gar nicht, wenn man darauf vergisst, wie wichtig die CO-ROUTINEN sind.
mfg
<Hoffentlich ist der Beitrag dieses Mal genau so informativ wie belustigend>
-
Korutine schrieb:
- Für alles was darüber hinaus geht (mehrere Akteure, teils KI-gesteuert, teils spielergesteuert + mehrere Szenen + womöglich auch noch kompliziertere Spiel-Logik) schriebe man sich mit C++ (auch unter Zuhilfenahme entsprechender low-level Bibliotheken) schlicht die Finger wund, bevor man jemals zu einem Ergebnis käme. In solchen Fällen sind eindeutig Frameworks wie z.B. Unity, Wintermute usw. (mit ihren entsprechenden Skript-Sprachen) unumgänglich.
Da werden dir viele große Softwareschmieden aber was anderes sagen
-
Wer die MFC empfiehlt ist entweder geistesgestört oder masochist.
-
Alle Sprachen nach C waren Trollversuche die sich zugegebeneermaßen durchgesetzt haben.
-
9 schrieb:
Alle Sprachen nach C waren Trollversuche die sich zugegebeneermaßen durchgesetzt haben.
Unsinn! Bereits C war ein Trollversuch:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-240812.htmlGrüssli
