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

• #2047 Vico87 tag

  Új Válasz 2013-04-15 22:14:26 #2047

  Ú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

  

  Vico87

  tag

  Szerintem a legegyszerűbb, ha bool[16]-ot használ, mivel úgy könnyen hozzá lehet férni az egyes "bitekhez," a kód szemléletesebb, és nem utolsó sorban ez egy tanulási célú házi feladat. Szerintem arra megy ki a játék, hogy implementáljon egy saját matematikai típust, operator overloadinggal.

  Az már más kérdés, hogy mennyire értelmes vagy életszerű maga a feladat.

• #2040 Vico87 tag Spam123 #2039

  Új Válasz 2013-04-14 23:00:33 #2040

  Ú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

  

  Vico87

  tag

  válasz Spam123 #2039 üzenetére

  Szia!

  Szükséged lesz további tagfüggvényekre is. Egyrészt decimálisból is kell konvertálnod kettes komplemensre, másrészt valahogy a hibákat is kell tudni jelezni (pl. overflow, underflow, nullával osztás, ...). Ami jó volna, ha implementálnád ezeket a műveleteket operátor túlterheléssel is, így tömörebb, olvashatóbb kódot is lehet majd írni a tesztelésre.

  A kettes komplemenses számábrázolás egyik előnye, hogy az alapműveletek úgy mennek, mint "sima" bináris számoknál egy-két apróságtól eltekintve. Az angol wikipédián szépen le is vannak írva, példákkal ([link]). Az osztásra sokféle módszer van ([link]), ha nem teljesítménykritikus a feladat, akkor elég a legegyszerűbb, naiv módszer, azaz a sorozatos kivonás, ami kb 5 sor kód, felhasználva a korábban implementált kivonást. Persze, ha gyorsan kell az eredmény, akkor a linkelt oldalon le vannak írva sokkal trükkösebb és egyben gyorsabb algoritmusok is.

• #1879 Vico87 tag jattila48 #1878

  Új Válasz 2012-10-26 21:54:10 #1879

  Ú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

  

  Vico87

  tag

  válasz jattila48 #1878 üzenetére

  Az egyik megoldás, ha Base** példányt vár a függvényed és létrehozáskor is Base**-ba pakolod a Derived példányaidat. Ez akkor jó, ha ki akarod használni a polimorfizmust és a kollekciód heterogén, azaz statikus típusa Base* tömb, de az egyes elemek dinamikus típusa elemenként eltérő.

  Ha biztosan csak Derived példányokat akarsz átadni és ez nem fog változni, akkor minek Base* tömb? A megoldás, hogy a függvényed Derived* tömböt kapjon.

  Megjegyzés: a fordító számára nincs különbség Base** és Base*[] között. Az, hogy számodra szemantikailag a két dolog eltérő, az jogos, de a szándékodat (hogy ez most egy Base* tömb, vagy pedig egy Base példányra mutató mutatónak mutatója) a tömb technikai megvalósítása (memóriaterületre pointer) miatt nem tudja megvalósítani a fordító. Csak akkor tudná kitalálni a pontos konverziót, ha pontosan tudná, hogy a Base* tömbödben mennyi példány van, de ezt nem tudhatja, mivel ez futási időben derül csak ki és függvényhívásonként nem konstans.

  Ez a konverzió olyan esetben veszélyes, amilyet írtál: egyik leszármazottból konvertálás másik ágon lévőbe, például a tömbödben nem csak Derived*-ok vannak, hanem Derived2*-ok is.

• #1839 Vico87 tag

  Új Válasz 2012-08-23 11:14:45 #1839

  Ú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

  

  Vico87

  tag

  A szerverekbe szánt chipsetekben szokott lenni random hardver (többnyire valamilyen kaotikus fizikai jelenséget idéznek elő és azt mintavételezik). Consumer chipsetekben ritka, ha jól tudom az Intel 810/815/840/845 chipsetekben volt csak.

  Szerintem kriptográfián kívül senkinek sincs szüksége valódi véletlenre, hanem elég ha "ránézésre" az. Sőt, a reprodukálható "véletlen" hasznos tud lenni (pl. könnyebb debuggolni).

• #1773 Vico87 tag birno #1772

  Új Válasz 2012-07-16 15:22:23 #1773

  Ú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

  

  Vico87

  tag

  válasz birno #1772 üzenetére

  Én ennek speciel C# + Entity Framework alapokon állnék neki, mert gyorsabban megoldható vele, mint C++ nyelven. Ezzel csak azt akarom mondani, hogy nem biztos, hogy ezen a példán keresztül akarod megtanulni a C++ nyelvet.

  A kétféle megoldást illetően (ha jól értem a két esetet) a második a jobb. Az adatbázis-kezelők nem szeretik a sok rövid kérést, mert fajlagosan jóval több overheaddel jár. Tárolni kliens oldalon elég sima listában, ha nem milliós nagyságrendű elemszámról van szó.

  Hülye kérdés, de miért nem egy kész megoldást használtok erre a feladatra? Azok érettebb és fejlettebb rendszerek, mint amit első próbálkozásra egy ember egyedül összerak egy még általa nem ismert programozási környezetben.

