Olen vasta-alkaja ohjelmoinnissa ja haluaisin oppia jonkin yleispätevän ohjelmointikielen (jolla voisi tehdä pelejä, hyötysoftaa jne.). C:een sukuiset kielet tuntuvat kiinnostavilta, mutta mieltäni askarruttaa kysymys "C vai C++?". Haluaisinkin nyt mahdollisimman perusteltuja vastauksia seuraaviin kysymyksiin:
Miten C++ eroaa C:stä? Millaisia etuja/haittoja on C++:an käytöstä verrattuna C:hen? Käytättekö itse jompakumpaa, kumpaakin vai ettekö kenties kumpaakaan? Vai suositteletteko jotain ihan toista kieltä?
Kiitos jo etukäteen :)
C++
sisältää aika paljon c-kielen ominaisuuksia joten on taaksepäin yhteensopiva. Ovat keskenään kuitenkin hyvin lähellä niin opettelee toisen niin osaa jo toisestakin lähes kaiken.
kts Zmyrgel
Onkos C++ sitten yleispätevä ohjelmointikieleksi? Ja jos osaan C++:aa onko siitä hyötyä muiden ohjelmointikielten oppimisessa? Ja jos on niin minkä kielien?
No tuota, ainakin PHP:n ja Javan opetteluun auttaa. PHP taitaa olla ihan C:tä. Javakin taitaa olla johdettu C:stä. Ylipäätään olio-pohjaisiin kieliin mitä niitä nyt onkaan.
Itsellä ei ole vielä juurikaan laajaa kokemusta ohjelmoinnista, käyn itse c++ kurssia par'aikaa.
Itse näen asiat näin...
Pelit yms. raskaat projektit: C / C++
Windows sovellukset: Visual Basic
Internet: ASP tai PHP
Kannattaa tutustua Päivi Hietasen C++ ja olio-ohjelmointi -kirjaan. Erittäin kätevä kirja c++ opetteluun.
C++ on erittäin yleispätevä ja hyvä valinta - toimii (ainakin lähes) kaikilla alustoilla sulautettuja järjestelmiä myöten ja sillä voi tehdä lähes mitä vain. Kielen kuin kielen opettelu auttaa jo toisen opettelussa, ja C++-taustasta on suurta etua siirryttäessa muihin kieliin - oikeastaan mihin tahansa.
Kiitos.
Mitäs mieltä olette Bjarne Stroustrupin kirjasta "C++-ohjelmointi"?
Jos meinaat alotella sillä ohjelmoinnin niin älä koske siihen. Itsellä oli tuo ja sain tehtyä Hello Worldin ja siihen jäi ohjelmointitaito tuon opuksen kanssa. Seuraavassa esimerkissä taisi olla vektoreita yms. settiä kun äijä haluaa käyttää "oikean elämän esimerkkejä" joista ei tajua mitään.
C++ sisältää kaikki monimutkaiset ominaisuudet mitä koskaan on keksitty, joten sen opeteltua kunnolla kaikki muut kielet tuntuu liian helpoilta ja yksinkertaisilta. Eli itse en ole koskaan jaksanut opiskella läheskään kaikkea kunnolla. INSEDE C++ KÄSIKIRJA on suositeltava opiskelu materiaaliksi.
Vaihtoehtoiseksi kieleksi voisin heittää C#:n, joka uusimpia kieliä, josta on tehty tuottoisa ohjelmoijan kannalta ja fiksu . Muistuttaa C++ valtavasti, mutta eroaa perinteisestä C++:sta siinä, että sillä on tarkoitus tehdä .NET ohjelmia, jotka on alustariippumattomia, kunhan käytetyt luokat on olemassa käytettävälle käyttikselle. No joo ne OLE objectit ei toimi missään muualla kuin windowsissa toistaiseksi.
Zmyrgel, onkos tämä "C++-ohjelmointi" sitten huono kirja C++:an opetteluun? Kun kuiteskin ajattelin, että kielen kehittäneen jannun kirjoittama opus olisi juuri paras valinta tähän tarkoitukseen. Voin tietenkin olla väärässäkin. :)
Aika masokistista on tuolla Bjarnen opuksella opetella C++:ssaa. Kannattaa katella tuo Päivi Hietasen kirja, löytyy esim Huuto.Netistä halvalla.
Esimerkkinä Hietasen kirjassa on koodiesimerkit käyty rivi kerrallaan läpi mitä siinä tehdää kun taas Bjarnen opuksessa mainitaan vain mitä koodi kokonaisuudessaan tekee ja saa ite pähkäillä mitä siinä tapahtuu. Itse pysyn Bjarnen opuksessa mukana siihen about sivulle 100 saakka. Sitten alkaa mennä hieman vaikeeksi, ja kirjassa kuitenkin on 900 sivua :(
Itse alkaa tässä 3kk C++ opiskelleena hieman aukeamaan tuo kirja. Ihan kätevä sekin on kun osaa jo muuten ohjelmoida C++:lla.
Itse en koskaan hommannut kirjaa kun c++:aa opettelin vaan käytin tätäopusta.
En tosin osaa sanoa onko hyvä jos ei ollenkaan kokemusta ohjelmoinnista mutta mulle opetti aika hyvin.
Entäs kun minulla olisi tuo Bjarnen teos tossa vieressä ja tuo Päivi Hietasen kirja maksaa 55e? Onko tuo kannattava ostos vai kannattaako vaan tyytyä tähän Bjarnen kirjaan? Huuto.netistä en kirjaa löytänyt (ainakaan siellä ei semmoista ole juuri nyt). Ja Jäynis, tuosta ei kyllä kovin paljoa opi. Onhan se ihan hyvä opus, mutta jättää paljon asiaa käsittelemättä.
Kannattaa varmaan ainakin alustavasti tutustua tuohon Bjarnen teoksees(en itse ole edes nähnyt kantta). Jos se tuntuu huonolta niin osta/lainaa jokin toinen.
C ja C++ ovat perin erilaisia kieliä, olkoonkin että C++:lla on mahdollista kirjoittaa C-tyylistä koodia samanlaisella syntaksilla. Ratkaiseva ero on, että C++ on ensisijaisesti olio-ohjelmointikieli, mikä tarkoittaa että ohjelmien suunnittelu ja rakenne poikkeavat merkittävästi proseduraalisten kielten (mm. C, Pascal) vastaavista.
C++ saattaa olla vaikeampi kieli aloittelijalle, mutta toisaalta sen hallitseminen antaa hyvät eväät esimerkiksi Javan opiskeluun. Samoin C:n ymmärtäminen C++-pohjalta on varmasti paljon helpompaa kuin päinvastoin. "Kaikkia monimutkaisia ominaisuuksia mitä koskaan on keksitty", kuten joku täällä väitti, C++ ei tietenkään sisällä, otetaan vaikka esimerkiksi lambda ja predikaattilogiikan kalkyyli. Ohjelmoijan olisikin hyvä laajentaa näkemystään tutustumalla useamman ohjelmointiparadigman kieliin.
Itse äänestäisin C++:aa, mutta aloittelijan käytännön tarpeisiin C ja C++ riittävät varmasti kumpikin hyvin. Taitojen kasvaessa osaa valita paremmin, mikä itselle sopii.
CyberianRat kirjoitti:
"Kaikkia monimutkaisia ominaisuuksia mitä koskaan on keksitty", kuten joku täällä väitti, C++ ei tietenkään sisällä, otetaan vaikka esimerkiksi lambda ja predikaattilogiikan kalkyyli.
Tosin lisäkirjastoilla ja etenkin preprosessorin ja templatejen avulla saa käytännössä kaiken implementoitua ainakin jollain tapaa, mukaan lukien kaksi antamaasi esimerkkiä. Tietenkään tällainen ei ole verrattavissa kieleen sisäänrakennettuihin ominaisuuksiin.
Alkuperäiseen kysymykseen onkin jo tullut melkoisesti vastauksia, mutta lisään oman korteni vielä kekoon.
Kannattaa tutustua C++ FAQ Liteen, jossa on paljon hyödyllistä asiaa uudelle ja vanhalle C++-ohjelmoijalle. Tässä tapauksessa erityisesti kohdista 6 Big Picture Issues ja 28 Learning OO/C++ voisi olla apua.
Stroustrupin kirja on lähdeteos, ei oppikirja.
Buu C on aito oikea.
uffis, onkos tällä sitten periaatteessa väliä, että onko se lähdeteos vai oppikirja?
Sehän sisällöllisesti on aivan eri asia.
Tässä tapauksessa käyttäisin ennemmin lähdeteosta kuin oppikirjaa. Omansa kullekin.
Oppikirja on aloittelijalle, lähdekirja on gurulle :D
Suosittelen C++:saa lämpimästi. Olen käyttänyt Hassun hauskaa C++ opasta ja Jesse Libertyn opeta itsellesi C++. Etuja C++:sasta on yleissyntaksin oppiminen ja muuttujien tyypittäminen. Itsekin tuossa pitkästä aikaa aloin PHP+MySQL yhdistelmällä koodailemaan sivustonylläpitojärjestelmää ja kyllä oli niin helppoa, kun oli pähkäillyt Datatähtitehtävien kanssa, koska se oli kasvattanut ajatteluani erittäin paljon.
Suosittelen!
Mitäs mieltä olette tästä c++-oppaasta?
http://www.nic.funet.fi/c opas/ on mielestäni parempi, koska on suomenkielinen, ja helppolukuinen
squid kirjoitti:
http://www.nic.funet.fi/c opas/ on mielestäni parempi, koska on suomenkielinen, ja helppolukuinen
Tosin jotkin seikat tuossa ovat vanhentuneet. Esim. main-funktion pitää ehdottomasti palauttaa int eikä void.
C vai C++? Hyvä perusta ohjelmointitaidolle ja sitä myötä rutiinin kehittymiselle on soveltaa matematiikkaa ja logiikkaa algoritmeiksi. Tehokas koodi (jota sulautettujen mööpeleitten kohdalla arvostetaan) on läpivaluvaa raakaa bittiaritmetiikkaa ja algebraa. Tee / harrasta mahdollisimman paljon A4:n algoritmeja. Mitä yhdellä A4:lla voi tehdä? Kuta enemmän sillä pystyy tekemään, sitä parempi ja rutinoituneempi koodaaja on. Kaikki suuremmatkin projektit jakautuvat lopulta A4:n arkkeihin. C, Pascal, Basic, assembler, C++, ..., kaikilla kielillä voi suunnileen tehdä saman pa...n yhtä tiiviisti ja hienosti.
Vinkiksi vaan että C:tä ei kannata lukea vaan heti alkaa C++:lla. Jotkut sanovat että on jopa huono idea aloittaa C:stä ja sitten jatkaa C++:aan jos on aikomuksena oppia C++:a. Syitä mm että C:n rajoitteisuus voi jotenkin häiritä ajateluasi kun jatkat C++:lla ja aikaakin kuluu kun opettelee C:tä. Ja että C ja C++ erot ovat pienet niin ei minun mielestä ole totta. Kun etenet C++:ssa niin eroista tulee entistä suuremmat. Sanotaampa oliopohjainen ohjelmointi joka ei yhtään tue C:tä. Näillä perusteilla suositellen lämpimästi C++:a.
Olen nyt paljon erimieltä Wiseguy:n kanssa. Ei C++, sen enempää kuin muutkaan ns. aidot oliopohjaiset kielet ole oikotie oppia tekemään ja hallitsemaan algoritmeja jotenkin paremmin. Päinvastoin, oliokielet pyrkivät tarjoamaan mahdollisimman paljon apupyöriä, ts. valmiita oliokirjastoja asioiden hallitsemiseen. Entä sitten, kun joutuu tekemään oman olion, jonka privaatti-osioon pitää osata vääntää äärimmäisen tehokas moottori pyörittämään sitä olion public-osan käyttöliittymää? Silloin on tehtävä omia tehokkaita C (mahdollisesti myös Assembler) algoritmeja. Yksistään C++ ei kyllä kovin pitkälle kanna ohjelmointi-opinnoissa. Olioissa pyritään helppoihin käyttöliittymiin (public), mutta itse olion metodeissa, joissa rakaa vääntöä tarvitaan, ei ole juuri mitään tekemistä C++:n kanssa. Ajatellaanpa esimerkiksi jotain sellaista ajanvietepeliä, jossa tietokoneesta otetaan kaikki mahdollinen irti. Kyllä sielä ruohonjuuritasolla moottoria pyöritetään raa'asti C:llä ja Assemblerilla. Tietenkin sitten ylemmällä tasolla hyödynnetään oliomallinnuksen mahdollistamaa mahdollisuutta hallita kompleksisia syy-seurauksia kurinalaisemmin.
Zmyrgel kirjoitti:
No tuota, ainakin PHP:n ja Javan opetteluun auttaa. PHP taitaa olla ihan C:tä. Javakin taitaa olla johdettu C:stä.
no huh huh...
Mää aloitin C:llä ihan tyytyväisenä. Jossain vaiheessa tein C++:lla yhden pelin ja päätin ihan suosiolla pysyä C:ssä. :) C tuntuu paljon simppelimmältä ainakin vielä tässä vaiheessa.
Mää aloitin ihan tyytyväisenä Pascalilla, ja hyvin sujuu C ja myös C++ tiettyyn rajaan asti, ilman sen suurempaa opettelua. Siltä kannalta siis aivan sama.
Aika paljon tuo on kiinni siitä, mitä haluaa tehdä. Vaikka C++ on varmasti hieno kieli kaikkine ominaisuuksineen, niin täytyy myöntää tosiasiat: jotkin asiat toimivat C-tyyliin tehtynä paljon nopeammin, ja jos kyseessä on nopeutta vaativa ohjelma, sillä on tosiaan merkitystä. Jos taas on tarkoitus saada paljon aikaan nopeasti ja tehdä helppokäyttöisiä ja laajennettavia ohjelmia tai ohjelman osia, C++ on yleisesti ottaen helpompi.
Tuo "Big Picture Issues" on oikeasti asiaa. Suosittelen erityisesti kohtaa 6.5. (http://new-brunswick.net/workshop/c++/faq/big-picture.html#faq-6.5)
Mää aloitin toimivalla 64:n Basicillä, jonka löysin peritörojujen seasta. Siinä sitä olikin ensin paljon opittavaa. Jossain vaiheessa kuvioon astui mukaan joku konekielimonitoriksi kutsuttu vekotin. Ensimmäisien assembler-luuppien teho heitti ällikällä. Miten oli mahdollista, että Basicillä luuppi kesti tunnin, mutta sama asia assemblerilla muutaman millisekunnin? Pikkuhiljaa rupesi sisäistämään mitä tarkoitti olla tekemisissä koneen oman luonnollisen kielen kaa. Sen jälkeen uusien prossoreiden eri kieliä on ollut helppo omaksua, kun vertailupohjana on 64:n legendaarinen akku, x- ja y-rekisterit, jne. Sitten lausekielistä ensimmäisenä Pascal oli kohtalaisen helppo oppia. TurboPascalissa muuten on vielä tänäpäivänäkin paras tuki lausekielen ja assemblerin mielivaltaiselle sekoittamiselle. C/C++ puutteena on, ettei niillä voi samaan lähteeseen tehdä aitoa assembler-funktiota alusta loppuun (TurboPascalissa funktion joku:assembler). Kait syynä on sitten ylenpalttinen huoli yhteensopivuudesta, koska ainakin ANSI C/C++:lla tehryt ohjelmat pitäisi toimia suunnilleen heittämällä missä tahansa ympäristössä, jossa vain on ANSI-kääntäjä. Pascalista C:hen on sama asia kuin muuttaisi Oulusta Helsinkiin - vähän vain puhuttu murre muuttuu. C++ on ihan jees käyttää ylemmän tason kontrolleissa, mutta tuskin on paras opettamaan, mitä kaikkea matematiikka, logiikka, algoritmit ja ohjelmointi sisäänsä kietovat.
ihe alotin ekana ohjelmointikielenä ikinä n. 4kk sitte c++:ssan, ja on ollu aika vaikeeta opetella. en ikinä oo kokeillukkaa c:tä, mutta joidenkin mielestä se on 'helpompi'. Mutta kai se kannattais alottaa heti ns."täysillä" sillä c++ kielellä, koska eikös siinä oo kaikki samat ku c:ssä ja vielä paljon ekstraa. elikkäs jos valitsee sen c++:ssan nii siinä sit oppii kaks kieltä (vaikkakin samanlaista) yhellä iskulla ;D
Hmh.... no eihän se nyt aivan näinkään ole. C:ssä ei ole olioita(kuten esimerkiksi tulostukseen käytetty std::cout), ja on muiltakin osin aika erilainen. Mielestäni C++ on selkeämpää, kuin C
Kyllä C sisältää melkein yhtä rankan strukturoinnin, kuin C++:kin. C++ itse asiassa konvertoi lähdekoodin ensin C:ksi, ja kutsuu vasta sitten C kääntäjää. Siten C++ kääntäjää ei ole olemassa sanan varsinaisessa merkityksessä. (Vain aidoissa oliokielissä voi olla oliokääntäjä. C++ on hybridikieli.)
Sen vuoksi C++:ssa olion voi määritellä C-perinteisesti myös struktuuriksi:
struct olio { public: olio(void); ~olio(void); int doSomething(void *dat); private: char param[256]; };
Toisaalta C++:kin on alkuajoistaan ottanut suuria harppauksia varsinkin stantardisoinnin suhteen.
C++ tyylinen koodaaminen on C:llä arkipäivää. Tietorakenteet määritellään hyvin vastaamaan tavoitetta, ja toisaalta palvelemaan kompaktia koodia, ja päinvastoin. Tietorakenteiden datan käsittelyyn kirjoitetaan ihan samanlaisia metodeja kuin C++:kin. Ehkä pienin ja näkyvin ero on se, että C:ssä tietyn struktuuri alias olio välitetään halutulle metodille tehokkaasti pointterilla.
Ja kun mennään syvemmälle C++ rakenteisiin, esimerkiksi C:llä tehdään C++ vastaavia virtuaalifunktioita, joiden ajonopeus on vähintään 1000 kertainen verrattuna C++:n tekniikkaan plarata funktiotaulukoitaan kiireettömästi.
Tämä keskustelunaihe on mielenkiintoinen. Mielipiteitä ja perusteluita on kohtalaisen tasaisesti C:n ja C++:n puolesta. Ehkä C kuitenkin kannattaa opetella. Ei se ole jatkossa esteenä ymmärtää oliokieliä, koska jos C++ tyylistä koodia tekee jo C:llä, pitemmässä juoksussa C++ pystyy käyttämään ja hallitsemaan tehokkaammin.
Tuollainen jäsenmäärittely ei silti mene C-standardeista läpi, ei sitten kirveelläkään. Rakenteet eivät sisällä jäsenfunktioita.
// C++ ja jäsenfunktio Objekti.Funktio(Syote); /* C-standardin tapa */ Funktio(&Objekti, Syote);
Hyvä tarkennus, ja hyvä määrittely. Esimerkkini oli huono, koska se on tosiaan kaukana C:n standarteista. Esimerkkini saattaa toimia hyvällä onnella vain joissakin C++ kääntäjissä.
Mutta juuri tuota määrittelyä hain C:n ja C++:n eroksi. Jos Funktio on virtuaalinen, sitten on määritelty tarpeellisen kokoinen taulukko Funktiota vastaaville virtuaali-metodeille:
int (*Funktio[16])(Objekti*, int); int SuoritaFunktio(char *ehdot, ...) { ... } void koodia(Objekti *x) { ... Funktio[SuoritaFunktio("%o%d", x, 7)](x, f); ... }
Voisihan sitä aloittaa C:llä C++:n sijaan, mutta missään nimessä ei kannata varta vasten hankkia C-ohjelmointiopasta, vaan mieluummin C++-oppaan. Tuo Hietasen kirjakin alkaa aika C-tyyppisillä jutuilla, vaikka syntaksi on puhdas C++. Sitten siirrytään enemmän C++:lle tyypillisiin juttuihin.
Niin, ja kääntäjänä pitää tietenkin olla C++-kääntäjä ja lähdetiedostot .cpp eikä .c.
Hmm, mielestäni on väärin väittää, että jos osaa c++, osaa myös c:tä ja vice versa. Ihan triviaalitkin asiat, kuten merkkijonojen käsittely tai tiedoston luku, tehdään eri tavoilla. Tai no, voihan c++:lla tehdä c-tavoin, mutta siinä taas ei ole mitään järkeä, kun STL tarjoa niin paljon helppokäyttöisemmät keinot. Ja kuten joku jo totesi, muutenkin ohjelmien suunittelussa (ohjelmoinnissa!) on suuria eroja.
JoinTuanJanohon viitaten:
Ja kun syvällisemmin miettii miten c++:ssa toimii templatet ja oliot, niin koodinhan ei pitäisi olla yhtään hitaampi ku C:n. Kääntäjä on vaan monimutkaisempi. Oliot ja kaikki muu "roska" on tehty ihmisen elämän helpottamista varten. Esim olioiden public osia tarjoa sen käyttöliittymän. Privatessa on taas piilotettua tietoa, jonka ei tarvi näkyä ulospäin => vaikeampi tehdä virheitä. C:ssä ei ole mahdollista "piilotaa" mitään.
Kun taas ne "raasti pyöritettävät jutut": Ei ne templatet yhtään hitaampia ole kuin C:n funktiot, niitä ei tarvi vaan miljoonaa: säästää aikaa.
Ja kun tehdään oikeesti aikakriitistä juttua niin se asmi on kai ainoa vaihtoehto. Tosin nykykääntäjät osaa optimoida paljon paremmin kuin aloitteleva asmisti. Ja kun assembly on alustariippuvainen, niin se tuo omia hankaluuksia. UNIX maailmassa muuten näkee aika vähän assemblya (on tosin niitäkin hulluja), mutta silti kaikki mitä pyörii, pyörii aika hyvällä vauhdilla.
btw: ei se prosessori C:tä osaa. Assemblya vaan. Assembler on kääntäjä. </pilknus>
offtopic: ainakin jossain vaiheessa borlandin kääntäjät tekivät ensin C/C++:sta asmi pätkiä, joita käänettiin TASM:lla.
En oikein osaa sanoa kummasta olisi hyvä aloittaa. Itse aloitin C:llä, pitkälti ilman kirjoja. Halusin jotakin matalatasoista juttua. Nyt kun tylstyi tekemään niitä niin c++ on aika kiva => jos jotain pidempää tulee seuraavaksi tehtyä niin kai teen C++:llä, tai ei sitä ikinä tiedä.
Sen jälkein kun on koodaillut vähän aikaa, niin oppii lukemaan käytännössä mitä tahansa lausekieltä => jos löytää jotain kivaa niin voi sitä opetella kirjottamaankin :) (IOCCC tapasia juttuja ei lasketa)
Mitä noista kirjoista. Itsellä on vain kaksi ohjelmointiin liittyvää kirjaa:
B. W. Kerninghan, D. M. Ritchie: The C programming language, 2nd edition, Prentice Hall, 1988
Kirjahan on vähän vanhentunut kun on tullut C89/C90 ja C99, mutta on siinä silti hyviä juttuja. ATK-opettajalla on joku viimeaikoina tehty suomennos, kun siinä on otettu C89/C90 juttuja. Se oli ihan kiva kirja, mutta en muista minkä niminen / kenen kustantama.
ja toinen:
B. Stroustrup: The C++ Programming Language, Special Edition, Addison-Wesley, 2000
Tämä kirja on kieltämättä vähän vaikea. En suosittelisi ensimmäiseksi kirjaksi. Jos C++:tä alkoo harrastaa vähän enemmänkin, tämä on pakkohankinta. Stroustrup käy kaikki kielen ominaisuuden läpi. Se ei opeta ohjelmoimaan vaan sen kielen. Itse tykkäsin, tosin en lukenut kokonaan. Aina kun avaa niin löytää jotakin uutta.
offtopic: aika tylsät kirjojen nimet kieltämättä.
offtopic: php:ssä on kieltämättä C:mäinen syntaksi, mutta on siinä selvästi JavaScriptista otettuja juttuja.
Javaa en ole koodannut, mut mitä olen kuullut: Java on oo-kieli, mutta C++ tarjoa enemmän ominaisuuksia siihen.
phadej puhui vähän, mutta asiaa. Kuitenkin yksi asia jäi kaivelemaan, kun viittasit kannanotossasi esimerkiksi STL-kirjastofunktioihin. Toki ne templaatit alias mallit ovat jossain määrin helpompi käyttää, mutta käytännön työssä ne ovat suoraan sieltä, minne Aurinko harvemmin pääsee paistelemaan.
Esimerkiksi joku Builderin VCL-kirjasto. Joo-o, niitä on hiki hatussa väännetty ja koodattu koodaamisen ilosta, mutta vastuu käyttämisestä on yksinomaan käyttäjällä. Jos bugittaa, valmistajan on helppo luovia vastuusta toteamalla, että mitäs käytät VCL-kirjastoa, jos ei kelpaa, niin te oma kirjasto! Juuri niin, jotta asiat saa toimimaan ja viimeisen päälle oman laatuvaatimuksen tasolle, niin ne todella pitää koodata kunnolla alusta loppuun.
Mutta tässä on nyt tietenkin kysymys siitä, mihin koodeilla ja sovelluksilla tähdätään. Onko kysymyksessä jokin sulautettu vekotin, jolla on tarkoitus pitää käynnissä esimerkiksi ihmistä elossa pitävää järjestelmää. Hyvänä esimerkkinä voisi olla sydämentahdistin. On päivän selvää, että sellaisen laitteen/koodin laatutaso on tasan 100 prosenttia. Virheisiin ja vielä pahemmin logiikkavirheisiin ei kerta kaikkiaan ole varaa!
Mutta jos ohjelman tavoitteena on ajanviete, peli tai jokin kännykän lisäsovellus, niin eihän sillä nyt niin kauhean väliä ole, miten vakaasti se sovellus missäkin tilanteessa pörrää. Itse asiassa sellaisissa tarpeissa tavoitteena ei edes ole varmatoiminen koodi.
Se, että ohjelmoinnin hallitsee niin hyvin, että tukalassa tilanteessa pystyy myös itse tekemään vastaavia STL-, VCL-, yms. ajankohtaisesti tarvittavia koodikokoelmia, yksiköitä, kirjastoja, se on kuitenkin parempi se, kuin vain luottaa sokeasti joidenkin heinähattujen väsäämiin valmiskirjastoihin. (Tässä yhteydessä muuten tarkoitan heinähatuilla sellaisia keskivertoa kokeneempia koodaajia.)
Sitä pitää käyttää, mitä osaa, mikä sattuu olemaan käsien ulottuvilla ja millä saa homman hoidettua haluamallaan tavalla.
Ja paljon vähemmän virheitä minä ainakin saan aikaan VCL:llä kuin jos itse säädän WinAPI:lla nappuloita ja listboxeja. Toisaalta, kun nyt enimmäkseen tulee tehtyä OpenGL:llä tai muulla vastaavalla kuitenkin, niin ei tarvitse WinAPI:lla kuin luoda ikkuna ja käsitellä näppäimistön ja hiiren syötteet, kun käytännössä kaikki komponentit ja ohjelman sisäinen viestiliikenne tulee itse rakennettua (toisinaan STL:n avulla, toisinaan ilman).
Tämä keskustelu alkaa kyllä luisua jo aika kauas metsikköön :)
Mikset aloittaisi ohjelmoijan uraasi Javalla? Java on nykyaikainen, todellinen oliokieli jossa asioita pystyy tekemään melko helposti. Esimerkiksi graafisten härpäkkeiden vääntäminen javalla on hauskaa ja mukavaa toisin kuin C++:lla. Itselle opetetaan opiskelupaikassani ohjelmoinnin peruskursseilla pelkästään Javaa, mutta vaativimmilla kursseilla vaaditaan C++-taitoja.
Mutta vastaus kysymykseesi: C++
EDIT: Valehtelin hiukan :/
Juuh, kun tarkemmin aattelee, niin on ytimekäs kiteyty: "Sitä pitää käyttää, mitä osaa, ja mikä on käsien ulottuvilla". Näinhän se on loppujen lopuksi ollut meidän jokaisen kohdalla. Yksi on aloittanut Fortranilla, toinen Pascalilla, kolmas Lispillä, neljäs Comalilla, viides C:llä, kuudes C++:lla. Lopputulos on jokaisella sama, tavoitteet ja niiden osia on saavutettu hitaasti, mutta varmasti. Tuskin on olemassa sitä yhtä oikeaa ja maailman parasta tapaa harrastaa tai tehdä työtä ohjelmoinnin parissa. Jokainen tietenkin yrittää vetää kotia päin, koska oma tuttu ja turvallinen tapa tuntuu jokaisesta melkein maailman parmailta. Hyvä niin. Tästä keskustelusta jäi ainakin itselleni paljon pohdittavaa ja kokonaan uusia näkökantoja.
JoinTuanJanohon kirjoitti:
Kuitenkin yksi asia jäi kaivelemaan, kun viittasit kannanotossasi esimerkiksi STL-kirjastofunktioihin. Toki ne templaatit alias mallit ovat jossain määrin helpompi käyttää, mutta käytännön työssä ne ovat suoraan sieltä, minne Aurinko harvemmin pääsee paistelemaan
Kuinkas tuo nyt on perusteltavissa? Minä oon aina luullut että ne STL-mallit on nimenomaan siunaukseksi käytännön työlle C++:n kanssa. Toki onhan noita sydämentahdistinsoftia yms. jotka vaatii paljon tarkempaa verifiointia kuin STL, mutta niiden kanssa saatkin unohtaa sitten likipitäen kaikki muutkin kirjastot. Väite että "STL on käytännön työssä perseestä" ei oikein kanna noilla argumenteilla.
"Perseestä" on liian rankka sanamuoto. Kysymys on kuitenkin siitä, että kääntäjän lisenssiehdoissa jokainen pistää törkyn kohtaan <hyväksyn>, jonka jälkeen kääntäjän valmistaja ei ota vastuuta mahdollisista virheistä, johtuivatpa ne sitten hw:stä, STL:stä, tai jostain muusta inhimmilisen lenkin pettämisestä.
Silloin, kun ihmiset tekevät, inhimilliset virheet ovat alati läsnä. Mitä oikein hait STL:n jatkolla? Omasta mielstä korjasin viestiäni niin, että se nimenomaan erotteli, että valmiskirjastojen käyttön mahdollisuus riippuu sovelluksen kriitisyydestä.
Esimerkiksi Jas-hävittäjässä ei ole lainkaan ohjaussauvaa, vaan konetta lentää tietokone! Ei kuitenkaan ihan STL:llä tehty algoritmi, vaan neljä toisistaan riippumatonta tietokonetta, joissa on neljän eri valmistajan toisistaan riippumattomat softat koneen ohjaamiseen. Jos yksi bugittaa, todennäköisesti ne kolme muuta sovellusta antavat kuitenkin siinä tilanteessa kohtalaisesti samaa ohjausinformaatiota, jolloin hävittäjä luottaa niiden kolmen antamaan tulokseen, sen sijaan että kääntäisi nokkansa alas sen yhden koneen ohjeen mukaan, että nyt pitää ruveta syöksymään.
Riitääkö tästä perusteluja? Toivottavasti, mutta jatkan keskustelua mielelläni, jos asiayhteys STL:ään ei vielä tästä selkiytynyt.
JoinTuanJanohon: samalla periattella voi pelätä libc:n käyttämistä. Ja muita valmiita kirjastoja. Veikkaisin vaan, että jos rupeaisit itse tekemään niitä, niin sinun tuotokset bugittaisivat vähintään yhtä paljon. Ja olisivat vielä hitaampiakin. Nämä peruskirjastot, kuten libc ja STL on niin vanhoja ja testattuja, että tuskin ohjelma alkaa niiden takia bugittamaan.
phadej kirjoitti:
JoinTuanJanohon: samalla periattella voi pelätä libc:n käyttämistä. Ja muita valmiita kirjastoja. Veikkaisin vaan, että jos rupeaisit itse tekemään niitä, niin sinun tuotokset bugittaisivat vähintään yhtä paljon. Ja olisivat vielä hitaampiakin. Ja niiden tekemiseen menisi aikaa. Nämä peruskirjastot, kuten libc ja STL on niin vanhoja ja testattuja, että tuskin ohjelma alkaa niiden takia bugittamaan.
:-) Mutta maailma on kovin pieni. En edes viitsi ruveta kommentoimaan kovin ahkerasti argumenttiasi. Minulla nyt tuskin on intressejä ruveta koodaamaan kaikkia kirjastoja ja libejä uudestaan, paitsi niitä juttuja, mitä tarvitsen, ja minkä mahdollinen valmiskirjasto ei ole syystä tai toisesta riittävästi wörki. Jos phadej on sitä mieltä, mitä mieltä olet, olet sitten sitä mieltä. Voi olla, että kirjoittaisin hitaampaa koodia, kuten mainitsit :-) Sekin on mahdollista, että kaiken lisäksi kirjoittamani koodi bugittaisi vielä todella pahasti :-)
Tässä onkin tullut aika rankasti asiasta (joku voisi sanoa, että jopa sen vierestäkin :D). JoinTuanJanohon sanoi aika osuvasti, että eri ihmiset koodaavat eri kielillä ja sillä siisti. Tämä olikin mielestäni aika hyvin sanottu. Jokainen kooda millä koodaa.
m00s3s kirjoitti:
Tässä onkin tullut aika rankasti asiasta (joku voisi sanoa, että jopa sen vierestäkin :D). JoinTuanJanohon sanoi aika osuvasti, että eri ihmiset koodaavat eri kielillä ja sillä siisti. Tämä olikin mielestäni aika hyvin sanottu. Jokainen kooda millä koodaa.
Mitä?! Ei tuollaista avomielisyyttä ja suvaitsevaisuutta sallita, kun kiistellään siitä mikä ohjelmointikieli/editori/maksalaatikko jne. on paras.
pukki kirjoitti:
m00s3s kirjoitti:
Tässä onkin tullut aika rankasti asiasta (joku voisi sanoa, että jopa sen vierestäkin :D). JoinTuanJanohon sanoi aika osuvasti, että eri ihmiset koodaavat eri kielillä ja sillä siisti. Tämä olikin mielestäni aika hyvin sanottu. Jokainen kooda millä koodaa.
Mitä?! Ei tuollaista avomielisyyttä ja suvaitsevaisuutta sallita, kun kiistellään siitä mikä ohjelmointikieli/editori/maksalaatikko jne. on paras.
Suvaitsevaisuutta ja avomielisyyttä voi soveltaa moniin asioihin ja olen sitä mieltä, ettei niistä luultavasti tässäkään ole haittaa...
Aihe on jo aika vanha, joten et voi enää vastata siihen.