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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2189
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 #142882   2010.10.30 18:55 GMT+1 óra  
Idézet
gaborlabor :
Idézet
lezli01 :
Hali, c-ben nincs olyan h tombméret egy előredefiniált értékkel legyen egyenlő.



Hát már hogy a viharba ne lenne?!


Ezt nem értem én sem, a fordító így is, úgy is "char tomb[100];"-t fog látni, mert a preprocesszor addigra a define-os verzióból is ezt állítja elő.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5455 hsz       Online status #142881   2010.10.30 18:52 GMT+1 óra  
Nekem vs2008 al még mindig simán megy...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #142880   2010.10.30 18:52 GMT+1 óra  
Idézet
lezli01 :
Hali, c-ben nincs olyan h tombméret egy előredefiniált értékkel legyen egyenlő.



Hát már hogy a viharba ne lenne?!

   
lezli01 - Tag | 190 hsz       Online status #142877   2010.10.30 18:38 GMT+1 óra  
Hali, c-ben nincs olyan h tombméret egy előredefiniált értékkel legyen egyenlő.

Be kell írnod, hogy char tomb[ 100 ]...

Ha eddig pl eclipsben működött, az azért van, mert eclipse rájön erre és a c++ fordítóval fordítja...

Idézet
gberes :
Hallo!

Erre a kódra:
Kód:
...
#define SW 100
...
int main(){
   char tomb[SW];
...


miért kapok
error C2143: syntax error : missing ']' before ';'
hibaüzenetet?

(VC++ 2010, c nyelv)

   
Asylum - Törzstag | 5455 hsz       Online status #142694   2010.10.27 17:39 GMT+1 óra  
A bemásolt kódban nincs hiba; vagy rosszul másoltad be... például hasonlo hiba keletkezhet ha:

Kód:
#define SW 100;


Biztos, hogy erre a sorra mondja a hibát?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bit.0x8000 - Törzstag | 574 hsz       Online status #142602   2010.10.26 01:15 GMT+1 óra  
Én első körben megnézném egy hex editorral, hogy nincsenek-e benne "vicces" karakterek.
   
gberes - Tag | 38 hsz       Online status #142601   2010.10.26 01:11 GMT+1 óra  
Hallo!

Erre a kódra:
Kód:
...
#define SW 100
...
int main(){
   char tomb[SW];
...


miért kapok
error C2143: syntax error : missing ']' before ';'
hibaüzenetet?

(VC++ 2010, c nyelv)

   
Pretender - Törzstag | 2498 hsz       Online status #142508   2010.10.22 20:33 GMT+1 óra  
Ez nem segitett rajta Bar amugy tenyleg, MANAGED fog kelleni, vagy a default melle dynamic. Viszont az tovabbra is fura, hogy teljesen szetkurodik az egesz. De mind1, nem is foglalkozok vele.

szerk.:
Ezen kivul a managed dolgon kivul meg sem merem mondani, h mi volt a gond

Ezt a hozzászólást Pretender módosította (2010.10.22 21:47 GMT+1 óra, ---)

   
Asylum - Törzstag | 5455 hsz       Online status #142506   2010.10.22 19:50 GMT+1 óra  
Nos, a dx dokumentáciot kéne olvasni.
D3DPOOL_DEFAULT-ban lévö dolgokat nem lehet lockolni (kivéve ha D3DUSAGE_DYNAMIC al hoztad létre).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #142504   2010.10.22 19:29 GMT+1 óra  
Ah, ezzel most nem erdemes foglalkozni, itt nagyon nagy gondok vannak... shift+del

   
Joga - Törzstag | 1791 hsz       Online status #142501   2010.10.22 19:22 GMT+1 óra  
const static int SizeInBytes = 56;
nem tudom, én azért azt mondanám, hogy az legyen sizeof( SzépHosszúNevűOsztály )

Ezenkívül semmi más tippem nincs
(ಠ ›ಠ) Stewie!

   
Pretender - Törzstag | 2498 hsz       Online status #142500   2010.10.22 19:07 GMT+1 óra  
Hu, ez erdekes. Csak release modban csinalja ezt!
van egy ilyenem ni:
Kód:
void Mesh::CreateVertices(const std::vector<VertexPositionNormalTextureTangentBinormal>& p_Vertices)
{
    m_SizeInBytes = VertexPositionNormalTextureTangentBinormal::SizeInBytes;
    m_VertexCount = p_Vertices.size();

    //create vertex buffer
    int size = m_VertexCount * m_SizeInBytes;

    m_Device->CreateVertexBuffer(size, D3DUSAGE_WRITEONLY, NULL, D3DPOOL_DEFAULT, &m_VertexBuffer, NULL);

    //fill vertex buffer
    VOID* pVertices;
    m_VertexBuffer->Lock(0, 0, &pVertices, NULL);
    memcpy(pVertices, &p_Vertices[0], size);
    m_VertexBuffer->Unlock();

    //create vertex declaration
    m_Device->CreateVertexDeclaration(VertexPositionNormalTextureTangentBinormal::VertexElements,
&m_VertexDeclaration);
}

~2700 elemszamu vectort adok at neki parameterkent. Itt az tortenik, hogy a Lock utan a p_Vertices egyszeruen torlodik, a memcpy utan pedig egy nagy-nagy elemszamu vector lesz belole, aminek termeszetesen az elemeivel minden baj van. Debug modban mukodik. Otletek?

szerk.:
Ahogy nezem kb. minden elkefelodik. az m_SizeInBytes es az m_VertexCount is. Minden

szerk.2:
A gondok ugy latom mar ott kezdodnek, hogy a legelso sorban az m_SizeInBytes -1163005939-es erteket kap... Az pedig meg a headerben:
Kód:
const static int SizeInBytes = 56;

Bar egy ilyen utan is
Kód:
m_SizeInBytes = 56;

ugyan ugy -1163005939 lesz az erteke...

   
Asylum - Törzstag | 5455 hsz       Online status #142291   2010.10.16 01:03 GMT+1 óra  
Tanulság: osztálydeklarációban csak integral típusokat lehet incializálni (tehát floatot és double-t sem).

Ezt a hozzászólást Asylum módosította (2010.10.16 01:15 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #142273   2010.10.15 20:47 GMT+1 óra  
Jaja, közben már rájöttem Asylum segítségével, de azért kösz
(ಠ ›ಠ) Stewie!

   
TPG - Tag | 3402 hsz       Online status #142271   2010.10.15 20:16 GMT+1 óra  
Idézet
Joga :
Naná, hogy nem tetszik a fordítónak, ti mit gondoltok az ilyesmiről, valahogy máshogy kéne megoldani?


Kód:
class vector{

public:
static const vector null_vector;
...
private:
...

}
const vector vector::null_vector = vector(0,0,0);

Esetleg így?
Reality is almost always wrong. - House

   
Joga - Törzstag | 1791 hsz       Online status #142267   2010.10.15 19:55 GMT+1 óra  
Kód:
class vector{

public:
static const vector null_vector( 0, 0, 0 );
...
private:
...

}

Naná, hogy nem tetszik a fordítónak, ti mit gondoltok az ilyesmiről, valahogy máshogy kéne megoldani?
(ಠ ›ಠ) Stewie!

   
Asylum - Törzstag | 5455 hsz       Online status #142258   2010.10.15 16:42 GMT+1 óra  
Hát aki egy widescreen monitoron 1024x768 ba dolgozik az meg is érdemli...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #142241   2010.10.15 07:11 GMT+1 óra  
Ha jól értem, akkor én is valami hasonlóképpen oldottam meg: lekérdezem az asztal felbontását, és aszerint állítom be a képarányt. Ha widescreen monitoron 1024x768 -at használ, akkor a játékban is 4:3-as képarány lesz az alap, mert bizonyára így szereti... (Aztán az options menüben vagy a .cfg -ben átállíthatja ha akarja.)

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
bit.0x8000 - Törzstag | 574 hsz       Online status #142238   2010.10.14 23:14 GMT+1 óra  
Egyébként most az alábbi megoldást használom (egyszerűsítettem persze):
Kód:
const SDL_VideoInfo *videoInfo;
int offset;

//...

SDL_SetVideoMode(0, 0, 0, SDL_OPENGL | SDL_FULLSCREEN);
videoInfo = SDL_GetVideoInfo();
if (static_cast<float>(videoInfo->current_w) /
  videoInfo->current_h > 1.5F)
{ offset = videoInfo->current_w - videoInfo->current_h * 1.5F;
  glViewport(offset / 2, 0,
    videoInfo->current_w - offset, videoInfo->current_h);
}
else
{ offset = videoInfo->current_h - videoInfo->current_w * 2.0F / 3.0F;
  glViewport(0, offset / 2,
    videoInfo->current_w, videoInfo->current_h - offset);
}
glOrtho(0.0, videoInfo->current_w,
  videoInfo->current_h, 0.0, 0.0, 1.0);

//...
   
bit.0x8000 - Törzstag | 574 hsz       Online status #142237   2010.10.14 22:45 GMT+1 óra  
Idézet
Asylum :
Erre gondolsz? (desktop felbontás; 0 és 1)

http://msdn.microsoft.com/en-us/library/ms724385%28VS.85%29.aspx


És ha egy widescreen monitoron mondjuk 1024x768 van beállítva?

(Ha valahogy le lehetne kérni a natív felbontást, az talán jó mérvadó lenne, de az értelmezhető CRT-k esetén is?)
   
Asylum - Törzstag | 5455 hsz       Online status #142236   2010.10.14 22:37 GMT+1 óra  
Erre gondolsz? (desktop felbontás; 0 és 1)

http://msdn.microsoft.com/en-us/library/ms724385%28VS.85%29.aspx
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bit.0x8000 - Törzstag | 574 hsz       Online status #142231   2010.10.14 22:00 GMT+1 óra  
Tudja valaki, hogy egy c++/sdl/opengl programban hogyan lehetne lekérni a kijelző (fizikai) képarányát, lehetőleg multiplatform módon?

szerk:
Vagy másképp megközelítve a kérdést: mi a legjobb/általános módja a "képarány korrekció" funkció megvalósításának?

Ezt a hozzászólást bit.0x8000 módosította (2010.10.14 22:29 GMT+1 óra, ---)
   
Pretender - Törzstag | 2498 hsz       Online status #142228   2010.10.14 19:14 GMT+1 óra  
A8R8G8B8 rendertargetek. Ablakos modban mukodik minden, fullscreenen ket lehetoseg: ha a desktop felbontast hasznalom (1440 x 900), akkor villog, mint a hulye, kisebb felbontason meg nem latszik semmi. Megneztem, hogy mindez akkor fordul elo, ha MRT-t hasznalok (azaz hasznalom az 1-es 2-es render targetet is). Otletek, hogy miert van? Az zavar, hogy csak fullscreenben nem jo (es x8r8g8b8-al mintha eddig jo lett volna)

szerk.:
Amikor megnyomom az alt-tabot, akkor egy pillanatra felvillan a helyes kep, de amikor visszanyomom az ablakba, akkor ujra az elozo tuneteket produkalja.

szerk.2:
Kód:
m_Device->SetRenderTarget(1, NULL);
m_Device->SetRenderTarget(2, NULL);

Ezt felejtettem el, erdekes, ablakos modban nem koveteli.

Ezt a hozzászólást Pretender módosította (2010.10.14 19:21 GMT+1 óra, ---)

   
Asylum - Törzstag | 5455 hsz       Online status #142193   2010.10.13 19:11 GMT+1 óra  
Nem tudod mit fog csinálni...lehet hogy kinullázza a pointert, de lehet hogy nem és amikor legközelebb push_back()-et nyomsz beleir a semmibe...ezmiatt volt egy olyan bug az elözö engineversenyes progimban, hogy konkrétan eltüntek bizonyos mesh darabok, vagy marhaságokat rajzolt.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #142191   2010.10.13 18:07 GMT+1 óra  
Idézet
Asylum :
A vektor destruktorát explicit meghivni nagyon nem ajánlott (egyáltalán bármilyen destruktort). Volt hogy csináltam és hihetetlen szopás lett a vége.


Az érdekes, erről még nem hallottam. Pedig vannak olyan helyzetek, amikor sok választásod nincs, mint kézzel destruktort hívni, pl saját allokátorban std konténerekhez.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5455 hsz       Online status #142190   2010.10.13 17:38 GMT+1 óra  
A vektor destruktorát explicit meghivni nagyon nem ajánlott (egyáltalán bármilyen destruktort). Volt hogy csináltam és hihetetlen szopás lett a vége.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bit.0x8000 - Törzstag | 574 hsz       Online status #142179   2010.10.13 00:01 GMT+1 óra  
Idézet
TheProGamer :
Idézet
bit.0x8000 :
Ha jól sejtem, ez azt használja ki, hogy a "*(tomb + 2)" egyenértékű ezzel: "*(2 + tömb)".


A józan paraszti ész ezt sejteti, amiben én nem vagyok biztos az az, hogy a szabvány megköveteli-e hogy az indexelés valóban a fenti kifejezéssé alakuljon át, vagy elég ha valami lényegileg hasonlót csinál.


Amennyire én tudom, a C++-beli tömbök elég egyszerű lelkületű dolgok, tehát sok variáció nem lehet az implementációra.
Ami nekem inkább szöget ütött a fejembe, hogy a fordító(k) hogyan viszonyul(nak) ehhez a kifejezéshez?
   
TPG - Tag | 3402 hsz       Online status #142176   2010.10.12 22:17 GMT+1 óra  
Idézet
bit.0x8000 :
Ha jól sejtem, ez azt használja ki, hogy a "*(tomb + 2)" egyenértékű ezzel: "*(2 + tömb)".


A józan paraszti ész ezt sejteti, amiben én nem vagyok biztos az az, hogy a szabvány megköveteli-e hogy az indexelés valóban a fenti kifejezéssé alakuljon át, vagy elég ha valami lényegileg hasonlót csinál.
Reality is almost always wrong. - House

   
bit.0x8000 - Törzstag | 574 hsz       Online status #142173   2010.10.12 21:36 GMT+1 óra  
Idézet
TheProGamer :
Idézet
Asylum :
Tömbök: és nem csak t[2] müködik hanem..

Kód:
int tomb[3] = { 4, 1, 7 };

std::cout << 2[tomb] << "\n";





Nah ez csak kb annyira félreérthető amennyire lehet. Bár lehet velem van a baj, de én azonnal valami asszociatív tömb indexelésére asszociáltam.


Ha jól sejtem, ez azt használja ki, hogy a "*(tomb + 2)" egyenértékű ezzel: "*(2 + tömb)".
   
TPG - Tag | 3402 hsz       Online status #142172   2010.10.12 21:28 GMT+1 óra  
Idézet
Asylum :
vectorhoz: a clear() meghivja az elemek destruktorát és a size-ot 0-ra állitja, viszont a vektor által lefoglalt memóriát nem szabaditja fel! Tehát ha biztosra akarsz menni akkor

Kód:
vektorod = std::vector();



Pont ez a lényege, majd ha a vector destruktora is lefut, akkor az a hely is felszabadul, addig meg frankón cache-eli a már lefoglalt területeket, arra az esetre ha használnád. Ha még a fentit is megcsinálod, akkor lefut egy vector konstruktor és létrejön egy temporális objektum, a "vektorod" belső cuccai felszabadulnak, ezután lemásolja a temporálist, majd a kiértékelés végén a temporális is felszabadul. Szal ez minden csak nem hatékony. (Ráadásul a konstruktor már valamennyi helyet foglal le a jövőbeli elemeknek.) A C++0x a move semantics-al ezen javítana valamennyit, de még mindig nem hatékonyabb úgy se, mintha csak hagyod egyszerűen scope-on kívül menni a clear-elt vectort, vagy esetleg kézzel meghívod rajta a destruktort.
Szerk: kicsit belenéztem a vector header-jébe, annyit tévedtem hogy a konstruktor nem foglal helyet a következő elemeknek alapból.
Idézet
Asylum :
Tömbök: és nem csak t[2] müködik hanem..

Kód:
int tomb[3] = { 4, 1, 7 };

std::cout << 2[tomb] << "\n";





Nah ez csak kb annyira félreérthető amennyire lehet. Bár lehet velem van a baj, de én azonnal valami asszociatív tömb indexelésére asszociáltam.

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

   
Asylum - Törzstag | 5455 hsz       Online status #142168   2010.10.12 21:11 GMT+1 óra  
vectorhoz: a clear() meghivja az elemek destruktorát és a size-ot 0-ra állitja, viszont a vektor által lefoglalt memóriát nem szabaditja fel! Tehát ha biztosra akarsz menni akkor

Kód:
vektorod = std::vector();


Tömbök: és nem csak t[2] müködik hanem..

Kód:
int tomb[3] = { 4, 1, 7 };

std::cout << 2[tomb] << "\n";


C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #142152   2010.10.12 18:40 GMT+1 óra  
Idézet
mark576 :
Idézet
TheProGamer :
Így belegondolva, template specializációval akár azt is el lehetne érni, hogy egy ilyen vektor minden esetben azt csinálja amire számítunk, tehát pointereknél a mutatott objektumot törölje.


Az elég veszélyes lenne, főleg, ha sok helyen tárolod. Nincs hozzá futtatórendszer, ami eldöntené, hogy az objektumot fogja e még valaki.


Veszélyesnek veszélyes lehet, de ezt általában el szokás intézni annyival, hogy a doksiba beírják, hogy az adott cucc átveszi a tulajdonjogot a neki adott pointer által mutatott cucc felett. Aztán ha a hülye programozó erre nem figyel, akkor úgy kell neki. wxWidgets-ben is van egy adag példa erre, bár ott emlékeim szerint azért nagyrészt ki/bekapcsolható ez a fajta viselkedés.

Idézet
kompabt :
Asylum
Dimenzionalt tombnel forditasi idoben ismertnek kell lennie a meretnek


De miert? a fuggvenynek nem csak a tombre mutato pointer adodik at? Memoriafoglalas nem tortenik, az oszlopok szamat csak az indexeles miatt kell megadni nem?
Kód:
tipus fnev(int s, int o, tipus nev[][o]);

amugy koszi.


Mutató adódik csak át, de te a függvény fejlécében nem mutatót, hanem tömböt adtál meg, annak meg ismertnek kell a méretének lennie.
Kieg: És ha tömböt adsz meg akkor márpedig a stack-en történni fog memóriafoglalás. Az oszlopszám megadást meg nem is értem, egy sima pointert is lehet indexelni, az hogy a[x] gyakorlatilag egyenlő azzal hogy *(a+x) .
Reality is almost always wrong. - House

   
kompabt - Tag | 27 hsz       Online status #142146   2010.10.12 16:49 GMT+1 óra  
Asylum
Dimenzionalt tombnel forditasi idoben ismertnek kell lennie a meretnek


De miert? a fuggvenynek nem csak a tombre mutato pointer adodik at? Memoriafoglalas nem tortenik, az oszlopok szamat csak az indexeles miatt kell megadni nem?
Kód:
tipus fnev(int s, int o, tipus nev[][o]);

amugy koszi.

   
mark576 - Tag | 256 hsz       Online status #142144   2010.10.12 15:38 GMT+1 óra  
Idézet
TheProGamer :
Így belegondolva, template specializációval akár azt is el lehetne érni, hogy egy ilyen vektor minden esetben azt csinálja amire számítunk, tehát pointereknél a mutatott objektumot törölje.


Az elég veszélyes lenne, főleg, ha sok helyen tárolod. Nincs hozzá futtatórendszer, ami eldöntené, hogy az objektumot fogja e még valaki.
   
TPG - Tag | 3402 hsz       Online status #142141   2010.10.12 15:01 GMT+1 óra  
Idézet
glezmen :
igen, ha magat az objektumot tarolod a containerben, sima object pointernel NEM!
pont par hete vetettem fel a temat, amit ki is veseztunk


Végül is ő mindig meghívja a tárolt objektum destruktorát, csak ha pointereket tárolsz benne, akkor azoknak a destruktorát hívja, nem az általuk mutatott objektumét.

Szerk:
Így belegondolva, template specializációval akár azt is el lehetne érni, hogy egy ilyen vektor minden esetben azt csinálja amire számítunk, tehát pointereknél a mutatott objektumot törölje.
Reality is almost always wrong. - House

   
proof88 - Törzstag | 530 hsz       Online status #142140   2010.10.12 14:57 GMT+1 óra  
glezmen - Törzstag | 381 hsz       Online status #142139   2010.10.12 14:54 GMT+1 óra  
Idézet
proof88 :
clear meghívja a destuktorokat egyébként ...



igen, ha magat az objektumot tarolod a containerben, sima object pointernel NEM!
pont par hete vetettem fel a temat, amit ki is veseztunk
   
proof88 - Törzstag | 530 hsz       Online status #142136   2010.10.12 14:17 GMT+1 óra  
clear meghívja a destuktorokat egyébként ...
   
Pretender - Törzstag | 2498 hsz       Online status #142134   2010.10.12 13:57 GMT+1 óra  
A felszabaditasrol jut eszembe...
Kód:
std::vector<int> valami;
for (int i = 0; i != 10; i++)
    valami.push_back(i);

valami.clear();

vector es list eseten elegendo-e a clear? (nyilvan ha nem csak int, hanem valami "osztaly", akkor azoknak is meghivni a destruktort, stb.)

szerk.:
Megvalami: ha en dll-t hasznalok, akkor nem lehet valahogy beleforditani a headereket, vagy valami ehhez hasonlo? Az lenne a cel, hogy ne kelljen az "olvashato" headereket mellekelni. Vagy kell?

Ezt a hozzászólást Pretender módosította (2010.10.12 14:15 GMT+1 óra, ---)

   
Asylum - Törzstag | 5455 hsz       Online status #142123   2010.10.12 08:26 GMT+1 óra  
Dimenzionált tömbnél fordítási időben ismertnek kell lennie a méretnek, tehát ha "o" alatt változót értesz, akkor nem lehet. Lehetséges megoldás a dinamikusan allokált tömb, vagyis a függvény egy pointert várjon:

Kód:
tipus fnev(tipus **nev, int s, int o);

// valahol a programban:
int o = 5;
int s = 3;

tipus** tombom = new tipus*[o];

for( int i = 0; i < o; ++i )
    tombom[i] = new tipus[s];

// feltöltés

fnev(tombom, s, o);

...

// felszabadítás:
for( int i = 0; i < o; ++i )
    delete[] tombom[i];

delete[] tombom;


A felszabadítást ne felejtsd el.

A másik esetet mark576 is mondta, tehát ha fordítási időben ismert a méret, akkor

Kód:
template <int s, int o>
tipus fnev(tipus nev[o][s]);


Ekkor viszont a definíciót is a headerbe kell kifejteni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
mark576 - Tag | 256 hsz       Online status #142119   2010.10.12 01:56 GMT+1 óra  
Idézet
kompabt :
nem-e lehetne valahogy parameteresen hagyni azaz, valahogy igy:
Kód:
tipus fnev(tipus nev[][o], int s, int o);

???

(namost erre ugye azt irja ki, hogy o undeclared identifier.)



Template paraméterezéssel?
Kód:
template <typename T, int size> T fnev(T nev[][size])
   
kompabt - Tag | 27 hsz       Online status #142118   2010.10.12 00:53 GMT+1 óra  
Sziasztok!
Ketdimenzios tomb fuggveny parametert akarok deklaralni:

Kód:
tipus fnev(tipus nev[][oszlopok_szama], int sorok_szama, int oszlopok_szama);


vagyis a szogletes zarojelek kozott meg kell adni a meretinformaciot, de csak az oszlopok szamat, hogy az indexeles operatora mukodjon.


kerdesem: a szogletes zarojelek koze muszaly egy konkret szamot megadni, tehat muszaly igy?
:
Kód:
tipus fnev(tipus nev[][10], int sorok_szama, int oszlopok_szama);


nem-e lehetne valahogy parameteresen hagyni azaz, valahogy igy:
Kód:
tipus fnev(tipus nev[][o], int s, int o);

???

(namost erre ugye azt irja ki, hogy o undeclared identifier.)

   
Pretender - Törzstag | 2498 hsz       Online status #142067   2010.10.10 18:19 GMT+1 óra  
Valoban, felreertettem. koszi vegulis logikusnak tunik

   
dvorgaz - Törzstag | 575 hsz       Online status #142066   2010.10.10 18:06 GMT+1 óra  
Az FLT_MIN az a legkisebb pozitív érték, ami neked kell, az a -FLT_MAX.
   
Pretender - Törzstag | 2498 hsz       Online status #142065   2010.10.10 17:25 GMT+1 óra  
Ha azt mondom, hogy:
Kód:
inline static Vector3 Min() throw()
{
    Vector3 result = Vector3(0);
    result.X = FLT_MIN;
    result.Y = FLT_MIN;
    result.Z = FLT_MIN;
    return result;
}

az ugye felveszi a legkisebb erteket (igen, float)
Bezzeg, amikor szamolom a boundingbox-nal:
Kód:
m_Max = Vector3::Min();

if (p_Vertices[i].X > m_Max.X)
    m_Max.X = p_Vertices[i].X;
if (p_Vertices[i].Y > m_Max.Y)
    m_Max.Y = p_Vertices[i].Y;
if (p_Vertices[i].Z > m_Max.Z)
    m_Max.Z = p_Vertices[i].Z;

Akkor mindegyikre jo, csak az y-ra nem teljesul soha. Miert nem? (a p_Vertices egy std::vector<>, es az elemeknek 0 az y ertekuk, ami ha jol tudom nagyobb, mint a legkisebb float)

Ha mondjuk megadok egy nagyon kicsi erteket, pl.:
result.Y = -10000000000000.0f;
Akkor mukodik. Esetleg nem jo igy ez az FLT_MIN? De akkor a tobbivel miert jo?

   
Asylum - Törzstag | 5455 hsz       Online status #142049   2010.10.09 21:10 GMT+1 óra  
Idézet
dvorgaz :
C++ban nem lehet olyat csinálni, mint C#-ban a template típus megszorítása, hogy az valamilyen ősosztályból származzon?
Kód:
class LinkedList<K,T> where K : IComparable




Megmondani nem lehet, de ha a template paraméternek nincs pl. < operátora akkor fordítási hibát ad, tehát funkcionalitásban ugyanaz.
Viszont ha az adott metódust soha nem hivod meg, akkor soha nem is fog kiderülni a hiba, tehát "rossz" tipussal is mküdhet az adott sablon bizonyos része.

C++0x-ben lettek volna a conceptek (van néhány müködö implementácio), amivel meg lehetett volna adni ilyesmit, de ez többnyire csak a forditási hibák átláthatoságát javitotta volna (ebben az esetben).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
mark576 - Tag | 256 hsz       Online status #142039   2010.10.09 16:56 GMT+1 óra  
Idézet
dvorgaz :
C++ban nem lehet olyat csinálni, mint C#-ban a template típus megszorítása, hogy az valamilyen ősosztályból származzon?
Kód:
class LinkedList<K,T> where K : IComparable



C#-ban ez azért van, hogy a fordító értelmezni tudja az adott típus műveleteit, amit aztán a JIT majd ténylegesen használni fog dinamikusan. Itt előre nem lehet tudni semmit, mert a T dinamikusan jöhet DLL-ből, akárhonnan. Ennél már csak a dynamic az elvontabb, ahol már akár egy típust futás közben is létrehozhatsz, módosíthatod a szerkezetét tetszőlegesen.

Mivel C++ ban ez teljesen statikus már fordítási közben tudni kell, hogy a T pontosan micsoda, külön ehhez megszorítást csinálni különösebben nincs értelme, hisz a fordító garantálja a típust.

Ilyet szoktam, amit kiskami is írt, de ez mást jelent egy kicsit:
Kód:
template <typename T> class MyArray
{
    static void Zero(void *array, int size)
    {
        //valamilyen saját megoldás
    }
};

template <> class MyArray<void *>
{
public:
    //C-s tömb kinullázása
    static void Zero(void *array, int size)
    {
        memset(array, 0, size);
    }
};

Ez csak annyi, hogyha a T void *, akkor a Zero művelet a memset-et hajtja végre, egyébként a másik Zero műveletet.
   
kiskami - Tag | 265 hsz       Online status #142038   2010.10.09 16:24 GMT+1 óra  
Előírni tudomásom szerint nem lehet, de lehet készíteni részleges specializációt, ami az adott típusú paraméterre optimalizált.

Vagy a Boost typetraits csinál ilyesmit.
[Silent Vertigo] { Solarah }
http://www.silentvertigo.hu
   
dvorgaz - Törzstag | 575 hsz       Online status #142032   2010.10.09 14:36 GMT+1 óra  
C++ban nem lehet olyat csinálni, mint C#-ban a template típus megszorítása, hogy az valamilyen ősosztályból származzon?
Kód:
class LinkedList<K,T> where K : IComparable
   
bit.0x8000 - Törzstag | 574 hsz       Online status #141910   2010.10.06 01:28 GMT+1 óra  
Itt a konkrét kód, ha esetleg számít valamit:
Kód:
const boost::ptr_vector<std::string>
  &profiles = profileManager->getProfiles();
CEGUI::ItemEntry *itemEntry;
CEGUI::Window *window;
int index;

profilesList->resetList();
for (index = 0; index != profiles.size(); index++)
{ window = windowManager->createWindow("TaharezLook/StaticText");
  window->setAlpha(0.5F);
  window->setWidth(CEGUI::UDim(0.9F, 0.0F));
  window->setHorizontalAlignment(CEGUI::HA_CENTRE);
  window->setHeight(CEGUI::UDim(0.8F, 0.0F));
  window->setVerticalAlignment(CEGUI::VA_CENTRE);
  window->setProperty("HorzFormatting", "HorzCentred");
  window->setFont("Commonwealth-14");
  window->setText(profiles[index]);
  itemEntry = static_cast<CEGUI::ItemEntry *>(
    windowManager->createWindow("TaharezLook/ListboxItem"));
  itemEntry->setMinSize(CEGUI::UVector2(
    CEGUI::UDim(0.0F, 0.0F), CEGUI::UDim(0.1F, 0.0F)));
  itemEntry->addChildWindow(window);
  profilesList->addItem(itemEntry);
  if (profiles[index] == profileManager->getActiveProfile())
    itemEntry->setSelected(true);
}
   
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]