welche programmiersprache für Programme benutzen?



  • Das sich alle immer hinter Jit-Compiler verstecken ... Und dann staendig im Konjunktiv reden. Nichts als Luftschloesser!



  • mdmr schrieb:

    das Makros gefährlich seien sollen erinnert mich, an die Hetzte des C# Dozenten meines Bruders, über Nativ Code und ganz gefähliche Zeiger^^.

    Makros sind durchaus gefährlich, gerade wenn sie zu intensiv und ohne sinnvolle Namenskonventionen verwendet, oder als Funktionsersatz verwendet werden. Dazu kannst du dir gerne viele Fachbücher anschauen, oder google benutzen. Ich rate hierbei beispielsweise zur "Effectiv-C++" oder "Exceptional-C++" Bücherreihe, aber auch jedes etwas modernere C++ Buch (teilweise selbst in Einsteigerliteratur) gibt hierzu schöne Beispiele.

    Besonders ärgerlich ist es wenn Funktionen von Makros überschrieben werden, weil es halt zufälligerweise ein Makro mit diesem Namen gibt. Auch ist es schön das Makros sich nur schlecht debuggen lassen, und Namensräume etc. unterwandern.

    mdmr schrieb:

    Wie schon erwähnt kann ich da wenn ich solche Topics wie dieses ( und viele andere ) lese kann ich jedem nur empfehlen sich seine eigene Meinung zu bilden und zu probieren.

    Aber bitte auch mit mehr Argumenten als "MFC ist das beste das es gibt".

    mdmr schrieb:

    ...um so mehr treffe ich auf Begriffe wie Windof und co, Dinge werden behauptet die nicht stimmen : MFC kein C++ , grausammer Code, MVC wird nicht unterstützt, gefährliche Makros...

    1. MFC und Standard C++ sind inkompatibel (zumindest waren sie es noch im Visual Studio 2003 mussten bestimmte Einstellungen im Projekt gemacht sein - was in MFC-Projekten natürlich still schweigend voreingestellt wurde).

    2. MFC ist an vielen Stellen typunsicher (Ich sage nur void*), was in der Praxis schon zu vielen Stunden Fehlersuche geführt hat.

    mdmr schrieb:

    Makros gehören nunmal nicht nur zum C++ , sonder in jede Gui Bibiothek und sind keine MFC eigenart.

    Es gibt einige UI-Bibliotheken die Makros nur minimal einsetzen (Sei es für Includeguards, wo es keine Alternative gibt, oder um etwas Tipaufwand zu verringern), oder wenigstens Makros nur mit einer festen Notation (ZUM_BEISPIEL_NUR_GROSS) einsetzen. Davon abgesehen sind Makros zwar C++, aber nichts was vom Compiler interpretiert werden kann (sondern nur von einem vorgeschalteten Präprozessor), und wie schon erwähnt zu schwer debugbaren Problemen führen kann.

    mdmr schrieb:

    Also das klingt für mich alles andere als sachlich, eher polistisierend.

    Also sind die C++ Gurus für dich allesamt unsachlich und polarisierend (Zu den C++ Gurus zähle ich Leute wie Stroustrup, Herb Sutter, Scott Meyers, Andrei Alexandrescu...).

    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.

    Es ist natürlich einfacher, alle neueren Erkenntnisse als unsachlich zu bezeichnen, als selbst auf dem Laufenden zu bleiben. Ich werde niemanden von der MFC-Programmierung abhalten, aber sie ist weder modern, noch entspricht sie der modernen C++ Programmierung (wie übrigens auch viele andere Bibliotheken, die vor der C++ Standardisierung heraus gekommen sind).



  • 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. Wir haben mittlerweile 2010. Ich meine sogar, dass es die meisten Inkompatibilitäten nur noch in VS 6 gab und danach gab es bloß noch einen Compilerswitch für die deprecated-Sachen, die in alten Projekten benutzt wurden.



  • 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&T

    SCO 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 😉


Anmelden zum Antworten