On Mon, May 17, 2004 at 03:41:04PM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > On Fri, May 14, 2004 at 09:22:05PM +0200, Oliver Fromme wrote:
> > > Wahrscheinlich arbeiten wir dann wohl auf sehr unterschied-
> > > lichen Leveln. Ich spreche jedenfalls von typischen Anwen-
> > > dungen aller Art, wie sie auf Desktops und Servern laufen.
> >
> > Wenn typisch gleich bunt ist gebe ich dir recht.
>
> Nicht unbedingt -- ich meine ganz normaler Anwendungen, die
> z.B. unter FreeBSD laufen könnten. Das mag eine Applika-
> tion mit GUI sein (»bunt«), aber auch irgendwelche Komman-
> dozeilentools oder sonstwas. Aber nicht ...
>
> > Ein kompletter Webserver mit TCP/IP Stack ist auf einem Controller mit
> > nur weniger kBytes Binärcode im Ergebniss in C Problemlos zu
> > realisieren.
>
> .. sowas. :-) Das meinte ich mit »sehr unterschiedlichen
> Leveln«.
War mir schon klar :)
> > > Ich kann nicht so recht nachvollziehen, wie man »C« und
> > > »Komfort« in einem Satz nennen kann. :-) In dieser Be-
> > > ziehung sehe ich mehr Gemeinsamkeiten als Unterschiede zwi-
> > > schen C und Assembler.
> >
> > Oh der Unterschied ist schon gewaltig.
>
> Nicht gewaltiger als der zwischen C und einer High-Level-
> Programmiersprache.
Mag sein - ich greife ja auch ab und an zu anderen Sprachen,
eil die für diverse Anwendungen einfach besser sind.
> > Alleine schon die Typenprüfung ist selbst bei C allemal komfortabler
> > als in Assembler.
>
> Ist nicht Dein Ernst, oder? C hat nichtmal strong typing.
> Das Typensystem von C ist eher ein Witz und provoziert ge-
> radezu Bugs.
Ein Witz ist besser als gar nichts.
Aber da aktuelle C Compiler allesamt auch C++ können kann man
auch die Typenprüfung bis in C++ Level hochschrauben.
> Davon abgesehen es Typprüfungen auch in Assembler (je nach-
> dem, welchen man verwendet). Ich habe vor vielen Jahren
> mal ziemlich intensiv mit TASM gearbeitet (unter DOS).
> Dessen Typprüfungen waren durchaus mit denen von C ver-
> gleichbar -- manchmal in so einem Maß, daß es mich schon
> genervt hat, weil ich Casts brauchte, genau wie in C, und
> damit die Typprüfungen ad absurdum geführt habe.
Ja - sowas gibt es, aber warum sollte ich es verwenden, wo es
doch C gibt.
> > Und das man die CPU wechseln kann ohne alles neu zu programmieren
> > ist nun wirklich komfortabel.
>
> Das nenne ich nicht komfortabel, sondern eine Grundvoraus-
> setzung. Man könnte genausogut sagen, daß es komfortabel
> ist, daß ein Auto ein Lenkrad hat. :-)
Komfortabel wird ein Auto erst ohne Lenkrad.
Ob das dann aber noch so viel Spaß macht ist fraglich.
Mir machen die Hintergrund Zaubereien von Hochsprachen immer ein
bischen Angst, da man die nicht sauber Kontrollieren kann und die
verbrauchten Resourcen sind niemals unbegrenzt verfügbar.
Wenn man es nicht kontrollieren braucht ist das toll, aber mir gehen
bisweilen auch die Optimierungen von C Compilern auf die Nerven, obwohl
ich darauf auch wiederum nicht verzichten möchte.
Zudem ist C überall verfügbar - für sehr viele andere Sprachen gilt das
leider nicht.
> Komfortabel ist es, wenn der Compiler für mich alle Typ-
> prüfungen macht und Typfehler strikt verhindert -- ohne
> dabei Einschränkungen in der Dynamik hinnehmen zu müssen.
> Komfortabel ist es, wenn man keinen Speicher alloziieren
> und freigeben muß. Wenn man bei einem String (oder Array)
Komfortabel hin oder her.
Ich brauche sehr oft die Möglichkeit gänzlich ohne dynamischen Speicher
auszukommen.
C macht das ganz gut mit static Variablen - OK Variablen auf dem
Stack nutze ich natürlich auch.
> nicht überlegen muß, wie lang der jetzt werden kann. Wenn
Ich mag asprintf - aber nur so am Rande...
> ich nicht darüber nachdenken muß, ob meine Zahlen jetzt
> in einen int reinpassen oder nicht. Wenn ich beim Program-
Ich will dass eine Zahl nicht mehr Speicher belegt als diese Zahl
braucht.
Und ich will, dass ein uint8_t mit dem Wert 0xff bei der Addition
von 1 auf 0x00 springt, weil ich in vielen Fällen darauf angewiesen
bin.
Es gibt da etliche Kniffe auf Assemblerebene, die ich in C Problemlos
umsetzen kann, aber in einer anderen Sprache nicht oder nur sehr
schlecht.
> mieren nicht ständig um Einschränkungen der Programmier-
> sprache herumarbeiten muß, sondern mich auf das konzent-
> trieren kann, was ich implementieren will.
Genau - und mangelnde Kontrolle ist für meine Anwendungen die größte
Einschränkung.
> Ich könnte noch viel mehr aufzählen, was komfortabel ist
> und was C nicht bieten kann.
Ich weiß Sprachen wie Java, Eiffel und sonstige durchaus zu schätzen,
aber den Overhead kann ich nur sehr selten in Kauf nehmen.
Und dann habe ich oftmals das Problem dass ich durch die tägliche
Verwendung in C einfach schneller bin.
Üblicherweise verwende ich deshalb auch bisweilen C++ - nicht weil
ich die Sprache so super toll finde, sondern weil die mir vertrauter
ist, aber selbst da verwende ich selbst geschriebene z.B. String
Klassen, da die Standartklassen durch die hohe Flexibilität sehr fett
sind und zudem beim GCC sehr schlecht implementiert waren.
-- B.Walter BWCT http://www.bwct.de bernd(at)bwct.de info(at)bwct.de To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Mon 17 May 2004 - 17:36:40 CEST