Hi,
C reizt ja dazu, den Speicher, wenn man ihn schon selbst verwalten muss/kann, auch optimal zu nutzen.
stimmt. ;-)
Ist es aber möglich, den beim Einlesen durch fgets automatisch reservierten Speicher per malloc persistent zu machen.
War das eine Frage.
Im Ernst: Du hast von dem Moment an die Kontrolle über die Speichernutzung, da fgets() zurückkehrt und den eingegebenen String ans das Anwenderprogramm übergibt.
Was fgets() intern anstellt, welche und wieviele Zwischenpuffer es verwendet oder ob es direkt eine geeignete Betriebssystemfunktion aufruft, darauf hast du keinen Einfluss.
Muss man immer ein Kopie davon irgendwo anlegen?
Wieso? Du rufst fgets() auf und sagst: Hier habe ich einen Puffer reserviert, leg mir die Eingabedaten bitte dorthin. Von da an brauchst du keine Kopien zu erzeugen, wenn dein Algorithmus ohne auskommt.
Und weiter, ist es besser, den Zelleninhalt einzeln zu allokieren, oder besser eine größeres Stück in einem (Zeile fortlaufend, darin die Zellen). Platzmäßig ist das ja wohl egal. Eher eine Fragmentierungsfrage.
Jetzt wird's philosophisch. ;-)
Sagen wir's mal so: Das OS muss über jeden angeforderten Speicherblock Buch führen. Wenn du viele kleine Blöcke anforderst, steigt natürlich der Varwaltungs-Overhead im Verhältnis zum Nutzen an. Aber das ist IMHO eher akademisch; verlass dich drauf, dass das Betriebssystem damit umgehen kann.
Da es keine Objekte/Strukturen mit Methoden gibt, in denen dann per "this" oder "self" auf Klassen/Strukturvariablen zugreifen kann, muss man das zu bearbeitende Objekt ja immer per Speicheradressenangabe rumreichen.
Das ist im Prinzip dasselbe wie "this".
Sind denn größere Projekte damit dann objektorientierungslike genauso übersichtlich realisierbar.
Ja, eigentlich schon. Man muss eben nur Spaß daran haben, sich die Möbel selbst zu bauen, anstatt sie fertig liefern zu lassen. :-)
Relativ abstrakt gesehen sind Klassen ja zum Teil "nur" Namensräume innerhalb derer dann interne "globale" Variablen definierbar sind. Diese Strukturierungsmöglichkeit fehlt ja bei C.
Jein. Mit normalen structs kann man das "im Prinzip" auch haben.
Mit der Funktionsbenennung lässt sich da vermutlich noch ein Teil strukturieren. Ist also ObjectivC oder C++ dann die Folge, oder gibt es Gründe, bei C zu bleiben?
Ich kenne ObjectiveC nicht. Aber C++ mag ich nicht so sehr, weil einerseits vieles "automagisch" hinter meinem Rücken passiert. Außerdem verleitet es durch die etwas laxen Syntaxregeln verleitet es zur Schlamperei.
Ansonsten: Wer's mag ...
So long,
Martin
Wenn die Amerikaner eines Tages von jeder Tierart ein Pärchen nach Cape Canaveral treiben ...
ja, DANN sollte man endlich misstrauisch werden.