GCC koodi ongelma

Kirjoittaja Viesti   JPQ Tiistaina, 9. elokuuta, 2005 - klo 7.53:    #include #include float cnt=0; main() { printf("%f\n",ZingMod(0.5,8)); printf("%f\n",ZingMod(0.5,8)); printf("%f\n",ZingMod(0.5,8)); } float ZingMod(float sample,float modfreq) { cnt=cnt+1; if (cnt >= 7.5) cnt=0; return cnt; } yritän tässä tehdä funktioita joka käsitelee float lukuja kappas ei vain suju ja tulostuskin parhaimilaan ollut 0.0000 tyylistä mikä hitto gcctä vaivaa vai olenko puusilmä.   Marq Tiistaina, 9. elokuuta, 2005 - klo 9.18:    Vika on siinä, että ZingMod pitää laittaa ennen mainia tai ainakin esitellä se. Muuten main ei kutsuessaan tiedä, minkä tyyppisiä parametreja ZingModin pitäisi saada ja yrittää laittaa täten inttejä sinne pinoon. GCC:lle on myös hyvä laittaa -lm perään, että se ottaa liukulukukirjaston mukaan.   Patte Tiistaina, 9. elokuuta, 2005 - klo 10.24:    C ohjelmointikieli pitäisi jo tänä päivänä lailla kieltää (about 15 vuoden kokemus kielestä) ja keksiä uusi ihmisläheisempi kieli... Älkää vaivautuko vastaamaan tähän, toivotaan että tietotekniikka taas joskus jatkaa kehitystään koska nyt se on jo liian kauan seisonut paikoillaan (Hui, tulipa kirjoitettua pessimistinen viesti!)   Marq Tiistaina, 9. elokuuta, 2005 - klo 10.32:    C-kielihän on silkkaa rakkautta! Tehokas, portattava ja tiivis. Assembleria helpompi, bloattikieliä nopeampi.   JPQ Tiistaina, 9. elokuuta, 2005 - klo 11.17:    Patte: Marq perustelikin jo munkin edestä. Marq: just sanoit syyt miksi C ja toiseksi en tiedä hyvää C++ kirjaa ja voin sanoa että ITpressillä esim. ei ole sellaista. Ja kiitosh vinkistä ja olin siis puusilmä eikun katsomaan miten esittely menee mutta luultavasti ZingMod siirtyy.   Marq Tiistaina, 9. elokuuta, 2005 - klo 11.36:    Näinhän se menee: float ZingMod(float sample,float modfreq);   Jani Kuituniemi Tiistaina, 9. elokuuta, 2005 - klo 13.25:    Höh.. C ja Assemblyhän on juuri ne parhaat kielet ohjelmointiin   JPQ Tiistaina, 9. elokuuta, 2005 - klo 15.51:    Jani Kuituniemi: aika lailla samaa mieltä vaikka assembleria en osaakkaan.(Yritetty on noin 3 kertaa 68000ta ja 5 kertaa 6502sta...)   Tomi Tiistaina, 9. elokuuta, 2005 - klo 19.04:    Ihan näin ohimennen: miksi aliohjelmasi ei hyödynnä parametrejään SAMPLE & MODFREQ ? Paras lyhyt ohjelmointiopas on mielestäni Käytännön ohjelmointi, Brian W. Kernighan & Rob Pike, ISBN 951-826-131-8 C ohjelmointi voi olla todella turhauttavaa... nimimerkki: Amphibian ohjelmointi kaatui puutteelliseen C-osaamiseen.   Jon Tiistaina, 9. elokuuta, 2005 - klo 19.28:    C-ohjelmoinnissa lienee aloittajien kannalta turhauttavaa kääntäjän ylimieliset herjat, joista ei meinaa aina saada selvää; virhekään ei välttämättä ole samalla riville. Ongelma voi olla jopa pahempi C++:ssa eikä siitä Javassakaan päästy eroon. Ja sitten kun kääntäjän kanssa on sopupeli niin pitää vieltä vääntää kättä linkkerin kera ;) Ja lopuksi vielä korjata ne taulukkoindeksit ja pointteribugit =) "Oh, I am a C programmer and I'm okay I muck with indices and structs all day And when it works, I shout hoo-ray Oh, I am a C programmer and I'm okay" "Old programmers never die - they just can't C" http://lalaland.cl.msu.edu/~vanhoose/humor/0070.html http://members.ozemail.com.au/~djbenn/docs/plquotes.html jne.   JPQ Tiistaina, 9. elokuuta, 2005 - klo 20.53:    Tomi: mulla kyllä hyvä c kirja ettei siitä ole kyse vaikka sen kanssa yritin aivot ei ongelmaa keksineet siksei hyödynnä tein muutoksen koodiin niin pienellä ajalla että jäi turhuuksia koska en halua julkisesti paljastaa funktiotani ainakaan ennen kun se toimii ajatelulla tavalla...   Patte Tiistaina, 9. elokuuta, 2005 - klo 20.57:    Marq: C-kielihän on silkkaa rakkautta! Tehokas, portattava ja tiivis. Assembleria helpompi, bloattikieliä nopeampi. C-ohjelman joutuu *tekemään* portattavaksi ei se sellaiseksi itsekseen muodostu johtuen kääntäjien eroista yms monesta muusta tekijästä.   Patte Tiistaina, 9. elokuuta, 2005 - klo 21.07:    JPQ: C-kirjat voivat sekoittaa sinua vain lisää koska ovat täynnä asiavirheitä + eivät kerro riittävän tarkasti milloin asiat ovat niin tai näin mutta eikun tsemppiä!   JPQ Tiistaina, 9. elokuuta, 2005 - klo 21.50:    Patte: tämä on se ANSIC kirja jossa Ritchie on toisena tekijänä ja se alkuperäinen englanninkielinen. ja tässä ei ole asia virheitä ainakaan yhtäkään en ole nähnyt.   jap Tiistaina, 9. elokuuta, 2005 - klo 22.04:    Kyllä tuo sinun ohjelma toimii ok ainakin minun systeemillä, kun sen kääntää gcc:llä. (ZingMod-funktio pitää tietenkin esitellä alussa, kuten Marq sanoi, ja laittaa mukaan stdio.h -tiedosto, että printf toimii). Tulostuksena tulee 1.000000 2.000000 3.000000 juuri niin kuin pitääkin. Sulla on varmaan jotain joka vetää tuloksen 0:ksi siinä osassa, mitä et ole laittanut näytille.   Tomi Tiistaina, 9. elokuuta, 2005 - klo 22.33:    JPQ, sun pitää muistaa että C:ssä tyyppimuunnokset sujuvat joskus vaarallisen helposti ja paikalliset muuttujat katoavat kun suoritus poistuu aliohjelmasta. Joskus ainoa keino, löytää "omat" ajatusmokat on lisäillä välitulostuksia... Joskus auttaa se, että kirjoittaa auki mitä ohjelma tekee ja tekee ohjelman vasta sitten .-) Aliohjelmien käyttäytyminen kannattaa testata sopivilla testitapauksilla ennenkuin niihin luottaa ja piilottaa isompaan pääohjelmaan.   JPQ Tiistaina, 9. elokuuta, 2005 - klo 22.34:    jap: foorumin lainaus kykyjen rajojen takia stdioon mukaan otto uupuu ja ongelmani oli tosiaan vain ainoastaan esittely kaikkia ceen huonouksia ja hienouksia ei aina muista kun ei aktiivi koodaa kun ei pahemmin huvita syitä on monia...   Tomi Tiistaina, 9. elokuuta, 2005 - klo 23.12:    Vielä lisäyksenä, että itse The Creator of C++ (Bjarne Stroustrup) valittaa kirjassaan The C++ Programming Language, että C-ohjelman päivittäminen Cplusplussaksi voi olla kovin vaikeata. Ensinnäkin näiden kahden kielen yhteinen kielioppi ei ole se paras tapa aloittaa modernin C++:n opiskelua ja toisekseen vanhemmat kääntäjät saattavat toteuttaa joitakin uusia ominaisuuksia puutteellisesti josko ollenkaan. Tosin vuonna 2005 on vaikea kuvitella, että olisi kyse tästä. Käsittääkseni viimeiset isot lisäykset C++ standardiin Dr. B.S. teki vuonna 1989 (multiple inheritance, templates, and exceptions). En siis etsisi vikaa kääntäjästä edes toisena vaihtoehtona. Mutta ehkä käännösympäristöstä. Käytännössä lähinnä include-tiedostojen järjestys ja sisältö. Ja jos tuntuu olevan yhteensopivuusongelma niin kyseinen kirja käteen (noin 1000 sivuinen tiiliskivi) ja sieltä Appendix B: Compatibility... "Deep in the fundamental heart of mind and Universe, there is a reason. - Slartibartfast" Ps. Kirjan kustantajan kotisivu Addison-Wesley -> Computer Science   JPQ Tiistaina, 9. elokuuta, 2005 - klo 23.52:    Tomi: ongelma ratkesi kuten jo sanoin eli se oli etten esitellyt funktiota ja gcceen otin vaihtoehdoksi olen varauksella aina softien kanssa varsinkin tälläisten jotka tekee koodia tai luo/käsitelee standardin mukaisia tiedostoja. Lisäksi ennenkin on ollut kait GCC riippuvia ongelmia mulla.   Jupp3 Tiistaina, 9. elokuuta, 2005 - klo 23.56:    >C-ohjelman päivittäminen Cplusplussaksi voi olla kovin vaikeata. Itse en kyllä näe yhtään syytä, miksi toimiva(?) C-ohjelma pitäisi "päivittää" C++-ohjelmaksi Enkä kyllä toisaalta ymmärrä mikä siinä C++:ssa olisi niin paljon parempaa, että sitä pitäisi käyttää... Hyvin olen C:llä pärjännyt tähänkin asti Tarkkana niiden funktiomäärittelyjen kanssa, palautusarvo tulkitaan helposti int-tyyppiseksi   Tomi Keskiviikkona, 10. elokuuta, 2005 - klo 0.12:    Hyvä että toimii, oli kiva yrittää olla avuksi. Päivittäminen C++-ohjelmaksi on aika usein edessä jos meinaa tehdä jotain "vakavaa" \blink{}}. Yleensä olen kohdannut tuon ongelman itse kun olen portannut/päivittänyt jonkun muun™ kirjoittamaa koodia ja olen halunnut käyttää ++ laajennoksia... Headerit varsinkin helposti aiheuttavat "yskää"... Vilkkuva smiley yskii   JPQ Keskiviikkona, 10. elokuuta, 2005 - klo 1.12:    Tomi: ei muuten ole kun vielä morphosinkin includet lienee c aikaa lisäksi ne vakavat mitä mietin nopeus on niin tärkeää ettei c++ kermavaahto ole kivaa. Tätäkin rutiinia pitänee pystyä kutsumaan sekunnissa 44100 kertaa.   itix Keskiviikkona, 10. elokuuta, 2005 - klo 1.56:    GCC:llä kannattaa käyttää optiota -Wall jolloin se whinettää puuttuvista prototyypeistä ja paljon muustakin. Ainakin oma koodin on parantunut kun ei jää vahingossa muuttujia alustamatta jne.   Jon Keskiviikkona, 10. elokuuta, 2005 - klo 10.58:    JPQ: se että käyttää C++:aa, ei tee ohjelmasta automaattisesti hidasta tai bloattia. Suurin osa PC-peleistä taitaa olla C++:lla kirjoitettuja. En ole tosin varma, joka Carmack on vaihtanut ;) Funktiosi vaikuttaa sellaiselta, että siitä kannattaa tehdä inline-funktio.   itix Keskiviikkona, 10. elokuuta, 2005 - klo 11.12:    "Funktiosi vaikuttaa sellaiselta, että siitä kannattaa tehdä inline-funktio." Kannattaa laittaa 'static' funktiomäärittelyn eteen. C-kääntäjä kyllä inlinettää funktiot jos vain mahdollista ja järkevää.   Palle Keskiviikkona, 10. elokuuta, 2005 - klo 11.46:    Kylläpä taitaa lähes kaikki kaupalliset "triple-A" pelimoottorit olla C++:lla tehtyjä, oliopohjaisia systeemejä, Esim. Unreal-Engine, ID:n DoomIII-Engine, Valve:n Source-Engine.   Jon Keskiviikkona, 10. elokuuta, 2005 - klo 11.52:    itix: riippuen optimointitasosta?   Jon Keskiviikkona, 10. elokuuta, 2005 - klo 12.02:    http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Inline.html#Inline   Frn Keskiviikkona, 10. elokuuta, 2005 - klo 12.04:    JPQ: "...nopeus on niin tärkeää ettei c++ kermavaahto ole kivaa" Mitähän tämä kermavaahto mahtaa olla? "Tätäkin rutiinia pitänee pystyä kutsumaan sekunnissa 44100 kertaa." Miksi se olisi c++:lla ongelma?   KimmoK Keskiviikkona, 10. elokuuta, 2005 - klo 12.36:    Työpaikan kokemuksista oon sen verran oppinut että joissain reaaliaikajutuissa joutuu olemaan varovainen C++:lla koodatessa. Jos kovasti olioherkkua on matkassa niin kyllä se alkaa näkyä "sykkeleiden" hukkumisena. Se että PC pelimoottoreissa käytetään c++:aa selittänee poskettomat CPU vaatimukset?????   Tomi Keskiviikkona, 10. elokuuta, 2005 - klo 13.50:    Se, pystytäänkö jotain rutiinia todella kutsumaan säännöllisin väliajoin tuhansia kertoja sekunnissa ei ole ohjelmointikielestä riippuvainen. Toki jos kääntäjä ei osaa optimoida koodia ja silmukoissa tehdään ylimääräistä työtä niin nykiihän se, helposti. Mutta noin yleisesti koneen teho ja kyky suoriutua keskeytyksistä ratkaisee onko mahdollista tehdä asioita oikeasti in Real TIME! C-ohjelmoijan tuottavuus ei välttämättä vastaa nykyajan vaatimuksia. Jos koodia pitää optimoida käsin niin sitten pitää ymmärtää konekäskyt kääntäjän "sielunelämän" lisäksi. Ja rahaa, tai vähintään tunteja palaa Se on sitten ihan eriasia onko edes C++ enää korrekti tuottava työkalu, mutta on sillä ainakin ajan patinaa .-) Kielen ongelma on sen laajuus ja vaativuus. Oliopohjaiset tietokannat lienevät tulossa myös peliohjelmointiin, rajauksesta riippuen moni nykyinen pelimoottori voidaan lukea tähän luokkaan kuuluvaksi.   Palle Keskiviikkona, 10. elokuuta, 2005 - klo 14.12:    Oliopohjaisuus C++:ssa ei tosiaankaan tarkoita automaattisesti hidasta koodia. Hyvänä esimerkkinä voisi mainita, esim erään SW- mallinnustyökalun, jossa voidaan määritellä generoidaanko tilakoneista oliopohjaista koodia, vai perinteinen switch-case hässäkkä. Oliopohjainen on nopeampi, mutta vie hieman enemmän muistia.   JPQ Keskiviikkona, 10. elokuuta, 2005 - klo 15.06:    Frn: C++ tekee isompaa koodia näin kokemus pohjalta. Ja peliä en ole tekemässä ja tehköön jokainen hänelle sopivalla välineellä ohjelmansa eiks je? PS. kun en kaupallista projektia tee niin ei liene hätää lisäksi C++ yksi suurimmista ongelmista on siitä olevat kirjat siis useimmat menevät ylikaalin c on vielä tarpeeksi helppoa eli jotenkin tajuaa sen. onhan oliot yms kivoja mutta mutta mitä niilläkään tekee jos niistä oleva selostus on sekavaa kuin en keksi edes mikä.   Jupp3 Keskiviikkona, 10. elokuuta, 2005 - klo 15.27:    >voidaan määritellä generoidaanko tilakoneista oliopohjaista koodia, vai perinteinen switch-case hässäkkä. Kannattaa tietenkin muistaa, etteivät nuokaan ole ne ainoat vaihtoehdot. C-ratkaisuista mieleen tulee mm. pointteri funktioon.   itix Keskiviikkona, 10. elokuuta, 2005 - klo 18.38:    jon: "riippuen optimointitasosta?" Noh, jos haluaa inlinettää funktioita niin sitten kannattaa laittaa optimointitasoakin korkeammalle (O2 tai O3).   itix Keskiviikkona, 10. elokuuta, 2005 - klo 18.46:    Palle: "Hyvänä esimerkkinä voisi mainita, esim erään SW- mallinnustyökalun, jossa voidaan määritellä generoidaanko tilakoneista oliopohjaista koodia, vai perinteinen switch-case hässäkkä. Oliopohjainen on nopeampi, mutta vie hieman enemmän muistia." Tuo ei niinkään vastaa kysymykseen onko C++ nopeampi kuin C. Sen sijaan jos kysytään kummalla kielellä saa helpommin tehokasta koodia niin sitten... ehkä.   Palle Keskiviikkona, 10. elokuuta, 2005 - klo 18.57:    itix:"Tuo ei niinkään vastaa kysymykseen onko C++ nopeampi kuin C. Sen sijaan jos kysytään kummalla kielellä saa helpommin tehokasta koodia niin sitten... ehkä." Tarkoitus ei toki ollutkaan väittää että C++ on aina ja absoluuttisesti nopeampi, vaan että silläkin saa aikan tehokasta koodia.   JPQ Keskiviikkona, 10. elokuuta, 2005 - klo 20.17:    Palle: tietenkin saa ja ongelmana on tosiaan ehkä eniten kirjallisuus.   Frn Torstaina, 11. elokuuta, 2005 - klo 1.06:    JPQ: Koskimies, Kai: Oliokirja   Tomi Torstaina, 11. elokuuta, 2005 - klo 8.52:    Koodin optimaalisuus lienee kääntäjän ominaisuus. Voisi kuvitella, että uudempi puspuscompiler tuottaa nopeampaa koodia kuin old school pure c-kompilaattori. Ja optimoinnissahan oli tämä 80/20 sääntö: 20% koodista imuttaa 80% ajasta. Sääntö joku putkahtelee siellä täällä hieman eri muodoissa. Veikkaan, että tietojenkäsittelyinstituuteista ympäri maailmaa löytyy runsaasti ns. objektiivisuuteen pyrkyäviä tutkimuksia eri kääntäjien "hyvyydestä" (useita attribuutteja toivottavasti).. Miksi tämä Oliokirja on tässä mainittu?   antime Torstaina, 11. elokuuta, 2005 - klo 9.13:    Kyllä kielelläkin on väliä. Esim. C++:an tiukempi tyyppijärjestelmä tarjoaa kääntäjälle enemmän optimointimahdollisuuksia. Jupp3, funktiopointtereiden kanssa leikkimisen sijasta voisit suoraan siirtyä virtuaalisiin funktioihin, saisit ainakin helpomman syntaksin..   Marq Torstaina, 11. elokuuta, 2005 - klo 10.17:    Tavallisesta ei-oliokoodista C++ -kääntäjä tekee epäilemättä ihan yhtä nopeaa kuin C:kin. Jos kovasti tusataan olio-ominaisuuksien kanssa, niin C-mäinen tapa tehdä asioita voi olla nopeampi, koska dynaamiset sidonnat ym. eivät mappaudu yhtä suoraan konekieleksi. Optimoinnin lisäksi voidaan sitten tietysti keskustella erikseen siitä, onko C:llä tuotettu koodi heikosti uudelleenkäytettävää spagettia tai onko C++:n syntaksi turvonnut ja sekava ;v)   Frn Torstaina, 11. elokuuta, 2005 - klo 10.22:    Tomi: Oliokirjaa ehdottelin JPQ:lle edellisen kommentin kirjallisuudenpuutteeseesn. Ymmärsin niin, että C on jotenkuten hanskassa ja oliot ovat se este C++:n kokeilulle. Jos ohjelmointiopuksista oliot eivät aukea, Koskimiehen Oliokirja voisi auttaa eteenpäin. Siinä on olioasia melko perusteellisesti selvitetty.   Tomi Torstaina, 11. elokuuta, 2005 - klo 14.50:    Joo, mulla on noin 2 tusinaa ohjelmoinnin oppikirjaa, mutta mikään ei mun mielestä selitä Olioita edes sinnepäin. HUOKS Mutta tutustunpa tuohon kun ei ole tuttu teos, danke Frn!   JPQ Torstaina, 11. elokuuta, 2005 - klo 15.10:    No yleis hyödyllinen C++ kirja olisi varmaan hyvä myös ja uskokaa tai älkää luen mielummin englanniksi. PääSyyt(ei siis SyyPäät): käännös virheet ja kielitoimiston keinosuomentama suomi jota en täysin aina ymmärrä.   Jupp3 Torstaina, 11. elokuuta, 2005 - klo 16.07:    antime: >funktiopointtereiden kanssa leikkimisen sijasta voisit suoraan siirtyä virtuaalisiin funktioihin, saisit ainakin helpomman syntaksin.. No sitä vain yritin sanoa, että kahden kielen tehokkuutta ei voi oikein vertailla toteuttamalla sama asia kahdella eri tavalla... funktiopointteri sattui vaan tulemaan mieleen muista mahdollisista ratkaisuista.   Jupp3 Torstaina, 11. elokuuta, 2005 - klo 16.12:    antime: Lisäksi "helpompi syntaksi" jossain tietyssä asiassa ei nyt ole paras mahdollinen peruste koko ohjelmointikielen vaihtamiseen   JPQ Torstaina, 11. elokuuta, 2005 - klo 19.55:    Jupp3: ei olekkaan lisäksi koska musta C syntaksi on helpompi kuin C++ kielen. Mutta Perl koodeja paljonkin sivusta katsoneena siitä ei ota ****kaan selvää ainakin musta tuntuu.