Új hozzászólás Aktív témák
-
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.
-
doc
nagyúr
válasz
EQMontoya
#3292
üzenetére
Mitol kene ebbe 'belezavarodni'?
Miert zavarodsz bele a pointerbe ha C++ tanulas soran talalkozol vele, es miert nem ha ugyanazt C-tanulas kozben tanulod meg?A referencia a pointerek utan nem egy nagy truvaj, a smart_ptr meg mar egy olyan feature ami C-ben nincs (tehat neked kell nullarol megcsinalni), C++ -ban meg keszen kapod. Raadasul az mar eleve nem kezdo anyag.
-
ToMmY_hun
senior tag
C-vel kezdtem és sokkal könnyebb, mint C++-ban programozni. Alapozni nagyon ideális. Szerintem maga az OOP programozás nem kezdő téma, legfőképp nem C++ segítségével. Én még kezdő C++ programozó se vagyok, van OOP és C tapasztaltom is, de még így is azt mondom, hogy nem egyszerű. Feltéve ha jól akar benne programozni, alibizni bármiben lehet. Amennyiben mindenképpen OOP a cél, akkor Javat javaslom, sokkal letisztultabb, kezdő számára ideálisabb. Ahhoz van jó könyv is, méghozzá az Agyhullám Java.
-
EQMontoya
veterán
Szerinted mi az amit kezdokent C-ben egyszerubb mint C++-ban? (foleg hogy a C++ az kb 99.9%-ban felulrol kompatibilis a C-vel)
Az, hogy C++-ban kb. minden olyannal foglalkozol, amivel C-ben, de ha C-vel kezdesz, akkor nem egyszerre fogsz belezavarodni a referenciákba, pointerekbe, smart_ptr-ekbe és az érték szerinti átadásba, hanem csak a felé kapod egyszerre az arcodba.
Továbbá nem fogsz kapásból belefutni mondjuk a vptr-be, hanem lesz már némi fogalmad a függvénypointerekről, el tudod képzelni, hogy hogyan is működik az egész. -
doc
nagyúr
válasz
EQMontoya
#3290
üzenetére
Amellett hogy nyilvan elfogadom hogy masnak az enyemtol eltero a velemenye, nem ertek egyet
A C nagyon keves es nagyon kenyelmetlenul hasznalhato eszkozt ad a programozonak. Nincsenek ertelmes adatszerkezetek, nullarol kell mindent megcsinalni. A stringkezeles gyalazatos, kb mindenre csak a legalacsonyabb szintu fuggvenyek leteznek, ha vannak egyaltalan.
A 'szemlelet' amit a C-s fuggvenyek adnak kenyelmetlen es idejetmult, a C++-hoz meg kb semmi koze sincs, igy ugrodeszkanak hasznalni csak akkor erdemes ha az ember eleve akar C-vel is foglalkozni.
Azok a feladatok amik C-ben egyszeruen megoldhatoak C++-ban sem bonyolultabbak vagy nehezebbek, forditva viszont egyaltalan nem biztos hogy igaz.
En szeretem mindket nyelvet es van ahol a C++ nem is alternativa, de altalanos nyelvkent a C++ sokkal konnyebben es jobban hasznalhato mint a C.
egy kezdonek a C sem egyszerubb
De.Szerinted mi az amit kezdokent C-ben egyszerubb mint C++-ban? (foleg hogy a C++ az kb 99.9%-ban felulrol kompatibilis a C-vel)
-
EQMontoya
veterán
-
#3289
Ereshkigal
őstag
g@bo
#3280
Ereshkigal
őstag
Ha megy az angol: http://www.stroustrup.com/Programming/
-
-
ToMmY_hun
senior tag
válasz
EQMontoya
#3269
üzenetére
Megnéztem, hogy NetBeans-ben milyen lehetőségek vannak.
Szimbólum keresés - Nem tudom pontosan mit értesz alatta, keresés projekten belül akármire lehetséges.
felhasználások megkeresése - Find Usages menü, kilistázza az egész projektben hogy hol van használva a keresett elem.
átnevezés egy gombbal - Refactor / Rename, kilistázza a találatokat és átnevezés előtt checkbox segítségével választható ki, hogy hol és mit szeretnél átnevezni.
autocomplete - Van, és nem csak kódkiegészítő, hanem a dokumentációt is mutatja.
beépített profiler - Ez sajnos nincs, legalábbis gyors keresés eredményeként ezt olvastam.
frankó debugger - Egy szálon futó programmal teszteltem, azzal minden fontosabb követelményt teljesített.
-
jattila48
aktív tag
válasz
dobragab
#3266
üzenetére
VS használható mingw-gcc-vel. Próbáld ki a VisualGDB-t. 30 napos teljes értékű próba verzió, utána fizetős (nem túl drága). Vannak még hibái, de egész jó. Az MSVC-nél én is találtam olyat amit le kellett volna fordítania, de mégsem tette (ezeket itt meg is tárgyaltuk). Amit "többet" tud mint a szabvány (microsoft extensions), arra adhat warning-ot, vagy hibát, vagy semmit (beállítható). Ilyen pl., hogy temporális értéket megenged nem const lvalue referenciához kötni (szabvány szerint csak const lvalue vagy rvalue referenciához lenne köthető).
-
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? 
-
ToMmY_hun
senior tag
válasz
jattila48
#3263
üzenetére
Használtam VS-t, és tényleg nem rossz - már amennyit én láttam belőle. Sajna olyat tapasztaltam, hogy corrupted lett egy bizonyos fájl (valami adatbázis) és emiatt nem engedte elmenteni az általam frissen létrehozott fájlokat.
Persze ez nem olyan vészes, letöröltem a fájlt, újragenerálta és rendbe is jött. Az IntelliSense és a debugger/profiler frankó.Java-hoz rengeteget használom a NetBeans-t és kipróbáltam C++-hoz is, azzal is ügyesen bánik. (Linuxon legalábbis, Win-en a compiler beállítással kínlódni kell). A fejlesztést sok eszközzel támogatja, amiket próbáltam és mennek: kódkiegészítés, debug, refaktorálás, library kezelés, CPP Unit test, Git addon (linuxon fontos). A profiler-re még kíváncsi vagyok, lesz olyan kódrész amit megnézek vele - feltéve ha van és működik.
MinGW gcc: thread-eket támogat? Ősszel próbálkoztam vele, és akkor azt olvastam hogy nem annyira, persze lehet hogy én voltam suta.
-
jattila48
aktív tag
válasz
dobragab
#3260
üzenetére
"Windows-ra fordításhoz ott a mingw-gcc cross"
A mingw-gcc valóban jó, de még kell rajta dolgozni. A Windows COM-mal pl. nagyon nem boldogul. A saját headereit sem mindig fordítja le. Különböző rejtélyes makrókat kell #define-olni (vagy preprocessor-nak definiálni), hogy rá vedd a fordításra. Több tízezer soros header-ek esetén ennek kiderítése igencsak strapás.
-
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
dobragab
#3260
üzenetére
Ez lehet, de ha speciel Windows-on kell vele dolgoznom, akkor nem vigasztal. Linux-on nem kell buildelni, nem függ a gcc verziójától, a lib-ek verziói is stimmelni fognak, vagy csak mindezt magától megoldja az apt-get? Azért Linuxon is szívtam én már hasonlóan (a boost-ot nem használtam).
-
ToMmY_hun
senior tag
válasz
jattila48
#3259
üzenetére
Most hogy mondod jönnek vissza az emlékek. Anno Win 10-en kezdtem el a fejlesztést, aztán amikor eljutottam a Qt használatáig, rá kellett jönnöm hogy szívás van. Le kellett volna fordítani az MSVC2015-tel az egész Qt-t, hogy tudjam használni a saját statikus könyvtáramat, vagy a saját kódot kellett volna lefordítani olyan fordítóval, amiből már van Qt bináris. Egyik megoldás sem lett volna egyszerű. Qt-re majd kíváncsi leszek, de átpártoltam Debian-ra, és ezen neki mernék állni a fordításának is.
Egyébként minden egyszerűbb rajta, szóval C++ fejlesztéshez ideálisabb, mint a Microsoft kacatjai. -
dobragab
addikt
válasz
jattila48
#3259
üzenetére
Ez nem a C++ libek telepítési nehézsége, hanem az összes Windows szegénységi bizonyítványa. Jól működő operációs rendszeren ennél kicsit egyszerűbb a dolog.
sudo apt-get install libboost-all-dev
A futtatáshoz szükséges binárisokat meg könnyebb beszerezni, akár Win, akár Linux, a Windows-ra fordításhoz ott a mingw-gcc cross.
-
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.
-
ToMmY_hun
senior tag
válasz
jattila48
#3257
üzenetére
Részben igazad van. Az tényleg nagyon hasznos, ha megírja az ember saját maga tanulási céllal az ilyen, és ehhez hasonló problémákat megoldó programokat. Ezt majd én is szeretném megtenni, csak egy kicsit kevésbé túlhajtott időszakban. Abban is igazad van, hogy a könyvtár használat sem mindig jó. Pár hete jártam úgy, hogy egy céges kódban kiváltottam egy 3rd party library-vel egy nagyobb kódrészletet. Teljesen jól szuperált, örültünk is neki, aztán rá egy hétre hozzá akartunk adni egy új feature-t, amit viszont nem lehetett megoldani azzal a library-vel. A vége az lett, hogy vissza kellett hozni a kigyomlált saját kódot. Van ilyen is, főleg akkor, ha nincs fix specifikáció.
Azzal viszont nem értek egyet, hogy nehéz telepíteni/megtanulni őket. Az installálás nem volt vészes eddig egyik könyvtárnál sem. (Egyébként ez iszonyat jól meg van oldva Java-ban, ha érdekel nézz utána a Maven-nek). Általában annyiból áll, hogy le kell szedni a projektet, lefordítani és bemásolni a megfelelő mappákba. (ZMQ automatikusan installál is, szóval itt a kézzel másolgatás is megúszható). Ezután ugye linker-nek kell megadni a lib nevét, include-olni a header-t és készen is van. A használat már más kérdés. Sok esetben hiányos, vagy nem is létezik a dokumentáció. Azokkal nagyon nehéz bánni, de a komolyabbak - amelyek mögött nagyobb közösség áll - rendelkeznek megfelelő doksival. A használatának megtanulása pedig a doksin múlik. Egy lényegre törő, jól strukturált dokumentációból pillanatok alatt ki lehet szűrni a lényeget. A többi funkció meg nem is biztos hogy akkor, abban a pillanatban érdekli az embert.
-
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
dabadab
#3254
üzenetére
A protokoll maga a szerializált csomag. Ha ezt TCP-n (vagy UDP-n) átküldöd, a másik oldal ugyanúgy fogja értelmezni. Az mit jelent, hogy a socket-ek kezelése nem thread safe? A socket az nem egy globális valami, amit több thread egyszerre használ, hanem azt maga a thread hozzza létre saját magának. Másik thread másik socket-et hoz létre. Innentől kezdve természetesen thread safe. Ha a program jól van megírva, akkor nem fognak a thread-ek közös socket-et használni, így szinkronizációra sincs szükség. Ha arra gondolsz, hogy több thread ugyan annak a távoli partnernek akar adatot küldeni, akkor persze szinkronizálni kell az írást, de erről nem a socket tehet. Ezt bármilyen library-t használva is szinkronizálni kéne. Itt nem arra gondolok, mint pl. a web szerver esetén, amikor sok kapcsolat épül ki a klienstől a szerver felé, amiket külön-külön thread-ek saját socket-eken keresztül kezelnek, hanem amikor egy adott konnektált socketre akar több thread írni. Az ftp speciel nem annyira szimpla, mert pl. két TCP csatornát használ, aktív vagy passzív módban működik, hitelesít, stb. Maga az adatkommunikációja pedig szintén szimpla TCP. Nem csak néztem ftp kódot, hanem írtam is.
-
ToMmY_hun
senior tag
válasz
jattila48
#3248
üzenetére
"ágyúval lövöldözés verébre"
Ezt jól látod, viszont egy sokszorosan tesztelt, sok ember által használt kódot felhasználni okosabb döntés, mint írni egy sajátot - az én tapasztalatommal legalábbis biztosan. Aztán az időnek is híján vagyok, van még egy hónapom befejezni a kódolást, szóval csak azt írom meg, amit muszáj.
(Ez amúgy sem rossz stratégia)Amúgy anno azért választottam a ZMQ-t, mert van Python és C++ variánsa is, így elég könnyű dolgozni vele. Bemegy a sztring C++ oldalon és a Pythonban megjelenik ugyanaz. A többi érvet, hogy cross-platform, cross-language és több kommunikációs modellt is támogat nem is sorolnám.
-
dabadab
titán
válasz
jattila48
#3253
üzenetére
"Miért lenne kevés?"
Eleve implementálni kell valami protokollt, a socketek kezelése alapvetően nem thread-safe (meg ha az egyes műveletek azok is), hibák lekezelése, stb. Nézz meg akár egy szimple ftp szervert v klienst, hogy abban mennyi hálózati kód van, pedig csak TCP csomagokat küldenek meg fogadnak
-
jattila48
aktív tag
-
dabadab
titán
-
dabadab
titán
válasz
jattila48
#3248
üzenetére
"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 API nem bonyolult.
Amíg megcsinálod azt, hogy azt használva legyen egy megbízható, normálisan és jól működő kommunikációs layered, az viszont igen. -
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ó. -
-
ToMmY_hun
senior tag
Az a helyzet, hogy van egy program amivel kommunikálnom kell. Konkrétan Blenderről van szó, ő pedig Python szkripteket futtat. (azt is elég bénán) Nem egészen arra van kitalálva, amire én használni szeretném, de hosszabb keresgélés után sem találtam alkalmasabb programot, ami ingyenes és cross platform. Szóval adott a Blender és adott a C++ kódom, őket kell kommunikációra bírni. A socketezésre ZeroMQ-t használtam eddig, azzal ment (megy) is minden. A belső állapotoknak az üzenetektől függően kelleni fog állapotgép, viszont magát a socket üzenetkezelést természetesen valamilyen library-re bízom (ez esetben ZeroMQ), miért is tennék másképp. Így is rossznak látod a megközelítési módot? Számomra annyira nem érződik a nehézsége vagy a kerék újra feltalálása, persze lehet, hogy rosszul érzem.
-
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.
-
ToMmY_hun
senior tag
Sziasztok!
Ismét lenne egy kérdésem. Eddig Java-n nevelkedtem OOP tekintetben, és nem tudom hogy itt mennyire elfogadottak az ott alkalmazott módszerek. Szeretnék socket-en keresztül kiküldeni struktúrákat, a túloldalon Python szkriptek hallgatóznak. Én úgy csinálnám meg a jelenlegi tudásom szerint, hogy egy JSON Parser library-vel sorosítanám a struktúrát, majd áttolnám socketen és Python-ban visszaalakítanám. Mennyire elfogadható megoldás ez C++ esetén? Esetleg van vamilyen kevésbé erőforrásigényes megoldás? A mostani programnál nem számít annyira az overhead, csak a későbbiekben nem ártana tudni milyen lehetőségek vannak.
-
jattila48
aktív tag
válasz
dabadab
#3240
üzenetére
Nem szokás olyan publikus tfv.-t írni, ami már meglévő publikus tfv.-ekkel megvalósítható. Az ilyet nem tfv.-ként kell megírni, hogy növeljék az enkapszulációt. A free fv.-eket kell előnyben részesíteni a tfv.-ekkel, és a friend fv.-ekkel szemben. Talán ez lehet az oka.
-
dabadab
titán
válasz
dobragab
#3239
üzenetére
"Megírhatták volna a contains-t is, de minek?"
Ergonómia, ahogy mondtam.
Melyik olvashatóbb?if(mmap.count("idk"))
vagy
if(mmap.contains("idk"))
Lefordítva meg mind a kettő ugyanaz, az STL kódolásánál meg dokumentálásánál meg kb. nulla többletmunkát jelentett volna és nagyjából ez lenne a második-harmadik leggyakrabban használt metódus a konténereknél.
-
dobragab
addikt
válasz
dabadab
#3238
üzenetére
Szerintem a multimap miatt van így. multimap-nél van értelme a count-nak, mindenképp meg kell írni a count-ot. Mást jelent a contains, felesleges lett volna megírni, mert használhatod helyette a count-ot is minden értelmes kontextusban.
bool asd = mmap.count("idk");
if(mmap.count("idk"))
...Megírhatták volna a contains-t is, de minek? Egyetlen int->bool típuskonverzió miatt? Ha nem akarsz a visszatérési értékkel pl. template osztályt példányosítani, semmi baj vele.
bool contains(Key key)
{
return count(key);
} -
ToMmY_hun
senior tag
-
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.
-
ToMmY_hun
senior tag
válasz
jattila48
#3234
üzenetére
Jól érted, és valóban az általad írt is jó megoldás. Amennyiben sok elemem lenne a map-ekben, akkor az általad javasoltat alkalmaznám, mert kisebb az erőforrásigénye a beillesztésnek. 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. Mivel az a helyzet, hogy a program indításakor nagyjából 20 elem kerül tárolásra a különböző konténerekben, itt nem igazán nyernék sokat az általad javasolt implementációval, legalábbis amennyire én meg tudom ítélni. Nagy elemszám vagy gyakori beillesztés esetén egészen más a helyzet.
Köszi a választ! Amúgy örülök neki hogy belekérdezel/kérdeztek, gondolom ilyesmire kell majd számítani a szakdoga bemutatáson is.
-
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.
-
ToMmY_hun
senior tag
-
dobragab
addikt
válasz
jattila48
#3226
üzenetére
Valóban.
template<typename T>
void print(std::vector<T> const& vec)
{
for(int i = 0; i < vec.size(); ++i)
std::cout << vec[i] << ' ';
}És igen, minden saját osztályra, amit ki szeretnél írni, érdemes overload-olni az operator<<-t.
std::ostream& operator<<(std::ostream& os, Ratio r) // tört osztályra
{
os << r.get_num() << '/' << r.get_den();
return os;
} -
ToMmY_hun
senior tag
válasz
jattila48
#3227
üzenetére
Megint nem írtam le a teljes problémakört.
Szóval ez az ID azonosítani fogja egyértelműen az objektumot ebben a programban, és egy socketen keresztül csatlakozott programban a hozzá tartozó, ID alapján meghívandó szkripteket. Ahhoz, hogy ne legyen kavarodás abból, hogy egy ID többször szerepel, ezt már itt lekezelem, így könnyebb lesz a dolgom a későbbiekben. Logikailag is inkább ide tartozik, mint egy felsőbb rétegbe."Nem overloadolni, hanem megvalósítani."Ezt miért nem overloadnak nevezik?
Ismereteim szerint egy már létező operátor új típusokkal való műveletvégézésnek definiálása az overload, ezek szerint rosszul tudom? -
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.
-
ToMmY_hun
senior tag
válasz
dobragab
#3224
üzenetére
Köszi szépen a részletes leírást! Jól sejted, valóban Javaztam eddig.
Azt nem hangsúyoztam ki a kérdésemben, hogy kulcs-érték párokat szeretnék tárolni a könnyű visszakereshetőség miatt, szóval vector helyettt inkább map-et használok majd. 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."...std:: ostream-et visszaadó) << operátora..."
Ezt manuálisan overloadolnom kell saját osztály esetén?
Más kérdés: Hamarosan aktuális lesz az álláskeresés, és ennek okán kérdezném, hogy szerintetek mi az, amivel mindenképpen tisztában kell lennie egy juniornak C++ kapcsán?
Köszi előre is!
-
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) << ' ';
} -
ToMmY_hun
senior tag
válasz
jattila48
#3222
üzenetére
Először is köszi a választ!
Konkretizálom a kérdést. Konténereket szeretnék csinálni, de mindegyik konténerben különböző típusú objektumot akarok tárolni. Szeretnék egy ősosztályt ezeknek a konténereknek, amelyben megadom a kötelezően megvalósítandó tagfüggvényeket, egyelőre két darabot. Egyik új elemet helyez bele, a másik pedig elkéri az elemet azonosító alapján. Az ötletem az lenne, hogy készítek egy template osztályt, amiben definiálom a put és get tagfüggvények működését, mivel a konténereknél csak típusbeli különbség van, ezen felül működésbeli nincs. Azért szeretném így megoldani, mert így viszonylag jól rétegezett és utólag könnyen bővíthető lenne a kód - legalábbis szerintem. Tehát ezek tükrében jó ötlet a template, vagy más felé tapogatózzak? -
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.
-
ToMmY_hun
senior tag
Sziasztok!
Ismét lenne egy kezdő kérdésem. Van néhány egymáshoz nagyon hasonló osztályom, amelyek különböző típusú objektumokat tárolnak. Szeretném megoldani azt, hogy 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. Az megfelelő megoldás, ha csinálok egy template osztályt és az abból készült osztályból származtatok le a konkrét, felhasználásra szánt osztályokban? Amennyiben nem, akkor mi a szebb megoldás?
Köszönöm előre is!
-
EQMontoya
veterán
Akkor gyorsan olvass utána a smart pointereknek. Úgy alapból a koncepciónak, hogy miről is szól ez az egész, utána pedig:
-kezdetben vala az auto_ptr
-majd lőn helyette unique_ptr
-kicsit bonyolultabb helyzetekre pedig van shared_ptr és weak_ptr (mint pl. a lentebbi, amikor több "tulajdonosa" van egy objektumnak) -
r4z
nagyúr
Nagyon láma kérdés következik.
Adott egy A és egy B osztály. A-nak az egyik adattagja B. Egy B többszáz A-hoz is tartozhat, és minden A-hoz tartoznia kell pontosan egy B-nek. Mindkettőt külön, rendszerezve szeretném tárolni/módosítani/törölni.
Hogyan érdemes nekiesni az adatszerkezetnek? Mindkettőből lista, és A B-nek csak a pointerét tartalmazza, vagy van ennél jobb megoldás is?
-
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)
{ }
}; -
ToMmY_hun
senior tag
Láma kérdés következik: Van egy Parent és sok Child osztályom. Az ősosztályban van egy paraméter, legyen a neve ID. Ezt az ID-t muszáj setelnie minden leszármazottnak, azonban tudomásom szerint nincs mód arra, hogy a default constructor helyett egy paraméterezettet hívjon meg az ősosztályban a leszármazott osztály konstruktora. Szóval szerintetek az mennyire jó megoldás, ha az ősben csinálok egy setparameters metódust és ezt hívom meg a leszármazott konstruktorában? Természetesen ha az ID nem megfelelő, akkor dob egy illegal_argument exception-t, így nem történik meg a példányosodás az alosztályból. Arra természetesen figyelek, hogy az ősosztályból létrejött példány is destruáljon.
-
dobragab
addikt
válasz
jattila48
#3208
üzenetére
Fordítsd normális fordítóval, ami támogatja a C++11-et, a zárójelek is rendben vannak. Pl. MinGW-GCC 4.8+
Létrehoz egy int-ekből álló tömböt, amit nullákkal tölt fel, és feltöltés közben egyesével kiírja az argumentumokat. Majd ezt a tömböt eldobja, mert nekünk csak a kiírás kellett, a (void) a compiler warning miatt kell.
Tudtommal ez a legegyszerűbb implementációja a variadic template-es mindent kiíró függvénynek, általában két függvény kell hozzá.
-
jattila48
aktív tag
válasz
dobragab
#3207
üzenetére
Hát, szintaktikusan biztos hogy hibás. using stílusú typedef-et soha nem használtam (VS2012 le sem fordítja), de nem is értem mit kéne csinálnia. Mi a (void) a swallow előtt? Gondolom különböző típusú argumentumokat írna ki. Kerek zárójelek nincsenek párban, a végén a ... sincs jó helyen (szerintem), szóval ennyi.
-
jattila48
aktív tag
válasz
EQMontoya
#3200
üzenetére
Majd kipróbálom. De hogy ezt meg tudja oldani, ahhoz a TU-kon "átlátó" optimalizáció kéne. Ezt tudja a g++? Én azt hittem, hogy az optimalizáció csak TU-n belül működik. Mivel itt a BodyClass esetleges ősosztályaitól függ, hogy hogy optimalizálható a kód, ezért ezt az információt meg kell tartani az object fájlban is, ha TU-k közötti optimalizációban szeretnénk ezt elvégezni. Esetleg pszeudokódot generáló fordítóknál lehetséges ez. Nem tudom, hogy a gcc végez-e ilyen pszeudo kód generálást majd azon optimalizálást, lehetséges. De akkor talán inkább az LLVM. Minden esetre a kérdés érdekes.
Az alapok fontosak, arra lehet stabil és magabiztos tudásbázist építeni - szerintem.
de valahol el kell kezdeni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Adott warningot, de akkor is, ez mi? 
Persze ez nem olyan vészes, letöröltem a fájlt, újragenerálta és rendbe is jött. Az IntelliSense és a debugger/profiler frankó.
(Ez amúgy sem rossz stratégia)
Ismereteim szerint egy már létező operátor új típusokkal való műveletvégézésnek definiálása az overload, ezek szerint rosszul tudom? 
Ú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!
- Apple iPhone 14 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple watch Series 10 42mm Silver 2027.05. Apple jótállás
- Nad Masters M10 BluOs integrált erősítő és hálózati média lejátszó
- Apple Watch Ultra 2 49mm Esim, Új állapotban, Akku:100%, 36 hónap Garancia, Titán Színben
- Aoostar WTR pro nas eladó, 8c/16t Ryzen7 5825u, 16GB DDR4 ram, 512GB SSD, 2X 2.5G lan, 4 HDD slot
- Dell latitude, precision, xps, magyar világítós billentyűzetek eladóak
- REFURBISHED - HP USB-C Dock G4 docking station (L13899-001)
- AKCIÓ! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
- Bomba ár! Dell Latitude E6520 - i5-2GEN I 6GB I 320GB I HDMI I 15,6" HD+ I W10 I Gari!
- 135 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090 (ELKELT)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest