welche programmiersprache für Programme benutzen?
-
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.)