Hi! Ich schlage mich nun schon eine Weile mit der Frage rum, welche Programmiersprache ich am besten zur Erzeugung von Windows-Anwendungen verwenden soll. Bitte keine Zusammenklick-Sachen wie Delphi oder so, sondern schon eine "für mehr" brauchbare Programmiersprache, die auch Win32 bzw. Win64 Anwendungen kann. Ich bin ganz gut in Basic (seit dem guten C64) und PHP. Somit ist auch klar zwischen welchen Programmiersprachen ich schwanke. PowerBasic/Win und C, bzw. einer Variante von C, von denen es unüberschaubar viele gibt. Auch nach dem Lesen diverser Artikel darüber bin ich nicht wesentlich schlauer als vorher, es gibt einfach zuviel und alles hat seine Vor- und Nachteile. Was mir wichtig wäre ist eine gute Oberfläche und schneller, kompakter Programmcode nach der Compilierung, der am Ende allein lauffähig sein soll (.EXE-Datei und evtl. ein paar DLLs). Geringe Investitionskosten sind ebenfalls nötig, das Programmieren ist ein Hobby von mir und soll keine Millionen kosten. Schlagt mir doch bitte mal was vor, was brauchbar ist oder was ihr verwendet und wo man eine gute Entwicklungsumgebung für bekommt... Danke! Wenn C, dann bitte auch welche Variante genau ihr meint...
Hi, Es kommt teils auf die Anwendung an und zum großen Teil ist es Geschmachssache. Ich habe gute Erfahrungen mit Qt gemacht. Programmiert wird in C++ und eine freie Entwicklungsumgebung gibt es von Nokia. Es sind auch schon relativ viele Beispiele vorhanden, sodass der Einstieg leichter fällt. Außerdem laufen die Programme auch auf Linux. Grüße Dnag
Ja, Qt mit C++ wäre auch das was ich empfehlen würde. Ein weiterer Vorteil ist, daß das ganze dann quasi ohne Änderungen auch für Mac und Linux compilierbar ist und dort dann auch sauber funktioniert.
Ben _ schrieb: > Bitte keine Zusammenklick-Sachen wie Delphi oder so, > sondern schon eine "für mehr" brauchbare Programmiersprache, die auch > Win32 bzw. Win64 Anwendungen kann. Was geht mit Delphi nicht, was mit C++ geht?
+1 für C++ mit Qt. Gut dokumentiert, (größtenteils) durchdachte API, läuft auf allen größeren Plattformen. Qt ist nicht nur eine GUI-Bibliothek sondern hat zum Beispiel auch sehr schöne Containerklassen (Liste, Vektor, Hashmap), und Kram wie XML-Parser, Netzwerk-Bibliothek, Skript-Engine, Bilder lesen/schreiben/bearbeiten, ... alles, was man mal brauchen könnte. Alternativ ist auch Python mit Qt ziemlich cool. Geht doch flotter von der Hand als mit C++, wenn man viel rechnen will im Hintergrund wird man aber evtl. dann doch auf C zurückgreifen müssen. btw: Nokia hat mit Qt so gut wie nichts mehr zu tun. ;)
Bildschirm leeren unter DOS Assembler: <30 Byte .COM-Datei Bildschirm leeren unter DOS PowerBasic: ~20kB .EXE-Datei Leeres Fenster unter Delphi: paar-100-kB .EXE-Datei oO Geht gar nicht! Und daß wohl Pascal drunter liegt geht erst recht nicht. Hätte man damals in der Schule nicht sinnlos Zeit damit verschwendet, uns diese Sackgasse von TurboPascal einzutrichtern, könnte ich heute C und hätte dieses Problem hier wahrscheinlich gar nicht!! **grummel** Nee, von allem was mit Pascal zu tun hat, habe ich die gelinde gesagt die Schnauze gestrichen voll. Von Qt hab ich noch gar nicht gehört, muß mich da mal schlau machen. Wo ist die Entwicklungsumgebung und evtl. ein paar Tutorials zu finden? Erzeugt das am Ende eine ausführbare Datei, die alleinständig ausgeführt werden kann oder braucht das irgendwelche Zusatzkomponenten, die auf dem System installiert sein müssen wie zB. bei Java?
Ben _ schrieb: > Bildschirm leeren unter DOS Assembler: <30 Byte .COM-Datei > > Bildschirm leeren unter DOS PowerBasic: ~20kB .EXE-Datei > > Leeres Fenster unter Delphi: paar-100-kB .EXE-Datei oO Wenn du Programme, die einfach nur den Bildschirm leeren und sich dann beenden, als deine Lebensaufgabe betrachtest, dann ist das eine sinnvolle Metrik. Und du bist mit Assembler gut bedient.
Woher wußte ich, daß selbst bei so einfachen Fragen wieder Trolle mit völlig sinnfreien Postings ihren vergammelten Senf dazukippen müssen? Man muß es Dir schlecht gehen, daß Du mir auf Deibel komm raus versuchen mußt an die Karre zu pissen.
Ben _ schrieb: > Bildschirm leeren unter DOS Assembler: <30 Byte .COM-Datei > Bildschirm leeren unter DOS PowerBasic: ~20kB .EXE-Datei > Leeres Fenster unter Delphi: paar-100-kB .EXE-Datei oO > > Geht gar nicht! Das ist Äpfel mit Birnen verglichen. Delphi läuft nur unter Windows. Ich Programmiere schon seit Delphi 1 mit Delphi, und es gibt FAST nix was Du mit Delphi nicht machen kannst ( FAST wegen Treiberprogramen und CO ) Geschwindigkeitsunterschiede merkst Du mit sicherheit kein. Ich habe Programme die sind total gleich programmiert und brauchen in C mehr platz wie in Delphi aber auch Programme die wiederum gleich Programmiert sind und in C weniger brauchen als in Delphi. Deine einschränkende Denkensweise beschneidet somit die Wahrheit sehr. Viel Glück bei der richtigen Programmiersprache. Ach ja bin kein Troll, werde aber von Dir bestimmt zu einem gemacht weil ich gegen Deine Meinung schreibe ;-)
Nimm Lazarus. Das schaut zwar auf Anhieb nach "zusammenklicken" aus, und Du kannst das auch machen, aber Du kannst selbstverständlich Deine GUI auch zur Laufzeit erstellen. Plus Du kannst das auch auf Win32 und Win64 laufen lassen, oder auch unter Linux, MacOSX oder gar Android. Plus die VCL hat relativ simpel zu bedienende Möglichkeiten damit sich die GUI an unterschiedliche Fenster- und Schriftgrößen anpasst. http://lazarus.freepascal.org/ Natürlich macht das statisch gelinkte Binaries. Allerdings sind die auch nach dem Du die Debug-Informationen ausgebaut hast immer noch 2 Megabytes.
Ben _ schrieb: > Geht gar nicht! Und daß wohl Pascal drunter liegt geht erst recht nicht. > Hätte man damals in der Schule nicht sinnlos Zeit damit verschwendet, > uns diese Sackgasse von TurboPascal einzutrichtern, könnte ich heute C > und hätte dieses Problem hier wahrscheinlich gar nicht!! **grummel** > Nee, von allem was mit Pascal zu tun hat, habe ich die gelinde gesagt > die Schnauze gestrichen voll. Christian Berger schrieb: > Nimm Lazarus. Das schaut zwar auf Anhieb nach "zusammenklicken" aus, und > Du kannst das auch machen, aber Du kannst selbstverständlich Deine GUI > auch zur Laufzeit erstellen. Plus Du kannst das auch auf Win32 und Win64 > laufen lassen, oder auch unter Linux, MacOSX oder gar Android. Plus die > VCL hat relativ simpel zu bedienende Möglichkeiten damit sich die GUI an > unterschiedliche Fenster- und Schriftgrößen anpasst. Und genau das will er ja nicht. grins
Ich würde C# verwenden, läuft auf jeder aktuellen windows Installationen ohne zustätzliche Installation. Es läuft sogar auf 32/64 oder ARM prozessoren ohne etwas am code zu ändern. Die Doku ist sehr gut und es gibt kostenlose IDEs. Es bietet auch möglichkeiten wie reflexion.
@Delphi Fan Du hast ja auch 'ne echte Meinung geschrieben. Die respektiere ich und ich lasse Delphi ja auch seine Daseinsberechtigung. Wenn Leute damit gut klarkommen und brauchbare Ergebnisse erzielen können, dann ist das ja okay. Allerdings mag ich es überhaupt nicht und möchte nichts, was irgendwie auf Pascal aufbaut. Hätte ich vielleicht im Anfangsposting schreiben sollen. Ich hatte gehofft irgendwer kennt/nutzt eine C-basierte Umgebung, die das kann. Ich hab immer Schwierigkeiten wenn irgendwas "zu relativ" ist. Weiß nicht wie ich das ausdrücken soll, aber beim Aufbau des Anwendungsfensters wäre es mir lieb wenn ich sagen kann Fenster feste Größe, Text an Koordinaten blah, Eingabezelle an Koordinaten blub, Button mit Funktionsaufruf X an Koordinaten laberlaber... ;) Dann weiß ich vielleicht auch ohne langes Suchen wo der eigentliche Programmcode hin muß. Oder wenn ich irgendein Fenster erzeugen kann, in dem ich frei grafisch zeichnen kann, sowas wäre auch schick. Aber wenn die Benutzeroberfläche in Bibliothek A enthalten ist und mit dem Programm X bearbeitet werden muß, damit ich hinterher irgendwie Relationen zum Programmcode B herstellen kann, der mit Programm Y zu erzeugen ist, dann find ich das schwieriger als wenn alles in einem und evtl. etwas umständlicher zu programmieren ist.
Aber Du schränkst Dich halt wegen Deinem Vorurteil ein. Lazarus ist kostenfrei und eigentlich genau das was Du suchst. Aber mach mal, Du machst das schon!
Ben _ schrieb: > Weiß nicht wie ich das ausdrücken soll, aber beim Aufbau des > Anwendungsfensters wäre es mir lieb wenn ich sagen kann Fenster feste > Größe, Text an Koordinaten blah, Eingabezelle an Koordinaten blub, > Button mit Funktionsaufruf X an Koordinaten laberlaber... ;) Dann weiß > ich vielleicht auch ohne langes Suchen wo der eigentliche Programmcode > hin muß. So etwas kann man mit wxWidgets (http://www.wxwidgets.org/) in C++ machen. Allerdings setzt das auch einen gewissen Lernaufwand voraus. Geht auch mit wxPython, allerdings hat man dann keine .exe-Datei, die man direkt ausführen kann. Um mit wxWidgets glücklich zu werden, sollte man aber schon einigermaßen erfahren in C++ sein, sonst dauert es ziemlich lang, bis man damit wirklich effizient arbeiten kann. Wenn du Pascal nicht magst und C/C++ nicht kannst, dafür Basic, dann würde ich an deiner Stelle mal Visual Basic testen. Das gibt es als Express-Version kostenlos.
@Ben Schon mal was von "AutoIt" gehört? -> http://www.autoit.de/index.php?page=Index. Einfach zu erlernen, gut dokummentiert - auch in deutsch! Alles Freeware. Ergibt sehr kleine exe-Datei ohne dass zusätzliches Beiwerk, wie Bibibliotheken oder Frameworks gebraucht wird. Läuft auf jedem Windows-PC ohne Installation. In o.g. Forum kann man sich ansehen, was da so alles möglich ist - z.B. "Wir bauen uns ein CAD" (unter Projekte suchen) Grüsse aus Berlin PSblnkd
Hallo Ben, wenn es dir wirklich nur um Windows Programme geht dann empfehle ich dir auch eine von Microsoft empfohlene Sprache zu verwenden. Ob C++ oder C# kannst du dann selbst entscheiden. Als Entwicklungsumgebung kannst du dir eine Express Version von Visual C++/Visual C# kostenlos herunterladen, welche auch die nötigen Bibliotheken für grafische Benutzeroberflächen mitbringt - Stichwort ".NET" . Hierfür brauchst du keine tieferen Kenntnisse in Sachen Makefiles, etc. Daher für ein Hobby und zum "senkrecht Starten" sehr geeignet. Hier gibts ein kostenloses Einsteiger Buch: http://openbook.galileocomputing.de/csharp/kap03.htm Kleine Anmerkung noch am Rande: Wer heutzutage grafische Oberflächen noch selbst schreibt ist selber Schuld. Designer bei denen man z.B. Buttons einfach nur per Drag&Drop auf seiner Oberfläche platziert erleichtern dir das Leben ungemein ;-) Edit: Visual Basic ist alternativ für dich vielleicht auch interessant, da du ja erwähntest dass du bereits gute Kenntnisse in Basic hast.
Ben _ schrieb: > Von Qt hab ich noch gar nicht gehört, muß mich da mal schlau machen. Wo > ist die Entwicklungsumgebung und evtl. ein paar Tutorials zu finden? > Erzeugt das am Ende eine ausführbare Datei, die alleinständig ausgeführt > werden kann oder braucht das irgendwelche Zusatzkomponenten, die auf dem > System installiert sein müssen wie zB. bei Java? Qt wurde von Trolltech entwickelt und dann von Nokia gekauft, dann weiterverkauft an Digia ... der OS-Part inklusive Doku ist hier zu finden --> http://qt-project.org/ Zur Verwendung eines kompilierten Programms mußt Du im selben Ordner noch die erforderlichen DLL's mit ausliefern, z.b. QtCore & QtGui für ein Hello World GUI Programm unter Windows... soweit die Theory. Verwendest du den Visual Studio C++ Compiler von Windows (es reicht die Express Version von VS), gibt es "lustige" Nebenwirkungen, was DLL-Versionen etc. angeht... Deshalb existiert für jede Visual Studio Entwicklungsumgebung auch das passende "Redistributable package" welches auf dem Zielsystem dann einmal mit installiert werden sollte. Alternative kann man auch den gcc aus der minGW-Portierung verwenden...
Vorsicht: Auch wenn Microsoft das "C++" nennt, wenn es mit .Net zusammenarbeitet, ist es kein C++, sondern nur etwas ähnliches, nämlich "C++/CLI". Das anzugeben ist beispielsweise bei Hilfeanfragen von essentieller Wichtigkeit.
Mir ist nicht ganz klar warum er Qt verwenden soll? So weit ich weiß wird das von Windows 8 Modern UI garnicht unterstützt? Damit wäre er also auf das Erstellen von "klassischen" Anwendungen eingeschränkt.
So jetzt hab ich nochmal 'ne dumme Frage für zwischendurch... :) Wo genau ist der Unterschied zwischen C, C++ und C#?
Ben _ schrieb: > Wo genau ist der Unterschied zwischen C, C++ und C#? C und C++ sind verwandt also ähnlich. C# ist etwas ganz anderes. Aber sehr gut zu lesen.
Ben _ schrieb: > Ich hatte gehofft irgendwer kennt/nutzt eine C-basierte Umgebung, die > das kann. Ich hab immer Schwierigkeiten wenn irgendwas "zu relativ" ist. > Weiß nicht wie ich das ausdrücken soll, aber beim Aufbau des > Anwendungsfensters wäre es mir lieb wenn ich sagen kann Fenster feste > Größe, Text an Koordinaten blah, Eingabezelle an Koordinaten blub, > Button mit Funktionsaufruf X an Koordinaten laberlaber... ;) Dann weiß > ich vielleicht auch ohne langes Suchen wo der eigentliche Programmcode > hin muß. > > Oder wenn ich irgendein Fenster erzeugen kann, in dem ich frei grafisch > zeichnen kann, sowas wäre auch schick. > > Aber wenn die Benutzeroberfläche in Bibliothek A enthalten ist und mit > dem Programm X bearbeitet werden muß, damit ich hinterher irgendwie > Relationen zum Programmcode B herstellen kann, der mit Programm Y zu > erzeugen ist, dann find ich das schwieriger als wenn alles in einem und > evtl. etwas umständlicher zu programmieren ist. Hallo Ben, vielleicht wäre PureBasic was für dich? Dort wird es eigentlich genau so gemacht wie Du oben schreibst und der erzeugte Programmcode ist nur eine .exe und wirlich sehr kompakt! http://www.purebasic.com/german/index.php Gruß, Steffen
Wenn's denn kompakt und übersichtlich sein soll: http://www.bloodshed.net/devcpp.html Eine Bibliothek für Oberflächen kann man nach Wunsch hinzufügen - oder man benutzt eben die Windows-API, kompakt eben.
Ihhh, ausgerechnet der DevC++. Das ist eine ganz schlechte Idee. Der ist total verbuggt und wird schon seit Jahren nicht mehr weiterentwickelt. Wenn es schon unbedingt nicht VS Express sein muss, dann doch bitte den Code::Blocks. Ach zum Topic: Vote for C#. Ist eine schöne Sprache mit sehr mächtigem .Net Framework. Wenn man C++ kann, findet man sich auch sehr schnell zurecht. Zum Oberflächen erstellen, hattte ich bisher C++/QT, Python/TKInter und eben C#. Letzteres bring bei mir die schnellsten und fehlerfreihesten Ergebnisse. Grüße,
Ich würde mal behaupten ich kann von C im Moment gar nichts. Was ich nicht so ganz verstehe, bei vielen C-Sources, die man auch hier im Forum so sieht blicke ich nicht durch (auch teilweise wegen mangelndem Interesse, sich damit länger zu befassen), aber PHP geht super. Viele sagen aber wenn PHP gut geht, dann müßte auch C gut gehen weil das ja ähnlich sein soll... Welches C meinen die?
Falls es jemanden interessiert... http://qt-project.org/wiki/Qt-5-on-Windows-8-and-Metro-UI Meine Empfehlung ist ganz klar Qt Programmierung mit C++! QtCreator ist eine recht komfortable IDE (man muss sich dran gewöhnen aber wenn man verstanden hat was die Entwickler wollten, ist sie ziemlich gut), Qt eine recht komfortable Lib, was will man mehr. Nachdem valve und co nun ziemlich aktiv auf Linux portieren, dürfte die Metro-Oberfläche/Win8.. naja.. egal :) Drawback: Recht große dlls unter windows damit's rennt (typischerweise packt mach die Qt-Dlls direkt mit dem Programm in den Installer) Vorteil: Windows, Mac, Linux aus einem Source, in einer IDE Die Geschwindigkeit ist auch phänomenal! 73
Schonmal was von Java gehört? Nur so ne Idee...
Ben _ (burning_silicon) schrieb: > Ich hatte gehofft irgendwer kennt/nutzt eine C-basierte Umgebung, die > das kann. Jeder C-Compiler kann ohne weiteres auch Windows GUI Programme erzeugen. Das geht sogar mit MASM32, dem 32-bit Assembler. Dazu wird im Grunde das gleiche gemacht, was die ganzen Frameworks veranstalten, nämlich Funktionen der Win32-API aufgerufen. Ob QT oder GTK, ob VCL bei Delphi oder das .NET FW von MS oder die alte MFC, sie alle bieten dir als Anwender eine Abstraktion und Kapselung der Win32-API, die zum Teil für den Programmierenden einfacher erscheint, weil GUT UND MODERN DOKUMENTIERT, weil alle modernen Schnittstellen abgebildet sind usw, aber dafür auch dazu verleitet bzw. vorraussetzt, entweder komplett neue Programmiersprachen wie C# zu lernen oder sich mit komplexen, mächtigen Sprachen wie C++ herumzuquälen (in all seiner bekannten Fehlerträchtigkeit). Von der Komplexität für den Anwender her würde ich C# aber deutlich angenehmer und eingängiger als C++ einstufen. C++ ist das reinste "Pointer-Moloch", aber vielleicht deswegen für viele Spezies gerade interessant. C# ist die bevorzugte Sprache des .NET (lies dot net) Frameworks für Windows. Im .NET FW wacht eine virtuelle Maschine darüber, eine Laufzeitumgebung, dass die Codeausführung nicht aus den Fugen gerät. Das kostet etwas an Ausführungsgeschwindigkeit, gibt dafür aber Sicherheit (Typsicherheit; Ressourcen werden z.T. automatisch freigegegen etc.), erreicht aber dafür nicht immer die Performance nativer Programme (wiewohl man auch in .NET "unmanaged code" schreiben kann). Und was man gar nicht hoch genug einschätzen kann, es gibt sehr viel Beispielcode für C#/.NET. Kaum einer der TOP-Frameworks (QT, .NET, VCL, GTK+, wxWidgets) kommt ohne Objekt-orientierten Anwender-Quellcode aus, erfordert daher ein komplettes Umdenken für Leute die nur TOP-Down Programme in C, PASCAL oder BASIC gewohnt sind. Selbst viele BASIC-Dialekte arbeiten inzwischen oder schon länger mit Objekten im Code, wenn auch deutlich vereinfachter als bei echter OOP in all ihren Facetten. Die einzige Möglichkeit (außer ein paar Nieschen-Frameworks, die ich aber eher meiden würde) sich vor der OOP "zu drücken" ist die gute alte Methode der Direktprogrammierung der Win32-API in herkömmlichen C-Code. Näheres dazu erfährst du beispielsweise im Forum von Pelles C. Das gilt aber als veraltet und würde so wohl auch nicht mehr an Hochschulen gelehrt. Mein Rat an dich wäre, schaue dir von jedem dieser prinzipiellen Möglichkeiten mehrere Codebeispiele und ein Tutorial an und entscheide dann in welche Richtung es gehen soll. Nur durch Empfehlungen allein ist das Thema nicht zu bewältigen. Ein schöner Ersatz für dein altes BASIC wäre vielleicht das hier: http://www.processing.org/learning/basics/ Probiere es ruhig mal aus. ;)
Ich glaube Java kann keine allein lauffähige .EXE aus dem Source erzeugen. Gibts bei C die Möglichkeit, die benutzten Funktionen aus den Bibliotheken in die .EXE zu übertragen? Meine angenommen, ich nutze aus einer 500kB DLL nur eine kleine Funktion, ists irgendwie unschön die komplette DLL mitzuschleppen.
static linking geht, würde ich aber nicht machen... über 500k dlls würde ich mir keine gedanken mehr machen. die zeiten der 30-byte COM-files ist (gott sei dank) vorbei. 73
Yep, schon klar, daß Speicherplatz heute zur Genüge da ist. Trotzdem muß man den ja nicht verschwenden, oder? Irgendwer hat mal gesagt niemand würde jemals mehr als 64kByte brauchen - und die 64k-Demoszene hat's geglaubt... ;) Und heute ahnt niemand mehr, was ein 4kByte großer Assembler-Virus zu DOS-Zeiten alles konnte... :D Mit MASM32 hab ich schon rumgespielt. Assembler ist eigentlich meine Lieblings-"Programmiersprache", aber für grafischen Kram unter Windows eindeutig ungeeignet bzw. extrem langwierig in der Anwendung. Aber inline-Assembler wäre schon cool! Auf jeden Fall möchte ich nicht auf ein Framework angewiesen sein. Wenn ichs mal später brauche okay, aber für irgendwelche einfachen Sachen sollte die .EXE ohne Framework mit Windows alleine auskommen. Also es sollte kein Zwang sein, das Framework zu benutzen. Ich stelle eine Frage nochmal konkret: Wenn ich ein Fenster zum freien drin Rummalen haben möchte - welche C-Variante könnte dies am besten und kommt ohne Framework aus?
Ben _ schrieb: > Ich stelle eine Frage nochmal konkret: Wenn ich ein Fenster zum freien > drin Rummalen haben möchte - welche C-Variante könnte dies am besten und > kommt ohne Framework aus? noch mal mit C macht man sotwas überhaupt nicht mehr, selbst in C++ tut ich mir das nicht mehr an. Installiert dir doch mal schnell http://www.icsharpcode.net/opensource/sd/ dann testest du mal 1 Stunde rum und wenn es dir nicht gefällt dann suchst du weiter.
Ben _ (burning_silicon) schrieb: > Auf jeden Fall möchte ich nicht auf ein Framework angewiesen sein. Wenn > ichs mal später brauche okay, aber für irgendwelche einfachen Sachen > sollte die .EXE ohne Framework mit Windows alleine auskommen. Also es > sollte kein Zwang sein, das Framework zu benutzen. Ich glaube du meinst eher Bibliotheken (DLLs), auf die das compilierte Programm angewiesen sein kann. Das Framework dient ja nur dazu den Quellcode des Programmierenden in einer bestimmten, verallgemeinerten Schreibweise formulieren zu können, sich also mehr von dem was darunter liegt zu distanzieren (abstrahieren). Das Kompilat ist dann nativ oder wie bei .NET halt automatisch Just-In-Time compiliert beim ersten starten (wovon du aber praktisch kaum was merkst). Irgendwo ist jede ausführbare Exe letztlich von DLLs abhängig, auch wenn es nur Kernel, User und GDI sind (letztere sind unter Windows sowieso immer geladen; das gleiche gilt aber auch für das .NET Framework - nur ist das ein wenig versionsabhängig, aber ab XP eigentlich kein Thema). > Ich stelle eine Frage nochmal konkret: Wenn ich ein Fenster zum freien > drin Rummalen haben möchte - welche C-Variante könnte dies am besten und > kommt ohne Framework aus? Du kannst sowohl von Pelles C als auch von Visual Studio Express C++ ein Windows Konsolenprojekt oder ein Win32-GUI Projekt mit dem Wizard starten, dir ein Fenster erzeugen und das "rummalen" mit LineTO Befehlen erreichen. Dazu gibt es genügend Beispiele. Sollten auch andere C-IDEs können.
Eine andere Möglichkeit wäre Tcl/Tk. Gibt es für Linux, Win, Mac usw. Eine Oberfläche lässt sich damit sehr schnell und einfach erstellen. OO wird unterstützt, ist aber kein Muss, wenn es z.B. darum geht, mal "eben schnell" eine brauchbare GUI für die Anzeige von Messwerten zu erstellen. Als StarKit lässt sich auch alles Nötige in eine von installierten Bibliotheken vollkommen unabhängige EXE packen. Kostet nix und ist privat wie auch kommerziell frei verwendbar (BSD-Lizenz). Wenn es wirklich zeitkritische Dinge gibt, so kann man den Interpreter sehr einfach durch eigene C-Funktionen erweitern. Chris D.
Ben _ schrieb: > Ich glaube Java kann keine allein lauffähige .EXE aus dem Source > erzeugen. > > Gibts bei C die Möglichkeit, die benutzten Funktionen aus den > Bibliotheken in die .EXE zu übertragen? Meine angenommen, ich nutze aus > einer 500kB DLL nur eine kleine Funktion, ists irgendwie unschön die > komplette DLL mitzuschleppen. Hi Warum tust Du uns nicht allen einen grossen Gefallen und lernst erst mal mit irgend einer aktuellen Programmiersprache zu arbeiten ? Ob nun Java, C# oder sonst irgendwas - krieg erst mal einen "Fuß in die Tür". Solange Du Dir selber mit Ansichten wie "ich nutze aus einer 500kB DLL nur eine kleine Funktion" im Weg stehst, wird das nie irgend etwas (Frage: Benutzt das OS die DLL garnicht ? Nirgends? Nie ? ) Resourcenprobleme wirst Du typischerweise erst mal nicht haben. Nimm etwas relativ Einfaches wie Java oder C#. Dann hast Du z.B. erst mal das Problem der Speicherverwaltung auf die Sprachumgebung abgewälzt und kannst erst mal schauen, was z.B. Design-Pattern sind. Man glaubts kaum aber auch SW-Entwicklung hat sich seit DOS Zeiten weiterentwickelt. C# hat den Vorteil, dass es relativ einfach den Zugriff auf native Windowsresourcen anbietet, Java ist dafür portabel über verschiedene OS. Such Dir einfach aus, was Du eher brauchst. Du bist auf die Sprache ja nicht auf ewig festgelegt. Von C/C++ würde ich im Augenblick abraten Die sind beide in manchen Details etwas "zickig". Am Anfang eher unnötiger Ärger. Du hast genug andere Sachen, um die Du Dich kümmern musst. Grüße Andreas P.S: Deine "merkwürdige" Ansicht über Delphi solltest Du eventuell mal hinterfragen. Da hat sich nämlich auch "ein bisschen" was getan und heute ist die Aufgabe nicht mehr "ein Fenster aufmachen" sondern z.B. Daten aus einer Exceltabelle zu lesen, zu verarbeiten und das Ergebnis in einer SQL-DB zu speichern, damit der WEB-Server die aktualisierten Daten auf einer WEB-Site anzeigen kann. Willkommen in diesem Jahrhundert^^ http://www.embarcadero.com/de/products/delphi (Nein, ich habe mit denen nix zu tun. Aber Delphi war schon zu CP/M & DOS Zeiten ganz nice und hat diese "Pauschalverurteilung" mMn nicht verdient.) A.
Deine Meinung. Meine kennst Du auch und ich will weder Pascal noch Delphi. Dieser Thread hier ist entstanden weil ich eben nicht mit irgendeiner aktuellen Programmiersprache irgendwas anfangen will, sondern mit der für mich richtigen Programmiersprache. Wenn das OS die angesprochene DLL sowieso benutzt und sie deswegen auch immer vorhanden ist, dann ists mir egal wie groß sie ist. Was mich ärgern würde ist wenn ich sie mitschleppen und mit-installieren muß, weil außer meinem Kram nichts sie benutzt. Ich werd mir C# mal genauer anschauen. Hoffe nur die Befehle sind einfach erlernbar, daß man nicht mehr Zeit über der Befehlsreferenz brütet, als man fürs eigentliche Programmieren aufwendet. Kann man mit C# auch ohne .NET arbeiten oder ist man gezwungen, es zu verwenden und kriegt Probleme wenn es auf irgendeiner alten Kiste mal nicht installiert ist?
Ben _ schrieb: > Hoffe nur die Befehle sind > einfach erlernbar Befehle gib es nicht wirklich viele, bei modernen Sprachen muss man wissen Klasse es gibt und welche Methoden sie anbieten.
Ben _ schrieb: > Kann man mit C# auch ohne .NET arbeiten oder ist man gezwungen, es zu > verwenden und kriegt Probleme wenn es auf irgendeiner alten Kiste mal > nicht installiert ist? c# ist .net. Es kann nicht ohne gehen. Und ab WinXP ist es immer mit drauf. Zumindest Version 2.0. Wenn du auf 3.0 setzt, dann musst du damit rechnen das es nicht überall vorhanden ist.
Ben _ schrieb: > Dieser Thread hier ist entstanden weil ich eben nicht mit irgendeiner > aktuellen Programmiersprache irgendwas anfangen will, sondern mit der > für mich richtigen Programmiersprache. > ... > > Kann man mit C# auch ohne .NET arbeiten oder ist man gezwungen, es zu > verwenden und kriegt Probleme wenn es auf irgendeiner alten Kiste mal > nicht installiert ist? Es gibt halt nicht DIE Programmiersprache, jede hat seine Vor- und Nachteile und ist letzten Endes ein Kompromiss... und auch eine Sache des persönlichen Geschmacks! C# ist Bestandteil von .NET ... ohne .NET kein C# :-)
> c# ist .net. Es kann nicht ohne gehen. Gerade schon selbst gemerkt. Na gut. Suboptimal sage ich mal. > Befehle gib es nicht wirklich viele, bei modernen Sprachen muss man > wissen Klasse es gibt und welche Methoden sie anbieten. Genau das ist das was ich eigentlich hasse... :-/ Body.Ass.Shit(What.HolyShit, Speed.Emergency, Extra.UnStoppable); **kicher** Wie soll man denn lernen was es da so alles gibt, wie's heißt (also wie es genannt wurde, nicht wie man es selbst nennen würde) und was es kann wenn man damit anfängt? Naja was mich da am Anfang noch interessiert sind Schleifen, Vergleiche (IF), Subroutines, evtl. Sprungbefehle... Inline-Assembler möglich?
Ben _ schrieb: > Inline-Assembler möglich? Mit .NET? Nö. Der Compiler erzeugt Byte/Zwischencode, der erst beim Ausführen intperpretiert oder per JIT in den jeweils passenden Maschinencode übersetzt wird, also wie Java. (Deswegen laufen C#-Programme angeblich ohne Neukompilierung auf ARM/WindowsRT) Du kannst natürlich eine ASM-DLL von C# aus ansprechen...
Hrm. Heißt das, es ist für besonders schnelle Rechenaufgaben nicht geeignet? Das gefällt mir gar nicht. Dann lieber doch C/C++ glaube ich.
Ben _ schrieb: > Genau das ist das was ich eigentlich hasse... :-/ Du hasst mächtige Frameworks, die für fast alle Probleme des Entwickler-Alltags sauber implementierte, performante und gut durchdachte Lösungen anbieten? Willst du alles von Grund auf selber schreiben? Dann kommst du aber nicht weit...
Ben _ schrieb: > Dieser Thread hier ist entstanden weil ich eben nicht mit irgendeiner > aktuellen Programmiersprache irgendwas anfangen will, sondern mit der > für mich richtigen Programmiersprache. > Cool. Wenn Du sie findest, lass es mich wissen. Ich such da ja auch. Aber est seit 35 Jahren. > Was mich ärgern würde ist wenn ich sie mitschleppen und mit-installieren muß, > weil außer meinem Kram nichts sie benutzt. Was einen Projektleiter ärgern würde ist, wenn Du 3MW damit verschwendest etwas neu zu implementieren, statt eine evtl. schon vorhandene DLL/Assembly zu benutzen, deren paar MB auf dem Auslieferungsmedium nicht mehr auffallen. Liegt evtl. daran, dass da Kosten entstehen die micht nur Esoterisch sind oder vielleicht auch daran, dass der "Eigenbau" typischerweise schlechter getestet ist als ein existierendes Standardmodul in >1Mio. Installationen ? Gruss Andreas
Ben _ schrieb: > Hrm. Heißt das, es ist für besonders schnelle Rechenaufgaben nicht > geeignet? Das gefällt mir gar nicht. Dann lieber doch C/C++ glaube ich. C# wird genauso kompiliert wie C/C++ auch...
Milord schrieb: > C# wird genauso kompiliert wie C/C++ auch... Nö. C# wird üblicherweise in CLI übersetzt. http://de.wikipedia.org/wiki/Common_Language_Infrastructure C und C++ in Maschinenkode. "Managed C++" etc ist viel näher an C# als an "echtem" C++ dran. Wird auch zu CLI.
Εrnst B✶ schrieb: > Nö. > C# wird üblicherweise in CLI übersetzt. > http://de.wikipedia.org/wiki/Common_Language_Infrastructure > > C und C++ in Maschinenkode. Nö. Schon mal was vom JIT gehört? Der IL wird vor der Ausführung in Maschinencode übersetzt, genauso wie C oder C++....
Ben _ schrieb: > Hrm. Heißt das, es ist für besonders schnelle Rechenaufgaben nicht > geeignet? Das gefällt mir gar nicht. Dann lieber doch C/C++ glaube ich. nein, sogar das gegenteil kann der Fall sein, der optimierer sieht noch den code damit kann er sogar amhängig von den Werten den code optimieren. bei berechnungen wirst du keinen unterschied feststellen können. Was etwas langsamer ist, sind zugriffe auf array weil da teiweise bereichtsprüfungen gemacht werden.
Milord schrieb: > Schon mal was vom JIT gehört? Natürlich. Hab ich oben auch geschrieben. Hast du verstanden, was ein JIT macht, und wann/wo er zum Einsatz kommt?
Εrnst B✶ schrieb: > Milord schrieb: >> Schon mal was vom JIT gehört? > > Natürlich. Hab ich oben auch geschrieben. > > Hast du verstanden, was ein JIT macht, und wann/wo er zum Einsatz kommt? Ich denke schon ;-) Der JIT übersetzt vor der Ausführung den Code von der IL in Maschinencode.
> Cool. Wenn Du sie findest, lass es mich wissen. > Ich such da ja auch. Aber est seit 35 Jahren. Hm. Ist was dran... so alt bin ich noch nicht. :-/ > Du hasst mächtige Frameworks, die für fast alle Probleme des > Entwickler-Alltags sauber implementierte, performante und gut > durchdachte Lösungen anbieten? Das ist der einzigste Vorteil, den sie bieten... gebe ich zu. > Willst du alles von Grund auf selber schreiben? > Dann kommst du aber nicht weit... Für sowas sollten evtl. DLLs vorhanden sein wenn man sie braucht. Mir gehts um ein Hobby und nicht um eine schnelle quick'n'dirty- aber dafür marktreife Lösung... Ich möchte aber am Ende echten ausführbaren Code erhalten und nicht irgendwelche Zwischen-Implantate, auf die sich dann ein Interpreter oder noch irgendein Compiler stürzen muß.
Ben _ schrieb: > Hrm. Heißt das, es ist für besonders schnelle Rechenaufgaben nicht > geeignet? Das gefällt mir gar nicht. Dann lieber doch C/C++ glaube ich. naja die v8 script engine von google schafft durch just-in-time-compiling und optimizing schon eine beträchtliche ausführungsgeschwindigkeit. http://www.youtube.com/watch?v=UJPdhx5zTaw 45:19 das script ist 17% langsamer als -O3 compilierter c-code! besonders schnelle rechenaufgaben lässt man den comiler optimieren, weil die besser optimieren wie du es in asm je könntest... die wissen nämlich ganz genau wie deine CPU tickt (caches, vector-units, ...) ausserdem ist typischerweise der algorithmus das problem (in dem video kommt ein 46:30 heraus, dass bei dem problem durch einen gefixten algorithmus faktor 40 drinnen war) asm war gestern (es sei denn man bau scheduler,compiler,... udgl)! 73
Milord schrieb: > Ich denke schon ;-) Der JIT übersetzt vor der Ausführung den Code von > der IL in Maschinencode. genau. Betonung auf (kurz) "vor der Ausführung". Sonst wäre auch "MS-Basic 1.0 für CP/M" eine "Kompilierte Sprache für x86_64-CPUs", nur weil mit ein paar Emulationsschichten dazwischen ein Basic-Befehl zur Ausführung eines Berges an Maschinencode auf der Intel-CPU führt...
Εrnst B✶ schrieb: > genau. Betonung auf (kurz) "vor der Ausführung". > > Sonst wäre auch "MS-Basic 1.0 für CP/M" eine "Kompilierte Sprache für > x86_64-CPUs", nur weil mit ein paar Emulationsschichten dazwischen ein > Basic-Befehl zur Ausführung eines Berges an Maschinencode auf der > Intel-CPU führt... Ich finde den Vergleich ein bisschen merkwürdig. MS-Basic scheint mir eine interpretierte Sprache zu sein. Das ist ja was ganz anderes als z.B. C#. C# ist dann doch eher mit C++ zu vergleichen, nur das bei C++ der gesamte Code zur Compilezeit kompiliert wird. Bei C# wird das Kompilieren dann nach hinten, d.h. in die Laufzeit verschoben um so mehr Flexibilität zu erreichen. Das Endergebnis (Maschinencode) ist aber in beiden Fällen das gleiche, und nicht mit interpretierten Sprachen zu vergleichen.
:-/ Ich möchte mich wirklich ungerne von Assembler und echtem greifbaren Code als Endprodukt trennen... Gibts irgendwo 'ne Klassenübersicht oder wie man das nennen soll, was C# alles kann? Meine, echten Maschinencode kann ein X86 auch in 20 Jahren noch ausführen, aber wer sagt, daß auf dem OS in 20 Jahren noch das nötige .NET Framework vorhanden ist?
Ben _ schrieb: > Meine, echten Maschinencode kann ein X86 auch in 20 Jahren noch > ausführen, aber wer sagt, daß auf dem OS in 20 Jahren noch das nötige > .NET Framework vorhanden ist? So würde ich das nicht sagen. Code ohne irgend ein Framework dahinter macht ja wenig Sinn. Irgendwelche Daten musst du verarbeiten (Dateien, Datenbanken, Webzugriffe), und irgendwie musst du mit der Hardware interagieren (Maus und Tastatureingaben, Grafische Ausgabe, Fensterframework, Sounds, IO-Schnittstellen etc.). Dazu brauchst du nun mal ein Framework. Und .NET ist da wunderbar geeignet und genaus zukunfts(un)sicher wie andere Frameworks auch...
Deswegen ja im Zweifel kein Framework verwenden, sondern die hoffentlich langlebigen Windows-Standard-Funktionen...
Ben _ schrieb: > Meine, echten Maschinencode kann ein X86 auch in 20 Jahren noch > ausführen, aber nur wenn es noch passende CPUs gibt. Auf ARM läuft den code schon nicht mehr. > aber wer sagt, daß auf dem OS in 20 Jahren noch das nötige > .NET Framework vorhanden ist? niemand Aber wenn du mit ASM eine GUI machen willst, dann brauchst du auch 20Jahre bis sie fertig ist.
Ben _ schrieb: > Meine, echten Maschinencode kann ein X86 auch in 20 Jahren noch > ausführen, aber wer sagt, daß auf dem OS in 20 Jahren noch das nötige > .NET Framework vorhanden ist? Auf diesem Niveau kannst Du Dich auf jeden Fall noch 20 Jahre vor dem programmieren drücken. Software über 20 Jahre lauffähig zu halten ist Arbeit. VIEL Arbeit. Fang doch einfach mal an. Notfalls reicht auch PowerShell damit Du erst mal alles was hier geschrieben wurde überhaupt einordnen kannst. Gruss Andreas
bezweifle ich... ist nur eine frage der zeit bis x87 endgültig rausfliegt.. selbes gilt für 16bit execution,real-mode... 73
Milord schrieb: > Ich finde den Vergleich ein bisschen merkwürdig. Jo, hinkt etwas, Trotzdem: Basic-Befehle vorne rein => Intel-Maschinencode kommt hinten zur Ausführung. Bei VB.NET, C#, Java usw üblich: Der Compiler erzeugt einmalig den Intermediate-Code (Java-Bytecode, CLI-Bytecode, ...). (jedesmal) bei der Ausführung wird dieser in Maschinencode übersetzt (Interpretiert oder per JIT) Bei C/C++ üblich: Der Compiler erzeugt einmalig den Maschinencode. Dieser kann direkt ohne Zwischenschicht auf der CPU laufen. Nicht falsch verstehen: ich halte die IL-Zwischenschicht nicht für schlecht. Die daraus resultierenden Vorteile wiegen den geringen, wenn überhaupt vorhandenen Geschwindigkeitsverluts bei weitem auf. Trotzdem sollte man sich im Klaren darüber sein, dass das zwei verschiedene Konzepte sind.
Ben _ schrieb: > Ich hab immer Schwierigkeiten wenn irgendwas "zu relativ" ist. > Weiß nicht wie ich das ausdrücken soll, aber beim Aufbau des > Anwendungsfensters wäre es mir lieb wenn ich sagen kann Fenster feste > Größe, Text an Koordinaten blah, Eingabezelle an Koordinaten blub, > Button mit Funktionsaufruf X an Koordinaten laberlaber... ;) Dann weiß > ich vielleicht auch ohne langes Suchen wo der eigentliche Programmcode > hin muß. Das ist aber Murks. Die Layouts, die in allen respektablen GUI-Frameworks benutzt werden, sind schon der richtige Weg. Absolut positionierte Widgets führen dazu, dass sich Fenster zum Beispiel nicht vernünftig skalieren lassen, was mich persönlich zum Beispiel wahnsinnig macht. ;)
Also mein alter PowerBasic-Kram läuft alles noch. Meine Assembler-Programme laufen noch, ausgenommen auf spezielle Hardware zugeschnittene Dinge wie Soundblaster-Karten. Und die naja ich nenne sie mal auf DOS und seine Dateien zugeschnittenen Spezialprogramme laufen auch nicht mehr bzw. es macht keinen Sinn sie in einer DOS-Box zu starten wo sie kein Futter kriegen. Also doch CSchurk?
Ben _ schrieb: > Also mein alter PowerBasic-Kram läuft alles noch. mach doch was du willst, wenn du C# nicht willst dann nimm es nicht. Es zwingt dich keiner. Wenn du viel zeit hast darst du auch alles in ASM machen. Mein C# Programme laufen sogar unter linux dein ASM auch?
Linsucks läuft noch nicht mal auf meinen Rechnern... :D > Absolut positionierte Widgets führen dazu, dass sich Fenster zum > Beispiel nicht vernünftig skalieren lassen Ist mir klar. Aber was willst Du zB. beim Standard-Fenster wie WinAmp eines nutzt groß skalieren?
Ben _ schrieb: > Also mein alter PowerBasic-Kram läuft alles noch. Ach ja ? Dann poke mal in die Graphikkarte (könnte sogar noch klappen) oder gib auf der V24 empfangenen Zeichen auf dem Parallelport aus. Wobei das ja erst richtig spassig wird, wenn V24 & LPT an Deinem Rechner USB Ports sind, die per FTDI chips die Ports nachbilden. Sollte das alles gehen, dann ist Dein "Problem" doch gelöst. Bleib bei PowerBasic :-) Gruss Andreas
Ben _ schrieb: > Ist mir klar. Aber was willst Du zB. beim Standard-Fenster wie WinAmp > eines nutzt groß skalieren? Und wenn du dann mal eine Liste, Textbox oder ähnliches verwendest? Wie machst du das dann mit der Skalierung? Oder gibts solche Steuerelemente bei dir nicht?
Ben _ schrieb: > Meine, echten Maschinencode kann ein X86 auch in 20 Jahren noch > ausführen, aber wer sagt, daß auf dem OS in 20 Jahren noch das nötige > .NET Framework vorhanden ist? Das mag für Anwendungen, die in der Console laufen, gelten. Auch mit reinstem Maschinencode wirst du aber bei richtige Windows-Programmen nichts anderes tun, als die entsprechenden Windows-Bibliotheksfunktionen auzurufen. Und du kannst ziemlich sicher sein, daß es die in 20 Jahren in der heutigen Form nicht mehr gibt. Im übrigen kümmerst du dich um die falschen Probleme. Du brauchst, um Windows-Programme erstellen zu können, zwingend eine (Klassen-)Bibliothek, die dir das Gehampel mit den Win32-API-Funktionen abnimmt. So viele frei verfügbare Systeme dieser Art gibt es da gar nicht. Von Microsoft bekommt du zwar den C/C++-Compiler nebst IDE kostenlos, aber die Windows-Klassenbibliothek für C/C++ nicht. gcc als freier Compiler ist Klasse, dazu brauchst du dann auch wieder die passenden Windows-Bibliothek. QT, GTK+, wxWidgets als vollwertige (oder gar bessere !) Alternativen wurden schon genannt, dann kenne ich noch Ultimate++, und das wars dann beinahe schon mit wirklich vollwertigen Systemen für C/C++. Dann gibts halt Java. Ist Klasse für mal eben eine Applikation zu basteln, das Ergebnis fühlt sich aber nie so richtig wie eine native Windowsprogramme an. Bleiben noch C# und Visual Basic. Beides kostenlos und mit Klassenbibiliothek, und das wars dann schon. So einen Liste hättest du dir aber mit etwas Mühe und google selber aufstellen können. Danach mal die für dich interessantesten Lösungen besorgen, installieren, und ausprobieren. Was du dann merken wirst, ist, daß das wesentlichste eine ausführliche Dokumation mit möglichst vielen verfügbaren Besipielprogrammenn ist, und daß du bisher wohl die falschen Vorstellungen davon hast, was es bedeutet, eine Windows-Anwendung zu erstellen. Am Ende ist die dafür verwendete Programmiersprache nämlich völlig egal. Du stellst schlicht die völlig falschen Fragen. Oliver
Ben _ schrieb: > Ist mir klar. Aber was willst Du zB. beim Standard-Fenster wie WinAmp > eines nutzt groß skalieren? Hier mal einige Beispiele, von denen immer wichtig ist, dass sie richtig skalieren: Line Edits, Text Edits, Dropdown-Listen sollten sich an die Breite vom Fenster anpassen. Buttons wie "Ok" oder "Anwenden" sollten immer rechts unten sein, und nicht irgendwo in der Mitte vom Fenster rumschweben (was passiert, wenn man absolute Positionierung verwendet). Ganz wichtig ist das natürlich falls das Programm irgendwas anzeigt (Diagramme etc.), das muss skalierbar sein. Absoute Positionierung von GUI-Widgets ist wirklich total unprofessionell. Kein vernünftiger Mensch macht sowas. ;)
Im Moment gibts noch gar keine Bedienelemente ... :D Ich denke in dem Moment wo das Fenster nicht so groß sein muß wie eine Winword-Oberfläche oder Excel wo der Bildschirm nicht groß genug für die Tabelle sein kann brauche ich nicht unbedingt eine gute Skalierbarkeit. Wenn mal sowas kommt wo ichs brauche, kann ich mir darüber immer noch Gedanken machen. PowerBasic, zumindest das alte, kann halt nichts können was es damals noch nicht gab. Mit dem richtigen Treiber wäre es sicher möglich, aber so sehr hänge ich da doch nicht dran. Die Assembler-Programme, die einen hardware-nah angesprochenen Grafikmodus benutzen laufen noch in der DOS-Box...
Ben _ schrieb: > Wenn mal sowas kommt wo ichs brauche, kann ich mir darüber immer noch > Gedanken machen. Außer natürlich du verwendest eines der Frameworks, die das nicht vernünftig unterstützen. Was leider wohl für ziemlich viele gilt.
Ben _ schrieb: >... brauche ich nicht unbedingt eine gute Skalierbarkeit. Das war unter Windows 3.1 schon immer offensichtlich, welcher Programmierer da genauso gedacht hat... schon damals konnte man die DPI des Bildschirms einstellen, und eigentlich sollten sich die Applikationen daran halten... Was ist sooo schlimm daran, beim Programmieren zu sagen "Button 2" ist rechts von "Button 1" anstatt von: Button1 liegt bei Pixel 320,155 und ist 32 Pixel hoch und 100 Pixel breit, egal ob der Beschriftungstext reinpasst oder nicht. Button2 liegt bei 450,166 ...
> Was ist sooo schlimm daran, beim Programmieren zu sagen > "Button 2" ist rechts von "Button 1" Daß alles irgendwie neben allem liegt und niemand weiß wo. Irgendein kleiner Fehler zerstört dann alle Abhängigkeiten komplett, killt das komplette Layout und man findet ihn nie weil man nicht weiß wo man suchen soll. Oder wenn ich mir die Oberfläche ohne Programm zusammenbaue und sie hinterher mit dem Programm verknüpfe - eine kleine Änderung weil einem noch was eingefallen ist oder so und man kann komplett von vorne anfangen weil man die Änderung nicht eingepflegt kriegt ohne die bestehenden Verknüpfungen durcheinanderzumixen.
Ich denke du hast Recht. Am sichersten, einfachsten, schnellsten, effektivsten und zukunftssichersten ist es, wenn du deine Anwendungen in ASM schreibst. Die GUI kannst du dann per Win32 API ganz komfortabel erstellen. Ich würde auch alle Postionen und Größen Pixelgenau hard-coden, dann kann nichts schief gehen. Viel Erfolg!
Εrnst B✶ schrieb: > Milord schrieb: >> Ich denke schon ;-) Der JIT übersetzt vor der Ausführung den Code von >> der IL in Maschinencode. > > genau. Betonung auf (kurz) "vor der Ausführung". Oder mit ngen deutlich vor der Ausführung http://msdn.microsoft.com/en-us/library/6t9t5wcf.aspx bzw. ab Windows 8 automatisch im Hintergrund (Native Image Task).
Warum muss es eigentlich unbedingt eine "Windows-Anwendung" sein? Oder hast Du da Spielraum? Zum Beispiel, da Du php beherrscht, könnte die Anwendung auch als Web-Applikation implementiert werden und dann via Internet Explorer funktionieren?
Ey also nu reichts aber wirklich mal. Ich wollte wissen was für eine einigermaßen zeitgemäße Programmiersprache für Windoofs-Anwendungen "am besten" ist oder am besten zu dem was ich mir so vorstelle passt. Ich wollte nicht wissen wie ich die Oberfläche meiner Anwendung zu gestalten habe damit sie Milord-zertifiziert werden kann. Sorry, danke Dir aber trotzdem für Deine Hilfe.
Schorsch schrieb: > Zum Beispiel, da Du php beherrscht, könnte die > Anwendung auch als Web-Applikation implementiert werden und dann via > Internet Explorer funktionieren? nein dann kann er ja nicht feste Pixel vorgeben
Schorsch schrieb: > Zum Beispiel, da Du php beherrscht, könnte die > Anwendung auch als Web-Applikation implementiert werden und dann via > Internet Explorer funktionieren? Son' neumodischen Kram? Nur in Assembler hardcodierte Programme sind richtige Programme, selbst Delphi ist Teufelszeug, und alles, was danach erfunden wurde, sowieso. In diesem Sinne... Oliver
> nein dann kann er ja nicht feste Pixel vorgeben
Klar könnte ich.
PHP kann aber nur auf dem Server laufen, nicht auf dem Client-Rechner.
Macht sich ein wenig schwer, wenn man zB. zum Einlesen irgendwelcher
Daten via USB oder so einen Webserver auf dem Rechner laufen lassen
muß...
Eventuell könntest Du Deine Applikation in Excel implementieren, mit Makro's und so
Ben _ schrieb: > Oder wenn ich mir die Oberfläche ohne Programm zusammenbaue und sie > hinterher mit dem Programm verknüpfe - eine kleine Änderung weil einem > noch was eingefallen ist oder so und man kann komplett von vorne > anfangen weil man die Änderung nicht eingepflegt kriegt ohne die > bestehenden Verknüpfungen durcheinanderzumixen. Deshalb nutzen alle brauchbaren Bibliotheken mittlerweile eine passende Beschreibungssprache für die GUI: Qt = QML + JavaScript, .NET = XAML + VB/C#/C++/etc (oder auch HTML5 + JavaScript, Win8)
Was die Skalierung von GUIs anbetrifft, habe ich mit GTK und Glade recht gute Erfahrungen gemacht. Als Programmiersprache bieten sich C, python oder Vala an. Nebenbei bist du damit auch weitestgehend Plattformunabhängig
Hallo, ich behaupte mal, wer von uns schon lange Zeit programmiert, hat mehrere Sprachen gelernt und nicht die eine "richtige". Wenn man Sprachen, die man ganicht kennt, aus irrationalen Gründen hasst und bewährte Workflows z.B. zur GUI-Erstellung ebenso irrational ablehnt, hat man sich von der erfolgreichen Weiterentwicklung als Programmierer schon verabschiedet. Von einem Programmierer der den Namen verdient erwarte ich, dass er in kurzer Zeit auch in einer neuen Sprache arbeiten kann. Bei Vorstellungsgesprächen kommt es auch besonders gut an, wenn man gleich zu Beginn unmissverständlich klarstellt, dass man alle Vorgaben des Arbeitgebers bezüglich verwendeter Sprachen und Werkzeuge strikt ablehnt und sich unter keinen Umständen weiterbilden will. Personalchefs lieben solche Bewerber. Gruss Reinhard
von mir: Auch wenns nicht gewünscht wird: Ich empfehle Delphi. Ich programmiere seit Jahren damit. Man mann kompakte EXEs, welche keine weiteren DLLs benötigen, erstellen. Die Programme sind sehr schnell erstellt, haben gute Ausführungsgeschwindigkeit und laufen stabil. Auch muss auf dem Zielrechner kein spezielles .NET, Java, Servicepack etc vorhanden sein. Einfach EXE starten und gut ists. Für graphische Oberflächen gibts ein riesiges Framework, zusätzlich noch tausende Komponenten von anderen Anbietern.
Achso Tschuldigung, ich wußte nicht, daß ich hier Bewerbungsgespräche führen muß. Dann bin ich hier ja völlig falsch! Naja, bissel schade, daß das so ausartet, es waren doch paar gute Ansätze dabei. Mal sehen was es mir nutzt. Danke euch für die hilfreichen Antworten!
Milord schrieb: > Die GUI kannst du dann per Win32 API ganz komfortabel > erstellen. Ich würde auch alle Postionen und Größen Pixelgenau > hard-coden, dann kann nichts schief gehen. Genau. Ben _ schrieb: > Klar könnte ich. > Nein, kannst Du nicht. Oder wie gibst Du dem Browser aus Deiner Dosbox heraus die Fenstergröße vor ? (Um nur eins der Probleme dabei zu nennen) > PHP kann aber nur auf dem Server laufen, nicht auf dem Client-Rechner. Dann lass halt den Server auch auf dem Client laufen. Ist nicht schwierig. Also wenn man darauf verzichtet, keine DLLs zu benutzen. > Macht sich ein wenig schwer, wenn man zB. zum Einlesen irgendwelcher > Daten via USB oder so einen Webserver auf dem Rechner laufen lassen > muß... Nö, wieso ? Aber dann geht USB in ASM in der DosBox schon mal bei Dir ? Magst Du nicht mal den Code posten ? Ich bin da zu dusselig und brauch immer einen Gerätetreiber. Und der ist igit mit einer "Bäh-"DLL gekoppelt. Und, stimmt schon, das kostet Hauptspeicher. Und der Laptop hat leider nur 4G :/
Ben _ schrieb: > Gibts irgendwo 'ne Klassenübersicht oder > wie man das nennen soll .Net-Framework: http://msdn.microsoft.com/en-us/library/gg145045.aspx Ein wenig über C#: http://msdn.microsoft.com/en-us/library/67ef8sbd.aspx
Ben _ schrieb: > Danke euch für die hilfreichen Antworten! Du hast gefragt, es wurde geantwortet, die Antworten haben Dir nicht gefallen weil Deine Vorstellungen völlig weltfremd sind, die Leute nehmen Dich nicht mehr für voll. Du willst ASM hacken ? Google mal nach Ocelot SQL. Ein DOS SQL-Datenbanksystem, das komplett in Assembler geschrieben war. Lies den Code und überleg Dir ob Du DAS auch so hinbekommen hättest. Du willst unter Windows programmieren ? Was ? Nur zum Spass ? --> C# Plattformübergreifend ? --> Java Du bist Rookie aber hart im nehmen ? --> C++ & QT/GTK etc etc (das mit den Memoryleaks kriegt man meist in den Griff, obwohl ein befreundeter SW-Projektleiter mal meinte, ab 1Mio LOCs hat man da immer noch irgendwo was) Du brauchst Rechenperformance ? -> Intel F90 oder Lahey F95. Beide mit add NAG Lib. Wieviel Antworten mit immer den gleichen Aussagen willst Du denn noch ? Gruss Andreas
> Windoofs > Linsucks > CSchurk Kindergarten? > DOS-Box Eine DOS-Box gibt es nicht mehr seit Windows 3. > PHP kann aber nur auf dem Server laufen, nicht auf dem Client-Rechner. Komisch. Bei mir kann ich php in der commandline ausführen. (Win 7) > Bitte keine Zusammenklick-Sachen Ist das zu kompliziert für Dich oder warum nicht? > Wo genau ist der Unterschied zwischen C, C++ und C#? Ich vermutete schon, du hast keine Ahnung. Herzlich willkommen im neuen Jahrtausend! Free protip: Mit der Einstellung wirst du NIE was ordentliches bringen. Viel Glück im Leben.
dann bleib doch bei php... wie oben erwähnt rennt php auch auf der cmd-line... zusätzlich: http://en.wikipedia.org/wiki/PHP-Qt 73
>Wo genau ist der Unterschied zwischen C, C++ und C#?
ok, da hab ich dann aufgehört
im Eröffnungspost über Delphi mosern, aber solche fragen stellen...
Peter S. schrieb: > Gucke mal PureBasic !!! > > http://www.purebasic.com/german/index.php wenn ich schon sotwas lese [...] - Sehr schneller Compiler, welcher hochoptimierte Executables erzeugt und globalen Variablen - Optimale Ausnutzung der verfügbaren Hardware durch Verwendung hochoptimierter (Asm) Befehle [...] was wohl hochoptimierter Asm Befehle sind? [...] - Unterstützung von Prozeduren zum strukturierten Programmieren mit lokalen und globalen Variablen [...] Sogar Prozeduren mit werden unterstützt, na wenn das nichts ist.
Robert L. schrieb: >>Wo genau ist der Unterschied zwischen C, C++ und C#? > > ok, da hab ich dann aufgehört > > im Eröffnungspost über Delphi mosern, aber solche fragen stellen... Den Teil fand ich noch relativ "normal". Wieviel Leute lästern über Common-Lisp obwohl sie noch nie versucht haben ein Problem damit zu lösen ? Ich kenne Einige (meist Profis), die es probiert haben und dann dabei geblieben sind. Die langweilige MS-Win/MacOS/Linux Zankerei ist ja auch ähnlich... Ärgerlicher finde ich, wenn jemand um Hilfe bittet, sich aber gleichzeitig weigert, Vorschäge anzunehmen weil irgendwelche Gründe dagegensprechen, die heutzutage einfach völlig nebensächlich geworden sind oder die Anforderungen nicht erfüllen, die (vermutlich) garnicht vorhanden sind. Absolute Positionierung von GUI-Elementen z.B. haben wir mal unter DOS gemacht (@TE: Mit TurboPascal 3 & Graphicstoolbox :p ). Heutzutage wäre man sehr verärgert, wenn das GUI sich beim Ändern der Fenstergröße nicht anpasst (man denke bloss mal an Sidebars die dann "mittig" auf dem Bildschirm stehen). Zu DOS Zeiten war Watcom C ein praktisches Tool weil es die 640K Barriere sehr elegant umgehen konnte. Interessiert heute auf aktuellen Maschinen nicht mehr. Für Apple-II gab es UCSD Pascal, das nicht 6502 Asm, sondern PCode auswarf (das Konzept sollte CIL & JIL Fans bekannt vorkommen). Tolles Tool. Interessierte keinen mehr als TurboPascal & IBM PC bezahlbar wurden. Unbestritten gibt es heutzutage noch Anwendungen für statisch gelinkten Asm-code. Aber im "normalen" PC Umfeld ? Doch eher nicht. Peter II schrieb: > was wohl hochoptimierter Asm Befehle sind? Das gibts wirklich. Die Instruction-selection der Codeerzeugungsphase des Compilers erzeugt aus dem Intermediate Code ja den ASM Schnipsel, der am besten passt, z.B "XOR X, X" (typ. 1-2 Byte) statt "MOX X, #$00000000" (mind. 5 Byte) Ausserdem verkauft sich das ja toll an Leute, die das letzte Quentchen an Rechenleistung aus ihren Rechnern rausktzeln wollen, damit die Kiste mehr Zeit für die Idle-Loop hat. Man muss Prioritäten setzen ;-) Grüße Andreas
Ich schließe mich der Meinung von Andreas an. Ben, du gibst ja selber zu, dass du nicht so viel Erfahrung hast. Das ist ja auch völlig okay. Aber dann lass' Dir doch auch raten, dass zum Beispiel Pixel-positionierte GUIs einfach dem letzten Jahrtausend angehören. Natürlich kann man sich mit Anchors oder Layouts auch in den Fuß schießen, aber es ist halt trotzdem das bessere Konzept. Und dass da immer alles verrutscht oder so irgendwas ist ein Aberglaube, genau das Gegenteil ist der Fall: Probleme mit dem nachträglichen Einfügen eines Buttons hat man genau dann nicht, wenn man die Elemente in einem geeigneten Layout anordnet. Dass hier einige etwas exotischere Vorschläge kommen war ja auch völlig klar, und die kann man auch ganz einfach ignorieren -- zweimal, wenn man keine stichhaltigen, klar und kurz zu formulierenden Argumente dagegen hat. Für ein ebenso unsinniges Argument halte ich sowas wie "Größe der Executables"... okay, die sind bei einigen Lösungen größer als bei anderen. Und? Bringt das einen relevanten Performance-Nachteil (oder überhaupt sonst irgendeinen Nachteil)? Nein. Also? Die Notwendigkeit zusätzlicher Abhängigkeiten hingegen könnte man schon eher zum Thema machen.
Ben _ schrieb: > Woher wußte ich, daß selbst bei so einfachen Fragen wieder Trolle mit > völlig sinnfreien Postings ihren vergammelten Senf dazukippen müssen? > Man muß es Dir schlecht gehen, daß Du mir auf Deibel komm raus versuchen > mußt an die Karre zu pissen. Er kapiert die Antwort nicht, also pöbelt er rum. Dein 30-Byte-DOS-Programm macht viel weniger im Hintergrund als dein 100kB-Delphi-Programm. DInge, die gebraucht werden, sobald man mehr machen will als das Spielprogramm "Konsole löschen", so daß der Unterschied schnell gering wird oder sich gar umdreht. Aber nein, der Herr ist ja entweder zu dumm, das zu begreifen, oder zu etepetete ("mimimi, das ist Pascal, das mag ich nicht. C kenne ich zwar nicht, aber das ist viel besser. Sagen alle meine Leet-Kumpelz.").
Bin grad im python-Fieber (unter debian squeeze). Das einzige was jetzt doof ist: wenn ich Atmega8 proggen will muss ich in die low-level-Welt von C & co. dank meiner langjährigen Erfahrung mit python (so ca. ne Woche) habe ich schon folgende Infos gefunden: Man kann mit python: - wissenschaftliche Berechnungen "freie Matlab-Konkurrenz" (numpy, scipy, matplotlib, ipython) - games: z.B. pygame (ist im Grunde SDL) - scripting - web-programming (django) - GUI: tk (nativ eingebaut), pygtk, pyqt, wxwidgets - plattformunabhängig - opensource-sprache - schöne syntax - interpretiert ( kann man auch mit reich werden, bsp.: minecraft in java [jaja, vom Tellerwäscher zum PopStar]) Wie aufwändig das Installieren der Bibos unter Windows ist weis ich nicht. Unter Debian squeeze z.B. copy&paste ins Terminal (wenn internet verbunden ist): sudo apt-get install python python-qt4 python-matplotlib python-gnuplot python-scipy python-pygame python-wxtools und man hat Alles, was cool ist. (Debian squeeze installiert python2.6.6) (der Befehl sollte unter Ubuntu genauso funktionieren, weis aber nicht welche Versionen die dort installieren, wenn nicht, die tools einzeln installieren... Oder eben im grafischen Paketmanager in die Python-Kategorie gucken) Ich wollte z.B. schon immer mal wissen, wie man 3D in der Praxis macht (also auch ohne openGL-Zauberrei, in Software und danach openGL lernen). Das kann man hier gut (in drei Stepps) nachvollziehen: http://codentronix.com/2011/04/20/simulation-of-3d-point-rotation-with-python-and-pygame/ http://codentronix.com/2011/04/21/rotating-3d-wireframe-cube-with-python/ http://codentronix.com/2011/05/12/rotating-3d-cube-using-python-and-pygame/ :-)
Jetzt brauchst du nur noch kdevelop-python als IDE, dann ist das Ganze perfekt ;)
Also sagen wir einfach mal aus persönlichen Gründen kommt mir Pascal und Delphi nicht ins Haus. Punkt, Aus, Ende, Feierabend. Bevor ich mit dem Dreck anfange mache ichs lieber mit Assembler und der Windows-API. Mir gefällt das beides einfach nicht und das geb ich offen zu, wo ist da das Problem? Das einzige was ich mir vorwerfen lassen muß ist, daß ich beides nicht bereits im Eröffnungsposting ausgeschlossen habe... Okay - mea culpa - kommt nicht wieder vor...! Zweitens hab ich im Moment nicht vor, irgendwelche hochkomplexen Programme mit noch komplexerer Benutzeroberfläche zu schreiben. Und manche kacken sich ins Hemd weil zB. der Windows-Rechner nicht skalierbar ist - au man! Sowas in der Größe dieses Rechners oder ggf. noch kleiner reicht mir im Moment völlig aus, ob ihr's glaubt oder nicht! Ich habe auch niemanden hier, der mir bei der Einarbeitung in diese Dinge über die Schulter schauen und helfen kann wenn ich damit Probleme kriege. Meistens haben solche Entwicklungsumgebungen ja recht verworrene Strukturen, die man erstmal gar nicht nachvollziehen kann wenn man 3 Programme braucht um einen Quellcode zu erzeugen. Wenn ich irgendjemanden hätte, der's mir so weit beibringt, daß ich damit ohne Schiffbrüche brauchbare Ergebnisse erzielen kann, wärs was anderes. Hab ich aber nicht. Drittens mag ich es irgendwie nicht, mehr Resourcen zu belegen, als ich wirklich brauche. Meiner Meinung nach sind genau solche Programme, die nach dem Prinzip "ooch ich nutze einfach alles was da ist, die Kiste idled da sowieso nur rum" arbeiten, mit daran schuld, daß man alle 2 Jahre einen neuen Rechner "braucht". Mir ist eben nicht ganz egal was hinten am Ende für ein "Executable" rauskommt, mir ists lieb wenn das nur das beinhaltet was es wirklich braucht, klein, schnell und eigenständig ist. Es ist nicht mein absolutes primäres Ziel, aber es wäre einfach schön wenn es ohne Framework und Bluray für die .EXE geht. Kriegen andere Programmierer ja auch hin. Alles andere empfinde ich irgendwie als Ballast solange man es nicht wirklich braucht. Aber das kapiert natürlich niemand, für den in der heutigen Stress-Welt Geld und Zeit alles im Leben ist. Ich bin kein BWLer, ich muß mit dem Projekt nicht nach drei Tagen Millionen erwirtschaften um meinen dummen Chef noch fetter zu machen und am Ende wenn alles läuft die Kündigung zu kriegen damit andere mein Geld verdienen. Ich mache das als Hobby und da soll es nur Spaß machen, evtl. auch Spaß machen, die Sprache zu lernen. Ich investiere da gerne etwas mehr Zeit, wenn das Programm dafür am Ende schlanker, schneller und nicht auf alles andere angewiesen ist. Ich suche da den guten Mittelweg zwischen "all-inklusive", und "nur das nötigste". Am besten eine Sprache, die beides ermöglicht. PureBasic muß ich mir mal anschauen, aber eigentlich wollte ich von Basic weg... C, bzw. eine Variante davon wäre mir lieb gewesen, weil ich es lieber anstelle von Pascal gelernt hätte. > Aber nein, der Herr ist ja entweder zu dumm, das zu begreifen, oder zu > etepetete ("mimimi, das ist Pascal, das mag ich nicht. C kenne ich zwar > nicht, aber das ist viel besser. Sagen alle meine Leet-Kumpelz."). Du pöbelst rum. Wahrscheinlich als Kind zu wenig Dreck gefressen? Schön, daß wenigstens Du das lustig findest. > wie oben erwähnt rennt php auch auf der cmd-line... Yep ich weiß, sowas hab ich schon als Cronjob gemacht, aber man kriegt damit halt keine Benutzeroberfläche hin. Das kann man machen wenn man irgendwas von festen Quellen einlesen, verarbeiten und in 'ne Datenbank reinschmeißen will, aber sonst... PHP ist auch keine Compilersprache, ohne Optimizer kann man nicht so viel von der Geschwindigkeit erwarten. Naja, wie gesagt - Danke euch trotzdem! Gute Nacht.
Naja, man muss sich halt entscheiden, ob man um Rat fragt, und dann auch mal die Vorurteile oder gestellten Ansprüche beiseite schiebt, und eine der vorgeschlagenen Lösungen in Betracht zieht, ohne von vorneherein von deren Tauglichkeit voll überzeugt zu sein -- oder ob man eh schon genau weiß, was man will (bzw. nicht will), was bei Dir der Fall zu sein scheint. In letzterer Situation hat ein solcher Thread wie dieser hier eigentlich wenig Sinn, denn jeder Vorschlag wird mit "will ich nicht, weil ich's nicht will" quittiert. Das kombiniert mit einem -- sorry -- doch relativ mäßigen Überblick über die Welt der Programmiersprachen und Frameworks macht jeden Versuch, hier weiterzuhelfen von vorneherein weitestgehend zunichte. Oder kürzer: Ziehe mal in Betracht, dass die von dir so überzeugt geforderten Kriterien vielleicht nicht die richtigen sind. Vielleicht würde dir beim Testen einer der vorgeschlagenen Lösungen auffallen, dass du einem Vorurteil unterlegen bist, welches du dann revidieren musst (vielleicht auch nicht -- weiß man ja vorher nicht). Oft stechen einem bei Sachen, die man nicht kennt, Details besonders in's Auge (sei es, weil man sie als besonders toll oder besonders schlimm bewertet), die sich später als überhaupt nicht relevant erweisen, oder bei näherer Betrachtung gar als Vorteil statt als Nachteil (hust Layouts hust). Ohne Ausprobieren kriegt man das aber nicht raus.
Womit am besten ausprobieren? Also Deine Layouts... ohne daß ich sie hinterher verwenden MUSS. Wenn Du was passendes weißt, wo man beides kann (skalierbare Layouts wie absolute Positionierung oder "Freimalerei" im Fenster) probier ich es. "Weil ichs nicht will" gilt nur für Pascal und Delphi. Bzw. für alles was auf Pascal aufbaut. Wie gesagt, hätte ich wohl gleich erwähnen müssen, das stand vorher schon fest.
Ben _ schrieb: > aus persönlichen Gründen kommt mir Pascal und > Delphi nicht ins Haus. Punkt, Aus, Ende, Feierabend. Bevor ich mit dem > Dreck anfange Ben _ schrieb: > mag ich es irgendwie nicht, mehr Resourcen zu belegen, als ich > wirklich brauche. Meiner Meinung nach sind genau solche Programme, die > nach dem Prinzip "ooch ich nutze einfach alles was da ist, die Kiste > idled da sowieso nur rum" arbeiten, mit daran schuld, daß man alle 2 > Jahre einen neuen Rechner "braucht". Mir ist eben nicht ganz egal was > hinten am Ende für ein "Executable" rauskommt, mir ists lieb wenn das > nur das beinhaltet was es wirklich braucht, klein, schnell und > eigenständig ist. Es ist nicht mein absolutes primäres Ziel, aber es > wäre einfach schön wenn es ohne Framework und Bluray für die .EXE geht. Keine Ahnung vom Ka... Delphi erzeugt mit den kompaktesten Code. Und wenn dann so ein Möchtegern, der noch nicht einmal den Unterschied zwischen C und C++ kennt, Windows Programme ins Assembler erzeugen will, na dann mal los! Delphi und C++ können auch ohne grafische Klassenbibliotheken verwendet werden. Aber welchen Sinn macht das? Gerade das Framework verkürzt die Entwicklungzeit. Erprobte und effiziente Klassen zu verwenden ist nicht uncool, sondern schlau. @Ben MS-DOS und Turbo C sind Deine Welt, viel Spaß in den 80zigern.
Du mußts ja wissen. Bestimmt bist Du auch deswegen als Gast unterwegs. Win32-Assembler hab ich übrigens bereits verwendet, allerdings bei Programmen, die ohne Benutzeroberfläche auskommen. Das hat in der Tat Spaß gemacht. Und nochmal - damit auch Du es kapierst - ich möchte kein Framework verwenden NUR weil es die Entwicklungszeit verkürzt. Komme immer mehr zu dem Eindruck, daß das hier das gleiche ist wie wenn ich frage ob die AVR oder PIC die besten Einsteiger-µCs sind. Jeder hat seinen eigenen Kram und das Eine-für-alles gibt es nicht.
@Ben Nur mal 'ne Nachfrage zu meinem Posting v. 09.01.2013 08:18Uhr: Du bist gegen Delphi und Pascal - na schön, warum auch immer. Hast Du auch was gegen "AutoIt"? - Nur mal so interessehalber... Vielleicht kann ich ja auch noch was dazulernen. Grüsse aus Berlin PSblnkd
LangeSchlange schrieb: > interpretiert ( kann man auch mit reich werden, bsp.: minecraft in > > java [jaja, vom Tellerwäscher zum PopStar]) Java wird kompiliert.
Ben _ schrieb: > Du pöbelst rum. Im meiner ersten Antwort nicht. Nachdem du dich aber als absolute Drecksau erwiesen hast, werde ich dir nicht mehr gegenübertreten, als ob du ein Mensch wärst.
Ben _ schrieb: > Bitte keine Zusammenklick-Sachen wie Delphi oder so, > sondern schon eine "für mehr" brauchbare Programmiersprache, Delphi war DAMALS sehr weit voraus! Viele Sachen die ich vor einigen Jahren in Delphi gesehen habe, kommen JETZT auch z.B. zu QT dazu. QT kann ich voll empfehlen, das ist sehr angenehm und man kann damit Plattformübergreifend(!!) gute Programme schreiben. Runterladen - installieren - fertig. Die Hilfe im Internet ist sehr gut, man findet viele Beispiele und auch ein Debugger usw. ist dabei.
>Java wird kompiliert.
python auch (zumindest in bytecode)
meckerziege schrieb: > QT kann ich voll empfehlen, das ist sehr angenehm und man kann damit > Plattformübergreifend(!!) gute Programme schreiben. Leider gibt's (noch) keine vernünftigen C# Bindings :-(
> Im meiner ersten Antwort nicht. [<<] [>] > Wenn du Programme, die einfach nur den Bildschirm leeren und sich dann > beenden, als deine Lebensaufgabe betrachtest, dann ist das eine > sinnvolle Metrik. Und du bist mit Assembler gut bedient. Das ist für Dich also eine sinnvolle und pöbelfreie Antwort? Okay, dann verrate ich Dir mal, daß es für mich eine absolut unsinnige Unterstellung ist und ich mir schon ein wenig verarscht vorkomme dabei. Wie gesagt, schön wenn wenigstens Du drüber lachen kannst, dann hat's immerhin etwas gebracht. Hilft mir aber in keiner Form weiter. Ich denke auch nicht, daß ich Dich nach Deinem letzten Posting noch vor mir sehen will, erspart mir lästige Erklärungen gegenüber dem Staatsanwalt. AutoIt muß ich überlesen haben sorry. Kenne ich nicht, werd ich gleich mal nach schauen was das ist. EDIT: AutoIt scheint mir nicht geeignet, sorry.
Also, Zusammengefasst: Du möchtest was C-Ähnliches. Also kein Pascal, Basic, Python, Whitespace, Brainf*ck... Du kommst aus der Assembler-Ecke, und möchtest zumindest die Möglichkeit haben, hardwarenah an Registern herumzufrickeln. Also nix mit einer IL-Zwischenschicht, kein C#, Managed C++, XXX.NET, Java, ... Vorschlag: Echtes C oder Echtes C++. Wenn das in Grundzügen gelernt ist: Dazu für die GUI entweder direkt an die Win32-API oder eine Klassenbibliothek (QT, GTK, wxWidgets, MFC, ...) Aber: diese Entscheidung kann man sich aufheben, und auch wieder revidieren, ohne dass das bisher mühsam angelernte C++ seinen Wert verliert. Und ja, niemand zwingt dich, intelligente Layout-Manager einzusetzen. Auch z.B. bei der QT kannst du mit absoluten Pixel-Koordinaten arbeiten. Und nein, QT-Programme werden keine riesigen EXE-Monster. Die QT-DLL selber ist zwar groß, aber die kann (zumindest in der Theorie, bzw. bei Betriebssystemen ohne "DLL-Hell") von mehreren Programmen geshared werden, und ist dann auch nur einmal im RAM.
So weit kommts noch - daß trollende Gäste hier festlegen wann Threads zu schließen sind. > Du kommst aus der Assembler-Ecke, und möchtest zumindest die > Möglichkeit haben, hardwarenah an Registern herumzufrickeln. > Also nix mit einer IL-Zwischenschicht, kein C#, Managed C++, > XXX.NET, Java, ... Nicht zwingend. Es wäre schön wenn Inline-Assembler möglich ist, aber wenn der Rest stimmt muß ich darauf halt verzichten. Über C# denke ich schon nach, das ist auf jeden Fall in der engeren Wahl. > Vorschlag: Echtes C oder Echtes C++. Welches von beiden würdest Du dann eher empfehlen? Angesichts des Hintergrundes Basic, Assembler und PHP, sowie der "Aufgabe" Windows-Anwendung erstellen?
Hallo, Ben. Schau Dir mal GfA-Basic für Windows an: http://gfabasic32.blogspot.de/p/download.html Bietet alle Vorteile eine modernen Programmiersprache, erzeugt sehr kompakten und schnellen Code. X86-Assembler kann problemlos "Inline" eingefügt werden. Und die Entwicklungsumgebung ist nicht mit sinnfreien Features überfrachtet. Gruß, Rüdiger
Ben _ schrieb: > Welches von beiden würdest Du dann eher empfehlen? Angesichts des > Hintergrundes Basic, Assembler Klar: C. > und PHP, Je nach dem. Objektorientiertes PHP? Dann C++. Ansonsten: C. > sowie der "Aufgabe" > Windows-Anwendung erstellen? ganz Klar: C++. OO bietet sich für GUIs einfach an. Klar, man kann auch mit C objektorientiert Programmieren, aber "schön" ist das nicht. Aber: C++ und C haben eine sehr große Schnittmenge. Du kannst in C++ erstmal C Programmieren, und dann je nach Bedarf C++-Konzepte einwerfen. z.B. Die "REPNZ"-Inspirierte String-Bearbeitung in C nervt dich? Verwende std::string. Nach der dritten Doppelt-Verketteten Liste in C hast du besseres zu tun? Verwende für die vierte eine std::list usw...
Ben _ schrieb: > Mir ist eben nicht ganz egal was > hinten am Ende für ein "Executable" rauskommt, mir ists lieb wenn das > nur das beinhaltet was es wirklich braucht, klein, schnell und > eigenständig ist. Das kann ich nachvollziehen. Das Problem dabei: SW-Entwicklung kostet Geld im gewerblichen Bereich. VIEL Geld. Also werden alle Werkzeuge auf möglichst hohen Durchsatz optimiert. Auch OpenSource Tools orientieren sich dann natürlich an "Industriestandards" und deren Möglichkeiten (und damit auch Komplexität). Ich bin ein großer Fan der Idee nur eine Baustelle gleichzeitig aufzumachen (auch wenn das meist nicht klappt). Darum fand das oben erwähnte PowerBasic gar nicht schlecht für Dich. Basic kannst Du, wäre also kein großes Thema. Die Möglichkeiten des Tools sehen vielversprechend aus (es erzeugt auch .exe's) Es hat bietet gute Möglichkeiten auf das OS (inkl. GUI) zuzugreifen. Du könntest Dich damit also in die aktuelle Win Umgebung einarbeiten, Applikationen erstellen und Erfahrung mit den APIs sammeln. Im zweiten Schritt könntest Du dann auf c#,c++, whatever umsteigen und müßtest Dich hier nur noch mit der neuen Sprache auseinandersetzen. Den Rest kennst Du dann ja schon. Also jeweils nur eine "Baustelle" offen. Ach ja: Und es ist keine Pascal^^ (sry, der muste sein ;-) Gruß Andreas
In solche Fallen wie die Stringbearbeitung werd ich wohl erstmal reinlaufen... :-/ Objektorientiert ist nicht meine Stärke, hab ich leider nie gelernt weils mir nie einer gezeigt hat. Vielleicht finde ich ja ein gutes Tutorial dazu. An PHP find ich halt klasse, daß es Dir fast alle Freiheiten läßt. Okay, kein Inline-Assembler, aber zur Not kann man externe Programme ausführen lassen. Kann aber dafür leider keine besonders hohe Geschwindigkeit und kein GUI - dafür ists einfach nicht gedacht.
Hi VB .NET kostenlos von Microsoft mit Visual Studio 2012. Löst alle Probleme. Habe damit gerade einen USB Programmer für meine DCC Servodecoder programmiert. Nach 2 Wochen Einarbeitungszeit. back to the BASICs! Gruß Thomas
Ah cool. Was ist dabei hinten rausgekommen, 'ne einzelne .EXE?
Thomas schrieb: > VB .NET > kostenlos von Microsoft mit Visual Studio 2012. > Löst alle Probleme. Ben _ schrieb: > Ah cool. Was ist dabei hinten rausgekommen, 'ne einzelne .EXE? ist auch nur .net kommt die gleiche exe wie bei C# raus. Auch die Klassen und methoden sind gleich. Es ist nur eine andere Sprache von .net
Ben _ schrieb: > Womit am besten ausprobieren? Also Deine Layouts... ohne daß ich sie > hinterher verwenden MUSS. Man kann ja auch mal zwei Tage was ausprobieren und das dann hinterher wieder wegwerfen. Mache ich ständig.
Ich benutze gern PureBasic. Dort bekommt man eine .exe-Datei heraus, die nichts weiter um sich braucht. Weiterhin schreibt man den ganzen Quelltext selbst, so daß nicht von der Bedienoberfläche irgendwelches unleserliches Zeug hinzugefügt wird, wenn man zum Beispiel eine Schaltfläche erzeugt. Probiere das mal aus. Lazarus ist mir auch ganz angenehm, aber Du wolltest ja nichst "pascalliges" MfG Paul
Du wirst dich wundern was deine "einzelne .EXE" (sic!) so alles an imports hat.
Angehängte Dateien:
>Du wirst dich wundern was deine "einzelne .EXE" (sic!) so alles an >imports hat. Ist gar nicht so schlimm, siehe beigefügten Dependency-Screenshot! Ich habe einst dieses simple Ping-Progrämmchen mit PureBasic geschrieben, das ganze Programm ist 32.5kByte gross, inkl. GUI und NEIN: es ist auch nicht bloss ein Wrapper für das Ping der Command-Shell. Bei einem .net Programm hingegen kommt mir das nackte Grauen auf, wenn man sieht, was da alles mitreingezogen wird...
Peter S. schrieb: > Bei einem .net Programm hingegen kommt mir das nackte Grauen auf, wenn > man sieht, was da alles mitreingezogen wird... Bei mir kommt das nackte Grauen auf wenn ich sehe, dass es immer noch Leute gibt, die meinen ständig das Rad neu erfinden zu müssen. Bloss kein wiederverwendbares Standard-Framework einsetzen weil Abhängigkeiten ja SO BÖSE sind. Lieber alles selber schreiben, damit ja keine Abhängigkeiten entstehen...
Quips schrabte: >Lieber alles selber schreiben, damit ja keine >Abhängigkeiten entstehen... Ganz grünau! Lieber alles selber schreiben und dadurch verstehen müssen , was passiert. Ich habe lediglich im übertragenen Sinn aufgezeigt, welche Suppe mir schmeckt und welche ich ohne Magenschmerzen verdauen kann. Es muß niemand mitessen -ich mache das auch allein. ;-) MfG Paul
Peter S. schrieb: > Ist gar nicht so schlimm, siehe beigefügten Dependency-Screenshot! Ich > habe einst dieses simple Ping-Progrämmchen mit PureBasic geschrieben, > das ganze Programm ist 32.5kByte gross, inkl. GUI und NEIN: es ist auch > nicht bloss ein Wrapper für das Ping der Command-Shell. > Bei einem .net Programm hingegen kommt mir das nackte Grauen auf, wenn > man sieht, was da alles mitreingezogen wird... Toll. 32K5. Mit GUI. Mit C# oder VB wäre so eine Kleinigkeit nur 20K groß. Für alles andere sorgt das nackte Grauen. mfg.
Thomas Eckmann schrieb: > Mit C# oder VB wäre so eine Kleinigkeit nur 20K groß. verschätzt, nur 6656 bytes. Kleiner geht scheinbar auch nicht.
> AutoIt scheint mir nicht geeignet, sorry.
Sehe ich genauso.
Wenn das Programm mal fertig ist, könnte man überlegen mittels AutoIt es
zu testen.
>Mit C# oder VB wäre so eine Kleinigkeit nur 20K groß >verschätzt, nur 6656 bytes. Kleiner geht scheinbar auch nicht Dann lasst mal sehen und postet ein lauffähiges Beispiel-EXE. Ohne Beweis stemple ich derartige Aussagen als leere Behauptungen ab! >Bei mir kommt das nackte Grauen auf wenn ich sehe, dass es immer noch >Leute gibt, die meinen ständig das Rad neu erfinden zu müssen Ich weiss nicht auf was Du diese Aussage beziehst, in meinem Beispiel ist kein neu erfundenes Rad mit dabei...
Etwas lieblos zusammengestückelt: die kommt auf 8kb.
Peter S. schrieb: > Dann lasst mal sehen und postet ein lauffähiges Beispiel-EXE. Ohne > Beweis stemple ich derartige Aussagen als leere Behauptungen ab! gerne doch (fehlerbehandun für ungültigen host fehlt noch) Hier auch noch der Quellcode:
1 | void Button1Click(object sender, EventArgs e) |
2 | {
|
3 | if ( textBox1.Text.Length == 0 ) {
|
4 | return; |
5 | } |
6 | textBox2.Clear(); |
7 | for( int i = 0; i < 3; ++i ) {
|
8 | if ( i > 0 ) {
|
9 | System.Threading.Thread.Sleep(1000); |
10 | } |
11 | System.Net.NetworkInformation.Ping p = new System.Net.NetworkInformation.Ping(); |
12 | System.Net.NetworkInformation.PingReply r = p.Send(textBox1.Text); |
13 | textBox2.Text += "Ping to " + textBox1.Text + " .. " + r.RoundtripTime + "ms\r\n"; |
14 | } |
Quips schrieb: > Etwas lieblos zusammengestückelt: die kommt auf 8kb. warum ist deines so gross, was hast du im code stehen?
Eigentlich noch weniger als du:
private void button1_Click(object sender, EventArgs e)
{
Ping p = new Ping();
var reply = p.Send(textBox1.Text);
MessageBox.Show("Ping: " + reply.RoundtripTime + "ms");
}
Liegts vielleicht am Dateisystem? Die exe ist nämlich EXAKT 8kb groß,
das kommt mir ein bisschen spanisch vor...
Quips schrieb: > Liegts vielleicht am Dateisystem? Die exe ist nämlich EXAKT 8kb groß, > das kommt mir ein bisschen spanisch vor... nein ganz bestimmt nicht. du hast einen langen copyright drin stehen, damit wird scheinbar eine grenz überschritten und du braucht die nächste einheit. Das sind scheinbar immer 2048byte.
Ey da ist aber gar nichts skalierbar ... ;) **sich in Deckung wirft** Was mich zu diesen Beispielen mal interessieren würde - wo ist das Layout festgelegt? Hat noch wer ein Beispiel in C/C++? ;)
>gerne doch (fehlerbehandun für ungültigen host fehlt noch)
Naja, ich würde sagen die Programm tuen etwa proportional zur Grösse
auch entsprechend weniger... Es kommt z.B. auch 0ms wenn keine Anwort!
Ben _ schrieb: > Was mich zu diesen Beispielen mal interessieren würde - wo ist das > Layout festgelegt? Hier:
1 | private void InitializeComponent() |
2 | {
|
3 | this.textBox1 = new System.Windows.Forms.TextBox(); |
4 | this.button1 = new System.Windows.Forms.Button(); |
5 | this.textBox2 = new System.Windows.Forms.TextBox(); |
6 | this.SuspendLayout(); |
7 | // |
8 | // textBox1 |
9 | // |
10 | this.textBox1.Location = new System.Drawing.Point(30, 22); |
11 | this.textBox1.Name = "textBox1"; |
12 | this.textBox1.Size = new System.Drawing.Size(100, 20); |
13 | this.textBox1.TabIndex = 0; |
14 | // |
15 | // button1 |
16 | // |
17 | this.button1.Location = new System.Drawing.Point(136, 19); |
18 | this.button1.Name = "button1"; |
19 | this.button1.Size = new System.Drawing.Size(75, 23); |
20 | this.button1.TabIndex = 1; |
21 | this.button1.Text = "button1"; |
22 | this.button1.UseVisualStyleBackColor = true; |
23 | this.button1.Click += new System.EventHandler(this.Button1Click); |
24 | // |
25 | // textBox2 |
26 | // |
27 | this.textBox2.Location = new System.Drawing.Point(30, 48); |
28 | this.textBox2.Multiline = true; |
29 | this.textBox2.Name = "textBox2"; |
30 | this.textBox2.Size = new System.Drawing.Size(181, 162); |
31 | this.textBox2.TabIndex = 2; |
32 | // |
33 | // MainForm |
34 | // |
35 | this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F); |
36 | this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font; |
37 | this.ClientSize = new System.Drawing.Size(235, 229); |
38 | this.Controls.Add(this.textBox2); |
39 | this.Controls.Add(this.button1); |
40 | this.Controls.Add(this.textBox1); |
41 | this.Name = "MainForm"; |
42 | this.Text = "ping"; |
43 | this.ResumeLayout(false); |
44 | this.PerformLayout(); |
45 | } |
46 | private System.Windows.Forms.TextBox textBox2; |
47 | private System.Windows.Forms.Button button1; |
48 | private System.Windows.Forms.TextBox textBox1; |
49 | } |
> Hat noch wer ein Beispiel in C/C++? ;)
nö, das macht man mal nicht so ebend schnell. Da gibt es ja nicht mal
befehle für ping.
Angehängte Dateien:
-
ping_kaputt.jpg
23 KB
Hab's schon kaputtgekriegt... ;) Steht das Layout mit im Quellcode drin oder irgendwo anders?
Ben _ schrieb: > Steht das Layout mit im Quellcode drin oder irgendwo anders? ja, habe ich doch schon gepostet.
>> Hat noch wer ein Beispiel in C/C++? ;) >nö, das macht man mal nicht so ebend schnell. Da gibt es ja nicht mal >befehle für ping. Befehle für "Ping" gibt es mit PureBasic leider auch nicht, aber man kann (bzw muss) direkt auf die ICMP-Objekte vom System zugreifen.
Ben _ schrieb: > Steht das Layout mit im Quellcode drin oder irgendwo anders? Na wo denn sonst. Das ist eine von mehreren Quellcodedateien. Diese wird vom Form-Designer selbst erzeugt. Das ist genau das, was manche verächtlich Klicki-Bunti nennen. Darin stehen alle Informationen, die das Framework braucht, um genau dieses Fenster zu erzeugen. Mit einem Button und zwei Textboxen. In dem Style, den du auf deinem Rechner eingstellt hast. Änderst du den Style, sieht auch das Fenster anders aus. Dahinter, in einer anderen Sourcedatei, werkelt dann der eigentliche Code. Für den ist der Programmierer aber ganz allein selbst verantwortlich. Das kannst du natürlich auch alles zu Fuß machen, wenn du es gerne möchtest. mfg.
Yep, ich meinte ob das in der gleichen Datei steht oder in einer anderen... Okay und damit sind auch "direkte zeichnerische Zugriffe" auf das Fenster möglich? Oder Zugriffe auf die Hardware wie USB-Schnittstellen? Kriegt man damit Abfragen hin, wenn der User irgendwo ins Fenster klickt, wo er "getroffen" hat? Wahrscheinlich werd ich da noch viele viele (dumme) Fragen haben und etliche Tutorials brauchen um sowas und die ganzen Klassen zu lernen. Erinnert ein wenig an JavaScript.
Ben _ schrieb: > Okay und damit sind auch "direkte zeichnerische Zugriffe" auf das > Fenster möglich? Wenn du unbedingt musst kannst du auch kleine Strichmännchen auf dein fenster zeichnen ;-) Ben _ schrieb: > Kriegt man damit Abfragen hin, wenn der User irgendwo ins Fenster > klickt, wo er "getroffen" hat? Ja, für sowas gibt es Events. Die werden vom system aufgerufen sobald etwas passiert ist (z.B. Mausklick bei X/Y).
Ben _ schrieb: > Yep, ich meinte ob das in der gleichen Datei steht oder in einer > anderen... Am Ende steht alles in einer exe. Oder wie meinst du das jetzt? Ben _ schrieb: > Okay und damit sind auch "direkte zeichnerische Zugriffe" auf das > Fenster möglich? Oder Zugriffe auf die Hardware wie USB-Schnittstellen? > Kriegt man damit Abfragen hin, wenn der User irgendwo ins Fenster > klickt, wo er "getroffen" hat? Alles. Zugriffe auf irgendwelche Hardware erfolgen nicht direkt. Ein PC ist ja kein Controller. Der Zugriff erfolgt über Treiber. Und dafür braucht man ein SDK. Für Standardsachen sind die schon drin, Drucker, COMx, Dateizugriffe z.B.. Hast du eine Kaffeemaschine mit USB, brauchst du ein SDK vom Hersteller. Ben _ schrieb: > Erinnert ein wenig an JavaScript Ist das gleiche Konzept. mfg.
Kann mir jemand sowas kurz zeigen wie's geht? Die Größe der .EXE und daß sie bei mir läuft ohne daß ich noch diverse SDKs und Frameworks installieren muß ist aber auf jeden Fall schon mal schön.
> Am Ende steht alles in einer exe. Oder wie meinst du das jetzt?
Nö, ob es in mehreren getrennten Dateien steht. Wurde schon beantwortet
und finde ich nicht sooo toll (daß es mehrere sind), aber kann ich mit
leben.
Yep mir ist schon klar, daß ich "nur" auf die Gerätetreiber zugreifen
kann. Aber USB zB. ist nicht ohne weiteres möglich? Was ist wenn ich auf
einen eigens programmierten Controller via USB zugreifen will?
Warum sollte man denn überhaupt direkt in das Fenster zeichnen wollen? Für sowas gibt es Canvas-Widgets. Dasselbe für Mausklicks: Warum? Was interessiert dich, wo der Benutzer auf den Button geklickt hat? Oder, warum interessiert dich überhaupt, dass der Benutzer auf den Button geklickt hat? Er könnte ja auch eine Taste dafür benutzen. Klar gibt es Fälle, in denen man wissen will, wo genau geklickt wurde, aber ein Fenster mit Buttons ist keiner dieser Fälle. Für sowas benutzt man dann eine Zeichenfläche. Alles andere ist Mist, weil es zu UIs führt, die sich nicht so verhalten, wie man es erwartet. Ein Beispiel dafür ist LabView, die haben auch alles viel "besser" gemacht, deshalb kann man Fenster nicht skalieren, Buttons nicht mit Tasten bedienen, und Kontextmenus funktionieren auch nicht wie sie sollen. Qt macht das natürlich :) richtig: in einem GraphicsView kann man genau sehen, was der Benutzer macht: http://doc.qt.digia.com/qt/qgraphicsview.html#mouseMoveEvent Für einen Button hingegen geht das standardmäßig nicht. http://doc.qt.digia.com/qt/qpushbutton.html
von Ben _ schrieb: > Und nochmal - damit auch Du es kapierst - ich möchte kein Framework > verwenden nach Ben _ schrieb: > Wahrscheinlich werd ich da noch viele viele (dumme) Fragen haben und > etliche Tutorials brauchen um sowas und die ganzen Klassen zu lernen. > Erinnert ein wenig an JavaScript. Ei, ei, schau her. Der Bennie kapiert so langsam worum es geht. Wahrscheinlich endet er doch noch bei Delphi oder Lazarus. >:->>>
Ben _ schrieb: > Kann mir jemand sowas kurz zeigen wie's geht? hast du es dann schon mal geschaft das charpdevlop zu installierne, oder sollen wir dabei auch helfen?
Was ich gerade über den Button und Mouse Events gesagt habe war wahrscheinlich Unsinn, geht denke ich auch da ohne Probleme. Nvm.
Ben _ schrieb: > Kann mir jemand sowas kurz zeigen wie's geht? Lade dir erstmal VisualC# oder VisualBasic als Expressedition runter. Dann legst du ein Projekt an, eine Windowsanwendung. Dann siehst in der IDE ein Fenster, Form1, das ist deine Anwendung. Aus der Toolbox ziehst du dann mit der Maus alles rein, was du brauchst. Und dann kümmerst du dich um das wesentliche. Nämlich den Code, der dafür sorgt, daß beim Klicken auf Button1, deiner Freundin eine SMS geschickt wird, in der steht, daß sie heute alleine ins Kino gehen muß, weil du gerade was besseres zu tun hast. Zuschauer schrieb: > Wahrscheinlich endet er doch noch bei Delphi oder Lazarus. >:->>> Hoffentlich nicht. mfg.
Ben _ schrieb: > AutoIt scheint mir nicht geeignet, sorry. ... und bitte mit welcher Begründung? Da trügt der "Schein"... Schon mal was mit "AutoIt" programmiert? Ihr werdet Euch wundern, wie einfach das geht! Aber wer sich unbedingt mit den Höhen und Tiefen von OO rumquälen will, na bitteschön, dem sei's gegönnt. PowerBasic ist auch ganz nett, vorallem sind die Tools "Libary Manager" und "COM Browser" sehr hilfreich - auch AutoIt. Grüsse aus Berlin PSblnkd
> Wahrscheinlich endet er doch noch bei Delphi oder Lazarus. >:->>>
Eher friert die Hölle zu!
Hab mich da evtl. auch falsch ausgedrückt - ich möchte keine Frameworks
benutzen, die ich hinterher mit mir rumschleppen muß. Der Nachteil der
(deutlich?) schlechteren Geschwindigkeit gegenüber C bei komplexen
Berechnungen bleibt aber, oder?
@Peter II
Werd ich gleich mal machen.
Ben _ schrieb: > Der Nachteil der > (deutlich?) schlechteren Geschwindigkeit gegenüber C bei komplexen > Berechnungen bleibt aber, oder? der war NIE da.
Thomas Eckmann schrieb: > Dann siehst in der > IDE ein Fenster, Form1, das ist deine Anwendung. Aus der Toolbox ziehst > du dann mit der Maus alles rein, was du brauchst. Aber das will er doch nicht. Er möchte alles zu Fuß und selbst machen: Ben _ schrieb: > Bitte keine Zusammenklick-Sachen wie Delphi oder so, > sondern schon eine "für mehr" brauchbare Programmiersprache, die auch > Win32 bzw. Win64 Anwendungen kann. Letztendlich geht es doch entweder um moderne OOP mit entsprechenden Klassenbibliotheken und einem effektiven Framework für aktuelle PCs mit aktuellen BS oder um hardwarenahe strukturierte Programmierung, wie *resourcenschonend für µCs sinnvoll* ist.
Delphi ist doch kein Framework... Ich finde deine ganzen Ansprüche relativ wirr, muss ich sagen. Vielleicht solltest du mal ein paar konkrete Problemstellungen nennen, die du angehen willst. Nicht für jedes Problem ist jede Sprache geeignet. Ich nutze viel C++/Qt und Python (evtl. auch mit Qt), damit kann man viele Dinge gut abdecken. Wenn's schnell sein muss oder ich den Eindruck habe, dass statisches Typing in diesem Fall besonders hilfreich wäre, nehme ich C++/Qt, ansonsten (wenn ich nur ein paar Fenster bauen oder Daten umformatieren will) Python. Manchmal schreibe ich z.B. für numerische Simulationen auch schnell einen Prototypen in Python, und wenn der zu langsam ist, mach' ich's in C++ noch einmal. Ich kann nur nochmal wiederholen, dass ich den Eindruck habe, dass deine Beurteilung der Vorschläge großteils auf Vorurteilen basiert, von denen du weite Teile revidieren würdest, würdest du eine Woche mit der betreffenden Lösung arbeiten. Vielleicht liege ich auch falsch, aber ich würde dir zumindest raten, diese Möglichkeit in Betracht zu ziehen.
Ich weiß gar nicht was diese immer gleichen Diskussionen alle 2 Monate hier immer sollen. In der Überschrift steht doch eindeutig: "Windows-Oberfläche" Und da gibt es halt nur eine einzige Empfehlung die man einem Neueinsteiger ohne Altlasten und Spezialanforderungen geben kann, nämlich .NET. Egal von VB oder C#. Alles andere was hier so an Vorschlägen kommt ist doch nur was wenn man irgendwelche Kompromisse eingehen muss, etwa wegen plattformunabhängigkeit. Und dann gibt es noch ein paar Altlasten von Leuten die nie etwas anderes gelernt haben und sich auch nicht mehr weiter entwickeln wollen. Mag ja sein, dass diese Exoten für diese Leute gut funktionieren, aber sowas kann man doch nicht ernsthaft einem Neueinsteiger als Tipp geben. Also: Visual Studio .NET Damit geht alles vom kleinen Helferlein bis zur mächtigen Enterprise Anwendung. Und trotzdem ist die Einstiegshürde sehr gering, man kommt schnell zu Erfolgen. Express Edition ist kostenlos. Ich bevorzuge C#, aber wenn du VB bereits kannst ist das auch I.O.
Ich ziehe Qt .NET jederzeit vor, auch wenn ich keine Plattformunabhängigkeit brauche. ;)
Für meinen Geschmack Full ACK! Wenn man GUI macht gibts Qt und .Net (Java ist dafür dank Netbeans-Klicksi-GUI-Helper auch Ok). Wenn man wirklich speed braucht, kommt man um OpenMP und konsorten eh nicht herum... da hilft auch kein ASM-programmieren... Und da man auf die Hardware eh nicht mehr zugreifen kann, stelle ich alle nicht High-Level-Sprachen (also auch C un C++ ohne Qt/GTK/.net/...) am PC (command-line ausgenommen) ernsthaft in frage. 73
Ich weis nicht ob diese Programmiersprachen schon empfohlen wurden. http://de.wikipedia.org/wiki/Brainfück <-- ü durch u ersetzen! http://de.wikipedia.org/wiki/Malbolge http://99-bottles-of-beer.net/language-malbolge-995.html
Malbolge kann ich auch empfehlen. Aber im Ernst, Brainf*ck ist sehr lehrreich! ;)
Ben _ schrieb: > Das ist für Dich also eine sinnvolle und pöbelfreie Antwort? Ja, ist es. Dein Denkfehler wird klar erkennbar thematisiert, und du wurdest in deiner Person in keinster Weise verunglimpft. Das hast du dann getan. Daß du dir deiner kriminellen Neigungen bewußt bist, zeigt ja schön deine obige Drohung, nach einem Treffen würde dich wohl der Staatsanwalt befragen müssen.
Oh Maaannn.... Wer ein wenig C++ und C gemacht hat und einen guten Einstieg in C# hat, wird bei C# bleiben. Die Sprache hat sehr viele Vorteile gegenüber klassischem C++ Kram. Wer jetzt wieder rumschreit wegen Plattformabhängigkeit: hat man bei Cpp auch nicht ;-P (zumindest in der GUI). Im Gegenteil: durch Mono kann man sehr gut mittlerweile portieren (abgesehen von den allerneuesten Features, die müssen immer erst noch nachimplementiert werden). Wer nach Qt schreit: schaut euch mal den Leidensweg von Qt an... Mit den Lizenzen usw. ist das auch nicht immer einfach und wer weiß, wie es mit Nokia weitergeht (momentaner Inhaber von Qt). Außerdem werden die Hauptfehlerquellen von Cpp in C# von vorn herein nahezu ausgeschlossen: Casting, Pointer usw. Ich will nicht damit sagen, dass Pointer schlecht sind - sie erlauben sehr effizientes Programmieren. Für den Heimanwender ist das aber eigentlich egal und es ist nun mal eine sehr sehr große Fehlerquelle - auch für Fortgeschrittene. Eventuelle Alternative: Java. Wer jetzt schreit: da kommt doch keine EXE raus - auch nur die halbe Wahrheit. 1. ist die Verbreitung von Java sehr gut. 2. gibt es (zumindest für Windoofs) das Java Runtime als portable Version. Sicherlich gibt es auch irgendwelche Wrapper, mit dem Teile der Java Runtime direkt in eine EXE gepackt werden. Wegen Win API: das kann sich auch mal irgendwann ändern. Gerade in Zeiten von Kacheln, mobilen Anwendungen usw. verliert eine antiquirte Win API an Wert.
Brater schrieb: > Mit den Lizenzen usw. ist das auch nicht immer einfach Was ist daran kompliziert? Qt steht unter der LGPL. > Nokia [...] (momentaner Inhaber von Qt). Nö: http://www.heise.de/developer/meldung/Digia-uebernimmt-Nokias-restliche-Qt-Aktivitaeten-1663660.html
Sven B. schrieb: > Brater schrieb: >> Mit den Lizenzen usw. ist das auch nicht immer einfach > Was ist daran kompliziert? Qt steht unter der LGPL. > >> Nokia [...] (momentaner Inhaber von Qt). > Nö: > http://www.heise.de/developer/meldung/Digia-uebern... Nagut, da hab ich einen alten Wissensstand und lass mich eines Besseren belehren. Dann ist Qt natürlich tendenziell wieder interessant. Wobei C# trotzdem auch sehr viel Spaß macht. Selbst ohne UI ist C# eine tolle Sprache nach der Eingewöhnung (man kann halt nicht mehr wirklich casten... macht aber nix, weil alles irgendwie ohne Casting realisierbar ist).
Sicher -- ich wollte nur die Gerüchteküche, die aus irgendwelchen Gründen immer um KDE und Qt köchelt, ein wenig dämpfen ;)
Welche Plattform für Windows hat denn die beste Dokumentation, die auch für Einsteiger am besten geeignet ist? Die Doku von Wxcpp (Wxwidget)und codeblock scheint da nicht geeignet entweder weil man sich visuell nicht die Bildschirm- funktionen vorstellen kann oder das man ordentlich dokumentierte Methoden findet, so das man auch nachvollziehen kann welche Funktionen was auch immer auf dem Bildschirm bewirken. Da verliert man als Anfänger ganz schnell die Lust. Erfahrungen mit VB waren da nachvollziehbarer.
Für Qt und den Qt-Designer gibts gute Schritt-für-Schritt videos... die Samples sind Ok... 73
Hans schrieb: > Für Qt und den Qt-Designer gibts gute Schritt-für-Schritt videos Youtube Kids! Wichtig ist eine saubere vollständige Klassenbeschreibung, kein bunten Videos.
Ähm Klassenbeschreibung ist Voraussetzung! Die Videos sind für Einsteiger hilfreich... IDE, Gui-Designer,... wird alles erklärt. Das hat nix mit "Youtube Kids" zu tun! 73
Hans schrieb: > Die Videos sind für Einsteiger hilfreich... nein, ganz bestimmt nicht. In einem Dokument kann man mal schnell zurück gehen und nachschauen. ein Video ist (für mich) die schlechteste Möglichkeit solches Wissen zu vermitteln. (der einzigste Vorteil ist das niemand etwas per copy und paste sich rausnehmen kann) > IDE, Gui-Designer,... wird alles erklärt. Das hat nix mit "Youtube Kids" > zu tun! doch hat es, denn auch ohne Videos sind gute Programmierer entstanden.
Ich bin dafür das es sich an diesem Punkt endlich ausgetrollt haben sollte. Gießt nicht noch mehr Öl ins Feuer! Alles weitere findet man bestens über unsere Lieblingssuchmaschine heraus.
Ich arbeite noch mit dem Borland C++ Builder und bin ich sehr zufrieden...
Peter II schrieb: > doch hat es, denn auch ohne Videos sind gute Programmierer entstanden. Klar, wenn man eine Schule (auch Fortbildung) besucht, aber zeig mir mal eine die GUI auf Wxwidget oder Codeblock lehrt? Eine die einen QT-Kurs hat, hatte ich schon mal gefunden, aber dann sollte man da nicht wie ein Grünschnabel dran teilnehmen, sondern schon ein paar Grundkenntnisse mit Compiler und Debugger haben. Da werd ich mich wohl mal mit QT beschäftigen müssen. Die käuflich teuren Tools kann man eh vergessen, kein Geld für so was.
Michael S. schrieb: > Klar, wenn man eine Schule (auch Fortbildung) besucht, > aber zeig mir mal eine die GUI auf Wxwidget oder Codeblock lehrt? früher hat man das auch mit Bilder (Screenshots lösen können)
Peter II schrieb: > Hans schrieb: >> Die Videos sind für Einsteiger hilfreich... > > nein, ganz bestimmt nicht. In einem Dokument kann man mal schnell zurück > gehen und nachschauen. ein Video ist (für mich) die schlechteste > Möglichkeit solches Wissen zu vermitteln. > (der einzigste Vorteil ist das niemand etwas per copy und paste sich > rausnehmen kann) > >> IDE, Gui-Designer,... wird alles erklärt. Das hat nix mit "Youtube Kids" >> zu tun! > doch hat es, denn auch ohne Videos sind gute Programmierer entstanden. Es ging um die IDE und die Dev-Tools - nicht Code-Monkey-Tätigkeiten! Gui wird zusammengeklickst, Wie man mit den Tools richtig arbeitet vermittelt ein Video am besten. Lesen und in Bildchen dann nachschaun wo das Icon jetzt ist und wie das ausschaut ist weniger effizient wie ein Video! Und ganz nebenbei gibts verdammt gute Videos zu Algorithmendesign, Design-Patterns, ... Ich nicht unterschätzen was man bei einem guten Vortrag so alle mitnehmen kann... aber egal.. OT! 73
Peter II schrieb: > Michael S. schrieb: >> Klar, wenn man eine Schule (auch Fortbildung) besucht, >> aber zeig mir mal eine die GUI auf Wxwidget oder Codeblock lehrt? > > früher hat man das auch mit Bilder (Screenshots lösen können) das Stichwort ist früher! Vllt. sind die jetzigen Lösungen effizienter??? schon mal daran gedacht? Aus dem selben Grund wird oben auch Win32ASM in Frage gestellt! 73
Hans schrieb: > Vllt. sind die jetzigen Lösungen effizienter??? schon mal daran gedacht? bestimmt nicht schon das video ist viel größer als jedes Bild - wie soll es da effizienter sein? Ich kann zumindest aus viedeo nichts lernen - scheinbar hat mein gehirn nicht die aktuelle Firmeware.
Hans schrieb: > Ich nicht unterschätzen was man bei einem guten Vortrag so alle > mitnehmen kann... aber egal.. OT! Schulfernsehen und Telekolleg lassen grüßen. ;)
Solange sich da in den letzten Jahren nichts krasses geändert hat, ist der "Sprachkern" hinter Delphi fähig mit der gesamten Windows-API zu arbeiten. Von Wegen Spielzeug... Daher stellt sich lediglich die Geschmacksfrage Pascal vs C++. Aber zu Zeiten von Macs und ARM-PCs sollte man es sich in der Tat dreimal überlegen ob man eine GUI-Anwendung nicht in der Tat auf CLR oder Java aufbauen möchte.
rackandboneman schrieb: > der "Sprachkern" hinter Delphi fähig mit der gesamten Windows-API zu > arbeiten Da gibt es eine eigene Unit (vgl. mit Header + obj-Datei bei C++) für. rackandboneman schrieb: > Daher stellt sich lediglich die > Geschmacksfrage Pascal vs C++. Woll wahr, und einfach über 180 Postings zusammen gefasst!
Hi, der Thread ist zwar schon etwa 1,5 Monate alt. Aber mit Sicherheit sucht der Themenstarter ja noch immer :) Ich muss zugeben, dass es sehr interessant ist, hier mitzulesen...bei der hälfte war es mir jedoch zu viel und habe das lesen abgebrochen. Ben _ (burning_silicon) du hast eigentlich schon die perfekten Antworten bekommen :) Was du genau willst, geht und gibt es einfach nicht...da musst du damit leben. Und auch wenn es vielleicht eine Möglichkeit gibt, mit Assembler auf die Win32API zuzugreifen...allein der Gedanke, es ist unbeschreiblich, es fehlen einfach die Worte wie man so etwas nur in Erwägung ziehen könnte :) Du willst LEICHT und WINDOWS? Dann nimm .NET! (C#, VB, usw) Du willst SCHWER und kompilierten Maschinencode? Dann nimm C/C++ mit GUI Toolkit (Qt, GTK, usw)! Alles andere ist auch sinnvoll, aber liegt nicht in deinem Interesse...Python, Java, usw. Alles hat seine Daseinsberechtigung. Aber für deinen Fall kommen nur die oberen zwei Punkte in Betracht. Assembler und Win32API: Vergiss es, schlag es dir aus dem Kopf. Mein Tip für DICH ist: C++ und FLTK! FLTK ist ein sehr leichtes GUI Toolkit, welches anstandslos auf mehreren Betriebsystemen läuft und du nicht mal im Code was ändern musst. FLTK ist wohl das schnellste was es an GUIs gibt. FLTK lässt sich rechtlich verwenden wie man will, so dass du es statisch linken kannst. SPRICH: Du kannst wirklich nur EINE EINZIGE EXE erstellen und da ist ALLES drin was du für deine GUI Anwendung brauchst...keine DLL, NICHTS! Und selbst eine kleine GUI Anwendung INKLUSIVER aller eingebundenen Bibliotheken in EINER EXE hat nur um die 100kB!!! Und das ganze darfst du sogar verkaufen! Und C++ empfehle ich wegen deinen Vorstellungen von Code und Geschwindigkeit...und eben weil du unbedingt eine "C-Variante" willst. Ich verstehe nicht, was du mit Variante meinst. C ist C und C++ ist C++! C# ähnelt nur etwas von der Syntax, ist aber was ganz anderes. Auch Java ähnelt der C-Syntax und ist fast gleich mit C#...aber auch wieder was anderes. Damit meine ich, dass du alles extra lernen müsstest. Wenn du C++ lernst, kannst du C++. Lernst du C, kannst du C. C und C++ sind nur eine Ausnahme, da sie verwandt sind. Du kannst mit einem C++ Compiler auch reinen C Code kompilieren. Du kannst auch beide Sprachen mischen. Jedoch bist du ein schlechter Programmierer, wenn du bei C++ Programmen häufig auf C-Bibliotheken zurückgreifst bzw beides mischst. C und C++ ist das was du willst...mit ausnahme von leicht. Das ist die absolute Königsdisziplin unter aktuellen Sprachen. Assembler hat auf einem "Personal Computer" NICHTS verloren! Außer extreme Ausnahmen, mit denen sich eher Betriebssystementwickler beschäftigen sollten. C alleine ist so hardware nah, und du kannst den Code auf so geringer ebene schreiben, dass du mit Assembler wahrscheinlich kaum mehr rausholen wirst. Wenn du nach diesem Beitrag hier immer noch nicht weißt, was du nun lernen sollst bzw immer noch auf "Windows-GUI-Programmierung mit Assembler" bestehst, dann musst du dir ein anderes Hobby wie Fotografieren, Malen, Basteln oder so suchen. Liebe Grüße und viel Erfolg ;)
Ich +1 mal für C# C# ist an sich eine schöne Sprache (schöner als C, C++ und Java). Die GUI-Programmierung ist nicht schwer (du hast nen Baukasten und kannst selbst daran werkeln und dynamisch Sachen einbinden). Zudem hast du die Möglichkeit DLL's aus C und C++ zu importieren. Also steht dir über Umwege auch Inline-asm zur Verfügung. Du bist am Zahn der Zeit (Windows 8, Windows Phone). Auf Linux gibt es Mono (.Net Implementierung, manche Stellen unvollständig - bisher aber keine entdeckt). Für Android soll es da auch was geben. Gleiches wird wohl auch für Ubuntu Phone gelten. (Für Ubuntu Phone und Ubuntu wäre wiederum C++, Python und Qt gut). Weiter hast du die Möglichkeit mit Visual Basic zu arbeiten (und eigentlich jeder anderen Sprache für das .Net Framework). Zusammen mit dem schlüsselwort "unsafe" kannst du auch direkt im Ram pfuschen und kannst etwas an Performance rausholen.
Bin zu dem Ergebnis gekommen, daß C++ und C# genau gleich gut und gleich schlecht sind. :D Allerdings sind die meisten Spiele wohl in C++ geschrieben, weswegen ich im Moment stark in diese Richtung tendiere. Assembler und Win32-Api hab ich schon gemacht. Aber das war nur ein Kommandozeilenprogramm mit einer Rechenanwendung, sollte also maximale Geschwindigkeit bringen.
Ben _ schrieb: > Bin zu dem Ergebnis gekommen, daß C++ und C# genau gleich gut und gleich > schlecht sind. :D Oha, das ist mal ne gewagt Behauptung ^^ C# ist meiner Meinung nach als Sprache deutlich angenehmer als C++. Dinge wie LINQ, das async-Keyword, Reflection, Garbage Collection, verbose strings usw. machen einem das Entwicklerleben sehr viel leichter...
Eigentlich ist C# ja der Versuch, Java mit C++ zu vereinigen. Die "Rechenoperationen" sind dabei etwa folgende:
1 | Java |
2 | + C++ |
3 | - ein paar C++-Dinge, die sich schwer mit Java vereinigen lassen |
4 | + ein paar andere Dinge, um einen gewissen Fortschritt anzudeuten |
5 | –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– |
6 | C# |
Da C++ für sich gesehen schon ziemlich dick ist und auch Java nicht gerade an Magersucht leidet und zudem er Mut zum Weglassen bei den C#-Entwicklern nur schwach ausgeprägt war, ist das Ergebnis einfach nur megafett. Von einer gewissen Eleganz, die man von einer neuen Program- miersprache gewöhnlich erwartet, ist bei C# nicht viel zu erkennen. Das neu hinzugekommene LINQ ist zugegebenermaßen eine coole Sache, aber eben nur eine Spitze in dem ansonsten vorherrschenden Mittelmaß und wirkt deswegen auch etwas aufgesetzt. So ein Zusammenpappen mehrerer existierender Programmiersprachen zu einer neuen gab es schon einmal in den 1960er Jahren, als IBM mit PL/1 versuchte, Algol, Fortran und Cobol miteinander zu vereinigen. Trotzdem (oder gerade deswegen) haben zumindest Fortran und Cobol PL/1 überlebt. So werden vermutlich auch Java, C++ und C noch lange die drei unagefoch- tenen Mainstream-Sprachen bleiben und garantiert nie von C# abgelöst werden. Um die potentiellen User nicht zu sehr zu verschrecken, veröffentlicht MS den riesigen C#-Kloß nur häppchenweise in etwa zweijährlichem Tur- nus¹. Das führt leider dazu, dass C#-Quellcode nach jeweils zwei Jahren einen altbackenen Eindruck macht, weil er die aktuellen Sprachelemente nicht nutzt. So etwas ist für die Softwareentwickler nicht unbedingt motivierend. Auch C++ wird weiterentwickelt, aber da sind die Zyklen sehr viel länger und die Deltas nicht so groß. Der einzige wirklich tiefgreifende Schritt war seinerzeit die Einführung der Templates. Wenn Ben also schreibt, Ben _ schrieb: > Bin zu dem Ergebnis gekommen, daß C++ und C# genau gleich gut und gleich > schlecht sind. :D muss das nicht falsch sein. Er schreibt ja nicht, dass beide Sprachen gleich sind, sondern nur gleich gut oder gleich schlecht. Da stimme ich ihm mit meiner subjektiven Meinung zu. Ich bin zwar gegenüber neuen Programmiersprachen sehr aufgeschlossen und habe in letzter Zeit auch öfters mit C# herum gespielt, aber einen Drang, die Sprache wirklich zu lernen und ernsthaft zu nutzen, habe ich bisher nicht verspürt. –––––––––––– ¹) Sicher hat auch gewaltiger Termindruck durch die Java-Konkurenz zu dieser Vorgehensweise beigetragen.
Ben _ schrieb: > Bildschirm leeren unter DOS Assembler: <30 Byte .COM-Datei > Bildschirm leeren unter DOS PowerBasic: ~20kB .EXE-Datei > Leeres Fenster unter Delphi: paar-100-kB .EXE-Datei *oO* Nur unwissende Vollidioten brauchen dazu ein paar 100KByte. Auch mit Delphi kann man natürlich ein leeres Fenster mit einem nur ein paar kByte großen Executable erzeugen. Man braucht nur einfach nicht die Forms-Unit einbinden und statt dessen das Fenster zu Fuß erzeugen. Genau wie man das unter Plain C oder C++ ohne MFC oder sonstige Toolkits auch machen würde. Was den Delphi-Code "fett" macht, wenn man das Fenster per Forms-Unit erzeugt, ist der viele Code, der bei einem leeren Fenster einfach nichts macht. Genauso wie bei C++ die MFC oder meinetwegen auch Qt. Bloß: der Sinn einer Programmiersprache ist ja nicht, leere Fenster zu erzeugen, sondern welche, auf denen was nützliches passiert... Außerdem: Ein paar 100kByte sind doch nach heutigen Maßstäben, wo schon ein verschissener Drucker- oder Grakatreiber Dutzende Megabyte braucht, rein garnix mehr. Da erspart man es sich doch gerne, Sachen wie RegisterClass, CreateWindowEx und die Messageloop von Hand zu machen, selbst wenn man es kann. Was auf dich ja übrigens offensichtlich nicht zutrifft. Und dies ganz unabhängig von der Sprache, die du verwendest, denn keine Sprache der Welt kann die Kompetenz des Programmierers ersetzen. Sie kann immer nur Ausdrucksmittel sein.
@Yalu: 1. C# will Cpp nicht ablösen. Aber es verfolgt andere Ziele. Ich merke das in der täglichen Arbeit: vor einem Jahr angefangen und ich schreibe immer noch nebenbei eigene Funktionen, weil Cpp einfach viel zu WENIG mitbringt. Typisches Beispiel: Arbeiten mit Zeichenketten (ich schreibe bewusste NICHT String). In C ist das Arbeiten mit Char-Arrays einfach nur fürchterlich, weil man nur überschreibend arbeiten kann und nicht einfügend (außer man macht sich eine zeichenweise Liste :D ). In Cpp könnte man im Prinzip mit Strings arbeiten - oft wird aus Kompatiblitätsgründen trotzdem einer Funktion nur ein char* übergeben. Für etwas mehr Komfort sollen dann die StringStreams sorgen - sie gehen allerdings auch nur gerade so. Das Netz ist voll von etlichen selbstgebastelten StringSplit-Funktionen. Das ist absolut fürchterlich. Von GUIs mit Cpp reden wir jetzt mal gar nicht. Wenn es so gut/einfach in der API implementiert wäre, hätten wir nicht diesen endlos langen Thread. 2. Warum muss man denn immer alles von Punkt 0 aus herausschnitzen? Das ist vergleichbar mit Arbeitsteilung in der Gesellschaft. Wenn wir die nicht hätten (auch mit Nachteilen, siehe my-lidl-Pony-Lasagne), müsste heute jeder von uns noch selbst sein Feld bestellen und ernten. C# ist einfach deshalb so aufgeblasen, weil in C und Cpp so viel fehlt. Schönes Beispiel: C# bzw. eigentlich alle .Net Sprachen können seit einer bestimmten Version (3.5 oder so) sogar nativ auf DirectX in "normalen" Windoofs-Fenstern zugreifen. Und, ist das schlimm? Warum soll ich 100 konkurierende Einzelbibliotheken verwenden, wenn ein Framework alles beherrscht? Ich will damit nicht sagen, dass das Framework perfekt oder fehlerfrei ist. Ich bin kein Freund von KleinWeich aber man muss leider Gottes auch ab und zu auch mal Positives anerkennen. Zum Thema große Dateien: die Applikationen mit .net sind auch erstaunlich klein.
Kann C/C++ kein Substring oder was äquivalentes?
C++ kann garnix. In C++ gibt es auch keine Stings. Eine String-Klasse wie QString kann das natürlich alles, oft sogar viel mehr als noch höhere Sprachen (python zum Beispiel). http://qt-project.org/doc/qt-4.8/qstring.html#mid
Gibt es schon... Gibt aber überall Nachteile/Fallstricke. Dein Vorschlag ist noch einer der brauchbarsten. Kleines Beispiel: http://www.cplusplus.com/faq/sequences/strings/split/
Ich habe diesen Beitrag mit Interesse verfolgt, da auch ich nach einer alternative zu Rapid-Q suche ... RapidQ wird leider seit Jahren nicht mehr weiter entwickelt, was wirklich schade ist. Nur wenn ich das hier lese, frage ich mich ob es für mich Sinn macht eine neu Sprache mit all den Besonderheiten zu lernen oder z.B. auf PureBasic zu wechseln.
Sven B. schrieb: > C++ kann garnix. In C++ gibt es auch keine Stings. Hm, was ist dann bitte std::string?
Mark Brandis schrieb: > Hm, was ist dann bitte std::string? Eine Klasse der STL. Aber kein Bestandteil der Programmiersprache C++.
Ben _ schrieb: > @Yalu > Heißt das, Du bist C++ Freak? Nein, wie kommst du darauf? Kilian schrieb: > Mark Brandis schrieb: >> Hm, was ist dann bitte std::string? > > Eine Klasse der STL. Aber kein Bestandteil der Programmiersprache C++. Doch, die STL ist Bestandteil der Programmiersprache C++. Der Standard beschreibt die Strings im Kapitel "Strings Library".
Yalu X. schrieb: > Doch, die STL ist Bestandteil der Programmiersprache C++. Der Standard > beschreibt die Strings im Kapitel "Strings Library". Jein ;-) Versuch mal einen string zu verwenden, ohne "#include <string>". Da wird der Compiler meckern. Ergo ist der string nicht Teil der Sprache, sondern gehört zur Basisbibliothek, die wiederum Teil des C++ Standards ist. Bei C# ist das (so glauibe ich) anders: hier kannst du den string wie einen int oder sonst was verwenden. Ist natürlich alles nur Haarspalterei ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.