C-Arrays und Stringverarbeitung

[minicrispie]

Hallo,

hab ein kleines Problem mit C.
mein Ziel ist es, alle Zeichen einer Eingabe zu verschlüsseln und zu speichern.
mein bisheriger programmcode:

#include <stdio.h>
#include <string.h>

int main()
{
  char eingabe[80] = "";
  char zeichen[2]  = "";
  char ergebnis[80]= "";
  int i            = 0;

char zeichentabelle;
  zeichentabelle["a"] = "1";
  zeichentabelle["b"] = "2";
  zeichentabelle["c"] = "3";

scanf("%s", &eingabe);

for(i=0; i<80; i++)
  {
    strcpy(zeichen, eingabe[i]);
    strcpy(zeichen, zeichentabelle[&zeichen]);
    strcat(ergebnis, &zeichen);
  }

printf("%s", ergebnis);

fflush(stdin);
  getchar();

return 0;
}

wenn ich jetzt abc eingeben würde, sollte mir 123 augegeben werden.
Nur komm ich nicht einmal zur eingabe. Das Programm bricht sofort nach dem start ab.(Es öffnet sich ein Fenster was irgendwas mit debuggen sagt).
könnt ihr mir sagen, was ich falsch mache? wo liegt der fehler?

MfG. Christoph Ludwig

[minicrispie]

Hallo,

edit: der compiler gibt folgendes aus:

12 C:...\test.c [Warning] assignment makes integer from pointer without a cast

irgendetwas weiter hinten noch dieses:

20 C:...\test.c [Warning] passing arg 2 of strcpy' makes pointer from integer without a cast 22 C:\...\test.c [Warning] passing arg 2 of strcat' from incompatible pointer type

MfG. Christoph Ludwig

[Vinzenz Mai]

Hallo Christoph,

char zeichentabelle;

// Eine Variable, die genau ein char aufnehmen kann.

was bitte soll das Folgende?

zeichentabelle["a"] = "1";
  zeichentabelle["b"] = "2";
  zeichentabelle["c"] = "3";

C-Arrays sind keine PHP-Arrays.
C-Arrays sind ganz speziell keine assoziativen Arrays.

Deine Variable zeichentabelle ist *kein* Array.

scanf("%s", &eingabe);

scanf ist böse [tm]. Was ist, wenn Du mehr als 79 Zeichen eingibst?
Denke daran, dass C-Zeichenketten nullterminiert sind.

Unkommentierter Code ist miserabler Code.

Freundliche Grüße

Vinzenz

[minicrispie]

Hallo,

Hallo Christoph,

char zeichentabelle;
// Eine Variable, die genau ein char aufnehmen kann.

also char zeichentabelle[4]; ?

Deine Variable zeichentabelle ist *kein* Array.

und wie mache ich sie zu einem Array?

scanf ist böse [tm]. Was ist, wenn Du mehr als 79 Zeichen eingibst?
Denke daran, dass C-Zeichenketten nullterminiert sind.

und welche funktion eignet sich dann?
eingabe = getchar()  ?

Unkommentierter Code ist miserabler Code.

ist mir klar ... nur das ist ein programm, welches recht klein und eigentlich übersichtlich ist. Deswegen hab ich sie weggelassen.

MfG. Christoph Ludwig

[Vinzenz Mai]

Hallo Christoph,

char zeichentabelle;
// Eine Variable, die genau ein char aufnehmen kann.

also char zeichentabelle[4]; ?

ja, das ist ein Array, das vier Elemente vom Typ char aufnehmen kann.

Deine Variable zeichentabelle ist *kein* Array.
und wie mache ich sie zu einem Array?

s.o.

scanf ist böse [tm]. Was ist, wenn Du mehr als 79 Zeichen eingibst?
Denke daran, dass C-Zeichenketten nullterminiert sind.

und welche funktion eignet sich dann?

</archiv/2008/8/t175521/#m1153658>, Archivsuche mit "scanf böse" :-)

Unkommentierter Code ist miserabler Code.

ist mir klar ... nur das ist ein programm, welches recht klein und eigentlich übersichtlich ist. Deswegen hab ich sie weggelassen.

Dann ist es noch viel wichtiger Kommentare zu schreiben. Ich schreibe die Kommentare, bevor ich Code schreibe. Normalerweise schreibt man übrigens, was man tun will, nicht wie man es macht. Spezielle Tricks sind natürlich zu erläutern - und für einen Anfänger ist alles ein spezieller Trick :-)

Freundliche Grüße

Vinzenz

[minicrispie]

Hallo,

also char zeichentabelle[4]; ?

ja, das ist ein Array, das vier Elemente vom Typ char aufnehmen kann.

naja das reicht für das beispiel ^^

wie definiere ich ein Array, mit welchem ich ein zeichen durch drei ersetzen kann?
JS-Beispiel:
var array = new array();
array["a"] = "001";
array["b"] = "002";
array["c"] = "003";

wie kann ich sowas in c realisieren?

MfG. Christoph Ludwig

[Vinzenz Mai]

Hallo,

JS-Beispiel:
var array = new array();
array["a"] = "001";
array["b"] = "002";
array["c"] = "003";

wie kann ich sowas in c realisieren?

das hängt davon ab :-)

a) Definiere Deine Aufgabenstellung genau.
   Was willst Du erreichen?

Hier hast Du etwas ganz anderes als in Deinem Ausgangsposting. Hier ersetzt Du jedes Zeichen der Eingabe durch drei Zeichen in der Ausgabe. Der Ausgabestring ist folglich dreimal so lang wie die Eingabe. Willst Du das wirklich?

Nächster Punkt:

Dein Programm besteht aus drei verschiedenen Teilen:

a) Eingabe
 b) Verarbeitung
 c) Ausgabe

Es ist eine verflixt gute Idee, bereits bei solch' simplen Programmen, diese Aufgaben mit Funktionen zu erledigen. Es erleichtert Dir ganz gewaltig das Testen und hilft Dir Fehler zu vermeiden:

a) Eingabe
/*
    Aufgabe:
    Liefert die Eingabe des Benutzers als eine nullterminierte Zeichenkette
    zurück.
    Seiteneffekt:
    Allokiert den notwendigen Speicher
*/
char* eingabe()

// Alternativ: übergebe den Eingabepuffer
// void eingabe(char* puffer)

b) Verarbeitung
/*
    Aufgabe:
    Codiert eine Eingabezeichenkette gemäß Vorschrift.
    Seiteneffekt:
    Allokiert den notwendigen Speicher
*/
char* codiere(char* eingabe)

// Alternative: übergebe Ein- und Ausgabepuffer (call by Reference)
// void codiere(char* klartext, char* chiffre)

c) Ausgabe
/*
    Aufgabe:
    gibt die übergebene Zeichenkette aus
*/
void ausgabe(char* zeichenkette)

d) Aufräumen
/*
    Aufgabe:
    gebe den dynamisch angeforderten Speicher wieder frei.
*/
// Anmerkung: entfällt bei Ein- und Ausgabepuffern, die per Referenz
//            übergeben werden (wäre also einfacher)

Grundsätzlich musst Du bei Zeichenketten in C gut aufpassen, um Buffer Overflows zu vermeiden.

Kurz und gut: Warum um alles in der Welt willst Du Dir C antun? Warum Stringverarbeitung in C (die letzte Sprache, in der ich dies tun möchte).

Freundliche Grüße

Vinzenz

[minicrispie]

Hallo,

Hier hast Du etwas ganz anderes als in Deinem Ausgangsposting. Hier ersetzt Du jedes Zeichen der Eingabe durch drei Zeichen in der Ausgabe. Der Ausgabestring ist folglich dreimal so lang wie die Eingabe. Willst Du das wirklich?

ja. das will ich wirklich.

[...]

ok ... da werd ich mir mal etwas zusammenbasteln ;)

Kurz und gut: Warum um alles in der Welt willst Du Dir C antun? Warum Stringverarbeitung in C (die letzte Sprache, in der ich dies tun möchte).

warum nicht? welche Sprache würdest du verwenden?

MfG. Christoph Ludwig

[Vinzenz Mai]

Hallo,

Kurz und gut: Warum um alles in der Welt willst Du Dir C antun? Warum Stringverarbeitung in C (die letzte Sprache, in der ich dies tun möchte).

warum nicht?

weil sie kompliziert und fehlerträchtig ist.

welche Sprache würdest du verwenden?

eine, die einen Datentyp für Zeichenketten eingebaut hat. Python ist eine tolle Sprache, um Programmieren zu lernen (und zu lehren ;-))

Freundliche Grüße

Vinzenz

[dedlfix]

echo $begrüßung;

Kurz und gut: Warum um alles in der Welt willst Du Dir C antun? Warum Stringverarbeitung in C (die letzte Sprache, in der ich dies tun möchte).
warum nicht? welche Sprache würdest du verwenden?

C passt doch eher zu Chemnitz. In Dresden wohnend wäre wohl D angebrachter.</wortspiel>

D wurde so entworfen, dass man viele der Fallstricke aus C und C++ links liegen lassen kann, aber sie auch verwenden kann, wenn man das unbedingt will.

echo "$verabschiedung $name";

[minicrispie]

Hallo,

echo $begrüßung;

printf("Hallo %s", HerrVonUndZu);

C passt doch eher zu Chemnitz. In Dresden wohnend wäre wohl D angebrachter.</wortspiel>
D wurde so entworfen, dass man viele der Fallstricke aus C und C++ links liegen lassen kann, aber sie auch verwenden kann, wenn man das unbedingt will.

wow ... gibts dann noch A und B ? *g*

echo "$verabschiedung $name";

echo "Sehr sinnvoller Beitrag, Her von und zu " . $name;
echo $Tschau . "!";

MfG. Christoph Ludwig

[Vinzenz Mai]

Hallo,

D wurde so entworfen, dass man viele der Fallstricke aus C und C++ links liegen lassen kann, aber sie auch verwenden kann, wenn man das unbedingt will.

wow ... gibts dann noch A und B ? *g*

A#.NET, B ;-)

ich liste meist: "Ada, Basic, C, Delphi, Eiffel, FORTRAN, ..."

Freundliche Grüße

Vinzenz

[Der Martin]

Hallo Vinzenz,

Seiteneffekt:
    Seiteneffekt:

das ist eine häufig anzutreffende, aber schlechte Übersetzung des englischen Begriffs "side effect" - ebenso wie "nicht wirklich" eine schlechte Übersetzung für die Floskel "not really" ist (besser: "eigentlich nicht"), oder "Sinn machen" für "make sense" (richtig: "Sinn ergeben", "sinnvoll sein").
Im Deutschen sollte man für "side effect" besser den Ausdruck "Nebenwirkung" benutzen.

Kurz und gut: Warum um alles in der Welt willst Du Dir C antun? Warum Stringverarbeitung in C (die letzte Sprache, in der ich dies tun möchte).

Für mich eine Sprache, in der das richtig Spaß macht.
Alles Geschmackssache. ;-)

Schönes Wochenende,
 Martin

[Vinzenz Mai]

Hallo,

Im Deutschen sollte man für "side effect" besser den Ausdruck "Nebenwirkung" benutzen.

das erscheint mir durchaus plausibel. Mal gespannt, ob ich's mir merken kann.

Kurz und gut: Warum um alles in der Welt willst Du Dir C antun? Warum Stringverarbeitung in C (die letzte Sprache, in der ich dies tun möchte).

Für mich eine Sprache, in der das richtig Spaß macht.
Alles Geschmackssache. ;-)

Als ich's gelernt hab', hat's mir auch Spass gemacht. Andere Sprachen haben mir inzwischen den Geschmack daran genommen.

Ich glaube, dass die Zeichenkettenverarbeitung in C für Einsteiger mit Kenntnissen anderer Programmiersprachen eine enorme Hürde darstellt. Ich glaube weiterhin, dass gerade C-Zeichenkettenverarbeitung auch für erfahrene C-Programmierer eine Hauptquelle für Fehler des Typs "Buffer overflow" sind. Die Lernkurve ist verflixt steil, und dazu bleibt der Umgang mit Zeichenketten ein ständiger Stolperstein.

Freundliche Grüße

Vinzenz

[Tom]

Hello,

Ich glaube, dass die Zeichenkettenverarbeitung in C für Einsteiger mit Kenntnissen anderer Programmiersprachen eine enorme Hürde darstellt. Ich glaube weiterhin, dass gerade C-Zeichenkettenverarbeitung auch für erfahrene C-Programmierer eine Hauptquelle für Fehler des Typs "Buffer overflow" sind.

Sie ist zumindest eine Ursache für schnelle Ermüdung ;-)

Da ist (Turbo-)Pascal wesentlich komfortabler gebaut und ich verstehe bis heute nicht, warum sich das nicht besser durchgesetzt hat.

Erst bei C++ gibt es dann wieder einigen Komfort. Aber Bjarne Stroutrup sagt in mehreren Interviews selber, dass er es heute ganz anders machen würde, klarer, leichter verständlich, einheitlicher. Aber für C++0 habe er schon wieder ganz viele Kompromisse machen müssen, um die Forderungen vieler alter Zopfträger doch noch zu erfüllen, obwohl die voraussichtlich morgen keiner mehr benutzen würde. Schaun wir also mal, ob es dieses Jahr noch was wird mit einem RC oder wenigstens nächstes.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Der Martin]

Hi,

Warum Stringverarbeitung in C (die letzte Sprache, in der ich dies tun möchte).
Für mich eine Sprache, in der das richtig Spaß macht.
Als ich's gelernt hab', hat's mir auch Spass gemacht. Andere Sprachen haben mir inzwischen den Geschmack daran genommen.

