Új hozzászólás Aktív témák
-
mgoogyi
senior tag
1, Ha csinálsz egy olyat, hogy
delete pData; akkor csináld így:
if (pData!=null) {
delete pData; pData = null;
}Ha úgy próbálsz felszabadítani, hogy a pData-t már egyszer felszabadítottad, el fog szállni futás közben, ezért a null-ra állítással jelzed magadnak, hogy felszabadítottad-e vagy sem.
Meg engem eléggé zavar, hogy pData=0; -t használsz pData=null; helyett.
2, A get()-nél nem ellenőrzöd, hogy elementNum elérte-e a nullát, mert ha igen, akkor a pData[0]-tól semmi jót ne várj.
3, az empty()-nél is ez kéne:
if (pData!=null) {
delete pData; pData = null;
}4, Nagyon nem hatékony, hogy minden egyes beszúrásnál és törlésnél újrafoglalod a tömböt meg átmásolgatod az elemeket. Célszerűbb lenne egy oda-vissza láncolt lista.
Remélem tudtam segíteni! Ha null-t Null-nak vagy NULL-nak kell itt írni, akkor sorry, mostanában inkább java-zok...
-
mgoogyi
senior tag
Ha bármely két pont között akarsz pontosan egy irányítatlan szakaszt, akkor az ennyi:
for (int i=0; i<N; i++) {
for (int j=i+1; j<N; j++) {
lineto (i, j);
}
}Bár nem tudom, hogy megy ez a lineto...
Ha két lineto kell egy szakaszhoz úgy, hogy először a kezdőpontot adod meg, aztán a végpontot, akkor a belső ciklusban két lineto kell így:for (int i=0; i<N; i++) {
for (int j=i+1; j<N; j++) {
lineto (pont(i).x, pont(i).y);
lineto (pont[j].x, pont[j].y);
}
}(/I) -
mgoogyi
senior tag
#include "fifo.h"
#include<stdio.h>FiFo:iFo()
{
elementNum=0;
pData=0;
}FiFo:iFo(const FiFo&theOther)
{
if(theOther.elementNum==0)
{
elementNum=0;
pData=0;
}
else
{
elementNum=theOther.elementNum;
pData=new double[elementNum];
for(int i=0;i<elementNum;i++)
{
pData=theOther.pData(i);
}
}
}FiFo::~FiFo()
{
if (pData) {
delete [] pData;
pData = 0;
}
}double FiFo::get()
{
if (elementNum==0) {
return 0;
}if(elementNum==1)
{
double element=pData[0];
if (pData) {
delete [] pData;
pData = 0;
}
elementNum=0;
return element;
}
elementNum--;
double element=pData[0];
double*pTemp=new double[elementNum];
for(int i=0;i<elementNum;i++)
{
pTemp(i)=pData[i+1];
}
if (pData) {
delete [] pData;
pData = 0;
}
pData=pTemp;
return element;
}bool FiFo::put(double element)
{
double*pTemp=new double[elementNum+1];
elementNum++;
for(int i=0;i<elementNum-1;i++)
{
pTemp(i)=pData(i);
}
pTemp[elementNum-1]=element;
if (pData) {
delete [] pData;
pData = 0;
}
pData=pTemp;
return true;
}bool FiFo::empty()
{
elementNum=0;
if (pData) {
delete [] pData;
pData = 0;
}
return true;
}Alapból a destruktorban szállt el, hiszen a get()-nél mikor kivetted az utolsó elemet, már felszabadítottad a pData-t, a destruktor pedig még1x megpróbálta ezt megtenni.
-
mgoogyi
senior tag
válasz Jhonny06 #692 üzenetére
Szia,
Első körben két problémát látok:
1, Write() meg Load() függvényeknek fordított sorrendben kéne lennie, mert egy inicializálatlan arrayből nem tudom mit akarsz kiíratni.
2, A Load()-ban a második paramétert tök felesleges referenciaként átadni, nem a tömb címét írod át, hanem a memóriacímen lévő adatokat piszkálod. Ha ez nem világos, amit írtam, akkor bővebben kifejtem. (Referencia helyett inkább const lenne a logikus szvsz.)Még most talán lényegtelen, amíg az alapok nem mennek, de dinamikusan kéne a tömböt lefoglalni menet közben, mert nem tudni, hány sor lesz a fájlban. Ezt így tudod megtenni, hogy: example * tomb = new example[n]; ahol n-et a fájl első sorából olvasod be. Bár ha dinamikusan foglalod le, akkor értelmet nyer a referencia, mert akkor a függvényen belül derül ki a címe. Felszabadítás pedig: delete [] tomb;
Ha pl. azokat a neveket akarod kinyerni, amelyeknél 2 van a név előtt, akkor egy for ciklus a tömbbön és ha if (something.day == 2) cout << something(i).name << endl;
Még valami:
Azzal a continue-val mit akartál elérni a végefelé??[ Szerkesztve ]
-
mgoogyi
senior tag
válasz Jhonny06 #694 üzenetére
Egyrészt ezt így próbáld ki, nekem így simán működik:
#include <stdio.h>
#include <iostream>
#include <fstream>
#include <string>using namespace std;
struct example
{
int day;
string name;
};typedef example array[5];
int load(int& counter, array something);
int write(array something);int main()
{
int counter;
array something;
load(counter, something);
write(something);getc(stdin);
return 0;
}int load(int& counter, array something)
{
ifstream file;
file.open("file.txt");
file >> counter; //<- #2 PROBLEM
for(int i=0; i<counter; i++)
{
file >> something.day;
file >> something(i).name;
cout << something(i).day << " " << something(i).name << endl;
}
file.close();
return 0;
}int write(array something)
{
int one=1;
if(something[one].day)
cout << something[one].name; //<- #1 PROBLEM
/*else
continue;*/
return 0;
}Referencia, cím, stb:
ha van egy tömböd, pl. int tomb[5];
akkor ha csak simán ezt írod le, hogy pl(sorry a c-s kiíratásért, én azt szeretem):
printf("%d",tomb); -> a tömb memóriacíme
tomb[0] -> a tomb memóriacíménél lévő int elem
tomb[1] -> a tomb címéhez képest egy inttel arrébb lévő elem
tomb[2] -> a tomb címéhez képest két inttel arrébb lévő elemtomb + 0 -> a tomb első elemének, avagy a tömbnek a memóriacíme
tomb + 1 -> a tomb második elemének a címe*(tomb + 0) -> a * rámutat a zárójelben lévő címre, azaz az ottani int értéket jelenti
az és(&) jel több dologra jó, most kettőre térek ki:
1. Cím lekérése
van egy ilyen változód, hogy:
int i = 5;
&i ennek az i változónak a címét jelenti a memóriában.
Ha pointerezel: *(&i) az i címére mutató pointer, tehát maga az i.2. Referencia (nem tudom milyen nyelvekben vagy jártas, pascalban pl. ez a var kulcsszó, ill. sok nyelvben meg mindig referencia szerinti átadás van, mint pl. java - persze vannak kivételek
int i = 5;
int & j = i; // az i "álneve" vagy "aliasa" j leszitt a j egy és ugyanaz a változó, mint az i, tehát ha ezt csinálod, hogy
j = 6;
akkor az i is 6 lesz, mivel a két változó ugyanaz, csak két különböző néven tudod őket elérni.ha van egy függvény, ami referenciát vár, pl:
void inc (int & j) {
j++;
}int i = 5;
inc (i);akkor ennek a függvénynek a paramétere egy alias lesz i-re, tehát ha a függvényben megváltoztatod j-t, azzal i-t változtatod. Szal a referencia arra van általában, hogy a bemeneti paraméter kimeneti is lehessen ill. még azért használják, mert ez egy dereferált pointer a beadott paraméterre és ha az a paraméter nagyobb helyet foglal, mint egy pointer, akkor nem kell lemásolni a beadott értéket az újonnan létrehozott ugyanolyan nagy paraméterváltozóba. Ha az utóbbi félmondatot még nem érted, nem nagy gond.
Szóval te egy függvénynek átadtad referenciaként egy tömb címét. Ezt a címet te nyilván nem akarod megváltoztatni, mert akkor a memóriában ki tudja honnan olvasnál be dolgokat.
Kíváncsi vagyok, hogy ebből mit értettél meg... -
mgoogyi
senior tag
válasz Jhonny06 #698 üzenetére
Nálam semmi hibaüzi nincs, visual studio + winXP.
Annak, hogy something.nev semmi értelme, mert a something az egy tömb, neki nincs olyan mezője, hogy nev. A something struktúrák tömbbje, a tömbnek van [i.] eleme, ennek az i. elemnek vannak mezői, mert ez a struktúra. Valahol nagyon kavarhatsz vmit.
Miért nem jó neked, ha azt írod, hogy something[változó].nev???[ Szerkesztve ]
-
mgoogyi
senior tag
válasz jattila48 #1867 üzenetére
Szia,
Ennek mi lenne a gyakorlati haszna számodra?
Csak a polimorfizmust akarod kihasználni, mert minden ilyen objektumra ugyanazt a virtuális függvényt hívod majd meg az f(Base **)-on belül?
Ezesetben azt tudod mondani, amit előttem is írtak, hogy Base ** tömb-ben közlekedtesd az összes leszármozott objektum-ra mutató pointert.Kooperálnak is ezek az objektumok f()-en belül, vagy csak minden egyes tömbelemre meg kell hívni egy függvényt?
Googyi
b, lehetőség egy makró, aminek a paramétere a tömböd, amit meg csinálni akarsz a makrón belül, azt úgyis csak a Base-ben definiált függvényekkel tudod.
[ Szerkesztve ]
-
mgoogyi
senior tag
válasz pityaa23 #1909 üzenetére
Csinálsz egy ehhez hasonló Aminosav osztályt:
Class Aminosav
{
private:
std::string rovidites;
char betujel;
int C,H,O,N,S;
const static int C_TOMEG = 12;
const static int *_TOMEG = ...
const static int *_TOMEG = ...
stb.
public:
Aminosav( >>paraméterek<< ) :
rovidites (p1),
betujel(p2),
stb.
{
}
std::string OsszegKeplet()
{
...
}
int RelativTomeg()
{
...
}
stb.
};Beolvasáskor valamilyen konténerbe(pl. std::set vagy std::vector) bepakolod őket a file-ból beolvasott adatok alapján.
Minden részfeladathoz csinálsz neki egy függvényt, és a függvényben megoldod a részfeladatot.
pl a relatív tömeg az egy súlyozott összeadás.Beolvasás: std::ifstream-mel például, a sorok parsolása meg tokenekre szedéssel vagy sscanf.
Az a kérdés, hogy milyen szinten vagy és mi nem világos abból, amit leírtam?
-
mgoogyi
senior tag
válasz jattila48 #1911 üzenetére
- auto_ptr-rel nem tudsz tömböt felszabadítani (ha tudsz is róla, nem biztos, hogy mindenkinek egyértelmű, főleg mert char tömbökkel dolgozol)
- miért lenne baj a kétfázisú inicializálás? azt kell használni, ami célszerű az adott helyzetben.
- az exception dobás elkerülhető a new esetén az std::nothrow paraméterrel: new(std::nothrow), ekkor NULL pointer-t ad vissza a new, ha nem volt elég memória.
- a destruktorodnak muszáj az objektumod által lefoglalt dolgokat felszabadítani, ez nem kérdés. Nem értem ezt a nagy felhajtást.
- a try catchet ennyi erővel berakhatod a ctor-ba is, ha csak az exception a nagy problémád -
mgoogyi
senior tag
válasz jattila48 #1913 üzenetére
Én még különösebb iránymutatást nem hallottam kétfázisú inicializálással kapcsolatban, pedig egy ideje már c++-ozok.
A ctor-os try catch dolog:
A felszabadítós dolgokat be lehet rakni egy függvénybe és azt hívod a ctor catch ágában és a dtor-ban is.
Na szóval az a véleményem, hogy ez nem egy lényeges kérdés. -
mgoogyi
senior tag
Mi a probléma konkrétan?
A függvény törzsébe nem tudod mit írj, vagy a paraméterlistájába?
Le se fordul?
Vagy ha elakad, hol akad el?Közben megpróbáltam lefordítani.
kivalogatas függvény:113.sor: string Mehetnek[N];
miért definiálod újra, ott van paraméterként
egyébként stack-en foglalt (nem írsz new-t) tömb esetén a tömbméret konstans kell legyen
(pl. const int N = 500 vagy #define N 500)114.sor: újradefiniálás megint, ha csak 0-ázni akarod, akkor elég a K = 0, de ekkor meg nincs értelme, hogy paraméter legyen
main:
33. sor: kivalogatas(N, M, Tanulok); - több, mint 3 paraméter kéne
34. sor: kiiras(); - nem hívhatod meg paraméterek nélkül, mert vannak paramétereibekeres:
89.sor: cin >> Tanulok.nev; - itt elsőre nem tom mi a baja, átírnám cin.getline-osra első próbálkozásképp
kiiras:
139.sor: cout <<"\n" <<" " << Mehetnek(i) <<endl; - itt sem értem miért nem kajolja be, egy .c_str() biztos megoldja
Összefoglalva:
Próbálj meg lépésenként haladni, és miután kipróbálsz(fordít,futtat, minden ok) egy kisebb dolgot, utána lépsz tovább.Most itt összehánytál egy csomó mindent, aztán halvány fingod sincs, hogy mi nem jó.
[ Szerkesztve ]
-
mgoogyi
senior tag
válasz jattila48 #1920 üzenetére
Úgy nézek ki, mint aki nem akar válaszolni?
- Az alapvető szabály (amennyire tudom), hogy ctor-ból és dtor-ból nem jöhet ki exception.
- Kétfázisú inicializálást meg akkor szoktak használni, amikor valamilyen hibakezelés szükséges, amit nem tehetünk meg a ctor-ban.Pl. mint amit te írsz, abban az esetben helytálló a dolog, hogy kétfázisú inicializálás kell. De ha veled kéne dolgoznom és csak az interface-ét látnám annak, amit használnom kell, akkor azt látnám, hogy az init visszatér egy bool-al, nyilván ez kéne, hogy jelezze, hogy sikerült-e az init. Ha teli kell raknom a kódot try - catch-el, mert mindenféle exception-re számítanom kell, akkor nem lesz nagy öröm használni az osztályodat.
És ha 1-nél többször kell használnom, amit csináltál, akkor már jobb, ha te try-catch-ezel az init-ben, az összes mindenki másnak, akik meg hívják az init függvényed, nekik meg elég a visszatérési értéket vizsgálniuk. -
mgoogyi
senior tag
Bocs, nem akartalak megbántani, de ennyire nem fog egyszerűen menni a tanulás, csak kis lépésekben.
Elsőnek csak csinálj egy kisebb programot, ami beolvas valamit és kiírja a képernyőre.
2, beolvassas azokat a dolgokat, amikre szükséged lesz és azokat kiírja
3, a beolvasott dolgokat eltárolod valahogy, majd azokon végiglépkedve íratod ki
4, elkezdhetsz gondolkozni a többi dolgonA "biztató" szavak azért jöttek ki belőlem, mert a kódod túl sok hibát tartalmaz egyszerre és úgy tűnik, hogy nem probáltad ki az alapvető dolgokat, mint beolvasás, stb.
Meg kell küzdeni lépésenként mindennel. -
mgoogyi
senior tag
válasz pityaa23 #1923 üzenetére
Keress neten a házitokhoz hasonló feladatokat és próbáld megoldani.
+ kérdezz itt, ha van időm, válaszolok.Mindenképp értened kéne ezeket, majdnemhogy készségszinten:
for, while ciklusok
if, else if, else
pointerek, pl int *
referenciák pl. int &
new, new[], delete, delete[]
tömbök kezelése
class
{
private:
public:
protected:konstruktor
destruktoradattagok
tagfüggvények
virtual tagfüggvényekstatic adattagok
static függvényeköröklődés
}fontosabb collection-ök: std::set, vector, list
Mondjuk ez így elég sok, nem igazán két hetes téma.
Jó lenne tudni, hogy mi az, amit elvárnak.[ Szerkesztve ]
-
mgoogyi
senior tag
Ez azért nehezen hihető, mert van olyan része a kódnak, ami nem fordul le.
Javítom a kódod és nemsokára felrakom pastebin-re.[ Szerkesztve ]
-
mgoogyi
senior tag
válasz jattila48 #1933 üzenetére
Igazad lehet.
Valszeg jobb a konstruktor-ból hibát dobni, mint kétfázisúan inicializálni.
Viszont ha tényleg exception lehetséges a konstruktorban alapesetben, akkor már inkább elmennék a factory irányba, ami lekreálja az objektumot, visszaad rá egy pointert és azt nézheti a hívó fél, hogy NULL vagy sem.
Ebben az esetben a hívó félnek nem kell semmi meglepetésre számítania. -
mgoogyi
senior tag
válasz bandi0000 #1966 üzenetére
Szia,
Nekem az első gondolatom egy map, ahol a kulcs a kártya azonosítója (1,2, stb.), az érték meg az, hogy hány darab van belőle.
A map-be szépen beupdateeled, hogy miből mennyi van, aztán néhány állapotjelző kell csak, pl.
numOfPairs
numOfDrills
numOfPokers
, amiket a map alapján feltöltesszKét párnál a numOfPairs 2 lesz, egy full-nál a numOfPairs és numOfDrills 1-1.
Ezeket viszont muszáj végigcsekkolni esetekre bontva. -
mgoogyi
senior tag
válasz pvt.peter #2057 üzenetére
röviden:
polimorf osztályoknál van értelme, amikor specializálod a működését az ősosztálynak és minden leszármazottat kezelhetsz úgy, mint ha az egy ősosztálybeli objektum lenne.
pl. minden almát és körtét kezelhetsz gyümölcsként
pl. Akkor van ennek haszna, mikor van egy rakás valamilyen gyümölcsöd mondjuk egy halmazban és együtt akarod kezelni őket, mert pl. az adott helyzetben számodra nem lényeg, hogy milyen specializált gyümölcsről van szó.Amikor örökölsz, akkor a virtuális függvények mindig befigyelnek!
hosszan:
class Gyumolcs
{
...
virtual void print() {printf("gyumolcs")}
...
};
class Alma() : public Gyumolcs
{
...
virtual void print() {printf("alma")}
...
};
class Korte() : public Gyumolcs
{
...
virtual void print() {printf("korte")}
...
};
Gyumolcs * a = new Alma();
a->print(); //azt írja ki, hogy alma, pedig ez egy Gyumolcs pointer
/*mivel: a virtuális függvényeknél futási időben dől el (dinamikusan), hogy mi hívódik (megnézi, hogy valójában milyen objektumról van szó és annak a függvényét hívja - a háttérben egyébként van az objektumnak egy virtuális táblája és abból nézi ki, hogy mit kell hívni)
ha nem virtuális lenne a függvény, akkor fordítási időben (statikusan dőlne el, mit kell hívni és "gyumolcs" íródna ki)*/ -
mgoogyi
senior tag
válasz axelf92 #2056 üzenetére
Valami ehhez hasonló kéne legyen az osztályod:
template < class Key, class Value>
class HashArray
{
bool Insert(const Key & index, const Value & value);
Value operator[] (Key index) { return ...}
stb..
}A kérdés az, hogy a mögöttes adatstruktúra hogy kéne, hogy kinézzen.
Két általános módszer van:
1, Bináris fában vannak a kulcs-érték párok. Ezesetben a kulcsra értelmezhető kell legyen a < operátor.
2, Vagy úgynevezett bucketokban, kb van egy tömb, aminek minden eleme egy lista. A tömbbéli indexet valamiféle hasheléssel találod ki. Pl. ha a kulcs egy szám és 1024 elemű a belső tömböd, akkor a kulcs % 1024 helyen lévő listába tolod bele az új elemet. Csakhogy itt generikus kulcsról van szó, azt nem annyira triviális hash-elni.Itt valszeg az 1-es az ésszerű irány, ami nagyrészt ugyanez, mint az stl mapje:
pl:
#include <map>
#include <string>
std::map<int, std::string> m;
m[1] = "kutya";A legegyszerűbb az lenne nyilván, ha lenne belül egy std::map-ed memberként. (leszármaztatni nem szabad belőle)
De valszeg az 1-es irányt akarja az oktatód, szerintem kérdezd meg, hogy arra gondolt e. -
-
mgoogyi
senior tag
"A b = B();"
Itt lehet van egy kis zavar az erőben, ugyanis ez a sor arra enged következtetni a 'b' változónévvel, hogy ez egy B típusú objektum lesz.
Holott ez a sor a következőt a jelenti:
A b ( B() );
Azaz hozz létre egy A típusú objektumot annak a copy konstruktorával, amely egy B objektumot kap paraméterként.
Ennek két lényeges aspektusa van.
Egyrészt a B() objektumból ledarálódik minden és A típusú objektum marad, merthogy a copy konstruktor érték szerinti A típusú bemenetet vár.
kb így néz ki és defaultból létrejön a copy constructor: A (A input)
Ez a ledarálás az ős irányába meg mindig implicit ( ~= láthatatlanul magától) megtörténik.Másrészt A típusú objektum fog létrejönni.
Másik dolog, hogy ez a kései virtuális kötés csak pointeren és referencián keresztül értelmezhető.
-
mgoogyi
senior tag
http://softwaresouls.com/softwaresouls/2011/12/11/simple-c-class-example-using-serial-port/
Google barátom ezt mondta, nem tudom, hogy segít-e.
Mindkét portodra rányitsz egy-egy ilyen SerialPort objektummal, aztán az egyikből olvasol(getArray(..)), a másikba meg áttolod (setArray(..)).
Hogy a byte-okból mit tudsz majd leszűrni + hogy mennyire jó Com input egy Com output, arról fogalmam sincs.
Nem csináltam még ilyet, szóval ne vedd készpénznek, amit írtam. -
mgoogyi
senior tag
válasz dejaris #2207 üzenetére
Neked valamilyen hexa editor lesz a barátod.
http://en.wikipedia.org/wiki/Hex_editorEgy olyannal rányitsz a file-ra, aztán átírod azt a részt, amit írnak. Ezután meg elmented.
-
mgoogyi
senior tag
válasz loopati #2224 üzenetére
Én lehet inkább stringgé alakítanám, de az osztogatás is jó.
#include <sstream>
...
std::stringstream ss;
ss << szam;
std::string s = ss.str();
s[ ahanyadik számjegy kell];
// ha nem jó char-ban, akkor ez megadja szám formában: ( s[ ahanyadik számjegy kell ] - '0' )[ Szerkesztve ]
-
mgoogyi
senior tag
válasz bandi0000 #2394 üzenetére
Akkor nem tudod szétválasztani az előadót és a szám címét, a kettőt egy stringként tudod csak kezelni.
egyben kezelés:
char src[512] = "3 4 5 elthon john: daralt macska";
int x,y,z;
char buff[512];
sscanf(src,"%d %d %d %[]", &x,&y,&z,buff);
printf("%d %d %d %s\n",x,y,z,buff);ha esetleg lenne egy fix elválasztó karakter:
char eloado[512];
char szam[512];
sscanf(src,"%d %d %d %[^:] %*c %[]", &x,&y,&z,eloado,szam);
printf("%d %d %d %s %s\n",x,y,z,eloado,szam);%[] : olyan string, amiben bármilyen karakter lehet, pl. szóköz is (%s-sel white spaceig olvas, pl. tab,szóköz,enter megszakítja a stringet)
%[^:] : olyan string, amiben nincs :
%*c : olvass egy karaktert, de nem kell semmilyen változóba berakni a * miatt[ Szerkesztve ]
-
mgoogyi
senior tag
A 8-bites stringből 16-bitesre alakító függvény nyilván determinisztikus kéne legyen.
Ha memória túlírás lenne valahol és az piszkálna bele az output-ba, akkor meg nem hinném, hogy mindig pontosan ugyanazokat a kínai jeleket adná.
Arra gondolnák elsőnek, hogy a lokalizáció változik. Esetleg van inverz transzformáció is a stringre?
Debug módban is jön?
Ki kéne emelni csak ezt a konvertálás dolgot, és izoláltan megnézni, hogy erre a bizonyos kakukktojásra mennyire determinisztikus a konvertálás.
Még esetleg olyat próbálnék meg, hogy a bejövő 8 bites stringet feltuningolnám kicsit, elé-mögé dobnák néhány fix karaktert, esetleg minden karaktere után bedobnék még egy szóközt, hátha abból látszik, hogy hol történik memória korrupció. -
mgoogyi
senior tag
Effective C++ könyv. Ha azt végigrágod és nagyrészt érted is, akkor jók az esélyeid az interjún.
Aminek ezen felül utánanézhetsz: stl, desing patterns, esetleg ha marad időd, akkor szálkezelés, szinkronizációs primitívek. A többi lényeges dolog szerintem benne van a könyvben. -
mgoogyi
senior tag
válasz jattila48 #3599 üzenetére
Vektorban ismétléseket keresni nem annyira hatékony. Vagy arra alapozol, hogy úgyis alacsony lesz az elemszám egy adott scope-ra?
Alapból nem tűnik jó ötletnek vektorba berakni egy csomó castolni való cuccot.Valszeg többet kellene tudnunk, hogy érdemben hozzá tudjunk szólni a témához.
Jó lenne tudni, hogy mikor mire használod a vektort, mikor van beszúrás, keresés, törlés, stb.
Az objektumok feldolgozása soros módon történik? Teszem azt be lehet rakni mindezt egy process nevű virtuális függvénybe, ami specifikus minden altípusra? -
mgoogyi
senior tag
válasz jattila48 #3602 üzenetére
Tudom mi a szimbólumtábla, viszont nem tudom, hogy mi történik pontosan a "tárolt attribútumai szerint folytatni a fordítást" során. Különböző külső függőségei vannak a különböző objektumoknak a további feldolgozás szempontjából? Még mindig az van a fejemben, hogy minden objektumra lehetne egy Process-t hívni, ami kezelné az adott objektumot a típusának megfelelően, ami kaphat egy olyan külső függőséget, amin keresztül mindent megkaphat, amire esetleg szüksége van, vagy esetleg vmi callback-et. Ha viszont teljesen heterogén és abszolút összegyezhetetlen dolgok vannak, akkor nincs ötletem.
-
mgoogyi
senior tag
válasz jattila48 #3610 üzenetére
Lehetséges, hogy nem tudom..
Nem az, amit leírtál? Egy tábla, ami tárolja a lefordítandó kód szimbólumait, mint változó, függvény, stb. és arra használod pl., hogy ellenőrizd, hogy az adott objektumra az adott scopeban lehet e egyáltalán hivatkozni.
A process kapcsán arra gondoltam, hogy valami gépi vagy köztes kódot generálsz, mikor mész a következő sorra a kódban és találkozol pl. egy szimbólumon végzett művelettel.
És elnézést, hogy beledumáltam (inkább ne tettem volna), nem vágom, hogy működnek a fordítóprogramok. -
mgoogyi
senior tag
válasz EQMontoya #3613 üzenetére
Értem mire gondolsz, de ez csak a pointerekre vonatkozó cache miss.
Az objektumok kapcsán annyi cache miss lesz, ahányat feleslegesen megnézünk, azaz set esetén O(log(N)), vektor esetén meg O(N).Ha csak a pointert elég használni a komparálásra, akkor teljesen igazad van, de nem látom, hogy ez milyen esetben van.
A fordító csak a szimbolúm nevét látja, nem?A kis elemszámra hol van algoritmikus overheadje a set-nek pointeren keresztüli elemkeresésnél?
(Mondjuk ez tök mellékes, mert úgyis elhanyagolható.)[ Szerkesztve ]
-
mgoogyi
senior tag
válasz Hunmugli #3797 üzenetére
"Baloldalt egy char van, jobboldalt egy bit, ez nem fog menni".
A char egy 8 bites szám és jobb oldalt nem bit van, hanem egy másik 8 bites szám, aminek jellemzően egy adott bitje tér el a többitől. Innentől pedig az alap bitműveletek kellenek (és,vagy,xor,negálás)
Amit csinálsz, azt szokták flageknek hívni, minden bitnek megvan a saját jelentése.Nem kell túlgondolni az elképzelést:
1101 & 0010 = 0000 (bit ellenőrzés)
1101 | 0010 = 1111 (bit beállítás)Gyakorold valamennyit papíron, lehet az segít abban, hogy lásd, hogy melyik művelet mire jó.
Pl. 1-es bittel éselés az adott bit értékét fogja kiköpni, 0-ással(1011) az adott bitet állítod garantáltan nullára.A flagekre visszatérve: ilyesmit szoktak csinálni, hogy:
Option1 = 1 (001)
Option2 = 2 (010)
Option3 = 4 (100)Options = 101 esetén az option 1 és 3 van bekapcsolva.
Bár lehet, hogy te pontosan erre akarod használni."C bitjei balról jobbra vannak számozva, 0tól kezdődően 7ig. Function szerűen kéne"
Szerintem jobbról balra számozd a biteket, akkor a természetes bitsorrendet kapod és a 001 = 1-et jelent majd decimálisan, az 100 meg 4-et pl.
A 0-ás indexű bit a 2^0-át jelenti, az 1-es a 2^1, stb.stb.Ha kérdésed van bitekkel kapcsolatban, akkor kérdezz(akár privátban is rámírhatsz), ezzel relatíve sok gyakorlatom van.
-
mgoogyi
senior tag
Debug módban indítva breakpointoknál meg tudod fogni a progi futását. Katt a sor elé és megjelenik egy piros pötty. Ha megállt a breakpointnál: F5 hagyja továbbfutni a progit, F10 egy sort lép, F11 belelép a hívandó függvénybe. Amikor áll a cucc, meg tudod nézni a változók értékét is. Próbálkozz, menni fog.
-
mgoogyi
senior tag
válasz nonsen5e #3826 üzenetére
Tudsz feltenni netre egy problémás minimál csomagot?
A leírásodból halvány fingom sincs, hogy mi lehet gond + nem tudok róla, hogy a .h és .hpp fileok között bármi különbség kéne legyen a kiterjesztésen kívül."rögtön különböző hibákra hivatkozik"
Konkrétan?"operator<< multiple deklarációra hivatkozik"
nem include-olod duplán ugyanazt véletlenül? (akár közvetetten is) -
mgoogyi
senior tag
Ha csinálsz szándékosan egy szintaktikai hibát, akkor minden sorra igaz ez a sorszám tévedés?
Hátha ki lehetne találni, hogy melyik sortól hülyül meg a sorszám.
(Az első gondolatom vmi rejtett karakter a kódban, amitől valamiért meghülyül a fordídtó.)Meglehetősen ezoterikus hibának látszik.
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!