hallo Ich programmiere seit jahren embedded C für 8051 oder Atmega usw. Nun suche ich eine einfache "C" Programmier umgebung mit der ich kleine test programme auf windows rechner grafisch darstellen kann. senden von strings über serielle ,empfangen bmp hinterlegen usw. In welches "C" Programmiersystem kann man sich am schnellsten einarbeiten? Gruß Juppo
ich verstehe die Frage nicht! du programmierst schon in C bzw C-Ansi bestimmt C99 oder so. Ok Embedded-C ist halt Microcontroller orientiert aber zu 90% ist es C. welche Anwung willst unter einem PC mit C programmieren? in Zeiten wo GUIs gibt und programme wie Visual C++, C#, VB etc.. warum muss du unbedingt in C programmieren? wer programmiert heutzutage ein Button, oder ein Fenster? C und Assembler können ruhig die Sprache der Micorcontroller bleiben, dann muss du über Seriell ein Port ansprechen und deine Anwendung unter Windows testen. Das Testprogramm kannst du aber mit anderen Sprache und IDE programmieren. Ich hoffe, ich habe richtig verstanden was du gefragst hast
> In welches "C" Programmiersystem kann man sich am schnellsten > einarbeiten? .NET & C# Wenn du die objektorientierten "Erweiterungen" ignorierst und "nur" C proggst, könnte es nahezu klappen. Allerdings möchte ich die OO eigentlich nicht mehr bei PC-Programmen missen. Ob C# das richtige ist, möchte ich hier nicht weiter vertiefen. Jedenfalls bist du was GUI & Schnittstelle betrifft extrem flott wenn du .NET verwendest. Ralf
Oh da habe ich mal wieder unverständlich gegeben. (sagt meine Frau auch immer) Also c syntax kenne ich.(µp Programmierung) Des wegen möcht ich be c bleiben. Objekt objektorientierten soll natürlich sein. Ich weiß nur nicht welches system ich nehmen soll ohne das nach ein Woche einarbeitung alles mumpiets ist . gruß juppo
Juppo Nini schrieb: > Ich weiß nur nicht welches system ich nehmen soll ohne das nach ein > Woche einarbeitung alles mumpiets ist . wenn du dich eh in eine GUI einarbeiten muss, dann ist kannst du dich auch gleich mit einer anderen sprache beschäftigen. Auch von mir die Empfehlung: C# - lade dir kostenlos http://www.icsharpcode.net/opensource/sd/ runter und teste mal einen tag. Viele dinge geht in .net viel einfacher als mit C/C++ und die Zeit die man damit spart kann man auch in eine neue Sprache investieren.
Wie immer: Nimm etwas mit Zukunft. Es gibt so viele tolle UI-Bibliotheken, die portabel und ANSI-C oder C++-konform sind, da brauchst du dir C# oder .NET nicht anzutun, wenn du ohnehin schon C sprichst. Schnell fertig bist du z.B. mit GTK, das dürfte dir recht weit entgegenkommen: Da du ja Datenblatt-lesen gewohnt bist, beginnst du mit einem kurzen Tutorial und hüpfst dann direkt in die Bibliotheksreferenz.
GTK habe ich sogar auf meinen Rechner OK da habe ich schon nmal einen Anfang. Den Besten .. Gruß Juppo
Juppo Nini schrieb: > Des wegen möcht ich be c bleiben. > > Objekt objektorientierten soll natürlich sein. Das widerspricht sich aber, du musst dich schon entscheiden. C++ ist schneller als c# (so langsam ist c# aber auch nicht). In c++ ist aber noch das Problem, dass man ziemlich einfach einen schwerwiegenden Fehler begeht. In c# findest man fast alle Fehler sofort. Dazu hast du mit .Net eine riesig umfangreiche Bibliothek mit allen möglichen Sachen drin. 99.99% wirst du wahrscheinlich nie benutzen. Ich empfehle dir auch mal c# zu testen. Die Syntax entspricht fast der von c++ und diese minimalen Änderungen sagt dir der Compiler. Was ich an c# auch sehr gut finde ist, dass man keine Header-Dateien braucht. Die Funktionen fischt sich der Compiler selbst heraus. PS: Ich persönlich finde MS VS C# besser als Sharpdevelop, ist aber (denke ich) geschmackssache. Hier nochmal beide Links: Sharpdevelop: http://www.icsharpcode.net/opensource/sd/ MS VS C# EE: http://www.microsoft.com/express/Downloads/#2010-Visual-CS Sven P. schrieb: > Wie immer: Nimm etwas mit Zukunft. Es gibt so viele tolle > UI-Bibliotheken, die portabel und ANSI-C oder C++-konform sind, da > brauchst du dir C# oder .NET nicht anzutun, wenn du ohnehin schon C > sprichst. Auf die Gefahr hin, dass wieder ein .NET Streit ausbricht: Welche tolle Bibliothek bietet denn diesen Umfang?
Hallo, interessiere mich grade auch für das Thema. Zu meinem Stand: Grundlagen ANSI-C Grundlagen Basic (u.a. für Excel VBA) Mein Dilemma: Ich würde eigentlich meine C Kentnisse vertiefen wollen, als z.B. auch kleine Programme für den PC schreiben. Andererseits sind Makros in Excel eine feine Sache, was man ja mit .NET und VB ebenfalls weiter ausbauen kann. Nun was macht mehr Sinn: a) C, C++(.NET) und Excel VBA b) C, VB(.NET) und Excel VBA Die Frage ist ja auch, was sich mehr gleicht, C und C++ oder VB und VBA. Wobei ich eher vermute das Basic sicher ähnelt. Vielen Dank für Feedback. Und um mein Lieblingshaßwort für 2010/2011 zu nutzen: "ich muss ja beim erlernen der Sprachen auch an die NACHHALTIGKEIT denken" :)
Wenn du Nachhaltigkeit willst UND auf dem PC unter Windows bleiben willst UND du hauptsächlich GUI-lastige Dinge machen willst, DANN würde ich (obwohl eingefleischter C++ Fan) zu entweder C# oder VB raten. In der Zeit, in der du dir in VB oder C# deine Oberfläche zusammengeklickt hast, hast du in C++ noch nichts erledigt. Muss man leider so sagen. Von dem Zeugs, das MS als 'managed C++' bezeichnet würde ich aus tiefstem Herzen abraten. Das macht keinen wirklichen Sinn und soll nur den C++ Leuten den Umstieg auf C# versüssen.
Samuel K. schrieb: > Das widerspricht sich aber, du musst dich schon entscheiden. Nein, mit GObject wurde C Objektorientierung aufgepfropft. GTK macht davon Gebrauch.
b00n schrieb: > C, C++(.NET) und Excel VBA > C, VB(.NET) und Excel VBA also C++(.NET) ist nichts halbes und nicht ganzes, VB(.NET) ist ok wenn man vorher Basic gemacht hat. Aber das "echte" .net ist nun mal c#.
also würde ich auf Variante a gehen: c, vba und vb.net. Danke! Jetzt noch wahrscheinlich eine Saublöde Idee... Sollte man dann C gleich ganz fallen lassen und die Mikrocontroller mit Basic programmieren?
b00n schrieb: > Sollte man dann C gleich ganz fallen lassen und die Mikrocontroller mit > Basic programmieren? NEIN, ich denke das hier (fast) alle der Meinung sind das ein schritt von C auf Basrom für einen µC der falsche weg ist. Teste einfach mal C#, danach kann man sich erst eine Meinung bilden. VB.net finde ich nicht sehr gut, es entspricht nicht der üblichen Programmierung. Ich finde die umstellung von VB auf C oder C# immer als schwer. C# und C(++) sind sich dagegen vomn Synteax her sehr ähnlich.
C# mit dem Net Geraffel? Das führt nur auf düstere Wege... Warum nicht einfach wenn doch schon vorhanden, C Proggen mit GTK Anbindung? Einfach zu lernen, wenn man schon C kann, Programme sind Ressourcen schonend und schnell (im Gegensatz zu dem NET Geraffel). Dazu kann man wenn benötigt, es sehr schnell noch auf andere Systeme Portionieren...
b00n schrieb: > also würde ich auf Variante a gehen: > > c, vba und vb.net. > > Danke! > > Jetzt noch wahrscheinlich eine Saublöde Idee... > Sollte man dann C gleich ganz fallen lassen und die Mikrocontroller mit > Basic programmieren? Wer möchte kann die größeren auch in C# programmieren: http://www.microsoft.com/netmf/default.mspx http://www.netduino.com/projects/ VB eventuell http://www.christec.co.nz/blog/archives/category/net-micro-framework/ p.s. bevor das Thema wieder kommt: das .NET Micro Framework gibt's vollständig im Quellcode unter der Apache 2.0 Lizenz.
uCs in Basic Programmieren oder gar VB? gerade bei den uCs würde ich das NIE tun, weil es gerade hier auf Performance ankommt, und das geht halt wegen der Hardware nähe fast ausschließlich mit C oder Assembler...
Fer T. schrieb: > Warum nicht einfach wenn doch schon vorhanden, C Proggen mit GTK > Anbindung? weil C zwar schön und gut ist, aber selber leider sogut wie nichts mitliefert. Nicht mal eine zeitgemäße String-Verarbeitung. Bei Sprachen wie C# oder auch Java ist der große Vorteil das man sogut wie keine externen Sachen braucht. Mache doch mal mit C ein Gui die von einer SSL Webseite eine Image lädt und den MD5 Hash prüft und das Bild invertiert speichert. Man braucht ja nur Openssl, GTK und irgendeine http lib und libjpeg. (klar kann man auch alles selber machen). In C# ist alles schon dabei. Es ist zwar etwas langsamer und brauch vermutlich etwas mehr resourcen aber dafür ist die Entwicklungszeit wesentlich kleiner und auch weniger fehleranfällig. Die Eigentliche exe ist vermutlich sogar kleiner als bei C (klar braucht man die .net Laufzeitumgebung) Und die C# version ist mit etwas übung in einer Stunde fertig. Für die C version hätte ich in der zeit nicht mal alle externen libs übersetzt.
Fer T. (fer_t) schrieb: > C# mit dem Net Geraffel? > Das führt nur auf düstere Wege... Unfug! Das ist wie Karl-Heinz Buchegger schon schrieb der beste Weg schlecht hin für Leute die "unter Windows bleiben" möchten. Das Framework ist sehr umfangreich, der Einsteig ist nicht schwer und es gibt viel gute Literatur sowie Programmbeispiele. Windows Programme lassen sich auch mit purem C (ganz ohne Objekt-orientierten Code) unter der Nutzung der Win32-API schreiben. Das ist nicht mal schwer, wenn man mal den hier http://www.charlespetzold.com/pw5/index.html durchgearbeitet hat. Für den ein- oder anderen zu altbacken (Petzold ist inzwischen auch zu C# "übergelaufen" siehe http://www.charlespetzold.com/books.html), funktioniert aber noch immer und die Programme sind schön schnell (was bei kleinen Programmen und heutiger Rechenleistung aber kaum mehr eine Rolle spielt). Für Leute die mit dem Erstellen von Klassen mittels Frameworks wie MFC auf Kriegsfuß stehen (warum auch immer) ist das aber eine Möglichkeit sich davor zu drücken und dennoch Windows Programme, ob Konsole oder vollständiges Fenster oder einfach alles in einen Dialog gepackt, ;) zu schreiben. Einfach ausprobieren. Eine kleine aber feine GUI neben den Platzhirschen Visual .. gibt es auch z.B. hier http://www.smorgasbordet.com/pellesc/ Merke: Das beste Programm ist immer das mit dem man selbst am besten zurecht kommt.
Johann schrieb: > Ich empfehle Qt. Ist zwar C++, aber das sollte kein Problem sein. Sehe ich auch so und im gegensatz zu denn C# ist QT auch für Linux Mac und ggf. soagr auf einen embedded System verfügbar hat also zumindestens Theoretisch das Potenzial auf anderen Systemen als ein Windows Pc laufen (zugegeben nach einer neu Kompilierung)
Jetzt mal meine Meinung als jemand, der da auch grad im Lernprozess drinsteckt: Die Originalfrage war ja nach einer Programmierumgebung. Für mich war es recht einfach, mich in CDT/Eclipse einzuarbeiten. Damit lassen sich C und C++ Anwendungen recht einfach erstellen. Zudem gibt's das für Windows und Linux, da kommst also in keine Sackgasse. Außerdem gibt's eh auch Eclipse-Versionen für viele Embedded-Systeme, so daß Du auch in der Richtung einen Nutzen daraus ziehen kannst wenn Du Dich einarbeitest. Wenn Dir Textzeile reicht, dann hast Du jetzt schon gewonnen. Wenn Du aber wirklich Fensterchen und Mausklicken programmieren willst würde ich dann wie Imon auch zu Qt mit Qt Creator raten. Das liefert dann Fensters, Netzwerk, Dateizugriff und vieles mehr, weit mehr als GTK jedenfalls. Und es läuft auch auf Win, Linux und Mac. Und um das zu lernen gibt's von Blanchette/Summerfield ein recht gutes Buch. (Ohne Buch oder Lehrgang recht mühselig, da sich das Konzept nicht automatisch von selbst erschließt.)
Samuel K. schrieb: > C++ ist schneller als c# (so langsam ist c# aber auch nicht). Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert sich das?
P. M. schrieb: >> C++ ist schneller als c# (so langsam ist c# aber auch nicht). > Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und > was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert > sich das? soetas kommt sehr oft von Leuten die noch die etwas mit .net gemacht haben. Ich war selber oft überrascht wie schnell .net ist. Ich konnte bis jetzt noch keine unterschied feststellen. Ich warte auch mal gespannt auf eine Antwort.
Peter schrieb: > soetas kommt sehr oft von Leuten die noch die etwas mit .net gemacht > haben. Ich war selber oft überrascht wie schnell .net ist. Ich konnte > bis jetzt noch keine unterschied feststellen. > Ich warte auch mal gespannt auf eine Antwort. Dem kann bei dir so sein, es kommt da aber auf das verwendete System (OS, also XP, Vist, 7) an und auf deine Hardware... Klar das man mit einem I7 oder Phenom II X8 nicht den Unterschied merkt, im Gegensatz (sehr radikal) zu einem Pentium IV oder Athlon. Zu GTK und QT: Ich selber bin auch auf der QT Seite, aber hier wurde nur erwähnt das C Kenntnisse Vorhanden sind, da wollte ich nicht noch den Umstieg auf C++ Voraussetzten. Was aber auch ganz einfach ist, wenn man das System durchschaut hat. Zu NET: + Sprachen dir Net Verwenden sind "einfach" mit viel Leistung (Aufwand/Leistung Verhältnis) - Net ist nicht überall performat - Net ist auf MS beschränkt - Net ist nicht gerade User freundlich (Wenn der User nur ein NEt Programm Nutzen Will, muss er das Programm (z.B. 10Mb) Installieren und NET (ca. 300Mb oder hat sich da seit meinem letzten Gebrauch von Win was geändert?). Bei einem normalen C++ oder C Programm wären es dann z.b. nur insgesamt 50Mb)... Ist halt Meinungssache... MfG,
Fer T. schrieb: > Programm Nutzen Will, muss er das Programm (z.B. 10Mb) Installieren und > NET (ca. 300Mb oder hat sich da seit meinem letzten Gebrauch von Win was > geändert?). Bei einem normalen C++ oder C Programm wären es dann z.b. > nur insgesamt 50Mb)... Wieso unterschlagt Ihr C/C++-Anhänger eigentlich immer, dass jeder Compiler seine eigene Version einer Runtime-Library mitbringt? Was dann auch bedeutet, dass jede Applikation ebenfalls mehrere MB an DLLs auf die Platte kopiert, die sich im IDEALFALL nicht gegenseitig in die Quere kommen. Mit dem .NET-Laufzeitumgebung hat MS da endlich einigermaßen in den Griff bekommen. Habe bei der Arbeit gerade wieder das Vergnügen, mich mit dem Scheiß rumzuplagen und nicht wirklich zu wissen, welche der tollen externen Bibliotheken da genau welche Runtime-Version benötigt... Gruß Markus
Markus Volz schrieb: > jeder Compiler Sorry, ich muß mich korrigieren: "jede Compiler-VERSION" ist richtiger. Gruß Markus
Markus Volz schrieb: > Wieso unterschlagt Ihr C/C++-Anhänger eigentlich immer, dass jeder > Compiler seine eigene Version einer Runtime-Library mitbringt? Was dann > auch bedeutet, dass jede Applikation ebenfalls mehrere MB an DLLs auf > die Platte kopiert ... Das trifft auf .NET auch zu, es "wiegt" immerhin etwa 360MB. Nur ist es auf Windows-Rechnern meist schon drauf. Wird also bei "normalen" Heim- und Büro-PCs nicht so wahrgenommen. Interessant wird es immer ab dem Moment, wo man den Bereich des Standard-Windows-PC verlassen will. Also entweder Mini- und Micro-PCs oder auch Linux/Mac. Da ist dann die Energie, die man ins .NET-lernen gesteckt hat weitgehend wertlos. Man muß halt wissen, in welche Richtung man sich bewegen will.
Markus Volz schrieb: > Wieso unterschlagt Ihr C/C++-Anhänger eigentlich immer, dass jeder > Compiler seine eigene Version einer Runtime-Library mitbringt? Das unterschlagen "wir" gar nicht. > Was dann > auch bedeutet, dass jede Applikation ebenfalls mehrere MB an DLLs auf > die Platte kopiert, Niemand zwingt den Nutzer eines C/C++-Compilers, dieses Programmiermodell zu nutzen. Durch die Möglichkeit des /statischen Linkens/ entstehen monolithische .exe-Dateien, die (vom Betriebssystem selbst abgesehen) keinerlei weitere Laufzeitunterstützung benötigen. Solche Dateien muss man nicht "installieren", man muss keinen DLL-Müll irgendwohin kopieren, man hat keinerlei Versionskonflikte. Klar, solche Programme sind etwas größer als welche, die sich auf das Vorhandensein einer Laufzeitumgebung verlassen, aber nicht ansatzweise so groß wie so eine typische Laufzeitumgebung. Denn im Gegensatz zur vollständigen Laufzeitumgebung wird zu so einem statisch gelinkten Programm nur das hinzugefügt, was es auch tatsächlich nutzt. Was bei einem typischen schon etwas größeren MFC-Projekt* in einer Exe-File-Größe im unteren einstelligen MB-Bereich resultiert, während ein C-Programm schon ziemlich aufwendig sein muss, um mehr als nur ein paar hundert kB zu benötigen. Und so ein Programm läuft überall, ohne Installation, ohne Updates, ohne Versionsblubber. *) Ja, ich weiß, gräuslich. Aber MFC-Programm linken verdammt viel Zeug.
Rufus Τ. Firefly schrieb: > Und so ein Programm läuft überall, ohne Installation, ohne Updates, ohne > Versionsblubber. aber du muss schon mal 2 versionen veröffentlichen. 64Bit und 32bit - das Problem geht es bei .net schon mal nicht.
Mag sein, aber die 32/64-Bit Problematik ist auch bei den "Profis" häufig anzutreffen. Übrigens würde ich nicht ausschließen, daß eine 32-Bit Version auf einem 64-Bit System läuft. Ansererseits gilt: Obwohl in der Open Source am manchen Stellen verpönt, ist das statische Linken unter Windows eine Tugend, und ich als Anwender bin jedesmal dankbar für ein Programm, das alles, was es braucht, mitbringt und nicht irgendeinen Blödsinn in "windows/system32" schreiben muß. Ansichtssache, aber trotzdem: Statisches Linken (zumindest unter Windows) erhöht die Zuverlässigkeit und vermeidet Versionskonflikte. Es verbessert auch die Performance - zugegeben marginal. Um auf die ursprüngliche Frage zurückzukommen, eine kompakte und anfängerfreundliche Entwicklungsumgebung ist "Dev-C++". Man kann damit natürlich auch simples C programmieren, es liegt der MinGW-Compiler zugrunde. Die Oberfläche ist simpel und effizient, die erzeugten Programme klein und man ist nicht gezwungen, irgendwelche .dll-Dateien mitzuliefern. Natürlich haben Frameworks ihren Reiz. Aber für mich ist .NET sowohl als Anwender (großer Installationsumfang, keineswegs überall vorhanden, gerade auf Rechnern ohne Internetanbindung) als auch als Programmierer (Cross-Platform muß eigentlich heute selbstverständlich sein, wenn man etwas in die Zukunft denkt) ein Reizthema. Alles Ansichtssache, natürlich. Will hier keinen Streit vom Zaun brechen.
Samuel K. schrieb: > Juppo Nini schrieb: >> Des wegen möcht ich be c bleiben. >> >> Objekt objektorientierten soll natürlich sein. > > Das widerspricht sich aber, du musst dich schon entscheiden. Nein, tut es nicht. Es ist nur für diejenigen ein Widerspruch, die OOP falsch verstanden haben. Der ganze Klassen-Vererbungs-Template-Interface-Wasserballon ist nur ein Teil von OOP. Ein eher zweitrangiger noch dazu. > Sven P. schrieb: >> Wie immer: Nimm etwas mit Zukunft. Es gibt so viele tolle >> UI-Bibliotheken, die portabel und ANSI-C oder C++-konform sind, da >> brauchst du dir C# oder .NET nicht anzutun, wenn du ohnehin schon C >> sprichst. > > Auf die Gefahr hin, dass wieder ein .NET Streit ausbricht: Welche tolle > Bibliothek bietet denn diesen Umfang? Für was denn? Es gibt unzählige gute Bibliotheken für jeden noch so erdenklichen Zweck. Und allesamt können sie eine Sache, und die dafür dann richtig. Ich kann sogar als Entwickler entscheiden, was ich brauche, und muss nicht zwangsweise das Kollektiv kaufen.
P. M. schrieb: > Samuel K. schrieb: >> C++ ist schneller als c# (so langsam ist c# aber auch nicht). > > Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und > was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert > sich das? Rein logisch betrachtet: 1.) C++ --> Compiler, Linker --> Ausführbares Binary in der Maschinensprache des Prozessors. 2.) C# und Java --> Compiler, Linker --> Bytecode --> Bytecode wird von der .NET Laufzeitumgebung bzw. von der Java Virtual Machine zur Laufzeit in die Maschinensprache des Prozessors übersetzt. Da 2.) einen Verarbeitungsschritt mehr benötigt, ist es durchaus logisch anzunehmen, dass dies mehr Rechenzeit braucht. Freilich muss der Unterschied nicht groß sein. Trotzdem wird man, wenn es absolut auf das letzte bisschen an Performance ankommt, wohl eher diejenige Sprache verwenden die den geringeren Overhead hat. (also C ;-) Dann gibt es auch noch Native Compiler, zumindest für Java :-)
Sebastian schrieb: > Ansererseits gilt: Obwohl in der Open Source am manchen Stellen verpönt, > ist das statische Linken unter Windows eine Tugend, und ich als Anwender > bin jedesmal dankbar für ein Programm, das alles, was es braucht, > mitbringt und nicht irgendeinen Blödsinn in "windows/system32" schreiben > muß. Muss es ja nicht. Der dynamische Linker lässt sich ja mühelos jeden Bibliotheks-Klon unterschieben ;-) > Ansichtssache, aber trotzdem: Statisches Linken (zumindest unter > Windows) erhöht die Zuverlässigkeit Nein, es erzeugt unnötige Redundanz. Wenn eine Bibliothek einen Fehler enthält, enthalten ihn 100 Programme. Wenn der Fehler behoben wird, sind 100 Updates fällig... Dann doch lieber einmal zentral gepflegt, oder? > und vermeidet Versionskonflikte. Die gibt es ohnehin Hauptsächlich beim Windows-Linker. Unices/Linux haben das irgendwie anders in den Griff bekommen. > Es > verbessert auch die Performance - zugegeben marginal. Ja und nein. Performance != Geschwindigkeit. Die Performance sackt rapide in den Keller, wenn der Arbeitsspeicher unnötig mit redundantem Code zugemüllt wird. Mark Brandis: Auch ja und nein. Der Zwischenschritt braucht gewiss Zeit, ja. Aber dafür kann der resultierende Programmtext effizienter sein, als das 'fest verdrahtete' Äquivalent in C(++). Denk z.B. mal an Programmpfade in einem Algorithmus, die per JIT vollständig entfernt werden können, konventionell aber einen bedingten Sprung benötigen.
Mark Brandis schrieb: > einen Verarbeitungsschritt mehr benötigt, ist es durchaus logisch > anzunehmen, dass dies mehr Rechenzeit braucht. Freilich muss der > Unterschied nicht groß sein. Trotzdem wird man, wenn es absolut auf das > letzte bisschen an Performance ankommt, wohl eher diejenige Sprache > verwenden die den geringeren Overhead hat. dabei übersieht du aber ein paar feinheiten. In C kann es sehr schnell passieren das z.b. ein Objekt kopiert wird (String). In .net wird aber mit Referenzen gearbeitet. Damit entällt ein Kopiervorgang und das Programm wird schneller. Dann kann ein Laufzeitsystem optimierungen abhängig von den Daten vornehmen was ein C Programm leider nicht kann. Auch die Freigabe von Speicher erfolgt in C sofort - was auch etwas zeit kostet. In .NET erfolgt das ganze irgendwann. Damit kann die Rumtime den speicher dann Freigeben wenn das Programm z.b. auf ein IO wartet. Das das speicherverwaltung Zeit kostet sieht das es smartheap gibt. Wenn die Rumtime eine bessere speicherverwaltung hat das das C programm dann ist es schon schneller. Man kann also auf keinen Fall sagen ein .net programm pauschal langsamer als ein C programm ist. Es werden sich für beide Fälle Beispiele finden lassen.
Ich glaube, wir sollten diese Perfomanc-Feinheiten lieber wieder beiseite lassen. 1. ging es in der Frage ja um eine Programmierumgebung bzw. auch IDE. So verstehe ich zumindest die Frage nach dem Programmiersystem. Und das vereint Sprache, eventuelle Toolkits und die IDE+Compiler. 2. können wir uns sicher darauf einigen, daß am Anfang die Performance das geringste Problem ist. Erlernbarkeit und Les-/Wartbarkeit des Codes sind weit wichtiger. Und im Laufe der Erfahrung kommt dann auch die Übersicht, mit der man sich dann die für die jeweilige Aufgabe passenden Mittel aussuchen kann. Jeder erfahrene Programmierer sagt ja auch, der Zweck bestimmt die Mittel. Die Aufgabe ist hier ja: Erlernen von PC-Programmierung. Vorhanden ist: C-Kenntnisse. Meiner Meinung nach ist die wichtigste Frage jetzt noch: Windows only oder einer für alle?
Sven P. schrieb: >> Ansichtssache, aber trotzdem: Statisches Linken (zumindest unter >> Windows) erhöht die Zuverlässigkeit > Nein, es erzeugt unnötige Redundanz. Wenn eine Bibliothek einen Fehler > enthält, enthalten ihn 100 Programme. Wenn der Fehler behoben wird, sind > 100 Updates fällig... Dann doch lieber einmal zentral gepflegt, oder? Bei einem statisch gelinkten Programm ist der Fehler, wenn er aus einer der verwendeten Bibliotheken kommt, aber auch statisch. Das bedeutet, daß der Nutzer des statisch gelinkten Programmes sich darauf verlassen kann, daß ein Fehler eindeutig im Programm zu suchen ist, statt an der wie auch immer gepflegten Liste von Bibliotheken auf dem Zielsystem. Der Entwickler muss sich bei einem Fehlerreport auch nicht damit beschäftigen, herauszufinden, wo in welcher Bibliothek, die auf dem Zielsystem in welcher Version auch immer vorhanden sein mag, das Problem liegen könnte, er muss sich nicht damit beschäftigen, in irgendwelchen Konfigurationen vorliegende Nebeneffekte auszuschließen. Andererseits muss er Fehlerreports ernstnehmen und kann sich nicht mit einem schnodderigen "Der Kunde muss halt sein System auf aktuellem Stand halten, dafür ist er verantwortlich" herausreden. Das "zentral gepflegte" Updateverfahren ist in der Theorie sicherlich ganz toll, aber in der Praxis kann es sehr unschöne Auswirkungen haben. Man nehme an, das eigentliche Programm nutzt eine Bibliotheksfunktion auf eine, sagen wir mal, vom Bibliotheksentwickler nicht vorgesehene Art und Weise. Bei Bibliotheksversion XY funktioniert das so, wie es sich der Entwickler des Programmes gedacht und gewünscht hat. Nun kommt ein "zentral gepflegtes" Bibliotheksupdate, die Bibliotheksfunktion verhält sich etwas anders, und der ... sagen wir mal "Fehler" des die Bibliothek nutzenden Programmes kommt plötzlich zum Tragen, und die Funktionalität des Programmes ist dahin. Wenn das Programm in diesem Falle statisch gelinkt wäre, würde es funktionieren. Nun mag man diese Art von Vorgehensweise seitens des Entwicklers verdammen, aber wenn eine Bibliothek zum Zeitpunkt der Entwicklung eines Programmes eine bestimmte Funktionalität nur auf eine bestimmte, nicht ganz "offizielle" Art zu erreichende Art und Weise zur Verfügung stellt, dann gibt es --außer bei OSS-Bibliotheken-- wenig Möglichkeiten, anders vorzugehen.
Rufus Τ. Firefly schrieb: > [...] Ist ja alles formal richtig, was du sagst. Aber es führt weder zu zuverlässiger Software, noch ist es der Qualität des ganzen Systemes irgendwie dienlich, oder? Dagegen steigern Fehlerberichte an die Entwickler der Bibliothek mitunter die Qualität. Aber selbst wenn ein Programm gegen eine spezielle Bibliothek linkt und sich auf das Verhalten verlässt: Bei ordentlicher Versionierung kracht es wenigstens nicht, dann bleibt halt eine alte Version neben der aktuellen Version -- das wäre beim statischen Binden ja ohnehin der Fall. Es macht die Sache, nämlich die Bibliothek zu missbrauchen, aber wiederum nicht besser. Man verhindert dadurch ja nicht nur, dass es zu Fehlern kommt, weil man sich auf ein spezielles Verhalten verlässt. Man verhindert ja auch, dass 'echte' Fehler behoben werden -- irgendwann geht das schief.
Sven P. schrieb: > Aber es führt weder zu zuverlässiger Software, noch ist es der Qualität > des ganzen Systemes irgendwie dienlich, oder? Dagegen steigern > Fehlerberichte an die Entwickler der Bibliothek mitunter die Qualität. Bei der Entwicklung unter OSS-Bedingungen gebe ich Dir da ganzheitlich recht. Aber bei der Entwicklung unter Systemen wie Windows ist der Weg des "Fehlerberichts an die Entwickler der Bibliothek" oft ähnlich ergiebig, wie den Fehlerreport an eine Klotür zu malen. Hier trennt sich Pragmatismus (den man unter Systemen wie Windows haben muss) und Einhaltung der hehren Lehre (was man sich unter OSS-Bedingungen leisten kann).
@Rufus und Sven: Was also würdet ihr im konkreten Fall einem Anfänger (auch ich würde mich als fortgeschrittenen Anfägner bezeichnen) denn jetzt empfehlen?
hubert schrieb: > @Rufus und Sven: > > Was also würdet ihr im konkreten Fall einem Anfänger (auch ich würde > mich als fortgeschrittenen Anfägner bezeichnen) denn jetzt empfehlen? Dir würde ich garnichts mehr empfehlen, denn Du beschreitest in meinen Augen bereits einen optimalen Weg. GTK solltest du dann allerdings zusammen mit der glib (nicht glibC, nur glib) betrachtet, beide zusammen sind in etwa vergleichbar mit Qt. Dem blutigen Anfänger empfehle ich ANSI-C und jemanden, der es schon beherrscht, als Anleitung. Das hilft, sich eine klare Meinung darüber zu bilden, wohin die Reise gehen soll. Und dazu empfehle ich etwas UNIX-Mentalität, um sich z.B. über Sinn und Unsinn von eierlegenden Wollmilchsäuen, graphischen Benutzeroberflächen und portablen Standards und Schnittstellen klar zu werden. 'The Art Of UNIX Programming' ist da ein ganz tolles Buch. <Disclaimer> Wie immer ohne Gewähr. C ist böse, die Konsole ist sowieso für Nerds. Windows ist toll, .NET der Heilige Gral. Graphische Oberflächen sind das beste, was die Computerwelt in den letzten 20 Jahren erlebt hat, vorher war alles schlecht und ineffizient. Meine Ansichten sind scheiße und von vorgestern, ich habe keinerlei Erfahrung mit Programmieren. Und damit fahre ich bislang recht gut. </Disclaimer>
Peter schrieb: > P. M. schrieb: >>> C++ ist schneller als c# (so langsam ist c# aber auch nicht). >> Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und >> was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert >> sich das? > > soetas kommt sehr oft von Leuten die noch die etwas mit .net gemacht > haben. Ich war selber oft überrascht wie schnell .net ist. Ich konnte > bis jetzt noch keine unterschied feststellen. > Ich warte auch mal gespannt auf eine Antwort. Hey ich programmiere 90% mit .NET und muss einfach manchmal feststellen, dass vieles die STL in c++ besser macht. Die Listen in c# sind nicht gerade die schnellsten. Ebenso wie Exceptions. Da gibts auch eine Quelle, allerdings hab ich vergessen auf welcher Seite die ist. Die Aussage c++ ist schneller heißt nicht, dass es gleich 50% sein müssen. Ich persönlich finde, dass c# schnell genug ist und das, was langsam ist, man umgehen kann. Das c# den Byte-Code erst noch übersetzen muss verlangsamt sicher noch ein bisschen, aber: Der Code wird nur einmal übersetzt! D.h. nach dem übersetzen ist das Programm nicht langsamer als c++. Sven P. schrieb: > Dir würde ich garnichts mehr empfehlen, denn Du beschreitest in meinen > Augen bereits einen optimalen Weg. GTK solltest du dann allerdings > zusammen mit der glib (nicht glibC, nur glib) betrachtet, beide zusammen > sind in etwa vergleichbar mit Qt. Es gibt keinen optimalen Weg! Jedem fällt etwas anderes leichter oder schwerer. Auch wenn jeder sagt es wäre leicht - ich habe mal in Basic reingeschnuppert und es war ein Qual für meine C(++), C# Syntax gewöhnten Augen.
Sven P. schrieb: > <Disclaimer> > Wie immer ohne Gewähr. C ist böse, die Konsole ist sowieso für Nerds. > Windows ist toll, .NET der Heilige Gral. Graphische Oberflächen sind das > beste, was die Computerwelt in den letzten 20 Jahren erlebt hat, vorher > war alles schlecht und ineffizient. > Meine Ansichten sind scheiße und von vorgestern, ich habe keinerlei > Erfahrung mit Programmieren. Und damit fahre ich bislang recht gut. > </Disclaimer> ROFL der war gut Aber eine gute IDE mit Debugger ist mir wirklich lieber als vi und ein Kommandozeilendebugger :-)
Es sagt ja niemand, dass eine IDE schlecht ist. Aber die IDE von VC++ etwa finde ich zum Abgewöhnen. Und den einen optimalen Weg gibt es nicht, das hat auch niemand behauptet. Trotzdem beschreitet hubert in meinen Augen einen optimalen Weg. Aber nur in meinen Augen und nur einen optimalen Weg, das hat was mit Meinung zu tun. Andre sehen das anders und es gibt sicher noch andere optimale oder ideale Wege.
Samuel K. schrieb: > Hey ich programmiere 90% mit .NET und muss einfach manchmal feststellen, > dass vieles die STL in c++ besser macht. Die Listen in c# sind nicht > gerade die schnellsten. bei welchen größenordnungen viel dir das auf? Ich hatte eine Anwendung mit etwa 10.000 einträgen und musste das sortieren und das ging in 0,nichts. (es war sogar nur ein langsamer Atom Prozessor). > Ebenso wie Exceptions. naja Exceptions beurteile ich nicht nach geschwindigkeit.
Sven P. schrieb: > Aber die IDE von VC++ etwa finde ich zum Abgewöhnen. Hängt von der Version ab. Und von dem, was man gewohnt ist. Wer mit vi/Emacs/gdb aufgewachsen ist, der will sich so etwas nicht antun, wer sonst mit Eclipse hantiert, der wird sicherlich schon eher etwas damit anfangen können ---
Rufus Τ. Firefly schrieb: > Sven P. schrieb: >> Aber die IDE von VC++ etwa finde ich zum Abgewöhnen. > > Hängt von der Version ab. Und von dem, was man gewohnt ist. > Wer mit vi/Emacs/gdb aufgewachsen ist, der will sich so etwas nicht > antun, wer sonst mit Eclipse hantiert, der wird sicherlich schon eher > etwas damit anfangen können --- Naja, ich bin ja selbst mit Visual Basic 5+ und VC++ aufgewachsen. Aber das, was MS sich da in der aktuellen Version leistet, ist an Unaufgeräumtheit und Aufdringlichkeit kaum zu überbieten. Der Quelltext rückt komplett in den Hintergrund vor lauter Explorern, Statuszeilen und Symbolleisten...
Sven P. schrieb: > ist an Unaufgeräumtheit und Aufdringlichkeit kaum zu überbieten Ja. Eindeutig. Abhilfe schafft hier ein ausreichend großer Monitor, besser noch sind zwei Monitore. Auf dem Hautpmonitor lässt man sich die Fenster mit Sourcecode anzeigen, "Solution Explorer", "Class View", "Resource View" sowie "Properties" und "Toolbox" und was es noch alles an Debugfenstern gibt/geben kann, das packt man auf den zweiten Monitor. Ist zwischen 2008 und 2010 gefühlt noch schlimmer geworden. Ich werde mir auf meinen Arbeitsplatz einen Drittmonitor stellen, weil ich den Zweitmonitor schon für andere Dinge benötige, und da einfach nicht genug Platz ist für das ganze andere Geraffel. Dann aber geht es, und im Gegensatz zu anderen IDEs darf man auch nach wie vor mehrere Quelltextdateien gleichzeitig ansehen. Das ist ja wirklich das allerletzte, wenn man bei egal welcher Bildschirmgröße immer nur genau ein Fenster mit Sourcecode angezeigt bekommt. IAR Embedded Workbench ist so ein Kandidat, so ein Screenshot sieht zwar im Reklamematerial schick aus, ist aber in der Realität ein Produktivitätshemmer par Excellence.
Peter schrieb: > bei welchen größenordnungen viel dir das auf? Ich hatte eine Anwendung > mit etwa 10.000 einträgen und musste das sortieren und das ging in > 0,nichts. (es war sogar nur ein langsamer Atom Prozessor). Das waren 100k. Zeig mir mal dein Sortieralgo meiner dauert immer noch geschätzt eine 10tel Sekunde und ich finde das ist zu langsam! Einzigste MEthode war noch parallel vorzusortieren. Ich hab einen Core2Duo @3Ghz also auch nur 2-6x so schnell (gibt ha viele). Sven P. schrieb: > <Disclaimer> > Wie immer ohne Gewähr. C ist böse, die Konsole ist sowieso für Nerds. > Windows ist toll, .NET der Heilige Gral. Graphische Oberflächen sind das > beste, was die Computerwelt in den letzten 20 Jahren erlebt hat, vorher > war alles schlecht und ineffizient. > Meine Ansichten sind scheiße und von vorgestern, ich habe keinerlei > Erfahrung mit Programmieren. Und damit fahre ich bislang recht gut. > </Disclaimer> Haha, ich habe nichts gegen C gesagt. Ich programmiere nämlich auch damit. Aber auf dem PC lieber mit C#. Vorteile von C(++) gegenüber c# - 0.01% mehr Speed - Plattformunabhängigkeit - 20MB weniger Resourcenverbrauch? ich hab zwar noch über 3GB frei aber wenigsten ein Grund zum meckern
Sven P. schrieb: > Rufus Τ. Firefly schrieb: >> Sven P. schrieb: >>> Aber die IDE von VC++ etwa finde ich zum Abgewöhnen. >> >> Hängt von der Version ab. Und von dem, was man gewohnt ist. >> Wer mit vi/Emacs/gdb aufgewachsen ist, der will sich so etwas nicht >> antun, wer sonst mit Eclipse hantiert, der wird sicherlich schon eher >> etwas damit anfangen können --- > > Naja, ich bin ja selbst mit Visual Basic 5+ und VC++ aufgewachsen. Aber > das, was MS sich da in der aktuellen Version leistet, ist an > Unaufgeräumtheit und Aufdringlichkeit kaum zu überbieten. > Der Quelltext rückt komplett in den Hintergrund vor lauter Explorern, > Statuszeilen und Symbolleisten... Also doch nur ein paar Screenshots gesehen ;-) Einmal zwei Minuten investieren und die Anordnung passend machen, dann geht das selbst auf 1280x800 Notebooks mit der selben sichtbaren Zeilenzahl wie bei jedem anderen "brauchbaren" Editor auch (kleiner Tip, Doppelklick zum Lösen des Tabs (Float), nochmal Doppelklick. dann ist der Tab mit dem Quelltext im Vollbild ohne "störendes" Drumrum oder man definiert sich passende Tastenkombinationen)
> Vorteile von C(++) gegenüber c# > - 0.01% mehr Speed > - Plattformunabhängigkeit > - 20MB weniger Resourcenverbrauch? ich hab zwar noch über 3GB frei aber > wenigsten ein Grund zum meckern Häh ? Falscher Film ? Hier wurde ein Projekt umgestellt, bei nahezu gleicher Funktionalität: Das C#-Programm ist nach anfänglichen Performanceproblemen jetzt genau so schnell wie das C++-Programm, allerdings wie jenes auf einem damals aktuellen 166MHz Pentium und das C# läuft auf einem aktuellen 3.2GHz Rechner. Das C++ Programm wurde auf alle möglichen Plattformen bei Beibehaltung des Quelltextes portiert, von Windows über *nixe und Mainframes von Siemens und IBM und irgendwelchen Palm-Pads, das C# Programm läuft ausschliesslich auf PC's. Statt damals ein Installpaket von 10MB inklusive Doku kommen jetzt 2GB ohne Doku an. Das ist die Realität, und ich möchten aktuellen Programmieren nicht unterstellen das sie voll blöd sind. Aber ich weiß, du bist so viel klüger...
MaWin schrieb: > Das C#-Programm ist nach anfänglichen Performanceproblemen > jetzt genau so schnell wie das C++-Programm, > allerdings wie jenes auf einem damals aktuellen 166MHz Pentium > und das C# läuft auf einem aktuellen 3.2GHz Rechner. > > Das C++ Programm wurde auf alle möglichen Plattformen bei > Beibehaltung des Quelltextes portiert, von Windows über > *nixe und Mainframes von Siemens und IBM und irgendwelchen > Palm-Pads, das C# Programm läuft ausschliesslich auf PC's. > > Statt damals ein Installpaket von 10MB inklusive Doku > kommen jetzt 2GB ohne Doku an. Nicht schlecht. Das muss man erstmal schaffen. Wie viel Thread.Sleep musste man einbauen, damit man ein Beispiel hatte um c# dermaßen runterzumachen? MaWin schrieb: > Statt damals ein Installpaket von 10MB inklusive Doku > kommen jetzt 2GB ohne Doku an. 2GB in c# aus 10MB halte ich für unmöglich. Zeig mal das Beispiel. > Das ist die Realität, und ich möchten aktuellen Programmieren > nicht unterstellen das sie voll blöd sind. Das möchten ich auch. > Aber ich weiß, du bist so viel klüger... Danke.
> Danke. Tja ja, die Selbstüberheblichkeit. > Wie viel Thread.Sleep musste man einbauen Falls du mal dem Kindergarten entwachsen sein solltest > Zeig mal das Beispiel. wirst du lernen was ein im Kundenauftrag erstelltes kommerzielles Programm ist. So lange: Hol wieder deine Bauklötzchen raus.
Anscheinend hast du wieder deine Märchenstunde. Das hier MaWin schrieb: > Das C#-Programm ist nach anfänglichen Performanceproblemen > jetzt genau so schnell wie das C++-Programm, > allerdings wie jenes auf einem damals aktuellen 166MHz Pentium > und das C# läuft auf einem aktuellen 3.2GHz Rechner. und das hier MaWin schrieb: > Statt damals ein Installpaket von 10MB inklusive Doku > kommen jetzt 2GB ohne Doku an. kauft dir keiner ab! Und genau das ist die Realität! Es könnte natürlich auch deine Fähigkeiten in der Programmierung wiederspiegeln.
Das ist aber möglich, guck dir doch mal die gesammte Computer Entwicklung an. Vor einigen Jahren, meinte eine Person (die ich hier nicht nennen will, weil sie bei einigen Gruppen komische Zuckungen auslöst) das man mit ca. 120kB auskommt. Damals war ein Text dokument noch ca. 0,5-1 Kb groß, heute ca. das gleich 5-50Kb. Besser noch, ich hatte mal ein Spiel hier, war um die 1Mb groß, heute das selbe (neu aufgelegt) ca. 150 Mb... So Ist die Entwicklung halt, und das selbe gilt für die Programmiersprachen. Ach ja ums zu erwähnen, ich selber hab nichts dagegen wenn jemand C# nutzt, aber in Kommerziellen Bereich finde ich es einfach... Naja immer hin besser als VB, das ist jetzt wirklich Kindergarten... Belassen wir es dabei, BTT or Close.
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.