<BøNilzen> Skrevet 28. desember 2004 Del Skrevet 28. desember 2004 Eneste jeg ser er at du har inkludert <time.h> istedet for <ctime>, men du skulle ikke få feilmelding for det. Lenke til kommentar
medi8or Skrevet 28. desember 2004 Del Skrevet 28. desember 2004 Hva skjer hvis du dropper #include "stdafx.h" ? Lenke til kommentar
søppel Skrevet 28. desember 2004 Del Skrevet 28. desember 2004 (endret) #include <ctime> #include <iostream> using namespace std; int main(int argc, char** argv) { srand(time(0)); int a = rand() % 20; int b = rand() % 7; cout << a << "+" << b << endl; int c; cin >> c; int d; int e; d = a + b; //cerr; // hva er poenget med dette egentlig? e = d; if (c == e) { cout << "riktig" << endl; } else { cout << "feil" << endl; } return 0; } Dette skal fungere i alle kompilere. Edit: Kortet ned på koden litt: #include <ctime> #include <iostream> using namespace std; int main(int argc, char** argv) { srand(time(0)); int a = rand() % 20; int b = rand() % 7; cout << "Hva blir " << a << " + " << b << "?" << endl; int svar; cin >> svar; int riktig_svar = a + b; if(svar == riktig_svar) cout << "Riktig." << endl; else cout << "Feil, svaret var " << riktig_svar << "." << endl; return(0); } // main Edit2: nah.. jaaa Prøv å få med deg noe av kodestilen også. :} Endret 28. desember 2004 av søppel Lenke til kommentar
<BøNilzen> Skrevet 28. desember 2004 Del Skrevet 28. desember 2004 Søppel : Hvorfor bruker du "char **argv" og ikke "char *argv[]" ? Lenke til kommentar
saboi Skrevet 28. desember 2004 Del Skrevet 28. desember 2004 bønilzen, kan du forklare hva den store forskjellen er? bortsett fra den åpenbarforskjellen at det er 2 * i den ene mens den andre bare har en * men et par [] Lenke til kommentar
A_N_K Skrevet 28. desember 2004 Del Skrevet 28. desember 2004 Et array er en peker til et område på stakken, allokert av kompilator. Derfor går det an å skrive char **argv og char *argv[] om hverandre :] Lenke til kommentar
GenericName Skrevet 29. desember 2004 Del Skrevet 29. desember 2004 (endret) ... Endret 11. januar 2011 av Token Lenke til kommentar
Dead_Rabbit Skrevet 29. desember 2004 Del Skrevet 29. desember 2004 Vi får en super ledetråd da ihvertfall! Bruker du Dev-C++ eller? Lenke til kommentar
søppel Skrevet 29. desember 2004 Del Skrevet 29. desember 2004 (endret) <BøNilzen>: Grunnen er det de andre nevner, og fordi det er kjappere å skrive. :} prog_master: Mangler et semikolon, ellers ser det greit ut. sum = tall1 * 2; // <--- der Pass på at du velger "build all", eller "rebuild all" ellernoesånnt. Om du bare velger "compile", så linkes ikke programmet og du sitter igjen kun med en *.o -fil og ingen *.exe -fil. Om du kompilerer fra konsollet (noe du bør lære deg - for siden å sette deg inn i scons for å spare masse tid) så foregår dette slik: g++ program.cpp -o program.exe ..eller slik: g++ program.cpp -o program ..man trenger altså ikke legge til .exe på slutten, den gjør dette av seg selv under Windows. Dette har visse fordeler hvis du bytter mellom *nix og Windows, fordi under *nix har ikke eksekverbare filer et bestemt etternavn som de må ha i Windows. http://www.network-theory.co.uk/docs/gccintro/ Endret 30. desember 2004 av søppel Lenke til kommentar
GenericName Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 (endret) ... Endret 11. januar 2011 av Token Lenke til kommentar
søppel Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 (endret) Jeg liker best dev. Det var den jeg snakket om. Dev-C++ bruker MinGW som er navnet de har gitt GCC-kompileren (+ noen ekstra headere m.m.) under Windows. Så man bruker GCC/MinGW på samme måte (stort sett) på alle platformer. Ganske greit i grunn. Endret 30. desember 2004 av søppel Lenke til kommentar
<BøNilzen> Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 bønilzen, kan du forklare hva den store forskjellen er? Nei, det er det jeg ikke kan (eller kunne da), det var derfor jeg spurte. Lenke til kommentar
Dead_Rabbit Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 GCC er ikke den for C? Og GXX for C++? prog master: Du burde sette deg inn i en text editor som f.eks vim/emacs. Da kan du editere filene mye raskere. Så bruker du scons som et build system(heter det ikke det?), og setter f.eks F5 til build, F8 til run, F10 til build & run. F11 kan du sette til debug. Har gjort dette selv i vim (bare at jeg ikke helt har satt meg inn i gdb, så jeg har ikke noen debug tast). Lenke til kommentar
søppel Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 (endret) GCC er navnet på "hele greia", eller "hele prosjektet". Man kaller/starter programmene via gcc eller g++ -front-endene, og gcc er for C, mens g++ er for C++ ja. Jeg (eller daysleper) har en post litt lengre tilbake i tid angående bruk av GDB. Postet et veldig enkelt eksempel som viser v.h.a. en backtrace hvordan man finner kilden til en segmenterings-feil (SIGSEGV). (hvordan kommer slike feil (SIGSEGV) opp i Windows btw.? -- en popup-boks ellernoe?) Endret 30. desember 2004 av søppel Lenke til kommentar
Dead_Rabbit Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 (endret) En pop-up ja. #include <vector> using namespace std; int main() { vector<int> v; for(int i = 0; i<10000; i++) v = 123; return 0; } //main() Hvorfor blir det SIGSEGV-feil her? Er kansje en litt dum ting å gjøre men... Edit: CODE-feil Endret 30. desember 2004 av zirener Lenke til kommentar
søppel Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 (endret) Hvorfor blir det SIGSEGV-feil her? Den rette måten å legge til nye elementer i en vector er v.h.a. push_back. Kan i grunn regne med at std::vector er implementert sånn ca. som et array i bakhånd, eller en array-pool eller noe lignende. Arrayer og pekere er nært beslektet - og referer man til noe utenfor det allokerte området til arrayet risikerer man å skrive over minnet til andre programmer (andre segmenter). OSet (som kjører i protected mode - noe DOS ikke gjorde) sørger for at programmet stoppes, i stedet for at det går "berserk" og skriver over andre programmers kode og data (segmenter). Det som kanskje er litt kjipt - er at du kan fint skrive over minnet som hører til gjeldende prosess. Altså du kan ved et uhell skrive over data/kode i ditt eget program på (mer eller mindre) tilfeldige steder. (Derfor satte jeg en så stor verdi i for-loopen, så det skulle være "garantert" at jeg kom utenfor min egen prossess's område). Dette er bugs fra helvette. Noe slikt: #include <vector> using namespace std; int main() { vector<int> v; for(int i = 0; i < 10000; i++) //v[i] = 123; // dette bør gi en SIGSEGV feil. v.push_back(123); return(0); } // main() operator[] sjekker med andre ord ikke grenser (bounds). at() gjør det: http://cppreference.com/cppvector_details.html#at Endret 30. desember 2004 av søppel Lenke til kommentar
Dead_Rabbit Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 Mm.. Tror jeg skjønner nå. Men skulle tro koden ville kjøre "feilfritt" selv om det da. "One past the last element" er jo noe av det samme det, er det ikke? Bare at det er litt fler "past the last element" her. Lenke til kommentar
søppel Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 (endret) litt fler ..er akkurat derfor for-loopen er satt til å gå så langt som den gjør. (redigerte posten min ovenfor btw.) Edit: SIGSEGV er forresten et signal. Så under Linux kan du om du vil sette opp en håndterer (funksjon angitt av deg) for dette signalet og detektere at dette har skjedd i programmet ditt og rette på det - i stedet for at du blir kastet tilbake til OSet med en feilmelding. Dette går sikkert under Windows også, men jeg kjenner ikke detaljene. Endret 30. desember 2004 av søppel Lenke til kommentar
Dead_Rabbit Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 Heh. Går litt i surr her nå. Hvorfor skulle ikke det der være lov når "one past the last element" er lov? Jeg skjønner at det er farlig, men som jeg ser det , så blir det litt dobbeltmoral fra kompilatorens side. Lenke til kommentar
søppel Skrevet 30. desember 2004 Del Skrevet 30. desember 2004 (endret) Hastighet. Edit: Det er ikke kompilatorens skyld -- den kan ikke alltid vite hvor store arrayer er (de er jo pekere). Edit2: Det finnes patcher for GCC der det er implementert run-time bounds-checking, har aldri testet disse. Endret 30. desember 2004 av søppel Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå