C - Programm

[unite]

Hallo,

ich habe eine Frage.

ich beschäftige mich z.Z. mit der C-Programmierung und möchte die folgende Aufgabe lösen:

Ich will ein Kopierprogramm schreiben, das Folgen von Leerzeichen in der Eingabe durch ein einzelnes Leerzeichen in der Ausgabe ersetzt.

Ein einfaches Kopierprogramm sieht folgendermassen aus:

#include <stdio.h>

int main() {

int c;

c = getchar();

while(c != EOF)

{

putchar©;

c = getchar();

}

return 0;

}

es funktioniert auch.

hier ist einfaches Zähler-Program:

#include <stdio.h>

/* Eingabezeilen zaehlen */

void main() {

int space_count = 0;

int tab_count = 0;

int line_count = 0;

int ch = 0;

while((ch = getchar()) != EOF) {

if(ch == '\t')

tab_count++;

if(ch == '\n')

line_count++;

if(ch == ' ')

space_count++;

printf("Tabulator: %d\nZeilen: %d\nLeerzeichen: %d\n",

tab_count, line_count, space_count);

}

}

funktioniert auch..

Wie löse ich denn das Problem mit dem ersetzen von Leerstellen-Zeichen?

Bis jetzt habe ich folgendes:

#include <stdio.h>

int main()

{

int c, zaehler, leer;

zaehler = 0;

//leer = ' ';

while((c = getchar()) != EOF)

{

if(c == ' ')

{

zaehler++;

}

if(zaehler > 1)

{

printf("%c %c", c, leer);

}

}

return 0;

}

Danke im voraus!

mfg,

Andre

www.crystalbeach.de

------------------

[Sirius2001]

Du mußt das ganze als String deklarieren und nicht als Integer. Auf den Rest mußt du dann selber kommen, denn mit Strings hatte ich noch nicht so viel zu tun.

CU Sirius2001

[gajUli]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">Zitat:</font><HR>Original erstellt von Sirius2001:

Du mußt das ganze als String deklarieren

[TingleTangle]

hi FaSI,

ich hab mal ein bisschen in deinem Code rumgewurschtelt. Warum nimmst du immer int.

Wenn du z.B. Visual C++ als Compiler hast, dann ist ein int 32bit gross--> gigantische Speicherverschwendung! und schlechtes Handling

#include <stdio.h>

void main() {

//short zaehler=0; //short reicht leicht

char leer,c,b; //reicht fuer ein Zeichen

leer = 0x20;

getch:

while((c = getchar()) != EOF)

{

if(b ==1 AND c==leer goto getch

else b=0;

if(c == leer)

{

b=1;

printf("%c",leer);

}

printf("%c",leer);

}

}

return 0;

}

Ich hab des nur so reingehackt. Vielleicht ist es auch Scheisse, aber des sollte schon gehen Ich glaube bei der Tastatureingabe ist es nicht so leicht ein EOF zu erzeugen.

Muss jetzt mal weitermachen, viel Spass beim probieren

[Dieser Beitrag wurde von DocNeo am 12. Februar 2001 editiert.]

[Gast bimei&uli]

Sag mal, Doc, musst Du den FaSi auf so seltsame Ideen bringen? Ist ja geradezu blasphemisch.

Der Reihe nach:

1. Mit goto an den Anfang einer while-Schleife springen (nimm continue!),

2. Variable b testen (ohne vorherige Initialisierung),

3. getch() statt getchar() (nicht ANSI)

4. und dann noch dieser Firlefanz mit short statt int (Funktionen, die int liefern, sollte man nicht unnoetig casten),

5. Listing nicht getestet).

Uebrigens erzeugt die Ausgabe eines Characters mit printf() statt mit putchar() vermutlich 5 mal soviel Code wie mit short statt int eingespart wird.

Ach ja, habs doch gerade tatsaechlich nochmal nachgeschaut: Es ist nach Sprachdefinition sogar moeglich, dass short die gleiche Groesse wie int besitzt.

Ich wuerde mal etwa so sagen:

int c, last='x';

while ((c=getchar())!=EOF)

{

if (c!=' ') putchar©;

if (c==' ')

if (last!=' ') putchar©;

last=c;

}

Uli

[Dieser Beitrag wurde von bimei&uli am 12. Februar 2001 editiert.]

[TingleTangle]

Ich hab nie behauptet das ich dem guten einen fertigen, voll profilierten Code hinstelle. Sollte nur eine Idee sein.

Ob int ein short oder ein long ist, haengt vom Compiler ab(16 od. 32bit) und beim MSVC++

sinds halt nunmal 32. Das kann bei einem grossen Array schon sehr lustig werden

Mit printf sparst du dir Code Memory mit short statt long Data RAM

[gajUli]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">Zitat:</font><HR>

Ich hab nie behauptet das ich dem guten einen fertigen, voll profilierten Code hinstelle. Sollte nur eine Idee sein.

[Dante]

Versuch das hier mal, müsste funktionieren:

#include <stdio.h>

/* Leerzeichenreihen sollen durch ein einzelnes Leerzeichen ersetzt werden*/

main()

{

int c,b;

while ((c = getchar ()) != EOF)

if (c == ' ')

{

putchar ©;

while (( b = getchar ()) == ' ')

;

putchar (;

}

else putchar ©;

}

[TingleTangle]

@ U.L.

1. gut das du so klug bist

2. Erst erzaehlst du mir das der Code Beispielfunktionen fuer Frischlinge hat, aber sagst einen Satz spaeter das die 'Quick&Dirty' - Loesung ja voellig reicht, weil ja eh keine Arrays verwendet werden. ??

3. Nat. gibt es auch 8bit Compiler/Systeme.

4. Deine Beweisfuehrung in allen Ehren, aber das ist wie gesagt Compilerspezifisch (und dann auch noch disassembliert?!?(welches Optimize Level denn??) am besten im Debugger! ROTFL). Ich gehe davon aus das du das auf einer WINTEL(Oder Linux auf Intel/Motorola-Maschine getestet hast). Bei einem µC z.B. kann der Spass naemlich gleich ganz anders aussehen.

5. short muss nicht auf Registergroesse "augeblasen" werden, da es genaudiese haben sollte. Ausser du hast vielleicht so einen Shareware-Compiler(evtl. sogar selbst entwickelt :> )

[Dieser Beitrag wurde von DocNeo am 16. Februar 2001 editiert.]

[unite]

Super, vielen Dank!

das Programm läuft wirklich.

Ist eigentlich ziemlich einfach, ich hatte nur mehr mit printf - Befehl gearbeitet, und es klappte irgendwie nicht ganz bei mir.

Vielen dank nochmals!

Bis dann,

Andre

www.crystalbeach.de

------------------

[gajUli]

Hi Doc!

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">Zitat:</font><HR>Original erstellt von DocNeo:

1. gut das du so klug bist

[TingleTangle]

Okay, Okay vergessen wir das. Ist doch egal.

Noch dazu:

>Klar gibts die. Dafuer wird sogar mehr ->entwickelt als fuer PC-Systeme (embedded >systems). Und einer der Vorzuege von C ist, >dass es sich dafuer eignet.

Deswegen verkaufen sich unsere Compiler wahrscheinlich so gut

[d.r.eam]

@Uli Luethen,

<hr>

Es kommt noch besser: In der Schleife sind 3 Vergleichsoperationen auszufuehren, jede braucht bei short 4 Byte Befehlsspeicher zusaetzlich fuer die extsh-Befehle abzueglich 8 Byte fuer zwei Register-Moves in der long-Variante fehlen, also insgesamt die 4 Byte Speichermehrbedarf, die der Disassembler angezeigt hat. Nach Deiner Ueberlegung, dass die zwei short-Variablen weniger Speicher brauchen als long, duerfte das aber nicht sein.

<hr>

Wirklich interessant deine Ausführungen, könntest du mir evtl. gute Literatur zum Thema Speicherbedarf & Dissambler empfehlen.

mfg david

[gajUli]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">Zitat:</font><HR>Original erstellt von d.r.eam:

Wirklich interessant deine Ausführungen, könntest du mir evtl. gute Literatur zum Thema Speicherbedarf & Dissambler empfehlen.

[Ketzer]

Hi Leute,

ist ja mal wieder ein interessantes Grundsatzfragen Thema:

"Codeoptimierung Vs funktionierender Code"

Code zu Optimieren ist sicherlich nicht blöd, aber sollte man als Entwickler nicht zuerst funktionierende Programme schreiben?

Und meiner Erfahrung nach gibt es da immer noch eine Menge zu tun, denn des öfteren sind Anwendungen instabil.

(von schlechtem Design mal ganz zu schweigen)

Und die Entwickler unterhalten sich über code-optimierung und nicht über QS-Verfahren...

Ketzer

testen,testen,testen...und an den User denken!

[gajUli]

Hi Ketzer,

ich versteh nicht so ganz, warum Du optimierten Code in einem Gegensatz zu userfreundlichem Verhalten siehst. Ist aber auch immer vom Anwendungsfall abhaengig. Wenn ich bei einer haeufig aufgerufenen Routine eine Sekunde Runtime spare, nun ja, ein hochbelasteter Server wird es mir danken, indem er meine Kunden schneller bedient. Dass Stabilitaet an hoechster Stelle steht, zweifelt glaube ich niemand an.

Uli

------------------

Uli's Prüfungspages ... die Seite mit den Prüfungshinweisen

[d.r.eam]

Hallo,

ich habe mir mal eine Z80 Emulation runtergeladen mal sehen obs was bringt.

Zur Not haben wir auch einen Lehrer der an solchen Rechnern seine Glanzzeiten hatte, vielleicht nützt der ja wenigstens zu diesem Thema.:-)

@Ketzer,

setzt optimierter Code nicht vorraus, das er funktioniert?

mfg d.r.eam

[Ketzer]

Hi Uli,

der Gegensatz resultiert aus meist nicht außreichenden Entwicklungszeiten, denn sonst hätte der Entwickler ja noch Zeit für mehr Stabilitätstests gehabt.

Meiner Erfahrung nach ist das wie folgt:

Die Programme sind zwar meist schnell genug, aber nicht unbedingt ausreichend stabil.

Natürlich gibt es Code, der so oft ausgeführ wird bzw. auf solch große Datenmengen Anwendung findet, das es sinnvoll bzw. sogar notwendig ist diesen zu optimieren.

Ich wollte damit auch nicht zum Ausdruck bringen, das Codeoptimierung Schwachsinn ist, sonder das es schlichtweg wichtigere dinge gibt.

Denn ein nicht bzw. schlecht laufendes Prog ist immer noch schlechter als ein langsam laufendes.

Grüße Ketzer

[gajUli]

@ketzer

OK, das mit dem Zeitfaktor seh ich ein. Wenn ich den Gedanken zu Ende denke, muss man da eigentlich die Schlussfolgerung ziehen, dass man als Kunde eigentlich immer im Nachteil ist, wenn man sich fuer ein kommerzielles Durschnittsprodukt entscheidet. Ein Argument fuer Open-Source Software.

@dream

Na dann viel Spass mit dem alten Zylog. Die Augen Deines alten Lehrers werden vermutlich glaenzen.

Uli