welche programmiersprache für Programme benutzen?
-
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
-
Eine Schach-Engine .. Klarer Fall für C .. Für alles was darüber hinaus
Tjs, nur dass C nicht gerade geeignete Funktionen fuer Logik hat. Und da du noch wenig Erfahrung hast, spreche ich dir mal ab, ueber alles andere zu urteilen zu koennen.
wie wichtig die CO-ROUTINEN sind
Die gibt es auch in anderen Sprachen. Auch gibt es reichlich Resourcen im Internet, wie sie fuer C zu realisieren sind.
-
knivil schrieb:
wie wichtig die CO-ROUTINEN sind
Die gibt es auch in anderen Sprachen. Auch gibt es reichlich Resourcen im Internet, wie sie fuer C zu realisieren sind.
Schon, aber da feiern vermutlich die Makros eine Party mit setjmp/longjmp. Wer will sochen Code noch warten?
Edit: Gerade noch in den Bookmarks gefunden: eine absolut realweltuntaugliche, aber dafür hochinteressante Implementierung von Coroutines in C über Fibers, die Raymond Chen hier, hier und hier beschrieben hat.
-
Aus den vorherigen Beiträgen könnte man schließen, daß Skriptsprachenentwickler sowas warten wollen.
-
kotred schrieb:
Wer die MFC empfiehlt ist entweder geistesgestört oder masochist.
Wie greifst du mit anderen Toolsets und C++ auf das MS ADS zu ?
Mal angenommen du schreibst einen Serverdienst mit Sockets wo Netzwerkauth notwendig ist, nun kannst du entweder das Auth selber handln oder MS ADS Nutzen.
Ist für die Nutzer deutlich einfacher wenn sie sich schon an der Domäne geauthed haben, nicht noch einmal zu Authen, mal angesehen davon ist es nicht ganz so trivial ein dem Kerb Auth mit LDAP Authisierung von MS ADS "nachzubauen".
Auch um ADS Tools zu entwickeln gibbet weiter keine Unterstützung von anderen Toolsets.Und was ist mit Aktive X ? QT bietet nur in der Komerziellen Lizenz ( 4000.- ) Aktive X Unterstützung.
Ist natrlich immer die Frage was man Entwickelt, sollen es Plattformunabhängige Clienttools werden ist natürlich QT /WX oder anderes Sinvoll. In MS Netzwerken sollte man aber mal einen Blick auf die MFC werfen, oder/und sich mit .Net anfreunden, was nicht immer die beste Lösung ist.
Macht eh Sinn mehr als ein Toolset zu kennnen, auch wenn man sich nur in eines "tief" einarbeiten kann.
-
Strunz schrieb:
Wie greifst du mit anderen Toolsets und C++ auf das MS ADS zu ?
Delphi/C++Builder und JWSCL.
-
audacia schrieb:
Strunz schrieb:
Wie greifst du mit anderen Toolsets und C++ auf das MS ADS zu ?
Delphi/C++Builder und JWSCL.
Damit kann man auf MS LDAP zugreifen, User Adden , Moddifi, Queri. Exchange Tools ? Berechtigungen der Serverdienste mit eigener Socketprogramierung an LDAP Gruppen knüpfen ?
Gibt es das auch für QT bzw alternativen für QT ?
Meinem bisherigem Wissensstand nach gabs da nix ausser MFC und .Net, um die MS Netwerkauthetifizierung des ADS zu nutzen.
Um mal ein aus der Luft gegriffenes Beispiel zu nehmen: Programm was aus einem Serverdienst besteht mit Sockets , ähnlich einer DB und Client was darauf zugreift und Informationen abruft. Berechtigungen kann man hier an LDAP knüpfen und mit LDAP Gruppen arbeiten ohne weitere Locale Benutzer Gruppen zu nutzen. Soweit ich das verstanden habe kann jwscl mit localen ACL´s und Localen Benutzern / Gruppen / Berechtigungen umgehen.
-
strunz schrieb:
Damit kann man auf MS LDAP zugreifen
Weiß ich nicht.
Welche APIs bieten die MFC denn da? Hast du einen Link?strunz schrieb:
Gibt es das auch für QT bzw alternativen für QT ?
Delphi und C++Builder sind Alternativen zu Qt.
-
http://msdn.microsoft.com/en-us/library/aa772170(v=VS.85).aspx schrieb:
Active Directory Service Interfaces (ADSI) is a set of COM interfaces
Von daher würde ich urteilen, es ist egal.
-
Zeus schrieb:
http://msdn.microsoft.com/en-us/library/aa772170(v=VS.85).aspx schrieb:
Active Directory Service Interfaces (ADSI) is a set of COM interfaces
Von daher würde ich urteilen, es ist egal.
Wenn es nur das ist, dann ist es wirklich egal - COM-Interfaces kannst du von überall aus benutzen -, und mit den MFC hat es nicht das geringste zu tun. (Das hätte mich doch auch verwundert.)