andere Sprachen haben mir einige Male bestätigt, wie gut mir C gefällt.
Du weißt doch, ich bin als Programmierer am liebsten im Low-Level-Bereich tätig. Und gerade da schätze ich die Philosophie von C:
 * Alles ist erlaubt, wenn man genau weiß, was man tut
 * Alles selbst machen zu müssen, heißt auch, alles selbst machen zu *können*

Ich glaube, dass die Zeichenkettenverarbeitung in C für Einsteiger mit Kenntnissen anderer Programmiersprachen eine enorme Hürde darstellt.

Ja, wenn jemand schon andere Programmiersprachen mit einer "komfortablen" Handhabung von Strings kennt, mag das Prinzip in C archaisch erscheinen. Ich find's dagegen gerade wegen seiner Einfachheit schon wieder elegant.

Ich glaube weiterhin, dass gerade C-Zeichenkettenverarbeitung auch für erfahrene C-Programmierer eine Hauptquelle für Fehler des Typs "Buffer overflow" sind. Die Lernkurve ist verflixt steil, und dazu bleibt der Umgang mit Zeichenketten ein ständiger Stolperstein.

Wenn man sich so weit in die Materie hineindenken kann, dass man *versteht*, was da wirklich abläuft, ist das alles nicht so wild. Wichtig ist, dass man tatsächlich jeden Schritt aufmerksam betrachtet und hinterfragt.

Schönes Wochenende,
 Martin

[Vinzenz Mai]

Hallo,

Ich glaube weiterhin, dass gerade C-Zeichenkettenverarbeitung auch für erfahrene C-Programmierer eine Hauptquelle für Fehler des Typs "Buffer overflow" sind. Die Lernkurve ist verflixt steil, und dazu bleibt der Umgang mit Zeichenketten ein ständiger Stolperstein.

Wenn man sich so weit in die Materie hineindenken kann, dass man *versteht*, was da wirklich abläuft, ist das alles nicht so wild. Wichtig ist, dass man tatsächlich jeden Schritt aufmerksam betrachtet und hinterfragt.

sorry, wenn ich mir die ständigen "Buffer Overflows" anschaue (Windows, Linux, ...), dann bezweifle ich das ganz einfach. Und nein, wenn ich Zeichenkettenverarbeitung betreibe, dann will ich Zeichenketten verarbeiten - und mich nicht um Speicherverwaltung und die Darstellung von Zeichenketten kümmern müssen.

*Mir* macht das keinen Spass - und ich finde die Kompliziertheit und die Klippen von C-Strings [1] alles andere als elegant.

Freundliche Grüße

Vinzenz

[1] wär's so einfach und glatt wie 'ne C-Saite, wär's was anderes.
    Solche Seiten hat C aber nicht :-)

[Vinzenz Mai]

Hallo Christoph,

also char zeichentabelle[4]; ?

ja, das ist ein Array, das vier Elemente vom Typ char aufnehmen kann.
naja das reicht für das beispiel ^^

wie definiere ich ein Array, mit welchem ich ein zeichen durch drei ersetzen kann?
JS-Beispiel:
var array = new array();
array["a"] = "001";
array["b"] = "002";
array["c"] = "003";

wie kann ich sowas in c realisieren?

Hier ein Beispiel (ich habs in Visual C++ getestet), das Dir eine Möglichkeit aufzeigt. Beachte, dass ich explizit ausnutze, dass ein Zeichen einem Byte entspricht.

Anmerkung:
Alle Kommentare, die angeben, *wie* sich etwas auswirkt, sind zu Lehrzwecken
für Christoph gedacht - und sind normalerweise überflüssig.

  
#include <stdio.h>  
#include <string.h>  
  
int main()  
{  
    // Jedes Byte-Zeichen wird mit einer dreibuchstabigen Zeichenkette ersetzt  
    // Wir benötigen daher ein Array mit 256 Einträgen, die jeweils 4 Byte  
    // aufnehmen können: 3 Buchstaben plus die Terminierung  
    char kodierungstabelle[256][3+1];  
  
    // Puffer für die Eingabe, 80 Nutzzeichen  
    char eingabe[80 + 1] = "";  
    // Puffer für die Ausgabe, 3*80 Nutzzeichen erforderlich  
    char ausgabe[240 + 1] = "";  
    // Anmerkung: potentielle Fehlerquelle, wenn die eine Angabe angepasst  
    //            wird, die andere dagegen nicht.  
  
    // Zählvariable  
    size_t i = 0;  
    // Anzahl der Zeichen im Eingabepuffer  
    size_t anzahl = 0;  
    // maximale Puffergröße  
    size_t maxsize = 80;  
  
    // Zeichenkette, die uns als Test dient.  
    // Ein- und Ausgabe lassen wir noch außen vor :-)  
    char test[] = "Hallo";  
  
    /*  
     * Initialisiere die Kodierungstabelle. Jedes Zeichen erhält als  
     * Kodierung eine dreibuchstabige Zeichenkette, die den Wert des  
     * Bytes mit führenden Nullen in Dezimalschreibweise repräsentiert:  
     *  
     * 0x00 : => "000"  
     * 0x01 : => "001"  
     * ...  
     * 0xFF : => "255"  
     *  
     */  
    for (i = 0; i < 256; i++) {  
        // %03u sorgt für führende Nullen (0) und dreistellige (3)  
        // Ganzzahlen, siehe Handbuch, Formatspezifikationen  
        sprintf_s (kodierungstabelle[i], 4, "%03u", i);  
    }  
  
    // Kopiere die Zeichenkette "Hallo" in den Eingabepuffer  
    strcpy_s(eingabe, test);  
  
    // Ermittle die Anzahl der Nutzzeichen im Eingabepuffer  
    // Beachte: Nullzeichen wird *nicht* mitgezählt  
    anzahl = strnlen(eingabe, maxsize);  
  
    // Kodiere die Nutzzeichen  
    /*  
     * Wir nutzen aus, dass ein Zeichen gerade ein Byte ist  
     * Da es implementierungsabhängig ist, ob der Datentyp char vorzeichenlos  
     * oder vorzeichenbehaftet ist, wandeln wir das Zeichen an der i-ten  
     * Stelle explizit in eine vorzeichenlose Zahl um, so dass der  
     * Wertebereich von 0 bis 255 geht und damit einen gültigen Eintrag in  
     * der Kodierungstabelle angibt.  
     */  
    for (i = 0; i < anzahl; i++) {  
        // Kontrollausgabe  
        printf_s ("Index: %d - Zeichen: %c - Kodierung: %s\n",  
                  i,  
                  eingabe[i],  
                  kodierungstabelle[(unsigned char)eingabe[i]]);  
        // strcat_s hängt ein terminierendes Nullzeichen an, wir brauchen uns  
        // nicht mehr darum zu kümmern.  
        strcat_s(ausgabe, kodierungstabelle[(unsigned char)eingabe[i]]);  
    }  
  
    // Kontrollausgabe, Klartext und Chiffre  
    printf_s("Klartext: %s, Chiffre: %s", eingabe, ausgabe);  
  
    return 0;  
}  

Vielleicht siehst Du jetzt etwas weiter.

Freundliche Grüße

Vinzenz

[minicrispie]

Hallo,

Anmerkung:
Alle Kommentare, die angeben, *wie* sich etwas auswirkt, sind zu Lehrzwecken
für Christoph gedacht - und sind normalerweise überflüssig.

wie nett ^^

#include <stdio.h>
#include <string.h>

int main()
{
    //...
    return 0;
}

>   
> Vielleicht siehst Du jetzt etwas weiter.  
  
also ich hab mir das jetzt durchgelesen, und scheine es auch zu verstehen. Allerdings wollte ich das ganze natürlich auch mal testen:  
  
es liegt warscheinlich daran, das ich den Blodsheet Dev C++ benutze ... aber er gibt mir fehlermeldungen aus:  
  
  [Linker error] undefined reference to `sprintf\_s'  
  [Linker error] undefined reference to `strcpy\_s'  
  [...] usw.  
  
woran liegt das jetz, das der MS-Compiler die Befehle kennt und der Blodsheet nicht?  
Ich werde mal die funktionen umschreiben in solche, die in den Lehrbüchern stehen:  
printf\_s() --> printf()   etc ....  
  
ansonsten kann ich erst einmal nur danke sagen :)  
  
  
MfG. Christoph Ludwig

-- 
Wo die Sprache aufhört, fängt die Musik an...  
Selfcode:  ie:( fl:| br:^ va:| ls:/ fo:| rl:? n4:) ss:) de:] js:) ch:{ sh:) mo:) zu:)  
  
Go to [this](http://home.arcor.de/minicrispie/index.html) 

[Vinzenz Mai]

Hallo,

Anmerkung:
Alle Kommentare, die angeben, *wie* sich etwas auswirkt, sind zu Lehrzwecken
für Christoph gedacht - und sind normalerweise überflüssig.
wie nett ^^

so bin ich halt :-)

es liegt warscheinlich daran, das ich den Blodsheet Dev C++ benutze ... aber er gibt mir fehlermeldungen aus:

[Linker error] undefined reference to sprintf\_s'   [Linker error] undefined reference to strcpy_s'
  [...] usw.

woran liegt das jetz, das der MS-Compiler die Befehle kennt und der Blodsheet nicht?

Ja. Ich wollte mir ehrlich gesagt, nicht die Arbeit machen, noch einen weiteren C-Compiler zu installieren. Ich schreibe derzeit sehr selten was in C bzw. C++, und wenn, für Windows. Da reicht mir mein Visual Studio völlig aus.

Ich werde mal die funktionen umschreiben in solche, die in den Lehrbüchern stehen:
printf_s() --> printf()   etc ....

an diesen Stellen musst Du ggf. zusätzliche Parameter der sichereren Funktionen entfernen.

Freundliche Grüße

Vinzenz

[minicrispie]

Hallo,

Ja. Ich wollte mir ehrlich gesagt, nicht die Arbeit machen, noch einen weiteren C-Compiler zu installieren. Ich schreibe derzeit sehr selten was in C bzw. C++, und wenn, für Windows. Da reicht mir mein Visual Studio völlig aus.

musst du auch nicht.
ich persönlich finde den compiler von MS ziemlich Bullshit, aber das muss jeder selber wissen ;)

an diesen Stellen musst Du ggf. zusätzliche Parameter der sichereren Funktionen entfernen.

genau^^ ... ich hab schon das büchlein vor mir :)
werde sicher heute nicht fertig, da ich nicht vor habe, den ganzen tag am pC zu verbringen ;)
aber ich sag bescheid, wenns so weit ist ...

MfG. Christoph Ludwig

[Vinzenz Mai]

Hallo,

Ja. Ich wollte mir ehrlich gesagt, nicht die Arbeit machen, noch einen weiteren C-Compiler zu installieren. Ich schreibe derzeit sehr selten was in C bzw. C++, und wenn, für Windows. Da reicht mir mein Visual Studio völlig aus.

musst du auch nicht.
ich persönlich finde den compiler von MS ziemlich Bullshit, aber das muss jeder selber wissen ;)

ich finde die IDE zum Entwickeln und Debuggen sehr angenehm. Den spartanischen GNU-Werkzeugen konnte ich nichts abgewinnen; ich bin seit meiner ersten Begegnung mit C auf einer VAX unter OpenVMS und einer wirklich genialen Entwicklungsumgebung (an der Textkonsole) zu sehr verwöhnt. Vielleicht gibt's von/mit GNU heutzutage ja auch was Ordentliches, ich kenn's nur nicht.

Freundliche Grüße

Vinzenz

[hotti]

hi,

Unkommentierter Code ist miserabler Code.

Wenn die Kommentare nicht zum Code passen, kann auch der Code falsch sein.

SCNR ;-)

[Vinzenz Mai]

Hallo,

Unkommentierter Code ist miserabler Code.

Wenn die Kommentare nicht zum Code passen, kann auch der Code falsch sein.

ja und? Was willst Du damit sagen?

Fragende Grüße

Vinzenz

[hotti]

Hallo,

Unkommentierter Code ist miserabler Code.

Wenn die Kommentare nicht zum Code passen, kann auch der Code falsch sein.

ja und? Was willst Du damit sagen?

Ganz einfach: heute ist Freitag!

Hotti ;-)

[minicrispie]

Hallo,

Wenn die Kommentare nicht zum Code passen, kann auch der Code falsch sein.

normalerweise schreibt man die kommentare PASSEND zum code ;)

MfG. Christoph Ludwig

[Multi]

normalerweise schreibt man die kommentare PASSEND zum code ;)

Genau andersrum.
Man überlegt sich erst, was man machen will und hat dadurch den Kommentar. Dann schreibt man danach den Code.
Alles andere wird irgendwann zu einer unübersichtlichen Codesuppe führen ;

[minicrispie]

Hallo,

Genau andersrum.
Man überlegt sich erst, was man machen will und hat dadurch den Kommentar. Dann schreibt man danach den Code.
Alles andere wird irgendwann zu einer unübersichtlichen Codesuppe führen;

nö ... ich erstell mir vorher ein metashema etc ... dann seh ich das alles und kann somit mein programm erstellen ... ich halte mich also nach dem wasserfallmodel :)
also schreibe ich die kommentare zusammen mit dem code ...

MfG. Christoph Ludwig

[Vinzenz Mai]

Hallo,

nö ... ich erstell mir vorher ein metashema etc ... dann seh ich das alles und kann somit mein programm erstellen ... ich halte mich also nach dem wasserfallmodel :)
also schreibe ich die kommentare zusammen mit dem code ...

woraus ich schließe, dass Du keinen Code gepostet hast ;-)

Achso: damit Du Dich nicht mit der Eingabe herumplagen musst, könntest Du die Eingabe an der Kommandozeile mit übergeben:

<shell-prompt>mein_programm "Das ist der zu codierende Text"

Freundliche Grüße

Vinzenz

[Multi]

nö ... ich erstell mir vorher ein metashema etc ... dann seh ich das alles und kann somit mein programm erstellen ...

Und dceine Kommentare weichen von diesem Schema ab? Wenn nicht, hast du ja praktisch die Kommentare vorher geschrieben ;)

ich halte mich also nach dem wasserfallmodel :)

Wenn ich das lese, zieht es mir die Schuhe aus, weil ich selbst entsprechende Erfahrung gemacht hab.
Sowas mag bei kleinen Programmen noch gutgehen. Wenn du aber erstmal viele tausend Zeilen Code hast, wirst du diese Methode verfluchen, weil du nicht mehr durchblickst.

Wissen musst du es natürlich selbst, wenn du damit auf Dauer zurechtkommst, ist das in Ordnung. IMO ist es aber einfacher, gleich von Anfang an so strukturiert zu arbeiten um später nicht umlernen zu müssen.

[Stefanie]

Hi,

Unkommentierter Code ist miserabler Code.

Jein. Der beste Code ist selbst-kommentierend, zumindest überwiegend. Es ist verdächtig, wenn ein Code geradezu danach schreit, kommentiert zu werden, weil man ihn sonst nicht versteht.

Ciao
Stefanie

[Harlequin]

Yerf!

Jein. Der beste Code ist selbst-kommentierend, zumindest überwiegend.

Selbs-kommentierender Code ist ein Wunschtraum. Der Code kann höchstens das "wie" kommentieren, aber niemals das "warum". Aber gerade die 2. Information ist die eigentlich wichtige.

(Warum greift der Code auf nicht initialisierten Speicher zu? Das wirft doch nur Warnings...)

Gruß,

Harlequin

[Stefanie]

Hi,

Selbs-kommentierender Code ist ein Wunschtraum. Der Code kann höchstens das "wie" kommentieren, aber niemals das "warum". Aber gerade die 2. Information ist die eigentlich wichtige.

Sagen wir mal so: Das "wie" sollte sowieso solange wie möglich verborgen bleiben und der Code stattdessen selber schreiben "was" er macht. Ich halte das nicht für weniger wichtig. Aber ich schrieb ja auch schon "überwiegend". Du hast recht, dass grobe Struktur-Beschreibugen, Entscheidungen für bestimmte Lösungswege, wichtige Anmerkungen usw.
über Kommentare zu realisieren sind (und für automatisierte Dokumentation ja auch nötig).

(Warum greift der Code auf nicht initialisierten Speicher zu? Das wirft doch nur Warnings...)

Meinst Du jetzt bestimmten Code, oder willst Du mir sagen, dass Du warnings begegnest in dem Du einen Kommentar dazu schreibst, statt sie zu eliminieren...?

Ciao
Stefanie

[Harlequin]

Yerf!

Sagen wir mal so: Das "wie" sollte sowieso solange wie möglich verborgen bleiben und der Code stattdessen selber schreiben "was" er macht. Ich halte das nicht für weniger wichtig.

Ok, in der Hinsicht sollte natürlich der Code für sich selbst sprechen.

Aber ich schrieb ja auch schon "überwiegend". Du hast recht, dass grobe Struktur-Beschreibugen, Entscheidungen für bestimmte Lösungswege, wichtige Anmerkungen usw.
über Kommentare zu realisieren sind (und für automatisierte Dokumentation ja auch nötig).

Mich hat an dem "überwiegend" nur die gewichtung gestört, da ich eben den anderen teil als wichtiger ansehe.

(Warum greift der Code auf nicht initialisierten Speicher zu? Das wirft doch nur Warnings...)

Meinst Du jetzt bestimmten Code, oder willst Du mir sagen, dass Du warnings begegnest in dem Du einen Kommentar dazu schreibst, statt sie zu eliminieren...?

Sollte ein Seitenhieb auf Debian werden, wo jemand einen Codeteil entfernt hat, weil er Warnings wegen nicht initialisierten Speicher geworfen hat. Leider wurde das eignetlich zum Erzeugen von Enthropie für die SSH-Schlüssel verwendet...

Mit einem entsprechenden Kommentar, "warum" das so gemacht wird wäre das vielleicht nicht passiert.

Gruß,

Harlequin

[Tom]

Hello,

Sollte ein Seitenhieb auf Debian werden, wo jemand einen Codeteil entfernt hat, weil er Warnings wegen nicht initialisierten Speicher geworfen hat. Leider wurde das eignetlich zum Erzeugen von Enthropie für die SSH-Schlüssel verwendet...

*ups*

Im erten Moment ging mir durch den Bauch: da wollte wohl jemand Zufallszahlen erzeugen. Aber es war nicht stark genug, um bis in den Kopf zu kommen. Eigentlich habe ich sogar gedacht: das wird doch kleinem Programmierer in den Kopf kommen, ohne 'was dazu zu schreiben und schon gar nicht einem, der am Debian-Projekt mitschreibt... ;-)

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Vinzenz Mai]

Hallo,

(Warum greift der Code auf nicht initialisierten Speicher zu? Das wirft doch nur Warnings...)

Meinst Du jetzt bestimmten Code, oder willst Du mir sagen, dass Du warnings begegnest in dem Du einen Kommentar dazu schreibst, statt sie zu eliminieren...?

Sollte ein Seitenhieb auf Debian werden,

Du meinst wohl auf OpenSSL :-)

wo jemand einen Codeteil entfernt hat, weil er Warnings wegen nicht initialisierten Speicher geworfen hat. Leider wurde das eignetlich zum Erzeugen von Enthropie für die SSH-Schlüssel verwendet...

Mit einem entsprechenden Kommentar, "warum" das so gemacht wird wäre das vielleicht nicht passiert.

so etwas wichtiges nicht zu dokumentieren, ist Entwicklerblödheit hoch 10.
Debian ließ sich seinen Patch ja von den OpenSSL-Entwicklern absegnen. Und die merkten aufgrund ihres eigenen Codes nicht, worum es an der Stelle wirklich ging.

Ein wundervolles Beispiel für eigentlich ausgezeichneten Code, der aufgrund fehlender Kommentare die Qualifizierung "miserabler Code" verdient.

Freundliche Grüße

Vinzenz

[Der Martin]

Hallo Stefanie,

Der beste Code ist selbst-kommentierend, zumindest überwiegend.

in gewissem Umfang stimme ich dieser Aussage zu. Eine günstige Benamsung von Variablen und Funktionen kann zum Beispiel *sehr* viel zur Verständlichkeit von Programmcode beitragen, so dass manche Abschnitte wirklich selbsterklärend sind. Ein Statement wie

if (isValidInput(arg))
   {
   }

braucht für sich allein keinen Kommentar mehr. Aber wie hier auch schon angesprochen wurde, geht es ja auch darum, die Zusammenhänge zu beschreiben. In diesem Beispiel also: Wo kommt arg her, welche Bedingungen erfüllt dieses Datum sowieso schon, welche Annahmen macht die Funktion isValidInput(), die vielleicht nicht immer zutreffen.

Es ist verdächtig, wenn ein Code geradezu danach schreit, kommentiert zu werden, weil man ihn sonst nicht versteht.

Allerdings. Und der Programmierer verdient "a Watsch'n".

Schönes Wochenende,
 Martin

[Tom]

Hello,

Es ist verdächtig, wenn ein Code geradezu danach schreit, kommentiert zu werden, weil man ihn sonst nicht versteht.

Allerdings. Und der Programmierer verdient "a Watsch'n".

Dann verdienen aber auch die Erfinder von C jeder eine Watsch'n, denn diese Sprache lässt erheblich leichter als viele andere zu, dass man schwer lesbaren Code schreibt.

Dabei benötigt expliziter Quellcode in der Ausführung selten mehr Zeit. Bei welchem Code der Parser mehr schuften muss, kann ich jetzt nicht nachvolliehen. Vermutlich wird ihm sauberer expliziter Code auch einfacher fallen, als tief geschachtelte Statements.

Könnte es bei Kurzschreibweisen dann genau umgekehrt sein?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Kai345]

[latex]Mae  govannen![/latex]

Es ist verdächtig, wenn ein Code geradezu danach schreit, kommentiert zu werden, weil man ihn sonst nicht versteht.

Allerdings. Und der Programmierer verdient "a Watsch'n".

Dann verdienen aber auch die Erfinder von C jeder eine Watsch'n, denn diese Sprache lässt erheblich leichter als viele andere zu, dass man schwer lesbaren Code schreibt.

Wenn die Erfinder von C schon "a Watsch'n" verdienen, was machen wir dann mit de(n|m) Erfinder(n) von Regular Expressions? Eine H-Bombe auf den Rücken schnallen und zünden?

Cü,

Kai

[Tom]

Hello,

Allerdings. Und der Programmierer verdient "a Watsch'n".

Dann verdienen aber auch die Erfinder von C jeder eine Watsch'n, denn diese Sprache lässt erheblich leichter als viele andere zu, dass man schwer lesbaren Code schreibt.

Wenn die Erfinder von C schon "a Watsch'n" verdienen, was machen wir dann mit de(n|m) Erfinder(n) von Regular Expressions? Eine H-Bombe auf den Rücken schnallen und zünden?

Die mögen wohl auch kryptisch sein, aber sie sind keine Programmiersprache, sondern nur eine Beschreibungssprache für die RegEx-Engine. Eigentlich sind sie "Bytecode" für die Engine und man müsste die Sprache dazu erst noch erfinden ;-)

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Der Martin]

Hallo,

Es ist verdächtig, wenn ein Code geradezu danach schreit, kommentiert zu werden, weil man ihn sonst nicht versteht.
Allerdings. Und der Programmierer verdient "a Watsch'n".
Dann verdienen aber auch die Erfinder von C jeder eine Watsch'n ...

nein, das sehe ich nicht so.

... denn diese Sprache lässt erheblich leichter als viele andere zu, dass man schwer lesbaren Code schreibt.

Mit nahezu jeder Programmiersprache kann man unübersichtlichen und dadurch fehleranfälligen Code schreiben. Das kannst du nicht der Sprache anlasten.
Schließlich wirst du auch einen Kugelschreiberhersteller nicht belangen wollen, weil manche Menschen mit dessen Kulis schlampig schreiben.

Es ist wohl wahr, dass man in C schwer lesbaren Code produzieren *kann*; das gilt aber für C++ noch mehr, das gilt für PHP und Javascript in besonderem Maß, das gilt sogar für Pascal, obwohl gerade das oft als Musterbeispiel für eine ordentliche, disziplinfordernde Sprache hergenommen wird.

Umgekehrt *kann* man in jeder dieser Sprachen auch sehr übersichtlichen und gut nachvollziehbaren Code schreiben.

Dabei benötigt expliziter Quellcode in der Ausführung selten mehr Zeit.

Was bezeichnest du als "explizit"?
Ich bin ja hier schon bekannt als Programmierer, der einen sehr knappen, kompakten Stil schätzt. Ich bin trotzdem der Ansicht, dass man wichtige Dinge wie das Initialisieren von Daten oder das Prüfen von Fehlerbedingungen auf keinen Fall vernachlässigen darf. Das sehe ich in diesem Zusammenhang als "explizit".

Bei welchem Code der Parser mehr schuften muss, kann ich jetzt nicht nachvolliehen. Vermutlich wird ihm sauberer expliziter Code auch einfacher fallen, als tief geschachtelte Statements.

Bei Compilersprachen wie C oder C++ ist das auch völlig unerheblich. Denn was der Compiler im Endeffekt erzeugt, ist eine lineare Abfolge von Einzelschritten. Wie komplex der zugrundeliegende Quellcode war, spielt dabei keine Rolle. Und ob ein Compiler für die Übersetzung eines Projekts 20 oder 26 Sekunden braucht, ist mir eigentlich völlig wurscht. Selbst wenn es größere Projekte sind: Was soll's, wenn der Compilerlauf eine Viertelstunde länger braucht - mir ist es trotzdem wichtiger, dass ich den Quellcode so schreibe, dass er für mich optimal lesbar und verständlich ist.

Könnte es bei Kurzschreibweisen dann genau umgekehrt sein?

Keine Ahnung, was du damit meinst.

Ciao,
 Martin

[Stefanie]

Hi,

Dann verdienen aber auch die Erfinder von C jeder eine Watsch'n, denn diese Sprache lässt erheblich leichter als viele andere zu, dass man schwer lesbaren Code schreibt.

och..., ich muss im Moment Bash-Skripte schreiben - die Sprache verhindert gerade zu, dass der Code leserlich wird ;-( Deswegen glaube ich die Geschichte mit dem Debian-Programmierer auch unbesehen. Als Linux-Programmierer gilt man doch als Weichei, wenn man Kommentare schreibt ;-) Aber genug der Klischees...

Dabei benötigt expliziter Quellcode in der Ausführung selten mehr Zeit. Bei welchem Code der Parser mehr schuften muss, kann ich jetzt nicht nachvolliehen.

Nun, auch sauber und ausführlich geschriebenen Code in der Ausführung zu optimieren, dass ist ja gerade der Job eines Compilers. Und das können gute Compiler heutzutage auch (Parser natürlich nicht). Natürlich ist von der Laufzeit ein Spaghetti-Code der nur globale Variablen benutzt erstmal schneller, weil der der Prozessor sich nicht damit aufhalten muss, dauernd was auf dem Stack hin und her zu packen und zu springen.

Manche Dinge kann der Compiler nicht wissen, da muss man eben selber dran denken, wenn man Laufzeit-Optimiert programmieren will. Z.B., immer den wahrscheinlicheren Teil einer Abfrage als erstes abzuhandeln, so dass ein Sprung weniger von nöten ist. Fliesszahlen sollten möglichst vermieden werden usw.

Vermutlich wird ihm sauberer expliziter Code auch einfacher fallen, als tief geschachtelte Statements.

Wie gesagt, für die Laufzeit sind tief geschachtelte Statements sogar erstmal besser als Funktionsaufrufe. Aber, hallo, das ist ohnehin nur im harten Echtzeitbereich interessant. Und leider wird da in der Tat die Laufzeit gerne mal als Totschlagargument gegen gut strukturierten Code benutzt (ich muss es wissen, ich arbeite in dem Bereich *gna*) Aber selbst da setzt sich langsam die Erkenntnis durch, dass man sich dadurch zu viele andere schwer lösbare Probleme einhandelt, und dass die Laufzeitoptimierung erst der zweite - und meist gar nicht nötige - Schritt ist.

Ciao
Stefanie

[Harlequin]

Yerf!

och..., ich muss im Moment Bash-Skripte schreiben - die Sprache verhindert gerade zu, dass der Code leserlich wird ;-( Deswegen glaube ich die Geschichte mit dem Debian-Programmierer auch unbesehen. Als Linux-Programmierer gilt man doch als Weichei, wenn man Kommentare schreibt ;-) Aber genug der Klischees...

Die Sache hat damals einige Wellen geschlagen... (siehe auch Heise)

Gruß,

Harlequin

[Tom]

Hello,

och..., ich muss im Moment Bash-Skripte schreiben - die Sprache verhindert gerade zu, dass der Code leserlich wird ;-(

Das steht mir ab Montag bevor. mach mir keine Angst!

Und das können gute Compiler heutzutage auch (Parser natürlich nicht)

Ich dachte an den Parser im Compiler, ohne wird es wohl nicht gehen :-)

Manche Dinge kann der Compiler nicht wissen, da muss man eben selber dran denken, wenn man Laufzeit-Optimiert programmieren will. Z.B., immer den wahrscheinlicheren Teil einer Abfrage als erstes abzuhandeln, so dass ein Sprung weniger von nöten ist. Fliesszahlen sollten möglichst vermieden werden usw.

Mir ging es eigetnlich gar nicht um Optimierung für den Compiler, sondern eher um Optimierung für einen späteren Leser des Codes. Wenn nun explizite Schreibweise nicht zu einem grottenschlechten Laufzeitverhalten führt im Gegensatz zur Einzeilervariante, dann wäre doch die explizite Schreibweise besser, oder?

Wie gesagt, für die Laufzeit sind tief geschachtelte Statements sogar erstmal besser als Funktionsaufrufe. Aber, hallo, das ist ohnehin nur im harten Echtzeitbereich interessant. Und leider wird da in der Tat die Laufzeit gerne mal als Totschlagargument gegen gut strukturierten Code benutzt (ich muss es wissen, ich arbeite in dem Bereich *gna*) Aber selbst da setzt sich langsam die Erkenntnis durch, dass man sich dadurch zu viele andere schwer lösbare Probleme einhandelt, und dass die Laufzeitoptimierung erst der zweite - und meist gar nicht nötige - Schritt ist.

Das beruhigt mich.
Dann kann ich meinen Code ja weiterhin explizit formulieren ;-)

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Stefanie]

Hi Tom,

Mir ging es eigetnlich gar nicht um Optimierung für den Compiler, sondern eher um Optimierung für einen späteren Leser des Codes. Wenn nun explizite Schreibweise nicht zu einem grottenschlechten Laufzeitverhalten führt im Gegensatz zur Einzeilervariante, dann wäre doch die explizite Schreibweise besser, oder?

Aber natürlich, absolut! Das ist ja gerade die Kunst, Code zu schreiben, den Menschen verstehen. Code zu schreiben, den "nur" die Maschine versteht, der sie irgendwie dazu bringt zu tun was sie soll, das ist viel leichter. Warum haben wir denn Hochsprachen entwickelt und schreiben unsere Software nicht mehr in Maschinensprache? Dem Rechner ist das egal - es ist doch die Mensch-Computer-Schnittstelle, die wir verbessern wollen (und müssen).

Das macht die Software leichter wartbar, besser testbar, einfacher von anderen Entwicklern zu übernehmen. Das ist heute bei den Massen ans Software, die jeden unserer Lebensbereiche durchdringt (vor allem auch sehr sicherheitsrelevante) einfach ein Muss.

Hast Du Dich schon mal mit Refactoring beschäftigt? Dürfte Dich interessieren.

LG, Stefanie

[Tom]

Hello,

Hast Du Dich schon mal mit Refactoring beschäftigt? Dürfte Dich interessieren.

Danke für die Anregung.
Jetzt weiß ich endlich, wei man das nennt, was ich die leztzten Jahre immer wieder gemacht habe :-)

Und ab Januar steht mir das mit einem 98% fertigen Projekt bevor. Da muss ich aber noch 'ein wenig' üben, damit ich die Geheimsprache-Teile, die in C++ geschrieben sind, auch richtig verstehe. Das strotzt nur so von Überladungen und sonstigen Tricks, die ich bisher noch nicht verstehe.

Ist natütlich auch meistens nichts dokumentiert :-(

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Vinzenz Mai]

Hallo,

Unkommentierter Code ist miserabler Code.
Jein.

klar, eine Pauschalaussage wie diese meinige ist stets anfechtbar.

Der beste Code ist selbst-kommentierend, zumindest überwiegend.

Selbstverständlich ist es sinnvoll, sprechende Namen für Konstanten, Variablen und Funktionen zu wählen, damit die Kommentierung sparsam ausfallen kann. Selbstkommentierender Code ist jedoch eine Illusion. Mir ist diese Illusion noch nie über den Weg gelaufen. Pseudokommentare wie "initialisert ein foo-Objekt" fallen übrigens in die gleiche Kategorie ...

Es ist verdächtig, wenn ein Code geradezu danach schreit, kommentiert zu werden, weil man ihn sonst nicht versteht.

Eine gewisse Zeit der Vernachlässigung, die Übergabe an einen Babysitter [1] oder Adoptiveltern [2] reichen in vielen Fällen aus. Bei einer ärztlichen Untersuchung [3] erst recht. Dann kann Code verdammt laut werden - wie z.B. der im Ausgangsposting :D

Freundliche Grüße

Vinzenz

[1] "Hey, kannst Du Dir mal die Funktion anschauen. Irgendwas läuft da schief."
[2] Übergabe in andere Hände
[3] Nachfrage in einem Forum

[Tom]

Hello,

