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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2194
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] [142]
Asylum - Törzstag | 5471 hsz       Online status #142931   2010.10.31 12:43 GMT+1 óra  
De akár ez is lehet a hiba

Kód:
#define SW 100

struct tomb
{
    int operator[] (int) { ... };
};

int main()
{
    char tomb[SW];
    ...
}
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bit.0x8000 - Törzstag | 574 hsz       Online status #142915   2010.10.31 00:05 GMT+1 óra  
Idézet
HomeGnome :
Lefogadom, hogy a ... lesz a hiba.


Szerintem is elég sanszos a dolog, de hát rossz kiindulási adatokból nem lehet jó következtetéseket levonni...
(Gondolom az elvi hibának számít, ha feltételezem, hogy tényleg a problémás kódrészletet másolja be valaki. )
   
TPG - Tag | 3402 hsz       Online status #142914   2010.10.30 23:54 GMT+1 óra  
Idézet
Asylum :
De csak mert rossz helyen van, egyébként az is C++ -os nyelvi elem


Szal akkor így már jó lesz?
Kód:
void fv1(...){}
#define SW 100
void fv2(...){}
int main(){
   char tomb[SW];
   [](...){};
}

Persze szigorúan C++0x-el értelmezve.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5471 hsz       Online status #142912   2010.10.30 23:35 GMT+1 óra  
De csak mert rossz helyen van, egyébként az is C++ -os nyelvi elem
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #142910   2010.10.30 23:32 GMT+1 óra  
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)


Lefogadom, hogy a ... lesz a hiba.

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Asylum - Törzstag | 5471 hsz       Online status #142908   2010.10.30 23:24 GMT+1 óra  
Kód:
void masoldbeideafajlt(const char* mit, const char* hova)
{
   ...
}

int main()
{
    masoldbeidea... // na vajja ez igy nem jo
}


C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #142904   2010.10.30 22:21 GMT+1 óra  
Hát ha lehet is, előfordító nélkül a #include-okat is manuálisan kellene elvégeznie, ami azért eléggé durva lenne

   
TPG - Tag | 3402 hsz       Online status #142900   2010.10.30 20:41 GMT+1 óra  

Azt lehet? Még sose próbáltam, eszembe se jutott ilyesmi.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5471 hsz       Online status #142897   2010.10.30 20:35 GMT+1 óra  
Szerintem kikapcsolta a preprocesszort....hát úgy tényleg nehéz
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #142892   2010.10.30 20:14 GMT+1 óra  
Tesztelve itt is, direkt visszabutítottam a fordítót a beállításoknál, hogy mindenképpen C kódként fordítsa, és megette simán. Plusz biztos-ami-biztos kipróbáltam pár webes C fordítóval is, ott is ment (Turbo C sajnos nincs kéznél). Szal annak mennie kell. Másrészt ahogy az előbb is mondtam, a preprocesszornak el kell intéznie az egészet, a fordító mindkét esetben ugyanazt a kódot fordítja, nincs számára különbség.
Reality is almost always wrong. - House

   
glezmen - Törzstag | 381 hsz       Online status #142891   2010.10.30 20:02 GMT+1 óra  
Idézet
lezli01 :
Tesztelve

C nem szereti az ilyet, ha mallocolsz akkor lehet jó lesz, de hagyd a c-t és írd be c++-ban és ha úgy lefordul igazam van



valami nagyon elb@szott forditod lehet... kapasbol a preprocesszor a fordito ELOTT kapja el a file-t, vagyis a fordito SEMMIT nem tud arrol, hogy ott a forrasban egy #define vagy egy konkret szam szerepelt, o mar csak a 100-at latja
vagyis ha ezt egy fordito nem eszi meg, akkor ott nagy baj van...
   
lezli01 - Tag | 190 hsz       Online status #142888   2010.10.30 19:44 GMT+1 óra  
Tesztelve

C nem szereti az ilyet, ha mallocolsz akkor lehet jó lesz, de hagyd a c-t és írd be c++-ban és ha úgy lefordul igazam van
   
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 | 5471 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 | 5471 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 | 5471 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 | 5471 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 | 5471 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 | 5471 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 | 5471 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 | 5471 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 | 5471 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 ...
   
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] [142]