Mégsem jó úgy, ahogy akartam... Adott egy c# control, annak van egy Handle property-je.
Ezt át akarom adni a c++ kódnak, és ott HWND-t csinálni belőle. Első körben úgy ellenőrzöm, hogy lekérem a méretét (GetClientRect), és kiírom egy file-ba.

Így próbálom az egészet:


szerk.:
Hmm, mégis csak működik.

Idézet

---

versio :
Pretender: kiprobalhatjuk ki a bena, irjal c++-ban egy olyan programot ami 10 millio floating szamot sorbarendez, en c#-vel leverlek 10-szeresen abban biztos vagyok

---

Programozási időben igen, viszont a programod futási ideje és általa lefoglalt memória méretét tekintve szerintem nem a ráfordított kódolási idő a lényeg! Persze megvannak mindkettőnek az előnyei és hátrányai is.

ha public a valtozo pl :

public alma = 10;

akkor unityban az inspector ablakban is megjelenik a script reszlegben, es jatek kozben is allitgathatod

A c++11 ben lehet.

mintha c++ban is lehetne

de c#-nel ilyen felesleges baromsagokra nincs szukseg, mert a valtozok deklaralasakor mar erteket lehet neki adni

class gyumulcs
{
int alma = 10;

public gyumulcs()
{
}
}

Ja akk sorry én nem C++ -zok.

Itt azt mondják, hogy nem lehet.

Idézet

---

The first one is not legal in C#

---

Nem ez érdekelt.
Elmagyarázom.
A c++ ban ahogy c# ben is a típusoknak van konstruktoruk.
C++ ban a konstruktornak nincs visszatérési értéke csak neve és bemenő paraméterei,inicializáló listája és törzse.

Itt egy példa:
class myType {
public:
myType(int, bool);
private:
int itsX;
bool itsV;
};

/*Figyeld meg,kettőspontot tettem a bemenő paraméterei után.A kettőspont azt jelzi,hogy amit utána írok azt a konstruktor inicializáló listájába fogom írni.Oda csak értékadó műveletek mehetnek egyéb kifejezések nem.Legalább is c++ ban*/
myType::myType(int x, bool v):
this->itsX(x),
this->itsV(v)
{
//Ez pedig a konstruktor törzse ide jöhetnek mondjuk a számítások
}

int main() {
myType type(4444, true);
return 0;
}

Értitek már ugyanezt akarom c# ben.
Nem a konstruktor törzsében akarok a tagváltozóknak értéket adni hanem a konstruktor inicializáló listájában.

Pretender nem láttam a te hozzászólásodat csak miután ki írtam az enyémet bocsi de azért jöhetne részletesebb magyarázat erre.

Ez azt jelenti,hogy c# ben ez nem lehetséges?

Ha jól tudom c#ban nincs initlist. Legalábbis nem valid.

@Pixi: nem listáról volt szó, hanem inicializáló listáról, ami c++ban egyszerűen használható:

Ezt nézted már?

msdn.microsoft.com/en-us/library/vstudio/bb397680(v=vs.100).aspx

// The default constructor has no parameters. - ebből azt veszem ki, hogy az alapnak nincs meghatározott paramétere, azt a példa legalul szintén úgy hozza létre egy Lista segítségével:



Azért remélem ír valami hozzáértőbb személy is, mostmár én is kiváncsi lettem mit szeretnél pontosan.

Én csak azt akarom megtudni,hogy egy c# osztály konstruktorának az inicializáló listájában(Nem a törzsében),hogyan inicializálunk változókat. Erre választ nem találok sehol .

Lehet, hogy nem teljesen értem amit akarsz. Szóval te példányostani szeretnéd magát az osztályt, méghozzá úgy, hogy egy listában is számon tartod az elemeket? Én most XNA-s projektból másolok egy egyszerű példát, ugye ez is C#:



ui: ja most látom nem a listába helyezés volt a kérdés Én publikáláskor a zárójelben is ugyanazt a nevet használom, mint az adattagoknál, de ettől még ugyanúgy működik ez ne zavarjon össze.

C# nek,hogyan kell használni a konstruktor inicializáló listáját?
C++ így jó volna de itt c# ben nem akar működni.Meg oldható ez valahogy az inicializáló listában ha igen,hogyan?
public EszrevetelClass(Transform _otherTrans, Transform _originalTrans, float _speed = 4.0f):
this.other ( _otherTrans),
this.original ( _originalTrans),
this.speed = (_speed)
{}

Idézet

---

versio :
meg jo hogy nem kell destructor, kit erdekel mikor torlodik a memoriabol az legyen a rendszer dolga, pont ezert jo a c# , nem tudsz torolni valamit ami meg kellhet, vagy nem hagysz benne valamit ami mar nem kell, c++-ban az idod felet ezeknek a faszsagoknak a debuggolasaval toltod , a produktivitas meg zero

---

Ez hülyeség. Megísz magadnak egy memória management-et és az központilag megoldja a memória kezelést, figyelmeztet, ha nem volt törlés stb. Többszörösen öröklést meg nem muszáj használni csak azért mert a nyelvben ott van és feltétlenül el kell gáncsolnia magát a fejlesztőnek, tervezni kell úgy, hogy ne legyen rá szükség.

Pretender: kiprobalhatjuk ki a bena, irjal c++-ban egy olyan programot ami 10 millio floating szamot sorbarendez, en c#-vel leverlek 10-szeresen abban biztos vagyok

Idézet

---

versio :
c++-ban az idod felet ezeknek a faszsagoknak a debuggolasaval toltod , a produktivitas meg zero

---

Hát, ha valaki béna...

@Viperion:
Csak egy konkrét implementációt tartalmazó osztályból tudsz öröklődni, a többi legfeljebb interface lehet. Hogy miért? Mert hülyék, és azt mondták, hogy nincs rá szükség. Túl sokszor valóban nincs, de néha nem ártana, ha lenne...

Amit versio linkelt, az meg nem igazi öröklődés, hanem generices trükközgetés. De hát ilyen egy hatékony nyelv...

versio én nem értem,hogy hogyan gondolja a megvalósítást azon a linken. De amúgy kösz.

Viperion, ha csak ez hianyzik a boldogsagodhoz

http://putabout.wordpress.com/2008/04/06/tobbszoros-oroklodes-c-ban/

Miért nincs a c# ben többszörös öröklődés?

meg jo hogy nem kell destructor, kit erdekel mikor torlodik a memoriabol az legyen a rendszer dolga, pont ezert jo a c# , nem tudsz torolni valamit ami meg kellhet, vagy nem hagysz benne valamit ami mar nem kell, c++-ban az idod felet ezeknek a faszsagoknak a debuggolasaval toltod , a produktivitas meg zero

Tévedés, hogy ne lenne destruktor, szintaxisa:



Az egyetlen gond vele, hogy nem igazán jó semmire, nem determinisztikus, hogy mikor hívódik meg a függvény, mivel a GC (GarbageCollection) saját maga kezeli a memóriát, nem igazán érdemes beleszólni, hogy kit mikor dobjon ki, annyit kell tudni erről, hogy különböző generációkba osztja az egyes objektumokat, és ennek megfelelő sorrendben szabadul meg tőlük, amikor helyre van szükség, pontosan ezért nem lehet megmondani mikor fut le a destruktor, így nem igazán szokás használni, egyszerűen felesleges.

Már nem lényeges a kérdés megoldottam a problémát ha akarjátok törölhetitek.
Amúgy köszi mindent.

Egyébként az volt a baj,hogy amelyik osztály örökli a MonoBehaviourt abban nem használható a konstruktor.

Itt miért kapom ezt a hibakódot: CS1729





Tudom mit jelent ez a hibaüzi de nem értem miért kapom hisz át adok neki én egy transform objektet és mégis.

.NET-ben nincs destruktor, illetve managed objektomoknál nincs is értelme, mert a GC felszabadítja, ha nem hivatkozik rá senki. 1-1 managed objektumra, ha nem hivatkozik semmi, akkor halottnak nyílvánítja a rendszer és onnan vagy feltámad, vagy a GC kinyírja egyszer, ha úgy tartja kedve.

Nem managed objektumoknál van értelme a "destruktornak", itt az ún dispose pattern-t lehet használni. Ennek lényege, ha a coder elfelejti meghívni a Dispose-t, akkor kinyírás előtt a rendszer megteszi.

A fentieknek semmi köze a C++ féle destruktor fogalmához, teljesen más a kettő memória kezelési mechanizmusa.

Semmi köze nincs ahhoz, hogy inline, vagy sem.

szerk.:
Na jó, kicsit konstruktívabb is legyek... c++ban az az alapvető szabály, hogy a header nem tartalmaz implementációt, egyfajta interfaceként szolgál csak. Egyéb nyelvekben (pl. c# és java) ez nem így működik, ott egyetlen fájl tartalmazza a deklarálást és a definiálást (tudjuk a különbséget!)

Attól, hogy a deklarálás és a definiálás egyetlen helyen van, még nem lesz inline, szimplán más elvet követ a két nyelv. És nagyon fontos, hogy ne akarjuk az egyiket úgy használni, mint a másikat.

C#-ban pedig nincs destruktor, csak valami dicső függvény (finalize talán? vagy az java?)

A c# nek van szemétgyűjtője,akkor én mire használjam benne a destruktort?
És miért kell az osztályon belül létrehozni a metódusok törzsét.Nekem c++ után ez úgy tűnik,hogy c# ben csak is inline módon létezhetnek az osztályokban a metódusok.
Példa:
public class Xy
{
private Xy(); //Így nem jó
public float getXyValue(); /*Nem jó nem lehet később megírni benne a metódus megvalósítását mint a c++ ban. Ugy akarnám mint a c++ ban:
visszatérési_értéke osztálynév::metódusa() {törzs} Így nem inline c++ ban.
}

Csak így jó, de ez C++ ban inline, C# ben is?Mert ha ige akkor nagy kóddal rendelkező metódus esetén ez fos módszer az tuti.
public class Xy
{
private Xy() {}
public float getXyValue() { /*Ngayon sok kód*/ }
}

Megoldodott, a projekt fájlban a IncludeAssemblyInVSIXContainer-t át kellett állíteni true-ra.

Valaki írt már visual studiohoz plugint? (konkréten MEF komponenst).
Az a bajom, hogy k*rvára nem töltödik be, a log viszont azt mondja, hogy igen...debugolni sem tudom mert "no symbols loaded".

Amugy csak azért kéne hogy az UML editorban úgy tudjam kiexportálni a xaros képet hogy átlátszó legyen a háttér...

A Skynet jo példa, de most már nem mondok semmit. Majd megcsinálom és akkor rájöttök (meg én is) mi motoszkál bennem. (lehet hogy csak valami betegség, de legalább megpróbálom)

Idézet

---

(A jelszós példányosítás meg egy nagyon programozó szinten lévő biztonsági mech szerintem így első ránézésre. Jelszóval védjük fájljainkat, adatainkat a neten, mért ne lehetne egy objektumot is védeni. Lehet, hogy nagyságrenddel biztonságosabb programokat lehetne csinálni...)

---

Ez fájt, de nagyon. Ezek szerint azért van az a sok sechole egyes programokban, mert valami galád eljárásban galád módon példányosítanak egy osztályt? Ki, vagy mi ellen védenénk jelszóval az objektumokat? A Skynet ellen?

Bukta:
Azért negatív mindenki, mert olyan felütéssel kezdted, hogy minden nyelv szar, mert vannak benne korlátok. Erre nehéz sok jót mondani.
Amúgy meg ha már olyan régóta használják olyan sokan, és még jön is ki belőle új változat, akkor nem lehet, hogy amire tényleg szükség van az belekerült? Pl magadnak definiálható hozzáférés módosító nem kell, de lambda kifejezés meg igen.

