játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5504
FZoli:    4894
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2528

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] > 60 < [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [143]
bit.0x8000 - Törzstag | 574 hsz       Online status #126557   2010.01.17 11:21 GMT+1 óra  
Idézet
Joga :
Arra akartam vélozni, hogyha az operátornak adsz egy inline módosítót, akkor azt a fordító nagyobb eséllyel optimalizálja ki



Baszki, erre magamtól is rájöttem
De még ha inline-olod is, akkor sem olyan triviális, mint a Sum-os megoldás (amit, ugyebár, szintén lehet inline-olni).

písz
   
Joga - Törzstag | 1791 hsz       Online status #126556   2010.01.17 11:12 GMT+1 óra  
Arra akartam vélozni, hogyha az operátornak adsz egy inline módosítót, akkor azt a fordító nagyobb eséllyel optimalizálja ki
(ಠ ›ಠ) Stewie!

   
bit.0x8000 - Törzstag | 574 hsz       Online status #126553   2010.01.17 11:10 GMT+1 óra  
Idézet
Joga :
inline operátor?


Ha esetleg némi kóddal is tudnál szolgálni...
   
Joga - Törzstag | 1791 hsz       Online status #126552   2010.01.17 11:04 GMT+1 óra  
inline operátor?
(ಠ ›ಠ) Stewie!

   
bit.0x8000 - Törzstag | 574 hsz       Online status #126551   2010.01.17 11:00 GMT+1 óra  
Igazából arra gondoltam, hogy az alábbinál...
Kód:
void Sum(const Vector2D &vector1, const Vector2D &vector2)
{                       
    x = vector1.x + vector2.x;
    y = vector1.y + vector2.y;
}

...az értékadásokat elméletileg néhány gépi kódú utasításból el lehet végezni, memóriafoglalás nélkül, míg az operátoros kódban létre lett hozva egy új Vector2D struct.
(Azt persze el tudom képzelni, hogy a fordító ezt "kioptimizálja", ezért is vetettem fel a dolgot, hátha valaki többet tud mondani erről.)
   
Asylum - Törzstag | 5504 hsz       Online status #126548   2010.01.17 10:34 GMT+1 óra  
Attol függ hogyan csinálod...pont erröl volt szo nemrég, hogy nem tudni, hogyan van implementálva egy operátor...általában igy szokás:

Kód:
Vector2 Vector2::operator+(const Vector2& other) const
{
    return Vector2(x + other.x, y + other.y);
}


Amit te irtál az pedig:

Kód:
Vector2& Vector2::operator+=(const Vector2& other)
{
    x += other.x;
    y += other.y;

    return *this;
}


Ami nyilván gyorsabb...az új cpp szabványban a jobbérték-referenciával már a fenti is gyors lesz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bit.0x8000 - Törzstag | 574 hsz       Online status #126546   2010.01.17 10:07 GMT+1 óra  
Az operátor felüldefiniálással kapcsolatban ütött szöget a fejembe a következő:

Ha van egy ilyen osztályom (struktúrám)...
Kód:
struct Vector2D
{   float x, y;

    Vector2D(float x, float y);
    Vector2D();
};


...és csinálok hozzá ilyeneket...
Kód:
Vector2D &operator+(const Vector2D &vector1, const Vector2D &vector2)
{   Vector2D sum;
                   
    sum.x = vector1.x + vector2.x;
    sum.y = vector1.y + vector2.y;
    return sum;
}
               
Vector2D &operator=(const Vector2D &vector)
{
    x = vector.x;
    y = vector.y;
    return *this;
}
               
void Sum(const Vector2D &vector1, const Vector2D &vector2)
{                       
    x = vector1.x + vector2.x;
    y = vector1.y + vector2.y;
}


...akkor az alábbi kettő közül...
Kód:
Vector2D a, b, c;
               
a = b + c;
a.Sum(b, c);


...a második elméletileg gyorsabb.
Esetleg az operátor felüldefiniálást kéne máshogy csinálni?
   
Winoxish - Törzstag | 121 hsz       Online status #126476   2010.01.15 23:04 GMT+1 óra  
És a
Kód:
b[0]
itt egy vector<bool>::reference-szel tér vissza.
.:: Blaises Games ::.

   
TPG - Tag | 3402 hsz       Online status #126474   2010.01.15 17:39 GMT+1 óra  
Két szó: template specialization. A vector-nak van egy bool-ra specializált változata ami már ismeri a flip metódust.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5504 hsz       Online status #126473   2010.01.15 17:34 GMT+1 óra  
Ha már szóba került:

Kód:
std::vector<bool> b;
b.push_back(true);

b[0].flip(); // ?


Aki meg tudja magyarázni gugli nélkül kap egy...hmm...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #126468   2010.01.15 15:33 GMT+1 óra  
bitsetnél érdekes is lenne a pointer iterátor
(ಠ ›ಠ) Stewie!

   
Asylum - Törzstag | 5504 hsz       Online status #126463   2010.01.15 14:47 GMT+1 óra  
Jajj gyerekek
Az lehet, hogy nincs kimondva az implementáció módja, de a vectornak konstans elérésünek kell lennie. Amit eddig észrevettem rajta, hogy amikor push_back-et hivsz, akkor mindig nyom egy realloc + copy kombót, igy az nagyon nem hatékony, DE:

Ki lehet optimalizálni a következőképpen: azt mondod, hogy v.reserve(10); nyilván problémafüggö, hogy mennyit érdemes elöre lefoglalni.
Beszúrás előtt pedig

Kód:
if( v.capacity() == v.size() )
{
    v.reserve(v.size() + 10); // vagy amennyit logikus
}

v.push_back(elem); // igy viszont már átlagosan ez is 1 költségü!


Az iterátor * operátora nem pointert ad vissza, hanem refet, iletve a const_iterator konstans refet. Általában amikor nem tudom eldönteni, hogy listát vagy vector-t használjak, akkor iterátorral iterálok, amikor viszont a probléma engedi vagy egyenesen megköveteli (például mert kell az index), akkor az indexelőset. Költségben szerintem ugyanannyi mindkettö. Ha irtatok már iterátort akkor tudjátok miért.
Az iterátor maga pedig nem pointer, hanem egy objektum.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
nadam - Törzstag | 364 hsz       Online status #126430   2010.01.15 05:21 GMT+1 óra  
Köszi!
   
proof88 - Törzstag | 530 hsz       Online status #126429   2010.01.15 05:17 GMT+1 óra  
nadam - Törzstag | 364 hsz       Online status #126428   2010.01.15 05:14 GMT+1 óra  
proof88:

egy évre szólt a domain bérlés, és mivel már eléggé lecsengett a játék iránt az érdeklődés, nem akartam fenntartani tovább (mert már csak vitte volna a pénzem). Persze a download.com-ról még letölthető a cucc.

Van egy másik miniprojektem:

http://memodrops.com

Most komolyabb projektekre nincs időm sajnos. A mostani melóhelyemen is sok a munka, meg megyek felvételizni a Google-höz, arra próbálok esténként készülni. (Jövő csütörtökön lesz az első telefonos szakmai interjú, aztán ha azon túljutok, akkor lesz személyesen Zürichben egy 8 órás maratoni interjúsorozat. Sajnos hírhedten sok embernek megköszönik a részvételt és szevasz, de egy próbát megér...)
   
bit.0x8000 - Törzstag | 574 hsz       Online status #126427   2010.01.15 05:12 GMT+1 óra  
Idézet
gaborlabor :
Azt tudtam, hogy az iterátor nem más, mint egy pointer az adott elemre...



Mondjuk vector-nál lehet, hogy így van, de pl. list-nél egész biztosan nem, legfeljebb hasonlóan működik...
   
proof88 - Törzstag | 530 hsz       Online status #126426   2010.01.15 05:08 GMT+1 óra  
nem elérhető a foosballmaniac.com
   
gaborlabor - Moderátor | 4449 hsz       Online status #126425   2010.01.15 05:07 GMT+1 óra  
Köszi a válaszokat.

Idézet
Wolfee :
nem tömb!
[...]
Viszont, hogy belül mi van (láncolt lista, tömb, más) az nem szabványos.
[...]


Nem is azt írtam, hogy tömb, hanem hogy dinamikus tömb!
Mivel a szabvány szerint konstans idejű elérést biztosít az elemekhez és konstans idejű beszúrást/törlést a végére/végéről, szerintem nevezhető dinamikus tömbnek (többek között egy gamedev.net-es cikkben is így hívják). [nadam meg megelőzött]

Azt tudtam, hogy az iterátor nem más, mint egy pointer az adott elemre, ez néha hasznos is, de ha csak kiolvasni akarom az elemek értékét, akkor nem nagyon.

   
nadam - Törzstag | 364 hsz       Online status #126424   2010.01.15 04:53 GMT+1 óra  
Wolfee:

Az STL konténerek kontraktja nem csak azt mondja meg, hogy mit produkálnak az adott metódusok, hanem az időkomplexitást is kikötik. Enélkül elképzelhetetlen a gyakorlati életben is használható (komolyan vehető) container library.

A vektor definíciója ez:

"A standard container which offers fixed time access to individual elements in any order. "

Ki van tehát kötve, hogy O(1) (vagyis fix) idejűnek kell lennie a random elemelérésnek. Ezt láncolt listával nem lehet megvalósítani. Nem kötelező belső tömmbbel dolgozni, de aki foglalkozott már ilyesmivel, az 99%-ra meg tudja modani, hogy egy kicsit is optimális megvalósítás az belső tömbbel dolgozik.

Megnéztem egy STL megvalósítást:

http://www.cs.brown.edu/~jwicks/libstdc++/html_user/stl__vector_8h-source.html

Természetesen belső tömbbel dolgozik, itt a releváns metódus:

Kód:
reference
  operator[](size_type __n) { return *(begin() + __n); }


(Meg lehet nézni a begin() implementációját, de ne feledjük, hogy ezek mind inline függvények, az elsőre komplexnek tűnő C++ bűvészkedéstből végül a fordító végül olyan asm kódot fordít az operator[] esetében, hogy egy pointertől kezdődő tömbbe relatíve címzünk __n-el. )

Azért az STL implementációk optimalizálására elég sok figyelmet fordítottak, elég jól össze vannak rakva. (Bár nagyon elvetelmültek szoktak még gyorsabb cuccokat csinálni, de általában speciális felhasználási esetekre tervezve.)
   
bit.0x8000 - Törzstag | 574 hsz       Online status #126423   2010.01.15 04:47 GMT+1 óra  
Idézet
Wolfee :
viszont igen, az operator[] az i-edik helyen álló elem értékét adja vissza. Ezzel szemben az iterátor az az i-edik elemre mutató pointert.



Biztos, hogy pointer-t ad vissza?
   
Kuz - Törzstag | 4455 hsz       Online status #126420   2010.01.15 03:43 GMT+1 óra  
Most nem azért, de a puding próbája az evés. Igen gyorsan le lehet tesztelni, hogy melyik a lassabb, nem?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Wolfee - Törzstag | 1337 hsz       Online status #126419   2010.01.15 03:40 GMT+1 óra  
nem tömb!
a vectornak a belső megvalósítása STL implementációnként változhat. ő csak azt tudja, hogy az interfésze standard, tehát a GCC-hez meg a VCC-hez mellékelt STDben is van a vector<>-nak size() meg operator[] meg push_back() meg... függvénye. Viszont, hogy belül mi van (láncolt lista, tömb, más) az nem szabványos.

viszont igen, az operator[] az i-edik helyen álló elem értékét adja vissza. Ezzel szemben az iterátor az az i-edik elemre mutató pointert.
operator[]-gal nem lehet pl törölni a vectorból, csak iterátorral. (pont az érték vs pointer miat)

hogy a kérdésre is válaszoljak: nem hiszem, hogy annyival lassabb lenne, hogy érdemes lenne érte szétbarmolni a kódot
FZoli jóváhagyásával XD

   
nadam - Törzstag | 364 hsz       Online status #126414   2010.01.15 02:52 GMT+1 óra  
bit.0x8000:

igen, jó ötlet!

Közben az is eszembe jutott, hogy a size() függvény valószínűleg inline fordul, és kb annyit tartalmaz, hogy "return size;", szóval végül a fordító jóvoltából valószínűleg akkor sem lesz lassabb a cucc, ha minden iterációban "meghívódik" a v.size(). (De csak tippelek.)
   
bit.0x8000 - Törzstag | 574 hsz       Online status #126412   2010.01.15 02:47 GMT+1 óra  
Idézet
nadam :
Persze nyilván ne kérdezd le a méretet minden iterációnál, tehát így csináld:
Kód:
int size = v.size();
for (size_t i = 0; i < size; i++)
{
...
}




Még egyszerűbben:
Kód:
for (size_t i = v.size(); i--;)
{
...
}
   
nadam - Törzstag | 364 hsz       Online status #126411   2010.01.15 02:44 GMT+1 óra  
Szerintem a második gyorsabb vagy legalábbis nem lassabb, (és én is ezt preferálom, mert szebb,) de csak tippelek, nem néztem meg a vector forrását (de nagyon nagyon csodálkoznék, ha a [] operátor nem egy sima belső tömbcímzésre fordulna....)

Persze nyilván ne kérdezd le a méretet minden iterációnál, tehát így csináld:
Kód:
size_t size = v.size();
for (size_t i = 0; i < size; i++)
{
...
}
   
gaborlabor - Moderátor | 4449 hsz       Online status #126406   2010.01.15 02:12 GMT+1 óra  
Ha std::vector-t használok, ami tulajdonképpen egy dinamikus tömb, akkor a bejárását megéri/jó-e nekem iterátorokkal elvégezni? Vagy simán jó az operator[ ] is? Én az utóbbit preferálom, mindig azt használtam, csak a példakódokban mindenhol iterátorokat látok.

Ennél
Kód:
for (std::vector<int>::iterator it = v.begin(); v.end() != it; it++)
{
...
}


szerintem szebb és olvashatóbb ez:
Kód:
for (size_t i = 0; i < v.size(); i++)
{
...
}


Viszont a 2. lassabb is, ha jól gondolom, mivel minden iterációnál lekérdezi a vektor méretét.

De egyébként, mivel itt random access iterator-ról van szó, egy-egy elem elérése esetén nincs különbség sebességben a kettő között, igaz?

   
syam - Törzstag | 1491 hsz       Online status #126332   2010.01.13 12:30 GMT+1 óra  
Ha MSVC-t használsz, akkor debug módban az alábbi értékkel tölti fel a pointereket:

•The newly allocated memory (0xCD) is Clean memory.
•The free()d memory (0xDD) is Dead memory.
•The guard bytes (0xFD) are like Fences around your memory.

Több info itt:
http://www.nobugs.org/developer/win32/debug_crt_heap.html
alias aalberik
   
mark576 - Tag | 256 hsz       Online status #126243   2010.01.12 23:00 GMT+1 óra  
Szerintem most sikerült jól összezavarnod mindenkit. static-re gondoltam.
   
Asylum - Törzstag | 5504 hsz       Online status #126242   2010.01.12 22:45 GMT+1 óra  
Akárhol is foglalódik le (stack v heap) mindig "szemét" lesz az értéke. A többiröl nem tudok nyilatkozni.

Elég botrányos elnevezés ez a "statikus változó", mert C-ben konkrétan mindenki pl. a static int i; -t érti alatta, pedig ugy általánosságba ugy értelmeznénk, hogy ami a végrehajtási stacken foglalódik le. Szerintem valahogy úgy kéne ezt kategorizálni, hogy:

statikus memóriafoglalású változó: stacken
dinamikus memóriafoglalású változó: heapen
statikus változó: a main memóriaterületen (vagyis az egész futás során él)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
mark576 - Tag | 256 hsz       Online status #126241   2010.01.12 22:35 GMT+1 óra  
Idézet
bit.0x8000 :
Idézet
mark576 :
Alapértelmezetten nincs értékük, memória szemét.



Mint a lokális változóknál?


Szerintem a nem statikus változóknak mindig szemét az értéke, ha semmit nem adsz nekik. Ez ilyen C++ dolog, hogy ettől gyorsuljon minden. Mert egyébként dupla értékadás lenne.

Ezt a hozzászólást mark576 módosította (2010.01.12 22:41 GMT+1 óra, ---)
   
proof88 - Törzstag | 530 hsz       Online status #126236   2010.01.12 16:26 GMT+1 óra  
Próbáld meg a -wall kapcsolóval fordítani a programod. Asszem ezzel lehet az összes warningot amit csak rá lehet mondani a programodra kikényszeríteni. De nem tudom. VC++ az tudom, hogy szól az inicializálatlan változókért.
   
Wolfee - Törzstag | 1337 hsz       Online status #126224   2010.01.12 14:22 GMT+1 óra  
a szabvány semmit nem mond ki a változók kezdőértékeiről
FZoli jóváhagyásával XD

   
bit.0x8000 - Törzstag | 574 hsz       Online status #126223   2010.01.12 14:20 GMT+1 óra  
Idézet
proof88 :
nem tudom, de alap, hogy nem kapnak semmit. Úgy írd, hogy te magad adod meg.



Igen, végül is arra voltam kíváncsi, hogy mi a "standard".
(Az már más kérdés, hogy hogyan detektálod az ilyen "hiányosságokat", ha a programod kipróbáláskor vígan fut. Bár a gcc-ben biztos ehhez is van valami paraméter, majd egyszer megkeresem )
   
proof88 - Törzstag | 530 hsz       Online status #126222   2010.01.12 14:13 GMT+1 óra  
Wolfee jól mondod. Release módban pedig az lesz a tartalmuk, mint ami azon a memóriaterületen épp van. Tehát nem árt, ha a konstruktorban alap értékeket adsz meg nekik. Persze csak ha szükséges.

szerk.: nem tudom, de alap, hogy nem kapnak semmit. Úgy írd, hogy te magad adod meg.
szerk2.: ráadásul lehet, hogy linux alatt ott pont null volt.
   
bit.0x8000 - Törzstag | 574 hsz       Online status #126221   2010.01.12 14:11 GMT+1 óra  
Igazából ez a CodeBlocks/SDL-nél jött elő: Linux alatt megkapta a null kezdőértéket, Win alatt meg nem...
   
Wolfee - Törzstag | 1337 hsz       Online status #126220   2010.01.12 14:08 GMT+1 óra  
a VS debug módban ad nekik null kezdőértéket, ha jól tévedek
FZoli jóváhagyásával XD

   
bit.0x8000 - Törzstag | 574 hsz       Online status #126219   2010.01.12 13:57 GMT+1 óra  
Idézet
mark576 :
Alapértelmezetten nincs értékük, memória szemét.



Mint a lokális változóknál?
   
mark576 - Tag | 256 hsz       Online status #126218   2010.01.12 13:56 GMT+1 óra  
Alapértelmezetten nincs értékük, memória szemét.
   
bit.0x8000 - Törzstag | 574 hsz       Online status #126216   2010.01.12 13:53 GMT+1 óra  
Egy rövid kérdés: ha egy objektum létrehozásakor a változóinak explicit nem adok értéket, akkor azoknak alapértelmezetten valamiféle "nullértéket" kéne kapnia, nem?
   
mark576 - Tag | 256 hsz       Online status #126165   2010.01.12 02:40 GMT+1 óra  
@svn: Na, egy dolog amiben egyetértünk. Asynak venni fogok zsírkrétát, meg palatáblát, hogy azzal programozzon.
   
fpeti - Törzstag | 1295 hsz       Online status #126134   2010.01.11 09:22 GMT+1 óra  
Idézet
Asylum :
Akko legalább ki lehessen kapcsolni


Tools->Options->Text editor környékén vannak ilyesmik, nyelvenként (sharp nekem nincs, azt nemtom )
   
Asylum - Törzstag | 5504 hsz       Online status #126125   2010.01.11 07:03 GMT+1 óra  
Akko legalább ki lehessen kapcsolni
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
svn - Tag | 92 hsz       Online status #126103   2010.01.10 23:38 GMT+1 óra  
Idézet
Asylum :
A vc++ -t hagyják meg ilyennek amilyen...minek ide refactor...ott a find and replace + reguláris kifejezések (ja hogy nem tudjátok miaz hát csak sajnálni tudlak titeket).



Nagyon is hasznos a refactoring vc++ alatt. Két kattintás és megvan, mi a fenének szórakozzon az ember regexp-el? Teljesen felesleges. Nem titkárnők vagyunk, és gépelnünk kell, hanem kódot fejleszteni. Legyen egy halom eszköz ami kinyalja az ember seggét és segít abban, hogy csak a kódolásra kelljen koncentrálni (legyen az c++, c# vagy bármi más).
bőgtem bazdmeg, mint carlos szokott amikor nem kap rózsaszín nyalókát a boltban... by Admiral Pecek
   
mark576 - Tag | 256 hsz       Online status #126102   2010.01.10 23:05 GMT+1 óra  
@Asy: Majd, ha éles környezetben kell tevékenykedned és azt mondják, hogy ez, meg ez 10 perc múlva legyen a release-ben, akkor majd rájössz, hogy ezekkel az eszközökkel akár fele, vagy harmad idő alatt is meg lehet írni ugyanazt a kódot. Nem hülyeség az se, ha gépelési időben dobálja a hibákat a rendszer, nem csak fordítás után. Egy Bjarne féle emberke megteheti azt, hogy az egyetemen elpöcsöljön a notepaddal, egy kutatási projectben, de az teljesen más.
   
Wolfee - Törzstag | 1337 hsz       Online status #126100   2010.01.10 16:25 GMT+1 óra  
Idézet
Asylum :
Tudom rengeteg editor van linux alatt de én már anyám hasában is a pico-t használtam ugyh már automatikusan azt irom be


gáááz. Vim for prezident
FZoli jóváhagyásával XD

   
Asylum - Törzstag | 5504 hsz       Online status #126095   2010.01.10 14:22 GMT+1 óra  
Tudom rengeteg editor van linux alatt de én már anyám hasában is a pico-t használtam ugyh már automatikusan azt irom be
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bit.0x8000 - Törzstag | 574 hsz       Online status #126094   2010.01.10 14:20 GMT+1 óra  
Idézet
Asylum :
Én még linux alatt is elvagyok a kis pico-val, használni alig tudom de mégis ugyanolyan gyorsan kódolok benne mint mondjuk vc++ ban.



Ne légy igénytelen: használj vim-et.
   
Asylum - Törzstag | 5504 hsz       Online status #126093   2010.01.10 14:10 GMT+1 óra  
Engem speciel baromira idegesit amikor a vc# az amugy szépre formázott kódomat össze vissza szurkálja tabokkal, meg aláhuzza pirossal meg egyebek. Jó tudom ki lehet kapcsolni de egyszerüen nincs ingerem keresgélni, hogy hol, inkább elöveszek egy (normális) szövegszerkesztöt. Ugyanez a legtöbb java-s fejlesztöeszköznél.

A vc++ -t hagyják meg ilyennek amilyen...minek ide refactor...ott a find and replace + reguláris kifejezések (ja hogy nem tudjátok miaz hát csak sajnálni tudlak titeket).
Én még linux alatt is elvagyok a kis pico-val, használni alig tudom de mégis ugyanolyan gyorsan kódolok benne mint mondjuk vc++ ban. Intellisense helyett max google.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
mark576 - Tag | 256 hsz       Online status #126092   2010.01.10 13:31 GMT+1 óra  
Egyszer az egyik VC++ IDE fejlesztőt megkérdezték a type rename funkcióról. Erre csak vigyorgott az ipse, hogy majd egyszer lesz, már tervben van. Az Eclipse ezt már 100 éve is tudta.
   
Joga - Törzstag | 1791 hsz       Online status #126087   2010.01.10 11:16 GMT+1 óra  
Még az ékezeteket is viszi
(ಠ ›ಠ) Stewie!

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] > 60 < [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [143]