"Thomas Holmgren" <thm@regnecentralen.dk> wrote in message
news:c36iap$1pg4$1@news.cybercity.dk...
> Njaah, jeg synes der har været flere småting hvor man lige har tænkt
> "det var da mystisk, det stammer helt sikkert fra det gode gamle
> Pascal". :) F.eks. at strenge indexeres fra 1 og ikke 0 glemmer jeg ret
> ofte.
Nu er strenge jo også en lidt speciel pascal-opfindelse...?
>Eller i det hele taget at strenge (og andre sammensatte typer),
> opfattes som simple typer og pr. default overføres som værdiparametre,
> modsat objekter, der altid overføres som referenceparametre, uanset om
> man angiver parametren som variabelparameter eller ej.
Jeg kan ikke se problemet. Det er ikke mange år siden, der overhovedet ikke
var noget der hed objekter, så for mange (måske de fleste?) gik tilvænningen
jo rent faktisk den anden vej.
Hvis jeg skal kritisere Delphi/Pascal er det faktisk, at man i modsætning
til andre sprog ikke bare kan oprette variable on-the-fly. Man går generelt
både med livrem og seler og Delphi.
> I denne
> sammenhæng: Skabes objekter altid på heapen når jeg instantierer dem med
> Create (som hvis jeg brugte new i java/C++)?
Ja! Men det er ikke "create" du danner objekter med, det er konstruktøren,
og den allokerer en pointer-reference på heapen, og kun denne
pointerreference.
>Kan man ikke skabe et
> objekt i den lokale stackframe hvis det kun skal bruges i en enkelt
> metode (som hvis jeg IKKE bruger new i java/C++)?
Du har i Delphi ækvivalenten class-methods, i stedet for de statiske metoder
du hentyder til i java/c. Delphis compiler gør meget ud af at reducere
brugen af stack frames, men det går uden for min rækkevidde at beskrive
dette i detaljer. Hvis du vil overstyre den slags, må du ty til
inline-assembler i koden - der findes adskillige artikler om den slags på
nettet. Jeg kan dog ikke begribe, at det overhovedet skulle være et problem
>Der har været andre
> tilsvarende småting undervejs, jeg kan ikke lige komme på dem nu. Men
> hva, det er jo de små forskelle der gør det morsomt at lære et nyt sprog
>
Har man lært ét sprog synes jeg man har lært alle, det er blot at vænne sig
til jargonen - som at flytte til Jylland, f.eks.
>OG så irriterer det mig lidt - nu hvor jeg lige kommer fra C++ - at
> der ikke findes multipel nedarvning i delphi!
Det gør der nu også, via interfaces. Men fortæl mig hvad problemet er, og
jeg kan sikkert vise dig en simpel løsning der ikke bruger multipel
nedarvning. Jeg har aldrig set et problem, hvor multipel nedarvning var
eneste og bedste løsning - ikke at de sikkert ikke findes, men det skal godt
nok være specielt
> MEN som sagt synes jeg man har en "god fornemmelse" når man sidder og
> laver et eller andet i delphi. Man får hurtigt fornemmelsen af at "det
> virker sgu" - uden at man - som f.eks. i C++ - skal sidde og bruge en
> masse krudt og kodelinier på at allokere hukommelse, kontrollere
> pointere, sikre sig mod overflow af ditten og datten, håndtere et hav af
> lavniveausignaler fra OS osv. osv. osv.
SÅ slemt synes jeg nu heller ikke C er. C er også rart, og jeg synes man med
C kan lave virkelig smarte ting, som ikke helt er så nemme at lave i Delphi.
> Man kan i delphi vældig hurtigt lave noget som fungerer glimrende og som
> ikke fylder ret mange linier. Det er samtidig grunden til at jeg spørger
> om så mange ting herinde - det er let at lave noget der virker, men
> laver man det "rigtigt" set med delphi-øjne?
Det der virker, og som andre kan forstå, og som man er i stand til at ændre
i også et halvt år efter må være rigtigt. Der findes imho ingen "rigtig"
Delphi-programmeringsteknik, måske bortset fra
navnetildelingskonventionerne.
> Der er ikke meget ved et
> nyt sprog, hvis man ikke får lært de helt specifikke, smarte ting, og i
> stedet bare sidder og implementerer tingene på samme måde som man plejer
> at gøre i de (andre) sprog man kender.
>
> Måske mangler jeg bare en god delphi-bog? Den eneste jeg har er "Delphi
> in a nutshell", og den er edderbankemig elendig!
"Mastering Delphi" er imho et kig værd.