mikrocontroller.net

Forum: PC-Programmierung PC Programme in C erstellen


Autor: Juppo Nini (juppo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo

Ich programmiere seit jahren embedded C für 8051 oder Atmega usw.

Nun suche ich eine einfache "C" Programmier umgebung mit der ich kleine 
test programme auf windows rechner grafisch darstellen kann.

senden von strings über serielle ,empfangen  bmp hinterlegen usw.

In welches "C" Programmiersystem kann man sich am schnellsten 
einarbeiten?

Gruß Juppo

Autor: Maximilian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich verstehe die Frage nicht! du programmierst schon in C bzw C-Ansi 
bestimmt C99 oder so.

Ok Embedded-C ist halt Microcontroller orientiert aber zu 90% ist es C.

welche Anwung willst unter einem PC mit C programmieren?

in Zeiten wo GUIs gibt und programme wie Visual C++, C#, VB etc..
warum muss du unbedingt in C programmieren? wer programmiert heutzutage 
ein Button, oder ein Fenster?

C und Assembler können ruhig die Sprache der Micorcontroller bleiben, 
dann muss du über Seriell ein Port ansprechen und deine Anwendung unter 
Windows testen.

Das Testprogramm kannst du aber mit anderen Sprache und IDE 
programmieren.

Ich hoffe, ich habe richtig verstanden was du gefragst hast

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In welches "C" Programmiersystem kann man sich am schnellsten
> einarbeiten?
.NET & C#
Wenn du die objektorientierten "Erweiterungen" ignorierst und "nur" C 
proggst, könnte es nahezu klappen.

Allerdings möchte ich die OO eigentlich nicht mehr bei PC-Programmen 
missen. Ob C# das richtige ist, möchte ich hier nicht weiter vertiefen.
Jedenfalls bist du was GUI & Schnittstelle betrifft extrem flott wenn du 
.NET verwendest.

Ralf

Autor: Juppo Nini (juppo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh da habe ich mal wieder unverständlich gegeben.
(sagt meine Frau auch immer)

Also c syntax kenne ich.(µp Programmierung)

Des wegen möcht ich be c bleiben.

Objekt objektorientierten soll natürlich sein.

Ich weiß nur nicht welches system ich nehmen soll ohne das nach ein 
Woche einarbeitung alles mumpiets ist .

gruß juppo

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juppo Nini schrieb:
> Ich weiß nur nicht welches system ich nehmen soll ohne das nach ein
> Woche einarbeitung alles mumpiets ist .

wenn du dich eh in eine GUI einarbeiten muss, dann ist kannst du dich 
auch gleich mit einer anderen sprache beschäftigen.

Auch von mir die Empfehlung: C# - lade dir kostenlos 
http://www.icsharpcode.net/opensource/sd/ runter und teste mal einen 
tag. Viele dinge geht in .net viel einfacher als mit C/C++ und die Zeit 
die man damit spart kann man auch in eine neue Sprache investieren.

Autor: ole (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie immer: Nimm etwas mit Zukunft. Es gibt so viele tolle 
UI-Bibliotheken, die portabel und ANSI-C oder C++-konform sind, da 
brauchst du dir C# oder .NET nicht anzutun, wenn du ohnehin schon C 
sprichst.

Schnell fertig bist du z.B. mit GTK, das dürfte dir recht weit 
entgegenkommen: Da du ja Datenblatt-lesen gewohnt bist, beginnst du mit 
einem kurzen Tutorial und hüpfst dann direkt in die Bibliotheksreferenz.

Autor: Juppo Nini (juppo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GTK habe ich sogar auf meinen Rechner

OK da habe ich schon nmal einen Anfang.
Den Besten ..


Gruß Juppo

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich empfehle Qt. Ist zwar C++, aber das sollte kein Problem sein.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juppo Nini schrieb:
> Des wegen möcht ich be c bleiben.
>
> Objekt objektorientierten soll natürlich sein.

Das widerspricht sich aber, du musst dich schon entscheiden.


C++ ist schneller als c# (so langsam ist c# aber auch nicht). In c++ ist 
aber noch das Problem, dass man ziemlich einfach einen schwerwiegenden 
Fehler begeht. In c# findest man fast alle Fehler sofort. Dazu hast du 
mit .Net eine riesig umfangreiche Bibliothek mit allen möglichen Sachen 
drin. 99.99% wirst du wahrscheinlich nie benutzen.

Ich empfehle dir auch mal c# zu testen. Die Syntax entspricht fast der 
von c++ und diese minimalen Änderungen sagt dir der Compiler.

Was ich an c# auch sehr gut finde ist, dass man keine Header-Dateien 
braucht. Die Funktionen fischt sich der Compiler selbst heraus.


PS: Ich persönlich finde MS VS C# besser als Sharpdevelop, ist aber 
(denke ich) geschmackssache. Hier nochmal beide Links:

Sharpdevelop: http://www.icsharpcode.net/opensource/sd/
MS VS C# EE: http://www.microsoft.com/express/Downloads/#2010-Visual-CS


Sven P. schrieb:
> Wie immer: Nimm etwas mit Zukunft. Es gibt so viele tolle
> UI-Bibliotheken, die portabel und ANSI-C oder C++-konform sind, da
> brauchst du dir C# oder .NET nicht anzutun, wenn du ohnehin schon C
> sprichst.

Auf die Gefahr hin, dass wieder ein .NET Streit ausbricht: Welche tolle 
Bibliothek bietet denn diesen Umfang?

Autor: b00n (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

interessiere mich grade auch für das Thema.

Zu meinem Stand:

Grundlagen ANSI-C
Grundlagen Basic (u.a. für Excel VBA)


Mein Dilemma:

Ich würde eigentlich meine C Kentnisse vertiefen wollen, als z.B. auch 
kleine Programme für den PC schreiben.

Andererseits sind Makros in Excel eine feine Sache, was man ja mit .NET 
und VB ebenfalls weiter ausbauen kann.

Nun was macht mehr Sinn:

a) C, C++(.NET) und Excel VBA
b) C, VB(.NET) und Excel VBA

Die Frage ist ja auch, was sich mehr gleicht, C und C++ oder VB und VBA. 
Wobei ich eher vermute das Basic sicher ähnelt.

Vielen Dank für Feedback.

Und um mein Lieblingshaßwort für 2010/2011 zu nutzen:

"ich muss ja beim erlernen der Sprachen auch an die NACHHALTIGKEIT 
denken"

:)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du Nachhaltigkeit willst UND auf dem PC unter Windows bleiben 
willst UND du hauptsächlich GUI-lastige Dinge machen willst, DANN würde 
ich (obwohl eingefleischter C++ Fan) zu entweder C# oder VB raten.

In der Zeit, in der du dir in VB oder C# deine Oberfläche 
zusammengeklickt hast, hast du in C++ noch nichts erledigt. Muss man 
leider so sagen.

Von dem Zeugs, das MS als 'managed C++' bezeichnet würde ich aus 
tiefstem Herzen abraten. Das macht keinen wirklichen Sinn und soll nur 
den C++ Leuten den Umstieg auf C# versüssen.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Das widerspricht sich aber, du musst dich schon entscheiden.

Nein, mit GObject wurde C Objektorientierung aufgepfropft. GTK macht 
davon Gebrauch.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
b00n schrieb:
> C, C++(.NET) und Excel VBA
> C, VB(.NET) und Excel VBA

also  C++(.NET) ist nichts halbes und nicht ganzes,  VB(.NET) ist ok 
wenn man vorher Basic gemacht hat. Aber das "echte" .net ist nun mal c#.

Autor: b00n (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also würde ich auf Variante a gehen:

c, vba und vb.net.

Danke!

Jetzt noch wahrscheinlich eine Saublöde Idee...
Sollte man dann C gleich ganz fallen lassen und die Mikrocontroller mit 
Basic programmieren?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
b00n schrieb:
> Sollte man dann C gleich ganz fallen lassen und die Mikrocontroller mit
> Basic programmieren?
NEIN, ich denke das hier (fast) alle der Meinung sind das ein schritt 
von C auf Basrom für einen µC der falsche weg ist.

Teste einfach mal C#, danach kann man sich erst eine Meinung bilden. 
VB.net finde ich nicht sehr gut, es entspricht nicht der üblichen 
Programmierung. Ich finde die umstellung von VB auf C oder C# immer als 
schwer. C# und C(++) sind sich dagegen vomn Synteax her sehr ähnlich.

Autor: Fer T. (fer_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C# mit dem Net Geraffel?
Das führt nur auf düstere Wege...
Warum nicht einfach wenn doch schon vorhanden, C Proggen mit GTK 
Anbindung?
Einfach zu lernen, wenn man schon C kann, Programme sind Ressourcen 
schonend und schnell (im Gegensatz zu dem NET Geraffel).
Dazu kann man wenn benötigt, es sehr schnell noch auf andere Systeme 
Portionieren...

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
b00n schrieb:
> also würde ich auf Variante a gehen:
>
> c, vba und vb.net.
>
> Danke!
>
> Jetzt noch wahrscheinlich eine Saublöde Idee...
> Sollte man dann C gleich ganz fallen lassen und die Mikrocontroller mit
> Basic programmieren?

Wer möchte kann die größeren auch in C# programmieren:
http://www.microsoft.com/netmf/default.mspx
http://www.netduino.com/projects/

VB eventuell
http://www.christec.co.nz/blog/archives/category/n...

p.s. bevor das Thema wieder kommt: das .NET Micro Framework gibt's 
vollständig im Quellcode unter der Apache 2.0 Lizenz.

Autor: Fer T. (fer_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uCs in Basic Programmieren oder gar VB?
gerade bei den uCs würde ich das NIE tun, weil es gerade hier auf 
Performance ankommt, und das geht halt wegen der Hardware nähe fast 
ausschließlich mit C oder Assembler...

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fer T. schrieb:
> Warum nicht einfach wenn doch schon vorhanden, C Proggen mit GTK
> Anbindung?
weil C zwar schön und gut ist, aber selber leider sogut wie nichts 
mitliefert. Nicht mal eine zeitgemäße String-Verarbeitung. Bei Sprachen 
wie C# oder auch Java ist der große Vorteil das man sogut wie keine 
externen Sachen braucht.

Mache doch mal mit C ein Gui die von einer SSL Webseite eine Image lädt 
und den MD5 Hash prüft und das Bild invertiert speichert. Man braucht ja 
nur Openssl, GTK und irgendeine http lib und libjpeg. (klar kann man 
auch alles selber machen).

In C# ist alles schon dabei. Es ist zwar etwas langsamer und brauch 
vermutlich etwas mehr resourcen aber dafür ist die Entwicklungszeit 
wesentlich kleiner und auch weniger fehleranfällig. Die Eigentliche exe 
ist vermutlich sogar kleiner als bei C (klar braucht man die .net 
Laufzeitumgebung)

Und die C# version ist mit etwas übung in einer Stunde fertig. Für die C 
version hätte ich in der zeit nicht mal alle externen libs übersetzt.

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fer T. (fer_t) schrieb:

> C# mit dem Net Geraffel?
> Das führt nur auf düstere Wege...

Unfug! Das ist wie Karl-Heinz Buchegger schon schrieb der beste Weg 
schlecht hin für Leute die "unter Windows bleiben" möchten. Das 
Framework ist sehr umfangreich, der Einsteig ist nicht schwer und es 
gibt viel gute Literatur sowie Programmbeispiele.

Windows Programme lassen sich auch mit purem C (ganz ohne 
Objekt-orientierten Code) unter der Nutzung der Win32-API schreiben. Das 
ist nicht mal schwer, wenn man mal den hier 
http://www.charlespetzold.com/pw5/index.html durchgearbeitet hat. Für 
den ein- oder anderen zu altbacken (Petzold ist inzwischen auch zu C# 
"übergelaufen" siehe http://www.charlespetzold.com/books.html), 
funktioniert aber noch immer und die Programme sind schön schnell (was 
bei kleinen Programmen und heutiger Rechenleistung aber kaum mehr eine 
Rolle spielt). Für Leute die mit dem Erstellen von Klassen mittels 
Frameworks wie MFC auf Kriegsfuß stehen (warum auch immer) ist das aber 
eine Möglichkeit sich davor zu drücken und dennoch Windows Programme, ob 
Konsole oder vollständiges Fenster oder einfach alles in einen Dialog 
gepackt, ;) zu schreiben. Einfach ausprobieren. Eine kleine aber feine 
GUI neben den Platzhirschen Visual .. gibt es auch z.B. hier 
http://www.smorgasbordet.com/pellesc/

Merke: Das beste Programm ist immer das mit dem man selbst am besten 
zurecht kommt.

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Ich empfehle Qt. Ist zwar C++, aber das sollte kein Problem sein.

Sehe ich auch so und im gegensatz zu denn C# ist QT auch für Linux Mac 
und ggf. soagr auf einen embedded System verfügbar hat also zumindestens 
Theoretisch das Potenzial auf anderen Systemen als ein Windows Pc laufen 
(zugegeben nach einer neu Kompilierung)

Autor: hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt mal meine Meinung als jemand, der da auch grad im Lernprozess 
drinsteckt:

Die Originalfrage war ja nach einer Programmierumgebung. Für mich war es 
recht einfach, mich in CDT/Eclipse einzuarbeiten. Damit lassen sich C 
und C++ Anwendungen recht einfach erstellen. Zudem gibt's das für 
Windows und Linux, da kommst also in keine Sackgasse. Außerdem gibt's eh 
auch Eclipse-Versionen für viele Embedded-Systeme, so daß Du auch in der 
Richtung einen Nutzen daraus ziehen kannst wenn Du Dich einarbeitest.

Wenn Dir Textzeile reicht, dann hast Du jetzt schon gewonnen. Wenn Du 
aber wirklich Fensterchen und Mausklicken programmieren willst würde ich 
dann wie Imon auch zu Qt mit Qt Creator raten. Das liefert dann 
Fensters, Netzwerk, Dateizugriff und vieles mehr, weit mehr als GTK 
jedenfalls. Und es läuft auch auf Win, Linux und Mac. Und um das zu 
lernen gibt's von Blanchette/Summerfield ein recht gutes Buch. (Ohne 
Buch oder Lehrgang recht mühselig, da sich das Konzept nicht automatisch 
von selbst erschließt.)

Autor: P. M. (o-o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> C++ ist schneller als c# (so langsam ist c# aber auch nicht).

Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und 
was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert 
sich das?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P. M. schrieb:
>> C++ ist schneller als c# (so langsam ist c# aber auch nicht).
> Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und
> was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert
> sich das?

soetas kommt sehr oft von Leuten die noch die etwas mit .net gemacht 
haben. Ich war selber oft überrascht wie schnell .net ist. Ich konnte 
bis jetzt noch keine unterschied feststellen.
Ich warte auch mal gespannt auf eine Antwort.

Autor: Fer T. (fer_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> soetas kommt sehr oft von Leuten die noch die etwas mit .net gemacht
> haben. Ich war selber oft überrascht wie schnell .net ist. Ich konnte
> bis jetzt noch keine unterschied feststellen.
> Ich warte auch mal gespannt auf eine Antwort.

Dem kann bei dir so sein, es kommt da aber auf das verwendete System 
(OS, also XP, Vist, 7) an und auf deine Hardware...
Klar das man mit einem I7 oder Phenom II X8 nicht den Unterschied merkt, 
im Gegensatz (sehr radikal) zu einem Pentium IV oder Athlon.

Zu GTK und QT: Ich selber bin auch auf der QT Seite, aber hier wurde nur 
erwähnt das C Kenntnisse Vorhanden sind, da wollte ich nicht noch den 
Umstieg auf C++ Voraussetzten. Was aber auch ganz einfach ist, wenn man 
das System durchschaut hat.

Zu NET:
+ Sprachen dir Net Verwenden sind "einfach" mit viel Leistung 
(Aufwand/Leistung Verhältnis)

- Net ist nicht überall performat
- Net ist auf MS beschränkt
- Net ist nicht gerade User freundlich (Wenn der User nur ein NEt 
Programm Nutzen Will, muss er das Programm (z.B. 10Mb) Installieren und 
NET (ca. 300Mb oder hat sich da seit meinem letzten Gebrauch von Win was 
geändert?). Bei einem normalen C++ oder C Programm wären es dann z.b. 
nur insgesamt 50Mb)...

Ist halt Meinungssache...
MfG,

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fer T. schrieb:
> Programm Nutzen Will, muss er das Programm (z.B. 10Mb) Installieren und
> NET (ca. 300Mb oder hat sich da seit meinem letzten Gebrauch von Win was
> geändert?). Bei einem normalen C++ oder C Programm wären es dann z.b.
> nur insgesamt 50Mb)...

Wieso unterschlagt Ihr C/C++-Anhänger eigentlich immer, dass jeder 
Compiler seine eigene Version einer Runtime-Library mitbringt? Was dann 
auch bedeutet, dass jede Applikation ebenfalls mehrere MB an DLLs auf 
die Platte kopiert, die sich im IDEALFALL nicht gegenseitig in die Quere 
kommen. Mit dem .NET-Laufzeitumgebung hat MS da endlich einigermaßen in 
den Griff bekommen. Habe bei der Arbeit gerade wieder das Vergnügen, 
mich mit dem Scheiß rumzuplagen und nicht wirklich zu wissen, welche der 
tollen externen Bibliotheken da genau welche Runtime-Version benötigt...

Gruß
Markus

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Volz schrieb:
> jeder Compiler

Sorry, ich muß mich korrigieren: "jede Compiler-VERSION" ist richtiger.

Gruß
Markus

Autor: hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Volz schrieb:
> Wieso unterschlagt Ihr C/C++-Anhänger eigentlich immer, dass jeder
> Compiler seine eigene Version einer Runtime-Library mitbringt? Was dann
> auch bedeutet, dass jede Applikation ebenfalls mehrere MB an DLLs auf
> die Platte kopiert ...

Das trifft auf .NET auch zu, es "wiegt" immerhin etwa 360MB. Nur ist es 
auf Windows-Rechnern meist schon drauf. Wird also bei "normalen" Heim- 
und Büro-PCs nicht so wahrgenommen. Interessant wird es immer ab dem 
Moment, wo man den Bereich des Standard-Windows-PC verlassen will. Also 
entweder Mini- und Micro-PCs oder auch Linux/Mac. Da ist dann die 
Energie, die man ins .NET-lernen gesteckt hat weitgehend wertlos. Man 
muß halt wissen, in welche Richtung man sich bewegen will.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Volz schrieb:
> Wieso unterschlagt Ihr C/C++-Anhänger eigentlich immer, dass jeder
> Compiler seine eigene Version einer Runtime-Library mitbringt?

Das unterschlagen "wir" gar nicht.

> Was dann
> auch bedeutet, dass jede Applikation ebenfalls mehrere MB an DLLs auf
> die Platte kopiert,

Niemand zwingt den Nutzer eines C/C++-Compilers, dieses 
Programmiermodell zu nutzen. Durch die Möglichkeit des /statischen 
Linkens/ entstehen monolithische .exe-Dateien, die (vom Betriebssystem 
selbst abgesehen) keinerlei weitere Laufzeitunterstützung benötigen. 
Solche Dateien muss man nicht "installieren", man muss keinen DLL-Müll 
irgendwohin kopieren, man hat keinerlei Versionskonflikte.

Klar, solche Programme sind etwas größer als welche, die sich auf das 
Vorhandensein einer Laufzeitumgebung verlassen, aber nicht ansatzweise 
so groß wie so eine typische Laufzeitumgebung.

Denn im Gegensatz zur vollständigen Laufzeitumgebung wird zu so einem 
statisch gelinkten Programm nur das hinzugefügt, was es auch tatsächlich 
nutzt. Was bei einem typischen schon etwas größeren MFC-Projekt* in 
einer Exe-File-Größe im unteren einstelligen MB-Bereich resultiert, 
während ein C-Programm schon ziemlich aufwendig sein muss, um mehr als 
nur ein paar hundert kB zu benötigen.

Und so ein Programm läuft überall, ohne Installation, ohne Updates, ohne 
Versionsblubber.

*) Ja, ich weiß, gräuslich. Aber MFC-Programm linken verdammt viel Zeug.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Und so ein Programm läuft überall, ohne Installation, ohne Updates, ohne
> Versionsblubber.

aber du muss schon mal 2 versionen veröffentlichen. 64Bit und 32bit - 
das Problem geht es bei .net schon mal nicht.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mag sein, aber die 32/64-Bit Problematik ist auch bei den "Profis" 
häufig anzutreffen. Übrigens würde ich nicht ausschließen, daß eine 
32-Bit Version auf einem 64-Bit System läuft.

Ansererseits gilt: Obwohl in der Open Source am manchen Stellen verpönt, 
ist das statische Linken unter Windows eine Tugend, und ich als Anwender 
bin jedesmal dankbar für ein Programm, das alles, was es braucht, 
mitbringt und nicht irgendeinen Blödsinn in "windows/system32" schreiben 
muß. Ansichtssache, aber trotzdem: Statisches Linken (zumindest unter 
Windows) erhöht die Zuverlässigkeit und vermeidet Versionskonflikte. Es 
verbessert auch die Performance - zugegeben marginal.

Um auf die ursprüngliche Frage zurückzukommen, eine kompakte und 
anfängerfreundliche Entwicklungsumgebung ist "Dev-C++". Man kann damit 
natürlich auch simples C programmieren, es liegt der MinGW-Compiler 
zugrunde. Die Oberfläche ist simpel und effizient, die erzeugten 
Programme klein und man ist nicht gezwungen, irgendwelche .dll-Dateien 
mitzuliefern.

Natürlich haben Frameworks ihren Reiz. Aber für mich ist .NET sowohl als 
Anwender (großer Installationsumfang, keineswegs überall vorhanden, 
gerade auf Rechnern ohne Internetanbindung) als auch als Programmierer 
(Cross-Platform muß eigentlich heute selbstverständlich sein, wenn man 
etwas in die Zukunft denkt) ein Reizthema.

Alles Ansichtssache, natürlich. Will hier keinen Streit vom Zaun 
brechen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Juppo Nini schrieb:
>> Des wegen möcht ich be c bleiben.
>>
>> Objekt objektorientierten soll natürlich sein.
>
> Das widerspricht sich aber, du musst dich schon entscheiden.
Nein, tut es nicht. Es ist nur für diejenigen ein Widerspruch, die OOP 
falsch verstanden haben. Der ganze 
Klassen-Vererbungs-Template-Interface-Wasserballon ist nur ein Teil von 
OOP. Ein eher zweitrangiger noch dazu.


> Sven P. schrieb:
>> Wie immer: Nimm etwas mit Zukunft. Es gibt so viele tolle
>> UI-Bibliotheken, die portabel und ANSI-C oder C++-konform sind, da
>> brauchst du dir C# oder .NET nicht anzutun, wenn du ohnehin schon C
>> sprichst.
>
> Auf die Gefahr hin, dass wieder ein .NET Streit ausbricht: Welche tolle
> Bibliothek bietet denn diesen Umfang?
Für was denn? Es gibt unzählige gute Bibliotheken für jeden noch so 
erdenklichen Zweck. Und allesamt können sie eine Sache, und die dafür 
dann richtig. Ich kann sogar als Entwickler entscheiden, was ich 
brauche, und muss nicht zwangsweise das Kollektiv kaufen.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P. M. schrieb:
> Samuel K. schrieb:
>> C++ ist schneller als c# (so langsam ist c# aber auch nicht).
>
> Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und
> was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert
> sich das?

Rein logisch betrachtet:

1.)
C++ --> Compiler, Linker --> Ausführbares Binary in der Maschinensprache 
des Prozessors.

2.)
C# und Java --> Compiler, Linker --> Bytecode --> Bytecode wird von der 
.NET Laufzeitumgebung bzw. von der Java Virtual Machine zur Laufzeit in 
die Maschinensprache des Prozessors übersetzt.

Da 2.) einen Verarbeitungsschritt mehr benötigt, ist es durchaus logisch 
anzunehmen, dass dies mehr Rechenzeit braucht. Freilich muss der 
Unterschied nicht groß sein. Trotzdem wird man, wenn es absolut auf das 
letzte bisschen an Performance ankommt, wohl eher diejenige Sprache 
verwenden die den geringeren Overhead hat. (also C ;-)

Dann gibt es auch noch Native Compiler, zumindest für Java :-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian schrieb:
> Ansererseits gilt: Obwohl in der Open Source am manchen Stellen verpönt,
> ist das statische Linken unter Windows eine Tugend, und ich als Anwender
> bin jedesmal dankbar für ein Programm, das alles, was es braucht,
> mitbringt und nicht irgendeinen Blödsinn in "windows/system32" schreiben
> muß.
Muss es ja nicht. Der dynamische Linker lässt sich ja mühelos jeden 
Bibliotheks-Klon unterschieben ;-)

> Ansichtssache, aber trotzdem: Statisches Linken (zumindest unter
> Windows) erhöht die Zuverlässigkeit
Nein, es erzeugt unnötige Redundanz. Wenn eine Bibliothek einen Fehler 
enthält, enthalten ihn 100 Programme. Wenn der Fehler behoben wird, sind 
100 Updates fällig... Dann doch lieber einmal zentral gepflegt, oder?

> und vermeidet Versionskonflikte.
Die gibt es ohnehin Hauptsächlich beim Windows-Linker. Unices/Linux 
haben das irgendwie anders in den Griff bekommen.

> Es
> verbessert auch die Performance - zugegeben marginal.
Ja und nein. Performance != Geschwindigkeit. Die Performance sackt 
rapide in den Keller, wenn der Arbeitsspeicher unnötig mit redundantem 
Code zugemüllt wird.


Mark Brandis:
Auch ja und nein. Der Zwischenschritt braucht gewiss Zeit, ja. Aber 
dafür kann der resultierende Programmtext effizienter sein, als das 
'fest verdrahtete' Äquivalent in C(++). Denk z.B. mal an Programmpfade 
in einem Algorithmus, die per JIT vollständig entfernt werden können, 
konventionell aber einen bedingten Sprung benötigen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> einen Verarbeitungsschritt mehr benötigt, ist es durchaus logisch
> anzunehmen, dass dies mehr Rechenzeit braucht. Freilich muss der
> Unterschied nicht groß sein. Trotzdem wird man, wenn es absolut auf das
> letzte bisschen an Performance ankommt, wohl eher diejenige Sprache
> verwenden die den geringeren Overhead hat.

dabei übersieht du aber ein paar feinheiten. In C kann es sehr schnell 
passieren das z.b. ein Objekt kopiert wird (String). In .net wird aber 
mit Referenzen gearbeitet. Damit entällt ein Kopiervorgang und das 
Programm wird schneller.
Dann kann ein Laufzeitsystem optimierungen abhängig von den Daten 
vornehmen was ein C Programm leider nicht kann.
Auch die Freigabe von Speicher erfolgt in C sofort - was auch etwas zeit 
kostet. In .NET erfolgt das ganze irgendwann. Damit kann die Rumtime den 
speicher dann Freigeben wenn das Programm z.b. auf ein IO wartet. Das 
das speicherverwaltung Zeit kostet sieht das es smartheap gibt. Wenn die 
Rumtime eine bessere speicherverwaltung hat das das C programm dann ist 
es schon schneller.

Man kann also auf keinen Fall sagen ein .net programm pauschal langsamer 
als ein C programm ist. Es werden sich für beide Fälle Beispiele finden 
lassen.

Autor: hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, wir sollten diese Perfomanc-Feinheiten lieber wieder 
beiseite lassen.

1. ging es in der Frage ja um eine Programmierumgebung bzw. auch IDE. So 
verstehe ich zumindest die Frage nach dem Programmiersystem. Und das 
vereint Sprache, eventuelle Toolkits und die IDE+Compiler.

2. können wir uns sicher darauf einigen, daß am Anfang die Performance 
das geringste Problem ist. Erlernbarkeit und Les-/Wartbarkeit des Codes 
sind weit wichtiger. Und im Laufe der Erfahrung kommt dann auch die 
Übersicht, mit der man sich dann die für die jeweilige Aufgabe passenden 
Mittel aussuchen kann.

Jeder erfahrene Programmierer sagt ja auch, der Zweck bestimmt die 
Mittel. Die Aufgabe ist hier ja: Erlernen von PC-Programmierung. 
Vorhanden ist: C-Kenntnisse. Meiner Meinung nach ist die wichtigste 
Frage jetzt noch: Windows only oder einer für alle?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
>> Ansichtssache, aber trotzdem: Statisches Linken (zumindest unter
>> Windows) erhöht die Zuverlässigkeit
> Nein, es erzeugt unnötige Redundanz. Wenn eine Bibliothek einen Fehler
> enthält, enthalten ihn 100 Programme. Wenn der Fehler behoben wird, sind
> 100 Updates fällig... Dann doch lieber einmal zentral gepflegt, oder?

Bei einem statisch gelinkten Programm ist der Fehler, wenn er aus einer 
der verwendeten Bibliotheken kommt, aber auch statisch. Das bedeutet, 
daß der Nutzer des statisch gelinkten Programmes sich darauf verlassen 
kann, daß ein Fehler eindeutig im Programm zu suchen ist, statt an der 
wie auch immer gepflegten Liste von Bibliotheken auf dem Zielsystem.

Der Entwickler muss sich bei einem Fehlerreport auch nicht damit 
beschäftigen, herauszufinden, wo in welcher Bibliothek, die auf dem 
Zielsystem in welcher Version auch immer vorhanden sein mag, das Problem 
liegen könnte, er muss sich nicht damit beschäftigen, in irgendwelchen 
Konfigurationen vorliegende Nebeneffekte auszuschließen.

Andererseits muss er Fehlerreports ernstnehmen und kann sich nicht mit 
einem schnodderigen "Der Kunde muss halt sein System auf aktuellem Stand 
halten, dafür ist er verantwortlich" herausreden.

Das "zentral gepflegte" Updateverfahren ist in der Theorie sicherlich 
ganz toll, aber in der Praxis kann es sehr unschöne Auswirkungen haben. 
Man nehme an, das eigentliche Programm nutzt eine Bibliotheksfunktion 
auf eine, sagen wir mal, vom Bibliotheksentwickler nicht vorgesehene Art 
und Weise. Bei Bibliotheksversion XY funktioniert das so, wie es sich 
der Entwickler des Programmes gedacht und gewünscht hat.

Nun kommt ein "zentral gepflegtes" Bibliotheksupdate, die 
Bibliotheksfunktion verhält sich etwas anders, und der ... sagen wir mal 
"Fehler" des die Bibliothek nutzenden Programmes kommt plötzlich zum 
Tragen, und die Funktionalität des Programmes ist dahin.

Wenn das Programm in diesem Falle statisch gelinkt wäre, würde es 
funktionieren.

Nun mag man diese Art von Vorgehensweise seitens des Entwicklers 
verdammen, aber wenn eine Bibliothek zum Zeitpunkt der Entwicklung eines 
Programmes eine bestimmte Funktionalität nur auf eine bestimmte, nicht 
ganz "offizielle" Art zu erreichende Art und Weise zur Verfügung stellt, 
dann gibt es --außer bei OSS-Bibliotheken-- wenig Möglichkeiten, anders 
vorzugehen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> [...]
Ist ja alles formal richtig, was du sagst.

Aber es führt weder zu zuverlässiger Software, noch ist es der Qualität 
des ganzen Systemes irgendwie dienlich, oder? Dagegen steigern 
Fehlerberichte an die Entwickler der Bibliothek mitunter die Qualität.

Aber selbst wenn ein Programm gegen eine spezielle Bibliothek linkt und 
sich auf das Verhalten verlässt: Bei ordentlicher Versionierung kracht 
es wenigstens nicht, dann bleibt halt eine alte Version neben der 
aktuellen Version -- das wäre beim statischen Binden ja ohnehin der 
Fall. Es macht die Sache, nämlich die Bibliothek zu missbrauchen, aber 
wiederum nicht besser.

Man verhindert dadurch ja nicht nur, dass es zu Fehlern kommt, weil man 
sich auf ein spezielles Verhalten verlässt. Man verhindert ja auch, dass 
'echte' Fehler behoben werden -- irgendwann geht das schief.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Aber es führt weder zu zuverlässiger Software, noch ist es der Qualität
> des ganzen Systemes irgendwie dienlich, oder? Dagegen steigern
> Fehlerberichte an die Entwickler der Bibliothek mitunter die Qualität.

Bei der Entwicklung unter OSS-Bedingungen gebe ich Dir da ganzheitlich 
recht.

Aber bei der Entwicklung unter Systemen wie Windows ist der Weg des 
"Fehlerberichts an die Entwickler der Bibliothek" oft ähnlich ergiebig, 
wie den Fehlerreport an eine Klotür zu malen.

Hier trennt sich Pragmatismus (den man unter Systemen wie Windows haben 
muss) und Einhaltung der hehren Lehre (was man sich unter 
OSS-Bedingungen leisten kann).

Autor: hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus und Sven:

Was also würdet ihr im konkreten Fall einem Anfänger (auch ich würde 
mich als fortgeschrittenen Anfägner bezeichnen) denn jetzt empfehlen?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hubert schrieb:
> @Rufus und Sven:
>
> Was also würdet ihr im konkreten Fall einem Anfänger (auch ich würde
> mich als fortgeschrittenen Anfägner bezeichnen) denn jetzt empfehlen?

Dir würde ich garnichts mehr empfehlen, denn Du beschreitest in meinen 
Augen bereits einen optimalen Weg. GTK solltest du dann allerdings 
zusammen mit der glib (nicht glibC, nur glib) betrachtet, beide zusammen 
sind in etwa vergleichbar mit Qt.

Dem blutigen Anfänger empfehle ich ANSI-C und jemanden, der es schon 
beherrscht, als Anleitung. Das hilft, sich eine klare Meinung darüber zu 
bilden, wohin die Reise gehen soll. Und dazu empfehle ich etwas 
UNIX-Mentalität, um sich z.B. über Sinn und Unsinn von eierlegenden 
Wollmilchsäuen, graphischen Benutzeroberflächen und portablen Standards 
und Schnittstellen klar zu werden.

'The Art Of UNIX Programming' ist da ein ganz tolles Buch.

<Disclaimer>
Wie immer ohne Gewähr. C ist böse, die Konsole ist sowieso für Nerds. 
Windows ist toll, .NET der Heilige Gral. Graphische Oberflächen sind das 
beste, was die Computerwelt in den letzten 20 Jahren erlebt hat, vorher 
war alles schlecht und ineffizient.
Meine Ansichten sind scheiße und von vorgestern, ich habe keinerlei 
Erfahrung mit Programmieren. Und damit fahre ich bislang recht gut.
</Disclaimer>

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> P. M. schrieb:
>>> C++ ist schneller als c# (so langsam ist c# aber auch nicht).
>> Hast du dafür irgendwelche Belege oder behauptest du das einfach? Und
>> was genau ist für dich "schnell" und "langsam" bzw. wie manifestiert
>> sich das?
>
> soetas kommt sehr oft von Leuten die noch die etwas mit .net gemacht
> haben. Ich war selber oft überrascht wie schnell .net ist. Ich konnte
> bis jetzt noch keine unterschied feststellen.
> Ich warte auch mal gespannt auf eine Antwort.

Hey ich programmiere 90% mit .NET und muss einfach manchmal feststellen, 
dass vieles die STL in c++ besser macht. Die Listen in c# sind nicht 
gerade die schnellsten. Ebenso wie Exceptions. Da gibts auch eine 
Quelle, allerdings hab ich vergessen auf welcher Seite die ist.

Die Aussage c++ ist schneller heißt nicht, dass es gleich 50% sein 
müssen. Ich persönlich finde, dass c# schnell genug ist und das, was 
langsam ist, man umgehen kann.

Das c# den Byte-Code erst noch übersetzen muss verlangsamt sicher noch 
ein bisschen, aber: Der Code wird nur einmal übersetzt! D.h. nach dem 
übersetzen ist das Programm nicht langsamer als c++.

Sven P. schrieb:
> Dir würde ich garnichts mehr empfehlen, denn Du beschreitest in meinen
> Augen bereits einen optimalen Weg. GTK solltest du dann allerdings
> zusammen mit der glib (nicht glibC, nur glib) betrachtet, beide zusammen
> sind in etwa vergleichbar mit Qt.

Es gibt keinen optimalen Weg!
Jedem fällt etwas anderes leichter oder schwerer. Auch wenn jeder sagt 
es wäre leicht - ich habe mal in Basic reingeschnuppert und es war ein 
Qual für meine C(++), C# Syntax gewöhnten Augen.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> <Disclaimer>
> Wie immer ohne Gewähr. C ist böse, die Konsole ist sowieso für Nerds.
> Windows ist toll, .NET der Heilige Gral. Graphische Oberflächen sind das
> beste, was die Computerwelt in den letzten 20 Jahren erlebt hat, vorher
> war alles schlecht und ineffizient.
> Meine Ansichten sind scheiße und von vorgestern, ich habe keinerlei
> Erfahrung mit Programmieren. Und damit fahre ich bislang recht gut.
> </Disclaimer>

ROFL der war gut

Aber eine gute IDE mit Debugger ist mir wirklich lieber als vi und ein 
Kommandozeilendebugger :-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sagt ja niemand, dass eine IDE schlecht ist. Aber die IDE von VC++ 
etwa finde ich zum Abgewöhnen.

Und den einen optimalen Weg gibt es nicht, das hat auch niemand 
behauptet. Trotzdem beschreitet hubert in meinen Augen einen optimalen 
Weg. Aber nur in meinen Augen und nur einen optimalen Weg, das hat was 
mit Meinung zu tun. Andre sehen das anders und es gibt sicher noch 
andere optimale oder ideale Wege.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel K. schrieb:
> Hey ich programmiere 90% mit .NET und muss einfach manchmal feststellen,
> dass vieles die STL in c++ besser macht. Die Listen in c# sind nicht
> gerade die schnellsten.

bei welchen größenordnungen viel dir das auf? Ich hatte eine Anwendung 
mit etwa 10.000 einträgen und musste das sortieren und das ging in 
0,nichts. (es war sogar nur ein langsamer Atom Prozessor).

> Ebenso wie Exceptions.
naja Exceptions beurteile ich nicht nach geschwindigkeit.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Aber die IDE von VC++ etwa finde ich zum Abgewöhnen.

Hängt von der Version ab. Und von dem, was man gewohnt ist.
Wer mit vi/Emacs/gdb aufgewachsen ist, der will sich so etwas nicht 
antun, wer sonst mit Eclipse hantiert, der wird sicherlich schon eher 
etwas damit anfangen können ---

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Sven P. schrieb:
>> Aber die IDE von VC++ etwa finde ich zum Abgewöhnen.
>
> Hängt von der Version ab. Und von dem, was man gewohnt ist.
> Wer mit vi/Emacs/gdb aufgewachsen ist, der will sich so etwas nicht
> antun, wer sonst mit Eclipse hantiert, der wird sicherlich schon eher
> etwas damit anfangen können ---

Naja, ich bin ja selbst mit Visual Basic 5+ und VC++ aufgewachsen. Aber 
das, was MS sich da in der aktuellen Version leistet, ist an 
Unaufgeräumtheit und Aufdringlichkeit kaum zu überbieten. Der Quelltext 
rückt komplett in den Hintergrund vor lauter Explorern, Statuszeilen und 
Symbolleisten...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> ist an Unaufgeräumtheit und Aufdringlichkeit kaum zu überbieten

Ja. Eindeutig. Abhilfe schafft hier ein ausreichend großer Monitor, 
besser noch sind zwei Monitore.

Auf dem Hautpmonitor lässt man sich die Fenster mit Sourcecode anzeigen, 
"Solution Explorer", "Class View", "Resource View" sowie "Properties" 
und "Toolbox" und was es noch alles an Debugfenstern gibt/geben kann, 
das packt man auf den zweiten Monitor.

Ist zwischen 2008 und 2010 gefühlt noch schlimmer geworden.

Ich werde mir auf meinen Arbeitsplatz einen Drittmonitor stellen, weil 
ich den Zweitmonitor schon für andere Dinge benötige, und da einfach 
nicht genug Platz ist für das ganze andere Geraffel.

Dann aber geht es, und im Gegensatz zu anderen IDEs darf man auch nach 
wie vor mehrere Quelltextdateien gleichzeitig ansehen.

Das ist ja wirklich das allerletzte, wenn man bei egal welcher 
Bildschirmgröße immer nur genau ein Fenster mit Sourcecode angezeigt 
bekommt. IAR Embedded Workbench ist so ein Kandidat, so ein Screenshot 
sieht zwar im Reklamematerial schick aus, ist aber in der Realität ein 
Produktivitätshemmer par Excellence.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> bei welchen größenordnungen viel dir das auf? Ich hatte eine Anwendung
> mit etwa 10.000 einträgen und musste das sortieren und das ging in
> 0,nichts. (es war sogar nur ein langsamer Atom Prozessor).

Das waren 100k. Zeig mir mal dein Sortieralgo meiner dauert immer noch 
geschätzt eine 10tel Sekunde und ich finde das ist zu langsam! Einzigste 
MEthode war noch parallel vorzusortieren. Ich hab einen Core2Duo @3Ghz 
also auch nur 2-6x so schnell (gibt ha viele).

Sven P. schrieb:
> <Disclaimer>
> Wie immer ohne Gewähr. C ist böse, die Konsole ist sowieso für Nerds.
> Windows ist toll, .NET der Heilige Gral. Graphische Oberflächen sind das
> beste, was die Computerwelt in den letzten 20 Jahren erlebt hat, vorher
> war alles schlecht und ineffizient.
> Meine Ansichten sind scheiße und von vorgestern, ich habe keinerlei
> Erfahrung mit Programmieren. Und damit fahre ich bislang recht gut.
> </Disclaimer>

Haha, ich habe nichts gegen C gesagt. Ich programmiere nämlich auch 
damit. Aber auf dem PC lieber mit C#.

Vorteile von C(++) gegenüber c#

- 0.01% mehr Speed
- Plattformunabhängigkeit
- 20MB weniger Resourcenverbrauch? ich hab zwar noch über 3GB frei aber 
wenigsten ein Grund zum meckern

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Rufus Τ. Firefly schrieb:
>> Sven P. schrieb:
>>> Aber die IDE von VC++ etwa finde ich zum Abgewöhnen.
>>
>> Hängt von der Version ab. Und von dem, was man gewohnt ist.
>> Wer mit vi/Emacs/gdb aufgewachsen ist, der will sich so etwas nicht
>> antun, wer sonst mit Eclipse hantiert, der wird sicherlich schon eher
>> etwas damit anfangen können ---
>
> Naja, ich bin ja selbst mit Visual Basic 5+ und VC++ aufgewachsen. Aber
> das, was MS sich da in der aktuellen Version leistet, ist an
> Unaufgeräumtheit und Aufdringlichkeit kaum zu überbieten.

>  Der Quelltext rückt komplett in den Hintergrund vor lauter Explorern,
> Statuszeilen und Symbolleisten...

Also doch nur ein paar Screenshots gesehen ;-)
Einmal zwei Minuten investieren und die Anordnung passend machen, dann 
geht das selbst auf 1280x800 Notebooks mit der selben sichtbaren 
Zeilenzahl wie bei jedem anderen "brauchbaren" Editor auch (kleiner Tip, 
Doppelklick zum Lösen des Tabs (Float), nochmal Doppelklick. dann ist 
der Tab mit dem Quelltext im Vollbild ohne "störendes" Drumrum oder man 
definiert sich passende Tastenkombinationen)

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Vorteile von C(++) gegenüber c#
> - 0.01% mehr Speed
> - Plattformunabhängigkeit
> - 20MB weniger Resourcenverbrauch? ich hab zwar noch über 3GB frei aber
> wenigsten ein Grund zum meckern

Häh ?

Falscher Film ?

Hier wurde ein Projekt umgestellt, bei nahezu gleicher Funktionalität:

Das C#-Programm ist nach anfänglichen Performanceproblemen
jetzt genau so schnell wie das C++-Programm,
allerdings wie jenes auf einem damals aktuellen 166MHz Pentium
und das C# läuft auf einem aktuellen 3.2GHz Rechner.

Das C++ Programm wurde auf alle möglichen Plattformen bei
Beibehaltung des Quelltextes portiert, von Windows über
*nixe und Mainframes von Siemens und IBM und irgendwelchen
Palm-Pads, das C# Programm läuft ausschliesslich auf PC's.

Statt damals ein Installpaket von 10MB inklusive Doku
kommen jetzt 2GB ohne Doku an.

Das ist die Realität, und ich möchten aktuellen Programmieren
nicht unterstellen das sie voll blöd sind.

Aber ich weiß, du bist so viel klüger...

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verweise einfach mal auf 
http://www.fefe.de/dietlibc/kleinesoftware.pdf

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Das C#-Programm ist nach anfänglichen Performanceproblemen
> jetzt genau so schnell wie das C++-Programm,
> allerdings wie jenes auf einem damals aktuellen 166MHz Pentium
> und das C# läuft auf einem aktuellen 3.2GHz Rechner.
>
> Das C++ Programm wurde auf alle möglichen Plattformen bei
> Beibehaltung des Quelltextes portiert, von Windows über
> *nixe und Mainframes von Siemens und IBM und irgendwelchen
> Palm-Pads, das C# Programm läuft ausschliesslich auf PC's.
>
> Statt damals ein Installpaket von 10MB inklusive Doku
> kommen jetzt 2GB ohne Doku an.

Nicht schlecht. Das muss man erstmal schaffen. Wie viel Thread.Sleep 
musste man einbauen, damit man ein Beispiel hatte um c# dermaßen 
runterzumachen?

MaWin schrieb:
> Statt damals ein Installpaket von 10MB inklusive Doku
> kommen jetzt 2GB ohne Doku an.

2GB in c# aus 10MB halte ich für unmöglich. Zeig mal das Beispiel.

> Das ist die Realität, und ich möchten aktuellen Programmieren
> nicht unterstellen das sie voll blöd sind.

Das möchten ich auch.

> Aber ich weiß, du bist so viel klüger...

Danke.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Danke.

Tja ja, die Selbstüberheblichkeit.

> Wie viel Thread.Sleep musste man einbauen

Falls du mal dem Kindergarten entwachsen sein solltest

> Zeig mal das Beispiel.

wirst du lernen was ein im Kundenauftrag erstelltes
kommerzielles Programm ist.


So lange: Hol wieder deine Bauklötzchen raus.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anscheinend hast du wieder deine Märchenstunde.

Das hier
MaWin schrieb:
> Das C#-Programm ist nach anfänglichen Performanceproblemen
> jetzt genau so schnell wie das C++-Programm,
> allerdings wie jenes auf einem damals aktuellen 166MHz Pentium
> und das C# läuft auf einem aktuellen 3.2GHz Rechner.

und das hier

MaWin schrieb:
> Statt damals ein Installpaket von 10MB inklusive Doku
> kommen jetzt 2GB ohne Doku an.

kauft dir keiner ab! Und genau das ist die Realität!

Es könnte natürlich auch deine Fähigkeiten in der Programmierung 
wiederspiegeln.

Autor: Fer T. (fer_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist aber möglich, guck dir doch mal die gesammte Computer 
Entwicklung an.
Vor einigen Jahren, meinte eine Person (die ich hier nicht nennen will, 
weil sie bei einigen Gruppen komische Zuckungen auslöst) das man mit ca. 
120kB auskommt.
Damals war ein Text dokument noch ca. 0,5-1 Kb groß, heute ca. das 
gleich 5-50Kb.
Besser noch, ich hatte mal ein Spiel hier, war um die 1Mb groß, heute 
das selbe (neu aufgelegt) ca. 150 Mb...
So Ist die Entwicklung halt, und das selbe gilt für die 
Programmiersprachen.

Ach ja ums zu erwähnen, ich selber hab nichts dagegen wenn jemand C# 
nutzt, aber in Kommerziellen Bereich finde ich es einfach...
Naja immer hin besser als VB, das ist jetzt wirklich Kindergarten...
Belassen wir es dabei, BTT or Close.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.