Az IGAZI C Programozó

A IGAZI TÖKÖS C PROGRAMOZÓ

Szigorúan nagybetűvel!

Annyira bírom, hogy egyesek annyira el vannak szállva maguktól, csak mert C PROGRAMOZÓK, hogy képtelenek észrevenni, hogy van élet a drágalátos C nyelvükön túl is és mindenki más láma szararc, csak mert épp a feladathoz jobban illeszkedett a PHP/C#/akármi.

Csak amikor visszakérdezek ilyenekre, hogy miért is egy "objektum szerű valami" a struct definiciója, amit "példányosítani" kell (C-ben!) és csak mindenféle idióta kitérő választ kapok, meg hogy "haha, én nyertem én tudom jobban, te meg nyomi .NET-s vagy*" akkor valahogy elgondolkozok azon, hogy miért is van egyeseknek ekkora arcuk?

Sebaj, az IGAZI TÖKÖS PROGRAMOZÓ kizárólag C-t használ. És nem baj, ha azt se érti, mi az az OOP, miért jó és miért rossz. Szar az egész úgy, ahogy van és kész, mert ő IGAZI TÖKÖS C PROGRAMOZÓ és jobban tudja.

* vicc, hogy egy komolyabb munkám nem volt még .NET-ben.

Ui.: remélem mindenki érti, hogy mely C programozókról van szó és melyekről nincs.

Hozzászólások

az igazi tökös c programozó fortrant használ… :)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

rosszul tudja, a c++ programozó az isten, és a többi szararc:)

ugyanmár, ez marhaság, ez a sok programozási nyelv mert mindent meg lehet írni fortranban, amit nem lehet megirírni fortranban azt meg lehet írni assemblyben, amit nem lehet megírni assemblybe, azt nem lehet megírni :D

Core2Duo T7100, 2.5G, Ubuntu 9.04, 2.6.28

Mit értesz azon, hogy példányosítani kell?

KisKresz

3/4-1 órás flame közben nem jöttem rá, hogy igazából mit akart mondani, ha rákérdeztem, hogy mégis mi az, hogy struct-t példányosítani C-ben, akkor meg jöttek a hülye oda nem tartozó hasonlatok meg a nagyképűség.

Egyébként szerintem is maximum lefoglalni lehet a struct helyét a memóriában..

----------------
Lvl86 Troll

Lattad mar, mit fordit egy atlag fordito egy OOP kodbol? :) "Minden gotova es pointerre fordul!" szoktam volt mondani. Szoval az egesz OOP egy maszlag, bullshit, picsafust, mivel minden fordito irtozatos erofeszitessel elso lepeskent kikurja az egeszet az ablakon. A processzornak ugyanis fingja sincs az OOP elemekrol, csak gotobol meg pointerekbol ert.

Ennek ellenere az OOP hasznos tud lenni, ha nem viszik tulzasba, es en is hasznalom, de pl. Javaban neha sikitofrasztkapok attol, hogy minden objektum, es vert pisalok, hogy leemulaljam azt, ami barmilyen ertelmes nyelvben 0.1 sec lenne, egy egyszeru pointercastolassal.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Értem én, hogy végső soron mi lesz mindenből, de szerintem te is tisztában vagy vele, hogy miért van olyan, hogy objektum orientált programozás és ennek mi a paradigmája.

De a bejegyzés nem erről szólt, hanem a önmaguktól elszállt "mindenki más hülye, de nekem sincs fogalmam, arról, hogy miről beszélek" C kóderekről.

----------------
Lvl86 Troll

Ugyan mar, az igazi programozo egy hexa editort hasznal csak.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Én utoljára COBOL-ban programoztam. Szerintem a jó program struktúrált, nem pedig objektum orientált. :-P

Ave, Saabi.

Egy helyesen megint strukturalt es egy helyesen megirt OOP program kozott minimalis a kulonbseg. Kb. annyi, hogy obj.valami(x); helyett valami(struc,x)-et irsz... :) Vagyis jol programozni csak egyfelekeppen lehet. Az, hogy milyen nyelvi elemeket hasznalsz hozza, az meg izles (es lehetoseg) kerdese, persze kozben fejbentartva, hogy "minden gotova es pointerre fordul". :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Az igazi tokos programozo ismeri a c sotet bugyrait, es fejbol nyomja a valaszokat (visszateresi ertekeket) az alabbi kerdesekre:

