Borland tajusi, lopultakin...
http://www.turboexplorer.com/turbosavailable
Delphi on erinomainen ohjelmistotyöväline. Helppo kuin VB, pystyvä ja tehokas kuin C , molemmat samassa välineessä.
Jokainen voi itse tehdä seuraavan yksinkertaisen testin:
1. Mene kirjastoon
2. Etsi käsikirjastosta sekä Delphiä että C :aa alkeista lähtien käsittelevä kirja, lue molemmista 1. luku
3. Eiköhän tuo jo selvitä, että Delphin syntaksi on olennaisen helppoa ja selkeää C :aan verrattuna.
Silti, voin vakuuttaa, että Delphillä voi tehdä ammattilaistasoisia ohjelmia siinä kuin C :llakin, itseasiassa paremminkin!
"Ai kuinka niin paremmin ?"
Tietoturvan osalta. Siinä, missä uutiset puskurin ylivuotohaavoittuvuuksia hyödyntävistä rikollisista hyökkäyksistä ovat jokapäiväisiä C:llä ja C :lla koodattuja ohjelmia kohtaan, Delphi -ohjelmoijan on helppo koodat ohjelmansa niin, että niitä kohtaan moiset jäävät pelkiksi yrityksiksi.
Toki, vaikka pienellä opettelulla kuka tahansa voi koodata Delphillä, niin ammattilaiseksi tulo edellyttää, että ohjelmoijan tulee ymmärtää, mitä ovat:
Pino (Stack)
Keko (Heap)
Staattiset eli pysyvät muuttujat (UNITtien ja pääohjelman tiedoston ylimmällä tasolla suortaan, ei siis minkään aliohjelman sisällä määritellyt muuttujat)
ja mihin mikäkin tieto tallentuu.
Aliohjelmaa kutsuttaessa prosessorin täytyy tietää, mihin palataan, kun aliohjelma päättyy. Tämä perustuu EIP -rekisterin tallennukseen pinoon.
Nuo hyökkäykset perustuvat siihen, kun taitamaton ohjelmoija varaa puskureina käytettyjä muuttujia pinosta, ja sitten vielä mokaa siinä, että sallii ohjelman kirjoittaa tuollaiseen puskurimuuttujaan enemmän tietoa kuin siihen mahtuu - seurauksena juurikin pinossa tallessa olevan EIP:n ylikirjoitus krakkerin määrittelemällä arvolla, seurauksena se, että aliohjelma päättyessään "palaa" paikkaan, josta sitä ei todellisuudessa kutsuttu, eli pinossa olevan puskurimuuttujan sisältämään krakkerin sinne tunkemaan konekielikoodiin - alkaako selvitä miksi tuollainen hyökkäys on niin vaarallinen - siinähän prosessori alkaakin suorittaa krakkerin ujuttamaa koodia EXE -tiedostossa olevan koodin sijaan!
Ikävä kyllä Delphin markkinaosuus on pysynyt pienenä. Ilmeisesti Borland on nyt tajunnut, että vaikka lyhyellä tähtäimellä saakin kovempia tuottoja myymällä kalliilla, niin tuo strategia voi näivettää Delphin kokonaisuutena, ei siksi, että siinä teknisesti olisi mitään vikaa, vaan siksi, ettei sitä yrityksissä käytetä tarpeeksi!
Nyt julkistetut halpaversiot toivottavasti lisäävät Delphin markkinaosuutta ja antavat epäilijöille pienin kustannuksin tai ilmaiseksi tutustua Delphi -koodaukseen.
Jos yritysjohtajat tajuavat, mitä kaikkia hyötyjä ja kilpailuetuja Delphin käyttö voi yritykselle merkitä, ehkäpä markkinoiden suunta muuttuu NYT!
Miettikääpä: Yritys A koodaan C/C :lla, ja tuotteista on löytynyt tietoturva-aukkoa toisen perään. Vaikka koodaajat tekevät jatkuvasti työtä aukkojen paikkamiseksi, uusia löytyy silti. Mitä, kun yrityksen A tuotteita käyttävän asiakkaan tietojärjestelmään murtaudutaan ja luottamuksellisia tietoja varastetaan. Syylliset jäävät harvoin kiinni...
Nyt yritys B tuo markkinoille kilpailevan, Delphillä koodatun tuotteen. Jos ohjelmoijilla on edes em. perusasiat oikein hallussa, on todennäköistä, ettei tuotteista esim. 5 vuoden aikana löydy yhtään vakavaa tietoturvareikää.
Jos yrityksen B koodari olisikin huolimattomuudessan tehnyt ohjelmointivirheen, pahimmillaan se aiheuttaisi ohjelman virheellisen toiminnan, mutta silti estäisi hyökkääjää ajamasta omaa konekielikoodiaan asiakkaan yrityksen B tuotetta käyttävässä tietojärjestelmässä.
Asiakas toki valittaisi väärin toimivasta tuotteesta, mutta yrityksen B työntekijä tutkittuaan virheen ja selvitettyään sen syyn, voisi korjata virheen ja toimittaa asiakkaalle korjatun version. Toki bugit aina aiheuttavat harmeja, kun ne vääristävät esim. tietokannassa olevia tietoja.
Mutta oikein peraattein koodatussa Delphi -ohjelmassa edes ohjelmointivirhe ei aiheuta vakavaa tietoturva-aukkoa, vaan ainoastaan väärin toimivan ohjelman.
Ehkä vaikutukset selviävät yrityksen B johdollekin, kun moni yrityksen A entinen asiakas ostaa yrityksen B laadukkaamman tuotteen...
Borland tajusi, lopultakin...
31
2011
Vastaukset
- Pus kuri
"Jos ohjelmoijilla on edes em. perusasiat oikein hallussa, on todennäköistä, ettei tuotteista esim. 5 vuoden aikana löydy yhtään vakavaa tietoturvareikää."
Heh. Niin, eihän sitä mitään muita vakavia turvaongelmia olekaan kuin tuo ylivuoto. Turvallisin mielin vaan koodaamaan!
Onhan se tietenkin niin, että jos asiakkaat voi laskea yhden otsan varpailla, ei varmasti kukaan heistä joudu tietomurron uhriksi. Mutta muuten tällainen saarna ei ihan oikein vakuuta.
Katsos kun siinä C :ssakin on ihan turvallinen string-luokka ja vektoreissakin voi käyttää range-checkingiä... - C#:iin?
No, missäpä olisi lyhyt kuvaus tuon uuden Delphin ominaisuuksista? Miten se vertautuu C#:iin? Taitaapa tuon sivun mukaan Borlandkin tarjota C#-ympäristöä.
Ihan vain hakisin yleistä kuvausta. Onko moninperintää tai interfaceja? Onko roskienkeruuta? Jne.
Tuolla sivulla ei ollut mitään datasheettejä vielä, vaikka linkki oli valmiina. Kaipa he päivittää, ku jaksaa...- a&a
Ei ole moninperiintää (eikä siitä aiheutuvia ongelmia). Tuo hommahan hoidetaan interfaceilla Javan tapaan.
Ei ole varsinaista roskienkeruuta (ja siitä aiheutuvia kummallisuuksia).Huomaa että kyse on siis Pascalista ei C:stä!!! - välikoodi
Delphillä tehdä suoraan natiivikoodia kun taas C# tekee välikoodia jo tästä seuraa se että Delphikoodi on nopeampaa!
Muuten ne on aika samansuuntaisia (delphissä Pascalin syntaksi ja C#:ssa C:n syntaksi)
C#:n kehittäjä on aikoinaan lähtenyt Delphitiimistä (MS puhuu että se oli yhteistyössäkehitetty).
http://fi.wikipedia.org/wiki/C_sharp - kummallisuuksia ne ovat
a&a kirjoitti:
Ei ole moninperiintää (eikä siitä aiheutuvia ongelmia). Tuo hommahan hoidetaan interfaceilla Javan tapaan.
Ei ole varsinaista roskienkeruuta (ja siitä aiheutuvia kummallisuuksia).Huomaa että kyse on siis Pascalista ei C:stä!!!"Ei ole varsinaista roskienkeruuta (ja siitä aiheutuvia kummallisuuksia)"
Tämä on selvä puute kielessä minun kannaltani. Ohjelmoin aina kielellä, jossa on roskienkeruu, jos se on mahdollista.
Voisitko nyt selvästi kertoa, mitä ne roskienkeruusta johtuvat kummallisuudet ovat? Lyhyt selitys käy. Huomaa, että en kirjoita mitään matalan tason drivereita tms. missä pitää joka muistibitti olla hallinnassa.
C#:ssakaan ei ole moninperintää. Minusta sekin on hyvä ominaisuus. Vain huonosta ohjelmoinnista aiheutuu ongelmia, ei jostain kielen ominaisuudesta itsestään. - Hauska lista
välikoodi kirjoitti:
Delphillä tehdä suoraan natiivikoodia kun taas C# tekee välikoodia jo tästä seuraa se että Delphikoodi on nopeampaa!
Muuten ne on aika samansuuntaisia (delphissä Pascalin syntaksi ja C#:ssa C:n syntaksi)
C#:n kehittäjä on aikoinaan lähtenyt Delphitiimistä (MS puhuu että se oli yhteistyössäkehitetty).
http://fi.wikipedia.org/wiki/C_sharpItse asiassa sitä välikoodia voi kääntää JIT-kääntäjällä natiiviksi, ja tämä toiminnallisuus on olemassakin monissa systeemeissä. .NET ei ole pelkkä Mikkisoftan lelu, vaan on myös sellainen Mono-projekti, josta löytää hakemalla lisää tietoa.
No, ei se ole tärkeää. Tällä sivulla on hauska lista kielten nopeustesteistä.
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all
D-kielen Digital Mars -kääntäjä tuottaa nopeinta koodia tällä hetkellä. Jos nopeus on teille tärkeää, miksi ette ohjelmoi D-kielellä?
Vai onko nopeuden sijasta jotain muitakin tärkeitä ominaisuuksia, jotka vaikuttavat kielivalintaan? Kyllähän tuolla listalla kelpaa kehuskella myös FreePascalin hyvällä sijainnilla, mutta minua kiinnostavimmat kielet ovat itse asiassa vielä alempana. Minusta ne ovat _tarpeeksi_ nopeita.
Mihinkähän se Delphi menisi tuossa listassa? Ei taida olla mukana, koska ei ole avoimen lähdekoodin softaa.
Eikä kannata ottaa noita testejä vakavissaan. Huvikseni vain laitoin tiedoksi. - Kirjastoreissu
Kirjastossa on tosiaan tarjolla erilaisia Delphi-opuksia. Sellaisen lainaaminen ei maksa mitään, joten tutustun kyllä kieleen, kun kerran Borland taas aikoo tukea sitä jotenkin.
Kirjastoreissu siis edessä. Parempi se on itse kirjasta lukea kuin kysellä tyhmiä täällä :-) - kyllä
Kirjastoreissu kirjoitti:
Kirjastossa on tosiaan tarjolla erilaisia Delphi-opuksia. Sellaisen lainaaminen ei maksa mitään, joten tutustun kyllä kieleen, kun kerran Borland taas aikoo tukea sitä jotenkin.
Kirjastoreissu siis edessä. Parempi se on itse kirjasta lukea kuin kysellä tyhmiä täällä :-)Jos englannin kieli ei ole este, suosittelen "Mastering Delphi" sarjaa.
- CodeMan
Kirjastoreissu kirjoitti:
Kirjastossa on tosiaan tarjolla erilaisia Delphi-opuksia. Sellaisen lainaaminen ei maksa mitään, joten tutustun kyllä kieleen, kun kerran Borland taas aikoo tukea sitä jotenkin.
Kirjastoreissu siis edessä. Parempi se on itse kirjasta lukea kuin kysellä tyhmiä täällä :-)Ainahan Borlandi on tukenut sitä. Tosin kukaan ohjelmoija ei juurikaan.
- Delphi on nopea!
Hauska lista kirjoitti:
Itse asiassa sitä välikoodia voi kääntää JIT-kääntäjällä natiiviksi, ja tämä toiminnallisuus on olemassakin monissa systeemeissä. .NET ei ole pelkkä Mikkisoftan lelu, vaan on myös sellainen Mono-projekti, josta löytää hakemalla lisää tietoa.
No, ei se ole tärkeää. Tällä sivulla on hauska lista kielten nopeustesteistä.
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all
D-kielen Digital Mars -kääntäjä tuottaa nopeinta koodia tällä hetkellä. Jos nopeus on teille tärkeää, miksi ette ohjelmoi D-kielellä?
Vai onko nopeuden sijasta jotain muitakin tärkeitä ominaisuuksia, jotka vaikuttavat kielivalintaan? Kyllähän tuolla listalla kelpaa kehuskella myös FreePascalin hyvällä sijainnilla, mutta minua kiinnostavimmat kielet ovat itse asiassa vielä alempana. Minusta ne ovat _tarpeeksi_ nopeita.
Mihinkähän se Delphi menisi tuossa listassa? Ei taida olla mukana, koska ei ole avoimen lähdekoodin softaa.
Eikä kannata ottaa noita testejä vakavissaan. Huvikseni vain laitoin tiedoksi.Ainakin se löy laudalta Borland tekemän C kääntäjän (joka on nopeimpia C kääntäjiä mitä on tarjolla)
- 3ds
Tässä on tähän aiheeseen jollain lailla sopiva linkki:
http://www.oreilly.com/catalog/delphi/chapter/ch02.html - sdvoåpd
3ds kirjoitti:
Tässä on tähän aiheeseen jollain lailla sopiva linkki:
http://www.oreilly.com/catalog/delphi/chapter/ch02.htmlkun tuota artikkelia lukee niin täytyy vain nyökkäillä päätä ja todeta miten fiksuja borlandin insinöörit ovat olleet delphiä kehitellessään. monta sudenkuoppaa on onnistuttu välttämään ja kieli on todella elegantti ja pieksee helposti javan monimuotoisuudellaan.
- ...................
Delphi on nopea! kirjoitti:
Ainakin se löy laudalta Borland tekemän C kääntäjän (joka on nopeimpia C kääntäjiä mitä on tarjolla)
Intel alustoille intelin oma kääntäjä lienee nopein c/c ...
- .....................
kummallisuuksia ne ovat kirjoitti:
"Ei ole varsinaista roskienkeruuta (ja siitä aiheutuvia kummallisuuksia)"
Tämä on selvä puute kielessä minun kannaltani. Ohjelmoin aina kielellä, jossa on roskienkeruu, jos se on mahdollista.
Voisitko nyt selvästi kertoa, mitä ne roskienkeruusta johtuvat kummallisuudet ovat? Lyhyt selitys käy. Huomaa, että en kirjoita mitään matalan tason drivereita tms. missä pitää joka muistibitti olla hallinnassa.
C#:ssakaan ei ole moninperintää. Minusta sekin on hyvä ominaisuus. Vain huonosta ohjelmoinnista aiheutuu ongelmia, ei jostain kielen ominaisuudesta itsestään.""Ei ole varsinaista roskienkeruuta (ja siitä aiheutuvia kummallisuuksia)""
Roskienkerääjä (siivooja) käyttäytyy ihan kuin oikeassa elämässä siivoja käyttäytyy. Vaatii lisäresursseja, osaa siivota vain selkeät roskat ja on tiellä silloin kun pitäisi tehdä tehokkaasti asioita... Lisäksi tietokoneiden GC on todella laadutonta, esim. jos koodiin unohtuu referointi objektiin niin sitä ei siivota vaan muistia varataan aina vaan lisää... toisin sanoen: GC:hen EI VOI LUOTTAA vaan jokatapauksessa pitää koodata oikein. Jos kerran kooderin työ ei siis helpotu niin miksi ottaa GC mukaan ylipäätään?
Parhaat duunarit, ammattilaiset, siivoaa itse omat jättensä työnsä jälkeen. Tän olen oppinut puusepänverstaalla.
Olio-ohjelmoinnissa (siis Object Pascalissa) ei tarvi viilata muistia suoraan vaan riittää että hanskaa destruktorissa asiat haluamallaan tavalla jos sille on tarvetta. Jos tekee asiat child-parent systeemillä niin se muistinvapautus on automaattinen.
Manuaalista ohjaamista tarvitaan vain silloin kun joku child-objekti pitää säästää parentin tuhoutumisen yli eli siis parentin destructorissa adoptoidaan se child... - Syynä oli kokemus
sdvoåpd kirjoitti:
kun tuota artikkelia lukee niin täytyy vain nyökkäillä päätä ja todeta miten fiksuja borlandin insinöörit ovat olleet delphiä kehitellessään. monta sudenkuoppaa on onnistuttu välttämään ja kieli on todella elegantti ja pieksee helposti javan monimuotoisuudellaan.
Delphihän on jatkoa 80-luvun suosituimalle kielelle Turbo Pascalille (joka oli jo olio-ohjelmointikieli). Eli firmalla oli ennen Delphiä monta vuotta kokemusta Pascalista ja muista ohjelmointikielistä.
- Nopein C++
................... kirjoitti:
Intel alustoille intelin oma kääntäjä lienee nopein c/c ...
Borlandhan tekee myös vain Intel alustalle. Onkohan noita eri valmistajien C-kääntimiä vertailtu jossain.
Borlandhan mainostaa että sen c on tuottavin C -ohjelma - Utelias
..................... kirjoitti:
""Ei ole varsinaista roskienkeruuta (ja siitä aiheutuvia kummallisuuksia)""
Roskienkerääjä (siivooja) käyttäytyy ihan kuin oikeassa elämässä siivoja käyttäytyy. Vaatii lisäresursseja, osaa siivota vain selkeät roskat ja on tiellä silloin kun pitäisi tehdä tehokkaasti asioita... Lisäksi tietokoneiden GC on todella laadutonta, esim. jos koodiin unohtuu referointi objektiin niin sitä ei siivota vaan muistia varataan aina vaan lisää... toisin sanoen: GC:hen EI VOI LUOTTAA vaan jokatapauksessa pitää koodata oikein. Jos kerran kooderin työ ei siis helpotu niin miksi ottaa GC mukaan ylipäätään?
Parhaat duunarit, ammattilaiset, siivoaa itse omat jättensä työnsä jälkeen. Tän olen oppinut puusepänverstaalla.
Olio-ohjelmoinnissa (siis Object Pascalissa) ei tarvi viilata muistia suoraan vaan riittää että hanskaa destruktorissa asiat haluamallaan tavalla jos sille on tarvetta. Jos tekee asiat child-parent systeemillä niin se muistinvapautus on automaattinen.
Manuaalista ohjaamista tarvitaan vain silloin kun joku child-objekti pitää säästää parentin tuhoutumisen yli eli siis parentin destructorissa adoptoidaan se child...Olen yhä utelias, vaikka tuntuu, että kukaan ei halua selittää asiaa kunnolla. Pelotellaan vain tällaisillä tyhjillä väitteillä: "Parhaat duunarit, ammattilaiset, siivoaa itse omat jättensä työnsä jälkeen. Tän olen oppinut puusepänverstaalla."
Kylläpä nyt hävettää, että olen huono puuseppä. O_o;;
Mutta herran jestas, puhutaankin ohjelmoinnista.
Tuollainen ei ole pätevää argumentointia. Kuvittele, että olisit vaikka jossain teknologiapalavarissa, jossa päätettäisiin, millä kielellä seuraava projekti aloitetaan. Noinko sinä siellä asiasi esittäisit? Kelpaako se sinun töissäsi, jos töissä olet?
Kysyisin myös, että mistä kielistä ja toteutuksista sinulla on seuraavanlaisia kokemuksia:
"Roskienkerääjä (siivooja) käyttäytyy ihan kuin oikeassa elämässä siivoja käyttäytyy. Vaatii lisäresursseja, osaa siivota vain selkeät roskat ja on tiellä silloin kun pitäisi tehdä tehokkaasti asioita..."
Siis, missä kielissä tämä on ollut sinulle ongelma? Mitä ympäristöjä olet käyttänyt?
"GC:hen EI VOI LUOTTAA vaan jokatapauksessa pitää koodata oikein."
Mitä GC:tä (kieltä, kääntäjää etc.) olet käyttänyt, ja miten olet todennut, että siihen ei voi luottaa?
Huomaatko, minulla olisi mahdollisuus oppia sinulta jotain, jos osaisit vain selittää asiasi selkeästi. Onko uhosi takana tietoa? Faktat ratkaisevat nämä asiat. - Muttamutta
Delphi on nopea! kirjoitti:
Ainakin se löy laudalta Borland tekemän C kääntäjän (joka on nopeimpia C kääntäjiä mitä on tarjolla)
Voihan se olla nopea, mutta onko siitä nopeudesta mitään faktoja? Tuollaiset testitkään eivät ole kovin luotettavia, koska niissä testataan aina enemmän tai vähemmän lelusovelluksia. Oikeissa ohjelmissa on enemmän toiminnallisuutta jne.
Missä on Delphin nopeutta tukevat faktat? Kannattaisi tarjota, jos haluaa väittää, että Delphi on nopea. Muuten se ei vakuuta.
En kyllä sitä hitaaksikaan usko. Vaan ei se nopeus ole tärkein asia. Jos joku ohjelma on liian hidas, syy on huonossa suunnitelussa. - asdasdasdasdf
Muttamutta kirjoitti:
Voihan se olla nopea, mutta onko siitä nopeudesta mitään faktoja? Tuollaiset testitkään eivät ole kovin luotettavia, koska niissä testataan aina enemmän tai vähemmän lelusovelluksia. Oikeissa ohjelmissa on enemmän toiminnallisuutta jne.
Missä on Delphin nopeutta tukevat faktat? Kannattaisi tarjota, jos haluaa väittää, että Delphi on nopea. Muuten se ei vakuuta.
En kyllä sitä hitaaksikaan usko. Vaan ei se nopeus ole tärkein asia. Jos joku ohjelma on liian hidas, syy on huonossa suunnitelussa.Käsittääkseni se miksi voidaan väittää että Delphi on vähän nopeampi kuin Borland C johtuu siitä Pascalissa ei ole kaikkia asioita määrätty niin tarkasti kuin C :ssa (eli millä tavalla jokin on toteutettava) joten ne voidaan toteutaa halutessa nopeammalla tavalla.
(Borland tekee sekä C että Delphiä eli sillä on sama tietätämys kääntäjäteknologiasta) - Ihanko totta?
asdasdasdasdf kirjoitti:
Käsittääkseni se miksi voidaan väittää että Delphi on vähän nopeampi kuin Borland C johtuu siitä Pascalissa ei ole kaikkia asioita määrätty niin tarkasti kuin C :ssa (eli millä tavalla jokin on toteutettava) joten ne voidaan toteutaa halutessa nopeammalla tavalla.
(Borland tekee sekä C että Delphiä eli sillä on sama tietätämys kääntäjäteknologiasta)Siis tähänkö se teidän käsitys Delphin nopeudesta perustuu? "Luulen, että on näin jotenkin..."
Odotin nyt, että jotain faktaa olisi edes näyttää. Benchmarkkeja jne.
Lukisin myös mielelläni vähän tarkemman kuvauksen tai esimerkin jostakin asiasta, "joka ei ole yhtä tarkasti määrätty Pascalissa". Osaan kyllä tarpeeksi assemblyäkin lukea, että ihan kääntäjän tuotoksia voit vertailla, jos niitä Delphistä saa assemblynä näkyviin mitenkään.
Tietääkseni Borlandin C -kääntäjä ei ole koskaan ollut markkinoiden nopeinta koodia tuottava... - Sivusta seuraaja
Ihanko totta? kirjoitti:
Siis tähänkö se teidän käsitys Delphin nopeudesta perustuu? "Luulen, että on näin jotenkin..."
Odotin nyt, että jotain faktaa olisi edes näyttää. Benchmarkkeja jne.
Lukisin myös mielelläni vähän tarkemman kuvauksen tai esimerkin jostakin asiasta, "joka ei ole yhtä tarkasti määrätty Pascalissa". Osaan kyllä tarpeeksi assemblyäkin lukea, että ihan kääntäjän tuotoksia voit vertailla, jos niitä Delphistä saa assemblynä näkyviin mitenkään.
Tietääkseni Borlandin C -kääntäjä ei ole koskaan ollut markkinoiden nopeinta koodia tuottava...Ihmettelen väitettäsi.
Pyydät että toinen perustelee väitteensä ja sitten esität oman väitteesi mutta unohdat perustella sen?
(eikö olisi parempi että kertoisit omat perustelusi väitteelle tarvitsemillasi faktoilla jolloin voisit häneltä vaatia vastaavanlaisia tietoja) - Te ensin
Sivusta seuraaja kirjoitti:
Ihmettelen väitettäsi.
Pyydät että toinen perustelee väitteensä ja sitten esität oman väitteesi mutta unohdat perustella sen?
(eikö olisi parempi että kertoisit omat perustelusi väitteelle tarvitsemillasi faktoilla jolloin voisit häneltä vaatia vastaavanlaisia tietoja)Hyvä on, perun väitteeni. En tiedä, mikä on nopein C -kääntäjä.
Onko teillä perusteita noille Delphin nopeutta koskeville väitteillenne? Niitä kyllä esitettiin jo ihan tarpeeksi. Mistä perusteet? - .......................
Utelias kirjoitti:
Olen yhä utelias, vaikka tuntuu, että kukaan ei halua selittää asiaa kunnolla. Pelotellaan vain tällaisillä tyhjillä väitteillä: "Parhaat duunarit, ammattilaiset, siivoaa itse omat jättensä työnsä jälkeen. Tän olen oppinut puusepänverstaalla."
Kylläpä nyt hävettää, että olen huono puuseppä. O_o;;
Mutta herran jestas, puhutaankin ohjelmoinnista.
Tuollainen ei ole pätevää argumentointia. Kuvittele, että olisit vaikka jossain teknologiapalavarissa, jossa päätettäisiin, millä kielellä seuraava projekti aloitetaan. Noinko sinä siellä asiasi esittäisit? Kelpaako se sinun töissäsi, jos töissä olet?
Kysyisin myös, että mistä kielistä ja toteutuksista sinulla on seuraavanlaisia kokemuksia:
"Roskienkerääjä (siivooja) käyttäytyy ihan kuin oikeassa elämässä siivoja käyttäytyy. Vaatii lisäresursseja, osaa siivota vain selkeät roskat ja on tiellä silloin kun pitäisi tehdä tehokkaasti asioita..."
Siis, missä kielissä tämä on ollut sinulle ongelma? Mitä ympäristöjä olet käyttänyt?
"GC:hen EI VOI LUOTTAA vaan jokatapauksessa pitää koodata oikein."
Mitä GC:tä (kieltä, kääntäjää etc.) olet käyttänyt, ja miten olet todennut, että siihen ei voi luottaa?
Huomaatko, minulla olisi mahdollisuus oppia sinulta jotain, jos osaisit vain selittää asiasi selkeästi. Onko uhosi takana tietoa? Faktat ratkaisevat nämä asiat."Mitä GC:tä (kieltä, kääntäjää etc.) olet käyttänyt, ja miten olet todennut, että siihen ei voi luottaa?"
Javaa ja Pythonia, molemmissa sama ongelma eli siis jos objektia referoidaan jostain niin roskienkeruu ei toimi.
Parhaana esimerkkinä tilanne jossa kaksi täysin muusta koodista irrallista objektia referoi toisiaan. Roskienkerääjä tarkistaa referenssin "Ahaa, näitä referoidaan!" ja jättää keräämättä. Toki kyseessä on ohjelmointiheikkous mutta hei, roskienkerääjänhän pitäisi olla sellainen että vapautettuja objekteja ei tarvi säätää...
Tää tilanne on vähän sellainen kuin puuseppä ruuvaisi kaksi puolivalmistetta yhteen ja jättäisi sen pöydälle. Tätä yhdistelmää ei tarvitakaan; jos puuseppä itse siivoaa hän tietää hökötyksen turhaksi. Jos siivooja siivoaa ei siivoja tiedä onko hötäskä tarpeellinen vai ei ja jättää sen paikalleen. Ennenpitkää verstas on täynnä erilaisia häkkyröitä joista millään ei tee mitään ja joita kukaan ei uskalla poistaa koska ne vaikuttavat olevan tärkeitä.
Suosittelen puutöitä, ihan vakavasti. Niitä tekemällä oppii paljon tehokkaan koodaamisen perimmäistä Zeniä. Siinä ei auta vaikka olisi verstas täynnä toinen toistaan parempaa vermettä. - adsl2
Ihanko totta? kirjoitti:
Siis tähänkö se teidän käsitys Delphin nopeudesta perustuu? "Luulen, että on näin jotenkin..."
Odotin nyt, että jotain faktaa olisi edes näyttää. Benchmarkkeja jne.
Lukisin myös mielelläni vähän tarkemman kuvauksen tai esimerkin jostakin asiasta, "joka ei ole yhtä tarkasti määrätty Pascalissa". Osaan kyllä tarpeeksi assemblyäkin lukea, että ihan kääntäjän tuotoksia voit vertailla, jos niitä Delphistä saa assemblynä näkyviin mitenkään.
Tietääkseni Borlandin C -kääntäjä ei ole koskaan ollut markkinoiden nopeinta koodia tuottava...Benchmarkkeja en ole tutkinut joten native koodin nopeuteen en pysty kommentoimaan. Omakohtaisten kokemusten perusteella kääntäjä tuottaa varsin nopeaa binääriä. Ja jos optimointia haluaa harrastaa se onnistuu helposti koska assemblyä voi kirjoittaa suoraan koodin sekaan. Kääntäjän tuotoksia pystyy tarkastelemaan runtimena suoraan IDE:ssä joten optimointi on helppoa.
- .........................
Te ensin kirjoitti:
Hyvä on, perun väitteeni. En tiedä, mikä on nopein C -kääntäjä.
Onko teillä perusteita noille Delphin nopeutta koskeville väitteillenne? Niitä kyllä esitettiin jo ihan tarpeeksi. Mistä perusteet?Perusteet:
Tuottaa natiivia binäärikoodia. Tällöin nopeudessa ohitetaan heti kaikki tulkattavat ja VM-kielet.
Borland oletettavasti on tehnyt pitkään kehitystyötä kääntäjiensä optimoinnissa. TurboPascalin ajoista saakka Borland on hionut tekniikkaansa kilpailun takia.
Tässä on jo kaksi hyvää syytä "voidaan olettaa" perusteella.
Pascalin (siis Delphin) ominaisuudet ovat enimmäkseen sytaktisia, kielen ominaisuudet ja laajuus ja sijoittuminen akselilla konekieli-strukturoitu kieli-oliokieli on hyvin samanlainen kuin c/c kielen. Oikeastaan se on 1:1 sama. Delphin ObjectPascal oikeastaan on "c ja c " eikä "c" tai "c ", se on ainoa merkittävä ero. Alkuperäinen Pascal lienee kuollut ja kuopattu missään muussa kuin oppikirjaesimerkkinä lineaarisesta koodauksesta; toisin kuin C jota ei ole vielä kuopattu vaikka C :kin on.
Niin, miten tämä liittyy nopeuteen? Siis Delphin kääntämä muistinhallintarakenne on hyvin samankaltainen kuin c/c :lla. Pointerit ja olioviittaukset käsittelevät suoraan muistiosoitteita eivätkä ne ole virtualisoitu/abstrahoitu millään tavalla.
Tässäpä kiteytettynä syyt miksi pascal on nopea, onko se nopein? Varmasti jossain. ja jostain anglesta Tuskin kaikessa. Delphi tekee luotettavasti nopeaa generistä koodia. - mythbuster
......................... kirjoitti:
Perusteet:
Tuottaa natiivia binäärikoodia. Tällöin nopeudessa ohitetaan heti kaikki tulkattavat ja VM-kielet.
Borland oletettavasti on tehnyt pitkään kehitystyötä kääntäjiensä optimoinnissa. TurboPascalin ajoista saakka Borland on hionut tekniikkaansa kilpailun takia.
Tässä on jo kaksi hyvää syytä "voidaan olettaa" perusteella.
Pascalin (siis Delphin) ominaisuudet ovat enimmäkseen sytaktisia, kielen ominaisuudet ja laajuus ja sijoittuminen akselilla konekieli-strukturoitu kieli-oliokieli on hyvin samanlainen kuin c/c kielen. Oikeastaan se on 1:1 sama. Delphin ObjectPascal oikeastaan on "c ja c " eikä "c" tai "c ", se on ainoa merkittävä ero. Alkuperäinen Pascal lienee kuollut ja kuopattu missään muussa kuin oppikirjaesimerkkinä lineaarisesta koodauksesta; toisin kuin C jota ei ole vielä kuopattu vaikka C :kin on.
Niin, miten tämä liittyy nopeuteen? Siis Delphin kääntämä muistinhallintarakenne on hyvin samankaltainen kuin c/c :lla. Pointerit ja olioviittaukset käsittelevät suoraan muistiosoitteita eivätkä ne ole virtualisoitu/abstrahoitu millään tavalla.
Tässäpä kiteytettynä syyt miksi pascal on nopea, onko se nopein? Varmasti jossain. ja jostain anglesta Tuskin kaikessa. Delphi tekee luotettavasti nopeaa generistä koodia."Tuottaa natiivia binäärikoodia. Tällöin nopeudessa ohitetaan heti kaikki tulkattavat ja VM-kielet. "
Tiedätkö mitä ovat JIT tai DynaRec ? Nykypäivänä ei ole ns "tulkaavia kieliä", niitä käytetään vain kun muistia on vähän.
Ja mitä tuohon Pascal/Dephi ja C/C suhteen tulee molemmat ovat samalla linjalla, vai väitätkö että et pysty tekemään funktiota ilman oliota ? vrt. java
"siis Delphin kääntämä muistinhallintarakenne on hyvin samankaltainen kuin c/c :lla. Pointerit ja olioviittaukset käsittelevät suoraan muistiosoitteita eivätkä ne ole virtualisoitu/abstrahoitu millään tavalla. "
Otetaanpa tähän esimerkki javasta, niin oudolta kuin asia kuulostaakin:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Netti on täynnä BechMark testejä kuten yllä, mutta missä on testit dephistä ?
Ps. henk. koht. pidän delphistä ja muista borlandin kielistä. - Mika0800
kyllä kirjoitti:
Jos englannin kieli ei ole este, suosittelen "Mastering Delphi" sarjaa.
Selkeimpiä kirjoja on tämä:
Delphi Developer's guide (Steve Teixeira, Xavier Pacheco)
Tämän ja muutamia muita aiheesta löydät täältä:
http://www.bookplus.fi/search.php?Text=DELPHI DEVELOPER'S GUIDE&TextType=words
Hyvä on myös tämä:
Delphi -sovellusten opas (Juha Piispa, Jani Järvinen), mutta tämä EI sovellu aloittelijalle, vaan alkeet on syytä opetella ensin jollain muulla tavalla. - Mika0800
3ds kirjoitti:
Tässä on tähän aiheeseen jollain lailla sopiva linkki:
http://www.oreilly.com/catalog/delphi/chapter/ch02.htmlLainaus: "Tässä on tähän aiheeseen jollain lailla sopiva linkki:"
http://www.oreilly.com/catalog/delphi/chapter/ch02.html
Hyvä linkki!
Tuon kun lukee, niin toivottavasti selviää, että on paha harhaluulo, että C tai C olisivat jotenkin Delphiä pätevämpiä.
Joitakin käännöksiä tärkeimmistä ja omia kommenttejani em. sivulla mainituista asioista:
1. Aito tuki interface:ille ja niiden toteutuksen voi tehdä joko luokassa suoraan tai delegoida toiselle luokalle, tarpeen mukaan
2. Vaikka roskienkeruuta ei ole, niin interface:jen avulla saa tämäntyyppisenkin toiminnallisuuden aikaan, jos sitä tarvitaan.
3. Moniperintä: EI luokkien moniperintää, mutta interface:jen moniperintä toki löytyy
4. "Class (static) fields" - tarkoittaakohan tämä luokka (ei siis ilmentymä) kohtaisia muuttujia. Jos, niin sellaisia ei Delphissä tosiaan suoraan ole, mutta niitä on haluttaessa helppo simuloida näin:
(
Huomaa myös property LuokkaLukuPtr; sitä ei tässä varsinaisesti tarvittaisi, mutta jos halutaan antaa suora pääsy itse muuttujaan, niin muuttujanimen paikalle vain LuokkaLukuPtr^
Tämä on tarpeen, jos haluat esim. välittää tuon luokkamuuttujan var -parametrina, mikä pelkällä
LuokkaLuku -propertyllä ei olisi mahdollista
)
Unit LuokkamuuttujaTesti;
interface
type
TJokinLuokka = class
//
function GetLuokkaLuku:Integer;
function GetLuokkaLukuPtr:PInteger;
procedure SetLuokkaLuku(Value:Integer);
property LuokkaLuku : Integer read GetLuokkaLuku write SetLuokkaLuku;
property LuokkaLukuPtr : PInteger read GetLuokkaLukuPtr;
end;
implementation
var
TJokinLuokka_LuokkaLuku : Integer;
function TJokinLuokka.GetLuokkaLuku:Integer;
begin
Result := TJokinLuokka_LuokkaLuku;
end;
procedure TJokinLuokka.SetLuokkaLuku(Value:Integer);
begin
TJokinLuokka_LuokkaLuku := Value;
end;
function TJokinLuokka.GetLuokkaLukuPtr:PInteger;
begin
Result := @TJokinLuokka_LuokkaLuku;
end;
end.
5. Ainakin omasta mielestäni Delphin unitteihin pohjautuva modulijärjestelmä on selkeä, ja siksi erillisiä namespaceja C:n tapaan ei yleensä tarvita. Kaikkien käytettyjen Unittien interface -osassa määriteltyjä asioita voi suoraan käyttää, mutta ns. "unit override" on käytettävissä mahdollisten nimikonfliktien ratkaisemiseksi, tai pakottamaan juuri haluttu asia useamman samannimisen joukosta.
esim. jos Unit A ja Unit B molemmat määrittelevät interface -osassaan muuttujan Muuttuja, niin tarvittaessa niihin voi yksilöidysti viitata näin:
A.Muuttuja
B.Muuttuja
6. Konstruktorit, destruktorit ja metodit:
Näissä perivä luokka itse päättää, missä vaiheessa (jos missään) kutsutaan perityn luokan vastaavaa.
Konstruktoreissa luotu luokka on heti oikeaa tyyppiä, ei ensin perityn luokan tyyppiä, kuten ilmeisesti C :ssa.
7. Class reference eli luokkatyypit. Tämä ominaisuus tukee mainiosti Delphin luokkamallia.
esim. Jos on yleiskäyttöinen komponentti TTcpServer, niin siinä voisi olla vaikkapa:
type
TTcpClient = class(TObject)
end;
TTcpClientRef = class of TTcpClient;
ja itse TTcpServer -luokassa:
ClientClass : TTcpClientRef;
kun sitten saapuu TCP -kutsu, luodaan lennossa oikeaa sovellusohjelmoijan haluamaa tyyppiä oleva ilmentymä, joka periytyy TTcpClient -luokasta:
procedure TTcpServer.OnTcpNewSession(Sender:TObject);
begin
//
AClient := ClientClass.Create(Self);
// luodaan käyttäjän määrittelemää tyyppiä oleva luokan ilmentymä, joka periytyy luokasta TTcpClient.
end;
Tässä siis esim. jokin komponenttivalmistaja on voinut kirjoittaa tämän koodin joka toteuttaa TTcpServer -luokan, joka siis on tämän komponenttivalmistajan luoma Delphi -komponentti ja tuote.
Ja tuotteen käyttäjä voi sitten vaikkapa:
type
TMyTcpClient = class(TTcpClient)
end;
ja...
TcpServer.ClientClass := TMyTcpClient;
tämän jälkeen TTcpServer -komponentti osaa luoda tyyppiä TMyTcpClient olevan ilmentymän uuden TCP -yhteyden saapuessa. Näin silti, vaikka komponentin TTcpServer tekijä ei tiedä TMyTcpClient -tyypistä sen nimeä, eikä mitään muuta kuin sen, että TMyTcpClient -luokka periytyy
TTcpClient -tyypistä.
Tässä siis hyvä esimerkki tuon "class reference" -tyypin käytöstä.
- xxxxx
"Mutta oikein peraattein koodatussa Delphi -ohjelmassa edes ohjelmointivirhe ei aiheuta vakavaa tietoturva-aukkoa, vaan ainoastaan väärin toimivan ohjelman."
Siis onko joku ohjelmointikieli, jossa 'oikein periaattein koodatussa' ohjelmassa voi olla vakava tietoturva-aukko?
Jos käyttää kielenä c -kieltä, niin kannattaa käyttää Microsoftin Visual Studion 2005:n c -kieltä.
Siinä voi määrätä kääntäjän estävän ettei ohjelmaa kaapata puskurin ylivuodolla http://www.microsoft.com/finland/msdn/tietoturvaominaisuudet.mspx
"Visual C :n Buffer Security Check -kääntäjäasetus (/GS) on suunniteltu auttamaan siinä, että haitalliseksi suunniteltua koodia voidaan estää hyödyntämästä puskurin ylivuotoja sovelluksissa. Suuri osa koodin heikkouksista on puskurin ylivuotoja. /GS-asetus asettaa salatun arvon (testiarvon) puskurin loppuun. Tämä arvo tarkistetaan koodin suorittamisen aikana. Jos arvo on muuttunut, ohjelman suoritus keskeytetään ja tehdään tietoturvapoikkeus.
/GS-asetus ei estä puskurin ylivuotoa, mutta se suojaa koodin mahdolliselta kaappaamiselta pysäyttämällä ohjelman suorituksen."- ....................
"/GS-asetus ei estä puskurin ylivuotoa, mutta se suojaa koodin mahdolliselta kaappaamiselta pysäyttämällä ohjelman suorituksen."
Vittu kun on eleganttia :D :D :D
"Meidän softat ovat turvallisia, nyt ne kaatuvat hakkerointiyritykseen..." - xxxxx
.................... kirjoitti:
"/GS-asetus ei estä puskurin ylivuotoa, mutta se suojaa koodin mahdolliselta kaappaamiselta pysäyttämällä ohjelman suorituksen."
Vittu kun on eleganttia :D :D :D
"Meidän softat ovat turvallisia, nyt ne kaatuvat hakkerointiyritykseen..."Jos joku yrittää hakkeroida ohjelman, niin silloinhan on parasta lopettaa ohjelman suoritus. Tuossa ed. lainauksessani sanottiin myös että silloin suoritetaan tietoturvapoikkeus. Käsittääkseni siihen moduliin voidaan sitten elegantisti panna End-käsky. Kukin käyttäjähän käyttää omaa muistialuetta, joten ei se ohjelman suoritus muilta katkea.
Tietysti ohjelmien syöttötietojen raja-arvot pitäisi aina tarkistaa, mutta kyllähän tuollainen automaattitarkistus joka tapauksessa ainakin vähän vähentää koodajan hermojen kulutusta.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Tollokin tajuaa että Timo Vornanen
oli joutunut äärimmäiseen tilanteeseen ampuessaa yhden laukauksen katuun. Ei poliisi tee tuollaista hetken mielijohteest6975899Istuva kansanedustaja epäiltynä pahoinpitelystä ja ampuma-aserikoksesta
Seiskan tietojen mukaan Timo Vornanen on epäiltynä pahoinpitelystä ja ampuma-aserikoksesta eikä kenellekään taatusti tul5143690Timo Vornanen kilahti
Mikähän sille kansanedustajalle polisiisi miehelle on noin pahasti mennyt hermot , että tulevaisuudensa pilasi totaalise1843512Pullonpalautusjärjestelmä muuttuu - paluu menneisyyteen
EU suuressa viisaudessaan on päättänyt, että pulloja pitää kierrättää. Jos oikein ymmärsin, nykyisen järjestelmänmme ti1722714Sininen farmari - Ford Focus- YFB-842 on poliisilta kadoksissa Kauhajärvellä
https://alibi.fi/uutiset/poliisilta-poikkeuksellinen-vihjepyynto-autossa-oleva-henkilo-on-avuntarpeessa/?shared=29255-2d102479- 2762116
Onko oikeudenmukaista? Yhdellä taholla yllättävä valta-asema Tähdet, tähdet -voittajan valinnassa!
Näinpä, onko sinusta tämä oikein? Viime jaksossakin voittaja selvisi vain yhden äänen erolla ja tänä sunnuntaina ensimm241563Persukansanedustaja Timo Vornanen ammuskellut Helsingissä
Poliisi siviiliammatiltaan, luvallinen ase mukana baarissa tällä hemmetin valopääpersulla. Meni eduskunnasta suoraan baa1071462No kerros nyt nainen
Kumpi mielestäsi oli se joka väärinkäsitti kaiken? Nyt voi olla jo rehellinen kun koko tilanne on jo lähes haihtunut.1001409Nainen, mietit miten minä jaksan
En voi hyvin. Nykyään elämäni on lähinnä selviytymistä tunnista ja päivästä toiseen. Usein tulee epävarma olo, että mite891200