Ofte stilte spørsmål (med tilhørende svar)

[☀ ❄]

MERK: Denne tråden ble laget i 2005 og er grovt utdatert. Hvis du fortsatt har spørsmål, sjekk StackOverflow eller google it.


Innholdsfortegnelse
0. Hva gjør jeg hvis spørsmålet mitt ikke er her?
1. Bør jeg lære C eller C++ (først)? uferdig
2a. Jeg vil lære C++. Hva gjør jeg?
2b. Jeg vil lære C. Hva gjør jeg? uferdig
3. Finnes det ingen norske C/C++-bøker?
4. Jeg er klar til å skrive mitt første program. Hva gjør jeg? (Noen kompilatorer)
5. Kompilator, preprocessor, compiler, linker, IDE -- hva er alt dette?
6. Når jeg kjører programmet kommer det en svart boks på skjermen i et lite sekund, og det skjer ikke noe mer. Hva er galt?
7. Hvordan lager jeg grafikk og et grafisk brukergrensesnitt til programmet mitt?
8. std::string? char*? Hva er forskjellen? Hva bør jeg bruke?
9. Hva er forskjellen på <iostream> og <iostream.h>?



0. Hva gjør jeg hvis spørsmålet mitt ikke er her?
Aller først, les i boken din eller i dokumentasjonen. cppreference.com og SGIs STL-dokumentasjon er nyttige sider for spørsmål rundt The Standard Template Library, STL. MSDN er siden du er ute etter hvis du leter etter svar på Windows-spesifikke spørsmål, mens Unix-spørsmål best besvares av manual-sidene. Det kan hende du finner svar i cprogramming.coms FAQ eller i Bjarne Stroustrups FAQ eller Bjarne Stroustrups tekniske FAQ. Hvis du ikke finner svar på spørsmålet ditt på noen av de sidene, prøv å søke med f.eks. google eller på forumet. Hvis du fortsatt ikke finner svar kan du aller nådigst få lov til å spørre


1. Bør jeg lære C eller C++ (først)?
Denne delen kommer snart (muligens som en ny tråd).


2. Jeg vil lære C/C++. Hva gjør jeg?

• 2a. Jeg vil lære C++. Hva gjør jeg?
  Den beste måten å lære seg C++ på, er ved å lese en bok. Accelerated C++ anbefales av mange, og er veien å gå om du er seriøs om å lære deg C++. Om du ikke vil koste på deg en bok som koster penger, kan Thinking in C++ være av interesse. Begge volumene er fritt tilgjengelig for nedlasting. Vær oppmerksom på at Thinking in C++ er tyngre og ikke fullt så god som den første. Vær også oppmerksom på at C++ for Dummies er en svært dårlig bok, og bør unngås.
   
• 2b. Jeg vil lære C. Hva gjør jeg?
  Denne delen kommer snart. I mellomtiden: Noen som har bokanbefalinger?

3. Men disse er jo på engelsk! Finnes det ingen norske alternativer?
Jo, det finnes norske C++-bøker, men de er ikke like gode som de engelske. Hvis du ikke behersker engelsk bør du heller lære deg det først. Det finnes ingen vei utenom engelsk i lengden uansett, så du kan like godt venne deg til det. Det sies at «All programmering skal foregå på engelsk», og det ligger utvilsomt noe i det.


4. Jeg er klar til å skrive mitt første program. Hva gjør jeg?
Du trenger en kompilator. Til Windows er bl.a. Dev-C++ å anbefale. Hvis du bruker en Unix-variant er GNU Compiler Collection din venn. Til C trenger du gcc og til C++ trenger du g++. På mange systemer er gcc / g++ allerede installert -- skriv gcc --version for å se om det er tilfellet. cc og c++ kan også være verdt et forsøk.


5. Kompilator, preprocessor, compiler, linker, IDE -- hva er alt dette?
Disse forklaringene er ment å være korte og utekniske. For grundigere forklaringer, klikk på navnene og du vil bli tatt til den respektive artikkelen på Wikipedia

• 5a. En kompilator (compiler på engelsk) er, kort sagt, et program som oversetter fra C/C++ til maskinkode. Kompilatoren gjør med andre ord mennskelig lesbar kildekode om til instruksjoner maskinen forstår.
   
• 5b. En linker (noen som har et godt norsk ord?) er et program som setter sammen de midlertidige filene som kompilatoren lager, objektfilene, til et ferdig program. Linkeren brukes ofte til å inkludere biblioteker man ønsker å programmere mot.
   
• 5c. En preprosessor (preprocessor på engelsk) er et program som forbereder kildefilene før kompileringen. Preprosessoren fjerner blant annet kommentarer i koden, inkluderer hodefiler, utvider makroer, osv. Bruk av preprosessoren er mest utbredt i C -- i C++ finnes det bedre måter å gjøre de fleste av preprosessorens oppgaver på.
   
• 5d. Et feilsøkingsprogram (debugger på engelsk) er et program som hjelper deg med å finne feil (bugs) i programmet, blant annet ved å gi deg tilgang til å finstyre programutførselen, samt at du får tilgang til en mengde informasjon som kan hjelpe deg med å forstå hva som skjer.
   
• 5e. Et IDE, eller integrert utviklingsmiljø (fra engelsk, Integrated Development Environment), er et program som gir deg enkel tilgang til alle verktøyene du trenger når du utvikler programvare. Et IDE inkluderer som oftest en kompilator (med linker), et redigeringsprogram, et feilsøkingsprogram, lett tilgang til dokumentasjon, osv. Eksempler på IDE-er inkluderer bl.a.: Dev-C++, KDevelop og Visual C++.
   
• 5f. API. Kommer snart.

6. Når jeg kjører programmet kommer det en svart boks på skjermen i et lite sekund, og det skjer ikke noe mer. Hva er galt?
Når programmet er ferdig med å kjøre, med andre ord nesten med én gang, lukker det seg igjen (programmet returnerer). Problemet er at terminalen/konsollet programmet kjører i også lukkes igjen når programmet er ferdig. Det er flere måter å løse dette på:
- Kjør programmet direkte fra en terminal, fremfor å dobbeltklikke på ikonet. Da vil ikke terminalen lukke seg igjen etterpå.
- Sørg for at programmet venter på inndata før det lukker seg igjen. Du kan lese i denne tråden for en ekstensiv diskusjon om hva man kan gjøre og hva man bør gjøre.


7. Hvordan lager jeg grafikk og et grafisk brukergrensesnitt til programmet mitt?

• 7a. Hvordan lager jeg grafisk brukergrensesnitt (GUI)?
  Siden standardbiblioteket ikke har noen støtte for grafiske brukergrensesnitt (GUI - Graphical User Interface), altså knapper, menyer, rullegardiner, osv., må du ha et eksternt API (Application Programming Interface). Eksempler på disse er:
  - Qt
  - FLTK
  - wxWidgets
  - FOX
  - GTK+
  
  Det er egentlig ikke så farlig hvilket bibliotek man lærer seg, for når man først har skjønt prinsippene rundt GUI-programmering, så er det ikke veldig vanskelig å gå over til et annet.Hvilket bibliotek som er "best" blir umulig å si, ettersom det for det meste går på smak og behag.
   
• 7b. Hvordan lager jeg grafikk?
  Vi har også en del API-er å velge i når det gjelder grafikk, men de største og mest bruke er vel hovedsaklig:
  - OpenGL
  - DirectX
  - SDL
  
  Hvorav OpenGL og DirectX primært er for 3D-grafikk, og SDL er for 2D-grafikk (SDL har også støtte for OpenGL). Det som også er verdt å merke seg er at OpenGL og SDL er plattformuavhenige, noe DirectX ikke er. DirectX begrenser seg til Microsoft Windows.

8. std::string? char*? Hva er forskjellen? Hva bør jeg bruke?
char* er en peker til én eller flere chars, altså bokstaver. En slik peker kalles ofte en C-style string, fordi de er vanlige i C. En char* er altså stort sett bare et område i minnet som (fortrinnsvis) består av en tekststreng. Dette betyr at du ikke kan gjøre stort med en char* i seg selv. Heldigvis finnes det en rekke hjelpefunksjoner du kan benytte deg av. Disse finnes i to utgaver, f.eks. strcpy() og strncpy(). Versjonen som inneholder en n begrenser lengden på strengen, noe som minsker faren for at man skriver forbi det allokerte minnet.

std::string er en egen klasse, som er en del av standardbiblioteket. (For å være korrekt er det egentlig en typedef av basic_string<char> -- noe som betyr at du kan få string-er som tar andre typer enn char.) Dette betyr at den har stor innebygd funksjonalitet, og ting som minneallokering, kopiering, osv. blir automagisk tatt hånd om. Dette gjør at det er mye greiere å bruke std::string. Den kan også være like rask som -- og i enkelte tilfeller raskere enn -- en vanlig C-streng. En std::string kan dessuten fritt konstrueres fra en char*, så følgende kode fungerer helt greit:

void iWantAString(string s);

void f()
{
    iWantAString("Hello, World!\n");
}

For å konvertere andre veien bruker man metoden c_str():

void iWantACStyleString(char* s);

void f()
{
    std::string myString = "Hello, World!\n";
    iWantACStyleString(myString.c_str());
}

For en mer fullstendig dokumentasjon av std::string, se SGIs dokumentasjon.


Ettersom den er mye enklere å bruke, og dessuten har mange andre fordeler, bør du i utgangspunktet bruke std::string. Det kan være spesialtilfeller hvor en C-style string er bedre, men er du i tvil er du ikke i tvil: Bruk std::string.


9. Hva er forskjellen på <iostream> og <iostream.h>?
Forskjellen på <iostream> og <iostream.h> er rett og slett at hvis du inkluderer <iostream.h> får du iostream-biblioteket i det globale namespace-et. Dersom du imidlertid bruker <iostream> ligger det i namespace std. Dette er å foretrekke, ettersom det da ikke så lett oppstår navnkonflikter (som faktisk var hovedgrunnen til at namespaces ble laget!). Men det er også verdt å merke seg at det egentlig ikke er noe snakk om å foretrekke, for <iostream.h> er erstattet av <iostream>, og eksisterer teknisk sett ikke, selv om de fleste kompilatorene allikevel støtter det.


Bidrag:
- zirener har skrevet og/eller gjort betydelige bidrag til: seksjon 7 og seksjon 9. Endret 16. mai 2015 av Lstor

[☀ ❄]

Det var vel på tide at vi fikk en slik tråd. (Konstruktiv) kritikk og forbedringsforslag mottas med takk, og ferdigskrevne seksjoner mottas med stor takk. Eventuelle tillegg kan postes i denne tråden eller sendes på privat melding, så skal jeg redigere posten. (Vær oppmerksom på at jeg forbeholder meg retten til fritt å redigere bidrag. Det betyr ikke at jeg sensurerer meninger som strider imot mine egne.)

 

Spørsmål (uten svar) rundt C/C++, enten spørsmålet berører noe av innholdet i OSS-en eller ikke, hører ikke hjemme i denne tråden -- lag en ny!

[Kjeksen]

sticky kanskje?

[Dead_Rabbit]

Tenkte jeg kunne prøve å bidra med noe jeg også, så jeg skrev det aller mest grunnleggende rundt avsnitt 7. Kan godt være det har sneket seg inn noen feil der, gikk litt fort i svingene men. Tenkte at det vel var bedre at det står noe der enn at det står tomt)

 

7. Hvordan lager jeg grafikk og et grafisk brukergrensesnitt til programmet mitt?

 

a) Hvordan lage grafisk brukergrensesnitt (GUI)?

 

(for en mer grundig beskrivelse om dette emnet refererer jeg til Wikipedia)

 

Siden standarbibloteket ikke har noen støtte for grafisk brukergrensesnitt (GUI - Graphical User Interface), altså knapper, menyer, rullegardiner, etc., må du ha et eksternt API (Application Programming Interface). Eksempler på disse er:

• Qt
  
• FLTK
  
• WxWidgets
  
• FOX
  

Det er egentlig ikke så farlig hvilket biblotek man lærer seg, for når man først har skjønt prinsippene rundt

GUI programmering, så er det ikke veldig vanskelig å gå over til et annet.Hvilket biblotek som er "best" blir umulig å si, ettersom det for det meste går på smak og behag.

 

b) Hvordan lage grafikk?

 

Vi har også en del API å velge i når det gjelder grafikk, men de største og mest bruke er vel hovedsaklig:

• OpenGL
  
• DirectX
  
• SDL
  

Hvorav OpenGL og DirectX primært er for 3D grafikk, og SDL er for 2D grafikk (SDL har også tøtte for OpenGL). Det som også er verdt å merke seg er at OpenGL og SDL er plattform uavhenig, noe DirectX ikke er. DirectX begrenser seg til Microsoft Windows.

[Ueland]

sticky kanskje?

Granted.

[charlie di meola]

jeg foreslår iallefall at en ikke-fanatiker skriver svaret til spm #1. ingen vits i å kamuflere meninger som fakta.

[☀ ❄]

jeg foreslår iallefall at en ikke-fanatiker skriver svaret til spm #1. ingen vits i å kamuflere meninger som fakta.

Hvorfor tror du jeg har tenkt til å organisere det spørsmålet som en egen tråd?

 

Hvis det er meg du sikter til med fanatiker, synes jeg du er urettferdig. I tillegg til at det er argumentum ad homine har det lite for seg: Mine grunner til å anbefale C++ fremfor C er objektive og veloverveide, og dessuten basert på erfaring med en god del C-utvikleres nokså dårlige forsøk på å skrive C++.

[Ueland]

Det ser forøvrig ut som at boken Thinking in C++ kan lastes ned gratis fra den overnevnte siden

[☀ ❄]

Det ser forøvrig ut som at boken Thinking in C++ kan lastes ned gratis fra den overnevnte siden

Jepp. La til en liten setning for å gjøre det litt tydeligere.

[Dead_Rabbit]

Hei og hu! Skrev en liten "greie" om spørsmål 9 også, mens jeg var så godt i gang!

 

9. Hva er forskjellen på <iostream> og <iostream.h>?

 

Forskjellen på <iostream> og <iostream.h> er rett og slett at hvis du inkluderer <iostream.h> får du iostream bibloteket globalt. Dersom du imidlertid bruker <iostream> ligger det i namespace std. Dette er å foretrekke, ettersom det da ikke så lett oppstår navnkonflikter (som faktisk var hovedgrunnen til at namespaces ble lagd!). Men, det er også verdt å merke seg at det egentlig ikke er noe snakk om å foretrekke, for <iostream.h> er erstattet av <iostream>, og eksisterer teknisk sett ikke, selv om de fleste kompilatorene allikevel støtter det!

Endret 28. juli 2005 av zirener

[Kjeksen]

Hvor blir det av resten?

[djorgen]

Enig... Hvor er resten? Blir dette et 2 årig prosjekt?

[Dead_Rabbit]

Myubi er vel i militæret nå, om jeg ikke husker helt feil.

[tomegundersen]

Annbefalning av bok for C (både lærebok og referanse):

"The C Programming Language" av Kernighan og Ritchie.

 

Bedre kjent som K&R, det er den orginale boken om C skrevet av de som utviklet språket. Må være den beste boken jeg har lest om C eller noe annet programmeringsspråk for den saks skyld. Finnes i et uttall oversettelser bl.a. norks og braille (for dem som måtte ønske det).

 

Tom

[dayslepr]

En sterk anbefalling eller oppfordring til alle de som holder på med programmering;

 

DET ER HELT BAK MÅL å bruke et IDE eller en editor uten å vite åssen man bruker kompileren/linkeren fra shellet! (fra cmd/command-vinduet, eller "DOS" som noen feilaktig kaller det.. linux-folk kaller det shellet eller terminalen)

 

man mister muligheten til å kommunisere med andre programmere, samtaler blir mer «jeg klikker på det røde ikonet i Bortland 5000, men det kommer ikke noen .exe-fil ut!» .. man mangler i dette eksempelet 99% av informasjonen andre trenger for å vite hvordan ting rundt selve kompilerings- og linker-prosessen er lagt opp hos deg

 

kan sammenligne det med en samtale på MSN eller IRC der jeg forsøker å forklare deg hvor stor fisk jeg har fått, og dermed begynner å vifte med armene for å illustrere .. det er totalt bak mål -- bruker man i stedet språk og tekst, så kan man si «45cm» og alle vet alle detaljer 100%

 

selvfølgelig bruker jeg et IDE eller en editor selv; men ikke uten å være klar over og hele tiden se hva den sender av parametere og argumenter til kompiler- og linker-programmet

 

lær hvordan man bruker kompileren og linkeren fra shellet før du begynner å klikke på knapper i et eller annet IDE!

 

her er en god bok om hvordan man bruker det jeg antar må være den absolutt mest brukte og mest utbredte kompileren som noen gang er laget, nemlig GCC (som under Windows også går under navnet MinGW):

http://www.network-theory.co.uk/docs/gccintro/

 

jeg har en mistanke om at disse tingene er viktigere å være klar over i C/C++ enn i andre språk, men det kan hende jeg tar feil her .. jeg har også en mistanke om at nybegynnere tror de sparer tid ved å hoppe over dette, og i stedet konsentrerer seg om selve språket fremfor kompileren/linkeren - men da synes jeg det er urimelig at de forventer at andre skal skjønne hva de faktisk driver med når de først setter i gang med kodingen i praksis

[Dead_Rabbit]

Jeg slang på en liten sak om headerfiler også, i tilfellet noen lurer på noe rundt det.

 

Hva er, og hvorfor har vi headerfiler?

I headerfiler legger man deklarasjoner. Dette gjør (faktisk!) at man slipper å ha deklarasjoner og definisjoner i samme fil, noe som vil bidra til å gjøre koden mer ryddig og oversiktlig, og mer håndterlig.

 

Eksempel på en headerfil:

#ifndef _person_hpp_
#define _person_hpp_

#include <string>

class Person {
       public:
               Person(std::string, int);

               void set_name(std::string);
               const std::string get_name() const;

               void set_age(int);
               const int get_age() const;

       private:
               std::string name;
               int age;
};

#endif

 

Her er den respektive kildefilen:

#include "person.hpp"

Person::Person(std::string nn, int aa) : name(nn), age(aa)
{
}

void Person::set_name(std::string nn)
{
       name = nn;
}

const std::string Person::get_name() const
{
       return name;
}

void Person::set_age(int aa)
{
       age = aa;
}

const int Person::get_age() const
{
       return age;
}

 

main.cpp

#include <iostream>
#include "person.hpp"

using namespace std;

int main(int argc, char* argv[])
{
       cout << "Skriv inn navn: ";
       std::string name;
       getline(cin, name);

       cout << "Skriv inn alder: ";
       int age;
       cin >> age;

       Person person(name, age);

       cout << "Du heter " << person.get_name() << " og er " << person.get_age()
                << " år gammel." << endl;

       return 0;
}

 

Resultat: Et mer oversiktlig og ryddig program. Det blir også lettere å lete frem APIet, når man bare kan se i headerfilen, fremfor å lete rundt i en hårete implementasjonsfil.

 

Edit: Hvor skal jeg begynne..? *sukk*

Endret 27. november 2006 av zirener

[GenericName]

En ting med det using direktivet.

 

using std::cout;

 

etc.. Er det dårlig "skikk"?

[Peter]

Niks, det er bedre skikk en å bruke "using namespace std" egentlig, da du med using std::cout spesifiserer hvilken funksjon av cout som skal brukes, mens det f.eks. kan finnes en annen cin enn std::cin

[Mapster]

Jeg er litt interressert i at #8 blir svart på. Fra boken jeg har lært meg c++ er jeg vant med std::string.

 

edit:

så vidt jeg forstår er det mer funksjonalitet med nullterminerte tekststrenger, mens std::string er enklere og dermed mindre funksjonalitet.

Endret 27. april 2006 av MapSter

[Dead_Rabbit]

8. std::string? char*? Hva er forskjellen? Hva bør jeg bruke?

For de som ikke har vært borti C++, eller for de som bare har vært borti litt eldre C++, kan std::string være ukjent. std::string er en string-klasse i namespace std i STL (Standard Template Library).

 

std::string tar seg av ting som automatisk håndtering av minne, automatisk reallokering når det er "fullt", osv. Man unngår også i stor grad ting som buffer overflow. std::string har også en del kjekke metoder som gjør ting lettere, som f.eks. size(), empty(), o.l. (Se http://www.cppreference.com for full oversikt.)

 

Litt "vag" forklaring kanskje, men siden det hastet tenkte jeg at det var bedre enn ingenting.