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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
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] [141]
TPG - Tag | 3402 hsz       Online status #97207   2008.10.18 12:58 GMT+1 óra  
Idézet
Asylum :
hát oké lehet hogy valahol beérik vs-el is, mindenestre nem ártana elöször a szabványos c++ t megtanulni (énszerintem), mert sosem lehet tudni, hogy hol kötsz ki, akár még linux alatt is programozhatsz (a g++ tud ansi és iso szabvány szerint forditani).


Ahogy végignéztem a társaságon itt asszem nem lesz linux alatti munkavégzés soha, ennyi Vista user-t még sosem láttam. Másrészt a 90% körüli analízis bukási arány miatt nem hiszem hogy sokan fogjuk elvégezni a 3 évet.

Egyébként az új VC++ és a szabványok viszonyával nincs nagyon probléma, én ami véleményeket olvastam a témában az mind 98-99%-ra hozta a 2005/2008 esetében a szabványban felsorolt dolgok előírt módon való támogatásának arányát. Szóval nincs itt probléma csak az alap nyelvet még itt-ott tunningolják egy kicsit. Aki szabványos akar maradni, az nem használ ilyet.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97203   2008.10.18 12:27 GMT+1 óra  
hát oké lehet hogy valahol beérik vs-el is, mindenestre nem ártana elöször a szabványos c++ t megtanulni (énszerintem), mert sosem lehet tudni, hogy hol kötsz ki, akár még linux alatt is programozhatsz (a g++ tud ansi és iso szabvány szerint forditani).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #97198   2008.10.18 10:53 GMT+1 óra  
Idézet
TheProGamer :
Nah közben asszem meg van mért hal szét a NULL pointer-es hibával a cucc ha a header-ben csinálok scope-ba hozatalt. Nekiálltam debug-olni a cuccot, a call stack alapján a dolog működik, csak az első konstruktor ami ilyen módszerrel hívódik műveletet szeretne végezni egy másik singleton-al. Csakhogy az a másik singleton-os osztálynak abban a pillanatban még nem futott le a konstruktora, majd csak egy későbbi menetben futna le. Így ugyan el tudja kérni az ő osztálypéldányát, sőt még az adott függvényt is meg tudja hívni ami el is kezd végrehajtódni, viszont az egész ott bekrepál amikor egy ofstream adattagot használni akar a függvény. Ennek az adattagnak a konstruktora az adott osztály konstruktorában futna le, de az adott osztály konstruktora még nem futott le. Tehát tömören összefoglalva a módszer jó, csak ki kell egészíteni valahogy úgy hogy szükség esetén GetInstanceReference-re is valahogy lefusson a konstruktor ha addig még ezt nem tette meg.

Szerk: Kicsit utánanéztem, kiderült hogy ennek a problémának már neve is van, "static initialization order fiasco" cím alatt létezik.


Azt hiszem sikerült a problémát megoldani, még lenyomok pár tesztet hogy tényleg jól működik-e aztán felrakom ide a megoldást hátha valakinek kell majd később. Annyi már most elárulok hogy igen csúnya.
Reality is almost always wrong. - House

   
TPG - Tag | 3402 hsz       Online status #97196   2008.10.18 10:05 GMT+1 óra  
Idézet
Asylum :
ja azt elfelejtettem mondani, hogy az eltén nem használunk vc++ t tehát eleve kilöve az ilyen (szabványtalan) "megoldás".


Itt a PTE-n mi vagy VS6-ot vagy VS9-et használunk, azt hogy milyen szabványos a megoldás idáig még nem nézték és nem is hívták fel a figyelmünket arra hogy foglalkozni kellene ilyesmivel. Az a lényeg hogy forduljon le és nézzen ki kulturáltan.

Idézet
Asylum :
abstract class -t szintén lehet csinálni egyszerüen csinálsz neki egy pure virtual (asszem igy nevezik) metódust.


Jaja, viszont ennek az abstract kulcsszónak nem az a lényege hogy ettől lesz az adott osztály absztrakt. Ez csak jelzi a fordítónak hogy az osztály absztrakt, így ha olyat akarnak az osztállyal csinálni amit vele nem lehet akkor értelmes hibaüzenetet tud dobni. Márpedig nagy mennyiségű forrás esetén nem árt ha a hibaüzenet azonnal célra vezet és nem kell külön dekódolni.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97194   2008.10.18 09:28 GMT+1 óra  
ja azt elfelejtettem mondani, hogy az eltén nem használunk vc++ t tehát eleve kilöve az ilyen (szabványtalan) "megoldás".

abstract class -t szintén lehet csinálni egyszerüen csinálsz neki egy pure virtual (asszem igy nevezik) metódust.

a templates kiegészités jó ötlet
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #97193   2008.10.18 09:05 GMT+1 óra  
Idézet
Csizmás Kandur :
Épp én is pont ezeket próbálgatom. Tisztára olyan ez, mint a C#-ban. VS 2010-ben mégdurvább dolgok lesznek.


Jah, van egy kis C# feeling-je. Mondjuk az ilyen jellegű kulcsszavakat simán átemelhetnék a C#-ból a standard C++ ban, apró de annál hasznosabb kiegészítései lennének a nyelvnek. Emlékeim szerint ilyen dolgok nem szerepelnek a C++0x tervezetben (pedig simán elférnének, más ilyen jellegű kulcsszavas majomkodások vannak a tervezetben), úgyhogy majd talán legközelebb.
Reality is almost always wrong. - House

   
Csizmás Kandur - Tag | 436 hsz       Online status #97192   2008.10.18 08:56 GMT+1 óra  
Épp én is pont ezeket próbálgatom. Tisztára olyan ez, mint a C#-ban. VS 2010-ben mégdurvább dolgok lesznek.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
TPG - Tag | 3402 hsz       Online status #97191   2008.10.18 08:53 GMT+1 óra  
Idézet
Csizmás Kandur :
Ez tényleg megy mindenféle trükközés és fölösleges agyonbonyolítás nélkül. Lehet adni egy tockost annak a tanárnak.



Annyi az összes probléma a ezzel a verzióval hogy nem igazán hordozható kódot fog eredményezni. Cserébe viszont sokkal tisztább és a hibajelzés is egyértelműbb. Ezután egyébként még jobban utánanyomoztam a dolgoknak és még két ilyen kulcsszót sikerült találni a VC++ 2005-höz, mindkettő elég hasznosnak tűnik.
override: jelzi hogy az adott függvénynek mindenképp egy ősosztályban található függvényt kell felülírnia. Ha ez nem így történik az fordítási hibához vezet.
Kód:
struct I1 {
   virtual void f();
};

struct X : public I1 {
   virtual void f() override {}
};


abstract: jelzi hogy az adott osztály absztrakt, nem példányosítható.
Kód:
class X abstract {
public:
   virtual void f() {}
};

//error C3622: 'X': a class declared as 'abstract' cannot be instantiated
int main() {
   X * MyX = new X;
}


Ezek is természetesen működnek natív programok esetén, és szép egyértelmű hibákat dobnak gáz esetén. Ez utóbbi az igazi előnyük, nem kell virágnyelven írt marhaságok értelmezésével szopni hogy az ember rájöjjön ilyen esetekben a hibára, a fordító odamutat ahol a probléma van, és konkrétan megmondja mi az baja.
Reality is almost always wrong. - House

   
Ashkandi - Törzstag | 1044 hsz       Online status #97190   2008.10.18 08:35 GMT+1 óra  
-

Ezt a hozzászólást Ashkandi módosította (2008.10.18 10:30 GMT+1 óra, ---)

   
Csizmás Kandur - Tag | 436 hsz       Online status #97189   2008.10.18 08:26 GMT+1 óra  
Ez tényleg megy mindenféle trükközés és fölösleges agyonbonyolítás nélkül. Lehet adni egy tockost annak a tanárnak.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
TPG - Tag | 3402 hsz       Online status #97188   2008.10.18 07:24 GMT+1 óra  
Idézet
TheProGamer :
.....
másrészt a sealed-et a VC++ 2008 kulcsszóként ismeri fel, és ennek megfelelően kékkel ki is emeli, így még egy kicsit feltűnőbb hogy nem hagyományos származtatásról van szó.


Nah ennek gyorsan utánanyomoztam, mondván nem véletlen ismeri fel a VC++ 2008 a sealed-et kulcsszóként. És igazam is lett, VC++ 2008-ban (és ha minden igaz a 2005-ben is) megengedett az alábbi forma (natív kódban is, direkt kipróbáltam):
Kód:
class Derived sealed
{
public:
    Derived() {}
};

//  error C3246: 'Apple' : cannot inherit from 'Derived' as it has been
// declared as 'sealed'
class Apple : public Derived
{
public:
    Apple() {}
};
Reality is almost always wrong. - House

   
TPG - Tag | 3402 hsz       Online status #97187   2008.10.18 07:07 GMT+1 óra  
Idézet
Asylum :
igen, ez is egy megoldás (private konstruktor), söt ezt is felhasználja, csak nem egészen igy. Ugyanis a konrét szülö osztálynak nem kell, hogy privát legyen a konstruktora (és akkor már lelövöm a poént mert nagyon jo )

.......

virtuális öröklésröl wikipedia-n is lehet találni leirást (konkrétan a diamond problem-re alkalmazza).

a lényeg, hogy az Apple nem a Derived konstruktorát akarja meghivni, hanem a Base-ét merthogy virtuálisan van örökölve belöle (elvileg a Derived konstruktora csak azután hivodna meg). Viszont a Derived-nek látnia kell a szülö konstruktorát ezért azt felvesszük barátnak a szülöbe.

igy a Derived egy final (sealed akármi) class.


Igen humoros darab. Az a szép benne hogy ha megdobjuk egy CRTP-vel (curiously recurring template pattern), akkor máris általánosítva van az egész. Mondjuk így:
Kód:
template<class T> class Base
{
    friend T;
private:
    Base() {}
};
#define Sealed virtual Base

class Derived : public Sealed<Derived>
{
public:
    Derived() {}
};

A define-al mindjárt ki is van küszöbölve az hogy az ember véletlenül lefelejtse a virtual módosítót.

Szerk:
Kód:
template<class T> class Sealed
{
    friend T;
private:
    Sealed() {}
};
#define sealed virtual Sealed

class Derived : public sealed<Derived>
{
public:
    Derived() {}
};

Így egy kicsit egyértelműbb lesz a hibaüzenet (egyértelműbb a dolog ha már a hibaüzenet is valami Sealed-ről beszél), másrészt a sealed-et a VC++ 2008 kulcsszóként ismeri fel, és ennek megfelelően kékkel ki is emeli, így még egy kicsit feltűnőbb hogy nem hagyományos származtatásról van szó.

Ezt a hozzászólást TheProGamer módosította (2008.10.18 07:18 GMT+1 óra, ---)
Reality is almost always wrong. - House

   
TPG - Tag | 3402 hsz       Online status #97186   2008.10.18 06:54 GMT+1 óra  
Idézet
Asylum :
tpg:
.....


Nah közben asszem meg van mért hal szét a NULL pointer-es hibával a cucc ha a header-ben csinálok scope-ba hozatalt. Nekiálltam debug-olni a cuccot, a call stack alapján a dolog működik, csak az első konstruktor ami ilyen módszerrel hívódik műveletet szeretne végezni egy másik singleton-al. Csakhogy az a másik singleton-os osztálynak abban a pillanatban még nem futott le a konstruktora, majd csak egy későbbi menetben futna le. Így ugyan el tudja kérni az ő osztálypéldányát, sőt még az adott függvényt is meg tudja hívni ami el is kezd végrehajtódni, viszont az egész ott bekrepál amikor egy ofstream adattagot használni akar a függvény. Ennek az adattagnak a konstruktora az adott osztály konstruktorában futna le, de az adott osztály konstruktora még nem futott le. Tehát tömören összefoglalva a módszer jó, csak ki kell egészíteni valahogy úgy hogy szükség esetén GetInstanceReference-re is valahogy lefusson a konstruktor ha addig még ezt nem tette meg.

Szerk: Kicsit utánanéztem, kiderült hogy ennek a problémának már neve is van, "static initialization order fiasco" cím alatt létezik.

Ezt a hozzászólást TheProGamer módosította (2008.10.18 08:04 GMT+1 óra, ---)
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97185   2008.10.18 06:33 GMT+1 óra  
igen, ez is egy megoldás (private konstruktor), söt ezt is felhasználja, csak nem egészen igy. Ugyanis a konrét szülö osztálynak nem kell, hogy privát legyen a konstruktora (és akkor már lelövöm a poént mert nagyon jo )

Kód:
class Base
{
    friend class Derived;

private:
    Base() {}
};

class Derived : public virtual Base
{
public:
    Derived() {}
};

// error C2248: 'Base::Base' : cannot access private member declared in
// class 'Base'
class Apple : public Derived
{
public:
    Apple() {}
};


virtuális öröklésröl wikipedia-n is lehet találni leirást (konkrétan a diamond problem-re alkalmazza).

a lényeg, hogy az Apple nem a Derived konstruktorát akarja meghivni, hanem a Base-ét merthogy virtuálisan van örökölve belöle (elvileg a Derived konstruktora csak azután hivodna meg). Viszont a Derived-nek látnia kell a szülö konstruktorát ezért azt felvesszük barátnak a szülöbe.

igy a Derived egy final (sealed akármi) class.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Csizmás Kandur - Tag | 436 hsz       Online status #97183   2008.10.18 05:00 GMT+1 óra  
Idézet
TheProGamer :
Idézet
Csizmás Kandur :
Csak az a kérdés ez a sok minden ér e annyit, mint a boost sealed-je.


A boost-ban merre kellene keresnem a sealed-et? Idáig még nem futottam össze vele.


Ez mintha valami olyasmi lenne. Nem szoktam boostozni amúgy.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
TPG - Tag | 3402 hsz       Online status #97182   2008.10.18 04:50 GMT+1 óra  
Idézet
Csizmás Kandur :
Csak az a kérdés ez a sok minden ér e annyit, mint a boost sealed-je.


A boost-ban merre kellene keresnem a sealed-et? Idáig még nem futottam össze vele.
Reality is almost always wrong. - House

   
Csizmás Kandur - Tag | 436 hsz       Online status #97181   2008.10.18 04:45 GMT+1 óra  
Idézet
TheProGamer :
Idézet
Asylum :
egyébként ha már érdekességeknél tartunk: az oprednszerek gyakvezemtöl hallottam, hogy hogyan lehet C++ ban final class-t csinálni (amiböl nem lehet örökölni). Jöhetnek az 5letek, google nem ér,


Hát, ha belegondolok akkor egy normálisan összerakott Singleton-ból nem lehet származtatni mert a konstruktora private és a származtatott osztály nem fogja tudni a saját konstruktorában meghívni. Szóval valahogy úgy meg lehetne oldani hogy az adott osztály konstruktorát priváttá tesszük majd készítünk egy olyan statikus függvényt az osztályba ami új példányokat gyárt saját magáról és azok mutatójával tér vissza. Így elvileg származtatni sem tudunk viszont új példányokat készíteni meg igen. Ha nagyon perverzek vagyunk akkor még egy new operátort is készíthetünk az osztályhoz hogy kicsit kevésbé legyen feltűnő a dolog.


Csak az a kérdés ez a sok minden ér e annyit, mint a boost sealed-je.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
TPG - Tag | 3402 hsz       Online status #97180   2008.10.18 04:42 GMT+1 óra  
Idézet
Asylum :
egyébként ha már érdekességeknél tartunk: az oprednszerek gyakvezemtöl hallottam, hogy hogyan lehet C++ ban final class-t csinálni (amiböl nem lehet örökölni). Jöhetnek az 5letek, google nem ér,


Hát, ha belegondolok akkor egy normálisan összerakott Singleton-ból nem lehet származtatni mert a konstruktora private és a származtatott osztály nem fogja tudni a saját konstruktorában meghívni. Szóval valahogy úgy meg lehetne oldani hogy az adott osztály konstruktorát priváttá tesszük majd készítünk egy olyan statikus függvényt az osztályba ami új példányokat gyárt saját magáról és azok mutatójával tér vissza. Így elvileg származtatni sem tudunk viszont új példányokat készíteni meg igen. Ha nagyon perverzek vagyunk akkor még egy new operátort is készíthetünk az osztályhoz ami ezt a függvény hívogatja, így kicsit kevésbé lesz feltűnő a dolog.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97179   2008.10.18 04:21 GMT+1 óra  
hát, hogy a srác szavaival éljek ez egy "nagyon perverz" megoldás
boost nem kell hozzá.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Csizmás Kandur - Tag | 436 hsz       Online status #97178   2008.10.18 04:19 GMT+1 óra  
Idézet
Asylum :
akkor ott tanitasz?

szerk.: még a levegöben hagyom egy kicsit; egyébként kiprobáltam itthon és tényleg müködik, nagyon állat


Dolgozgatok. Majd egyszer akkor rakd fel a megoldást, bár ezt patkolás nélkül szerintem nem lehet megúszni úgyse, kivéve, ha alapból boost-olsz. C++0x-ben már lesz ilyen?
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
Asylum - Törzstag | 5440 hsz       Online status #97177   2008.10.18 04:13 GMT+1 óra  
akkor ott tanitasz?

szerk.: még a levegöben hagyom egy kicsit; egyébként kiprobáltam itthon és tényleg müködik, nagyon állat
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Csizmás Kandur - Tag | 436 hsz       Online status #97176   2008.10.18 04:06 GMT+1 óra  
Idézet
Asylum :
te sunyizol
te is abba a csoportba jársz?


Én már sehova nem járok.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
Asylum - Törzstag | 5440 hsz       Online status #97175   2008.10.18 03:55 GMT+1 óra  
te sunyizol
te is abba a csoportba jársz?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Csizmás Kandur - Tag | 436 hsz       Online status #97174   2008.10.18 03:53 GMT+1 óra  
Idézet
Asylum :
egyébként ha már érdekességeknél tartunk: az oprednszerek gyakvezemtöl hallottam, hogy hogyan lehet C++ ban final class-t csinálni (amiböl nem lehet örökölni). Jöhetnek az 5letek, google nem ér,


No, áruld el a titkot mit mondott a tanár, ami a public sealed class C++ megfelelője.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
Orphy - Törzstag | 1893 hsz       Online status #97171   2008.10.18 03:28 GMT+1 óra  
Sziasztok,

Nem tudjátok véletlenül, hogyan lehet normálisan megoldani C++ alatt a C# Exception-öknél már megszokott Stack Trace-et?

Nézegettem neten, de elég kifacsart dolgokat találtam, olyan érzésem volt, hogy senki sem tudja igazán, mit lehet kezdeni a problémával...
   
Asylum - Törzstag | 5440 hsz       Online status #97159   2008.10.17 14:23 GMT+1 óra  
szerk.: aha oké értem a problémádat, szóval eddig nem volt elötte Singleton<Alma>:: minösitö... hát ilyenkor jön a quick replace és a reguláris kifejezések (pl. egy makróval helyettesitheted mondjuk:

Kód:
#define _GETREF(x) Singleton<x>::GetInstanceReference()


az már problémásabb ha x egy objektum...nem tudom most hogy van.

Ezt a hozzászólást Asylum módosította (2008.10.17 16:27 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #97158   2008.10.17 14:14 GMT+1 óra  
Idézet
Asylum :
hát én még mindig nem értem...a példám alapján itt semmi gebasz (hadd nevezzem igy) nincsen. Hogyhogy elökerülne a cpp ben? Nem azért van a GetInstanceReference()?

irj egy példát pls mert téleg nem értem


De, pont a GetInstanceReference hívásával kerül elő. Csak tippem van hogy mi lehet a probléma (mert probléma az tuti van, ha nem hozok sehol scope-on belülre akkor egyesével dob unresolved external-okat minden fájlra ahol singleton tagfüggvényét hívom, ha pedig a header-ben csinálom meg akkor kivétellel hal szét). A GetInstanceReference egy csodás egysoros inline tagfüggvény, ennek rendje és módja szerint a fordító inline-olja is ahogy azt kell (tehát az összes GetInstanceReference hívást osztálypéldány.instance-ra cserél, a fordítás ezen szakaszában már mindegy hogy public/private/protected volt az adattag, a fordító ezt figyelmen kívül hagyja), ezután a linker meg vakarja a fejét hogy az adott cpp-ben az adott statikus adattag úgy van elérve hogy az nincs a scope-on belül. Hogy a problémát megoldja, dob egy unresolved external-t, és ezzel részéről el van intézve. Ha a header-ben teszem meg a scope-ba hozást, akkor széthal azzal hogy egy null pointer adattagját szeretné valahol elérni (erre mondjuk még nem találtam magamnak értelmes magyarázatot,a vicc az hogy nem is a saját kódomban döglik meg, hanem egy ofstream-be való írás kellős közepén), direkt ki is próbáltam most még egyszer. Azt hogy az előbbi sejtésem jó-e, azt most fogom tesztelni, csak a fordítás megint vagy 30 percig tart.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97154   2008.10.17 13:34 GMT+1 óra  
hát én még mindig nem értem...a példám alapján itt semmi gebasz (hadd nevezzem igy) nincsen. Hogyhogy elökerülne a cpp ben? Nem azért van a GetInstanceReference()?

irj egy példát pls mert téleg nem értem
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #97153   2008.10.17 13:23 GMT+1 óra  
Idézet
Asylum :
erre szokták mondani, hogy rossz tervezés
ezt a 70 átirást nem igazán értem.


A statikus adattag a header-ben van, de rendszeresen a cpp-kben kerülne elő. Az ilyen statikus adattagoknak ugye az a csúnya tulajdonsága hogy csak file scope-on belül látszanak, szóval ha valamelyik cpp-ben használni szeretném a singleton-jaimat akkor ott az adott adattagot a scope-on belülre kell hoznom. Mivel gyak. nincs olyan fájl ahol ne lennének a singleton-ok használva ezért elég súlyos a dolog. Azt hogy a header-ben teszem meg a scope-on belülre hozást már anno kínomban kipróbáltam (hátha sikerül alapon), de arra meg valami kivétellel széthalt az egész, szóval az sem működik (biztos ami biztos alapon éppen most próbálom újra, olyan 30 perc és végez a fordítással talán).

Lehet mondani hogy rossz tervezés, spec. én inkább arra mondanám hogy rossz tervezés ha a ~36k sor 1-2 tucat fájlban lenne található.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97152   2008.10.17 13:14 GMT+1 óra  
erre szokták mondani, hogy rossz tervezés
ezt a 70 átirást nem igazán értem.... templateket eleve headerbe szokás irni (máshogy le se fordul).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #97150   2008.10.17 13:12 GMT+1 óra  
Nah ez így már nagy valószínűséggel működne, csak ez a praktikusság szempontjából bukik meg. Ugyanis az osztálydeklarációk annak rendje és módja szerint header fájlokban vannak, a definíciók és a lényegi kód pedig cpp fájlokban. A lényeg hogy az hogy így minden egyes cpp fájlban a scope-ba kéne hoznom azt a statikus adattagot hogy ne kapjak unresolved external symbol-okat. Ez kis projektnél és kevés fájlnál nem is lenne gond, viszont nálam nem ez a helyzet, a projekt 153 fájlból áll, a header-ek és a cpp-k hasonló számban találhatók. Ez azt jelentené hogy cirka 70-75 fájlban kellene a scope-on belülre hoznom az adattagot amit még esetleg egy elvetemültebb napomon meg is csinálnék, viszont az egésznek a karbantartása elég csúnya lenne ezután.

Jelenleg egyetlen egy megoldást találtam, a következő makrót amivel viszont az a baj hogy pont azt nem küszöböli ki amit szeretnék: a saját feledékenységemet.
Kód:
#define ForceSingletonInit(x) namespace{struct ForceSingletonInitialization \
{ForceSingletonInitialization(){x::GetInstanceReference();}}instance;}


Ez így elvileg működne is, csak tuti elfelejteném a megfelelő osztályoknál alkalmazni, ugyanúgy mint ahogy elfelejtem a megfelelő osztályokat rendszeresen beregisztrálni a pluginrendszerbe (aminek a következményeként jönnek az igen ronda heisenbugok amiktől meg égnek áll a hajam). Ezért szeretném valahogy úgy megoldani hogy a származtatásoknál valahogy elintéződjön a dolog, mást ne kelljen csinálni. A származtatást egyrészt nem szoktam elfelejteni, másrészt ha mégis az hamar kiderül, ezzel szemben az ilyen kis extra kódok hozzáadását rendszeresen elfelejtem megtenni.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97149   2008.10.17 12:28 GMT+1 óra  
tpg:

Kód:
//****************************************************************************
#include <iostream>

template<typename T>
class Singleton
{
private:
    static T instance;

public:
    static T& GetInstanceReference() { return instance; }

    virtual ~Singleton(){}
    Singleton() {}
};

template<typename T>
T Singleton<T>::instance;
//****************************************************************************
class Apple
{
    friend class Singleton<Apple>;

private:
    Apple() {}

public:
    void Foo() { std::cout << "apple\n"; }
};
//****************************************************************************
int main()
{
    Singleton<Apple> apple;

    apple.GetInstanceReference().Foo();

    system("pause");
    return 0;
}
//****************************************************************************


egyébként ha már érdekességeknél tartunk: az oprednszerek gyakvezemtöl hallottam, hogy hogyan lehet C++ ban final class-t csinálni (amiböl nem lehet örökölni). Jöhetnek az 5letek, google nem ér,
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #97148   2008.10.17 10:44 GMT+1 óra  
Azt nem tudjátok véletlenül, hogyan lehet normálisan megoldani C++ alatt a C# Exception-öknél már megszokott Stack Trace-et?

Nézegettem neten, de elég kifacsart dolgokat találtam, olyan érzésem volt, hogy senki sem tudja igazán, mit lehet kezdeni a problémával...
   
TPG - Tag | 3402 hsz       Online status #97147   2008.10.17 10:09 GMT+1 óra  
Idézet
Asylum :
ehhez mit souls?

Kód:
{
public:
static T instance;

static T& GetInstanceReference() {return instance;}
virtual ~Singleton(){}
Singleton(){}
};



Ha ilyen egyszerű lett volna a megoldás, nem kérdeztem volna. Egy halom "unresolved external symbol"-t dob rá a linker, ami így utólag belegondolva teljesen logikus reakciónak tűnik.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5440 hsz       Online status #97117   2008.10.16 11:36 GMT+1 óra  
Kód:
polinom operator+(polinom& a, polinom& b);
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Kristf - Törzstag | 123 hsz       Online status #97115   2008.10.16 09:50 GMT+1 óra  
A << és >> -re csináltam friendet azokkal nincs is baj, a beolvasás és kiírás működik rendesen. Az operator+ művelet a polinom osztály friend-je, most amúgy nincs is más osztály a programban. De kipróbáltam úgy is, hogy:
Kód:
polinom operator+(polinom &_p);


És így is hasonló hibaüzenetet kapok a c=a+b -re:
no match for 'operator=' in 'c = polinom::operator+(polinom&)(((polinom&)(&b)))

   
Asylum - Törzstag | 5440 hsz       Online status #97097   2008.10.15 16:12 GMT+1 óra  
az operator+ miért friend? kinek a friendje?
friend nélkül müködnie kell.

viszont nem látok friend << és friend >> t
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Kristf - Törzstag | 123 hsz       Online status #97093   2008.10.15 14:30 GMT+1 óra  
Van egy osztályom amiben két tagfüggvény a következő:

Kód:
polinom& operator=(polinom &_p);
friend polinom operator+(polinom &_p1, polinom &_p2);


A definíciójuk most nem lényeges. És van egy másik osztály, amiben ezzel a kóddal használom őket:

Kód:
...
polinom a, b, c;

    cout<<endl<<"Az elso polinom: "<<endl<<endl;
    cin>>a;

    cout<<endl<<"A masodik polinom: "<<endl<<endl;
    cin>>b;

    c = a+ b;
    cout<<c;
...


És az a problémám, hogy a c= a+b sorra hibaüzenetet kapok érthetetlen módon:

no match for 'operator=' in 'c = operator+(polinom&, polinom&)(((polinom&)(&b)))

Ha csak annyit írok hogy c= a, akkor teljesen jól működik, vagy ha csak annyit, hogy a+b, az is jó. Valakinek van valami ötlete esetleg?

   
Seeting - Törzstag | 2306 hsz       Online status #96989   2008.10.13 09:11 GMT+1 óra  
Problem solved
   
Seeting - Törzstag | 2306 hsz       Online status #96987   2008.10.13 08:38 GMT+1 óra  
Olyankor mi a teendő, ha a CodeBlock nem fordít emiatt:

"project - Debug" uses an invalid compiler. Skipping...
   
Asylum - Törzstag | 5440 hsz       Online status #96902   2008.10.10 13:54 GMT+1 óra  
ehhez mit souls?

Kód:
{
public:
static T instance;

static T& GetInstanceReference() {return instance;}
virtual ~Singleton(){}
Singleton(){}
};
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #96897   2008.10.10 12:05 GMT+1 óra  
Adott az alábbi két osztály:
Kód:
class CPlugin
{
public:
CPlugin(){}
virtual ~CPlugin(){}
virtual void Cleanup(){}
virtual void FinalCleanup(){}
virtual void Initialize(){}
virtual void OneTimeInitialize(){}
virtual void Reset(){}
virtual void Invalidate(){}
};

template<typename T> class Singleton : public noncopyable
{
public:
static T& GetInstanceReference() {static T instance; return instance;}
virtual ~Singleton(){}
Singleton(){}
};


Előbbi egy pluginrendszerbe regisztrálható osztályok ősosztálya, utóbbi pedig segédosztály egy adott osztály singleton-ná alakításához. Utóbbinál látszik hogy az adott osztálypéldány az első használatkor fog automatikusan létrejönni (ugyebár ilyenkor hívjuk először a GetInstanceReference-t amiben ekkor fog létrejönni az instance nevű változó). A pluginok jelenleg kézzel kerülnek regisztrálásra a pluginrendszerben, ezt kellene átalakítani úgy hogy ha egy osztályt származtatok a CPlugin-ból akkor a regisztrálás automatikusan megtörténjen. Ez még így nem is lenne vészes, CPlugin-t át lehetne alakítani CRTP (curiously recurring template pattern) szerint, majd a beküldött template paraméteren keresztül el lehetne kérni egy GetInstanceReference hívással a CPlugin konstruktorában az adott osztálypéldányt (egyenlőre nyugodtan feltételezhető hogy plugin csak singleton osztály lehet) és beregisztrálni a rendszerbe. A CPlugin konstruktora ugyebár meghívódik mikor a belőle származtatott osztály konstruktora meghívódik. És itt jön a probléma: a származtatott plugin osztály konstruktora csak akkor hívódik meg ha hívunk egy GetInstanceReference-t, amit viszont egyrészt nem tudunk garantálni hogy hívódni fog (előfordulhat hogy a plugin osztály csak a CPlugin-ból származó függvényeket tartalmaz, amiket meg a pluginrendszer hívogatna, feltéve ha az osztályt beregisztrálnánk, ami ebben az esetben nem történne meg), másrészt azt sem tudjuk garantálni hogy ha esetleg meghívódik akkor azt jókor fogja tenni (lehet hogy csak azután hívódik meg hogy a pluginrendszernek kellett volna hívnia rá egy OneTimeInitialize-t meg egy Initialize-t). Azt kellene elérni hogy ez a két dolog minden esetben garantálva legyen ha egy osztályt a CPlugin-ból származtatunk, méghozzá úgy hogy hogy a származtatáson felül extrán kódot ne kelljen hozzáadni abban az esetben ha egy osztályt CPlugin-ból származtatunk. Várom az ötleteket, az enyémek már elfogytak.
Reality is almost always wrong. - House

   
hamvaszto - Tag | 12 hsz       Online status #96580   2008.10.02 08:12 GMT+1 óra  
naggyon széépen köszönöm mind a kettőtöknek!
működnek, és már értem!

   
Joga - Törzstag | 1791 hsz       Online status #96540   2008.10.01 12:54 GMT+1 óra  
Pedig egyszerű
balról kezdve megvizsgálja a biteket, hogy 1, vagy 0 és kiírja.
(ಠ ›ಠ) Stewie!

   
Wolfee - Törzstag | 1336 hsz       Online status #96539   2008.10.01 12:46 GMT+1 óra  
5 perce nézem azt a bitshiftelős sort, de nem értem...
FZoli jóváhagyásával XD

   
Asylum - Törzstag | 5440 hsz       Online status #96536   2008.10.01 12:23 GMT+1 óra  
most jöjjön a kocka megoldás

Kód:
#include <stdio.h>
#include <stdlib.h>

int main()
{
    int szam, i = 31;

    printf("Kerek egy szamot: ");
    scanf("%d", &szam);

    printf("Binaris alak: ");

    for( ; i >= 0; i-- )
        printf("%c", ((1 << i) & szam) ? '1' : '0');

    printf("\n");

    system("pause");
    return 0;
}
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #96528   2008.10.01 09:14 GMT+1 óra  
Kód:
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
int szam, i=0, tomb[ 32 ];
int k;    //Ciklusokhoz

for( k = 0; k < 32; k++ )tomb[ k ] = 0;   // Tömb nullázása

printf ("\nKérek egy számot: \n");
scanf ("%d", &szam);
for( k = 31; szam!= 0 ;k-- ) {
  tomb[ k ] = szam % 2 ;
  szam /= 2;
}
//   Szám kiírása
printf(" 2es számrendszerbeli szám: ");
for( k = 0; tomb[ k ] == 0 ;k++ );  //Az első valahány számjegy mindig nulla, ezeket átugorjuk
for( ; k < 32; k++ )printf( "%d", tomb[k] );
system("PAUSE");
return 0;
}


a tömbben szépen ott lesznek a számjegyek, a végén ki is írom ezt az értéket
(ಠ ›ಠ) Stewie!

   
hamvaszto - Tag | 12 hsz       Online status #96526   2008.10.01 08:38 GMT+1 óra  
huhh, hát ezt jól megmagyaráztad egy c mazsolának, bocs, de ha esetleg leírnád a forrkódot plsss, abból tudnám értelmezni

   
Joga - Törzstag | 1791 hsz       Online status #96508   2008.09.30 09:50 GMT+1 óra  
Az x az jelkép, és próbálj meg ne 8szor üzenni egymás után, hanem egybe leírni a dolgokat

a while ciklust cseréld ki egy visszafele számláló for-ral, és akkor a számláló legyen az index
(ಠ ›ಠ) Stewie!

   
hamvaszto - Tag | 12 hsz       Online status #96507   2008.09.30 09:05 GMT+1 óra  

   
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] [141]