JAVA/C#/C++



  • Ist es möglich ein JAVA-Programm zu einer ausführbaren Datei zu machen oder muß man immer das SDK mitliefern, damit das Programm läuft?

    Frage wurde bereits beantwortet. Für xxx.exe nimmt man C++.

    C# läuft doch nur unter Windows, oder? Alles andere sollte mich bei M$ wundern

    http://www.mono-project.com/about/index.html
    Mono is a comprehensive open source development platform based on the .NET framework that allows IT and ISV developers to build Linux and cross-platform applications with unprecedented productivity. Mono's .NET implementation is based on the ECMA standards for C# and the Common Language Infrastructure.

    Hat jemand zufällig Geschwindigkeitsvergleiche zwischen den Programmiersprachen zur Hand?

    Wichtiger ist die Bedeutung und die entsprechende Nachfrage.
    http://www.gulp.de/kb/tools/gulpometer/pdb.html#Programmiersprachen
    Java liegt knapp vor C++, wird aber immer bedeutender.

    Achso last, but not least hat jemand ein paar online-Ressourcen zu C++ für mich parat?

    http://www.cpp-tutor.de/
    http://tutorial.schornboeck.net/
    http://de.geocities.com/throni3/
    http://www.cprogramming.com/tutorial.html
    http://www.codeguru.com/Cpp/
    http://www.codeproject.com
    http://www.robsite.de/tutorials.php?tut=c



  • @kuh_die_macht_muh

    1. Mono ist nicht 100% kompatibel zu dem MS dotNET! Da MS die Datenbank, GUI und Websachen nicht standardisiert hat.

    2. GULP ist nicht representativ und zweitens ist es jeden Monat anders, mal ist C++ vorne, mal Java und manchmal sogar COBOL... 🙄



  • kingruedi schrieb:

    btw. sucht man Programmiersprachen auch nicht nach Geschwindigkeit aus, in den meisten Fällen kommt das eh aufs gleiche raus.

    Das sehe ich anders.
    Für viele Anwendungen ist Geschwindigkeit ein Kriterium.
    Und selbst, wenn das natürlich auch von der Güte des Compilers abhängt (in dem Fall nimm man halt den Besten, den man sich leisten kann), schaut man bei der Wohl der Sprache doch auch darauf, wie gut(effizent) sie mit dem angestrebten Framework/Api zusammenarbeitet.
    Wäre das nicht so, würde jeder nur noch Plattformunabhängig programmieren.



  • Ahja. Ich schreibe mein Paint natürlich in Assembler, weil das ist ja schneller als C#.



  • @Gonzo
    quatsch, 99% der Anwendungen die entworfen werden sind Geschwindigkeits unkritisch (natürlich sollten sie flüssig laufen). Das ist totaler Blödsinn.



  • Das ist wohl eine pers. Definition was man unter Geschwindigkeitskritisch versteht, oder?

    Ich entwickel gerade für die Produktionsplanung eine Anwendung, wo auch Grafikfunktionen drin sind (so mit Layering, Vectorgrafik usw.). Nun, dazu ist es nötig 2D-Zeichnungen reinzuladen. Der Witz an der Sache ist, das Java für eine TIFF-Datei auf einem Pentium4 mit 2 GHz mehrere Sekunden benötigt, um diese entsprechend zu decodieren. Diese Grafik ist ca. 1600x1200 groß und s/w.

    Jedes andere billige Freeware-Programm in nativ Windows macht das schneller. Jetzt darf ich den Benutzern verklickern, das es am Java liegt. Aber Java als Entwicklungsplattform trotzdem gut ist. 😃 😉 Klar, in der normalen GUI mag sowas wie Java i.O. sein. Aber sobald es an größeren Datenmengen mit ein paar Algorithmen geht, bekommt der User Wartezeiten im Sekundenbereich zu sehen, wo nativer Code einen Wimpernschlag benötigt.

    Klar, es ist nicht kritisch, aber doch irgendwie traurig.



  • Optimizer schrieb:

    Ahja. Ich schreibe mein Paint natürlich in Assembler, weil das ist ja schneller als C#.

    Warum übertreibst Du so?
    Ich habe gesagt, für "viele" Anwendungen.
    Und eben weil ich diese Art Kommentare kenne, habe ich bewusst die Zusammenarbeit mit dem Framework mit einbezogen.
    Und für ein Zeichenprogramm, wie Photoshop, wurden Zeitweise übrigens extra PCI-Karten verkauft, die nichts weiter konnten, als die Arbeit mit diesem Programm zu beschleunigen.
    Für mich ist Geschwindigkeit nicht das einzige Kriterium, aber immerhin ein Wichtiges.
    Und selbst wenn ein einzelnes Programm gerade so noch flüssig läuft, gibt es einige Leute, die mehrere Programme nebeneinanderlaufen lassen möchten und trozdem noch Leistungsreserven haben möchten.
    Aber nein, warum sich darum scheren.Dazu gibt es ja Motherboards mit mehr als einer CPU.



  • Ich finde es einfach übertrieben, wie schon von Anfang an auf die Performance geachtet wird. Da kommen (jetzt nicht auf dich bezogen!) totale Anfänger daher und sagen: "Hey, welche Programmiersprache soll ich lernen? Ich habe gehört, dass C++ am schnellsten ist. Stimmt das?"
    Das ist doch lächerlich, solchen Leuten muss man vor Augen führen, dass der bei weitem allergrößte Teil der Performance von dem Typen vorm Monitor abhängt. Natürlich glaub ich das schon mal, wenn in Java die Swing-GUI langsam ist, etc. Aber es gibt immer eine "bessere" Lösung (wenn man C++ jetzt mal als "nicht gut" darstellen würde), als alles in C++ oder C zu coden. Du kannst bestimmte Teile Native coden. Die GUI ist z.B. in C#.Net auch keineswegs irgendwie träge.
    Ich finde solche generellen Aussagen einfach für den Allerwertesten. Vielleicht spare ich mir auch die halbe Entwicklungszeit und dafür braucht mein selbstgebauter ICQ-Client ne Sekunde länger zum Starten. Dafür läuft er auch auf Linux. Über sowas denkt aber keiner nach. C++ ist schneller (diese Verallgemeinerung ist sowieso falsch), also code ich C++. 🙄



  • Artchi schrieb:

    Der Witz an der Sache ist, das Java für eine TIFF-Datei auf einem Pentium4 mit 2 GHz mehrere Sekunden benötigt, um diese entsprechend zu decodieren. Diese Grafik ist ca. 1600x1200 groß und s/w.

    Da es in der Standardbibliothek von Java keine Möglichkeit gibt, TIFFs zu laden, würde mich interessieren, wie du das machst. JAI? Eigene Implementation? Ganz andere Bibliothek?

    Grundsätzlich liegt so ein Problem nicht an Java, sondern an einer schlechten Implementation des Algorithmus. Wenn dir die genutzte Bibliothek zu lahm ist, dann nutze halt ne andere oder schreib das ganze selbst. Wenn es schon dein eigener Code ist, dann optimier ihn mal. Vielleicht hast du einfach vergessen, irgendetwas zu puffern oder so. Wer weiß.



  • kingruedi schrieb:

    2. GULP ist nicht representativ und zweitens ist es jeden Monat anders, mal ist C++ vorne, mal Java und manchmal sogar COBOL... 🙄

    Hmmm... COBOL war lange nicht mehr vorne.

    Es mag sein, dass Gulp alleine nicht repräsentativ ist, aber wenn du dir diverse Jobbörsen etc. im Netz anguckst, dann wirst du schnell feststellen, dass an Programmiersprachen-Skills in erster Linie Java und C++ gesucht werden. Alle anderen folgen mit einigem Abstand.



  • Wir streben ein rundenbasierendes Strategiespiel an und da interessiert Geschwindigkeit schon...ich habe keine Luste mehrere Minuten auf die Züge der AI zu warten (Civilization 3 (hat das wer?) läßt grüßen...)



  • UNeverNo schrieb:

    Wir streben ein rundenbasierendes Strategiespiel an und da interessiert Geschwindigkeit schon...ich habe keine Luste mehrere Minuten auf die Züge der AI zu warten (Civilization 3 (hat das wer?) läßt grüßen...)

    Ihr wollt also Civilization 3 programmieren und wisst nicht mal welche Programmiersprache zu verwenden??

    Na dann viel Spass! Post doch in 5 Jahren noch mal, wie weit ihr seid... 🤡



  • Nö nicht Civ3, was neues. Und wir wissen schon, daß es ein paar Jährchen dauern wird 🤡

    Aber was wäre für die konkrete Anwendung nun das Beste?



  • warum sind es eigentlich immer die Spiele-Progger [sic] die immer wegen der Geschwindigkeit so besorgt sind, gerade bei so einem Spiel, kommt es auf 1 ms mehr oder weniger nicht an.

    btw. natürlich würde ich das Spiel in C++ machen, weil ich es besser in C++ machen könnte, als zB. in Java. Aber generell würde ich empfehlen, dass man einfach die Sprache nimmt, die man am besten beherscht und wenn man dann doch noch Angst um die Geschwindigkeit von zB. seiner Java Anwendung hat, dann nimmt man einfach den GCJ und kompiliert das.

    Geschwindigkeit wird idr. durch die verwendeten Algorithmen geholt und nicht durch die verwendete Programmiersprache.



  • Sgt. Nukem schrieb:

    Im Prinzip wird da aber nur die ganze Java API reingepackt und mit einer Runtime versehen, d.h. aus Deiner 20 KB class-Datei werden 9 MB - fast so groß wie die Runtime zum Runterladen.

    Die Aussage ist aber nicht dein Ernst oder? JBuilderX macht mir aus einem 600KB Jar eine Native Executeable mit 711KB, indem er nur das in die Exe Packt, was du auch benutzt. Du musst ja JDBC Komponenten usw. nicht mitlinken in die Exe, wenn du sie nicht brauchst.



  • Ich würd einfach auf http://www.99-bottles-of-beer.net// gehen und mir irgendeine der dort aufgeführten Sprachen auswählen.


Anmelden zum Antworten