Hallo,
ein C Buch durchzuarbeiten und ein bisschen damit herumexperimentieren
ist eine Sache, mit C ein richtiges Programm zu schreiben, eine ganz
andere Sache. Mir fehlt es nicht an Verständnis sondern mir fehlt ein
Konzept wie ich C benutzen soll. Wie sieht modernes C aus? Jeder kennt
diese prähistorische prozeduralen C-Codebeispiele, aber das ist nicht so
der Hit, wenn das Programm mal ein bisschen größer wird, leidet die
Übersicht doch schnell darunter. Deshalb wurde wohl auch OOP und C++
erfunden. Oder ist PP immer noch konkurrenzfähig? Mir jedenfalls ist C++
überhaupt nicht sympatisch, zu überladen, zu hässlich (Template-Hölle),
wird doch schnell unübersichtlich und die Kompilierzeiten sind ein
Graus. Aber mit C++ kann man halt tolle Sachen machen, wie z.B.
SmartPointer (RAII). Leider vermisst man doch schnell die guten Seiten
von C++, sowas wie SmartPointer kann man in C einfach nicht so toll
umsetzen, da fehlt einfach der automatische Destruktoraufruf. Sowas muss
man in C halt selbst erledigen, wenn man das aber mal schnell vergisst,
gibts gleich ein Speicherleck. Solche modernen Techniken fehlen mir in C
einfach. Deshalb kann ich mich zwischen C und C++ nicht entscheiden.
Die Frage ist also, gibt es in C auch solche tollen Techniken/Tricks und
wie sieht modernes C aus? Ich hab mir schon mal den Quellcode von
Blender runtergeladen und angeschaut, um allerdings schlau daraus zu
werden, muss man sich richtig hineinarbeiten.
Danke.
Geht mir mit C++ genau so, deswegen bleib ich auch lieber bei C.
Ein schönes Beispiel ist z.B. DirectFB:
http://directfb.org/index.php?path=Development%2FSource+Code%2FGIT+Access
SDL ist glaub ich auch recht sauber:
http://www.libsdl.org/download-1.2.php
Habe mir auch angewöhnt, alles in verschiedene structs aufzuteilen die
dann mit typedef definiert werden. Die Funktion bekommt dann immer nen
Pointer auf ihren Kontext. Um das destroy muss man sich natürlich noch
selber kümmern, aber so hat man nicht kiloweise globale Variablen und
kann mehrere Instanzen anlegen.
Danke hunz das sind wirklich gute Beispiele, die werd ich mir genauer
anschauen.
Das Prinzip mit den Strukturen als Klasse habe ich mir auch schon
angewohnt. Ich habe auch schon angefangen mir ein kleines Framework zu
schreiben, dass mit solchen Strukturen funktioniert (Strings, etc.).
Selbst ein Exceptionsystem habe ich eingefügt (TRY, CATCH, ENDTRY),
funktioniert auch gut, nur der FINALLY Block fehlt noch. Die
Funktionsspünge werden mithilfe von longjmp() realisiert. Ein throw()
ohne TRY lässt das Programm mit abort() abbrechen. Sowas finde ich
einfach praktisch, da man nicht ständig die Rückgabewerte prüfen muss,
was sehr lästig sein kann. Was mir vorallem fehlt ist ein ausgeklügeltes
Speichersystem, dass die Ressourcen automatisch freigibt wenn sie nicht
mehr benötigt werden, sowas wie SmartPointer eben. Aber so wie es
aussieht muss ich das per Hand machen, immer noch besser als C++. Ich
habe auch versucht in jede "Klasse" einen Referenzzähler einzubauen, ist
allerdings lästig bei jeder Klasse einen zu implementieren. Vielleicht
fällt mir noch was ein.
Christopher schrieb:> [...]
Ich kenne das Problem...
> immer noch besser als C++.
Das ist aber der falsche Ansatz. Du implementierst da Zeugs, das es
schon gut getestet gibt. Benutze doch einfach C++. Es zwingt dich ja
niemand, auch den ganzen STL-Krams mitzunehmen und so weiter.
Das wäre auch m.M.n. das Imageproblem von C++: Mit Templates und
solcherlei kann man ganz wunderbar akademische Kuriositäten
konstruieren, die STL fällt für mich auch darunter. Ich finds schon
toll, was die Sprache alles zu leisten vermag und wie elegant man
komplexe Algorithmen, ja sogar komplette formale Sprachen damit
formulieren kann. Benutzen möchte ich die Ungetüme aber eigentlich
nicht... siehe Boost, zum Bleistift. Warten/pflegen/debuggen möcht ich
das schon dreimal nicht.
Muss ich ja auch nicht. Du auch nicht.
Mit deinen Longjumps da, das hab ich auch schonmal gemacht. Ist aber
weder elegant noch effizient -- letztlich strickst du wieder Krempel mit
Makros um irgendwelche for-Schleifen drumherum. Und umgehst damit wieder
eine Sache, die du gleichzeitig an C++ ankreidest.
Ach und was C angeht: Es gibt Leute, die haben sich damit ernsthaft
auseinandergesetzt und ein paar wichtige Gedanken dazu halbwegs
begriffen. Für alle anderen ist C einfach nur blöd, wie immer.
guenni schrieb im Beitrag #2883508:
> Dann bricht endlich die Ära von lauffähigen Programmen an, welche von> redlichen und aufrichtigen Programmierern angefertigt werden und nicht> von diesem lichtscheuen Kellergesindel mit heftigem Juckreiz im Schritt!
Dann kommt der BWLer mit einem Java ... :-)))
Ich habe schon von Leuten gehört, welche Assembler vergöttern und C
Gefrickel nennen, sonderbare Welt! ;)
Sven P. schrieb:> Mit deinen Longjumps da, das hab ich auch schonmal gemacht. Ist aber> weder elegant noch effizient -- letztlich strickst du wieder Krempel mit> Makros um irgendwelche for-Schleifen drumherum. Und umgehst damit wieder> eine Sache, die du gleichzeitig an C++ ankreidest.
Naja Exceptions sind nicht das, was C++ schlecht macht, nein ich finde
sie sogar nützlich und sinnvoll. Ich habe vor kurzen versucht einen
XML-Tokenizer zu schreiben, das ewige "if (c == EOF) ...;" hat dann
genervt, deshalb habe ich mir gedacht sowas wie try, catch, etc.
einzufügen. Das Problem ist wohl, dass ich aus C versuche C++ zu machen.
Das ist natürlich nicht so sinnvoll. Aber es ist doch genial was alles
mit C möglich ist, oder?
du musst erstmal definieren, was ein "richtiges" programm ist.
jede programmiersprache hat ihren anwendungsbereich.
ich würde spontan zB sagen
c -> hardwarenah/µC
c++ -> hardwarenah, bedingt GUI geeignet (qt: -= bedingt)
.net -> GUI, bedingt hardwarenah
java -> plattformunabhängig
php -> web
du scheinst ja profi zu sein, was C angeht, im gegensatz zu mir (eigtl
c# only).
ich persönlich glaube, dass PP bzw C durchaus noch eine
daseinsberechtigung hat, insbesondere wenn es um performance geht. für
große projekte kann mans aber (als einzelperson) vergessen.
an programmen wie blender oder vlc arbeiten ja ein haufen leute, von
denen jeder seinen fachbereich hat.
insbesondere "quick and dirty" geht mit neueren programmiersprachen
wesentlich besser. der code ist auch besser von aussenstehenden wartbar,
da diese kein großes tieferes verständnis (pointer etc) brauchen.
sorry dass ich die frage nicht beantwortet habe, wollte das einfach mal
loswerden in dem kontext ^^
Vom C Profi bin ich leider noch weit entfernt, ich kenn die C
Standardbibliothek z.B. noch nicht auswendig.^^
Ja natürlich, jede Programmiersprache hat ihren Anwendungsbereich, mit C
möchte ich lieber keine Datenbankanwendung schreiben, das mach ich dann
doch lieber mit C# oder Java.
Das interessante ist, dass ich auch aus der C# Ecke stamme, schon damals
hat mich der Low-Level Bereich fasziniert (OpenGL/DirectX). Mir ist
öfters mal in den Sinn gekommen, mit C oder C++ anzufangen, da diese
Sprachen ja quasi dafür geschaffen sind. Die konnten mich allerdings
nicht überzeugen, ich sah den Sinn einfach nicht. Da ich das alles ja
auch mit C# machen konnte und ich ein riesiges Framework zur Verfügung
hatte. Später fing ich an zum Embedded/µC zu wechseln und da fing ich
mit C richtig an. C wurde zu meiner Lieblingssprache, die ich jetzt auch
auf den Computer nutze, jedenfalls wenns noch um Grafik oder andere
Low-Level Dinge geht, ansonsten C#.
Christopher schrieb:> einzufügen. Das Problem ist wohl, dass ich aus C versuche C++ zu machen.
Genau das tust du gerade.
Und nein: ist nicht sinnvoll.
Da kannst du auch gleich einen C++ Compiler benutzen. Als besseren C
Compiler.
> Das ist natürlich nicht so sinnvoll. Aber es ist doch genial was alles> mit C möglich ist, oder?
Wenn man bedenkt, dass es C++ Compiler gibt, deren Output C ist (die
also C++ auf C zurückführen um dann einen C-Compiler die Drecksarbeit
machen zu lassen), dann ist das weit weniger verwunderlich als du jetzt
denkst.
Christopher schrieb:> Vom C Profi bin ich leider noch weit entfernt, ich kenn die C> Standardbibliothek z.B. noch nicht auswendig.^^
Mußt Du auch nicht, C ist eher eine Denkweise.
Das was der TE sucht lernt man leider nicht in einem Forum. Man kann
Programmiersprachen lernen in dem man ein Buch liest, aber niemals
programmieren oder gar Softwareentwicklung. Wie bei vielem anderen auch,
ist das Kunst und Handwerk in einem und kann nur durch Erfahrung und
Übung erlernt werden.
gruß cyblord
Karl Heinz Buchegger schrieb:> Wenn man bedenkt, dass es C++ Compiler gibt, deren Output C ist (die> also C++ auf C zurückführen um dann einen C-Compiler die Drecksarbeit> machen zu lassen), dann ist das weit weniger verwunderlich als du jetzt> denkst.
gibt es sowas noch?
kannst du einen nennen? ich hatte vor einer weile mal gesucht, bin aber
nicht fündig geworden.
Vlad Tepesch schrieb:> gibt es sowas noch?> kannst du einen nennen?
CFront fällt mir da als aller erstes ein.
Und wenn mich nicht alles täuscht, hat Greg seinen Compiler davon
abgeleitet und weiter entickelt. Such mal nach Greg Comeau C++
Ok, da frage ich mich doch was ist C?
Exception/Try,Catch,... ist kein C, das haben wir ja geklärt.
Aber was ist mit OOP? C ist ja eigentlich von Natur aus prozedural, hat
allerdings auch Werkzeug mit den man sich Objekte basteln kann,
Strukturen + Funktionen, schon hat man die Datenkapselung. Ich denke,
dass C nicht auf PP beschränkt ist.
Was ich damit meine ist:
1
typedefstructObject
2
{
3
inta,b;
4
};
5
6
Object*obj_create(inta,intb);
7
voidobj_destroy(Object*obj);
8
intobj_foo(Object*obj,intbar);
Nur ein Beispiel.
Ist ein SmartPointer C? Klar das Konzept kommt, so denke ich, aus C++.
Und gibt es eine gescheide Implementierung? Oder sollte ich einfach
einen Refernzzähler in meine "Klassen" einbauen? Oder gar darauf
verzichten und altes, bewährtes malloc/free (ich weiß darüber lässt sich
streiten) nutzen?
cyblord ---- schrieb:> Das was der TE sucht lernt man leider nicht in einem Forum. Man kann> Programmiersprachen lernen in dem man ein Buch liest, aber niemals> programmieren oder gar Softwareentwicklung. Wie bei vielem anderen auch,> ist das Kunst und Handwerk in einem und kann nur durch Erfahrung und> Übung erlernt werden.
Ja natürlich hast du da recht, Programmieren ist gute alte Handarbeit,
aber ich habe leider keinen Lehrmeister/Professor der mir erklärt wie
ich vorgehen soll.
Christopher schrieb:> Ok, da frage ich mich doch was ist C?> Exception/Try,Catch,... ist kein C, das haben wir ja geklärt.> Aber was ist mit OOP? C ist ja eigentlich von Natur aus prozedural, hat> allerdings auch Werkzeug mit den man sich Objekte basteln kann,> Strukturen + Funktionen, schon hat man die Datenkapselung. Ich denke,> dass C nicht auf PP beschränkt ist.
Natürlich kannst du das machen.
Das ist ja nicht die Frage. Aber um bei deinem Beispiel zu bleiben:
Nimmst du einen C++ Compiler, dann schreibst du
1
structObject
2
{
3
Object(inta,intb);
4
~Object();
5
6
inta,b;
7
8
intobj_foo(intbar);
9
};
und hast #genau# das gleiche. D.h. fast. Denn in deinem C-Beispiel
darfst #DU# nicht vergessen, die create bzw. destroy Funktion
aufzurufen. In C++ KANNST du es nicht vergessen, weil sich der Compiler
darum kümmert, dass der Constructor bzw. Destructor aufgerufen wird.
Aber ansonsten ist das 1:1 identisch zu deinem C-Beispiel.
> Ist ein SmartPointer C? Klar das Konzept kommt, so denke ich, aus C++.> Und gibt es eine gescheide Implementierung? Oder sollte ich einfach> einen Refernzzähler in meine "Klassen" einbauen? Oder gar darauf> verzichten und altes, bewährtes malloc/free (ich weiß darüber lässt sich> streiten) nutzen?
Der springende Punkt ist auch hier:
Damit das alles ordentlich funktioniert MUSST du deinen C-Programmierer
in die Pflicht nehmen. Er DARF NICHT vergessen die entsprechenden
Funktionen auch aufzurufen.
In C++ kümmert sich aber der Compiler darum, dass Ctor und Dtor
aufgerufen werden. Und zwar IMMER. Wird ein Objekt erzeugt, wird ein
Constructor aufgerufen. Wird ein Objekt zerstört, zb weil es aus dem
Scope geht, wird der Destructor aufgerufen. Du kannst das nicht
vergessen und hast damit einen Teil der Verantwortung an den Compiler
übertragen, der das rigoros durchzieht. Der C++ Compiler kann dich in
dem Sinne unterstützen, indem er dir stupide #MUSS# Regelungen abnimmt,
die man als menschlicher Programmierer schon gerne mal vergisst.
Wenn du in diese Richtung gehen willst, dann würde ich dir sehr ans Herz
legen, deinen C-Compiler beiseite zu legen und dir statt dessen einen
C++ Compiler zu nehmen. Niemand sagt, dass du sofort mit Templates
rummachen musst. Du kannst im wesentlichen erst mal so weiter
programmieren, wie du es von C gewohnt bist. Nur eben mit den kleinen
'Hilfen', die dir C++ zb in Form der Ctors und DTors an die Hand gibt.
In diesem Sinne programmierst du zwar immer noch so gesehen C, hast aber
einen zusätzlichen Nutzen durch die Verwendung des C++ Compilers. Und im
Laufe der Zeit, wirst du noch so manch andere Feature von C++ kennen und
schätzen lernen.
Das man diese Dinge mit C auch machen kann, steht ausser Frage.
Natürlich kann man. Aber es ist ein Unterschied ob ich als Programmierer
dabei keinen Fehler machen darf, oder ob mir der Compiler die Dinge von
vorne herein fehlerfrei implentiert, mich so entlastet und ich mich um
das eigentliche Problem, die Programmlogik kümmern kann.
Karl Heinz Buchegger schrieb:> CFront fällt mir da als aller erstes ein.> Und wenn mich nicht alles täuscht, hat Greg seinen Compiler davon> abgeleitet und weiter entickelt. Such mal nach Greg Comeau C++
das kostet ja geld
Ja zum Einen bin ich von den C++ Features angetan und zum Anderen bin
ich von C++ abgestoßen. Ich denke, dass ich C++ doch noch eine Chance
geben sollte und dass es eigentlich sinnvoller wäre C++ zu nehmen.
C++ ist bei Weitem komplexer als C!
Und dabei ist C ja schon nicht so einfach.
Nachdem ich nun seit einem halben Jahr in der Arbeit nur noch C++
programmiere, möchte ich nicht mehr zu C wechseln. Der Umstieg war hart,
aber die Möglichkeiten von C++ sind doch viel größer.
Templates machen auch Sinn, genauso wie die STL absolut spitze ist -
wenn man sich mal damit beschäftigt hat. vector<T> ist seitdem mein
bester Freund geworden;-)
Mit malloc/free (new/delete) kommt man zum Glück auch seltener in
Berührung durch Verwendung von boost::shared_ptr<T> und vector (oder ein
anderer STL Container) als Ersatz für dynamsiche Arrays.
Insgesamt würde ich dir raten, dich nochmal mit C++ genau
auseinanderzusetzen. Wenn du danach sagst, dass es nichts für dich ist,
ok.
Aber nur mal schnell C++ überfliegen bringt nichts. Man muss sich schon
mal ein paar Wochen hinsetzen und auch was programmieren, um die
Grundprinzipien zu verstehen!
Buchtipp: "Der C++ Programmierer"
Jedenfalls lernst du mit C++ wirklich ordentlich programmieren, im
Gegensatz zu solch komischen Erfindungen wie C#.
Was viele einfach nicht verstehen wollen, ist:
C++ hat vieles, was man nicht nehmen MUSS - wenn es nicht angemessen
ist.
Man kann sich von allen Features genau die nehmen, die gerade sinnvoll
sind.
Nimmt man keine, heißt der Quelltext halt .cpp statt .c und fertig,
keine Erweiterungen, keine Nachteile.
Echte OOP-Programmierung wird das erstmal nicht, aber dafür soviel
Fortschritt gegenüber C wie man möchte.
Gerade bei uC-Programmierung pickt man sich das heraus, was dafür gut
ist, und ignoriert einfach den ganzen Rest.
Wenn ein AVR nicht mit Exceptions und der STL zurecht kommt, wäre es
borniert, deshalb auf Klassen und templates zu verzichten.
Von den vielen kleinen nicht-OOP-Verbesserungen ganz zu schweigen.
Ich kann nicht verstehen, daß Leute immer noch über reines C schimpfen,
es aber trotzdem nehmen.
Vlad Tepesch schrieb:> gibt es sowas noch?> kannst du einen nennen? ich hatte vor einer weile mal gesucht, bin aber> nicht fündig geworden.
Comeau. Das dürfte auch quasi der einzige C++-Compiler sein, der C++
wirklich nahezu vollständig unterstützt, einschließlich externer
Templates. Da scheiter(te)n fast alle anderen nämlich dran.
Klaus Wachtler schrieb:> Ich kann nicht verstehen, daß Leute immer noch über reines C schimpfen,> es aber trotzdem nehmen.
Dann erkläre ich es dir:
Die Leute benutzen C eben notgedrungen, weil nix besseres in greifbarer
Nähe ist. Vor rund 25 Jahren ist in der Programmiererwelt ne
Entscheidung für C und gegen Pascal gefallen und nun haben wir seitdem
den Salat, aus dem die Welt auch nicht mehr herauskommt. Das ist
schlichtweg bedauerlich und durchaus ein Grund, auf C zu schimpfen und
es dennoch benutzen zu müssen.
Sag jetzt nicht, C++ oder C# wären eine grundlegende Verbesserung der
Lage. Es ist immer nur Herumgefrickel an all den Unzulänglichkeiten von
C, die damals den Programmierern ja so toll erschienen sind. C++ ist in
meinen Augen keine Verbesserung, eher eine Verschlimmbesserung, weil es
sämtliche Geburtsfehler und Seiteneffekte von C immer noch mit sich
herumschleppt und noch zusätzliche Seiteneffekte mitbringt. Wie schön,
wenn alloziierte Objekte beim Verlassen eines Blockes implizit wieder
beseitigt werden und der Konstruktor den Namen seiner Klasse hat, aber
das alles macht C++ Programme noch unleserlicher als sture C-Quellen.
Ich versuch's mal ganz deutlich zu formulieren: Je mehr wir in die
Zukunft kommen, desto dringender wird es, daß eine Programmiersprache
selbstdokumentierend wird, möglichst frei von Seiteneffekten ist und
möglichst wenig zu erlernende (weil sich nicht durch LESEN erklärende)
Bestandteile hat. Das wird derzeit mißachtet, wohl weil die Insider der
Ansicht sind, daß die Lern- und Versteh-Schwelle ruhig ganz hoch sein
darf, aber in zunehmendem Maße fällt es allen auf die Füße, weil genau
dadurch immer mehr dilettantischer Code seinen Weg in die Produkte
findet.
Vergleiche doch mal C++ mit Pascal, so wie es vor 10 Jahren als Sprache
für Delphi 4..7 und derzeit von FreePascal definiert ist. Da macht C++
keine gute Figur. Bloß ne Reihe von oberfaulen Programmierern nörgeln,
daß man dort ja "begin" schreiben muß und das ist ihnen zu aufwendig.
W.S.
Was soll diese Diskussion hier? Du kannst doch Pascal nehmen, wenn du
willst.
Ich halte es für eine tolle Sprache, aber nicht zum Programmieren,
sondern zum Lernen. Aber jeder, wie er will.
Was Pascal ermöglicht, ist ein müder Witz gegen das, was in C geht -
wenn man C kann.
Nichtsdestotrotz kann C++ mehr (vor allem mehr automatisieren) als C,
also kann man das doch auch nutzen.
PS: mich stören begin und end überhaupt nicht. Ich schreibe nichtmal die
geschweiften Klammern in C einzeln, sondern paarweise mit einer Taste im
Editor meiner Wahl - dann stehen sie wenigstens paarweise da, in
getrennten Zeilen und sauber eingerückt.
In Pascal würde ich mir halt begin und end auf diese Taste legen.
Klaus Wachtler schrieb:> Was viele einfach nicht verstehen wollen, ist:>> C++ hat vieles, was man nicht nehmen MUSS - wenn es nicht angemessen> ist.
Leider begreifen das auch so manche recht bekannte Leute wie Linus
Torvalds nicht. Wenn der C++ öffentlich verteufelt, hat das natürlich
eine gewisse Wirkung auf andere Entwickler. Der nennt unter anderem die
Exceptions als Grund, warum seiner Meinung nach C++ in einem Kernel
grundsätzlich nichts zu suchen hat. Alles, was er an Gründen nennt, ist
fadenscheinig. Er mag einfach C++ nicht, oder er hat sich zuwenig damit
beschäftigt, um es überhaupt beurteilen zu können. Meiner Meinung nach
ist C++ prima für einen Kernel geeignet, und im Linux-Kernel werden zum
Teil auch OOP-Konzepte verwendet, die in C++ viel eleganter umsetzbar
wären.
Georg A. schrieb:>> und dass es eigentlich sinnvoller wäre C++ zu nehmen.>> Genau. Zumindest um schon mal die //-Kommentare rechtmässig verwenden zu> dürfen ;)
Die darf man in C seit 13 Jahren rechtmäßig verwenden, weil sie in C99
offiziell in den Sprachumfang aufgenommen wurden. Es gibt aber wohl
immer noch Compiler, die das unrechtmäßigerweise nicht können. C89/C90
wurde offiziell abgeschafft und exstiert nicht mehr. Wenn ein Compiler
nur dazu kompatibel ist, ist das im Bezug auf Standard-Konformität also
rein gar nichts wert. Das gilt inzwischen übrigens auch für C99, das
inzwischen durch C11 ersetzt wurde.
1. "Modern" ist in der IT eher ein Schimpfwort, das bedeutet, dass was
noch nicht durchdacht ist und man einfach einem Trend hinterherläuft.
2. Wenn Du Deinen Stil suchst, lese Dir doch mal "The Art of Unix
Programming" durch. http://www.faqs.org/docs/artu/ Der legt da relativ
fundierte Meinungen dar, die Du in Deinen Entscheidungsprozess mit
einfließen lassen kannst.
OK ich glaub C++ hat mich überzeugt.
Ich hab mal eine kleine Anwendung geschrieben, die ein Fenster mit der
WinAPI öffnet und beim Fenster Schließen sich beendet. Dazu wurde eine
eigene Fensterklasse geschrieben, in der man auch den Titel einstellen
kann. Ich lass die Details mal aus.
Das Programm wurde in C und C++ vom Aufbau haargenau aufgebaut.
Ausnahme: bei C++ wurde die STL benutzt.
Die Programmgröße:
C++ (VSC /O2): 15kB (bei /O1 14kB)
C (gcc -O3): 57kB !!!! auch bei -Os
Ich dachte C macht es sich zur Aufgabe kleine Programme zu erzeugen.
Zudem war es relativ mühselig die C-Variante zu schreiben. Dann kommt
noch dazu, dass ich vergessen habe den Destruktor aufzurufen. Is zwar
nicht so schlimm, da der sowieso am Programmende hätte kommen müssen und
sich dann Windows drum kümmert, aber ihr wisst sicher was ich meine.
Bei C++ hab ich einfach std::unique_ptr<Window> benutzt und konnte
nichts vergessen. Ich denke, dass ich meine Wahl getroffen habe.
Aber der riesen Unterschied der Programmgröße kann irgendwie nicht sein,
die C++ Version habe ich einfach mit VS2012 erstellt (Win32-Anwendung).
Hier meine build.bat (C-Version):
Christopher schrieb:> Vielleicht liegts am Linkverfahren? VSC linkt dynamisch?
MS verwendet üblicherweise DLLs als Runtime Libs für die normalen
Libfunktionen. GCC meist nicht.
Stimmt. Habs in den Einstellungen gefunden.
C++: 70kB
Auch nicht so schlimm, ich bleib trotzdem bei C++.
Ist es zu empfehlen Vorkompilierte Header zu verwenden? Etwas Unbehagen
hab ich schon, normalerweise gilt die Regel: Header einbinden wo es
wirklich notwendig ist. Allerdings finde ich, dass Header bei C++
unnötig sind, da es Namespaces gibt. Ein Modulsystem täte C++ gut.
Christopher schrieb:> Stimmt. Habs in den Einstellungen gefunden.> C++: 70kB>> Auch nicht so schlimm, ich bleib trotzdem bei C++.> Ist es zu empfehlen Vorkompilierte Header zu verwenden?
Ja.
Die Compilezeiten sinken schon um einiges.
> Etwas Unbehagen> hab ich schon, normalerweise gilt die Regel: Header einbinden wo es> wirklich notwendig ist.
Das Problem sind nicht >deine< Header.
Das Problem sind die Windows Header. Da ziehst du dir erst mal
Zig-Kilobytemässig immer gleiche Header Files rein, die praktisch
gesehen in jedem CPP File durch den Präprozessor geschleust werden
müssen. Und ich möchte hinzufügen: sinnloserweise, denn diese Header
ändern sich ja nicht.
Dev Studio macht das schon richtig. In dem Punkt darfst du ihm
vertrauen. Precompiled Header Files werden so verpackt, dass der
Präprozessor den ganzen Wust, der damit zusammenhängt, nicht jedesmal
neu begutachten muss.
> Allerdings finde ich, dass Header bei C++> unnötig sind, da es Namespaces gibt.
Das eine hat mit dem anderen nichts zu tun.
> Ein Modulsystem täte C++ gut.
Das allerdings.
C++ aber auch C sind so ausgelegt, dass man keine IDE benötigt um
trotzdem effizient arbeiten zu können. Daher dieses Header-File System.
Ist zwar eine Krücke, aber funktioniert auch dann noch gut, wenn alles
was du hast eine Command Line, ein Compiler, Linker und ein Make ist.
> C++ aber auch C sind so ausgelegt, dass man keine IDE benötigt um> trotzdem effizient arbeiten zu können. Daher dieses Header-File System.
Verstehe ich nicht. Java hat kein Header-System, kann aber genauso ohne
IDE auf der Console entwickelt werden, nämlich mit dem Befehl javac.
Das halte ich sogar effizienter, da man nicht *.h und *.c parallel
pflegen muss.
Jürgen W. schrieb:>> C++ aber auch C sind so ausgelegt, dass man keine IDE benötigt um>> trotzdem effizient arbeiten zu können. Daher dieses Header-File System.>> Verstehe ich nicht. Java hat kein Header-System, kann aber genauso ohne> IDE auf der Console entwickelt werden, nämlich mit dem Befehl javac.
Ja. Heute.
Vor 40 Jahren (und soweit liegen die Wurzeln zurück) war das aber
anders. Damals wurde die Taktfrequenz selbst von Grossrechnern noch im
einstelligen Mega-Herz Bereich gemessen. Und von Hauptspeichergrößen,
den Kosten dafür, Plattenzugriffszeiten bzw. was das Megabyte
Plattenplatz gekostet hat, reden wir mal lieber nicht.
Was du heute wie selbstverständlich auf dem Schreibtisch stehen hast,
hängt jedes Rechenzentrum von vor 30 Jahren aber locker ab. Und zwar in
allen Belangen.
A. K. schrieb:> MS verwendet üblicherweise DLLs als Runtime Libs für die normalen> Libfunktionen.
MS verwendet das, was bei den Linkeroptionen eingestellt ist, und kann
daher problemlos auch statisch gelinkte Programme erzeugen.
W.S. schrieb:> ag jetzt nicht, C++ oder C# wären eine grundlegende Verbesserung der> Lage. Es ist immer nur Herumgefrickel an all den Unzulänglichkeiten von> C, die damals den Programmierern ja so toll erschienen sind.
die da wären?
W.S. schrieb:> desto dringender wird es, daß eine Programmiersprache> selbstdokumentierend wird, möglichst frei von Seiteneffekten ist und> möglichst wenig zu erlernende (weil sich nicht durch LESEN erklärende)> Bestandteile hat.
moment, c++ und c# sind doch keine grundlegende verbesserungen oder?
hust
> Die Leute benutzen C eben notgedrungen, weil nix besseres> in greifbarer Nähe ist.
So ein Quatsch.
Sie benutzen es, vor allen Dingen in der µC Szene, weil es eine gesunde
Mischung zwischen der Abstraktheit ist, die mit einer Hochsprache einher
geht, und der Präzission die man mit Assembler hat.
Auf der einen Seite das Loslassen von den vielen kleinen Details, mit
denen man sich in Assembler rumschlagen muss. Auf der anderen Seite aber
noch nicht weit genug von Assembler entfernt, um die Kontrolle über die
CPU vollständig aufzugeben.
Da draussen gibt es tausende Programmiersprachen. Und gegen viele davon
kannst du mit deinem Pascal brausen gehen.
Jürgen W. schrieb:>> C++ aber auch C sind so ausgelegt, dass man keine IDE benötigt um>> trotzdem effizient arbeiten zu können. Daher dieses Header-File System.>> Verstehe ich nicht. Java hat kein Header-System, kann aber genauso ohne> IDE auf der Console entwickelt werden, nämlich mit dem Befehl javac.>> Das halte ich sogar effizienter, da man nicht *.h und *.c parallel> pflegen muss.
Hmm, also ich empfinde es als Vorteil, Code und Interface sauber
getrennt halten zu können und nicht sämtlichen Funktionscode in einem
einzelnen großen File in die Klassendefinition reinverwursten zu müssen.
> und nicht sämtlichen Funktionscode in einem einzelnen großen File
Dass man Klassen nicht auf mehrere Dateien aufteilen kann, verstehe ich
nicht. C# kann das.
Wobei es bei sauberem strukturiertem Code nicht oft diese
"Riesenklassen" ohne Substrukturen gibt.
Jürgen W. schrieb:> Dass man Klassen nicht auf mehrere Dateien aufteilen kann, verstehe ich> nicht.
Warum sollte man das nicht können? Lediglich die Deklaration darf
nicht aufgeteilt werden, die Implementierung aber kann in so viel
Dateien untergebracht werden, wie es Memberfunktionen gibt.
Ich meinte, dass man es mit Java nicht kann.
http://stackoverflow.com/questions/2764234/partial-classes-partial-class-file
Aber es ging um das Headersystem, aber das Headersystem hat nichts mit
der Frage zu tun, ob man eine Klasse auf mehrere Dateien aufteilen kann
oder nicht.
Für mich war dies nie relevant, auch unter C# nicht.
Frank Meier schrieb:> die da wären?
Betriebsblind geworden, gelle?
Ich nenn mal ne Kleinigkeit: Datentypen, Seiteneffekte.
und...
Karl Heinz Buchegger schrieb:> So ein Quatsch.> Sie benutzen es, vor allen Dingen in der µC Szene, weil es eine gesunde> Mischung zwischen der Abstraktheit ist, die mit einer Hochsprache einher> geht, und der Präzission die man mit Assembler hat.
Du tust ja gerade so, als ob man heutzutage die Wahl hätte. Ich sag mal
dazu: weltfremd. Für die allermeisten uC kriegst du nix anderes als C
und Assembler - und das isses. Den "Quatsch" geb ich die postwendend
zurück.
Jaja, man kann sich auch an C gewöhnen und es benutzen (wahrscheinlich
wird C länger in dieser Welt sein als C++, C#, Java und sonstwas
zusammen), aber halte es für ausgesprochen trollhaft, darüber zu
vergessen, gelegentlich über den Tellerrand zu schauen und C nebst
seinen Kindern mal mit dem nötigen kritischen Abstand zu sehen. Siehe
oben: Betriebsblindheit. Teste dich mal selbst, indem du dich fragst,
wie häufig du in derzeitigen C-Programmen bei Variablendeklarationen
Bezeichnungen wie u32, uint8, uint16 oder wie sie auch immer heißen
mögen gesehen und dabei "jaja, klar doch" gedacht hast. Hast du dich nie
gefragt, warum dort nicht schlicht long, byte, int steht? Ja klar, es
sind Workarounds um einen der Geburtsfehler von C bei den Datentypen
herum. Das ist nur ne Kleinigkeit, die aber zeigt, wie sehr C-Quellen
heutzutage mit Workarounds vollgestopft sind, die man schlichtweg
benötigt (oder zu benötigen glaubt). Wenn du dies für ne gesunde
Mischung aus Abstraktheit und Präzision hältst, dann machst du mich
grausen.
W.S.
W.S. schrieb:> Die Leute benutzen C eben notgedrungen, weil nix besseres in greifbarer> Nähe ist.
Also ist C deiner Ansicht nach zwar nicht der Weisheit letzter Schluss,
aber das Beste, was derezeit verfügbar ist? Damit widersprichst du
vermutlich keinem der Threadteilnehmer.
> Vor rund 25 Jahren ist in der Programmiererwelt ne Entscheidung für C> und gegen Pascal gefallen
Da die Entscheidung sehr einhellig war, muss es wohl triftige Gründe
dafür gegeben haben.
> und nun haben wir seitdem den Salat, aus dem die Welt auch nicht mehr> herauskommt.
Warum sollte die Welt aus C nicht wieder herauskommen? Sie ist auch aus
Fortran (weitestgehend) herausgekommen, obwohl es lange Zeit nicht
danach aussah. Aber es muss halt erst ein Konkurrent kommen, der die
Softwareentwickler wirklich vom Hocker reißt. Bisher lässt er noch auf
sich warten.
> Ich versuch's mal ganz deutlich zu formulieren: Je mehr wir in die> Zukunft kommen, desto dringender wird es, daß eine Programmiersprache> selbstdokumentierend wird, möglichst frei von Seiteneffekten ist und> möglichst wenig zu erlernende (weil sich nicht durch LESEN erklärende)> Bestandteile hat.
Da hast du meine volle Zustimmung. Was wären denn deine Vorschläge?
Aber doch nicht etwa Pascal:
> Vergleiche doch mal C++ mit Pascal, so wie es vor 10 Jahren als Sprache> für Delphi 4..7 und derzeit von FreePascal definiert ist.
Nein, an Pascal ist doch seit dessen Entstehung noch sehr viel mehr
herumgedoktert worden als an C. Nebeneffekte ("Seiteneffekt" soll man ja
nicht mehr sagen, habe ich vor kurzem gelernt) gibt es in Pascal genauso
wie in C, und vom Ziel, selbstdokumentierend zu sein, ist auch Pascal
noch Lichtjahre entfernt.
W.S. schrieb:> Du tust ja gerade so, als ob man heutzutage die Wahl hätte. Ich sag mal> dazu: weltfremd. Für die allermeisten uC kriegst du nix anderes als C> und Assembler - und das isses.
Hmm, ich sehe da Pascal-Compiler für AVR, PIC, ARM, PPC, SPARC, x86 ...
Für die meisten davon gibt es sogar gleich mehrere zur Auswahl. Man
könnte sie nutzen, wenn man nur wollte. Außerdem gibt es noch Basic, und
für die größeren Controller, die gut mit Speicher ausgestattet werden,
kannst du dir fast jede Programmiersprache aussuchen, für die es eine
Community von mindestens ein paar tausend Leuten gibt.
> Teste dich mal selbst, indem du dich fragst, wie häufig du in> derzeitigen C-Programmen bei Variablendeklarationen Bezeichnungen wie> u32, uint8, uint16 oder wie sie auch immer heißen mögen gesehen und> dabei "jaja, klar doch" gedacht hast.
Was soll an int8_t, uint16_t usw. schlecht sein? Das sind offzielle
Datentypen in C, die immer dann genutzt werden, wenn die tatsächliche
Bitbreite von Variablen von Bedeutung ist.
> Hast du dich nie gefragt, warum dort nicht schlicht long, byte, int> steht?
Diese werden (mit Ausnahme von byte, das kein C-Datentyp ist) mindestens
genauso oft benutzt, je nach Verwendung der entsprechenden Variablen.
> Ja klar, es sind Workarounds um einen der Geburtsfehler von C bei den> Datentypen herum.
Ich würde das weder als Geburtsfehler noch als Workarounds bezeichnen.
Es hat sich eben im Lauf der Zeit herausgestellt, dass insbesondere bei
der µC-Programmierung weitere Datentypen sinnvoll sind. Wo ist das
Problem? Nenne mir eine Programmiersprache, die von Anfang an perfekt
war und keinerlei Nachbesserungen bedurfte.
Rohr Frei schrieb:> C ist out, AA ist der neue Hype!
Wie kommst du jetzt auf AA?
http://en.wikipedia.org/wiki/Atlas_Autocode
Ich lese den Namen heute zum ersten Mal :)
Yalu X. schrieb:> Also ist C deiner Ansicht nach zwar nicht der Weisheit letzter Schluss,> aber das Beste, was derezeit verfügbar ist?
Du sprichst mir so einigermaßen aus dem Herzen. Und ich dachte schon,
hier treiben sich nur Fanboys herum. Ich würde es aber nicht "das Beste"
nennen, so toll finde ich C nicht. Sag also lieber "benutzbar", das ist
realistischer.
Und was Pascal versus C betrifft: Vergleiche mal K&R mit heutigem C++,
da sind genauso große Unterschiede wie zwischen Wirth's erstem Entwurf
und dem, was seit Delphi3 sich als Quasistandard etabliert hat. Trotzdem
ist Pascal in sich konsistenter und hat auch das Erfinden der
objektorientierten Programmschreiberei besser überstanden als C. Gelle?
Nebenbei gefragt: Kann mir jemand irgendeine Aufgabe nennen, die man mit
C besser als mit Pascal lösen kann? Aber Pascal war nur ein Beispiel für
ne real existierende Alternative und ist nicht der Gegenstand der
Diskussion.
Die Frage, was modernes C sei, kann man sehr einfach beantworten: RTND
(read the newest document), aber ich denke, es steht eine ganz andere
Frage dahinter:
"Wie soll es weiter gehen?"
Da sehe ich nämlich nichts, was wirklich weiterbringt. Ist C++ oder C#
das 'bessere' C? oder kommt nächstes Jahr ein tolles C$$ heraus, was
noch vieeeeel besser ist? Nee, das ist es alles NICHT - und so wie ich
das sehe, gibt es bei C kein wirkliches Verbesserungspotential. Soll
nicht heißen, daß C mittlerweile die ideale Programmiersprache ist,
sondern daß man zum Einführen von echten Verbesserungen so viel von der
bisherigen Substanz einreißen müßte, daß es wohl besser sein wird, ganz
neu anzufangen. Vorschläge für nen neuen Sprachnamen sind willkommen...
So, ich hätte da schon einiges (zum Stänkern):
- Preprozessor abschaffen. Was es zu deklarieren und zu definieren geben
soll, soll sich gefälligst in der Sprachkonstruktion finden und nicht
irgendwelcher Text-Ersetzen-Akrobatik anheimgestellt werden.
- verläßliche Datentypen schaffen. Datentypen sollen von der Sprache
definiert sein und nicht von der Maschine abhängen. Dafür sollten die
Datentypen allerdings ne saubere Benennung haben und nicht
zusammengestückelt werden müssen. unsigned long long ist ein Krampf -
und das Mitschleppen von sowas wie struct ist ebenfalls ein Krampf. Wenn
man schon einen Datentyp kreiert hat, dann sollte dessen Bezeichner im
folgenden Text ausreichen. Sowas wie typedef ist dann überflüssig.
- Den Wert von Anweisungen abschaffen. Sowas wie "if(A=B)" wird aus
gutem Grunde von fast jedem modernen Compiler beanstandet, weil es sich
in vielen Jahren herausgestellt hat, daß es zu 99.9% ein Schreibfehler
war und weil heutzutage ein Compiler viel besser optimieren kann als ein
Quellcode-Schreiber. All diese scheinbar so tollen Optimierungen in der
Quelle, die damals angedacht wurden (a+=b; ? Operator uvm.), weil man
glaubte, damit dem Compiler die Arbeit zu erleichtern, sind heutzutage
überflüssig wie ein Blinddarm.
- Case-Sensitivität abschaffen. Ich kenne Quellen, wo besonders tolle
Gurus sowas bis zum Erbrechen zelebriert haben, nur um Nachfolgenden
Generationen das Lesen ihrer Poeme zu erschweren.
- echte Strings und Abschaffung der bisherigen Krampflösung. Hat
eigentlich schon mal jemand nachgedacht wie unsäglich oft strlen
gebraucht wird und dann jedesmal wieder alle Zeichen im Puffer
nachzählt? Ressourcenverschwendung auf höherem Niveau.
So, genug gemosert für heute Abend.
W.S.
Klassische Desktop-Software mit GUI würde ich heutzutage nicht mehr
unbedingt in C entwickeln wollen, ...
Da greife ich dann doch lieber zu einem von diesen Kandidaten:
C++/Qt
Java/Swing
C#/WPF
Moin,
da will ich auch mal meinen Senf dazugeben.
Ich kann überhaupt nicht verstehen, warum hier so viele was gegen C
haben. Das ist eine wunderbare Programmiersprache mit nur wenigen
reservierten Wörtern wodurch ein paar schöne Effekte entstehen:
• es kann mit vergleichsweise wenig Aufwand ein guter C-Compiler für
fast jede Plattform erstellt werden
• klasse Geschwindigkeit für Programme und Libs
• in C ist auch OOP möglich, nur eben anders als von C++ gewohnt
(z.B. die Enlightenment Foundation Libraries (EFL) sind großartig
designte C-Bibliotheken)
• Debuggen ist in C göttlich simpel, verglichen mit C++ mit virtuellen
Methoden
• viele Laufzeitschweinereien die es in C++ gibt, entfallen, wenn man
sich an die Programmierparadigmen der Programmiersprache C hält (z.B.
Datenaustausch zwischen DLLs über STL-Container und
Allokationen/Deallokationen über DLL-Grenzen hinweg)
• das ABI ist in C++ noch viel komplexer als in C, korrupte Interfaces
durch veraltete Header/Lib-Kombinationen in verschiedenen Namespaces ist
ganz großer Mist in C++
• mal versucht, C++-Exporte aus Namespaces aus DLLs heraus zu
importieren? Viel Spaß! Und noch mehr Freude gibts, wenn die zu
importierende C++-DLL mit'm Visual Studio und der Importer mit GCC
erstellt wurde... dann sind Bißspuren im Keyboard ganz normales
Programmiererverhalten.
• je näher es Richtung Treiber geht, desto besser muss mit Allokationen
gehaushaltet werden (Paged/Non-Paged und der ganze Mist), ist man C
gewohnt, keine große Umstellung
• mal Ada programmiert oder VHDL synthetisiert/implementiert? Was nützen
tausend und fünf tolle Sprachkonstrukte wenn man sie seltenst gebraucht?
Da ist ein kleiner Sprachkern wie in C herrlich. Geht fast bissl in die
Richtung CISC vs. RISC (Hennessy/Patterson-Studie), nur eben auf
Programmiersprachen-Ebene, also komplexer Sprachumfang vs. geringer
Sprachumfang
Man kann ruhig über C schimpfen, es macht einen Haufen Arbeit, vor allem
im String-Verhalten, wenn man den Komfort der STL-Container gewohnt ist
oder in der C++-Templateprogrammierung mit einem geschickten Template
eine generische/universelle Lösung für ein Problem finden kann oder
Operatoren überlädt für eigene Datentypen. Und C alleine garantiert
keinen effizienten Code.
Aber dennoch: C hat gegenüber C++ mitunter große Vorteile. Schaut man
mal die SQLite, die ZBar oder die oben erwähnte EFL an, sind das
Musterbeispiele für Cross-Platform-Bibliotheken auf Embedded-Systemen.
Ingesamt gesehen: auf PCs für den größten Teil der Anwendungsentwicklung
ist Java oder .NET der Weg der Dinge, der in kürzerer Zeit wartbarere
Resultat hervorbringt. Daher sollten schon die Anforderungen gescheit
abgeschätzt werden und nicht so eine pauschale Diskussion a la: "Sprache
A is viel schneller", "Sprache B ist scheiße", "Sprache N ist toll" oder
ähnliches geführt werden. Entscheidend ist der Zweck und was dabei
rauskommt, alles andere sind wohl akademische Eitelkeiten.
Falk (DB8FS) schrieb:> Anwendungsentwicklung> ist Java oder .NET
Kann mir mal wer die Java immer nachgesagte Bedeutung erklären? Ich hab
mal meinen Paketmanager gefragt, was denn alles so von java abhängt:
$ pacman -Qi openjdk6
[...]
Required By : funambol funambol-admin
Also server-software.
W.S. schrieb:> - Preprozessor abschaffen. Was es zu deklarieren und zu definieren geben> soll, soll sich gefälligst in der Sprachkonstruktion finden und nicht> irgendwelcher Text-Ersetzen-Akrobatik anheimgestellt werden.>> - verläßliche Datentypen schaffen. Datentypen sollen von der Sprache> definiert sein und nicht von der Maschine abhängen.> - echte Strings und Abschaffung der bisherigen Krampflösung. Hat> eigentlich schon mal jemand nachgedacht wie unsäglich oft strlen> gebraucht wird und dann jedesmal wieder alle Zeichen im Puffer> nachzählt? Ressourcenverschwendung auf höherem Niveau.
Mit den Punkten kannst du dann aber die hardwarenahe programmierung
vergessen. Und genau da punktet C doch. Ohne Präprozessor kannst du auf
Maschinen mit begrenztem Speicher nicht ordentlich programmieren.
Und das Datentypen eben doch von der Maschine abhängen ergibt sich aus
der Realität. Und eine Strinverarbeitung auf dem Niveau von Java und C#
kannst du eben auf kleinen Controllern auch nicht machen. C muss
hardwarenah sein. Für alles andere kann man ja dann was anderes nehmen.
gruß cyblord
Im Endeffekt wird der Maschinencode ausgeführt, nichts anderes.
Es geht darum diesen effizient zu erstellen. C ist da mE unschlagbar.
schnell, flexibel und es kann einfach alles ohne mich auszubremsen.
LOL
Programmiert doch in EIFFEL da kann man auch gleich die Varianten und
Invarianten vom Compiler überprüfen lassen.
Achja der macht auch C-Code draus, teilweise mit echt
"gewöhnungsbedüftigen" Konstruktionen.
Und dann gibt es da noch diverse UML Pakete die dann aus den grafischen
Darstellungen JAVA/C++ oder anderen objektorientierten Code erzeugen.
Aber C ist schon schön "shoot yourself in the foot" -> BANG
Falk (DB8FS) schrieb:> • mal Ada programmiert oder VHDL synthetisiert/implementiert? Was nützen> tausend und fünf tolle Sprachkonstrukte wenn man sie seltenst gebraucht?> Da ist ein kleiner Sprachkern wie in C herrlich. Geht fast bissl in die> Richtung CISC vs. RISC (Hennessy/Patterson-Studie), nur eben auf> Programmiersprachen-Ebene, also komplexer Sprachumfang vs. geringer> Sprachumfang
Da sprichst du mir aus der Seele, genau das ist was ich an C, AVR, RISC
so mag, mit wenig Mitteln so ziemlich alles machen können.
Die "modernen" Sprachen werden ja auch immer fetter, da ist C++ das
Paradebeispiel. C#, Java haben auch schon einen recht großen
Sprachumfang, welcher stätig wächst. Vielleicht geht man da in die
falsche Richtung. Ich denke, dass das genauso eine Diskussion sein
könnte wie, sollte die Sprache den Programmierer dazu zwingen
übersichtlichen Code zu schreiben (Pascal).
Mir jedenfalls hat es gut getan zuerst C# zu lernen und zu nutzen, da
die Sprache schon ein bisschen dazu tendiert vorzugeben wie du deinen
Code gestaltest. Dadurch weiß ich jetzt ungefähr was schlechter und was
guter Quellcode ist, wenns um Übersichtlichkeit geht, darüber mach mir
immer Gedanken.
Eine Sprache wie C mit vereinfachtem OO Ansatz, mit Exceptions und
möglicherweise auch mit einfachen Templates oder Generika. Natürlich
ohne C Subset und die C Fallstricke. Das wär DIE Programmiersprache für
mich.
Was der Sprache natürlich nicht fehlen darf: Referenzen.
Ich verstehe auch nicht warum C keine Referenzen kennt. Pascal ein paar
Jahre zuvor hatte schon Referenzen.
Vielleicht, weil dadurch die wieder Verschleiert werden würde, was nach
C Philosophie natürlich verboten ist. Aber das hätte so manchen Bug
schon im Vorfeld ausradiert.
W.S. schrieb:> So, ich hätte da schon einiges (zum Stänkern):>> - Preprozessor abschaffen.>> - Den Wert von Anweisungen abschaffen. Sowas wie "if(A=B)">> - echte Strings und Abschaffung der bisherigen Krampflösung.
Hast du dir mal Go angeschaut?
http://golang.org/
Auf mich macht die Sprache einen ganz guten Eindruck, da sie zusätzlich
eine ähnliche Sicherheit wie Java bietet (keine Pointer-Arithmetik,
geringe Gefahr von Speicherlecks, Überprüfung von Array-Grenzen zur
Laufzeit usw.). Anders als in Java ist in Go aber hardwarenahe
Programmierung möglich. Da hardwarenahe Programmierung generell mit
Gefahren verbunden ist, sind die dafür erforderlichen Operationen in
einem Package mit dem warnenden Namen "unsafe" zusammengefasst, das
für die normale Anwendungsprogrammierung einfach weggelassen wird.
Ok, einige deiner Forderungen sind auch in Go nicht erfüllt:
> - verläßliche Datentypen schaffen. Datentypen sollen von der Sprache> definiert sein und nicht von der Maschine abhängen.
Die maschinenabhängigen Typen int und uint gibt es auch in Go, aber die
muss man na nicht unbedingt nutzen. Wenn man sie aber doch braucht,
fehlen sie nicht.
> - Case-Sensitivität abschaffen.
Case-Insensitivität in Programmiersprachen ist eigentlich längst
abgeschafft, nicht nur in C. Sie war vielleicht zu Zeiten sinnvoll, wo
die Computer, Terminals, Drucker, Lochkartenstanzer usw. noch nicht
richtig mit Groß-/Kleinschrift umgehen konnten. Heute möchte man aber
nicht, dass jemand einen Variablennamen einmal "var" und ein paar
Code-Zeilen später als "VAR", "Var" oder gar "vAr" schreibt. Gleiche
Namen sollten immer auch exakt gleich aussehen.
Christopher schrieb:> Die "modernen" Sprachen werden ja auch immer fetter, da ist C++ das> Paradebeispiel.
Das ist richtig. Vielleicht würde auch dir Go gefallen. Die Sprache ist
vom Sprachumfang nicht größer als C, aber sehr viel mächtiger.
Für alle die Go schnell mal ausprobieren möchten, gibt es hier eine
interaktive Einführung im Web-Browser:
http://tour.golang.org/#1
Man erkennt da sehr schnell, ob man sich mit der Sprache anfreunden kann
oder nicht.
Vielleicht wird ja Go eines Tages das "moderne C"?
Auf 8-Bit-AVRs und ähnlich RAM-armen Controllern wird Go allerdings
nicht sinnvoll einzusetzen sein. Da werde ich weiterhin bei dem
"verzuckerten Assembler" C bleiben und habe ein gutes Gefühl dabei :)
Das sieht auf jeden Fall mal interessant aus. Die Syntax ist eine
Mischung aus C und Pascal.
cyblord ---- schrieb:> Wie soll man ohne Pointer maschinennah programmieren?
cyblord ---- schrieb:> Wie soll man ohne Pointer maschinennah programmieren?
War das auf meinen letzten Beitrag bezogen oder generell gemeint?
Was Go betrifft: Ja, in Go gibt es Pointer (s. voriger Beitrag von
Christopher). Es verbietet nur Pointer-/Arithmetik/. Aber selbst diese
ist über das unsafe-Package möglich, da man damit beliebig zwischen
Pointern und Integers (uintptr) herumkonvertieren kann. Somit sind die
gleichen "Schweinereien" wie in C möglich. Wenn man in hardwareferneren
Programmmodulen das unsafe-Package weglässt, hat man dort eine deutlich
höhere Typsicherheit als in C. Man kann also die "gefährlichen" Aktionen
einer Software auf ganz wenige, hardwarenahe Module beschränken, was in
C nur mit viel Disziplin möglich ist.
Generell: Man braucht für die hardwarenahe Programmierung nicht
unbedingt Pointer. Manche Sprachen (auch manche C-Dialekte) erlauben es
bspw., gewöhnliche Variablen an absolute Adressen zu legen und sie damit
auf I/O-Register zu mappen. Im Vergleich zur Pointer-Methode in C ist
dieser Weg auf jeden Fall der elegantere.
Du scheinst dich schon näher mit Go beschäftigt zu haben.
Ist das schon brauchbar? Oder sollte man warten? Meistens ist es so die
Programmiersprache erst einmal reifen muss (z.B. C#).
Gibts über Go eventuell ein EBook? Hab bis jetzt noch nichts brauchbares
gefunden, mit Übersichten kann man schlecht eine Programmiersprache
lernen.
Hast du die go-ide ausprobiert? Oder programmierst du Go über einen
Editor? Wie gut geht das?
Aus dem FAQ von Go
" Why is my trivial program such a large binary?
The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All
Go binaries therefore include the Go run-time, along with the run-time
type information necessary to support dynamic type checks, reflection,
and even panic-time stack traces.
A simple C "hello, world" program compiled and linked statically using
gcc on Linux is around 750 kB, including an implementation of printf. An
equivalent Go program using fmt.Printf is around 1.2 MB, but that
includes more powerful run-time support. "
:)
Christopher schrieb:> Du scheinst dich schon näher mit Go beschäftigt zu haben.
"Näher" ist zuviel gesagt. Ich habe einen Compiler geschnappt (den von
Google) und ein Bisschen damit herumgespielt, das ist alles.
> Ist das schon brauchbar? Oder sollte man warten?
Für den sogenannten "produktiven Einsatz" würde ich es noch nicht ver-
wenden.
Immerhin wird an dem Teil schon fünf Jahre entwickelt, vor drei Jahren
wurde es der Öffentlichkeit vorgestellt, die Versionsnummer beginnt
mittlerweile mit einer 1, und es gibt zwei, den vollen Sprachumfang
abdeckende Compiler (den von Google und GCC). Auch die Package-Liste
erweckt nicht den Eindruck, dass man damit nur Hello-World-Programme
erstellen kann:
http://golang.org/pkg/
Aber das muss natürlich alles nicht heißen ... :)
> Meistens ist es so die Programmiersprache erst einmal reifen muss> (z.B. C#).
C# ist natürlich auch ein extremes Beispiel für Bananensoftware (die
erst beim Kunden reift). Das liegt aber u.a. daran, dass C# eine sehr
"große" Sprache ist und MS damals bei der Veröffentlichung sehr unter
Zeitdruck stand. Seither gibt es im Mittel alle zwei Jahre eine neue
Sprachspezifikation (zum Vergleich: Bei C und C++ liegen die einzelnen
Versionen zehn Jahre und mehr auseinander).
Beide Probleme (Größe und Zeitdruck) treffen auf Go eher nicht zu. So
könnte ich mir durchaus vorstellen, dass es schon relativ "fertig" ist.
> Gibts über Go eventuell ein EBook?
Keine Ahnung. Es gibt halt die übliche Tutorials, die Sprachspezifika-
tion und die Dokumentation der Packages:
http://golang.org/doc/> Hast du die go-ide ausprobiert?
Nein.
> Oder programmierst du Go über einen Editor?
Ja, und zwar mit denselben, den ich auch für C, C++, Python, Bash-
Skripte, Haskell usw. nutze: Vim :)
> Wie gut geht das?
Sehr gut. Aber wie gesagt, ich habe noch nichts größeres in Go gemacht.
Gelegenheitsprogrammierer schrieb:> A simple C "hello, world" program compiled and linked statically using> gcc on Linux is around 750 kB, including an implementation of printf. An> equivalent Go program using fmt.Printf is around 1.2 MB, but that> includes more powerful run-time support. "
Mit gccgo und dynamisch gelinkt braucht ein Hello-World 19,5kB. Das ist
auch nicht ganz wenig, aber für PCs und etwas größere ARM-Rechner schon
in Ordnung.
Hallo W.S.,
W.S. schrieb:> Ich versuch's mal ganz deutlich zu formulieren: Je mehr wir in die> Zukunft kommen, desto dringender wird es, daß eine Programmiersprache> selbstdokumentierend wird, möglichst frei von Seiteneffekten ist und> möglichst wenig zu erlernende (weil sich nicht durch LESEN erklärende)> Bestandteile hat.
Python existiert.
Beste Grüße,
Klaus
Hallo Christoph,
Christopher schrieb:> Allerdings finde ich, dass Header bei C++ unnötig sind, da es Namespaces> gibt. Ein Modulsystem täte C++ gut.
Header machen vor allem in der kommerziellen Softwareentwicklung Sinn.
Da kann ich meine Library als Binärcode ausliefern, und mit Hilfe der
Header kann der Kunde sein Programm dagegen linken.
Beste Grüße,
Klaus
Thread beobachten
Seitenaufteilung abschalten