Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
"A fajlmeret-beolvasas nem mukodik"
Már miért ne működne?
Legfeljebb akkor lehet gond, ha már fájl végéhez értünk (pl. egyszer már beolvastuk az állományt), de ekkor kiadsz egy clear()-t, és megint menni fog.Fájlméret-lekérdezés:
ifstream file_to_process("test.dat" , ifstream::in);
//fájl elejéhez ugrás:
if( (int)file_to_process.tellg() != 0) //ha nem az elején vagyunk
file_to_process.clear(); //ha EOF-hoz értünk, már nem menne enélkül...
//elejére ugrunk
file_to_process.seekg(0, ios::beg);
//végére ugrunk
file_to_process.seekg(0, ios::end);
//hol tart?
long length =(long) file_to_process.tellg();
//méret kiírása
cout<<"File merete: "<<length<<" byte"<<endl;[ Szerkesztve ]
Sk8erPeter
-
veterán
Még kicsit rágódni fogok rajta, mert futási időben dől el hogy hány szál lesz, és ugyebár be kell várni a szálakat annak a szálnak ami indítja őket, és ez az esetemben nem is a főszál, hanem egy másik szál
Elég fura a szintakszis java után.
[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
veterán
Részleteket tudok mutatni, és elmondom mit csináltam.
Elöljáróban annyit, hogy csináltam egy wrapper osztályt a winapi köré, hogy OO módon tudjam kezelni socketeket, és amúgy tök jól működik.
Itt az 1. számú szálon meghívódik a rcvfrom() és várakozik is csomagra timeout nélkül, ahogy annak lennie kell:
Miután küldök neki egy csomagot, azt szépen feldolgozza a szál:
Ezek után elindítja a 2. számú szálat, ami egy másik socketre hívja meg a recvfrom()-ot:
Megnyomom az F11-et (step into) és voilà:
Látom szerkesztettél és call stack kell, intézek egyet.
Itt a call stack, nyilván csak az abortot előidéző utasításig tudom megnézni:[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
veterán
-
veterán
az opertor<< nem csinál semmit csak kiír. Az is mindig jól működik, kivéve ebben a szálban. Nem használ közös adatot, két külön objektumról van szó amik a saját tagváltozóit írják ki.
std::ostream& operator<<(std::ostream& os, const Socket& sock)
{
os << sock.IP_address << ":" << sock.port;
return os;
}A két szál közös adatai meg mutex-ekkel védett stl tárolók, de odáig most nem jut el a program, hogy használja is őket a második szál.
[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
veterán
Először is odaadom a Socket és az UDP_Socket forrását. A thread indítása elég összetett és inkább nem adnám oda. A threadként elindított függvény egy objektum tagfüggvénye, és ezt az objektumot először inicializálom az első beérkező csomag függvényében.
Így deklarálom az objektumot:
auto forwarder = std::make_shared<RTP_proxy>();Ha a csomagban megfelelő content van és még nem létezik forwarder a forráscímhez tartozóan, akkor csinálok egy új forwardert:
forwarder = std::make_shared<RTP_proxy>(proxy_IP, rtp_addr, call_ID);Hozzáadom a forwardereket tároló map-hez:
RTP_forwarder_list[rtp_addr] = forwarder;És elindítom az új szálat:
std::thread(&RTP_proxy::run, RTP_forwarder_list[rtp_addr].get());https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
veterán
-
veterán
-
dabadab
titán
"Ha a fuggveny, amit hivsz, virtualis, akkor igazabol barmi megtortenhet, lenyegeben a leszarmazott osztalyok azonos nevu (virtualis) metodusai mind elerhetoek lesznek a hivo (friend) szamara."
Igen, de csak akkor, ha az adott objektumra base class tipusu pointerrel hivatkozik az ember (mert kulonben latja a fordito, hogy a leszarmazott methodjat kellene hivni)
#include <stdio.h>
class Q
{
protected:
friend class P;
virtual int q()
{
return 9;
}
};
class R : public Q
{
protected:
virtual int q()
{
return 3;
}
};
class P
{
public:
int p()
{
R r;
Q* q=&r;
//return r.q(); // NOT OK
return q->q(); // OK
}
};
int main(void)
{
P p;
printf("%d\r\n",p.p());
}DRM is theft
-
Nem, semmi ilyesmi.
De ha valaki nagyon unatkozik és érdekli, akkor feltöltöttem a kódot a codeviewer-en.
MC_func.cpp //függvény definíciók
MC_func.h //header file
A program úgy működik, hogy a megadott helyzetű pontforrás a megadott paraméterű hengeres detektorba lövi ki a fotonokat. Izotróp módon, de úgy van megcsinálva a hatékonyság érdekében, hogy ne mindenfelé indítsa őket, csak a detektor köré írható gömb irányába.
Ezután a fotonok nagy része eltalálja a detektort és jó eséllyel valamilyen kölcsönhatásba lép az anyagával és lead valami energiát.a main 93. sorában az "sz2" számolja azokat a fotonokat, amik eltalálták a detektort. Amíg az el nem éri a megadott számot, addig a ciklus ismétlődik. Ha egy adott foton a detektorban van, akkor amíg benne van, vagy amíg van energiája, addig pedig a 3 kölcsönhatás típus közül mennek a sorsolások és azok ismétlődnek.
[ Szerkesztve ]
-
-
Jaa, bocsi, arról el is felejtkeztem.
-
nagyúr
Ami miatt nagyon lassu a program:
- a ComptonScatter fv.-ben az elejen letrehozol egy 3x3-as matrixot vector<vector<double>> formajaban, ujra es ujra, minden fuggvenyhivasnal. Feltetelezem, hogy ez az elozo, mindent-egybe verzioban nem igy volt. Csak ez onmagaban a programod futasidejenek kb. 30%-at viszi el, nagysagrendileg 500e-szert hivod (csak a 10%-aig futtattam a profilert, mert marha sokaig tart, amig kielemzi az instrumentalas utan a hivasszamokat). Javaslat: ezt az atmeneti vektort ne generald ujra mindig, hanem (mezitlabas modon) hasznalj valami globalis valtozot, lehetoleg ne is vector<vector<>>-t hanem csak egy 9 hosszu sima vector<>-t, amit aztan megfeleloen indexalsz. (Tobbiek ne kopjenek le a global miatt, eleve gyakorlatilag C kodrol beszelunk..)
- a FreePath fv-ben, amit szinten joparszor meghivsz, ott pedig van ez a sor:
while (hkm[k][0] < E1) k++;// mc_4, hkm_E 5 elemû sorvektor. Megadja az hkm-értékeket a keresett E1 energiánál.
Ez szinten a teljes futasido kb. 30%-at veszi el. Ha jol latom, itt a hkm az a fajlban tarolt adat, es ebben keresgelsz. Ahelyett, hogy linearisan keresnel, tedd bele valami masfele adatstrukturaba. (Biztos lehet egyeb dolgokat is csinalni, de faj a szemem a kododtol ).Kicsit itthagyom a gepet, csinalok egy full analizist, es felrakom valahova.
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
> Kicsit itthagyom a gepet, csinalok egy full analizist, es felrakom valahova.
Hat, jelenleg nincs annyi szabad helyem az SSD-n, hogy vegigfusson a full instrumented profiling (40 GB-ot irt ki, amikor betelt), szoval majd egyszer maskor, a lenyeg nem valtozna ugysem. Oldd meg a lenti problemakat, utana folytatjuk.
[ Szerkesztve ]
while (!sleep) sheep++;
-
Krono91
csendes tag
Reggel amint lesz rá időm nekiesek és átnyálazom az erről szóló dolgokat.
A többieknek csak hogy a hibát kicsit jobban specifikáljam:
Ha a ListaElem konstruktorát kijavítom ez a kódrészlet nekem tökéletesen lefordul, de ha használni szeretném már nem tudom.
Első gyors ránézésre azonnal feltűnik hogy a Lista konstruktorában mikor a strázsákat hozom létre a next és pre pointereket mintha nem definiáltam volna. tehát olyan mintha a a Lista osztály nem látná a ListaElem struktúra belső felépítését.A megoldás az lett hogy létrehoztam egy ListaElem.h headert és abba tettem bele ezt a kódrészletet:
template <class Adat>class ListaElem // privát struktúra így nem kell a fiend ami nehezíti az olvashatóságot, és így tényleg senki nem fér hozzá ehhez az adattaghoz
{
friend class Lista;Adat data; // maga az adat része az objektumnak
ListaElem *next; // a listában következőre mutató pointer
ListaElem *pre; // a listában előzőre mutató pointer//ListaElem konstruktora, ezzel már azonnal beszúrhatóvá is válik 2 listaelem közé
ListaElem(ListaElem *next = 0, ListaElem *prev = 0) :next(next), pre(prev) {}
};A másik headerben a generikusság miatt egy kis átalakítással pedig ez maradt:
#include "ListaElem.h"template<class Adat>
class Lista
{
ListaElem<Adat> *first; // Első eleme a listának strázsa
ListaElem<Adat> *last; // Utolsó eleme a listának strázsapublic:
//Lista konstruktora, strázsák létrehozása
Lista()
{
//Strázsák létrehozása
first = new ListaElem<Adat>;
last = new ListaElem<Adat>;
first->pre = 0;
first->next = last;
last->pre = first;
last->next = 0;
}
};Ekkor már tökéletes a kód és használható is.
A kérdés az hogy az első megoldásom miért nem helyes.
El szeretném kerülni a friend class használatát és egy belső privát struktúrában szeretném tárolni a ListaElemek felépítését.Bocsánat ha ködösen fogalmaztam elsőre, de már tényleg lassan alvás idő van
-
zsambek
aktív tag
Mi a baj a constructorommal? Hogy kellene megirnom, hogy a fordito leforditsa?
||=== Build: Debug in v1 (compiler: GNU GCC Compiler) ===|
main.cpp|8|error: default argument missing for parameter 2 of 'Array<T>::Array(int, T*)'|
main.cpp||In constructor 'Array<T>::Array(int, T*)':|
main.cpp|11|error: expected unqualified-id before '[' token|
main.cpp||In member function 'void Array<T>::merge_Sort(Array<T>&)':|
main.cpp|52|error: expected unqualified-id before '[' token|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 1 second(s)) ===|[ Szerkesztve ]
-
zsambek
aktív tag
Basszus, tenyleg... Erre egyaltalan nem gondoltam....
A T[] meg mar kitoroltem, csak, amit feltoltottem, abban meg nem volt benne a javitas...Koszi a gyors segitseget, remelem nem fogok elakadni a kesobbiekben. Gondolom a merge_sort reszben is le lehet szedni a T[]-t, de majd meg kitapasztalom...
[ Szerkesztve ]
-
EQMontoya
veterán
Ez legalább annyira agybeteg, mint a méltán híres sleep sort
Same rules apply!
-
EQMontoya
veterán
Példakód, nyilván. De alapvetően szerintem az a baj, hogy az egy paraméteres konstruktor nem explicit.
Azért az bárkivel megesik, hogy referencia helyett próbál meg pointert átadni, vagy fordítva. Nyilván értelmes esetben csak az egyik megy, és beszól a fordító, hogy csinálj valamit a szaroddal. Ha mindkettő megy, az baj, szerintem ez nem a hívó fél hibája, itt egyértelműen a konstruktorért jár a körmös. Legalábbis szerintem.[ Szerkesztve ]
Same rules apply!
-
amargo
addikt
-
EQMontoya
veterán
Értem, mire gondolsz, de alapvetően az ilyen esetekre is lehet valamilyen attribútumot, vagy egy virtuális függvényt (ez jobb, főleg ha az ősben van deffiniálva mondjuk, és false-t ad vissza, a megfelelő leszármazottban meg true-t), és az lényegesen elegánsabb (és gyorsabb) megoldás, mint a cast. Ha reflection-szerű megoldásra van szükség c++-ban, az gáz, azért van többszörös öröklés, hogy minden megfelelő interface-szel rendelkezhessen az adott osztály.
Emiatt én leginkább hacknek tartom, ami ugyan lehetséges az adott nyelven, de alapvetően nem ajánlott, és inkább tervezési hibára vezethető vissza.
Szerk: Meh, hamarabb írtam a választ, mint az edited.
[ Szerkesztve ]
Same rules apply!
-
ToMmY_hun
senior tag
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. Végülis a dynamic_cast működik és a miatta keletkező overhead sem probléma, mert csak az inicializálásnál lesz használva.
Szerk: Akkor inkább legyen az objektum típusát tartalmazó tagváltozó és ellenőrizzem azt?
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
ToMmY_hun
senior tag
Rendben, köszi. Viszont ha már belelendültem a kérdezgetésbe, akkor azt is megkérdezném hogy egy viszonylag könnyen használható XML Parser lib-et tudtok ajánlani? 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. Sebesség itt sem mérvadó, mert beállításokat fogok abból betölteni egyetlen egyszer, a program indításakor.
C programmers never die, they are just cast into void.
-
semij9699
csendes újonc
Köszi a válaszod!
Hát igazából elég zöldfülű vagyok a területen.
A kérdésem az lenne nagy körvonalakban ,hogy a 3 adat amiket kér (t, dátum , f) azokat hogyan kellene megadni? Véletlenszerű adatokkal tölti fel? vagy csak simán a textboxba mikor beirnak egy adatot ezt elment?
A válaszod előre is köszi
Ú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!
- Elektromos rásegítésű kerékpárok
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- EA Sports WRC '23
- Milyen notebookot vegyek?
- Kínai, és egyéb olcsó órák topikja
- Napelem
- Azonnali informatikai kérdések órája
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Audiokultúra - Hi-Fi-ről hifisen
- További aktív témák...
- I7 - GAMER /8700K + VÍZ - Z370 - 16GB DDR4 - 512GB NVME - 4TB HDD -RX 6600/8GB DDR6- 700W - RGB HÁZ
- Samsung Galaxy S23 Ultra 256gb/8gb Phantom Black
- Sony PlayStation 5 (PS5) Játékkonzol
- Samsung Galaxy S22 5G Dual Sim 8/128gb Hibátlan állapot
- 10.GEN GAMER PC /B460-STEEL-I5 10400F +VÍZ - 1TB NVME + 4TB HDD - 16GB RGB - RX 6600-8GB DDR6 + RGB/