- Apple iPhone 16 Pro - rutinvizsga
- Mobil flották
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Samsung Galaxy S24 FE - később
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy S21 FE 5G - utóirat
- iPhone topik
- Honor Magic6 Pro - kör közepén számok
- Íme az új Android Auto!
- Yettel topik
Új hozzászólás Aktív témák
-
Tomi_78
aktív tag
válasz
mgoogyi #4267 üzenetére
Nem, a Unt1.h-ban ez a fejléc:
void __fastcall alakcsinalas(TObject *Sender);
De itt az egész kódom, talán még nem olyan nagy annyira, hogy ne tegyem itt közzé:#include <vcl.h>
#pragma hdrstop
#include "Unit1.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
}
//---------------------------------------------------------------------------
class egyalak
{
public:
egyalak(int px, int py, Graphics::TBitmap* kep)
{ x=px; y=py; kepe=kep;}
int x;
int y;
Graphics::TBitmap* kepe;
unsigned char alkepvaltoido; //0-255
unsigned char aktalkep;
unsigned char alkepdb;
unsigned char sebessege;
};
const int maxalakdb = 5;
egyalak *alakok[maxalakdb];
int alakdb = maxalakdb;
TTimer *alakmozgato;
Graphics::TBitmap* kepei[4];
int pontok = 0;
unsigned char as = 32;
unsigned char th = 1;
void __fastcall TForm1::alakcsinalas(TObject *Sender)
{
int i;
for (i=0; i<alakdb; i++)
{
alakok[i]=new egyalak(4,i*kepei[0]->Height*2,kepei[0]);
alakok[i]->alkepvaltoido=5;
alakok[i]->aktalkep=0;
alakok[i]->alkepdb=3;
alakok[i]->sebessege=as;
}
}
void __fastcall TForm1::alakmozgatas(TObject *Sender)
{
int i;
for (i=0; i<alakdb; i++)
{
if (alakok[i]->alkepvaltoido>0)
{
alakok[i]->alkepvaltoido-=1;
}
else
{
if (alakok[i]->aktalkep+1<=alakok[i]->alkepdb)
{
alakok[i]->aktalkep+=1;
}
else
{
alakok[i]->aktalkep=0;
}
if (alakok[i]->x+(kepei[0]->Width)<Form1->Width)
{
alakok[i]->x+=alakok[i]->sebessege;
}
else
{
delete alakok[i];
if (i<alakdb)
{
int j;
for (j=i+1; j<alakdb; j++)
{
alakok[i]=alakok[j];
}
};
alakdb-=1;
if (alakdb<1)
{
if (as+4<255)
{
as+=4;
}
&alakcsinalas;
};
}
alakok[i]->alkepvaltoido=5;
}
alakok[i]->kepe=kepei[alakok[i]->aktalkep];
}
Invalidate();
}
void __fastcall TForm1::FormCreate(TObject *Sender)
{
kepei[0] = new Graphics::TBitmap;
kepei[0]->LoadFromFile("alak\\alak_all.bmp");
kepei[0]->Transparent=true;
kepei[2] = new Graphics::TBitmap;
kepei[2]->LoadFromFile("alak\\alak_all.bmp");
kepei[2]->Transparent=true;
kepei[1] = new Graphics::TBitmap;
kepei[1]->LoadFromFile("alak\\alak_lep1.bmp");
kepei[1]->Transparent=true;
kepei[3] = new Graphics::TBitmap;
kepei[3]->LoadFromFile("alak\\alak_lep2.bmp");
kepei[3]->Transparent=true;
&alakcsinalas;
alakmozgato=new TTimer(this); //Időzítő létrehozása
alakmozgato->Interval=50; //Időtartam beállítása
alakmozgato->Enabled=true;
alakmozgato->OnTimer=alakmozgatas; //Ez történjen, ha lefutott.
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Kirajzol(TObject *Sender)
{
TPoint p = Form1->ScreenToClient(Mouse->CursorPos);
int i;
for (i=0; i<alakdb; i++)
{
if (GetAsyncKeyState(VK_LBUTTON) && p.x>=alakok[i]->x && p.x<=alakok[i]->x+kepei[0]->Width && p.y>=alakok[i]->y && p.y<=alakok[i]->y+kepei[0]->Height)
{
pontok+=1;
delete alakok[i];
if (i<alakdb)
{
int j;
for (j=i+1; j<alakdb; j++)
{
alakok[i]=alakok[j];
}
};
alakdb-=1;
}
Canvas->Draw(alakok[i]->x,alakok[i]->y,alakok[i]->kepe);
}
Form1->Caption = "Alakok: "+IntToStr(alakdb)+" - Pontjaid: "+IntToStr(pontok)+" - Támadóhullám: "+IntToStr(th);
} -
Tomi_78
aktív tag
-
Tomi_78
aktív tag
válasz
mgoogyi #4250 üzenetére
Most ilyen a fejléce a függvényemnek:
void __fastcall alakmozgatas(TObject *Sender)
a hívása pedig:alakmozgato->OnTimer=(TNotifyEvent) &alakmozgatas;
És mégis ezt a hibaüzenetet kapom:
[C++ Error] Unit1.cpp(90): E2031 Cannot cast from 'void (_fastcall *)(TObject *)' to 'void (_fastcall * (_closure )(TObject *))(TObject *)'De majd próbálok utánanézni, hogy az OnTimer milyen típust fogadhat.
-
-
-
jattila48
aktív tag
válasz
mgoogyi #4148 üzenetére
Ahogy írtam, a const int kezelése esetleg lehet fordító és helyzet függő, pl. a példa programodban képezhető a címe (bár sok értelme nincs, mivel értéket nem adhatsz neki). De amiket példákat írtam (template argumentum, tömb méret), valószínűleg az értékét mint konstanst fogja használni, hiszen fordításkor még semmilyen memória címet nem tulajdoníthat neki. Értékadásnál esetleg lehet más a helyzet, hiszen az értékadás futás időben történik, és ott hivatkozhat a konstansra a memória címén keresztül (sok értelme ennek sem lenne, esetleg gyorsabb lehet az újra fordítás, ha megváltoztatod a forráskódban a konstans értékét. Ez csak tipp).
A #define egy más kérdés, az pusztán szövegfeldolgozás. Ott tényleg semmi különbség nem lehet ahhoz képest, mintha a konstans literált írtad volna minden helyen.
Kicsit elkanyarodtunk a témától. A const int-et és enum-ot csak a tömb mint konstans cím hasonlósága miatt hoztam fel. Eredetileg arra válaszoltam, hogy a tömb nem pointer, még ha sokszor hasonlóan is kezeljük. A különbség gyakorlatban is fontos vonatkozására is felhívtam a figyelmet, amit minden programozónak tudni kell. A technikai különbségek (mi hogy fordul, mennyire hatékony) valóban nem életbe vágók, de érdemes tudni róluk. -
jattila48
aktív tag
válasz
mgoogyi #4144 üzenetére
Nem, nem csak nevezéktanról, hanem lényeges különbségről van szó. A
const int harom=3;
kódban a harom semmilyen módon nem változó, mert a lefordított kódban nem a memóriában elfoglalt címe alapján fognak rá hivatkozni, hanem pl. egy értékadó utasításban konkrétan befordítják a 3 konstans értéket:x=harom;
lefordítva valahogy így fog kinezni:lea eax,DWORD PTR[ebp-12] ;x cime az eax regiszterbe kerul
mov DWORD PTR[eax],3 ;x a 3 konstanst kapja ertekul. a 3 itt jelenik meg a kodbanharom nevu valtozo pedig sehol nincs.Amit angolul idéztél, szerintem kissé értelem zavaró, mert valóban olyan változóként (mintha memóriában el lenne tárolva) hivatkozik rá, aminek az értékét nem lehet megváltoztatni. Ez szerintem nem így van (bár talán lehet fordító függő), annál is inkább, hogy a const int-ek és enumok lehetnek template argumentumok, amiket a fordító egész biztos konstans int-ként fog értelmezni mikor a template-et példányosítja. Sőt a tömb konstans mérete is lehet const int, vagy enum. Mikor a fordító a stack-en (vagy globális adatterületen)" lefoglalja" a megfelelő méretű memóriát a tömb számára, ott konkréten az adott konstans számszerű értékét fogja használni, nem pedig holmi memória címből képzett indirekt hivatkozást.
-
jattila48
aktív tag
válasz
mgoogyi #4142 üzenetére
"Pont nem érdekel, nem látom a gyakorlati jelentőségét"
Pl. az lehet a gyakorlati jelentősége, hogy innen már világos, hogy a C/C++ -ban miért nem lehet dinamikus méretű tömböt deklarálni (bár mint most megtudtam, újabb C szabvány szerint lehet):
int n=10;
int a[n]; //hiba. tomb meret csak konstans lehetEzt kezdők általában nem szokták érteni.
Ha az új C szabvány ezt mégis megengedi, akkor a tömb címe szükségképpen eltárolódik a memóriában (mintha változó lenne), de a fordító nem engedi meg a megváltoztatását és a címének képzését (gondolom így van, de nem ismerem a C-nek ezt a lehetőségét).
Másik gyakorlatban fontos vonatkozása a dolognak, hogy a dinamikusan allokált memóriát fel kell szabadítanod (ha nem akarsz memory leaket), a tömböt pedig nem kell (sőt nem szabad!) felszabadítani (hiszen nem a heapen lett lefoglalva). Tekintsük a következő kódrészletet:int tomb[10];
int *dinamik_tomb=new int[10];
int *pointer;
pointer=tomb;
delete[] pointer; //hiba! nem szabad felszabaditani a tomb-ot
pointer=dinamik_tomb;
delete[] pointer; //OK, fel kell szabaditani a dinamik_tombotAmint látod, a pointer felszabadításánál észnél kell lenni, tudni kell, hogy tömb, vagy dinamikusan allokált memória terület címét tartalmazza-e. Ebből bizony sok hiba adódik (jó párat láttam már), és megy a fejvakarás, hogy miért száll el a program, hiszen a "tomb valójában pointer". Hát nem!
-
jattila48
aktív tag
válasz
mgoogyi #4142 üzenetére
Nevezheted tömbnek a dinamikusan allokált memória területet, de az nem tömb abban az értelemben (konstans mérettel deklarált tömb), ahogy írtam. A különbséget nem írom le még egyszer.
"Pusztán ránézve a kódra én "a"-ra és "b"-re is változóként(előbbire pointer típusú változóként, utóbbira tömb típusúként) fogok hivatkozni."
b nem változó, hiszen nem változhat az értéke, mint ahogy egy változónál (a nevében is benne van) ez megtörténhet. Ennyi erővel a 3-at is nevezheted változónak, holott az sincs sehol a memóriában eltárolva. A tömb esetében kicsit azért kevésbé nyilvánvaló, hogy nem változó, hanem konstans, mert nevet adsz neki. A 3 leírva konstans literál, ezért nyilvánvalóbb hogy ő nem változó. Azonban írhatsz olyat, hogyconst int harom=3;
enum akarmi={nulla,egy,ketto};
ahol a névvel illetett számok szintén konstansok, nem lehet sem megváltoztatni az értéküket, sem a címüket képezni. A tömb ugyanilyen értelemben konstans. Ennek a látszat ellenére igenis van gyakorlati jelentősége, és illik is tudni róla. Csak erre szerettem volna felhívni a figyelmet -
jattila48
aktív tag
válasz
mgoogyi #4140 üzenetére
Attól tartok, teljesen félreérted.
"...én a t-re gondolok, mint változóra"
Ahogy írtam, a t NEM változó, hanem konstans és ez a lényeg. Ha azt írod, hogyint i=j+3;
akkor az i és j változók, amik a memóriában futás időben keletkeznek, a 3 viszont konstans, ami sehol nem tárolódik el e memóriában, hanem a generált kódban jelenik meg mint konstans adat. Hasonlóan a tömb esetén is, sehol nem tárolódik a tömb (mint cím) értéke, hiszen csak egy konstans.
"Az a konstans cím, amiről beszélsz, az maga a t változó tartalma"
Nincs semmiféle t változó.
"Annyit tud egy pointerhez képest, hogy a típusából kifolyólag tud arról, hogy hány elemű"
Nem, nem tud róla hogy hány elemű, hiszen a konstansban ez nincs kódolva. C-ben egyébként sincs tömb index ellenőrzés (futás közben), és a fordító sem különböztet meg ez alapján típusokat (template-tel megoldható, ha a tömb méret template argumentum).
"nem pointer, de mégis pontosan ugyanúgy viselkedik"
Nem pontosan úgy viselkedik, ahogy előző hozzászólásomban írtam, nem adható neki érték, és nem képezhető a címe (szemben a pointerrel).
"Másrészt nem csak a stacken lehet a tömbünk, hanem a heapen is"
Nem, nem lehet a heapen tömb. Az nem tömb lesz, hanem dinamikusan foglalt memória, aminek a címe bekerül egy változóba (vagyis pointer), bár valóban kezelheted tömb szintaxissal, ha az elemeit akarod elérni. Tömböt deklarálni a stack-en lehet, vagy a globális adatterületen (amit a betöltő foglal le a memóriában).
"Egyébként aki most ismerkedik a C++-szal, annak lehet inkább riasztó, mint segítség."
A C++ nem egy egyszerű nyelv, és szerintem jó az elején tisztázni bizonyos dolgokat (pl. ezt), hogy később ne rögzüljön hibásan, mint ahogy az esetedben is. -
Teasüti
nagyúr
válasz
mgoogyi #4134 üzenetére
A new (new []) esetében egy pointer-t kapsz vissza
De hisz a tömb is egy pointer.Ha ezeket nem használod és elfelejteted a delete-et, akkor keresheted, hogy miért növekszik a progid memóriahasználata (memóriaszivárgás).
Mi van akkor, ha egy függvény minden lefutáskor létrehoz egy tömböt és elfelejtem törölni miután lefutott, majd újra meghívom a függvényt? Más memóriaterületen fogja megint létrehozni ugyanazt a tömböt?(#4133) dabadab
Áhhá!! Értem.
Ezt mintha olvastam is volna, hogy adott esetben egy szinttel feljebb szokták törölni, mondjuk az adott függvényen kívül. -
PandaMonium
őstag
válasz
mgoogyi #3992 üzenetére
Biztos, hogy nem ez a probléma, különben a for-ciklus el sem indulna (i < v.size() feltétel).Félreértettem amit mondtál, jogos a felvetés.(#3997) gepa7: Örülök, hogy megoldódott, de két apróság. Ha csak a vector mögött levő buffer méretét akarod állítani, anélkül, hogy létrejönnének benne az objektumok vagy változna a v.size(), használd a v.reserve() függvényt. A másik, hogy felejtsd el az egy betűs változókat, mert ettől minden programozó falnak megy, és ha másnap ránézel a saját kódodra már te sem fogod tudni mi micsoda. Nekem is többször át kellett olvasnom a kódodat, hogy megértsem, pedig nem egy bonyolult algoritmus.
Szerk: Az is sokat segít ha konzisztensen formázod a kódodat, behúzások rendben vannak, stb.
-
#74220800
törölt tag
válasz
mgoogyi #3992 üzenetére
Hi,
Nem. Arrol van szo, hogy az "a" vektor egyes elemeiből indulva kummulalom az ertekeket. Kerdes mikor eri el az osszeg leghamarabb a 4-et. De a feladat sztem elvben jol van megoldva. Ha lefuttatod a progit ki is tudtam iratni az eredmenyvektort. De vhogy az elso oszlop kiiratasa nem megy, vagyis megy de utana leall. Vmi memoria gond lehet.
-
b.kov
senior tag
-
G.A.
aktív tag
válasz
mgoogyi #3830 üzenetére
(Az első gondolatom vmi rejtett karakter a kódban, amitől valamiért meghülyül a fordídtó.)
Köszönöm szépen! Igazad van!
A kód pdf-ből történt másolása során az "enter" kód nem lett úgymond konstans. (Néhol \n, máshol \r\n)
Bezártam a VS-t, majd újranyitottam és egyből jelezte is a hibát és ki is javította.Köszönöm szépen még egyszer a segítséget!
-
jattila48
aktív tag
válasz
mgoogyi #3611 üzenetére
De, erről van szó. Azonban a kód generálás, már nem a szimbólum tfv.-einek hívásával történik, hanem a szimbólum attribútumai alapján. A megtalált szimbólum állapotán már nem változtatunk. Ahogy írtad, pl. függvények, változók neveiből keletkeznek szimbólumok, teljesen különböző attribútumokkal. Ezért nem lehet egységes interfészen kezelni őket, viszont mégis egy táblázatban kell tárolni ezeket.
Nyugodtan dumálj bele, nem leugatni akartalak. Bocs, ha így érezted. -
jattila48
aktív tag
válasz
mgoogyi #3606 üzenetére
Nekem úgy tűnik, mégsem egészen tudod, mi a szimbólum tábla (bocs). Ha egyszer bekerült a szimbólum a táblázatba, akkor azt már nem kell "feldolgozni" (legfeljebb törölni), hanem szükség szerint megtalálni kell, és az attribútumai alapján generálni a megfelelő kódot. A tárolt szimbólumnak ha lenne virtuális fv.-e, akkor az csak getter lenne, de semmiképpen nem "processz". Tulajdonképpen a find const pointereket ad vissza, mivel egyáltalán nincs szükség a megtalált szimbólum megváltoztatására. Azonban a szimbólumok, ahogy írtam teljesen különbözők, így nincsenek hasonló attribútumaik sem (a nevet és típust kivéve). Ezért nem lehet (és nem is kell) őket egységes interfészen keresztül kezelni.
-
jattila48
aktív tag
válasz
mgoogyi #3603 üzenetére
Ne haragudj, de szerintem nem érted miről van szó. Persze, hogy csak a pointerek vannak sorfolytonosan a vektorban (hiszen írtam, hogy csak ezeket tárolom vektorban). EQMontoya arra gondolt, hogy vektorban (a sorfolytonos elrendezés miatt), kis elemszám esetén gyorsabb az ismétlődés keresés, mint pl. set-ben. Ez akkor is így van ha, csak az objektumok pointereit tároljuk, mert az algoritmus ezen fog föl-alá futkosni, miközben a pointerek által hivatkozott objektumokat hasonlítja össze. Ha jól van megírva az ismétlődés kereső algoritmus, akkor mindössze egy összehasonlító operátort kell neki átadni, és pont ugyanúgy működik, mint egyéb esetben.
Na de ennek semmi köze az eredeti problémához, mert szimbólum táblában NEM keresünk ismétlődést. -
jattila48
aktív tag
válasz
mgoogyi #3600 üzenetére
Leírtam, hogy miről van szó. Ha nem tudod mi az a szimbólum tábla, akkor azt most nem tudom teljes részletességgel elmagyarázni. Nem ismétléseket kell keresni benne, hanem hanem amikor a programszövegből új nevet olvas a szintaktikus elemző, meg kell állapítani, hogy előfordult-e már ilyen nevű szimbólum. Ezt vagy azért teszi, mert új nevet definiálunk (ekkor ellenőrizni kell, hogy a scope-ban szerepel-e már), vagy azért, mert hivatkozunk rá (ekkor ki kell keresni (nem csak a scope-ból), és a tárolt attribútumai szerint folytatni a fordítást). Leírtam, hogy miért kell az összes különböző típusú szimbólumnak egy táblázatban szerepelni. Mivel különböző típusúak, ezért nem lehet őket egységesen (polimorf módon sem) kezelni. Az, hogy a szimbólum tábla most vektor-e, map, vagy hash tábla, teljesen mindegy. Nekem bőven elég a vektor. A hangsúly a heterogén tároló használatán van.
-
-
Karma
félisten
válasz
mgoogyi #2400 üzenetére
Ezt tapasztaltam igen, ha az enumot kihagytam a buliból, megjavult a sor...
De közben megoldódott, kaptam egy szeletet a másik fél tesztprojektjéből, amiben mbstowcs helyett MultiChar... valami függvényt használtak a 8-16 bites konverzióra, erre átálltam teljesen, és elmúlt a hiba...
Holnap esetleg bemásolom az eredeti kódomat, hátha valaki látja mi a baj vele. Én továbbra se látom.
-
Karma
félisten
válasz
mgoogyi #2397 üzenetére
És WonderCsabo: erre nincs lehetőség, mert a C++ -> C# irányban elég korlátozott lehetőségeim vannak (egy féle, WinRT specifikus tömb, lista, dictionary). Legalább generikus, úgyhogy tudok saját objektumokat belepakolni (ez a String^, String^, enum hármas).
Mivel ez egy blocker probléma, ma öltem időt a kísérletezésbe. Az eredmény már annyira nem determinisztikus, hogy kvantummechanikai jelleget mutat
Schrödinger macskája pörög a hátára kötött vajaskenyérrel.
Átírtam az adatgyűjtő metódust, hogy ciklusban százszor hajtsa végre a lépést, és az eredménx a jó-rossz között ingadozott egymás alatt. A teljes folyamatot ciklusba téve még mindig ez a sor billegett, ergo nincs a hívások számához vagy hyorsaságához kötve.
Debug változatot sajnos nem kaphatok a fekete dobozból (másik fél policyje), így a saját kódomat is csak Release módban fordíthatom. De itt van a másik kvantumjelenség: azért ilyenkor is meg tudok állni breakpointokon, megpróbálhatok belenézni a változókba, de ha ezt teszem, minden számolt érték átmegy zajba. Mint az elektronok elhajlása résen...
Maga a 8/16 konverzió az mbstowcs/wcstombs segítségével megy, és mivel minden kommunikáció alapja a fekete doboz és a C# világ között, elég sokat hívom - nem ezzel lehet a baj.
Lokalizáció csak a telefon ujraindításával változhat, nem kavarhat be. Főleg hogy az előző két függvény nem locale érzékeny.
A szöveg prefixelésével sokat próbálkoztam: ha rossz, akkor a konstans string se jön vissza, ha jó, akkor meg igen. Így gyanússá vált, hogy nem a szöveg összeállításával, hanem az enumnál lehet a gond, átírtam fix értékre, amitől stabilizálódott a szöveg
A baj csak az, hogy semmi értelme, mert az enumot kiválasztó függvényt a szövegnél is felhasználom...
Nekem továbbra is megvan az a sejtésem, hogy a fekete doboz belepiszkít a stackbe, elrontva az előtte lévő wstringet. De nem tudom bizonyítani - a fejlesztőinél nem mutat ilyen tüneteket.
Ha nem fogadnák el a workaroundot, holnap megnézem hogy binárisan hogy viszonyul a zaj a szöveghez.
-
modder
aktív tag
válasz
mgoogyi #2079 üzenetére
Hali,
Azt hiszem igazad van, a "A b = B();" tényleg az A copy konstruktorát fogja meghívni, tehát ez egy A objektum lesz. Akkor viszont pvt.péter felvetésére mégis csak jogos, hogy a dinamikus kötés csak pointeren keresztül lehetséges C++-ban. De nem a stack vs. heap miatt, hanem a pointer miatt.
Megnéztem az egyik régi házimat, ahol nem lehetett new operátort használni, és így oldottam meg:
Henger henger;
Asztal asztal;
Object* objects_[ MAX_OBJECTS ] = {&henger,&asztal};Ezt csak azért írom, mert a new operátort direkt el akartam kerülni az egész példámban, hogy látszódjon, anélkül is lehet dinamikus kötést alkalmazni.
Köszi a tisztázást!
-
scream
veterán
válasz
mgoogyi #2067 üzenetére
Van egy konkrét feladatom :
"Egy szöveges állományban tároljuk egy magasugró verseny eredményét. Az állomány minden sorában egy-egy versenyző adatait találjuk: a versenyző nevét (szóközök nélküli szöveg) és mellette azt, hogy az egyes próbáknál mekkorát ugrott. A versenyen egy versenyző 6-szor próbálkozhatott. Ha leverte a lécet, X a próba eredménye, ha kihagyta az adott magasságot, akkor O. Feltehetjük, hogy az állomány helyesen van kitöltve.
Listázza ki azoknak a nevét a konzolra, akiknek csak egy sikeres próbálkozása (150 cm-nél magasabb ugrása) volt, valamint adja meg a legjobb ugrást teljesítő sportoló nevét és összes eredményét! "Például az input fájl adatai:
Nagy_Bela 120 X O 125 130 X
Kiss_Agoston 140 145 X 150 155 X
Toth_Pal 135 O 140 145 X 155Namármost kell használnom szekvenciális inputfile-t, majd a két feladatra kell egy keresést meg egy max.kiv-t csinálnom, nem ?
Én úgy indultam neki, hogy egy struktúrában (7 string) vannak az adatok, a beolvasás is megvolt, az adatok a megfelelő helyen szerepelnek. Viszont innen most nem tudom hogyan induljak tovább, mert csak 1-szer lehet bejárni a meghívott file-t.
Intervallumos progtételek : ITT.
Nevezetes felsorolós progtéltelek : ITT -
jattila48
aktív tag
válasz
mgoogyi #1921 üzenetére
Ez így is van. A kliens felé biztosított init nem generál exceptiont, hanem bool-lal tér vissza. Viszont ez az init tagobjektumok init-jét hívja, amik generálhatnak exceptiont, de azok itt lekezelésre kerülnek.
Kontruktor-nak meg muszáj exceptiont generálni ha valami hiba történik, hiszen másképp nem tudja jelezni a hibát. A bad_alloc-ot lekezelheti (sőt!), de utána új exceptiont kell generálnia. -
scream
veterán
-
pityaa23
senior tag
válasz
mgoogyi #1910 üzenetére
Köszi!
Holnap tudok nekiállni. Eléggé amatőr vagyok. Későn kezdtem el foglalkozni vele. Programozás 1 tantárgyon túl vagyok, ami a struktúrákig tartott. Komolyabb dolgokat nem csináltunk. Most a programozás 2 eléggé nehezen megy, jó nagy különbség van nehézség terén a 2 tárgy között. Levelezőn tanulok, 3 hete volt az első óra, szóval nagyon idő se volt gyakorolgatni. Most yútúb videókat nézve kell tanulnom, mert az oktatás az kb annyi, hogy órán legépelünk egy programot, gondolkozni vagy önerő az nulla. Ezen a hétvégén vettük az osztályokat, de a fele anyagot le sem adták. Szuper. 15.-én Zh, addig szerintem minden időmet bele kell ölnöm, hogy összehozzak egy kettest. Házi egyébként a 2006 májusi emelt szintű programozás érettségi egyik feladata, csak ott ugye más nyelven írták.
Esetleg ha van ötletetek, hogyan tudnék gyorsan megtanulni programozni ne tartsátok magatokban!
-
scream
veterán
válasz
mgoogyi #1918 üzenetére
Sajnos még kezdő "programozó" vagyok, most tapasztalom ki mit hogyan kéne.
Mellesleg "csak" (
) félreértelmeztem, hogy mit is csinál a void paraméterlistája és nem voltak deklarálva az int mainben a dolgok, illetve a K-t &K-ként kell átadni és megy is.
"Most itt összehánytál egy csomó mindent, aztán halvány fingod sincs, hogy mi nem jó."
Köszönöm a biztató szavakat
-
jattila48
aktív tag
válasz
mgoogyi #1917 üzenetére
Biztosan meg lehet oldani másképp is ezt a problémát, pl. ahogy írod. Az én javaslatomnak az az előnye, hogy a konstruktorban nem kell kezelni az exceptiont, sőt az init tfv.-ben sem. Az init tfv. természetesen generálhat exceptiont, de azt lehet kezelni felsőbb szinten, és mikor az objektum kilép a scope-ból a destruktora (illetve a tagobjektumok destruktorai) automatikusan mindig elvegzik a deallokációt. Tehát bármilyen "mélyről" jön egy pointer tag inicializálásával keletkező exception, a végén minden sikeresen allokált pointer tag automatikusan felszabadul.
Nem mondtam, hogy ez lényeges kérdés, viszont szerintem érdekes. Ha nem akarsz, ne válaszolj rá! A kétfázisú inicializálást pedig sok tanulmány ellenzi. Keress rá! -
jattila48
aktív tag
válasz
mgoogyi #1912 üzenetére
Így van, az auto_ptr nem jó tömbre.
Általában nem tanácsolják a kétfázisú inicializálást. Egy olyan helyzetet próbáltam mutatni, ahol mégiscsak célszerű lehet.
Ha a try cathc-et berakom a ctor-ba, ekkor a try-ban auto_ptr-t kéne használni, ami nem jó tömbre.
Az exception-nel az a problémám, hogy ha ctor-ban keletkezik, akkor nem fut le a destruktor (mivel ekkor nem lett teljesen megkonstruálva az objektum), és azok a felszabadítások amiket a destrukdornak kéne elvégezni, nem végződnek el. A kétfázisú inicializálás azon segít, hogy a destruktor mindenképp lefut (mivel a ctor nem dobott exceptiont, hiszen a kritikus inicializálást az init tfv. végzi), és elvégzi a nem NULL pointerek felszabadítását. A ctor-nak természetesen NULL-lal kell inicializálni a szóbanforgó pointereket.
Egyébként éppen tömb inicializálása kapcsán jött ez elő. Remélem így érthetőbb a dolog, persze felhajtást nem szeretnék csinálni, csak megbeszélni, kinek mi a véleménye. -
Jhonny06
veterán
Ja a cím szerinti átadás világos, elsőre azt hittem, hogy valami komolyabbról van szó (ezt most úgy mondtam, mintha akkora májer lennék, mindegy
).
Lefuttatom az általad bemásolt kódot és ugyanaz a hibaüzi, nem adhatsz meg csak simán something-et osztálynak, mert egy array-be vannak, mindenképpen ott kell lennie a [ ]-nek. Szerintem ez az egész alapvetően nem alkalmas arra, amit szeretnék, mert bárhogy próbálom, mindig ugyanahhoz a hibához lyukadok ki.
Azt kellene megvalósítanom, hogy miközben végigmegy a sorokon (pl. for szerkezettel) kilistázza azoknak a soroknak a neveit, amikben a szám == 2, például.
Tehát hiába hozok létre egy változót mondjuk 2 értékkel és írom be a tömbbe, pl.: something[változó].szam, mert utána nem írhatom azt, hogy something.nev, ez egy ördögi kör.
-
-
Jhonny06
veterán
1. Azt a példát csak gyorsan összedobtam, azért vannak felcserélve, véletlenül.
2. Ezt kifejthetnéd bővebben.A dinamikus tömbökről már korábban tanultam, csak most még nem jut eszembe használni, de kipróbálom így is.
A something.day viszont továbbra sem működik, mert alapvetően így olvastam be ugye az adatokat, hogy something[i].day, tehát dob egy szokásos hibaüzit, hogy .day must have a class/struct/union, tudod. Vagy ezt már a dinamikus tömbökkel kéne és menni fog?
A continue egy korábbi while-ból véletlenül maradt bent, figyelmetlen vagyok.
-
doc
nagyúr
Meg engem eléggé zavar, hogy pData=0; -t használsz pData=null; helyett.
ezzel en is sokaig igy voltam C -> C++ valtas utan, de a '0' a C++ 'standard', es egy ideje mar en is igy hasznalom (bar valoban nem kimondottan logikus, a NULL sokkal jobban leirja hogy mi is tortenik a mutatoval mint egy sima numerikus ertek)
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- Bomba ár! Lenovo ThinkPad T490s - i5-8GEN I 16GB I 512SSD I 14" FHD I Cam I W11 I Gari!
- Apple iPhone 12 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! MSI Z77 MPOWER Z77 chipset alaplap garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RTX 4060 Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i3 10105F 8/16/32GB RAM RX 6500 XT 4GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest