Új hozzászólás Aktív témák

• #1523 proci985 MODERÁTOR doc #1517

  Új Válasz 2012-04-24 22:10:53 #1523

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  proci985

  MODERÁTOR

  válasz doc #1517 üzenetére

  szerintem lehet egyel nagyobb is az eredeti tömbméretnél. leírás alapján nekem ez egy Cben használt dinamikus tömb megoldásnak tűnik. más kérdés, hogy nem értem, hogy ez minek C++ alatt, amikor ott vannak a beépített funkciók.

  h1ght3chzor:
  Memory::tomb[k]=a;

  a az itt micsoda? honnan jön? mi a típusa? szerintem ez is lehet baj.

  tippek:
  - használj változóneveket angolul, konvenciókkal. pl class scope változóneveknél m előtag sokkal átláthatóbb kódot eredményez.
  - a this és Class:: jó móka, de legyél velük koherens
  - ha nem ez volt a lényeg, akkor használd a beépített C++ funkciókat. vannak szép dinamikus listák, ez nem C. ArrayListel egy sima add() meghívásával megoldható a problémád
  - getProjektMeret redundanciát és több helyen tárolt változókat jelent, amiket pl a mutatott kód alapján nem is updateltél. szerencsésebb a tömb méretét nem letárolni külön, vagy létrehozni egy külön container classot, ha mndenképpen sajátot akarsz írni.
  (másképp: ránézésre vizsgafeladatnak hittem a problémád, annyira spagettiszerű. ez hosszú távon nem jó)

  ArchElf: még azon gondolkodtam el, hogy a tömbnél a tárolás hogy van megoldva, mert a delete[] elvileg csak a mutatókat törli implementációfüggően. nem vagyok benne biztos, de ez nekem gyanús, hogy leakelni fog (pl saját operator= segítségével nem).

  WonderCSabo: tippeltem, illetve tippelek.

  temp1[i]=tomb[i];
  this->tomb=new Project [this->getprojektmeret()+1];
  Memory::tomb[k]=temp1[k];

  mivel egy dinamikus tömböt megvalósító funkcióról van szó arrayekkel, a két tombnek elvileg ugyanoda kéne kerülnie. a két kódrészlet futás után csak akkor egyezik, ha ugyan ahhoz a classhoz tartoznak. hacsak nem tomb egyszerre van deklarálva globális változóként és a Memory class változójaként (és a this miatt ebben az osztályban) is, de az azért erős lenne. ha viszont eléri a tomb[]ot innen, tomb[], Memory::tomb[] és this->tomb[] megoldásokkal is, akkor jelen pillanatban a Memory classban kell lennünk, másképp három különböző tömbről lenne szó. habár, a this->tomb sor kiakad, szóval lehet, hogy mégse így van. ebből következtettem, hogy ha ez így működik, akkor a Memory classban kell lenni.

  getprojektmeretnek classfunctionnak kell lennie, ami eltárolja az elvárt projektméretet és nem a tomb méretét adja vissza (egyébként az új projektnél kiakadna).

Új hozzászólás Aktív témák