Java.

Muu yhteisön välinen keskustelu.
User avatar
esa94
Guru
Posts: 1855
Joined: Tue Sep 04, 2007 5:35 pm

Re: Java.

Post by esa94 »

Feuer wrote:
esa94 wrote:No mitä nyt akana tulee mieleen se ettei oo kivoja fasiliteettejä niinku osoittimia tai ees erillisiä viittauksia.
Njoo, oliomalli on kieltämättä melko outo verrattuna muuhun maailmaan (C++, C#). Etenkin kun ottaa huomioon geneerisyyden ja sen vaatimat typerät kääreluokat perustietotyypeille.
Generiikkoja ei kannata edes käyttää kun ne ei oo templaattoja.

Yleensä kun ite tarttisin niin pitäis jotenkin erikoistaa muutamaa geneeristä metodia mutta se nyt vaan on sitten mahdotonta. Ai jaa.
TheFish
Developer
Developer
Posts: 477
Joined: Mon Aug 27, 2007 9:28 pm
Location: Joensuu

Re: Java.

Post by TheFish »

esa94 wrote:Generiikkoja ei kannata edes käyttää kun ne ei oo templaattoja.

Yleensä kun ite tarttisin niin pitäis jotenkin erikoistaa muutamaa geneeristä metodia mutta se nyt vaan on sitten mahdotonta. Ai jaa.
Minusta kuulostaa jotenkin siltä, että ongelmana on vain se, että yrität koodata C++:aa Javalla. Kyseessä on eri kieli, joten asiat tehdään eri tavalla. Tuo on ihan niin kuin sanoisi, että Linux on vittumainen, koska siinä ei ole Windowsin rekisteriä.
CoolBasic henkilökuntaa
Kehittäjä
User avatar
esa94
Guru
Posts: 1855
Joined: Tue Sep 04, 2007 5:35 pm

Re: Java.

Post by esa94 »

TheFish wrote:
esa94 wrote:Generiikkoja ei kannata edes käyttää kun ne ei oo templaattoja.

Yleensä kun ite tarttisin niin pitäis jotenkin erikoistaa muutamaa geneeristä metodia mutta se nyt vaan on sitten mahdotonta. Ai jaa.
Minusta kuulostaa jotenkin siltä, että ongelmana on vain se, että yrität koodata C++:aa Javalla. Kyseessä on eri kieli, joten asiat tehdään eri tavalla. Tuo on ihan niin kuin sanoisi, että Linux on vittumainen, koska siinä ei ole Windowsin rekisteriä.
No siitähän on kyse tavallaan juu. Joka tapauksessa en ole oikeen keksinyt montaakaan asiaa joihin generiikkaa voi käyttää jos ei ole spesialisaatiomahdollisuutta tai keinoa tunnistaa parametrien tietotyyppejä. Jos vois spesialisoida niin ois paljon yksinkertasempaa tehdä jotain asioita.

Tietty vois vaan käyttää Objecteja ja muuta mutta se on niin pahaa että sattuu.
TheFish
Developer
Developer
Posts: 477
Joined: Mon Aug 27, 2007 9:28 pm
Location: Joensuu

Re: Java.

Post by TheFish »

esa94 wrote:
TheFish wrote:
esa94 wrote:Generiikkoja ei kannata edes käyttää kun ne ei oo templaattoja.

Yleensä kun ite tarttisin niin pitäis jotenkin erikoistaa muutamaa geneeristä metodia mutta se nyt vaan on sitten mahdotonta. Ai jaa.
Minusta kuulostaa jotenkin siltä, että ongelmana on vain se, että yrität koodata C++:aa Javalla. Kyseessä on eri kieli, joten asiat tehdään eri tavalla. Tuo on ihan niin kuin sanoisi, että Linux on vittumainen, koska siinä ei ole Windowsin rekisteriä.
No siitähän on kyse tavallaan juu. Joka tapauksessa en ole oikeen keksinyt montaakaan asiaa joihin generiikkaa voi käyttää jos ei ole spesialisaatiomahdollisuutta tai keinoa tunnistaa parametrien tietotyyppejä. Jos vois spesialisoida niin ois paljon yksinkertasempaa tehdä jotain asioita.

Tietty vois vaan käyttää Objecteja ja muuta mutta se on niin pahaa että sattuu.
Et ole keksinyt niille käyttöä, koska ajattelet asioita C++:ana. Sinun pitää vain unohtaa kokonaan, miten asiat tehtäisiin C++:lla, ja miettiä koko homma Javana. Käyttäen aikaisempaa esimerkkiäni, ei siis pidä miettiä "Miten voin tallentaa tietoa rekisteriin linuxissa?", vaan kysymystä "Miten tiedon tallentaminen kuuluu tehdä Linuxissa?". Toisena esimerkkinä voisi käyttää tätä:

Code: Select all

(format t "~d" (loop for i from 1 to 100 summing i))
Tuo summaa luvut yhdestä sataan ja tulostaa summan. Lisp-ohjelmoija kun joutuu tekemään saman C++:lla, hänhän huomaa heti, että eihän for-looppia voi käyttää inlinenä, ja siitä ei voi palauttaa tulosta. Mihin sitä siis muka voi käyttää!?

En tiedä, että mihin olet yrittänyt javan generiikkoja käyttää, mutta melkein löisin vetoa, että saman tuloksen saat aikaan Javallakin, kun vain ajattelet asian Javana. Se kyseinen tapaus voi olla monimutkaisempi tehdä Javalla, mutta ainahan ei voi voittaa. Java sopii toisiin asioihin paremmin ja C++ toisiin.
CoolBasic henkilökuntaa
Kehittäjä
User avatar
esa94
Guru
Posts: 1855
Joined: Tue Sep 04, 2007 5:35 pm

Re: Java.

Post by esa94 »

Yritin muistaakseni luoda metodia joka osaa palauttaa geneerisen tietotyypin.
Dimple
Active Member
Posts: 103
Joined: Wed Nov 17, 2010 5:43 pm

Re: Java.

Post by Dimple »

esa94 wrote:
KilledWhale wrote:Javaa on ollut tarkoitus opetella jo jonkin aikaa kun se tuntuu niin keskeiseltä ohjelmointibisneksessä ja C++-koodauksen jälkeen tuntuu varsin helpolta.
Öh.

Enemmänkin vittumaiselta.
Komppaan kyllä tätä. Periaatteessa helppoa joo, mutta ai että sitä turhautumisen määrää.

Koulun puolesta vaan on pakko käyttää Javaa, koska tehtävät tarkastetaan automaattisesti. Kurssina on siis tietorakenteet. Täytyy sanoa, että kyllä paljon mieluummin käyttäisin esim. C:tä niihin tietorakenteiden toteuttamiseen jo pelkästään siitä syystä, että Javassa ei ole pointtereita.

Muuten, miksi Javan String-luokassa on läjä metodeja, joilla voi korvata kaikki tietyt esiintymät toisella, mutta sitten ei ole metodia, jolla voisi korvata merkkejä indeksien perusteella? Makes sense to me not.
TheFish
Developer
Developer
Posts: 477
Joined: Mon Aug 27, 2007 9:28 pm
Location: Joensuu

Re: Java.

Post by TheFish »

Dimple wrote:...
Muuten, miksi Javan String-luokassa on läjä metodeja, joilla voi korvata kaikki tietyt esiintymät toisella, mutta sitten ei ole metodia, jolla voisi korvata merkkejä indeksien perusteella? Makes sense to me not.
Koska String-luokan oliota ei pysty muokkaamaan sen luomisen jälkeen, vaan muutoksien teko luo uuden olion. Ei siis olisi "kustannustehokasta" tehdä tuota Stringillä, vaan mikäli sinun tarvitsee käsitellä merkkijonoa taulukkomaisesti, on tehokkaampi käyttää StringBuilder-luokkaa (josta löytyy metodi tuon tekemiseen):

Code: Select all

StringBuilder sb = new StringBuilder("fjdsg ijodsgpsdfjg idsgopsdf g");
System.out.println(sb.replace(9, 12, "aaa"));
Sanoisin siis sinullekkin samaa kuin esa94:llekkin :)
CoolBasic henkilökuntaa
Kehittäjä
User avatar
esa94
Guru
Posts: 1855
Joined: Tue Sep 04, 2007 5:35 pm

Re: Java.

Post by esa94 »

TheFish wrote: Sanoisin siis sinullekkin samaa kuin esa94:llekkin :)
Ongelmahan on siinä että missään ei puhuta StringBuilderista (Joka muuten on paljon stringstreameja vittumaisempi härpäke adfeswrgsehrta) tahi siitä että Stringit poolataan tai tai tai.

Javassa on niin paljon ikäviä ratkaisuja että se sattuu. String-objektit voisivat ihan helposti olla muutettavia mutta joku nyt vaan on päättänyt etteivät ne ole eikä siinä ole mitään järkeä.
TheFish
Developer
Developer
Posts: 477
Joined: Mon Aug 27, 2007 9:28 pm
Location: Joensuu

Re: Java.

Post by TheFish »

esa94 wrote: Ongelmahan on siinä että missään ei puhuta StringBuilderista (Joka muuten on paljon stringstreameja vittumaisempi härpäke adfeswrgsehrta) tahi siitä että Stringit poolataan tai tai tai.
Kyllähän StringBuilderi mainitaan Sunin (/Oraclen) omissa tutoriaaleissa. Ja Stringin Javadocissakin sanotaan niiden olevan immutableja. Vittumaisuuden osalta kantani pysyy samana.
esa94 wrote:Javassa on niin paljon ikäviä ratkaisuja että se sattuu. String-objektit voisivat ihan helposti olla muutettavia mutta joku nyt vaan on päättänyt etteivät ne ole eikä siinä ole mitään järkeä.
Kyllähän Javan kokoisessa projektissa on varmasti huonojakin ratkaisuja, mutta Stringeille näyttää olevan jopa mahdollisia perustelujakin. Virallista syytä en tietenkään tiedä, mutta kannattaa muistaa, että Javan kehitystiimiin kuuluu (/on kuulunut) erittäin fiksua porukkaa, joten heillä on varmasti ollut hyvät syyt Stringin kaltaisen perusasian toteutukselle.
CoolBasic henkilökuntaa
Kehittäjä
Latexi95
Guru
Posts: 1166
Joined: Sat Sep 20, 2008 5:10 pm
Location: Lempäälä

