Re: C++ (war: Re: [Debian]: Partitionierung der Festplatte
On Tue, Mar 17, 1998 at 12:50:17AM +0100, Dirk Luetjens wrote:
>
> Hi,
>
> On Sun, 15 Mar 1998, Marcus Brinkmann wrote:
>
> > > Fazit: So lange man eh nur eine Platte hat, wuerde ich nur 2 Partitionen
> > > machen, eine fuer root eine fuer swap.
> >
> > Ahem. Für eine single user home machine sollte das reichen, ja. Für den
> > Fileserver im Betrieb *sicherlich* nicht ratsam.
>
> Dann wurde ich auch eher mehrere Platten nehmen. Wir hatten mal zwei 4GB
> Platten im Institut die nacheinander abgeraucht sind. In beiden Faellen
> war der Kontroller defekt. Bei der ersten konnten wir mit Hilfe des
> Tauschens des Kontrollers von der zweiten Platte das Backup vom Band
> ersparen. Bei der zweiten dann nicht mehr.
>
> > Da habe ich eher den Compiler im Verdacht. Wenn der Source Code sinnvoll in
> > einzelne Files eingeteilt ist, sollte das Compilieren eines Programs (und
> > wenn es X ist), niemals 164 MB verbrauchen. Welchen Compiler benutzt du
> > denn? gcc 2.7.2.3 hat viele Probleme mit C++ (nicht ANSI standard, exception
> > handling is hoffnungsvoll kaputt, ...) Probier mal den egcs.
> Also das groesste File hat ein Groesse von:
> dirk@hobbes[~]# wc lbasin.C
> 441 1074 10074 lbasin.C
>
> Pro File habe ich eine einzige Klasse. Ich benutzte folgende zwei Templates:
> vector<Basin> vbasins;
> list<Gruppe> lgruppen;
>
> Wobei Basin und Gruppe selbstdefinierte Klassen sind.
>
> Als Compiler benutzte ich gerade den gcc 2.8.1 mit
> "-O2 -fstrength-reduce". Ich dachte auch nicht, dass ich damit an die
> Speichergrenzen komme. Aber nach einer Weile heftigster Plattenkapazitaet
> bekomme ich immer "virtual memory exhausted", oder so aehnlich. Ich
> kompiliere seit dem nur noch mit "-O2" damit gehts dann.
Ich denke, du hast da einen Bug im gcc gefunden. Gcc 2.8 ist auch noch nicht
so das Gelbe vom Ei. Schau doch mal mit "top" nach, wieviel Speicher der
Compiler mit und ohne -fstrength-reduce verbraucht, denn der Unterschied
sollte nicht dutzende von Megabyte betragen.
Probier auch mal den egcs. Der bringt in Punkto ANSI C++ mehr Erleuchtung.
> Und sprich mich bloss nicht auf die C++ Probleme vom gcc an. Was meinste
> was ich mich mit dem Ding rumgeaergert habe. Als Anfaenger in Sachen C++
> wollte ich mal einfach mal so mit dem Debugger meinen Fehler finden.
> Pustkuchen. Mal kann ich mir die Variablen ansehen, das naechste mal
> bekomme ich nur noch "this is not of type aggregate" (mit this ist
> natuerlich der "this Pointer" einer Instanz gemeint). Inzwischen kann ich
> im Debugger kein Programm mehr zweimal starten. Nach dem ersten
> erfolgreichen Lauf bekomme ich dann nach beim Versuch erneut zu starten
> nur noch "can't access memory at ###". Ich koennte die Liste noch ein
> wenig fortsetzten.
Oh je. Ja, probier's mal mit einem Update der binutils, da habe die auch
schon ganz witzige Fehler gefunden in letzter Zeit.
Als ebenfalls Anfänger in Sachen C++ habe ich mich schon sehr über g++
geärgert, besonders weil ich mit dem Stroustrup arbeite, und der setzt
voraus, daß dort, wo C++ drauf steht, auch C++ drin ist. Hat er ja auch
irgendwo Rrecht mit, sollte so sein.
> Ich habe schon fast an mir selber gezweifelt. Aber inzwischen laechel ich
> nur noch und denke mir, es koennte noch schlimmer kommen.
Es wird schlimmer kommen ;)
> Insgesamt glaube ich mir, die GNU Tools beduerften einer Politur des
> Outfits. Sie sind zwar leistungsfaehig, aber nicht mehr unbedingt am Zahn
> der Zeit. Der {X}Emacs ist ein Monster, welches es tagtaeglich zu zaehmen
> gilt. Manche glauben ja, er sei schon zu einem BS avanciert. Bin mal
> gespannt, wann der Erste einen Hurd-kernel in LISP als Emacs Modul
> schreibt. Der Unix-Style ist ja eigentlich "Schreibe kleine funktionale
> Programme, die nur eine Sache machen, die aber richtig". Von einer
> intergrierten Entwicklungsumgebung, Projektmanagement mit Hilfe vom
> {X}Emacs ist zumindest ohne Einarbeitung in diverse Sprachen nicht zu
> reden. Ich sage ja nicht, dass soetwas nicht geht. Aber eben nicht immer
> besonders einsichtig.
Das Problem ist, daß jeder eine andere Umgebung haben will. Es sind einige
solche Tools da, aber keins was wirklich einen Standard gibt. Probleme sind
auch Geschwindigkeit (Maus ist langsamer als Tastatur) und Lesbarkeit
(Console ist lesbarer als X, besonders mit svgatextmode).
Ich denke, es gibt einiges an GUI Entwiclungsumgebungen, aber nichts was
dich vom Hocker reißen würde. Also: eg++ raus, Gtk-- raus, und ran and die
Arbeit ;)
> Manchesmal habe ich das Gefuehl, dass ein Generationenwechsel stattfinden
> muss. Von den Hardlinern, die noch auf den Maschinen von vor 20 Jahren
> hacken, die nur Schwarz-Weiss Monitore benutzten :-), zu Leuten, die sich
> nicht scheuen auch mal das Wort "GUI" in den Mund zu nehmen. Ich denke
> mir, dass sich Funktionaliaet und Oberflaeche nicht unbedingt
> wiedersprechen muessen. Und so manches mal habe ich auch das Gefuehl, das
> dieser frische Wind an meiner Nase vorbeiweht und mich hoffen laesst in
> ein paar Jahren mit einem Linux System aufwarten zu koennen, dass auch
> _jeden_ Vergleich zu einem Desktop Rechner anderer Bauart standhaellt.
> Bitte folgert jetzt nicht daraus, dass ich glaube W.. sei besser. Ganz im
> Gengenteil. Ich wuensche mir fuer die Zukunft nur bessere Interaktion
> und leichtere Bedienung der vorhandenen Tools und sei es z.B. durch ein
> Developement Center.
Mmmmh. So ein Debugger, der immer die aktuelle Zeile rot anmalt... wär schon
schön. Aber ich glaube, daß die Grenze zwischen unnötiger Pixelzier und
wahrem Funktionalitätsvorteil sehr wackelig ist.
> So, das war ein bisschen OFF-Topic, musste aber mal raus.
Klar, es gibt immer Dinge über die man sich ärgert. Das ist die Motivation
zum Besser-Machen ;)
> In diesem Sinne, lang lebe Linux, GNU, Debian und all die Leute, die diese
> Kombi zu einem begehrenswerten System machen
Prost!
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <your_email_address>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 414
Reply to: