Debugging via gdb

[kernel]

Debugging på kommandolinjen, er det mulig dah?!

 

Jepp, og i mange tilfeller er det veldig greit. Har gjort noen endringer i en applikasjon, og nå feiler parsing av config filer:

 

$ bin/pin_senter.debug --front-end TFS --issuer gem --conf conf/pin_test.conf --in pregchip01.txt

Loading config 'conf/pin_test.conf'

ENVIRONMENT '=' TESTMATRIX

SDC-SOURCE-PATH '=' data/emv/input_pin/sdc/

TFS-SOURCE-PATH '=' data/emv/input_pin/tfs/

BBS-SOURCE-PATH '=' data/emv/input_pin/bbs/

CPRF-REQUEST-PATH '=' data/emv/input_pin/temp_debet/

ISO-RESPONSE-PATH '=' data/emv/input_pin/temp_debet/

PINDB-PATH '=' data/emv/pindb/

2009-06-04 17:46:14 ERROR 'getconf/conf_sym.c' line 686: pre-condition violation: 'SYM_LOG_FILE && is_file(value)'

 

så programmet trynet, når LOG_FILE parameter ble lest inn. Vi fyrer opp gdb

 

$ gdb --args bin/pin_senter.debug --front-end TFS --issuer gem --conf conf/pin_test.conf --in pregchip01.txt

GNU gdb 6.8-debian

Copyright © 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...

 

for å starte debug sesjon, så kan man enten skrive break main og run, eller

 

gdb $ start

Breakpoint 1 at 0x80590cc: file src/pin_main.c, line 302.

main (argc=0x9, argv=0xbfab8014) at src/pin_main.c:302

302 {

 

jeg setter break punkt der hvor feilen var

 

gdb $ b conf_sym.c:686

Breakpoint 2 at 0x8063440: file getconf/conf_sym.c, line 686.

gdb $ info break

Num Type Disp Enb Address What

2 breakpoint keep y 0x08063440 in pin_conf_add at getconf/conf_sym.c:686

 

og kjører via continue kommandoen:

 

gdb $ c

Loading config 'conf/pin_test.conf'

ENVIRONMENT '=' TESTMATRIX

SDC-SOURCE-PATH '=' data/emv/input_pin/sdc/

TFS-SOURCE-PATH '=' data/emv/input_pin/tfs/

BBS-SOURCE-PATH '=' data/emv/input_pin/bbs/

CPRF-REQUEST-PATH '=' data/emv/input_pin/temp_debet/

ISO-RESPONSE-PATH '=' data/emv/input_pin/temp_debet/

PINDB-PATH '=' data/emv/pindb/

 

Breakpoint 2, pin_conf_add (conf=0xbfaa6028, ctx=0x808ea00, id=SYM_LOG_FILE, value=0x808f078 "data/log/PIN_system.log") at getconf/conf_sym.c:686

686 REQUIRE( SYM_LOG_FILE && is_file(value) );

 

nå er vi interessert i å kikke på variabelen "value"

 

gdb $ print value

$1 = 0x808f078 "data/log/PIN_system.log"

 

for å steppe til neste linje, next

 

gdb $ n

2009-06-04 17:52:03 ERROR 'getconf/conf_sym.c' line 686: pre-condition violation: 'SYM_LOG_FILE && is_file(value)'

 

Program exited with code 01.

 

setter debug sesjon i bakgrunnen med Control-Z

 

gdb $

[1]+ Stopped gdb --args bin/pin_senter.debug --front-end TFS --issuer gem --conf conf/pin_test.conf --in pregchip01.txt

 

og sjekker om filen finnes

 

$ ls data/log/

PIN_senter.log

 

Nei, så da lager vi den

 

$ touch data/log/PIN_system.log

 

tar debugger opp igjen

 

$ fg

gdb --args bin/pin_senter.debug --front-end TFS --issuer gem --conf conf/pin_test.conf --in pregchip01.txt

 

The program is not being run.

 

setter break punkt på main

 

$ b main

Breakpoint 3 at 0x80590cc: file src/pin_main.c, line 302.

 

og kjører fra starten igjen

 

gdb $ run

 

Breakpoint 3, main (argc=0x9, argv=0xbf8b7614) at src/pin_main.c:302

302 {

gdb $ c

Loading config 'conf/pin_test.conf'

ENVIRONMENT '=' TESTMATRIX

SDC-SOURCE-PATH '=' data/emv/input_pin/sdc/

TFS-SOURCE-PATH '=' data/emv/input_pin/tfs/

BBS-SOURCE-PATH '=' data/emv/input_pin/bbs/

CPRF-REQUEST-PATH '=' data/emv/input_pin/temp_debet/

ISO-RESPONSE-PATH '=' data/emv/input_pin/temp_debet/

PINDB-PATH '=' data/emv/pindb/

 

Breakpoint 2, pin_conf_add (conf=0xbf8a5628, ctx=0x808ea00, id=SYM_LOG_FILE, value=0x808f078 "data/log/PIN_system.log") at getconf/conf_sym.c:686

686 REQUIRE( SYM_LOG_FILE && is_file(value) );

 

tilbake til der hvor programmet feilet, stepper til neste linje

 

gdb $ n

687 conf->fname_log = xstrdup(value);

 

vola, det virket!

 

Her er gdbinit filen min:

 

# INSTRUCTIONS: save as ~/.gdbinit

#

# DESCRIPTION: A cracker-friendly gdb configuration file.

#

# REVISION : 7

#

# CONTRIBUTORS: mammon_, elaine, pusillus, mong, tor

#

# FEEDBACK: http://board.anticrack.de/viewforum.php?f=35

#

# NOTES: 'help user' in gdb will list the commands/descriptions in this file

# 'context on' now enables auto-display of context screen

#

# CHANGELOG:

# Version 7

# removed much stuff that didn't work, added "des"

# Version 6.1

# fixed filename in step_to_call so it points to /dev/null

# changed location of logfiles from /tmp to ~

# Version 6j

# added print_insn_type, get_insn_type, context-on, context-off commands

# added trace_calls, trace_run, step_to_call commands

# changed hook-stop so it checks $SHOW_CONTEXT variable

# Version 5

# added bpm, dump_bin, dump_hex, bp_alloc commands

# added 'assemble' by elaine, 'gas_asm' by mong

# added Tip Topics for aspiring crackers

# Version 4

# added eflags-changing insns by pusillus

# added bp, nop, null, and int3 patch commands, also hook-stop

# Version 3

# incorporated elaine's if/else goodness into the hex/ascii dump

# Version 2

# radix bugfix by elaine

# TODO:

# * add global vars to allow user to control stack,data,code win sizes

# * add dump, append, set write, etc commands

# * more tips!

 

 

# __________________gdb options_________________

set confirm off

set verbose off

#

#set prompt 33[01;m33] niel@gdb $ 33[0m

#

set prompt 33[31mgdb $ 33[0m

set output-radix 0x10

set input-radix 0x10

#

# These make gdb never pause in its output

#

set height 0

set width 0

 

# why do these not work??? ==> REMOVE

#set $SHOW_CONTEXT = 1

#set $SHOW_NEST_INSN=0

 

set disassembly-flavor intel

 

# ______________breakpoint aliases_____________

define bpl

info breakpoints

end

document bpl

List breakpoints

end

 

define bp

#set $SHOW_CONTEXT = 1

break * $arg0

end

document bp

Set a breakpoint on address

Usage: bp addr

end

 

define bpc

clear $arg0

end

document bpc

Clear breakpoint at function/address

Usage: bpc addr

end

 

define bpe

enable $arg0

end

document bpe

Enable breakpoint #

Usage: bpe num

end

 

define bpd

disable $arg0

end

document bpd

Disable breakpoint #

Usage: bpd num

end

 

define bpt

set $SHOW_CONTEXT = 1

tbreak $arg0

end

document bpt

Set a temporary breakpoint on address

Usage: bpt addr

end

 

define bpm

set $SHOW_CONTEXT = 1

awatch $arg0

end

document bpm

Set a read/write breakpoint on address

Usage: bpm addr

end

 

define bhb

set $SHOW_CONTEXT = 1

hb * $arg0

end

document bhb

Set Hardware Assisted breakpoint on address

Usage: bhb addr

end

 

# ______________process information____________

define argv

show args

end

document argv

Print program arguments

end

 

define stack

info stack

end

document stack

Print call stack

end

 

define frame

info frame

info args

info locals

end

document frame

Print stack frame

end

 

define flags

if (($eflags >> 0xB) & 1 )

printf "O "

else

printf "o "

end

if (($eflags >> 0xA) & 1 )

printf "D "

else

printf "d "

end

if (($eflags >> 9) & 1 )

printf "I "

else

printf "i "

end

if (($eflags >> 8) & 1 )

printf "T "

else

printf "t "

end

if (($eflags >> 7) & 1 )

printf "S "

else

printf "s "

end

if (($eflags >> 6) & 1 )

printf "Z "

else

printf "z "

end

if (($eflags >> 4) & 1 )

printf "A "

else

printf "a "

end

if (($eflags >> 2) & 1 )

printf "P "

else

printf "p "

end

if ($eflags & 1)

printf "C "

else

printf "c "

end

printf "\n"

end

document flags

Print flags register

end

 

define eflags

printf " OF <%d> DF <%d> IF <%d> TF <%d>",\

(($eflags >> 0xB) & 1 ), (($eflags >> 0xA) & 1 ), \

(($eflags >> 9) & 1 ), (($eflags >> 8) & 1 )

printf " SF <%d> ZF <%d> AF <%d> PF <%d> CF <%d>\n",\

(($eflags >> 7) & 1 ), (($eflags >> 6) & 1 ),\

(($eflags >> 4) & 1 ), (($eflags >> 2) & 1 ), ($eflags & 1)

printf " ID <%d> VIP <%d> VIF <%d> AC <%d>",\

(($eflags >> 0x15) & 1 ), (($eflags >> 0x14) & 1 ), \

(($eflags >> 0x13) & 1 ), (($eflags >> 0x12) & 1 )

printf " VM <%d> RF <%d> NT <%d> IOPL <%d>\n",\

(($eflags >> 0x11) & 1 ), (($eflags >> 0x10) & 1 ),\

(($eflags >> 0xE) & 1 ), (($eflags >> 0xC) & 3 )

end

document eflags

Print entire eflags register

end

 

define reg

printf " eax:%08X ebx:%08X ecx:%08X ", $eax, $ebx, $ecx

printf " edx:%08X eflags:%08X\n", $edx, $eflags

printf " esi:%08X edi:%08X esp:%08X ", $esi, $edi, $esp

printf " ebp:%08X eip:%08X\n", $ebp, $eip

printf " cs:%04X ds:%04X es:%04X", $cs, $ds, $es

printf " fs:%04X gs:%04X ss:%04X ", $fs, $gs, $ss

echo 33[31m

flags

echo 33[0m

end

document reg

Print CPU registers

end

 

define func

info functions

end

document func

Print functions in target

end

 

define var

info variables

end

document var

Print variables (symbols) in target

end

 

define lib

info sharedlibrary

end

document lib

Print shared libraries linked to target

end

 

define sig

info signals

end

document sig

Print signal actions for target

end

 

define thread

info threads

end

document thread

Print threads in target

end

 

define u

info udot

end

document u

Print kernel 'user' struct for target

end

 

define dis

disassemble $arg0

end

document dis

Disassemble address

Usage: dis addr

end

 

# ________________hex/ascii dump an address______________

define ascii_char

# thanks elaine

set $_c=*(unsigned char *)($arg0)

if ( $_c < 0x20 || $_c > 0x7E )

printf "."

else

printf "%c", $_c

end

end

document ascii_char

Print the ASCII value of arg0 or '.' if value is unprintable

end

 

define hex_quad

printf "%02X %02X %02X %02X %02X %02X %02X %02X", \

*(unsigned char*)($arg0), *(unsigned char*)($arg0 + 1), \

*(unsigned char*)($arg0 + 2), *(unsigned char*)($arg0 + 3), \

*(unsigned char*)($arg0 + 4), *(unsigned char*)($arg0 + 5), \

*(unsigned char*)($arg0 + 6), *(unsigned char*)($arg0 + 7)

end

document hex_quad

Print eight hexadecimal bytes starting at arg0

end

 

define hexdump

printf "%08X : ", $arg0

hex_quad $arg0

printf " - "

hex_quad ($arg0+8)

printf " "

 

ascii_char ($arg0)

ascii_char ($arg0+1)

ascii_char ($arg0+2)

ascii_char ($arg0+3)

ascii_char ($arg0+4)

ascii_char ($arg0+5)

ascii_char ($arg0+6)

ascii_char ($arg0+7)

ascii_char ($arg0+8)

ascii_char ($arg0+9)

ascii_char ($arg0+0xA)

ascii_char ($arg0+0xB)

ascii_char ($arg0+0xC)

ascii_char ($arg0+0xD)

ascii_char ($arg0+0xE)

ascii_char ($arg0+0xF)

 

printf "\n"

end

document hexdump

Display a 16-byte hex/ASCII dump of arg0

end

 

#

# des

#

define des

printf "%02X%02X %02X%02X %02X%02X %02X%02X", \

*(unsigned char*)($arg0), *(unsigned char*)($arg0 + 1), \

*(unsigned char*)($arg0 + 2), *(unsigned char*)($arg0 + 3), \

*(unsigned char*)($arg0 + 4), *(unsigned char*)($arg0 + 5), \

*(unsigned char*)($arg0 + 6), *(unsigned char*)($arg0 + 7)

 

printf " - '"

 

ascii_char ($arg0)

ascii_char ($arg0+1)

ascii_char ($arg0+2)

ascii_char ($arg0+3)

ascii_char ($arg0+4)

ascii_char ($arg0+5)

ascii_char ($arg0+6)

ascii_char ($arg0+7)

 

printf "'\n"

end

document des

Print arg0 as a DES block (eight hexadecimal bytes)

end

 

 

#

# sha - dump SHA-1 buffer

#

define sha

set $i = 0

while $i < 20

printf "%d %02X\n", $i, *(unsigned char*)($arg0 + $i)

set $i = $i + 1

end

printf "\n"

end

document sha

Print arg0 as a SHA-1 block (20 hexadecimal bytes)

end

 

#EOF

[GeirGrusom]

Er dette reklame for debugging 1985-style?

[kernel]

Hehe, det er faktisk mange som synes dette er veldig grei metode å debugge på.

 

Når man jobber på stormaskiner eller servere som ikke kjører Windows, så er det vanlig at GUI mangler totalt. Så dette er veldig nyttig å kunne, selv om studenter slipper unna med IDE, så gjør ikke alle profesjonelle utviklere det gitt.

[Giddion]

<snip>

Når man jobber på stormaskiner eller servere som ikke kjører Windows, så er det vanlig at GUI mangler totalt. Så dette er veldig nyttig å kunne, selv om studenter slipper unna med IDE, så gjør ikke alle profesjonelle utviklere det gitt.

Det stemmer det... dessverre.

Takk og lov for gdbserver så man kan redusere det til et minimum

[kernel]

Takk og lov for gdbserver så man kan redusere det til et minimum

 

Jeg ser ungdommen gjør alle mulige krumspring for å unngå dette, de installerer cross-compiler og masse tjafs for å kunne debugge via IDE, men etter min erfaring trengs kun en backtrace og så finner jeg feilen i ca. 90% av tilfellene. De bruker lenger tid...

 

[Giddion]

Det er poenget når jeg bruker gdb direkte... det er rett og slett den enkleste og raskeste metoden for å finne feil i enkelte tilfeller...... men i mer kompliserte situasjoner syntes jeg at det er best med en ide.... nå har ikke jeg gdb inn i fingrenne så det blir mange oppslag i manualen og det påvirker nok mitt synspunkt

[kernel]

nå har ikke jeg gdb inn i fingrenne så det blir mange oppslag i manualen og det påvirker nok mitt synspunkt

 

Det er ikke så mye å huske, du kommer langt med

 

start

r - run

b - break

n - next

s - step

c - continue

p - print

l - list

q - quit

info

help

 

og for mer avansert gdb debugging, kan man ta en titt på

 

core <core-dump> - post-mortem debugging

bt - backtrace print av call stack av f.eks. <core-dump>

frame n - hopper til frame nr. n i f.eks <core-dump>

 

watch - setter watch point, dvs. break punkt når variabel endres

rwatch - break punkt når variabel leses

awatch - break punkt når variabel leses eller endres

 

og for enda mer avanserte triks, kan man ta en titt på .gdbinit filen jeg postet, akkurat som jeg definerte des og sha funksjonene der, så er det enkelt å utvide med sine egne gdb makroer.

Endret 4. juni 2009 av kernel

[[kami]]

en ting mange ikke vet er at man kan bytte til windowed mode ved å trykke ctr+x,ctr+a (samme for å bytte tilbake)

Da får man kildekoden på øvre halvdel og kommandolinje på resten. når du stepper så er det en indikator som flytter seg etter som hvor du er i kildekoden.

 

gdb er nyttig den, bare litt avskrekkende å bli kjent med. visual studio/valgrind er overlegene om man har det som alternativ though.

[GeirGrusom]

I VS har en øyeblikkelig oversikt over call stack, registre, variabler, watches og dissasembly mens en debugger.

I tillegg har du jo edit & continue så en slipper å restarte debugging dersom en finner en liten feil.

[Giddion]

I VS har en øyeblikkelig oversikt over call stack, registre, variabler, watches og dissasembly mens en debugger.

I tillegg har du jo edit & continue så en slipper å restarte debugging dersom en finner en liten feil.

 

gdb har støtte for det også (så vidt jeg vet)... vel ikke e&c da.

gdb burde ikke sammenlignes med visual studio debugger, men heller med programmer som er av samme type som gdb som f. eks. microsoft console debugger (cdb).

 

[kami]

Det med vindu modus skulle jeg gjerne vist før

 

kernel

Nice liste.

[GeirGrusom]

gdb har støtte for det også (så vidt jeg vet)

 

Joda, jeg at det har støtte for det.

Jeg laget et IDE for D en gang, og da brukte jeg gdb som debugger gjennom IDE-et ved å sende og lese tekst fra programmet. Poenget er at en får ikke vite alt samtidig fordi det ikke er GUI basert. Du må spørre etter forskjellige ting.

I et IDE er alle opplysningene tilgjengelig hele tiden uten at du trenger å spørre etter dem, og du får vite verdien i en variabel ved å holde over den med musepekeren.

[kernel]

I et IDE er alle opplysningene tilgjengelig hele tiden uten at du trenger å spørre etter dem, og du får vite verdien i en variabel ved å holde over den med musepekeren.

 

Poenget er at man ikke alltid kan debugge et program via IDE, og i en rekke tilfeller går det veldig greit å gjøre dette på gamle måten. Forøvrig, applikasjonen jeg debugget i initiell post, går på en system uten X windows og all kommunikasjon til maskinen er stengt, skal applikasjon debugges i produksjon, må man gjøre dette direkte via konsollet. All input- og output inneholder sensitiv informasjon, og det er ikke tillatt å feilsøke produksjons data på testsystem.

 

Den mest effektive måten å feilsøke for eksempel en server på, er ikke å sette break punkt og vente på at feiltilfelle oppstår. Noen bugs kan skje en per 100 000 skudd... andre bugs oppstår kun på produksjon maskin, hvor man som utvikler ikke nødvendigvis har tilgang. Det man gjerne får er en core dump, det å ta en backtrace, gå til riktig frame og se på variablene der, er ingen heksekunst og går utmerket uten IDE.

 

Hvis man vedlikeholder en kernel-mode driver eller real-time kode, så er heller ikke en IDE den måten debugging (normalt) foregår på. Har ikke sett noe statistikk, men det vil ikke forundre meg om andelen av C programmerere som bedriver embedded/kernel mode utvikling nå, er større en dem som bedriver applikasjons utvikling.

[GeirGrusom]

Poenget er at man ikke alltid kan debugge et program via IDE, og i en rekke tilfeller går det veldig greit å gjøre dette på gamle måten. Forøvrig, applikasjonen jeg debugget i initiell post, går på en system uten X windows og all kommunikasjon til maskinen er stengt, skal applikasjon debugges i produksjon, må man gjøre dette direkte via konsollet. All input- og output inneholder sensitiv informasjon, og det er ikke tillatt å feilsøke produksjons data på testsystem.

Er det ikke mer normalt å bare ha test-data i et test-system?

Den mest effektive måten å feilsøke for eksempel en server på, er ikke å sette break punkt og vente på at feiltilfelle oppstår. Noen bugs kan skje en per 100 000 skudd... andre bugs oppstår kun på produksjon maskin, hvor man som utvikler ikke nødvendigvis har tilgang. Det man gjerne får er en core dump, det å ta en backtrace, gå til riktig frame og se på variablene der, er ingen heksekunst og går utmerket uten IDE.

Ja, så klart. Hvis problemet skjer på produksjonsmaskinen er vel neppe et IDE aktuelt.

Hvis man vedlikeholder en kernel-mode driver eller real-time kode, så er heller ikke en IDE den måten debugging (normalt) foregår på. Har ikke sett noe statistikk, men det vil ikke forundre meg om andelen av C programmerere som bedriver embedded/kernel mode utvikling nå, er større en dem som bedriver applikasjons utvikling.

 

Ja, det har du nok rett i. Det finnes mange bedre alternativer til C for normal applikasjonsutvikling.

[kernel]

Det finnes mange bedre alternativer til C for normal applikasjonsutvikling.

 

Tja, hvilket verktøy som er best blir fort subjektivt, etter min mening kommer det først og fremst an på hva man kan godt.

 

Så for de som kan C eller C++ best, så blir det mest effektivt å bruke det språket.

Endret 8. juni 2009 av kernel

[Giddion]

<nip>

Så for de som kan C eller C++ best, så blir det mest effektivt å bruke det språket.

 

Jeg er ikke enig, med deg.

Hvis prosjektet er av en hvis størrelse kan det godt hende at det lønner seg å lære seg et nytt språk.

[kernel]

Jeg er ikke enig, med deg.

Hvis prosjektet er av en hvis størrelse kan det godt hende at det lønner seg å lære seg et nytt språk.

 

Greit nok, men forutsetningen min var at man kan språket godt.

 

Edit:

Det eneste området jeg har følt C/C++ virkelig kommer til kort, har vært til programmering av avansert logikk, men kostnaden ved å lære Lisp og/eller Prolog ser ganske avskrekkende ut...

Endret 8. juni 2009 av kernel

[Giddion]

Dette blir veldig off topic, men jeg mener at man vil være mer effektiv med et høyere språk enn c++ selv om man kan c++ godt. C++ er rett og slett for tungvindt i forhold til andre språk. Det er ikke noe begrensninger i selve språket, men det er mye mer å tenke på i forhold til andre språk.

Endret 8. juni 2009 av Giddion

[kernel]

For min del, vil det å opparbeide samme kompetansenivå i ett annet språk, ta flere år.

[kernel]

Eksempel på debugge program med Segmentation fault.

 

#include <stdio.h>
#include <string.h>
void foo(void)
{
       char *p = NULL;

       strcpy(p, "Seg fault");
}

int main(void)
{
       foo();
       return 0;
}

 

$ gcc -g -ansi seg_fault.c

$ gdb a.out

GNU gdb 6.8-debian

Copyright © 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...

gdb $ r

 

Program received signal SIGSEGV, Segmentation fault.

0xb7ed89ba in memcpy () from /lib/tls/i686/cmov/libc.so.6

gdb $ bt

#0 0xb7ed89ba in memcpy () from /lib/tls/i686/cmov/libc.so.6

#1 0x0804839c in foo () at seg_fault.c:7

#2 0x080483b4 in main () at seg_fault.c:12

gdb $ frame 1

#1 0x0804839c in foo () at seg_fault.c:7

7 strcpy(p, "Seg fault");

gdb $ p p

$1 = 0x0

gdb $ q

[GeirGrusom]

Det finnes mange bedre alternativer til C for normal applikasjonsutvikling.

 

Tja, hvilket verktøy som er best blir fort subjektivt, etter min mening kommer det først og fremst an på hva man kan godt.

 

Så for de som kan C eller C++ best, så blir det mest effektivt å bruke det språket.

 

 

Det er jeg kjempeuenig i. For å dra sammenligningen veldig mye lenger for å understreke poenget kan en ikke si det er like enkelt å lage et program som skriver ut en Fibbonaci rekke i Assembly som det er i Haskell.

 

Det er mange ting C++ er uegnet til, både på grunn av minnebehandling og på grunn av syntaks som andre språk ville gjort en bedre jobb.

Eksempelvis er GUI noe som på tross av gode GUI biblioteker i C++ kan være betydelig enklere å få til i andre språk.

Ta for eksempel C# (som jeg kan best) som har LINQ (Language Intergrated Query) for å jobbe med data i arrays (collections) XML datakilder eller SQL datakilder, lambdauttrykk og automatisk garbage collection.

Dette er ting som helt klart gjør at C# for en fordel ovenfor C++ i mange oppgaver. Selv om oppgaven kan løses i C++ er ikke løsningen like elegant som den ville vært i C#.

Det var jo lenge her en tråd hvor noen ønsket å lese en fil til en string, som kan gjøres med én linje i kanskje alle andre programmeringsspråk enn C++.

 

Men øh, dette er off-topic

 

I et IDE ville en segmentation fault gitt deg et breakpoint mye hendigere ^^

Endret 9. juni 2009 av GeirGrusom