C++ vaikein kieli nykyään?

Ehkä sun kannattaisi vaan pysytellä pyyttonissa.

M‒Kar kirjoitti:

Ehkä sun kannattaisi vaan pysytellä pyyttonissa.

c ja java ovat todella kankeita pythoniin verrattuna. siirtyminen sieltä pythoniin laajentaa pääkoppaa, siirtyminen toiseen suuntaan pistää puremaan hammasta.

roskapostirobotti 22 kirjoitti:

c ja java ovat todella kankeita pythoniin verrattuna. siirtyminen sieltä pythoniin laajentaa pääkoppaa, siirtyminen toiseen suuntaan pistää puremaan hammasta.

Aivan ja Pythonista kannattaa siirtyä Rubyyn, aivot kasvavat vielä lisää...

IsoPää+++ kirjoitti:

Aivan ja Pythonista kannattaa siirtyä Rubyyn, aivot kasvavat vielä lisää...

...kohonneen verenpaineen takia, kun koodia pitäisi lukea.

Pythonissa on tehty sekin oikein. Ei tarvitse osata kirjoittaa Pythonia, että sitä pystyy lukemaan. Ruby on melkein yhtä paha kuin Perl. Vaikka sitä osaisi kirjoittaa, lukeminen ei ole ihan helppoa.

**Pada-tsing**

Tarkoitatko, että Japani on kokonaisuudessaan vaikeampi kuin C , vai pelkkä pääsaari Honshu? Entä onko pelkkä Etelä-Korea yksin vakeampi kuin C ?

Tiedän tunteen, mutta kyllä se perl sieltä lähtee, kun vähän potkii ;)

Perlissä on kyllä erinomainen kieli tekstin pyörittelyyn, mutta syntaksissa on kyllä kummallisia sääntöjä. Toisaalta muuttujien prefixit ($, @, % tms.) kertovat paljon minkälainen muuttuja on kyseessä. Tuli käytettyä pari vuotta Perliä ensimmäisessä työpaikassani.

Yksi suuri ongelma on siinä, että jotkut vaan kirjoittavat niin epäselvää Perl-koodia, että sitä on todella vaikeata muiden lukea. Tämän tyylinen ns. Perl-golffaus on mielestäni typerä tapa ohjelmoida, koska samat asiat voi tehdä paljon selkeämmin, jos vaan jaksaa kirjoittaa muutaman rivin lisää koodia.

Monikaan ohjelmointikieli ei kuitenkaan ole näin kaunista ja toimivaa: http://www.perlmonks.org/?node_id=45213 ;)

"Ainakin mielestäni mm. Perl, Python, Ruby tuntuu avuttomilta C:n rinnalla."

Eivät ne ole avuttomia C:hen verrattuna kuin suorituskyvyssä ja laitetasonohjelmoinnissa. Kaikessa muussa jyräävät C:een.
(tai ei ainakaan heti tule mieleen muita juttuja...)

IsoPää+++ kirjoitti:

"Ainakin mielestäni mm. Perl, Python, Ruby tuntuu avuttomilta C:n rinnalla."

Eivät ne ole avuttomia C:hen verrattuna kuin suorituskyvyssä ja laitetasonohjelmoinnissa. Kaikessa muussa jyräävät C:een.
(tai ei ainakaan heti tule mieleen muita juttuja...)

Lue lisää

Aivan. Turha kokeilla ruuvimeisselillä hakata naulaa seinään, koska vasaralla siitä suoriutuu helpommin ja tehokkaammin. Vasaralla taas on vaikea ruuvata ruuvia seinään.

IsoPää+++ kirjoitti:

"Ainakin mielestäni mm. Perl, Python, Ruby tuntuu avuttomilta C:n rinnalla."

Eivät ne ole avuttomia C:hen verrattuna kuin suorituskyvyssä ja laitetasonohjelmoinnissa. Kaikessa muussa jyräävät C:een.
(tai ei ainakaan heti tule mieleen muita juttuja...)

Lue lisää

Tekstin pyörittely niillä on sinänsä helpompaa mutta muuten aika avuttomia.

Parhaiten sopii juurikin pikku skriptien tekemiseen.

sdfsdf kirjoitti:

Tekstin pyörittely niillä on sinänsä helpompaa mutta muuten aika avuttomia.

Parhaiten sopii juurikin pikku skriptien tekemiseen.

Höpö höpö...

Kyllä Python, Ruby, Perl yms kielillä kaikki on helpompaa kuin C/C , Java, C# yms. kielillä. Sanon näin vaikka enimmäkseen koodaan C/C :aa.

Kerropas edes yksi esimerkki missä C:llä (tai muu vastaava) on helpompaa (pl. suorituskyky ja laitetaso, joissa C:llä on helpompi saada halutusti toimiva ohjelma, esim. äärimmäisen nopea tai ajuri).

IsoPää+++ kirjoitti:

Höpö höpö...

Kyllä Python, Ruby, Perl yms kielillä kaikki on helpompaa kuin C/C , Java, C# yms. kielillä. Sanon näin vaikka enimmäkseen koodaan C/C :aa.

Kerropas edes yksi esimerkki missä C:llä (tai muu vastaava) on helpompaa (pl. suorituskyky ja laitetaso, joissa C:llä on helpompi saada halutusti toimiva ohjelma, esim. äärimmäisen nopea tai ajuri).

Lue lisää

En ole tuo edellinen "sdfsdfsd" nimemerkillä kirjoittanut tyyppi mutta tuli tässä mieleen pieni koodipätkä jota oikeasti tarvitsin ja toteutin sen C:llä koska parhaiten sen hallitsen.

Onnistuu siis varmaan suurimmalla osasta kielistä hyvin nopeasti mutta koska en hallitse varsinkaan Rubya, Perliä tai Pythonia kunnolla niin kysynkin miten tehdään jollain näistä kielistä ohjelma joka dumppaa tiedoston hexana ulos.

C:llä onnistuu itseasiassa muutamalla koodirivillä. Omani on 2 riviä pitkä jos ei lasketa includea ja main funktioon meneviä rivejä.

sdfsfsd kirjoitti:

En ole tuo edellinen "sdfsdfsd" nimemerkillä kirjoittanut tyyppi mutta tuli tässä mieleen pieni koodipätkä jota oikeasti tarvitsin ja toteutin sen C:llä koska parhaiten sen hallitsen.

Onnistuu siis varmaan suurimmalla osasta kielistä hyvin nopeasti mutta koska en hallitse varsinkaan Rubya, Perliä tai Pythonia kunnolla niin kysynkin miten tehdään jollain näistä kielistä ohjelma joka dumppaa tiedoston hexana ulos.

C:llä onnistuu itseasiassa muutamalla koodirivillä. Omani on 2 riviä pitkä jos ei lasketa includea ja main funktioon meneviä rivejä.

Lue lisää

No, kokeillaan Rubylla, jota en edes kunnolla osaa (joten kuukletin). Tässäpä koko ohjelma:

#!/usr/bin/env ruby

File.open(ARGV[0]).each_byte { |c| printf "%.2X ", c }
puts #rivinvaihto loppuun

Siis jos tiedostossa text.txt on "abc", niin terminaalissa tulostaa:

./hex.rb text.txt
61 62 63 0A 0A

Hmm... Rubyn printf vastaa näköjään pitkälti C:n printf:ää... Tietysti pitäisi olla tarkistus että annetaan yksi argumentti ja tulostus pitäisi laittaa 10 hexaa per rivi tai jotain.

Oliko muita ehdotuksia?

IsoPää+++ kirjoitti:

No, kokeillaan Rubylla, jota en edes kunnolla osaa (joten kuukletin). Tässäpä koko ohjelma:

#!/usr/bin/env ruby

File.open(ARGV[0]).each_byte { |c| printf "%.2X ", c }
puts #rivinvaihto loppuun

Siis jos tiedostossa text.txt on "abc", niin terminaalissa tulostaa:

./hex.rb text.txt
61 62 63 0A 0A

Hmm... Rubyn printf vastaa näköjään pitkälti C:n printf:ää... Tietysti pitäisi olla tarkistus että annetaan yksi argumentti ja tulostus pitäisi laittaa 10 hexaa per rivi tai jotain.

Oliko muita ehdotuksia?

Lue lisää

Käsitteeleekö tuo tiedostot "text" moodissa vai binäärinä.

Yleisesti "text" moodi I/O:ssa on perustavanlaatuinen suunnitteluvirhe.
mm. Windowsin terminaali kärsii tästä. Perusmoodissa stdin ja stdout on "teksti" moodissa ja ohjelmalle ei voi putkittaa binäärejä ilman että ne hajoaa.

Ongelman onneksi voi korjata ainakin C/C :ssa muuttamalla erillisellä posix funktiolla streamien moodin binääriksi.

Unix/Linux alustoilla ei tälläisiä typeryyksiä ole.

sdfsdfs kirjoitti:

Käsitteeleekö tuo tiedostot "text" moodissa vai binäärinä.

Yleisesti "text" moodi I/O:ssa on perustavanlaatuinen suunnitteluvirhe.
mm. Windowsin terminaali kärsii tästä. Perusmoodissa stdin ja stdout on "teksti" moodissa ja ohjelmalle ei voi putkittaa binäärejä ilman että ne hajoaa.

Ongelman onneksi voi korjata ainakin C/C :ssa muuttamalla erillisellä posix funktiolla streamien moodin binääriksi.

Unix/Linux alustoilla ei tälläisiä typeryyksiä ole.

Lue lisää

Enpä tiedä kuinka on, tarttis varmaan testaa... miten se ongelma ilmenee?

Ja toi voisi tosiaan olla binääri-moodissa:
File.open(ARGV[0], "rb").each_byte { |c| printf "%.2X ", c }

Tuolla http://stackoverflow.com/questions/130948/ruby-convert-file-to-string sanotaan että ehkä voi olla jopa tarpeen (miksiköhän?):
s = File.open(filename, 'rb') { |f| f.read }

Noin Rubyn File.open- yms.- kutsut on kirjoitettu C:llä, niin että ovatkohan ottaneet huomioon. On siellä ainakin #ifdef _WIN32-herjaa väliin työnnetty:
http://www.ruby-doc.org/doxygen/1.8.4/file_8c-source.html

Josta tulee mieleen että käyttöjärjestelmän läheisiä juttuja kutsuttaessa C:llä homma on varmaan helpompaa (koska KJ on yleensä C:llä koodattu) tai tietysti voi yrittää FFI-systeemillä.

IsoPää+++ kirjoitti:

Enpä tiedä kuinka on, tarttis varmaan testaa... miten se ongelma ilmenee?

Ja toi voisi tosiaan olla binääri-moodissa:
File.open(ARGV[0], "rb").each_byte { |c| printf "%.2X ", c }

Tuolla http://stackoverflow.com/questions/130948/ruby-convert-file-to-string sanotaan että ehkä voi olla jopa tarpeen (miksiköhän?):
s = File.open(filename, 'rb') { |f| f.read }

Noin Rubyn File.open- yms.- kutsut on kirjoitettu C:llä, niin että ovatkohan ottaneet huomioon. On siellä ainakin #ifdef _WIN32-herjaa väliin työnnetty:
http://www.ruby-doc.org/doxygen/1.8.4/file_8c-source.html

Josta tulee mieleen että käyttöjärjestelmän läheisiä juttuja kutsuttaessa C:llä homma on varmaan helpompaa (koska KJ on yleensä C:llä koodattu) tai tietysti voi yrittää FFI-systeemillä.

Lue lisää

Ruby vaikuttaa varsin mielyttävältä kieleltä.

Lisäksi Lua ja Python vaikuttaa kokelemisen arvoisilta.

C parroille parhautta on "Pike" niminen kieli jonka soisi yleistyvän.

http://en.wikipedia.org/wiki/Pike_(programming_language)
http://pike.ida.liu.se/

IsoPää+++ kirjoitti:

No, kokeillaan Rubylla, jota en edes kunnolla osaa (joten kuukletin). Tässäpä koko ohjelma:

#!/usr/bin/env ruby

File.open(ARGV[0]).each_byte { |c| printf "%.2X ", c }
puts #rivinvaihto loppuun

Siis jos tiedostossa text.txt on "abc", niin terminaalissa tulostaa:

./hex.rb text.txt
61 62 63 0A 0A

Hmm... Rubyn printf vastaa näköjään pitkälti C:n printf:ää... Tietysti pitäisi olla tarkistus että annetaan yksi argumentti ja tulostus pitäisi laittaa 10 hexaa per rivi tai jotain.

Oliko muita ehdotuksia?

Lue lisää

tosiaan eka komentoriviargumentti? Jos on, mistä saa ohjelman nimen (hex.rb)?

22 kirjoitti:

tosiaan eka komentoriviargumentti? Jos on, mistä saa ohjelman nimen (hex.rb)?

En ota tuohon kantaa mutta eikös kaikista helpointa olisi ottaa suoraa järjestelmän stdinistä redirectilä se tiedosto sisään.

22 kirjoitti:

tosiaan eka komentoriviargumentti? Jos on, mistä saa ohjelman nimen (hex.rb)?

ARGV[0] on ensimmäinen argumentti ei tiedoston nimi.

Tiedoston nimi on rubyssä yksi globaali muuttujuista.. olikohan se nyt sitten "$0"..

http://ideone.com/Q9C7y

22 kirjoitti:

tosiaan eka komentoriviargumentti? Jos on, mistä saa ohjelman nimen (hex.rb)?

Ohjelman nimi löytyy muuttujasta $0. Kai ne ovat erikseen että voi tehdä luupissa mukavammin:

ARGV.each { |a| puts a }

IsoPää+++ kirjoitti:

Ohjelman nimi löytyy muuttujasta $0. Kai ne ovat erikseen että voi tehdä luupissa mukavammin:

ARGV.each { |a| puts a }

Voisitko avata tuon koodinpätkän C-ohjemoijalle pala palalta.

Näissä skriptikielissä on vähän esoteerisyyttä koska voidaan helpolla tehdä lyhyitä rivejä jotka tekevät yksistään monta asiaa ja lopulta ne näyttävät melko kryptisiltä rimpsuilta..

Kyseinen pätkä nyt ei hirveänk kryptinen lyhykäsyydessään ole mutta ihmetyttää tuo erikoinen syntaxi.

Mitä tarkoittaa |0| ?

sdfsdfs kirjoitti:

Voisitko avata tuon koodinpätkän C-ohjemoijalle pala palalta.

Näissä skriptikielissä on vähän esoteerisyyttä koska voidaan helpolla tehdä lyhyitä rivejä jotka tekevät yksistään monta asiaa ja lopulta ne näyttävät melko kryptisiltä rimpsuilta..

Kyseinen pätkä nyt ei hirveänk kryptinen lyhykäsyydessään ole mutta ihmetyttää tuo erikoinen syntaxi.

Mitä tarkoittaa |0| ?

Lue lisää

ARGV on taulukko (globaali)
each on Array-luokan metodi, joka käy läpi kaikki taulukon elementit. for-luupilla saa saman C:ssä.
{...} on blokki eli lohko. Myös do ... end on blokki.
|a| on blokin parametri

Omituista lienee se että blokki on todellisuudessa nimetön funktio (oikeammin proseduuri) eli siis vain eri kuin koodiblokki C:ssä. Blokki siis välitetään metodille (esim. each) joka jossain vaiheessa kutsuu blokkia. Funktio-pointterin antaminen funktiolle taitaa olla C:ssä lähinnä tätä tai makro jossa annetaan parametrina koodi-blokki.

Esimerkiksi voimme tehdä Array-luokalle oman each-metodin (kyllä, luokkia ei ole 'lukittu' Rubyssa):

class Array
   def my_each
      if block_given?
        for i in 0...size
          item = self[i]
          yield item
        end
      end
      return nil
   end
end

Esim:

["a", "b", "c"].my_each { |c| puts c } # printtaa a b c

Jolloin yield kutsuu blokkia ja item sijoitetaan c-muuttujaan.

Näkyvyysalue (scope) on blokin ulkopuolelle:
sum = 0
[1, 2, 3].my_each { |i| sum = i }
puts sum #printtaa 6

Nerokasta, eikö vain.

Lisää selitystä aiheeseen:

http://www.cs.helsinki.fi/u/wikla/OKP/OppaatK07/ruby/#lohkot
http://ruby-doc.org/docs/ProgrammingRuby/
(kohdassa Containers, Blocks, and Iterators)

Tarkemmin:
http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/

Matsumoton haastattelu:
http://www.artima.com/intv/closures.html

Tietysti pitää itse koodata muutamia metodeja/funktioita ennen kuin homman tajuaa...

IsoPää+++ kirjoitti:

ARGV on taulukko (globaali)
each on Array-luokan metodi, joka käy läpi kaikki taulukon elementit. for-luupilla saa saman C:ssä.
{...} on blokki eli lohko. Myös do ... end on blokki.
|a| on blokin parametri

Omituista lienee se että blokki on todellisuudessa nimetön funktio (oikeammin proseduuri) eli siis vain eri kuin koodiblokki C:ssä. Blokki siis välitetään metodille (esim. each) joka jossain vaiheessa kutsuu blokkia. Funktio-pointterin antaminen funktiolle taitaa olla C:ssä lähinnä tätä tai makro jossa annetaan parametrina koodi-blokki.

Esimerkiksi voimme tehdä Array-luokalle oman each-metodin (kyllä, luokkia ei ole 'lukittu' Rubyssa):

class Array
   def my_each
      if block_given?
        for i in 0...size
          item = self[i]
          yield item
        end
      end
      return nil
   end
end

Esim:

["a", "b", "c"].my_each { |c| puts c } # printtaa a b c

Jolloin yield kutsuu blokkia ja item sijoitetaan c-muuttujaan.

Näkyvyysalue (scope) on blokin ulkopuolelle:
sum = 0
[1, 2, 3].my_each { |i| sum = i }
puts sum #printtaa 6

Nerokasta, eikö vain.

Lisää selitystä aiheeseen:

http://www.cs.helsinki.fi/u/wikla/OKP/OppaatK07/ruby/#lohkot
http://ruby-doc.org/docs/ProgrammingRuby/
(kohdassa Containers, Blocks, and Iterators)

Tarkemmin:
http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/

Matsumoton haastattelu:
http://www.artima.com/intv/closures.html

Tietysti pitää itse koodata muutamia metodeja/funktioita ennen kuin homman tajuaa...

Lue lisää

Ihmettelen hiukan miksi skriptikielissä käytetään sanallisia blokki elementtejä.

Aaltosulkee tai mitkä tahansa yhden merkin sulkeet olisivat selkeämmät ja helpommin tulkattavat. Ei tuhlata turhaan tilaa ja arvokasta tulkkausnopeutta.

sdfsfsfsdfs kirjoitti:

Ihmettelen hiukan miksi skriptikielissä käytetään sanallisia blokki elementtejä.

Aaltosulkee tai mitkä tahansa yhden merkin sulkeet olisivat selkeämmät ja helpommin tulkattavat. Ei tuhlata turhaan tilaa ja arvokasta tulkkausnopeutta.

Lue lisää

Ööö... missähän kohtaa käytetään "sanallisia blokki elementtejä"?

IsoPää+++ kirjoitti:

Ööö... missähän kohtaa käytetään "sanallisia blokki elementtejä"?

class Array
def my_each
if block_given?
for i in 0...size
item = self[i]
yield item
end
end
return nil
end
end

sdfsfsfsdfs kirjoitti:

Ihmettelen hiukan miksi skriptikielissä käytetään sanallisia blokki elementtejä.

Aaltosulkee tai mitkä tahansa yhden merkin sulkeet olisivat selkeämmät ja helpommin tulkattavat. Ei tuhlata turhaan tilaa ja arvokasta tulkkausnopeutta.

Lue lisää

""Ei tuhlata turhaan tilaa ja arvokasta tulkkausnopeutta.""

Täh? Et taida olla koskaan toteuttanut tulkkia tai kääntäjää? Se, että kuinka monta merkkiä pitkä yksi tokeni on ei todellakaan merkitse yhtään mitään tulkkausnopeudessa. Eri asia olisi toki jos blokin alku- ja loppumerkit olisivat jotain kilotavun pituisia merkkijonoja, jolloin tiedostonlukunopeus alkaisi olla merkityksellistä.

begin/end on helpompi lukea kuin {}. Pythonissa ei muuten ole ollenkaan loppumerkkejä vaan pelkästään sisennykset merkitsevät. Käytännössä tämä aiheuttaa sen, että sisäkkäisen luuppien loppukohtien arvaaminen on yhtä painajaista,

pkjppk kirjoitti:

class Array
def my_each
if block_given?
for i in 0...size
item = self[i]
yield item
end
end
return nil
end
end

Lue lisää

Ahaa, tarkoitit että koodilohkon lopetus on "sanallinen" siis tässä Rubyn tapauksessa "end". Tuskin sillä on mitään merkitystä onko se yksi merkki vai kolme, tavukoodiksi se kuitenkin (yleensä) käännetään.

Rubyn ja monen muu "skripti"-kielen hitaus johtuu ihan muista jutuista (dynaaminen tyypitys kai on se suurin syy).

jhjkhuhuihui kirjoitti:

""Ei tuhlata turhaan tilaa ja arvokasta tulkkausnopeutta.""

Täh? Et taida olla koskaan toteuttanut tulkkia tai kääntäjää? Se, että kuinka monta merkkiä pitkä yksi tokeni on ei todellakaan merkitse yhtään mitään tulkkausnopeudessa. Eri asia olisi toki jos blokin alku- ja loppumerkit olisivat jotain kilotavun pituisia merkkijonoja, jolloin tiedostonlukunopeus alkaisi olla merkityksellistä.

begin/end on helpompi lukea kuin {}. Pythonissa ei muuten ole ollenkaan loppumerkkejä vaan pelkästään sisennykset merkitsevät. Käytännössä tämä aiheuttaa sen, että sisäkkäisen luuppien loppukohtien arvaaminen on yhtä painajaista,

Lue lisää

Kylläpäs koodin kirjoitusasu vaikuttaa suoraan tulkkausnopeuteen ellei tulkki itse aja ensin lähdekoodille jonkinlaista tiivistystä tai bittikoodimuunnosta.

Ja tietysti mitä enemmän on tilaa tuhlattu koodin ulkoasuun sitä hitaammin tiivistys ja tulkkaus jokatapauksessa tapahtuu.

Mielestäni { } on huomattavasti helpomi lukea kuin begin / end yms.. härveleitä. Tämä tietysti tulee C taustastani joten ei päde kaikille.

sdfsdfsdffsdf kirjoitti:

Kylläpäs koodin kirjoitusasu vaikuttaa suoraan tulkkausnopeuteen ellei tulkki itse aja ensin lähdekoodille jonkinlaista tiivistystä tai bittikoodimuunnosta.

Ja tietysti mitä enemmän on tilaa tuhlattu koodin ulkoasuun sitä hitaammin tiivistys ja tulkkaus jokatapauksessa tapahtuu.

Mielestäni { } on huomattavasti helpomi lukea kuin begin / end yms.. härveleitä. Tämä tietysti tulee C taustastani joten ei päde kaikille.

Lue lisää

""Kylläpäs koodin kirjoitusasu vaikuttaa suoraan tulkkausnopeuteen ellei tulkki itse aja ensin lähdekoodille jonkinlaista tiivistystä tai bittikoodimuunnosta.""

