Delphi koodaus

Kommentti tuokin on. Mutta Delphiä tekevä yritys on hylännyt esim. C shapin, Javan ja PHP (todennäköisesti) kannattomina valmistaa ja kehittää. Sekin on kannanotto (business näkökulma).

Delphi10_Seattle kirjoitti:

Kommentti tuokin on. Mutta Delphiä tekevä yritys on hylännyt esim. C shapin, Javan ja PHP (todennäköisesti) kannattomina valmistaa ja kehittää. Sekin on kannanotto (business näkökulma).

Lue lisää

Delphiä tekevä yritys on vaihtanut omistajaansa aika ahkerasti kun sitä on palloteltu, että mistä nyt ihan tarkalleen ottaen puhut?

Delphiä tekevälle yritykselle lienee kannattamatonta tehdä oikein yhtään mitään muuta jos edes Delphiäkään eikä se johdu mitenkään siitä, että esim. C#:ssa olisi vikaa vaan siitä, että Delphiä tekevällä yrityksellä ei oikein ole mitään merkitystä nykyisillä teknologiapinoilla.

Se on oikeastaan aika yksi ja sama mitä kieltä opettelee. Tärkeintä siinä kuitenkin ohjelmoinnin opettelu, ei se kieli.
Teen itsekin omaan käyttöön ohjelmia lazaruksella, kun en vaan jaksa alkaa vapaa-aikana käyttämään mitään, mitä käytän työssä 20..25 tuntia viikossa.

toki.

2. mahdollisuus:

Laita formille TPaintBox -komponentti, ja sen OnPaint -käsittelijässä maalataan haluttu sisältö.

huom: jos vaikkapa siirryt hetkeksi toiseen sovellukseen (Alt-Tabilla esim. windows laskimeen tai muistioon), niin kun tulet takaisin, niin Delphi s-sovelluksesi ei automaattisesti muista, mitä tuossa PaintBoxissa oli (siis jos laskin tai muistio peitti ko. PaintBoxin), vaan sovelluksesi liipaisee tässä vaiheessa OnPaint -käsittelijän, jonka tulee vastata siitä, että haluamasi sisältö maalataan uudelleen.

Mutta vanhemmissa Delphin versioissa esim. Png -muoto ei ole suoraan tuettu.

Mutta kun käytät PngImage -unitia, niin sillä saa png -tuen lisättyä Delphi -sovellukseesi.

Yksittäisten pikselien käsittely Pixels[] -propertyn kautta, ja jos kaipaat lisää nopeutta pikselien käsittelyyn, tällöin opettele käyttämään ScanLine -propertyä.

niin... vaikuttaa siltä, että M-Kar on Delphi -vihaaja ja C/C -fanittaja.

Tosiasioita:

1. Delphillä merkkijonojen käsittely on helppoa, eikä siihen liity riskiä puskurin ylivuodoista, kuten C -kielessä liittyy (syynä se, ettei C -kielessä oikeasti edes ole merkkijonoja, vaan C pakottaa käyttämään merkkitaulukoita kun kieli ei tue merkkijonoja).

Toki, JOS joudut esim. käyttämään C -kielellä tehtyä DLL:ää Delphi -ohjelmastasi, tällöin tulee olla hyvin tarkkana merkkijonojen kanssa.
(Rudy Velthuis:n sivulta http://rvelthuis.de/articles/ löytyy lisää hyödyllistä tietoa).

2. Muut taulukot:

Jos määrittelet vaikkapa 10 -alkioisen taulukon:

C-kielessä:

char a[10];
char test;

ja Delphissä esim:

var
a : Array[0..9] of AnsiChar; // vastaa em. c-kielen määrittelyä
test : AnsiChar;

niin C -kielessä tämä on aina vaarallista:

test = a[10]; // lukee arvon, joka EI ole em. a[] -taulukossa !!!

tai:

a[10] = test; // ylikirjoittaa muistia, joka EI kuulu a[] -taulukkoon !!!

Delphissäkin on oletuksena sama vaarallinen käytäntö.
Vaarallinen käytäntö on oletuksena luultavasti siksi, että jos ei olisi, niin Delphivihaajat valittaisivat, kuinka Delphi on hidas, ainakin hitaampi kuin C -kieli.

Mutta:

JOS Delphissä laitat käännösyksikön (Unit) alkuun kääntäjädirektiivin:

{$R }

niin nyt Delphi antaa suojaa ohjelmointivirheiden aiheuttamia puskurin ylivuotoja vastaan (toki ohjelmointivirhe on silti korjattava, mutta ainakaan se ei enää aiheuta vaarallista puskurin ylivuoto -riskiä).

eli jos tuon {$R } voimassaollessa yrität tehdä esim:

begin
a[10] := test; // aiheuttaa poikkeuksen, katso try - except -end
// ja try -finally -end

end;

poikkeus aiheutuu juuri ENNEN kuin vahingollinen käsky suoritettaisiin - vaarallista puskurin ylivuotoa ei ehdi tapahtumaan.

Lisäksi, voi kysyä, MIKSI C -kielessä on erikseen esim & ja && sekä ja ||, kun Delphissä selvitään AND ja OR -toiminnoilla.

Oikea vastaus:

Se, että C -kielessä tarvitaan erikseen & ja && johtuu siitä, ettei C -kielessä ole täsmällisesti ja yksikäsitteisesti määriteltyä TRUE -arvoa.

C -kielessähän FALSE = 0 (kuten Delphinkin sisäisessä esitysmuodossa, mutta EI syntaksissa), mutta arvon TRUE osalta:

C -kielessä mikä tahansa nollasta poikkeava arvo on TRUE, Delphissä taas TRUE on varattu sana, eikä sillä Boolean -tyyppisenä ole suoraa numeroarvoa, mutta sisäisessä esitysmuodossa TRUE tallennetaan AINA arvona 1.

Siis jos:

C - kielessä:

int B1,B2,B3;

ja

Delphissä
var
B1,B2,B3 : Boolean;

Niin jos sekä B1 että B2 ovat TRUE, niin

Delphissä:

B3 := B1 AND B2; // jos kerran B1 JA B2 ovat TRUE, silloin voidaan taata, että myös B3 = TRUE.

Mutta C -kielessä, jos erehtyisi käyttämään bitwise AND -operaattoria noihin B1 ja B2, niin esim, jos B1 = 2 (eli C-kielen säännöillä TRUE) ja B2=4 (eli C-kielen säännöillä myös TRUE), silti B3=0 (FALSE).

Delphissä ei tarvita erillistä logical AND -operaattoria, koska kun TRUE ei Delphissä ole mikä tahansa nollasta poikkeava arvo, vaan (sisäisessä esitysmuodossa) tasan 1 , silloin ihan normaali AND (eli siis bitwise AND, suoraan kuten esim 80386 CPU:n AND) antaa aina oikean lopputuloksen.

Delphi on myös aito oliokieli, mutta erittäin selkeällä syntaksilla, toisin kuin vaikea C , jossa vielä tämä lisäongelma:

JOS lähdekoodi on tehty ennen C 11 -standardia, niin vanha C -kääntäjä kääntää sen ongelmitta, mutta uudella C 11 -standardin mukaisella C -kääntäjällä kääntämisyritys tuottaa kasan kryptisiä virheilmoituksia.

Eli siis uusi C ja vanha C ovat ihan eri asioita.

Delphi ei myöskään pakota käyttämään olioita kuten Java.

Delphissä olioiden käyttö on mahdollisuus, ei pakko.

Ja: Delphin inline ASM on helppokäyttöinen ja selkeä, toisin kuin C: vastaava, jota ei edes voi käyttää opettelematta ensin käsitettä constraints (C -kääntäjälle ominainen asia).

Delphi inline ASMissa on selkeä periaate:

3 ensimmäistä tyypiltään kelvollista parametria menee rekistereihin EAX, EDX ja ECX, tässä järjestyksessä.

Funktion tulos rekisteriin EAX (tai sen osajoukkoon AL tai AX), paitsi 64 -bittinen Int64 menee EDX:EAX rekisteripariin.

Ja rutiinissa voi sellaisenaan käyttää rekistereitä EAX, EDX ja ECX,
mutta jos haluat käyttää mitään muuta rekisteriä, tulee ne ensin tallentaa pinoon (PUSH) ja lopuksi palauttaa sieltä (POP).

siis esim:

push EDI
push ESI
push EBX

// tässä voi käyttää myös EBX, ESI, EDI normaalien EAX, EDX ja ECX lisäksi.

pop EBX
pop ESI
pop EDI

Lisäksi, Delphi tukee säikeitä (TThread) suoraan.

Delphin name -lisäys tuotaessa DLL -funktioita on varsin kätevä.

Sen ansiosta voi esim. käyttää CreateFile -Windows -API -funktiota
tai myös uudelleenmääritellä ko. funktion tuolla nimellä, vaikka itseasiassa windowsin API ei tuon nimistä funktiota exportoi, vaan

CreateFileA ja CreateFileW -funktiot.

Siis nuo W -loppuiset ovat Unicode -versioita.

"mutta jos haluat käyttää mitään muuta rekisteriä, tulee ne ensin tallentaa pinoon (PUSH) ja lopuksi palauttaa sieltä (POP)."
-Pieni huomio free-pascal:sta tässä kohdassa, eli voi tehdä näin, tai sitten luetella asm-lohkon lopussa, mitä rekistereitä on käyttänyt, jolloin kääntäjä hoitaa homman:
asm
Movl $1,%ebx
Movl $0,%eax
addl %eax,%ebx
end; [’EAX’,’EBX’];
Nykyään ei ole pakko myöskään käyttää kamalaa AT&T-syntaksia, vaan on olemassa sisäinen versio assemblerista, jonka syntaksi on paljonkin mukavampaa, aika lähellä tasm-syntaksia oikeastaan.

Minä en kyllä ole kehunut tässä mitään toista kieltä. Delphi vaan alkaa olla aika kuollut juttu.

Kieli valitaan kyllä sitten ihan projektin vaatimusmäärittelyn mukaisesti, että mikä on sopivin. Yksi kieli ei oikein sovi kaikkeen.

Delphiguru kirjoitti:

niin... vaikuttaa siltä, että M-Kar on Delphi -vihaaja ja C/C -fanittaja.

Tosiasioita:

1. Delphillä merkkijonojen käsittely on helppoa, eikä siihen liity riskiä puskurin ylivuodoista, kuten C -kielessä liittyy (syynä se, ettei C -kielessä oikeasti edes ole merkkijonoja, vaan C pakottaa käyttämään merkkitaulukoita kun kieli ei tue merkkijonoja).

Toki, JOS joudut esim. käyttämään C -kielellä tehtyä DLL:ää Delphi -ohjelmastasi, tällöin tulee olla hyvin tarkkana merkkijonojen kanssa.
(Rudy Velthuis:n sivulta http://rvelthuis.de/articles/ löytyy lisää hyödyllistä tietoa).

2. Muut taulukot:

Jos määrittelet vaikkapa 10 -alkioisen taulukon:

C-kielessä:

char a[10];
char test;

ja Delphissä esim:

var
a : Array[0..9] of AnsiChar; // vastaa em. c-kielen määrittelyä
test : AnsiChar;

niin C -kielessä tämä on aina vaarallista:

test = a[10]; // lukee arvon, joka EI ole em. a[] -taulukossa !!!

tai:

a[10] = test; // ylikirjoittaa muistia, joka EI kuulu a[] -taulukkoon !!!

Delphissäkin on oletuksena sama vaarallinen käytäntö.
Vaarallinen käytäntö on oletuksena luultavasti siksi, että jos ei olisi, niin Delphivihaajat valittaisivat, kuinka Delphi on hidas, ainakin hitaampi kuin C -kieli.

Mutta:

JOS Delphissä laitat käännösyksikön (Unit) alkuun kääntäjädirektiivin:

{$R }

niin nyt Delphi antaa suojaa ohjelmointivirheiden aiheuttamia puskurin ylivuotoja vastaan (toki ohjelmointivirhe on silti korjattava, mutta ainakaan se ei enää aiheuta vaarallista puskurin ylivuoto -riskiä).

eli jos tuon {$R } voimassaollessa yrität tehdä esim:

begin
a[10] := test; // aiheuttaa poikkeuksen, katso try - except -end
// ja try -finally -end

end;

poikkeus aiheutuu juuri ENNEN kuin vahingollinen käsky suoritettaisiin - vaarallista puskurin ylivuotoa ei ehdi tapahtumaan.

Lisäksi, voi kysyä, MIKSI C -kielessä on erikseen esim & ja && sekä ja ||, kun Delphissä selvitään AND ja OR -toiminnoilla.

Oikea vastaus:

Se, että C -kielessä tarvitaan erikseen & ja && johtuu siitä, ettei C -kielessä ole täsmällisesti ja yksikäsitteisesti määriteltyä TRUE -arvoa.

C -kielessähän FALSE = 0 (kuten Delphinkin sisäisessä esitysmuodossa, mutta EI syntaksissa), mutta arvon TRUE osalta:

C -kielessä mikä tahansa nollasta poikkeava arvo on TRUE, Delphissä taas TRUE on varattu sana, eikä sillä Boolean -tyyppisenä ole suoraa numeroarvoa, mutta sisäisessä esitysmuodossa TRUE tallennetaan AINA arvona 1.

Siis jos:

C - kielessä:

int B1,B2,B3;

ja

Delphissä
var
B1,B2,B3 : Boolean;

Niin jos sekä B1 että B2 ovat TRUE, niin

Delphissä:

B3 := B1 AND B2; // jos kerran B1 JA B2 ovat TRUE, silloin voidaan taata, että myös B3 = TRUE.

Mutta C -kielessä, jos erehtyisi käyttämään bitwise AND -operaattoria noihin B1 ja B2, niin esim, jos B1 = 2 (eli C-kielen säännöillä TRUE) ja B2=4 (eli C-kielen säännöillä myös TRUE), silti B3=0 (FALSE).

Delphissä ei tarvita erillistä logical AND -operaattoria, koska kun TRUE ei Delphissä ole mikä tahansa nollasta poikkeava arvo, vaan (sisäisessä esitysmuodossa) tasan 1 , silloin ihan normaali AND (eli siis bitwise AND, suoraan kuten esim 80386 CPU:n AND) antaa aina oikean lopputuloksen.

Delphi on myös aito oliokieli, mutta erittäin selkeällä syntaksilla, toisin kuin vaikea C , jossa vielä tämä lisäongelma:

JOS lähdekoodi on tehty ennen C 11 -standardia, niin vanha C -kääntäjä kääntää sen ongelmitta, mutta uudella C 11 -standardin mukaisella C -kääntäjällä kääntämisyritys tuottaa kasan kryptisiä virheilmoituksia.

Eli siis uusi C ja vanha C ovat ihan eri asioita.

Delphi ei myöskään pakota käyttämään olioita kuten Java.

Delphissä olioiden käyttö on mahdollisuus, ei pakko.

Ja: Delphin inline ASM on helppokäyttöinen ja selkeä, toisin kuin C: vastaava, jota ei edes voi käyttää opettelematta ensin käsitettä constraints (C -kääntäjälle ominainen asia).

Delphi inline ASMissa on selkeä periaate:

3 ensimmäistä tyypiltään kelvollista parametria menee rekistereihin EAX, EDX ja ECX, tässä järjestyksessä.

Funktion tulos rekisteriin EAX (tai sen osajoukkoon AL tai AX), paitsi 64 -bittinen Int64 menee EDX:EAX rekisteripariin.

Ja rutiinissa voi sellaisenaan käyttää rekistereitä EAX, EDX ja ECX,
mutta jos haluat käyttää mitään muuta rekisteriä, tulee ne ensin tallentaa pinoon (PUSH) ja lopuksi palauttaa sieltä (POP).

siis esim:

push EDI
push ESI
push EBX

// tässä voi käyttää myös EBX, ESI, EDI normaalien EAX, EDX ja ECX lisäksi.

pop EBX
pop ESI
pop EDI

Lisäksi, Delphi tukee säikeitä (TThread) suoraan.

Delphin name -lisäys tuotaessa DLL -funktioita on varsin kätevä.

Sen ansiosta voi esim. käyttää CreateFile -Windows -API -funktiota
tai myös uudelleenmääritellä ko. funktion tuolla nimellä, vaikka itseasiassa windowsin API ei tuon nimistä funktiota exportoi, vaan

CreateFileA ja CreateFileW -funktiot.

Siis nuo W -loppuiset ovat Unicode -versioita.

Lue lisää

"niin... vaikuttaa siltä, että M-Kar on Delphi -vihaaja ja C/C -fanittaja."

En minä ole mitään kieltä kehunut.

Työkalu valitaan projektin mukaan, yksi väline ei ole sopiva kaikkeen. Delphi on vaan aika kuollut, että siinä en näe järkeä. Ei oikein ole projektia missä se olisi parempi kuin joku muu työkalu.

"1. Delphillä merkkijonojen käsittely on helppoa"

Niinkuin on muillakin.

"eikä siihen liity riskiä puskurin ylivuodoista, kuten C -kielessä liittyy (syynä se, ettei C -kielessä oikeasti edes ole merkkijonoja, vaan C pakottaa käyttämään merkkitaulukoita kun kieli ei tue merkkijonoja)."

C-kieli on systeemitason kieli. Sillä tehdään lähinnä matalan tason kirjastoja, kerneliä, palikoita putkeen. Yllättävän vähän siellä tarvitsee mitään merkkijonoja missään.

Että vähän kiinnostaa mistä projektista oikein puhut kun tunnut valitsevan väärää työkalua.

"Delphi on myös aito oliokieli, mutta erittäin selkeällä syntaksilla, toisin kuin vaikea C , jossa vielä tämä lisäongelma:"

Ei C ole mikään vaikea. Ohjelmoijalle joku ohjelmointikieli ei ole mikään "vaikea". Se on työkalu.

"JOS lähdekoodi on tehty ennen C 11 -standardia, niin vanha C -kääntäjä kääntää sen ongelmitta, mutta uudella C 11 -standardin mukaisella C -kääntäjällä kääntämisyritys tuottaa kasan kryptisiä virheilmoituksia."

Saa sen version sieltä vaihdettua.

"Eli siis uusi C ja vanha C ovat ihan eri asioita."

Ihan sama asia, on vain lisätty ominaisuuksia ja järkevöitetty jotain vanhoja.

"Ja: Delphin inline ASM on helppokäyttöinen ja selkeä, toisin kuin C: vastaava, jota ei edes voi käyttää opettelematta ensin käsitettä constraints (C -kääntäjälle ominainen asia)."

C-kieli on lähinnä korkean tason assembler, mutta se porttautuu näppärästi arkkitehtuurilta toiselle. Mitään inline ASM:ia ei käytännössä tarvitse.

"3 ensimmäistä tyypiltään kelvollista parametria menee rekistereihin EAX, EDX ja ECX, tässä järjestyksessä."

Tuo on jotain x86 riippuvaista kuraa. C kääntyy kaikille arkkitehtuureille.

"Lisäksi, Delphi tukee säikeitä (TThread) suoraan."

Säikeet ovat perusjuttuja.