C/C++ (MFC) vs. C# .net

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.

Nimm C#. Als erfahrener C++ Programmierer wirst du dran sehr viel Spaß 
haben.

CLI soll auch sehr schön sein...

> 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 (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.

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...

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:
> 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.

So kann man dem eigentlich nur zustimmen, würd ich meinen.

wieso schreibst du nicht deine Programme nicht in Python?

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).

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...

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

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?

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

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.

>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.

> 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)

>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.