Hallo Leute, ich habe schon etwas Programmiererfahrung in C/C++ jedoch ausschließlich Konsole. Nun möchte ich endlich damit anfangen mal richtige Anwendungen wie z.B. eine Datenauswertung (also auch grafische Aufbereitung) für eine Wetterstation zu programmieren. Nun stellt sich mir zwangsläufig die Frage, ob ich dies mit MFC machen soll, oder ob es nicht doch geschickter wäre das mit C# und .net anzugehen. Ich weis, daß C++ die wohl mächtigste Programmiersprache ist, die es gibt, insbesondere wenn es um hardwarenahe Geschichten bzw. zeitkritische Sachen geht. Ich weis auch, daß .net insofern den Nachteil hat, daß die Programme eine Laufzeitumgebung brauchen, was mit in C++ mit MFC geschriebenen Programmen wohl nicht so ist. Auch heißt es immer wieder die MFC wären überholt und auch schwieriger zu erlernen als .net. Prinzipiell käme auch Visual Basic in Frage, da ich jedoch an die C-Syntax schon etwas gewohnt bin wäre der Umstieg für mich mit C# wohl leichter zu erlernen, auch wenn VisualBasic noch den Vorteil bringen würde, daß man sich mit VBA in Office-Software leichter tun würde. Was meint ihr ? MFC oder .net wenn man noch keinerlei Erfahrungen mit beiden hat. Auch soll es ja anscheinend so sein, daß das Speichermanagement bei C# leichter von der Hand gehen soll, weil hier viel übernommen wird und man sich nicht um die Freigabe von Speicher und sonstigem im Prinzip selbst kümmer muß wie bei C++. Wäre nett, wenn der eine oder andere hierzu etwas sagen kann. Von (wie oft hier agressiven) und dummen Beiträgen wie "kauf dir halt eine Messdatenerfassung" oder "mach das halt in Labview" bitte ich euch Abstand zu nehmen. Zu viele Threads sind schon voll mit solchen Antworten, und ich habe mir von vornherein schon überlegt, daß ich es eben nur in C/C++, C# oder evt. noch VisualBasic machen möchte. Vielen Dank für eure hilfreichen Beiträge. Gruß
Mane Heinzinger schrieb: > Ich weis, daß C++ die wohl mächtigste Programmiersprache ist, die es > gibt, insbesondere wenn es um hardwarenahe Geschichten bzw. > zeitkritische Sachen geht. > > Ich weis auch, daß .net insofern den Nachteil hat, daß die Programme > eine Laufzeitumgebung brauchen, was mit in C++ mit MFC geschriebenen > Programmen wohl nicht so ist. > > Auch heißt es immer wieder die MFC wären überholt und auch schwieriger > zu erlernen als .net. Alle drei Aussagen sind Unfug. MFC ist insofern 'überholt', als dass Microsoft schon eine Handvoll Nachfolger hinterhergeworfen hat, von denen die ersten aber auch schon wieder überholt sind... > Was meint ihr ? MFC oder .net wenn man noch keinerlei Erfahrungen mit > beiden hat. Garkeine der beiden. C# ist nicht C++ und hat auch mit C++ nichts zu tun. MFC ist ein neues API, das musst du von Grund auf neu lernen. Wobei ich die nativen C++-API von Microsoft bislang immer recht katastrophal fand, was aber Geschmackssache ist. Da du bei MFC ein neues API erlernen musst, kannst du z.B. auch gleich Qt wählen. Qt musst du dann auch erlernen, aber Qt läuft auch auf vielen Embedded-Systemen, auf Mac und Linux/Unix. Ersteres könnte für dich interessant sein. Insofern gleiche Kosten, aber deutlich mehr Nutzen. > Auch soll es ja anscheinend so sein, daß das Speichermanagement bei C# > leichter von der Hand gehen soll, weil hier viel übernommen wird und man > sich nicht um die Freigabe von Speicher und sonstigem im Prinzip selbst > kümmer muß wie bei C++. Die Frage ist, was einfacher für dich ist. Für mich als alter C-ler ist C# einfach nur ätzend, weil ich häufig lange überlegen muss, ob irgendeine Ressource tatsächlich freigegeben wird und/oder wann das passiert. Ist halt so in mir drin. In der gleichen Zeit hätte ich locker saubere Aufräum-Routinen entwickelt und den ganzen GC-Krams weggespart. Auch das ist aber Geschmack und Gewohnheit. Und nun viel Spaß mit dem Flamewar :-)
Ist alles Geschmackssache. benutz doch VC++ da brauchst dich nicht umgewöhnen. Persönlich programmiere ich mit allen Syntaxarten, jedoch kann ich VB echt net leiden und ziehe als Kompormiss C# vor. Erzeugte Klassen sind eh untereinander austauschbar.
> Ich weis, daß C++ die wohl mächtigste Programmiersprache ist, die es > gibt, insbesondere wenn es um hardwarenahe Geschichten bzw. > zeitkritische Sachen geht. Also daß diese Aussage Unfug ist wage ich doch mal deutlich zu bezweifeln. Nach Rücksprache mit Leuten, die schon seit 30 Jahren nichts anderes tun als zu Programmieren ist insbesondere das Stichwart "Zeitkritisch" immer wieder als ein Pluspunkt für C++ erwähnt worden.
Mane Heinzinger schrieb: > "Zeitkritisch" immer wieder als ein Pluspunkt für C++ erwähnt worden. Zeitkritisch und C++ in einem Satz, geht doch mal garnicht :D Zeitkritisch -> Assambler, weniger zeitkritisch C, noch weniger C++ und wenn Zeit scheiss egal ist, kommen diese ganzen zusammen klick Programme.
Also daß Assembler noch davor liegt ist mir auch klar.... Wir eröffnen hier mal wieder einen typischen Nebenkriegsschauplatz....Ich spreche hier schließlich vom Anfang weg von Anwendungsprogrammierung. Ich möchte hier nur das Wort "Unfug" im Zusammenhang von zeitkritischen Anwendungen und C++ zurückweisen. Jetzt wieder zum Thema....sonst könnnen wir es hier auch gleich wieder abbrechen, weil es sonst nichts bringt.
> Nun stellt sich mir zwangsläufig die Frage, ob ich dies mit MFC machen > soll, oder ob es nicht doch geschickter wäre das mit C# und .net > anzugehen MFC ist selbst nach Microsoft's Meinung tot, und war ein total vergurkter Ansatz, die Objekte der GUI in Objektklassen von C++ abzubilden. Microsoft möchte dich gerne bei DotNET einladen, weil das deren Anrwort auf den Konkurrenten Java ist. Wenn du deren Ruf folgen möchtest, kannst du das tun, die Anwender finden dann deine Anwendung genau so wie eine Java Anwendung eher blöd: Noch ein parallel installiertes DotNet Framework oder eben Java-Runtime, noch was was Speicher frisst ohne Ende, noch was was updates zieht und "anders" aussieht als eine richtige Anwendung. Und so richtig plattformunabhängig ist es trotz Mono auch nicht, da wäre Java noch ein bischen besser. Schreib den Programm in C/C++ ohne jeden direkten Bezug zur Oberfläche. Programmiere dann die Oberfläche je nach Plattform in der "nativen" Umgebung, bei Windows also Win32 API. Ja, es ist schwieriger, ja, man muß manchmal einiges vorher wissen (weiß es aber nicht), es ist nicht verkehrt, mal in solche plattformunabhängigen Oberflächen zu gucken, wie Tcl/TK oder FLTK.
Hallo MaWin, im Prinzip hab ich mir das genauso gedacht wie du geschrieben hast. Das Problem ist halt nur immer der Forschritt beim Programmieren einer Anwendung. Ich habe hier einen rießen Schinken über Win32-API von Charles Petzold liegen, und es sieht ehrlich gesagt schon so furchteinflößend aus. Ich dachte halt (auch insbesondere) wegen dem streng objektorientiertem Design von C# wäre es für einen mehr oder weniger Anfänger in Sachen Anwendungsprogrammierung leicher über C# (wieder) auf C++ zu wechseln....denn wenn man mal ehrlich ist, ist die Win32-API Geschichte schon wirklich ein sehr dickes Brett das es zu bohren gilt.
Also ich würde dir entweder zu C++ + Qt raten oder C#. Ich würde vermuten mit C# gelangt man am schnellsten zum Ziel, weil man sich auf das Wesentliche beschränken kann und einem der andere Kram abgenommen wird und es eine umfangreiche Klassenbibliothek ähnlich wie bei Java gibt. kA warum man sich heutzutage für neue Sachen noch mit der Win32 API abquälen will. Das bisschen Speicher was nun .NET oder ne JRE heutzutage frisst, kriegt man doch schon hinterher geschmissen und wenn mich das immer noch stört dann greife ich halt auf C++/Qt zurück.
Ich wiederhole mich gern. Das WinAPI ist nichts, aber wirklich gar-nichts, an dem man sich ein Beispiel holen sollte, oder wodran man irgendwas gescheit lernen kann. Sämtliche Prototypen strotzen vor völlig missverstandener ungarischer Notation, und das gepaart mit haarsträubendem Herumgecaste durch Dummyparameter (wParam, lParam...). > Ich weis, daß C++ die wohl mächtigste Programmiersprache ist, die es > gibt, insbesondere wenn es um hardwarenahe Geschichten bzw. > zeitkritische Sachen geht. Diese Aussage ist aber effektiv Unfug. Allein schon deshalb, weil 'mächtig' je nach Problemstellung anders ausfallen kann. Halt dich von solchen haarsträubenden Schwanzvergleichen fern! Dass C# für einen C++ler einfach sein soll, mag der Name suggerieren. Es hat aber nicht viel mit C++ gemein, bis auf ein paar geschweifte Klammern. Und Syntax ist gerade das Allerletzte, was bei einer Programmiersprache wirklich interessant ist. MaWin erfasst das dann ganz gut. Das läuft recht gut auf 'die' Unix-Philosophie hinaus: Vernünftige Schnittstellen. Was nachher noch an Kosmetik drumherum kommt, ist nachrangig.
Sven P. schrieb: > Und nun viel Spaß mit dem Flamewar :-) Dann mal los... > Da du bei MFC ein neues API erlernen musst, kannst du z.B. auch gleich > Qt wählen. Qt musst du dann auch erlernen, aber Qt läuft auch auf vielen > Embedded-Systemen, auf Mac und Linux/Unix. Ersteres könnte für dich > interessant sein. > Insofern gleiche Kosten, aber deutlich mehr Nutzen. C#, .NET läuft auch (nativ) auf allen möglichen Systemen -> kein Vorteil für Qt. Dazu kommt das C++ wesentlich kostenintensiver ist (je nach Studie 15% bis 50% mehr Fehler bei einem drittel/Hälfte der Produktivität 1)) als C# oder Java. .NET MicroFramework (Apache-Lizenz) http://www.netmf.com/Home.aspx oder mit WinCE als OS oder auf normalen Systemen oder nativ Verve (ohne eine Zeile C/C++ und vollständig formal verifiziertes OS http://research.microsoft.com/apps/pubs/?id=122884) oder wenn man C# haben will MonoDroid (Android), MonoTouch (iPhone) oder Mono für die restlichen Systeme (0.x % Marktanteil) (wenn man sich auf WinForms beschränkt). Also höhere Kosten mit C++/Qt und weniger Nutzen. Um mal die Frage des TO zu beantworten: C# + .NET für die Anwendung, C++ falls es nötig ist, für extrem zeitkritische Sachen (und einige Interop-Sachen) > Die Frage ist, was einfacher für dich ist. Für mich als alter C-ler ist > C# einfach nur ätzend, weil ich häufig lange überlegen muss, ob > irgendeine Ressource tatsächlich freigegeben wird und/oder wann das > passiert. using, IDisposable etc. > MaWin erfasst das dann ganz gut. Das läuft recht gut auf 'die' > Unix-Philosophie hinaus: Vernünftige Schnittstellen. Was nachher noch an > Kosmetik drumherum kommt, ist nachrangig. So sieht's dann auch nachher aus scnr 1) u.a. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.7580&rep=rep1&type=pdf MaWin schrieb: > Wenn du deren Ruf folgen möchtest, kannst du das tun, > die Anwender finden dann deine Anwendung genau so wie > eine Java Anwendung eher blöd: Noch ein parallel > installiertes DotNet Framework oder eben Java-Runtime, Wenn man nicht alle Funktionen aus den neueren Frameworks braucht, kann man mit .NET 2.0 von XP bis 7 und div. Servern alles ohne etwas nach zu installieren erledigen > noch was was updates zieht und "anders" aussieht als eine richtige Anwendung. Sehen genau so aus wie MFC-Anwendungen, Updates kommen mit dem normalen Windows-Update > Schreib den Programm in C/C++ ohne jeden direkten > Bezug zur Oberfläche. Dann erst recht kein C/C++ > Programmiere dann die Oberfläche je nach Plattform in der > "nativen" Umgebung, bei Windows also Win32 API. Wann soll das Programm fertig werden?
Nimm C#. Als erfahrener C++ Programmierer wirst du dran sehr viel Spaß haben.
> Um mal die Frage des TO zu beantworten: > C# + .NET für die Anwendung For every complex problem there is an answer that is clear, simple, and wrong. (H. L. Mencken, 1880 - 1956)
MaWin (Gast) schrieb: > Microsoft möchte dich gerne bei DotNET einladen, > weil das deren Anrwort auf den Konkurrenten Java ist. Mir scheint MS hat viel mehr erkannt, dass Java nicht wirklich taugt, um eine umfassende Laufzeitumgebung für eben viele Sprachkonstrukte und nicht nur C# bereitzustellen (neben anderen Gründen). Und wenn man sich attraktive Programme wie Paint.net betrachtet http://www.getpaint.net/screenshots/pdn35_kirkland.jpg (und nutzt) finde ich, ist das auch gelungen. > Wenn du deren Ruf folgen möchtest, kannst du das tun, Wieso "folgen"? Was willst du damit ausdrücken? Das gerne für .NET genutzte C# (C-Sharp) ist eine nach ISO standardisierte Programmiersprache die inzwischen doch eine beachtliche Entwicklung durchlaufen hat. > die Anwender finden dann deine Anwendung genau so wie > eine Java Anwendung eher blöd: Was soll an einem Paint.net blöd sein? Das erkläre mir bítte mal. > Noch ein parallel > installiertes DotNet Framework oder eben Java-Runtime, Das sind doch zwei völlig verschiedene paar Schuhe. Das dämliche Java habe ich installiert weil OpenOffice das anscheint braucht, was ich für nicht besonders toll halte. .NET ist bei jedem halbwegs aktuellen Windows ab XP sowieso dabei. Da braucht keiner "parallel" fette Add-Ons wie Java mit seinen zig MBytes zu installieren. Wer WIndows hat, hat auch .NET. Nur Abdul hat als einziger noch WinME (armer, Abdul, armer ;)). Überhaupt, mal ein Thema zur Ausführungsgeschwindigkeit: Immer wird versucht .NET madig zu machen, weil es angeblich zu lahm ist. Jetzt nehmen wir mal OpenOffice als Beispiel. Das ist garantiert keine .NET Anwendung. OpenOffice ist aber sobald man es ein bisschen intensiver benutzt eine schleichend lahme Software, selbst bei 3 GHz Prozessorleistung. Ich führe das auf die allseits so geliebte Plattform-Unabhängigkeit zurück, die den Code dieser Software wohl irgendwie reichlich aufbläht (oder das Ding ist reichlich ineffizient programmiert). Wäre OO eine reine .NET Anwendung für MS, wäre die Software mit Sicherheit auch nicht noch langsamer (wahrscheinlich eher das Gegenteil). Mir wäre ein OO lieber, das auf Basis von .NET komplett auf den JAVA-Kram verzichtet. Zur Ausführungsgeschwindigkeit mal ein Zitat aus Wikipedia (http://de.wikipedia.org/wiki/.NET) "Dabei hat sich – analog zur Diskussion „Assembler ja oder nein“ – gezeigt, dass oftmals durch die Optimierung der zugrundeliegenden Algorithmen und Datenstrukturen eine wesentlich höhere Ausführungsgeschwindigkeit erzielt werden kann als durch die Entscheidung für oder gegen eine Programmiersprache oder Programmiertechnik." Also wäre demnach das Argument der höheren Performance durch C++ hinfällig oder zumindest keineswegs so bedeutsam wie immer getan wird. Sollte man vielleicht mal bedenken bei der ewigen Diskussion um Performance. Mane Heinzinger (Gast) schrieb: > Das > Problem ist halt nur immer der Forschritt beim Programmieren einer > Anwendung. Ich habe hier einen rießen Schinken über Win32-API von > Charles Petzold liegen, und es sieht ehrlich gesagt schon so > furchteinflößend aus. Wenn du Zeit und Muße hast kann ich nur raten den Petzold sich mal zu Gemüte zu führen. Ist eines der besten Bücher die man zum Thema Windows-Programmierung lesen kann. Danach fällt einem vieles leichter zu verstehen, wie das Windows-OS grundsätzlich funktioniert und anprogrammiert wird. > Ich dachte halt (auch insbesondere) wegen dem > streng objektorientiertem Design von C# wäre es für einen mehr oder > weniger Anfänger in Sachen Anwendungsprogrammierung leicher über C# > (wieder) auf C++ zu wechseln.. Mal ehrlich, um Windows Programme zu schreiben braucht man die beachtlich komplizierte C++ Syntax mit seinen fiesen Fallstricken nicht wirklich. Das einzige weshalb hier so oft C++ der Vorzug gegeben wird ist der Tatsache geschuldet, dass C# auf Unixoiden OS ein zwar durchaus wachsendes aber insgesamt noch immer eher kümmerliches Dasein fristet. Und woran liegt das? Sind wir doch mal ehrlich, das liegt im Wesentlichen am Unwillen der Community auf C# zu setzen, weil C# doch sehr mit dem Namen Microsoft verbunden ist (und die Community traditionell leider alles hasst was von MS kommt oder mit MS zu sehr verbandelt ist). Angebliche Persormancegründe werden zwar immer gerne vorgeschoben, sind aber im Zeitalter der vielen, vielen Skriptsprachen die heutzutage permanent genutzt werden doch nur noch Kappes und die allermeisten Rechner sind heutzutage mit genügend Rechenleistung und RAM ausgestattet und auch Garbage Collection im Hintergrund auszuführen (schließlich wird der Virenscanner und anderes Zeugs auch alles im Hintergrund ausgeführt - auch das frisst Performance und die meisten unter uns haben sich damit arrangiert). Außerdem sei an dieser Stelle noch mal mein Beispiel mit OO genannt. OO ist denke ich eine C++ Software und wirkt dennoch oft genug recht träge auch ohne "Managed Codeanteil". ;) Mein Voting deshalb ganz klar: PRO C#
OpenOffice ist größtenteils in C++ geschrieben und läuft auch komplett ohne Java (startet dann allerdings aktuell noch mit ein paar Fehlermeldungen, da wird wohl aktuell dran gearbeitet) Die relativ lahme Geschwindigkeit von OpenOffice kann man also zumindest nicht auf Java zurückführen ;D Generell geht mein Vote an C#
Ich stimme für C++ un Qt. Die Vorteile wurden schon mehrfach erwähnt. Leit zu programmieren ist es auch, da viele Beispiele beim Toolkit dabei sind. Eine integrierte Entwicklungsumgebumg ist auch dabei und das alles gratis. Wer unbedingt will, kann statt Qt auch andere Toolkits wie WWidgets benutzen, muß sich aber dann halt mit der Beschaffung und Installation von Entwicklungsungebung, Compiler, Toolkit herumschlagen. Dagegen Qt: herunterlöaden, installieren, loslegen. Und was jemand weiter oben vorgeschlagen hat, das native API des Betriebssystems für die GUI zu verwenden, ist an Kurzsichtigkeit nicht zu überbieten. Genau so schreibt man Programme, die sich nicht portieren lassen. Wer das will, bitte. Wer ein wenig mehr Weitblick hat, sucht sich ein Toolkit, das auf möglichst vielen Plattformen erhältlich ist (und das schließt C# und .Net schonmal aus. Auch wenn immer wieder irgendwelchen fadenscheinigen Argumente vorgebracht werden wg. Mono auf Linux. Mit .Net habe ich ja schon unter Windows Sorgen.)
> Und wenn man sich attraktive Programme wie Paint.net betrachtet > http://www.getpaint.net/screenshots/pdn35_kirkland.jpg > (und nutzt) finde ich, ist das auch gelungen. > Was soll an einem Paint.net blöd sein? Das erkläre mir bítte mal. Gerade DIE Software ist ja ein erklärtes Armutszeugnis für DotNET. Ein 1:1 Clone des über 10 Jahre älteren PaintShop (wo bleibt da der Fortschritt, es ist ein einfaches ideenloses mee-too), aber langsamer, grösser, hakeliger zu bedienen, und erfordert die Nachinstallation eines Magebytes-Frameworks, welches den Rechner nachhaltig ausbremst schon ab dem booten, also in jeder Beziehung schlechter als das Original. > .NET ist bei jedem halbwegs aktuellen Windows ab XP sowieso dabei. Nur wenn du so bescheuert bist, es dir heimlich unterschieben zu lassen, mit dem Erfolg, daß dein Rechner halb so schnell ist. Deinstalliere alles was von DotNET kommt und wundere dich wie rasend schnell dein Rechner bootot, wie rasend schnell er ist ganz ohne daß du jemanls ein DotNET Programm aufrufst. Microsoft gelingt es immer, Dinge maximal zu vergurken, aus politischer Vorgabe "wir wollen Intel helfen neue CPUs zu verkaufen". Selbst schuld, wer darauf reinfällt. Ich hab hier gerade Win7, das Zeug ist dermassen bugverseucht wie noch kein Betriebssystem davor. Mehrmals am Tag begegnen mit Bugs die meine Arbeit blockieren, und das bei einem "nackten" System nur mit MS-Software, und ich rede nicht mal von den Dingen, mit denen es Anfänger in den Wahnsinn treibt und Erfahrene zu unsäglicher Mehrarbeit zwingt.
MaWin schrieb: > Gerade DIE Software ist ja ein erklärtes Armutszeugnis für DotNET. > Ein 1:1 Clone des über 10 Jahre älteren PaintShop (wo bleibt da der > Fortschritt, es ist ein einfaches ideenloses mee-too), > aber langsamer, grösser, hakeliger zu bedienen, Ist das nicht die grundlegende Philosophie im *nix-Bereich, den 100 Klon des 100 Klons zu programmieren ohne Verbesserungen vorzunehmen? > und erfordert die Nachinstallation eines Magebytes-Frameworks, > welches den Rechner nachhaltig ausbremst schon ab dem booten, > also in jeder Beziehung schlechter als das Original. Schonmal die Abhängigkeiten von Firefox, OpenOffice, Ruby oder anderer Sachen auf *nix-Systemen angesehen... >> .NET ist bei jedem halbwegs aktuellen Windows ab XP sowieso dabei. > > Nur wenn du so bescheuert bist, es dir heimlich unterschieben zu .NET 2.0 und 3.0 sind bei Vista und Server 2008 vorinstalliert. .NET 3.5 bei Windows 7 und Server 2008 R2 Selbst XP SP1 lieferte die Version 1.0 auf der Installations-CD mit. > lassen, mit dem Erfolg, daß dein Rechner halb so schnell ist. FUD Das einzige was nach der Installation passiert, ist, dass das Framework d.h. die Assemblies vorkompiliert werden. > Deinstalliere alles was von DotNET kommt und wundere dich wie rasend > schnell dein Rechner bootot, wie rasend schnell er ist ganz ohne daß du > jemanls ein DotNET Programm aufrufst. FUD Mal zwei Sachen von denen man nicht annehmen würde das sie .NET bzw. mono nutzen... developer.mozilla.org insg. und Wikipedia für die Indizierung und Suche... http://www.mono-project.com/Companies_Using_Mono > Microsoft gelingt es immer, Dinge > maximal zu vergurken, aus politischer Vorgabe "wir wollen Intel helfen > neue CPUs zu verkaufen". Selbst schuld, wer darauf reinfällt. Ich hab > hier gerade Win7, das Zeug ist dermassen bugverseucht wie noch kein > Betriebssystem davor. Mehrmals am Tag begegnen mit Bugs die meine Arbeit > blockieren, und das bei einem "nackten" System nur mit MS-Software, FUD oder mal die "Bugs" benennen. Die "Hitliste" der Programme die hier am häufigsten abstürzen (Zuverlässigkeitsüberwachung Win7 und Vista)... Adobe Reader, OpenOffice, uVision, Firefox, Opera (wobei die drei erstgenannten wohl >90% der abstürze generieren) Dagegen sind in den letzten drei Jahren von den "Systemprogrammen" nur der Explorer, der IE und svchost jeweils ein einziges Mal abgestürzt... Auf dem Laptop (Win7) insg. nur zwei Abstürze des Intel-Grafiktreibers innerhalb eines Jahres.. Genug OT Es ging um C/C++ mit MFC vs. C# und .NET und da ist die Antwort eindeutig: C# und .NET
MaWin (Gast) schrieb: >> Und wenn man sich attraktive Programme wie Paint.net betrachtet >> http://www.getpaint.net/screenshots/pdn35_kirkland.jpg >> (und nutzt) finde ich, ist das auch gelungen. >> Was soll an einem Paint.net blöd sein? Das erkläre mir bítte mal. > Gerade DIE Software ist ja ein erklärtes Armutszeugnis für DotNET. Wie kommst du denn auf so einen Schwachfug? > Ein 1:1 Clone des über 10 Jahre älteren PaintShop (wo bleibt da der > Fortschritt, es ist ein einfaches ideenloses mee-too), An welchem Programm man sich orientiert hat ist doch völlig nebensächlich. Es wird gute gründe dafür gegeben haben. > aber langsamer, grösser, hakeliger zu bedienen, Auf meinem Rechner nicht. > und erfordert die Nachinstallation eines Magebytes-Frameworks, Auf meinem Rechner nicht. > welches den Rechner nachhaltig ausbremst schon ab dem booten, Hä? Wo hast du denn den Blödsinn her? > also in jeder Beziehung schlechter als das Original. Ich vergleiche Paint.net gar nicht mit irgend einem Vorgänger, das ist irrelevant für die Anwendung. >> .NET ist bei jedem halbwegs aktuellen Windows ab XP sowieso dabei. > Nur wenn du so bescheuert bist, es dir heimlich unterschieben zu > lassen, mit dem Erfolg, daß dein Rechner halb so schnell ist. Du leidest offensichtlich an Wahnvorstellungen. > Deinstalliere alles was von DotNET kommt und wundere dich wie rasend > schnell dein Rechner bootot, wie rasend schnell er ist ganz ohne daß du > jemanls ein DotNET Programm aufrufst. Mal ehrlich, so einen Schwachsinn kann ehrlich gesagt nur ein Trottel empfehlen. Bei einem Windows 7 ist .NET ein zentraler Bestandteil des OS und nicht irgend ein Zusatz wie Java. Ich hätte nicht gedacht das es hier Leute gibt die mal so einen Quark verbreiten. > Microsoft gelingt es immer, Dinge > maximal zu vergurken, aus politischer Vorgabe Labertasche! > Ich hab > hier gerade Win7, das Zeug ist dermassen bugverseucht wie noch kein > Betriebssystem davor. Mehrmals am Tag begegnen mit Bugs die meine Arbeit > blockieren, und das bei einem "nackten" System nur mit MS-Software, und > ich rede nicht mal von den Dingen, mit denen es Anfänger in den Wahnsinn > treibt und Erfahrene zu unsäglicher Mehrarbeit zwingt. Tut mir leid aber das ist so ein grotesk dummes Zeug was du hier ablässt, das nehme ich nicht ernst und dich künftig somit auch nicht mehr. Irgendwie muss die Hitze den Restverstand bei manchen Schreibern vertreiben.
Johann (Gast) schrieb: > Wer unbedingt will, kann statt Qt auch andere Toolkits wie WWidgets > benutzen, muß sich aber dann halt mit der Beschaffung und Installation > von Entwicklungsungebung, Compiler, Toolkit herumschlagen. Ein sehr steiniger Weg im Vergleich mit der sehr gut gelungenen Visual C# Express Version. > Dagegen Qt: > herunterlöaden, installieren, loslegen. Vor dem "loslegen" kommt dann aber erst mal der mühsame Weg sich die C++ Syntax reinzuziehen. Viel Spass dabei, das wird das "loslegen" erst mal wieder kräftig ausbremsen. > Und was jemand weiter oben vorgeschlagen hat, das native API des > Betriebssystems für die GUI zu verwenden, ist an Kurzsichtigkeit nicht > zu überbieten. Genau so schreibt man Programme, die sich nicht portieren > lassen. Und warum sollte jedes Programm und Progrämmchen das man mal braucht immer gleich "portierbar" sein? Wieso unterstellt ihr eigentlich, dass jedes Programm was man sich selbst zusammenstrickt (bei den allermeisten selbstgeschriebenen Programmen läuft es doch genau so, da reden wir ja nicht über eine Software, an der 12 Leute 4 Mannjahre programmieren, um das Endprodukt dann nachher zu vermarkten) unbedingt auf allen OS-Hochzeiten tanzen können muss? Habt ihr immer Angst, Linux könnte etwa zu kurz kommen oder die Mac-Plattform müsste das selbstgestrickte Programm auch unbedingt bekommen? > Wer ein wenig mehr Weitblick hat, sucht > sich ein Toolkit, das auf möglichst vielen Plattformen erhältlich ist Wozu? Es gibt gar keinen Grund grundsätzlich immer ALLE Plattformen bedienen zu MÜSSEN (zumal das ja dann auch für exotische Plattformen gelten müsste, wie BSD o.ä. oder vielleicht das alte Amiga-OS). Gerade für nicht so programmierkundige gilt viel mehr, es sich so "einfach" wie möglich zu machen, sonst stellt sich schnell Frust ein und das Programmieren macht keinen Spass mehr. Die Frage ist also nicht, wie erfülle ich den Wusch ANDERER die immer alles erwarten, sondern wie komme ich SELBST am schnellsten zu brauchbaren Ergebnissen. Ein gewisser Egoismus ist an dieser Stelle ausnahmsweise mal hilfreich. Sollen doch die anderen sehen wie sie MEIN Programm zum laufen kriegen (falls sie überhaupt jemals mein Programm zu Gesicht bekommen). Es wird bei den Tipps hier stets viel zu wenig unterschieden zwischen a) ich will OpenSource FÜR ALLE schreiben oder b) ich möchte ein Programm im Wesentlichen FÜR MICH schreiben (weil Programmieranfänger, Gelegenheitsprogrammierer, Ungeübter, "brauch mal gerade was" o.ä.) Im letzteren Fall interessiert ist die Plattformunabhängigkeit erst mal völlig sekundär; hauptsache das Programm läuft auf dem eigenen Rechner, das reicht völlig aus. > (und das schließt C# und .Net schonmal aus. Auch wenn immer wieder > irgendwelchen fadenscheinigen Argumente vorgebracht werden wg. Mono auf > Linux. Wenn Linux sich selbst C# Programme ausschließt ist das ein Linux-Problem. Dann müssen sie eben diese Programmierschnittstelle besser ausgestalten. Und wenn sie das nicht wollen (um mal wieder gegen MS zu schießen) dann kucken sie halt künftig in die Röhre bei C# Software. > Mit .Net habe ich ja schon unter Windows Sorgen. Du vielleicht, andere nicht.
> FUD oder mal die "Bugs" benennen. Im Gegensatz zu dir, dem offensichtlich jegliche Erfahrungen fehlen, rede ich von der realen Welt und nicht irgendwelchen rosarote-Brille-Träumen. Auf einem right-out-of-the-Box installierten Win7-64 mit IE9 funktioniert in diesem Forum das Eingabefeld oftmals (aber nicht immer) nicht: Man kann oft den Cursor in einem längeren Text nicht mit der Cursor ^ Taste eine Zeile nach oben bewegen (z.B. bleibt er in der dritten Zeile von unten hängen) man sieht oft den Cursor nicht, d.h. er blinkt an der Zielstelle nicht sondern woanders als die nächsten Zeichen erschineen steht ein dauerleuchtender schwarzer Strich, und (nicht nur in diesem Forum, sondern eher als Folg des Shcliessen eiones Reiters) hat der IE eine disabelte Menüzeile, manchmal eine Menüzeit die 1 cm mitten in der WebSeite steht (und dort sogar funktioniert). All diese Dinge gingen in vorherigen Versionen von Windows und IE schon, sie sind also kaputtprogrammiert worden von Leuten denen bunten Blinken offenbar wichtiger war als funktionierende Programme. Und es gibt hundert weitere. Sehr gut hat mir diese Anleitung gefallen http://wiki.winboard.org/index.php/MSI-Windows_Installer_Packet_aus_eingeschr%C3%A4nktem_Konto_als_Administrator_installieren die jeder Anfänger befolgen muß, der (p.s.: hier gerade an dieser Stelle geht cursor-hoch nicht) das System nur verwenden will. Unglaublich, daß eine Firma so was wirklich als zumutbar empfindet. Auch die Erfarhung mit DotNET fehlt die offenkundig, im Gegensatz zu dir habe ich es schon mal komplett deinstalliert (nach Anleitung aus dem Internet, bis im Control-Panel kein CardSpace mehr auftaucht) und konnte die wundersame Leistunggssteigerung meines Rechners nicht übersehen, obwohl auf ihm davor keine offen sichtbare DotNET Anwendung lief. Also Arc Net, wenn man so wie du keine wirkliche Ahnung hat, einfach mal die Klappe halten.
> Auf einem right-out-of-the-Box installierten Win7-64 > mit IE9 funktioniert in diesem Forum das Eingabefeld > oftmals (aber nicht immer) nicht: Also auf meinem Win7 32-bit funktioniert das Eingabefeld hier genau so wie vorher noch unter W2k, egal ob IE oder FF. Es ist also kein Problem das man so einfach .NET zuschreiben kann. > der IE eine > disabelte Menüzeile, manchmal eine Menüzeit die 1 cm > mitten in der WebSeite steht Mal abgesehen davon, wer zwingt dich eigentlich den IE zu verwenden? > Auch die Erfarhung mit DotNET fehlt die offenkundig, > im Gegensatz zu dir habe ich es schon mal komplett > deinstalliert Sowas dummes sollte man bei einem Win7 tunlichst unterlassen, sonst steht man bald da wie Abdul und wundert sich, dass dies und jenes plötzlich nicht funktioniert. > konnte > die wundersame Leistunggssteigerung meines Rechners nicht > übersehen, obwohl auf ihm davor keine offen sichtbare > DotNET Anwendung lief. Wenn ich Openoffice deinstalliere ist mein Rechner auch schneller (als mit der Installation). Wenn du übrigens GAR NICHTS installierst, dann ist der Rechner am schnellsten. Nur brauchst du dann vermutlich auch gar keinen Rechner, wenn du damit glücklich bist.
Das meiste wurde zwar schon gesagt, aber ich werde noch etwas "Senf" hinzufügen. Zunächst: Wenn du mit Windows-Only gut leben kannst, dann kann man für mittlere und große Projekte bedenkenlos zu C# und VisualStudioExpress greifen; wenn Linux auch ins Spiel kommt, dann nimm das Qt SDK. Ich persönlich finde zwar C# etwas eleganter, aber Qt verbirgt viel von den C++ Stolperfallen. Heutzutage will man Windows/Linux nicht mehr ohne Toolkit programmieren, ob man nun Qt installieren muss oder das .NET Framework ist eher zweitrangig. Allerdings greife ich bei "kleinen" Dingen (deine Messwertauswertung klingt danach) eher zu Python+Toolkit deiner Wahl (wenn's nur für mich ist) oder gar zu wxLua (http://wxlua.sourceforge.net/), wenn ich es weitergeben will. Grad wxLua ist da sehr net, man kann relativ einfach eine exe-Datei erstellen, die alles enthält. Kompiliert man dann noch SQLite (siehe http://www.dynaset.org/dogusanh/pgbookworm.html) mit rein, hat man gleich auch eine einfache Datenbank dabei. Das schöne: Dieses Executable kann man dann für viele Projekte verwenden, da man dann (mit wxLuafreeze) jeweils den Lua Code mit reinkopiert. Die Datei ist dann zwar mehrere MB groß (da ist ja u.U. ein Großteil der wxWidgets Lib drin), aber man hat eine einfache .exe die man problemlos weitergeben kann oder sogar die Programme dann vom USB Stick aus startet.
MaWin schrieb: > Auf einem right-out-of-the-Box installierten Win7-64 > mit IE9 funktioniert in diesem Forum das Eingabefeld > oftmals (aber nicht immer) nicht: > > Man kann oft den Cursor in einem längeren Text nicht > mit der Cursor ^ Taste eine Zeile nach oben bewegen > (z.B. bleibt er in der dritten Zeile von unten hängen) Ist tatsächlich unter W7/x64/IE9 (allerdings hier nur auf dem Laptop) reproduzierbar. > Sehr gut hat mir diese Anleitung gefallen > http://wiki.winboard.org/index.php/MSI-Windows_Installer_Packet_aus_eingeschr%C3%A4nktem_Konto_als_Administrator_installieren > die jeder Anfänger befolgen muß Wenn's ein Anfänger ist, ist dieser meistens ehe als Admin unterwegs... Abgesehen davon stellt sich die Frage wie oft man das denn am Tag so braucht, um sich das als Shortcut einzurichten zu müssen. BTW die div. Package-Systeme unter *nix sind auch nicht alle gleich bedienbar > Auch die Erfarhung mit DotNET fehlt die offenkundig, Sagen wir's mal so, wer keine Ahnung hat wie .NET überhaupt funktioniert, nichts damit entwickelt hat und anscheinend noch nicht mal ein einziges Rollout gemacht hat (von Rollouts in großen Umgebungen ganz zu schweigen) sollte sich an seine eigenen Empfehlungen halten. > und konnte > die wundersame Leistunggssteigerung meines Rechners nicht > übersehen, obwohl auf ihm davor keine offen sichtbare > DotNET Anwendung lief. Objektiv hat sich da genau nichts getan. Einfach mal den Process Explorer auf einem frisch gebooteten System starten und nachsehen was da denn so läuft. Nichts (außer man hat eine Grafikkarte von ATI/AMD). Auch der Dienst, der die Vorkompilierung (nach einem/r Update/Neuinstallation) durchführt, ist im Status beendet (Paint.NET stößt diesen Vorgang allerdings an) p.s. am Umgangston könnte man auch mal arbeiten
Vielen Dank für eure Beiträge. Ich versuch mich mal mit C# und .net. Wie ein Vorredner schon richtig geschrieben hat, geht es mir wirklich berhaupt nicht um portierbarkeit auf z.B. Linux, sondern erstmal darum kleine Sachen selbst programmieren zu können und das auf Windwos. Von diesen typischen "Windoof"-Beiträgen usw. halte ich ehrlich gesagt überhaupt gar nichts. Wenn Linux im Desktop-Bereich so toll wäre wie die "Windoof" Verfechter annehmen, hätte es sich schon längst durchgesetzt. Zugegeben ist z.B. Ubuntu echt nicht schlecht, aber eine Alternative wäre es für mich derzeit trotzdem noch nicht. Die beschriebenen Windows 7 Fehler kann ich in keiner WEise nachvollziehen. Bei mir zumindest klappt alles super, und noch kein OS vorher hat so schnell gebootet wie Windows 7. Wenn alles so scheiße ist, dann nehmt doch einfach Linux und gut is. Das mit dem Petzold überleg ich mir noch...aber zwischenzeitlich werd ich jetzt wohl erstmal anfangen mich in C# einzuarbeiten. Danke und schönen Gruß an euch alle. MaWin schrieb: > Also Arc Net, > wenn man so wie du keine wirkliche Ahnung hat, > einfach mal die Klappe halten. Das sind genau die Beiträge die echt für gar nichts gut sind. Du urteilst über die Leute die du nur aus ca. 20 Zeilen "kennst" und bringst hier eine unnötige Schärfe rein...genau diese dämlichen Anmachereien zerstören hier oftmals ganze Threads die einfach nur Sachlich über ein bestimmtes Thema diskutieren wollen.
> Einfach mal den Process Explorer auf einem frisch gebooteten > System starten und nachsehen was da denn so läuft. Nein, natürlich läuft .Net nicht als Prozess. Aber das Package schummelt dermassen viele Hooks ins System, daß jede Operation langsamer wird, obwohl gerade das ja bei Ausfüührungsschichten nicht der Fall sein 'sollte'. > Wenn's ein Anfänger ist, ist dieser meistens ehe als Admin unterwegs... Acuh Anfänger müssen gewisse Dinge einfach machen, um einen benutzbaren Rechner zu bekommen, z.B. bestimmte Software installieren. Aber ich seh schon, du hast eine andere Auffassung davon, du meinst daß es für einen Anwender unter Windows nicht vorgesehen ist was zu installieren sondern er dazu den Kundendienst anrufen soll. Das erklärt vieles deiner Kommentare.
Mane Heinzinger schrieb: > Ich weis, daß C++ die wohl mächtigste Programmiersprache ist, die es > gibt, insbesondere wenn es um hardwarenahe Geschichten bzw. > zeitkritische Sachen geht. Blödsinn. Man kann in C/C++ nichtmal Bitfelder präzise deklarieren. > Ich weis auch, daß .net insofern den Nachteil hat, daß die Programme > eine Laufzeitumgebung brauchen, was mit in C++ mit MFC geschriebenen > Programmen wohl nicht so ist. Auch da weißt du falsch. C/C++-Programme benötigen selbstverständlich ebenso eine Laufzeitumgebung (und wehe, hier kommt jemand mit freestanding).
Irgendwie geht der Schwanzvergleich wieder total am Thema vorbei. agp schrieb: >> Wer unbedingt will, kann statt Qt auch andere Toolkits wie WWidgets >> benutzen [...] > > Ein sehr steiniger Weg im Vergleich mit der sehr gut gelungenen Visual > C# Express Version. Findest du. Objektiv Geschwafel. Bis Win7 für mich einigermaßen 'bedienbar' war, musste ich auch jede Menge Zeug nachinstallieren. Halt am anderen Ende gespart. >> Dagegen Qt: >> herunterlöaden, installieren, loslegen. > > Vor dem "loslegen" kommt dann aber erst mal der mühsame Weg sich die C++ > Syntax reinzuziehen. Viel Spass dabei, das wird das "loslegen" erst mal > wieder kräftig ausbremsen. Und die C#-Syntax fällt vom Himmel ins Gehirn. Klar. >> Und was jemand weiter oben vorgeschlagen hat, das native API des >> Betriebssystems für die GUI zu verwenden, ist an Kurzsichtigkeit nicht >> zu überbieten. Genau so schreibt man Programme, die sich nicht portieren >> lassen. > > Und warum sollte jedes Programm und Progrämmchen das man mal braucht > immer gleich "portierbar" sein? Gegenfrage: Wenn ich keines der Toolkits beherrsche, also beide von Grund auf neu erlernen muss, warum sollte ich eines lernen, welches nicht plattformunabhängig ist? Ohne nennenswerten Mehraufwand krieg ich die Unabhängigkeit bei Qt geschenkt. Wenn ich ein kleines Tool schreibe, würde ich Qt vorziehen. Zumindest, wenn ich auch noch Leute erreichen möchte, die irgendwo bei Win2000 stehen geblieben sind. Ja, das gibt es, ist aber zugegebenermaßen selten. Insofern hat Qt den Nachteil, dass die Bindings zwar schnell mitgeliefert sind, aber dank der hirnverbrannten Mentalität hinsichtlich der Versionierung von Programmbibliotheken, die Windows an den Tag legt, werden die Bindings praktisch dann nicht mehr aktualisiert. Statt einer zentralen Bibliothek, wie es eigentlich alle anderen Systeme machen, schleppt jedes Windows-Progrämmchen seine Abhängigkeiten mit. Und so wächst der Wasserkopf von Qt schnell über .NET raus: Jedes Programm hat eine eigene Kopie dabei...
Sven P. schrieb: > Statt einer zentralen Bibliothek, wie es eigentlich alle anderen Systeme > machen, schleppt jedes Windows-Progrämmchen seine Abhängigkeiten mit. Den Versuch gab es, und der endete in der "DLL Hell". Jedes Programm wirft die mitgelieferte Variante der benötigten DLLs in das System-Verzeichnis ... und wenn der Installer nichts taugt, wird damit die bereits vorhandene, aber neuere Version überschrieben.
Rufus Τ. Firefly schrieb: > Sven P. schrieb: >> Statt einer zentralen Bibliothek, wie es eigentlich alle anderen Systeme >> machen, schleppt jedes Windows-Progrämmchen seine Abhängigkeiten mit. > > Den Versuch gab es, und der endete in der "DLL Hell". Jedes Programm > wirft die mitgelieferte Variante der benötigten DLLs in das > System-Verzeichnis ... und wenn der Installer nichts taugt, wird damit > die bereits vorhandene, aber neuere Version überschrieben. Jedes Programm schleppt seinen eigenen Installer mit, von Wise über NSIS bis WinZip/RAR. Das machts jetzt irgendwie nicht besser :-) Windows krankt doch ohnehin schon am kranken dynamischen Linker. Die Methodik, irgendwie eine brauchbare Bindung im System zu finden, ist schon gefährlich :-)
Sven P. (haku) schrieb: >> Ein sehr steiniger Weg im Vergleich mit der sehr gut gelungenen Visual >> C# Express Version. > Findest du. Ja. > Objektiv Geschwafel. Wenn du meinst. > Bis Win7 für mich einigermaßen 'bedienbar' war, musste ich auch jede > Menge Zeug nachinstallieren. Halt am anderen Ende gespart. Und ein nacktes Linux ist da anders? Wohl kaum .. Außerdem ist das nicht die Frage. Die Frage worum es geht ist, wie gut sind die Tools ausgestaltet, die mir das Erlernen einer Programmiersprache erleichtern und wie einfach ist deren Einrichtung und Bedienung. Die wichtigste Frage ist aber, womit komme ich am besten zurecht und das muss jeder selber herausfinden. > Und die C#-Syntax fällt vom Himmel ins Gehirn. Klar. Nein, natürlich nicht, aber das die Sprache eingängiger ist als C++ erleben komischerweise viele so. Wenn DU der C++ Nerd bist, dann Gratulation. Das ist aber lange nicht jeder. >> Und warum sollte jedes Programm und Progrämmchen das man mal braucht >> immer gleich "portierbar" sein? > Gegenfrage: Wenn ich keines der Toolkits beherrsche, also beide von > Grund auf neu erlernen muss, warum sollte ich eines lernen, welches > nicht plattformunabhängig ist? Weil ich es weiter oben schon erklärt habe. Zum hunderttausendsten Mal, plattformunabhängigkeit brauche ich nicht, wenn ich meine Programme nicht als OpenSource "vermarkten" möchte bzw. OpenSource geht auch - wenn es denn wirklich sein muss - mit C#. Wäre doch mal ein Anreiz sich seitens der Community sich endlich stärker um die Entwicklung von C# auf Linux zu kümmern oder? Aber da steht wohl der noch immer geplegte Hass vieler Commu-narden gegen MS im Wege. Aus dieser Kindernummer bin ich geistig glücklicherweise längst entwachsen und sehe die Dinge allseits viel entspannter und ohne diese verfluchte Lagerdenke und die Community sollte auch langsam mal geistig (in dieser Hinsicht) erwachsen werden. MS ist als Wirtschaftsunternehmen nicht schlechter als viele andere im Markt, deren Produkte auch der eingefleischte Linux-Nerd täglich nutzt. Das man MS grundsätzlich alles was sie machen negativ auslegt geht mir einfach so gegen den Kamm, da mag ich mich nicht mehr mit solidarisieren. > Ohne nennenswerten Mehraufwand krieg > ich die Unabhängigkeit bei Qt geschenkt. Der Mehraufwand steckt doch im Erlernen der C++ Syntax und des anderen Konzepts von QT. > Wenn ich ein kleines Tool schreibe, würde ich Qt vorziehen. Zumindest, > wenn ich auch noch Leute erreichen möchte, die irgendwo bei Win2000 > stehen geblieben sind. Ja, das gibt es, ist aber zugegebenermaßen > selten. Aber auch unter C# kannst du Programme schreiben die auf einem W2k laufen, das ja immerhin .NET 2.0 mitbringt (nur Abdul wird kreidebleich, wenn sein C# JIT-Compiler auf WinMe ihm den Dienst angesichts der geforderten .NET Version 2.0 stur verweigert ;-)) und somit die Allermeiste Funktionalität bereits drauf hat.
apg schrieb: >> Bis Win7 für mich einigermaßen 'bedienbar' war, musste ich auch jede >> Menge Zeug nachinstallieren. Halt am anderen Ende gespart. > > Und ein nacktes Linux ist da anders? Wohl kaum .. Nein, es ist für mich aber bedienbarer, selbst mit dem einfachen Standard-Werkzeugkoffer. Deshalb ja subjektiv. > Außerdem ist das nicht > die Frage. Die Frage worum es geht ist, wie gut sind die Tools > ausgestaltet, die mir das Erlernen einer Programmiersprache erleichtern > und wie einfach ist deren Einrichtung und Bedienung. Und wie viel verstecken die Tools vor mir, und wie stehe ich da, wenn es mal kracht und ich keine Idee hab, warum. Prominentes Beispiel: Borland Delphi. Eigentlich (damals) eine schöne IDE, aber für Anfänger total unbrauchbar, oft wegen automatisch generiertem Quelltext. > Die wichtigste > Frage ist aber, womit komme ich am besten zurecht und das muss jeder > selber herausfinden. Jawohl. >> Und die C#-Syntax fällt vom Himmel ins Gehirn. Klar. > > Nein, natürlich nicht, aber das die Sprache eingängiger ist als C++ > erleben komischerweise viele so. Viele erleben auch, dass sie plötzlich mehr oder weniger problemlos weg von syntactic sugar kommen, nachdem sie sich einmal so richtig durch C gebissen haben. Viele finden/fanden auch VB ganz toll und fielen nachher ganz toll auf die Schnauze damit. Viele verzweifeln auch an C(++). Ein recht fadenscheiniges Argument also. > Weil ich es weiter oben schon erklärt habe. Zum hunderttausendsten Mal, > plattformunabhängigkeit brauche ich nicht, wenn ich meine Programme > nicht als OpenSource "vermarkten" möchte bzw. OpenSource geht auch - > wenn es denn wirklich sein muss - mit C#. Das ist aber keine Begründung dafür oder dagegen. Das ist nur eine freiwillige Einschränkung unter unseren Voraussetzungen. >> Ohne nennenswerten Mehraufwand krieg >> ich die Unabhängigkeit bei Qt geschenkt. > > Der Mehraufwand steckt doch im Erlernen der C++ Syntax und des anderen > Konzepts von QT. Mir leuchtet aber immer noch nicht so recht ein, warum C# 'eingängiger' oder 'einfacher' sein soll. Die Sprache ist objektiv deutlich komplexer, als C++. Ok, mit C++ wird dafür öfter Schindluder getrieben, siehe Boost. Du sagst, der Mehraufwand steckt im Erlernen von C++ und dem Konzept von Qt. Ich sag, C# lernen und das Konzept von WPF oder was auch immer da gerade Mode ist, ist genauso Aufwand. Führt auch nicht weiter. Und der Qt-Designer ist wirklich, wirklich gut. Qt hatte schon Layouts, da waren Windows-Fenster noch Pixelzählerei. Guck dir manchen Konfigurationsdialog von Windows an, wo auf jeder Seite die Eingabefelder an unterschiedlichen Positionen anfangen...
apg schrieb: > Wäre doch mal ein Anreiz sich seitens der Community sich endlich stärker > um die Entwicklung von C# auf Linux zu kümmern oder? Aber da steht wohl > der noch immer geplegte Hass vieler Commu-narden gegen MS im Wege. Aus > dieser Kindernummer bin ich geistig glücklicherweise längst entwachsen > und sehe die Dinge allseits viel entspannter und ohne diese verfluchte > Lagerdenke und die Community sollte auch langsam mal geistig (in dieser > Hinsicht) erwachsen werden Das ist der absolute Brüller! Der größte und eifrigste Haßprediger in diesem Thread wirft genau das anderen vor. Und der letzte der Interesse daran hat, daß es ein gutes .net für andere Plattformen gibt ist ... Na versuche mal nachzudenken, wer hätte den größten Nachteil davon wenn Linux attraktiver würde? Aber nein, für dich sind die Linux Fans die bösen, die trotz Patente und nicht offengelegten Internas seitens MS Ihren Lebensunterhalt nicht darin sehen ein .net für Linux zu programmieren. @TE: Nimm c# das passt schon und die Anwendung sieht 'modern' aus. Aber denke nicht daß c# viel mit c++ zu tun hat, die Verwandschaft ist eher zu Java zu sehen. So wie Windows NT ein nachprogrammiertes (aber durchaus besseres) OS/2 war, ist c# die Antwort von Microsoft auf die Gefahr Java. Und auch hier ist c# genau dann die bessere Alternative, wenn du nur für Windows System Programme mit grafischen Interfaces schreibst. Die Argumente der Hasser und Jünger kannst du selbst erkennen und blendest du am besten aus. Also viel Spass und keine Angst vor etwas Neuem.
U.R. Schmitt (Gast) schrieb: apg schrieb: >> Wäre doch mal ein Anreiz sich seitens der Community sich endlich stärker >> um die Entwicklung von C# auf Linux zu kümmern oder? Aber da steht wohl >> der noch immer geplegte Hass vieler Commu-narden gegen MS im Wege. Aus >> dieser Kindernummer bin ich geistig glücklicherweise längst entwachsen >> und sehe die Dinge allseits viel entspannter und ohne diese verfluchte >> Lagerdenke und die Community sollte auch langsam mal geistig (in dieser >> Hinsicht) erwachsen werden > Das ist der absolute Brüller! Dann lach mal schön. > Der größte und eifrigste Haßprediger in diesem Thread wirft genau das > anderen vor. Da hab ich wohl ins Wespennest gestochen. Davon abgesehen ist deine Wortwahl vollkommen inakzeptabel und entbehrt jeglicher Diskussion. > Und der letzte der Interesse daran hat, daß es ein gutes .net für andere > Plattformen gibt ist ... Na versuche mal nachzudenken, Ach mein Gottchen, die übliche Leier. Microsoft ist an allem Schuld. > wer hätte den > größten Nachteil davon wenn Linux attraktiver würde? Wer verhindert denn, das Linux diesbezüglich attraktiver wird? Doch nur die ewige Rivalität einer auf die Gegnerschaft zu MS eingeschworenen Community. Kinderkacke ist das. > Aber nein, für dich > sind die Linux Fans die bösen, Das Gut-Böse Schema hast DU gerade selber bedient. > die trotz Patente Jaja, Patente, Patente. Patente gibt es bei Apple reichlich, reg dich darüber mal auf. Stell dir mal vor, manche umschiffen Patente durch kleine Änderungen. Alles gang und gebe. > und nicht offengelegten > Internas seitens MS Aber wenn das DEINE Firma wäre, dann würdest DU alles "offenlegen"? Jaja, ganz sicher. So funktioniert Wettbewerb heutzutage, so funktioniert die Finanzwelt usw. Alles wird immer "offengelegt". Träumer! > Ihren Lebensunterhalt nicht darin sehen ein .net für > Linux zu programmieren. Wieso soll euch MS euer Linux .NET Stricken? Das müsst ihr schon selber machen. Geschieht doch auch bereits, nur liegen die Vorlieben wohl woanders und das hat nicht nur technische Gründe und das weiß auch jeder.
Sven P. (haku) schrieb: >> Und ein nacktes Linux ist da anders? Wohl kaum .. > Nein, es ist für mich aber bedienbarer, selbst mit dem einfachen > Standard-Werkzeugkoffer. Deshalb ja subjektiv. Nur ging es doch eigentlich gar nicht darum wie ein Linux-OS zu bedienen ist (das in der Bedienung noch nie einfacher war als Windows. Das sieht man ja schon an solchen tradiotionellen Tools wie vi, emacs usw.), sondern wie man einen einigermaßen leichten Zugang zur Programmierung von Gui-Programen bekommt und welche Tools da einem am ehesten helfen. > Und wie viel verstecken die Tools vor mir, Was ist es denn was du unbedingt wissen möchtest und was man vor dir verbirgt? > und wie stehe ich da, wenn es > mal kracht und ich keine Idee hab, warum. Und bei Linux weißt du natürlich über jedes Bit bescheit. Deswegen gibt es unter Linux auch niemals längere Buglisten. Weil jeder immer aufs bit genau bescheit weiß können sich quasi nie Bugs ausbilden. Die werden just in time behoben. > Prominentes Beispiel: Borland Delphi. Eigentlich (damals) eine schöne > IDE, aber für Anfänger total unbrauchbar, Jo, das ist auch sehr sinnig hier jetzt mit Delphi zu kommen. Borland hatte auch mal ein schönes Turbo-Pascal und ein schönes Turbo-C zu bieten. Die IDE war die hauseigene Turbo-Vision Oberfläche. Da konnte sich seinerzeit Linux eine Scheibe von abschneiden, nix dergleichen auf Lager. > oft wegen automatisch > generiertem Quelltext. Auch ein Visual Studio mit oder ohne Express C/C++/C# kann auch Quelltext generieren wenn man das möchte. > Viele erleben auch, dass sie plötzlich mehr oder weniger problemlos weg > von syntactic sugar kommen, Na dann lass' ihnen doch erst mal den leichten Zugang. Hast du in der Grundschule mit irrationalen Zahlen zu rechnen begonnen oder doch viel eher mit den Natürlichen Zahlen und der "Modulo-Denke"? > nachdem sie sich einmal so richtig durch C > gebissen haben. Ob "richtig durchgebissen" oder vielleicht auch noch ausbaubar, ANSI-C halte ich - nachdem die Bedeutung von Pascal als erste Programmiersprache an Hochschulen zurückgegangen ist - für DIE Sprache schlecht hin, also durchweg positiv und ein absolutes muss. Jedoch .. der Sprung von ANSI-C zum C++ MIT objektorientierter Syntax wie sie von QT verwendet wird ist schon beachtlich und nach meinem Gefühl größer als der Sprung von C nach C# bei der Verwendung von .NET. Jedenfalls stellt sich das mir so dar, wenn man sich mal Tutorials beider Sprachen (also QT und C#) zur Windows-Programmierung betrachtet. Und dann ist da noch der Aspekt weswegen C# doch überhaupt entwickelt wurde: um weniger handgestrikte Fehler durch den Programmierer zu erhalten. Die Idee dahinter ist doch klasse. Den "Kehraus" (die Speicherbereinigung) überlässt man dem System so wie man das Schalten besser dem Automatikgetriebe überlässt - das kann das besser. Obwohl, ein paar Freiheiten gibt es ja noch immer. ;) > Viele finden/fanden auch VB ganz toll und fielen nachher > ganz toll auf die Schnauze damit. Warum? Weil sich VB nunmal nicht für alles eignet? Warum sollte nur etwas eine Berechtigung haben, das sich für alles eignet? Dann gäbe nur eine Programmiersprache, nämlich C++. Aber schau dir mal die beachtliche Entwicklung der Skriptsprachen an. > Viele verzweifeln auch an C(++). An C glaube ich weniger, an C++ bestimmt. >> Weil ich es weiter oben schon erklärt habe. Zum hunderttausendsten Mal, >> plattformunabhängigkeit brauche ich nicht, wenn ich meine Programme >> nicht als OpenSource "vermarkten" möchte bzw. OpenSource geht auch - >> wenn es denn wirklich sein muss - mit C#. > Das ist aber keine Begründung dafür oder dagegen. Ich sehe keine Begründung dafür sich etwas aufzuladen was man gar nicht braucht. > Das ist nur eine > freiwillige Einschränkung unter unseren Voraussetzungen. Deine "Plattformunabhängigkeit" ist doch genauso eine Einschränkung oder läuft dein "plattformunabhängiger" Code auf ALLEN erdenklichen OS? Wohl kaum. Was du als plattformunabhängig bezeichnest ist doch streng genommen nur eine Erweiterung auf die verbreitete Linux-Plattform (denn da kannst du noch relativ einfach testen). Welcher Programmierer will denn kontrollieren, ob sein Compilat auf sonstigen Plattformen überhaupt gescheit läuft? Sinn macht das nur wenn dort auch getestet werden könnte, womit wir wieder beim Aufwand sind. Dieser Aufwand ist schlicht UNSINN wenn es um das geht, was den Threadersteller bewogen hat diesen Thread zu starten, nämlich "mal weg von der Konsole hin zu GUi-Programmen zu kommen). > Mir leuchtet aber immer noch nicht so recht ein, warum C# 'eingängiger' > oder 'einfacher' sein soll. Die Sprache ist objektiv deutlich komplexer, > als C++. Findest du? Ich nicht. > Du sagst, der Mehraufwand steckt im Erlernen von C++ und dem > Konzept von Qt. So ist es und die Fehleranfälligkeit ist auch größer. > Ich sag, C# lernen und das Konzept von WPF oder was auch immer da gerade > Mode ist, ist genauso Aufwand. Aufwand ist alles, aber ich würde C++ nicht als DIE Sprache schlechthin für den Gelegenheitsprogrammer hinstellen, sondern eher als gute Wahl für Nerds. Und kommt mir jetzt nicht mit Brainf;ck oder sowas. ;-) > Führt auch nicht weiter. Der Threadersteller sollte sich beides (C++/QT und C#/.NET) mal zu Gemüte führen und herausfinden was ihm eher liegt. Das ist das Hauptaugenmerk und sonst erst mal nichts. Wenn ihm QT/C++ liegt dann soll er's nehmen. Da spricht nichts dagegen. Ich glaube nur da wird er mehr Schweiß rein stecken müssen. > Und der Qt-Designer ist wirklich, wirklich gut. Glaube ich dir. > Qt hatte schon Layouts, da waren Windows-Fenster noch Pixelzählerei. .. und DOS hatte schon IDE's mit Turbo C++ und Turbo Pascal da war Linux noch ein Gerücht im Netz eines begabten Finnischen Studenten. > Guck dir manchen Konfigurationsdialog von Windows an, wo auf jeder Seite > die Eingabefelder an unterschiedlichen Positionen anfangen... Wenn die Welt nicht mehr Probleme hat?! :)
apg schrieb: > Nur ging es doch eigentlich gar nicht darum wie ein Linux-OS zu bedienen > ist (das in der Bedienung noch nie einfacher war als Windows. Das sieht > man ja schon an solchen tradiotionellen Tools wie vi, emacs usw.), Subjektiver Unfug. Ich komme mit Windows 7 absolut nicht zurecht. Für mich ist das deutlich komplizierter, mich anhand der Anleitung durch den 10000. Dialog zu wühlen, als ein dämliches Kommando auf der Konsole abzusetzen. Subjektiv halt. >> Und wie viel verstecken die Tools vor mir, > > Was ist es denn was du unbedingt wissen möchtest und was man vor dir > verbirgt? Ich (ich!, andere vielleicht nicht) möchte gerne sehen, wie der Build verläuft, und was das Projekt zusammenhält. Delphi z.B. hat dazu automatisch einige Units erzeugt, die man eigentlich nicht sehen sollte. Im Debugger kamen die dann aber plötzlich dazu, und das hat regelmäßig große Verwirrung gestiftet. Das sollte der RAD-Benutzer halt nicht sehen, entsprechend dünn war es dokumentiert. Und hatte man versehentlich mal etwas darin verändert, war das Projekt (also die Projektdatei) nicht selten im Eimer. Ein transparentes Makefile hat da schon seinen Reiz. >> und wie stehe ich da, wenn es >> mal kracht und ich keine Idee hab, warum. > > Und bei Linux weißt du natürlich über jedes Bit bescheit. Deswegen gibt > es unter Linux auch niemals längere Buglisten. Weil jeder immer aufs bit > genau bescheit weiß können sich quasi nie Bugs ausbilden. Die werden > just in time behoben. Blah, blah. Sie werden zumindest behoben, ohne auf beknackte Patchdays zu warten. Bei VC++ Express ist/war das zum Beispiel schön. Wenn man ein Projekt unwissentlich auf einem Netzlaufwerk liegen hat (CIP an der FH...) und dann den Build anstößt, passiert entweder garnichts (Klick, nix passiert. Klick, immer noch nix.) oder der Build bricht mit einem 'Datei nicht gefunden'-Dialog ab. Hat eine Weile gedauert, bis ich das mit dem Netzlaufwerk in Verbindung gebracht habe. >> Prominentes Beispiel: Borland Delphi. Eigentlich (damals) eine schöne >> IDE, aber für Anfänger total unbrauchbar, > > Jo, das ist auch sehr sinnig hier jetzt mit Delphi zu kommen. Borland > hatte auch mal ein schönes Turbo-Pascal und ein schönes Turbo-C zu > bieten. Die IDE war die hauseigene Turbo-Vision Oberfläche. Da konnte > sich seinerzeit Linux eine Scheibe von abschneiden, nix dergleichen auf > Lager. Turbo Vision, ich hab es auch genutzt -- eine prima Sache -- kam um 1992 auf. Die graphische Oberfläche X11 für Unix, heute dann auch Linux, gibt es seit 1984. >> oft wegen automatisch >> generiertem Quelltext. > > Auch ein Visual Studio mit oder ohne Express C/C++/C# kann auch > Quelltext generieren wenn man das möchte. Das soll es aber für den Anfänger nicht. >> Viele erleben auch, dass sie plötzlich mehr oder weniger problemlos weg >> von syntactic sugar kommen, > > Na dann lass' ihnen doch erst mal den leichten Zugang. Hast du in der > Grundschule mit irrationalen Zahlen zu rechnen begonnen oder doch viel > eher mit den Natürlichen Zahlen und der "Modulo-Denke"? Nein, aber ich selbst habe bisher zwei Informatikkurse gegeben und zwei gehört und dabei jedes Mal erlebt, wie etwa 75% der Teilnehmer ständig in ihren 'leichten Zugang' zurückfielen. Es klingt aberwitzig, aber diese 'Warum braucht man überhaupt Strukturen, geht doch mit einzelnen Variablen genauso.'-Mentalität herauszukriegen, ist garnicht einfach. Die Leute, die aber vorher mal eine schwere Sprache versucht haben und ggf. sogar dran gescheitert sind, gehen deutlich, ich kanns nur betonen, offener an die Sache heran, mit entsprechend riesigen Lernfortschritten. >> nachdem sie sich einmal so richtig durch C >> gebissen haben. > > Ob "richtig durchgebissen" oder vielleicht auch noch ausbaubar, ANSI-C > halte ich - nachdem die Bedeutung von Pascal als erste > Programmiersprache an Hochschulen zurückgegangen ist - für DIE Sprache > schlecht hin, also durchweg positiv und ein absolutes muss. > > Jedoch .. der Sprung von ANSI-C zum C++ MIT objektorientierter Syntax > wie sie von QT verwendet wird ist schon beachtlich und nach meinem > Gefühl größer als der Sprung von C nach C# bei der Verwendung von .NET. > Jedenfalls stellt sich das mir so dar, wenn man sich mal Tutorials > beider Sprachen (also QT und C#) zur Windows-Programmierung betrachtet. Kann ich nicht nachvollziehen. Qt ist aber auch keine Sprache. Man könnte Qt noch anlasten, nicht die STL zu benutzen, für Container etc. Das rührt aber aus einer Zeit, als Templates noch gerade mangelhaft von Compilern unterstützt wurden. > Und dann ist da noch der Aspekt weswegen C# doch überhaupt entwickelt > wurde: um weniger handgestrikte Fehler durch den Programmierer zu > erhalten. Die Idee dahinter ist doch klasse. Den "Kehraus" (die > Speicherbereinigung) > überlässt man dem System so wie man das Schalten besser dem > Automatikgetriebe überlässt - das kann das besser. Obwohl, ein paar > Freiheiten gibt es ja noch immer. ;) Naja, das ist für den Einsteiger nicht gerade hilfreich. Genau da versteckt die Sprache wieder Dinge vorm Benutzer(*) Der Umstieg von Java/C# nach C (meiner Meinung nach auf lange Sicht unumgänglich) ist dann anschließend eine Katastrophe. Das sind dann die Programmierer, die überall die Speicherbereinigung vergessen... Deshalb ja dieses Sakrileg, sich erstmal durch C zu beißen: Alles von Hand. Und später lieber mal einmal zu viel gefragt, wer den Speicher aufräumt, als umgekehrt. >> Viele finden/fanden auch VB ganz toll und fielen nachher >> ganz toll auf die Schnauze damit. > > Warum? Weil sich VB nunmal nicht für alles eignet? Warum sollte nur > etwas eine Berechtigung haben, das sich für alles eignet? Dann gäbe nur > eine Programmiersprache, nämlich C++. Aber schau dir mal die beachtliche > Entwicklung der Skriptsprachen an. Weil VB (nicht VB.net) ein verkorkstes Dingen ist. Ist eine Lernsprache, nur aufgebohrt. Entsprechend kracht und scheppert es und geht nur mit Klimmzügen bei simplen API-Aufrufen. Dazu eine schräge Idee von 'OOP', jedenfalls ein bisschen OOP :-} >> Das ist aber keine Begründung dafür oder dagegen. > > Ich sehe keine Begründung dafür sich etwas aufzuladen was man gar nicht > braucht. Tust du ja nicht. Deshalb schrieb ich ja: Es bedeutet keinen Mehraufwand. >> Das ist nur eine >> freiwillige Einschränkung unter unseren Voraussetzungen. > > Deine "Plattformunabhängigkeit" ist doch genauso eine Einschränkung oder > läuft dein "plattformunabhängiger" Code auf ALLEN erdenklichen OS? Mein Produkt läuft auf Unixoiden (Unix, Linux, Mac, BSD) und Windows. Das reicht mir. Mac braucht niemand, verschiedene Linux und Windows werden und wurden getestet. > Wohl > kaum. Was du als plattformunabhängig bezeichnest ist doch streng > genommen nur eine Erweiterung auf die verbreitete Linux-Plattform (denn > da kannst du noch relativ einfach testen). Welcher Programmierer will > denn kontrollieren, ob sein Compilat auf sonstigen Plattformen überhaupt > gescheit läuft? Derjenige, der es da vertreiben möchte. Meine Zielgruppe ist nicht Mac. Trotzdem kann ich die Codebasis dort übersetzen und testen, wenn es irgendwann mal nötig wird. >> Mir leuchtet aber immer noch nicht so recht ein, warum C# 'eingängiger' >> oder 'einfacher' sein soll. Die Sprache ist objektiv deutlich komplexer, >> als C++. > > Findest du? Ich nicht. Ja. C# enthält deutlich mehr Sprachkonstruktionen. Ob die Sprache in ihrer Anwendung auch komplexer ist, weiß ich nicht, dafür hab ich zu wenig C# gelesen. >> Du sagst, der Mehraufwand steckt im Erlernen von C++ und dem >> Konzept von Qt. > > So ist es und die Fehleranfälligkeit ist auch größer. Welche 'Fehleranfälligkeit'? Die Aussage ist so Leerdammer. >> Ich sag, C# lernen und das Konzept von WPF oder was auch immer da gerade >> Mode ist, ist genauso Aufwand. > > Aufwand ist alles, aber ich würde C++ nicht als DIE Sprache schlechthin > für den Gelegenheitsprogrammer hinstellen, sondern eher als gute Wahl > für Nerds. Owei. VB ist gut als Aggressionsabbutraining.. >> Qt hatte schon Layouts, da waren Windows-Fenster noch Pixelzählerei. > > .. und DOS hatte schon IDE's mit Turbo C++ und Turbo Pascal da war Linux > noch ein Gerücht im Netz eines begabten Finnischen Studenten. Und die Unix-Leute benutzten schon das, was heute VNC ist, während der Xerox Star auf den Markt kam, mit Drucker- und Dateiserver, Email und so weiter... (81 glaub ich). Interessant ist auch, dass Turbo Vision später als Windows 3.0 herauskam. >> Guck dir manchen Konfigurationsdialog von Windows an, wo auf jeder Seite >> die Eingabefelder an unterschiedlichen Positionen anfangen... > > Wenn die Welt nicht mehr Probleme hat?! :) Nu, wer braucht schon einen Computer... :-}
Sven P. schrieb: > apg schrieb: >> Nur ging es doch eigentlich gar nicht darum wie ein Linux-OS zu bedienen >> ist (das in der Bedienung noch nie einfacher war als Windows. Das sieht >> man ja schon an solchen tradiotionellen Tools wie vi, emacs usw.), > Subjektiver Unfug. Ich komme mit Windows 7 absolut nicht zurecht. Für > mich ist das deutlich komplizierter, mich anhand der Anleitung durch den > 10000. Dialog zu wühlen, als ein dämliches Kommando auf der Konsole > abzusetzen. Subjektiv halt. > >>> Und wie viel verstecken die Tools vor mir, >> >> Was ist es denn was du unbedingt wissen möchtest und was man vor dir >> verbirgt? > Ich (ich!, andere vielleicht nicht) möchte gerne sehen, wie der Build > verläuft, und was das Projekt zusammenhält. Delphi z.B. hat dazu > automatisch einige Units erzeugt, die man eigentlich nicht sehen sollte. > Im Debugger kamen die dann aber plötzlich dazu, und das hat regelmäßig > große Verwirrung gestiftet. Das passiert/e auch regelmäßig bei C++, wenn's beim Debugging dann z.B. durch die STL geht. Von Delphi ist mir das nur bei zwei Gelegenheiten bekannt: Man hat die VCL-Sourcen oder es gibt eine unbehandelte Exception und man landet in der DPR die meist nur aus
1 | program XYZ; |
2 | uses |
3 | Forms, |
4 | AUnit in '...pas' {MainForm},
|
5 | BUnit in '...pas', |
6 | ...; |
7 | {$R *.res}
|
8 | begin |
9 | Application.Initialize; |
10 | Application.Title := 'XYZ'; |
11 | Application.CreateForm(TXYZForm, XYZForm); |
12 | try |
13 | Application.Run; |
14 | except |
15 | end; |
16 | end. |
besteht > Das sollte der RAD-Benutzer halt nicht sehen, entsprechend dünn war es > dokumentiert. Und hatte man versehentlich mal etwas darin verändert, war > das Projekt (also die Projektdatei) nicht selten im Eimer. Die gesamten Projektdateien und was dazu gehört sind extrem einfach aufgebaut. Gebraucht wurden afair nur die dpr und dof (Ini mit den Compiler etc. Einstellungen). > Turbo Vision, ich hab es auch genutzt -- eine prima Sache -- kam um 1992 > auf. Die graphische Oberfläche X11 für Unix, heute dann auch Linux, gibt > es seit 1984. X11 waren ein paar Grafikprimitiven und Abstraktionen zusammen mit einem Protokoll, die weit hinter dem hinterherhinkten was Apple, Atari, Amiga und Xerox zu diesem Zeitpunkt konnten. Einige Sachen z.B. Amiga Datatypes gibt's bis heute nicht in den gängigen Betriebssystemen. > Naja, das ist für den Einsteiger nicht gerade hilfreich. Genau da > versteckt die Sprache wieder Dinge vorm Benutzer(*) Der Umstieg von > Java/C# nach C (meiner Meinung nach auf lange Sicht unumgänglich) Auf lange Sicht ist der Trend klar: Kein C oder C++ (siehe z.B. das oben genannte OS Verve und andere Ansätze in diese Richtung), für Benutzeroberflächen wird's langfristig in vielen Bereichen Richtung HTML/JavaScript gehen (selbst Qt Quick nutzt JavaScript). > Ja. C# enthält deutlich mehr Sprachkonstruktionen. Ob die Sprache in > ihrer Anwendung auch komplexer ist, weiß ich nicht, dafür hab ich zu > wenig C# gelesen. C++0x sind 73 Schlüsselwörter und 43 Operatoren C# 4 sind 79 Schlüsselwörter und 41 Operatoren (new und delete sind bei beiden nicht doppelt gezählt). Die Sachen die C# mehr hat sind Properties, Events/Delegates (mehr oder weniger mit Funktionszeigern nachbildbar) und LINQ Dagegen hat C++ mit den Templates noch eine zweite Turing-vollständige Sprache eingebaut und ""C++ grammar is ambiguous, context-dependent and potentially requires infinite lookahead to resolve some ambiguities". http://stackoverflow.com/questions/243383/why-c-cannot-be-parsed-with-a-lr1-parser >> So ist es und die Fehleranfälligkeit ist auch größer. > Welche 'Fehleranfälligkeit'? Die Aussage ist so Leerdammer. Siehe Link von oben, die Fehleranfälligkeit (Defects per kSLOC) ist bei C++ höher und die Produktivität deutlich niedriger im Vergleich zu "verwalteten" Sprachen. u.a. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.7580&rep=rep1&type=pdf
Sven P. schrieb: > Und später lieber mal einmal zu viel gefragt, wer den Speicher > aufräumt, als umgekehrt. Endet bei C-Programmierern oft genug in doppelten free()s. Einen Zeiger nach dem Freigeben auf 0 zu setzen ist ja irgendwie nicht so komplett bei allen angekommen.
Also ich würde dir zu Piet + native Win32-API raten. Mit Piet kannst du ohne viel Text sehr schön anzuschauende Programme entwerfen. Dabei ist Piet systemunabhängig, also das läuft auf allen Systemen wo es einen Piet-Interpreter gibt. Vor allem ist das keine Sprache von so einem imperialistischen Ausbeuterunternehmen wie Oracle oder so.
Sven P. (haku) schrieb: apg schrieb: >> Nur ging es doch eigentlich gar nicht darum wie ein Linux-OS zu bedienen >> ist (das in der Bedienung noch nie einfacher war als Windows. Das sieht >> man ja schon an solchen tradiotionellen Tools wie vi, emacs usw.), > Subjektiver Unfug. Das ist eben MEINE subjektive Sicht, genau so wie du DEINE subjektive Sicht hier mitteilst. Du willst mir also ernsthaft erzählen, Tools wie vi oder emacs seien besonders anwenderfreundlich und damit für den Einsteiger geeignet? Sorry, aber das ist einfach nicht wahr. Damit nimmst du die Nöte und Schwierigkeiten von Leuten wie dem Threadstarter nicht ernst. Das ist schlicht die Sichtweise eines eingefleischten Konsolennerds der Unix-Gilde. Das ist überholt, das ist von vorgestern, diese Zeit ist ZUM GLÜCK vorbei (ich hab mich immer geärgern wenn ich unter Linux mal wieder auf dieses DING (Editor kann man einen vi ja nicht nennen) zurückgreifen musste. Unbequemer gings nicht - ohne Kenntnis ein paar wichtiger Kommandos ist es schon ein Frust in den Editiermodus und wieder zurück in den Befehlsmodus zu kommen - herumstochern im Nebel. Sowas wie vi braucht kein Mensch mehr heutzutage. Das Ding ist auf dem Niveau der eines CP/M. Mit Benutzerfreundlichkeit hat das nix, aber auch GAR NIX zu tun. > Ich komme mit Windows 7 absolut nicht zurecht. Ein Crack wie DU kommt mit so einem einfachen OS nicht zurecht? Das glaube ich dir nicht. Es ist wohl eher deine Einstellung zu einem Konzern wie MS, die hier das tragende Element der Abneigung darstellt. Mit Windows kommen komischerweise die allermeisten Computerneulinge schnell zurecht. Muss schon ein arger Zufall sein. > Ich (ich!, andere vielleicht nicht) möchte gerne sehen, wie der Build > verläuft Und das ist für den Threadersteller die entscheidene Frage? Der Threadersteller hat ein ganz anderes Interesse. Er möchte schnell zu Lernfortschritten gelangen. Was sich da alles unter der Haube abspielt ist für ihn erstmal völlig ohne Belang. Du setzt hier völlig falsche Prioritäten. > Blah, blah. Sie werden zumindest behoben, ohne auf beknackte Patchdays > zu warten. Da gibt es genau so Bugs die auch länger vorhanden sind. Das nimmt sich nix. Der Update-Service von Windows funktioniert ausgezeichnet. Ich kann mich noch an schlimme Zustände erinnern, als mein Suse Linux mir elende Wartezeit bescherte und das Update praktisch gar nicht funktionierte (der Netzwerkverkehr dümpelte bitweise vor sich hin). Zudem sind die Updates sowie Fehlerbeschreibung bei Windows transparenter. Man braucht kein Spezialwissen um erst mal herauszubekommen, was und mit welchen Auswirkungen überhaupt verändert wurde. Beim Suse Linux war das vergleichsweise mühsam herauszufinden. > Bei VC++ Express ist/war das zum Beispiel schön. Wenn man ein Projekt > unwissentlich auf einem Netzlaufwerk liegen hat (CIP an der FH...) und > dann den Build anstößt, passiert entweder garnichts (Klick, nix > passiert. Klick, immer noch nix.) oder der Build bricht mit einem 'Datei > nicht gefunden'-Dialog ab. > Hat eine Weile gedauert, bis ich das mit dem Netzlaufwerk in Verbindung > gebracht habe. Das eine Datei nicht gefunden wird ist ein alltägliches Szenario auf Rechnern und nun wirklich kein Grund für den Entscheid über so grundsätzliche Fragen wie die des Threadstarters. Ich hab beispielsweise mit dem LCC-Win32 und seiner hakligen IDE (besonders der Projektverwaltung) auch viel K(r)ampf erlebt. Solche Beispiele gibt es immer wieder. > Für > mich ist das deutlich komplizierter, mich anhand der Anleitung durch den > 10000. Dialog zu wühlen, Jetzt übertreibe mal nicht. Die Dialoge haben grundsätzlich (wenn richtig gestaltet) alle ihren Sinn und sind nichts anderes als die Abbildung der Kommandozeilenargumente in einer für den Anwender lesbareren und besser handhabbareren Form. Willst du den Anwender lieber mit einer endlosen Liste von Kommandozeilenbefehlen und Optionen "beglücken", deren Syntax oftmals nicht so einfach ist (man verschreibt sich schnell; es gibt viel Versuch und Irrtum dem Programm mitzuteilen was es machen soll) anstatt ihm in wohldosierten Häppchen jeweils einen übersichlichen Dialog mit Hilfestellung F1 zu spendieren? Seit wann ist denn die Kommandozeile ein Fortschritt in der Usability? Die Kommandozeile stammt aus der Zeit als Rechner noch Textbasiert waren und nicht genügend Rechenleistung hatten für ansprechende visuelle Darstellungen. Sie hat auch heute noch vereinzelt ihre Berechtigung, aber ein Ersatz für wohl gestaltete Dialoge ist sie nicht. > Turbo Vision, ich hab es auch genutzt -- eine prima Sache -- kam um 1992 > auf. Die graphische Oberfläche X11 für Unix, heute dann auch Linux, gibt > es seit 1984. Wir reden aber über Hilfmittel die den Einsteiger beim Lernen einer Programmiersprache unterstützen. Da hatte Unix/Linux als TurboVision am Markt war nichts Vergleichbares zu bieten. >> Auch ein Visual Studio mit oder ohne Express C/C++/C# kann auch >> Quelltext generieren wenn man das möchte. > Das soll es aber für den Anfänger nicht. Er muss auch nicht zwangsläufig die Helferlein dort benutzen. Er kann auch ein leeres Projekt nehmen und von dort seine Übungen beginnen, wie das Beispielsweise auch in Petzolds Buch zu C# (gibt mehrere) oder auch in anderen guten Büchern empfohlen wird. Ich halte nichts davon sich als Einsteiger eine Anwendung zusammenzuklicken. Solche Generatoren sind was für den geübten Benutzer, der sich nicht mehr so stark im Lernprozess befindet und besser bescheid weiß und Zeit sparen möchte. > Die Leute, die aber vorher mal eine schwere Sprache versucht haben und > ggf. sogar dran gescheitert sind, gehen deutlich, ich kanns nur > betonen, offener an die Sache heran, mit entsprechend riesigen > Lernfortschritten. Deswegen halte ich auch C für eine gute Einsteigersprache (mal abgesehen davon, dass wohl die Allermeisten die ersten Erfahrungen doch irgendwann mit Basic gemacht haben; die Älteren unter uns mit dem Aufkommen der Atari/C64 usw.; da war nichts schlimm dran, im Gegenteil, nichts wäre schlimmer als vor lauter Frust beim ersten Programmieren wenn nichts klappt nie mehr damit zu tun haben zu wollen) und um mal wieder auf den Petzold der Win32-API zu kommen, auch das ist eine gute Schule (wo man die MFC auch schön umschiffen kann). Alles bleibt beim reinen C - keine extra Einarbeitung in objektorientierte Syntax. > Kann ich nicht nachvollziehen. Qt ist aber auch keine Sprache. Aber ein Toolkit, dass die komplizierte und aus Anwendersicht (besonders der des unkundigen) eher fehleranfällige C++ Syntax bedingt. Klar, dass man das anders sieht als jemand der darin sehr geübt ist und andere sogar unterrichten kann. > Der Umstieg von > Java/C# nach C (meiner Meinung nach auf lange Sicht unumgänglich) ist > dann anschließend eine Katastrophe. Macht man auch nicht so, sondern genau anders herum. Erst C dann später C# oder Java oder .. . C kann man sowieso immer gut gebrauchen, wenn man sich in einem Forum wie diesem aufhält. Ich wüsste nicht, dass Atmel Controller neuerdings objektorientiert programmiert werden, ist also (objektorientiertes) C++ hier unnötig. Der Threadersteller hat außerdem bereits Erfahrung in C (dürfte den Allermeisten auch so gehen und ist auch prima so). > Deshalb ja dieses Sakrileg, sich erstmal durch C zu beißen: Alles von > Hand. Und später lieber mal einmal zu viel gefragt, wer den Speicher > aufräumt, als umgekehrt. Wer Erfahrung in C hat, hat auch schon malloc und Konsorten verwendet, aber wenn eine automatische Speicherbereiningung einem wie bei C# diese Arbeit abnimmt und damit die Software robuster gegen Programmierfehler wird, ist das umso besser, solange das gut funktioniert. Überhaupt gehst du viel zu oft davon aus, dass der Programmierer immer alles richtig macht. Dem ist aber nicht so. Woher kommen sonst all die Bugs? > Weil VB (nicht VB.net) ein verkorkstes Dingen ist. Ist eine Lernsprache, > nur aufgebohrt. Entsprechend kracht und scheppert es und geht nur mit > Klimmzügen bei simplen API-Aufrufen. Dazu eine schräge Idee von 'OOP', > jedenfalls ein bisschen OOP :-} Hab ich nie verwendet, aber (das alte) VB erfreut sich bei nicht gerade wenigen hoher Beliebtheit. Das sind wahrscheinlich hauptsächlich diejenigen, die andere Programmiersprachen wie zu sehr C/C++ abgeschreckt haben. >> Ich sehe keine Begründung dafür sich etwas aufzuladen was man gar nicht >> braucht. > Tust du ja nicht. Deshalb schrieb ich ja: Es bedeutet keinen > Mehraufwand. Auch wenn du das nicht verstehen willst, der Mehraufwand von C++ im Zusammenhang mit QT liegt für mich im schwierigeren Verständnis gegenüber beispielsweise einem C# oder Java. Du bist vielleicht der Nerd in C++, aber andere sind das eben nicht. Darauf solltest du mehr Rücksicht nehmen. > Mac braucht niemand Nana, wer wird denn die armen Mac-Leute von der allseits gepriesenen "plattformunabhängigkeit" ausschließen wollen? So kannst du dein heiliges Sakrileg kaum aufrecht erhalten .. >> Welcher Programmierer will >> denn kontrollieren, ob sein Compilat auf sonstigen Plattformen überhaupt >> gescheit läuft? > Derjenige, der es da vertreiben möchte. Siehst du, deshalb ist Plattformunabhängigkeit hauptsächlich etwas für Leute, die ihre Software mal vermarkten wollen. Alle anderen brauchen das nicht und sollten lieber ihrer persönlichen Neigungen zu einer bestimmten Programmiersprache folgen. > C# enthält deutlich mehr Sprachkonstruktionen. Ob die Sprache in > ihrer Anwendung auch komplexer ist, weiß ich nicht, dafür hab ich zu > wenig C# gelesen. Es genügt von beiden sich ein paar Tutorials reinzuziehen, dann sollte man merken was einem eher liegt. Da braucht man keine komplizierten Seminare drüber abzuhalten. Wenn ich einen Blick auf Brainf;ck werfe, weiss ich binnen Sekunden, dass ich und diese Programmiersprache niemals Freunde werden. ;) Zugegeben bei C++ ist das nicht so eindeutig, aber zumindest tendentiell ebenso. Zutrauen würde ich mir es aber auch, nur mögen mag ich es eben nicht. > Welche 'Fehleranfälligkeit'? Die Aussage ist so Leerdammer. Ja nu, da wo Freiheiten existieren nehmen die Fehler zu. Was meinst du wohl was einer der wesentlichen Hintergründe war eine neue Programmiersprache wie C# auf den Plan zu rufen? Jaja, das reizt jetzt zur Polemik, ich weiß. >> Aufwand ist alles, aber ich würde C++ nicht als DIE Sprache schlechthin >> für den Gelegenheitsprogrammer hinstellen, sondern eher als gute Wahl >> für Nerds. > Owei. VB ist gut als Aggressionsabbutraining.. Warum anwortest du mit dem Beispiel VB? Darum ging es doch hier gar nicht. > Und die Unix-Leute benutzten schon das, was heute VNC ist, während der > Xerox Star auf den Markt kam, mit Drucker- und Dateiserver, Email und so > weiter... (81 glaub ich). Die hatten auch schon den Kernighan/Ritchie als Ausgabe Copyright 1988/78. :) Meine deutsche Ausgabe ist von 1990. Ich bin aber aufgrund allgemeiner menschlicher Vergesslichkeit und eher gelegentlicher Übung noch immer in der C-ASM-Win32 (und C# sowieso) Lernphase und werde das auch wohl ewig bleiben - also auf Nerd-Ebene kann ich nicht wirklich mitreden, aber Anfänger bin ich auch nicht mehr (DSP-Programmierung schon gemacht etc.). Das tut dem Spass aber keinen Abbruch. ;) > Nu, wer braucht schon einen Computer... :-} Ach sie sind doch so schön (wehmut tut sich auf) .. selbst die, deren OS nicht aus dem Hause Microsoft kommt (hehe).
agp schrieb: > Die hatten auch schon den Kernighan/Ritchie als Ausgabe Copyright > 1988/78. Den will man nicht haben, der ist schrecklich. > Meine deutsche Ausgabe ist von 1990. Die ist hingegen gut und wird von mir nach wie vor als Grundlagenliteratur empfohlen. Schade, daß es davon keine neue Ausgabe gibt, die sich der Neuerungen seit C89 annimmt, aber das tun ja die Compilerhersteller nur zu oft auch nicht. (Wenn MS mal C99-Unterstützung in seinen C-Compiler einbaut, dann wird der Nachfolger von C99 auch schon veraltet sein).
Nein, mich stört Windows immer mehr. Es wird immer unübersichtlicher, immer unbedienbarer. Seit neuestem sind die Linien in TreeViews weg. Die Systemsteuerung verkommt zu einem Roman (zwei Bildschirmseiten randvoll Text mit Bildchen), ich brauche ewig, bis ich das richtige Symbol gefunden habe. Das Startmenü geht an jeder Ergonomik vorbei, dynamische Ribbons sowieso. Die Dusselige herumklickerei geht mir mehr und mehr auf den Zeiger -- was früher noch mit wenigen Handgriffen in zwei Dialogen zu machen war, wird jetzt hinter zehn Vorhängen versteckt, damit es auch ja benutzerfreundlich ist. Überall noch mehr Textwildwuchs: - Einstellungen -> Einstellungen ändern -> Erweiterte Einstellungen -> Zurzeit nicht verfügbare Einstellungen -> Aha! Genau DAS nervt. Einen Modus für diejenigen, die glauben, einen Computer bedient man ohne Anleitung aus dem Stehgreif, kann man ja einbauen. Aber bitte, BITTE, dann auch einen Knopf, um den Firlefanz wieder abzustellen und die Anzeige von 'Aerodynamisch interaktiv transparent' in 'Einfach' umzustellen. Meine Linien in TreeViews hat mir jetzt wenigstens 'Classic Shell' wieder eingebaut.
Haku (Gast) schrieb: > Nein, mich stört Windows immer mehr. > Es wird immer unübersichtlicher, immer unbedienbarer. > Seit neuestem sind die Linien in TreeViews weg. Die Systemsteuerung > verkommt zu einem Roman (zwei Bildschirmseiten randvoll Text mit > Bildchen), ich brauche ewig, bis ich das richtige Symbol gefunden habe. > Die Dusselige herumklickerei geht mir mehr und mehr auf den Zeiger -- Ist bei mir eine Seite. Aber genau DIESE Klickerei brauche ich doch unter W7 gar nicht mehr. Früher musste man sich anstrengen um z.B. zum Gerätemenager zu gelangen. Unter W7 genügt es in der Startzeile ein "gerä" einzugeben und schon wird mir als zweiter Eintrag "Geräte-Manager" angeboten. Oder Energieoptionen, bei mir genügt ein "ene" + Return und ich bin im Energie Management. Oder wie heißt noch mal der Teil von Windows in dem man neue Partitionen erstellen kann? Wer vergessen hat, dass das die sog. Datenträgerverwaltung ist, kein Problem, einfach "fest" (für irgendwas mit Festplatten machen) eingeben und schon kommt man ganz einfach zur Datenträgerverwaltung usw. usw. Um das herauszufinden brauchte ich weder Forenrecherche noch Handbüchelein noch sonst irgendwelche Hilfmittel. DAS IST INTUITIV und wirklich sehr gut gelöst. Wer das nicht nutzt und lieber klickt macht es sich nur unnütz schwer. > Das Startmenü geht an jeder Ergonomik vorbei .. Also im Vergleich mit dem Startmenü aus KDE 4 ist das W7 Startmenü für mich ganz ehrlich ein Wohltat. Rufus Τ. Firefly (rufus) (Moderator) schrieb: > (Wenn MS mal C99-Unterstützung in seinen C-Compiler einbaut, dann wird > der Nachfolger von C99 auch schon veraltet sein). Dafür gibt es doch das freie Pelle Orinius' C. Eine für den Einstieg in C schön gelungene IDE, die nicht viel an Ressourcen verschlingt und C99 unterstützt bzw. mehr noch, Pelle hat dort eigene interessante Erweiterungen eingebaut (muss man ja nicht nutzen, kann man aber) siehe "The #include files classified as private are not part of the ISO C99 standard. They are a mix of files from the Posix standard ("a useful selection"), Microsoft, and Pelle." Plattformunabhängig ist das dann natürlich nicht. ;)
Bisher empfand ich das nicht sonderlich intuitiv, wenn ich bei jeder neuen Windowsversion wieder ganz von vorne anfangen konnte, weil sämtliche Dialoge umstrukturiert, neu sortiert und tapeziert wurden. Dann steh ich aber lieber auf Anleitung. Gestern wieder im Explorer: 'Ordner kann nicht gelöscht werden, weil ein Programm darauf zugreift.' Na danke, und jetzt? Die Taskleiste ist leer. Als Intuitiv-Benutzer fühle ich mich jetzt irgendwie aufgeschmissen...
Sven P. schrieb: > Bisher empfand ich das nicht sonderlich intuitiv, wenn ich bei jeder > neuen Windowsversion wieder ganz von vorne anfangen konnte, weil > sämtliche Dialoge umstrukturiert, neu sortiert und tapeziert wurden. Schick ist, daß das mitunter schon bei kleinen Versionssprüngen passiert. Windows Server 2008 und Windows Server 2008 R2 unterscheiden sich teilweise deutlich. Wenn man übrigens auf diesem System (oder auch Windows 2007) eine "eingehende Verbindung" einrichten möchte, so hilft die von "apg" geschilderte Vorgehensweise nicht. Weder die zentrale Suchfunktion noch die Suchfunktion in der Systemsteuerung findet diesen Ausdruck, auch mit "RAS" kommt man nicht weiter. Man muss wissen, daß man im "Netzwerk- und Freigabecenter" die "Adaptereinstellungen ändern" will (nicht aber die erweiterten), und dann muss man wissen, daß man im folgenden Fenster das Menü nur durch Drücken der Alt-Taste erhält, und dann muss man wissen, daß man "Datei"->"Neue eingehende Verbindung" anklicken muss. Das ist total intuitiv, klar. "Dokumentiert" ist dieser Krampf natürlich im "Hilfe- und Supportcenter" Und einen Weg, den ganzen unnötigen Müll im Explorer auszublenden ("Favoriten" und "Bibliotheken" zusätzlich zum mit dem Benutzernamen benannten Symbol, hinter dem sich der ganze Kram nochmal verbirgt ... auf dem 2008 Server ist der Explorer noch schlimmer, der muss so eine Art "Zieharmonika" wahlweise mit Linkfavoriten oder den Ordnern anzeigen. Natürlich ist das Haupteinfallstor für Trottelviren bei Windows immer noch weit geöffnet: Das Ausblenden der Dateinamenerweiterungen bei "bekannten" Dateien. Diese Firma setzt grenzdebile "Designer" ein.
Rufus Τ. Firefly schrieb: > Wenn man übrigens auf diesem System (oder auch Windows 2007) eine > "eingehende Verbindung" einrichten möchte, so hilft die von "apg" > geschilderte Vorgehensweise nicht. Weder die zentrale Suchfunktion noch > die Suchfunktion in der Systemsteuerung findet diesen Ausdruck, auch mit > "RAS" kommt man nicht weiter. scheinbar kannst du nicht mal die Hilfe bedienen. Wenn ich in Win7 "eingehende Verbindung" in der hilfe Suche, dann kommt ich zu diesem Thema: Einrichten einer eingehenden VPN- oder DFÜ-Verbindung
Peter II schrieb: > scheinbar kannst du nicht mal die Hilfe bedienen. Scheinbar kannst Du auch keine Texte lesen, was meinst Du wohl, was ich da beschrieben habe? Was aber ist von einer Funktion zu halten, die man nur über die Hilfefunktion aufrufen kann? Und das ist halt schon was anderes, als das, was "apg" hier schildert: > Unter W7 genügt es in der Startzeile ein "gerä" einzugeben und > schon wird mir als zweiter Eintrag "Geräte-Manager" angeboten.
Gähn Ging es hier nicht eigentlich mal um C++ und C#? Gibts eigentlich schon ein Netlaw, dass jede Diskussion, wenn sie nur lange genug dauert, irgendwann zu einem Windows-Linux-Flamewar mutiert?
agp schrieb: > Aber genau DIESE Klickerei brauche ich doch > unter W7 gar nicht mehr. Früher musste man sich anstrengen um z.B. zum > Gerätemenager zu gelangen. Unter W7 genügt es in der Startzeile ein > "gerä" einzugeben und schon wird mir als zweiter Eintrag > "Geräte-Manager" angeboten. Juchu, jetzt wird immer besser. Es ist also ein Fortschritt, wenn ich ein mehr oder weniger kryptisches Kommando bzw. Wort wissen muss um dahin zu kommen wohin ich will? Hüstel, DOS2.11 (die älteren erinnern sich vieleicht) konnte das auch schon rmdir eingegeben und schon war ein Verzeichnis gelöscht. Auch Unix vor 30 Jahren hat so gearbeitet, und das hatte damals schon ein echtes Multiuser und Multitasking, was Windows irgendwie immer noch nicht hat. Wenn da ein automatisches Windows Update im Hintergrund läuft kanns schon sein, daß der Browser (das aktive Fenster!) mal für 15 Sekunden gar nix macht. Ich erinnere nur daran: "Wenn Microsoft Autos bauen würde..." Beim Übergang auf Vista musste ich daran denken, da war der Blinker plötzlich mit dem Fuss zu bedienen, die Bremse war seitlich an der Tür, ... Hauptsache immer anders und Bonbonbunt :-) Egal, man kann mit Windows arbeiten vieles ist einfacher als früher und vor allem macht es immer wieder Spass wenn die Sektierer und MS Jünger reflexartig allen anderen den selben -nur umgekehrten- Absolutismus vorwerfen, den sie praktizieren. In dem Sinne viel Spass noch mit den Thread, dem TO wurden ja genügend Hinweise gegeben wie er sich entscheiden soll...
Rufus Τ. Firefly (rufus) (Moderator) schrieb: > Wenn man übrigens auf diesem System (oder auch Windows 2007) eine > "eingehende Verbindung" einrichten möchte, so hilft die von "apg" > geschilderte Vorgehensweise nicht. So? Räusper .. > Weder die zentrale Suchfunktion noch > die Suchfunktion in der Systemsteuerung findet diesen Ausdruck, auch mit > "RAS" kommt man nicht weiter. > Man muss wissen, daß man im "Netzwerk- und Freigabecenter" die > "Adaptereinstellungen ändern" will (nicht aber die erweiterten), und > dann muss man wissen, daß man im folgenden Fenster das Menü nur durch > Drücken der Alt-Taste erhält, und dann muss man wissen, daß man > "Datei"->"Neue eingehende Verbindung" anklicken muss. Also spontan-intuitiv hätte ich es mit einem "verb" (für Verbindungen) im Startmenü probiert. Dann erscheint rechts unten "Netzwerk und Freigabecenter öffnen". Klick drauf bringt u.A. die Apaptereinstellungen zutage. "Menü nur durch Drücken der Alt-Taste" Ah, sehe was du meinst. In der Tat, gebe ich zu, hat MS ganz schön versteckt. Hätte ich mir einen Hinweis dazu auf der Seite gewünscht. > Das ist total intuitiv, klar. Das sind die Dinge die ich so auch nicht mag. Aber mal ehrlich, gegen das was die Suse Distro mir mit meinem Modem einst zugemutet hat ist das gar nix. Für beide gilt aber, wenn man's erst mal weiß ist es halb so wild. Wer es nicht weiß kann daran aber auch schnell verzweifeln. ;) > "Dokumentiert" ist dieser Krampf natürlich im "Hilfe- und Supportcenter" Immerhin dokumentiert. > Und einen Weg, den ganzen unnötigen Müll im Explorer auszublenden Ich hänge an der alten zwei-Fenster-Technik eines FreeCommander oder bisweilen auch Total Commander. Explorer nur wenn es sein muss, z.B. für den Zugriff aufs (pöse) Nokia Handy. Das Laufwerk für die USB-Verb. zeigt sich nur im Explorer. > Natürlich ist das Haupteinfallstor für Trottelviren bei Windows > immer noch weit geöffnet: Das Ausblenden der Dateinamenerweiterungen > bei "bekannten" Dateien. Selbst schuld, wer das nicht als erstes (nach der OS-Installation) ändert. Aber ich kenne auch Spezies, die mit dem "mehr an Info" sich eher latent überfordert zeigen (man glaubt das nicht, bis man es mal selbst miterlebt hat :)). Bitte immer dran denken, es gibt Leute, die sich einen Computer zulegen, um ihn für wenige spezielle Aufgaben MAL ZU NUTZEN, aber ansonsten keine Zeit oder kein Interesse haben (oder beides) sich ein wenig mit ihrem PC zu befassen (sind meist nicht die Allerjüngsten - manchmal aber sobar auch junge Studentinnen ;)). > Diese Firma setzt grenzdebile "Designer" ein. Wiviel "Debilität" steckt denn in dem der das KDE-4 Startmenü erfunden hat? Udo Schmitt (urschmitt) schrieb: agp schrieb: >> Aber genau DIESE Klickerei brauche ich doch >> unter W7 gar nicht mehr. Früher musste man sich anstrengen um z.B. zum >> Gerätemenager zu gelangen. Unter W7 genügt es in der Startzeile ein >> "gerä" einzugeben und schon wird mir als zweiter Eintrag >> "Geräte-Manager" angeboten. > Juchu, jetzt wird immer besser. Aber sicher. > Es ist also ein Fortschritt, wenn ich ein mehr oder weniger kryptisches > Kommando Ab hier lese ich nicht mehr weiter, denn die Vokabel die du hier verwendest, hat nicht mal im entfernstesten etwas mit dem zu tun worüber ich schrieb. Schlag mal nach was Kryptologie ist! Du kannst aber gerne auch die Wörter vollständig ausschreiben (im W7 Startmenü), wenn du einen bedarf dafür siehst. Ich sehen diesen jedenfalls nicht. Ich glaube wir beenden diese jetzt langweilig werdende Diskussion mal an dieser Stelle. Es macht nänlich keinen Sinn mehr und der TO wird seine Entscheidung längst getroffen haben.
Warum schlagen hier noch Leute .NET vor? MS selber schiebt das doch so langsam wieder ab... Mit Windows8 kommt dann eher HTML5 + Javascript statt .NET, weil muss ja alles Web und Cloud und facebook werden... http://www.heise.de/developer/artikel/Windows-8-HTML5-und-die-Folgen-fuer-NET-1267153.html Also gleich auf Webapplikationen setzen (mit Framework, z.B. qooxdoo, welches ironischerweise stark von der QT inspiriert wurde), und das Backend geht dann wieder in einer beliebigen Sprache, SOAP oder JSON-RPC gibts ja wirklich für alles und jeden..
HTML5 schrieb: > Also gleich auf Webapplikationen setzen (mit Framework, z.B. qooxdoo, > welches ironischerweise stark von der QT inspiriert wurde), und das > Backend geht dann wieder in einer beliebigen Sprache, SOAP oder JSON-RPC > gibts ja wirklich für alles und jeden.. Hey, juchuu. Das ist ein großer Teil dessen, was man gemeinhin unter Unix-Philosophie verfasst: Einfache Tools mit klaren Schnittstellen. Die GUI kann man immernoch drumherum bauen. Aber das geht halt nicht, wenn man Kernfunktionalität schon von vornherein mit Klickibunti mischt und verpackt. Aus einem Konsolenprogramm ein GUI zu machen, ist einfach. Macht z.B. K3B eindrucksvoll. Aber umgekehrt, also ein Klickibunti zu automatisieren, ist einfach katastrophal.
Sven P. schrieb: > Unix-Philosophie Psst. Nicht so laut. Sonst überlegt sich Microsoft das noch anders, und macht die Win32 API per Javascript-Funktionsaufruf im Browser verfügbar.
Sven P. schrieb: > Hey, juchuu. Das ist ein großer Teil dessen, was man gemeinhin unter > Unix-Philosophie verfasst: Einfache Tools mit klaren Schnittstellen. Die > GUI kann man immernoch drumherum bauen. so toll ist das aber auch nicht. Wenn man eine CD Brennen will braucht man 2 Tools. Eines was ein Iso erzeugt, das andere was ein ISO auf CD-Brennen kann. Das ganze ist langsam und braucht "viel" Platz auf der Platte. Wie kann ich den einen Benuzter unter linux anlegen? Wo ist dann dafür die API? Ach die gibt es gar nicht. Das muss ich also ein fremdes Programm nutzen hoffen das sich die Parameter in der nächsten zeit nicht ändern, die ausgaben von dem programm Parsen dabei noch die Sprache berücksichtigen weil die ausgaben auf jedem System anders sein können. Da finde doch eine API (wie schlecht auch immer) mit definierten Parametern und definierten fehlercodes wesentlich besser.
Peter II schrieb: > so toll ist das aber auch nicht. Wenn man eine CD Brennen will braucht > man 2 Tools. Und kann beide austauschen, wenn sie nicht gefallen. > Eines was ein Iso erzeugt, das andere was ein ISO auf > CD-Brennen kann. > Das ganze ist langsam und braucht "viel" Platz auf der > Platte. Das ist Käse. Die Tools sind winzig, Updates gehen daher schnell. Klar, das Image muss erst gebaut werden. Das machen aber alle Brennprogramme, die sich nicht darauf verlassen wollen, die Daten anderweitig schnell genug hinterhergeschaufelt zu kriegen. Man kann so ein Image auch on-the-fly durchreichen (pipe) oder in eine Ramdisk schreiben. Vorallem hat man bei einem Image aber nachher etwas zum Verifizieren, sofern sich die Daten auf der Festplatte ungewollt ändern. > Wie kann ich den einen Benuzter unter linux anlegen? Du mit useradd. > Wo ist dann dafür > die API? Lesen: IEEE Std 1003.1, Volumn XSH: endpwent, getpwent, setpwent - user database functions Schreibroutinen sind u.a. auch in SVID spezifiziert. > Da finde doch eine API (wie schlecht auch immer) mit definierten > Parametern und definierten fehlercodes wesentlich besser. Hast du ja. Gescheite Programme steuert man auch nicht über E/A, sondern über Kommandozeilenargumente. Die haben dann meistens auch einen Schalter, um leicht zu parsende Ausgaben zu erzeugen. Die meisten einfachen System-Tools unter Linux sind 'nur' Frontends zu irgendwelchen Tools, die wiederum Frontends zu APIs sind.
Sven P. schrieb: > Lesen: > IEEE Std 1003.1, Volumn XSH: > endpwent, getpwent, setpwent - user database functions das ganze ist aber nur für passwd, es gibt seit langen eine zwischenschicht PAM. Wie lege ich denn einem LADP nutzern über diese schnittelle an?
Peter II schrieb: > Wenn man eine CD Brennen will braucht > man 2 Tools. Eines was ein Iso erzeugt, das andere was ein ISO auf > CD-Brennen kann. Kein Nachteil. Dank Multitasking können beide Tools (und die GUI) gleichzeitig laufen. > Das ganze ist langsam und braucht "viel" Platz auf der > Platte. Dank Pipes braucht's auch keinen Zwischenspeicher für das ISO, das geht "on-the-fly". Außer natürlich du willst mehrere Kopien oder einen Verify-Lauf. Peter II schrieb: > Wie kann ich den einen Benuzter unter linux anlegen? Wo ist dann dafür > die API? Ach die gibt es gar nicht. Natürlich gibts die API dafür. "useradd". Ist aber M.W. nicht standardisiert, obwohl seit Jahrzehnten die API (== Parameter) kompatibel geblieben sind. Peter II schrieb: > die ausgaben von dem programm Parsen dabei noch die Sprache > berücksichtigen weil die ausgaben auf jedem System anders sein können. Deshalb haben GUI-Prädestinierte Tools oft einen speziellen, leichter zu parsenden GUI-Modus (Vorteil von OSS: Den kannst du auch selber nachrüsten). Und du kannst jedem Backend-Programm einfach die Lokalisierung abdrehen (LC_ALL=C), so dass du immer die unübersetzten Meldungen zum Parsen hast.
> Warum schlagen hier noch Leute .NET vor? MS selber schiebt das doch so > langsam wieder ab... > Mit Windows8 kommt dann eher HTML5 + Javascript statt .NET, weil muss ja > alles Web und Cloud und facebook werden... Dann wäre man aber mit dem Gespann C++/QT auch nicht besser dran, zumal das Papier die Frage aufwirft, ob funktional-orientierte Skriptsprachen womöglich Vorteile gegenüber objekt-orientierten Programmiersprachen (wie C# und C++ es sind) Vorteile haben. Außerdem hast du den Satz wohl überlesen "Sicherlich wird JavaScript auf absehbare Zeit dennoch nicht dazu führen, dass C# an Popularität einbüßt. JavaScript wird jedoch eine zunehmend wichtiger werdende Ergänzung zu C# werden." MS wird wohl künftig mehr auf Javasrkipt und HTML 5 setzen, aber dabei sicherlich in absehbarer Zeit nicht .NET "abschaffen". MS wird C# im Gegenteil erweitern und wenn man ansieht wie lange die Win32-API schon besteht (und noch immer nutzbar ist) braucht man da keine Bedenken haben. Außerdem wer gibt den Leuten denn die Gewissheit, dass das QT Framework noch auf Jahre weiter für Windows gepflegt und ausgebaut wird?
Das Leute scheinbar freiwillig JavaScript nutzen wollen ist mir ein Rätsel ;D
Da ich vor einiger Zeit genau vor dem gleichen Problem stand und genau die gleichen Anforderungen wie du hatte: Fang einfach mal mit C# an. Das ist eine einfache aber dennoch leistungsfähige Sprache mit der du sehr einfach GUIs unter Windows erstellen kannst. Das Nonplusultra an Geschwindigkeit ist es nicht. Das .NET Framework ist auf aktuellen Systemen sowieso installiert und wenn nicht installiert mans halt. Das Problem ist, dass jede Programmiersprache so ihre Vor- und Nachteile hat. Früher oder später wirst du dir sowieso weitere Sprachen aneignen und dich in neue Konzepte usw. einarbeiten. Von daher kannst du mit dem anfangen, was dir am meisten erfolg verspricht. Mit den gewonnenen Erfahrungen kannst du dann an neue Dinge herangehen. Bei mir steht auch C++, Java und Python auf dem Programmplan. Danach Qt, damit gehts dann an die embedded Programmierung :-) Zusätzliches Wissen schadet nie!
Sehe ich genauso. C# für den Hausgebrauch ist deutlich einfacher zu erlernen als C++ und Java (in all seinen Varianten). Vorhanden ist es meistens auch schon (so man MS-gepestet ist) oder läßt sich simpel und schmal auf Linux per Mono nachinstallieren. Selbst wenn MS demnächst von .Net ablassen sollte: Wie will man denn mit HTML5 und JavaScript derzeit ansatzweise ähnlich komfortabel eine komplette Anwendung entwickeln? Eine GUI hinzuclicken ist eines, der Rest eines Programmes aber was anderes. Und da bietet .Net mit der (möglichen) Trennung von GUI und eigentlicher Anwendung doch schon was doll feines. Vielleicht läuft ja aber in Zukunft alles auf spezialisierte Modulentwickler hinaus: Einer entwickelt nur Buttons, der andere EventHandler etc. ... Kurzum: Derzeit würde ich (-> nehme ich) C# für alles PC-seitige nehmen. Für hardwarenahe Sachen dann C.
Arc Net schrieb: > Schonmal die Abhängigkeiten von Firefox, OpenOffice, Ruby oder anderer > Sachen auf *nix-Systemen angesehen... https://www.archlinux.org/packages/extra/i686/firefox/ Oh wunder, fast keine Abhängigkeit ist firefox-spezifisch. Ein Großteil kann man auf einem gewöhnlichen Desktop-System als 'Ehda' auffassen.
>Nimm c# das passt schon und die Anwendung sieht 'modern' aus. >Aber wenn das DEINE Firma wäre, dann würdest DU alles "offenlegen"? Bei .Net sehe ich den 'Haken', dass das Program faktisch im Quellcode ausgeliefert wird!!! Mir scheint, dass manchen .Net-Benutzern dieser Umstand nicht bewusst ist.
Lösung: Softwarepatent und die verklagen, die ähnliche Programme veröffentlichen. Das holt auf kürzeste Zeit die Kosten für das Patent wieder raus ;-)
MCUA schrieb: >>Nimm c# das passt schon und die Anwendung sieht 'modern' aus. > >>Aber wenn das DEINE Firma wäre, dann würdest DU alles "offenlegen"? > > Bei .Net sehe ich den 'Haken', dass das Program faktisch im Quellcode > ausgeliefert wird!!! > Mir scheint, dass manchen .Net-Benutzern dieser Umstand nicht bewusst > ist. Bewusst? K.A. Zumindest wird/wurde Dotfuscator beim VS mitgeliefert (normal nur die Community-Edition, für WP7 eine bessere). Das Problem haben aber genauso alle Java, Javascript (auch Qt wenn sie QML/QtQuick nutzen), Ruby, Python etc. Nutzer. Und wenn man sich aktuelle Decompiler ansieht, auch "normale" C und C++Programmierer... z.B. "A Refined Decompiler to Generate C Code with High Readability", WCRE 2010 (die dort erwähnten Decompiler Hex-Rays und Boomerang sind für vieles schon ausreichend) http://cmacs.cs.cmu.edu/seminars/slides/qi.pdf
> Bei .Net sehe ich den 'Haken', dass das Program faktisch > im Quellcode ausgeliefert wird!!! Der einzige Grund, dieses nicht tun zu wollen, bestünde darin, daß es einem total peinlich wäre, wenn andere Leute sehen, was man für einen Murks zusammenprogrammiert hat, in dem es vor Fehlern und umständlichen Konstrukten nur so wimmelt, oder bei dem man 90% des Codes gnadenlos von anderen abgeschreiben hat. Für ein Richtiges Programm ist solche kindermässige Furcht vor angeblichen anderen Dieben komplett überflüssig, denn ein Gutes Programm lebt vom Supoprt, lebt von der Komplexität, lebt von der jahrelangen Erfahrung des Herstellers, die jemand anderes selbst wenn er wollte und selbst wenn er gross ist, so schnell nicht so einfach durch lesen des Quelltextes übernehmen könnte. Es sind die Guttenbergs, die vor Einblicken in die eigenen Quellen Angst haben. Also schäm dich, und kriech zurück in dein Loch. Wenn es mir wirklich wichtig ist, bekomme ich auch aus einem EXE den Quelltext eines C-Programms (ohne Kommentare und Originalnamen), zu einem Bruchteil des Preises, den es mich kosten würde, ihn zu verstehen.
>> Bei .Net sehe ich den 'Haken', dass das Program faktisch im Quellcode >> ausgeliefert wird!!! >Zumindest wird/wurde Dotfuscator beim VS mitgeliefert Diese Verschleierung ist letzlich wirkungslos. >Und wenn man sich aktuelle Decompiler ansieht, auch "normale" C und >C++Programmierer... Ob die aus dem generierten ASM den compl. Quellcode erzeugen können? >> Bei .Net sehe ich den 'Haken', dass das Program faktisch >> im Quellcode ausgeliefert wird!!! >Der einzige Grund, dieses nicht tun zu wollen, >bestünde darin, daß es einem total peinlich wäre, >wenn andere Leute sehen, was man für einen Murks zusammenprogrammiert >hat, in dem es vor Fehlern und umständlichen Konstrukten nur so wimmelt, >oder bei dem man 90% des Codes gnadenlos von anderen abgeschreiben hat. Blödsinn! Guter effiz. Code, der mit viel Aufwand erstellt ist, will man gerade nicht preisgeben. Und wenn doch, dann wird ihn eine Firma teuer verkaufen wollen, was geradezu heisst, dass er nicht öffentlich überall rumliegen soll. (Gut, bei machen Anwendungen ist es vielleicht egal, weil die eh keinen interessieren) >Es sind die Guttenbergs, die vor Einblicken in die eigenen Quellen Angst >haben. Blödsinn! Vielleicht (oder wahrscheinlich) will ein Guttenberg seine geklaute Ware vor Einblicken schützen. Aber nicht jeder, der vor Einblicken schützen will, hat geklaute Ware. Oder hat CocaCola das Rezept auch geklaut? >Also schäm dich, und kriech zurück in dein Loch. Blödsinn!
> Aber nicht jeder, der vor Einblicken schützen will, hat geklaute Ware. So lange nicht das Gegenteil beweisen wird, können wir das aber annehmen. > Oder hat CocaCola das Rezept auch geklaut? http://de.wikipedia.org/wiki/Vin_Mariani > Guter effiz. Code, der mit viel Aufwand erstellt ist, > will man gerade nicht preisgeben. Selbstüberheblichkeit. Daß du dazu lange gebraucht hast, sagt nichts über die Gutheit aus.
>> Aber nicht jeder, der vor Einblicken schützen will, hat geklaute Ware. > So lange nicht das Gegenteil beweisen wird, können wir das aber annehmen. (es heisst bewiesen, nicht beweisen) Lachhaft! Würde ja bedeuten, dass jede Firma, mit spezieller Software (oder spez. Algorithmen) die mit viel Aufwand erstellt worden ist, alles complett offen legen muss. Blödsinn. Man versuche mal von Xilinx den Algorithm. des Bitstreams zu bekommen. > Oder hat CocaCola das Rezept auch geklaut? Oder hat Angelo Mariani das Rezept auch geklaut? >Selbstüberheblichkeit. Nein. Ich wills einfach nur gegen Klau schützen, sonst nichts. (Dafür gibts auch die Fuses in uC's, die (fast) jeder nutzt)
MCUA schrieb: >>> Aber nicht jeder, der vor Einblicken schützen will, hat geklaute Ware. >> So lange nicht das Gegenteil beweisen wird, können wir das aber annehmen. > (es heisst bewiesen, nicht beweisen) > Lachhaft! > Würde ja bedeuten, dass jede Firma, mit spezieller Software (oder spez. > Algorithmen) die mit viel Aufwand erstellt worden ist, alles complett > offen legen muss. Blödsinn. Warum? Wenn es so wichtig ist, packt man das eben in eine native Lib/DLL und fertig, keiner wird gezwungen alles offen zu legen. > Man versuche mal von Xilinx den Algorithm. des Bitstreams zu bekommen. Nicht von Xilinx, ansonsten... http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/df171d4b06078600 und wenn's ein ASIC ist nimmt man Leute die auch das "zerlegen" http://www.chipworks.com/en/technical-competitive-analysis/resources/technology-blog >>Selbstüberheblichkeit. > Nein. Ich wills einfach nur gegen Klau schützen, sonst nichts. Günstige Tools ~5 DM für Palm's wurden Anfang der 2000er gecrackt, davor war es bei div. Shareware üblich, dass man diese irgendwo gecrackt im Netz finden konnte, selbst absolute Nischenprogrammen. Wenn's jemanden interessiert wird es gecrackt und analysiert, um an die Algorithmen zu kommen. Wie oben schon gesagt: Probier die erhältlichen Tools (Hex-Rays, Boomerang) einfach aus.
>Warum? Wenn es so wichtig ist, packt man das eben in eine native Lib/DLL >und fertig, keiner wird gezwungen alles offen zu legen. Sag ich ja. (Aber mit .net geht das nicht) >>Man versuche mal von Xilinx den Algorithm. des Bitstreams zu bekommen. >Nicht von Xilinx, ansonsten... >http://groups.google.com/group/comp.arch.fpga/brow... Wenn das den Xilinx Bitstream 'knackt', wird Xilinx im Dreieck springen! >und wenn's ein ASIC ist nimmt man Leute die auch das "zerlegen" >http://www.chipworks.com/en/technical-competitive-... Ja. "zerlegen" kann man alles. Die Frage ist, wieviel es kostet, bzw ob sich das jemand antun will (oder kann). Man muss es dem Spion ja nicht noch extra leicht machen. (Die DDR hatte auch Intel-(CPU)Chips "zerlegen" wollen, bis sie irgentwan doch nicht mehr weiter gekommen sind) >Wenn's jemanden interessiert wird es gecrackt und analysiert, um an die >Algorithmen zu kommen. Ja. Und bei ASM (oder das vom Compiler erzeugte ASM (*)) ist das ungleich schwerer, als wenn man auf höherer Ebene schon Quellen einsehen kann. (*)Da gibts nachtürlich auch Unterschiede. Vielleicht kann man bei dem Einen eher verschiedene Quell-Möglichkeiten vermuten als bei einem Anderen.
MCUA (Gast) schrieb: >> Warum? Wenn es so wichtig ist, packt man das eben in eine native Lib/DLL >> und fertig, keiner wird gezwungen alles offen zu legen. > Sag ich ja. (Aber mit .net geht das nicht) Doch natürlich geht das. Gerade .NET ist in dieser Hinsicht äußert flexibel. Du kannst jeglichen unmanaged Code in dein .NET Programm einbinden und darauf zugreifen. Pack deinen bewahrenswerten "Superalgorithmus" also einfach in eine DLL, binde sie unter .NET ein und fertig.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.