Skandinaaviset kirjaimet C:llä

Anonyymi

Olen vasta-alkaja ja joitakin yksinkertaisia ohjelmia kirjoitellut CodeBlocksilla. Ohjelmien toiminnallisuuden osalta ei ole ollut ongelmaa, mutta on vain ankean näköistä, kun ä- ja ö-kirjaimet muuttuvat käännettäessä õ ja jakomerkiksi. Ääkköset siis käytössä vain tulostuksissa, ei muuttujissa.

Tällaista ohjeistusta löytyi nopealla googlauksella: "kokeileppas korvata ä = \x84 ja ö = \x94 eli esim. ääkköset --> \x84\x84kk\x94set.".

Onko olemassa muita (yksinkertaisia) keinoja esim. kääntäjien tai ohjelmointialustan asetuksien osalta, joilla ongelman saisi ratkaistua? Ja kuten mainitsinkin, ohjelmat kyllä pelittää, mutta kivempi olisi, jos saisi tekstit näkymään kunnolla. Etenkin, kun suomen kielessä varsin runsaasti noita ääkkösiä käytössä.

28

2367

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
    • Anonyymi

      Pitäisikö tämä tulostaa jotain outoa:

      #include <stdio.h>
      int main()
      {
      printf("Tämä näytetään Äidille!");
      return 0;
      }

      • Anonyymi

        Juu, elikkäs tuon tuloste näyttäisi seuraavalta: Tõmõ nõytetõõn õidille!
        tai "syötä luku" = sy÷tõ luku

        Niin toiveissa olisi, että saisi jotenkin ketterästi tuon tulostumaan ihan normaalisti suomeksi. Ja tosiaan jos jokainen ä ja ö lauseen sisällä pitäisi korvata noilla \x84 ja \x94, taidan mieluummin yrittää vain ummistaa silmäni niiltä ja olla välittämättä.


    • Anonyymi

      Kokeilin Netbeans IDE:ssä tulostaa printf("åäö");
      Se tulostui oikein.
      Katsoin sitten projektin asetuksia. Siellä oli General kohdassa Encoding ISO-8859-1
      Windows kyseessä.

      Tämä oli vain kokeillu.

      • Anonyymi

        mutta tämä oli IDE tulostusikkunassa. Pitää tsekata komentoriviltä myös. Linuxissa saattaa olla sama, mutta ainakin Javaa koodatessa windowsissa nuo eivät ole samat asiat tai tulostus ei ole aina samanlainen idessä ja käyttöjärjestelmässä.

        Oikeastaa ei ehkä olisi pitänyt vastata kun en tiedä.
        Ehkä tämä triggeröi jonkun asiantuntijan vastaamaan.


    • Anonyymi

      CodeBlocks asetukset

      Mene tämän kuvan ( https://s3.gifyu.com/images/Start-here---CodeBlocks-17.12_084.png ) mukaisesta valikosta.

      Tarkista onko samat asetukset kuin tässä kuvassa ( https://s3.gifyu.com/images/Configure-editor_083.png )

      Nämä ovat oletusasetuksia jotka syntyvät ohjelman asennuksessa. Minun ei ole tarvinnut muuttaa kuin: "xterm -T $TITLE -e" => "xfce4-terminal -T $TITLE -x"

      Lopputulos näyttää tältä: https://s3.gifyu.com/images/skandit.c---CodeBlocks-17.12_085.png

      Tehty ja testattu Linux Mint 19 Xfce 64-bit ympäristössä.

    • Anonyymi

      Jätit kertomatta, ajatko kääntämääsi C -ohjelmaa Windowsissa vai linuxissa.

      Nyky -linuxeissa merkkikoodaus on käytännössä aina UTF-8 (joka on yksi UNICODE:n tallennusmuodoista).

      Vanhoissa linuxeissa (esim. Debian 3.1 ja Debian woody) merkkikoodaus on ISO-8859-1 (joka on melkein, mutta ei ihan, sama asia kuin Windows-1252).

      Windows-1252:ssa on esim. euron merkki €, mutta ISO-8859-1:stä se puuttuu kokonaan! Sitten on vielä ISO-8859-1 5, jossa kyllä on euron merkki €, mutta eri koodilla kuin Windows-1252:ssa.

      Windowseissa taas tilanne on hyvinkin omalaatuinen!

      Jos käytät uudempia W -loppuisia windows API -funktioita, silloin merkkikoodaus on UTF-16LE (jota Microsoft harhaanjohtavasti kutsuu nimellä UNICODE, vaikka se on vain yksi vaihtoehtoisista UNICODEn koodaustavoista).

      Jos käytät vanhempia A-loppuisia windows API -funktioita, silloin merkkikoodaus on yleensä Windows-1252 (tästä voi olla poikkeuksia, jos asennat koneellesi esim. Thai, venäjän, kiinan, tai japaninkielisen Windowsin).

      Ylläoleva pätee graafisiin eli GUI -sovelluksiin.

      MUTTA:

      Windows -komentoriviohjelmissa (joita ajetaan cmd.exe -komentotulkin avulla),

      oletusmerkkikoodaus on CP850 (tai joissain tapauksissa CP437).

      Jos siis kirjoitat Windows notepadilla tai vastaavalla lähdekoodin, niin win10:ä vanhemmissa versioissa oletus on tallentaa Windows-1252 -merkkikoodauksella, ja kun komentoriviohjelmissa oletusmerkkikoodaus on CP850, niin tämän takia Ä j Ö (ja eräät muutkin merkit) vääristyvät, kun ohjelma on koodattu eri merkkikoodauksella kuin sitä ajetaan.

      CharToOemBuff
      OemToCharBuff

      ks. ylläolevat 2 Windows API -funktiota.

      Linuxilla taas: käytä samaa merkkikoodausta ohjelmissasi kuin mikä on käyttämäsi linux -käyttöjärjestelmän oletus.

    • Anonyymi

      tuollainen toimii hauskasti terve äidille näin tiekokone toimii :D

      Kuin taskulaskin oikeasti on, itsekin käytän monissakin jutuissa tietokonetta taulukkolaskentajutuissa, helpottaa..

      Joku grafiikkakiihdytin ja jotain jo9ku mikä edes on joku direct3d ja sellaiset jutut, niin Ei tietääkään ollenkaan jos tietokoneeta on muutenkin hyötyä tavallisissa asioissa.

    • Anonyymi

      voisit käyttää suoraa c-kielen konversiota eli mitenkähän se menikään ihan pikku-funktio... jo ku se oli ihan 2 kirjainta vain jos osaa heh.

      ..mietin se oli, no en muista niin lapselista..

      ascctoong tai lo0ngtoiasci jotain... joku tuon tyyppinen ja SITTEN mainitse tuollaisissa merkkijonoissa aina 'L' alkuun niin tajuaa että on sitä kiinalaisten kirjoitusta, eli monimerkkistä...

    • Anonyymi

      Itse kun niin noita grafiikkakiihdyttimien juttuja katson niin aina kysyn väyläajurilta että onko minkälisia kelvollisia väylällä, itselläni nyt ilmoittaa koodissa kun debuggaankin että on 2kpl AMD Radeon käyttävät PCI-E -väylää tällä hekellä ;D

    • Anonyymi

      Riippuu ympäristöstä, mutta oletan, että olet Windowsissa koska code blocks käytössä.

      Windowsinkin konsolin saa muutettua UTF-8:ia käyttämään.

      Kokeiles vaikka vaihtaa code page UTF-8:ksi windowsissa.

      • Anonyymi

        "Kokeiles vaikka vaihtaa code page UTF-8:ksi windowsissa."

        Joka teoriassa tehdään näin:

        chcp 65001

        Huomaa: Windowsin komentotulkin tuki UTF-8:lle (joka aktivoidaan em. chcp 65001 -komennolla), ei välttämättä toimi 100% oikein !

        Komentoriviä ei alunperin ole suunniteltu toimimaan UNICODE / UTF-8 -moodissa, joten tuki tuolle on vain osittainen, eli jos käytät tuota, varaudu siihen, että kaikki ei siltikään toimi 100% oikein !

        varsinaisista Windows API -funktioista on monista A -versio (Ansi = yleensä windows-1252) ja W -versio (UNICODE = UTF16LE -versio).

        Noita löytyy myös konsolin hallintaan.

        Eli käyttämällä W -versiota pystyt lukemaan ja kirjoittamaa konsolille / -lta unicode -muodossa.

        Huomaa, että eräät merkit (kuten esim. aramean kielen merkin tai shakkinappuloiden symbolit) ovat Basic Multilingual Page:n (= ensimmäiset 65536 koodia) ulkopuolella, ja vaativat siksi UTF-16 -systeemissä ns. surrogate -parin käyttöä.

        Koska näitä käytetään varsin vähän, ne ovat pääosin huonosti testattuja, ja siksi niissä saattaa esiintyä yllättäviä virheitä.

        Periaatteessa konsolissa Backspacen pitäisi poistaa 1 merkki.

        Mutta jos kyseessä on aramean kielen merkki tai shakkinappulan symboli, on epäselvää, poistaako Backspace yhden merkin vai ½ merkkiä (jälkimmäisessä tapauksessa joutuu tällöin painamaan 2 Backspacea yhden merkin poistamiseksi).

        Malliesimerkki huonosta koodaustyöstä, kun asioita ei viitsitä testata kunnolla.

        1 aramean kielen merkki on nimenomaan 1 merkki, vaikka se UTF-16 esitysmuodossa koostuukin kahdesta surrogatesta, eli 2 x 16 bittiä = 4 tavua.


    • Anonyymi

      Manjaro Linuxissa Code::Blocks IDE asennetaan ellei ennestään jo ole näin:

      pacman -S codeblocks

    • Anonyymi

      Jotain kautta pitää saada tietää, mitä encoding:ia terminaalisi käyttää. Linuxissa tämä on usein kerrottu ympäristömuuttujien LANG/LANGUAGE kautta, joista toinen kertoo kielen ja toinen käytetyn merkistö-kodauksen.
      declare -x LANG="fi_FI.UTF-8"
      declare -x LANGUAGE="fi"
      Tämän perusteella, pitäisi ohjelmasi siis päättää, mitä merkkejä se käyttäjälle näyttää. Editori, jolla ohjelmaasi työstät käyttää tietysti myös jotain encoding-asetusta, jonka perusteella se osaa näyttää näytöllä lähdekoodin. Näillä tietysti ei ole mitään tekemistä sen kanssa välttämättä, mitä varten ohjelmaasi teet! Koodauksen saa siis menemään oikein tietämällä, millä sen tekee ja millä sen näyttää.
      utf-8 koodaus tuli muistaakseni ensin web-sovelluksissa vastaan, eli joutui miettimään merkistökoodausta vastaanotetun url-pyynnön oheistietojen perusteella. Sieltä se laajeni yleispäteväksi tavaksi toteuttaa merkistökoodausta ilman koodisivujen yms. sellaisten tuntemusta.

      • Anonyymi

        Selityksesi tukee ajatusta, ettei C-kieli mahdollista koodisivun valintaa, jos näin on eihän tuolla kielellä mitään tee.


      • Anonyymi
        Anonyymi kirjoitti:

        Selityksesi tukee ajatusta, ettei C-kieli mahdollista koodisivun valintaa, jos näin on eihän tuolla kielellä mitään tee.

        C-kieli ei tiedä mitään koodisivuista - tosi on. Sillä silti voi koodata millä tahansa koodisivulla, mutta tämä ei vaikuta järjestelmän toimintaan millään tavalla - koodisivu on käyttöjärjestelmän ominaiusuus ja pitää asettaa käyttöjärjestelmän toimesta..


      • Anonyymi
        Anonyymi kirjoitti:

        C-kieli ei tiedä mitään koodisivuista - tosi on. Sillä silti voi koodata millä tahansa koodisivulla, mutta tämä ei vaikuta järjestelmän toimintaan millään tavalla - koodisivu on käyttöjärjestelmän ominaiusuus ja pitää asettaa käyttöjärjestelmän toimesta..

        Autuaita ovat puupäät sillä he eivät huku.


    • Anonyymi

      Tarvitsikohan joku oikeasti tapaa tulostaa kaikki aakkoset ja öökköset C-kielellä?

    • Anonyymi

      Tässä yksi esimerkki kuinka ASCII merkit C:llä tulostuu, eivät ole oikeassa järjestyksessä. Testaa miten ääkkösten käy kun suljet ulos tämän rivin: [setlocale (LC_ALL, "fi_FI.utf8");]

      #include <stdio.h>
      #include <locale.h>
      #include <wchar.h>

      int main() {

      wchar_t ch[] = L"!\"#$%&'()* ,-./0123456789:;<=>?@[\\]^_`{|}~abcdefghijklmnopqrsštuvwxyzžåäöABCDEFGHIJKLMNOPQRSŠTUVWXYZŽÅÄÖ";
      setlocale (LC_ALL, "fi_FI.utf8");

      for ( int i = 0; i < 104; i ) {
      wchar_t *p = &ch[i];
      printf( "%d\t%lc\n", i, *p );
      }
      return 0;
      }

    • Anonyymi

      Ei tarvitse muutella kuin vain 1 asetus kääntäjässä että hyväksyy kaikki kirjiameta, yhden rasitn laitto vain, turha niitä napsutella erikseen heheheh :D

      Itselläni hyvä kun juurikin directx ja video-kuvajuttuja ja ääni juttuja ja ohjelma koodeja teen, niin C-kielellä tietysti, niin hyvä kun tunget johonkin MFC-koodin sekaan:

      short int muuttuja;

      _asm {
      mov ax,muuttuja
      xchg al,ah
      mov muuttuja,ax
      ]

      • Anonyymi

        _asm {
        mov ax,muuttuja
        xchg al,ah
        mov muuttuja,ax
        ]

        Hienoa, joku ymmärtää assembleristakin edes jotakin!

        MUTTA:

        Jos C -kääntäjäsi on gcc (tai mingw-gcc) niin noissa (ikävä kyllä, jotain fanatismiahan tuokin on!) oletuksena on (ihan järkyttävän epälooginen ja hankala) AT&T -syntaksi.
        Sensijaan, että alkaisit opiskella tuon helvetillisen syntaksin kummallisuuksia ja epäloogisuuksia, on järkevämpää, että:

        1. asetat direktiivillä syntaksin intel -moodiin

        2. kirjoitat haluamasi assembly -käskyt

        ja lopuksi (todella tärkeää):

        3. asetat direktiivillä syntaksin takaisin at&t -moodiin !
        (tärkeää, koska muuten gcc -kääntäjä sekoaa totaalisesti, se kun käyttää sisäisesti aina at&t -syntaksia).

        gcc -kääntäjän käyttäjän vaikeudet eivät edes lopu tähän:
        seuraavaksi käsittämätön "constrains" -säännöstö, jolla:

        1. kerrotaan kääntäjälle, mitä rekistereitä assembly -koodisi muuttaa

        2. määritetään input -ja output -parametrit niin, että tiedetään (jos tiedetään, kun dokumentointi on niin vaikeaselkoista), mihin rekistereihin parametrit menevät ja mihin rekistereihin tulokset pitää jättää!

        Olisi säästytty monelta murheelta, jos gcc:n (ja Microsoftin C -kääntäjän) tekijät ottaisivat mallia Embarcadero C -kääntäjän säännöistä:

        32-bit windows:

        1. parametri menee aina -> EAX
        2. parametri menee aina -> EDX
        3. parametri menee aina -> ECX

        Ja 64-bit paluuarvon tulee olla EDX:EAX -rekisteriparissa.

        huomaa: JOS kyseessä on luokan metodi, niin osoitin luokan ilmentymään on ensimmäinen näkymätön parametri, jolloin 1. näkyviin kirjoitettu parametri onkin itseasiassa 2. parametri em. sääntöjen mukaisesti. Selkeää, ja 100% ennustettavaa = ei arvailua, kokeilua ja virheitä !

        Sopii kysyä: Miten vain ja ainoastaan Embarcaderon (ja sen edeltäjän Borlandin) kääntäjätiimiin on onnistuttu palkkaamaan loogisella ajattelulla varustettuja työntekijöitä, kun taas gcc:n vastaava säännöstö on luokattoman huonosti dokumentoitu, ja luultavasti helpompaa kuin yrittää ymmärtää kelvotonta dokumentaatiota, olisi etsiä jostakin koodia, joka käyttää intel syntaksin assemblyä gcc:llä, ja ajaa debuggerin kanssa koodia läpi selvittääkseen, miten tuo parametrien välitys gcc:ssä oikeasti toimii !

        Joku Microsoftin tuotteita paremmin tunteva voisi laittaa vastaavan yhteenvedon assemblyn oikeaoppisesta käytöstä samoin kuin olen tehnyt C Builderin ja siltä osin kuin tiedän, gcc:n vastaavista käytännöistä.

        Pahoittelen puutteita tiedoissa gcc:n osalta, mutta gcc:n kelvottoman dokumentaation takia minulla ei ole laadukkaampia tietoja asiasta !

        Katsotaanpa, osaako joku gcc -osaaja täydentää tietoja tältä osalta:

        Jos gcc:llä (32-bit windows -versio) halutaan kirjoittaa intel -syntaksin assemblya, niin:

        __int64 esimerkkifunktio(uint32 A32, uint32 D32, uint32 C32) {

        // ... assembly -koodia (intel syntax) tähän

        }

        MITEN nuo constraints -systeemit pitää kirjoittaa, jotta homma toimisi samoin kuin se Embarcadero C Builderissa toimii jo vakiona, eli:

        A32 -> EAX
        D32 -> EDX
        C32 -> ECX

        ja lopulta kun assembly -koodi jättää 64-bit tuloksen EDX:EAX -rekisteripariin, niin se pitäisi saada näkymään __int64 -tyyppisenä funktion paluuarvona !

        Saisi joku keksiä "laiteriippumattoman" assemblyn....

        ja EI, C -kieli EI OLE laiteriippumatonta assemblya, vaikka joku C -kielifani sellaista toisinaan yrittääkin väittää. esim. C -kieli ei tue Carry Flag:in käyttöä !

        assemblyllä on helppo kirjoittaa:

        add EAX, [dword ptr Luku2]
        adc EDX, [dword ptr Luku2 4]

        Tuo summaa EDX:EAX -rekisteripariin ko rekisteriparin vanhan sisällön ja uint64 -tyyppisen muuttujan Luku2 sisällön ja JOS sisältö ei mahdu 64 bittiin, niin asettaa Carry Flagin, muuten nollaa sen. Tätä temppuahan C -kieli ei osaa.

        Tästä syystä, jos tarvitset esim. kyvyn laskea vaikkapa 256 -bittisiä kokonaislukuja yhteen, niin toteutukset on lähes aina kirjoitetty assemblyllä, koska se on ainoa kieli, joka tukee Carry Flagin käyttöä, mikä mahdollistaa CPU -rekisterikokoa suurempien lukujen matemaattiset operaatiot.


      • Anonyymi
        Anonyymi kirjoitti:

        _asm {
        mov ax,muuttuja
        xchg al,ah
        mov muuttuja,ax
        ]

        Hienoa, joku ymmärtää assembleristakin edes jotakin!

        MUTTA:

        Jos C -kääntäjäsi on gcc (tai mingw-gcc) niin noissa (ikävä kyllä, jotain fanatismiahan tuokin on!) oletuksena on (ihan järkyttävän epälooginen ja hankala) AT&T -syntaksi.
        Sensijaan, että alkaisit opiskella tuon helvetillisen syntaksin kummallisuuksia ja epäloogisuuksia, on järkevämpää, että:

        1. asetat direktiivillä syntaksin intel -moodiin

        2. kirjoitat haluamasi assembly -käskyt

        ja lopuksi (todella tärkeää):

        3. asetat direktiivillä syntaksin takaisin at&t -moodiin !
        (tärkeää, koska muuten gcc -kääntäjä sekoaa totaalisesti, se kun käyttää sisäisesti aina at&t -syntaksia).

        gcc -kääntäjän käyttäjän vaikeudet eivät edes lopu tähän:
        seuraavaksi käsittämätön "constrains" -säännöstö, jolla:

        1. kerrotaan kääntäjälle, mitä rekistereitä assembly -koodisi muuttaa

        2. määritetään input -ja output -parametrit niin, että tiedetään (jos tiedetään, kun dokumentointi on niin vaikeaselkoista), mihin rekistereihin parametrit menevät ja mihin rekistereihin tulokset pitää jättää!

        Olisi säästytty monelta murheelta, jos gcc:n (ja Microsoftin C -kääntäjän) tekijät ottaisivat mallia Embarcadero C -kääntäjän säännöistä:

        32-bit windows:

        1. parametri menee aina -> EAX
        2. parametri menee aina -> EDX
        3. parametri menee aina -> ECX

        Ja 64-bit paluuarvon tulee olla EDX:EAX -rekisteriparissa.

        huomaa: JOS kyseessä on luokan metodi, niin osoitin luokan ilmentymään on ensimmäinen näkymätön parametri, jolloin 1. näkyviin kirjoitettu parametri onkin itseasiassa 2. parametri em. sääntöjen mukaisesti. Selkeää, ja 100% ennustettavaa = ei arvailua, kokeilua ja virheitä !

        Sopii kysyä: Miten vain ja ainoastaan Embarcaderon (ja sen edeltäjän Borlandin) kääntäjätiimiin on onnistuttu palkkaamaan loogisella ajattelulla varustettuja työntekijöitä, kun taas gcc:n vastaava säännöstö on luokattoman huonosti dokumentoitu, ja luultavasti helpompaa kuin yrittää ymmärtää kelvotonta dokumentaatiota, olisi etsiä jostakin koodia, joka käyttää intel syntaksin assemblyä gcc:llä, ja ajaa debuggerin kanssa koodia läpi selvittääkseen, miten tuo parametrien välitys gcc:ssä oikeasti toimii !

        Joku Microsoftin tuotteita paremmin tunteva voisi laittaa vastaavan yhteenvedon assemblyn oikeaoppisesta käytöstä samoin kuin olen tehnyt C Builderin ja siltä osin kuin tiedän, gcc:n vastaavista käytännöistä.

        Pahoittelen puutteita tiedoissa gcc:n osalta, mutta gcc:n kelvottoman dokumentaation takia minulla ei ole laadukkaampia tietoja asiasta !

        Katsotaanpa, osaako joku gcc -osaaja täydentää tietoja tältä osalta:

        Jos gcc:llä (32-bit windows -versio) halutaan kirjoittaa intel -syntaksin assemblya, niin:

        __int64 esimerkkifunktio(uint32 A32, uint32 D32, uint32 C32) {

        // ... assembly -koodia (intel syntax) tähän

        }

        MITEN nuo constraints -systeemit pitää kirjoittaa, jotta homma toimisi samoin kuin se Embarcadero C Builderissa toimii jo vakiona, eli:

        A32 -> EAX
        D32 -> EDX
        C32 -> ECX

        ja lopulta kun assembly -koodi jättää 64-bit tuloksen EDX:EAX -rekisteripariin, niin se pitäisi saada näkymään __int64 -tyyppisenä funktion paluuarvona !

        Saisi joku keksiä "laiteriippumattoman" assemblyn....

        ja EI, C -kieli EI OLE laiteriippumatonta assemblya, vaikka joku C -kielifani sellaista toisinaan yrittääkin väittää. esim. C -kieli ei tue Carry Flag:in käyttöä !

        assemblyllä on helppo kirjoittaa:

        add EAX, [dword ptr Luku2]
        adc EDX, [dword ptr Luku2 4]

        Tuo summaa EDX:EAX -rekisteripariin ko rekisteriparin vanhan sisällön ja uint64 -tyyppisen muuttujan Luku2 sisällön ja JOS sisältö ei mahdu 64 bittiin, niin asettaa Carry Flagin, muuten nollaa sen. Tätä temppuahan C -kieli ei osaa.

        Tästä syystä, jos tarvitset esim. kyvyn laskea vaikkapa 256 -bittisiä kokonaislukuja yhteen, niin toteutukset on lähes aina kirjoitetty assemblyllä, koska se on ainoa kieli, joka tukee Carry Flagin käyttöä, mikä mahdollistaa CPU -rekisterikokoa suurempien lukujen matemaattiset operaatiot.

        Oikeasti ei tuollaista paskaa tarvitse ääkkösiä varten.

        wchar_t tuli C90 standardissa, että voi käsitellä unicodena.


    • Anonyymi

      Se on projekti-> language optionsi, compilerilen alla se säätö.

      Mutta itselleni hauskasti ilmoittaa Visual C debuggeri että on joku virhe tullut ohjelmoajssa, eikä edes omia vaan pitää debukata toisten tekemisiiä: "flipping to assembly-dwebugger", ja sitten, voit muuttaa ajon aikaisesti sitä kooia jos osaat assebly-kieltä, jotta se ohjelma toimii hetken sitten kuitenkin :D

      Debugging Linux-Core, onko tuollaistaq ohjelmaa :D

      • Anonyymi

        "Visual C" ... " ja sitten, voit muuttaa ajon aikaisesti sitä kooia jos osaat assebly-kieltä"

        No, jos kyse on Visual C:stä, niin olettaisin, että se assembly sentään on Intel / Microsoft -syntaksia EIKÄ tuota kelvotonta AT&T -syntaksia, jota gcc jostakin poliittisista / fanaattisista syistä suosii.

        Intel / Microsoft -syntaksin mukainen assembly sentään on ihan looginen kieli (mitä AT&T -sekoilu EI OLE).

        Joku puupää aina toisinaan väittää, että AT&T:ssä vain vaihdetaan 2 ensimmäisen argumentin järjestys.

        Jos ne 2 ensimmäistä argumenttia ovat KOHDE, LÄHDE niin AT & T tosiaan haluaa ne lähde, kohde -järjestyksessä.

        Mutta tämä sääntö EI VASTAA kysymyksiin, miten menetellään, jos:

        a) argumentteja onkin 3: KOHDE, LÄHDE, MÄÄRITE (esimerkki: shld EDX, eax, 7)

        b) argumentteja on 2, mutta ne EIVÄT OLE KOHDE, LÄHDE, vaan ne ovat KOHDE, MÄÄRITE (esimerkki: shl EDX, 7)

        tässä muutamia syitä, miksi ja millä perusteella AT&T -syntaksi on lähinnä sekopäistä.

        No, tuo AT&T -hölmöily on käsittääkseni gcc:n ja eräiden muiden siihen liittyvien työkalujen (BINTOOLS ?) juttuja, onneksi Visual Studion käyttäjän ei tarvitse päätään vaivata jollain AT&T -syntaksilla.


    • Anonyymi

      Tässä esimerkki HEX koodina ä ja koodisivu utf-8

      #include <stdio.h>

      int main() {
      printf("Argumenttien lukumäärä\n");
      printf("%s","Argumenttien lukum\xc3\xa4\xc3\xa4r\xc3\xa4");
      return 0;
      }

    • Anonyymi

      sw-long-word-kirjain tai 'L' stgoso aluassa pelle tiedototon kuin Linux Varaton,

      mutta kerropa mitä tarkoittaa Visual C :ssa: multimediasubsystems, getting DMA-tranfer counter on bytes where is going, so you have to modify so fast code of yours in assembly so dma-transfer can keep with it so, solution:

      tarkkaile multiple DMA-transfer-counters so and optimize the code on certain processor in assembly code _D

    • Anonyymi

      Tietystikin on joku AMD:n eli entisen ATIn grafiikkakiihdyin jolle heittää laskuja jotta CPU:n ei kaikkea matriisesien pyörilyä laskea D;D;

    • Anonyymi

      Global Memory Lock on taaskin sellainen DirectX-juttuja ja DMA-siirtoja, mutta josk käytät tuollaisia niin ptää huolehtia proswessorin tehoisztakin että pärjää siirroissa eli pitää laskea jotta I7-Intelikin pärjää tenhoissa laskenno

    • Anonyymi

      Ckandinaavicet kirjaimet?

    Ketjusta on poistettu 1 sääntöjenvastaista viestiä.

    Luetuimmat keskustelut

    1. Haluaisitko nähdä

      Hänet alastomana?
      Ikävä
      74
      3680
    2. Hilirimpsistä

      Hyvää huomenta ja kivaa päivää. Ilmat viilenee. Niin myös tunteet. 🧊☕✨🍁❤️
      Ikävä
      201
      2992
    3. Nainen lopeta pakoon luikkiminen?

      Elämä ei oo peli 😔😟
      Ikävä
      25
      2900
    4. Älä elättele

      Toiveita enää. Ihan turhaa. Sotku mikä sotku.
      Ikävä
      49
      2768
    5. Olet täällä. Mutta ei minulle.

      Nyt olen tästä 100% varma. Satuttaa. T: V
      Ikävä
      24
      2694
    6. Kuule rakas...

      Kerrohan minulle lempivärisi niin osaan jatkaa yhtä projektia? Arvaan jo melkein kyllä toki. Olethan sinä aina niin tyyl
      Ikävä
      41
      2465
    7. Miten hitsissä ulosoton asiakas?

      On tää maailma kumma, tässä haisee suuri kusetus ja ennennäkemättömän törkeä *huijaus*! Miten to.monen kieroilu on edez
      Kotimaiset julkkisjuorut
      254
      2193
    8. Törmättiin tänään

      enkä taaskaan osannut reagoida fiksusti. Menen aina lukkoon. Yksi asia on varma: tunteeni sinua kohtaan ovat edelleen v
      Ikävä
      24
      1917
    9. Kela valvoo lasten tilejä.

      Tämä isoveli Kela kyttää jopa lasten yli 200,- euron rahat jotka on melko varmasti lahjaksi saatu. Se vaikuttaa perheen
      Yhteiskunta
      209
      1898
    10. Vieläkö sä

      Rakastat mua?❤️😔
      Ikävä
      44
      1857
    Aihe