- 65 órányi zenét ígér az Audio-Technica új TWS fülese
- Yettel topik
- Samsung Galaxy Watch7 - kötelező kör
- iPhone topik
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
- Samsung Galaxy A53 5G - kevesebbet többért
- Sony Xperia 1 V - kizárólag igényeseknek
- Milyen okostelefont vegyek?
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Fotók, videók mobillal
Új hozzászólás Aktív témák
-
Hannibhál
őstag
válasz
ToMmY_hun
#3750
üzenetére
Azt a stroupasos könyvet kezdtem el én is de tényleg elég nehéz, viszont ha nekem úgy mond elég a 2d meg alap számítások(excelbe már csináltam hozzá pár dolgot, hogy kicsit automatizáljam) igazából a 2d-s grafikus felület hiányzik(térkép, kezelőfelület) a játék pedig a civilizationra hasonlít kicsit
-
Hannibhál
őstag
válasz
ToMmY_hun
#3747
üzenetére
van egy nagyon régi álmom miszerint az általam kreált stratégiai játékot csinálnám meg pc-re(eddig papíron ment). sima kis négyzethálós game lenne amit eddig pl papíron is lehetett csak mindent nekem számolni, meg rajzolni....ai nem lenne s egyszer valamelyik ismerősöm ezt javasolta. de ha van jobb alternatíva akkor hallgatom
-
EQMontoya
veterán
válasz
ToMmY_hun
#3567
üzenetére
A "const" csak a változó állandó értékéért felel, míg a "static" azért, hogy csak egy példány jöjjön létre?
Pontosan.
Ha const tagja van, az az jelenti, hogy csak konstruktorban kaphat értéket, de több példánynak lehet különböző értékű ilyen tagja.
Ha static, akkor minden példány ugyanazt az egyet példányt látja az adott tagváltozóból, ami kvázi a program indulásánál kap értéket. -
dobragab
addikt
válasz
ToMmY_hun
#3496
üzenetére
Ez C++-ban is egy erős elv, előadáson a kolléga még el is mondta, hogy nem hívunk konstruktorban / destruktorban virtuális függvényt, vagy le fogják törni a kezed. Utána belerakja ezt a ZH-ba, én meg javíthatom. Komolyan, legszívesebben annak is megadtam volna a pontot, aki B::f-et írt.
(#3492) sztanozs
A genyaság nincs még kimaxolva, szerintem sosem lehet kimaxolni. Még facsarhatjuk belőle a sz@rt kicsit.
(#3489) ToMmY_hun
Konstruálás során ugye először az ősosztály példányosodik, és mivel az említett kódban annak a példányosítása során hívunk egy virtuális függvényt, ezért nem futhat le olyan objektumhoz tartozó definíciója, ami a hívás pillanatában nem is létezik.
Ez a C++ megoldása a problémára, úgy definiálták a szabványban, hogy ilyen ne történhessen. Történhet viszont rosszabb.
Minden konstruktor csak saját magáért felelős. Így az ősosztályok konstruktorát hívja (+ virtuális örökléses blablabla), majd beállítja a vptr-t a sajátjára, aztán meghívja a tagváltozók konstruktorát, majd lefut a törzs. Fikarcnyit sem foglalkozik azzal, hogy mi van alatta. Nem tud róla, ki származik le belőle. És mivel a vptr-t is majd ezek után állítja csak be a leszármazott a saját vptr-ére, a konstruktorban a vptr még nem a leszármazottéra mutat, hanem a sajátra.
Egyébként a szabványban nincs benne sehol a vtable / vptr, nincs rögzítve, hogy úgy kell implementálni, de úgy érdemes. Sőt, a szabvány úgy lett kialakítva, ahogy a vtable-ös megoldások működnek.
A szabványban volt még egy sor, amit nem részleteztetek. A tagváltozók konstruktorában is az a fv. fog hívódni, ami a hierarchiában "nincs lejjebb", azaz a saját vagy "feljebb" van.
Ha a konstruktorban hívott f tisztán virtuális, akkor nem fog fordulni, mert a linker nem találja meg a függvényt. Tisztán virtuális függvény lehet definiálva is, ez most mellékszál. Itt nem kell a vtable-höz nyúlni, mert nyilvánvaló, melyik típusnak a függvényét kell hívni. Ha viszont nem maga hívja meg, hanem közvetve egy olyan függvény, ami nem tudja, pontosan milyen típust is kapott, akkor muszáj lesz a vtable-ben megnéznie. Akár tagváltozó konstruktorában is, mint írtam. Tadamm, így lehet tisztán virtuális függvényt meghívni.
#include <iostream>
class A;
struct member
{
A * a;
member(A* a);
};
struct A
{
member m = this;
A() { }
virtual void f() = 0;
virtual ~A() {}
};
member::member(A * a) : a(a)
{
a->f();
}
struct B : public A
{
void f() { std::cout << "B::f\n";}
};
int main()
{
B b;
return 0;
} -
-
dobragab
addikt
válasz
ToMmY_hun
#3424
üzenetére
A feladat első ránézésre nem tűnik elvetemültnek, de valahogy nem értem minden részletét.
Mátrixban kellene tárolnom trigonometrikus függvényeket, úgy, hogy ezek a függvényeket tartalmazó mátrixok egymással szorozhatóak legyenek.
Mit értesz két ilyen mátrix szorzatán? Ugyanúgy számolnád, ahogy rendes számokkal? Akkor mit jelent két ilyen függvény összege ill szorzata?
A függvények a következő alakot ölthetik: x * sin(y)
Itt x és y változók, vagy paraméterek?
-
-
jattila48
aktív tag
-
doc
nagyúr
válasz
ToMmY_hun
#3305
üzenetére
mert C++-ban NEM lehet olyat hogy "készítesz egy szimpla változót, és azt éred el cím alapján", ugye?
az egyetem meg megint mas kerdes, szerintem nem azert iratkozik be valaki egyetemre hogy megtanulhasson (5+ ev alatt) C++-ban programozni. Ott teljesen mas a cel, igy nyilvan mas a bejarando ut is.
-
dabadab
titán
válasz
ToMmY_hun
#3293
üzenetére
"C-vel kezdtem és sokkal könnyebb, mint C++-ban programozni. Alapozni nagyon ideális."
Meg arra is, hogy rossz szokásokat vegyél fel, szoktam azzal baszogatni a kollégákat, hogy amit írnak, az C, nem C++, szóval az így nem lesz jó
Pointereket meg hasonló alacsonyszintű dolgokat szerintem assemblerben sokkal jobban meg lehet tanulni
Az eredeti kérdéshez sajnos érdemben nem tudok hozzászólni, a kézenfekvő válasz a Stroustrup-féle C++ aktuális kiadása lenne, de azt is csak a polcon van meg, valahogy soha nem jutottam el odáig, hogy el is olvassam.
-
doc
nagyúr
válasz
ToMmY_hun
#3298
üzenetére
mennyivel nehezebb a pointer fogalmat megerteni C++ tanulas kozben mint C tanulas kozben? nyilvan semmivel, pontosan ugyanarrol van szo mindket esetben
valamiert meg vagytok gyozodve arrol hogy aki C++ -t tanul az nem tanul tombokrol meg pointerekrol, mig aki C-t tanul az igen, holott mindket esetben ugyanugy, es ugyanott resze az ismeretanyagnakA kulonbseg hogy amikor eloszor irsz egy tombelemeket ciklusban kiiro kodot akkor nem mondjuk printf("%d\n", arr[i]) hanem cout << arr[i] << endl lesz a kod. A lenyeg, vagyis a ciklus pont ugyanaz lesz mindket esetben.
Amikor pointerekrol tanulsz, akkor meg plane ugyanaz lesz, ugyanugy kell dereferalni mindket esetben, ugyanugy kell megerteni hogy hogyan 'mutat' a pointer a mogotte levo adatra.
Amikor mar benne vagy a surujeben akkor a C++ mar nyilvan bonyolultabb lesz, de ott meg pont nem segit semmit ha a C-specifikus dolgokat tudod (sot, csabit a durva ganyolasra C-s modszerek hasznalataval, lattam mar ilyet...)
-
doc
nagyúr
válasz
ToMmY_hun
#3293
üzenetére
Az OOP valoban tok mas gondolkodasmod, mar csak ezert sem tartom jo otletnek csak azert C-t tanulni hogy utana C++-ozz. A C megtanit egy adott, strukturalt modon gondolkodni amit az OOP-nal kb. dobhatsz is ki, mert teljesen mas a megkozelites.
En is C-vel kezdtem, es C++-ra valtva nagyon sokaig gyakorlatilag C-ben progamoztam C++ szintaktikaval
Nehez volt atszokni az OOP-re, nagyon visszahuztak a C-s szokasok.Abban megintcsak egyetertek hogy ha a cel egy barmilyen OOP nyelv akkor a C++ elsore nem egy jo valasztas.
-
-
dobragab
addikt
válasz
ToMmY_hun
#3265
üzenetére
Mingw-gcc frankón bánik a threadekkel, hiszen betartja a szabványt: és a C++11 szabványban minden van, ami a multithreading-hez kell.
(#3263) jattila48
VS2015 mint IDE zseniális, ha lehetne mingw-vel használni, tökéletes lenne, de tök más a fordító paraméterezése, max. Intel compilerre tudnám cserélni. Az MSVC meg kritikán aluli.
C++ fordítója is a legjobbak között lehet, bár nem mindig tartja be a szabványt.
Remek, ezzel a legfontosabb kritériumot bukta. Azóta nem voltam hajlandó használni, amikor egyszer C-ben egy három paraméterrel előre deklarált függvényt egyetlen paraméterrel hívtam, és lefordult
Adott warningot, de akkor is, ez mi? 
-
jattila48
aktív tag
válasz
ToMmY_hun
#3261
üzenetére
"Egyébként minden egyszerűbb rajta, szóval C++ fejlesztéshez ideálisabb, mint a Microsoft kacatjai"
Ebben engedd meg, hogy vitatkozzak veled! A Microsoft VS kifejezetten jó IDE környezet, stabilitásban, használhatóságban nincs Linux megfelelője (szerintem!). A C++ fordítója is a legjobbak között lehet, bár nem mindig tartja be a szabványt. Generált kód minőségét (sebesség, méret, szabvány megfelelés) pedig a gcc-ét nem múlja felül egyik általam ismert fordító sem.
-
jattila48
aktív tag
válasz
ToMmY_hun
#3258
üzenetére
Biztos van könnyen kezelhető könyvtár is, de sajnos van aminek az installálásától is lesz néhány ősz hajszálad. A boost-ot pl. azzal az adott fordítóval komplett buildelni kell, amivel majd használni fogod (több óra). Buildelés során hol ezt, hol azt nem talál, az SDK verzió nem jó, stb. Ha esetleg előre buildelt változatot használsz, akkor nem fog működni más verziójú fordítóval, a lefordított kód fut windows7-en de nem fut XP-n, könyvtárak és object fájlok verziói nem stimmelnek, nem lehet statikusan a programhoz linkelni, stb. Aztán jön a dependency walker, meg a szarakodás, hogy mégis mi a fene baja van. protocol buffer hasonló, kicsiben. De az OpenSSL-ből sem szokott jó lenni az előre buildelt. Amikor könyvtárat használsz (főleg template könyvtárat mint a boost), akkor erre is fel kell készülni.
-
jattila48
aktív tag
válasz
ToMmY_hun
#3255
üzenetére
Végül is, te tudod... A tapasztalatom az, hogy sokszor érdemes az egyszerű problémát egyszerűen megoldani. Ha saját megoldást dolgozol ki, akkor mélyebben megérted a dolgok működését, és később jobban fogod látni, hogy a könyvtári megoldásoknak mik az előnyei, hátrányai, és érdemes-e alkalmazni egyáltalán. Másrészt ezeknek a kész könyvtáraknak az installálása, használatának megtanulása sokszor több időt/energiát emészt fel, mint ha megírod saját magad a kis problémádat megoldó kódot. Persze ha már ismered, akkor más a helyzet. Én pl. a boost-ról (de kicsit a protocol bufferről is) gondolom, hogy jó-jó, de amire használtam (asio) arra túl sok energiát pazaroltam el miatta. Ezek a könyvtárak (a boost főleg) sokszor erősen "túldizájnoltak" és marha nagyok. Belekényszerítenek egy olyan keretbe, ami nem feltétlenül jó az adott feladatra, és ez rengeteg plusz munkát jelent. (ez most nem flame akart lenni, pusztán vélemény!)
-
jattila48
aktív tag
válasz
ToMmY_hun
#3247
üzenetére
Hát, én nem tudom, mi az a ZeroMQ, thrift, meg avro (őszintén szólva nem is nagyon érdekel), de könnyen lehet, hogy a te problémádra ez az ágyúval lövöldözés verébre esete. Nem kell megijedni a TCP socket-ektől, semmilyen külön library nem kell hozzá, simán a BSD (POSIX) socket API-t kell használni, nem bonyolult. Az átküldendő objektumot persze előbb szerializálni kell. Ezt magad is megteheted, azért általában ez sem annyira bonyolult. C++-ban (tudtommal) nincs külön könyvtár a szerializálásra, ezért ha esetleg nem magad csinálod, akkor a google protocol buffer jó lehet. Ez C++ kódot generál, amit a programodba beépíthetsz. Python oldalon nem tudom, hogy van-e protocol buffer. Sajnos nem túl egyszerű telepíteni, és a generált kód sem túl optimális, ezért én a helyedben saját megoldással próbálkoznék.
Az SNMP nem tudom, hogy merült fel, szerintem az tök másra való. -
-
Karma
félisten
válasz
ToMmY_hun
#3243
üzenetére
Miért pont socketek? Mi lesz a socketek állapotgépével, a hibakezeléssel?
Miért törnél arra, hogy újra feltaláld a kereket?Van rengeteg protokoll, amit mások már implementációval együtt kidolgoztak neked.
Ott az MQTT, ami elég karcsú beágyazott rendszereknek is. Az óvilág szabványaiból ott az SNMP. Vagy ott a Protocol Buffers, a Thrift és az Avro, amikkel hatékonyabb és strukturált kommunikációt írhatsz. De ha az overhead nem számít, Pythonban egy sorral tudsz HTTP szervert írni, amit a másik oldalad egyébként bejáratott eszközökkel és egyszerűen hívogathat...Ebben semmi C++ specifikus nincs, nem véletlenül tettem OFF-ba a hozzászólásom. A megközelítésed a Java világban is öngyilkosság.
-
dobragab
addikt
válasz
ToMmY_hun
#3235
üzenetére
Az enyémben ugye ellenőrizni kell, hogy rendelkezésre áll-e az ID, és ez a lista egy sima vector-ban van tárolva, amiben iterálva keresek.
Gyorsabb lenne a különálló map-ekben keresni, mint egy vector-t lineárisan végignyalni. Ha már mindenáron önálló nyilvántartást vezetsz róluk, arra az std::set való.
Trükkös a map és a set, contains függvényük nincs, illetve van, de count-nak hívják.
-
jattila48
aktív tag
válasz
ToMmY_hun
#3229
üzenetére
És ezt az ID-et miért nem az adott konténer példány azonosítójából, és az elem kulcsából generálod (tulajdonképpen (konténer_ID,elem_kulcs) pár valamilyen kódolásban)? Ez egyértelműen azonosítaná az adott elemet, és nem kéne, hogy a kulcs az összes konténerre vonatkozóan egyedi legyen. Ezt a generált ID-et küldhetnéd aztán át a hálózaton, hogy kiválaszd a megfelelő szkriptet. Nem tudom, jól értettem-e.
-
jattila48
aktív tag
válasz
ToMmY_hun
#3225
üzenetére
"Szükség lesz egy STL tárolót burkoló osztályra, mert szeretném megoldani hogy az összes konténerben egy kulcs csak egyetlen egyszer szerepelhessen, biztonsági okokból"
Ez miért, és hogyan? Amikor kiválasztod, hogy melyik tároló objektum milyen kulcsú elemét használod, az már egyértelműen azonosítja a kiválasztott elemet az összes konténer tekintetében. Miért kéne, hogy két különböző konténer objektumban ne lehessen azonos kulcsú elem (ha jól értem, ezt szeretnéd elérni)? Lehet, hogy "véletlenül" más tárolót jelölsz ki, mint amit akartál? Nem értem.
"Ezt manuálisan overloadolnom kell saját osztály esetén?"
Nem overloadolni, hanem megvalósítani.
-
dobragab
addikt
válasz
ToMmY_hun
#3223
üzenetére
Jó irányba tapogatózol, a template a megoldás. Amit te keresel, az az std::vector. Mindent tud, ami neked valaha kelleni fog dinamikus tömb szintjén. Egyrészt tud automatikusan megnyúlni (push_back), viszont előre is le tudja foglalni a memóriát, és nem kell nyújtózkodnia, ha konstruktorparaméterként adod neki a darabszámot, vagy reserve-ölsz. Természetesen ezután is tud megnyúlni.
Túl jávásan gondolkozol. Egyrészt teljesen felesleges nekik ősosztály, anélkül is lehet különböző típusokat megetetni egy generikus algoritmussal: erre való a template. Másrészt a get helyett C++-ban illik indexelő operátort használni.
std::vector<int> vec(100); // 100 darab helyet lefoglal előre,
// de nem tölti fel, egy darab int sem kerül bele
vec.push_back(1); // belekerült az első elem
for(int i = 0; i < vec.size(); ++i)
std::cout << vec[i];Egy generikus algoritmus lényege a duck typing: minden, ami úszik, és hápog, az kacsa. Másképp: az alábbi algoritmus bármilyen típust tartalmazó vector-ral működni tud, aminek van rendes (std::ostream-et visszaadó) << operátora. Ha te ezt meghívod std::vector<int>-ekre, akkor a fordító fordítási időben legenerálja neked a print<int>-et, mert az int úszik és hápog (van << operátora).
template<typename T>
void print(std::vector<T> const& vec)
{
std::cout << vec(i) << ' ';
} -
jattila48
aktív tag
válasz
ToMmY_hun
#3221
üzenetére
Lehet, hogy nekem nehéz a felfogásom, de a magam részéről nem értem mit szeretnél.
"Van néhány egymáshoz nagyon hasonló osztályom, amelyek különböző típusú objektumokat tárolnak."
Tehát ezek az osztályok konténerek? Egy konténeren belül lehet egymáshoz képest különböző típusú objektumokat tárolni, vagy egy konténer egy adott típusú objektumok tárolására alkalmas?
"minden ilyen osztály rendelkezzen előre deklarált metódusokkal, amelyek osztályonként különböző típusú objektummal térnek vissza vagy végeznek rajtuk műveletet"
Mármint az adott metódust (c++ -ban tagfüggvény) tartalmazó osztályonként..., vagy paraméterben kapott objektum típusától függően térnek vissza...?
Ha konténerről van szó, akkor ezt mint template-et akarod a tartalmazott objektumok típusával paraméterezni? Miért akarsz leszármaztatni? A leszármazott osztály valamely objektumára mutató pointert (referenciát) ősosztály típusúként akarod használni?
Egy kicsit konkrétabban, és részletesebben írd le mit szeretnél, akkor talán tudunk segíteni.
-
dobragab
addikt
válasz
ToMmY_hun
#3210
üzenetére
Van mód arra, hogy ne a default-ot hívja meg a leszármazott, mégpedig inicializáló listán. A "setter" ctort akár protected-be is teheted.
class Parent
{
int id;
protected:
Parent(int id) :
id(id)
{ }
public:
Parent() {}
};
class Child : public Parent
{
public:
Child() :
Parent(0)
{ }
}; -
EQMontoya
veterán
válasz
ToMmY_hun
#3050
üzenetére
Végezhető munka mellett, de szerintem nem ad annyi hasznos tudást, amennyi szopás van vele.
Főleg, hogy BME-n pl. csak nappalin van, OE-n meg van esti, de sajna eléggé gittegylet.
Ráadásul az értelmes tárgyak leginkább szabadon választhatók, amikkel nem fogsz foglalkozni, ha meló mellett végzed.Szóval én nem vágnék bele.
-
jattila48
aktív tag
válasz
ToMmY_hun
#2926
üzenetére
Itt teljesen mindegy, hogy pre vagy post inkrementálást használsz. Alaptípusoknál (POD) nincs sebességbeli különbség. Általad definiált típusok esetén viszont valóban lassabb a post inkrementálás:
MyClass &operator++(){
//elvegzed a pre inkrementalashoz szukseges muveleteket
return *this; //hivatkozas szerinti visszaadas
}
MyClass operator++(int){
//post inkrementalas. Az int parameter csak ennek a jelzese, nem hasznalt.
MyClass tmp(*this); //temporalis objektumot hozunk letre
operator++(); //ez a pre inkrementalas az aktualis objektumon
return tmp; // a nem inkrementalt temporalist adjuk vissza ertek szerint
}Amint látod, minimum egy copy ctor hívással (és plusz egy fv. hívással) több a post inkrementálás. Hogy ez van-e kétszer annyi idő, vagy nincs, az az inkrementálás műveletigényétől függ.
-
LordX
veterán
-
ToMmY_hun
senior tag
válasz
ToMmY_hun
#2890
üzenetére
Biztosan a compiler különbözőség miatt jelentkezik a probléma. A Qt fórumon találtam egy topicot, ahol ugyanúgy definíció hiányra panaszkodott a mingw és a megoldás az azonos compiler használata volt. Sajna a Qt 5.5 (jelenlegi verzió) nem támogatja a VS 2015 C++ compilert, szóval a lehetőségek eléggé korlátozottak. Jó hír, hogy decemberben jön az új Qt (5.6) ami már elvileg kompatibilis lesz vele.
[bocsánat a duplázásért]
-
LordX
veterán
válasz
ToMmY_hun
#2887
üzenetére
Mégis csak linker hiba lesz (milyen linker mondja meg sorra pontosan, hogy mi hiányzik?) - úgy tűnik nincs bent a lib-ben a függvény. Nézd meg így a lib-et, hogy benne van (most nincs megfelelő tool a gépemen), és ha nincs, akkor annak a buildelésénél kell körülnézned.
-
LordX
veterán
válasz
ToMmY_hun
#2884
üzenetére
Ha a fordító adja a hibaüzenetet, akkor mindegy hogy mi a lib, hol van, mivel fordítottad, mert el se jut odáig, hogy az probléma legyen. Vagy nem jó az include, vagy a deklaráció a headerben, vagy a használat. Namespace-eket, paraméter típusokat ellenőrizd, hogy nincs-e valami elgépelve, esetleg ellenőrizd, hogy tényleg jó headert próbálsz behúzni. (Utóbbihoz tipp: a deklaráció mellé tegyél egy #error BLAH direktívát, ha megkapod hibaként, akkor jó. Ha nem, akkor valami más van include-olva.)
-
LordX
veterán
válasz
ToMmY_hun
#2882
üzenetére
A fordítási hibának semmi köze nincs a libekhez; azok max a linkernél tudnak hibát okozni.
Normális angolul van a hibaüzenet, nem kell tőle félni
: nincs definiálva a RoboticArm::ArmRunner::getInstance() függvény. Gondolom ez a librarynek egy függvénye, tehát kellene legyen hozzá egy header (RoboticArm.h?), ami tartalmazza a library publikus felületét ( függvények, osztályok, típusok), és be kell #include-olnod. -
jattila48
aktív tag
válasz
ToMmY_hun
#2867
üzenetére
Nem igazán értem mit szeretnél, de tartok tőle, hogy túlbonyolítod. Ha TCP listen socket-ről van szó, akkor a főprogramban listen-el, majd az accept-ált connected socket-tel új thread-et indítasz. Minden kapcsolathoz külön thread-et, tehát nem 1 vagy 2 thread-ed lesz, hanem annyi, amennyi kapcsolatot fogadsz (természetesen ezek dolguk végeztével (pl. a kliens lezárja a kapcsolatot) "elhalnak"). Az új thread-nek paraméterként csak a konnektált socket-re lesz szüksége, amit void *-ra castolva a CreateThread-nek átadsz.
Te valamiféle callback függvényt akarsz így member function pointerrel csinálni? Ez egyfajta delegate lenne? Miért csak 1 thread-et akarsz indítani? -
EQMontoya
veterán
válasz
ToMmY_hun
#2865
üzenetére
class A {
public:
int f();
int (A::*x)(); // <- declare by saying what class it is a pointer to
};
int A::f() {
return 1;
}
int main() {
A a;
a.x = &A::f; // use the :: syntax
printf("%d\n",(a.*a.x)()); // use together with an object of its class
}Ugyanakkor muszáj felhívom a figyelmed, hogy ha ilyet akarsz csinálni, akkor valamit nagyon elb@sztál a tervezésnél, vagy nagyon nem ismersz valami olyan patternt, amivel kiváltható lenne ez a működés. Látatlanban nem tudom, hogy pontosan mi lehet szükséged, de a visitort, decoratort, nézd meg.
-
Whysperer
addikt
válasz
ToMmY_hun
#2862
üzenetére
Koszi az oldalt. Ezt kerestem...pont ilyesmi miatt irtam ide. Nem azert hogy Ti irjatpk meg... Ifen szamoltam egy eves munkankat fel evre redukalna es igy izon simulaciora is volna ido es kapacotas... Egy evrol fel evre csokkenes.... Eleg a fejlesztesre valo indokra. Mondom nem olyan embert keresek.. Aki ejjel nappal dolgozva megirja (bar ez sem kizart) hanem aki szakmailag tudok vele ertekezni errol.
Koszonom az utmitatast.
-
Whysperer
addikt
válasz
ToMmY_hun
#2860
üzenetére
Assasin Creed Cinematic-ok, Desitiny és hasonló volumenü cinematico-kat gyártunk. Válaszolva a kérdésedre. Igen érdmes mert a ruha szimulációk sebességét felgyorsítaná. Sokszorosára. Ami nem mindegy. Föleg amikor 20-30 perc alatt megy le és utánna meg,ha valami nem jó akkor finom hangolni és megint elidíntani. Azután megint ha megfelelő és van 200 más és más szituáció nagyon sok beállítással. Maya Ncloth sajnos ilyen macerás.. minden ruha máshogy reagál más jelenetben más poligon számmal más környezeti hatással már animációval. Szóval nincs sablon.
Szóval igen szükséges és és érdemes.Mivel. Mert az Animációs csapat is tudna részesülni a dologból.
"fórumos igazolás" nem elegendő csak hátha iylen topicba kaptam volan ötletet.. Most várjuk a forráskódot Nvidia developmentől és a Maya supporttól. Találtam több müködő refferencia munkát. Ezekre várom a emaileket.
-
LordX
veterán
válasz
ToMmY_hun
#2787
üzenetére
Ha előre tudod a szükséges típust, és csak egyféle kell egy adott helyen, akkor minek tárolod őket egy közös mapban?
Külön map az Effector-nak, Joint-nak, stb, a "factory" (off: én nem hívnám factorynak, mert a factory nem tulajdonosa a legyártás után az objektumnak, ez inkább valami storage) meg a típus alapján template:
Storage<Effector> effectors;
Storage<Joint> joints;
effectors.create("effector1", 1);
joints.create("joint1", 2.0, true);
auto &x = effectors.get("effector1");
auto &y = joints.get("joint1");Teljes kód itt: [link]
Ja, én nem szeretem a naked mutatókat; smart pointer, observing pointer objektum (asszem jön egy standard C++17-el) vagy referencia, különben nem egyértelmű, ki destruálja az objektumot, ha már nem kell.
-
-
EQMontoya
veterán
válasz
ToMmY_hun
#2784
üzenetére
RapidXML-t próbáltam, de nem kezeli a string objektumot, csak karaktertömböt, abból meg nem kérek ha nem muszáj.
A a void* azért lenne jobb, mert később még szeretném kiegészíteni a factory-t más osztályokkal is. Emvy kolléga jól látja, a Part-ból származtatott osztályok különböző tagváltozókkal, metódusokkal rendelkeznek, így a sima Part pointer visszatérés még nem elég.
A factory miért nem template class?
Az pedig, hogy a partban nincs megfelelő infó ennek eldöntésére, tervezési hiba.Ha PartSubC mellett lesz egy PatrSubD, ami szintjén jó Neked, akkor 2x fogsz castolni, és még pár módosítás múlva láncolt listát bejáva fogsz castolni (
), vagy lesz egy PartSubVirtualCD osztály, amiből leszármazik mindkettő, tehát az objektumstruktúrádat b@szod szét fölöslegesen? -
válasz
ToMmY_hun
#2777
üzenetére
Egyreszt, void * helyett visszaterhetnel Part *-al is.
Ez a szokasos ko/kontravariancia problema. Ha a maped Part*-okat tartalmaz, es forditasi idoben nem tudod leszukiteni a potencialisan tartalmazott leszarmazottak tipusat, akkor nincs mese, futasideju ellenorzest kell valahol csinalni. Ezt sok ponton meg tudod oldani, de a vege tuti az lesz, hogy valahol ellenorizned kell azt, hogy az adott sztring kulcshoz tartozo ojjektum megfelelo tipusu-e.
Erre a dynamic_cast egy lehetseges megoldas, de akar tarolhatod a mapban is a tipusinformaciot, ahogy jolesik.
-
LordX
veterán
válasz
ToMmY_hun
#2768
üzenetére
Használd inkább a map::emplace függvényt, az pont arra van kitalálva, hogy új elemet hozz létre a konténerben:
PartCoordinates.emplace(std::piecewise_construct, std::forward_as_tuple("B"), std::forward_as_tuple(10.3f, 45, 456.0f, 54));
A te módszereddel készül egy temporális Matrix objektum, amiből (és a temporális std::string-ből) készítesz egy szintén temporális std::pair, amiből végül az insert move-construct-olja a konténerben a végleges eredményt. Ugyanez igaz az std::string-re is, 2 extra temporális jön létre a kódban. (Mondjuk ilyen kicsi stringek esetében mindegy, de ha nagyobb, mint az SSO méret, akkor meglepően gyenge lesz ennek a kódnak a sebessége.)
Amit én írtam, ott nincs semmilyen temporális objektum, minden forwardolva van. A szintaxis kicsit béna, mert valahogy meg kell különböztetni, hogy az egyébként 5 paraméter közül melyik a kulcs melyik az érték paramétere, de a többi konténerben csak simán felsorolod a konstruktor paramétereket:
std::vector<Matrix> foo;
foo.emplace_back(1,2,3,4); -
ToMmY_hun
senior tag
válasz
ToMmY_hun
#2767
üzenetére
Meg is válaszolnám a kérdésemet:
A map deklarációja:
std::map <std::string, Matrix>PartCoordinates;
Első körben a [] operátorral szerettem volna új elemet hozzáadni, az így nézett ki:
PartCoordinates["B"] = Matrix(10.3f, 45, 456.0f, 54)
Ebben az esetben szükség van mindkét elemnél a default konstruktorra, de mátrixnál nem szerettem volna ilyet alkalmazni. A map insert tagfüggvényét használva megoldható a dolog, így néz ki:
PartCoordinates.insert(std::pair<std::string, Matrix>(std::string("B"), Matrix(10.3f, 45, 456.0f, 54)));
Remélem segít valakinek.
-
jattila48
aktív tag
válasz
ToMmY_hun
#2739
üzenetére
Ha exceptiont dob a konstruktor, akkor nem jön létre az objektum (és így a destruktora sem fog meghívódni). A new lefoglalja a megfelelő tárhelyet, majd mikor a ctor exceptiont dob, fel is szabadítja azt. A factory függvényedben kell lekezelni az exceptiont, és NULL-t (vagy nullptr-t, vagy "üres" smart pointert) visszaadni, ha a konstruktor exceptiont dobott.
class MyClass{
....
};
MyClass * factory(int arg){
MyClass *p=NULL;
try{
p=new MyClass(arg);
}
catch(...){{
return p;
}Az egyszerűség kedvéért írtam raw pointer visszatérő értéket, igazából a factory fv.-nek inkább std::unique_ptr<MyClass> smart pointert célszerű visszaadni.
Egyébként a paraméter ellenőrzést már a factory fv.-ben is elvégezheted, de akkor csak ezzel célszerű objektumot létrehozni, ctor közvetlen hívásával nem, mert az nem ellenőrzi a paramétereket. Ezt úgy lehet elérni, hogy a ctor-t protected-dé teszed, a factory-t pedig az osztály friend-jévé, vagy statikus tfv.-évé.MyClass * factory(int arg){
if(arg>0){
return new(std::nothrow) MyClass(arg);
}
else{
return NULL;
}
} -
EQMontoya
veterán
válasz
ToMmY_hun
#2735
üzenetére
A feltételes példányosítás alatt pontosan mit értesz?
Különböző paraméterszámú konstruktorok: az egyik variácó, hogy vannak opcionális paraméterek. Ennek a sorrend miatt az a hátránya, hogy ha megadsz egy opcionálisat, akkor az összes előtte lévőt is meg kell adnod, nem kapják meg a default értéket. Illetve asszem, c++14-ben meg tudod oldani pythonos módon, tehát hogy minden paraméternek van default értéke, és név szerint adsz néhánynak.
A másik, hogy settereket írsz az extra paraméterekre, és egy konstruktorod van, de ez alapvetően béna.A factorydon meg nyilván annyi publikus függvény lesz, amennyiféle konstruktorod van, ezt szerintem semmilyen nyelven nem úszod meg.
bár nem pont így... Mire akartak felvenni?
Adott warningot, de akkor is, ez mi? 
Ú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!
- PS5 konzolod megvásároljuk: Budapest, Kecskemét, Szeged, Debrecen vagy akár GLS futárt küldünk!
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- HP 635 laptop eladó
- Eredeti Windows 10 / 11 Pro aktiválókulcs AZONNALI SZÁLLÍTÁSSAL!
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest