Új hozzászólás Aktív témák

• #2510 kingabo őstag #39560925 #2508

  Új Válasz 2014-07-20 23:47:07 #2510

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  kingabo

  őstag

  válasz #39560925 #2508 üzenetére

  Ja, ok. Az már nem rémlett, hogy direkt írtad meg így.

• #2509 emvy félisten #39560925 #2508

  Új Válasz 2014-07-20 22:46:16 #2509

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2508 üzenetére

  Jaja, abort()-ot nem kapsz csak ugy el catch()-el.. (SIGABRT handlerrel lehet talan).

• #2507 kingabo őstag #39560925 #2494

  Új Válasz 2014-07-20 22:22:38 #2507

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  kingabo

  őstag

  válasz #39560925 #2494 üzenetére

  Első kép: kivétel esetén egy memória szemetet adsz vissza! Illetve semmiből sem látszik, hogy hiba történt: se log, se vmi kiíratás, se vmi extremális elem visszaadás, amit a hívó oldalon ellenőrzől, vagy egy bool érték, hogy sikerült-e, vagy bármi amiből a hivó oldalon rájösz, hogy hiba volt, ill debug közben kiírná, hogy hohó hiba törpént...

• #2505 emvy félisten #39560925 #2504

  Új Válasz 2014-07-20 21:16:47 #2505

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2504 üzenetére

  ctrl+alt+e

  ... FB is jo, amit akarsz, privatban megirhatod

• #2503 emvy félisten #39560925 #2502

  Új Válasz 2014-07-20 21:13:55 #2503

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2502 üzenetére

  Headerek? A bufferek amikbe a socketek tarolnak a bejovo cuccot, threadenkent szeparaltak? Megprobaltad bekapcsolni a lentebb emlitett opciokat debugolaskor?

  Szerk.: keress mar meg szkajp cseten, vagy valami hasonlo..

• #2501 emvy félisten #39560925 #2500

  Új Válasz 2014-07-20 20:26:16 #2501

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2500 üzenetére

  Az UDP_Socket forrasat es azt, ahol a threadet inditod, nem tudod felrakni a pastebinre (vagy akar ide, de pb jobb)? Ha jol latom, ez nem titkos (merthat eleve adtal rola sok kepernyofotot).

  Miben kulonbozik a ket thread?

  Plusz:

  - a debug opcioknal kapcsold be a 'break on first chance exceptions'-t
  - kapcsold be a c++ exception-oknel a 'break on thrown'-t
  - esetleg kapcsold ki a just my code-ot

• #2500 #39560925 törölt tag #39560925 #2499

  Új Válasz 2014-07-20 20:04:53 #2500

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2499 üzenetére

  Tehát az UDP_Socket operator<< függvénye lentebb olvasható (mint mondtam is, mindig működik). A sender_address és a sender_port egy std::string és uint16_t típusú, inicializált változók.

  Itt megtörtént a standard outputra kiírás:
  

  De közben felvillan a "debug error!" hibaüzenet, amiből utána ennyi látszik:
  

  Jó, mi?

• #2498 emvy félisten #39560925 #2497

  Új Válasz 2014-07-20 19:18:16 #2498

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2497 üzenetére

  Nyilvan nem az std::cout az erdekes, hanem hogy mit csinal az << operatorod az osztalyodban.

  Mi az az adat, ami a ket szalban kozos? Gyanitom, hogy a << operator hasznal osztott adatot.

• #2496 emvy félisten #39560925 #2495

  Új Válasz 2014-07-20 19:15:36 #2496

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2495 üzenetére

  Tehat jol ertem, hogy
  - a problema determinisztikus
  - mindig a masodik szalnal jon elo (az elso recvfrom mukodik, de ugyanaz a kod egy masik szalon meghivva mar nem)

• #2495 #39560925 törölt tag #39560925 #2494

  Új Válasz 2014-07-20 19:07:25 #2495

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2494 üzenetére

  Kicsit elrontottam a debugolási lépések leírását, nem azok a képek vannak, amikre emlékeztem.

  Szóval a második képhez tartozó helyes szöveg ez lenne: várakozik is csomagra timeout nélkül, ahogy annak lennie kell.

  Az első képhez meg csak annyi a komment, hogy meghívódik a recvfrom()

• #2493 emvy félisten #39560925 #2492

  Új Válasz 2014-07-20 18:32:47 #2493

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2492 üzenetére

  Publikus a forras? Ha nekiallsz debugolni, akkor mi tortenik (call stack kellene)?

• #2492 #39560925 törölt tag #39560925 #2491

  Új Válasz 2014-07-20 18:28:27 #2492

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2491 üzenetére

  Senkinek nincs ötlete?

• #2491 #39560925 törölt tag #39560925 #2490

  Új Válasz 2014-07-19 10:56:19 #2491

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2490 üzenetére

  Amugy irtam kis kiegeszito programokat amikkel kiprobaltam, hogy mukodik-e amit csinalok, es mukodik. Meg ezen a programon belul is mukodik, csak azon a bizonyos szalom nem.

• #2484 WonderCSabo félisten #39560925 #2481

  Új Válasz 2014-07-01 17:38:15 #2484

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WonderCSabo

  félisten

  válasz #39560925 #2481 üzenetére

  Nem tudom, hogy világos-e, de itt nincs semmi extra szintaxis (ahogy javában sincs ebben az esetben). Az std::thread egy sima osztály, thread_name itt a változó neve, és létrehozatalakor a két paraméteres konstruktort hívja meg. Az első paraméter egy függvény pointer, jelen eseten itt egy member function-ra, a második paraméter pedig sima address of operátor, hogy referencia szerint legyen átadva. Ez azért szükséges, hogy a metódus hívásakor adott legyen a this. (Mellesleg a példánymetódusoknál amúgy is valami ilyesmire fordul, mármint mindig a függvény első paramétere az objektum lesz.)

• #2483 emvy félisten #39560925 #2481

  Új Válasz 2014-07-01 17:18:40 #2483

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2481 üzenetére

  Az miert fontos, hogy melyik szal? (Hacsak nincs UI thread.)

• #2482 #39560925 törölt tag #39560925 #2481

  Új Válasz 2014-07-01 17:03:40 #2482

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  válasz #39560925 #2481 üzenetére

  Hazafelé menet leírom hogy mit csináltam, hátha segít majd egyszer valakinek, bár nem egy nagy mágia.

• #2480 emvy félisten #39560925 #2479

  Új Válasz 2014-07-01 15:45:14 #2480

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz #39560925 #2479 üzenetére

  Szerintem:

  class A {
  void foo() {}
  };
  
  // stb..
  
  A a;
  std::thread thread_name(&A::foo,&a);

Új hozzászólás Aktív témák