Re: Java.

Post by Latexi95 »

TheFish wrote:Kyllähän Javan kokoisessa projektissa on varmasti huonojakin ratkaisuja, mutta Stringeille näyttää olevan jopa mahdollisia perustelujakin. Virallista syytä en tietenkään tiedä, mutta kannattaa muistaa, että Javan kehitystiimiin kuuluu (/on kuulunut) erittäin fiksua porukkaa, joten heillä on varmasti ollut hyvät syyt Stringin kaltaisen perusasian toteutukselle.
Lueskelin tuota ja tuli mieleen, että miksi Java:n Stringit ei ole toteutettu vaikka "implicit sharingin" avulla, samaan tapaan kuin QStringit? Eli ainostaan merkkijonon muuttaminen aiheuttaa kopioimisen.

Code: Select all

QString str1 = "Tekstiä";
QString str2 = str1; //str2:lla sama tekstin pätkä, eikä kopiointia ole tapahtunut
QString str3 = str2; //Ei vieläkään kopiointia
str3 = str3.toUpper(); //merkkijonosta tehdään kopio, joka muutettaan isoilla kirjaimilla kirjoitetuksi ja se laitettaan str3:een.
str2 = str3; //Taas str2:ssa sama merkkijono kuin str3:ssa eikä kopiointia ole tapahtunut.
str1 = str2; //str1:een sama teksti kuin muihinkin. Viimeinenkin viittaus alkuperäiseen tekstiin poistuu ja se poistettaan.
Tuossa blogissa mainittu hashi systeemi voitaisiin korvata tekemällä erillinen HashString luokka joka toimisi muuten samoin kuin edellinen, mutta pitäisi mukanaan myös merkkijonon hashin. Hashin arvo voitaisiin nollata aina kun merkkijonoa muutettaan, mistä jokin "getHash" funktio tietäisi, että pitäisi uudelleen tehdä hashi. Näin hashi laskettaisiin vain ainoastaan, kun sitä tarvitaan eikä sitä lasketa jos se on jo tiedossa.

Joskus kyllä tekisi mieli tehdä oma ohjelmointikieli, kun sattuu tulemaan hyviä ideoita tai huomaa puutteita muissa ohjelmointikielissä. :lol:
User avatar
esa94
Guru
Posts: 1855
Joined: Tue Sep 04, 2007 5:35 pm

Re: Java.

Post by esa94 »

TheFish wrote:
esa94 wrote:Javassa on niin paljon ikäviä ratkaisuja että se sattuu. String-objektit voisivat ihan helposti olla muutettavia mutta joku nyt vaan on päättänyt etteivät ne ole eikä siinä ole mitään järkeä.
Kyllähän Javan kokoisessa projektissa on varmasti huonojakin ratkaisuja, mutta Stringeille näyttää olevan jopa mahdollisia perustelujakin. Virallista syytä en tietenkään tiedä, mutta kannattaa muistaa, että Javan kehitystiimiin kuuluu (/on kuulunut) erittäin fiksua porukkaa, joten heillä on varmasti ollut hyvät syyt Stringin kaltaisen perusasian toteutukselle.
Voi kristus
5) Another good reason of Why String is immutable in Java suggested by Dan Bergh Johnsson on comments is: The absolutely most important reason that String is immutable is that it is used by the class loading mechanism, and thus have profound and fundamental security aspects.
Had String been mutable, a request to load "java.io.Writer" could have been changed to load "mil.vogoon.DiskErasingWriter"
Feuer
Devoted Member
Posts: 520
Joined: Tue Jun 16, 2009 11:13 am
Contact:

Re: Java.

Post by Feuer »

Latexi95 wrote: Lueskelin tuota ja tuli mieleen, että miksi Java:n Stringit ei ole toteutettu vaikka "implicit sharingin" avulla, samaan tapaan kuin QStringit? Eli ainostaan merkkijonon muuttaminen aiheuttaa kopioimisen.

Code: Select all

QString str1 = "Tekstiä";
QString str2 = str1; //str2:lla sama tekstin pätkä, eikä kopiointia ole tapahtunut
QString str3 = str2; //Ei vieläkään kopiointia
str3 = str3.toUpper(); //merkkijonosta tehdään kopio, joka muutettaan isoilla kirjaimilla kirjoitetuksi ja se laitettaan str3:een.
str2 = str3; //Taas str2:ssa sama merkkijono kuin str3:ssa eikä kopiointia ole tapahtunut.
str1 = str2; //str1:een sama teksti kuin muihinkin. Viimeinenkin viittaus alkuperäiseen tekstiin poistuu ja se poistettaan.
Niinhän tuo tietääkseni toimii, olettaen että ymmärsin logiikan.

Code: Select all

String str1 = "Jee!";
String str2 = str1; //str1 == str2 ja str2.equals(str1)
String str3 = str2; //Kaikki kolme viittaavat samaan stringiin
str3 = str3.toUpperCase(); //Merkkijonosta tulee kopio, str3 != str1 ja !str3.equals(str1);
str2 = str3; //str2 ja str3 viittaavat samaan olioon, toisinkuin str1
str1 = str2; //alkuperäinen str1 on vapaata riistaa gc:lle tai stringpoolin muistinvapautuslogiikalle
Latexi95 wrote: Joskus kyllä tekisi mieli tehdä oma ohjelmointikieli, kun sattuu tulemaan hyviä ideoita tai huomaa puutteita muissa ohjelmointikielissä. :lol:
Siitähän ne parhaat kielet ovat lähteneet :P

Palaten alkuperäiseen ongelmaani, Japura ei ollut ihan se mitä hain takaa, mutta ratkaisin ongelman kirjoittamalla oman listaelementin.
Asus P8P67 LE/Intel Core i5 2500K/ GTX560/ 8GT RAM/750GT HDDt + 120GT SSD + 13" Macbook Pro
Blogi - Peräpohjola - MERPG
Latexi95
Guru
Posts: 1166
Joined: Sat Sep 20, 2008 5:10 pm
Location: Lempäälä

Re: Java.

Post by Latexi95 »

Feuer wrote:
Niinhän tuo tietääkseni toimii, olettaen että ymmärsin logiikan.

Code: Select all

String str1 = "Jee!";
String str2 = str1; //str1 == str2 ja str2.equals(str1)
String str3 = str2; //Kaikki kolme viittaavat samaan stringiin
str3 = str3.toUpperCase(); //Merkkijonosta tulee kopio, str3 != str1 ja !str3.equals(str1);
str2 = str3; //str2 ja str3 viittaavat samaan olioon, toisinkuin str1
str1 = str2; //alkuperäinen str1 on vapaata riistaa gc:lle tai stringpoolin muistinvapautuslogiikalle
Niin tietysti. Sehän toimiikin käytännössä lähes samanlailla. Mitähän taas ajattelin... :lol:
Mutta en kyllä siltikkään tajua pointtia, miksi javassa ei ymmärtääkseni onnistu muokkaus vaan aina luodaan uusi merkkijono. Eikö merkkijono tiedä montako referenssiä siihen on? "Implicit sharingissahan" muokkaus onnistuu ilman kopiointia, jos referenssejen määrä on 1:ksi (referenssejen määrä on aina tiedossa), muussa tapausessa luodaan uusi.
Feuer wrote: Siitähän ne parhaat kielet ovat lähteneet :P
Joo ehkä jossain vaiheessa. cbEnchanted toimii pienenä harjoituksena ennen sitä. :lol:
TheFish
Developer
Developer
Posts: 477
Joined: Mon Aug 27, 2007 9:28 pm
Location: Joensuu

Re: Java.

Post by TheFish »

Latexi95 wrote:Eikö merkkijono tiedä montako referenssiä siihen on? "Implicit sharingissahan" muokkaus onnistuu ilman kopiointia, jos referenssejen määrä on 1:ksi (referenssejen määrä on aina tiedossa), muussa tapausessa luodaan uusi.
Periaatteessahan se voisi olla toteutettu noin, mutta käyttäjän näkökulmasta kyseessä olisi sama asia. Keskusteluhan lähti käyntiin siitä, että miksi ei ole kannattavaa laittaa tuota merkkienvaihto-metodia Stringiin. Tämä ei muuttaisi sitä mitenkään, koska ohjelmoija ei voi ikinä luottaa siihen, että viittauksia on vain yksi.
CoolBasic henkilökuntaa
Kehittäjä
Latexi95
Guru
Posts: 1166
Joined: Sat Sep 20, 2008 5:10 pm
Location: Lempäälä

Re: Java.

Post by Latexi95 »

TheFish wrote: Periaatteessahan se voisi olla toteutettu noin, mutta käyttäjän näkökulmasta kyseessä olisi sama asia. Keskusteluhan lähti käyntiin siitä, että miksi ei ole kannattavaa laittaa tuota merkkienvaihto-metodia Stringiin. Tämä ei muuttaisi sitä mitenkään, koska ohjelmoija ei voi ikinä luottaa siihen, että viittauksia on vain yksi.
Niin mutta ainakin implicit sharingin idea on, että data on yhtenä pakettina joka pitää mukanaan referenssilaskurin. Jos halutaan muuttaa merkkijonoa josta on jo useampia referenssejä, referenssilaskurista miinustettaan yksi ja merkkijono tekee uuden kopion datasta, jolla on taas referenssien määrä 1:ksi. Joten ohjelmoijan kannalta ei ole mitään merkitystä onko referenssejä yksi vai useampi.
Tässä Qt:n dokumentaation kattava artikkeli implicit sharingista.
TheFish
Developer
Developer
Posts: 477
Joined: Mon Aug 27, 2007 9:28 pm
Location: Joensuu

Re: Java.

Post by TheFish »

Latexi95 wrote:
TheFish wrote: Periaatteessahan se voisi olla toteutettu noin, mutta käyttäjän näkökulmasta kyseessä olisi sama asia. Keskusteluhan lähti käyntiin siitä, että miksi ei ole kannattavaa laittaa tuota merkkienvaihto-metodia Stringiin. Tämä ei muuttaisi sitä mitenkään, koska ohjelmoija ei voi ikinä luottaa siihen, että viittauksia on vain yksi.
Niin mutta ainakin implicit sharingin idea on, että data on yhtenä pakettina joka pitää mukanaan referenssilaskurin. Jos halutaan muuttaa merkkijonoa josta on jo useampia referenssejä, referenssilaskurista miinustettaan yksi ja merkkijono tekee uuden kopion datasta, jolla on taas referenssien määrä 1:ksi. Joten ohjelmoijan kannalta ei ole mitään merkitystä onko referenssejä yksi vai useampi.
Tässä Qt:n dokumentaation kattava artikkeli implicit sharingista.
Mutta tämä ei poistaisi sitä ongelmaa, että jos Stringejä ruvetaan muokkamaan, tämä saattaa aiheuttaa (mahdollisesti useiden) uusien olioiden luomisen. On siis tehokkaampaa käyttää StringBuilderia jos aikoo muokata Stringiä, koska tällöin voi olla varma, että uusia olioita ei luoda. Elikkä vaikka Stringit toteutettaisiin noin, se ei aiheuttaisi mitään muutoksia siihen miltä asiat näyttävät ohjelmoijalle.

StringBuilderin käyttö myös mahdollistaa muutosten teon eri metodissa (mikä käsittääkseni aiheuttaisi kopioinnin Qt:ssa?):

Code: Select all

public static void main(String[] args) {
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < 100; i++) {
        foo(sb);
    }
    System.out.println(sb);
}
public static void foo(StringBuilder sb) {
    sb.append("a");
}
Tosin siitä voi sitten väitellä, että kannattaako näin tehdä...
CoolBasic henkilökuntaa
Kehittäjä
Latexi95
Guru
Posts: 1166
Joined: Sat Sep 20, 2008 5:10 pm
Location: Lempäälä

Re: Java.

Post by Latexi95 »

TheFish wrote: Mutta tämä ei poistaisi sitä ongelmaa, että jos Stringejä ruvetaan muokkamaan, tämä saattaa aiheuttaa (mahdollisesti useiden) uusien olioiden luomisen. On siis tehokkaampaa käyttää StringBuilderia jos aikoo muokata Stringiä, koska tällöin voi olla varma, että uusia olioita ei luoda. Elikkä vaikka Stringit toteutettaisiin noin, se ei aiheuttaisi mitään muutoksia siihen miltä asiat näyttävät ohjelmoijalle.
Kyllähän uusi olio luodaan: StringBuilder. Jos muokkaan yhtä QStringiä kokoajan ja se on yhdessä muuttujassa, niin sitä ei kopioda kertaakaan (paitsi ehkä ihan aluksi, ennen ensimmäistä muokkausta). Jos taas käytät useita muuttujia, niin kopiointi aiheutuu, mutta silloin kyllä käyttäjä sitä odottaakin, koska muutenhan kaikki merkkijonot muuttuisivat. Javan tapausessa silloin varmaankin luotaisiin useita StringBuildereita.
TheFish wrote: StringBuilderin käyttö myös mahdollistaa muutosten teon eri metodissa (mikä käsittääkseni aiheuttaisi kopioinnin Qt:ssa?):

Code: Select all

public static void main(String[] args) {
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < 100; i++) {
        foo(sb);
    }
    System.out.println(sb);
}
public static void foo(StringBuilder sb) {
    sb.append("a");
}
Tosin siitä voi sitten väitellä, että kannattaako näin tehdä...
Kyllä tuollainen aiheuttaa kopioinnin, mutta sen estämiseksi merkkijono kannattaa antaa referenssinä, jolloin kopiointia ei tapahdu. QStringin ollessa parametrina kannattaa aina laittaa se vakioksi ja referenssiksi.

Code: Select all

void foo(const QString &str) { ...}
C++ & Qt yhdistelmällä toteuttaisin tuon esimerkkisi näin:

Code: Select all

int main() {
    QString sb;
    for (int i = 0; i < 100; i++) {
        foo(sb);
    }
    qDebug() << sb;
    return 0;
}
void foo(QString &sb) {
    sb.append("a");
}
Täsmälleen sama lopputulos eikä yhtään ainutta (turhaa) kopiointia.
TheFish
Developer
Developer
Posts: 477
Joined: Mon Aug 27, 2007 9:28 pm
Location: Joensuu

Re: Java.

Post by TheFish »

Latexi95 wrote:Täsmälleen sama lopputulos eikä yhtään ainutta kopiointia.
Ei paljon lohduta kielessä ilman varsinaisia pointtereita/referenssejä :) Kumpikin menetelmä siis toimii, mutta nähdäkseni Javan tapa on parempi Javalla, kun taas Qt on parempi C++:lla. Tästä päästään takaisin siihen mitä aiemmin sanoin esalle; Jos koodaat Javaa, koodaa Javaa.

Ylemmästä vielä, että eihän StringBuilderin luonti periaatteessa aiheuta uuden olion luontia, koska merkkijonohan on alunperinkin Stringbuilderi (yksi oliohan on aina oltava, oli se sitten String tai StringBuilder, joten sitä on turha laskea).
CoolBasic henkilökuntaa
Kehittäjä
Latexi95
Guru
Posts: 1166
Joined: Sat Sep 20, 2008 5:10 pm
Location: Lempäälä

Re: Java.

Post by Latexi95 »

TheFish wrote: Ei paljon lohduta kielessä ilman varsinaisia pointtereita/referenssejä :) Kumpikin menetelmä siis toimii, mutta nähdäkseni Javan tapa on parempi Javalla, kun taas Qt on parempi C++:lla. Tästä päästään takaisin siihen mitä aiemmin sanoin esalle; Jos koodaat Javaa, koodaa Javaa.
Kyllä näin on. Kannattaa aina koodata ohjelmointikieltä siten sen omilla ehdoilla ja keinoilla. Silloin saa parhaan mahdollisen lopputuloksen. :)
TheFish wrote: Ylemmästä vielä, että eihän StringBuilderin luonti periaatteessa aiheuta uuden olion luontia, koska merkkijonohan on alunperinkin Stringbuilderi (yksi oliohan on aina oltava, oli se sitten String tai StringBuilder, joten sitä on turha laskea).
No joo. Mutta ei Qt:ssakaan tarvita kuin yksi QString (eikä siitä tarvitse tehdä kopiota). En ehkä aivan tajunnut tuon aikaisemman selityksesi pointtia. :lol:
User avatar
Dibalo
Advanced Member
Posts: 298
Joined: Mon Aug 27, 2007 8:12 pm
Location: Espoo, Finland
Contact:

Re: Java.

Post by Dibalo »

Teille, jotka ette halua opetella ohjelmoimaan [Javaa Javan tavalla], vaan pitäydytte itsepintaisesti C++:n konventioissa ja design patterneissa, koska teidän mielestänne C++ on maailman paras:

Onnea työelämään
The darkest spells can be found from
http://tunkkaus.blogspot.fi
Post Reply