C (alle ISO-Standards)

• S

  bibliothek prob
  • Schlaftänzer  

  9
  0
  Stimmen
  9
  Beiträge
  757
  Aufrufe

  S

  okay beim nächsten mal, war nicht ganz bei der sache
• ?

  strchr funzt nit...
  • Gast  

  12
  0
  Stimmen
  12
  Beiträge
  1077
  Aufrufe

  P

  net schrieb: warum nicht, wenn s schon ein char* ist: return s+i; Weil "s" im Anfangspost als "const char*" definiert ist.
• V

  Letztes Element einer LinkedList
  • Vertexwahn  

  15
  0
  Stimmen
  15
  Beiträge
  1101
  Aufrufe

  B

  Ich finde, du solltest erstmal ausschlafen, oder alternativ das Kapitel Zeiger (inkl. * und -> Operatoren) nochmal überfliegen. Das kann eigentlich nicht sein, dass man solche Fehler nicht selber findet.
• ?

  Pointer auf Funktion mit Pointer als Returnvalue
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  410
  Aufrufe

  B

  char *(*foo)(blahblah)
• ?

  Datei bitweise lesen
  • Gast  

  9
  0
  Stimmen
  9
  Beiträge
  911
  Aufrufe

  P

  Herr-Vorragend schrieb: oder einfach sowas: bool Read1Bit(FILE *fInput) { static char buffer = 0; static char current = 8; if (current >= 8) { buffer = getc(fInput); current = 0; } return (buffer & (1 << (7-current++))); } Das ist fuer den Anfang zwar ok, aber es gibt zwei potentielle Probleme: 1. Es wird angenommen, dass "char" immer 8 Bit gross ist. Um das Problem zu loesen, muesste die Routine so aussehen: #include <limits.h> bool Read1Bit(FILE *fInput) { static char buffer = 0; static char current = CHAR_BIT; if (current >= CHAR_BIT) { buffer = getc(fInput); current = 0; } return (buffer & (1 << (CHAR_BIT-1-current++))); } 2. Durch die Verwendung von "static"-Variablen ist die Routine nicht multithreadfaehig. Das mag zwar jetzt kein Problem darstellen, aber man stelle sich tausende solcher Funktionen vor, die in einer Multithread-Anwendung verwendet werden sollen. Dann hat man auf einmal alle Haende voll zu tun. EDIT: 3. Hier noch ein drittes Problem: EOF wird voellig ignoriert!
• ?

  Probleme beim Lesen aus ini-Datei
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  445
  Aufrufe

  V

  ich würde einfach fscanf() - verwenden Urs24 schrieb: kann ich mit einer Funktion in gewisse Zeilen springen oder muss ich immer von Beginn an alle durchlaufen ( mit while oder so )? bin mir nicht sicher, aber ich glaube es gibt so etwas wie fseek oder so - die Funktion erwartet einen Offset und ließt dann, ab einer bestimmten Stelle die Daten ein - weiß ich nicht ob man nicht einfach den Filepointer (den man durch fopen) bekommt nicht einfach "manipulieren" kann und damit etwas in der Datei überspringen kann - glaub eher nicht
• D

  Probleme mit printf in C...
  • DragonShaolin  

  3
  0
  Stimmen
  3
  Beiträge
  418
  Aufrufe

  D

  Oh doch lieder übersehen. Danke dir... mensch... line 1: inlcude is not a valid preprocessor directive.
• P

  Fragen zu Argumentlisten
  • pointercrash**  

  10
  0
  Stimmen
  10
  Beiträge
  733
  Aufrufe

  P

  supertux schrieb: das hab ich mehrmals gesagt, weil va_end die Variablen und Speicher aufräumt, damit va_start das nächste Mal auch richtig startet. Wenn du genauer wissen willst, schau dir den Code von stdarg.h oder mach's hardcore mäßig und untersuch den Code von gibc. ... ich würde es nicht tun, weil dir va_* Makros sind und da weißt du nicht, wie sie die Argumente behandeln, es könnte auch sos ein, dass der Code nachher nicht mehr kompilierbar ist. Hab' ich mir jetzt angesehen - va_end setzt das PP-Argument AP auf 0, va_start setzt es aber sowieso neu. Störend wird Einstreuen von va_end also nur, wenn man einzeln auf die Argumente zugreifen will. Damit wird auch klar, daß das alles beim Compilieren passiert, man sich die Initialisierung einer Argumentliste beim Handling eines gespeicherten Argumentpointers sparen soll und nur die Gültigkeit der übergebenen Variablen zu beachten ist. Gut, jetzt haben wir's ja Danke zwar, aber die Müll- Sprüche wären nicht nötig gewesen ...
• S

  Logischen Ausdruck normalisieren
  • SonjaB  

  17
  0
  Stimmen
  17
  Beiträge
  1997
  Aufrufe

  ?

  glaubst du das sie dir jetzt einen blaest?
