Keskustelu: Ohjelmointikysymykset: C++: Metodin vakioargumentit

Tuli ihan mieleen sellainen triviaalinen kysymys että mikä virka on vakioargumenteilla tyyliin:

int rangeFix(const int pValue, const int pMin, const int pMax)
{
    if (pValue < pMin)
        return pMin;
    else if (pValue > pMax)
        return pMax;
    else
        return pValue;
}

Jos argumentin edessä on const niin sen arvoa ei tietenkään voi muuttaa metodin sisällä, mutta onko sen käyttö edes suositeltavaa jos tietää mitä on tekemässä? En Delphilläkään oikeastaan ikinä kirjoittanut constia minkään argumentin eteen. Säästääkö se muistia, nopeuttaako ohjelmaa, lieventääkö kasvihuoneilmiötä?

const tässä on lähinnä vinkki kääntäjälle, joka voi tehdä parempia optimointeja kun tietää, ettei noita arvoja koskaan muuteta.

Se on hyvä tapa ja siksi suositeltava. Se ei kuitenkaan välttämättä nopeuta ohjelmaa, kun nykykääntäjien ei tarvitse luottaa tuollaisiin vaan ne voivat tavallisenkin muuttujan kanssa tehdä samat optimoinnit, kun toteavat, etteivät ne muutu.

Missä sitten on erityisesti järkeä? Voihan koko ohjelman kirjoittaa yhteen funktioon, jossa hypitään gotolla. Asian tyhmyyttä ei tällöinkään lievennä, vaikka tietäisikin, mitä on tekemässä. Toki kyseessä on aivan toisen mittakaavan tyhmyys. :)

Suurempi merkitys const-määreellä on, kun käytetään esimerkiksi osoittimia tai viittauksia. Tällöinhän kyse on siitä, voiko funktio muuttaa muuttujaa kutsupaikalla, jolloin kyse on jo merkittävästä semanttisesta erosta.

Metabolix kirjoitti:

Se on hyvä tapa ja siksi suositeltava. - -

Missä sitten on erityisesti järkeä? Voihan koko ohjelman kirjoittaa yhteen funktioon, jossa hypitään gotolla. Asian tyhmyyttä ei tällöinkään lievennä, vaikka tietäisikin, mitä on tekemässä. Toki kyseessä on aivan toisen mittakaavan tyhmyys. :)

(Korostus minun, yrityksenä korostaa ensimmäisen ja viimeisten lauseiden välinen lievähkö ristiriita) Tässä kohtaa katkeaa joko minun tai lainauksen ajatus - suositteletko siis tapaa vai et?

Janezki kirjoitti:

Säästääkö se muistia, nopeuttaako ohjelmaa, lieventääkö kasvihuoneilmiötä?

Olisikos tämä sellaista paljon parjattua optimointia ilman pullonkaulaa ;)? No, onneksi ei sentään tee koodista vaikeaselkoisempaa.

(Nykyiset) C-kääntäjät tunnistavat optimoitavat tilanteet varsin hyvin (kun vain optimoinnit ovat päällä), joten tällaisissakin tapauksissa kääntäjä saattaa tiedostaa parametrien muuttumattomuuden jos sillä on merkitystä. Tämä ei toki estä sitä, etteikö halutessaan saisi vaikka.. kokeilla ja mitata :)

eq kirjoitti:

Tässä kohtaa katkeaa joko minun tai lainauksen ajatus - suositteletko siis tapaa vai et?

Viittasin Janezkin viestin kohtaan "onko sen käyttö edes suositeltavaa jos tietää mitä on tekemässä", joka sisältää toisin luettuna väitteen "ei ole suositeltavaa niille, jotka tietävät, mitä ovat tekemässä". Tämä oli tarkoittamani toinen tapaus, jossa siis tehtäisiin tyhmästi (jätettäisiin käyttämättä sanaa) sillä perusteella, että "tietää kyllä itse".

Siis kyllä, suosittelen semanttisia ohjelmointitapoja. Pääsääntöisesti oikeassa paikassa oleva const kannattaa — ainakin sitten parin vuoden kuluttua, kun miettii, mitäs tämä int f(int a, int *b, int **c) tekikään... Muuta hävittävää ei ole kuin ne kuusi tavua kovalevytilaa, jotka const välilyönteineen vie. :)

Lisään vielä oman 5c aiheeseen, vaikka se onkin jo aika hyvin tullut selvitettyä.

Se ei ole pelkästään vinkki kääntäjälle, eikä muistituki itselle. Se on myöskin vinkki muille ohjelmoijille, jotka tulevat koodiasi lukemaan. Niin sanotut input-parametrit on hyvä pitää consteina, jolloin niiden käyttötarkoitus on helpompi ymmärtää. Ja kuten Metabolix sanoikin, on se erityisen tärkeää osoittimien kanssa pelattaessa, jolloin estetään se että koodia myöhemmin muokattaessa (omasta tai jonkun muun toimesta) rikottaisiin jotain tuota pointteria käpistelemällä.

Lisäksi ei se vinkki kääntäjällekään pahaa tee. Tosielämässä kun ei sitä moderneinta ja hienointa kääntäjää ole moneenkaan ympäristöön edes saatavilla.

Triviaaleissa oppikirjaesimerkeissä ja pienissä ohjelmissa asia voi tuntua merkityksettömältä. Mutta pitkissä ja laajoissa projekteissa, joiden ylläpito ja muokkaus kestää ja projektissa on muitakin henkilöitä, säästytään potentiaalisesti monelta salakavalaltakin ongelmalta.

Torgo kirjoitti:

Se ei ole pelkästään vinkki kääntäjälle, eikä muistituki itselle. Se on myöskin vinkki muille ohjelmoijille, jotka tulevat koodiasi lukemaan. — —

Triviaaleissa oppikirjaesimerkeissä ja pienissä ohjelmissa asia voi tuntua merkityksettömältä. Mutta pitkissä ja laajoissa projekteissa, joiden ylläpito ja muokkaus kestää ja projektissa on muitakin henkilöitä, säästytään potentiaalisesti monelta salakavalaltakin ongelmalta.

Säästyttäisiin. :) Itse ohjelmoin töissä PHP:llä, ja kuinka usein toivonkaan, että olisi vahva tyypitys ja sen kautta käännöksenaikainen tyyppitarkistus, kunnollinen const ja funktioiden ylikuormitus sekä paljon muita C++:n ominaisuuksia, jotka varsinkin moni aloittelija kokee turhiksi tai jopa haitallisiksi. Toisaalta joissain tilanteissa samaiset seikat tuntuvat C++:n kanssa rajoitteilta, eli asia ei ole mustavalkoinen.

Kannattaa pitää mielessä, että yleensä mikään toiminto ei ole turha; joissain kielissä asioita on ja joissain ei, ja niiden merkityksen ymmärtää paremmin usein vasta, kun on tehnyt jotain isompaa kielellä, josta ne puuttuvat, tai edes ihmetellyt C++-koodia, jossa niitä on käytetty aivan väärin. En toki väitä, että jokainen tarvitsisi jokaista ominaisuutta, mutta useimpiin kieliin niitä ei kuitenkaan ohjelmoida huvin vuoksi.

Olipa nyt pakko vuodattaa julkisestikin työvälineen kurjuudesta. ;)

Ja vielä viimeinen veto constin puolesta.

Nykyään kovin harvoin (ainakin isoissa ohjelmistotaloissa) yksi tekijä pitää oman koodinsa ylläpidossa yksinään. Ts. vaikka sinä kirjoittaisit sen ensimmäisen version funktiosta, voi olla, että joku muu joutuu sitä muokkaamaan. Tässävaiheessa uusi muokkaaja saattaa (helposti?) tehdä virheen, muuttamalla esim. jotain arvoa joka välittyy funktiosta ulos (ja jota ei saa muuttaa). Jos muuttujaan on liimattu const lappu, kääntäjä ärähtää ja bugi jää kiinni jo ennen pakettiin pääsyä..