Re: diskless system ohne swap

On Mon, May 17, 2004 at 08:43:03PM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > On Mon, May 17, 2004 at 03:41:04PM +0200, Oliver Fromme wrote:
> > > 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.
>
> Ja, nur leider ist das Typsystem von C++ statisch.

Ich kann dir da jetzt nicht ganz folgen.
Du kannst doch problemlos Typen definieren wie du willst.

> > Mir machen die Hintergrund Zaubereien von Hochsprachen immer ein
> > bischen Angst, da man die nicht sauber Kontrollieren kann
>
> Will man das denn? Will ich mich um die Belegung von jedem
> einzelnen Bit kümmern müssen? Nö, will ich eigentlich
> nicht. Ich will meinen Krempel implementiert kriegen, und
> zwar möglichst schnell. Was dann letztendlich für Bits im
> RAM liegen, ist mir relativ egal. Das ist Job der Sprache.

Solange mir die Sprache die funktionalität nicht verhaut, weil einfach
2 blöde Taktzyklen zuviel verwendet wurden.
Es gibt sehr viele Situationen wo ich mir sicher sein muss, dass
einfach kein Bit zuviel belegt wird.
Selbst wenn eine Sprache das sauber erledigt kann ich mir dessen nicht
sicher sein.

> Es gibt natürlich zweifellos auch Anwendungen, wo man das
> genau kontrollieren und auf unterster Ebene herumpfriemeln
> muß. Das ist dann Pech.

Du nennst es Pech - für mich ist das der Normalfall.

> > > nicht überlegen muß, wie lang der jetzt werden kann. Wenn
> >
> > Ich mag asprintf - aber nur so am Rande...
>
> Ist nicht portabel - aber nur so am Rande...
> ;-)

Ist mir auch schon aufgefallen :)
Aber in meiner Sammlung existiert eine passende Implementierung, die
per configure eingebunden wird wenn es nötig ist.

> > > 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.
>
> Das muß ja kein Widerspruch sein.

Sicher nicht - ist es aber meistens.
Schau dir aleine mal an wieviels mehr Speicher ein C++ String im
Vergleich zu einem C String belegt.
Das ist natürlich nicht unbegründed, aber wenn ich den Vorteil nicht
nutze dann ist die Belegung des Speichers und gar die Befüllung
einfach vermeidbar.
Auch der uint8_t Fall ist nicht ohne - wenn du keine Limitierung willst
brauchst du einfach wenigstens die Information ob da ein weiteres Byte
exisitert - 1bit Zusatz macht ein Byte im Speicher und du belegst
gleich doppelt so viel.
Jetzt stelle dir mal ein Array mit ein paar Millionen davon vor.
Schlimmer wird es wenn der Compiler das gar als Objekte verwaltet und
noch eine vtable oder sowas reinpackt - weiterhin brauchen wir auf einer
alpha oder sparc64 gar 64bit Alignment und der Speicherbedarf wird
nochmals um ein wesentliches größer.

> > 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.
>
> Ich brauche üblicherweise eher eine arithmetisch korrekt
> funktionierende Addition. Und wenn man eine Addition mit
> Spezialverhalten braucht, dann kann man sie sich definie-
> ren.

Ist glaub ich sehr Absurd eine Sprache die die Maschine Abstrahieren
soll mit Definitionen an Maschinennahe Konstrukte anzupassen.

> > Es gibt da etliche Kniffe auf Assemblerebene, die ich in C Problemlos
> > umsetzen kann, aber in einer anderen Sprache nicht oder nur sehr
> > schlecht.
>
> Ja, wie gesagt, da sieht man die Verwandtschaft von Assem-
> bler und C ganz deutlich.

Ja - zweifelslos - deshalb mag ich C.

> > > 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.
>
> Dann sind Deine Programmieraufgaben eher untypisch.

Glaube ich gar nicht mal - sind aber offensichtlich anders als deine.

> > > 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,
>
> Das sind auch nicht gerade High-Level-Sprachen, und in bei-
> den ist das Programmieren (meiner Meinung nach) eher ziem-
> lich unbequem und unflexibel (beide haben ein rein stati-
> sches Typsystem). Eiffel kennt nicht einmal native Arrays.
> Und in Java programmiert man sich schon für die einfachsten
> Dinge einen Wolf (z.B. um eine Datei zeilenweise einzule-
> sen).

Alles eine Frage dessen was man damit Programmieren will.

> Das ist natürlich auch ein bißchen subjektiv. :-)
>
> > Und dann habe ich oftmals das Problem dass ich durch die tägliche
> > Verwendung in C einfach schneller bin.
>
> Das kann ich überhaupt nicht nachvollziehen. Für Dienge,
> die in C zehn Zeilen brauchen, braucht man z.B. in Python
> (oder meinetwegen auch in Perl, Ruby etc.) eine Zeile.
> In Python schreibe ich in 15 Minuten Dinge herunter, für
> die ich in C einen halben Tag bräuchte -- und die Programme
> sind dann sogar einfacher zu lesen (mithin wartungsfreund-
> licher), weil sie sich auf das konzentrieren, was das Pro-
> gramm tatsächlich tun soll.

Ansichtssache - wobei ich Perl mangels funktionierendemn Compiler
einfach nur hasse.
Das Zeugs ist so derart Lahm, dass man es nur für Performance-
unkritische Dinge einsetzen kann.
Das ist natürlich ein Perl spezifisches Problem.

> Ich persönlich mag inzwischen (das war bei mir auch ein
> längerer Prozeß) am liebsten Sprachen mit dynamischem Typ-
> System, d.h. wo Werte Typen haben, nicht Variablen (diese
> Sprachen haben dann zwangsläufig »weak typing«), und sol-
> che mit »strong typing« verbunden mit Typinferenz.

Sowas kann man mit C++ auch hinbekommen wenn man es wirklich braucht.
Selbst Microsoft hat das seit OLE2 auf C++ Basis hinbekommen.
Das Geheimniss einer gemeinsammen Basisklasse - wenn die von der
Sprache selber kommt ist das natürlich einfacher.
Auf jeden Fall ist der Overhead schon aus der Tatsache, dass du
Typeninformation zu jeder Variable brauchst deutlich klar.

> Von C und den meisten C-Abkömmlingen (C++, Java, C#) habe
> ich eher die Nase voll. :-)

Tja - jeder sollte das Werkzeug benutzen mit dem er am besten seine
Aufgaben bewältigen kann.
Wenn Performance weniger wichtig ist als die Punkte in denen die
jeweilige Sprache ihre Stärken hat ist das OK.

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