Persze ha valami világrengetőt kitalálsz, az oké, ha hiányolod. De néhány nagyon gyenge hasraütésszerű példával bizonyítani, hogy szar minden.
"Azért szart a gazdaság, mert nincs ingyen sör meg ingyen internet"

Idézet

---

Honnét tudod minek mi értelme van?

---

Mondjuk onnan h 8 eve aktivan programozok?
A legjobb pelda a C++0x bol kivett conceptek. Baromi jo otlet, baromi hasznos lett volna, de a kutya nem hasznalta/nem ertette.

Bukta: Te szerintem kevered az adatbázis kezelést a programozással, vagy csak nagyon unatkozol. Egyébként vicces lenne jelszóval levédeni osztályokat, biztosan örülnének neki az adott libet használók.

Hasra ütés helyett szerintem többet ér ha nekiállsz kódolni, megpróbálod megvalósítani amiket szerinted nem lehet. És ha tényleg nem lehet, akkor posztolod a problémát, esetleg a kódot ami már majdnem tudja amit kellene, de mégse.
Szerintem sokkal értelmesebb és szakmaibb viták lennének belőle, minthogy leállsz szidni egy olyan nyelvet amit milliók használnak és még mindig nem váltotta fel más az adott területen és amit nem csak úgy hasra ütés szerűen építettek fel.

Jó most csak hasra ütöttem és írtam pár dolgot, ki tudja. Van egy millió programozo lehet hogy vkinek felötlenek ilyenek és ugy gondolják hogy ha azt ugy meg lehetne csinálni akkor jobb lenne. Nem a konkrét példáimmal akarok meggyőzni senkit, csak próbálok tágabban gondolkozni.
(A jelszós példányosítás meg egy nagyon programozó szinten lévő biztonsági mech szerintem így első ránézésre. Jelszóval védjük fájljainkat, adatainkat a neten, mért ne lehetne egy objektumot is védeni. Lehet, hogy nagyságrenddel biztonságosabb programokat lehetne csinálni...)
A "Kurvasok ertelme van..." mondat szerintem akkor is elhangzott mikor Galilei asszondta h forog a Föld. Honnét tudod minek mi értelme van? A php-re meg akkor a lambdára is biztos sokan mondták h semmi értelme mégis mi lett belőle. A dolgok attól érdekesek, hogy parányi dologból lesz valami amit nem gondoltunk volna. Nem mondom, hogy meg lehet váltani a világot, meg hogy 100% hogy a C++nál van jobb is meg hogy előre tudom, hogy most milyen lesz/lenne, meg hogy "dual_password onlyonce donottouch unbondable standalone class MySuperClass {...}" ilyen sorok lennének benne. De olyan negatívak vagytok mind állat. Mondom, hogy mi lenne ha talán ez meg ez lenne és akkor mi van: Annak mi érelme, minek az neked? Semminek, de lehet, hogy kialakul belőle valami.
De azért nagyjából kiderült, hogy a C++ is jó ilyenekre. Büszke vagyok a csapatra
[igaz én ettől még megcsinálom ahogy Matzi mondta ]

Idézet

---

Matzi :
Ne panaszkodj róla ,hogy miért nem csinálnak ilyet meg olyat, pláne ilyen buta példákkal. Csináld meg, és bizonyítsd be vele, hogy mennyire beszédes és jó amit kitaláltál, és akkor lehet, hogy valamikor elterjed.

---

Ott a pont!

Jelszoval peldanyositani ...

Tessek:



Kurvasok ertelme van...
Amiket meg leirtal mindegyik megcsinalhato C++ ban.

"Mi van akkor, ha én ugy akarok deklarálni egy osztályt, hogy azt csak:
-egy adott osztály tudja példányosítani
-egy adott névtérben lehet példányosítani
-az tudja példányosítani, aki ismeri az xyz jelszót"
A kérdés az, hogy minek? A hozzáférési módosítók védelmek. Részben azért, hogy ne kövess el könnyen hibát, de legfőképpen azért, hogy ha kiadod a kezedből az osztályt (nem a kódot, a binárist), akkor le legyen szabályozva, hogy mihez férhetsz hozzá, így nem rontja el egy másik programozó egykönnyen.
Amiket te leírtál, ezeknek például egyiknek sem lenne értelme. Ráadásul ez is olyan lenne, mint az operátor overload, ami ha rosszul használják több problémát okoz, mint amennyit megold.

