- Yettel topik
- Apple iPhone 16 Pro - rutinvizsga
- iPhone topik
- Macrodroid
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Szerkesztett és makrofotók mobillal
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy A56 - megbízható középszerűség
- Samsung Galaxy A54 - türelemjáték
Új hozzászólás Aktív témák
-
#4225
DrojDtroll
veterán
EQMontoya
#4224
DrojDtroll
veterán
válasz
EQMontoya
#4224
üzenetére
Ugyan ezt, csak 4s körüli értékkel.
Úgy néz ki tényleg beleszámolja a fordítást is.
stavkoverflow:Measuring execution time of a function in C++
Ez alapján mindig ugyan azt mérem.
-
xors
senior tag
válasz
EQMontoya
#4115
üzenetére
Igen, erre én is gondoltam, csak az zavart meg, hogy a típusnév(), ugye konstruktor hívás, aminek nincs visszatérési értéke alapból.
De azt értem , hogy kell valami default érték, amit ugye majd a sablon fog adni, és a default konstruktor pedig valamit létre tud hozni. -
dobragab
addikt
válasz
EQMontoya
#4103
üzenetére
Egyébként ezt is meg lehet csinálni, azért élőben is szoktad látni a próbálkozásaimat
Annyi a lényeg, hogy a szüzet a másik irányból kell támadni. (Mármint a legelvadultabb C++ kiskapukat kell keresgélni és abuse-olni.) Ami szar meló, sok munka van vele, és sose lesz az igazi
-
jattila48
aktív tag
válasz
EQMontoya
#4106
üzenetére
Melyik ostoba hozzászólásomra gondoltál? Amiben annak minősítettem, hogy szerinted 2018-ban a bináris api fv.-eknek C++ template-eket kéne tudni értelmezni? Ha az szerinted nem volt ostobaság, az baj.
A másik, hogy nincs azzal baj, ha api fv.-eket akarok objektum orientált módon használni, az miért ostobaság? Ilyen simán előfordulhat. Az, hogy te még nem találkoztál ilyennel, nem jelent semmit. -
jattila48
aktív tag
válasz
EQMontoya
#4084
üzenetére
Milyen API fv. kezel C++ template-eket 2018-ban? Ne beszélj már butaságokat! Tudod mi az az API? Az egy bináris interfész az op. rendszer felé. C++ -ban forráskód szinten használhatók az ilyen konstrukciók, mert a c++ fordító a template-eket megfelelően lefordítja a template argumentumok típusának megfelelő forráskódra, majd azt bináris kódra. Egy bináris interfész-hez hogy akarod ezt illeszteni?
-
jattila48
aktív tag
válasz
EQMontoya
#4080
üzenetére
A CreateThread-et csak példának hoztam. C++ -ban is előjöhetnek hasonló problémák, pl. különböző objektumok (pl. nyomógomb) tfv.-eit mint üzenetkezelő callback fv.-t kell regisztrálni.
Nem kikerülni, hanem megérteni szeretném a problémát, úgyhogy ne a kikerülésére tegyetek javaslatot. Azt nyilván magam is meg tudom tenni, ha arra van szükségem. -
jattila48
aktív tag
válasz
EQMontoya
#4077
üzenetére
Lambdát nem tudsz átadni callback fv. pointerként pl. egy CreateThread vagy StartServiceCtrlDispatcher api hívásnak. Ezek egyetlen pointert várnak, a lambda pedig egy C++ nyelvi konstrukció (a mélyben egy névtelen osztály konstruktorral,...), amit az api fv. nem fog tudni értelmezni.
-
-
#4008
m.zmrzlina
senior tag
EQMontoya
#4004
m.zmrzlina
senior tag
válasz
EQMontoya
#4004
üzenetére
A világért sem szeretnék hitvitát generálni de ha már itt tartunk van e konszenzus (tudom nincsen) a szakmában hogy melyik ingyenes IDE-vel érdemes bajlódni (vagy mondjuk melyik hárommal)? Igen tudom, hogy a szakma nem ingyenes fejlesztőkörnyezeteket használ de mégis nagyobb rálátásotok van a témára mint pl a Pékek Országos Szakmai Fórumának.
Félreértés ne essék tudok guglizni (noha nagyon nem a barátom) inkább tapasztalatok érdekelnének. Egészen onnan hogy text editor >> parancssorból fordítás odáig hogy színes szagos IDE mindenféle kényelmi funkcióval.
-
#4005
m.zmrzlina
senior tag
EQMontoya
#4004
m.zmrzlina
senior tag
válasz
EQMontoya
#4004
üzenetére
Akkor valamit nagyon elszúrok:
Ez van linux alatt:
xenon@xenon-P5QL-PRO /usr/bin $ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609Ez a kód:
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s = "1234";
int i = stoi(s);
return 0;
}A hibaüzenet itt is ugyanaz:
error: 'stoi' was not....stb...stb....
-
#3917
m.zmrzlina
senior tag
EQMontoya
#3916
m.zmrzlina
senior tag
válasz
EQMontoya
#3916
üzenetére
A megoldás: stringbe olvasunk be, azt konveráljuk számmá. Ha nem sikerül, lehet hibát dobni.
Ha jól sejtem ez az a megoldás amit javasolsz (16-30 sor)
-
dobragab
addikt
válasz
EQMontoya
#3841
üzenetére
Megnéztem, se gcc 7.1.1, se clang 4.0, se clang-tidy nem találja meg. Utóbbiba mondjuk lehetne egy ilyen check-et építeni, majd rá is kérdezek, mert tényleg oltári szopás lehet egy ilyenből.
Valami clang sanitizer tuti megtalálná, de ez elvileg megfogható statikus ellenőrzéssel is.
Talán a legnagyobb probléma itt az, hogy a ctor valami olyat próbál csinálni, ami nem teljesen feladata
Az a vicc, hogy semmi olyan nem történik, mert a count_a melléktermékeként áll elő a prod kódban is a b.
-
dobragab
addikt
válasz
EQMontoya
#3823
üzenetére
Nem. A mutable az ellenség megtévesztése miatt került oda, az élet szülte változatban nem volt mutable.
[=]valamiért (nem tudom, miért, számomra is rejtély) nem x-et, hanem this-t capture-öli érték szerint, de mivel this az eredeti objektumra mutat, az eredeti x-et változtatja. Tehát 3.(#3822) Domonkos
Funkcionális programozás nélkül elég mélyen lennék a ganéban, így egy teljes natív C++ shell motorja ~2000 sor.
-
nji
aktív tag
válasz
EQMontoya
#3785
üzenetére
Nekiállok, ez nem kérdés, de hogyan lehet egységnyi idő alatt legjobban felkészülni:
- a könyvet olvasva,
- youtube-ot nézve,
- tutorialt olvasva,
- telefonon a SoloLearn programmal?
Napi nyolc órát dolgozom, hétvégén házimunka, tehát max. napi egy órám van rá esténként.
Ezért szerettem volna megtudni a gyakorlott szakemberektől, hogy mi a legjobb módszer. -
-
pvt.peter
őstag
válasz
EQMontoya
#3693
üzenetére
Mentségemre legyen, hogy ez egy 3rd party *.dll egyik callback függvényének a paramétere.Én is érzem, hogy eléggé fos megoldás...
Persze szebben is megcsinálhatták volna, pl. a paraméter legyen egy interfész amit a saját típusaimmal megvalósíthatok, utána kedvem szerint castolhatok. Vagy az interfészt megvalósító típusba becsomagolni a saját cuccomat.Az egyetlen egy talán még szép megoldás erre az, hogy két ugyanolyan callback szignatúra lesz csak más névvel, és adott feladat elvégzésére mindig beállítgatom, hogy melyik callback hívódjon meg.
Mindenesetre köszönöm szépen mindenkinek a válaszát
-
dobragab
addikt
válasz
EQMontoya
#3686
üzenetére
Klasszikus értelemben vett hibát egyet sem. Olyat viszont, ami a költő hozzá nem értéséről tanúskodik, többet is.
- Az osztály elnevezése. Ha kommentben kell jelezni, hogy ez bizony
XMLParsingException, tessék már úgy is nevezni az osztályt. Bár ahogy nézem, itt az osztálynevek módosítva vannak, nem hiszem, hogy az XML-t kiszedted volna belőle.-
std::string-et érték szerint átvenni a konstruktorban. Elvileg nem baj, sok esetben érdemes így csinálni C++11 óta, ha ugyanis aBaseException-nek vanstd::string&&-es konstruktora, egy füst alatt csinálhatsz string-et másoló és mozgató konstruktort, ha az inicializáló listán ezt írod:BaseException{std::move(error_)}.Mivel pl. az
std::runtime_error-nak nincs ilyen konstruktora, és az egész kódból sugárzik, hogy C++98-ban írták, így erős a gyanúm, hogy itt csak egy felesleges másolást látunk. Plusz sose szerencsés, ha exception dobása közben dobódik egy másik a másolásnál, mert pl. elfogyott a memória. Ezt viszont nem lehet teljesen kikerülni.- Kézzel forward-olni a konstruktort, mint az állatok. Ráadásul rosszul, lásd előző pont. C++11 óta illik így írni:
using BaseException::BaseException;- Copy ctor kézzel, mint az állatok. Ha valami magic-et csinál ott, még elfogadható, de akkor az op=-nél is illene, meg amúgy is minek. Ez egy sima kivétel-osztály, az ilyen szarság csak hibalehetőség.
- Virtuális destruktor a leszármazottban. Feltételezem, csak azért csinálta, hogy a destruktort virtuálisnak deklarálja, annak meg így semmi értelme, azt az ősben kellett. Ha a destruktora nem üres, komoly indok kell az egészhez, de attól még lehet jó.
-
throw(). Már a C++98 szabványosítás körül kiderült, hogy athrow(...)deklaráció szar, elavult, nincs értelme, csak ront a helyzeten. 2016-ban még "karban tartják" ezt a kódot, és ilyen van benne. Athrow()ráadásul inkompatibilis anoexcept-tel, tehát ha tényleg rögzíteni és vizsgálni kell, hogy egy függvény dobhat-e, ez a kifejezés false lesz.if(noexcept(e::~ParsingException())) // ...- Kivételdobásról nyilatkozni destruktorban. Egyrészt ha konstruktorban bármi dobódik, az
std::terminate. Másrészt, hathrowdeklaráció sérül, az isstd::terminate, tehát a destruktornál pontosan ugyanaz történik, akármit nyilatkozik ott. Még hanoexcept-et ír, az is ugyanazt jelenti, mintha semmit nem ír oda.- Az egysoros tagfüggvények definícióját kiviszi másik forrásfájlba. Ugyan már, kinek fáj, ha inline? Feltételezem, egyikben történik semmi eget rengető, tehát egyrészt a nagy semmiért egy egész függvényhívás lesz (pl. a destruktornál). Másrészt az olvasót baszogatja a tudat, hogy meg kéne nézni, mi van a cpp fájlban, pedig sejti, hogy valószínűleg semmi különös, amiért érdemes lenne megmozdítani az ujját.
Szóval röviden ennyi. Nálam így nézne ki ez az osztály:
struct XMLParsingException : public BaseException
{
using BaseException::BaseException;
}; -
cattus
addikt
-
bandi0000
nagyúr
válasz
EQMontoya
#3644
üzenetére
biztos jók amit mondotok meg stb, de az a baj hogy nem tudom mit írtál most le
természetesen nem várom hogy elmagyarázd, majd apránként megtanulom ezeket, de annak sincs értelme ha csak lemásolgatom amit írtoktetszik ez a shuffle, sztem ezt majd használom
de a vektor alatt ti mit értetek? sima tömböt nem?
-
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ó.) -
dobragab
addikt
válasz
EQMontoya
#3519
üzenetére
Nem nagyon látom, mi van a set-nél, nem áll össze a fejemben.
A legjobb megoldás valóban az, ha mindent arra használunk, amire való. Kivéve persze a template, mert azt template metaprogramming-ra is.
Igen, de hát az emplace pont erre van, hogy meghívja helyetted a konstruktort, még ha explicit is. Pont az ilyen baklövések miatt nem kéne push_back helyett is emplace-t használni, ahogy megállapítottuk
-
dobragab
addikt
válasz
EQMontoya
#3502
üzenetére
Csak elkészült ez a válasz, túl régóta írom.
Az emplace_back veszélyét szerintem az első világítja meg legjobban. Nem te hívod meg a konstruktort, így történhetnek olyan konverziók, amit nem szeretnénk.
A második példában az igazi körmös nem az emplace_back, hanem a RAII megsértéséért jár. Sőt, rosszabb: RAII és raw pointer keverése. Ugye resource acquisition is initialization lenne, csakhogy a foglalás után pakolod bele egy unique_ptr-be, itt épp implicit módon.
Ha azt vesszük, hogy a vector deklarációja zömmel három forrásfájllal és 2000 sorral arrébb van, mint ahol belepakolsz, és lehet, hogy rosszul emlékszel, hogy az most A*-ot, vagy unique_ptr<A>-t tartalmaz. push_back-nél ha rosszul emlékszel, a fordító hörögve kiszáll.
Szóval a második esetért közvetve az emplace_back felelős, közvetlenül az, aki nem emlékszik, hogy ott unique_ptr van. Általános esetben is, az emplace_back-nél nem mindig kell tudnod, hogy temporális vagy létező cuccot akarsz-e belerakni, és ez itt a fő veszélyforrás.
Engem kísértetiesen emlékeztet a kérdés a C-s NULL és a 0 esetére, a hatékonyságot kivéve. Mindenhova írhatsz 0-t, ahova NULL-t, de fordítva nem igaz. Most ne keverjük ide a printf-et, talán az az egy kivétel van. Mégis, az olvashatóság kedvéért pointereknél NULL-t, egészeknél 0-t írunk, pedig írhatnánk mindenhova 0-t. Ugyanígy, az olvashatóság kedvéért létező objektumnál tessék push_back-et írni, hogy biztosak lehessünk benne, ott tényleg létező objektumról van szó.
Ennyi indok bőven elég, hogy push_back helyett ne használjunk emplace_back-et.
Továbbmegyek: van egyáltalán létjogosultsága az emplace_back-nek?Ha egy már létező objektumot akarsz belepakolni, a kettő pont ugyanannyira hatékony, ugyanaz történik. Megnéztem, mi a helyzet abban az esetben is, amire az emplace_back elsődlegesen való: temporális objektumnál. Igazából arra ment ki a játék, hogy ilyenkor jobb-e az emplace_back, mint a push_back kiírt konstruktorhívással. Azért mégis csak jobban látni, hogy ott egy temporális objektumot pakolunk bele a vektorba, ha oda van írva.
Ilyenkor szoktam elővenni a Noisy osztályt, ami mindig kiírja, mikor mi történik vele, és számolja, hány példány van belőle, amúgy semmi másra nem jó. Itt a teljes forráskód, a Noisy túl hosszú ahhoz, hogy gátlástalanul bemásoljam, ide csak a lényeget hoztam.
int main()
{
std::vector<Noisy> vec;
vec.reserve (1000);
Noisy n1(1);
vec.emplace_back(n1);
Noisy n2(2);
vec.push_back(n2);
vec.emplace_back(Noisy(3));
vec.push_back (Noisy(4));
vec.emplace_back(5);
}Az elején azért van ott a ronda reserve, hogy ne legyen átméreteződés, az csak összezavar minket.
Az n1 és az n2 esetében kottára ugyanaz történik, ahogy el is várjuk, copy ctor. Noisy(3) és Noisy(4) is egyforma, move ctor. Az igazán érdekes a 4-es és 5-ös összehasonlítása. Annyit nyertünk az 5-össel a 4-eshez képest, hogy egy move ctorral és egy ki-move-olt objektum destruktorával kevesebb. Ezen spórolni meg igencsak barbár dolog C++11 óta.
Ha kikommenteled a move ctort, akkor a fordító sem generál - mert írtunk destruktort -, így a copy ctor hívódik, tehát a push_back lényegesen lassabb lesz.
És mivel az emplace_back eleve C++11, így jó eséllyel van move ctora a tárolt cuccnak. Akkor van igazán értelme az emplace_back-nek, ha nincs move ctor, ilyen-olyan okból. Nem is lehet neki jó move ctort írni - ilyet nehezen tudok elképzelni, de C++-ban semmit nem zárok ki -, vagy C++98-as, nem módosítható API-ból jön.
Ha nincs move ctor, a hatékonyság számít annyit, hogy szerintem elfogadható az emplace_back. Egyéb esetben én azt mondom, fordítva kéne: emplace_back helyett is push_back-et használni: fontosabb az, hogy lásd kiírva a ctort, mint a move ctor overhead-je.
Akkor viszont egy másik probléma jön elő: ha van move ctor, akkor push_back, ha nincs, emplace_back. Ez kb. ugyanolyan rossz, mint az eredeti probléma, szóval temporális objektumra egységesen kéne a kettő közül választani. Nézzük meg a várható kockázatokat és a nyereséget:
push_back: ha nincs move ctor, lassú, de jól olvasható és egyértelmű
emplace_back: ha nincs move ctor, gyorsabb, néhány karakterrel rövidebb. Várható kockázat: egy elrontott emplace_back miatt végtelen debuggolás...Szóval én azt mondom, temporális objektumnál az API függvényében kéne dönteni, hogy az adott projektben melyik. De létező objektumra egész biztosan push_back.
-
sztanozs
veterán
válasz
EQMontoya
#3490
üzenetére
Jaja, kisérleteztem közben, hogy megértsem
Jessz, genyaság kimaxolva:
struct A{ virtual void f(){ std::cout << "A::f"; } };
struct B : public A{ void f(){ std::cout << "B::f"; } };
struct C : public B{ C(){ f(); } };
struct D : public C{ void f(){ std::cout << "D::f"; } };
int main()
{
D d;
return 0;
} -
Jester01
veterán
válasz
EQMontoya
#3485
üzenetére
Nem hiba. A szabvány szerint:
When a virtual function is called directly or indirectly from a constructor or from a destructor, including during the construction or destruction of the class's non-static data members, and the object to which the call applies is the object (call it x) under construction or destruction, the function called is the final overrider in the constructor's or destructor's class and not one overriding it in a more-derived class.
-
dobragab
addikt
válasz
EQMontoya
#3431
üzenetére
+1. A megoldás ránézésre jó, én csiszolnék rajta.
1. a trim nagyon enum-szagú
2. char* a 21. században?
3. Igen, szerintem helyben kéne végezni, egy std::string-en. Aztán betenni egy függvénybe, ami std::string&-et vár.Vagy std::ostringstream-be pusholni a karaktereket.
(#3432) jattila48
Szabványos C99. Sőt, egyetlen nem-C89 elemet használ, a for(int...
Szebb megoldás: írsz IPv6 osztályt, ahol uint16_t-tömböt tárolsz belül. Megírod a beolvasást, ami tetszőleges formátumú IPv6 címet be tud olvasni, és a kanonikus alakba visszaírást, és mindjárt egyszerre több feladatot oldottál meg.
Ha tényleg "csak" a rövidítés a feladat, ahhoz tényleg OP egy ilyen osztály, de ha használni kell az IPv6 címeket, nem igazán illik sztringben tárolni.
-
ToMmY_hun
senior tag
válasz
EQMontoya
#3422
üzenetére
Pontosan ilyen egyszerű feladatokra lettek kitalálva és ezekben nagyon is jók. A probléma ott kezdődik, ha kicsit komolyabb, nagyobb projektet is ezek segítségével akarnak létrehozni. Sajnos láttam már ilyeneket nagy multinál és egyáltalán nem tetszett.
Egyébként a Java is nagyon kényelmesen használható. Én ahhoz szoktam nyúlni, ha valami triviális dolgot gyorsan kell megoldani. Múltkor például apámnak készítettem benne GUI-s képátméretező szoftvert. Nagyjából 1,5 óra volt megírni nem túl szolid, körülbelül fél éves Java tapasztalattal.Egyéb: Úgy néz ki sikerült C++ fejlesztői munkát megnyernem, ezúton is köszönöm a segítséget a fórum lakóinak! Lehet, hogy nektek nem tűnt úgy, de iszonyat sokat segítettek az ügyben.
-
-
-
dobragab
addikt
válasz
EQMontoya
#3358
üzenetére
Szerintem nem annak kéne hívódnia.
int operator,(std::ostream&, int) <- ezt a fordító generálta
int operator,(proxy, int) <- ezt én írtamEzek közül szerintem annak kéne hívódnia, amihez nem kell típuskonverzió, jelen esetben az elsőnek. Ha azt akarnám, hogy itt is az enyém hívódjon, akkor felüldefiniálnám ezt:
int operator,(std::ostream&, int) <- már ezt is én írtam
Szóval felül tudom csapni.
-
-
jattila48
aktív tag
válasz
EQMontoya
#3342
üzenetére
Én 136-ot mondanék futtatás nélkül. Többszörös öröklődésnél a this pointert igazítani kell, amit az ún. thunk kód végez. Erről írtam a pimpl példámnál, amikor hatékonysági okból a forwarding fv. hívásokat member pointer-ekkel helyettesítettem. Ha csak az osztály incomplete deklarációját látja a fordító, akkor nem tudja eldönteni, hogy kell-e this pointer igazítás vagy nem, ezért a legrosszabb esetre készült. Ez volt az a bizonyos assembly kód, amit a VS feltehetőleg rosszul linkelt. Ha azonban a a forward deklarációban közöljük, hogy a szóban forgó osztály _single_inheritance (MS kulcsszó), akkor nem generálja a felesleges thunk kódot, és jól működik. A gcc-nek nem okozott ez problémát, persze az is generálta a thunk kódot.
-
dobragab
addikt
válasz
EQMontoya
#3321
üzenetére
Konkrétan C++98-ban:
- default ctor: végighívja az ősosztályok és adattagok default ctor-át, sorrendben. Ha írsz bármilyen ctort, ami nem copy ctor, bukod a default ctort, kézzel kell írnod, ha akarsz. (vagy = default, C++11-ben)
- copy ctor: végighívja az ősosztályok és adattagok copy ctor-át, sorrendben.
- operator=: végighívja az ősosztályok és adattagok operator=-jét, sorrendben.
- dtor: végighívja az adattagok és ősosztályok dtor-át, ebben a sorrendben- címképző operátor (&)
- vessző operátor (,)Ehhez hozzá jön a C++11-es move ctor és move assignment operator, ami ha kínai, nézz utána alaposan a jobbérték referenciáknak.
- move ctor: a move ctor-okat hívja végig, ha van, egyébként a copy ctort
- move op=: a move op=-ket hívja végig, ha van, egyébként a sima op=-tEz a kettő csak akkor van, ha
- nincs a felhasználó által írt copy ctor vagy dtor,
- nincs a felhasználó által írt másoló vagy move operator=,
- nincsen valami miatt implicit törölve (például mert az egyik adattagé törölve van).Mindennek az a célja, hogy az erőforráskezelést el tudd rejteni egy-egy erre specializált osztály belsejébe, pl. string vagy vector. Ezeket aztán máshol úgy tudod használni, mint egy sima int-et, mert a fordító mindig tudja, mikor mit kell meghívni. A felsőbb szintű (nem erőforráskezelő) osztályoknak nem kell foglalkoznia a fent említett tagfüggvényekkel, a default is úgy fog működni, ahogy elvárjuk.
Nyilván ez nagyon le van egyszerűsítve, de nagyságrendileg stimmel.
Jávához képest: van destruktor, mégpedig arra, hogy bármilyen erőforrást (memória, fájl, mutex, grafikus memória, stb.) becsukjon. Ha jól tervezed meg az osztályaidat, ezek mind automatikusan történnek. A GC ennél butább, mert csak memóriát szabad / lehet rábízni.
Jó, igen a finalize-ra elvileg rá lehet bízni pl. egy fájl bezárását, de az ki tudja, mikor fut le... Nagyon nem vicces nyitva hagyni egy fájlt random ideig, amíg a GC össze nem szedi a memóriában lévő objektumot. Ezért van jávában minden fájlkezelős történet try - catch - finally blokkban, hogy akármi történik, kézzel be tudd csukni a fájlt. C++-ban a compiler biztosan becsukja a fájlt a blokk végén (fstream).
Kicsit elkanyarodtam a kérdéstől. Remélem, azért mondtam újat, rosszat meg nem
-
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.
-
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)
-
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
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.
-
jattila48
aktív tag
válasz
EQMontoya
#3196
üzenetére
A gcc generálja a thunk kódot, a virtuális hívást, és még nem tudom mit. Mint ahogy a VS is, ha nem tud a BodyClass-ról semmit. Bármelyik fordítónak a "legrosszabb" esetre kell készülni (többszörös virtuális öröklés, virtuális tfv.), ha csak a BodyClass forward deklarációját látja, és semmi egyéb segítséget nem kap. Magától nem találhatja ki hogy "mizu" van. Nem tudom, hogy a gcc-nek vannak-e erre kulcsszavai, nem nagyon használom. A VS-ben is csak most találtam rá. Mondjuk member function pointert sem igen használtam, és gyakorlatban a forwarding fv. hívás sem túl nagy overhead, inkább csak elméletileg érdekelt a dolog. A C++-ból azért mindig van mit tanulni.
-
jattila48
aktív tag
válasz
EQMontoya
#3174
üzenetére
Valószínűleg nem ez a legjobb megoldás, úgyhogy le is tettem róla. Ettől a kérdés még elméletileg érdekes. A pimpl marad, viszont az int template paramétert (amihez a static_for kellett volna), megszüntetem. Azt hiszem, a pimpl idióma egyébként sem ajánlható template-ekben (pont az explicit példányosítás szükségessége miatt), de nekem most nagyon jól jön, és nem az implementáció elrejtése vagy a gyorsabb fordítás miatt.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Viiiiiszont.. így, hogy le lehet futtatni kipróbáltam, beraktam breakpointokat és azt láttam amit vártam.. a második esetben nem hívódik a copy.. akkor miért ad nekem hibát a fordító?
Ú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!
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude E7270 - i7-6GEN I 8GB I 256GB SSD I 12,5" FHD I HDMI I CAM I W10 I Gari!
- BESZÁMÍTÁS! Sony PlayStation 4 PRO 1TB SSD fekete játékkonzol extra játékokkal garanciával hibátlan
- Csere-Beszámítás! Sapphire Pure RX 7900XT 20GB Videokártya! Bemutató darab!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged