Gå til innhold

har du en kode som ikke virker? post den her!


Anbefalte innlegg

Videoannonse
Annonse

#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 av søppel
Lenke til kommentar

<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 av søppel
Lenke til kommentar
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 av søppel
Lenke til kommentar

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?:p), 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

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 av søppel
Lenke til kommentar

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

post-41-1104427178_thumb.jpg

Endret av zirener
Lenke til kommentar
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 av søppel
Lenke til kommentar
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 av søppel
Lenke til kommentar

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 av søppel
Lenke til kommentar

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...