Mondd meg ez mit jelent, és akkor én implementálom neked a fordítót hozzá:
"dual_password onlyonce donottouch unbondable standalone class MySuperClass {...}"
Nem véletlenül vannak a kötöttségek, hogy ne fuss bele ilyenekbe. Hidd el, nálam és nálad okosabb emberek fejlesztik ezeket a nyelveket, olyanok, akik láttak már akkor tapasztaltak voltak, amikor te még olvasni tanultál. Ennek ellenére, ha kifejlesztesz egy ilyen nyelvet, még lehet, hogy valamikor még lesz is belőle valami. Ne panaszkodj róla ,hogy miért nem csinálnak ilyet meg olyat, pláne ilyen buta példákkal. Csináld meg, és bizonyítsd be vele, hogy mennyire beszédes és jó amit kitaláltál, és akkor lehet, hogy valamikor elterjed. Pl a lambda kifejezések is hasonló igényből erednek, és puff, manapság már elérhetőek jópár nyelvben.

Ami manapság a divatos, az inkább a dinamikus programozás, ahol menet közben tudod módosítani a program viselkedését, illetve fel fel tűnnek apróbb igények.

Például jelenleg sokkal fontosabb probléma egy olyan fordító (esetleg nyelvi elem) kifejlesztése, ami jelentősen megkönnyítené, hogy párhuzamosan sok magon tudjanak futni a kódok kevés erőlködéssel. Ez egy érvényes és fontos probléma, míg az, hogy jelszóval lehessen egy osztályt példányosítani az nem.

Parallax: nyilván C vagy C++, de attól még hogy a { jelet begin-nek nevezed még nem lesz más a funkciója. Ahogy a C#ban sem lesz más ez:
using sys = System;
A #define integer int; mint integer 'típus' is csak egy alias név az int-re semmi értelme nincs csak hogy izlés szerint más legyen a neve, de attól még ugyanaz a típus mint az int. Igaz nem vagyok nagy C prog mester, de így a nyelvet azért átlátom.

Pretender: "akkor írd le nekem függvénnyel a new, delete, vagy esetleg a static keywordöt" A függvényest ugy értettem, hogy assembly-beni "függvény" magyarán, hogy assemblyben meg lehet írni. És igen erre gondoltam, hogy ilyen gyökeres kulcsszavakat lehetne írni. Nem pedig alias nevekre gondoltam.
""saját keyword"re pedig nem igen van szükség" akkor mutatok vmit:

Mindenki találkozott már ilyenekkel. Az Asd példányokat nem lehet publikussá tenni ha az osztály privát.

Mi van akkor, ha én ugy akarok deklarálni egy osztályt, hogy azt csak:
-egy adott osztály tudja példányosítani
-egy adott névtérben lehet példányosítani
-az tudja példányosítani, aki ismeri az xyz jelszót
és pl így is lehetne

Más: mi van akkor ha ha egy delegátot, vagy eventet úgy akarok meghívni/feltölteni/feliratkozni, hogy azt is csak adott helyen vagy adott jogosultsággal rendelkezők tudják használni. És persze a jogosultságokat is én írnám le.

Nem tudom, de ha ti mondjátok elhiszem, hogy ezeket -,meg 'mident' amit lentebb írtam- pointerekkel meg C nyelvel meg lehetne csinálni, de annyi mindent meg kéne változtatni, hogy érdemes lenne inkább egy új nyelvet írni ami kényelmesen használná az "új" lehetőségeket. És azt már lehet, hogy érdemes lenne assemblyben és akkor tutibiztos lesz minden.
Jah meg tudom, hogy nem véletlenül alakult ki az OOP, de attól hogy feltalálták az autót miért ne lehetne repülő. Akkor ez nem OOP lesz hanem ASD (A tervezési mintákkal nem lesz password class Asd sehogyan se, de ha tévedek javítsatok.)

Idézet

---

Bukta :
Saját kulcsszavakat írni, amivel bővítenénk a nyelvet

---

Előbb szerintem ismerd meg alaposan a nyelveket, utána nyilatkozz.

Egyébként:


Házi feladat kitalálni milyen nyelven lehet ezt.

[Off]
Biztos jól csinálod a dolgokat? Amiket felsoroltál az mind megoldható, az ilyen "saját keyword"re pedig nem igen van szükség...
"mikor függvényekkel mindent le lehet írni"
akkor írd le nekem függvénnyel a new, delete, vagy esetleg a static keywordöt

Nem véletlen alakult ki az OOP, eleve az egész szemlélet közel áll az emberi agy gondolkozásához (közös tulajdonságok, stb. - minden alma gyümölcs -> minden gyümölcs étel , ...), innentől pedig már csak gondolkozni kell (vagy esetleg neten tervezési mintákat nézegetni).
[/Off]

Szerintem meg a C, C++, C#, php, java mind egy rakás szar. Csak azért használjuk mert ezekből építettek várat, ezekből van az összes library, ezekhet vannak a gyors fordítók. Egyébként pedig az oop teljesen berögzült a c++ c# java php kb mind ugyanaz. Pl a public private protected.. miért kötöttek? Miért nem lehet saját elérésmódosítót írni? A class-on a struct-on túl miért nem írhatunk saját "tömböket"? Egyáltalán minek ez a sok kötöttség, mikor függvényekkel mindent le lehet írni -mint pl lefoglalt szavak. Az osztályok meg társaik miért fixek, miért nem lehet az int-re IComparable interfészt rákényszeríteni? Miért nem lehet olyanokkal bővíteni a kész "osztályokat" amikre gyártáskor nem gondoltak, pedig bele illenének.. Saját kulcsszavakat írni, amivel bővítenénk a nyelvet, csökkentenénk a library-k terjedelmét.
Ha ilyesmi rugalmasság lenne a nyelvekben, már nem ott járnánk ahol most, de már évtizedek óta ugyanaz megy, csak egyikre több sót szornak. Jó persze ez van ezt rakták alánk már nem lehet mit csinálni, csak reménykedhetünk, de senki se fogja megcsinálni mert ekkora változtatásokba nincs pénz, csak --money. Pedig a kód már szinte beszélne
Szó mi szó az Assembly nem való semmire, de mindenre megoldás.

Mindkettő nyelvvel dolgozok, szerintem semmi különbség nincs a fejlesztési sebességükben. Azért C++ t választom játékokhoz, mert egyszrűbb cross-platform architektúrát kialakítani mindenféle segédeszköz és megkötések nélkül. A sebsség mobil eszközökön okozhat gondot, jobban kell optimalizálni C#-nál (range checkinng, GC stb), ezért C#-ban picit nehezebb fejleszteni performanciára kihegyezett alkalmazást.

Idézet

---

Pretender :
"és nem kellene C++-al és a natív programozás minden gusztustalan apró részletével szenvedjek, kezdve a memóriafoglalásoktól a headereken át a fordításig"

Én tényleg nem értem... Miért baj az, hogy gyors kódot generál a fordító egy f6 megnyomása után? Mitől lesz ez gusztustalan? Mitől lesz ez átláthatatlan? Miért kell szenvedni a memóriafoglalással és a fordítással?

A C#ban folyamatosan memóriát foglalgatsz le (new Vector2() pl. ). Fordítani meg semmiben sem másabb. Szóval mi a probléma a C++al, ami miatt annyira a C#ot véditek?

---

Ez teljesen személyes vélemény volt, bár ezt oda is írtam. Egyáltalán nem utálom a C++-t, bőven meg van a maga helye a programozás világában. De amíg egyedül fejlesztek, addig nekem nagyon is számít a kényelem és a fejlesztés gyorsasága, amiben számomra a C#/.NET platform köröket ver a natív programozás minden formájára. Ráadásul egy viszonylag új, fejlődő, tök logikusan felépített nyelv, amiben egyszerűen fun programozni.
Részemről a téma lezárva, bár igazából ez nem hit-vita volt eleinte, hanem értelmetlen kötekedés (szerintem).

Én azt nem értem, hogy miért kell utálni a C#ot.

Én mindkettőt szeretem, és mindkettőnek megvan a maga szépsége, és a maga hibái is. És aki azt állítja, hogy a c++ tökéletes, és mindenre a legjobb nyelv, akkor azt kiröhögöm.

'nuff said.

De amúgy mi ez a nagy c++ utálat? Miért mondjátok az, hogy nehéz, bonyolult, undorító? Semmivel sem rondább, mint a C#. Valaki felvilágosítana?

"Szvsz egy hobby fejlesztőnek tök felesleges azzal szopatnia magát, hogy a C++al kínlódik"

"és nem kellene C++-al és a natív programozás minden gusztustalan apró részletével szenvedjek, kezdve a memóriafoglalásoktól a headereken át a fordításig"

Én tényleg nem értem... Miért baj az, hogy gyors kódot generál a fordító egy f6 megnyomása után? Mitől lesz ez gusztustalan? Mitől lesz ez átláthatatlan? Miért kell szenvedni a memóriafoglalással és a fordítással?

A C#ban folyamatosan memóriát foglalgatsz le (new Vector2() pl. ). Fordítani meg semmiben sem másabb. Szóval mi a probléma a C++al, ami miatt annyira a C#ot véditek?

A delegate pedig könnyen kiváltható, bár ez egy hiányossága a C++nak (mármint az ilyen event-handling - ami mondjuk egy relatív lassú dolog )

"Engem személy szerint nagyon idegesít, hogy C#ban nem mondhatom azt, hogy delete."
Engem meg az idegesít, hogy nincs rendes delegate, csak függvénypointer, ami ezer helyen elhalhat.

"Télleg sokkal átláthatóbb hogy egyetlen szaros fájlba van behányva minden metodus implementácioja..."
Nem mintha nem lehetne szétrakni több fájlba ott is.

Viszont a vallási vitákkal át lehet menni a Hit-vita topicba.

Idézet

---

Parallax :
Szájkarate?

Idézet

---

MaNiAc :
Ad1) Aki linuxon játszik, az már hozzászokott, hogy libEZ-t és libAZ-t mindig telepíteni kell - hála az égnek, ez mostanra nevetségesen könnyű (lásd: Gentoo, Ubuntu, etc)

---

Its great that people are enthusiastic about Linux as a gaming platform but there are not many people who are interested in paying for a game and that seems to be the reality.

---

Tehát, ha a dependency lib-es témára neked a warez (vagy mi az istent akartál ezzel a "paying for a game" dologgal??) a válaszod, akkor én szájkaratézok. Értem..... Na hagyjuk.

Egy ember legalább úgy tűnik megértette, mit akartam, szóval részemről nothing to do here. Btw az egész hozzászólásom sík felesleges volt, csak nem bírtam szó nélkül hagyni, hogy megint megy a szokásos vetítés, hogy a kezdők előtt fikázni kell mindent, ami nem C++, mert a hardcore programozók C++t használnak, meg amúgy is abban írtak egy valag játékot, blah, blah, blah. Who cares? Használja mindenki azt, ami tetszik neki. Minden nyelvnek, eszköznek, etc. van előnye, hátránya, etc.

Megszolalt a c++ riasztom. Méghogy gusztustalan ehh? Télleg sokkal átláthatóbb hogy egyetlen szaros fájlba van behányva minden metodus implementácioja...

A sebességröl meg: én pont ezért hagytam ott a fenébe Amikor egy mesh betöltés 24 mp volt neki. Jó persze mondhatod azt hogy mert szarul használtam. De kéremszépen, ha ezt annyira tudni kell használni, akkor miért is jobb?

Ettöl függetlenül a Tao-ról látom hogy sokan használják, úgyh erröl nem is akarok vitázni (meg nincs is ellenérvem).