Die breite Masse der C-Programmierer und Interessierten nutzt Windows? Das Erscheint mir irgendwie Abwegig. Die breite Masse dürften mit ihren Problemen ohnehin besser mit einer Hochsprache bedient sein, am besten irgendetwas das mit dem Attribut Skriptsprache versehen ist. Wenn es dieser breiten Masse auf Ausführungsgeschwindigkeit ankommt wird sie sinnvollerweise wohl zu Java greifen.
Was viele hier vergessen ist, dass es sich um ein Lernbuch für den Einstieg in das Programmierung allgemein anhand der Sprache C handelt und nicht um die Proklamation "C über alles".
Nicht dass ich ein Freund von Windows bin, aber die breite Masse der Programmierneulinge hat Windows, oder will das jemand bestreiten? In dem Buch wird genau so das Kompilieren unter Linux erklärt. Die Codes sind 1:1 für Linux heraus zu kopieren und lauffähig.
Ich habe gerade direkt im ersten Satz der Einleitung nen Rechtschreibfehler gefunden. Nun ja, kann ja mal passieren.
Also dann aber bei ner zweiten Stichprobe direkt schon wieder ein doppeltes Wort im Satz war, da war ich ein wenig geschockt. Hoffentlich hat sich der Autor ein wenig mehr Mühe gegeben bei der gedruckten Version!
Laut amazon ist es BOD (books on demand) und die bieten Hilfestellungen an, siehe http://www.book-on-demand.de/manuskriptservice.html. Könnte aber zu teuer gewesen sein...
Der Anfang ist ja nicht der Bringer. Später halten sich die Fehler aber in Grenzen. Das Buch ist aber durchaus empfehlenswert und eines der besseren Bücher zum C.
Hier meldet sich der Autor Das Buch zur C Programmierung wurde wird im Eigenverlag und zusätzlich über BoD vertrieben, wie schon erörtert wude. Das ist auch der Grund, warum kein Geld für professionelle Lektoren zur Verfügung steht. Probegelesen wurde es, deshalb würden mich die Fehler natürlich brennend interessieren - vielleicht kannst du sie mir senden: http://www.c-howto.de/kontakt-hilfe-fragen.html
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 31. Jan 2011 um 10:03.
- Betriebssystem werden darin programmiert - Scriptsprachen werden von C Programmen interpretiert - Ist nicht auch die Java VM in C geschrieben ? - C ist der bessere Assembler - C/C++ ist in der Praxis sehr gefragt
Warum machen dann eigentlich so viele Leute einen Bogen darum ?
> > Warum machen dann eigentlich so viele Leute einen > > Bogen darum ? > Weil so viele Leute umbedingt programmieren wollen es > aber nicht können. Ich denke da eigentlich mehr an Anpassungen vorgefertigter Programme/Programmbausteine. In C/C++ ginge das oft problemlos, weil alles sonst in C/C++ ist. Aber da muss dann immer eine Scriptsprache her, weil die Anwender Angst vor C haben. Die Mischung von Sprachen in einem Projekt finde ich eigentlich nicht so toll.
Von hahhahahhahahar am So, 30. Januar 2011 um 20:19 #
Lua/Javascript/Angelcode rein, fertig. Sprachen, bei denen man SWIG benötigt, sind eher für "richtige" Anwendungsentwicklung gedacht. Naja, meistens zumindest.
> Das die Leuts umbedingt Lua wollen wundert > mich etwas. Die Leute wollen die Masken Ihrer Visualisierungen "on the fly" ändern können. Ohne zu kompilieren oder den Server neu starten zu müssen. Da erscheint Lua gut geeignet.
> Sind allerdings von qmake auf CMake umgestiegen und > CMake ist echt ne feine Sache muss ich sagen. Ich kenne CMake von http://vtk.org/ Das ist da glaube ich entwickelt worden (kitware). Aber für Qt Anwendungen finde ich qmake klasse. Zumal das sowieso mit Qt Installiert wird. Wir benutzen jedenfalls qmake.
> Ok. Aber ich hätt gedacht da gibts populärere Sprachen... aber egal...
Wir haben bereits die Möglichkeit den Server in Python zu programmieren. Aber Lua hat den Vorteil sehr klein zu sein (statische lib mit ca. 2MB) und nicht separat installiert werden zu müssen. Das wäre unter Linux zwar nicht so das Problem aber unter Windows sieht es da schon anders aus.
Mit Lua braucht man nur unsere Anwendung zu installieren. - wir brauchen keinen MinGW bei den Anwendern - wir brauchen kein Qt SDK bei den Anwendern - wir müssen die Scriptsprache nicht erst installieren - die Qt libs werden unter Windows mitgeliefert
> Die Mischung von Sprachen in einem Projekt finde ich > eigentlich nicht so toll. Wieso? Funzt sehr gut. Ausser mit Java (weswegen Java auch kacke ist, aber IMO).
Weil die Leute irrtümlicherweise annehmen, es sei übersichtlicher, sich den Code mithilfe von UML zu modellieren, generieren zu lassen und anschließend rumjammern, das es nicht so fluppt. C ist zwar hässlich wie die Sünde und Einsteigern würde ich tatsächlich erstmal zu Python oder so raten, aber man kann mit C arbeiten und für Bibliotheken sollte es ausschließlich benutzt werden. Immerhin gibt es fast überall einen C-Compiler und man kann Anbindungen an die meisten Sprachen dafür bauen.
Ich werde echt langsam alt, denn mit UML kann ich mich immer noch nicht anfreunden (Bin Quereinsteiger was Programmieren anbegeht / Elektoingenieur). Mir reicht es eigentlich völlig aus die Header Dateien zu schreiben und Doxygen darüber rennen zu lassen.
PS: Nach FORTRAN und Assembler war C die Lösung. Nach GEM, Motif, MFC war Qt die Lösung.
> Mir reicht es eigentlich völlig aus die Header Dateien > zu schreiben und Doxygen darüber rennen zu lassen. Die Idee ist, das man /bevor/ man Anfängt zu coden einen Plan macht (mit zB UML Diagrammen).
Das ist mir bekannt. Mir gings um den Wink mit dem Zaunpfaul bzgl der Arbeits- bzw Vorgehensweise.
Ich selbst benutze sowas nicht und mich hat in 10 Jahren die ich den Beruf des SW Entwicklers (meist im Bereich Technische Informatik muss ich dazu sagen) ausübe auch zum Glück noch keiner dazu gezwungen.
>- C ist der bessere Assembler Unfug. Jedes Werkzeug ist zu seiner Zeit einzusetzen. Schon alleine auf Register zu zugreifen wenn diese nicht im Speicher abgebildet sind ist in reinem C nicht möglich.
5 Bücher finden einen Leser, das ist alles. Ein C Handbuch, das kostenlos für die User abrufbar ist, hat kein (großes) Werbebudget, das kann ich dir versichern.
Natürlich ist der Artikel Werbung und jeder, der nur ein wenig denken kann erkennt es sofort. Noch nie eine Verlosung irgendwo erlebt? Noch nie Fernsehen geschaut und eine der zahlreichen Verlosungen gesehen? Mann... Die Frage ist eines 42-jährigen nicht würdig.
C ist ein Relikt der 70er, das in der modernen Softwareentwicklung nichts mehr verloren hat, außer vielleicht zur Pflege von Legacy-Code. Die Einschränkungen dieser Sprache sind heute nicht mehr zeitgemäß.
Was soll dieser arrogante Ton? Ich habe jahrelang mit C-Programmierung mein Geld verdient und bin wirklich froh, das nicht mehr machen zu müssen. Nicht, weil ich es nicht könnte, sondern weil es schlicht nervt und keinen Spaß macht.
Schönheit ja, Eleganz nein! C stammt aus einer Zeit, in der viele Konzepte neuerer Sprachen noch nicht bekannt waren. Es ist somit klar, dass diese Sprache veraltet wirkt. Trotz diverser Nachbesserungen kann man die grundlegenden Paradigmen einer Sprache eben nicht umkrempeln.
Ganz so extrem würde ich das nicht ausdrücken, es gibt durchaus interessante Konzepte, die erst spät erfunden wurden. Beispielsweise wurde lineare Logik erst 1987 erfunden, und diese Logik bildet die Grundlage mancher Typsysteme in modernen Sprachen.
Aber im Grunde hast Du Recht, sehr viel von dem, was in C fehlt, gab es vorher schon.
Man versucht zwar ne VM auf nen Chip zu packen aber wozu? Historische Software wie der Bekannte Webserver sind in reinem C geschrieben. D. h. neue Software wäre es sinnfrei wieder mit C anzufangen aber bei Echtzeitprogrammen ist C halt eben C und kein lahmes C# oder Java.
Für den bequemen Programmierer von heute sind Referenzen das Nonplusultra. Für mich sind Pointer einfach der Inbegriff von Macht....Deshalb halte ich von C# mehr als von Java wenn man sich dem Hype nicht verschließt...Wobei sowohl Sun als auch MS ganz groß im Kopieren Sprachkonstrukten sind
Kurz gesagt vorher gefriert die Hölle bevor C ausstirbt...Danke liebe stabile C Software das es dich gibt. Solange ne C# VM auf nem Hardwarebaustein nicht genauso schnell läuft wie C braucht man hier nicht weiterdiskutieren.
Besonders diejenigen die eine Sachlage nur aus einer Richtung betrachten. "Ich mag C nicht weil es viel zu unbequem ist"
Kurz gesagt vorher gefriert die Hölle bevor C ausstirbt...Danke liebe stabile C Software das es dich gibt. Solange ne C# VM auf nem Hardwarebaustein nicht genauso schnell läuft wie C braucht man hier nicht weiterdiskutieren.
Genauso schnell ist nicht relevant, da C# primär einen anderen Einsatzzweck besitzt als C. In viele naturwissenschaftlichen Disziplinen ist ja sogar noch Fortran im Einsatz und das nicht nur aus historischen Gründen. Für reines Numbercrunching mag C ok sein, für komplexe Software Programme a la ApplicationServer und Anwendungsprogramme sind die Zeiten von C einfach vorbei. Dort bestimmt neben Entwicklungszeit eben auch Sicherheit; und da sind Pointer eben Gift!
Für den bequemen Programmierer von heute sind Referenzen das Nonplusultra. Für mich sind Pointer einfach der Inbegriff von Macht.
Also wenn Du ein so triviales Konstrukt wie Pointer für den "Inbegriff von Macht" hältst, was machst Du dann erst, wenn Du wirklich mächtige Features siehst? Z. B. Lisp-Macros, Funktionen höherer Ordnung, das Actor-Modell in Erlang...
und du bist halt so ein bequemer der auch von Speicher freigeben nichts hält. oder? hantierst da mit deinen Abstrakten Konstrukten rum und weil sie dir so viel Arbeit abnehmen sind sie ja so mächtig aber so manch einer versteht unter mächtig auch was anderes u.a pointer/inine asm/usw.
ich für meine Person mag am liebsten Assembler nicht weil es Schön/Elegant/usw. ist nicht weil dabei schnell Ergebnisse raus kommen die sich verkaufen lassen nein ich mag es weil es noch so richtig Spaß macht!
das ist doch immer das gleich das ist alt das ist schlecht siehe "Prozedurale Programmierung" wurde doch auch größtenteils von OO abgelöst und galt als veraltet usw doch jetzt ist sie wieder im kommen und wird sogar wieder schön geredet siehe Scala.
Ich habe mich angesichts Deines Schreibstils gefragt, ob ich überhaupt antworten soll. Ein paar Kommata tun nicht weh und verbessern den Lesefluss erheblich, ebenso wie Groß- und Kleinschreibung. Aber sei's drum.
ich glaube nicht das du verstehst was er meint!
Naja, zumindest verstehe ich unter Macht offenbar etwas anderes als er. Meinem Verständnis nach ist ein mächtiges Konstrukt eines, das es mir ermöglicht, mit wenig Code viel zu erreichen. Pointer gehören meiner Ansicht nach eher nicht zu dieser Kategorie.
und du bist halt so ein bequemer der auch von Speicher freigeben nichts hält. oder?
Kommt drauf an, ob es wirklich nötig ist oder nicht. Aber wenn es nötig ist, dann bitte nicht so wie in C. Moderne Typsysteme können die Abwesenheit von Leaks, hängenden Zeigern etc. statisch garantieren. Ein möglicher Ansatz wird z. B. hier erläutert, und das Paper verweist noch auf weitere Ansätze. Sprachen mit manuellem Speichermanagement ohne solche Features werde ich tunlichst meiden.
das ist doch immer das gleich das ist alt das ist schlecht siehe "Prozedurale Programmierung" wurde doch auch größtenteils von OO abgelöst und galt als veraltet usw doch jetzt ist sie wieder im kommen und wird sogar wieder schön geredet siehe Scala.
Scala hat nicht mehr mit prozeduraler Programmierung zu tun als z. B. Java. Der Witz an Scala ist die Kombination von OOP mit funktionalen Ansätzen.
Wie schon erwähnt gibt es ja nich die Hardwareentwicklung. Für den Einstieg in die Softwareentwicklung würde ich trotzdem C vor C++ wählen. Das ist auch die Praxis von Berufs- und Fachhochschulen, wie ich sie erfahren habe.
Komisch, dass fast alle Applikationen die ich beruflich und private nutze entweder in C oder in C++ geschrieben sind. Dazu kommen noch ein paar in Perl, Python geschriebene oder bei Web Sachen halt sowas wie PHP.
Datenbanken, Firefox, KDE, VLC, alles *wichtige ist entweder C oder C++ oder eine Mischung daraus.
> Komisch, dass fast alle Applikationen die ich beruflich > und private nutze entweder in C oder in C++ geschrieben > sind.
Dieses "weil es alle so machen" oder wahlweise auch "weil es schon so lange so gemacht wird" ist für mich kein sachliches Argument. Es können im Prinzip auch "alle" falsch machen und nur einem Hype hinterherrennen.
Im hardwarenahen Bereich ist C unverzichtbar da C++ nach wie vor ineffzienteren Code generiert. Sprich wenn es beim Timing und bei den Ressourcen wirklich hart auf hart kommt, stehst du mit C++ in einer Sackgasse.
Unstrittig ist aber, das C für Applikationen auf höheren Leveln ein paar grundlegende Designschwächen hat. Das sind aber genau die Dinge, die es im hardwarenahen Bereich so unverzichtbar machen - nämlich eben die ganze Pointerei. Auf Ebene von Benutzerapplikationen brauche ich das nicht, da kommt es weder auf ein paar Millisekunden Reaktionszeit mehr oder weniger an, noch gibt es bei vernünftiger Programmierung auch nur einen einzigen Grund, in irgend einem Speicherbereich herumzupoken.
Im hardwarenahen Bereich ist C unverzichtbar da C++ nach wie vor ineffzienteren Code generiert. Sprich wenn es beim Timing und bei den Ressourcen wirklich hart auf hart kommt, stehst du mit C++ in einer Sackgasse.
C++ ist nicht weniger effizient als C. Das kann schon allein deswegen nicht sein, weil jedes C-Programm auch ein gültiges C++-Programm ist (gut, man muss ein paar Casts einfügen und Variablen umbenennen, deren Name in C++ ein Schlüsselwort ist. Auf den generierten Code hat das keinen Einfluss).
Ein C++-Programm, welches einen konstanten Wert als Member einer Klasse definiert (so dass dieser nur im Kontext der Klasse benutzt werden kann, was aus OOP-Sicht sehr elegant ist) und ein C-Programm, das die gleiche Konstante als simples #define (und damit global und funktionsorientiert-hässlich) implementiert.
Dann compiliere die beiden Programme und erzähle mir noch mal was von "kann nicht sein".
Die von Dir genannten Applikationen sind allesamt schon ziemlich alt. Mit der Entwicklung der Firefox-Engine wurde 98 begonnen, VLC gibt es seit 99, KDE gibt es seit 96. Da hatte man eben noch ganz andere Anforderungen an Performance und Speicherverbrauch. Zudem sind die auch alle in C++ und eben nicht in C geschrieben.
Was Datenbanken angeht, stimmt Deine Behauptung nicht uneingeschränkt, Apache Cassandra ist z. B. in Java geschrieben (gut, das ist nun auch nicht gerade eine tolle Sprache, aber nicht so grausam wie C) und CouchDB in Erlang. Und serverseitige Software schreibt heute sowieso kein Mensch mehr in C oder C++.
Ich würde wohl nicht so weit gehen, es zu empfehlen. Aber wenn ich es mit C vergleiche, ist es in meinen Augen die deutlich bessere Alternative. Meist wird gegen C++ argumentiert, dass es gegenüber C neue Fehlerklassen gibt, z. B. dass man einen Destruktor virtual machen muss, damit man ein Objekt durch einen Basisklassenpointer löschen kann. Natürlich gibt es diese Fehlerklasse in C nicht, weil es keine Destruktoren gibt. Aber wenn man ein äquivalentes, objektorientiertes Design in C umsetzt (mit vtable-Zeigern etc.), kriegt man einen Code-Moloch, der noch viel fehleranfälliger und hässlicher als der C++-Code ist.
Oder anders gesagt: C-Fanboys kritisieren C++ in der Regel dafür, dass die Lösungen, die es für Probleme wie generische Programmierung (Templates), OOP (Klassen, Vererbung, virtuelle Memberfunktionen), Fehlerbehandlung (Exceptions), Ressourcenmanagement (Destruktoren) usw. bietet vielleicht nicht perfekt sind, und ignorieren dabei komplett, dass C da noch viel weniger hilfreich ist.
> Aber wenn man ein äquivalentes, objektorientiertes Design in C umsetzt (mit vtable-Zeigern etc.), kriegt man einen > Code-Moloch, der noch viel fehleranfälliger und hässlicher als der C++-Code ist.
Wer das macht, hat aber doch schon den grundsätzlichen Unterschied zwischen C (funktionsorientiert) und C++ (objektorientiert) nicht verstanden. Es ist also absolut kein Verlgeichskriterium, wenn sich in einer Sprache etwas nicht vernünftig umsetzen lässt, für das die Sprache gar nicht gedacht ist (ich fahre ja auch nicht mit einem LKW zum Einkaufen und habe dann eine einzelne Tüte auf der Ladefläche stehen).
Die gängigen C-Programme sind aber voll mit solchen Designs. GTK ist komplett objektorientiert, und auch der Linux-Kernel enthält zahlreiche objektorientierte Designs. Beispielsweise ist struct file_operations [1] voll mit Funktionspointern, sprich: es ist nichts anderes als die vtable einer Klasse.
Was hat die Implementation mit dem Funktionsprinzip zu tun?
Genau so könntest du behaupten, "Auto fahren" ist das gleiche wie "Benzin", weil das Auto ja Benzin für seine Funktion benötigt. Völliger Schwachsinn also.
Dein Vergleich? Ja, in der Tat. Fakt ist, dass hier ganz klar ein objektorientiertes Konzept umgesetzt wurde, indem man das, was in einer objektorientierten Sprache der Compiler machen würde, von Hand hingeschrieben hat. Wenn Du da keinen Zusammenhang siehst, bist Du offenbar dum.
Äh..? Das Video zeigt Windows. Wer sowas benutzt sollte besser gar nicht programmieren.
Naja, egal. C in a Nutshell ist eh besser. Ist halt ne Referenz, aber Programmieren sollte man eh besser mit ner anderen Sprache anfangen.
Windows, weil das die breite Masse hat. Die Codes im Buch sind betriebsystemunabhängig.
Die breite Masse der C-Programmierer und Interessierten nutzt Windows? Das Erscheint mir irgendwie Abwegig. Die breite Masse dürften mit ihren Problemen ohnehin besser mit einer Hochsprache bedient sein, am besten irgendetwas das mit dem Attribut Skriptsprache versehen ist. Wenn es dieser breiten Masse auf Ausführungsgeschwindigkeit ankommt wird sie sinnvollerweise wohl zu Java greifen.
Was viele hier vergessen ist, dass es sich um ein Lernbuch für den Einstieg in das Programmierung allgemein anhand der Sprache C handelt und nicht um die Proklamation "C über alles".
Nicht dass ich ein Freund von Windows bin, aber die breite Masse der Programmierneulinge hat Windows, oder will das jemand bestreiten? In dem Buch wird genau so das Kompilieren unter Linux erklärt. Die Codes sind 1:1 für Linux heraus zu kopieren und lauffähig.
Passt hier schon allein deshalb nicht, weil diese Site
pro LINUX heisst und nicht pro Windos.
Der Omega13.
Ich habe gerade direkt im ersten Satz der Einleitung nen Rechtschreibfehler gefunden.
Nun ja, kann ja mal passieren.
Also dann aber bei ner zweiten Stichprobe direkt schon wieder ein doppeltes Wort im Satz war, da war ich ein wenig geschockt.
Hoffentlich hat sich der Autor ein wenig mehr Mühe gegeben bei der gedruckten Version!
nope ist ja nur cnp
Im Allgemeinen haben Verlage für sowas Lektoren.
Was für ein Verlag ist es denn?
Es könnte sich ja auch um eine Art "Selbstverlag" handeln, Lulu, vielleicht auch BOD o.ä.
Laut amazon ist es BOD (books on demand) und die bieten Hilfestellungen an, siehe http://www.book-on-demand.de/manuskriptservice.html. Könnte aber zu teuer gewesen sein...
Ich bezweifle, dass BOD einen C-Experten hat. :-)
Oben steht was von Rechtschreibfehlern.
Der Anfang ist ja nicht der Bringer. Später halten sich die Fehler aber in Grenzen. Das Buch ist aber durchaus empfehlenswert und eines der besseren Bücher zum C.
Hier meldet sich der Autor
Das Buch zur C Programmierung wurde wird im Eigenverlag und zusätzlich über BoD vertrieben, wie schon erörtert wude. Das ist auch der Grund, warum kein Geld für professionelle Lektoren zur Verfügung steht. Probegelesen wurde es, deshalb würden mich die Fehler natürlich brennend interessieren - vielleicht kannst du sie mir senden: http://www.c-howto.de/kontakt-hilfe-fragen.html
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 31. Jan 2011 um 10:03.Na da bevorzuge ich doch eher
http://openbook.galileocomputing.de/c_von_a_bis_z/
- Betriebssystem werden darin programmiert
- Scriptsprachen werden von C Programmen interpretiert
- Ist nicht auch die Java VM in C geschrieben ?
- C ist der bessere Assembler
- C/C++ ist in der Praxis sehr gefragt
Warum machen dann eigentlich so viele Leute einen Bogen darum ?
> - C/C++ ist in der Praxis sehr gefragt
"Richtiges "C++ und C sind schon sehr verschieden.
Ich würd die nicht so in einen Topf werfen.
> Warum machen dann eigentlich so viele Leute einen
> Bogen darum ?
Weil so viele Leute umbedingt programmieren wollen es
aber nicht können.
Der Omega13.
> > Warum machen dann eigentlich so viele Leute einen
> > Bogen darum ?
> Weil so viele Leute umbedingt programmieren wollen es
> aber nicht können.
Ich denke da eigentlich mehr an Anpassungen vorgefertigter Programme/Programmbausteine.
In C/C++ ginge das oft problemlos, weil alles sonst in C/C++ ist.
Aber da muss dann immer eine Scriptsprache her, weil die Anwender Angst vor C haben.
Die Mischung von Sprachen in einem Projekt finde ich eigentlich nicht so toll.
Gut, dass es http://swig.org gibt
Lua/Javascript/Angelcode rein, fertig.
Sprachen, bei denen man SWIG benötigt, sind eher für "richtige" Anwendungsentwicklung gedacht. Naja, meistens zumindest.
Wir bauen Lua gerade in unseren http://pvbrowser.org ein.
In C geht es aber genau so gut, wenn nicht besser.
Aber die Anwender wollen es so.
Hmmm... interessantes/kuhles Projekt.
Das die Leuts umbedingt Lua wollen wundert
mich etwas.
Der Omega13
> Das die Leuts umbedingt Lua wollen wundert
> mich etwas.
Die Leute wollen die Masken Ihrer Visualisierungen "on the fly" ändern können. Ohne zu kompilieren oder den Server neu starten zu müssen.
Da erscheint Lua gut geeignet.
Ok. Aber ich hätt gedacht da gibts populärere Sprachen... aber egal...
Ihr benutzt Qt seh ich grad. Seeehr gut! Wir auch.
Sind allerdings von qmake auf CMake umgestiegen und
CMake ist echt ne feine Sache muss ich sagen.
Nur so, by the way...
Der Omega13.
> Sind allerdings von qmake auf CMake umgestiegen und
> CMake ist echt ne feine Sache muss ich sagen.
Ich kenne CMake von http://vtk.org/ Das ist da glaube ich entwickelt worden (kitware).
Aber für Qt Anwendungen finde ich qmake klasse.
Zumal das sowieso mit Qt Installiert wird.
Wir benutzen jedenfalls qmake.
> Ok. Aber ich hätt gedacht da gibts populärere Sprachen... aber egal...
Wir haben bereits die Möglichkeit den Server in Python zu programmieren.
Aber Lua hat den Vorteil sehr klein zu sein (statische lib mit ca. 2MB)
und nicht separat installiert werden zu müssen.
Das wäre unter Linux zwar nicht so das Problem aber
unter Windows sieht es da schon anders aus.
Mit Lua braucht man nur unsere Anwendung zu installieren.
- wir brauchen keinen MinGW bei den Anwendern
- wir brauchen kein Qt SDK bei den Anwendern
- wir müssen die Scriptsprache nicht erst installieren
- die Qt libs werden unter Windows mitgeliefert
> Die Mischung von Sprachen in einem Projekt finde ich
> eigentlich nicht so toll.
Wieso? Funzt sehr gut. Ausser mit Java (weswegen
Java auch kacke ist, aber IMO).
Der Omega13
> Wieso? Funzt sehr gut.
Seitdem es http://swig.org gibt.
Zu Fuss wäre das aber eine Qual.
Was hat das mit SWIG zu tun? Auch wenn SWIG ist Idiotie von JNI vielleicht abmildern kann, wird JNI selbst dadurch nicht besser.
Weil die Leute irrtümlicherweise annehmen, es sei übersichtlicher, sich den Code mithilfe von UML zu modellieren, generieren zu lassen und anschließend rumjammern, das es nicht so fluppt.
C ist zwar hässlich wie die Sünde und Einsteigern würde ich tatsächlich erstmal zu Python oder so raten, aber man kann mit C arbeiten und für Bibliotheken sollte es ausschließlich benutzt werden. Immerhin gibt es fast überall einen C-Compiler und man kann Anbindungen an die meisten Sprachen dafür bauen.
Ich werde echt langsam alt, denn mit UML kann ich mich immer noch nicht anfreunden (Bin Quereinsteiger was Programmieren anbegeht / Elektoingenieur).
Mir reicht es eigentlich völlig aus die Header Dateien zu schreiben und Doxygen darüber rennen zu lassen.
PS:
Nach FORTRAN und Assembler war C die Lösung.
Nach GEM, Motif, MFC war Qt die Lösung.
> Mir reicht es eigentlich völlig aus die Header Dateien
> zu schreiben und Doxygen darüber rennen zu lassen.
Die Idee ist, das man /bevor/ man Anfängt zu coden einen Plan macht (mit zB UML Diagrammen).
Der Oemga13.
Es gibt leider auch Generatoren, die aus UML-Diagrammen Code erzeugen können.
Das ist mir bekannt. Mir gings um den Wink
mit dem Zaunpfaul bzgl der Arbeits- bzw
Vorgehensweise.
Ich selbst benutze sowas nicht und mich hat
in 10 Jahren die ich den Beruf des SW Entwicklers
(meist im Bereich Technische Informatik muss
ich dazu sagen) ausübe auch zum Glück noch
keiner dazu gezwungen.
Der Omega13.
>- C ist der bessere Assembler
Unfug. Jedes Werkzeug ist zu seiner Zeit einzusetzen. Schon alleine auf Register zu zugreifen wenn diese nicht im Speicher abgebildet sind ist in reinem C nicht möglich.
Naja es gibt eine GNU extension...
http://tigcc.ticalc.org/doc/gnuexts.html#SEC97
In ANSI-C gibt es immerhin register
ist das ein Bezahlter Artikel?
Manchmal Frage ich mich wirklich, wie Alt die Leute hier sind...
42 Mein kleiner.
Und der Artikel ist keine Rezession sondern Werbung.
Werbeeinschaltungen sollten als solche gekennzeichnet sein.
5 Bücher finden einen Leser, das ist alles. Ein C Handbuch, das kostenlos für die User abrufbar ist, hat kein (großes) Werbebudget, das kann ich dir versichern.
Natürlich ist der Artikel Werbung und jeder, der nur ein wenig denken kann erkennt es sofort. Noch nie eine Verlosung irgendwo erlebt? Noch nie Fernsehen geschaut und eine der zahlreichen Verlosungen gesehen? Mann... Die Frage ist eines 42-jährigen nicht würdig.
Wenn ich mal bei Freunden Fernsehe, dann bestimmt kein QVC oder 9LIVE.
Bei selben Kommentaren stelle ich mich immer wieder die Frage, warum ich mir eigentlich das Ganze hier antue...
Cheers,
demon
SCNR.
C ist ein Relikt der 70er, das in der modernen Softwareentwicklung nichts mehr verloren hat, außer vielleicht zur Pflege von Legacy-Code. Die Einschränkungen dieser Sprache sind heute nicht mehr zeitgemäß.
Sagt jmd der von der Praxis offenbar keine Ahnung
hat.
Was soll dieser arrogante Ton? Ich habe jahrelang mit C-Programmierung mein Geld verdient und bin wirklich froh, das nicht mehr machen zu müssen. Nicht, weil ich es nicht könnte, sondern weil es schlicht nervt und keinen Spaß macht.
Stell dir vor das sieht schon der nächste! wieder ganz anders.
Schönheit ja, Eleganz nein! C stammt aus einer Zeit, in der viele Konzepte neuerer Sprachen noch nicht bekannt waren. Es ist somit klar, dass diese Sprache veraltet wirkt. Trotz diverser Nachbesserungen kann man die grundlegenden Paradigmen einer Sprache eben nicht umkrempeln.
Ich kann da AnonymousCoward nur zustimmen!
So ein Blödsinn. Sämtliche Konzepte neuerer Sprachen waren schon in den 70ern bekannt.
Von mir aus auch das
Wichtig ist doch nur, dass die in C nicht enthalten sind - die Gründe dafür sind letztlich egal.
Ganz so extrem würde ich das nicht ausdrücken, es gibt durchaus interessante Konzepte, die erst spät erfunden wurden. Beispielsweise wurde lineare Logik erst 1987 erfunden, und diese Logik bildet die Grundlage mancher Typsysteme in modernen Sprachen.
Aber im Grunde hast Du Recht, sehr viel von dem, was in C fehlt, gab es vorher schon.
Und auf der Hardware Ebene unverzichtbar ist....
Man versucht zwar ne VM auf nen Chip zu packen aber wozu? Historische Software wie der Bekannte Webserver sind in reinem C geschrieben. D. h. neue Software wäre es sinnfrei wieder mit C anzufangen aber bei Echtzeitprogrammen ist C halt eben C und kein lahmes C# oder Java.
Für den bequemen Programmierer von heute sind Referenzen das Nonplusultra. Für mich sind Pointer einfach der Inbegriff von Macht....Deshalb halte ich von C# mehr als von Java wenn man sich dem Hype nicht verschließt...Wobei sowohl Sun als auch MS ganz groß im Kopieren Sprachkonstrukten sind
Kurz gesagt vorher gefriert die Hölle bevor C ausstirbt...Danke liebe stabile C Software das es dich gibt. Solange ne C# VM auf nem Hardwarebaustein nicht genauso schnell läuft wie C braucht man hier nicht weiterdiskutieren.
Besonders diejenigen die eine Sachlage nur aus einer Richtung betrachten. "Ich mag C nicht weil es viel zu unbequem ist"
ich glaube nicht das du verstehst was er meint!
und du bist halt so ein bequemer der auch von Speicher freigeben nichts hält. oder?
hantierst da mit deinen Abstrakten Konstrukten rum und weil sie dir so viel Arbeit
abnehmen sind sie ja so mächtig aber so manch einer versteht unter mächtig
auch was anderes u.a pointer/inine asm/usw.
ich für meine Person mag am liebsten Assembler nicht weil es Schön/Elegant/usw.
ist nicht weil dabei schnell Ergebnisse raus kommen die sich verkaufen lassen
nein ich mag es weil es noch so richtig Spaß macht!
das ist doch immer das gleich das ist alt das ist schlecht siehe "Prozedurale Programmierung"
wurde doch auch größtenteils von OO abgelöst und galt als veraltet usw doch jetzt ist
sie wieder im kommen und wird sogar wieder schön geredet siehe Scala.
Ich habe mich angesichts Deines Schreibstils gefragt, ob ich überhaupt antworten soll. Ein paar Kommata tun nicht weh und verbessern den Lesefluss erheblich, ebenso wie Groß- und Kleinschreibung. Aber sei's drum.
Naja, zumindest verstehe ich unter Macht offenbar etwas anderes als er. Meinem Verständnis nach ist ein mächtiges Konstrukt eines, das es mir ermöglicht, mit wenig Code viel zu erreichen. Pointer gehören meiner Ansicht nach eher nicht zu dieser Kategorie.Kommt drauf an, ob es wirklich nötig ist oder nicht. Aber wenn es nötig ist, dann bitte nicht so wie in C. Moderne Typsysteme können die Abwesenheit von Leaks, hängenden Zeigern etc. statisch garantieren. Ein möglicher Ansatz wird z. B. hier erläutert, und das Paper verweist noch auf weitere Ansätze. Sprachen mit manuellem Speichermanagement ohne solche Features werde ich tunlichst meiden.Scala hat nicht mehr mit prozeduraler Programmierung zu tun als z. B. Java. Der Witz an Scala ist die Kombination von OOP mit funktionalen Ansätzen.> C ist ein Relikt der 70er, das in der modernen Softwareentwicklung nichts mehr verloren hat
Das ist richtig - so lange du nicht C++ als Alternative empfiehlst.
Wie schon erwähnt gibt es ja nich die Hardwareentwicklung. Für den Einstieg in die Softwareentwicklung würde ich trotzdem C vor C++ wählen. Das ist auch die Praxis von Berufs- und Fachhochschulen, wie ich sie erfahren habe.
Komisch, dass fast alle Applikationen die ich beruflich
und private nutze entweder in C oder in C++ geschrieben
sind. Dazu kommen noch ein paar in Perl, Python geschriebene
oder bei Web Sachen halt sowas wie PHP.
Datenbanken, Firefox, KDE, VLC, alles *wichtige ist
entweder C oder C++ oder eine Mischung daraus.
Willkommen in der Realität.
Der Omega13.
Richtig, C als EINTIEGSsprache.
> Komisch, dass fast alle Applikationen die ich beruflich
> und private nutze entweder in C oder in C++ geschrieben
> sind.
Dieses "weil es alle so machen" oder wahlweise auch "weil es schon so lange so gemacht wird" ist für mich kein sachliches Argument. Es können im Prinzip auch "alle" falsch machen und nur einem Hype hinterherrennen.
Im hardwarenahen Bereich ist C unverzichtbar da C++ nach wie vor ineffzienteren Code generiert. Sprich wenn es beim Timing und bei den Ressourcen wirklich hart auf hart kommt, stehst du mit C++ in einer Sackgasse.
Unstrittig ist aber, das C für Applikationen auf höheren Leveln ein paar grundlegende Designschwächen hat. Das sind aber genau die Dinge, die es im hardwarenahen Bereich so unverzichtbar machen - nämlich eben die ganze Pointerei. Auf Ebene von Benutzerapplikationen brauche ich das nicht, da kommt es weder auf ein paar Millisekunden Reaktionszeit mehr oder weniger an, noch gibt es bei vernünftiger Programmierung auch nur einen einzigen Grund, in irgend einem Speicherbereich herumzupoken.
LOL! Und für die Begründung: ROTFL!
Bastel dir mal zwei Programme:
Ein C++-Programm, welches einen konstanten Wert als Member einer Klasse definiert (so dass dieser nur im Kontext der Klasse benutzt werden kann, was aus OOP-Sicht sehr elegant ist) und ein C-Programm, das die gleiche Konstante als simples #define (und damit global und funktionsorientiert-hässlich) implementiert.
Dann compiliere die beiden Programme und erzähle mir noch mal was von "kann nicht sein".
Von mir aus... hier das C-Programm:
#include <stdio.h>
#define FOO 42
static void go() {
printf("%d\n", FOO);
}
int main() {
go();
return 0;
}
Kompiliert mit gcc -O2 -S ergibt das
.file "test.c"
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
pushl %ebp
movl %esp, %ebp
andl $-16, %esp
subl $16, %esp
movl $42, 4(%esp)
movl $.LC0, (%esp)
call printf
xorl %eax, %eax
leave
ret
.size main, .-main
.ident "GCC: (Debian 4.4.5-10) 4.4.5"
.section .note.GNU-stack,"",@progbits
Und nun das C++-Programm:
#include <cstdio>
namespace {
class dummy {
static const int FOO = 42;
public:
static void go() {
std::printf("%d\n", FOO);
};
};
}
int main() {
dummy::go();
}
Kompiliert mit g++ -O2 -S -fno-exceptions ergibt das
.file "test.cc"
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
pushl %ebp
movl %esp, %ebp
andl $-16, %esp
subl $16, %esp
movl $42, 4(%esp)
movl $.LC0, (%esp)
call printf
xorl %eax, %eax
leave
ret
.size main, .-main
.ident "GCC: (Debian 4.4.5-10) 4.4.5"
.section .note.GNU-stack,"",@progbits
Der Code ist auf's Komma genau derselbe.
Krasser Hype, Meister. Hält jetzt schon fast 40 Jahre (C)
bzw fast 30 Jahre (C++) an.
Der Omega13.
Die von Dir genannten Applikationen sind allesamt schon ziemlich alt. Mit der Entwicklung der Firefox-Engine wurde 98 begonnen, VLC gibt es seit 99, KDE gibt es seit 96. Da hatte man eben noch ganz andere Anforderungen an Performance und Speicherverbrauch. Zudem sind die auch alle in C++ und eben nicht in C geschrieben.
Was Datenbanken angeht, stimmt Deine Behauptung nicht uneingeschränkt, Apache Cassandra ist z. B. in Java geschrieben (gut, das ist nun auch nicht gerade eine tolle Sprache, aber nicht so grausam wie C) und CouchDB in Erlang. Und serverseitige Software schreibt heute sowieso kein Mensch mehr in C oder C++.
Ich würde wohl nicht so weit gehen, es zu empfehlen. Aber wenn ich es mit C vergleiche, ist es in meinen Augen die deutlich bessere Alternative. Meist wird gegen C++ argumentiert, dass es gegenüber C neue Fehlerklassen gibt, z. B. dass man einen Destruktor virtual machen muss, damit man ein Objekt durch einen Basisklassenpointer löschen kann. Natürlich gibt es diese Fehlerklasse in C nicht, weil es keine Destruktoren gibt. Aber wenn man ein äquivalentes, objektorientiertes Design in C umsetzt (mit vtable-Zeigern etc.), kriegt man einen Code-Moloch, der noch viel fehleranfälliger und hässlicher als der C++-Code ist.
Oder anders gesagt: C-Fanboys kritisieren C++ in der Regel dafür, dass die Lösungen, die es für Probleme wie generische Programmierung (Templates), OOP (Klassen, Vererbung, virtuelle Memberfunktionen), Fehlerbehandlung (Exceptions), Ressourcenmanagement (Destruktoren) usw. bietet vielleicht nicht perfekt sind, und ignorieren dabei komplett, dass C da noch viel weniger hilfreich ist.
> Aber wenn man ein äquivalentes, objektorientiertes Design in C umsetzt (mit vtable-Zeigern etc.), kriegt man einen
> Code-Moloch, der noch viel fehleranfälliger und hässlicher als der C++-Code ist.
Wer das macht, hat aber doch schon den grundsätzlichen Unterschied zwischen C (funktionsorientiert) und C++ (objektorientiert) nicht verstanden. Es ist also absolut kein Verlgeichskriterium, wenn sich in einer Sprache etwas nicht vernünftig umsetzen lässt, für das die Sprache gar nicht gedacht ist (ich fahre ja auch nicht mit einem LKW zum Einkaufen und habe dann eine einzelne Tüte auf der Ladefläche stehen).
Könnte meine Rede sein
Die gängigen C-Programme sind aber voll mit solchen Designs. GTK ist komplett objektorientiert, und auch der Linux-Kernel enthält zahlreiche objektorientierte Designs. Beispielsweise ist struct file_operations [1] voll mit Funktionspointern, sprich: es ist nichts anderes als die vtable einer Klasse.
[1] http://lxr.linux.no/#linux+v2.6.37/include/linux/fs.h#L1520
Ich weiß nicht was ein struct mit OOP zu tun hat. In dem Fall wurde ein struct verwendet wozu es da ist, eine Ansammlung von Daten.
Structs mit Funktionen, virtuellen Funktionszeigern und Parent-Feld sind das selbe wie eine Klasse.
Autsch, das tut weh, aber richtig.
Ich hoffe, du verdienst deinen Lebensunterhalt mit was anderem (und damit meine ich nicht HartzIV).
[1] http://de.wikipedia.org/wiki/VTable
Was hat die Implementation mit dem Funktionsprinzip zu tun?
Genau so könntest du behaupten, "Auto fahren" ist das gleiche wie "Benzin", weil das Auto ja Benzin für seine Funktion benötigt. Völliger Schwachsinn also.