• #1758 Vico87 tag Davs #1756

  Új Válasz 2012-06-17 22:42:40 #1758

  Ú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

  

  Vico87

  tag

  válasz Davs #1756 üzenetére

  Én nem ismerek olyan IDE-t, ami C++ esetén is tudja ezt (bár tény, hogy nem használtam sokfélét ). Java és C# esetben sok dolog lényegesen egyszerűbb, ezért is "okosabbak" az IDE-k ezekhez a nyelvekhez (pl. C#-nál olyat is tud a VS, hogy kitalálja mit kell "include-olni" amikor eddig nem definiált típust használsz).

• #1733 Vico87 tag doc #1732

  Új Válasz 2012-06-13 14:44:07 #1733

  Ú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

  

  Vico87

  tag

  válasz doc #1732 üzenetére

  Nyugodtan. Van erről egy xkcd is.

• #1731 Vico87 tag Davs #1729

  Új Válasz 2012-06-13 14:32:17 #1731

  Ú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

  

  Vico87

  tag

  válasz Davs #1729 üzenetére

  Ahogyan doc is rávilágított, csínján kell bánni az inline-nal. A különbség az inline és a VC++ __forceinline között az, hogy egyrészt előbbi szabványos, míg utóbbi nem, másrészt az előbbi csak javaslat a fordító számára (amit olyan esetekben, amelyekben nem lenne jó, figyelmen kívül hagy), míg utóbbival kifejezetten kéred, hogy mindenképp inline-osítsa. Mint mindennel a programozásban, jól végig kell gondolni, hogy mit csinál az ember, és ha jó indoka van rá, akkor nyugodtan használja. Nem jön és esz meg a raptor, ha leírsz egy goto-t, __forceinline-t, amennyiben jó okod van rá. Különben jön és megesz.

• #1728 Vico87 tag proci985 #1724

  Új Válasz 2012-06-13 12:26:07 #1728

  Ú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

  

  Vico87

  tag

  válasz proci985 #1724 üzenetére

  Én így gondolom: ha elfogadható egy felügyelt környezet (Java VM, .NET CLR) overheadje (és az üzleti/web alkalmazások esetében az, webes esetben a PHP-t nem is említve), akkor a C++ függvényhívások overheadje is elfogadható. Ezeknél az alkalmazásoknál a tiszta, karbantartható kód az elsődleges szempont.

  Teljesítménykritikus esetben adott helyzettől függ, hogy mennyit vagyunk hajlandók áldozni az olvashatóságból/érthetőségből a teljesítményért. Néhány esetben megéri a mikrooptimalizálás, ahol már tényleg arra mész, hogy minimalizáld a cache-miss-t, az elágazásokat, stb... de ez általában nem triviális kódot eredményez és kevés esetben hoz látványos pluszt. Persze ha ezt a kódot megfelelően dokumentálod, akkor nincs gond.

  A Visual C++ tud olyat, hogy __forceinline, ami egyrészt kierőszakolja egy függvény inline-osítását, másrészt így az optimalizáló jobb eredményt ad, mert a "hívást" a kontextusával együtt képes feldolgozni.

• #1713 Vico87 tag WonderCSabo #1712

  Új Válasz 2012-06-11 11:08:36 #1713

  Ú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

  

  Vico87

  tag

  válasz WonderCSabo #1712 üzenetére

  Eclipse-t eddig csak Javara használtam, szóval nincs tapasztalatom a C++ képességeiről. Az igaz, hogy az Intellisense egy rakás "zajt" is felkínál, főleg, hogy ugye Windows alkalmazásoknál a windows.h miatt egy csillió deklaráció közül kell kikeresni a dolgokat.

  Egy kis ideig használtam Code:: Blocks-ot. Ami tetszett, hogy kis egyszerű, minimalista a nagyágyúkhoz képest, viszont a kódkiegészítése nem a legjobb, ami miatt sokat kell gépelni.

• #1706 Vico87 tag WonderCSabo #1705

  Új Válasz 2012-06-11 00:37:29 #1706

  Ú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

  

  Vico87

  tag

  válasz WonderCSabo #1705 üzenetére

  Szerintem nem. Alapból gépeléskor nem, csak függvényhívás nyitó zárójelénél, tagpointernél (->) és scope operátornál. Azt külön kell engedélyezni (és alapból tiltva van), hogy úgy működjön, mint C#-nál, azaz bármit gépelsz, egyből felkínálja. Legalábbis eddig nekem VS2005 óta mindegyik alapból így működik (friss OS install utáni telepítéskor is, szóval joggal feltételezem, hogy ez a default).

  Szerk.: C# esetén viszont az a default, amit mondasz.

• #1704 Vico87 tag pckownz #1696

  Új Válasz 2012-06-10 22:36:44 #1704

  Ú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

  

  Vico87

  tag

  válasz pckownz #1696 üzenetére

  C++ esetében nem indul automatikusan az Intellisense gépeléskor. Ctrl+Space kombóval lehet beindítani, vagy a beállítások között bekapcsolható, hogy gépeléskor egyből felkínálja a lehetőségeket. Ctrl+Shift+Space kombóval pedig függvények paraméterlistája kérhető (ha egy függvényhívás zárójelei között vagy). Azt vedd figyelembe, hogy nem lesz olyan pontos és gyors, mint egy Pascal vagy C# esetében, mert C++ nyelvet nehezebb feldolgozni.

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