0) return ((1 - sizeof(int)) >> 32);
1) return ((int []){1,2,3,4})[1];
2) return ({goto L; 0;}) && ({L: 5;});

;)

Fejből azért nem tudom, de az első kettő - szerintem - nem nagy ügy. A harmadikon még agyalok (így tanítás közben persze nem triviális). Ellenben a www.ioccc.org darabjaiból én konkrétan ezt szeretem:


main() {
printf( &unix[ "\021%six\012\0" ], (unix) [ "have" + "fun" -0x60 );
}
gcc -Wall test.c
test.c:1: warning: return type defaults to ‘int’
test.c: In function ‘main’:
test.c:2: warning: implicit declaration of function ‘printf’
test.c:2: warning: incompatible implicit declaration of built-in function ‘printf’
test.c:2: error: invalid operands to binary +
test.c:2: error: expected ‘]’ before ‘)’ token
test.c:2: warning: embedded ‘\0’ in format
test.c:3: warning: control reaches end of non-void function

hmm. interesting.

Mea culpa, mea maxima culpa!


main() {
printf( &unix[ "\021%six\012\0" ], (unix) [ "have" ] + "fun" -0x60 );
}

Bocsanat, lehagytam a teljesen nyilvanvalo helyen levo ] -t :-)

Ellenben en is megprobaltam leforditani a 3-t, es nekem bizony aszongya:

la.c:3: error: jump into statement expression
*** Error code 1

Szoval en se jutottam semmire a kiindulo kerdesfeltevessel.

Jav:
Tovabb tesztelve, erdekes eredmenyre jutottam az 1-essel, kerem a kerdesfeltevot a dontes meghozatalara:

szerintem a korrekt valasz az abrazolhato legkisebb negativ szam, leven a kivonas negativ eredmenyenek elojele fog szepen vegigcsuszni (es sokszorozodni) a biteken. Ellenben gcc (4.2.1 20070719 [FreeBSD]) -O0 es gcc -O2 is dob egy warningot arrol, hogy a shift tobb a kelletenel, es szepen kioptimalizalja 0-ra. Ezzel szemben a sokak altal szidott pcc (0.9.9.081227) az altalam varhato erteket adja vissza, igy shell-bol hivva a gcc-s verzio 0, mig a pcc-s verzio 255 erteket dob ki. No ki a hulye? (marmint rajtam kivul?)

> ...a kivonas negativ eredmenyenek elojele fog szepen vegigcsuszni (es sokszorozodni) a biteken.

Én úgy tudom, a gcc "okosan" shiftel: az előjelbitet megőrzi, vagyis az nem shiftelődik, így pontosan a 2^n-el való szorzást valósítja meg, de fixme.

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

En is azt irtam, hogy megmarad az elojelbit, de mivel a masik iranyba siftelodik, ez max osztas lehet :-), viszont balrol jobbra ugy szoktak siftelni, hogy pontosan az elojelbit jon be (ha pozitiv volt akkor 0, ha negativ volt, akkor 1) balrol a "kiuresedo" helyekre.
Szerk: raadasul az 1) eroteljesen feltetelezi, hogy a - tudtommal - nem egyertelmu meretu "int" mit ad isten pont 4 byte. Mert mondjuk egy 8 byte-os intet hasznalo architekturan ugye meg csak nem is -1 lenne az eredmeny. (Szoval egy korrekten megirt "lint"-nek portability errorokat kene dobalni.)

Igen, természetesen szorzás/osztás akart lenni.
Amúgy közben én is rájöttem arra, amit írtál, és így csakis -1 lehet. Ugye az 1-sizeof(int) egy viszonylag kis abszolútértékű negatív szám, ami valahogy úgy fog kinézni, hogy sok 1-es, a legkisebb pár biten meg vagy 1, vagy 0. Ezt rengetegszer shiftelve szépen kitöltődnek ezek a bitek is 1-gyel.
Szerk: még a te "szerk"-ed előtt írtam ezt, de szerintem ebből kifolyólag nem függ az int méretétől. Kivéve, ha 1 byte-os, mert akkor 0. :))

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Ismerjuk az osszes van/volt/LESZ!!!! architekturat? Szoval ga'zos :-)

Nekem igy remlik:

sizeof( char ) <= sizeof( short ) <= sizeof( int ) <= sizeof( long )
(mas meg nincs is ebben a keszletben, pl. long long) Mint ahogy a sizeof(int) es sizeof(void * ) kozott sem letezik semmilyen kapcsolat. Regebben szokott volt azonos meretu lenni, de manapsag mar nagyon nem.

A sizeof(int) mindig nagyobb lesz mint egy, mert kvazi-standard, hogy minimum ketto byte-n kell abrazolni. Meg a Commodore 64/ZX Spectrum gepek is ketto byte-n abrazoltak, pedig ott aztan sporolni kellett a hellyel. Az ok amugy nagyon egyszeru: a memoriacimek egesz szamok, es manapsag mar nincs olyan kornyezet, ahol 256 byte RAM eleg lenne barmire is.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

4) hm. ezt a nyelv szabalyaibol egyertelmuen meg lehet mondani? Nekem ugy remlik, hogy ilyen esetben x, y es z gyakorlatilag veremszemettel lesz tele, kovetkezeskeppen ugyanugy lehet 0 es nem-0 is. Ebbol viszont az kovetkezik, hogy vagy sizeof(int), vagy sizeof(int)*2 (gcc nem engedi forditani, pcc meg a szamomra ertelmezhetetlen -1 -et adja. hm) (*)

5) lasd mint fent. 2x deklaralod a fv-t, ez megengedett? Illetve, hogy egy extern modosito eseten legyen fv-torzs? (gcc szo nelkul forditja, es 4 lesz; pcc nyafog - ugyanazon, mint en :-) )

(*) Szerk: hm. tovabb gondolkodva, a dolog meg zurosebb, leven az elso tagja a kifejezesnek raadasul meg csak nem is az y (esetleg z) cime, hanem ezek valamelyikenek *ertekenek* a cime - ami eleg agyatlan dolognak tunik, hajlok a gcc valaszat jonak tekinteni.

En a gcc-re vagy az emacs-ra tippelnek ha egyaltalan valoban leteznek - ezekrol olvastam, hogy embertelenul vannak/(voltak amikor X eve olvastam) kodolva. De inkabb szivatasnak tunik, mint epelmeju programozoi eszkoznek. (Persze ez jo lehet arra, hogy ne akarjanak kirugni a project-bol, mert nem lesz ember, aki kepes lesz javitani :-) )

En lattam mar ilyesmiket real world programban. cucipop / procmail forraskodja bar nem ennyire gaz, eleg kozel jar.

Korabban dolgoztam olyan cegnel ahol az egyik kollega eloszeretettel irt meglehetosen obfuscated C kodot, mert ugy gondolta, hogy ha csak o erti, akkor nem rugjak ki (es megis :P).

open source programban nem lattam (meg) ennyire elvetemult kodot, de csak ido kerdese :)

Aki nem tudta volna mind az 5 pelda innen van: http://manju.cs.berkeley.edu/cil/cil016.html
Az elso kettot kiveve az eredmeny - mint az oldal irja - forditotol fugg, illetve ok konkretan a gcc viselkedeset neztek. Szoval aki az elso kettore tudta a valaszt, de a tobbire nem, az is jo C programozo.

- Use the Source Luke ! -

aki jart mar freenode ##c-n, az tudja, hogy ennel az allatfajnal gusztustalanabb a vilagon nincs

--
When in doubt, use brute force.

Hehe. Erről ez jutott eszembe.
Konrétan a C ("You shoot yourself in the foot") szemben az összes többivel, pl. a Java-val ("After importing java.awt.right.foot.* and java.awt.gun.right.hand.*, and writing the classes and methods of those classes needed, you’ve forgotten what the hell you’re doing").