Keskustelu: Ohjelmointikysymykset: C++ tyhmä kysymys

Oompas tässä muutaman tunnin yrittänyt opetella C++, mutta ongelmaksi muodostu MySQL kysely, allaoleva tulostaa näytölle mitä haluan, mutta mitenkäs tuo sama tehdään itse kyselyyn?

....
int x;
  cout << "x" << endl;
  cin >> x;
  cout << "SELECT.... LIMIT " << x << ", 50";


if (mysql_query(&mysql, "SELECT.... LIMIT (x tieto tähän), 50 "))

Kiitoksia tuolla toimiipi.

Lisää tyhmiä kysymyksiä.

1) Miten määritellään moniulotteinen taulukko?

2) Miten lasketaan monta alkiota on?

1)

int jees[2][2];

2) Et mitenkään. Kannattaa varmaan joko
a) käyttää vektoreita
b) keksiä alkioitten määrä jotenkin muuten (ottaa ylös taulukoita luodessa)
c) laittaa null-arvo viimeiseen alkioon ja forrilla käydä sitten läpi

Juice kirjoitti:

1) int jees[2][2];

Joka ei ole moniulotteinen taulukko, vaan taulukoita sisältävä taulukko. Ei ihan sama asia.

o_O? mikäs on sitten moniulotteinen taulukko jos ei tuo?

Jos nyt viilataan vielä pilkkua, niin oikeastihan taulukkoja ei ole olemassakaan, sehän on vain harhaa :P

Joissakin kääntäjissä tuo kuulemma vieläpä kieltäytyy toimimasta samalla tavalla kuin dynaamisesti varattu taulukollinen taulukkoja.

Kyllähän sen moniulotteisen taulukon koon saa selville siinä missä yksiulotteisenkin.

T t[n][m];
size_t koko = sizeof(t)/sizeof(T);

Jokaisen blokin koko on sizeof(T), ja koko härpäkkeen koko nm*sizeof(T) joten tietty koko saada selville.

Mitä MySQL-kirjastoa muuten käytät opisklelija?

Jälleen oppimisessa päästy eteenpäin kiitos auttajien.

Ceez: Käytän MySQL omaa kirjastoa, http://wiki.mureakuha.com/wiki/Libmysql_-_tuki_Dev-Cpp:lle tuon ohjeen mukaan sain toimimaan.

T.M. kirjoitti:

o_O? mikäs on sitten moniulotteinen taulukko jos ei tuo?

Tässä tapauksessa eroa ei hirveästi ole, koska taulukoiden koko on määritelty etukäteen.

Moniulotteinen taulukko on suorakulmion mallinen, kun taas taulukko, joka sisältää taulukoita, voi olla minkä mallinen tahansa: jokainen taulukko "päätaulukon" sisällä voi olla eripituinen.

Jälleen tyhmä kysymys.

G++ sisältää jonkinmoisen koodin optimoijan, joka kyllä nopeuttaa melkoisesti. Mutta mitä moiset optimoijat koodille tekee?

Jonkin verran löytyy Applen GCC-sivuilta: http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Optimize-Options.html
Luulen kuitenkin, että tuolla on jo jonkin verran Mac-spesifistä tavaraa. -O2 kuitenkin näytti melko samalta kuin GCC:n lähdekoodissa, ja tuolta tosiaan löytyy tiiviit selitykset asioista.

Kiitoksia. Vielä olis muutamia kysymyksiä.

Noita C++ kääntäjiä on monia, mutta onko niiden tuottamassa koodissa mitään eroa, kuten nopeudessa, toimivuudesa? Vai onko ihan sama mitä käyttää.

Mitenkäs muuttujat saa ohjelmaan eri tiedostosta? Siis, että ne haetaan joka kerta kun ohjelmaa suoritetaan.

Voi olla minimaalisia eroja, ainakin optimointien jälkeen, mutta käytännössä hyvin vähän. Kuitenkin yleisesti ehkä käytetyin kääntäjä löytyy GCC-paketista, joten voisi olettaa, ettei se ainakaan ole muita huonompi. Ja kun se kerran on avointa lähdekoodia, niin tuskinpa muutkaan silloin ovat kovin paljon sitä huonompia. Tietenkin sitten eri alustoille käännettäessä alkaa erojakin tulla, ymmärrettävistä syistä.

Merkkikääntäjät (VC++, Borland) tukevat toisinaan hieman omia virityksiään, ja lisäksi niiden standardikirjastot voivat olla hieman erilaisia. Microsoftin standardikirjastosta löytyy tunnetusti erinnäisiä bugeja, joiden ansiosta VC++ saa aikaan hieman toisin toimivan ohjelman kuin muut kääntäjät. Onneksi en itse ole törmännyt noihin.

Tiedostojen lukemisesta kertovat monet oppaat, esimerkiksi tämä: http://www.cplusplus.com/doc/tutorial/files.html

Itse olen havainnut, että toisinaan gcc/g++:llä ja Microsoftin cl-kääntäjällä käännettyjen koodien välillä on paikoin jopa noin 20% nopeuseroja puoleen tai toiseen. Eli jos tarvitsee jotain todella nopeaa, kannattaa kokeilla eri kääntäjiä ennen kuin siirtyy kirjoittamaan asmseblya.

Itselläni ei ole tullut vastaan tilannetta, jossa molemmista kääntäjistä läpi mennyt koodi olisi toiminut jotenkin eri tavalla. Toki kannattaa olla varovainen käytettäessä kääntäjien eksoottisimpia optimointioptiota, jotka eivät välttämättä tuota oikeaa tai kaikilla koneilla toimivaa ohjelmaan.

Koodin optimoija analysoi ja virittää generoitua konekielikoodia. Tyypillisiä temppuja ovat pikkufunktioiden inlinetys, silmukoitten oikominen, rekisterien merkityksettömien muistilukujen/kirjoitusten poistelu ja toisistaan riippumattomien operaatioiden uudelleenjärjestely ja rinnakkaistus peruslohkojen sisällä. Ei ihan tavallisen koodipuoskarin hommaa, vaan vaatii aika paljon analyysiä ja taustatietoa koodista ja prosessoriarkkitehtuurista (ja konetehoa käännösaikana). Varsinkin kireimmillä asetuksilla optimointi saattaa mennä myös vikaan, kun optimoija tekee liian pitkälle meneviä oletuksia tai sekoaa omiin laskelmiinsa.

Kääntäjiä on erilaisia ja se on periaatteessa ihan hyvä, sillä silloin on kilpailua, valinnanvaraa ja kehitystä. Standardin mukaan kirjoitetun koodin pitäisi wörkkiä ihan samalla tavalla kääntäjästä riippumatta, vaikka exen koko ja ajoaika voivat vaihdella.

Usein on ihan sama, mitä kääntäjää käyttää, kunhan kääntäjä on riittävän uusi eikä rupea sotkemaan eri kääntäjillä tehtyjä juttuja keskenään. Kannattaa myös lukea lähinnä tällä vuosituhannella kirjoitettuja C++-kirjoja. Kaiken maailman DJGPP-purkkaviritykset ja ikivanhat C++ Builder -versiot yhdessä vanhojen opaskirjojen kanssa eivät oikein edistä <iostream>- ja int main()-juttujen perillemenoa, puhumattakaan ihan oikeista kirjastoasioista ja ohjelmointikäytännöistä.

Gnu-kääntäjillä käännösajat ovat yleensä melko pitkiä eikä lopputuloskaan yleensä ole nopein mahdollinen. Siirrettävyys on kuitenkin ollut hyvä, sillä jokseenkin samat temput ja kirjastot ovat olleet saatavissa ja toimineet ompelukoneista superkompuuttereihin. G++:n kolmosversion aikoihin kirjastopaketti meni remonttiin ja oli aika epämääräisessä kunnossa. Viimeisintä tilannetta en ole ihan tarkkaan seurannut.

Microsoftin vanhemmat kääntäjät (erityisesti MSVC++6) eivät eri syistä ole olleet ihan standardin tasalla. Intelin kääntäjä on ollut optimoinnin huippua pc-ympäristössä, mutta jos nyt ottaa tuoreen MS:n kääntäjän (vähintään 2003 kun 2005:kin on saatavilla ja ilmaiseksi), niin ero nopeudessa ei ole enää kovinkaan suuri. Nykyään MSVC++ on parhaimmasta päästä myös standardinmukaisuutensa puolesta.

Itse en olisi ottamassa assemblyä käyttöön nopeuttaakseni koodia, vaan miettisin algoritmipuolta uudelleen. Kääntäjä optimoi koodin (konekieleksi) usein ihmeen paljon paremmin kuin mitä koodaaja itse luulee assemblyllä pystyvänsä.

Vielä semmoista, että miks G++ tekee hello worldista yli 400kt suuremman tiedoston kuin Microsoftin kääntäjä?

Voisiko olla niin, että Microsoftin kääntäjä linkkaa ohjelman dynaamisen kirjaston kanssa, mitä Gnu-kääntäjä ei sitten Windows-ympäristössä teekään. Ero voisi syntyä myös siitä, että käytetään erilaisia optimointi- ja debug-vipuja.

Pienehköt erot exen koossa ovat ihan odotettaviakin, kyseessähän on eri "tuotteet".

Juuri tuosta linkittämisestä on kyse. Solariksessa dynaaminsta linkitystä käyttäen käännetty Hello world -ohjelma vie 5 kt ja staattisesti (eli kirjastot mukaan linkitettynä) 376 kt (ilman debuggaustietoja 240 kt).

Opiskelija kirjoitti:

Vielä semmoista, että miks G++ tekee hello worldista yli 400kt suuremman tiedoston kuin Microsoftin kääntäjä?

Se sisältää debuggaustavaraa. Siitä lähtee muutama sata kilotavua kun ajat strip.exe ohjelmasi.exe. Strip.exe löytyy sieltä missä g++.exekin sijaitsee.

Kun käännät sen lipulla -s, tuo tehdään automaattisesti.

Mitäs kaikkia lippuja kääntämisessä kannattaa käyttää jotta exen suoritus olis nopeaa ja muutenkin yleisesti ottaen?
Tähän mennessä lähinnä iso ja pikku o ovat olleet mukana, ja nyt tuo s.

Mites pystyy käyttämään isohkoja lukuja kun long long ei riitä?

Logaritmeillä tai jollain suuren tarkkuuden aritmeettisella kirjastolla, vaikkapa GMP:llä

Täytyypä illemmalla katsella tuota GMP:tä joskos sillä onnistus.

Entäs miten double muuttuja tyyppinen tulostetaan bitteinä?

Mitä tarkoitat "tulostetaan bitteinä"? Tietokoneessahan kaikki muuttujat ovat bittejä, joten eikös se tapahdu komennolla

std::cout << d;

missä d on double-tyyppinen muuttuja? Haitko kenties jotain muuta, kerropa selkeämmin mitä haluat.

Jaska kirjoitti:

Mitä tarkoitat "tulostetaan bitteinä"? Tietokoneessahan kaikki muuttujat ovat bittejä, joten eikös se tapahdu komennolla

std::cout << d;

missä d on double-tyyppinen muuttuja? Haitko kenties jotain muuta, kerropa selkeämmin mitä haluat.

Tarkoittanee, että tulostetaan bitit, joista muuttuja koostuu. Eli esimerkiksi muuttujan ollessa nolla tulostuisi 64 nollaa (olettaen, että double on 64-bittinen liukuluku).

Siinä tapauksessa pitää muuntaa luku 2-lukujärjestelmään. Tässä joku vanha koodini joka muuntaa 10-järjestelmän luvun toiseen järjestelmään:

 int luku=1234;	// Muunnettava luku

 // Vektori johon muunnetut luvut tallennetaan
vector<short int>muunnettu;

 // Muunto
 bool run=true;
 int kanta=2;	// Kantaluku

 while(luku!=0) {
     muunnettu.push_back(luku%kanta);
     luku/=kanta;
 }

Koodi on aika vanha ja en mene takuuseen että se toimii (en jaksa testata vaikka vähän siistinkin).

Ongelma tuossa tekniikassa on, että se ei taida toimia liukuluvuille. Niiden bittikoostumus kun on vähän kiinnostavaa lajia, ja riippuu vielä järjestelmästä. Asiaan liittyvä linkki: http://docs.sun.com/source/806-3568/ncg_goldberg.html

Osoitinkikkailuilla tuokin onnistuu. Tässä C-tyylinen esimerkki, C++ tietenkin tykkää enemmän omista tyypinmuunnoksistaan (reinterpret_cast jne.)

void tulosta(double luku)
{
  void * osoitin = &luku;
  int i, j;
  for (i = 0; i < sizeof(double); ++i)
    for (j = 0; j < 8; ++j)
      printf("%i", ((((unisgned char *)osoitin)[i] >> j) & 1));
}

En testannut, mutta tuolla idealla. Tuosta voi vielä suuntaa käännellä halunsa mukaan oikeammaksi.