• M

  Fortschrittsbalken/anzeige
  • maximo  

  6
  0
  Stimmen
  6
  Beiträge
  665
  Aufrufe

  H

  Am coolsten finde ich: #include <stdio.h> int main() { int i = 0; char str[256] = ""; for(i = 0; i < 50; ++i) { str[i]=219; printf("\r%s", str); printf("%c",177); fflush(stdout); _sleep(100); } getch(); return(0); } mfg hohesC
• ?

  Adresse ist int ?
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  483
  Aufrufe

  ?

  ...jedenfalls, sofern sizeof(int) >= sizeof(ETWAS*). Das muss aber nicht der Fall sein - portabel ist der Code auf die Art nicht.
• V

  NULL gleich dem boolschen Wert false bzw. 0?
  • Vertexwahn  

  32
  0
  Stimmen
  32
  Beiträge
  2896
  Aufrufe

  S

  Vertexwahn schrieb: mir war unklar, dass der int Wert 0 als "null pointer constant" betrachtet wird genau das haben wir auch gesagt.
• P

  Typumwandlung: int -&gt; char[4]
  • pmw  

  39
  0
  Stimmen
  39
  Beiträge
  3243
  Aufrufe

  ?

  Voila: unsigned char *int_to_ascii(int punkte) { static unsigned char temp[4]={'\0','\0','\0', '\0'}; int faktor=1,n=0; for(n=3;n>0;n--) { if(((punkte%(faktor*10)-punkte%faktor)/faktor)!=0) temp[n-1]=(punkte%(faktor*10)-punkte%faktor)/faktor+'0'; else temp[n-1]='0'; faktor=faktor*10; } //temp[3]='\0'; return temp; } mfg, Harri
• ?

  Grösse von passwd ?
  • Gast  

  6
  0
  Stimmen
  6
  Beiträge
  531
  Aufrufe

  D

  wo es eine /etc/passwd datei gibt, gibt es bestimmt auch die funktion stat() und wäre vorzuziehen.
• O

  Fehler beim Einbinden der Library &quot;Iphlpapi.lib&quot;
  • opfer.der.genauigkeit  

  2
  0
  Stimmen
  2
  Beiträge
  685
  Aufrufe

  S

  Falsches Forum, frag im MFC/WinAPI Forum nach, hier geht es nur um ANSI C.
• -

  komma zahln problem
  • -*beelze*-  

  6
  0
  Stimmen
  6
  Beiträge
  572
  Aufrufe

  V

  Die Datentypen die am häufigsten vorkommen sind: unsigned char signed char signed short int unsigend short int unsigned int signed int unsigned long int signed long int float double was passiert, wenn: unsigned char = signed char unsigned char = signed short int unsigned char = unsigend short int unsigned char = unsigned int unsigned char = signed int unsigned char = unsigned long int unsigned char = signed long int unsigned char = float unsigned char = double was passiet hier?
• V

  Zweidimmensionales Array?
  • Vertexwahn  

  5
  0
  Stimmen
  5
  Beiträge
  616
  Aufrufe

  ?

  Warum machst du es dann nich?
• V

  interne Bit Repräsentation eines int ausgeben
  • Vertexwahn  

  9
  0
  Stimmen
  9
  Beiträge
  3403
  Aufrufe

  P

  TheTester schrieb: Der C Standard sagt zur Bitdarstellung nicht mehr als das es ein LSB und ein MSB gibt. Der Rest ist den Compilerbauern überlassen unter der Bedingung das ein Linkshift eine "Multiplikation" mit 2^Anzahl der zu shiftenden Bits^ und ein Rechtsshift eine "Division" mit 2^Anzahl der zu shiftenden Bits^ zu sein hat. Das reicht, um die Bitordnung festzulegen -- waere das LSB links, waere ein Linksshift eine Division und ein Rechtsshift eine Multiplikation. Da es aber andersum ist, muss das LSB rechts sein, klar?
• C

  Was liefert mir open() zurück?
  • CeNoRiDeR  

  10
  0
  Stimmen
  10
  Beiträge
  746
  Aufrufe

  S

  na dann man: open(2)
• ?

  lstrcat zu langsam?
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  884
  Aufrufe

  S

  kRUSty schrieb: Es scheint so zu sein, daß je länger der String, an den man anhängen will, umso länger benötigt die lstrcat-Funktion. strcat wäre naiv so zu implementieren: void strcat(char* str, char* app) { while(*str) ++str; while(*app) { *str=*app; ++str; ++app; } } oder ganz kurz: void strcat(char* str, char* app) { str+=strlen(str); strcpy(str, app); } Logisch dass es langsamer als laenge merken und strcpy ist wenn du die laenge von app auch kennst, wäre memcpy sogar noch einen tick besser...