palstan elvytys

..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.
Itse käytän Delphi, C ja assembly kieliä sovelluspuolella, kyllä delphi nopein on.
Alkuperäiseen kysymykseen, niin ehkä täällä keskustelu on suht kuollutta tästä aiheesta, Borlandin omat newsgroupit on paras paikka jos itse pitää jotain kysellä.
Minusta täällä nää ohjelmointikieli osiot on muutenkin hiljaisia, mureakuha tai ohjelmointiputka on parempia kotimaisia mestoja tästäkin aiheesta.

Delhiini kirjoitti:

..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.
Itse käytän Delphi, C ja assembly kieliä sovelluspuolella, kyllä delphi nopein on.
Alkuperäiseen kysymykseen, niin ehkä täällä keskustelu on suht kuollutta tästä aiheesta, Borlandin omat newsgroupit on paras paikka jos itse pitää jotain kysellä.
Minusta täällä nää ohjelmointikieli osiot on muutenkin hiljaisia, mureakuha tai ohjelmointiputka on parempia kotimaisia mestoja tästäkin aiheesta.

Lue lisää

Minä en tajua sitä mitä porukka kuolaa Visual Basicissa, kun Delphi on paljon parempi vaihtoehto?

En tosin tiedä uusimmasta VB:stä kuin versio 6, mutta silti Delphi tarjoaa heti alussa olio-ohjelmoinnin periaatteet jne.. Mielestäni kun oppii Delphin, niin on hellppo oppia myös C/C ja Java. Toki RAD periaatteen puuttuminen esim Visual C saattaa tuoda yllätyksen, mutta kyllä C kielen (ja Javan) ominaisuudet olisi paremmin tiedossa jos alottaisin pelkästään sekamelska VB:stä.. Delphi ei kummiskaan ole kaukana Visual Basicin periaatteista, kieli on kummiskin oikeanlaisempi kummiskin.

Delhiini kirjoitti:

..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.
Itse käytän Delphi, C ja assembly kieliä sovelluspuolella, kyllä delphi nopein on.
Alkuperäiseen kysymykseen, niin ehkä täällä keskustelu on suht kuollutta tästä aiheesta, Borlandin omat newsgroupit on paras paikka jos itse pitää jotain kysellä.
Minusta täällä nää ohjelmointikieli osiot on muutenkin hiljaisia, mureakuha tai ohjelmointiputka on parempia kotimaisia mestoja tästäkin aiheesta.

Lue lisää

*ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.*

Aivan, mut C kielen, C on hieman eriasia. Sekä maailmakehittyy enään ei ole tarpeen aloittaa milläin toisella kielellä kun löytyy hyvät oppaat jne...

Delphin osaamisesta ei ole varsinaisesti mitään hyötyä jos osaa C . Joten ennemmin vaik aloittaa opiskelun PHP, JSP tai muilla ihan eritarkoituksiin suunnitelluilla ja sit siirtyy näihin. Niin osaat kahta eritarkoituksiin sopivaa kieltä joiden osaamisesta on varmasti enemmän hyötyä kuin lähes samoihin tarkoitettujen kielten osaamisest.


*Delphi, C ja assembly... kyllä delphi nopein on*

Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä.

423 kirjoitti:

*ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.*

Aivan, mut C kielen, C on hieman eriasia. Sekä maailmakehittyy enään ei ole tarpeen aloittaa milläin toisella kielellä kun löytyy hyvät oppaat jne...

Delphin osaamisesta ei ole varsinaisesti mitään hyötyä jos osaa C . Joten ennemmin vaik aloittaa opiskelun PHP, JSP tai muilla ihan eritarkoituksiin suunnitelluilla ja sit siirtyy näihin. Niin osaat kahta eritarkoituksiin sopivaa kieltä joiden osaamisesta on varmasti enemmän hyötyä kuin lähes samoihin tarkoitettujen kielten osaamisest.


*Delphi, C ja assembly... kyllä delphi nopein on*

Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä.

Lue lisää

On aika jo tajuta että Delphi on ollut jo kauan nopea. Ai miksikö . Siinä on optimoiva kääntäjä ollut jo iät ja ajat!!


Eli miksiköhän Delphi voi hakata jopa assemblerin?
vastaus tuli jo kerrottua. Eli Delphin nopea optimoiva kääntäjä (mieti sitä)!


Mitä Delphin nopea kääntäjä sitten tekee. Tässä esimerkki eli jos kerrot luvun kahdella niin Delphin kääntäjä tekee yhteenlaskun kyseisen luvun kanssa (koska yhteenlasku on nopeampi kuin kertolasku). No entäpä jos luku jolla kerrotaan onkin neljä niin delphi teekee pari bitin siirrosta koska se on tässä tapauksessa nopein!
Eli tuotettva Delphi koodi on todellakin optimoitua (eli niinkuin kerroin niin tuotettava konekoodi pohjautuu pascal-kielisen lähdekoodin analysointiin)

423 kirjoitti:

*ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.*

Aivan, mut C kielen, C on hieman eriasia. Sekä maailmakehittyy enään ei ole tarpeen aloittaa milläin toisella kielellä kun löytyy hyvät oppaat jne...

Delphin osaamisesta ei ole varsinaisesti mitään hyötyä jos osaa C . Joten ennemmin vaik aloittaa opiskelun PHP, JSP tai muilla ihan eritarkoituksiin suunnitelluilla ja sit siirtyy näihin. Niin osaat kahta eritarkoituksiin sopivaa kieltä joiden osaamisesta on varmasti enemmän hyötyä kuin lähes samoihin tarkoitettujen kielten osaamisest.


*Delphi, C ja assembly... kyllä delphi nopein on*

Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä.

Lue lisää

>Äläs kuule valehtele. Eiköhän kuitenkin liene >Assembly sitten C/C ja Delphi tuossa >järjestyksessä.

Myt ei ollut puhe käännetyn koodin nopeudesta, vaan kehitys nopeudesta, jolloin järjestys on päinvastainen.

Delhiini kirjoitti:

..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.
Itse käytän Delphi, C ja assembly kieliä sovelluspuolella, kyllä delphi nopein on.
Alkuperäiseen kysymykseen, niin ehkä täällä keskustelu on suht kuollutta tästä aiheesta, Borlandin omat newsgroupit on paras paikka jos itse pitää jotain kysellä.
Minusta täällä nää ohjelmointikieli osiot on muutenkin hiljaisia, mureakuha tai ohjelmointiputka on parempia kotimaisia mestoja tästäkin aiheesta.

Lue lisää

"..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi."

Ei Pascalia kehitetty c:n opettelukieleksi (en luokittele teoreettisia metakieliä ohjelmointikieliksi kun niillä ei ohjelmia voi tehdä). Ensimmäinen pascal-kieli kehitettiin joskus 1950-luvulla ja c-kieli vasta 1970-luvulla.

Ei kai mitään ohjelmointikieltä ole tehty vartavasten toisen kielen opettelua varten. Pascal tehtiin varsin taipumattomaksi ja loogisesti selkeäksi. Tämä lisäsi sen käyttöä opetuksessa.

Kun joskus 1980-luvulla tutustuin UCSD-Pascaliin, niin MS-Basiciin verrattuna se oli turhan kankea.

Jotenkin ihmetyttää nämä asenteelliset tekstit eri kielien paremmuudesta. Ne jotka niitä käyvät eivät ilmeisesti ole juurikaan tehneet tietokoneohjelmia. Kyllä nykyiset kehittimet mahdollistavat helpon monimutkaisen ohjelmoinnin, mutta huono ohjelmoija tekee huonoa koodia kaikilla kehittimillä.

xxxxx kirjoitti:

"..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi."

Ei Pascalia kehitetty c:n opettelukieleksi (en luokittele teoreettisia metakieliä ohjelmointikieliksi kun niillä ei ohjelmia voi tehdä). Ensimmäinen pascal-kieli kehitettiin joskus 1950-luvulla ja c-kieli vasta 1970-luvulla.

Ei kai mitään ohjelmointikieltä ole tehty vartavasten toisen kielen opettelua varten. Pascal tehtiin varsin taipumattomaksi ja loogisesti selkeäksi. Tämä lisäsi sen käyttöä opetuksessa.

Kun joskus 1980-luvulla tutustuin UCSD-Pascaliin, niin MS-Basiciin verrattuna se oli turhan kankea.

Jotenkin ihmetyttää nämä asenteelliset tekstit eri kielien paremmuudesta. Ne jotka niitä käyvät eivät ilmeisesti ole juurikaan tehneet tietokoneohjelmia. Kyllä nykyiset kehittimet mahdollistavat helpon monimutkaisen ohjelmoinnin, mutta huono ohjelmoija tekee huonoa koodia kaikilla kehittimillä.

Lue lisää

Mutta nykyään Pascal (tämä hetkiset toteutukset) on erittäin joustava ja pitkälle viety kieli. Siinä tuki mmm moduleille, pakkauksille, olio-ohjelmoinnille, löytyy pointterit jne.

Delphiini kirjoitti:

>Äläs kuule valehtele. Eiköhän kuitenkin liene >Assembly sitten C/C ja Delphi tuossa >järjestyksessä.

Myt ei ollut puhe käännetyn koodin nopeudesta, vaan kehitys nopeudesta, jolloin järjestys on päinvastainen.

Lue lisää

Delphi on yksinkertaisesti nopein ! Eräs syy on on "virtuaalityypitys"(oma epävirallinen nimitys) jos tyypitystä verrataan C :n vastaavaan (toki voi Pascalissa käyttää tyyppejä C :n tavoin mutta harvapa tekee niin)

"virtuaalityypityksellä" tarkoitan sitä että kääntäjä tekee lopullisen valinnan käytettävästä tyypistä. Ohjelmoija vain yleensä ehdottaa että tälläistä haluan.

xxxxx kirjoitti:

"..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi."

Ei Pascalia kehitetty c:n opettelukieleksi (en luokittele teoreettisia metakieliä ohjelmointikieliksi kun niillä ei ohjelmia voi tehdä). Ensimmäinen pascal-kieli kehitettiin joskus 1950-luvulla ja c-kieli vasta 1970-luvulla.

Ei kai mitään ohjelmointikieltä ole tehty vartavasten toisen kielen opettelua varten. Pascal tehtiin varsin taipumattomaksi ja loogisesti selkeäksi. Tämä lisäsi sen käyttöä opetuksessa.

Kun joskus 1980-luvulla tutustuin UCSD-Pascaliin, niin MS-Basiciin verrattuna se oli turhan kankea.

Jotenkin ihmetyttää nämä asenteelliset tekstit eri kielien paremmuudesta. Ne jotka niitä käyvät eivät ilmeisesti ole juurikaan tehneet tietokoneohjelmia. Kyllä nykyiset kehittimet mahdollistavat helpon monimutkaisen ohjelmoinnin, mutta huono ohjelmoija tekee huonoa koodia kaikilla kehittimillä.

Lue lisää

Alunperin pascal perustuu Algol ohjelmointikieleen, pascal kehitettiin siitä -70 luvulla ja sitä käytettiin rakenteellisen ohjelmoinnin opetteluun, mutta sittemmin se alkoi elämään omaa elämäänsä ja kehittyi object pascaliksi.
Mutta en sekoittaisi käännettäviä ja tulkattavia kieliä, joita basicit ovat.
Missään vaiheessa en maininnut mitään minkään kielen paremmuudesta, ja ohjelmoinut olen työkseni -70 luvun lopulta alkaen lähes kaikilla tunnetuilla kielillä, tunnut itse olevan asenteellinen.

on näin kirjoitti:

Mutta nykyään Pascal (tämä hetkiset toteutukset) on erittäin joustava ja pitkälle viety kieli. Siinä tuki mmm moduleille, pakkauksille, olio-ohjelmoinnille, löytyy pointterit jne.

Lue lisää

Varmaankin "joustavuudella" tarkoitettiin tässä yhteydessä pascalin timantinkovaa tyypitys-ominaisuutta joka suojelee ohjelmiston järkevyyttä.

Pascalilla on vaikea tehdä välinpitämättömyysvirheitä, se on loistava ominaisuus vakavissa softissa.

Ei tuntematonta typecastia!

Delphiini kirjoitti:

Alunperin pascal perustuu Algol ohjelmointikieleen, pascal kehitettiin siitä -70 luvulla ja sitä käytettiin rakenteellisen ohjelmoinnin opetteluun, mutta sittemmin se alkoi elämään omaa elämäänsä ja kehittyi object pascaliksi.
Mutta en sekoittaisi käännettäviä ja tulkattavia kieliä, joita basicit ovat.
Missään vaiheessa en maininnut mitään minkään kielen paremmuudesta, ja ohjelmoinut olen työkseni -70 luvun lopulta alkaen lähes kaikilla tunnetuilla kielillä, tunnut itse olevan asenteellinen.

Lue lisää

Tuo mainintasi että Pascal perustuu Algoliin löytyy Googlesta ensimmäisenä kun hakusanoiksi syöttää "pascal kehitettiin" sivulta http://www.tuug.fi/~f/pascal/luku04.html
Jos vastauksessa viittaat jonkin sivun tietoon, niin kerro mihin nettiosoitteeseen vastauksesi perustuu.



"itse olevan asenteellinen."

Minä olen kyllä tosi asenteellinen siinä, etten siedä kun joku yrittää esiintyä älykkäämpänä kuin on. Tämän kirjoitusketjun ensimmäisessä viestissä sanoit, että "pascal kieli alunperin kehitettiin c:n opettelukieleksi". Minä vastasin ettei pidä paikkaansa. Sen jälkeen vastasit, että "Alunperin pascal perustuu Algol ohjelmointikieleen, pascal kehitettiin siitä -70 luvulla ja sitä käytettiin rakenteellisen ohjelmoinnin opetteluun."



"Missään vaiheessa en maininnut mitään minkään kielen paremmuudesta."

Miten niin et maininnut? Ensimmäisessä viestissäsi sanoit näin: "Itse käytän Delphi, C ja assembly kieliä sovelluspuolella, kyllä delphi nopein on."



"Mutta en sekoittaisi käännettäviä ja tulkattavia kieliä, joita basicit ovat."

Miksi ne pitäisi pitää omana ryhmänään? Kyllähän suuri osa basiceista on käännettäviä kieliä. Visual Basic myös käännetään. Ja aliohjelmakirjastoja (kuten windowsin functioita) käyttää kaikki ohjelmointikielet, joten on vaikea edes tehdä määrityksiä siitä, milloin ohjelmointikieli on tulkattava ja milloin käännettävä. Nykyään taulukoihin ja tietokantoihin viitataan useimmiten niiden tekstinimillä, joten ei niiden suoritus nopeudu vaikka ohjelma tehtäisiin assemblerilla.




"... ja ohjelmoinut olen työkseni -70 luvun lopulta alkaen lähes kaikilla tunnetuilla kielillä"

Sivulla http://www.cs.helsinki.fi/u/kerola/tkhist/k2006/alustukset/ohjkielet/hpr-historiasemma.pdf on yliopiston opiskelijan tekemä tutkimuksen alustus ohjelmointikielten kehittymisestä. Sen mukaan "viimeisen 60 vuoden aikana on kehitetty tuhansia ja taas tuhansia erilaisia ohjelmointikieliä", joten oletko todella ohjelmoinut työksesi lähes kaikilla tunnetuilla kielillä?

423 kirjoitti:

*ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi.*

Aivan, mut C kielen, C on hieman eriasia. Sekä maailmakehittyy enään ei ole tarpeen aloittaa milläin toisella kielellä kun löytyy hyvät oppaat jne...

Delphin osaamisesta ei ole varsinaisesti mitään hyötyä jos osaa C . Joten ennemmin vaik aloittaa opiskelun PHP, JSP tai muilla ihan eritarkoituksiin suunnitelluilla ja sit siirtyy näihin. Niin osaat kahta eritarkoituksiin sopivaa kieltä joiden osaamisesta on varmasti enemmän hyötyä kuin lähes samoihin tarkoitettujen kielten osaamisest.


*Delphi, C ja assembly... kyllä delphi nopein on*

Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä.

Lue lisää

"Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä."

Assembleri ei välttämättä ole nopein, kaikki kun riippuu sillä ohjelmoijan kyvyistä mutta ohjelmoija ei välttämättä osaa koodata nopeimmalla mahdollisella tavalla assyllä. Puhumattakaan siitä että kehitysaika on helvetin hidas, harvempi kuitenkaan haluaa viettää 20 vuotta tehden perussovellutusta...

C-kielellä tietyt ohjelmarakenteet saattavat täsmälleen saman lopputuloksen kuin assembler, käännetty konekielikoodi ei ole välttämättä yhtään sen hitaampi kuin suoraan konekieliseksi koodattu ohjelma. Kuitenkin monimutkaisissa ohjelmissa kääntäjän älykkyys työskentelee kooderin eduksi. inlinet, volatilet yms. tapahtuvat automattisesti toisin kuin assemblerissa.

Delphi - siis pascal - ei eroa c/c :sta mitenkään arkkitehtuurisesti; kääntäjä tuottaa optim,oidun konekielibinäärin. Siis ihan oikeasti, samaa konekieltä tuotetaan. Delphin etuna on vahva tyypitys jolloin ohjelmat voidaan optimoida paremmin. Toisaalta c-kielelle ominainen "control it all" voi toimia taitavan kooderin käsissä tehokkaammin kun pääsee oikomaan kääntäjää kauhistuttavilla hackeilla.

Nopein? Sanosin että jos nopeutta haluaa pitää valita sellainen kieli joka tukee arkkitehtuuria. Prosessoriksi Intel Pentium 4 / uudempi ja kääntäjäksi Intel C/C compiler. Tulee nopeinta koodia koska se optimoidaan tietylle arkkitehtuurille.

.................... kirjoitti:

"Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä."

Assembleri ei välttämättä ole nopein, kaikki kun riippuu sillä ohjelmoijan kyvyistä mutta ohjelmoija ei välttämättä osaa koodata nopeimmalla mahdollisella tavalla assyllä. Puhumattakaan siitä että kehitysaika on helvetin hidas, harvempi kuitenkaan haluaa viettää 20 vuotta tehden perussovellutusta...

C-kielellä tietyt ohjelmarakenteet saattavat täsmälleen saman lopputuloksen kuin assembler, käännetty konekielikoodi ei ole välttämättä yhtään sen hitaampi kuin suoraan konekieliseksi koodattu ohjelma. Kuitenkin monimutkaisissa ohjelmissa kääntäjän älykkyys työskentelee kooderin eduksi. inlinet, volatilet yms. tapahtuvat automattisesti toisin kuin assemblerissa.

Delphi - siis pascal - ei eroa c/c :sta mitenkään arkkitehtuurisesti; kääntäjä tuottaa optim,oidun konekielibinäärin. Siis ihan oikeasti, samaa konekieltä tuotetaan. Delphin etuna on vahva tyypitys jolloin ohjelmat voidaan optimoida paremmin. Toisaalta c-kielelle ominainen "control it all" voi toimia taitavan kooderin käsissä tehokkaammin kun pääsee oikomaan kääntäjää kauhistuttavilla hackeilla.

Nopein? Sanosin että jos nopeutta haluaa pitää valita sellainen kieli joka tukee arkkitehtuuria. Prosessoriksi Intel Pentium 4 / uudempi ja kääntäjäksi Intel C/C compiler. Tulee nopeinta koodia koska se optimoidaan tietylle arkkitehtuurille.

Lue lisää

Pärjääköhän tuo edes Borlandin C kääntäjälle? (Delphihän on tunnetusti Borlandin nopein tuote)

.................... kirjoitti:

"Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä."

Assembleri ei välttämättä ole nopein, kaikki kun riippuu sillä ohjelmoijan kyvyistä mutta ohjelmoija ei välttämättä osaa koodata nopeimmalla mahdollisella tavalla assyllä. Puhumattakaan siitä että kehitysaika on helvetin hidas, harvempi kuitenkaan haluaa viettää 20 vuotta tehden perussovellutusta...

C-kielellä tietyt ohjelmarakenteet saattavat täsmälleen saman lopputuloksen kuin assembler, käännetty konekielikoodi ei ole välttämättä yhtään sen hitaampi kuin suoraan konekieliseksi koodattu ohjelma. Kuitenkin monimutkaisissa ohjelmissa kääntäjän älykkyys työskentelee kooderin eduksi. inlinet, volatilet yms. tapahtuvat automattisesti toisin kuin assemblerissa.

Delphi - siis pascal - ei eroa c/c :sta mitenkään arkkitehtuurisesti; kääntäjä tuottaa optim,oidun konekielibinäärin. Siis ihan oikeasti, samaa konekieltä tuotetaan. Delphin etuna on vahva tyypitys jolloin ohjelmat voidaan optimoida paremmin. Toisaalta c-kielelle ominainen "control it all" voi toimia taitavan kooderin käsissä tehokkaammin kun pääsee oikomaan kääntäjää kauhistuttavilla hackeilla.

Nopein? Sanosin että jos nopeutta haluaa pitää valita sellainen kieli joka tukee arkkitehtuuria. Prosessoriksi Intel Pentium 4 / uudempi ja kääntäjäksi Intel C/C compiler. Tulee nopeinta koodia koska se optimoidaan tietylle arkkitehtuurille.

Lue lisää

FreePascal:kin on nopea (pärjäilee nopeuskisoissa ihan hyvin C kääntäjien kanssa) vaikka se on tehty monelle eri arkkitehtuurille. (Kuuluu ehdottomasti nopeimpiin kääntäjiin mitä saa Linuxiin)!

xxxxx kirjoitti:

Tuo mainintasi että Pascal perustuu Algoliin löytyy Googlesta ensimmäisenä kun hakusanoiksi syöttää "pascal kehitettiin" sivulta http://www.tuug.fi/~f/pascal/luku04.html
Jos vastauksessa viittaat jonkin sivun tietoon, niin kerro mihin nettiosoitteeseen vastauksesi perustuu.



"itse olevan asenteellinen."

Minä olen kyllä tosi asenteellinen siinä, etten siedä kun joku yrittää esiintyä älykkäämpänä kuin on. Tämän kirjoitusketjun ensimmäisessä viestissä sanoit, että "pascal kieli alunperin kehitettiin c:n opettelukieleksi". Minä vastasin ettei pidä paikkaansa. Sen jälkeen vastasit, että "Alunperin pascal perustuu Algol ohjelmointikieleen, pascal kehitettiin siitä -70 luvulla ja sitä käytettiin rakenteellisen ohjelmoinnin opetteluun."



"Missään vaiheessa en maininnut mitään minkään kielen paremmuudesta."

Miten niin et maininnut? Ensimmäisessä viestissäsi sanoit näin: "Itse käytän Delphi, C ja assembly kieliä sovelluspuolella, kyllä delphi nopein on."



"Mutta en sekoittaisi käännettäviä ja tulkattavia kieliä, joita basicit ovat."

Miksi ne pitäisi pitää omana ryhmänään? Kyllähän suuri osa basiceista on käännettäviä kieliä. Visual Basic myös käännetään. Ja aliohjelmakirjastoja (kuten windowsin functioita) käyttää kaikki ohjelmointikielet, joten on vaikea edes tehdä määrityksiä siitä, milloin ohjelmointikieli on tulkattava ja milloin käännettävä. Nykyään taulukoihin ja tietokantoihin viitataan useimmiten niiden tekstinimillä, joten ei niiden suoritus nopeudu vaikka ohjelma tehtäisiin assemblerilla.




"... ja ohjelmoinut olen työkseni -70 luvun lopulta alkaen lähes kaikilla tunnetuilla kielillä"

Sivulla http://www.cs.helsinki.fi/u/kerola/tkhist/k2006/alustukset/ohjkielet/hpr-historiasemma.pdf on yliopiston opiskelijan tekemä tutkimuksen alustus ohjelmointikielten kehittymisestä. Sen mukaan "viimeisen 60 vuoden aikana on kehitetty tuhansia ja taas tuhansia erilaisia ohjelmointikieliä", joten oletko todella ohjelmoinut työksesi lähes kaikilla tunnetuilla kielillä?

Lue lisää

..pilkun nysvääjä.

http://en.wikipedia.org/wiki/Pascal_programming_language

Se millä työkseni ohjelmoin ja siitä mainitsin, ei tarkoita minkään sortin paremmuutta, tai sitten suomen kielikin on muuttunut, minkään paremmuudesta ei ollut puhe, tai sitten nysväät rivien välitkin.


Joo, joo, voihan räkä, en ole ohjelmoinut kiinan kielellä, huh huh

Delphiini kirjoitti:

..pilkun nysvääjä.

http://en.wikipedia.org/wiki/Pascal_programming_language

Se millä työkseni ohjelmoin ja siitä mainitsin, ei tarkoita minkään sortin paremmuutta, tai sitten suomen kielikin on muuttunut, minkään paremmuudesta ei ollut puhe, tai sitten nysväät rivien välitkin.


Joo, joo, voihan räkä, en ole ohjelmoinut kiinan kielellä, huh huh

Lue lisää

"pilkun nysvääjä"

Tietokoneohjelmointi on täysin binääristä ja joka pilkun on oltava kohdallaan. Jos olet tottunut puhumaan tietokoneohjelmointikielistä vain yleisellä tasolla ilman tarkkoja faktoja, niin et voi olla tietokoneohjelmoija. Ainakaan kunnon koodaaja. Tästä mainitsin jo aikaisemmin ja siihen vastauksesi viittaavat, sillä et ole tässä kirjausketjussa vastannut esittämiini kysymyksiin. Sen sijaan olet itse tässä keskustelussa takertunut yhteen asiaan ja nysväät sen kanssa.



Jos sanot että jollain ohjelmointikielellä on nopeinta tehdä ohjelmaa, niin miten niin se ei tarkoita sitä, että mielestäsi se on ohjelmointinopeuden suhteen paras?


Tuohon Wikipedian artikkeliinko perustit alkuperäisen väitteesi, että Pascal kehitettiin C:n opettelukieleksi?



"Joo, joo, voihan räkä, en ole ohjelmoinut kiinan kielellä, huh huh"

Tällaisiin vastauksiin olen tottunut aikaisemminkin silloin, kun vastapuolella ei ole mitään älykästä lisättävää. Tietysti tuossa on jonkintasoinen fiksu sarkastinen heitto, mutta viittaus ohjelmointikielistä kiinankieleen on turhan yksinkertainen. Tuo olisi ollut parempi vaikka näin: "Sinäkin varmaan osaat ohjelmoida useammalla kielellä, mutta kun toinen koodaaja lukee ohjelmiasi, niin ne lukijasta näyttävät kiinalta ja siansaksalta. Joten vaikka sinä vaikututat selväjärkiseltä, niin ohjelmiasi selvittävä tarvitsee lääkitystä."



Wikipediassa on artikkeli argumentointivirheestä sivulla http://fi.wikipedia.org/wiki/Argumentaatiovirhe
tässä muutama viittaus sinun käyttämiin virheisiin:

"Argumentointivirheet ovat keskustelutekniikan ja mielipiteen esittämisen virheitä, jotka muodollisesti näyttävät oikeilta, mutta joissa lähemmin tarkasteltuina on joko looginen virhe, ne kohdistuvat johonkin muuhun kuin itse asiaan tai joissa käydään ihmisten eikä asioiden kimppuun."

"Argumentum ad auctoritatemin [auktoriteettiin vetoaminen] yleiskaava on seuraava:
A esittää väitteen B;
Esittäjässä A on jotain positiivista/negatiivista,
siispä väite B on tosi/epätosi."

Eli kun sanoit tehneesi 1970-luvulta lähtien tietokoneohjelmia lähes kaikilla kielillä.




"O sancta simplicitas (voi pyhä yksinkertaisuus!) ovat teologi Jan Husin viimeiset sanat, kun hänet vuonna 1415 poltettiin roviolla Konstanzin kirkolliskokouksessa. Hus lausui sanat nähdessään yksinkertaisen maalaismummon kantavan puita rovioon. Sanat ovat myös antaneet nimen argumentaatiovirheelle, jossa vedotaan yksinkertaisuuteen ja "maalaisjärkeen" ja yritetään esittää vasta-argumentin esittäjä elämästä vieraantuneeksi nörtiksi. Tämän argumentaation yleinen kaava on:
Henkilö X edustaa ihmistyyppiä P ja henkilö Y ihmistyyppiä Q
Henkilö X esittää argumentin A
Henkilö Y esittää, että ihmistyyppi P on elämästä vieraantunut viisasteleva nörtti ja tyyppi Q edustaa totuutta
Siispä argumentti A on epätosi"

Eli kun sanoit minun olevan "pilkun nysvääjäksi" ja että "nysvään rivien välitkin".


"Savuverho (englanniksi Red herring) on argumentaatiovirhe, joka liittyy asian vierestä puhumiseen. Siinä tarkoitus on ikään kuin luoda verbaalinen savuverho, joka harhauttaa keskustelun sivupoluille niin, että argumentoijan alkuperäinen argumentti jää kohtaamatta."

Delphi on nopea! kirjoitti:

On aika jo tajuta että Delphi on ollut jo kauan nopea. Ai miksikö . Siinä on optimoiva kääntäjä ollut jo iät ja ajat!!


Eli miksiköhän Delphi voi hakata jopa assemblerin?
vastaus tuli jo kerrottua. Eli Delphin nopea optimoiva kääntäjä (mieti sitä)!


Mitä Delphin nopea kääntäjä sitten tekee. Tässä esimerkki eli jos kerrot luvun kahdella niin Delphin kääntäjä tekee yhteenlaskun kyseisen luvun kanssa (koska yhteenlasku on nopeampi kuin kertolasku). No entäpä jos luku jolla kerrotaan onkin neljä niin delphi teekee pari bitin siirrosta koska se on tässä tapauksessa nopein!
Eli tuotettva Delphi koodi on todellakin optimoitua (eli niinkuin kerroin niin tuotettava konekoodi pohjautuu pascal-kielisen lähdekoodin analysointiin)

Lue lisää

Esimerkkisi ei voi pitää paikkaansa.

Jos numeron kertominen 4:llä tehdään kahdella bitinsiirrolla, miksi kertomista 2:lla ei tehdä yhden bitin siirrolla?

Lisäksi Intel suosittelee käyttämään bitinsiirron tilalta ynnäystä: Shifts, rotations: Avoid if possible, schedule dependent instructions as far away as possible; replace shl with additions http://www.intel.com/cd/ids/developer/asmo-na/eng/44010.htm?prn=Y

Käskyt ADD ja SHL vievät molemmat yhden kellopulssin (tosin ADD-käskyllä siihen vaikuttaa missä olevat luvut ynnätään).

Pentium-prosessori voi suorittaa 2 käskyä yhtäaikaa liukuhihnaperitaatteella http://www.dc.turkuamk.fi/titem/tite_modernit.pdf
joten optimoinnissa olisi oleellista että käskyt on niin järjestetty että prosessori pystyy ennustamaan suoritettavat käskyt oikein. Lisäksi tietysti se että pidetään rekistereissä ne muuttujat joita joudutaan käyttämään. Tuolta osin kääntäjä on vaikeassa asemassa, koska sen pitäisi pystyä ennustamaan ohjelman suoritusta ja se tekisi käännöksestä hidasta. Osin tuo tietysti on mahdotonta, sillä kääntäjä ei voi tietää millä arvoilla koodia tullaan suorittamaan ja mistä kohdin haaraudutaan.

Tuolla sivulla lukee näin:
"Koska Intelin alkuperäisessä arkkitehtuurissa ei ole paljoa rekistereita, voi niiden käyttö peräkkäisissä käskyissä johtaa tilanteisiin joissa ei suoritusjärjestyksen muuttaminen ole mahdollista kirjoittamatta toisen käskyn tiedon päälle, tarvitaan vielä lisärekistereitä. Ongelman ratkaisuksi on 40 yleiskäyttöistä rekisteriä, joita käytetään todellisissa laskuissa."

Minä ymmärrän nuo 40 yleiskäyttöistä rekisteriä prosessorin sisäisiksi, jolloin ohjelmakoodi ei edes voisi niitä käyttää vaan prosessori itse käyttää niitä ennusteensa mukaan nopeuttamaan suoritusta. Joka tapauksessa koska prosessori ennustaa itse asioita ja hylkää väärin ennustamiaan suoritusjärjestyksiä (=tuloksia), niin ohjelmakääntäjän ja edes konekieliohjelmoijan on mahdotonta tehdä täysin optimoitua koodia kuten vanhoissa yksinkertaisesti toimivissa prosessoreissa voitiin tehdä (tosin i/o-toimintojen nopeutta ei silloinkaan pystytty ennustamaan).


Minä en kiellä etteikö Delphi tekisi nopeampaa suoritettavaa koodia kuin Visual Basic. Minua vain ärsyttää että jotkut pitävät joitain ohjelmointikieliä uskontona, eivätkä hyväksy niihin kohdistuvaa perusteltua kritiikkiä.

xxxxx kirjoitti:

Esimerkkisi ei voi pitää paikkaansa.

Jos numeron kertominen 4:llä tehdään kahdella bitinsiirrolla, miksi kertomista 2:lla ei tehdä yhden bitin siirrolla?

Lisäksi Intel suosittelee käyttämään bitinsiirron tilalta ynnäystä: Shifts, rotations: Avoid if possible, schedule dependent instructions as far away as possible; replace shl with additions http://www.intel.com/cd/ids/developer/asmo-na/eng/44010.htm?prn=Y

Käskyt ADD ja SHL vievät molemmat yhden kellopulssin (tosin ADD-käskyllä siihen vaikuttaa missä olevat luvut ynnätään).

Pentium-prosessori voi suorittaa 2 käskyä yhtäaikaa liukuhihnaperitaatteella http://www.dc.turkuamk.fi/titem/tite_modernit.pdf
joten optimoinnissa olisi oleellista että käskyt on niin järjestetty että prosessori pystyy ennustamaan suoritettavat käskyt oikein. Lisäksi tietysti se että pidetään rekistereissä ne muuttujat joita joudutaan käyttämään. Tuolta osin kääntäjä on vaikeassa asemassa, koska sen pitäisi pystyä ennustamaan ohjelman suoritusta ja se tekisi käännöksestä hidasta. Osin tuo tietysti on mahdotonta, sillä kääntäjä ei voi tietää millä arvoilla koodia tullaan suorittamaan ja mistä kohdin haaraudutaan.

Tuolla sivulla lukee näin:
"Koska Intelin alkuperäisessä arkkitehtuurissa ei ole paljoa rekistereita, voi niiden käyttö peräkkäisissä käskyissä johtaa tilanteisiin joissa ei suoritusjärjestyksen muuttaminen ole mahdollista kirjoittamatta toisen käskyn tiedon päälle, tarvitaan vielä lisärekistereitä. Ongelman ratkaisuksi on 40 yleiskäyttöistä rekisteriä, joita käytetään todellisissa laskuissa."

Minä ymmärrän nuo 40 yleiskäyttöistä rekisteriä prosessorin sisäisiksi, jolloin ohjelmakoodi ei edes voisi niitä käyttää vaan prosessori itse käyttää niitä ennusteensa mukaan nopeuttamaan suoritusta. Joka tapauksessa koska prosessori ennustaa itse asioita ja hylkää väärin ennustamiaan suoritusjärjestyksiä (=tuloksia), niin ohjelmakääntäjän ja edes konekieliohjelmoijan on mahdotonta tehdä täysin optimoitua koodia kuten vanhoissa yksinkertaisesti toimivissa prosessoreissa voitiin tehdä (tosin i/o-toimintojen nopeutta ei silloinkaan pystytty ennustamaan).


Minä en kiellä etteikö Delphi tekisi nopeampaa suoritettavaa koodia kuin Visual Basic. Minua vain ärsyttää että jotkut pitävät joitain ohjelmointikieliä uskontona, eivätkä hyväksy niihin kohdistuvaa perusteltua kritiikkiä.

Lue lisää

Delphissä on CPU-ikkuna josta voi katsoa käännöstä ja joskus katsoin juuri tuon.

Eli
- kun Pascal-koodissa kerrottiin kahdella suoritettiin yhteenlasku itsensä kanssa.
- kun Pascal-koodissa kerrottiin neljällä siirrettiin bittejä

Delphi on nopea! kirjoitti:

Delphissä on CPU-ikkuna josta voi katsoa käännöstä ja joskus katsoin juuri tuon.

Eli
- kun Pascal-koodissa kerrottiin kahdella suoritettiin yhteenlasku itsensä kanssa.
- kun Pascal-koodissa kerrottiin neljällä siirrettiin bittejä

Lue lisää

Voisitko laittaa Delphi-koodin tuosta ja sen osan konekielikäännöksen? Oikeastaan sinun olisi pitänyt laittaa se jo edelliseen vastaukseesi. Tietokoneohjelmoinnista keskusteltaessa minua ärsyttää väitteet joita ei voi tarkistaa, joten koodia kehiin.

Jos olet käyttänyt samaa kokonaislukumuuttujaa ensin yhteenlaskussa ja seuraavalla rivillä kertomisella 4:llä, niin silloin tuo voisi olla ymmärrettävää kun muuttuja on jo rekisterissä. Mutta jos teit noin, niin osoittaa että Delphi ei optimoinut laskentaa kertomalla sitä suoraan 8:lla.

Bittien siirtoa voidaan käyttää kertomisessa vain kokonaisluvuilla ja se on muutenkin nopeaa. Oleellisempaa useissa ohjelmissa on se, kuinka käsitellään liukulukulaskentaa ja dynaamisia merkkijonoja.

Testasin aikoinani Basicilla eri käskyjen nopeuksia. Esim. kokonaislukuluuppi For i=1 to 10000:next suoritettiin heti, mutta kun väliin lisättiin a=i:b=a, niin sitten se hidastui. Eli oleellista on se pystyykö prosessori pitämään käytetyt arvot rekistereissä.

xxxxx kirjoitti:

"..ehkä siksi että pascal kieli alunperin kehitettiin c:n opettelukieleksi."

Ei Pascalia kehitetty c:n opettelukieleksi (en luokittele teoreettisia metakieliä ohjelmointikieliksi kun niillä ei ohjelmia voi tehdä). Ensimmäinen pascal-kieli kehitettiin joskus 1950-luvulla ja c-kieli vasta 1970-luvulla.

Ei kai mitään ohjelmointikieltä ole tehty vartavasten toisen kielen opettelua varten. Pascal tehtiin varsin taipumattomaksi ja loogisesti selkeäksi. Tämä lisäsi sen käyttöä opetuksessa.

Kun joskus 1980-luvulla tutustuin UCSD-Pascaliin, niin MS-Basiciin verrattuna se oli turhan kankea.

Jotenkin ihmetyttää nämä asenteelliset tekstit eri kielien paremmuudesta. Ne jotka niitä käyvät eivät ilmeisesti ole juurikaan tehneet tietokoneohjelmia. Kyllä nykyiset kehittimet mahdollistavat helpon monimutkaisen ohjelmoinnin, mutta huono ohjelmoija tekee huonoa koodia kaikilla kehittimillä.

Lue lisää

>...asenteelliset tekstit eri kielien paremmuudesta.

Näitä kirjoittelee sellaiset joilla ei ole syvempää näkemystä sovelluskehityksestä vaan sellainen käsitys että ohjelmoinnin tärkeimpiä asioita on se millä kielellä projektin tuotos lopulta koodataan.

xxxxx kirjoitti:

Voisitko laittaa Delphi-koodin tuosta ja sen osan konekielikäännöksen? Oikeastaan sinun olisi pitänyt laittaa se jo edelliseen vastaukseesi. Tietokoneohjelmoinnista keskusteltaessa minua ärsyttää väitteet joita ei voi tarkistaa, joten koodia kehiin.

Jos olet käyttänyt samaa kokonaislukumuuttujaa ensin yhteenlaskussa ja seuraavalla rivillä kertomisella 4:llä, niin silloin tuo voisi olla ymmärrettävää kun muuttuja on jo rekisterissä. Mutta jos teit noin, niin osoittaa että Delphi ei optimoinut laskentaa kertomalla sitä suoraan 8:lla.

Bittien siirtoa voidaan käyttää kertomisessa vain kokonaisluvuilla ja se on muutenkin nopeaa. Oleellisempaa useissa ohjelmissa on se, kuinka käsitellään liukulukulaskentaa ja dynaamisia merkkijonoja.

Testasin aikoinani Basicilla eri käskyjen nopeuksia. Esim. kokonaislukuluuppi For i=1 to 10000:next suoritettiin heti, mutta kun väliin lisättiin a=i:b=a, niin sitten se hidastui. Eli oleellista on se pystyykö prosessori pitämään käytetyt arvot rekistereissä.

Lue lisää

Vaikka en mitään tiedäkkään, ja sinä varmaan tiedätkin, mutta jos for looppi on tyhjä tai muuten turha niin ainakin C kääntäjä poistaa moiset.

Joku__ kirjoitti:

Vaikka en mitään tiedäkkään, ja sinä varmaan tiedätkin, mutta jos for looppi on tyhjä tai muuten turha niin ainakin C kääntäjä poistaa moiset.

En ole paljonkaan ohjelmoinnut c:llä enkä yhtään c :lla. Nykyään en muutenkaan enää ole juuri testannut eri tavalla kirjoitetun koodin nopeutta ja sillä tavoin saada ohjelmiini lisää vauhtia.

Itse teen ohjelmat VB:llä. Aloittaessani sillä joskus 1995, niin koodi oli kyllä hidasta. Etenkin kun silloin päätin aloittaa tyhjästä unohtaen vanhojen merkkipohjaisten ohjelmien koodit. Pidin tärkeämpänä että ohjelmien ylläpito käy sujuvasti ja ajattelin että koneet kuitenkin jatkuvasti nopeutuvat. Ohjelmissani välitin parametreita dynaamisissa merkkijonoissa tähän tapaan: "Toiminto=4|Tulostustapa=Esikatselu|TarranMuoto=Osoitetarra". Tuo oli hidasta, mutta se mahdollisti parametrien lisäyksen ilman että vanhoja aliohjelmakutsuja täytyi muuttaa. Lisäksi tuo mahdollisti ulkopuoliselle aliohjelmallekin kutsun pääohjelmaan ja aliohjelmien välillä niin että parametrit välittyivät automaattisesti mukana. Joku mainitsi äskettäin että PHP-kielessä toimitaan samoin, mutta siitä en tiedä sen enempää. Olen pitänyt tapaa erittäin kätevänä ja ohjelmiani helposti ylläpidettävinä.

Harvoissa ohjelmissa aika enää on kyseenalainen, kun laajatkin toiminnot käyvät sekunneissa.

Tässä oli vähän tilitystä siitä, miksi ärsyynnyn kun jotkut puhuvat epäoleellisia asioita. Tietenkään tämä teksti ei liity sinuun millään tavalla, vaan niihin jotka esiintyvät suurinakin asiantuntijoita ilman että pystyvät perustelemaan väitteitään.

Kuten tuossa alempana joku mainitsi, niin ei ole tärkeää millä ohjelmointikielellä ohjelma tehdään, kunhan se on hyvä loppukäyttäjälle.

xxxxx kirjoitti:

Voisitko laittaa Delphi-koodin tuosta ja sen osan konekielikäännöksen? Oikeastaan sinun olisi pitänyt laittaa se jo edelliseen vastaukseesi. Tietokoneohjelmoinnista keskusteltaessa minua ärsyttää väitteet joita ei voi tarkistaa, joten koodia kehiin.

Jos olet käyttänyt samaa kokonaislukumuuttujaa ensin yhteenlaskussa ja seuraavalla rivillä kertomisella 4:llä, niin silloin tuo voisi olla ymmärrettävää kun muuttuja on jo rekisterissä. Mutta jos teit noin, niin osoittaa että Delphi ei optimoinut laskentaa kertomalla sitä suoraan 8:lla.

Bittien siirtoa voidaan käyttää kertomisessa vain kokonaisluvuilla ja se on muutenkin nopeaa. Oleellisempaa useissa ohjelmissa on se, kuinka käsitellään liukulukulaskentaa ja dynaamisia merkkijonoja.

Testasin aikoinani Basicilla eri käskyjen nopeuksia. Esim. kokonaislukuluuppi For i=1 to 10000:next suoritettiin heti, mutta kun väliin lisättiin a=i:b=a, niin sitten se hidastui. Eli oleellista on se pystyykö prosessori pitämään käytetyt arvot rekistereissä.

Lue lisää

Voit kokeilla tutkia itse:
http://www.borland.com/us/products/delphi/index.html

xxxxx kirjoitti:

Voisitko laittaa Delphi-koodin tuosta ja sen osan konekielikäännöksen? Oikeastaan sinun olisi pitänyt laittaa se jo edelliseen vastaukseesi. Tietokoneohjelmoinnista keskusteltaessa minua ärsyttää väitteet joita ei voi tarkistaa, joten koodia kehiin.

Jos olet käyttänyt samaa kokonaislukumuuttujaa ensin yhteenlaskussa ja seuraavalla rivillä kertomisella 4:llä, niin silloin tuo voisi olla ymmärrettävää kun muuttuja on jo rekisterissä. Mutta jos teit noin, niin osoittaa että Delphi ei optimoinut laskentaa kertomalla sitä suoraan 8:lla.

Bittien siirtoa voidaan käyttää kertomisessa vain kokonaisluvuilla ja se on muutenkin nopeaa. Oleellisempaa useissa ohjelmissa on se, kuinka käsitellään liukulukulaskentaa ja dynaamisia merkkijonoja.

Testasin aikoinani Basicilla eri käskyjen nopeuksia. Esim. kokonaislukuluuppi For i=1 to 10000:next suoritettiin heti, mutta kun väliin lisättiin a=i:b=a, niin sitten se hidastui. Eli oleellista on se pystyykö prosessori pitämään käytetyt arvot rekistereissä.

Lue lisää

Pascalin liukulukualueet:
Tietotyyppi...Selitys...Koko(bitteinä)...Arvoalue
Single...pieni liukuluku...32...1.5E-45->3.4E38
Double...liukuluku...64...5.0E-324->1.7E308
Extended...laajennettu liukuluku...80...1.9E-4951->1.1E4952

liukulukualueet kirjoitti:

Pascalin liukulukualueet:
Tietotyyppi...Selitys...Koko(bitteinä)...Arvoalue
Single...pieni liukuluku...32...1.5E-45->3.4E38
Double...liukuluku...64...5.0E-324->1.7E308
Extended...laajennettu liukuluku...80...1.9E-4951->1.1E4952

Lue lisää

Niin, entä sitten?

Kokeile kirjoitti:

Voit kokeilla tutkia itse:
http://www.borland.com/us/products/delphi/index.html

Lue lisää

Jos jollain on Delphi koneessa ja se näyttää konekielikäännöksen viereisessä ikkunassa, niin hänellä tuohon olisi mennyt pari minuuttia.

En minä ole käyttänyt Delphiä, joten miksi minä sitä testaisin? Nimimerkki "Delphi on nopea" kehui Delphin optimoivaa kääntäjää muutamalla väitteellä ja minä kumosin hänen väitteensä.

Jos minä esitän väitteen Visual Basic -koodista, niin silloin minä tietysti kerroin kyseisen ohjelmakoodin ja siltä osin selvitän asiaa.

On varsin ääliömäistä esittää minulle, että tuon takia lataisin Delphin demon ja sitten monta tuntia selvittäisin kuinka saan asiaa kokeiltua kun Delphi-taiturin pitäisi pystyä testaamaan sitä parissa minuutissa. Ja nimimerkki "Delphi on nopea" oli pakosta omasta mielestään asiantuntija, sillä ei kai hän muuten olisi heittänyt kommenttia millaista koodia Delphi konekielellä tekee ja kehunut Delphin optimoivaa kääntäjää.

xxxxx kirjoitti:

Voisitko laittaa Delphi-koodin tuosta ja sen osan konekielikäännöksen? Oikeastaan sinun olisi pitänyt laittaa se jo edelliseen vastaukseesi. Tietokoneohjelmoinnista keskusteltaessa minua ärsyttää väitteet joita ei voi tarkistaa, joten koodia kehiin.

Jos olet käyttänyt samaa kokonaislukumuuttujaa ensin yhteenlaskussa ja seuraavalla rivillä kertomisella 4:llä, niin silloin tuo voisi olla ymmärrettävää kun muuttuja on jo rekisterissä. Mutta jos teit noin, niin osoittaa että Delphi ei optimoinut laskentaa kertomalla sitä suoraan 8:lla.

Bittien siirtoa voidaan käyttää kertomisessa vain kokonaisluvuilla ja se on muutenkin nopeaa. Oleellisempaa useissa ohjelmissa on se, kuinka käsitellään liukulukulaskentaa ja dynaamisia merkkijonoja.

Testasin aikoinani Basicilla eri käskyjen nopeuksia. Esim. kokonaislukuluuppi For i=1 to 10000:next suoritettiin heti, mutta kun väliin lisättiin a=i:b=a, niin sitten se hidastui. Eli oleellista on se pystyykö prosessori pitämään käytetyt arvot rekistereissä.

Lue lisää

Ikävä kyllä minulla ei ole nyt Delphiä käsillä mutta
voinet testata saman asian itsekin esim. hankkimalla Delphin kokeiluversion. Samalla voit testata monta muutakin asiaa (ihan mitä haluat)

xxxxx kirjoitti:

Niin, entä sitten?

"Oleellisempaa useissa ohjelmissa on se, kuinka käsitellään liukulukulaskentaa"

On kai sillä merkitystä miten montako muistitavua yksi liukuluku vie.
Eli Single vie 4 tavua, Double vie 8 tavua ja Extended vie 10 tavua.
Se mitä liukulukua noista käytetään vaikuttaa myös siihen millä tarkkuudella
lasketaan. Eli mikä on riittävä tarkkuus.

Eli tästä voit jo päätellä miten paljon Pascal antaa mahdollisuuksia
vaikuttaa liukulukulaskentaan.

liukulukualueet kirjoitti:

"Oleellisempaa useissa ohjelmissa on se, kuinka käsitellään liukulukulaskentaa"

On kai sillä merkitystä miten montako muistitavua yksi liukuluku vie.
Eli Single vie 4 tavua, Double vie 8 tavua ja Extended vie 10 tavua.
Se mitä liukulukua noista käytetään vaikuttaa myös siihen millä tarkkuudella
lasketaan. Eli mikä on riittävä tarkkuus.

Eli tästä voit jo päätellä miten paljon Pascal antaa mahdollisuuksia
vaikuttaa liukulukulaskentaan.

Lue lisää

Single- ja Double-liukuluvut nyt taitavat olla kaikissa ohjelmointikielissä. Visual Basicissa on lisäksi 16 tavun Desimaaliluku stores floating-point values from -79,228,000,000,000,000,000,000,000,000 to 79,228,000,000,000,000,000,000,000,000 http://en.wikibooks.org/wiki/Visual_Basic_.NET/Variables

Kaikkihan sen tietää, että Single-luvun lukualue ei ole riittävä esim. eurojen laskentaan.

Kun hain tuohon liittyviä sivuja, niin minua yllätti että Double olisi ilmeisesti nopeampi kuin Single koska prosessori käyttää sitä tyyppiä:
Double is the most efficient of the fractional data types, because the processors on current platforms perform floating-point operations in double precision. However, operations with Double are not as fast as with the integral types such as Integer. http://msdn2.microsoft.com/en-us/library/ae55hdtk.aspx


Jos sinä olit tosissasi että vastauksesi kuuluu tähän tekstiketjuun tuoden lisäselvyyttä johonkin, niin se todella tarkoittaa vain sitä, että sinä olet vasta aloittanut Pascalin opiskelun ja lukenut manuaalista ensimmäiset 10 sivua.

Delphi on nopea! kirjoitti:

Ikävä kyllä minulla ei ole nyt Delphiä käsillä mutta
voinet testata saman asian itsekin esim. hankkimalla Delphin kokeiluversion. Samalla voit testata monta muutakin asiaa (ihan mitä haluat)

Lue lisää

Kerro miten voin testata alkuperäisen Delphi-koodin kun jo ylempänä kysyin sinulta missä järjestyksessä laskenta oli suoritettu?

Eli toistan asian nyt yksinkertaisesti:

1) Sinä sanoit että Delphi optimoi koodin käännön konekielelle, mutta et kertonut edes alkuperäistä koodia ja konekielikoodistakin kerroit ylimalkaisesti vain muutaman käskyn.
Sanoit tuossa ylempänä näin: "Tässä esimerkki eli jos kerrot luvun kahdella niin Delphin kääntäjä tekee yhteenlaskun kyseisen luvun kanssa (koska yhteenlasku on nopeampi kuin kertolasku). No entäpä jos luku jolla kerrotaan onkin neljä niin delphi teekee pari bitin siirrosta koska se on tässä tapauksessa nopein!
Eli tuotettva Delphi koodi on todellakin optimoitua (eli niinkuin kerroin niin tuotettava konekoodi pohjautuu pascal-kielisen lähdekoodin analysointiin)"

2) Minä sanoin että tuskin tekee mainitsemallasi tavalla ja perustelin väitteeni.

3) Sinä vänkäsit vastaan ylimalkaisilla selittelyillä.

4) Minä mietin mahdollisia vaihtoehtoja miksi se tekisi noin ja vaadin sinua esittämään Delphi-koodin ja koodia vastaavan konekielikoodin.

5) Nyt viimeisessä vastauksessasi sanot ettei sinulla ole Delphiä ja että minä voin hankkia siitä kokeiluversion. Miksi et itse hanki siitä kokeiluversiota kun tiedät miten se toimii? Vai etkö ole edes ikinä käyttänyt Delphiä? Miten minä voin todeta sinun väitteesi kun et ole edes kertonut alkuperäistä Delphi-koodiasi?

6) En minä halua testata Delphiä. Sinä esitit alkuperäisen väitteen Delphin optimoidusta kääntäjästä, ja tuon väitteen minä kumosin.

7) Älä sinä älköönkä ketään muukaan kehuko ohjelmointikieltä jota eivät tunne alkuunkaan.

Miksi sinä ja jotkut muutkin tässä kirjoitusketjussa vänkäsivät ja vänkäävät vastaan ilman tarkkoja tosia? Ilman tietoa ohjelmoinnista tai ohjelmointikielistä?

xxxxx kirjoitti:

Single- ja Double-liukuluvut nyt taitavat olla kaikissa ohjelmointikielissä. Visual Basicissa on lisäksi 16 tavun Desimaaliluku stores floating-point values from -79,228,000,000,000,000,000,000,000,000 to 79,228,000,000,000,000,000,000,000,000 http://en.wikibooks.org/wiki/Visual_Basic_.NET/Variables

Kaikkihan sen tietää, että Single-luvun lukualue ei ole riittävä esim. eurojen laskentaan.

Kun hain tuohon liittyviä sivuja, niin minua yllätti että Double olisi ilmeisesti nopeampi kuin Single koska prosessori käyttää sitä tyyppiä:
Double is the most efficient of the fractional data types, because the processors on current platforms perform floating-point operations in double precision. However, operations with Double are not as fast as with the integral types such as Integer. http://msdn2.microsoft.com/en-us/library/ae55hdtk.aspx


Jos sinä olit tosissasi että vastauksesi kuuluu tähän tekstiketjuun tuoden lisäselvyyttä johonkin, niin se todella tarkoittaa vain sitä, että sinä olet vasta aloittanut Pascalin opiskelun ja lukenut manuaalista ensimmäiset 10 sivua.

Lue lisää

Tähän väliin että

valuutan laskemiseen on oma tyyppi Delphissä:
- Currency

http://www.delphibasics.co.uk/RTL.asp?Name=Currency

xxxxx kirjoitti:

Single- ja Double-liukuluvut nyt taitavat olla kaikissa ohjelmointikielissä. Visual Basicissa on lisäksi 16 tavun Desimaaliluku stores floating-point values from -79,228,000,000,000,000,000,000,000,000 to 79,228,000,000,000,000,000,000,000,000 http://en.wikibooks.org/wiki/Visual_Basic_.NET/Variables

Kaikkihan sen tietää, että Single-luvun lukualue ei ole riittävä esim. eurojen laskentaan.

Kun hain tuohon liittyviä sivuja, niin minua yllätti että Double olisi ilmeisesti nopeampi kuin Single koska prosessori käyttää sitä tyyppiä:
Double is the most efficient of the fractional data types, because the processors on current platforms perform floating-point operations in double precision. However, operations with Double are not as fast as with the integral types such as Integer. http://msdn2.microsoft.com/en-us/library/ae55hdtk.aspx


Jos sinä olit tosissasi että vastauksesi kuuluu tähän tekstiketjuun tuoden lisäselvyyttä johonkin, niin se todella tarkoittaa vain sitä, että sinä olet vasta aloittanut Pascalin opiskelun ja lukenut manuaalista ensimmäiset 10 sivua.

Lue lisää

Olio-ohjelmointikielissä joissa on operator -niminen (tapainen) metodi (löytyy mm Pascal:sta, C :sta jne) on mahdollisuus sitä hyväksikäyttäen tehdä vaikka kuinka isot (tai sopivat) lukualueet. Itse koodissa sen käyttö on samanlaista kuin tavallistenkin tyyppien. Tosin tämä kirjasto joudutaan joko koodaamaan (tekemään) itse tai sitten hankkimaan jostakin.

xxxxx kirjoitti:

En ole paljonkaan ohjelmoinnut c:llä enkä yhtään c :lla. Nykyään en muutenkaan enää ole juuri testannut eri tavalla kirjoitetun koodin nopeutta ja sillä tavoin saada ohjelmiini lisää vauhtia.

Itse teen ohjelmat VB:llä. Aloittaessani sillä joskus 1995, niin koodi oli kyllä hidasta. Etenkin kun silloin päätin aloittaa tyhjästä unohtaen vanhojen merkkipohjaisten ohjelmien koodit. Pidin tärkeämpänä että ohjelmien ylläpito käy sujuvasti ja ajattelin että koneet kuitenkin jatkuvasti nopeutuvat. Ohjelmissani välitin parametreita dynaamisissa merkkijonoissa tähän tapaan: "Toiminto=4|Tulostustapa=Esikatselu|TarranMuoto=Osoitetarra". Tuo oli hidasta, mutta se mahdollisti parametrien lisäyksen ilman että vanhoja aliohjelmakutsuja täytyi muuttaa. Lisäksi tuo mahdollisti ulkopuoliselle aliohjelmallekin kutsun pääohjelmaan ja aliohjelmien välillä niin että parametrit välittyivät automaattisesti mukana. Joku mainitsi äskettäin että PHP-kielessä toimitaan samoin, mutta siitä en tiedä sen enempää. Olen pitänyt tapaa erittäin kätevänä ja ohjelmiani helposti ylläpidettävinä.

Harvoissa ohjelmissa aika enää on kyseenalainen, kun laajatkin toiminnot käyvät sekunneissa.

Tässä oli vähän tilitystä siitä, miksi ärsyynnyn kun jotkut puhuvat epäoleellisia asioita. Tietenkään tämä teksti ei liity sinuun millään tavalla, vaan niihin jotka esiintyvät suurinakin asiantuntijoita ilman että pystyvät perustelemaan väitteitään.

Kuten tuossa alempana joku mainitsi, niin ei ole tärkeää millä ohjelmointikielellä ohjelma tehdään, kunhan se on hyvä loppukäyttäjälle.

Lue lisää

Pascal:ssa kuten Delphi:ssä merkkijonojen käsittely on monipuolista.

Voit vaikkapa käyttää (tuohon tarkoitukseen)
TStringList tyyppiä

TStringList-tyyppiseen muuttujaan on esim. helppo
- lisätä (add-metodilla) uusia merkkijonoja,
- tyhjentää (clear-metodi) merkkijonoista,
- laskea (count-metodi) sen sisältämän merkkijonojen määrään,
- tallentaa tiedostoon ( SaveToFile(Tiedostonnimi) -metodi),
- voit sijoittaa sen minkä tahansa olion TStrings-ominaisuuteen
jne.

Joitakin esimerkkejä sen käytöstä löydät vaikkapa:

http://www.delphibasics.co.uk/RTL.asp?Name=TStringList

xxxxx kirjoitti:

Kerro miten voin testata alkuperäisen Delphi-koodin kun jo ylempänä kysyin sinulta missä järjestyksessä laskenta oli suoritettu?

Eli toistan asian nyt yksinkertaisesti:

1) Sinä sanoit että Delphi optimoi koodin käännön konekielelle, mutta et kertonut edes alkuperäistä koodia ja konekielikoodistakin kerroit ylimalkaisesti vain muutaman käskyn.
Sanoit tuossa ylempänä näin: "Tässä esimerkki eli jos kerrot luvun kahdella niin Delphin kääntäjä tekee yhteenlaskun kyseisen luvun kanssa (koska yhteenlasku on nopeampi kuin kertolasku). No entäpä jos luku jolla kerrotaan onkin neljä niin delphi teekee pari bitin siirrosta koska se on tässä tapauksessa nopein!
Eli tuotettva Delphi koodi on todellakin optimoitua (eli niinkuin kerroin niin tuotettava konekoodi pohjautuu pascal-kielisen lähdekoodin analysointiin)"

2) Minä sanoin että tuskin tekee mainitsemallasi tavalla ja perustelin väitteeni.

3) Sinä vänkäsit vastaan ylimalkaisilla selittelyillä.

4) Minä mietin mahdollisia vaihtoehtoja miksi se tekisi noin ja vaadin sinua esittämään Delphi-koodin ja koodia vastaavan konekielikoodin.

5) Nyt viimeisessä vastauksessasi sanot ettei sinulla ole Delphiä ja että minä voin hankkia siitä kokeiluversion. Miksi et itse hanki siitä kokeiluversiota kun tiedät miten se toimii? Vai etkö ole edes ikinä käyttänyt Delphiä? Miten minä voin todeta sinun väitteesi kun et ole edes kertonut alkuperäistä Delphi-koodiasi?

6) En minä halua testata Delphiä. Sinä esitit alkuperäisen väitteen Delphin optimoidusta kääntäjästä, ja tuon väitteen minä kumosin.

7) Älä sinä älköönkä ketään muukaan kehuko ohjelmointikieltä jota eivät tunne alkuunkaan.

Miksi sinä ja jotkut muutkin tässä kirjoitusketjussa vänkäsivät ja vänkäävät vastaan ilman tarkkoja tosia? Ilman tietoa ohjelmoinnista tai ohjelmointikielistä?

Lue lisää

Mitähän tähän vastaisi muuta kuin sen että
sinulle (ja muillekin jotka eivät ole tutustuneet Delphiin)
niin sitä kannattaisi kokeilla.

Tekemällä näin avarrat omia käsityksiäsi ja opit uusia asioita.
Voit puhua omista kokemuksista (jolloin ei tarvitse käyttää toisen "käden" tietoa).
Todennäköisesti tästä tekemisestä on hyötyä työssäsi. Kun osaat käyttää muitakin kieliä niin saat sen lisän ansiolistaasi.

Lazarus. kirjoitti:

Olio-ohjelmointikielissä joissa on operator -niminen (tapainen) metodi (löytyy mm Pascal:sta, C :sta jne) on mahdollisuus sitä hyväksikäyttäen tehdä vaikka kuinka isot (tai sopivat) lukualueet. Itse koodissa sen käyttö on samanlaista kuin tavallistenkin tyyppien. Tosin tämä kirjasto joudutaan joko koodaamaan (tekemään) itse tai sitten hankkimaan jostakin.

Lue lisää

Kyllähän omat lukualueet (vaikka 5000 tavua) voi tehdä kiinteämittaisella merkkijonolla, kunhan laskentafunktion (ja numerojen pakkauksen) tekee itse tai käyttää valmiita kirjastoja.

Ymmärsin viestistäsi että ei se tuon helpommalla onnistu Pascalissa, C :ssa tai Lazaruksessakaan.

xxxxx kirjoitti:

Kyllähän omat lukualueet (vaikka 5000 tavua) voi tehdä kiinteämittaisella merkkijonolla, kunhan laskentafunktion (ja numerojen pakkauksen) tekee itse tai käyttää valmiita kirjastoja.

Ymmärsin viestistäsi että ei se tuon helpommalla onnistu Pascalissa, C :ssa tai Lazaruksessakaan.

Lue lisää

Tarkoitin sitä että operator-metodia hyväksi käyttäen pystytään tekemään sellainen oma tyyppi että sen vaihto lähdekoodiin on samanlaista kuin Doublen vaihto Singleksi.

Suosittelen seuraavan askeleen ottamista ja siirtymistä Pascaliin. Pascal on erittäin hyvä aloituskieli ja siinä ei ominaisuudet lopu heti kättelyssä (C ssa on turhan helppo ottaa harha-askelia). Eli olet aikamoinen ohjelmointi guru jos hallitset Pascalin täydellisesti. Jos joskus tarvetta on niin Pascal:sta on helppo siirtyä C :n (osaat silloin luonnostaan pienen opettelun jälkeen tehdä hyvän C tyylin mukaista koodia. Hyvästä tyylistä sortuminen on iso ongelma c-koodissa).

Lazarus. kirjoitti:

Tarkoitin sitä että operator-metodia hyväksi käyttäen pystytään tekemään sellainen oma tyyppi että sen vaihto lähdekoodiin on samanlaista kuin Doublen vaihto Singleksi.

Suosittelen seuraavan askeleen ottamista ja siirtymistä Pascaliin. Pascal on erittäin hyvä aloituskieli ja siinä ei ominaisuudet lopu heti kättelyssä (C ssa on turhan helppo ottaa harha-askelia). Eli olet aikamoinen ohjelmointi guru jos hallitset Pascalin täydellisesti. Jos joskus tarvetta on niin Pascal:sta on helppo siirtyä C :n (osaat silloin luonnostaan pienen opettelun jälkeen tehdä hyvän C tyylin mukaista koodia. Hyvästä tyylistä sortuminen on iso ongelma c-koodissa).

Lue lisää

Eipä ole suuremmin ollut omille oliotyypeille tarvetta. Tuollaisten käytössä täytyy olla varovainen ettei tuo muutu itsetarkoitukseksi. Minulle on riittänyt normaalit muuttujatyypit.

Miksi suosittelet minulle seuraavan askeleen ottamista ja siirtymistä Pascaliin? Miksi kerrot minulle perusasioita Pascalista ja C :sta? Minä osaan Visual Basicin hyvin eikä ole järkevää alkaa opetella samantason kieltä. Joten ei ole mitään mieltä vaihtaa Pascaliin kun Pascal kuitenkin on suunnilleen samantyyppinen ohjelmointikieli kuin VB.

Tuo mainintasi, että hyvästä tyylistä sortuminen on iso ongelma c-koodissa pitää paikkaansa. Ohjelmakoodin selkeys on tärkeää. Siltä pohjaltakin kannattaa välttää liikaa muuttamasta ohjelmointikieltä vaikka operator-metodit, periytyvyys ja olit sen sallisivatkin. Eli parempi on pysyä perus koodaustavassa ilman kielen erityistoimintojen käyttöä. Tämän olen itsekin havainnut ohjelmoitaessa, että peruskoodia kannattaa vääntää ja sillä tavalla ratkaista ohjelmointiongelmat.

xxxxx kirjoitti:

Eipä ole suuremmin ollut omille oliotyypeille tarvetta. Tuollaisten käytössä täytyy olla varovainen ettei tuo muutu itsetarkoitukseksi. Minulle on riittänyt normaalit muuttujatyypit.

Miksi suosittelet minulle seuraavan askeleen ottamista ja siirtymistä Pascaliin? Miksi kerrot minulle perusasioita Pascalista ja C :sta? Minä osaan Visual Basicin hyvin eikä ole järkevää alkaa opetella samantason kieltä. Joten ei ole mitään mieltä vaihtaa Pascaliin kun Pascal kuitenkin on suunnilleen samantyyppinen ohjelmointikieli kuin VB.

Tuo mainintasi, että hyvästä tyylistä sortuminen on iso ongelma c-koodissa pitää paikkaansa. Ohjelmakoodin selkeys on tärkeää. Siltä pohjaltakin kannattaa välttää liikaa muuttamasta ohjelmointikieltä vaikka operator-metodit, periytyvyys ja olit sen sallisivatkin. Eli parempi on pysyä perus koodaustavassa ilman kielen erityistoimintojen käyttöä. Tämän olen itsekin havainnut ohjelmoitaessa, että peruskoodia kannattaa vääntää ja sillä tavalla ratkaista ohjelmointiongelmat.

Lue lisää

"Samantason kieltä"

Niin jos perusteena on vain helppokäyttöisyys.

xxxxx kirjoitti:

Eipä ole suuremmin ollut omille oliotyypeille tarvetta. Tuollaisten käytössä täytyy olla varovainen ettei tuo muutu itsetarkoitukseksi. Minulle on riittänyt normaalit muuttujatyypit.

Miksi suosittelet minulle seuraavan askeleen ottamista ja siirtymistä Pascaliin? Miksi kerrot minulle perusasioita Pascalista ja C :sta? Minä osaan Visual Basicin hyvin eikä ole järkevää alkaa opetella samantason kieltä. Joten ei ole mitään mieltä vaihtaa Pascaliin kun Pascal kuitenkin on suunnilleen samantyyppinen ohjelmointikieli kuin VB.

Tuo mainintasi, että hyvästä tyylistä sortuminen on iso ongelma c-koodissa pitää paikkaansa. Ohjelmakoodin selkeys on tärkeää. Siltä pohjaltakin kannattaa välttää liikaa muuttamasta ohjelmointikieltä vaikka operator-metodit, periytyvyys ja olit sen sallisivatkin. Eli parempi on pysyä perus koodaustavassa ilman kielen erityistoimintojen käyttöä. Tämän olen itsekin havainnut ohjelmoitaessa, että peruskoodia kannattaa vääntää ja sillä tavalla ratkaista ohjelmointiongelmat.

Lue lisää

Olisi hyvä tietää millä perusteella teet tuon päätelmän (eli mikä on jaotteluperusteesi. Mitä vertailet)?

xxxxx kirjoitti:

Eipä ole suuremmin ollut omille oliotyypeille tarvetta. Tuollaisten käytössä täytyy olla varovainen ettei tuo muutu itsetarkoitukseksi. Minulle on riittänyt normaalit muuttujatyypit.

Miksi suosittelet minulle seuraavan askeleen ottamista ja siirtymistä Pascaliin? Miksi kerrot minulle perusasioita Pascalista ja C :sta? Minä osaan Visual Basicin hyvin eikä ole järkevää alkaa opetella samantason kieltä. Joten ei ole mitään mieltä vaihtaa Pascaliin kun Pascal kuitenkin on suunnilleen samantyyppinen ohjelmointikieli kuin VB.

Tuo mainintasi, että hyvästä tyylistä sortuminen on iso ongelma c-koodissa pitää paikkaansa. Ohjelmakoodin selkeys on tärkeää. Siltä pohjaltakin kannattaa välttää liikaa muuttamasta ohjelmointikieltä vaikka operator-metodit, periytyvyys ja olit sen sallisivatkin. Eli parempi on pysyä perus koodaustavassa ilman kielen erityistoimintojen käyttöä. Tämän olen itsekin havainnut ohjelmoitaessa, että peruskoodia kannattaa vääntää ja sillä tavalla ratkaista ohjelmointiongelmat.

Lue lisää

Avainsana on olio-ohjelmointi. Pascal on myös täysverinen oliokieli (niinkuin on C ). Jos vertaat (nykyistä) Pascalia johonkin kieleen niin ekaksi (ainakin minulle) tulee mieleen C . Eräs suurimmista eroista on näiden välillä kirjoitusasu (vertaa esim. begin ja { ).

Suosittelen Pascalia siksi koska se on turvallisempi (aloittelijalle) kuin C . Verrattuna puhtaisiin oliokieliin niin pystyt Pascalilla aloittamaan olioihin tutustumisen halutessasi pienin harppauksin.

xxxxx kirjoitti:

Eipä ole suuremmin ollut omille oliotyypeille tarvetta. Tuollaisten käytössä täytyy olla varovainen ettei tuo muutu itsetarkoitukseksi. Minulle on riittänyt normaalit muuttujatyypit.

Miksi suosittelet minulle seuraavan askeleen ottamista ja siirtymistä Pascaliin? Miksi kerrot minulle perusasioita Pascalista ja C :sta? Minä osaan Visual Basicin hyvin eikä ole järkevää alkaa opetella samantason kieltä. Joten ei ole mitään mieltä vaihtaa Pascaliin kun Pascal kuitenkin on suunnilleen samantyyppinen ohjelmointikieli kuin VB.

Tuo mainintasi, että hyvästä tyylistä sortuminen on iso ongelma c-koodissa pitää paikkaansa. Ohjelmakoodin selkeys on tärkeää. Siltä pohjaltakin kannattaa välttää liikaa muuttamasta ohjelmointikieltä vaikka operator-metodit, periytyvyys ja olit sen sallisivatkin. Eli parempi on pysyä perus koodaustavassa ilman kielen erityistoimintojen käyttöä. Tämän olen itsekin havainnut ohjelmoitaessa, että peruskoodia kannattaa vääntää ja sillä tavalla ratkaista ohjelmointiongelmat.

Lue lisää

Teet selkeän koodin jossa käytät Single-tyyppisiä reaalilukuja. Sitten
muutat koodia niin että käytät Double-tyyppisiä lukuja. Muuttuiko koodin selkeys kun vaihdot eri tyyppiin ?

No joku kaveri antaa sinulle yhden tiedoston (palan koodia) ja sanoo että nyt voit muuttaa nuo doublet tripleksi.

Huomautan vielä tähän sen että ainakin Pascalissa ja C voi tehdä koodia niin että Single tyypin muutto Doubleksi (tai tripleksi) onnistuu haluttaessa vain yhdellä määrittelyllä (yksi koodirivi)

PooL kirjoitti:

Olisi hyvä tietää millä perusteella teet tuon päätelmän (eli mikä on jaotteluperusteesi. Mitä vertailet)?

No vaikka ohjelman lopputulosta, joka on kuitenkin tärkein peruste. Visual Basicilla ja Delphillä voi molemmilla tehdä hyviä ohjelmia. Toki räpellyksiäkin voi molemmilla tehdä.

Tässä kirjoitusketjussa olen perustellut asioita, mutta minulle vastaväitteitä esittävät heittävät vain yksittäisiä perustelemattomia kysymyksiä, joilla he ikään kuin asettavat minulle vaatimuksen kirjoittaa laajoja perusteluita. Perusteluita olen tässä kirjoitusketjussa paljon kirjoitellut ja eikö ne sitten sivuteta ja esitetä taas yksittäisiä lisäkysymyksiä.

Tuo edellinen viestisi on toinen tässä ketjussa. Edellisessä vain mainitsit että Delphissä on valuutan laskemiseen Currency-tyyppi. Niin on Visual Basicissakin http://www.ohjelmointiputka.net/opas.php?tunnus=vbo_2

Palataan vielä edelliseen kysymykseesi. Siihen voi lisätä esim. nämä: samantyyppiset muuttujat, molempia on kehitetty paljon, molemmat tekevät koodia parhaalle käyttöjärjestelmälle eli Microsoftin Windows XP:lle, molemmat on helppokäyttöisia. Noin. Siinä nyt samankaltaisuuksia.

Jos Visual Basicilla ja Delphillä on merkittäviä eroja, jotka estävät sen, että valmis ohjelma ei voi olla hyvä, niin kerro sinä tai joku muu niistä eroista. JA PERUSTELKAA VÄITTEENNE ETTETTE VAIN HEITÄ ETTÄ PAREMMUUS JOHTUU OLIOISTA TAI MUISTA UFOJUTUISTA, JOTKA OVAT VAIN TRIVIAALIA TYPERÄÄ VASTAANÄNKYTYSTÄ ETTEI VISUAL PEISIKILLÄ MUKA VOI TEHDÄ HYVIÄ OHJELMIA.

Lazarus. kirjoitti:

Avainsana on olio-ohjelmointi. Pascal on myös täysverinen oliokieli (niinkuin on C ). Jos vertaat (nykyistä) Pascalia johonkin kieleen niin ekaksi (ainakin minulle) tulee mieleen C . Eräs suurimmista eroista on näiden välillä kirjoitusasu (vertaa esim. begin ja { ).

Suosittelen Pascalia siksi koska se on turvallisempi (aloittelijalle) kuin C . Verrattuna puhtaisiin oliokieliin niin pystyt Pascalilla aloittamaan olioihin tutustumisen halutessasi pienin harppauksin.

Lue lisää

Kun sinä olet aloittelija olio-ohjelmoinnissa, niin miksi minun pitäisi aloittaa samalta alaportaalta sen opettelu kuin kaltaisesi muut ohjelmoinnista tietämättömät?

Väität erään suurimmista eroista C :n ja Pascalin välillä olevan kirjoitusasu (hakasulut begin). Olet väärässä. Paljon suurempi ero on esim. muistinkäsittely ja pointterit, jotka ainakin Delphissä on piilotettu käyttäjältä.

Toki vastauksesi on ymmärrettävää silloin kun on vasta lukenut molempien (C :n ja Pascalin) manuaaleista ensimmäiset 10 sivua, jolloin on vasta käsitelty kielten perusasioiden kirjoitusasu.

Mihin olio-ohjelmointi on avainsana?

Lazarus. kirjoitti:

Teet selkeän koodin jossa käytät Single-tyyppisiä reaalilukuja. Sitten
muutat koodia niin että käytät Double-tyyppisiä lukuja. Muuttuiko koodin selkeys kun vaihdot eri tyyppiin ?

No joku kaveri antaa sinulle yhden tiedoston (palan koodia) ja sanoo että nyt voit muuttaa nuo doublet tripleksi.

Huomautan vielä tähän sen että ainakin Pascalissa ja C voi tehdä koodia niin että Single tyypin muutto Doubleksi (tai tripleksi) onnistuu haluttaessa vain yhdellä määrittelyllä (yksi koodirivi)

Lue lisää

Sinun tulisi tehdä yksi laajahko tietokoneohjelma. Suunnittele se ensin paperilla. Sitten koodaat sen. Myyt sen useille asiakkaille tai laitat vaikka ilmaiseksi nettiin. Ohjelmaasi käyttävät sitten esittävät parannusehdotuksia. Parannat ohjelmaasi.

Vähitellen alat ymmärtää mitä ohjelmointi tarkoittaa. Se tarkoittaa että loppukäyttäjän ohjelma on hyvä ja että ohjelman koodaajat pystyvät sitä helposti ylläpitämään.

Ohjelmointi ei ole triviaaleja takertumisia yksittäisiin asioihin. Niillä ei ole käytännön merkitystä ohjelmoinnin kannalta.

Edellinen viestisi on hyvä esimerkki triviaalista typeryydestä, kun mainitset että tyypin muutto onnistuu yhden rivin muutoksella. Tyyppien muunnoksia lopullisessa ohjelmassa tehdään tosi harvoin ja silloinkin täytyy käydä koodi niiltä osin läpi, jotta havaitaan aiheuttaako tyypin muutos ongelmia jollekin toiselle muuttujalla tai aliohjelmakutsulle. Olisikin hyvä että tekisit jonkin ohjelman, jotta ymmärtäisit välttää käytännön ohjelmointikeskustelussa triviaalit tapaukset muuten kuin piristämässä keskustelua.

xxxxx kirjoitti:

Kun sinä olet aloittelija olio-ohjelmoinnissa, niin miksi minun pitäisi aloittaa samalta alaportaalta sen opettelu kuin kaltaisesi muut ohjelmoinnista tietämättömät?

Väität erään suurimmista eroista C :n ja Pascalin välillä olevan kirjoitusasu (hakasulut begin). Olet väärässä. Paljon suurempi ero on esim. muistinkäsittely ja pointterit, jotka ainakin Delphissä on piilotettu käyttäjältä.

Toki vastauksesi on ymmärrettävää silloin kun on vasta lukenut molempien (C :n ja Pascalin) manuaaleista ensimmäiset 10 sivua, jolloin on vasta käsitelty kielten perusasioiden kirjoitusasu.

Mihin olio-ohjelmointi on avainsana?

Lue lisää

Ihan ensimmäisistä Pascal-toteutuksista lähtien on Pascalissa ollut pointterit ja muistin dynaaminen varaaminen. Löytyy myös nykyisistä toteutuksistakin. Tosin Pascal ei ole ollut koskaan noista "kuuluisa" koska nuo asiat monesti kierretään ja käytetään muita keinoja. Mutta ohjelmoija voi niitä halutessaan käyttää.

xxxxx kirjoitti:

Kun sinä olet aloittelija olio-ohjelmoinnissa, niin miksi minun pitäisi aloittaa samalta alaportaalta sen opettelu kuin kaltaisesi muut ohjelmoinnista tietämättömät?

Väität erään suurimmista eroista C :n ja Pascalin välillä olevan kirjoitusasu (hakasulut begin). Olet väärässä. Paljon suurempi ero on esim. muistinkäsittely ja pointterit, jotka ainakin Delphissä on piilotettu käyttäjältä.

Toki vastauksesi on ymmärrettävää silloin kun on vasta lukenut molempien (C :n ja Pascalin) manuaaleista ensimmäiset 10 sivua, jolloin on vasta käsitelty kielten perusasioiden kirjoitusasu.

Mihin olio-ohjelmointi on avainsana?

Lue lisää

Mutta ilmeisesti tarkoitit Javaa?

xxxxx kirjoitti:

Kun sinä olet aloittelija olio-ohjelmoinnissa, niin miksi minun pitäisi aloittaa samalta alaportaalta sen opettelu kuin kaltaisesi muut ohjelmoinnista tietämättömät?

Väität erään suurimmista eroista C :n ja Pascalin välillä olevan kirjoitusasu (hakasulut begin). Olet väärässä. Paljon suurempi ero on esim. muistinkäsittely ja pointterit, jotka ainakin Delphissä on piilotettu käyttäjältä.

Toki vastauksesi on ymmärrettävää silloin kun on vasta lukenut molempien (C :n ja Pascalin) manuaaleista ensimmäiset 10 sivua, jolloin on vasta käsitelty kielten perusasioiden kirjoitusasu.

Mihin olio-ohjelmointi on avainsana?

Lue lisää

Olio-ohjelmoinnissa monasti pyritään uudelleen käyttöön.

Esim voidaan soveltaa valmiita suunnittelumalleja (jo valmiiden suunnittelumallien käyttöä voidaan pitää uudelleen käyttönä).



Toinen esimerkki olio-pohjaisesta uudelleen käytöstä voisi olla vaikka Lazarus. Sama koodi käännetään eri alustoilla (esim. eri käyttöjärjestelmät, 32-bittinen/64-bittinen, eri prosessori) toimivaksi. (Niin Lazaruksen lähdekoodi tulee Lazaruksen mukana)

xxxxx kirjoitti:

Sinun tulisi tehdä yksi laajahko tietokoneohjelma. Suunnittele se ensin paperilla. Sitten koodaat sen. Myyt sen useille asiakkaille tai laitat vaikka ilmaiseksi nettiin. Ohjelmaasi käyttävät sitten esittävät parannusehdotuksia. Parannat ohjelmaasi.

Vähitellen alat ymmärtää mitä ohjelmointi tarkoittaa. Se tarkoittaa että loppukäyttäjän ohjelma on hyvä ja että ohjelman koodaajat pystyvät sitä helposti ylläpitämään.

Ohjelmointi ei ole triviaaleja takertumisia yksittäisiin asioihin. Niillä ei ole käytännön merkitystä ohjelmoinnin kannalta.

Edellinen viestisi on hyvä esimerkki triviaalista typeryydestä, kun mainitset että tyypin muutto onnistuu yhden rivin muutoksella. Tyyppien muunnoksia lopullisessa ohjelmassa tehdään tosi harvoin ja silloinkin täytyy käydä koodi niiltä osin läpi, jotta havaitaan aiheuttaako tyypin muutos ongelmia jollekin toiselle muuttujalla tai aliohjelmakutsulle. Olisikin hyvä että tekisit jonkin ohjelman, jotta ymmärtäisit välttää käytännön ohjelmointikeskustelussa triviaalit tapaukset muuten kuin piristämässä keskustelua.

Lue lisää

"Tyyppien muunnoksia lopullisessa ohjelmassa tehdään tosi harvoin ja silloinkin täytyy käydä koodi niiltä osin läpi, jotta havaitaan aiheuttaako tyypin muutos ongelmia jollekin toiselle muuttujalla tai aliohjelmakutsulle."

Juuri tätä työtä ei periaatteessa tarvitse hyvässä ohjelmassa tehdä
(jossa on hyvin suunniteltu tyypitys)!

xxxxx kirjoitti:

Kun sinä olet aloittelija olio-ohjelmoinnissa, niin miksi minun pitäisi aloittaa samalta alaportaalta sen opettelu kuin kaltaisesi muut ohjelmoinnista tietämättömät?

Väität erään suurimmista eroista C :n ja Pascalin välillä olevan kirjoitusasu (hakasulut begin). Olet väärässä. Paljon suurempi ero on esim. muistinkäsittely ja pointterit, jotka ainakin Delphissä on piilotettu käyttäjältä.

Toki vastauksesi on ymmärrettävää silloin kun on vasta lukenut molempien (C :n ja Pascalin) manuaaleista ensimmäiset 10 sivua, jolloin on vasta käsitelty kielten perusasioiden kirjoitusasu.

Mihin olio-ohjelmointi on avainsana?

Lue lisää

"niin miksi minun pitäisi aloittaa samalta alaportaalta sen opettelu kuin ... muut"

Tottakai osaat tehdä Delphillä/Pascalilla jo nyt (siksi kun jotkut rakenteet samantapaisia) eli olet eri asemassa kuin aloittelijat. Siksi Delphi on hyvä valinta myös sinulle koskas voit lisätä täysin uusia asioita vähitellen (verrattuna siihen että aloitat pelkällä oliokielellä jolloin kaikki asiat ovat avain uusia).

xxxxx kirjoitti:

No vaikka ohjelman lopputulosta, joka on kuitenkin tärkein peruste. Visual Basicilla ja Delphillä voi molemmilla tehdä hyviä ohjelmia. Toki räpellyksiäkin voi molemmilla tehdä.

Tässä kirjoitusketjussa olen perustellut asioita, mutta minulle vastaväitteitä esittävät heittävät vain yksittäisiä perustelemattomia kysymyksiä, joilla he ikään kuin asettavat minulle vaatimuksen kirjoittaa laajoja perusteluita. Perusteluita olen tässä kirjoitusketjussa paljon kirjoitellut ja eikö ne sitten sivuteta ja esitetä taas yksittäisiä lisäkysymyksiä.

Tuo edellinen viestisi on toinen tässä ketjussa. Edellisessä vain mainitsit että Delphissä on valuutan laskemiseen Currency-tyyppi. Niin on Visual Basicissakin http://www.ohjelmointiputka.net/opas.php?tunnus=vbo_2

Palataan vielä edelliseen kysymykseesi. Siihen voi lisätä esim. nämä: samantyyppiset muuttujat, molempia on kehitetty paljon, molemmat tekevät koodia parhaalle käyttöjärjestelmälle eli Microsoftin Windows XP:lle, molemmat on helppokäyttöisia. Noin. Siinä nyt samankaltaisuuksia.

Jos Visual Basicilla ja Delphillä on merkittäviä eroja, jotka estävät sen, että valmis ohjelma ei voi olla hyvä, niin kerro sinä tai joku muu niistä eroista. JA PERUSTELKAA VÄITTEENNE ETTETTE VAIN HEITÄ ETTÄ PAREMMUUS JOHTUU OLIOISTA TAI MUISTA UFOJUTUISTA, JOTKA OVAT VAIN TRIVIAALIA TYPERÄÄ VASTAANÄNKYTYSTÄ ETTEI VISUAL PEISIKILLÄ MUKA VOI TEHDÄ HYVIÄ OHJELMIA.

Lue lisää

Delphihän tarjoaa mahdollisuuden myös ohjelman osien rinnakkaisen suorituksen tekemiseen.
Eli tätä kutsutaan myös nimellä säikeet.

.................... kirjoitti:

"Äläs kuule valehtele. Eiköhän kuitenkin liene Assembly sitten C/C ja Delphi tuossa järjestyksessä."

Assembleri ei välttämättä ole nopein, kaikki kun riippuu sillä ohjelmoijan kyvyistä mutta ohjelmoija ei välttämättä osaa koodata nopeimmalla mahdollisella tavalla assyllä. Puhumattakaan siitä että kehitysaika on helvetin hidas, harvempi kuitenkaan haluaa viettää 20 vuotta tehden perussovellutusta...

C-kielellä tietyt ohjelmarakenteet saattavat täsmälleen saman lopputuloksen kuin assembler, käännetty konekielikoodi ei ole välttämättä yhtään sen hitaampi kuin suoraan konekieliseksi koodattu ohjelma. Kuitenkin monimutkaisissa ohjelmissa kääntäjän älykkyys työskentelee kooderin eduksi. inlinet, volatilet yms. tapahtuvat automattisesti toisin kuin assemblerissa.

Delphi - siis pascal - ei eroa c/c :sta mitenkään arkkitehtuurisesti; kääntäjä tuottaa optim,oidun konekielibinäärin. Siis ihan oikeasti, samaa konekieltä tuotetaan. Delphin etuna on vahva tyypitys jolloin ohjelmat voidaan optimoida paremmin. Toisaalta c-kielelle ominainen "control it all" voi toimia taitavan kooderin käsissä tehokkaammin kun pääsee oikomaan kääntäjää kauhistuttavilla hackeilla.

Nopein? Sanosin että jos nopeutta haluaa pitää valita sellainen kieli joka tukee arkkitehtuuria. Prosessoriksi Intel Pentium 4 / uudempi ja kääntäjäksi Intel C/C compiler. Tulee nopeinta koodia koska se optimoidaan tietylle arkkitehtuurille.

Lue lisää

..basic miehen örvellystä selvästi, kyllä mäkin joskus hurjassa nuoruudessa sitä olen käyttänyt, kunnes huomasin että parempaakin on tarjolla.

Tämäkin tutkimus kertoo ettei Delphiä/Pascalia tunneta suomessa

"Sivulla http://www.cs.helsinki.fi/u/kerola/tkhist/k2006/alustuk set/ohjkielet/hpr-historiasemma.pdf on yliopiston opiskelijan tekemä tutkimuksen alustus ohjelmointikielten kehittymisestä"

Tunnettavuus kirjoitti:

Tämäkin tutkimus kertoo ettei Delphiä/Pascalia tunneta suomessa

"Sivulla http://www.cs.helsinki.fi/u/kerola/tkhist/k2006/alustuk set/ohjkielet/hpr-historiasemma.pdf on yliopiston opiskelijan tekemä tutkimuksen alustus ohjelmointikielten kehittymisestä"

Lue lisää

Delphi on kuitenkin kovin marginaalisessa asemassa ohjelmointikielten joukossa, samaa tasoa C#:n kanssa.

Java ja C ovat ihan omassa luokassaan, sitten seuraa tiukka rypäs, C , Basic ja PHP, ehkä Perl. Muut ovatkin sitten lähinnä "erikoisuuksia".

http://www.tiobe.com/tpci.htm

faktaa. kirjoitti:

Delphi on kuitenkin kovin marginaalisessa asemassa ohjelmointikielten joukossa, samaa tasoa C#:n kanssa.

Java ja C ovat ihan omassa luokassaan, sitten seuraa tiukka rypäs, C , Basic ja PHP, ehkä Perl. Muut ovatkin sitten lähinnä "erikoisuuksia".

http://www.tiobe.com/tpci.htm

Lue lisää

Noissa tilastoissa Delphi on vain Borlandin tuote ja muut Pascalit (lähinnä FreePascal ja Lazarus) ovat sitten omana ryhmänään.

Mutta markkinaosuus ei kerro kielen tasosta, kehittynyisyydestä, käytettävyydestä mitään.
Vertaappa c & c suosiota toisiinsa.

Se että Delphillä ja muilla Pascaleilla on aika pieni osuus johtuu lähinnä vanhentuneesta tiedosta. Moni kuvittelee että Pascal on vanhanaikainen mutta hän on todella väärässä.

Nykyisissä Pascaleissa (Delphi, FreePascal, Lazarus) on kaikki nykyaikaiset ominaisuudet (vrt vaikkapa Java ja C )

faktaa. kirjoitti:

Delphi on kuitenkin kovin marginaalisessa asemassa ohjelmointikielten joukossa, samaa tasoa C#:n kanssa.

Java ja C ovat ihan omassa luokassaan, sitten seuraa tiukka rypäs, C , Basic ja PHP, ehkä Perl. Muut ovatkin sitten lähinnä "erikoisuuksia".

http://www.tiobe.com/tpci.htm

Lue lisää

Ilmeisesti Lazarus kuluu tässä tilastossa Pascal-kielien ryhmään. Lazaruksen käyttöliittymä tukee (suomen ohella) mm japania ja kiinaa. En viitsinyt edes
selvittää mistä tuo sivu hakee nuo prosenttiosuudet ja millä perusteella. (Onkohan siinä vain USAn prosentit?).

Mainittu Lazarus on vapaasti käytettävissä ja imuroitavissa vaikkapa täältä:
https://sourceforge.net/project/showfiles.php?group_id=89339

Ohjeet:
http://wiki.lazarus.freepascal.org/index.php/Main_Page/fi

Tunnettavuus kirjoitti:

Noissa tilastoissa Delphi on vain Borlandin tuote ja muut Pascalit (lähinnä FreePascal ja Lazarus) ovat sitten omana ryhmänään.

Mutta markkinaosuus ei kerro kielen tasosta, kehittynyisyydestä, käytettävyydestä mitään.
Vertaappa c & c suosiota toisiinsa.

Se että Delphillä ja muilla Pascaleilla on aika pieni osuus johtuu lähinnä vanhentuneesta tiedosta. Moni kuvittelee että Pascal on vanhanaikainen mutta hän on todella väärässä.

Nykyisissä Pascaleissa (Delphi, FreePascal, Lazarus) on kaikki nykyaikaiset ominaisuudet (vrt vaikkapa Java ja C )

Lue lisää

>...ei kerro kielen tasosta, kehittynyisyydestä, käytettävyydestä mitään.

Ohjelmoinnissa on muitakin tavoitteita kuin koodarin viihtyvyys, esim. lopputuotteen toimivuus.

Otapa selvää miksi Torvalds ei anna, jatkuvasta painostuksesta huolimatta, koodata Linuxin kerneliä c :lla.

Kirjoitusohjelma ilmoitti ettei viestiä voi lisätä tuohon ylös vaan se näköjään jatkuu tästä.

Edellinen siis oli vastaus Lazarukselle kohtaan "Jatkoa edelliseen".


FreePascalin sanoin kohdassa "Pointterit" näin:

"Ihan ensimmäisistä Pascal-toteutuksista lähtien on Pascalissa ollut pointterit ja muistin dynaaminen varaaminen. Löytyy myös nykyisistä toteutuksistakin. Tosin Pascal ei ole ollut koskaan noista "kuuluisa" koska nuo asiat monesti kierretään ja käytetään muita keinoja. Mutta ohjelmoija voi niitä halutessaan käyttää."

Ei Pascalissa ole ollut pointtereita ja dynaamista muistinhallintaa niinkuin ne C-kielestä ymmärretään. Tietysti joku tietämätön voi ajatella että kaikki muuttujat ja taulukkovaraukset ovat pointtereita, sillä ne osoittavat muistipaikkaan jossa muuttujan sisältö on.

Sivulla http://www.informatik.fh-wiesbaden.de/~weber/sysprog/rdp/rdp_case.pdf on asiasta enemmänkin, mutta tässä yksi pointti tai pointteri :)

"Assembly using the DATA and CODE pointers"


Sivulla http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/PointersI.html todetaan sama asia:

"A pointer variable consists of a memory address.
...
This is true in any language which has pointer variables, e.g. Pascal, but in C it is more explicit than in Pascal."


En tiedä onko Delphissä, mutta ei ainakaan 1980-luvun Pascalissa ollut Basicin loistavaa dynaamisten merkkijonojen käsittelyä. Ehkä nykyiset Pascal-kääntäjät ovat ottaneet oppia fiksummaltaan ja saaneet siihen lisättyä Basicin joustavuutta.


Joten ihan totta: Voisitteko edes opetella asian (Pascalin) jossa esiinnytte asiantuntijoina?

xxxxx kirjoitti:

Kirjoitusohjelma ilmoitti ettei viestiä voi lisätä tuohon ylös vaan se näköjään jatkuu tästä.

Edellinen siis oli vastaus Lazarukselle kohtaan "Jatkoa edelliseen".


FreePascalin sanoin kohdassa "Pointterit" näin:

"Ihan ensimmäisistä Pascal-toteutuksista lähtien on Pascalissa ollut pointterit ja muistin dynaaminen varaaminen. Löytyy myös nykyisistä toteutuksistakin. Tosin Pascal ei ole ollut koskaan noista "kuuluisa" koska nuo asiat monesti kierretään ja käytetään muita keinoja. Mutta ohjelmoija voi niitä halutessaan käyttää."

Ei Pascalissa ole ollut pointtereita ja dynaamista muistinhallintaa niinkuin ne C-kielestä ymmärretään. Tietysti joku tietämätön voi ajatella että kaikki muuttujat ja taulukkovaraukset ovat pointtereita, sillä ne osoittavat muistipaikkaan jossa muuttujan sisältö on.

Sivulla http://www.informatik.fh-wiesbaden.de/~weber/sysprog/rdp/rdp_case.pdf on asiasta enemmänkin, mutta tässä yksi pointti tai pointteri :)

"Assembly using the DATA and CODE pointers"


Sivulla http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/PointersI.html todetaan sama asia:

"A pointer variable consists of a memory address.
...
This is true in any language which has pointer variables, e.g. Pascal, but in C it is more explicit than in Pascal."


En tiedä onko Delphissä, mutta ei ainakaan 1980-luvun Pascalissa ollut Basicin loistavaa dynaamisten merkkijonojen käsittelyä. Ehkä nykyiset Pascal-kääntäjät ovat ottaneet oppia fiksummaltaan ja saaneet siihen lisättyä Basicin joustavuutta.


Joten ihan totta: Voisitteko edes opetella asian (Pascalin) jossa esiinnytte asiantuntijoina?

Lue lisää

Tuolla ylempänä oli merkkijonojen käsittelystä Pascalissa jo kerrottukin.
Lue se nyt ensin (katso myös se linkkikin).

Minkälaista toimintoa oikein haluat?

xxxxx kirjoitti:

Kirjoitusohjelma ilmoitti ettei viestiä voi lisätä tuohon ylös vaan se näköjään jatkuu tästä.

Edellinen siis oli vastaus Lazarukselle kohtaan "Jatkoa edelliseen".


FreePascalin sanoin kohdassa "Pointterit" näin:

"Ihan ensimmäisistä Pascal-toteutuksista lähtien on Pascalissa ollut pointterit ja muistin dynaaminen varaaminen. Löytyy myös nykyisistä toteutuksistakin. Tosin Pascal ei ole ollut koskaan noista "kuuluisa" koska nuo asiat monesti kierretään ja käytetään muita keinoja. Mutta ohjelmoija voi niitä halutessaan käyttää."

Ei Pascalissa ole ollut pointtereita ja dynaamista muistinhallintaa niinkuin ne C-kielestä ymmärretään. Tietysti joku tietämätön voi ajatella että kaikki muuttujat ja taulukkovaraukset ovat pointtereita, sillä ne osoittavat muistipaikkaan jossa muuttujan sisältö on.

Sivulla http://www.informatik.fh-wiesbaden.de/~weber/sysprog/rdp/rdp_case.pdf on asiasta enemmänkin, mutta tässä yksi pointti tai pointteri :)

"Assembly using the DATA and CODE pointers"


Sivulla http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/PointersI.html todetaan sama asia:

"A pointer variable consists of a memory address.
...
This is true in any language which has pointer variables, e.g. Pascal, but in C it is more explicit than in Pascal."


En tiedä onko Delphissä, mutta ei ainakaan 1980-luvun Pascalissa ollut Basicin loistavaa dynaamisten merkkijonojen käsittelyä. Ehkä nykyiset Pascal-kääntäjät ovat ottaneet oppia fiksummaltaan ja saaneet siihen lisättyä Basicin joustavuutta.


Joten ihan totta: Voisitteko edes opetella asian (Pascalin) jossa esiinnytte asiantuntijoina?

Lue lisää

Pointtereita voi Pascalissa käyttää mm erilaisten linkitettyjen listojen (tietorakenteiden) käyttöön, niillä voidaan varata esim. dynaamista muistia olion ulkopuolelta tai esim. olioita voidaan osoittaa pointtereilla.


Eli on ohjelmointikieliä joissa on pointterit ja Pascal kuuluu niihin.

FreePascal kirjoitti:

Pointtereita voi Pascalissa käyttää mm erilaisten linkitettyjen listojen (tietorakenteiden) käyttöön, niillä voidaan varata esim. dynaamista muistia olion ulkopuolelta tai esim. olioita voidaan osoittaa pointtereilla.


Eli on ohjelmointikieliä joissa on pointterit ja Pascal kuuluu niihin.

Lue lisää

Mitä hyötyä on siitä, että voit Pascalissa varata dynaamista muistia olion ulkopuolelta tai että voit osoittaa oliota pointtereilla?

Kerro millä tavalla ja millaisten ongelmien ratkaisuun olet itse Pascalissa käyttänyt noita toimintoja.

on näin kirjoitti:

Tuolla ylempänä oli merkkijonojen käsittelystä Pascalissa jo kerrottukin.
Lue se nyt ensin (katso myös se linkkikin).

Minkälaista toimintoa oikein haluat?

Missä kohtaa ylempänä on kerrottu merkkijonojen käsittelystä Pascalista sillä tavalla, että se olisi vastaus edelliseen viestiini?


"Minkälaista toimintoa oikein haluat?"

Miten niin? Miksi tuollaista kysyt?

xxxxx kirjoitti:

Missä kohtaa ylempänä on kerrottu merkkijonojen käsittelystä Pascalista sillä tavalla, että se olisi vastaus edelliseen viestiini?


"Minkälaista toimintoa oikein haluat?"

Miten niin? Miksi tuollaista kysyt?

Lue lisää

Lue tämän alla olevan linkin sisältö:
http://www.delphibasics.co.uk/RTL.asp?Name=TStringList

(jotakin kyseisestä asiasta on kerrottu täälläkin
http://wiki.mureakuha.com/wiki/TStringList
)


Ymmärsitkö mitä siinä tehtiin?



""Minkälaista toimintoa oikein haluat?"

Miten niin? Miksi tuollaista kysyt?"

Kysyn siksi koska en tosiaankaan tiedä
mitä ominaisuutta tarvitset (voisit antaa esimerkin)?

on näin kirjoitti:

Lue tämän alla olevan linkin sisältö:
http://www.delphibasics.co.uk/RTL.asp?Name=TStringList

(jotakin kyseisestä asiasta on kerrottu täälläkin
http://wiki.mureakuha.com/wiki/TStringList
)


Ymmärsitkö mitä siinä tehtiin?



""Minkälaista toimintoa oikein haluat?"

Miten niin? Miksi tuollaista kysyt?"

Kysyn siksi koska en tosiaankaan tiedä
mitä ominaisuutta tarvitset (voisit antaa esimerkin)?

Lue lisää

Katsoin antamisiesi linkkien 2 sivua. Ei niistä tullut mitään tietoa minun väitteitäni vastaan. Minähän sanoin äsken että jokainen ohjelmointikieli sisältää pointterit. Ja melkein kaikki kielet myös dynaamisten merkkijonojen käsittelyn. Pascalissa niiden toteutuksessa on sekoiltu niin, että ne eivät olleet yhtä yksinkertaisia ja käyttäjille käteviä kuin Basicissa. Delphi on parantanut merkkijonojen käsittelyä ottamalla mallia Basicista.


"Kysyn siksi koska en tosiaankaan tiedä mitä ominaisuutta tarvitset (voisit antaa esimerkin)?"

En minä tarvitse mitään Pascalin tai Delphin ominaisuutta. Tässä kirjoitusketjussa olen kritisoinut sitä, että joidenkin mielestä Visual Basic on huonompi ohjelmointikieli kuin Delphi tai jotkut Pascalit. Sinäkin voisit muistaa edelliset kirjoitukset ja vastaukset jotta keskustelisit siitä missä täällä keskustellaan.


Oletko tehnyt ohjelmia Delphillä? Kerro millä tavalla ja millaisten ongelmien ratkaisuun olet itse Pascalissa käyttänyt noita toimintoja (pointtereita ja olioita) sekä millä tavalla niiden käyttö teki ohjelman teosta helpompaa kuin "tavallisella" koodauksella.

xxxxx kirjoitti:

Katsoin antamisiesi linkkien 2 sivua. Ei niistä tullut mitään tietoa minun väitteitäni vastaan. Minähän sanoin äsken että jokainen ohjelmointikieli sisältää pointterit. Ja melkein kaikki kielet myös dynaamisten merkkijonojen käsittelyn. Pascalissa niiden toteutuksessa on sekoiltu niin, että ne eivät olleet yhtä yksinkertaisia ja käyttäjille käteviä kuin Basicissa. Delphi on parantanut merkkijonojen käsittelyä ottamalla mallia Basicista.


"Kysyn siksi koska en tosiaankaan tiedä mitä ominaisuutta tarvitset (voisit antaa esimerkin)?"

En minä tarvitse mitään Pascalin tai Delphin ominaisuutta. Tässä kirjoitusketjussa olen kritisoinut sitä, että joidenkin mielestä Visual Basic on huonompi ohjelmointikieli kuin Delphi tai jotkut Pascalit. Sinäkin voisit muistaa edelliset kirjoitukset ja vastaukset jotta keskustelisit siitä missä täällä keskustellaan.


Oletko tehnyt ohjelmia Delphillä? Kerro millä tavalla ja millaisten ongelmien ratkaisuun olet itse Pascalissa käyttänyt noita toimintoja (pointtereita ja olioita) sekä millä tavalla niiden käyttö teki ohjelman teosta helpompaa kuin "tavallisella" koodauksella.

Lue lisää

"Katsoin antamisiesi linkkien 2 sivua."

Ymmärsitkö mitä siinä tehtiin?

on näin kirjoitti:

"Katsoin antamisiesi linkkien 2 sivua."

Ymmärsitkö mitä siinä tehtiin?

Miten niin ymmärsinkö? Minähän kysyin äsken että miten ne sivut vastasivat edellisiin kysymyksiini?

Mutta käsitellään tuota kysymystäsi, että ymmärsinkö mitä tuolla linkkisivuilla oleva koodi tekee. Kyllä Delphissä näyttää olevat paljon käskyjä. Tuon DelimitedText-esimerkin tyyppisellä tavalla olen itse VB:llä välittänyt tietoja. Tosin minun täytyi itse tehdä funktio joka palauttaa halutun tiedon. Mutta ohjelmoinnissahan tehdään koodia jatkuvasti ja koodaus on minulla kyllä hallussa, kuten olen maininnut. En ole Delphillä tehnyt ikinä mitään, Pascalilla jotain joskus aikoinaan. Silti tuo koodin luku kävi varsin helposti, sillä tuo koodi on aloittelijan peruskoodia.

Eli tuo Delphin TStringList-muoto on aloittelijalle yksi kätevä tapa käsitellä merkkijonolistoja, mutta eipä tuossa mitään sen erinomaisempaa ole.

Joten ymmärsinhän minä mitä siinä koodissa tehtiin. Ymmärrätkö sinä mistä tässä on keskusteltu?

xxxxx kirjoitti:

Mitä hyötyä on siitä, että voit Pascalissa varata dynaamista muistia olion ulkopuolelta tai että voit osoittaa oliota pointtereilla?

Kerro millä tavalla ja millaisten ongelmien ratkaisuun olet itse Pascalissa käyttänyt noita toimintoja.

Lue lisää

Olioilla ja pointtereilla on helppo tehdä vaikkapa pino

xxxxx kirjoitti:

Miten niin ymmärsinkö? Minähän kysyin äsken että miten ne sivut vastasivat edellisiin kysymyksiini?

Mutta käsitellään tuota kysymystäsi, että ymmärsinkö mitä tuolla linkkisivuilla oleva koodi tekee. Kyllä Delphissä näyttää olevat paljon käskyjä. Tuon DelimitedText-esimerkin tyyppisellä tavalla olen itse VB:llä välittänyt tietoja. Tosin minun täytyi itse tehdä funktio joka palauttaa halutun tiedon. Mutta ohjelmoinnissahan tehdään koodia jatkuvasti ja koodaus on minulla kyllä hallussa, kuten olen maininnut. En ole Delphillä tehnyt ikinä mitään, Pascalilla jotain joskus aikoinaan. Silti tuo koodin luku kävi varsin helposti, sillä tuo koodi on aloittelijan peruskoodia.

Eli tuo Delphin TStringList-muoto on aloittelijalle yksi kätevä tapa käsitellä merkkijonolistoja, mutta eipä tuossa mitään sen erinomaisempaa ole.

Joten ymmärsinhän minä mitä siinä koodissa tehtiin. Ymmärrätkö sinä mistä tässä on keskusteltu?

Lue lisää

Kyllä tuo sama koodi käy myös Pascaliin eli se toimii sellaisenaan Delphin lisäksi myös Lazaruksessa ja FreePascalissa!

FreePascal kirjoitti:

Olioilla ja pointtereilla on helppo tehdä vaikkapa pino

Aliohjelmalla ja yhdellä dynaamisella merkkijonomuuttujallakin voi helposti tehdä pinon, joten kerro millä tavalla pinon käsittely on olioiden ja pointtereiden avulla helpompaa tai muuten kätevämpää? Minulle ei nyt äkkiseltään tule mieleen, että missä olisin pinoa vuosikausiin tarvinnut ja käyttänyt, joten käytätkö sinä pinoa paljonkin ja millaisissa käyttötarkoituksissa, vai puhutko sinäkin vain teoreettisella tasolla ilman käytännön ohjelmointikokemusta?

FreePascal kirjoitti:

Kyllä tuo sama koodi käy myös Pascaliin eli se toimii sellaisenaan Delphin lisäksi myös Lazaruksessa ja FreePascalissa!

Borlandhan toi aikoinaan Delphin Turbo-Pascalin ihan uudeksi versioksi ottaen pohjaksi osan Pascalin syntaksista. Ja kun eri ohjelmointikielet jatkuvasti ottavat ideoita muista kielistä, niin onhan se luonnollista että pascalpohjaisissa kääntäjissä voidaan ajaa osin samaa koodia.

xxxxx kirjoitti:

Borlandhan toi aikoinaan Delphin Turbo-Pascalin ihan uudeksi versioksi ottaen pohjaksi osan Pascalin syntaksista. Ja kun eri ohjelmointikielet jatkuvasti ottavat ideoita muista kielistä, niin onhan se luonnollista että pascalpohjaisissa kääntäjissä voidaan ajaa osin samaa koodia.

Lue lisää

Turbo Pascal oli Delphin edeltäjä. Siinä oli siihen aikaan monia uusia asioita kuten olio-ohjelmointi, Turbo Vision, IDE jne. Turbo Pascal oli dos ajanjakson tuote (harva enään puhuu dos-ohjelmista). Borland toi ensin 16-bittisen Delphin windows 3.1:n ja sen jälkeen 32-bittisen version windows95 myötä. Toki Turbo Pascalilla hyvin tehtyjä kirjastoja voidaan käyttää myös nykyisissä Delphi-ohjelmissa. Mutta tuo oli siis viime vuosituhannella.

Delphi on nopea! kirjoitti:

Turbo Pascal oli Delphin edeltäjä. Siinä oli siihen aikaan monia uusia asioita kuten olio-ohjelmointi, Turbo Vision, IDE jne. Turbo Pascal oli dos ajanjakson tuote (harva enään puhuu dos-ohjelmista). Borland toi ensin 16-bittisen Delphin windows 3.1:n ja sen jälkeen 32-bittisen version windows95 myötä. Toki Turbo Pascalilla hyvin tehtyjä kirjastoja voidaan käyttää myös nykyisissä Delphi-ohjelmissa. Mutta tuo oli siis viime vuosituhannella.

Lue lisää

Miksi jatkat tuollaisten tekstien kirjoittamista?

Niiden informaatioarvo on nolla.

Oletko itse ohjelmoinut Turbo Pascalilla vai oletko syntynyt vasta 1990-luvulla?

xxxxx kirjoitti:

Miten niin ymmärsinkö? Minähän kysyin äsken että miten ne sivut vastasivat edellisiin kysymyksiini?

Mutta käsitellään tuota kysymystäsi, että ymmärsinkö mitä tuolla linkkisivuilla oleva koodi tekee. Kyllä Delphissä näyttää olevat paljon käskyjä. Tuon DelimitedText-esimerkin tyyppisellä tavalla olen itse VB:llä välittänyt tietoja. Tosin minun täytyi itse tehdä funktio joka palauttaa halutun tiedon. Mutta ohjelmoinnissahan tehdään koodia jatkuvasti ja koodaus on minulla kyllä hallussa, kuten olen maininnut. En ole Delphillä tehnyt ikinä mitään, Pascalilla jotain joskus aikoinaan. Silti tuo koodin luku kävi varsin helposti, sillä tuo koodi on aloittelijan peruskoodia.

Eli tuo Delphin TStringList-muoto on aloittelijalle yksi kätevä tapa käsitellä merkkijonolistoja, mutta eipä tuossa mitään sen erinomaisempaa ole.

Joten ymmärsinhän minä mitä siinä koodissa tehtiin. Ymmärrätkö sinä mistä tässä on keskusteltu?

Lue lisää

Tässähän on keskusteltu Delphistä ja sinä olet ilmeisesti jossain määrin puhunut ja käyttänyt vertailukohtana USCD-pascalia (joka perustui välikoodin käyttöön ja) joka oli 70-luvun lopun tuote. Vai oletko edes vieläkään kokeillut jotain tämän päivän Pascalia /Delphiä. Onhan se basikki muuttunut ja ottanut hurjasti mallia Pascalista ja muista rakenteellisista kielistä(mm rivinumerointia ei ole enään).

xxxxx kirjoitti:

Aliohjelmalla ja yhdellä dynaamisella merkkijonomuuttujallakin voi helposti tehdä pinon, joten kerro millä tavalla pinon käsittely on olioiden ja pointtereiden avulla helpompaa tai muuten kätevämpää? Minulle ei nyt äkkiseltään tule mieleen, että missä olisin pinoa vuosikausiin tarvinnut ja käyttänyt, joten käytätkö sinä pinoa paljonkin ja millaisissa käyttötarkoituksissa, vai puhutko sinäkin vain teoreettisella tasolla ilman käytännön ohjelmointikokemusta?

Lue lisää

Mutta sinne voi laittaa vain yksinkertaisia tyyppejä ei esim toisia olioita.
Mutta pino oli vain ainoastaan yksi esimerkki. Tekemällä itse tämänkaltaisen pinon oliolla opit ymmärtämään ja soveltamaan sitä muuallekin.

Niin sanotaahan että harjoitus tekee mestarin.

xxxxx kirjoitti:

Mitä hyötyä on siitä, että voit Pascalissa varata dynaamista muistia olion ulkopuolelta tai että voit osoittaa oliota pointtereilla?

Kerro millä tavalla ja millaisten ongelmien ratkaisuun olet itse Pascalissa käyttänyt noita toimintoja.

Lue lisää

Tokihan Delphissä pointterit löytyy.

Sovellusohjelmoija tarvitsee niitä varsin harvoin.

Sensijaan, jos ohjelmoi itse Delphi -komponentteja, niin pointtereista on hyötyä esim. seuraavissa tapauksissa:

1. Niiden käyttäminen voi joskus johtaa nopeampaan koodinsuoritukseen (vaatii toki taitoa, miten niitä käytetään. Pointterit eivät ole mitenkään automaattisesti nopeampi ratkaisu)

2. Vanhemmissa Delphin versioissa Delphin oma String -tyyppi (Delphi 2.0:sta alkaen = AnsiString eli ns. long string) ei ole säieturvallinen. Joskus pointtereita joutuu käyttämään, jotta luokat toimivat oikein myös useita säikeitä käyttävässä koodissa

3. Käytettäessä windowsin VirtualAlloc, VirtualProtect ja VirtualFree -funktioita

4. muistikartoitetun (memory mapped) tiedosto -IO:n yhteydessä

5. Varsinkin PChar -tyyppiä yleisesti aina, kun ollaan tekemisissä windowsin API -kutsujen kanssa

Eli ovat kyllä hyödyllisiä, mutta Delphi -ohjelmoijalla ei ole samanlaista pakkoa niiden käyttöön kuin C -ohjelmissa.

muuten, jo MS-DOS -aikakauden Turbo pascalit pystyivät tähän:

var
I : Integer;
P : ^Integer;

begin
I := 7;
P := @I; { vai olisiko ollut P := addr(I); }
P^ := 9;
WriteLn(I); { tulostaa "9" }
end.

Eli kyllä Borlandin Pascal -tuotteissa on aina ollut vahva osaamisen leima.

Monen C/C -koodaajan "anti-pascal" -asenne onkin muinaisjäänne jostain "standardi" -pascalista, joka on kyllläkin jonkin virallisen standardointikomitean hyväksymä, mutta käytännössä niin rajoittunut, ettei sillä tee mitään, muuta kuin opetuskielenä.

Borlandin Pascal ja ObjectPascal -pohjaiset tuotteet (Turbo Pascal, Turbo Pascal for windows, Borland Pascal ja Delphi) ovat aina olleet päteviä välineitä, joissa on kaikki modernien ohjelmointivälineiden ominaisuudet, eikä noita "standardi"pascalin puutteita.

esim. modulaarinen kääntö UNIT kerrallaan on ollut jo iät ja ajat Borlandin tuotteisiin vakiona kuuluva ominaisuus.

Mika0800 kirjoitti:

Tokihan Delphissä pointterit löytyy.

Sovellusohjelmoija tarvitsee niitä varsin harvoin.

Sensijaan, jos ohjelmoi itse Delphi -komponentteja, niin pointtereista on hyötyä esim. seuraavissa tapauksissa:

1. Niiden käyttäminen voi joskus johtaa nopeampaan koodinsuoritukseen (vaatii toki taitoa, miten niitä käytetään. Pointterit eivät ole mitenkään automaattisesti nopeampi ratkaisu)

2. Vanhemmissa Delphin versioissa Delphin oma String -tyyppi (Delphi 2.0:sta alkaen = AnsiString eli ns. long string) ei ole säieturvallinen. Joskus pointtereita joutuu käyttämään, jotta luokat toimivat oikein myös useita säikeitä käyttävässä koodissa

3. Käytettäessä windowsin VirtualAlloc, VirtualProtect ja VirtualFree -funktioita

4. muistikartoitetun (memory mapped) tiedosto -IO:n yhteydessä

5. Varsinkin PChar -tyyppiä yleisesti aina, kun ollaan tekemisissä windowsin API -kutsujen kanssa

Eli ovat kyllä hyödyllisiä, mutta Delphi -ohjelmoijalla ei ole samanlaista pakkoa niiden käyttöön kuin C -ohjelmissa.

muuten, jo MS-DOS -aikakauden Turbo pascalit pystyivät tähän:

var
I : Integer;
P : ^Integer;

begin
I := 7;
P := @I; { vai olisiko ollut P := addr(I); }
P^ := 9;
WriteLn(I); { tulostaa "9" }
end.

Eli kyllä Borlandin Pascal -tuotteissa on aina ollut vahva osaamisen leima.

Monen C/C -koodaajan "anti-pascal" -asenne onkin muinaisjäänne jostain "standardi" -pascalista, joka on kyllläkin jonkin virallisen standardointikomitean hyväksymä, mutta käytännössä niin rajoittunut, ettei sillä tee mitään, muuta kuin opetuskielenä.

Borlandin Pascal ja ObjectPascal -pohjaiset tuotteet (Turbo Pascal, Turbo Pascal for windows, Borland Pascal ja Delphi) ovat aina olleet päteviä välineitä, joissa on kaikki modernien ohjelmointivälineiden ominaisuudet, eikä noita "standardi"pascalin puutteita.

esim. modulaarinen kääntö UNIT kerrallaan on ollut jo iät ja ajat Borlandin tuotteisiin vakiona kuuluva ominaisuus.

Lue lisää

Esimerkkisi pointtereista oli selkeä mutta huono, sillä siitä käy vain ilmi että voit viitata muuttujan sisältöön tai sen muistipaikkaan (pointtereilla). Eli on tyhmää sekoittaa itseään sillä, että täytyy aina miettiä kummalla tavalla nyt taas tässä pitikään viitata. Vanhoissa pascaleissa jotkut IO-funktiot nimenomaan vaativat viittauksen pointtereilla, joten pointtereiden käyttö ei ollut etu vaan haitta.

Joten kun kehuit Delphin pointtereita, niin laita käytännön esimerkki jossa olet niitä itse käyttänyt. Sillä jos olet Delphillä tehnyt oikean tietokoneohjelman ja kehusi pitävät paikkansa, niin toki sinulta löytyy roppakaupalla hienoja omia esimerkkikoodeja pointtereiden käytöstä.

Joten pane yksi itse tekemäsi koodipätkä, jossa selviää pointtereiden etu koodiin ilman pointtereita. Eli että pointtereita olisi "tavallisessa" koodissa vaikea kiertää.

FreePascal kirjoitti:

Pointtereita voi Pascalissa käyttää mm erilaisten linkitettyjen listojen (tietorakenteiden) käyttöön, niillä voidaan varata esim. dynaamista muistia olion ulkopuolelta tai esim. olioita voidaan osoittaa pointtereilla.


Eli on ohjelmointikieliä joissa on pointterit ja Pascal kuuluu niihin.

Lue lisää

Ponttereilla voi tehdä mm linkitettyjä listoja (esim. kahteen suuntaan), binääripuita jne. (Jo vanhatkin pascalit mahdollistivat näiden käytön)

FreePascal kirjoitti:

Ponttereilla voi tehdä mm linkitettyjä listoja (esim. kahteen suuntaan), binääripuita jne. (Jo vanhatkin pascalit mahdollistivat näiden käytön)

Tekevätkö pointterit koodauksen helpommaksi ja mahdollistavat koodin jota ei voi ilman ns. pointtereita tehdä?

Kerro esimerkki omasta ohjelmakoodistasi, jossa olet pointtereilla tehnyt binääripuun. Tietokannat lajittelevat tiedot automaattisesti ja vastaavia voi tehdä ohjelmaan helposti vaikka väliaikaisesti, joten kerro mihin olet itse käyttänyt pointtereilla tehtyä binääripuuta? Ja pätkä ohjelmakoodiasi mukaan.

xxxxx kirjoitti:

Tekevätkö pointterit koodauksen helpommaksi ja mahdollistavat koodin jota ei voi ilman ns. pointtereita tehdä?

Kerro esimerkki omasta ohjelmakoodistasi, jossa olet pointtereilla tehnyt binääripuun. Tietokannat lajittelevat tiedot automaattisesti ja vastaavia voi tehdä ohjelmaan helposti vaikka väliaikaisesti, joten kerro mihin olet itse käyttänyt pointtereilla tehtyä binääripuuta? Ja pätkä ohjelmakoodiasi mukaan.

Lue lisää

Tottakai pointterit antavat lisämahdollisuuksia etenkin niille jotka ne hyvin hallitsevat (Niille jotka hyvin hallisevat pointterit niin heidän ohjelmat saattavat näyttää aivan toisenlaisilta). Pointtereita voi myös sekoittaa olio-ohjelmoitiin joilloin saadaan yksi "sävy" lisää.

FreePascal kirjoitti:

Tottakai pointterit antavat lisämahdollisuuksia etenkin niille jotka ne hyvin hallitsevat (Niille jotka hyvin hallisevat pointterit niin heidän ohjelmat saattavat näyttää aivan toisenlaisilta). Pointtereita voi myös sekoittaa olio-ohjelmoitiin joilloin saadaan yksi "sävy" lisää.

Lue lisää

"Pointtereita voi myös sekoittaa olio-ohjelmoitiin joilloin saadaan yksi "sävy" lisää."

Tietokoneohjelmien tekeminen loogisesti ja selkeästi, jotta myös muut voivat niitä ylläpitää, on yksi tärkeimmistä koodiasioista. Joten ei ole mielekästä tuoda lisää sekoittavia asioita koodiin.

Kerro yksi esimerkkikoodi, jonka olet itse tehnyt ja jossa käytetään pointtereita olio-ohjelmoinnissa, niin käsitellään sitä onko koodin teko sinun mainitsemallasi tavalla järkevää.

xxxxxx kirjoitti:

"Pointtereita voi myös sekoittaa olio-ohjelmoitiin joilloin saadaan yksi "sävy" lisää."

Tietokoneohjelmien tekeminen loogisesti ja selkeästi, jotta myös muut voivat niitä ylläpitää, on yksi tärkeimmistä koodiasioista. Joten ei ole mielekästä tuoda lisää sekoittavia asioita koodiin.

Kerro yksi esimerkkikoodi, jonka olet itse tehnyt ja jossa käytetään pointtereita olio-ohjelmoinnissa, niin käsitellään sitä onko koodin teko sinun mainitsemallasi tavalla järkevää.

Lue lisää

Tuota oliota pointtereiden päässä olevaa tyyliä käytetään myös paljon Cplusplus ohjelmoijien keskuudessa. Eli täm tapa on yleistä ohjelmointitekniikkaa kielissä joissa on pointterit ja oliot

Tunnettavuus kirjoitti:

Tuota oliota pointtereiden päässä olevaa tyyliä käytetään myös paljon Cplusplus ohjelmoijien keskuudessa. Eli täm tapa on yleistä ohjelmointitekniikkaa kielissä joissa on pointterit ja oliot

Lue lisää

Kerro yksi esimerkkikoodi Delphillä, jonka olet itse tehnyt ja jossa käytetään pointtereita olio-ohjelmoinnissa, niin käsitellään sitä onko koodin teko sinun mainitsemallasi tavalla järkevää.

Esitin saman vaatimuksen edellisessä viestissä edelliselle kirjoittajalle, joten jos sinä siihen kerta vastasit, niin vastaa myös vaatimukseeni äläkä muuta puheenaihetta tai ala käsitellä asiaa puhumalla jostain yleisestä asiasta.

Lazarus on itsellään (pascalia) tehty ohjelmointiympäristö (sovelluskehitys-periaate) joka toimii useassa käyttöjärjestelmässä (Se käännetään samoista lähdekoodista jokaiselle käyttöjärjestelmälle erikseen. Se ei käytä mitään välikoodia).

Tutustu ihan vapaasti (kaikki lähdekoodit on mukana).

https://sourceforge.net/project/showfiles.php?group_id=89339

Delphi on ns hybridikieli eli se on sekä oliokieli että proseduraalinen ohjelmointikieli.

Tarjolla on siis myös pelkkiä oliokieliä jolloin kaikki asiat tehdään olioilla. Delphissä voi näin tehdä mutta välttämättä ei niin tarvitse tehdä. Voit myös sekoittaa olio-ohjelmointia muun koodin joukkoon kun näät sen hyväksi.


Miksi siis Delphi siksi että pääset mm helposti tutustumaan olio-ohjelmointiin.

Delphi on nopea! kirjoitti:

Delphi on ns hybridikieli eli se on sekä oliokieli että proseduraalinen ohjelmointikieli.

Tarjolla on siis myös pelkkiä oliokieliä jolloin kaikki asiat tehdään olioilla. Delphissä voi näin tehdä mutta välttämättä ei niin tarvitse tehdä. Voit myös sekoittaa olio-ohjelmointia muun koodin joukkoon kun näät sen hyväksi.


Miksi siis Delphi siksi että pääset mm helposti tutustumaan olio-ohjelmointiin.

Lue lisää

"Delphi on ns hybridikieli eli se on sekä oliokieli että proseduraalinen ohjelmointikieli."

Luuletko todella että olet fiksu käyttäessäsi erikoisia käsitteitä? Jos tietäisit ohjelmoinnista, niin niiden käyttö olisi ok, mutta kun sinä vain luet jostain jotain asiaan liittyvää ja sitten käytät niitä väärin. Siis tyhmästi.

Wikipedian mukaan http://fi.wikipedia.org/wiki/Proseduraalinen_ohjelmointikieli proseduraalinen ohjelmointikieli on tällaista:
"Ohjelmointi proseduraalisella tavalla on tehtävän jakamista osatehtäviin, ja näiden jakamista edelleen, kunnes tuloksena on niin yksinkertaisia tehtäviä, että ne voidaan suoraan kirjoittaa ohjelmariviksi."

Samoin toimii olio-ohjelmointikin, jossa oliot koodataan ohjelmariveinä. Ymmärrätkö edes vieläkään kuinka typerä on väitteesi että olio-kieli olisi jotain hirveän paljon erinomaisempaa kuin "tavalliset" ohjelmointikielet? Sinun tavalla olio-ohjelmointikieltä kehuvat vain sellaiset henkilöt, jotka eivät tiedä ohjelmoinnista juuri mitään.


"Tarjolla on siis myös pelkkiä oliokieliä jolloin kaikki asiat tehdään olioilla."

Tarkoitatko ettei niissä olioita kuitenkin koodata suurimmaksi osaksi perinteisellä koodaustavalla?



"Miksi siis Delphi siksi että pääset mm helposti tutustumaan olio-ohjelmointiin."

Sinä jankutat ja toistat samoja vastauksiasi. Jos yrität keskustella olio-ohjelmoinnista (tai mistä tahansa), niin yritä edes olla johdonmukainen äläkä jankuta samoja mitäänsanomattomia lauseita. Tuota samaa siis olet toistanut ikäänkuin olio-ohjelmointiin ei voisi tutustua yhtä helposti Visual Basicilla.



Kun olet kehunut Delphiä, niin miksi et vastannut näihin edellisessä viestissäni oleviin kysymyksiin:

Miksi minä vaihtaisin Visual Basicin Delpiin? Mitä etuja se minulle ohjelmien tekemisessä toisi?

xxxxx kirjoitti:

"Delphi on ns hybridikieli eli se on sekä oliokieli että proseduraalinen ohjelmointikieli."

Luuletko todella että olet fiksu käyttäessäsi erikoisia käsitteitä? Jos tietäisit ohjelmoinnista, niin niiden käyttö olisi ok, mutta kun sinä vain luet jostain jotain asiaan liittyvää ja sitten käytät niitä väärin. Siis tyhmästi.

Wikipedian mukaan http://fi.wikipedia.org/wiki/Proseduraalinen_ohjelmointikieli proseduraalinen ohjelmointikieli on tällaista:
"Ohjelmointi proseduraalisella tavalla on tehtävän jakamista osatehtäviin, ja näiden jakamista edelleen, kunnes tuloksena on niin yksinkertaisia tehtäviä, että ne voidaan suoraan kirjoittaa ohjelmariviksi."

Samoin toimii olio-ohjelmointikin, jossa oliot koodataan ohjelmariveinä. Ymmärrätkö edes vieläkään kuinka typerä on väitteesi että olio-kieli olisi jotain hirveän paljon erinomaisempaa kuin "tavalliset" ohjelmointikielet? Sinun tavalla olio-ohjelmointikieltä kehuvat vain sellaiset henkilöt, jotka eivät tiedä ohjelmoinnista juuri mitään.


"Tarjolla on siis myös pelkkiä oliokieliä jolloin kaikki asiat tehdään olioilla."

Tarkoitatko ettei niissä olioita kuitenkin koodata suurimmaksi osaksi perinteisellä koodaustavalla?



"Miksi siis Delphi siksi että pääset mm helposti tutustumaan olio-ohjelmointiin."

Sinä jankutat ja toistat samoja vastauksiasi. Jos yrität keskustella olio-ohjelmoinnista (tai mistä tahansa), niin yritä edes olla johdonmukainen äläkä jankuta samoja mitäänsanomattomia lauseita. Tuota samaa siis olet toistanut ikäänkuin olio-ohjelmointiin ei voisi tutustua yhtä helposti Visual Basicilla.



Kun olet kehunut Delphiä, niin miksi et vastannut näihin edellisessä viestissäni oleviin kysymyksiin:

Miksi minä vaihtaisin Visual Basicin Delpiin? Mitä etuja se minulle ohjelmien tekemisessä toisi?

Lue lisää

""Tarjolla on siis myös pelkkiä oliokieliä jolloin kaikki asiat tehdään olioilla."

Tarkoitatko ettei niissä olioita kuitenkin koodata suurimmaksi osaksi perinteisellä koodaustavalla?
"

Puhtaissa oliokielissä ei ole samankaltaisia rakenteita kuin esim. Pascalissa ja C . Niissä kaikki tosiaankin tehdään olioilla.

Olio-ohjelmoinnin ensimmäinen asia on periytyvyys (kun kielessä on periytyvyys voidaan puhua oliokielestä). Juuri periytyvyys tuo uusia mahdollisuuksia.

xxxxx kirjoitti:

"Delphi on ns hybridikieli eli se on sekä oliokieli että proseduraalinen ohjelmointikieli."

Luuletko todella että olet fiksu käyttäessäsi erikoisia käsitteitä? Jos tietäisit ohjelmoinnista, niin niiden käyttö olisi ok, mutta kun sinä vain luet jostain jotain asiaan liittyvää ja sitten käytät niitä väärin. Siis tyhmästi.

Wikipedian mukaan http://fi.wikipedia.org/wiki/Proseduraalinen_ohjelmointikieli proseduraalinen ohjelmointikieli on tällaista:
"Ohjelmointi proseduraalisella tavalla on tehtävän jakamista osatehtäviin, ja näiden jakamista edelleen, kunnes tuloksena on niin yksinkertaisia tehtäviä, että ne voidaan suoraan kirjoittaa ohjelmariviksi."

Samoin toimii olio-ohjelmointikin, jossa oliot koodataan ohjelmariveinä. Ymmärrätkö edes vieläkään kuinka typerä on väitteesi että olio-kieli olisi jotain hirveän paljon erinomaisempaa kuin "tavalliset" ohjelmointikielet? Sinun tavalla olio-ohjelmointikieltä kehuvat vain sellaiset henkilöt, jotka eivät tiedä ohjelmoinnista juuri mitään.


"Tarjolla on siis myös pelkkiä oliokieliä jolloin kaikki asiat tehdään olioilla."

Tarkoitatko ettei niissä olioita kuitenkin koodata suurimmaksi osaksi perinteisellä koodaustavalla?



"Miksi siis Delphi siksi että pääset mm helposti tutustumaan olio-ohjelmointiin."

Sinä jankutat ja toistat samoja vastauksiasi. Jos yrität keskustella olio-ohjelmoinnista (tai mistä tahansa), niin yritä edes olla johdonmukainen äläkä jankuta samoja mitäänsanomattomia lauseita. Tuota samaa siis olet toistanut ikäänkuin olio-ohjelmointiin ei voisi tutustua yhtä helposti Visual Basicilla.



Kun olet kehunut Delphiä, niin miksi et vastannut näihin edellisessä viestissäni oleviin kysymyksiin:

Miksi minä vaihtaisin Visual Basicin Delpiin? Mitä etuja se minulle ohjelmien tekemisessä toisi?

Lue lisää

Laadukkaat kielet kuten Delphi ( Pascal, C jne) tarjoavat myös poikkeukset. Eli mahdollisuuden toipua virhetilanteissa poikkeuksien avulla.

Delphi on nopea! kirjoitti:

""Tarjolla on siis myös pelkkiä oliokieliä jolloin kaikki asiat tehdään olioilla."

Tarkoitatko ettei niissä olioita kuitenkin koodata suurimmaksi osaksi perinteisellä koodaustavalla?
"

Puhtaissa oliokielissä ei ole samankaltaisia rakenteita kuin esim. Pascalissa ja C . Niissä kaikki tosiaankin tehdään olioilla.

Olio-ohjelmoinnin ensimmäinen asia on periytyvyys (kun kielessä on periytyvyys voidaan puhua oliokielestä). Juuri periytyvyys tuo uusia mahdollisuuksia.

Lue lisää

"Olio-ohjelmoinnin ensimmäinen asia on periytyvyys (kun kielessä on periytyvyys voidaan puhua oliokielestä). Juuri periytyvyys tuo uusia mahdollisuuksia."

Kerro mitä uusia mahdollisuuksia koodin periytyvyys on sinulle ohjelmoinnissa tuonut. Mainitse jokin käytännön esimerkki, jonka olet hoitanut periytyvyydellä. Sellainen joka ilman periytyvyyttä olisi ollut vaikeata tai mahdotonta hoitaa.

Delphi on nopea! kirjoitti:

Laadukkaat kielet kuten Delphi ( Pascal, C jne) tarjoavat myös poikkeukset. Eli mahdollisuuden toipua virhetilanteissa poikkeuksien avulla.

Jatkat edelleen samalla yleisellä huuhaa-linjalla, joka ei tarkoita mitään.

Mainitse jokin ohjelmointikieli, jossa ei ole mahdollisuutta toipua virhetilanteissa poikkeuksien avulla?

Sinä puhut virhetilanteista toipumisesta kuin uskonnosta. Olen jo aikaisemmin sanonut että et ole tehnyt yhtään oikeata tietokoneohjelmaa ja toistan sen nyt. Jos olisit koodannut, niin tietäisit että virhetilanteiden käsittely täytyy määritellä tapauskohtaisesti. Toki on hyvä että voidaan määritellä virhetilanteessa ohjelman menevän virheosaan, mutta ei ohjelmointikieli itsessään virhetilanteita voi korjata. Tietysti voidaan jättää jokin toiminto tekemättä, mutta jos se on mielestäsi toipumista virhetilanteesta, niin olet totaalisen väärässä. Jos yhden virheen yli hypätään, niin se saattaa aiheuttaa vakavampia virheitä, esim. laskennassa josta jätetään yksi käsky suorittamatta.

Käytätkö jotain puppulausegeneraattoria noiden mitäänsanomattomien yleisten tekstiesi tekemiseen? Yksi puppulausegeneraattori löytyy sivulta http://puppulausegeneraattori.fi/

xxxxx kirjoitti:

Jatkat edelleen samalla yleisellä huuhaa-linjalla, joka ei tarkoita mitään.

Mainitse jokin ohjelmointikieli, jossa ei ole mahdollisuutta toipua virhetilanteissa poikkeuksien avulla?

Sinä puhut virhetilanteista toipumisesta kuin uskonnosta. Olen jo aikaisemmin sanonut että et ole tehnyt yhtään oikeata tietokoneohjelmaa ja toistan sen nyt. Jos olisit koodannut, niin tietäisit että virhetilanteiden käsittely täytyy määritellä tapauskohtaisesti. Toki on hyvä että voidaan määritellä virhetilanteessa ohjelman menevän virheosaan, mutta ei ohjelmointikieli itsessään virhetilanteita voi korjata. Tietysti voidaan jättää jokin toiminto tekemättä, mutta jos se on mielestäsi toipumista virhetilanteesta, niin olet totaalisen väärässä. Jos yhden virheen yli hypätään, niin se saattaa aiheuttaa vakavampia virheitä, esim. laskennassa josta jätetään yksi käsky suorittamatta.

Käytätkö jotain puppulausegeneraattoria noiden mitäänsanomattomien yleisten tekstiesi tekemiseen? Yksi puppulausegeneraattori löytyy sivulta http://puppulausegeneraattori.fi/

Lue lisää

Täytyy ihmetellä jos teet ohjelmia ja pidät poikkeuksia ihan huuhaa juttuna.
Oletko koskaan miettinyt miksi ne ovat niin monissa kielissä?

Tunnettavuus kirjoitti:

Täytyy ihmetellä jos teet ohjelmia ja pidät poikkeuksia ihan huuhaa juttuna.
Oletko koskaan miettinyt miksi ne ovat niin monissa kielissä?

Tietysti ohjelmoinnissa otetaan huomioon mahdollisimman paljon ennakoitavia virhetilanteita. Etenkin windows-ohjelmoinnissa täytyy yrittää miettiä ja testata mitä kaikkea käyttäjä yhtä aikaa tekee, jotta ohjelma toimii joustavasti eikä kaadu.

Enkö muka kirjoittanut kyllin selkeästi edellisessä viestissäni:
Jos olisit koodannut, niin tietäisit että virhetilanteiden käsittely täytyy määritellä tapauskohtaisesti. Toki on hyvä että voidaan määritellä virhetilanteessa ohjelman menevän virheosaan, mutta ei ohjelmointikieli itsessään virhetilanteita voi korjata.


Jos sinäkin tekisit ohjelmia työksesi, niin ymmärtäisit että ohjelmointikieli ei millään tekoälyllä korjaa ongelmia. Tai jos yleensä tekisit ohjelmia. Ohjelmakoodi on yksittäisiä yksityiskohtaisia ohjeita, eli koodirivejä joissa ei ole mitään mystistä eikä ole mahdollista koodata sellaista riviä, että "kun tulee poikkeustapaus, niin korjaa virhe".

Ohjelma on ennalta kirjoitettuja tarkkoja ohjelmarivejä. Tämän pitäisi olla selvää. Ainakin kaikille niille, jotka tällä palstalla kirjoittavat.

xxxxx kirjoitti:

Jatkat edelleen samalla yleisellä huuhaa-linjalla, joka ei tarkoita mitään.

Mainitse jokin ohjelmointikieli, jossa ei ole mahdollisuutta toipua virhetilanteissa poikkeuksien avulla?

Sinä puhut virhetilanteista toipumisesta kuin uskonnosta. Olen jo aikaisemmin sanonut että et ole tehnyt yhtään oikeata tietokoneohjelmaa ja toistan sen nyt. Jos olisit koodannut, niin tietäisit että virhetilanteiden käsittely täytyy määritellä tapauskohtaisesti. Toki on hyvä että voidaan määritellä virhetilanteessa ohjelman menevän virheosaan, mutta ei ohjelmointikieli itsessään virhetilanteita voi korjata. Tietysti voidaan jättää jokin toiminto tekemättä, mutta jos se on mielestäsi toipumista virhetilanteesta, niin olet totaalisen väärässä. Jos yhden virheen yli hypätään, niin se saattaa aiheuttaa vakavampia virheitä, esim. laskennassa josta jätetään yksi käsky suorittamatta.

Käytätkö jotain puppulausegeneraattoria noiden mitäänsanomattomien yleisten tekstiesi tekemiseen? Yksi puppulausegeneraattori löytyy sivulta http://puppulausegeneraattori.fi/

Lue lisää

"Mainitse jokin ohjelmointikieli, jossa ei ole mahdollisuutta toipua virhetilanteissa poikkeuksien avulla? "

Esim. C (poikkeukset siis ovat C :ssa, Delphissä, Pascalissa jne)

Delphi on nopea! kirjoitti:

"Mainitse jokin ohjelmointikieli, jossa ei ole mahdollisuutta toipua virhetilanteissa poikkeuksien avulla? "

Esim. C (poikkeukset siis ovat C :ssa, Delphissä, Pascalissa jne)

Lue lisää

"Esim. C (poikkeukset siis ovat C :ssa, Delphissä, Pascalissa jne)"

Mistä tuon luit? Koska ilmeisesti et ole ikinä tehnyt tietokoneohjelmia, niin miksi heität edelleen tuollaisia outoja heittoja. Siis jos lainaat käsitteitä jostain sivuilta, niin kerro mistä ne on peräisin.

Toistan sen, mitä edellisessä vastauksessani sinulle sanoin:
Sinä puhut virhetilanteista toipumisesta kuin uskonnosta. Olen jo aikaisemmin sanonut että et ole tehnyt yhtään oikeata tietokoneohjelmaa ja toistan sen nyt. Jos olisit koodannut, niin tietäisit että virhetilanteiden käsittely täytyy määritellä tapauskohtaisesti.

Kerro mitä tarkoitat poikkeuksilla. Ja jos ne tiedot on jostain nettisivulta niin laita linkki sinne.

Ja vastaa tähän kysymykseen: Oletko ikinä itse tehnyt yhtään tietokoneohjelmaa?

xxxxx kirjoitti:

Tietysti ohjelmoinnissa otetaan huomioon mahdollisimman paljon ennakoitavia virhetilanteita. Etenkin windows-ohjelmoinnissa täytyy yrittää miettiä ja testata mitä kaikkea käyttäjä yhtä aikaa tekee, jotta ohjelma toimii joustavasti eikä kaadu.

Enkö muka kirjoittanut kyllin selkeästi edellisessä viestissäni:
Jos olisit koodannut, niin tietäisit että virhetilanteiden käsittely täytyy määritellä tapauskohtaisesti. Toki on hyvä että voidaan määritellä virhetilanteessa ohjelman menevän virheosaan, mutta ei ohjelmointikieli itsessään virhetilanteita voi korjata.


Jos sinäkin tekisit ohjelmia työksesi, niin ymmärtäisit että ohjelmointikieli ei millään tekoälyllä korjaa ongelmia. Tai jos yleensä tekisit ohjelmia. Ohjelmakoodi on yksittäisiä yksityiskohtaisia ohjeita, eli koodirivejä joissa ei ole mitään mystistä eikä ole mahdollista koodata sellaista riviä, että "kun tulee poikkeustapaus, niin korjaa virhe".

Ohjelma on ennalta kirjoitettuja tarkkoja ohjelmarivejä. Tämän pitäisi olla selvää. Ainakin kaikille niille, jotka tällä palstalla kirjoittavat.

Lue lisää

"kun tulee poikkeustapaus, niin korjaa virhe" juuri tätähän (yleisesti ottaen) poikkeuksilla tehdään.

Kannattaisi tutustua poikkeuksiin. Poikkeuksetkaan ei ole enään mikään uusi asia.
Poikkeukset ovat olleet aina Delphissä.

Tunnettavuus kirjoitti:

"kun tulee poikkeustapaus, niin korjaa virhe" juuri tätähän (yleisesti ottaen) poikkeuksilla tehdään.

Kannattaisi tutustua poikkeuksiin. Poikkeuksetkaan ei ole enään mikään uusi asia.
Poikkeukset ovat olleet aina Delphissä.

Lue lisää

>...ovat olleet aina Delphissä.

Kuten kaikissa muissakin.

Tunnettavuus kirjoitti:

"kun tulee poikkeustapaus, niin korjaa virhe" juuri tätähän (yleisesti ottaen) poikkeuksilla tehdään.

Kannattaisi tutustua poikkeuksiin. Poikkeuksetkaan ei ole enään mikään uusi asia.
Poikkeukset ovat olleet aina Delphissä.

Lue lisää

Käsitettä "poikkeukset" en ollut aikaisemmin kuullut, mutta oletin sen tarkoittavan juuri virheiden korjausta. Muutama viesti ylempänä sai minut epäilemään, että olisko se tarkoittanut muutakin.

Tuossa edellisessä viestissä jo mainittiin, että virhetilanteiden korjaukset on kaikissa ohjelmointikielissä. Niin on aina ollut ja niin on aina oleva. Tietysti, sillä ohjelmointihan on suurelta osalta juuri poikkeustapausten miettimistä, että ohjelma toimisi kaikissa tilanteissa. Esim. kun ohjelma kysyy päivämäärää, niin sen jälkeen ohjelma tarkastaa päivämäärän oikeellisuuden ja raja-arvot. Virhetilanteessa pyydetään uusi päivämäärä. Esim. palkanlaskentaohjelmassa voidaan tehdä tarkistus että työntekijä ei saa olla yli 100 vuotta vanha. Tuollaisia tarkastuksia ohjelmat on täynnä. Tarkastukset täytyy kuitenkin aina määritellä ennalta ohjelmakoodiin, sillä ei mikään ohjelmointikieli voi älykkäästi suorittaa virhekorjauksia ilman ennalta määriteltyä koodia.

Tämä tekstini on täysin selvää kaikille ohjelmoijille, mutta vaikka miten yksinkertaisesti yritän selittää asian tällä palstalla oleville "asiantuntijoille", niin ei tunnu menevän perille.

Joten noudattakaa tuota edellisen kirjoittajan ohjetta, että kannattaa tutustua ohjelmointiin ennenkuin alkaa vänkäämään ohjelmoijan kanssa.

1980-luvulla alkoi yrityksiin tulla kaikenlaista organisaatiokaaviota ja muuta sellaista, jotka loppujenlopuksi olivat vain uusia käsitteitä vanhoille toimille.

Tietokonealallakin niitä on ollut paljon.

Esim. oliotietokannat tulivat 1980-luvulla ja silloinkin niitä hehkuttivat lähinnä sellaiset jotka eivät paljoa ohjelmoinnista tajunneet. Kun kysyi miten oliotietokannat poikkesivat vanhoista tietokannoista (tiedostot, tietueet, tietokentät), niin vastauksesta ei jäänyt yhtään mitään muuta käteen kuin että vanhoille käsitteille oli tehty uudet nimet (taulut, rivit, sarakkeet).

Toinen esimerkki on olio-ohjelmointi. 1980-luvulla sitäkin hehkutettiin, mutta ei silloinkaan vastattu kysymykseen, miten oliot poikkeavat aliohjelmista. Olioiden erinomaisuudesta julistaminen sitten vähitellen hiipui.

Tuosta edellisestä tuli vielä mieleen se, kun 1980-luvulla olin toissä tietokoneita myyvässä putiikissa ohjelmoijana ja ne myivät myös UNIX-koneita. Niiden asiantuntija kehui unixin olevan käyttöjärjestelmä, joka syrjäyttää muut käyttöjärjestelmät, koska se on niitä niin paljon parempi. Siihen sitten kommentoi yliopistossa 1960-luvulla opiskellut, että unix oli samassa tilanteessa jo 1960-luvulla ja siitä piti tulla hallitseva käyttöjärjestelmä paremmuutensa takia. Nyt joillain on vielä samanlaisia kuvitelmia Linuxista (unix), mutta ei siitäkään mitään tule.

Samaa sitten puhutaan Delphistä, joka on kyllä hyvä ohjelmointikieli, ei siinä mittään, mutta kokonaisuutena se on kuitenkin samantasoa kuin muutkin markkinoiden parhaimmat kehittimet, kuten Visual Basic. Yhtä loistavia molemmat. Erinomaisia välineitä ohjelmien tekemiseen.

xxxxx kirjoitti:

"Esim. C (poikkeukset siis ovat C :ssa, Delphissä, Pascalissa jne)"

Mistä tuon luit? Koska ilmeisesti et ole ikinä tehnyt tietokoneohjelmia, niin miksi heität edelleen tuollaisia outoja heittoja. Siis jos lainaat käsitteitä jostain sivuilta, niin kerro mistä ne on peräisin.

Toistan sen, mitä edellisessä vastauksessani sinulle sanoin:
Sinä puhut virhetilanteista toipumisesta kuin uskonnosta. Olen jo aikaisemmin sanonut että et ole tehnyt yhtään oikeata tietokoneohjelmaa ja toistan sen nyt. Jos olisit koodannut, niin tietäisit että virhetilanteiden käsittely täytyy määritellä tapauskohtaisesti.

Kerro mitä tarkoitat poikkeuksilla. Ja jos ne tiedot on jostain nettisivulta niin laita linkki sinne.

Ja vastaa tähän kysymykseen: Oletko ikinä itse tehnyt yhtään tietokoneohjelmaa?

Lue lisää

Siis väittänet että mm C:stä ja VB:stä löytynevät poikkeukset. Kerroppa mitä kyseisen kielen varattuja sanoja käytetään kun halutaan käyttää poikkeuksia?

ohjelmointiin kirjoitti:

>...ovat olleet aina Delphissä.

Kuten kaikissa muissakin.

Jos väittänet että poikkeukset löytyy kaikista kielistä. Tiedät varmaan että ohjelmointikieliä on useita kymmeniä. Kuvittelisin että osaat kertoa aika monista kielistä niiden poikkeukselle varatuista sanoista. Voit kirjoittaa ne tähän alle tai sitten tuonne alas johon saadaan kooste eri kielten poikkeuksista.

Delphi on nopea! kirjoitti:

Laadukkaat kielet kuten Delphi ( Pascal, C jne) tarjoavat myös poikkeukset. Eli mahdollisuuden toipua virhetilanteissa poikkeuksien avulla.

Kerätään tähän nyt ne kielet joissa on poikkeukset ja niiden varatut sanat.
Itse voin kertoa että Pascalit kuten Delphi, Lazarus ja FreePascal käyttää
rakenteita try ... except ja try ... finally

- Pascal (Delphi, Lazarus, FreePascal) try - except ja try - finally
- C :sta löytyy rakenne try - catch
- Java :sta löytyy rakenne try - catch
- Python try - except ja try - finally

(kertokaa lisää)

Delphi on nopea! kirjoitti:

Kerätään tähän nyt ne kielet joissa on poikkeukset ja niiden varatut sanat.
Itse voin kertoa että Pascalit kuten Delphi, Lazarus ja FreePascal käyttää
rakenteita try ... except ja try ... finally

- Pascal (Delphi, Lazarus, FreePascal) try - except ja try - finally
- C :sta löytyy rakenne try - catch
- Java :sta löytyy rakenne try - catch
- Python try - except ja try - finally

(kertokaa lisää)

Lue lisää

Noista sinun mainitsemista (try-except-finally) sanoista löytyy sivulta http://www.python.org/dev/peps/pep-0341/ esimerkki:

f = None
try:
try:
f = open(filename)
text = f.read()
except IOError:
print 'An error occurred'
finally:
if f:
f.close()


Käytät sanaa "poikkeukset" virheiden käsittelystä. Pythonissa, Delphissä ja pascaleissa voidaan ilmeisesti käyttää myös tuota rakennetta, mutta jos sinä olisit joskus ohjelmoinnut, niin tietäisit että sama onnistuu kaikissa, siis kaikissa, ohjelmointikielissä jollain tavoilla. Myös C-kielessä ja Assembly-kielissä. Visual Basicissa voidaan myös On error goto -käskyllä suorittaa virhetilanteessa haluttu toiminto. Tai On error resume next -käskyllä ja sitten saadaan virhe numerona Err-koodilla ja tekstinä Error$-muuttujasta.

Tuosta koodista käy myös hyvin ilmi se, että poikkeukset tarkoittavat vain tavallista koodia, jossa varaudutaan virheisiin. Eli poikkeukset tekevät vain sen, jota niiden on määritelty tehtävän. Näinhän ohjelmoinnissa on aina: Ohjelmakoodi täytyy aina kirjoittaa ensin. Joissain kielissä tiedoston avaus palauttaa jollain muulla tavalla koodin siitä, onnistuiko avaus. Siihen voidaan puuttua esim. If then print "Eipä onnistunut tiedoston avaus". Käytettävä koodaustapa on erilainen, mutta lopputulos on sama.

Tuossa ylempänä kohdassa http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000646&posting=22000000017801139 sanoin, että tietokoneala on täynnä erilaisia käsitteitä, jotka kuitenkin tarkoittavat samaa. Eli poikkeustilanteiden (virhetilanteiden) käsittely on KAIKISSA ohjelmointikielissä, mutta KAIKISSA ohjelmointikielissä pitää poikkeustilanteet ymmärtää etukäteen ja tehdä etukäteen niitä varten käsittelykoodi.

Yritän vielä selittää mahdollisimman yksinkertaisesti, että jokaisessa ohjelmointikielessä on virheiden käsittelyyn (tai käytetään niistä vaikka nimeä poikkeukset), sillä ilman tuota toimintaa on ohjelmaa mahdotonta tehdä. Esim. kun syötetään ohjelmaan jokin arvo, on oltava mahdollista tarkastaa pystytäänkö sitä käsittelemään (esim. kaikissa ohjelmointikielissä voidaan tarkastaa onko syötetty luku nolla, jolloin sillä ei voi suorittaa jakolaskua). Wikipedian mukaan "Z3 oli ensimmäinen täysautomaattinen ohjelmoitava tietojenkäsittelykone eli tietokone. Sen suunnitteli ja rakensi saksalainen Konrad Zuse." http://fi.wikipedia.org/wiki/Z3 Vaikka se toimi releillä, niin pakko siinäkin oli olla virheiden (poikkeusten) käsittely, esim. ettei se tiltannut kun laskettavaksi oli annettu liian suuri luku.

Selitän vielä tuon edellisen toisesta näkökulmasta, jotta kenellekään ei jää siitä mitään epäselvää. Sivulla http://www.delphibasics.co.uk/RTL.asp?Name=Finally on esimerkki Delphi-koodista, jossa Try-osassa suoritetaan jakolasku nollalla ja Finally-osassa tarkastetaan tuliko virhe. Tuossa vasta virheen jälkeen käsitellään virhe. Missä tahansa, eli kaikissa ohjelmointikielissä, voidaan tarkastaa onko syötetty arvoksi nolla, jolla ei voida jakaa. Eli varaudutaan poikkeuksiin. Tuossa Delphin esimerkissä poikkeusta varten on kirjoitettu koodia samalla tavalla kuin aina täytyy kirjoittaa koodia etukäteen kutakin poikkeusta varten. Eli vaikka eri ohjelmointikielissä käytetään erinimisiä käskyjä, niin niiden taustalla on sama logiikka.

Ymmärrätkö nyt, että kaikissa ohjelmointikielissä on virhetilanteiden (poikkeusten) käsittely, mutta ei ne toimi automaattisesti vaan niitä varten täytyy kirjoittaa ohjelmakoodia?

xxxxx kirjoitti:

Noista sinun mainitsemista (try-except-finally) sanoista löytyy sivulta http://www.python.org/dev/peps/pep-0341/ esimerkki:

f = None
try:
try:
f = open(filename)
text = f.read()
except IOError:
print 'An error occurred'
finally:
if f:
f.close()


Käytät sanaa "poikkeukset" virheiden käsittelystä. Pythonissa, Delphissä ja pascaleissa voidaan ilmeisesti käyttää myös tuota rakennetta, mutta jos sinä olisit joskus ohjelmoinnut, niin tietäisit että sama onnistuu kaikissa, siis kaikissa, ohjelmointikielissä jollain tavoilla. Myös C-kielessä ja Assembly-kielissä. Visual Basicissa voidaan myös On error goto -käskyllä suorittaa virhetilanteessa haluttu toiminto. Tai On error resume next -käskyllä ja sitten saadaan virhe numerona Err-koodilla ja tekstinä Error$-muuttujasta.

Tuosta koodista käy myös hyvin ilmi se, että poikkeukset tarkoittavat vain tavallista koodia, jossa varaudutaan virheisiin. Eli poikkeukset tekevät vain sen, jota niiden on määritelty tehtävän. Näinhän ohjelmoinnissa on aina: Ohjelmakoodi täytyy aina kirjoittaa ensin. Joissain kielissä tiedoston avaus palauttaa jollain muulla tavalla koodin siitä, onnistuiko avaus. Siihen voidaan puuttua esim. If then print "Eipä onnistunut tiedoston avaus". Käytettävä koodaustapa on erilainen, mutta lopputulos on sama.

Tuossa ylempänä kohdassa http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000646&posting=22000000017801139 sanoin, että tietokoneala on täynnä erilaisia käsitteitä, jotka kuitenkin tarkoittavat samaa. Eli poikkeustilanteiden (virhetilanteiden) käsittely on KAIKISSA ohjelmointikielissä, mutta KAIKISSA ohjelmointikielissä pitää poikkeustilanteet ymmärtää etukäteen ja tehdä etukäteen niitä varten käsittelykoodi.

Yritän vielä selittää mahdollisimman yksinkertaisesti, että jokaisessa ohjelmointikielessä on virheiden käsittelyyn (tai käytetään niistä vaikka nimeä poikkeukset), sillä ilman tuota toimintaa on ohjelmaa mahdotonta tehdä. Esim. kun syötetään ohjelmaan jokin arvo, on oltava mahdollista tarkastaa pystytäänkö sitä käsittelemään (esim. kaikissa ohjelmointikielissä voidaan tarkastaa onko syötetty luku nolla, jolloin sillä ei voi suorittaa jakolaskua). Wikipedian mukaan "Z3 oli ensimmäinen täysautomaattinen ohjelmoitava tietojenkäsittelykone eli tietokone. Sen suunnitteli ja rakensi saksalainen Konrad Zuse." http://fi.wikipedia.org/wiki/Z3 Vaikka se toimi releillä, niin pakko siinäkin oli olla virheiden (poikkeusten) käsittely, esim. ettei se tiltannut kun laskettavaksi oli annettu liian suuri luku.

Selitän vielä tuon edellisen toisesta näkökulmasta, jotta kenellekään ei jää siitä mitään epäselvää. Sivulla http://www.delphibasics.co.uk/RTL.asp?Name=Finally on esimerkki Delphi-koodista, jossa Try-osassa suoritetaan jakolasku nollalla ja Finally-osassa tarkastetaan tuliko virhe. Tuossa vasta virheen jälkeen käsitellään virhe. Missä tahansa, eli kaikissa ohjelmointikielissä, voidaan tarkastaa onko syötetty arvoksi nolla, jolla ei voida jakaa. Eli varaudutaan poikkeuksiin. Tuossa Delphin esimerkissä poikkeusta varten on kirjoitettu koodia samalla tavalla kuin aina täytyy kirjoittaa koodia etukäteen kutakin poikkeusta varten. Eli vaikka eri ohjelmointikielissä käytetään erinimisiä käskyjä, niin niiden taustalla on sama logiikka.

Ymmärrätkö nyt, että kaikissa ohjelmointikielissä on virhetilanteiden (poikkeusten) käsittely, mutta ei ne toimi automaattisesti vaan niitä varten täytyy kirjoittaa ohjelmakoodia?

Lue lisää

Tuo try - finally tulkintasi oli väärä. Kyseisellä (delphi..) linkissä oli myös huono esimerkki.
Suosittelen että kokeilisit jotain kieltä missä on poikkeukset. Uskoisin että kokeiltuasi ja opittuasi käyttämään niitä (on helppo oppia) pidät todellakin niistä(kin).

Delphi on nopea! kirjoitti:

Laadukkaat kielet kuten Delphi ( Pascal, C jne) tarjoavat myös poikkeukset. Eli mahdollisuuden toipua virhetilanteissa poikkeuksien avulla.

Pascal:ssa on paljon englannin kielisiä sanoja (vrt c ).

Try - Finally voidaan suomentaa vaikka näin
Try - kokeile
Finally - lopuksi

Eli
- KOKEILE tätä (try-)lohkoa ja LOPUKSI tee tämä (finally-)lohko.


Tämä merkitsee sitä että normaali tapauksessa eli silloin kun poikkeuksia ei tule niin
tehdään kaikki nuo.

Selvennän tälläisellä esimerkillä

try
tehtävä1;
tehtävä2;
finally
tehtävä3;
end;


Siis tehtävä1, tehtävä2 ja tehtävä3 voi olla vaikkapa aliohjelmia.

Normaalisti tuossa tapauksessa tehdään tehtävä1, tehtävä2 ja tehtävä3.
Mutta jos poikkeus tapahtuu tehtävä1:ssä niin ei suoriteta tehtävä2 vaan siirrytään tehtävä3 tekemiseen.

Ideana tässä on siis (normaalisti) resurssien vapauttaminen tai sulkeminen (joka tapahtuu myös poikkeustilanteissa).

Delphi on nopea! kirjoitti:

Laadukkaat kielet kuten Delphi ( Pascal, C jne) tarjoavat myös poikkeukset. Eli mahdollisuuden toipua virhetilanteissa poikkeuksien avulla.

Try - Except on ehkäpä vähän enemmän käytetty poikkeuskäsittely (samantapainen kuin esim. C :n try - catch)

(except - sulje pois)

Eli
- KOKEILE tätä (try-)lohkoa ja SULJE POIS normaalisti tämä (except-)lohko.


Selvennän tälläisellä esimerkillä

try
tehtävä1;
tehtävä2;
except
tehtävä3;
end;

Normaalisti tuossa tapauksessa tehdään tehtävä1 ja tehtävä2.
Jos poikkeus tapahtuu tehtävä1:ssä niin ei tehdä tehtävä2 vaan mennään suoraan tehtävä3:n suorittamiseen (eli tehtävä3 tehdään vain poikkeustapauksissa).

xxxxx kirjoitti:

Noista sinun mainitsemista (try-except-finally) sanoista löytyy sivulta http://www.python.org/dev/peps/pep-0341/ esimerkki:

f = None
try:
try:
f = open(filename)
text = f.read()
except IOError:
print 'An error occurred'
finally:
if f:
f.close()


Käytät sanaa "poikkeukset" virheiden käsittelystä. Pythonissa, Delphissä ja pascaleissa voidaan ilmeisesti käyttää myös tuota rakennetta, mutta jos sinä olisit joskus ohjelmoinnut, niin tietäisit että sama onnistuu kaikissa, siis kaikissa, ohjelmointikielissä jollain tavoilla. Myös C-kielessä ja Assembly-kielissä. Visual Basicissa voidaan myös On error goto -käskyllä suorittaa virhetilanteessa haluttu toiminto. Tai On error resume next -käskyllä ja sitten saadaan virhe numerona Err-koodilla ja tekstinä Error$-muuttujasta.

Tuosta koodista käy myös hyvin ilmi se, että poikkeukset tarkoittavat vain tavallista koodia, jossa varaudutaan virheisiin. Eli poikkeukset tekevät vain sen, jota niiden on määritelty tehtävän. Näinhän ohjelmoinnissa on aina: Ohjelmakoodi täytyy aina kirjoittaa ensin. Joissain kielissä tiedoston avaus palauttaa jollain muulla tavalla koodin siitä, onnistuiko avaus. Siihen voidaan puuttua esim. If then print "Eipä onnistunut tiedoston avaus". Käytettävä koodaustapa on erilainen, mutta lopputulos on sama.

Tuossa ylempänä kohdassa http://keskustelu.suomi24.fi/show.fcgi?category=108&conference=4500000000000646&posting=22000000017801139 sanoin, että tietokoneala on täynnä erilaisia käsitteitä, jotka kuitenkin tarkoittavat samaa. Eli poikkeustilanteiden (virhetilanteiden) käsittely on KAIKISSA ohjelmointikielissä, mutta KAIKISSA ohjelmointikielissä pitää poikkeustilanteet ymmärtää etukäteen ja tehdä etukäteen niitä varten käsittelykoodi.

Yritän vielä selittää mahdollisimman yksinkertaisesti, että jokaisessa ohjelmointikielessä on virheiden käsittelyyn (tai käytetään niistä vaikka nimeä poikkeukset), sillä ilman tuota toimintaa on ohjelmaa mahdotonta tehdä. Esim. kun syötetään ohjelmaan jokin arvo, on oltava mahdollista tarkastaa pystytäänkö sitä käsittelemään (esim. kaikissa ohjelmointikielissä voidaan tarkastaa onko syötetty luku nolla, jolloin sillä ei voi suorittaa jakolaskua). Wikipedian mukaan "Z3 oli ensimmäinen täysautomaattinen ohjelmoitava tietojenkäsittelykone eli tietokone. Sen suunnitteli ja rakensi saksalainen Konrad Zuse." http://fi.wikipedia.org/wiki/Z3 Vaikka se toimi releillä, niin pakko siinäkin oli olla virheiden (poikkeusten) käsittely, esim. ettei se tiltannut kun laskettavaksi oli annettu liian suuri luku.

Selitän vielä tuon edellisen toisesta näkökulmasta, jotta kenellekään ei jää siitä mitään epäselvää. Sivulla http://www.delphibasics.co.uk/RTL.asp?Name=Finally on esimerkki Delphi-koodista, jossa Try-osassa suoritetaan jakolasku nollalla ja Finally-osassa tarkastetaan tuliko virhe. Tuossa vasta virheen jälkeen käsitellään virhe. Missä tahansa, eli kaikissa ohjelmointikielissä, voidaan tarkastaa onko syötetty arvoksi nolla, jolla ei voida jakaa. Eli varaudutaan poikkeuksiin. Tuossa Delphin esimerkissä poikkeusta varten on kirjoitettu koodia samalla tavalla kuin aina täytyy kirjoittaa koodia etukäteen kutakin poikkeusta varten. Eli vaikka eri ohjelmointikielissä käytetään erinimisiä käskyjä, niin niiden taustalla on sama logiikka.

Ymmärrätkö nyt, että kaikissa ohjelmointikielissä on virhetilanteiden (poikkeusten) käsittely, mutta ei ne toimi automaattisesti vaan niitä varten täytyy kirjoittaa ohjelmakoodia?

Lue lisää

On totta että poikkeus on usein virhetilanne mutta sen ei tarvitse sitä olla.
Myös virhetilanteet voidaan hoitaa niin haluttaessa ilman poikkeuksiakin.

Sillä poikkeus on keino siirtää normaalista poikkeava toiminta toiselle tasolle.

Tämä ei ole niin hyvä esimerkki mutta tuon ilmi kuitenkin että poikkeuksen käytöllä sopivassa kohdassa voidaan rajoittaa esim. ohjelman käyttöä (eli tällöin kyseessä voisi olla ns trial-versio)

Delphi on nopea! kirjoitti:

Tuo try - finally tulkintasi oli väärä. Kyseisellä (delphi..) linkissä oli myös huono esimerkki.
Suosittelen että kokeilisit jotain kieltä missä on poikkeukset. Uskoisin että kokeiltuasi ja opittuasi käyttämään niitä (on helppo oppia) pidät todellakin niistä(kin).

Lue lisää

"Tuo try - finally tulkintasi oli väärä."

Kerro sitten mikä on oikea tulkinta? Kerro myös mikä kohta tulkinnastani oli väärä? Muutenkin ihmettelen miksi et täsmennä mikä väitteissäni on väärin. Olen tietokoneohjelmoija, joten ohjelmoinnista puhuttaessa ajattelen yksittäisiä käskyjä. Eli kerro mihin tekstiosaan viittaat ja perustele mikä siinä on väärin.



"Kyseisellä (delphi..) linkissä oli myös huono esimerkki."

Kerro linkki, jossa on parempi esimerkki.



"Suosittelen että kokeilisit jotain kieltä missä on poikkeukset. Uskoisin että kokeiltuasi ja opittuasi käyttämään niitä (on helppo oppia) pidät todellakin niistä(kin)."

Oletko sinä oppinut käyttämään niitä? Ohjelmoitko Delphillä? Laita pari esimerkkiä omista ohjelmistasi joissa olet käyttänyt try-except-finally -käskyä.

Tunnettavuus kirjoitti:

On totta että poikkeus on usein virhetilanne mutta sen ei tarvitse sitä olla.
Myös virhetilanteet voidaan hoitaa niin haluttaessa ilman poikkeuksiakin.

Sillä poikkeus on keino siirtää normaalista poikkeava toiminta toiselle tasolle.

Tämä ei ole niin hyvä esimerkki mutta tuon ilmi kuitenkin että poikkeuksen käytöllä sopivassa kohdassa voidaan rajoittaa esim. ohjelman käyttöä (eli tällöin kyseessä voisi olla ns trial-versio)

Lue lisää

"Sillä poikkeus on keino siirtää normaalista poikkeava toiminta toiselle tasolle."

Eli sama voidaan hoitaa kaikkien ohjelmointikielten sisältämällä if-then -käskyllä.


"Tämä ei ole niin hyvä esimerkki"

Kertoisitko sinäkin paremman esimerkin.

Delphi on nopea! kirjoitti:

Pascal:ssa on paljon englannin kielisiä sanoja (vrt c ).

Try - Finally voidaan suomentaa vaikka näin
Try - kokeile
Finally - lopuksi

Eli
- KOKEILE tätä (try-)lohkoa ja LOPUKSI tee tämä (finally-)lohko.


Tämä merkitsee sitä että normaali tapauksessa eli silloin kun poikkeuksia ei tule niin
tehdään kaikki nuo.

Selvennän tälläisellä esimerkillä

try
tehtävä1;
tehtävä2;
finally
tehtävä3;
end;


Siis tehtävä1, tehtävä2 ja tehtävä3 voi olla vaikkapa aliohjelmia.

Normaalisti tuossa tapauksessa tehdään tehtävä1, tehtävä2 ja tehtävä3.
Mutta jos poikkeus tapahtuu tehtävä1:ssä niin ei suoriteta tehtävä2 vaan siirrytään tehtävä3 tekemiseen.

Ideana tässä on siis (normaalisti) resurssien vapauttaminen tai sulkeminen (joka tapahtuu myös poikkeustilanteissa).

Lue lisää

"Pascal:ssa on paljon englannin kielisiä sanoja (vrt c )."

Suurin osa ohjelmointikielistä on englanninkielisiä, joten niiden kaikki kokonaiset sanat on englannista ja keksityt käskynimetkin pohjautuvat englantiin.



"Normaalisti tuossa tapauksessa tehdään tehtävä1, tehtävä2 ja tehtävä3. Mutta jos poikkeus tapahtuu tehtävä1:ssä niin ei suoriteta tehtävä2 vaan siirrytään tehtävä3 tekemiseen."

Tarkoitat samaa kuin jos tehtävä1:n jälkeen tarkastetaan tuliko virhe ennen tehtävä 2:n suoritusta. Eli basic-koodina:

tehtävä1
if Err=0 then tehtävä 2
tehtävä3

Visual Basicissa siihen menee 3 riviä, sinun pascal-esimerkissä tuplamäärä eli 6 riviä.


"Ideana tässä on siis (normaalisti) resurssien vapauttaminen tai sulkeminen (joka tapahtuu myös poikkeustilanteissa)."

Tätä en ymmärrä lainkaan. Mitä resursseja tuolla vapautetaan tai suljetaan?

xxxxx kirjoitti:

"Pascal:ssa on paljon englannin kielisiä sanoja (vrt c )."

Suurin osa ohjelmointikielistä on englanninkielisiä, joten niiden kaikki kokonaiset sanat on englannista ja keksityt käskynimetkin pohjautuvat englantiin.



"Normaalisti tuossa tapauksessa tehdään tehtävä1, tehtävä2 ja tehtävä3. Mutta jos poikkeus tapahtuu tehtävä1:ssä niin ei suoriteta tehtävä2 vaan siirrytään tehtävä3 tekemiseen."

Tarkoitat samaa kuin jos tehtävä1:n jälkeen tarkastetaan tuliko virhe ennen tehtävä 2:n suoritusta. Eli basic-koodina:

tehtävä1
if Err=0 then tehtävä 2
tehtävä3

Visual Basicissa siihen menee 3 riviä, sinun pascal-esimerkissä tuplamäärä eli 6 riviä.


"Ideana tässä on siis (normaalisti) resurssien vapauttaminen tai sulkeminen (joka tapahtuu myös poikkeustilanteissa)."

Tätä en ymmärrä lainkaan. Mitä resursseja tuolla vapautetaan tai suljetaan?

Lue lisää

Except vissiin voidaan korvata Finally-sanalla. Tai jotain. Mutta vastaa muuhun osaan edellisestä viestistäni.

Delphi on nopea! kirjoitti:

Try - Except on ehkäpä vähän enemmän käytetty poikkeuskäsittely (samantapainen kuin esim. C :n try - catch)

(except - sulje pois)

Eli
- KOKEILE tätä (try-)lohkoa ja SULJE POIS normaalisti tämä (except-)lohko.


Selvennän tälläisellä esimerkillä

try
tehtävä1;
tehtävä2;
except
tehtävä3;
end;

Normaalisti tuossa tapauksessa tehdään tehtävä1 ja tehtävä2.
Jos poikkeus tapahtuu tehtävä1:ssä niin ei tehdä tehtävä2 vaan mennään suoraan tehtävä3:n suorittamiseen (eli tehtävä3 tehdään vain poikkeustapauksissa).

Lue lisää

Alunperin olinkin ymmärtänyt asian juuri noin. Tarkoitat samaa kuin jos tehtävä1:n jälkeen tarkastetaan tuliko virhe ennen tehtävä 2:n suoritusta ja jos jommassa kummassa tuli virhe, niin suoritetaan tehtävä3. Eli basic-koodina:

tehtävä1
if Err=0 then tehtävä 2
if Err0 then tehtävä3

Kyllä Visual Basic on loistavaa, kun taaskin sillä pääsi Pascaliin verrattuna puolet vähemmällä koodirivimäärällä.

xxxxx kirjoitti:

Except vissiin voidaan korvata Finally-sanalla. Tai jotain. Mutta vastaa muuhun osaan edellisestä viestistäni.

On siis tarkoitettu sellaisiin tilanteisiin jossa esim. suljetaan tiedosto (tällöin normaalitapauksissa ja poikkeustilanteissa se suljetaan) jne.

xxxxx kirjoitti:

Alunperin olinkin ymmärtänyt asian juuri noin. Tarkoitat samaa kuin jos tehtävä1:n jälkeen tarkastetaan tuliko virhe ennen tehtävä 2:n suoritusta ja jos jommassa kummassa tuli virhe, niin suoritetaan tehtävä3. Eli basic-koodina:

tehtävä1
if Err=0 then tehtävä 2
if Err0 then tehtävä3

Kyllä Visual Basic on loistavaa, kun taaskin sillä pääsi Pascaliin verrattuna puolet vähemmällä koodirivimäärällä.

Lue lisää

Periaatteessa poikkeukset voitaneen korvata mielettömällä määrällä if-lauseita. Miltä vaikuttaisi
sellainen ohjelma jossa joka lauseen edessä olisi if. Ota huomioon sekin että nä if-menisivät myös
aliohjelmiin

tehtävä1
if ei poikkeusta then tehtävä2
if ei poikkeusta then tehtävä3
...
if ei poikkeusta then tehtäväN
if poikkeus then poikkeustehtävä


Täällä on kehoitettu kokeilemaan Delphiä (tai ohjelmia missä on kyseinen ominaisuus) niin kannattaisi
se tehdä. Asia on helpommin ja paremmin ymmärrettävissä kun on itse kokeillut.

PooL kirjoitti:

On siis tarkoitettu sellaisiin tilanteisiin jossa esim. suljetaan tiedosto (tällöin normaalitapauksissa ja poikkeustilanteissa se suljetaan) jne.

Voisitko laittaa esimerkkikoodin, jossa itse olet käyttänyt finally-osaa mainitsemallasi tavalla. Minä voin sitten kirjoittaa saman Visual Basic -koodina, niin nähdään tekeekö pascalin try-finally -tapa koodista selkeämpää.

Koodiesimerkkisi selkeyttäisi asiaa, sillä edellisestä viestistäsi ei käynyt ilmi missä vaiheessa tiedosto avataan. Eikä sitä tietenkään voi sulkea jos sitä ei ole ensin avattu, eli jos tiedoston avauksessa tulee virhe niin eihän silloin voida hypätä sulkemaan tiedostoa.

PooL kirjoitti:

Periaatteessa poikkeukset voitaneen korvata mielettömällä määrällä if-lauseita. Miltä vaikuttaisi
sellainen ohjelma jossa joka lauseen edessä olisi if. Ota huomioon sekin että nä if-menisivät myös
aliohjelmiin

tehtävä1
if ei poikkeusta then tehtävä2
if ei poikkeusta then tehtävä3
...
if ei poikkeusta then tehtäväN
if poikkeus then poikkeustehtävä


Täällä on kehoitettu kokeilemaan Delphiä (tai ohjelmia missä on kyseinen ominaisuus) niin kannattaisi
se tehdä. Asia on helpommin ja paremmin ymmärrettävissä kun on itse kokeillut.

Lue lisää

"Periaatteessa poikkeukset voitaneen korvata mielettömällä määrällä if-lauseita. Miltä vaikuttaisi
sellainen ohjelma jossa joka lauseen edessä olisi if. Ota huomioon sekin että nä if-menisivät myös
aliohjelmiin"

Oletko sinäkään ikinä tehnyt yhtään varsinaista tietokoneohjelmaa? Jos olet, niin laita yksi tekemäsi esimerkkikoodi jossa olet käyttänyt pascalin try-käskyä siten, että ilman try-käskyä ohjelma vaatisi jokaisen käskyn eteen if-then -ehtolauseen.

Eihän ikinä joka lausetta ennen tarvita ehtoa. Tiettyjen asioiden voidaan olettaa toimivan eikä niihin ohjelmassa tarvitse varautua. Esim. siihen että kun muuttujalla on joku arvo, niin arvo pysyy samana kunnes ohjelma sen muuttaa.



"Täällä on kehoitettu kokeilemaan Delphiä (tai ohjelmia missä on kyseinen ominaisuus) niin kannattaisi
se tehdä. Asia on helpommin ja paremmin ymmärrettävissä kun on itse kokeillut."

Asia on paremmin ymmärrettävissä kun näkee käytönnössä käytetyn esimerkkikoodin, joten voisitko laittaa jonkun koodipätkän jostain omasta ohjelmastasi?

Delphi on nopea! kirjoitti:

Siis väittänet että mm C:stä ja VB:stä löytynevät poikkeukset. Kerroppa mitä kyseisen kielen varattuja sanoja käytetään kun halutaan käyttää poikkeuksia?

Ennustamattomiin virhetilanteisiin varautuminen käy vaikka seuraavasti:

Sub Ohjelma
On error goto Virherutiini

Err=0
Tehtävä1
Tehtävä2

Virherutiini:
if err then
msgbox ("Tuli virhe:" & err & " " & error$)
end if

end Sub

xxxxx kirjoitti:

"Periaatteessa poikkeukset voitaneen korvata mielettömällä määrällä if-lauseita. Miltä vaikuttaisi
sellainen ohjelma jossa joka lauseen edessä olisi if. Ota huomioon sekin että nä if-menisivät myös
aliohjelmiin"

Oletko sinäkään ikinä tehnyt yhtään varsinaista tietokoneohjelmaa? Jos olet, niin laita yksi tekemäsi esimerkkikoodi jossa olet käyttänyt pascalin try-käskyä siten, että ilman try-käskyä ohjelma vaatisi jokaisen käskyn eteen if-then -ehtolauseen.

Eihän ikinä joka lausetta ennen tarvita ehtoa. Tiettyjen asioiden voidaan olettaa toimivan eikä niihin ohjelmassa tarvitse varautua. Esim. siihen että kun muuttujalla on joku arvo, niin arvo pysyy samana kunnes ohjelma sen muuttaa.



"Täällä on kehoitettu kokeilemaan Delphiä (tai ohjelmia missä on kyseinen ominaisuus) niin kannattaisi
se tehdä. Asia on helpommin ja paremmin ymmärrettävissä kun on itse kokeillut."

Asia on paremmin ymmärrettävissä kun näkee käytönnössä käytetyn esimerkkikoodin, joten voisitko laittaa jonkun koodipätkän jostain omasta ohjelmastasi?

Lue lisää

..jaksaako tää basic räpeltäjä aina vaan viisastella täällä, basicille löytyy ihan ikioma topicci.

xxxxx kirjoitti:

Ennustamattomiin virhetilanteisiin varautuminen käy vaikka seuraavasti:

Sub Ohjelma
On error goto Virherutiini

Err=0
Tehtävä1
Tehtävä2

Virherutiini:
if err then
msgbox ("Tuli virhe:" & err & " " & error$)
end if

end Sub

Lue lisää

Ilmeisesti myös sitten voi itse nostaa poikkeuksen? Ja tuo siirtyy tarvittaessa seuraavalle tasolle. Eli jos sitä ei käsitellä tällä tasolla (aliohjelmassa) niin se siirtyy kutsuvaan aliohjelmaan?

C:stä ei tietääkseni poikkeusta löydy.

Niinkuin täällä on aiemmin todettu pitää muistaa että virheenkäsittely ja poikkeus eivät ole aina sama asia.

xxxxx kirjoitti:

Voisitko laittaa esimerkkikoodin, jossa itse olet käyttänyt finally-osaa mainitsemallasi tavalla. Minä voin sitten kirjoittaa saman Visual Basic -koodina, niin nähdään tekeekö pascalin try-finally -tapa koodista selkeämpää.

Koodiesimerkkisi selkeyttäisi asiaa, sillä edellisestä viestistäsi ei käynyt ilmi missä vaiheessa tiedosto avataan. Eikä sitä tietenkään voi sulkea jos sitä ei ole ensin avattu, eli jos tiedoston avauksessa tulee virhe niin eihän silloin voida hypätä sulkemaan tiedostoa.

Lue lisää

Ei tuo Finally osa mitenkään erikoinen ole (ja samantapainen toiminta löytyy muistakin kielistä joten sen on moni kielen suunnittelija nähnyt tarpeelliseksi). Tosin sehän on suht helppo korvata esim. C :ssa niin että
tehdään nuo lopetustoimet (esim kutsumalla jotain aliohjemaa) myös poikkeusosassa. Eli se antaa ohjelmoijalle vaan toisenlaisen toteutusmahdollisuuden lisää.

Delphi on nopea! kirjoitti:

Laadukkaat kielet kuten Delphi ( Pascal, C jne) tarjoavat myös poikkeukset. Eli mahdollisuuden toipua virhetilanteissa poikkeuksien avulla.

Tälläisiä poikkeuksia voi tulla Delphin vakiokirjaston osalta. Lisäksi myös poikkeuksia voi nostaa itse tekemät osat ja muut käytettävät kirjastot.

EAbort Abort without dialog
EAbstractError Abstract method error
AssertionFailed Assert call failed
EBitsError Boolean array error
ECommonCalendarError Calendar calc error
EDateTimeError DateTime calc error
EMonthCalError Month calc error
EConversionError Raised by Convert
EConvertError Object convert error
EDatabaseError Database error
EExternal Hardware/Windows error
EAccessViolation Access violation
EControlC User abort occured
EExternalException Other Internal error
EIntError Integer calc error
EDivByZero Integer Divide by zero
EIntOverflow Integer overflow
ERangeError Out of value range
EMathError Floating point error
EInvalidArgument Bad argument value
EInvalidOp Inappropriate operation
EOverflow Value too large
EUnderflow Value too small
EZeroDivide Floating Divide by zero
EStackOverflow Severe Delphi problem
EHeapException Dynamic memory problem
EInvalidPointer Bad memory pointer
EOutOfMemory Cannot allocate memory
EInOutError IO error
EInvalidCast Object casting error
EInvalidOperation Bad component op
EMenuError Menu item error
EOSError Operating system error
EParserError Parsing error
EPrinter Printer error
EPropertyError Class property error#
EPropReadOnly Invalid property access
EPropWriteOnly Invalid property access
EThread Thread error
EVariantError Variant problem

xxxxx kirjoitti:

"Sillä poikkeus on keino siirtää normaalista poikkeava toiminta toiselle tasolle."

Eli sama voidaan hoitaa kaikkien ohjelmointikielten sisältämällä if-then -käskyllä.


"Tämä ei ole niin hyvä esimerkki"

Kertoisitko sinäkin paremman esimerkin.

Lue lisää

En ole mikään opettaja (annoin kuitenkin jo yhden esimerkin). Mutta jos välttämättä haluat tietää lisää niin voisi sinun osaavan miettiä asioita (tai kysyä myös muilta keskustelualueilta. Poikkeukset ovat aika monessa kielessä). Poikkeukset ovat tulleet eri kieliin vissiin 80-luvun jälkeen. Tästä voit jo päätellä että miksi puhutaan poikkeuksista eikä vain virhetilanteista johtunee siitä että sitä voidaan hyödyntää muissakin asioissa kuin pelkissä virhetilanteissa. Niinkuin sanottu jo niin aika moni kieli on ottanut poikkeukset käyttöönsä (tuskinpa turhaan).

01000110 kirjoitti:

..jaksaako tää basic räpeltäjä aina vaan viisastella täällä, basicille löytyy ihan ikioma topicci.

Hän on ilmeisesti kiinnostunut Delphistä (tai Pascalista). Mikä on ihan hyvä asia. Sillä elämässä on hyvä mennä eteenpäin. Ottaa seuraava askel. Delphihän on seuraava askel vaikka sillä voisi ihan hyvin aloittaakin. Delphihän (Pascal) tarjoaa paljon erilaisia haasteita! Toivottavasti hän ymmärtää sen että hänen on myös itse tehtävä tarvittavat harjoitukset.

Tunnettavuus kirjoitti:

Hän on ilmeisesti kiinnostunut Delphistä (tai Pascalista). Mikä on ihan hyvä asia. Sillä elämässä on hyvä mennä eteenpäin. Ottaa seuraava askel. Delphihän on seuraava askel vaikka sillä voisi ihan hyvin aloittaakin. Delphihän (Pascal) tarjoaa paljon erilaisia haasteita! Toivottavasti hän ymmärtää sen että hänen on myös itse tehtävä tarvittavat harjoitukset.

Lue lisää

..toivottavasti ei joudu koskaan tilanteeseen jossa joutuu yrittää ymmärtää basic kooodaajan aivoituksia, muuttujia kun ei tarvi esitellä ne vaan otetaan käyttöön kiva selvittää mitä moninkertaisessa hierarkisessa rakenteessa on i, ix,x,y,yy,xx, ii ja monet muut, itse olen joutunut ao tilanteeseen, viikon tutkinnan jälkeen todettiin ettei kannata, tehdään homma uusiksi ja peremmin oikealla ohjelmointikielellä.

01000110 kirjoitti:

..toivottavasti ei joudu koskaan tilanteeseen jossa joutuu yrittää ymmärtää basic kooodaajan aivoituksia, muuttujia kun ei tarvi esitellä ne vaan otetaan käyttöön kiva selvittää mitä moninkertaisessa hierarkisessa rakenteessa on i, ix,x,y,yy,xx, ii ja monet muut, itse olen joutunut ao tilanteeseen, viikon tutkinnan jälkeen todettiin ettei kannata, tehdään homma uusiksi ja peremmin oikealla ohjelmointikielellä.

Lue lisää

Jos Visual Basicissa laittaa käskyn Option Excplicit, niin silloin muuttujat tarvii esitellä.

On huonoa koodausta käyttää mitäänsanomattomia kahden merkin muuttujia. Sinä ikäänkuin väität, että se johtui siitä, että ohjelma on tehty vb:llä ja esim. pascalilla ei tuollaista huonoa koodia voi tehdä.

Delphi on nopea! kirjoitti:

Ei tuo Finally osa mitenkään erikoinen ole (ja samantapainen toiminta löytyy muistakin kielistä joten sen on moni kielen suunnittelija nähnyt tarpeelliseksi). Tosin sehän on suht helppo korvata esim. C :ssa niin että
tehdään nuo lopetustoimet (esim kutsumalla jotain aliohjemaa) myös poikkeusosassa. Eli se antaa ohjelmoijalle vaan toisenlaisen toteutusmahdollisuuden lisää.

Lue lisää

Edellisessä viestissäni oli oleellista pyyntö saada esimerkki koodista.

Ohjelmointikeskustelussa pitää pystyä todistamaan koodiväitteensä ja laittaa esimerkkikoodia. Minä on tässä keskustelussa usemman kerran vaatinut koodiesimerkkejä, mutta ne enimmäkseen sivutetaan jollain yleisen tason höpötyksellä.

Nytkin unohdit vastauksessa vastata mihinkään ja siirtää aiheen mainitsemalla että "Tosin sehän on suht helppo korvata esim. C :ssa niin että tehdään nuo lopetustoimet (esim kutsumalla jotain aliohjemaa) myös poikkeusosassa."

Paljon kerrot ohjelmakoodista yleisellä tasolla, ja vielä niin, että koodin teko on helppoa, mutta etpä ole koodiesimerkkejä tälle palstalle tuonut.

Tunnettavuus kirjoitti:

Hän on ilmeisesti kiinnostunut Delphistä (tai Pascalista). Mikä on ihan hyvä asia. Sillä elämässä on hyvä mennä eteenpäin. Ottaa seuraava askel. Delphihän on seuraava askel vaikka sillä voisi ihan hyvin aloittaakin. Delphihän (Pascal) tarjoaa paljon erilaisia haasteita! Toivottavasti hän ymmärtää sen että hänen on myös itse tehtävä tarvittavat harjoitukset.

Lue lisää

"Toivottavasti hän ymmärtää sen että hänen on myös itse tehtävä tarvittavat harjoitukset."

Tuo on huono tapa muuttaa keskustelun suunta. En halua siirtyä Delphiin, sillä kuten tämä keskustelumme on osoittanut, niin ei Delphiin siirtymisessä ole kokonaisuudessa etua verrattuna Visual Basiciin. Samantasoisia ohjelmointikehittimiä ovat.

Mikähän siinä on, että tässä keskustellussa Delphi-asiantuntijoina on harrastelijoita jotka eivät edes osaa vastata kysymyksiin tai todistaa jotain pienellä koodipätkällä.

Delphi on nopea! kirjoitti:

Tälläisiä poikkeuksia voi tulla Delphin vakiokirjaston osalta. Lisäksi myös poikkeuksia voi nostaa itse tekemät osat ja muut käytettävät kirjastot.

EAbort Abort without dialog
EAbstractError Abstract method error
AssertionFailed Assert call failed
EBitsError Boolean array error
ECommonCalendarError Calendar calc error
EDateTimeError DateTime calc error
EMonthCalError Month calc error
EConversionError Raised by Convert
EConvertError Object convert error
EDatabaseError Database error
EExternal Hardware/Windows error
EAccessViolation Access violation
EControlC User abort occured
EExternalException Other Internal error
EIntError Integer calc error
EDivByZero Integer Divide by zero
EIntOverflow Integer overflow
ERangeError Out of value range
EMathError Floating point error
EInvalidArgument Bad argument value
EInvalidOp Inappropriate operation
EOverflow Value too large
EUnderflow Value too small
EZeroDivide Floating Divide by zero
EStackOverflow Severe Delphi problem
EHeapException Dynamic memory problem
EInvalidPointer Bad memory pointer
EOutOfMemory Cannot allocate memory
EInOutError IO error
EInvalidCast Object casting error
EInvalidOperation Bad component op
EMenuError Menu item error
EOSError Operating system error
EParserError Parsing error
EPrinter Printer error
EPropertyError Class property error#
EPropReadOnly Invalid property access
EPropWriteOnly Invalid property access
EThread Thread error
EVariantError Variant problem

Lue lisää

Voisitko laittaa sen esimerkkikoodin, jossa poikkeuksilla hoidetaan tiedoston käsittelyä (avaus-luku/talletus-sulku)?

xxxxx kirjoitti:

Edellisessä viestissäni oli oleellista pyyntö saada esimerkki koodista.

Ohjelmointikeskustelussa pitää pystyä todistamaan koodiväitteensä ja laittaa esimerkkikoodia. Minä on tässä keskustelussa usemman kerran vaatinut koodiesimerkkejä, mutta ne enimmäkseen sivutetaan jollain yleisen tason höpötyksellä.

Nytkin unohdit vastauksessa vastata mihinkään ja siirtää aiheen mainitsemalla että "Tosin sehän on suht helppo korvata esim. C :ssa niin että tehdään nuo lopetustoimet (esim kutsumalla jotain aliohjemaa) myös poikkeusosassa."

Paljon kerrot ohjelmakoodista yleisellä tasolla, ja vielä niin, että koodin teko on helppoa, mutta etpä ole koodiesimerkkejä tälle palstalle tuonut.

Lue lisää

Miksi pyydät sitä vieläkin hänhän antoi sinulle vihjeen että asiaa voi myös kysyä muiltakin
palstoilta. Koska kyseessä on yleinen tapaus. (lueppa myös toi toinen vastaukseni alempana).

xxxxx kirjoitti:

"Toivottavasti hän ymmärtää sen että hänen on myös itse tehtävä tarvittavat harjoitukset."

Tuo on huono tapa muuttaa keskustelun suunta. En halua siirtyä Delphiin, sillä kuten tämä keskustelumme on osoittanut, niin ei Delphiin siirtymisessä ole kokonaisuudessa etua verrattuna Visual Basiciin. Samantasoisia ohjelmointikehittimiä ovat.

Mikähän siinä on, että tässä keskustellussa Delphi-asiantuntijoina on harrastelijoita jotka eivät edes osaa vastata kysymyksiin tai todistaa jotain pienellä koodipätkällä.

Lue lisää

Pidät muiden keskustelijoiden tasoa huonona. Mutta teet kuitenkin heidän kertomuksista jonkinlaisen johtopäätöksen. Vertaappa tilannetta siihen että on ammattikuski joka pitää tietystä autosta ja pärjää sillä hyvin. Mutta se ei tarkoita sitä että hän voisi pärjätä vielä paremmin jollain toisella. Hänen kykynsä voisi tulla esille vähän paremmalla vehkeellä jos hän vain uskaltaisi kokeilla sitä!

xxxxx kirjoitti:

Edellisessä viestissäni oli oleellista pyyntö saada esimerkki koodista.

Ohjelmointikeskustelussa pitää pystyä todistamaan koodiväitteensä ja laittaa esimerkkikoodia. Minä on tässä keskustelussa usemman kerran vaatinut koodiesimerkkejä, mutta ne enimmäkseen sivutetaan jollain yleisen tason höpötyksellä.

Nytkin unohdit vastauksessa vastata mihinkään ja siirtää aiheen mainitsemalla että "Tosin sehän on suht helppo korvata esim. C :ssa niin että tehdään nuo lopetustoimet (esim kutsumalla jotain aliohjemaa) myös poikkeusosassa."

Paljon kerrot ohjelmakoodista yleisellä tasolla, ja vielä niin, että koodin teko on helppoa, mutta etpä ole koodiesimerkkejä tälle palstalle tuonut.

Lue lisää

Mielestäni asiat kannattaa yleistää jolloin siitä on suuremmalle joukolle hyötyä.

xxxxx kirjoitti:

"Toivottavasti hän ymmärtää sen että hänen on myös itse tehtävä tarvittavat harjoitukset."

Tuo on huono tapa muuttaa keskustelun suunta. En halua siirtyä Delphiin, sillä kuten tämä keskustelumme on osoittanut, niin ei Delphiin siirtymisessä ole kokonaisuudessa etua verrattuna Visual Basiciin. Samantasoisia ohjelmointikehittimiä ovat.

Mikähän siinä on, että tässä keskustellussa Delphi-asiantuntijoina on harrastelijoita jotka eivät edes osaa vastata kysymyksiin tai todistaa jotain pienellä koodipätkällä.

Lue lisää

Kaikki riippu kriteereistä. Jos vaatimuksena on vain että sillä pystyy tekemään ohjelman niin silloin käy melkein mikä tahansa kieli. Mutta Delphi on siitä hyvä että sillä voi aloittaa ohjelmmoinnin ja sillä pääsee pitkälle sekä asioita voi tehdä monipuolisesti (luulisi jo ainakin sinun sen huomanneen).

xxxxx kirjoitti:

Voisitko laittaa sen esimerkkikoodin, jossa poikkeuksilla hoidetaan tiedoston käsittelyä (avaus-luku/talletus-sulku)?

Moneen paikkaan riittää ihan perustiedostonkäsittelyksi:
SaveToFile(TiedostonNimi) ja LoadFromFile(TiedostonNimi)

Niin tuota Finally hommaa käytetään usein niin että jos jollekin varataan muistia (esim. puskuri) niin ja sitten suoritetaan jotain jonka jälkeen tuo (puskuri)muistinvaraus puretaan finally osassa (eli se suoritetaan vaikka tulisi poikkeus: esim. ohjelman käyttäjä haluaa lopettaa ohjelman toiminnan kesken sen suorituksen tms )

kyselijä kirjoitti:

Miksi pyydät sitä vieläkin hänhän antoi sinulle vihjeen että asiaa voi myös kysyä muiltakin
palstoilta. Koska kyseessä on yleinen tapaus. (lueppa myös toi toinen vastaukseni alempana).

Lue lisää

Tässä keskustelussa on keskusteltu pascalista ja Delphistä. Minulle on sitä kehuttu väitteillä, jotka olen kumonut. Ohjelmakoodaus on nimenomaan yksittäisiä käskyjä, joten yleistykset voidaan ja ne pitää pystyä todistamaan kooditasolla.

Jos joku tulee tälle palstalle esiintymään asiantuntijana yrittäen tyrmätä väitteeni, niin kun hän ei siinä onnistu, on typerää sanoa että kysy muilta palstoilta. Jos muilla palstoilla on joku joka on samaa mieltä tälle palstalle kirjoittaneiden "asiantuntijoiden" teksteistä, niin tulkoon tälle palstalla murskaamaan väitteeni.

Delphi on nopea! kirjoitti:

Mielestäni asiat kannattaa yleistää jolloin siitä on suuremmalle joukolle hyötyä.

Tietyt asiat kannattaa yleistää, mutta siinä täytyy olla looginen.

Tietokoneohjelmointi on nimenomaan yksittäisiä tarkkoja käskyjä, jolloin yleistykset pitää pystyä yksilöimään.

Eli ohjelmakoodauksessa väitteet pitää pystyä todistamaan kooditasolla. Sinä et siihen ole pystynyt. Eikä muutkaan tällä palstalle esiintyneet "Delphi-asiantuntijat".

Voin kuvitella miten karmeaa olisi keskustelu kanssasi mistä muusta aiheesta tahansa, kun koodaukseen verrattuna niitä ei pysty yksilöimään yksittäisiin toimintoihin. Etkä pysty uskomaan että tietosi pascalista on pelkkää elvistelyä ilman tietoa siitä, mitä ohjelmointi on.

kyselijä kirjoitti:

Pidät muiden keskustelijoiden tasoa huonona. Mutta teet kuitenkin heidän kertomuksista jonkinlaisen johtopäätöksen. Vertaappa tilannetta siihen että on ammattikuski joka pitää tietystä autosta ja pärjää sillä hyvin. Mutta se ei tarkoita sitä että hän voisi pärjätä vielä paremmin jollain toisella. Hänen kykynsä voisi tulla esille vähän paremmalla vehkeellä jos hän vain uskaltaisi kokeilla sitä!

Lue lisää

"Pidät muiden keskustelijoiden tasoa huonona."

Kyllä pidän erittäin huonona, sillä he puhuvat koodauksesta vain yleisellä tasolla esiintyen kuitenkin "Delphi-asiantuntijoina".

Koodauskeskustelussa pitää pystyä yksilöimään väitteensä ohjelmariveinä. Tällä palstalla asiantuntijoina esiintyvät eivät ole siihen kyenneet.

Eli muiden keskustelijoiden taso on huono, sillä he vänkäävät ilman tietoa keskusteltavasta asiasta (ohjelmoinnista). Yksityiskohdat (koodirivit) he jättävät huomioimatta ja yrittävät jatkuvasti siirtää keskustelua yleisemmälle tasolle. Se on erittäin huonoa keskustelua että ei hyväksytä vastapuolen perusteltuja väitteitä vaan ne hylätään ilman tarkkoja vastaperusteita. Selitetään vain jotain yleistä samaan tapaan kuin politiikot jotka eivät suostu tunnustamaan että eivät tiedä keskusteltavasta asiasta oikeastaan mitään.


"Hänen kykynsä voisi tulla esille vähän paremmalla vehkeellä jos hän vain uskaltaisi kokeilla sitä!"

Minähän olen sanonut että Delphi on samaa tasoa oleva ohjelmakehitin kuin Visual Basic, joten en ymmärrä miten Delphin käyttö lisäisi koodaustehokkuuttani. Vastaväitteet tuohon ovat olleet vain jotain yleistä örinää Basicin huonoudesta eikä perusteltuja väitteitä Delphin paremmuudesta Visual Basiciin nähden.

Delphi on nopea! kirjoitti:

Kaikki riippu kriteereistä. Jos vaatimuksena on vain että sillä pystyy tekemään ohjelman niin silloin käy melkein mikä tahansa kieli. Mutta Delphi on siitä hyvä että sillä voi aloittaa ohjelmmoinnin ja sillä pääsee pitkälle sekä asioita voi tehdä monipuolisesti (luulisi jo ainakin sinun sen huomanneen).

Lue lisää

"Mutta Delphi on siitä hyvä että sillä voi aloittaa ohjelmmoinnin ja sillä pääsee pitkälle sekä asioita voi tehdä monipuolisesti (luulisi jo ainakin sinun sen huomanneen)."

Kyllä minä tuon tiedän. Samoin voi tehdä Visual Basicilla. Yhtä hyviä kehittimiä ovat.

Olet esittänyt tässä keskustelussa väitteitä, jotka minä olen tyrmännyt. Olet kehunut Delphi-koodia, mutta et ole pystynyt esittämään todisteita väitteidesi tueksi. Minä tiedän mitä ohjelmakoodaus on ja siksi olen esittänyt vaatimuksen että todistat väitteesi yksinkertaisilla koodipätkillä. Kun minä olen laittanut pascalin esimerkkikoodeja netistä, niin minulle on sanottu niiden olevan huonoja esimerkkejä, jonka jälkeen olen vaatinut muita panemaan palstalle parempia esimerkkejä. Niitä ei ole kuitenkaan näkynyt.

Delphi on nopea! kirjoitti:

Moneen paikkaan riittää ihan perustiedostonkäsittelyksi:
SaveToFile(TiedostonNimi) ja LoadFromFile(TiedostonNimi)

Niin tuota Finally hommaa käytetään usein niin että jos jollekin varataan muistia (esim. puskuri) niin ja sitten suoritetaan jotain jonka jälkeen tuo (puskuri)muistinvaraus puretaan finally osassa (eli se suoritetaan vaikka tulisi poikkeus: esim. ohjelman käyttäjä haluaa lopettaa ohjelman toiminnan kesken sen suorituksen tms )

Lue lisää

Taas kerrot asian vain yleisellä tasolla. Laita esimerkkikoodi miten tuon olet ratkaissut ohjelmissasi. Vai etkä todellakoon ole ikinä tehnyt yhtään ohjelmaa?

Tuo mainitsemasi tiedostojen käsittely on ohjelmoinnin perusjuttuja, joten jos olet tehnyt yhdenkään varsinaisen tietokoneohjelman, niin olet tarvinnut tiedostokäsittelyä. Joten laita esimerkkikoodi kuinka pascalissa olet tuon tehnyt niin nähdään koodiriveinä onko se kätevämpää kuin Visual Basicissa. Minä sitten voin esimerkkikoodiisi perustuen kirjoittaa saman Visual Basicilla, jolloin voidaan koodiriveinä tarkastella onko Delpi-koodi toimivampaa ja kätevämpää kun Visual Basic -koodi.

xxxxx kirjoitti:

Taas kerrot asian vain yleisellä tasolla. Laita esimerkkikoodi miten tuon olet ratkaissut ohjelmissasi. Vai etkä todellakoon ole ikinä tehnyt yhtään ohjelmaa?

Tuo mainitsemasi tiedostojen käsittely on ohjelmoinnin perusjuttuja, joten jos olet tehnyt yhdenkään varsinaisen tietokoneohjelman, niin olet tarvinnut tiedostokäsittelyä. Joten laita esimerkkikoodi kuinka pascalissa olet tuon tehnyt niin nähdään koodiriveinä onko se kätevämpää kuin Visual Basicissa. Minä sitten voin esimerkkikoodiisi perustuen kirjoittaa saman Visual Basicilla, jolloin voidaan koodiriveinä tarkastella onko Delpi-koodi toimivampaa ja kätevämpää kun Visual Basic -koodi.

Lue lisää

Tässä on sinulle katsottavaksi yksinkertainen mutta toimiva valikkopohjainen muistio joka on tehty Lazaruksella (vastaava onnistuu myös Delphillä). Vaikka koodia on paljon niin se mitä on itse näppäiltyä on vain murto-osa tästä (Delphi niin kuin Lazarus luo osan koodista taustalla) (En minä ole kiinnostunut VB-koodista):



unit memounit;

{$mode objfpc}{$H }

interface

uses
Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs, StdCtrls, Menus;

type

{ TForm1 }

TForm1 = class(TForm)
MainMenu1: TMainMenu;
Tiedostovalikko: TMenuItem;
MenunUuusiKohta: TMenuItem;
MenunLopetaKohta: TMenuItem;
MenunAvaaKohta: TMenuItem;
MenunTallennaKohta: TMenuItem;
Memo1: TMemo;
OpenDialog1: TOpenDialog;
SaveDialog1: TSaveDialog;
procedure MenunAvaaKohta1Click(Sender: TObject);
procedure MenunLopetaKohtaClick(Sender: TObject);
procedure MenunTallennaKohtaClick(Sender: TObject);
procedure MenunUuusiKohtaClick(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;

var
Form1: TForm1;

implementation

{ TForm1 }

procedure TForm1.MenunAvaaKohta1Click(Sender: TObject);
begin
if OpenDialog1.execute then
Memo1.Lines.LoadFromFile(OpenDialog1.FileName);
end;


procedure TForm1.MenunTallennaKohtaClick(Sender: TObject);
begin
if SaveDialog1.execute then
Memo1.Lines.SaveToFile(SaveDialog1.FileName);
end;

procedure TForm1.MenunUuusiKohtaClick(Sender: TObject);
begin
Memo1.Clear;
end;

procedure TForm1.MenunLopetaKohtaClick(Sender: TObject);
begin
Close;
end;

initialization
{$I memounit.lrs}

end.

xxxxx kirjoitti:

"Mutta Delphi on siitä hyvä että sillä voi aloittaa ohjelmmoinnin ja sillä pääsee pitkälle sekä asioita voi tehdä monipuolisesti (luulisi jo ainakin sinun sen huomanneen)."

Kyllä minä tuon tiedän. Samoin voi tehdä Visual Basicilla. Yhtä hyviä kehittimiä ovat.

Olet esittänyt tässä keskustelussa väitteitä, jotka minä olen tyrmännyt. Olet kehunut Delphi-koodia, mutta et ole pystynyt esittämään todisteita väitteidesi tueksi. Minä tiedän mitä ohjelmakoodaus on ja siksi olen esittänyt vaatimuksen että todistat väitteesi yksinkertaisilla koodipätkillä. Kun minä olen laittanut pascalin esimerkkikoodeja netistä, niin minulle on sanottu niiden olevan huonoja esimerkkejä, jonka jälkeen olen vaatinut muita panemaan palstalle parempia esimerkkejä. Niitä ei ole kuitenkaan näkynyt.

Lue lisää

Pascalilla voi tehdä vaikkapa kääntäjän (tai graafisen ohjelmointiympäristön) joka toimii useassa eri käyttöjärjestelmässä ja eri prosessoreilla (natiivisti, siis ilman välikoodia). Asian voit halutessasi varmistaa vaikka tutkimalla FreePascalin (tai Lazaruksen) lähdekoodeja.

Ne löytyvät vaikkapa täältä:

https://sourceforge.net/project/showfiles.php?group_id= 89339

FreePascal kirjoitti:

Pascalilla voi tehdä vaikkapa kääntäjän (tai graafisen ohjelmointiympäristön) joka toimii useassa eri käyttöjärjestelmässä ja eri prosessoreilla (natiivisti, siis ilman välikoodia). Asian voit halutessasi varmistaa vaikka tutkimalla FreePascalin (tai Lazaruksen) lähdekoodeja.

Ne löytyvät vaikkapa täältä:

https://sourceforge.net/project/showfiles.php?group_id= 89339

Lue lisää

Linkinne taisi olla rikki ja tarkoititte tätä
https://sourceforge.net/project/showfiles.php?group_id=89339

FreePascal kirjoitti:

Pascalilla voi tehdä vaikkapa kääntäjän (tai graafisen ohjelmointiympäristön) joka toimii useassa eri käyttöjärjestelmässä ja eri prosessoreilla (natiivisti, siis ilman välikoodia). Asian voit halutessasi varmistaa vaikka tutkimalla FreePascalin (tai Lazaruksen) lähdekoodeja.

Ne löytyvät vaikkapa täältä:

https://sourceforge.net/project/showfiles.php?group_id= 89339

Lue lisää

Tietysti Pascalilla voi tehdä monenlaisia ohjelmia. Niin voi Visual Basicillakin. Ja Assemblerillakin. Joillakin ohjelmointikielillä voi tehdä joitain asioita helpommin kuin toisella. Mitä ohjelmia sinä olet tehnyt Pascalilla?

Eihän kukaan ole epäillytkään ettei Pascalilla voi väsätä kaikenlaista, joten miksi taas yrität siirtää tätä keskustelua jollekin ufotasolle?

Aika harva kuitenkin tekee oman kääntäjän tai graafisen ohjelmointiympäristön. Toki niitä on moniakin, mutta ei varmaan yli kymmentä joilla on 10 prosenttia markkinaosuuksista. ;)

Joten kun minä olen yrittänyt tässä keskustelussa todistaa väitteet koodirivitasolla, niin miksi sinäkin yrität vastata minulle viittaamalla asioihin jotka tässä keskustelussa eivät ole oleellisia?

Toistan vielä sen, että ohjelmointikielten eroja käsittelevissä keskusteluissa pitää pystyä todistamaan väitteensä koodiriveinä. Siis ainakin yksittäiset väitteet.

Lazarus. kirjoitti:

Tässä on sinulle katsottavaksi yksinkertainen mutta toimiva valikkopohjainen muistio joka on tehty Lazaruksella (vastaava onnistuu myös Delphillä). Vaikka koodia on paljon niin se mitä on itse näppäiltyä on vain murto-osa tästä (Delphi niin kuin Lazarus luo osan koodista taustalla) (En minä ole kiinnostunut VB-koodista):



unit memounit;

{$mode objfpc}{$H }

interface

uses
Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs, StdCtrls, Menus;

type

{ TForm1 }

TForm1 = class(TForm)
MainMenu1: TMainMenu;
Tiedostovalikko: TMenuItem;
MenunUuusiKohta: TMenuItem;
MenunLopetaKohta: TMenuItem;
MenunAvaaKohta: TMenuItem;
MenunTallennaKohta: TMenuItem;
Memo1: TMemo;
OpenDialog1: TOpenDialog;
SaveDialog1: TSaveDialog;
procedure MenunAvaaKohta1Click(Sender: TObject);
procedure MenunLopetaKohtaClick(Sender: TObject);
procedure MenunTallennaKohtaClick(Sender: TObject);
procedure MenunUuusiKohtaClick(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;

var
Form1: TForm1;

implementation

{ TForm1 }

procedure TForm1.MenunAvaaKohta1Click(Sender: TObject);
begin
if OpenDialog1.execute then
Memo1.Lines.LoadFromFile(OpenDialog1.FileName);
end;


procedure TForm1.MenunTallennaKohtaClick(Sender: TObject);
begin
if SaveDialog1.execute then
Memo1.Lines.SaveToFile(SaveDialog1.FileName);
end;

procedure TForm1.MenunUuusiKohtaClick(Sender: TObject);
begin
Memo1.Clear;
end;

procedure TForm1.MenunLopetaKohtaClick(Sender: TObject);
begin
Close;
end;

initialization
{$I memounit.lrs}

end.

Lue lisää

Mikä tuossa pascalohjelmassa oli hyvä esimerkki viitaten tähän meidän keskusteluun? Tässä keskustelussa on paljon käsitelty poikkeuksia ja Delphi-koodaajat ovat kehuneet sen try-finale -käskyä. Tuota käskyä ei ole esimerkissäsi käytetty kertaakaan.

Esimerkkisi on muutenkin huono esimerkki pascalista, sillä se käyttää lähes pelkästään kirjastoja eikä sisällä juurikaan varsinaista koodia.

Tee itse tai etsi netistä mielestäsi hyvä lyhyt esimerkkikoodi jossa tiedoston luku hoidetaan Try-Except-Finally -käskyn sisällä. Analysoidaan sitä sitten ja mietitään mahdollistaako pascal siihen ja tiedoston luvun poikkeuksiin jotenkin paremmat välineet kuin Visual Basic. Visual Basic vertaus sen vuoksi kun sitä on tässä keskustelussa haukuttu ja pascaleita sanottu siihen verrattuna ylivoimaisiksi.

xxxxx kirjoitti:

Tietysti Pascalilla voi tehdä monenlaisia ohjelmia. Niin voi Visual Basicillakin. Ja Assemblerillakin. Joillakin ohjelmointikielillä voi tehdä joitain asioita helpommin kuin toisella. Mitä ohjelmia sinä olet tehnyt Pascalilla?

Eihän kukaan ole epäillytkään ettei Pascalilla voi väsätä kaikenlaista, joten miksi taas yrität siirtää tätä keskustelua jollekin ufotasolle?

Aika harva kuitenkin tekee oman kääntäjän tai graafisen ohjelmointiympäristön. Toki niitä on moniakin, mutta ei varmaan yli kymmentä joilla on 10 prosenttia markkinaosuuksista. ;)

Joten kun minä olen yrittänyt tässä keskustelussa todistaa väitteet koodirivitasolla, niin miksi sinäkin yrität vastata minulle viittaamalla asioihin jotka tässä keskustelussa eivät ole oleellisia?

Toistan vielä sen, että ohjelmointikielten eroja käsittelevissä keskusteluissa pitää pystyä todistamaan väitteensä koodiriveinä. Siis ainakin yksittäiset väitteet.

Lue lisää

Niin väitehän on ollut että aloittelijoille sopivista kielistä Pascalilla pääsee pidemmälle. Eikä tätä väitettä ole kukaan kumonnut.

FreePascal kirjoitti:

Niin väitehän on ollut että aloittelijoille sopivista kielistä Pascalilla pääsee pidemmälle. Eikä tätä väitettä ole kukaan kumonnut.

Tässä keskustelussahan pascalien paremmuudesta puhuvat ovat esittäneet vain yleisiä väitteitä sen erinomaisuudesta, mutta kun olen tyrmännyt väitteet (esim. try-finally -käskyn käsittelyssä) ja vaatinut koodiesimerkkejä väitteiden tueksi, niin eipä ole niitä juuri näkynyt. Eikä etenkään sellaisia jotka olisivat tukeneet väitettä Delphin tai muihin pascaliin perustuvien ohjelmointikielten paremmuudesta esim. Visual Basiciin nähden.

Esimerkiksi Wordin ja Excelin sisällä olevalla Visual Basic for Application:illa voidaan kirjoittaa ohjelmamakroja ja laajempaakin koodia. Eli nähdäkseni basicillä pääsee windows-maailmassa huomattavasti pidemmälle kuin pascaleilla. Toinen pointti tuossa on se, että basic on sisäänrakennettuna moniin Microsoftin ohjelmiin, joten aloittelevan koodaajan kannattaa mielestäni suoraan opetella Visual Basic, sillä sillä pääsee windows-maailmassa pidemmälle kuin pascaleilla.

xxxxx kirjoitti:

Mikä tuossa pascalohjelmassa oli hyvä esimerkki viitaten tähän meidän keskusteluun? Tässä keskustelussa on paljon käsitelty poikkeuksia ja Delphi-koodaajat ovat kehuneet sen try-finale -käskyä. Tuota käskyä ei ole esimerkissäsi käytetty kertaakaan.

Esimerkkisi on muutenkin huono esimerkki pascalista, sillä se käyttää lähes pelkästään kirjastoja eikä sisällä juurikaan varsinaista koodia.

Tee itse tai etsi netistä mielestäsi hyvä lyhyt esimerkkikoodi jossa tiedoston luku hoidetaan Try-Except-Finally -käskyn sisällä. Analysoidaan sitä sitten ja mietitään mahdollistaako pascal siihen ja tiedoston luvun poikkeuksiin jotenkin paremmat välineet kuin Visual Basic. Visual Basic vertaus sen vuoksi kun sitä on tässä keskustelussa haukuttu ja pascaleita sanottu siihen verrattuna ylivoimaisiksi.

Lue lisää

Tuo koodi näyttää miten tiedoston käsittely voidaan tehdä (ja näin se peruskäyttäjä sen tekee).

Jos niin halutaan tuohon koodiin voi laittaa poikkeusten tarkastelua.
Except


Jos todella haluat tietää poikkeusten käytöstä niin lataappa nyt vaikkapa Lazarus
(https://sourceforge.net/project/showfiles.php?group_id=89339)
Teet sen jälkeen sillä aluksi pienen ohjelman pätkän.

Sen jälkeen kerron kuinka saat useita tuhansia kohtia missä on käytetty Try..Finally tai Try..Except poikkeuskoodia (jos itse ole vielä silloin keksinyt. Vihjeenä Lazaruksen mukana tulee sen lähdekoodi)

xxxxx kirjoitti:

Tässä keskustelussahan pascalien paremmuudesta puhuvat ovat esittäneet vain yleisiä väitteitä sen erinomaisuudesta, mutta kun olen tyrmännyt väitteet (esim. try-finally -käskyn käsittelyssä) ja vaatinut koodiesimerkkejä väitteiden tueksi, niin eipä ole niitä juuri näkynyt. Eikä etenkään sellaisia jotka olisivat tukeneet väitettä Delphin tai muihin pascaliin perustuvien ohjelmointikielten paremmuudesta esim. Visual Basiciin nähden.

Esimerkiksi Wordin ja Excelin sisällä olevalla Visual Basic for Application:illa voidaan kirjoittaa ohjelmamakroja ja laajempaakin koodia. Eli nähdäkseni basicillä pääsee windows-maailmassa huomattavasti pidemmälle kuin pascaleilla. Toinen pointti tuossa on se, että basic on sisäänrakennettuna moniin Microsoftin ohjelmiin, joten aloittelevan koodaajan kannattaa mielestäni suoraan opetella Visual Basic, sillä sillä pääsee windows-maailmassa pidemmälle kuin pascaleilla.

Lue lisää

Pascal soveltuu erinomaisesti ohjelmoinnin aloittajalle ja pidemmälle ehtineelle sillä
Pascalilla pääsee pidemmälle. Tällä tarkoitan sitä että Pascalissa on paljon erilaisia ominaisuuksia joita voi käyttää jos haluaa edetä ohjelmmoin opiskelussa pidemmälle (eikä jäädä peruskoodarintasolle). Täällähän on jo ainakin osa mainittu. Tarkoitan siis olio-ohjelmointia, poikkeuksia, pointtereita, rinnakkaisuutta jne.

Lazarus. kirjoitti:

Tuo koodi näyttää miten tiedoston käsittely voidaan tehdä (ja näin se peruskäyttäjä sen tekee).

Jos niin halutaan tuohon koodiin voi laittaa poikkeusten tarkastelua.
Except


Jos todella haluat tietää poikkeusten käytöstä niin lataappa nyt vaikkapa Lazarus
(https://sourceforge.net/project/showfiles.php?group_id=89339)
Teet sen jälkeen sillä aluksi pienen ohjelman pätkän.

Sen jälkeen kerron kuinka saat useita tuhansia kohtia missä on käytetty Try..Finally tai Try..Except poikkeuskoodia (jos itse ole vielä silloin keksinyt. Vihjeenä Lazaruksen mukana tulee sen lähdekoodi)

Lue lisää

"Tuo koodi näyttää miten tiedoston käsittely voidaan tehdä (ja näin se peruskäyttäjä sen tekee)."

Tässä keskustelussa on kehuttu pascalin poikkeustenkäsittelyä ja tuossa koodissasi on se tehty kahdella if-then -käskyllä eikä käytetty pascalin try-finally -käskyä. Sitähän minä olen tässä jo monesti todistanut ettei try-finally -käsky ole mitenkään erinomainen lisä ohjelmointikieleen.

Sanoin edellisen viestisi koodiesimerkissä että "Delphi niin kuin Lazarus luo osan koodista taustalla". Mitä tarkoitat? Ainakin Visual Basic käyttää OpenDialog- ja SaveDialog-toiminnoissa käyttöjärjestelmän toimintoja eikä kielen omaa koodia. Eli esimerkkisi on lähinnä mainos Microsoftin Windowseille (ehkä sama toimii myös muissa uusissa käyttöjärjestelmissä jotka ovat ottaneet Microsoftin loistavista windowseista mallia).


"Jos todella haluat tietää poikkeusten käytöstä niin lataappa nyt vaikkapa Lazarus"

Tässä keskustelussa on keskusteltu poikkeuksista ja olen tyrmännyt Try-Finally ja Try-Except käskyjen erinomaisuuden poikkeuskoodin käsittelyssä. On outoa keskustelua että keskustelumme jälkeen sysäät vielä minun tehtäväksi selvittää asioita jotka olen jo tässä keskustelussa tyrmännyt. Tuo osoittaa että ainakaan tähän keskusteluun osaavat eivät joko osaa pascalia tai jos osaavat niin eivät kykene todistamaan väitteitään oikeiksi.


"Sen jälkeen kerron kuinka saat useita tuhansia kohtia missä on käytetty Try..Finally tai Try..Except poikkeuskoodia"

Noitahan saa kun Kuukleen syöttää "try except finally". Jos sinä olet pascal-asiantuntija, niin tuo tälle palstalle mielestäsi loistava esimerkki koodista, jolloin nähdään pätevätkö väitteesi vai pystynkö helpostikin murskaamaan väitteesi try-finally -käskyn erinomaisuudesta. Toki mieluummin näkisin sinun itsesi tekemän koodipätkän, jossa olet jonkin asian ratkaissut tuolla.

xxxxx kirjoitti:

"Tuo koodi näyttää miten tiedoston käsittely voidaan tehdä (ja näin se peruskäyttäjä sen tekee)."

Tässä keskustelussa on kehuttu pascalin poikkeustenkäsittelyä ja tuossa koodissasi on se tehty kahdella if-then -käskyllä eikä käytetty pascalin try-finally -käskyä. Sitähän minä olen tässä jo monesti todistanut ettei try-finally -käsky ole mitenkään erinomainen lisä ohjelmointikieleen.

Sanoin edellisen viestisi koodiesimerkissä että "Delphi niin kuin Lazarus luo osan koodista taustalla". Mitä tarkoitat? Ainakin Visual Basic käyttää OpenDialog- ja SaveDialog-toiminnoissa käyttöjärjestelmän toimintoja eikä kielen omaa koodia. Eli esimerkkisi on lähinnä mainos Microsoftin Windowseille (ehkä sama toimii myös muissa uusissa käyttöjärjestelmissä jotka ovat ottaneet Microsoftin loistavista windowseista mallia).


"Jos todella haluat tietää poikkeusten käytöstä niin lataappa nyt vaikkapa Lazarus"

Tässä keskustelussa on keskusteltu poikkeuksista ja olen tyrmännyt Try-Finally ja Try-Except käskyjen erinomaisuuden poikkeuskoodin käsittelyssä. On outoa keskustelua että keskustelumme jälkeen sysäät vielä minun tehtäväksi selvittää asioita jotka olen jo tässä keskustelussa tyrmännyt. Tuo osoittaa että ainakaan tähän keskusteluun osaavat eivät joko osaa pascalia tai jos osaavat niin eivät kykene todistamaan väitteitään oikeiksi.


"Sen jälkeen kerron kuinka saat useita tuhansia kohtia missä on käytetty Try..Finally tai Try..Except poikkeuskoodia"

Noitahan saa kun Kuukleen syöttää "try except finally". Jos sinä olet pascal-asiantuntija, niin tuo tälle palstalle mielestäsi loistava esimerkki koodista, jolloin nähdään pätevätkö väitteesi vai pystynkö helpostikin murskaamaan väitteesi try-finally -käskyn erinomaisuudesta. Toki mieluummin näkisin sinun itsesi tekemän koodipätkän, jossa olet jonkin asian ratkaissut tuolla.

Lue lisää

En tiedä mitään muuta alunperin pikkupehmon keksintöä kuin rullahiiri. Toki pikkupehmolla on moniin asioihin (nykyään) oikeudet (joistakin niistä se on maksanut maltaita. No siltä voi saada paljon rahaa koska sitä sillä on). Esim. VB on alan cooperin myymä idea. Uudemmat ohjelmointiasiat mm dot.netit ovat lähinnä aikaisemmin Delphin (versioon 2 asti) taustalla toimineen Anders Hejlsberg:n ideoita (Ostamalla hyvin suurella summalla Anders Hejlsberg:n pikkupehmo pystyi torjumaan Delphille veikatun suuren suosion. Missä se onnistui.).

on näin kirjoitti:

En tiedä mitään muuta alunperin pikkupehmon keksintöä kuin rullahiiri. Toki pikkupehmolla on moniin asioihin (nykyään) oikeudet (joistakin niistä se on maksanut maltaita. No siltä voi saada paljon rahaa koska sitä sillä on). Esim. VB on alan cooperin myymä idea. Uudemmat ohjelmointiasiat mm dot.netit ovat lähinnä aikaisemmin Delphin (versioon 2 asti) taustalla toimineen Anders Hejlsberg:n ideoita (Ostamalla hyvin suurella summalla Anders Hejlsberg:n pikkupehmo pystyi torjumaan Delphille veikatun suuren suosion. Missä se onnistui.).

Lue lisää

Olihan Microsoft jo aikoinaan CP/M -käyttöjärjestelmän ohjelmointikielten toimittaja, joten kyllä heillä on ohjelmoinnista paljon kokemusta.

Mitä sitten että Microsoft on ostanut muiden ideoita ja niistä tehnyt Visual Basicin?

Microsoft on tehnyt hommat niin taitavasti että on saanut tuotteistansa paljon rahaa. Ihmiset maksavat Microsoftin Windowseista vaikka saisivat muita ikkunakäyttöjärjestelmiä ilmaiseksi. Asiakkaat maksavat Microsoftin Wordistä, Excelistä ja Visual Basicista sillä ne ovat ainakin kokonaisuutena parempia kuin ilmaiset Linuxit, tekstinkäsittelyt, taulukkolaskennat ja pascalit.

Eli ei siinä ole mitään pahaa että yritys ostaa ideoita muilta ja lisää muiden ohjelmien ideoita omiin ohjelmiinsa. Sitähän ohjelmakehitys on, että saadaan asiakkailta ja muilta tahoilta vinkkejä miten hommaa kannattaa parantaa.

xxxxx kirjoitti:

"Tuo koodi näyttää miten tiedoston käsittely voidaan tehdä (ja näin se peruskäyttäjä sen tekee)."

Tässä keskustelussa on kehuttu pascalin poikkeustenkäsittelyä ja tuossa koodissasi on se tehty kahdella if-then -käskyllä eikä käytetty pascalin try-finally -käskyä. Sitähän minä olen tässä jo monesti todistanut ettei try-finally -käsky ole mitenkään erinomainen lisä ohjelmointikieleen.

Sanoin edellisen viestisi koodiesimerkissä että "Delphi niin kuin Lazarus luo osan koodista taustalla". Mitä tarkoitat? Ainakin Visual Basic käyttää OpenDialog- ja SaveDialog-toiminnoissa käyttöjärjestelmän toimintoja eikä kielen omaa koodia. Eli esimerkkisi on lähinnä mainos Microsoftin Windowseille (ehkä sama toimii myös muissa uusissa käyttöjärjestelmissä jotka ovat ottaneet Microsoftin loistavista windowseista mallia).


"Jos todella haluat tietää poikkeusten käytöstä niin lataappa nyt vaikkapa Lazarus"

Tässä keskustelussa on keskusteltu poikkeuksista ja olen tyrmännyt Try-Finally ja Try-Except käskyjen erinomaisuuden poikkeuskoodin käsittelyssä. On outoa keskustelua että keskustelumme jälkeen sysäät vielä minun tehtäväksi selvittää asioita jotka olen jo tässä keskustelussa tyrmännyt. Tuo osoittaa että ainakaan tähän keskusteluun osaavat eivät joko osaa pascalia tai jos osaavat niin eivät kykene todistamaan väitteitään oikeiksi.


"Sen jälkeen kerron kuinka saat useita tuhansia kohtia missä on käytetty Try..Finally tai Try..Except poikkeuskoodia"

Noitahan saa kun Kuukleen syöttää "try except finally". Jos sinä olet pascal-asiantuntija, niin tuo tälle palstalle mielestäsi loistava esimerkki koodista, jolloin nähdään pätevätkö väitteesi vai pystynkö helpostikin murskaamaan väitteesi try-finally -käskyn erinomaisuudesta. Toki mieluummin näkisin sinun itsesi tekemän koodipätkän, jossa olet jonkin asian ratkaissut tuolla.

Lue lisää

Väittänet taas sitä että poikkeukset olisivat huuhaata. Ihmettelen millä ihmeellä perustelet että joku nimimerkki xxxxx on paljon viisaampi kuin moni ohjelmointikielen kehittäjä. Niinkuin on todettu poikkeuksia käytetään useissa kielissä.

Väittäisin että pää syy on se että kun sitä ominaisuutta ei löydy (täydellisenä) minun kielestä niin sitten voit sanoa että se ei ole niin hyvä ominaisuus.

xxxxx kirjoitti:

Olihan Microsoft jo aikoinaan CP/M -käyttöjärjestelmän ohjelmointikielten toimittaja, joten kyllä heillä on ohjelmoinnista paljon kokemusta.

Mitä sitten että Microsoft on ostanut muiden ideoita ja niistä tehnyt Visual Basicin?

Microsoft on tehnyt hommat niin taitavasti että on saanut tuotteistansa paljon rahaa. Ihmiset maksavat Microsoftin Windowseista vaikka saisivat muita ikkunakäyttöjärjestelmiä ilmaiseksi. Asiakkaat maksavat Microsoftin Wordistä, Excelistä ja Visual Basicista sillä ne ovat ainakin kokonaisuutena parempia kuin ilmaiset Linuxit, tekstinkäsittelyt, taulukkolaskennat ja pascalit.

Eli ei siinä ole mitään pahaa että yritys ostaa ideoita muilta ja lisää muiden ohjelmien ideoita omiin ohjelmiinsa. Sitähän ohjelmakehitys on, että saadaan asiakkailta ja muilta tahoilta vinkkejä miten hommaa kannattaa parantaa.

Lue lisää

CP/M -käyttöjärjestelmä ja MS-dos olivat kilpailijoita aikoinaan. Kun IBM valitsi MS-dosin niin se voitti kilpailun. On väitetty että bill olisi "lainannut" muiden koodia siihen.

Microsoftin tuotteet eivät ole (välttämättä) parempia vaan ihmisten ostopäätökset useimmiten perustuvat markkinoinnin tehokkuuteen ja senhän Microsofti osaa.


No siinä olet oikeassa että se on aivan sallittua kaupankäyntiä ostaa muilta ideoita, tuotteita ja myös vastaavia tuotteita voi ja saa tehdä (tosin joitakin asioita voidaan suojata muutaman vuoden ajan)

Tunnettavuus kirjoitti:

CP/M -käyttöjärjestelmä ja MS-dos olivat kilpailijoita aikoinaan. Kun IBM valitsi MS-dosin niin se voitti kilpailun. On väitetty että bill olisi "lainannut" muiden koodia siihen.

Microsoftin tuotteet eivät ole (välttämättä) parempia vaan ihmisten ostopäätökset useimmiten perustuvat markkinoinnin tehokkuuteen ja senhän Microsofti osaa.


No siinä olet oikeassa että se on aivan sallittua kaupankäyntiä ostaa muilta ideoita, tuotteita ja myös vastaavia tuotteita voi ja saa tehdä (tosin joitakin asioita voidaan suojata muutaman vuoden ajan)

Lue lisää

"CP/M -käyttöjärjestelmä ja MS-dos olivat kilpailijoita aikoinaan. Kun IBM valitsi MS-dosin niin se voitti kilpailun. On väitetty että bill olisi "lainannut" muiden koodia siihen."

Olenko väittänyt muuta? Itse silloin työssäni käytin Concurrent CP/M -käyttöjärjestelmää (se ajoi montaa ohjelmaa yhtäaikaa), joka kaikkien mielestä oli MS-dos -käyttöjärjestelmää parempi. Myös minä olin sitä mieltä. Mutta ehkä IBM juuri sen vuoksi valitsi MS-dosin, että se oli huonompi, sillä he halusivat PC:llä tehtävän vain yksinkertaisia asioita.



"Microsoftin tuotteet eivät ole (välttämättä) parempia vaan ihmisten ostopäätökset useimmiten perustuvat markkinoinnin tehokkuuteen ja senhän Microsofti osaa."

Miksi yritykset, kunnat ja valtiot sitten eivät hanki ilmaista Linuxia ja muita ohjelmia? Miksi tietokonelehdet ja asiantuntijat muualla eivät tuo julki että kannattaa hankkia ilmaisia ohjelmia mieluummin kuin Microsoftin ohjelmia?

On aika yksisilmäistä ajatella että Microsoftin menestys perustuu markkinoinnin tehokkuuteen. Jotkut suhtautuvat näihin asioihin kuin uskontoon: Vaikka todistetaan mitä ja tyrmätään vastaväitteet, niin sitten kuitenkin sanotaan että Microsoftin menestys ei perustu ohjelmien hyvyyteen.


Joten voisitko yksilöidä missä kohdassa edellisessä viestissäni tai koko tässä kirjoitusketjussa olen puhunut paskaa?

Tunnettavuus kirjoitti:

Väittänet taas sitä että poikkeukset olisivat huuhaata. Ihmettelen millä ihmeellä perustelet että joku nimimerkki xxxxx on paljon viisaampi kuin moni ohjelmointikielen kehittäjä. Niinkuin on todettu poikkeuksia käytetään useissa kielissä.

Väittäisin että pää syy on se että kun sitä ominaisuutta ei löydy (täydellisenä) minun kielestä niin sitten voit sanoa että se ei ole niin hyvä ominaisuus.

Lue lisää

Se kaikki mitä tässä kirjoitusketjussa on mainittu kuuluvan poikkeustenkäsittelyyn löytyy kyllä Visual Bascista.

Jos jossain muussa kielessä on jotain poikkeuksiin liittyvää mitä mielestäsi ei voi Visual Basicilla tehdä, niin laita esimerkkikoodi ja minä sitten kirjoitan vastaavan koodin Visual Basicilla.


"Niinkuin on todettu poikkeuksia käytetään useissa kielissä."

Minähän olen tässä keskustelussa juuri sanonut että poikkeuksia käytetään kaikissa ohjelmointikielissä. Joka kielessä on vähintään if-then -ehto poikkeusten käsittelyyn.



"Väittänet taas sitä että poikkeukset olisivat huuhaata. Ihmettelen millä ihmeellä perustelet että joku nimimerkki xxxxx on paljon viisaampi kuin moni ohjelmointikielen kehittäjä."

En minä sitä väitä. Minä väitän että Delphin try-finally -käsky ei ole mitään erinomaisempaa kuin Visual Basicin vastaava. Monet tällä palstalla leikkivät käsitteillä ja käskyjen nimillä ymmärtämättä mitä koodaus kokonaisuudessaan ja kaikessa yksinkertaisuudessaan on.

Pidä tuota haasteena, joten todista pystytkö vastaamaan puheistasi etkä jauha vain jotain yleistä paskaa?

xxxxx kirjoitti:

Se kaikki mitä tässä kirjoitusketjussa on mainittu kuuluvan poikkeustenkäsittelyyn löytyy kyllä Visual Bascista.

Jos jossain muussa kielessä on jotain poikkeuksiin liittyvää mitä mielestäsi ei voi Visual Basicilla tehdä, niin laita esimerkkikoodi ja minä sitten kirjoitan vastaavan koodin Visual Basicilla.


"Niinkuin on todettu poikkeuksia käytetään useissa kielissä."

Minähän olen tässä keskustelussa juuri sanonut että poikkeuksia käytetään kaikissa ohjelmointikielissä. Joka kielessä on vähintään if-then -ehto poikkeusten käsittelyyn.



"Väittänet taas sitä että poikkeukset olisivat huuhaata. Ihmettelen millä ihmeellä perustelet että joku nimimerkki xxxxx on paljon viisaampi kuin moni ohjelmointikielen kehittäjä."

En minä sitä väitä. Minä väitän että Delphin try-finally -käsky ei ole mitään erinomaisempaa kuin Visual Basicin vastaava. Monet tällä palstalla leikkivät käsitteillä ja käskyjen nimillä ymmärtämättä mitä koodaus kokonaisuudessaan ja kaikessa yksinkertaisuudessaan on.

Pidä tuota haasteena, joten todista pystytkö vastaamaan puheistasi etkä jauha vain jotain yleistä paskaa?

Lue lisää

Koska olet toivonut (minultakin) niin paljon Pascal-koodia niin tässä on pieni koodin palanen.

Koodi on hyvin simppeli mutta se kertoo periaatteen . Eli jos annat sellaisia syötteitä kuin ohjelmassa pyydetään niin ohjelma etenee ja loppuu ajallaan. Muuten nostetaan poikkeus ja kerrotaan että ohjelman suoritus lopetaan sekä sen syy.


program koe1;

{$mode objfpc}{$H }

uses
Classes,sysutils;
procedure homma1;
var s:integer;
begin
writeln('anna kokonaisluku');
readln(s);
writeln ('annettu luku oli: ',s);
end;
procedure homma2;
var s:string;
begin
writeln('anna jotain merkkejä');
readln(s);
writeln ('annettuja merkkejä oli: ',s);
end;
procedure testijatkuu;
begin
writeln('testi jatkuu yhä');
homma1;
writeln('hienoa');
end;
begin
try
try
writeln('Ohjelma aloitetaan');
homma1;
homma2;
homma1;
testijatkuu;
homma2;
homma1;
finally
writeln('Ohjelma lopetetaan');
end;
except
on E : EInOutError do begin
writeln('koska et antanut numeroa');
end;
end;
end.

FreePascal kirjoitti:

Koska olet toivonut (minultakin) niin paljon Pascal-koodia niin tässä on pieni koodin palanen.

Koodi on hyvin simppeli mutta se kertoo periaatteen . Eli jos annat sellaisia syötteitä kuin ohjelmassa pyydetään niin ohjelma etenee ja loppuu ajallaan. Muuten nostetaan poikkeus ja kerrotaan että ohjelman suoritus lopetaan sekä sen syy.


program koe1;

{$mode objfpc}{$H }

uses
Classes,sysutils;
procedure homma1;
var s:integer;
begin
writeln('anna kokonaisluku');
readln(s);
writeln ('annettu luku oli: ',s);
end;
procedure homma2;
var s:string;
begin
writeln('anna jotain merkkejä');
readln(s);
writeln ('annettuja merkkejä oli: ',s);
end;
procedure testijatkuu;
begin
writeln('testi jatkuu yhä');
homma1;
writeln('hienoa');
end;
begin
try
try
writeln('Ohjelma aloitetaan');
homma1;
homma2;
homma1;
testijatkuu;
homma2;
homma1;
finally
writeln('Ohjelma lopetetaan');
end;
except
on E : EInOutError do begin
writeln('koska et antanut numeroa');
end;
end;
end.

Lue lisää

Kyllähän tuo asian kertoo, mutta muutama huomioni siitä.

Ainakin vielä 1990-luvulla pidettiin huonona koodauksena jos virheet käsitellään virherutiinissa, sillä virhekäsittelyä (kuten pascalin Try-Except-Finally -käskyä ja Basicin On Error -käskyä) pitää käyttää vain odottamattomien virheiden tullessa. Eli ohjelmoija yrittää ohjelmaa tehdessä ennakoida kaikki virheet että ne korjataan fiksusti if-then -käskyllä ja ilmoituksella, jolloin voidaan kysyä edellinen syöttötieto uudestaan eikä lopeteta ohjelmaa kesken.

Uskoakseni on myös niin, että jos ohjelmoija käyttää virherutiinia (joita tällä palstalla on kutsuttu poikkeuksiksi) paljon varsinaisessa ohjelmoinnissa, niin koodin tasokkuus alkaa lipsua. Eli tämänkin vuoksi mielestäni ohjelmoijan tulisi pitää omaa koodiaan huonona silloin jos suoritus menee virherutiiniin, sillä se kertoo että ohjelmoija ei ollut ymmärtänyt ajatella ohjelman suoritusta, syöttöarvoja ja muita ongelmatilanteita ohjelmaa koodatessa. Koodajaan tarkkaavaisuuden vähetessä (koska hän ajattelee että asiat hoituu virherutiinilla) alkaa ohjelmaan myös tulla lisää loogisia virheitä. Vähän samaan tapaan jos joku kirjoittaa nettiin tai tekstiviesteihin lyhennyksiä ja huonoa suomea, niin vähitellen suomenkielen taito rapautuu. Tai kun joku luottaa hyvään sairaalahoitoon ja siihen että kaikki hoituu, niin hän ei ota edes matkavakuutusta, jolloin tsunamin alle jäätyä ihmetellään miksi kukaan ei korvaa. Tuo on mielestäni hyvä vertaus poikkeustapauksista: virhe jota ei oikeastaan kannattanut muuten ennakoida kuin ottamalla vakuutus (eli Try-Except). Sama on tietysti ohjelmakoodissa siten, että kaikkea ei pidä ennakoida sillä koodin tekemiseen menisi turhan paljon aikaa.


Visual Basicilla sinun esimerkkiohjelma menee näin:


Sub Homma1
var s as Integer
s= InputBox("Anna kokonaisluku")
Call MsgBox("Annettu luku oli" str$(s))
End Sub

Sub Homma2
var s as string
s= InputBox("Anna jotain merkkejä")
Call MsgBox("Annettu merkkijono oli " s)
End Sub

Sub TestiJatkuu
Call MsgBox("Testi jatkuu yhä")
Homma 1
Call MsgBox("Hienoa")
End Sub

Sub Main
on error goto Virherutiini
Homma1
Homma2
Homma1
TestiJatkuu
Homma2
Homma1
Call MsgBox("Ohjelma lopetetaan")
Exit Sub

Virherutiini:
call MsgBox("Annettu virheellinen syöttötieto")

End Sub



Jos joku haluaa oppia perusteita Visual Basic for Applicationista (VBA) ja tekemään pieniä ohjelmia Excelin ja Wordin sisällä, niin alkuun pääsee esim. sivulla http://appro.mit.jyu.fi/doc/tiedonhallinta/vba/

xxxxx kirjoitti:

Kyllähän tuo asian kertoo, mutta muutama huomioni siitä.

Ainakin vielä 1990-luvulla pidettiin huonona koodauksena jos virheet käsitellään virherutiinissa, sillä virhekäsittelyä (kuten pascalin Try-Except-Finally -käskyä ja Basicin On Error -käskyä) pitää käyttää vain odottamattomien virheiden tullessa. Eli ohjelmoija yrittää ohjelmaa tehdessä ennakoida kaikki virheet että ne korjataan fiksusti if-then -käskyllä ja ilmoituksella, jolloin voidaan kysyä edellinen syöttötieto uudestaan eikä lopeteta ohjelmaa kesken.

Uskoakseni on myös niin, että jos ohjelmoija käyttää virherutiinia (joita tällä palstalla on kutsuttu poikkeuksiksi) paljon varsinaisessa ohjelmoinnissa, niin koodin tasokkuus alkaa lipsua. Eli tämänkin vuoksi mielestäni ohjelmoijan tulisi pitää omaa koodiaan huonona silloin jos suoritus menee virherutiiniin, sillä se kertoo että ohjelmoija ei ollut ymmärtänyt ajatella ohjelman suoritusta, syöttöarvoja ja muita ongelmatilanteita ohjelmaa koodatessa. Koodajaan tarkkaavaisuuden vähetessä (koska hän ajattelee että asiat hoituu virherutiinilla) alkaa ohjelmaan myös tulla lisää loogisia virheitä. Vähän samaan tapaan jos joku kirjoittaa nettiin tai tekstiviesteihin lyhennyksiä ja huonoa suomea, niin vähitellen suomenkielen taito rapautuu. Tai kun joku luottaa hyvään sairaalahoitoon ja siihen että kaikki hoituu, niin hän ei ota edes matkavakuutusta, jolloin tsunamin alle jäätyä ihmetellään miksi kukaan ei korvaa. Tuo on mielestäni hyvä vertaus poikkeustapauksista: virhe jota ei oikeastaan kannattanut muuten ennakoida kuin ottamalla vakuutus (eli Try-Except). Sama on tietysti ohjelmakoodissa siten, että kaikkea ei pidä ennakoida sillä koodin tekemiseen menisi turhan paljon aikaa.


Visual Basicilla sinun esimerkkiohjelma menee näin:


Sub Homma1
var s as Integer
s= InputBox("Anna kokonaisluku")
Call MsgBox("Annettu luku oli" str$(s))
End Sub

Sub Homma2
var s as string
s= InputBox("Anna jotain merkkejä")
Call MsgBox("Annettu merkkijono oli " s)
End Sub

Sub TestiJatkuu
Call MsgBox("Testi jatkuu yhä")
Homma 1
Call MsgBox("Hienoa")
End Sub

Sub Main
on error goto Virherutiini
Homma1
Homma2
Homma1
TestiJatkuu
Homma2
Homma1
Call MsgBox("Ohjelma lopetetaan")
Exit Sub

Virherutiini:
call MsgBox("Annettu virheellinen syöttötieto")

End Sub



Jos joku haluaa oppia perusteita Visual Basic for Applicationista (VBA) ja tekemään pieniä ohjelmia Excelin ja Wordin sisällä, niin alkuun pääsee esim. sivulla http://appro.mit.jyu.fi/doc/tiedonhallinta/vba/

Lue lisää

Poikkeuksia kannattaa käyttää kun tekee esim dll (tai linuxissa so) -kirjastoja.

Tunnettavuus kirjoitti:

Poikkeuksia kannattaa käyttää kun tekee esim dll (tai linuxissa so) -kirjastoja.

Voisitko laittaa pascal-kielisen esimerkkikoodin, joka mielestäsi tuo hyvin esiin poikkeusten käyttämisen dll- tai so-kirjastossa?

xxxxx kirjoitti:

"Tuo koodi näyttää miten tiedoston käsittely voidaan tehdä (ja näin se peruskäyttäjä sen tekee)."

Tässä keskustelussa on kehuttu pascalin poikkeustenkäsittelyä ja tuossa koodissasi on se tehty kahdella if-then -käskyllä eikä käytetty pascalin try-finally -käskyä. Sitähän minä olen tässä jo monesti todistanut ettei try-finally -käsky ole mitenkään erinomainen lisä ohjelmointikieleen.

Sanoin edellisen viestisi koodiesimerkissä että "Delphi niin kuin Lazarus luo osan koodista taustalla". Mitä tarkoitat? Ainakin Visual Basic käyttää OpenDialog- ja SaveDialog-toiminnoissa käyttöjärjestelmän toimintoja eikä kielen omaa koodia. Eli esimerkkisi on lähinnä mainos Microsoftin Windowseille (ehkä sama toimii myös muissa uusissa käyttöjärjestelmissä jotka ovat ottaneet Microsoftin loistavista windowseista mallia).


"Jos todella haluat tietää poikkeusten käytöstä niin lataappa nyt vaikkapa Lazarus"

Tässä keskustelussa on keskusteltu poikkeuksista ja olen tyrmännyt Try-Finally ja Try-Except käskyjen erinomaisuuden poikkeuskoodin käsittelyssä. On outoa keskustelua että keskustelumme jälkeen sysäät vielä minun tehtäväksi selvittää asioita jotka olen jo tässä keskustelussa tyrmännyt. Tuo osoittaa että ainakaan tähän keskusteluun osaavat eivät joko osaa pascalia tai jos osaavat niin eivät kykene todistamaan väitteitään oikeiksi.


"Sen jälkeen kerron kuinka saat useita tuhansia kohtia missä on käytetty Try..Finally tai Try..Except poikkeuskoodia"

Noitahan saa kun Kuukleen syöttää "try except finally". Jos sinä olet pascal-asiantuntija, niin tuo tälle palstalle mielestäsi loistava esimerkki koodista, jolloin nähdään pätevätkö väitteesi vai pystynkö helpostikin murskaamaan väitteesi try-finally -käskyn erinomaisuudesta. Toki mieluummin näkisin sinun itsesi tekemän koodipätkän, jossa olet jonkin asian ratkaissut tuolla.

Lue lisää

"Sanoin edellisen viestisi koodiesimerkissä että "Delphi niin kuin Lazarus luo osan koodista taustalla". Mitä tarkoitat?"

Sitä että Delphi niin kuin Lazarus lisää lähdekoodiin tekstiä. Aiemmin esitetyn esimerkin teksteistä nämä on tehnyt ohjelmointiympäristö (ja osa poistetuista teksteistä saadaan aikaan koodin täydentäjillä). Kokeile niin ymmärrät asian paremmin.

unit memounit;

{$mode objfpc}{$H }

interface

uses
Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs, StdCtrls, Menus;

type

{ TForm1 }

TForm1 = class(TForm)
MainMenu1: TMainMenu;
Tiedostovalikko: TMenuItem;
MenunUuusiKohta: TMenuItem;
MenunLopetaKohta: TMenuItem;
MenunAvaaKohta: TMenuItem;
MenunTallennaKohta: TMenuItem;
Memo1: TMemo;
OpenDialog1: TOpenDialog;
SaveDialog1: TSaveDialog;
procedure MenunAvaaKohta1Click(Sender: TObject);
procedure MenunLopetaKohtaClick(Sender: TObject);
procedure MenunTallennaKohtaClick(Sender: TObject);
procedure MenunUuusiKohtaClick(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;

var
Form1: TForm1;

implementation

{ TForm1 }

procedure TForm1.MenunAvaaKohta1Click(Sender: TObject);
begin


end;


procedure TForm1.MenunTallennaKohtaClick(Sender: TObject);
begin


end;

procedure TForm1.MenunUuusiKohtaClick(Sender: TObject);
begin

end;

procedure TForm1.MenunLopetaKohtaClick(Sender: TObject);
begin

end;

initialization
{$I memounit.lrs}

end.

Lazarus. kirjoitti:

"Sanoin edellisen viestisi koodiesimerkissä että "Delphi niin kuin Lazarus luo osan koodista taustalla". Mitä tarkoitat?"

Sitä että Delphi niin kuin Lazarus lisää lähdekoodiin tekstiä. Aiemmin esitetyn esimerkin teksteistä nämä on tehnyt ohjelmointiympäristö (ja osa poistetuista teksteistä saadaan aikaan koodin täydentäjillä). Kokeile niin ymmärrät asian paremmin.

unit memounit;

{$mode objfpc}{$H }

interface

uses
Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs, StdCtrls, Menus;

type

{ TForm1 }

TForm1 = class(TForm)
MainMenu1: TMainMenu;
Tiedostovalikko: TMenuItem;
MenunUuusiKohta: TMenuItem;
MenunLopetaKohta: TMenuItem;
MenunAvaaKohta: TMenuItem;
MenunTallennaKohta: TMenuItem;
Memo1: TMemo;
OpenDialog1: TOpenDialog;
SaveDialog1: TSaveDialog;
procedure MenunAvaaKohta1Click(Sender: TObject);
procedure MenunLopetaKohtaClick(Sender: TObject);
procedure MenunTallennaKohtaClick(Sender: TObject);
procedure MenunUuusiKohtaClick(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;

var
Form1: TForm1;

implementation

{ TForm1 }

procedure TForm1.MenunAvaaKohta1Click(Sender: TObject);
begin


end;


procedure TForm1.MenunTallennaKohtaClick(Sender: TObject);
begin


end;

procedure TForm1.MenunUuusiKohtaClick(Sender: TObject);
begin

end;

procedure TForm1.MenunLopetaKohtaClick(Sender: TObject);
begin

end;

initialization
{$I memounit.lrs}

end.

Lue lisää

Tottakai ohjelmointikieli luo osan koodia taustalla. Näin tekee kaikki kääntäjät. Esim. merkin tulostus kuvaruudulle on ohjelmointikielessä esim. print "tekstiä". Kääntäjä sitten kääntää homman konekielelle ja tekee tarvittavat lisäykset, jotta käyttöjärjestelmä länttää tekstin ruudulle. Ohjelmointikielessä on myös tietysti valmiit rutiinit eri toiminnoille kuten matemaattisille funktioille.

Mutta palataan tuohon esimerkkiisi, joka on nyt jo toisen kerran tässä keskustellussa, joten sen täytyy mielestäsi olla hyvä esimerkki tukemaan väitteitäsi.

Minä jo aikaisemmin sanoin, että esimerkkisi OpenDialog- ja SaveDialog-mokkulat ovat samantyyppisiä kuin on myös Visual Basicissa. Visual Basicissa kääntäjä ei siis varsinaisesti tee koodia vaan välittää käyttöjärjestelmälle ohjelmoijan määrittämät parametrit, jolloin ruutuun tulee käyttöjärjestelmän tiedoston nimen kysely. Tästä on se etu kääntäjän lisäämään koodiin verrattuna, että tiedostonnimenkyselyruutu on samalla kielellä kuin käyttöjärjestelmän kieli. Todennäköisesti Delphi ja Lazarus tekevät samalla tavalla. Ja samoin myös noiden valikoiden suhteen, jolloin ohjelman valikot noudattavat Windows-XP:ssä samaa muotoa kuin muut ohjelmat.

Eli se on ohjelmointiympäristön tehtävä, että kun käyttäjä vaikka tallentaa merkin tiedostoon, niin kääntäjä käyttää käyttöjärjestelmän toimintoa siihen eikä varsinaisesti omaa koodia.

Ja kuten tässä viestissä jo ylempänä sanoin, niin kun toit tuon esimerkkikoodin jo toisen kerran, niin se sitten varmasti mielestäsi kuvaa hyvin esimerkkiä Delphin ja Lazaruksen lisäämästä omasta koodista. Oletko edelleen samaa mieltä? Jos olet niin pysytään esimerkkikoodissasi ja perustele siihen liittyen väitteesi hiukan yksilöidymmin.

xxxxx kirjoitti:

Tottakai ohjelmointikieli luo osan koodia taustalla. Näin tekee kaikki kääntäjät. Esim. merkin tulostus kuvaruudulle on ohjelmointikielessä esim. print "tekstiä". Kääntäjä sitten kääntää homman konekielelle ja tekee tarvittavat lisäykset, jotta käyttöjärjestelmä länttää tekstin ruudulle. Ohjelmointikielessä on myös tietysti valmiit rutiinit eri toiminnoille kuten matemaattisille funktioille.

Mutta palataan tuohon esimerkkiisi, joka on nyt jo toisen kerran tässä keskustellussa, joten sen täytyy mielestäsi olla hyvä esimerkki tukemaan väitteitäsi.

Minä jo aikaisemmin sanoin, että esimerkkisi OpenDialog- ja SaveDialog-mokkulat ovat samantyyppisiä kuin on myös Visual Basicissa. Visual Basicissa kääntäjä ei siis varsinaisesti tee koodia vaan välittää käyttöjärjestelmälle ohjelmoijan määrittämät parametrit, jolloin ruutuun tulee käyttöjärjestelmän tiedoston nimen kysely. Tästä on se etu kääntäjän lisäämään koodiin verrattuna, että tiedostonnimenkyselyruutu on samalla kielellä kuin käyttöjärjestelmän kieli. Todennäköisesti Delphi ja Lazarus tekevät samalla tavalla. Ja samoin myös noiden valikoiden suhteen, jolloin ohjelman valikot noudattavat Windows-XP:ssä samaa muotoa kuin muut ohjelmat.

Eli se on ohjelmointiympäristön tehtävä, että kun käyttäjä vaikka tallentaa merkin tiedostoon, niin kääntäjä käyttää käyttöjärjestelmän toimintoa siihen eikä varsinaisesti omaa koodia.

Ja kuten tässä viestissä jo ylempänä sanoin, niin kun toit tuon esimerkkikoodin jo toisen kerran, niin se sitten varmasti mielestäsi kuvaa hyvin esimerkkiä Delphin ja Lazaruksen lisäämästä omasta koodista. Oletko edelleen samaa mieltä? Jos olet niin pysytään esimerkkikoodissasi ja perustele siihen liittyen väitteesi hiukan yksilöidymmin.

Lue lisää

Tarkoitat tuolla eri asiaa kuin minä.

Eli ymmärtänet asian jos kokeilisit edes kerran Delphiä tai Lazarusta.

Yllä oleva esimerkkikoodi (samasta asiasta) selittää myös tämän kunhan vertailet niitä kahta toisiinsa rivi riviltä (mutta helpoimmin ymmärrät mitä tarkoitan kun kokeilet itse)

Lazarus. kirjoitti:

Tarkoitat tuolla eri asiaa kuin minä.

Eli ymmärtänet asian jos kokeilisit edes kerran Delphiä tai Lazarusta.

Yllä oleva esimerkkikoodi (samasta asiasta) selittää myös tämän kunhan vertailet niitä kahta toisiinsa rivi riviltä (mutta helpoimmin ymmärrät mitä tarkoitan kun kokeilet itse)

Lue lisää

Jos sinulla on siitä selkeätä tietoa niin kerro. On typerää keskustelua vaatia minua selvittämään mitä sinä tarkoitat. Siis kun sinähän tässä olet esiintynyt pascal-tietäjänä.

Minulle riittää Visual Basic, sillä tässä keskustelussa ei ole tullut ilmi syitä, joiden vuoksi kannattaisi vaihtaa pascaliin. Eli Visual Basic on tämän keskustelun mukaan ylivoimainen pascaliisi verrattuna.

xxxxx kirjoitti:

Jos sinulla on siitä selkeätä tietoa niin kerro. On typerää keskustelua vaatia minua selvittämään mitä sinä tarkoitat. Siis kun sinähän tässä olet esiintynyt pascal-tietäjänä.

Minulle riittää Visual Basic, sillä tässä keskustelussa ei ole tullut ilmi syitä, joiden vuoksi kannattaisi vaihtaa pascaliin. Eli Visual Basic on tämän keskustelun mukaan ylivoimainen pascaliisi verrattuna.

Lue lisää

Monia asioita on jo kerrottu. Ehkäpä kannattaisi lukea nämä viestit läpi.

Lazarus. kirjoitti:

Monia asioita on jo kerrottu. Ehkäpä kannattaisi lukea nämä viestit läpi.

Monia asioita olette yrittäneet selittää, mutta varsinaista asiaa on ollut vähän ja vielä vähemmän vastauksia.

Lazarus. kirjoitti:

Monia asioita on jo kerrottu. Ehkäpä kannattaisi lukea nämä viestit läpi.

Niin alunperin sinun piti vertailla vain kahta viestiä (jotka jo on tässä ketjussa).

xxxxx kirjoitti:

Kyllähän tuo asian kertoo, mutta muutama huomioni siitä.

Ainakin vielä 1990-luvulla pidettiin huonona koodauksena jos virheet käsitellään virherutiinissa, sillä virhekäsittelyä (kuten pascalin Try-Except-Finally -käskyä ja Basicin On Error -käskyä) pitää käyttää vain odottamattomien virheiden tullessa. Eli ohjelmoija yrittää ohjelmaa tehdessä ennakoida kaikki virheet että ne korjataan fiksusti if-then -käskyllä ja ilmoituksella, jolloin voidaan kysyä edellinen syöttötieto uudestaan eikä lopeteta ohjelmaa kesken.

Uskoakseni on myös niin, että jos ohjelmoija käyttää virherutiinia (joita tällä palstalla on kutsuttu poikkeuksiksi) paljon varsinaisessa ohjelmoinnissa, niin koodin tasokkuus alkaa lipsua. Eli tämänkin vuoksi mielestäni ohjelmoijan tulisi pitää omaa koodiaan huonona silloin jos suoritus menee virherutiiniin, sillä se kertoo että ohjelmoija ei ollut ymmärtänyt ajatella ohjelman suoritusta, syöttöarvoja ja muita ongelmatilanteita ohjelmaa koodatessa. Koodajaan tarkkaavaisuuden vähetessä (koska hän ajattelee että asiat hoituu virherutiinilla) alkaa ohjelmaan myös tulla lisää loogisia virheitä. Vähän samaan tapaan jos joku kirjoittaa nettiin tai tekstiviesteihin lyhennyksiä ja huonoa suomea, niin vähitellen suomenkielen taito rapautuu. Tai kun joku luottaa hyvään sairaalahoitoon ja siihen että kaikki hoituu, niin hän ei ota edes matkavakuutusta, jolloin tsunamin alle jäätyä ihmetellään miksi kukaan ei korvaa. Tuo on mielestäni hyvä vertaus poikkeustapauksista: virhe jota ei oikeastaan kannattanut muuten ennakoida kuin ottamalla vakuutus (eli Try-Except). Sama on tietysti ohjelmakoodissa siten, että kaikkea ei pidä ennakoida sillä koodin tekemiseen menisi turhan paljon aikaa.


Visual Basicilla sinun esimerkkiohjelma menee näin:


Sub Homma1
var s as Integer
s= InputBox("Anna kokonaisluku")
Call MsgBox("Annettu luku oli" str$(s))
End Sub

Sub Homma2
var s as string
s= InputBox("Anna jotain merkkejä")
Call MsgBox("Annettu merkkijono oli " s)
End Sub

Sub TestiJatkuu
Call MsgBox("Testi jatkuu yhä")
Homma 1
Call MsgBox("Hienoa")
End Sub

Sub Main
on error goto Virherutiini
Homma1
Homma2
Homma1
TestiJatkuu
Homma2
Homma1
Call MsgBox("Ohjelma lopetetaan")
Exit Sub

Virherutiini:
call MsgBox("Annettu virheellinen syöttötieto")

End Sub



Jos joku haluaa oppia perusteita Visual Basic for Applicationista (VBA) ja tekemään pieniä ohjelmia Excelin ja Wordin sisällä, niin alkuun pääsee esim. sivulla http://appro.mit.jyu.fi/doc/tiedonhallinta/vba/

Lue lisää

Delphi ja VB -ohjelma *eivät* tee samaa!

" Call MsgBox("Ohjelma lopetetaan") "

tuossa VB -koodissa tuota "Ohjelma lopetetaan" EI näytetä jos tulee poikkeus.

em. Delphi -ohjelmassa taas tuo "Ohjelma lopetetaan" näytetään AINA, tuli poikkeus tai ei.

Delphissä siis näin:

try

// koodia, joka SAATTAA aiheuttaa poikkeuksen

finally

// koodia, joka suoritetaan lopuksi AINA, tuli poikkeus tai ei.

end;

try

// koodia, joka SAATTAA aiheuttaa poikkeuksen

except

// koodia, joka suoritetaan VAIN jos tulee poikkeus.


ON E:Exception do
ShowMessage('Aiheutui poikkeus, tarkemmin: ' E.Message);
end;

esim Delphissä TÄMÄ aiheuttaa poikkeuksen:

procedure Test1;
var
A,B,C : Integer;

begin

//
A := 5; B := 0;

try
//

C := A div B; // C on A jaettuna B:llä

except

//

On E:Exception do begin end;

end;

end;

Tämä esimerkki "syö" poikkeuksen! Poikkeus ei siis automaattisesti lopeta ohjelmaa. Kutsuttaessa Test1 -proseduuria, nollalla jakamisesta aiheutuva virhetilanne EI mitenkään näy sille, joka kutsuu Test1 -proseduuria! Eli kutsujan kannalta asiat ovat aivan, kuin mitään poikkeusta ei tapahtuisikaan.

Mutta tuohon on E:Exeption do begin end; -väliin voisi kirjoittaa vaikkapa

LoggaaPoikkeus(E.Message);

joka määriteltäisiin näin:

const
LogFileName = 'C:\DelphiDemo_Poikkeukset.txt';

procedure LoggaaPoikkeus(Msg:String);
var
F1 : TFileStream;
FMode : Integer;

begin
Msg := Msg ^M^J; // Lisää CrLf, jotta jokainen poikkeusilmoitus tulee omalle rivilleen.

// Haluttaessa myös:
Msg := FormatDateTime(Now, 'yyyy-mm-dd hh:nn:ss.zzz') ' ' Msg;
// jos em. rivi on mukana, loggataan jokaisen poikeuksen yhteydessä tiedostoon myös päivämäärä ja kellonaika, 1 ms resoluutiolla.

if FileExists(LogFileName)
then FMode := fmOpenReadWrite or fmShareDenyWrite
else FMode := fmCreate;

F1 := TFileStream.Create(LogFileName, FMode);
try
//
F1.Position := F1.Size; // Siirry tiedoston loppuun

F1.WriteBuffer(Msg[1], length(Msg));
finally
FreeAndNil(F1);
end;

end;

Tässä mainio esimerkki poikkeusten käytöstä.

Pointtereista: Delphissä niitä tarvitaan loppuen lopuksi aika harvoin. Aloittelija tulee melko pitkälle toimeen ilmankin.

Mutta esim. windowsin API -kutsuissa:

jos windowsissa olisi vaikkapa tällainen

procedure ChangeCurrentDir(ADirName:PChar);

Niin sitä voisi Delphistä kutsua helposti näin;

var
HakemistoNimi : String;

begin

HakemistoNimi := 'C:\WINDOWS';

ChangeCurrentDir(PChar(HakemistoNimi));

end;

tuossa siis PChar(xxx) typecastaa tuon Delphin oman Stringin Win API:n kanssa yhteensopivaksi osoittimeksi ASCIIZ -tyyliseen #0 -loppuiseen merkkijonoon.

Tämä on mahdollista, koska Delphin AnsiStringit on suunniteltu siten, että varsinkin kutsuttaessa systeemikutsuja, jotka eivät muuta mekkijonoa, vaan vain lukevat syötetyn parametrin arvon, niin nuo ovat yhteensopivia, jolloin pelkkä typecastaus riittää.

Mutta kuitenkin:

var

St1 : String;

P : PChar;

i,j : Integer;

begin

St1 := 'abc'#0'def';

P := PChar(St1);

i := length(St1);

j := Strlen(P);

// nyt i, j on seuraavat arvot:

// i = 7
// j = 3

tuo ASCII NUL -merkki siis EI katkaise Delphin omaa Stringiä, ja kuluttaa siinä yhden merkin paikan. Sensijaan Ascii NUL luonnollisesti päättää AsciiZ -merkkijonon, ja osoitin sellaiseenhan tunetaan Delphissä PChar -tyyppinä, C-kielihän käyttä samaan tarkoitukseen:

char *P;

tuo C:n ilmaus on toki hieman epälooginen, mutta vaikka jälkimmäistä ei C -ohjelmissa näe juuri koskaan, omasta mielstäni se on loogisempi, ja menee ainakin linuxin gcc:stä läpi ilman virheitä:

char* P;

Ai miksikö loogisempi?

No eihän tässä ole tarkoitus määritellä, että

muuttuja *P olisi merkki -tyyppiä, vaan että

muuttuja P on osoitin merkki -tyyppiseen tietoon.

Juuri siksi Delphissä on tuo PChar, joka on määritelty näin:

type

PChar = ^Char;

Delphi -ohjelmissa on yleensä syytä käyttää String -tyyppisiä merkkijonoja, mutta esim. Windows APIa suoraan kutusttaessa tai käytettäessä Delphi -ohjelmasta käsin muilla kielillä (Kuten C/C ) tehtyjä DLL:iä tarvitaan usein muita merkkijonotyyppejä, kuten PChar.

PChar on kuitenkin osoitinmuuttuja eli pointteri. Sillä ei ole automaattista muistinhallintaa kuten String -tyypillä on.

Englantia osaaville hyvä kuvaus PChar -tyypistä ja sen yhteensopivuudesta / yhteiskäytöstä String -tyypin kanssa löytyy esim. täältä:

http://rvelthuis.de/articles/articles-pchars.html

En siis lähde näin forumkirjoituksen muodossa suomentamaan tuon yllelinkatun sisältöä.

FreePascalin ja Lazaruksen lähdekoodi on avointa (voit koska tahansa tutkia sitä) ja sen omistaa koodarit itse jolloin sitä voi kuka tahansa käyttää ja parantaa.

VB ja jotkut muut ohjelmat ovat suljettuja ja niiden käyttö tulevaisuudessa on kiinni yhden yrityksen päätöksistä. Tämä yritys voi koska tahansa päättää muuttaa koodia niin että se ei ole yhteensopiva aikaisempien versioiden kanssa (ja näinhän on jo tehtykin)
tai muuta vastaavaa. Koodarit ovat tässä tapauksessa vuokralaisen asemassa.

Ohjelmien käyttöarvo on niiden osaamisessa ja mahdollisuuksissa.

on näin kirjoitti:

FreePascalin ja Lazaruksen lähdekoodi on avointa (voit koska tahansa tutkia sitä) ja sen omistaa koodarit itse jolloin sitä voi kuka tahansa käyttää ja parantaa.

VB ja jotkut muut ohjelmat ovat suljettuja ja niiden käyttö tulevaisuudessa on kiinni yhden yrityksen päätöksistä. Tämä yritys voi koska tahansa päättää muuttaa koodia niin että se ei ole yhteensopiva aikaisempien versioiden kanssa (ja näinhän on jo tehtykin)
tai muuta vastaavaa. Koodarit ovat tässä tapauksessa vuokralaisen asemassa.

Ohjelmien käyttöarvo on niiden osaamisessa ja mahdollisuuksissa.

Lue lisää

Miksi sitten FreePascal ja Lazarus eivät menesty laajemmin? Miksi ne eivät ensimmäisesti syrjäyttäisi maksullista Delphiä? Onko Delphissä jotain niin paljon parempia ominaisuuksia kuin FreePascalissa ja Lazaruksessa, että käyttäjät mieluummin maksavat Delphistä vaikka eivät saa siihen edes lähdekoodia mukaan?

Kun olet ensin vastannut noihin kysymyksiin, niin käsitellään sitten pascaleiden ja Visual Basicin paremmuutta.

xxxxx kirjoitti:

Miksi sitten FreePascal ja Lazarus eivät menesty laajemmin? Miksi ne eivät ensimmäisesti syrjäyttäisi maksullista Delphiä? Onko Delphissä jotain niin paljon parempia ominaisuuksia kuin FreePascalissa ja Lazaruksessa, että käyttäjät mieluummin maksavat Delphistä vaikka eivät saa siihen edes lähdekoodia mukaan?

Kun olet ensin vastannut noihin kysymyksiin, niin käsitellään sitten pascaleiden ja Visual Basicin paremmuutta.

Lue lisää

Miksi linux ei ole syrjäyttänyt windowsia?

Miksi mac ei ole syrjäyttänyt ibm-pc:tä?

Miksi betamax ei syrjäyttänyt vhs:aa?

Miksi dvd ei syrjäyttänyt cd:tä?

Jne jne jne.

Ohjelmointikieli on kuin mikä tahansa muukin kieli. Se kuinka monta asiaa on suunniteltu suomenkielellä on vähäisempi kuin se kuinka monta asiaa on koordinoitu englannin kielellä - mutta se ei tarkoita että suomen kielen avulla kehitetyt jutut on aina huonompia kuin englannin kielellä ohjatut jutut.

Kyse on ohjaajan taidosta selittää asioita, ei siitä mitä kieltä käytetään kunhan kuuntelija ymmärtää mitä puhutaan, KUNHAN kieli on sanastoltaan tarpeeksi ilmaisuvoimainen. Delphi/Pascal takuulla on ilmaisuvoimainen kaikissa suhteissa.

Itse koodaan sekä c/c :aa että pascalia. Duunissani joudun käyttämään c/c koska muutkin puhuvat sitä, mutta itse suosin kuitenkin henkilökohtaisesti Delphi-object pascalia koska minusta se on kielenä kaunis. Siinä missä c/c on jäyhää monien ymmärtämää englantia on Delphi minulle ranskaa ja puhun tätä kaunista kieltä mielelläni muiden kieltä osaavien kanssa.

Merci lé petit.

.......................... kirjoitti:

Miksi linux ei ole syrjäyttänyt windowsia?

Miksi mac ei ole syrjäyttänyt ibm-pc:tä?

Miksi betamax ei syrjäyttänyt vhs:aa?

Miksi dvd ei syrjäyttänyt cd:tä?

Jne jne jne.

Ohjelmointikieli on kuin mikä tahansa muukin kieli. Se kuinka monta asiaa on suunniteltu suomenkielellä on vähäisempi kuin se kuinka monta asiaa on koordinoitu englannin kielellä - mutta se ei tarkoita että suomen kielen avulla kehitetyt jutut on aina huonompia kuin englannin kielellä ohjatut jutut.

Kyse on ohjaajan taidosta selittää asioita, ei siitä mitä kieltä käytetään kunhan kuuntelija ymmärtää mitä puhutaan, KUNHAN kieli on sanastoltaan tarpeeksi ilmaisuvoimainen. Delphi/Pascal takuulla on ilmaisuvoimainen kaikissa suhteissa.

Itse koodaan sekä c/c :aa että pascalia. Duunissani joudun käyttämään c/c koska muutkin puhuvat sitä, mutta itse suosin kuitenkin henkilökohtaisesti Delphi-object pascalia koska minusta se on kielenä kaunis. Siinä missä c/c on jäyhää monien ymmärtämää englantia on Delphi minulle ranskaa ja puhun tätä kaunista kieltä mielelläni muiden kieltä osaavien kanssa.

Merci lé petit.

Lue lisää

Minähän olen tässä kirjoitusketjussa juuri sanonut että kyllä jokaisella yleisessä käytössä olevalla ohjelmointikielellä voi tehdä hyviä ohjelmia. Räpellyksiäkin saa kaikilla aikaan. Tärkeintä on lopputulos ohjelman käyttäjän kannalta ja se että ohjelmakoodi on helposti muokattavissa.

Jos vertaat Delphiä ranskaan, niin eipä se ole kehu Delphiä kohtaan. Ranska saattaa jonkun mielestä kuulostaa kauniilta, mutta se ei ole kovin looginen.

Kukaan ei myöskään opi ohjelmointikieltä ennen ihmisten puhumaan kieltä eikä niin ollen vertaus niiden välillä ole pätevä, joten pysykäämme ohjelmointikielissä.

Ohjelmointikielet ovat loogisesti testattavissa tietokoneissa, eikä niiden oikeasta ääntämisestä tarvitse äänestää kuten on ranskan kanssa.

Vastasit kysymyksillä antamatta yhtään sellaista vastausta jota ei tässä kirjoitusketjussa ole vielä esitetty. Oikeastaan vastasit tavalla jota olen tässä kirjoitusketjussa jo useampaan kertaan moittinut: siirryt yksityiskohtaisista väitteistä laajempaan kokonaisuuteen hämärtäen varsinaista keskustelua.

Delphi (Object Pascal) on ihan yhtä helppo perusominaisuuksiltaan oppia kuin joku rupu Basic (VB) ja siinä ei ole samoja rajoituksia kuin jossain VB:ssä. Se on täysin olio-ominainen kieli, joka osaa pointerit ja periytymisen C :n tapaan. Siis samassa paketissa on KAIKKI! Jos opit Delphin, on sun helppo oppia C , Java, C# jne puhumattakaan paskaa Visual Basicia joka Dlephin ym. muiden "oikeiden" kielien jälkeen näyttää lähinnä säälittävältä räpellykseltä.

Ja eiköhän eri kielien tuntemus ole rikkaus eikä heikkous!!!!!!!!!!!

Itse aloitin koodailun harrastuksen Atari ST:n GFA-Basicilla 1989 joka oli sekoitus Basicia ja Pascalia.

alkup. kirjoitti:

Delphi (Object Pascal) on ihan yhtä helppo perusominaisuuksiltaan oppia kuin joku rupu Basic (VB) ja siinä ei ole samoja rajoituksia kuin jossain VB:ssä. Se on täysin olio-ominainen kieli, joka osaa pointerit ja periytymisen C :n tapaan. Siis samassa paketissa on KAIKKI! Jos opit Delphin, on sun helppo oppia C , Java, C# jne puhumattakaan paskaa Visual Basicia joka Dlephin ym. muiden "oikeiden" kielien jälkeen näyttää lähinnä säälittävältä räpellykseltä.

Ja eiköhän eri kielien tuntemus ole rikkaus eikä heikkous!!!!!!!!!!!

Itse aloitin koodailun harrastuksen Atari ST:n GFA-Basicilla 1989 joka oli sekoitus Basicia ja Pascalia.

Lue lisää

Edellistä viestiä et osoittanut suoraan minulle, mutta koska vastauksessasi mainituista asioista on tässä kirjoitusketjussa paljon keskusteltu, niin minä vastaan.


"Ja eiköhän eri kielien tuntemus ole rikkaus eikä heikkous!!!!!!!!!!!"

Ei kai se heikkous ole, mutta mitä hyötyä siitä on? Meinaan vaan kun yhden hyvän ohjelmakehittimen hallinta riittää eikä ole mielestäni järkevää käyttää suuremmin aikaa muiden ohjelmointikielten oppimiseen. Paitsi jos niitä tarvitsee työssä. Minä olen viimeiset 10 vuotta tehnyt työkseni töitä Visual Basicilla ja sillä pystyy kyllä tekemään yhtä hyviä ohjelmia kuin Delphilläkin. Jos olet eri mieltä niin perustele miksi? Äläkä vastaa vain yleisillä mitäänsanomattomilla heitoilla ilman yksilöityjä perusteluja.


Tutustuin aikoinaan 1990-luvulla Turbo-Pascaliin ja minua silloin nimenomaan ärsytti sen rajoitukset. Esimerkiksi dynaamisten merkkijonojen käsittelyfunktiot eivät vetäneet vertoja Basicin vastaaville. Nyt ne on kyllä Delphiin ja muihin pascaleihin lisätty, joten sikäli sen toiminnat ovat parantuneet ja lähentyneet Visual Basicia.

Kerroppa mitä rajoituksia Visual Basicissa on Delphiin nähden? Laita vaikka joku itse tekemäsi Delphi-koodipätkä, jossa olet käyttänyt olio-ohjelmointia, pointtereita ja periytymistä, niin analysoidaan sitten sitä, että osaatko sinä kirjoittaa hyvää koodia vai oletko vain samanlainen perusteettomia yleisiä väittäitä heittävä kuin tässä kirjoitusketjussa on ollut moni muukin pascaleiden puolustaja.

xxxxx kirjoitti:

Edellistä viestiä et osoittanut suoraan minulle, mutta koska vastauksessasi mainituista asioista on tässä kirjoitusketjussa paljon keskusteltu, niin minä vastaan.


"Ja eiköhän eri kielien tuntemus ole rikkaus eikä heikkous!!!!!!!!!!!"

Ei kai se heikkous ole, mutta mitä hyötyä siitä on? Meinaan vaan kun yhden hyvän ohjelmakehittimen hallinta riittää eikä ole mielestäni järkevää käyttää suuremmin aikaa muiden ohjelmointikielten oppimiseen. Paitsi jos niitä tarvitsee työssä. Minä olen viimeiset 10 vuotta tehnyt työkseni töitä Visual Basicilla ja sillä pystyy kyllä tekemään yhtä hyviä ohjelmia kuin Delphilläkin. Jos olet eri mieltä niin perustele miksi? Äläkä vastaa vain yleisillä mitäänsanomattomilla heitoilla ilman yksilöityjä perusteluja.


Tutustuin aikoinaan 1990-luvulla Turbo-Pascaliin ja minua silloin nimenomaan ärsytti sen rajoitukset. Esimerkiksi dynaamisten merkkijonojen käsittelyfunktiot eivät vetäneet vertoja Basicin vastaaville. Nyt ne on kyllä Delphiin ja muihin pascaleihin lisätty, joten sikäli sen toiminnat ovat parantuneet ja lähentyneet Visual Basicia.

Kerroppa mitä rajoituksia Visual Basicissa on Delphiin nähden? Laita vaikka joku itse tekemäsi Delphi-koodipätkä, jossa olet käyttänyt olio-ohjelmointia, pointtereita ja periytymistä, niin analysoidaan sitten sitä, että osaatko sinä kirjoittaa hyvää koodia vai oletko vain samanlainen perusteettomia yleisiä väittäitä heittävä kuin tässä kirjoitusketjussa on ollut moni muukin pascaleiden puolustaja.

Lue lisää

Nykyään lähes kaikki kielet tukevat myös säännöllisiä lausekkeita. Eikä ne ole alunperin olleet missään basicissä joten turha on sitä pitää kielenä jossa alunperin on ollu hyvä merkkijonon käsittely.

GT1 kirjoitti:

Nykyään lähes kaikki kielet tukevat myös säännöllisiä lausekkeita. Eikä ne ole alunperin olleet missään basicissä joten turha on sitä pitää kielenä jossa alunperin on ollu hyvä merkkijonon käsittely.

Lue lisää

voisitko vähän valaista miten tämä edes liittyy merkkijonojen käsittelyyn?

Jöpöp kirjoitti:

voisitko vähän valaista miten tämä edes liittyy merkkijonojen käsittelyyn?

käsittääkseni nämä liittyvät ainoastaan scripti-kieliin, ei varsinaisiin ohjelmointikieliin.

Jöpöp kirjoitti:

käsittääkseni nämä liittyvät ainoastaan scripti-kieliin, ei varsinaisiin ohjelmointikieliin.

Ilmeisesti hän tarkoittanee sitä että säännöllinen lauseke-luokka on ollut Pascal:ssa (ja esim. C ssa jne) jo viime vuosituhannella. Eli kyseessä ei ole enään mikään uusi juttu!

GT1 kirjoitti:

Nykyään lähes kaikki kielet tukevat myös säännöllisiä lausekkeita. Eikä ne ole alunperin olleet missään basicissä joten turha on sitä pitää kielenä jossa alunperin on ollu hyvä merkkijonon käsittely.

Lue lisää

Jos edellinen vastauksesi liittyy merkkijonojen käsittelyihin, niin kerro mitä säännölliset lauseet tarkoittavat?

Minä sain ensimmäisen tuntuman Basic-kieleen jotain 25 vuotta sitten ja ainakin silloin niissä oli dynaamiset merkkijonot ja hyvät merkkijonokäsittelyfunktiot. Esim. Mid$(), jossa pystyi määrittämään näin: Vuosi$=Mid$(SOTU$,5,2) tai Mid$(SOTU$,5,2)=Vuosi$

Minä olen kyllä ollut siinä luulossa että basiceissa on alunperin ollut dynaamiset merkkijonot ja hyvät merkkijonofunktiot. Ainakin ne oli jo 1970-luvulla. Joten perustele sinä väitteesi.

xxxxx kirjoitti:

Edellistä viestiä et osoittanut suoraan minulle, mutta koska vastauksessasi mainituista asioista on tässä kirjoitusketjussa paljon keskusteltu, niin minä vastaan.


"Ja eiköhän eri kielien tuntemus ole rikkaus eikä heikkous!!!!!!!!!!!"

Ei kai se heikkous ole, mutta mitä hyötyä siitä on? Meinaan vaan kun yhden hyvän ohjelmakehittimen hallinta riittää eikä ole mielestäni järkevää käyttää suuremmin aikaa muiden ohjelmointikielten oppimiseen. Paitsi jos niitä tarvitsee työssä. Minä olen viimeiset 10 vuotta tehnyt työkseni töitä Visual Basicilla ja sillä pystyy kyllä tekemään yhtä hyviä ohjelmia kuin Delphilläkin. Jos olet eri mieltä niin perustele miksi? Äläkä vastaa vain yleisillä mitäänsanomattomilla heitoilla ilman yksilöityjä perusteluja.


Tutustuin aikoinaan 1990-luvulla Turbo-Pascaliin ja minua silloin nimenomaan ärsytti sen rajoitukset. Esimerkiksi dynaamisten merkkijonojen käsittelyfunktiot eivät vetäneet vertoja Basicin vastaaville. Nyt ne on kyllä Delphiin ja muihin pascaleihin lisätty, joten sikäli sen toiminnat ovat parantuneet ja lähentyneet Visual Basicia.

Kerroppa mitä rajoituksia Visual Basicissa on Delphiin nähden? Laita vaikka joku itse tekemäsi Delphi-koodipätkä, jossa olet käyttänyt olio-ohjelmointia, pointtereita ja periytymistä, niin analysoidaan sitten sitä, että osaatko sinä kirjoittaa hyvää koodia vai oletko vain samanlainen perusteettomia yleisiä väittäitä heittävä kuin tässä kirjoitusketjussa on ollut moni muukin pascaleiden puolustaja.

Lue lisää

// kopioidaan engine!
procedure TElement.CopyEngine(Engine: TElementEngine);
var
element: TElement;
I: Integer;
begin
if FEngine nil then
begin
FEngine.Clear();
FEngine.Destroy();
end;

FEngine := TElementEngine.Create( Self );

for I := 0 to Engine.Count - 1 do
begin
element := TElement(Engine.Item[I]).MakeCopy();

// tämä on tärkeä, parent on tämä elementti!!
element.FParent := Self;

// huom kopioitujen elementtien ID on 0, eli $000000
// näille on myöhemmin (MainFormissa) arvottava
// uniikki id!
element.FID.Value := $00000000;

FEngine.Add( element );
end;
end;

..............


Siinä yks piskuruinen pätkä yhdestä projektista mitä teen nykyään työkseni, tässä on tosi vaikea selittää pitäs pistää koko hiton koodi, joka sisältää tuhansia riviä koodia eri tiedostoista!

Turha selittää! Mitä mulla VB6:sta on kokemusta, niin sillä ei sais ikimaailmassa hoidettua asioita niin elegantisti, kuten oikeissa kielissä on tapana.

xxxxx kirjoitti:

Jos edellinen vastauksesi liittyy merkkijonojen käsittelyihin, niin kerro mitä säännölliset lauseet tarkoittavat?

Minä sain ensimmäisen tuntuman Basic-kieleen jotain 25 vuotta sitten ja ainakin silloin niissä oli dynaamiset merkkijonot ja hyvät merkkijonokäsittelyfunktiot. Esim. Mid$(), jossa pystyi määrittämään näin: Vuosi$=Mid$(SOTU$,5,2) tai Mid$(SOTU$,5,2)=Vuosi$

Minä olen kyllä ollut siinä luulossa että basiceissa on alunperin ollut dynaamiset merkkijonot ja hyvät merkkijonofunktiot. Ainakin ne oli jo 1970-luvulla. Joten perustele sinä väitteesi.

Lue lisää

Säännöllinen lauseke on ehkäpä peräisin unixista. Viime vuosituhannen lopulla se löytyi jo monista ojelmointikielistä ja joistakin ohjelmista.

Jos haluat tietää mitä kaikkia ominaisuuksia säännöllisellä lausekkeella on niin on parempi kysyä joltain siihen perehtyneeltä gurulta asiasta. Sillä vaikka säännöllistä lauseketta voidaan hyödyntää Pascalissa niin se ei ole mitenkään Pascal-riippuvainen asia vaan löytyy monista muistakin kielistä (ja aika harva peusohjelmoija hyödyntää sen kaikkia ominaisuuksia).

Yksikertaistettuna voit esim. tietyllä ehtomerkkijonolla verrata toista merkkijonoa sopiiko se kyseiseen tapaukseen. Voi esim. edellyttää että on tiettyjä merkkejä tietyllä paikalla tai tiettyjä merkkejä ei ole tietyllä paikalla jne.

Lisää perusteita:
http://fi.wikipedia.org/wiki/Säännöllinen_lauseke

Voit testata säännöllisen lausekkeen käyttöä:
http://matwww.ee.tut.fi/hmopetus/hm-ohj/2005/demo/saannollinen-lauseke/sl-testipenkki.php

Jos sen käyttö Pascalissa kiinnostayneeltä gurulta asiasta. Sillä vaikka säännöllistä lauseketta voidaan hyödyntää Pascalissa niin se ei ole mitenkään Pascal-riippuvainen asia vaan löytyy monista muistakin kielistä (ja aika harva peusohjelmoija hyödyntää sen kaikkia ominaisuuksia).

Yksikertaistettuna voit esim. tietyllä ehtomerkkijonolla verrata toista merkkijonoa sopiiko se kyseiseen tapaukseen. Voi esim. edellyttää että on tiettyjä merkkejä tietyllä paikalla tai tiettyjä merkkejä ei ole tietyllä paikalla jne.

Lisää perusteita:
http://fi.wikipedia.org/wiki/Säännöllinen_lauseke

Voit testata säännöllisen lausekkeen käyttöä:
http://matwww.ee.tut.fi/hmopetus/hm-ohj/2005/demo/saannollinen-lauseke/sl-testipenkki.php

Jos sen käyttö Pascalissa kiinnostaa:
http://wiki.mureakuha.com/wiki/Säännölliset_lausekkeet_Pascalissa

Lazarus. kirjoitti:

Säännöllinen lauseke on ehkäpä peräisin unixista. Viime vuosituhannen lopulla se löytyi jo monista ojelmointikielistä ja joistakin ohjelmista.

Jos haluat tietää mitä kaikkia ominaisuuksia säännöllisellä lausekkeella on niin on parempi kysyä joltain siihen perehtyneeltä gurulta asiasta. Sillä vaikka säännöllistä lauseketta voidaan hyödyntää Pascalissa niin se ei ole mitenkään Pascal-riippuvainen asia vaan löytyy monista muistakin kielistä (ja aika harva peusohjelmoija hyödyntää sen kaikkia ominaisuuksia).

Yksikertaistettuna voit esim. tietyllä ehtomerkkijonolla verrata toista merkkijonoa sopiiko se kyseiseen tapaukseen. Voi esim. edellyttää että on tiettyjä merkkejä tietyllä paikalla tai tiettyjä merkkejä ei ole tietyllä paikalla jne.

Lisää perusteita:
http://fi.wikipedia.org/wiki/Säännöllinen_lauseke

Voit testata säännöllisen lausekkeen käyttöä:
http://matwww.ee.tut.fi/hmopetus/hm-ohj/2005/demo/saannollinen-lauseke/sl-testipenkki.php

Jos sen käyttö Pascalissa kiinnostayneeltä gurulta asiasta. Sillä vaikka säännöllistä lauseketta voidaan hyödyntää Pascalissa niin se ei ole mitenkään Pascal-riippuvainen asia vaan löytyy monista muistakin kielistä (ja aika harva peusohjelmoija hyödyntää sen kaikkia ominaisuuksia).

Yksikertaistettuna voit esim. tietyllä ehtomerkkijonolla verrata toista merkkijonoa sopiiko se kyseiseen tapaukseen. Voi esim. edellyttää että on tiettyjä merkkejä tietyllä paikalla tai tiettyjä merkkejä ei ole tietyllä paikalla jne.

Lisää perusteita:
http://fi.wikipedia.org/wiki/Säännöllinen_lauseke

Voit testata säännöllisen lausekkeen käyttöä:
http://matwww.ee.tut.fi/hmopetus/hm-ohj/2005/demo/saannollinen-lauseke/sl-testipenkki.php

Jos sen käyttö Pascalissa kiinnostaa:
http://wiki.mureakuha.com/wiki/Säännölliset_lausekkeet_Pascalissa

Lue lisää

Eli säännöllinen lauseke ei liittynyt merkkijonoihin, vaikka niistä oli kyse.

ap. kirjoitti:

// kopioidaan engine!
procedure TElement.CopyEngine(Engine: TElementEngine);
var
element: TElement;
I: Integer;
begin
if FEngine nil then
begin
FEngine.Clear();
FEngine.Destroy();
end;

FEngine := TElementEngine.Create( Self );

for I := 0 to Engine.Count - 1 do
begin
element := TElement(Engine.Item[I]).MakeCopy();

// tämä on tärkeä, parent on tämä elementti!!
element.FParent := Self;

// huom kopioitujen elementtien ID on 0, eli $000000
// näille on myöhemmin (MainFormissa) arvottava
// uniikki id!
element.FID.Value := $00000000;

FEngine.Add( element );
end;
end;

..............


Siinä yks piskuruinen pätkä yhdestä projektista mitä teen nykyään työkseni, tässä on tosi vaikea selittää pitäs pistää koko hiton koodi, joka sisältää tuhansia riviä koodia eri tiedostoista!

Turha selittää! Mitä mulla VB6:sta on kokemusta, niin sillä ei sais ikimaailmassa hoidettua asioita niin elegantisti, kuten oikeissa kielissä on tapana.

Lue lisää

"Turha selittää! Mitä mulla VB6:sta on kokemusta, niin sillä ei sais ikimaailmassa hoidettua asioita niin elegantisti, kuten oikeissa kielissä on tapana."

Miksi sitten yleensä otat osaa tähän keskusteluun jos ajattelet että on turha selittää mitä (luulet) tietäväsi?

Jos tuo esimerkkipätkäsi on hyvä esimerkki siitä miten pascalilla hoidetaan asiat elegantiksi, niin silloin siitä pitäisi muidenkin saada jotain tolkkua. Sen sijaan sanot että "Turha selittää!".

Eikä ole kovin selkeä koodiesimerkki jos siinä täytyy olla tuhansia rivejä.

ap. kirjoitti:

// kopioidaan engine!
procedure TElement.CopyEngine(Engine: TElementEngine);
var
element: TElement;
I: Integer;
begin
if FEngine nil then
begin
FEngine.Clear();
FEngine.Destroy();
end;

FEngine := TElementEngine.Create( Self );

for I := 0 to Engine.Count - 1 do
begin
element := TElement(Engine.Item[I]).MakeCopy();

// tämä on tärkeä, parent on tämä elementti!!
element.FParent := Self;

// huom kopioitujen elementtien ID on 0, eli $000000
// näille on myöhemmin (MainFormissa) arvottava
// uniikki id!
element.FID.Value := $00000000;

FEngine.Add( element );
end;
end;

..............


Siinä yks piskuruinen pätkä yhdestä projektista mitä teen nykyään työkseni, tässä on tosi vaikea selittää pitäs pistää koko hiton koodi, joka sisältää tuhansia riviä koodia eri tiedostoista!

Turha selittää! Mitä mulla VB6:sta on kokemusta, niin sillä ei sais ikimaailmassa hoidettua asioita niin elegantisti, kuten oikeissa kielissä on tapana.

Lue lisää

Juuri duunissa oli valmistunut 15 000 rivin vb-ohjelma ja kiiteltiin kovasti toimivuutta...

xxxxx kirjoitti:

"Turha selittää! Mitä mulla VB6:sta on kokemusta, niin sillä ei sais ikimaailmassa hoidettua asioita niin elegantisti, kuten oikeissa kielissä on tapana."

Miksi sitten yleensä otat osaa tähän keskusteluun jos ajattelet että on turha selittää mitä (luulet) tietäväsi?

Jos tuo esimerkkipätkäsi on hyvä esimerkki siitä miten pascalilla hoidetaan asiat elegantiksi, niin silloin siitä pitäisi muidenkin saada jotain tolkkua. Sen sijaan sanot että "Turha selittää!".

Eikä ole kovin selkeä koodiesimerkki jos siinä täytyy olla tuhansia rivejä.

Lue lisää

On tässä!

for I := 0 to Engine.Count - 1 do
begin
element := TElement(Engine.Item[I]).MakeCopy();
end;

Mutta jos et sitä huomannut, etkä älyä niin en voi sille mitään. Ainaskaan Visual Basic 6:ssa tuo ei olisi ikinä onnistunut ja joka on ikänsä Basicmäisesti ohjelmoinut ei varmaan älyäkkään ko. tapaa ja sen tehokkuutta. Silloin pitää vain vääntää homma perinteisesti, tokihan se niinkin onnistuu, mutta vaarana on juurikin sen kuuluisan spagettikoodin syntyminen.

koodaaja4 kirjoitti:

Juuri duunissa oli valmistunut 15 000 rivin vb-ohjelma ja kiiteltiin kovasti toimivuutta...

Koodirivien määrästä vaan juurikin päinvastoin, että koodirivien MÄÄRÄ pitää saada mahdollisimman VÄHÄISEKSI! Tietty ohjelman laajuus määrää sen koodirivien lopullisen määrän, sille ei voi toki mitään.

Veikkaan että ko. ohjelma mitä mainostat olisi koodirivien määrältään saanut Delphillä 4000-8000 riviin.

ap. kirjoitti:

On tässä!

for I := 0 to Engine.Count - 1 do
begin
element := TElement(Engine.Item[I]).MakeCopy();
end;

Mutta jos et sitä huomannut, etkä älyä niin en voi sille mitään. Ainaskaan Visual Basic 6:ssa tuo ei olisi ikinä onnistunut ja joka on ikänsä Basicmäisesti ohjelmoinut ei varmaan älyäkkään ko. tapaa ja sen tehokkuutta. Silloin pitää vain vääntää homma perinteisesti, tokihan se niinkin onnistuu, mutta vaarana on juurikin sen kuuluisan spagettikoodin syntyminen.

Lue lisää

No kerro mitä tuo sitten tekee? Kopioi jonkin kontrollin vai? Ja missä käytännön tarkoituksessa sitä tarvitset?

ap. kirjoitti:

Koodirivien määrästä vaan juurikin päinvastoin, että koodirivien MÄÄRÄ pitää saada mahdollisimman VÄHÄISEKSI! Tietty ohjelman laajuus määrää sen koodirivien lopullisen määrän, sille ei voi toki mitään.

Veikkaan että ko. ohjelma mitä mainostat olisi koodirivien määrältään saanut Delphillä 4000-8000 riviin.

Lue lisää

Minustakin on hyvä että koodista tehdään selkeätä vähäisellä koodirivimäärällä, mutta se ei ole (enää) niin oleellista sillä muistia nykyään riittää.

Kyllä kaikki ohjelmoijat laittavat usein käytettyjä ohjelmakohtia aliohjelmiksi, jolloin koodirivimäärä vähenee.

Oikeastaan koodirivi ei myöskään ole enää windows-ohjelmoinnissa sellainen käsite kuin oli aikaisemmin kun kaikki koodattiin käsin. Esim. onko kontrollien propertiesit koodirivejä kun ne ohjelman kooditulosteessa näkyvät riveinä?

Mihin muuten perustuu veikkauksesi (!) siitä, että Delphillä tekisi 15000 VB-ohjelmointirivin ohjelman 4000-8000 rivillä? Etenkin kun koodirivi käsitteenä basicissa poikkeaa pascalista sillä basicissa on useinkin samalle riville saatu useita käskyjä.

Esimerkki jossa VB tekee siistimpää ja lyhyempää koodia kuin Delphi:

If a=b then c=d:e=f

Pascalilla tuohon tarvitaan monta riviä tai sitten koodista tulee vaikeaselkoista.

ap. kirjoitti:

Koodirivien määrästä vaan juurikin päinvastoin, että koodirivien MÄÄRÄ pitää saada mahdollisimman VÄHÄISEKSI! Tietty ohjelman laajuus määrää sen koodirivien lopullisen määrän, sille ei voi toki mitään.

Veikkaan että ko. ohjelma mitä mainostat olisi koodirivien määrältään saanut Delphillä 4000-8000 riviin.

Lue lisää

Ei hemmeti mikä urpo toi AP...

Tärkeätä ei todellakaan ole saadaa koodirivien määrää pieneksi vaan useimmiten juuri päin vastoin.

Tärkeää on tehdä ohjelmasta sellainen, että sen kehtittäminen on myöhemmin helppoa (koodi helposti ymmärrettävää) ja virheet saadaan karsittua helposti pois.

xxxxx kirjoitti:

Eli säännöllinen lauseke ei liittynyt merkkijonoihin, vaikka niistä oli kyse.

Ainakin mun mielestä ne kuuluu merkkijonon käsittelyyn.

Esim. SplitRegExpr aliohjelmalla saa selville
merkkijonosta 'Basic basic BaSic CaRic'
kun laittaa säännölliseksi lausekkeeksi esim.'[AaBbCc]a[Rs]ic'
ettei 'BaSic' täytä ehtoa.

Hippo kirjoitti:

Ei hemmeti mikä urpo toi AP...

Tärkeätä ei todellakaan ole saadaa koodirivien määrää pieneksi vaan useimmiten juuri päin vastoin.

Tärkeää on tehdä ohjelmasta sellainen, että sen kehtittäminen on myöhemmin helppoa (koodi helposti ymmärrettävää) ja virheet saadaan karsittua helposti pois.

Lue lisää

Niin selvyys on tärkeintä eli yksi käsky koodiriville.

Mutta hyvällä suunnittelulla ja monipuolisella kielellä pystyy saman ongelman ratkaisemaan hyvin monella tavalla. Aika usein se ratkaisu jossa on vähemmän koodirivejä on paremmin tehty.

a&a kirjoitti:

Ainakin mun mielestä ne kuuluu merkkijonon käsittelyyn.

Esim. SplitRegExpr aliohjelmalla saa selville
merkkijonosta 'Basic basic BaSic CaRic'
kun laittaa säännölliseksi lausekkeeksi esim.'[AaBbCc]a[Rs]ic'
ettei 'BaSic' täytä ehtoa.

Lue lisää

Kyllähän nuo kuuluvat merkkijonokäsittelyyn, sillä kaikki käskyt joilla merkkijonoja käsitellään ovat merkkijonojen käsittelyyn liittyviä. Sain vain ensin edellisistä kirjoituksista eri käsityksen siitä mitä tarkoitetaan säännöllisellä lausekkeella. Lazarushan sanoi ettei se olisi merkkijonokäsittelyä.

Tuossa ylempänä olleessa Wikipedian linkissä http://fi.wikipedia.org/wiki/Säännöllinen_lauseke sanotaan näin:

"Säännöllinen lauseke on tietojenkäsittelyteoriassa lauseke, joka määrittelee säännöllisen kielen. Kieli tarkoittaa tässä yhteydessä joukkoa merkkijonoja."

Eli ei pidä sekoittaa merkkijonoa ja ohjelmointikielessä olevaa merkkijonokäsittelyä.

a&a kirjoitti:

Niin selvyys on tärkeintä eli yksi käsky koodiriville.

Mutta hyvällä suunnittelulla ja monipuolisella kielellä pystyy saman ongelman ratkaisemaan hyvin monella tavalla. Aika usein se ratkaisu jossa on vähemmän koodirivejä on paremmin tehty.

Lue lisää

Eiköhän kaikki ohjelmia tehneet ja etenkin jonkun toisen koodia päivittäneet ole yhtämieltä siitä, että ohjelmakoodin muodossa selkeys on tärkeintä.

Kyllä ohjelmakoodi on monesti kuitenkin mielestäni siistimpää kun yhdelle riville laitetaan samaan asiaan liittyviä useampia käskyjä. Basicissa se onnistuu siististi mutta pascaleissa tulos on tosi sekavaa.

Etenkin jos on useita sisäkkäisiä ehtolauseita niin sama ohjelmakokonaisuus saadaan kerralla ruudulle paremmin nähtäville. Itse pidän siitä sillä se mahdollistaa paremmin ohjelman hahmottamisen. Tosin aikaisemmin merkkipohjaisissa 24-rivisissä näytöissä (80 merkkiä rivillä) tuo oli vielä tärkeämpää.

Ja jos jonkin ohjelmaosan tulostaa paperille niin silloinkin tiivis koodi on ainakin minun mielestä kätevämpää kun se on yhdellä sivulla. Tietysti niin ettei koodin selkeys kärsi.


"Aika usein se ratkaisu jossa on vähemmän koodirivejä on paremmin tehty."

Joo kyllä kai tuosta vallitsee yhtämielisyys. Siis kun puhutaan samat toiminnot tekevästä ratkaisusta.

xxxxx kirjoitti:

Kyllähän nuo kuuluvat merkkijonokäsittelyyn, sillä kaikki käskyt joilla merkkijonoja käsitellään ovat merkkijonojen käsittelyyn liittyviä. Sain vain ensin edellisistä kirjoituksista eri käsityksen siitä mitä tarkoitetaan säännöllisellä lausekkeella. Lazarushan sanoi ettei se olisi merkkijonokäsittelyä.

Tuossa ylempänä olleessa Wikipedian linkissä http://fi.wikipedia.org/wiki/Säännöllinen_lauseke sanotaan näin:

"Säännöllinen lauseke on tietojenkäsittelyteoriassa lauseke, joka määrittelee säännöllisen kielen. Kieli tarkoittaa tässä yhteydessä joukkoa merkkijonoja."

Eli ei pidä sekoittaa merkkijonoa ja ohjelmointikielessä olevaa merkkijonokäsittelyä.

Lue lisää

Viittaamasi linkki oli vain siksi että en ole kovinkaan paljoa säännöllisiä lausekkeita käyttänyt. Uskoisin että moni muu tietää niiden mahdollisuuksista paljon enemmän (ja osannee kertoa niiden hienoudet).

Lazarus. kirjoitti:

Viittaamasi linkki oli vain siksi että en ole kovinkaan paljoa säännöllisiä lausekkeita käyttänyt. Uskoisin että moni muu tietää niiden mahdollisuuksista paljon enemmän (ja osannee kertoa niiden hienoudet).

Lue lisää

En minäkään ole juurikaan käyttänyt säännöllisiä lausekkeita. Ja vasta äsken opin niiden nimityksen.

Jossakin tietokantahauissa olen käyttänyt jotain "*abc*"-tyyppisiä.

Tuo nimitys "säännöllinen lauseke" kyllä kuulostaa minusta omituiselta nimitykseltä tuolle toiminnolle.

xxxxx kirjoitti:

No kerro mitä tuo sitten tekee? Kopioi jonkin kontrollin vai? Ja missä käytännön tarkoituksessa sitä tarvitset?

Niin tuo kopion luominen oliosta on ihan peruskuraa, mutta toki homma onnistuu muillakin olio-pohjaisilla kielilllä, kuten Delphillä.

Eli ei tuossa mitään ns. kontrollia kopioida (noh miten sen katsoo) vaan tehdään listasta löytyvistä olioista kopio.

Mitä se tekee? Oliolle voit määritellä puhtaasti mitä se tekee. Jos yritän selittää maalaisjärjellä, niin yleensä 3D-peleissä hahmot ovat sanan varsinaisessa merkityksessä niitä "olioita", yleensä näet näissä peleissä samoja örkkejä siellä täällä. Ne ovat niitä olioita, jokainen käyttäytyy samanlailla ja niitä olioita voit kopioida periaatteessa mielin määrin sinne kentälle ja jokainen käyttäytyy niin miten se on ohjelmoitu.

Tutustu olio-ohjelmointiin ja sen periaatteisiin, niin tajuat mistä on kyse. Aloita vaikka Javasta.

ap. kirjoitti:

Niin tuo kopion luominen oliosta on ihan peruskuraa, mutta toki homma onnistuu muillakin olio-pohjaisilla kielilllä, kuten Delphillä.

Eli ei tuossa mitään ns. kontrollia kopioida (noh miten sen katsoo) vaan tehdään listasta löytyvistä olioista kopio.

Mitä se tekee? Oliolle voit määritellä puhtaasti mitä se tekee. Jos yritän selittää maalaisjärjellä, niin yleensä 3D-peleissä hahmot ovat sanan varsinaisessa merkityksessä niitä "olioita", yleensä näet näissä peleissä samoja örkkejä siellä täällä. Ne ovat niitä olioita, jokainen käyttäytyy samanlailla ja niitä olioita voit kopioida periaatteessa mielin määrin sinne kentälle ja jokainen käyttäytyy niin miten se on ohjelmoitu.

Tutustu olio-ohjelmointiin ja sen periaatteisiin, niin tajuat mistä on kyse. Aloita vaikka Javasta.

Lue lisää

Matrix leffassa Revolutions. Siinä se paha agentti Smith kopioi itseään mielin määrin siihen Matrix maailmaan ja kaikki toimivan prikulleen samoin. It's good to be me, me me me!! :D

xxxxx kirjoitti:

Minustakin on hyvä että koodista tehdään selkeätä vähäisellä koodirivimäärällä, mutta se ei ole (enää) niin oleellista sillä muistia nykyään riittää.

Kyllä kaikki ohjelmoijat laittavat usein käytettyjä ohjelmakohtia aliohjelmiksi, jolloin koodirivimäärä vähenee.

Oikeastaan koodirivi ei myöskään ole enää windows-ohjelmoinnissa sellainen käsite kuin oli aikaisemmin kun kaikki koodattiin käsin. Esim. onko kontrollien propertiesit koodirivejä kun ne ohjelman kooditulosteessa näkyvät riveinä?

Mihin muuten perustuu veikkauksesi (!) siitä, että Delphillä tekisi 15000 VB-ohjelmointirivin ohjelman 4000-8000 rivillä? Etenkin kun koodirivi käsitteenä basicissa poikkeaa pascalista sillä basicissa on useinkin samalle riville saatu useita käskyjä.

Esimerkki jossa VB tekee siistimpää ja lyhyempää koodia kuin Delphi:

If a=b then c=d:e=f

Pascalilla tuohon tarvitaan monta riviä tai sitten koodista tulee vaikeaselkoista.

Lue lisää

Tuo on JUURI huono tapa koodata! Koodista tulee tosi epäkelpoa lukea.

Dlephissä vastaava!

if a = b then
begin
c:=d;
e:=f;
end;

Lisäät vain begin ja end, jolla määrität lohkon, onko vaikeeta? Näin tehdään muissakin oikeissa kielissä, kuten c/c {} suluilla.

Delphillä voi kapseloida suurempia kokonaisuukia osioihin (olioihin) ja luoda näistä osioista periytyviä osioita ja näitä osioita voi kopioida muistiin ilman että tarvii kirjoitta jokaista pikkasen eriytyvää ominaisuutta aina uudelleen ja uudelleen. Kopioi, kopioi hyvä mies, elä kirjoita aina uusiksi. Lisäksi voi käyttää pointereita, tehokasta.

Hippo kirjoitti:

Ei hemmeti mikä urpo toi AP...

Tärkeätä ei todellakaan ole saadaa koodirivien määrää pieneksi vaan useimmiten juuri päin vastoin.

Tärkeää on tehdä ohjelmasta sellainen, että sen kehtittäminen on myöhemmin helppoa (koodi helposti ymmärrettävää) ja virheet saadaan karsittua helposti pois.

Lue lisää

Kiitos hyvistä nauruista :D hahahah!

Ai että 100'000 koodiriviä on parempi ratkaisu kuin 10'000 riviä samoilla ominaisuuksilla, niinkö? Phauah! :D Voi jeesus!

Tiesitkö muuten sitä että olio-ohjelmoinnin yksi perusideoista on juuri koodin hallittavuus ja ylläpitäminen. Kaikkea ei aina tarvi kirjoittaa uusiksi. Pyörää ei tarvi aina keksiä uusiksi, kun luodaan valmiiksi rajapinnat ja niiden määritykset, voit käyttää valmiiksi havaittuja ratkaisuja.

Jos mielit minua urpoksi, tutustu toki meikeläiseen: http://www.knubits.com/index.php?page=2

ap. kirjoitti:

Tuo on JUURI huono tapa koodata! Koodista tulee tosi epäkelpoa lukea.

Dlephissä vastaava!

if a = b then
begin
c:=d;
e:=f;
end;

Lisäät vain begin ja end, jolla määrität lohkon, onko vaikeeta? Näin tehdään muissakin oikeissa kielissä, kuten c/c {} suluilla.

Delphillä voi kapseloida suurempia kokonaisuukia osioihin (olioihin) ja luoda näistä osioista periytyviä osioita ja näitä osioita voi kopioida muistiin ilman että tarvii kirjoitta jokaista pikkasen eriytyvää ominaisuutta aina uudelleen ja uudelleen. Kopioi, kopioi hyvä mies, elä kirjoita aina uusiksi. Lisäksi voi käyttää pointereita, tehokasta.

Lue lisää

Kun on sisäkkäisiä ehtoja eikä homma mahdu ruudulle niin se ei ole selkeää.

En tiedä mitä tarkoitat kapseloinnilla. Ja olioistakin on tässä keskustelussa jo väitelty. Mutta suurempia kokonaisuuksia voi kaikissa kielissä jakaa osiin. Niitä on vain aikaisemmin nimitetty funktioiksi ja aliohjelmiksi.

Pointtereistakin on tässä kirjoitusketjussa jo väitelty. Jos sinulla on siihen jotain lisättävää, eli väität pointtereiden käyttöä tehokkaaksi, niin kerro toki käytännön esimerkki jossa olet niitä itse tehokkaasti käyttänyt. Mutta lue ensin tämän keskustelun aikaisemmat viestit ettei taas tarvitse alkaa jankata samoja asioita uudestaan.

Kyllä minä osaan melko hyvin tehdä ohjelmakoodia jota voi muokata ja käyttää uudelleen. Mutta en kopioi sillä jos jotain ohjelmakoodia tarvitsi uudelleen niin teen siitä aliohjelman.

Olen koodannut 20 vuotta, joten kyllä minä olen siinä ajassa oppinut millä tavalla pystyn ohjelmakoodia selkeästi lukemaan.

Pascalissa muutenkin on typerää kun basicin "c=d" täytyy siinä koodata "c:=d;"-tavalla, sillä kaikki ylimääräiset merkit haittaavat nopeaa lukemista. Samoin on niiden Begin-End -sanojen kanssa.

ap. kirjoitti:

Matrix leffassa Revolutions. Siinä se paha agentti Smith kopioi itseään mielin määrin siihen Matrix maailmaan ja kaikki toimivan prikulleen samoin. It's good to be me, me me me!! :D

Lue lisää

Olen tutustunut Javaan, mutta en pidä sen liian tiukasta kieliopista. Samasta syystä 15 vuotta sitten en pitänyt pascalista.

Käytetään sitten nimeä kontrolli (Control) tai olio, niin ei se homma siitä muutu. Tätä käsittelillä leikkimistä on tullut atk-alalla kuultua jo pari kymmentä vuotta ja se ärsytti jos silloin. Ihmiset jotka eivät ole koodanneet ollenkaan tai vain pari vuotta, ovat niin innoissaan uusista käsitteistä mutta eivät osaa kuitenkaan perustella mitä perustavanlaatuista muutosta niillä on aikaisempiin.

ap. kirjoitti:

Kiitos hyvistä nauruista :D hahahah!

Ai että 100'000 koodiriviä on parempi ratkaisu kuin 10'000 riviä samoilla ominaisuuksilla, niinkö? Phauah! :D Voi jeesus!

Tiesitkö muuten sitä että olio-ohjelmoinnin yksi perusideoista on juuri koodin hallittavuus ja ylläpitäminen. Kaikkea ei aina tarvi kirjoittaa uusiksi. Pyörää ei tarvi aina keksiä uusiksi, kun luodaan valmiiksi rajapinnat ja niiden määritykset, voit käyttää valmiiksi havaittuja ratkaisuja.

Jos mielit minua urpoksi, tutustu toki meikeläiseen: http://www.knubits.com/index.php?page=2

Lue lisää

"Ai että 100'000 koodiriviä on parempi ratkaisu kuin 10'000 riviä samoilla ominaisuuksilla, niinkö? Phauah! :D Voi jeesus!"

Huomioit varmaan että minä olin sanonut että "samoilla ominaisuuksilla".

Sinä sanoit näin: "Koodirivien määrästä vaan juurikin päinvastoin, että koodirivien MÄÄRÄ pitää saada mahdollisimman VÄHÄISEKSI!"

Ja tuossa olet väärässä. Nykyään kun koneissa muistia piisaa niin muistinkulutuksen voi tavallisesti unohtaa (paitsi jos käsittelee erityisen suuria tietomääriä kuten kuvia muistissa), sillä normaalissa ohjelmoinnissa muistia on tavattomasti. Eri asia oli joskus muinaishistoriassa 10 vuotta sitten, mutta siihen ajatusmaailmaan ovat vain urpot jääneet.



"Tiesitkö muuten sitä että olio-ohjelmoinnin yksi perusideoista on juuri koodin hallittavuus ja ylläpitäminen. Kaikkea ei aina tarvi kirjoittaa uusiksi. Pyörää ei tarvi aina keksiä uusiksi, kun luodaan valmiiksi rajapinnat ja niiden määritykset, voit käyttää valmiiksi
havaittuja ratkaisuja."

Minä ainakin tiesin tuon. Samaa tapaa käytettiin myös ennen olio-käsitteen keksimistä 20 vuotta sitten kaikessa hyvässä koodauksessa, joten ei se oliohin liity.



"Jos mielit minua urpoksi, tutustu toki meikeläiseen:"

Tutustuin nettisivuihisi ja niiden perusteella voin muutaman päätelmän tietokonetaidoistasi tehdä: Tyypillinen harrastelija joka väsää vähän kaikkea ja tutustuu uusiin asioihin mutta luulee itsestään liikoja, sillä omaa vain hatarat perustiedot. Opiskeli vuoden Javaa saaden hyvän todistuksen, mutta taitoihin verrattuna todistus kertoo Länsi-Lapin Ammatti-instituutin heppoisesta vaatimustasosta. Kahden kuukauden työharjoittelussa vuonna 2004 teki suppean ja erittäin yksinkertaisen laskutusohjelman ja piti kahden kuukauden aikarajaa tiukkana vaikka omien sanojen mukaan omaa yli 15 vuoden ohjelmointikokemuksen. Lisäksi harjoittelutyössä loppukäyttäjien ohjeissa oli monta dos-kehotteesta ja mysql-kehotteesta tehtävää toimintaa joita ei nykyajan (2004) windows-ohjelmoinnissa tulisi käyttää. Loppuarvio: Henkilö on urpo eikä hänelle tulisi maksaa kuin korkeintaan euron tuntipalkkaa eikä häntä saa päästää koskemaan tärkeisiin ohjelmaprojekteihin eikä kirjoittamaan käyttöohjeita.

xxxxx kirjoitti:

"Ai että 100'000 koodiriviä on parempi ratkaisu kuin 10'000 riviä samoilla ominaisuuksilla, niinkö? Phauah! :D Voi jeesus!"

Huomioit varmaan että minä olin sanonut että "samoilla ominaisuuksilla".

Sinä sanoit näin: "Koodirivien määrästä vaan juurikin päinvastoin, että koodirivien MÄÄRÄ pitää saada mahdollisimman VÄHÄISEKSI!"

Ja tuossa olet väärässä. Nykyään kun koneissa muistia piisaa niin muistinkulutuksen voi tavallisesti unohtaa (paitsi jos käsittelee erityisen suuria tietomääriä kuten kuvia muistissa), sillä normaalissa ohjelmoinnissa muistia on tavattomasti. Eri asia oli joskus muinaishistoriassa 10 vuotta sitten, mutta siihen ajatusmaailmaan ovat vain urpot jääneet.



"Tiesitkö muuten sitä että olio-ohjelmoinnin yksi perusideoista on juuri koodin hallittavuus ja ylläpitäminen. Kaikkea ei aina tarvi kirjoittaa uusiksi. Pyörää ei tarvi aina keksiä uusiksi, kun luodaan valmiiksi rajapinnat ja niiden määritykset, voit käyttää valmiiksi
havaittuja ratkaisuja."

Minä ainakin tiesin tuon. Samaa tapaa käytettiin myös ennen olio-käsitteen keksimistä 20 vuotta sitten kaikessa hyvässä koodauksessa, joten ei se oliohin liity.



"Jos mielit minua urpoksi, tutustu toki meikeläiseen:"

Tutustuin nettisivuihisi ja niiden perusteella voin muutaman päätelmän tietokonetaidoistasi tehdä: Tyypillinen harrastelija joka väsää vähän kaikkea ja tutustuu uusiin asioihin mutta luulee itsestään liikoja, sillä omaa vain hatarat perustiedot. Opiskeli vuoden Javaa saaden hyvän todistuksen, mutta taitoihin verrattuna todistus kertoo Länsi-Lapin Ammatti-instituutin heppoisesta vaatimustasosta. Kahden kuukauden työharjoittelussa vuonna 2004 teki suppean ja erittäin yksinkertaisen laskutusohjelman ja piti kahden kuukauden aikarajaa tiukkana vaikka omien sanojen mukaan omaa yli 15 vuoden ohjelmointikokemuksen. Lisäksi harjoittelutyössä loppukäyttäjien ohjeissa oli monta dos-kehotteesta ja mysql-kehotteesta tehtävää toimintaa joita ei nykyajan (2004) windows-ohjelmoinnissa tulisi käyttää. Loppuarvio: Henkilö on urpo eikä hänelle tulisi maksaa kuin korkeintaan euron tuntipalkkaa eikä häntä saa päästää koskemaan tärkeisiin ohjelmaprojekteihin eikä kirjoittamaan käyttöohjeita.

Lue lisää

Siirryin VB:stä (versiosta 5) Delphiin kun NT:n "start up" -ryhmässä ollut VB -applikaatio kaatui aina PC:tä buutatessa (ja tämä toistui usein - valitettavasti). Toinen ongelma oli Win32 API jota VB ei tukenut kunnolla, vaan (muistaakseni) merkkijonojen ja nimenomaan pointtereiden kanssa oli epäyhteensopivuus -ongelmia. Lisäksi dll:n koodaus ei onnistunut VB:llä (tarvitsi tehdä kerran yksi dll että sai NT:n servicelle command line parametrit (mitä ne on suomeksi!?). Mitähän muuta..Delphillä pystyin toteuttamaan MB/TCP:n varsin kivuttomasti, mutta VB:llä se oli mahdottomuus. Voi olla että joku OCX tänä päivänä löytyisi - tosin voisihan kirjoittaa (Delphillä?) taas kirjaston jota ajaa VB:stä.
Minusta VB oli (ja on) helppo ja hyvä ympäristö. Mutta henkilökohtaisesti en ole kaivannut sitä vaan koen että Delphillä saan enemmän resursseja käyttööni ja ohjelmien jakelu hoituu "yhtenä pakettina".

Collier kirjoitti:

Siirryin VB:stä (versiosta 5) Delphiin kun NT:n "start up" -ryhmässä ollut VB -applikaatio kaatui aina PC:tä buutatessa (ja tämä toistui usein - valitettavasti). Toinen ongelma oli Win32 API jota VB ei tukenut kunnolla, vaan (muistaakseni) merkkijonojen ja nimenomaan pointtereiden kanssa oli epäyhteensopivuus -ongelmia. Lisäksi dll:n koodaus ei onnistunut VB:llä (tarvitsi tehdä kerran yksi dll että sai NT:n servicelle command line parametrit (mitä ne on suomeksi!?). Mitähän muuta..Delphillä pystyin toteuttamaan MB/TCP:n varsin kivuttomasti, mutta VB:llä se oli mahdottomuus. Voi olla että joku OCX tänä päivänä löytyisi - tosin voisihan kirjoittaa (Delphillä?) taas kirjaston jota ajaa VB:stä.
Minusta VB oli (ja on) helppo ja hyvä ympäristö. Mutta henkilökohtaisesti en ole kaivannut sitä vaan koen että Delphillä saan enemmän resursseja käyttööni ja ohjelmien jakelu hoituu "yhtenä pakettina".

Lue lisää

Oiskohan tämänkin ikuisuuden vanhan ketjun voinu jättää hautaansa uinumaan ja aloittaa uuden aiheen, ei tätä palstaa ainakaan tällä tavoin elvytetä!

Puhutko nyt Windows NT:n alle 5.0 versiosta, vai mistä? Mitä laajemmin kysymyksen tai tässä tapauksessa aiheen siirtyä toiseen kieleen niin hyvä kertoa hiukan tarkemmin asiasta..

"@VB my arse: NT:n "start up" -ryhmässä ollut VB -applikaatio kaatui aina PC:tä buutatessa (ja tämä toistui usein - valitettavasti)."
Saattaa olla myöskin että yritit käyttää esim. Ajureita joita vielä ei oltu ladattu, oliko ohjelmasi riippuvainen muista ohjelmista, kenties ne eivät olleet vielä käynnistyneet...Ehkä on syytä jatkaa uuden aiheen kanssa tästä, eli ei muuta kuin kysymyksiä/aiheita pintaan vaan niin saadaan tänne eloa..