[C] return - zeiger - Seite 3

Seite 3 von 4 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/c_return_zeiger_204643/page_3 - zur Vollversion wechseln!

@DirtyHarry: Ja, das ist es.

gcc rufe ich so auf: gcc file.c -o file.o

http://openbook.galileocomputing.de...40028C21F04A198

um Abbildung 14.19: Wenn ich mir dies anschaue und nichts übersehen habe, dann war das kein einmaliger Ausrutscher des Autors (*string).

Diese Buch zu kübeln würde mir weh tun - erstens gibt es es als Openbook, und zweitens gefällt es mir von der Aufmachung her.

Zitat von lama007

http://openbook.galileocomputing.de...40028C21F04A198

um Abbildung 14.19: Wenn ich mir dies anschaue und nichts übersehen habe, dann war das kein einmaliger Ausrutscher des Autors (*string).

Zitat

Zeiger auf Zeiger ist ein recht schwieriges Thema, aber es zu verstehen, lohnt sich.

Zitat

Bei den ersten drei Ausgaben

printf("%p = %c\n", **sort, **sort);
printf("%p = %c\n", *sort[0], *sort[0]);
printf("%p = %c\n", *(sort[0]+0), *(sort[0]+0));

wurden immer die (Anfangs-)Adressen und Inhalte verwendet, auf die der zweite Zeiger zeigt. Was die Ausgabe auch bestätigt.

Code:

warning: format '%p' expects type 'void *', but argument 2 has type 'int'

Zitat von lama007

Diese Buch zu kübeln würde mir weh tun - erstens gibt es es als Openbook, und zweitens gefällt es mir von der Aufmachung her.

Code:

gcc -ansi -pedantic -Wall ...

Ok, mal schauen, ob ich mir das alles merken kann.

man gcc

Ich hab mir gerade das Kapitel "14.6.1 Zeiger als Rückgabewert" (http://openbook.galileocomputing.de...40028BF1F0331A3) in dem Buch in der überarbeiteten Version nochmal angeschaut und bin etwas irritiert über den Text, der ist meiner Meinung nach Falsch, und das Beispiel auch wieder. Da wird das alte Beispiel als Negativbeispiel angeführt (Haha sehr witzig), das Neue unterscheidet sich aber nur in der Zeile der Rückgabe und warum das so gemacht wird im "Positivbeispiel" wird nirgendwo erwähnt.

Also da mal das "Positivbeispiel":

Code:

char *eingabe(char *str) {
   char input[MAX];
   printf("Bitte \"%s\" eingeben: ",str);
   fgets(input, MAX, stdin);
   return strtok(input, "\n");
}

Zitat von watchout

So viel text...

bei dem codeschnippsel da kommt einem sowieso das speibn :P

der ptr als parameter muß eh ned schlecht sein - wenn er richtig verwendet werden tät

void blablubb( char* ptr )
{
char buf[10];
//buf irgendwie anschreiben von stdin zb
strcpy(ptr, buf);
}

da brauchst dann garkeinen returnvalue mehr ansich, der steht dann an der adresse vom parameter drin, mit ginge das natürlich auch, weil ja einfach nur die adresse vom parameter zurückgegeben werden würde.

mal jetzt so ohne bufferüberlaufkontrolle und sonstigem zeug. das funktioniert sehrwohl.

der übergebene parameter kann da sowohl am stack, als auch am heap sein.

wundert mich nicht wenn soviel buggy software im umlauf is, wenn die alle das openbook von denen gelesen haben

Zitat von Blair

bei dem codeschnippsel da kommt einem sowieso das speibn :P

der ptr als parameter muß eh ned schlecht sein - wenn er richtig verwendet werden tät

void blablubb( char* ptr )
{
char buf[10];
//buf irgendwie anschreiben von stdin zb
strcpy(ptr, buf);
}

da brauchst dann garkeinen returnvalue mehr ansich, der steht dann an der adresse vom parameter drin, mit ginge das natürlich auch, weil ja einfach nur die adresse vom parameter zurückgegeben werden würde.

mal jetzt so ohne bufferüberlaufkontrolle und sonstigem zeug. das funktioniert sehrwohl.

der übergebene parameter kann da sowohl am stack, als auch am heap sein.

wundert mich nicht wenn soviel buggy software im umlauf is, wenn die alle das openbook von denen gelesen haben

hehe, das wär ein gag

strtok verwendet einen statischen Puffer. Das würde also sogar funktionieren, außer in Multi-Thread-Situationen. Aber dafür gibt's ja strtok_r.

Zitat von Ringding

strtok verwendet einen statischen Puffer. Das würde also sogar funktionieren, außer in Multi-Thread-Situationen. Aber dafür gibt's ja strtok_r.

Diese zwei sind nach meinem Verständnis auch nicht korrekt:

Code:

/* union2.c */ 
#include <stdio.h> 
#include <stdlib.h>
 
union number {    
  float x;    
  int y; 
};
 
int main(void) {    
  union number mixed[2];    
  mixed[0].x = 1.123;    
  mixed[1].y = 123;    
  mixed[2].x = 2.345;    
  printf("%.2f\t%d\t%.2f\n", mixed[0].x, mixed[1].y, mixed[2].x);    
  return EXIT_SUCCESS; 
}

Code:

/* count_char.c */ 
#include <stdio.h> 
#include <stdlib.h> 

int main (void) {    
  int c,counter=0;    
  printf("Bitte Eingabe machen:");
  /* Eingabe machen bis mit Return beendet wird */    
  while((c=getchar()) != '\n') {
    /* Leerzeichen und Tabulatorzeichen nicht mitzählen */       
    if( (c != ' ') && (c != '\t') )          
      counter++;     /* counter erhöhen */    
  }    
  /* Gibt die Anzahl eingegeb. Zeichen von 0 bis counter-1 aus     
   * mit counter-1 wird das Zeichen '\0' nicht mitgezählt */    
  printf("Anzahl der Zeichen beträgt %d Zeichen\n", counter-1);    
  return EXIT_SUCCESS; 
}

Zitat von semteX

ganz sicher? Mein VS2008 is nämlich ziemlich unglücklich damit (im sinne von: Es liest nur mist ausm speicher)

edit: ich seh da nix von wegen statischem puffer. bin ich blind? http://www.koders.com/c/fid9E7961E1...82726B3FCD.aspx

Zitat von lama007

Diese zwei sind nach meinem Verständnis auch nicht korrekt:

Aber das Buch passt mir recht gut; vielleicht gehören die Fehler zum pädagogischen Konzept des Buches .

Zitat von semteX

ein float ist nix für fließkommazahlen

Zitat

c ist zwar in dem beispiel ein integer, macht aber eigentlich auch nix, jedes character zeichn wird ja sowieso als zahl repräsentiert. is halt der falsche datentyp, aber solang der gewählte zu groß und ned zu klein ist, ned viel passiert

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025