Hirdetés
- iPhone topik
- Milyen okostelefont vegyek?
- Xiaomi 15 - kicsi telefon nagy energiával
- Yettel topik
- Vivo X200 Pro - a kétszázát!
- Huawei Watch GT 6 és GT 6 Pro duplateszt
- Apple iPhone 16 Pro - rutinvizsga
- Apple iPhone 17 Pro Max – fennsík
- Honor Magic6 Pro - kör közepén számok
- Xiaomi 15T - reakció nélkül nincs egyensúly
Új hozzászólás Aktív témák
-
#2700
Mesterlovesz
aktív tag
Mesterlovesz
aktív tag
Sziasztok!
Programozót keresek Altcoin fejlesztéshez. Az érme kész van, a jelenlegi tárcát kellene az új igényekhez fejleszteni. ( a régi fejlesztőm ebben már nem tud segíteni)
Érdekes lehet még egy androidos vagy webes tárca az érméhez.
Elsősorban árajánlatot szeretnék kapni egy ilyen projektre!Programnyelv amire szükség van: C++, Java, Python.
-
EQMontoya
veterán
válasz
EQMontoya
#2695
üzenetére
Válaszolva erre is: ma már eléggé nagy multi lett, keresnek kezdőt, tapasztaltat, javast, pythonost, PM-et, stb.
C++-os vonalon igazából nem kell semmilyen ilyen múlt, akinek van tapasztalata és vágja a c++, vagy kezdő de van jó agya és affinitása, azt felveszik simán.Lassan 700 fő a cég, szegedi irodával, nincs már olyan nagy válogatás... Azért mondjuk az Ericssonnál, NSN-nél magasabban van a mérce még mindig.
-
mgoogyi
senior tag
Effective C++ könyv. Ha azt végigrágod és nagyrészt érted is, akkor jók az esélyeid az interjún.
Aminek ezen felül utánanézhetsz: stl, desing patterns, esetleg ha marad időd, akkor szálkezelés, szinkronizációs primitívek. A többi lényeges dolog szerintem benne van a könyvben. -
Az NNG-nel (gondolom roluk van szo
) regebben direkt demoscene multu, assemblyt is erto embereket kerestek. Demoscene karriert nem fogsz epiteni masfel honapban, de az realis cel, hogy valami assembler alaptudast felszedjel, ami szimpatikusabba tehet az allasinterjun. Egyebkent C++-nal is segit idonkent az egzotikusabb hibaknal, ha az ember ranez arra, hogy valojaban milyen kodot produkalt a fordito meg ugy altalaban sem rossz dolog, ha az ember beszeli a processzor anyanyelvet -
Orionk
senior tag
Sziasztok !
Egy kis segítséget szeretnék kérni azoktól, akik szoftverfejlesztésben dolgoznak és leginkább C++ programozási nyelvet használnak.
Jelenleg még programtervező informatikus szakon tanulok, de végzős vagyok és Júliusban megyek majd állásinterjúra, ahol bekerülhetnék egy céghez gyakornoki programra.
Júliusig még van kb. 1,5 hónapom és az idő alatt még tudnék egy kicsit fejlődni. Az állásinterjún természetesen a gondolkodásmódot is nézni fogják, de a C++ prog.nyelvet követelik majd meg, mert ők abban fejlesztenek.Azt szeretném kérdezni, hogy az egyetemi tudáson felül, gondolok itt az objektum orientált szemléletmódra és a c++ programozás tanulására minek nézzek utána ? Mit tanuljak meg használni ? Mit használtok tik, akik már dolgoztok a C++ keretein belül ?
köszönöm szépen. /A cég, ahova interjúra megyek autónavigációt fejleszt/
-
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. -
EQMontoya
veterán
Heti fun.
#include <iostream>
class A
{
public:
bool mb;
A(bool b): mb(b) {}
};
void Foo(const A& a)
{
std::cout << ( a.mb ? "true" : "false" ) << std::endl;
}
int main()
{
A* ap = new A(false);
Foo(ap); //prints true
}kijavitottam a formazast meg az elirasokat - dabadab
Tanulság: sose nyomd fullba a kretént...
[ Módosította: dabadab ]
-
zsambek
aktív tag
válasz
EQMontoya
#2682
üzenetére
Haha
Ha mar itt tartunk, most neztem, hogy meg biztosan le van mentve a 2003-as evfolyamig a felhasznalo fiokok, szoval nem tudom, h mikor vegezted az infot, de esetleg meg te is be tudnal lepni
Valósítson meg C++ nyelven egy olyan osztályt (F12),
amely egyrészt átadható a 2. feladat megoldását segítő
függvénynek (solveF2(const F2&)), másrész képes az STL deque
sablonjához hasonlóan működve ASCII karaktereket tárolni!
C++ nyelven a többszörös öröklést célszerű használni, ha
egy objektumnak többféle interfésszel kell rendelkeznie, ezért
a feladat megoldásához előkészített f12.h állományban, mely
az aktuális katalógusban (...) található,
az F12 osztályt az F2 és a Queue osztályból származtattuk.
Az F2-ben deklaráltuk azt az f() függvényt, ami a hftest 2. feladatát
hivatott megoldani. A Queue osztály pedig egy karaktereket tároló
kétvégű sort valósít meg az STL deque sablonjának felhasználásával,
de attól egy kicsit eltérő funkcionalitással.
Az Ön feladata megvalósítani az f12.cc állományban az F2,
az F12 és a Queue osztály tagfüggvényeit és statikus adattagjait.
Az F2 osztály double f(double) tagfüggvénye a következő függvényt
kell, hogy megvalósítsa (ld. 2. feladat):
f(X) = X/120.90, ha X > 35,
f(X) = 0.472*X^4 - 0.943*X^3 + 60.38*X^2 + 3*X - 35, ha X <= 35
A Queue osztálynak van egy myIteraror nevű iterátora is,
amellyel a karaktersorozat az elejétől a végéig bejárható.
Segitségképpen egyes tagfüggvényeket már definiáltunk az f12.h
állományban.
Figyelje meg, hogy az iterator milyen egyszerűvé teszi a tároló
kezelését! Az f12_main.cc állományban lát erre példát, ami az aktuális
(...) katalógusban található a fordítást segítő
f12.mak állománnyal együtt.
Ha elkészült, fordítsa le, ill. tesztelje az osztályt
a következő paranccsal:
make -f f12.mak
A make lefordítja az f12.cc-t valamint az
f12_main.cc-t és így futtatható a keletkező f12 nevű program.
Az f12_main.cc a teszetlést segíti. Azt igénye szerint módosíthatja.
Az f12.h állományt azonban NE módosítsa!
Ha úgy gondolja, hogy helyesen oldotta meg a feladatot, akkor a
make -f f12.mak submit
paranccsal adja be azt az automatikus feladatellenőrző rendszernek.
Az automatikus teszt csak az f12.cc állományban megvalósított
F2, F12 és Queue osztályok működését vizsgálja, azaz, hogy megfelelnek-e
a fent megadott specifikációnak. Így nem veszi figyelembe az f12_main.cc
tartalmát, és azt sem, ha esetleg módosított az f12.h-ban! -
zsambek
aktív tag
Sziasztok!
Van egy ilyen hftest12 nevezetu feladatom, amit meg szoktam csinalni, viszont most elakadtam.
Kaptam hozza 2 darab file-t, es egy 3. kell csinalnom, ami a headerben levo fv-ket kivitelezi.Szerintem jol csinaltam meg a programot, viszont valamiert meg se. Az ural-on az alabbi hibat kapom. (Bocsi az UTF-8 hiany miatt)
"
cc1plus: note: obsolete option -I- used, please use -iquote instead
Errors: 0Hello az1412!
Tesztelem a "a.out" programot...
Az azonos▒t▒ adatok nem tal▒lhat▒k meg az els▒ 0 sorban!A program abnorm▒lisan ▒llt le (sig:11)
"Feldobtam Cubbyra az egeszet( http://bit.ly/1bXhXJu ), ha csak a sajat reszem az erdekes, akkor azt megtalalhatjatok itt:
http://pastebin.com/pAKN8pnKKipróbáltam úgy, hogy az első sorban van ténylegesen a myId, viszont, akkor is ugyanez a gond. Kipróbáltam \n -vel a végén, anélkül is. include-ltam <iostream> -et is, talán az a baja...
Lényeg, hogy nem tudom...
Előre is köszönöm a segítségeteket,
-
EQMontoya
veterán
Az ">>" operatort erre ebben a formában ne használd.
Ha megvan a fix struktúrád, akkor a következőképp csináld:
-Határozd meg, hogy mekkora egy elem. (mondjuk 2*sizeof(int) + x*sizeof(char) )
-Olvass be ekkora blokkokat egy bufferbe.
-A bufferből szedd ki az adatot a változóidba (memcopy pl.). -
Weper
tag
Üdv.
Az lenne a problémám, hogy program orientált programozásnál a Visual Studioban meg kellene nyitni 1 bináris fájlt és az adatait be kellene olvasnom egy "kolcsonzo" típusú tömbbe. Az lenne a gondom, hogy a while(!be.eof) résznél a végtelenségig megy. Valaki nem tudja mi a probléma?
A feladat leírása: http://prog.hu/tudastar/185858/Binaris+fajl+beolvasasa+objektum+orientaltan.html
A kolcsonzo.dat az imént belinkelt témához van csatolva.#include <iostream>
#include <fstream>
#include <conio.h>
using namespace std;
struct kolcsonzes
{
char datum[12]; //a kölcsönzés napja
char tipus[20]; //a kerékpár típusa
int sorszam; //a kerékpár sorszáma
int ido; //a kölcsönzés ideje
};
class kolcsonzo
{
private:
kolcsonzes *k;
int db;
public:
kolcsonzo();
void Kiiras();
int Getdb() { return db; };
//int GetMagellan( return )
};
kolcsonzo::kolcsonzo()
{
db = 0;
ifstream be("kolcsonzo.dat", ios::binary);
if (be)
{
while (!be.eof())
{
db++;
k = new kolcsonzes[db];
if (k)
{
be >> k[db - 1].datum[12];
be >> k[db - 1].tipus[20];
be >> k[db - 1].sorszam;
be >> k[db - 1].ido;
cout << db << ". adat: " << k[db - 1].datum[12] << endl;
cout << db << ". adat: " << k[db - 1].tipus[20] << endl;
cout << db << ". adat: " << k[db - 1].sorszam << endl;
cout << db << ". adat: " << k[db - 1].ido;
}
else
{
cerr << "Kevés a memória!" << endl;
}
}
}
else
{
cerr << "Nincs ilyen fájl!" << endl;
}
be.close();
cout << db;
}
void kolcsonzo::Kiiras()
{
for (int i = 0; i < db; i++)
{
cout << i+1 << ". adat: " << k[i].datum << endl;
cout << i + 1 << ". adat: " << k[i].tipus << endl;
cout << i + 1 << ". adat: " << k[i].sorszam << endl;
cout << i + 1 << ". adat: " << k[i].ido;
}
}
void main()
{
setlocale(LC_ALL, "HUN");
kolcsonzo a;
a.Kiiras();
_getch();
} -
Jester01
veterán
válasz
zsambek
#2675
üzenetére
Ha a 44. sorban a temp az simán csak T* tömb lenne akkor a 67-69 sorokban egyszerűen értékadás lehetne.
A kisebb függvényben a const hibás használata (célszerűen const char*).
Nincs ~Array ezért az adat nem kerül felszabadításra, memory leak.Stilisztikai megjegyzések:
Nyelveket keverni nem szerencsés: adat, kisebb, getData(int i){return adat[i];}, stb...
Érthetelen/félrevezető nevek: ssize, elements
Inkonzisztens elnevezések: getData, setElements de bubble_Sort és merge_Sort.
Nem a legszűkebb scope használata.Elsőre ennyi
-
zsambek
aktív tag
Sziasztok!
http://pastebin.com/5JPYkYQ4
Ha minden igaz kesz lett a hazim.
Viszont lenne par kerdesem.
A Bubble Sort-nal csinalhattam volna ugy is, hogy mondjuk Array<T> temp(1) -et csinalok, de szerintem annak nem lenne sok ertelme, hogy egy valtozonak egy kulon tombot csinaljak.Egy olyan kerdes is felmerult bennem, hogy esetleg ellenorizni, hogy ugyanazt a tipust adjuk-e be Merge_Sort-hoz. Meg is kerdeztem, es azt mondtak, hogy nem kell vele foglalkozni, de engem akkor is erdekel, hogy milyen modja lehet? Hasznalhatnam az std::is_same, viszont STL tarolot nem szabad hasznalni, szoval esetleg valami mas otlet? Vagy inkabb felejtsem el.
Ezen kivul meg erdekelne a velemenyetek, hogy esetleg valamit mashogyan kellett volna csinalni, persze csak, ha van.Koszi a valaszaitokat,
-
#2670
emvy
félisten
Sk8erPeter
#2667
válasz
Sk8erPeter
#2667
üzenetére
-
#2669
EQMontoya
veterán
Sk8erPeter
#2667
EQMontoya
veterán
válasz
Sk8erPeter
#2667
üzenetére
Különösen annak tükrében, hogy láthatóan életében nem írt még 30 sor kódot...
-
#2667
Sk8erPeter
nagyúr
Scrake^;DD
#2665
Sk8erPeter
nagyúr
válasz
Scrake^;DD
#2665
üzenetére
Hát igen, a Console.WriteLine() egy C++ topicban elég rossz.
Amúgy az előbb linkeltem egy konkrét megoldást C-ben, a Wikipédia Buborékrendezés cikkében meg egy pszeudokód van, ha ezek alapján nem tudod összehozni, akkor úgyis veszett fejsze nyele.
Ja, egyébként van egy jó tippem, ha már C# kell... (konkrét megoldásokat kapsz így is) Mondjuk eleve finoman szólva etikátlan, ha ez csaláshoz kell. -
#2666
EQMontoya
veterán
Scrake^;DD
#2665
EQMontoya
veterán
válasz
Scrake^;DD
#2665
üzenetére
Leadandó kell, gyorsan valami suliban, ugye?
-
#2664
Sk8erPeter
nagyúr
Scrake^;DD
#2662
Sk8erPeter
nagyúr
válasz
Scrake^;DD
#2662
üzenetére
Google 3. találata, 5 másodperc alatt (C-ben):
http://wiki.prog.hu/wiki/Buborékrendezés_(algoritmus) -
#2663
EQMontoya
veterán
Scrake^;DD
#2662
EQMontoya
veterán
válasz
Scrake^;DD
#2662
üzenetére
Oké, hol tartasz?
-
#2662
Scrake^;DD
aktív tag
Scrake^;DD
aktív tag
Hali! ha valaki tudna gyorsan írni..
stringbe meg vannak adva nevek és rendezni kellene növekvő sorrendbe, buborékos rendezéssel! köszi előre is! -
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...
-
válasz
zsambek
#2657
üzenetére
Egyreszt szerintem az nem jo, hogy az elso parameternek van defaultja, a masodiknak nincs. Default parametert csak ugy lehet megadni, ha az utana kovetkezo parametereknek mind van defaultja, vagy nincs tobb parameter.
A masik problema az, hogy
T[] adat = new T[ssize]; //lefoglalok T tipus tomb adatot, ssize meretut
itt a T[] felesleges, mert nem lokalis valtozot szeretnel inicializalni, hanem az adattagot. (Gondolom en.)
-
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)) ===| -
zsambek
aktív tag
Sziasztok!
Kicsit elakadtam, nem tudom, h pontosan mit is csinalok rosszul.
http://pastebin.com/P3yc7buw
Probaltam kikommentelni, hogy ertheto legyen, remelem sikeresen
Az biztos, hogy az egyik baj a constructorommal van.
Ebbol indultam ki, hogy igy kell constructort csinalni, csak szerintem a template T -ben levo T miatt rontok el valamit.template<typename T>
class Array{
public:
Array(){ }Kellemes hetveget,
-
EQMontoya
veterán
válasz
Krono91
#2652
üzenetére
A friend kicsit gusztustalan, es annyira nem is kell. Listaelemet siman definialhatod a lists belso osztalyakent is, ha mar mindenkepp osztalyba szeretned rakni.
Strazsa szinten nem tul hasznos szerintem, elso elem prr pointers es utolso next pointers null. Persze az elso elem egyben az utolso is lehet, vagy akar 0 elem is lehet. -
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
-
Krono91
csendes tag
válasz
Jester01
#2647
üzenetére
Ebben igazad van azt már én is átírtam, a kód lefordul utána, de ha megnézed akkor nem lát bele a ListaElem struktúrába a Lista, és nem tudom miért... a favágó megoldás az most hogy külön headerben tárolom a ListaElemet, és friend class a Lista, így látja a privát adattagokat, és így már működik...
De sajnos nem tudom a miértjét:S -
Jester01
veterán
válasz
Krono91
#2646
üzenetére
Nem ott van a hiba ahol mutatod, szerintem a fordító sem ott mondja ... az enyém legalábbis nem
Ez a rossz:
ListaElem(ListaElem *next = 0, ListaElem *prev = 0) :n(next), p(prev) {}
Valószínűleg ezt akartad inkább:
ListaElem(ListaElem *n = 0, ListaElem *p = 0) :next(n), pre(p) {}
-
Krono91
csendes tag
Hellosztok.
Szeretném megtudni hogy ez a kódrészlet miért nem működik helyesen:
template<class Adat>
class Lista
{
struct ListaElem // privát struktúra így nem kell a friend ami nehezíti az olvashatóságot, és így tényleg senki nem fér hozzá ehhez az adattaghoz
{
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) :n(next), p(prev) {}
};
ListaElem *first; // Első eleme a listának strázsa
ListaElem *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;
last = new ListaElem;
first->pre = 0; // nem ismeri a fordító a pre pointert...
first->next = last; // nem ismeri a fordító a next pointert...
last->pre = first;
last->next = 0;
}
}A problémám a Lista konstruktorával van, bele is kommenteltem a megakadásom okát.
Elképzelhető hogy én vagyok nagyon fáradt és valmai triviális dolgot nem veszek észre de akkor sem látom, mi lehet a hiba.
A segítséget előre is köszönöm -
EQMontoya
veterán
válasz
Jester01
#2644
üzenetére
Nagyjából, igen.
Az stiimmel, hogy sizeof(int) != sizeof(double).
64 bit amúgy, linux, gcc. Ez viszont önmagában nem indokolja az "üres helyet".
Az egy paddig, hogy jó legyen az alignment. Elvégre 64 bites proci szereti, ha az osztály mérete 8 bájt többszöröse. Ettől még lehetne a nem használt hely az objektum végén, viszont ugye a cpu 8 bájtos egységeket olvas be 64 biten a memóriából, tehát ha ezen a nem 8-cal osztható címen kezdődne a double, akkor csak két művelettel tudná beolvasni. Ezt pedig nem szeretik. Nem is mindegyik kezeli le, ez ugye SIGBUS signal formájában tud jelentkezni. (pl. ARM-on) Ezért nem a végén tölt fel négy bájttal, hanem a közepén. -
Jester01
veterán
válasz
EQMontoya
#2643
üzenetére
Minden bizonnyal olyan környezetben vagy ahol az int és a double között van egy kis üres hely. Például ha az int 32 bites a double meg 64 akkor lesz közöttük 4 byte üres hely. Az ip++ erre az üres helyre fog mutatni, viszont a dp már félig át fog lógni a double tagba. -
EQMontoya
veterán
struct t_struct
{
int im;
double dm;
};void hack(char *p)
{
int* ip = (int*)p;
*ip=6;
ip++;
double* dp=(double*)ip;
*dp = 6.6;
}int main()
{
t_struct t;
t.im=0;
t.dm=0.0;
char *p = (char*)&t;
hack(p);
std::cout << t.im << "\t" << t.dm << "\n";
}Lefuttatva:
6 és 5.31354e-315 (6.6 helyett)
A helyes megfejtők között c++ vándorserleget sorsolunk ki.
-
-
> 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.
-
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.
-
#2634
emvy
félisten
Sk8erPeter
#2633
válasz
Sk8erPeter
#2633
üzenetére
spekt.txt az asszem kimeno adat, a masik viszont kellene
(akarok rajta futtatni egy profilert)
-
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.
-
-
válasz
HussarF
#2622
üzenetére
"most már csak kb. másfélszer lassabb a függvényekbe szedett kód a spagettinél."
Akkor inline-old a függvényeket. Ahhoz az kell, hogy egy fordítási egységben legyenek, vagyis praktikusan a kis függvények vagy egy c++-ban legyenek azzal, ami meghívja őket (ez esetben inline-ként kell őket deklarálni), vagy benne legyen a függvény törzse is a header file-ban (ilyenkor meg automatikusan inline-olódik).
-
válasz
proof88
#2621
üzenetére
Na átírtam a függvényeket, hogy referenciaként kapják meg a vectorokat. Ez megoldotta a problémát, most már csak kb. másfélszer lassabb a függvényekbe szedett kód a spagettinél. Ezt már be lehet szerintem tudni a függvényhívás idejének. Valójában észrevettem, hogy a vectorok nagy részét már így is referenciaként kapja és nem úgy, ahogy szombaton mutattam. Erre úgy emlékszem azért volt szükség, mert ha értékként adtam át, akkor csak a függvényen belül létrehozott másolatban változtatta meg az értéket, de az eredetit nem módosította. Most átírtam referenciára azokat a vectorokat is, amelyeknek nem kell az értékét változtatni, ezért előzőleg nem írtam át őket referenciára.
Egyébként valóban azért adtam át mindent pointerként a függvényeknek, mert én C-t tanultam és nem C++ -t. Bár mostanában már C++ -t használok, és próbálom kihasználni az előnyeit a C-hez képest, de sajnos én még mindig C-ben írom a programokat C++ -os beütéssel. Próbálom megtanulni minél jobban a C++ -ban való kódolást.
Egyébként kivettem a pointereket és referenciaként adtam át őket a függvénynek, de ez a sebességen már nem változtatott.
Kösz a segítséget -
proof88
addikt
válasz
HussarF
#2620
üzenetére
ebben az esetben, ne pointerként add át őket, hanem simán csak értékként (ezt az E1-re és az sz_E-re értem). Nem vesztesz sebességet. Pointereket akkor használj, ha tényleg tömbről van szó, és dinamikusan lefoglalt memóriaterületre mutat a mutatód. Ha esetleg kifelé is változtatni akarsz a beadott paramétereken, akkor inkább referenciaként add át, ne mutatóként. Érdemes ezt használni, ha már C++. C-ben nincs referencia.
-
Rendben, hétfőn át fogom írni akkor. Amikor azt kerestem a neten, hogy hogy lehet vector-t átadni függvénynek akkor ezt a két módszert láttam. Már kicsit rozsdás a C++ tudásom, de próbálom feleleveníteni. Nem programozó vagyok, hanem fizikus, aztán van, hogy hosszabb ideig nem kell programozgatni és ilyenkor feledésbe merül pár dolog.
(#2619) proof88
Az *E1 és az *sz_E nem tömbökre mutató pointerek. Az E1 a foton aktuális energiája, az sz_E meg egyszerűen azt számolja, hogy hányszor lépett kölcsönhatásba (azaz hányszor történt energialeadás). Ugye a program úgy működik, hogy mindig indít egy adott energiájú fotont, az pedig a detektorba belépve kölcsönhatásba lép a detektor anyagával, szóródik, elnyelődik stb. és egy ilyen kölcsönhatás után veszít az energiájábólKöszönöm még egyszer a segítségetek.
-
proof88
addikt
válasz
HussarF
#2617
üzenetére
nem, ilyenkor a vector-ok másolódnak, azaz új vector objektumok keletkeznek, az eredetik tartalmával, és a függvény a másolatokon fog dolgozni, nem az eredetiken. A vektorokat add át referenciaként, pl:
vector<double>& E_tarolo
vagy pl.:
vector<vector<double>>& hkmígy az eredeti, függvénynek megadott vektorokkal fog dolgozni a függvény, mert csak referenciát adsz át neki.
Ezzel máris megspórolsz egy csomó dinamikus memóriafoglalást, melyek eddig mindig megtörténtek bármelyik vector-os függvényed hívásakor (a komplett vektor lemásolása végett).Amúgy Debug vagy Release módban fordítasz? Utóbbiban gyorsabb lesz a futás, persze fejleszteni Debug-ban ajánlott, a jobb hibakeresés végett.
Igazából nem tudom, milyen célja van ezeknek a vektoroknak, ezek csak bemeneti paraméterek? Mert ha igen, és a függvény nem is módosít rajtuk, csak olvassa őket, akkor még a const-ot is odaírhatod eléjük, pl.:
void PhotoEffect(double *E1, int *sz_E, const vector<double>& E_tarolo)
Illetve ami még nem világos, hogy pl ennél a függvénynél az E1 ill. sz_E paraméterek valóban tömbökre mutatnak?
-
válasz
HussarF
#2617
üzenetére
"Meg a vector-okat, de azok is pointerként működnek, mint a tömbök, nem? vagy legalábbis nem hiszem, hogy az okozná a problémát"
Pedig de. Az std:vector<> az ugy mukodik, hogy amikor lemasolod, akkor a komplett adatstrukturat lemasolja.
(A QT containere pl. nem igy mukodnek, azok copy-on-write-ot csinalnak, de ez most csak mellekszal.)vagyis neked a kovetkezo kell pl:
void PhotoEffect(double *E1, int *sz_E, const vector<double> &E_tarolo)
-
válasz
proof88
#2615
üzenetére
Sajnos most hétvégén nem érem el a végleges verziót, de a függvény paraméterek nem változtak. Azok így néznek ki:
void InTheInfiniteTube(double *v1, double *v2, double *v3, int *sz2, double *xbe, double *ybe, double *zbe)
void AroundTheCylinder(double *v1, double *v2, double *v3, double xy_det_tav, double hatarszog, int *sz2, double *xbe, double *ybe, double *zbe)
void FreePath(double *v1, double *v2, double *v3, vector<vector<double>> hkm, vector<double> hkm_E, double *xbe, double *ybe, double *zbe, double *E1)
void ComptonScatter(double *v1, double *v2, double *v3, double *E1, int *sz_E, vector<double> E_tarolo)
void PhotoEffect(double *E1, int *sz_E, vector<double> E_tarolo)
void PairProduction(double *xbe, double *ybe, double *zbe, double *v1, double *v2, double *v3, double *E1, int *sz_E, vector<double> E_tarolo, vector<double> hkm_E, vector<vector<double>> hkm)
Végülis túlnyomórészt pointereket adok át nekik. Meg a vector-okat, de azok is pointerként működnek, mint a tömbök, nem? vagy legalábbis nem hiszem, hogy az okozná a problémát
-
proof88
addikt
-
válasz
proof88
#2613
üzenetére
Rendben, köszi!
Még egy kérdést engedjetek meg. Ez a programom eredetileg egy nagy spagetti kód volt, egy forrás fájllal és kb. 400 sorral. Mivel egy csomó ismétlődő rész volt benne, ezért egyértelműen adta magát a dolog, hogy egyes részeiből függvényt csináljak. De ekkor az a teljesen váratlan és megdöbbentő dolog történt, hogy a kód kb. 50-ed (!) részére lassult. Ami eddig 2-3 mp-es futás volt, az most 2 perc. És gyakorlatilag semmi mást nem csináltam, csak az ömlesztett kódot kicsit rendeztem azzal, hogy függvényt csináltam egyes részeiből. Kérdésem, hogy ez a függvény hívás tényleg ennyire időigényes dolog, hogy ennyire belassítja a futást?Egyébként először az eredeti forrás fájlba tettem a függvényeket is, a main() előtt definiálva. A futási sebességen nem változtatott, hogy utána a függvényeket külön forrásfáljban definiáltam és header-ben deklaráltam. A program egyébként egy NaI szcintillációs detektort szimulál fotonok detektálása közben. Mivel ez egy elég jól párhuzamosítható dolog, ezért az eredeti célom az volt, hogy CUDA-ra írom át a kódot, de lesokkolt, hogy mennyire belassult attól, hogy függvényekbe szedtem. Így szinte nincs is értelme átírni GPU-ra, mert még ha 10x-esére is gyorsul, akkor is jóval lassabb lesz, mint a spagetti-kód.
-
Sziasztok!
Lenne egy kérdésem, mert már megőrít a dolog. A programomban van két .cpp fájl, meg egy header. A header fájlban van definiálva 2 struktúra meg 7 függvény. A függvények közül többnek is van vector típusú argumentuma. A fordító viszont állandóan panaszkodik, hogy: error C2061: syntax error: identifier 'vector'Már beletettem a header-be, hogy #include <vector>, de ez sem segített. Valaki tudna segíteni?
Köszi!
-
InterFox
senior tag
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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!
- HP Thunderbolt 4 kábel
- Eredeti Microsoft Windows 10 / 11 Pro OEM licenc Akciós áron! 64/32 bit Azonnali kézbesítéssel
- GYÖNYÖRŰ iPhone 13 Pro 256GB Sierra Blue - 1 ÉV GARANCIA, Kártyafüggetlen, 100% Akkumulátor,MS3379
- MacBook, Apple M1 / M2 kompatibilis dokkolók, DisplayLink 4K, USB-C, Type-C
- Apple iPhone 13 256GB / Kártyafüggetlen / 12Hó Garancia / 100% Akku
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest