Muuttujien alustus?

Ahaa, no kiitos vinkistä, minäpä lopetan sitten.

Katkeruus ei kannata, paitsi että elämä ja siten kärsimykset lyhenevät

KUOLEMA UKRAINALLE
KUOLEMA ZELENSKYILLE

Peruϟϟuomalais ♿ k_o_l _l_ i_m_a_a_t_t_o_r_i !

Joka ilta kollirunkkari kumartaa purran kuvaa! ja heittää Ukrainan natsitervehdyksen.

seuraavalla sivulla muuten kerrotaan default funktiosta ts. jos kirjoittaa koodiin:
B := Default ( Boolean );
Pitäisi alustua false:ksi? Tuon pitäisi toimia kaikilla tyypeillä ja jos oikein luin luokat alustuu globaalissa skoopissa nil:liksi ja objektit ei.
Oikeastaan tuo on loogista, että pitää alustaa itse: funktion var-määrittelyt varataan paikallisesta muistista(ts. pinosta) eikä alusteta, koska se on usein turha operaatio kun ei tiedetä, mihin pitäisi alustaa.
Heap:sta varataan sen sijaan olioita varten tilaa ja ne alustetaan?

Anonyymi kirjoitti:

seuraavalla sivulla muuten kerrotaan default funktiosta ts. jos kirjoittaa koodiin:
B := Default ( Boolean );
Pitäisi alustua false:ksi? Tuon pitäisi toimia kaikilla tyypeillä ja jos oikein luin luokat alustuu globaalissa skoopissa nil:liksi ja objektit ei.
Oikeastaan tuo on loogista, että pitää alustaa itse: funktion var-määrittelyt varataan paikallisesta muistista(ts. pinosta) eikä alusteta, koska se on usein turha operaatio kun ei tiedetä, mihin pitäisi alustaa.
Heap:sta varataan sen sijaan olioita varten tilaa ja ne alustetaan?

Lue lisää

Jep, samapa tuo kun nyt hoksaa nuo alustaa oletuksena ja yleensä näin on tullut tehtyäkin, mutta yhdessä toiminnallisuudessa tämä alustus jäi tekemättä ja ihmettelin vaihtelevaa toimintaa.

Viimeiset 11v tullut koodailtua lähinnä php- & javascript työkseen, jossa ei tämmöistä ongelmaa ole ja/tai herjailut tulee huomattua helpommin. D-kielellä (ei siis Delphi) tullut koodailtua myös viimeiset 6v oman projektin osalta ja vaikka se on C/C kaltainen kieli, siinä muuttujat alustuu automaagisesti oletusarvoilla, eli riittää määritys vaikka int i; jonka arvo on 0

Anonyymi kirjoitti:

Jep, samapa tuo kun nyt hoksaa nuo alustaa oletuksena ja yleensä näin on tullut tehtyäkin, mutta yhdessä toiminnallisuudessa tämä alustus jäi tekemättä ja ihmettelin vaihtelevaa toimintaa.

Viimeiset 11v tullut koodailtua lähinnä php- & javascript työkseen, jossa ei tämmöistä ongelmaa ole ja/tai herjailut tulee huomattua helpommin. D-kielellä (ei siis Delphi) tullut koodailtua myös viimeiset 6v oman projektin osalta ja vaikka se on C/C kaltainen kieli, siinä muuttujat alustuu automaagisesti oletusarvoilla, eli riittää määritys vaikka int i; jonka arvo on 0

Lue lisää

Millä tavalla tämä on joku ongelma?

Anonyymi kirjoitti:

Millä tavalla tämä on joku ongelma?

Ilmeisesti ollut pascalissa alusta asti tuo ettei alustuksia tehdä paikallisille muuttujille. Se, että var-osiossa pystyy alustamaan ylipäätään muuttujan "var i: integer = 0" - yksi riviä kohti - on yllättävän uusi ominaisuus ja vanhemmat kääntäjät ei tuota hyväksy sillä vakioiden alustus on varattu const-osiolle koodissa. Muuttujat alustetaan begin/end-ohjelmalohkossa
Mietin tuota, miten nuo saisi alustettua ja tuli mieleen tällainen kikkailu: {$STACKFRAMES ON} määrittely saa jokaisen funktiokutsun tekemään oman pinon ja tämä tulee kernelin muistivaraukselta nollilla täytettynä virtuaalisena muistisivuna. JOS kääntäjä ei uudelleenkäytä noita stack-kehyksiä, pitäisi sen olla alustettu. Näin ollen varatut muuttujat olisi nollia.. no, kokeilin tuota ja tein fun1 ja fun2:n samoilla(eri nimisillä) muuttujilla - ja muuttujat näkyi funktiokutsujen läpi toisilleen: Eli stack uudelleenkäytetään. Sen sijaan alunperin kerneliltä saatu stack on nollilla ennen käyttöä. Enpä kyllä osaa sanoa, kuinka käyttöjärjestelmäriippuvaista tuo sitten on?

Anonyymi kirjoitti:

Ilmeisesti ollut pascalissa alusta asti tuo ettei alustuksia tehdä paikallisille muuttujille. Se, että var-osiossa pystyy alustamaan ylipäätään muuttujan "var i: integer = 0" - yksi riviä kohti - on yllättävän uusi ominaisuus ja vanhemmat kääntäjät ei tuota hyväksy sillä vakioiden alustus on varattu const-osiolle koodissa. Muuttujat alustetaan begin/end-ohjelmalohkossa
Mietin tuota, miten nuo saisi alustettua ja tuli mieleen tällainen kikkailu: {$STACKFRAMES ON} määrittely saa jokaisen funktiokutsun tekemään oman pinon ja tämä tulee kernelin muistivaraukselta nollilla täytettynä virtuaalisena muistisivuna. JOS kääntäjä ei uudelleenkäytä noita stack-kehyksiä, pitäisi sen olla alustettu. Näin ollen varatut muuttujat olisi nollia.. no, kokeilin tuota ja tein fun1 ja fun2:n samoilla(eri nimisillä) muuttujilla - ja muuttujat näkyi funktiokutsujen läpi toisilleen: Eli stack uudelleenkäytetään. Sen sijaan alunperin kerneliltä saatu stack on nollilla ennen käyttöä. Enpä kyllä osaa sanoa, kuinka käyttöjärjestelmäriippuvaista tuo sitten on?

Lue lisää

procedure TForm1.Button1Click(Sender: TObject);
Var i:integer=3; j:integer=2;
begin

end;

Tämä on ihan syntaksin mukainen muuttujan alustaminen. Mikä ongelma sinulla on siinä?

Anonyymi kirjoitti:

Ilmeisesti ollut pascalissa alusta asti tuo ettei alustuksia tehdä paikallisille muuttujille. Se, että var-osiossa pystyy alustamaan ylipäätään muuttujan "var i: integer = 0" - yksi riviä kohti - on yllättävän uusi ominaisuus ja vanhemmat kääntäjät ei tuota hyväksy sillä vakioiden alustus on varattu const-osiolle koodissa. Muuttujat alustetaan begin/end-ohjelmalohkossa
Mietin tuota, miten nuo saisi alustettua ja tuli mieleen tällainen kikkailu: {$STACKFRAMES ON} määrittely saa jokaisen funktiokutsun tekemään oman pinon ja tämä tulee kernelin muistivaraukselta nollilla täytettynä virtuaalisena muistisivuna. JOS kääntäjä ei uudelleenkäytä noita stack-kehyksiä, pitäisi sen olla alustettu. Näin ollen varatut muuttujat olisi nollia.. no, kokeilin tuota ja tein fun1 ja fun2:n samoilla(eri nimisillä) muuttujilla - ja muuttujat näkyi funktiokutsujen läpi toisilleen: Eli stack uudelleenkäytetään. Sen sijaan alunperin kerneliltä saatu stack on nollilla ennen käyttöä. Enpä kyllä osaa sanoa, kuinka käyttöjärjestelmäriippuvaista tuo sitten on?

Lue lisää

"Muuttujat alustetaan begin/end-ohjelmalohkossa"

Onko siinä jokin ongelma, että muuttuja saa sisältöä siellä missä sitä käytetään.

Anonyymi kirjoitti:

Millä tavalla tämä on joku ongelma?

No on se sillä tavalla "ongelma" kun ei ole pitkään aikaan Pascalilla tullut koodailtua, että jää helposti tottumuksesta tämmöinen alustus oletuksella huomaamatta?

ap.

Anonyymi kirjoitti:

No on se sillä tavalla "ongelma" kun ei ole pitkään aikaan Pascalilla tullut koodailtua, että jää helposti tottumuksesta tämmöinen alustus oletuksella huomaamatta?

ap.

Lue lisää

Ehkäpä sillä Pascalilla ei kannattaisi muutenkaan tehdä mitään kun käytännössä aina löytyy sopivampia välineitä.

Anonyymi kirjoitti:

Ehkäpä sillä Pascalilla ei kannattaisi muutenkaan tehdä mitään kun käytännössä aina löytyy sopivampia välineitä.

Jotkut käyttä tennismailaa ja majavaleikkejä, kollilla on kauha!

Anonyymi kirjoitti:

Ilmeisesti ollut pascalissa alusta asti tuo ettei alustuksia tehdä paikallisille muuttujille. Se, että var-osiossa pystyy alustamaan ylipäätään muuttujan "var i: integer = 0" - yksi riviä kohti - on yllättävän uusi ominaisuus ja vanhemmat kääntäjät ei tuota hyväksy sillä vakioiden alustus on varattu const-osiolle koodissa. Muuttujat alustetaan begin/end-ohjelmalohkossa
Mietin tuota, miten nuo saisi alustettua ja tuli mieleen tällainen kikkailu: {$STACKFRAMES ON} määrittely saa jokaisen funktiokutsun tekemään oman pinon ja tämä tulee kernelin muistivaraukselta nollilla täytettynä virtuaalisena muistisivuna. JOS kääntäjä ei uudelleenkäytä noita stack-kehyksiä, pitäisi sen olla alustettu. Näin ollen varatut muuttujat olisi nollia.. no, kokeilin tuota ja tein fun1 ja fun2:n samoilla(eri nimisillä) muuttujilla - ja muuttujat näkyi funktiokutsujen läpi toisilleen: Eli stack uudelleenkäytetään. Sen sijaan alunperin kerneliltä saatu stack on nollilla ennen käyttöä. Enpä kyllä osaa sanoa, kuinka käyttöjärjestelmäriippuvaista tuo sitten on?

Lue lisää

Paavo Väyrysen sai kutsun pyllymajaan!

Anonyymi kirjoitti:

Ilmeisesti ollut pascalissa alusta asti tuo ettei alustuksia tehdä paikallisille muuttujille. Se, että var-osiossa pystyy alustamaan ylipäätään muuttujan "var i: integer = 0" - yksi riviä kohti - on yllättävän uusi ominaisuus ja vanhemmat kääntäjät ei tuota hyväksy sillä vakioiden alustus on varattu const-osiolle koodissa. Muuttujat alustetaan begin/end-ohjelmalohkossa
Mietin tuota, miten nuo saisi alustettua ja tuli mieleen tällainen kikkailu: {$STACKFRAMES ON} määrittely saa jokaisen funktiokutsun tekemään oman pinon ja tämä tulee kernelin muistivaraukselta nollilla täytettynä virtuaalisena muistisivuna. JOS kääntäjä ei uudelleenkäytä noita stack-kehyksiä, pitäisi sen olla alustettu. Näin ollen varatut muuttujat olisi nollia.. no, kokeilin tuota ja tein fun1 ja fun2:n samoilla(eri nimisillä) muuttujilla - ja muuttujat näkyi funktiokutsujen läpi toisilleen: Eli stack uudelleenkäytetään. Sen sijaan alunperin kerneliltä saatu stack on nollilla ennen käyttöä. Enpä kyllä osaa sanoa, kuinka käyttöjärjestelmäriippuvaista tuo sitten on?

Lue lisää

Väärää tietoa!

{$STACKFRAMES ON}

tuo EI varaa jokaiselle funktiolle omaa pinoa eikä nollaa pinomuistin tavuja!

Vaan se, mitä tuo tekee, on varmistaa, että jokaiselle funktiolle luodaan oma pinon rakenne, eli on tarpeen tiettyjä debuggaustapoja varten.

Ilman tuota debuggerin "View/Debug Windpows/Call Stack" -ominaisuus ei välttämättä toimi oikein / lainkaan.

Debuggauksen ajaksi kannattaa laittaa myös Unit:in alkuun:

{$O-}

tai

{$OPTIMIZATION OFF}

Tuo hidastaa koodia jonkin verran, mutta tuon ansiosta debuggaus toimii paljon paremmin.

Ilman tuota, koodi on nopeampaa, mutta kun yrität tarkastella debuggerilla jonkin muuttujan arvoa, niin debuggeri valittaa, ettei ko. muuttujan arvo ole saatavilla optimoinnin takia.

Anonyymi kirjoitti:

Ehkäpä sillä Pascalilla ei kannattaisi muutenkaan tehdä mitään kun käytännössä aina löytyy sopivampia välineitä.

Muiden kielten kuin Pascalin / ObjectPascalin käyttäjät saavat yleensä aikaiseksi kaiken maailman virheitä, joita monet ohjelmistot ovat täynnä, kun niitä ei ole koodattu Delphillä.

Delphin käyttäjät tekevät yleensä huolellista työtä, ja siksi Delphi -ohjelmissa moiset bugit ovat harvinaisuus.

Omaa koodia kirjoitettaessa kannattaa laitta vielä {$R+}

Tosin, jos koodi on suoraan C -kielisestä koodista Delphille käännetty, niin monessa kohdassa ei voi käyttää {$R+}
koska C:n yleinen koodaustyyli olettaa, ettei muuttujien muistirajoja tarvitse kunnioittaa.

Delphiksi käännettäessä, siellä missä voi, kannattaa käyttää dynaamisia taulukoita ja SetLength -proseduuria.

Mainittakoon toki se, että joissakin kielissä voi pino vuotaa, että tarvitsee erittäin huolellisesti kirjoittaa funktiot ilman rekursiota ja siinä sitten sitä sijoitusta tarvitaan. Toki se voidaan rajata siihen scopeen missä tarvitaan ja oletus on että ei ole alkuarvoa ellei sitä anna.

Anonyymi kirjoitti:

Mainittakoon toki se, että joissakin kielissä voi pino vuotaa, että tarvitsee erittäin huolellisesti kirjoittaa funktiot ilman rekursiota ja siinä sitten sitä sijoitusta tarvitaan. Toki se voidaan rajata siihen scopeen missä tarvitaan ja oletus on että ei ole alkuarvoa ellei sitä anna.

Lue lisää

Mikäli pino vuotaa sisäänpäin ja samalla aaltoilee sekä liplattaa, on alkuarvoa silloin tarkasteltava epätavallisenkin tarkasti, vaikka muut ohjelmiston osat hinattaessa eivät sitä ollenkaan ennen jäidenlähtöä sallisi.

Anonyymi kirjoitti:

Mikäli pino vuotaa sisäänpäin ja samalla aaltoilee sekä liplattaa, on alkuarvoa silloin tarkasteltava epätavallisenkin tarkasti, vaikka muut ohjelmiston osat hinattaessa eivät sitä ollenkaan ennen jäidenlähtöä sallisi.

Lue lisää

ECHO ON ja spinonarvo fast 14, vol 65.