Eine gewisse Zeit der Vernachlässigung, die Übergabe an einen Babysitter [1] oder Adoptiveltern [2] reichen in vielen Fällen aus. Bei einer ärztlichen Untersuchung [3] erst recht. Dann kann Code verdammt laut werden - wie z.B. der im Ausgangsposting :D

Die wichtigsten Kommentare sind mMn diejenigen, die kurz mit (sic!) beschrieben werden könnten:
Was hat sich der Programmierer an dieser Stelle gedacht? Ist es ein Programmiertrick oder ist es eine Nachlässigkeit, die sich als Bug entwickeln könnte?

Früher *gg* bei Relaisschaltungen (Telefonanlagen) hatte man immer eine vollständige Funktionsbeschreibung in der Dokumentation, obwohl doch ein geübter Nachrichtentechniker auch sicherlich aus dem Schaltplan irgendwann die Funktionalitäten und die Abhängigkeiten der einzelnen Baugruppen herausgefunden hätte.

Das fand ich immer sehr gut, obwohl selbst ich da erst 14 war ;-)

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Vinzenz Mai]

Hallo,

char eingabe[80] = ""; // Eingabepuffer
  char zeichen[2]  = ""; // Wozu ist diese Variable da?
  char ergebnis[80]= ""; // Ausgabepuffer

int i            = 0;  // Zählvariable

char zeichentabelle;
  zeichentabelle["a"] = "1";
  zeichentabelle["b"] = "2";
  zeichentabelle["c"] = "3";

//  Du hast offensichtlich keinen blassen Schimmer davon, was Du in
//  der Schleife tun willst. Ich verstehe es überhaupt nicht.

//  Meine Idee wäre:
//  Verarbeite die Zeichen des Eingabepuffers zeichenweise.
//  Höre beim Ende auf. Das ist nicht bei 80, das kann früher sein
//  Für jedes Zeichen im Eingabepuffer
//      Ermittle das entsprechende Ersetzungszeichen
//      Hänge das Ersetzungszeichen an den Ausgabepuffer an
//  Ende Für
//  Sorge für die Terminierung des Ausgabestrings (Null-Byte am Ende einfügen

for(i=0; i<80; i++)
  {

// Wenn Du einzelne Zeichen verarbeitest, dann benötigst Du
      // *nicht* strcpy. Da ist direkter Zugriff möglich

strcpy(zeichen, eingabe[i]);

// Zeiger hast Du überhaupt nicht verstanden.
      // Die Adresse eines Zeichens dürfte auf 32-Bit-Systemen 4 Byte,
      // auf 64-Bit-Systemen 8 Byte groß sein. Das ist *kein* Wert.
      // Du möchtest auf den Wert zugreifen.

strcpy(zeichen, zeichentabelle[&zeichen]);

// Argh, was machst Du da überhaupt?

strcat(ergebnis, &zeichen);
  }

Es ist schon rekordverdächtig, wieviele Fehler Du eingebaut hast.

Freundliche Grüße

Vinzenz

[minicrispie]

Hallo,

Es ist schon rekordverdächtig, wieviele Fehler Du eingebaut hast.

ja, kann ich mir denken ...
kannst du mir ein beispiel geben?
ich arbeite sonst ur mit Zahlen &co ... in sachen strings bin ich noch nicht wirklich erfahren ...

MfG. Christoph Ludwig

[Stefanie]

Hi,

ich arbeite sonst ur mit Zahlen &co ... in sachen strings bin ich noch nicht wirklich erfahren ...

Mit Arrays aber auch nicht wirklich, oder...? Vielleicht machst Du Dir erstmal klar, was ein String überhaupt ist, nämlich ein Array aus Zeichen. Jedes Zeichen passt genau in ein Byte und der String ist also eine gewisse Anzahl von Bytes, die im Speicher direkt hintereinander liegen. Dein Rechner kennt den Anfang des Strings, bzw. den String dadurch, dass er die Adresse des ersten Zeichens hat. Das Ende erkennt er _nur_ daran, dass ein Byte mit dem Inhalt 0 folgt. Deshalb ist für den Compiler ein String auch im Grunde nichts weiter als ein Pointer auf ein Zeichen (sprich die Adresse des ersten Zeichens Deines Strings).

Auf die einzelnen Inhalte eines Arrays kannst Du in C _ausschliesslich_ über ihren Index (als einen Zahlwert, also einen Integer) zugreifen, der immer für das erste Element mit 0 beginnt. Du versuchst im Beispiel ein Feld mit "a" zu addressieren. "a" ist ein String und deshalb für den Compiler ein Pointer. Deshalb sagt er Dir, Du versuchst den Wert des Pointers als Integer zu benutzen und warnt Dich, weil das sehr wahrscheinlich nicht das ist, was Du willst (natürlich ist es das nicht).

Versuch mal, in Deinem Programm die Variablen genauer zu benennen, danach welche Funktion sie erfüllen. Dann wird Dir vielleicht manches schon klarer und ohnehin besser zu verstehen. Wenn Du z.B. eingabe eingabeString nennst, dann wird Dir bei der Variable zeichen vielleicht selbst die Diskrepanz auffallen. Denn die heisst zeichen, obwohl sie in Wirklichkeit ein String ist, das "stinkt".

Ach, noch eine dumme Anfängerfalle: Mit einfachen Hochkommata wird genau ein Zeichen zugewiesen. Also z.B. mit 'a' genau das Zeichen a, das passt in ein Byte. Mit doppelten Hochkommate wird aber ein String zugewiesen. "a" ist also nicht nur ein a sondern es ist ein Array aus zwei Bytes in dem das erste den Wert 'a' und das zweite den Wert 0 hat (= String-Ende-Kennung). Und noch ein Unterschied zu PHP: Strings kannst Du in C durch "=" nur bei der Deklaration zuweisen, später musst Du immer mit strcpy arbeiten (besser aber mit strncpy oder memcpy, weil sicherer).

Ich hoffe, das war verständlich. C muss man tatsächlich verstanden haben, um vernünftig damit arbeiten zu können, denn es macht wirklich genau das, was Du ihm sagst ;-)

Ciao
Stefanie

MfG. Christoph Ludwig

[stareagle]

Moin,

könnt ihr mir sagen, was ich falsch mache? wo liegt der fehler?

Darin, das du dich noch ausreichend mit C beschäftigt hast.

Bevor du dich an eigene C-Programme traust, solltest du dich erst mal intensiv mit C auseinandersetzen. Empfehlen kann ich folgendes Buch:

http://openbook.galileocomputing.de/c_von_a_bis_z/

Gruß

Stareagle

[minicrispie]

Hallo,

Bevor du dich an eigene C-Programme traust, solltest du dich erst mal intensiv mit C auseinandersetzen. Empfehlen kann ich folgendes Buch:

http://openbook.galileocomputing.de/c_von_a_bis_z/

ich hab ein gutes buch ... nur irgendwann muss ich ja mit strings anfangen ;)

MfG. Christoph Ludwig