Funktion tolower() mit Zeiger
-
Tim schrieb:
µngbd schrieb:
Wenn ein char ein Byte hat
Ein char ist per Definition ein Byte.
Wenn ein char 8 Bit hat. Besser?
-
Genmutant schrieb:
Tim schrieb:
µngbd schrieb:
Wenn ein char ein Byte hat
Ein char ist per Definition ein Byte.
Wenn ein char 8 Bit hat. Besser?
Unwichtige Information
-
Wieso, ein Byte muss ja nicht 8 Bit haben. Kann ja auch 512 Bit haben, und dann sieht die Sache ganz anders aus!
-
Ach, dann sind char foo[10] keine 10 Bytes mehr?
-
Ach verflucht, die 1.5MB stimmen dann ja immer noch... sind ja nur mehr ^^
Ok, das hatte ich nicht bedacht.
-
Genmutant schrieb:
Wieso, ein Byte muss ja nicht 8 Bit haben. Kann ja auch 512 Bit haben, und dann sieht die Sache ganz anders aus!
Klar, aber er wird trotzdem recht behalten, weil der Begriff "MB" aus dem Begriff "Byte" konstruiert ist. Widerspruch ist nutzlos.
-
µngbd schrieb:
nwp2 schrieb:
Keine Ahnung wieso eigentlich.
Ich hab's auch nie so recht verstanden. Irgendwer sagt zu der Frage immer, dass man sie deshalb mehrfach belegen kann, und das muss scheinbar so sein.
Stimmt, da war ja was. Wenn man zweimal denselbe String definiert kann man sich den Inhalt beim zweiten sparen und auf den Inhalt des ersten zeigen lassen. Naja, man hätte auch ruhig const char * und char * unterscheiden können für sowas.
Tim schrieb:
Und lass doch bitte nwp2 einfach die beleidigte Leberwurst sein
[ironie]Danke, endlich unterstützt mich jemand.[/ironie]
µngbd schrieb:
Es will ja niemand behaupten, dass malloc() keine Daseinsberechtigung hat, ich bin sogar erklärter Freund von Böhm's GC (malloc ohne free). Nur gibt's halt C auf allen Platformen und Systemen, und manchmal ist so ein malloc() einfach nicht drin (überleg dir mal, wie viel Aufwand so ein Heap eigentlich ist).
Meiner Meinung nach ist die Übersicht, Richtigkeit und Sauberkeit des Codes es wert. Und irgendwie zieht das Argument "Stell dir vor es gibt manchmal kein malloc" nicht wirklich. malloc ist kein Allheilmittel, aber auf jeden Fall besser als Buffer[wirdschonreichen]. Aber naja, damit stehe ich wohl allein
-
nwp2 schrieb:
Und irgendwie zieht das Argument "Stell dir vor es gibt manchmal kein malloc" nicht wirklich.
Wenn's keines gibt, dann gibt's eben keines. Das trifft mindestens einen, nämlich den armen Kerl, der malloc() schreiben muss. Das ist btw Kapitel 5.4 im K&R, dort wird eine einfache Möglichkeit gezeigt, wie man malloc() bauen kann. Und natürlich beginnt das mit einem
static char allocbuf[wirdschonreichen]
, weil der Speicher schließlich auch irgendwo herkommen muss.Tim schrieb:
Und lass doch bitte nwp2 einfach die beleidigte Leberwurst sein
Sei doch nicht so hart, es ist Weihnachten.
-
µngbd schrieb:
Und natürlich beginnt das mit einem
static char allocbuf[wirdschonreichen]
, weil der Speicher schließlich auch irgendwo herkommen muss.Das ist kein buffer[wirdschonreichen] sondern ein buffer[sovielwiedaist]. Das ist ein Unterschied. Wenn man sich bei der Zahl in den Arrayklammern was denkt und begründen kann wieso gerade diese Zahl dort stehen muss und wieso sie nicht größer und nicht kleiner sein kann, dann ist das durchaus legitim. Wenn man sich irgendeine halb zufällige Zahl ausdenkt, weil man zu faul ist malloc zu benutzen ist das schlampig.
Ich werde demnächst versuchen nicht mehr auf Diskusionen zum Thema malloc vs buffer[wirdschonreichen] einzugehen. Es ist alles gesagt.
-
nwp2 schrieb:
Es ist alles gesagt.
Ich formuliere es um: Du hast alles mißverstanden. Allgemein habe ich den Eindruck dass du nicht sonderlich viel verstehst. Du hast "dein Ding" und alles was davon abweicht ist Gefrickel, unles/wartbar und was weiss ich noch. Dabei gehst du Diskussionen und vor allem Argumenten aus dem Weg und pauschalisierst eben durch Spezialaussagen wie "das ist bei >1000 Zeilen nicht mehr handlebar". Ich kann mich noch gut an deinen Groll gegen realloc erinnern, aber warum realloc nun schlimm sein soll (wo du ja offensichtlich ein absoluter Fan von malloc bist), da kam nix. Spiel ruhig die beleidigte Leberwurst, halt dich aus Diskussionen raus, aber dann sei auch konsequent und spar dir solche Anmerkungen wir "[ironie]Hier wieder ein fürchterlicher malloc-Kampf, unmöglich zu gewinnen[/ironie]". Oder wir starten einen Thread und diskutieren das einmal aus. Ich denke, dann werden sich einige Mißverständnisse klären.
@Op: Sorry für off-topic
-
nwp2 schrieb:
Stimmt, da war ja was. Wenn man zweimal denselbe String definiert kann man sich den Inhalt beim zweiten sparen und auf den Inhalt des ersten zeigen lassen. Naja, man hätte auch ruhig const char * und char * unterscheiden können für sowas.
kannste doch machen. verwende künftig 'const char*' für pointer denen du stringliterale zuweist. ist weder verboten noch ein zeichen von schlampigkeit.
nwp2 schrieb:
Und irgendwie zieht das Argument "Stell dir vor es gibt manchmal kein malloc" nicht wirklich.
doch, weil C oft in umgebungen verwendet wird, wo keine dynamische speicherverwaltung (oder kein malloc-äquivalent) existiert. nichtverwendung von malloc hält C-code einfach portabler, das ist so.
nwp2 schrieb:
µngbd schrieb:
Und natürlich beginnt das mit einem
static char allocbuf[wirdschonreichen]
, weil der Speicher schließlich auch irgendwo herkommen muss.Das ist kein buffer[wirdschonreichen] sondern ein buffer[sovielwiedaist].
das ist ein buffer[soviel_wie_für_den_heap_festgelegt_wurde], ein reiner schätzwert für ein gutes verhalten des gesamtsystems. bei manchen malloc-implementationen ist dieser wert fix, andere können zur laufzeit noch mehr speicher vom OS anfordern (mit der konsequenz, dass speicher plötzlich anderen prozessen fehlen könnte, das system lagt, weil ausgelagert werden muss, usw).
nwp2 schrieb:
Wenn man sich irgendeine halb zufällige Zahl ausdenkt, weil man zu faul ist malloc zu benutzen ist das schlampig.
schlampig ist's z.b. wenn man völlig gedankenlos 'malloc' benutzt, um sich etwa speicher für eine kleine struct anzulegen, dann noch nichtmal den rückgabewert prüft oder das 'free' vergisst.
nwp2 schrieb:
Ich werde demnächst versuchen nicht mehr auf Diskusionen zum Thema malloc vs buffer[wirdschonreichen] einzugehen.
wir (zumindest ich) werden aber weiterhin an deinen code-beispielen rummäkeln, wenn du mal wieder grundlos 'malloc' verwendest. das ist doch ok, oder? *fg*
Tim schrieb:
Oder wir starten einen Thread und diskutieren das einmal aus. Ich denke, dann werden sich einige Mißverständnisse klären.
mach das.