[C] bitni operator

Če v C rečemo if (a=1) .... potem nam kar priredi a-ju 1. Zato moramo reči if (a==1), da je ta if nedestruktiven za a.
Zakaj ne bi potem s to logiko šli tudi iz & na &&?

Zato sem te vprašal po tej ideji, ker je edino na kar sem lahko sklepal iz zgornjega tisto kar sem napisal (& postane destruktiven se pravi identičen &=). Kar se pa Criticalla tiče pa ok, ni se treba branit zakaj si kaj uporabil in zakaj ne. Upam da neuporaba && ni edina poenostavitev C-ja, v Criticallu. Je še nekaj konstruktov, ki so zelo primerni za poenostavitev dela človeškemu programerju in so najverjetneje v Criticallu povsem nepotrebni.

Bolj me zanima kako ti, ko kdaj sam kakšen program napišeš v C(++) (če ga sploh), pišeš logične in in ali. Ker očitno se vgrajenih logičnih operatorjev izogibaš.

Kako bi ti spisal:

a = fx1();
b = fx2();

if(a && b)
printf("Obe funkciji sta uspeli\n");
else
printf("Fail");

??

Kako bi ti spisal:

a = fx1();
b = fx2();

if(a && b)
printf("Obe funkciji sta uspeli\n");
else
printf("Fail");

V critticall omejenem c bi blo takole:

true=0;
if(a)
{
    if(b)
    {
        true=1;
    }
}

if(true)
{
    printf("obe uspeli");
}
else
{
    printf("fail");
}

Me zanima če Thomas misli isto.

se pravi eno preverjanje in ena spremenljivka več zato ker ne maraš &&?

Kako v bistvu veste, kaj bo compiler iz tega naredil in kako bo pokrajšal zadevo ?

Ali compilate brez optimizacij ?

Compiler ne ve, kateri pogoj je manj verjeten. Lazy eavaluation switch na on, mu pač omogoči zapuščanje pogoja takoj ko je false, pri &&.

Isto je pa doseženo z dvojno (mnogoterno) if zanko.

Samo ... hehe .. to je tko mau. Amatersko. Taprav program mora on fly zamenjat vrstni red ifov, če pri prvem gnezdenem, relativno malokrat pade ven.

Mah .. to je tko. Manufaktura je pri programiranju na poti v muzej.

Compiler ne ve, kateri pogoj je manj verjeten.


Ne nujno. Ti pri gccju lahko vklopiš poseben profiling, scompilaš zadevo, jo poženeš v nekem tipičnem okolju, stvar prešteje kako so se izšli določeni skoki in temu ustrezno nastavi končno verzijo.

Pojma nimam kako to dela gcc.

Vsakakor ima na vpogled source, vse funkcije in temu ustrezne števce.

Ni nujno, da se gre samo (niti ne tako) trapasto štetje, kot to počnejo recimo nekateri CPUji v zgodovini skokov...

Mogoče še nekaj. AFAIK ima gcc/gdb precej elpo urejen profiling, skozi katerega lahko ve natanko koliko ciklov je program preživel v neki funkciji.

Če stvar naredi spremembo in zato pospeši notranjo funkcijo vendar je zato vse skupaj počasnejše, lahko to lepo vidi iz stanja števcev.
Tudi ni nujno,d a števci kažejo srednji ali kumulativni čas, mislim, da lahko izmeriš čas natanko določenega preleta funkcije.

Spomnim se, da je bila stvar videti kar kompleksna in je omogočala zajem shitloada koristnih podatkov.

Druga stvar pa je seveda, če ti že sam profiling spremeni stvari tako, da se program ne obnaša tako kot bi se sicer.

A tudi temu se verjetno da lepo pomagat, če se zavedaš omejitev orodja...

> V determinističnem stroju so vsi skoki predvidljivi.

Le z dosti computinga. Natanko toliko, kolikor ga program sam po sebi ponuca.

Delajo pa seveda enostavnejše predictinge skokov. Če so kakorkoli statistično signifikantno uspešni, program ni optimalen.

Ja. If mora biti tak, da se izvaja, kot bi metal pošten kovanec. Nobenih pravil ne sme biti v tem. Sicer je program s tem ifom suboptimalen.

> A taka zasnova CPUja in komplikacija pravil vsaj nekaj ne spremeni-a tega pravila ?

Ga spremeni. Potem mora if v obeh primerih (da je true in da je false) pokuriti enako časa. Potem je optimiziran na čas.

Lahko je pa optimiziran tudi na energijo. Da po obeh možnih plateh v povprečju pokuri enako energije.

Pa seveda, da ni kakšnih enostavnih vzorcev v obeh primerih. Da bi kakšen predicting bil tako pameten, da bi uspešno predvideval program, kam se bo nagnil.

Če je ... ni idealen.

if (pogoj && !klic()) printf("Error");

> if (pogoj && !klic()) printf("Error");

Mislis:
pogoj && (klic() || printf("Error"));

Sej ga lahko nategneš s typecastom...

pogoj && (klic() || *(int *) (printf("Error") != 0)); //

Torej:

int shrani_v_bazo(int);
int izpisi_napako(int);

int neki(int a)
{
  int napaka;
  return
    a > 5
      ? (napaka = shrani_v_bazo(a * 3))
      : (napaka = shrani_v_bazo(0)),
    napaka == 0 || izpisi_napako(napaka),
    napaka;
}

Ne, sej to sem mislu v kakšnem starejšem C-ju, brez skrbi, da se je dalo!
C++ je potem (hvalabogu) v zadnjih 10 letih kar precejšnjo pot naredil...

Evo, še ena C-jevska cvetka - ZAKAJ SE VEDNO IZPIŠE "JAO!"?
(To napako sem že pred leti debuggeriral ene 8 ur! )

if (a += 10); printf ("Jao!\n);
// izpisati "Jao" samo kadar (a != 0)

NavadniNimda, tale smajli vse pove - ;)

aja... pa ; je prevec
:P

Haha, jaz sm pa to takoj vidu. Zato ker sem enkrat bral pejdz o najbolj bolecih programerjevih napakah. Pa sem si tega se posebej zapomnil

Stranski učinki so že sami po sebi grdi, ne vem čemu bi si želel temu dodati še nedeterministične skrivalnice.

Komot izklopiš lazy evaluation. Ni problema.

popec sam da ne bos na EEju isklopu k bo slo vse v kurac :)

Jaz sem tudi mnenja, da je short circuit boolean evaluation izrazov ena bolj simpatičnih pridobitev civilizacije. Na ta račun dobimo VSAJ dve reči:
- hitrejše izvajanje kode!
- prisili se programerja, da ne dela funkcij z bebavimi stranskimi efekti.

Evo, to je bilo moje OSEBNO, subjektivno mnenje!

Katera moja trditev ti ni všeč?

Zavračanje &&?

> Komot izklopiš lazy evaluation. Ni problema.

Namesto if (a && b) ....

c=a && b; if (c!=0)

Tkole.