Niin mutta kun nykyajan tulkit toimivat aina niin, että se ensin pistää sen leksikaalisen analysaattorin läpi ja sen jälkeen parserin läpi, jonka jälkeen se ajetaan. Jos vaikka for-luupin lopussa on "end", se luetaan ja tulkitaan tasan kerran eikä esimerkiksi joka luupilla. Teoriassa toki kolmen merkin lukeminen on joskus nopeampaa kuin yhden merkin, mutta ei nykyajan systeemeillä käytännössä, koska joka tapauksessa sieltä levyltä pitää lukea datat jossain kilon paloissa vähintään. C64-basic aikana tilanne oli toki toinen.

""Mielestäni { } on huomattavasti helpomi lukea kuin begin / end yms.. härveleitä. Tämä tietysti tulee C taustastani joten ei päde kaikille.""

Mielestäni { } on kyllä kiva siitä, että se on nopea kirjoittaa, mutta oikeasti helppolukuisin on tyyliin if ... endif, for ... endfor. Kyllähän C:ssäkin on hyvää ohjelmointityyliä tehdä näin:

for (i = 0; i < 10; i ) {

} /* for */

Jahas ja suomi24 imaisi sisennykset..

{{{{{}}}}}

for(i = 0; i < 10; i)
{
/* sisennys neljä välilyöntiä */
}

dsfsfsdf kirjoitti:

for(i = 0; i < 10; i)
{
/* sisennys neljä välilyöntiä */
}

PASKA.

dsfsfsdf kirjoitti:

for(i = 0; i < 10; i)
{
/* sisennys neljä välilyöntiä */
}

EI tuo näyttää inhottavalta kun on tuon funktion (for)-perässä heti sulku, ja puuttuu tuo "{" for-lausekkeen päätteestä..

for (i=0;i

näinnätimpää.. kirjoitti:

EI tuo näyttää inhottavalta kun on tuon funktion (for)-perässä heti sulku, ja puuttuu tuo "{" for-lausekkeen päätteestä..

for (i=0;i

Suomi24 feilaa sisennykset täysin.

Edellä yritettiin seuraavaa:

for (i=0;i

dfsdfsdfsdfsd kirjoitti:

Suomi24 feilaa sisennykset täysin.

Edellä yritettiin seuraavaa:

for (i=0;i

for (i=0;i

ööööö----- kirjoitti:

for (i=0;i

for (i=0;i

ööööö----- kirjoitti:

for (i=0;i

Millä kikkailulla siat toimimaan.

sfsfsdfsdf kirjoitti:

Millä kikkailulla siat toimimaan.

Aaltosulun katsoin tuolta (html number 123): http://www.ascii.cl/htmlcodes.htm

Ja välilyöntinä http://www.htmlbasictutor.ca/non-breaking-space.htm

Toimiskohan html-numero 160 myös nbsp:n sijasta:
    //jos on sisennyt niin toimii, muutoin ei

öööööö------ kirjoitti:

Aaltosulun katsoin tuolta (html number 123): http://www.ascii.cl/htmlcodes.htm

Ja välilyöntinä http://www.htmlbasictutor.ca/non-breaking-space.htm

Toimiskohan html-numero 160 myös nbsp:n sijasta:
    //jos on sisennyt niin toimii, muutoin ei

Lue lisää

Ihan kuin söisi pari 160:stä, kokeillaan:
 //yksi space
  //kaksi spacea
   //kolme spacea
    //4 spacea
     //5 spacea

öööööö----- kirjoitti:

Ihan kuin söisi pari 160:stä, kokeillaan:
 //yksi space
  //kaksi spacea
   //kolme spacea
    //4 spacea
     //5 spacea

Eipä syökään, optinen harha varmaan tai fontti hämää...

öööööö------ kirjoitti:

Aaltosulun katsoin tuolta (html number 123): http://www.ascii.cl/htmlcodes.htm

Ja välilyöntinä http://www.htmlbasictutor.ca/non-breaking-space.htm

Toimiskohan html-numero 160 myös nbsp:n sijasta:
    //jos on sisennyt niin toimii, muutoin ei

Lue lisää

Minä kun oletin että tämä foorumi syö nuo html entity kooditkin pois. Muistaakseni olen kokeillutkin joskus mutta ei sitten näköjään. :D

Suhteellisen paska kyllä tämä systeemi.