Gå til innhold

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


Anbefalte innlegg

Videoannonse
Annonse
Skrevet (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 av søppel
Skrevet

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 []

Skrevet

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 :]

Skrevet (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 av søppel
Skrevet (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 av søppel
Skrevet

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).

Skrevet (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 av søppel
Skrevet (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

post-41-1104427178_thumb.jpg

Endret av zirener
Skrevet (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 av søppel
Skrevet

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.

Skrevet (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 av søppel
Skrevet

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.

Skrevet (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 av søppel

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å
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...