Hur kommer man igång med g++?

[christer]

Hur kommer man igång med g++ ?

Skrev en kort programsnutt i en fil som heter hello.c.
Med gedit blev det så här:
#include <iostream.h>

main()
{
cout <<"hello C++ " ;
}

Hur skall man kunna kompilera och köra programmet ?
Har försökt med g++ hello.c och får:
kalle@kalle:~$ g++ hello.c
hello.c:2:22: error: iostream.h: Filen eller katalogen finns inte
hello.c: In function "int main()":
hello.c:6: fel: "cout" deklarerades inte i detta definitionsområde

Något iostream.h hittas heller inte i Ubuntu med locate.
Förväntade mig en fil a.out, som kan köras, men detta funkar inte längre.

Som sagt hur kommer man igång ? Gedit verkar i varje fall förstå C++ och färgar
texten vackert. Man gcc eller man g++ verkar hebreiska.

[Urban Anjar]

Du verkar sakna headerfilen

[Lars]

I C++ finns det aldrig något .h i filnamnet, d.v.s. det ska vara #include <iostream>

[christer]

I Ubuntu finns massor med .h filer, h står för header.
locate *.h ger också en hel del men inte iostream.h däremot finns iostream.
Jesper Ek, som skrivit Lätt Pocket om C++ programmering har också iostream.h

Utan h i iostream fås följande:
kalle@kalle:~$ g++ hello.c
hello.c: In function "int main()":
hello.c:6: fel: "cout" deklarerades inte i detta definitionsområde

cout verkar obekant, men finns också i Jespers bok. Det konstiga är att det fungerade
i mitt lastgamla SuSE. Men med Ubuntu tappade jag bort C++.

[Konservburk]

Det ska vara std::cout istället för cout.

[mcNisse]

Du måste deklarera cout vilken är en medlem av namespacet std.

Antingen så skriver du:
using std::cout;

Eller så använder du
std::cout istället för cout.

[christer]

Nu blev det en körbar fil, som heter a.out
Men inget hände

kalle@kalle:~$ a.out
bash: a.out: kommandot finns inte

Inget hände från den grafiska delen heller.
kalle@kalle:~$ ls -al a.out
-rwxr-xr-x 1 kalle kalle 9541 2009-03-26 21:18 a.out
Körbar verkar den vara. Hur kör man då ?

Är 10 år gamla kunskaper i C++ föråldrade ?

[mcNisse]

./a.out

[christer]

Nu äntligen lyckades jag att med Ubuntu få ett första c++ program att fungera.

kalle@kalle:~$ ./a.out
hello C++ kalle@kalle:~$

Varför just ./ och vad betyder ./ ?

Var hittar jag modernare uppgifter över C++ ?

Tack för den fina hjälpen.

[mcNisse]

Det är en sökväg som gör att programmet hittas. Det är för att du inte har aktuell katalog i PATH variabeln.

[Urban Anjar]

./ är den aktuella katalogen, alltså den "mapp" du "är i".

[Konservburk]

Varför just ./

Etersom det är lättast att skriva. Men det går att göra på flera andra sätt också, t.ex:

Kod: Markera allt

$(pwd)/a.out

eller

Kod: Markera allt

PATH= a.out

OBS: Det måste finnas ett mellanrum efter = om det ska fungera.

[Johnny Rosenberg]

Varför just ./

Etersom det är lättast att skriva. Men det går att göra på flera andra sätt också, t.ex:

Kod: Markera allt

$(pwd)/a.out

eller

Kod: Markera allt

PATH= a.out

OBS: Det måste finnas ett mellanrum efter = om det ska fungera.

Just det där med ./ har jag stört mig ganska mycket på. Kring 1990 när man skrev en massa meningslös dynga i C under Unix behövdes inget sådant. Skrev man ingen sökväg så letades filen upp i både PATH och den mapp där man för tillfället befann sig. Eller är det möjligt att jag kommer ihåg så fel?

Förstår inte varför fanskapet inte kan bemöda sig att åtminstone leta i den mapp där man befinner sig utan att man ber om det. Vad skulle det kunna vara för negativt med det? Är det en säkerhetstanke som ligger bakom denna till synes löjliga begränsning?

[mcNisse]

Du kan ju enkelt lägga in . i PATH. Det är är ett säkerhetshål. Det är ju därför det inte är aktiverat direkt.

Kod: Markera allt

PATH=$PATH:.

[Lars]

Är det en säkerhetstanke som ligger bakom denna till synes löjliga begränsning?

Utanför ämnet: Ja, det stämmer. Tänk dig att du kör "cd /tmp" och sedan "ls". I /tmp har alla användare skrivrättigheter så där kan man lägga in ett skript som heter ls och som gör elaka saker. OK, om "." ligger sist i PATH är det ingen fara, men man kan skapa ett elakt skript som heter l istället och vänta på att någon slinter på tangentbordet.

[Johnny Rosenberg]

Är det en säkerhetstanke som ligger bakom denna till synes löjliga begränsning?

Utanför ämnet: Ja, det stämmer. Tänk dig att du kör "cd /tmp" och sedan "ls". I /tmp har alla användare skrivrättigheter så där kan man lägga in ett skript som heter ls och som gör elaka saker. OK, om "." ligger sist i PATH är det ingen fara, men man kan skapa ett elakt skript som heter l istället och vänta på att någon slinter på tangentbordet.

Men om jag, som är den enda som använder min dator, lägger till ”.” sist i PATH, så kommer det att fungera i alla fall?

[mcNisse]

Det beror på vad du menar med fungera. Det finns ju ingen som kan lägga elaka skript i datorn förutom du.
Det är inget stor säkerhetsrisk.

Knepet med . sist hjälper inte mot felstavningar. Ta tex more. Det är enkelt att skrive mroe istållet.

[Johnny Rosenberg]

Det beror på vad du menar med fungera. Det finns ju ingen som kan lägga elaka skript i datorn förutom du.
Det är inget stor säkerhetsrisk.

Knepet med . sist hjälper inte mot felstavningar. Ta tex more. Det är enkelt att skrive mroe istållet.

Vad menar du hjälper mot felstavningar?

[mcNisse]

Stavas kommandot rätt kommer du att köra ett det program tidigare i PATH:en. Men om du skulle stava fel och någon har laggt en fil med en vanlig felstavning i aktuell katalog kommer du att köra det felstavade kommandot. Du skriver mroe istället för more och någon har laggt in ett skript mroe så kommer du att köra mroe.

[Johnny Rosenberg]

Stavas kommandot rätt kommer du att köra ett det program tidigare i PATH:en. Men om du skulle stava fel och någon har laggt en fil med en vanlig felstavning i aktuell katalog kommer du att köra det felstavade kommandot. Du skriver mroe istället för more och någon har laggt in ett skript mroe så kommer du att köra mroe.

Okej, en teoretisk risk finns ju där, kanske. Själv brukar jag alltid titta i mappen innan jag kör något, eller på ett eller annat sätt ha koll på vad som finns där. En sak som har betydelse är, och nu pratar jag ju om mina egna filer och mappar i $HOME, att jag alltid ser till att ha relativt få filer i varje mapp. Det gör det lätt att se om något hamnat där som inte ska vara där. Kör alltid en ”ll” (alias för ls -laB) när jag just kommit till en mapp, alternativt kör ”cdl” (egendefinierad funktion för ”cd” följt av ”ll”) istället för ”cd”. Då ser jag alltid innehållet i mappen direkt så fort jag kommer dit. Jag är inte så mycket för att knappa blint utan kontroll. Men den dagen det händer att jag klantar mig, kanske det bli annat ljud i skällan…

Men än så länge har jag inte inkluderat ”.” i min PATH, har bara funderat på att göra det.