DevBlox

Taip, linked list'as. Manau supranti, ką programa daro. Internete daugiau negu reikia paaiškinimų kaip linked list'ai veikia. Labai geras source'as čia.

Kodėl rašai c++ kodą, bet naudoji c bibliotekas? Suprasčiau jei būtų konkreti ir rimta priežastis, bet dabar nematau tikslo, nes c++ bibliotekos ne ka blogesnės, tikrai patogsnės ir aiškesnės nei c bibliotekos. O dabar viskas labai maišosi, bloga praktika taip daryti, geriau palaikyti vientisumą.

Kad kurti app'sus reikia tikrai neblogai išmokti pagrindų visų progamavimo, nes prasidės visokių bibliotekų naudojimas ir tt, o jei tų pagrindų neturėsi tai užsikasi. Manau gerai kad C++ renkiesi, išmoksi ir low-level ir high-level programavimo, tik gali maišytis viskas pradžioje, nes visko labai daug, kalba plati. Jei viskas maišosi per daug tai gali nuo C pradėt, nes nuo pačio žemiausio lygio pradėti gal pravers tada, nes išmokti smulkiausius dalykus yra naudingiau, išmoksti suprasti kaip viskas "po kapotu" dirba, o po to gali eiti toliau, į vis abstraktesnes kalbas (todėl ir C++ gerai, n

Pamislijau kiek ir manau jog geriausia būtų naudoti OpenMAX kartu su OpenGL ES (arba dar geriau su OpenVG, bet su juo neteko susidurti tai ir informacijos jokios nedrįstu pateikti), pavaizduotą lentelėje. Paguglinęs radau keletą šaltinių kuriais naudotis galėtum. Apie OpenMAX: http://ccppcoding.blogspot.com/2012/09/openmax.html Taip pat tame puslapyje daug naudingos info apie Linux galima rasti, visai naudingas puslapis. Dekodavimo tutorial: http://www.raspberrypi.org/forums/viewtopic.php?f=33&t=57721 Tau tektų atlikti dekodavimą, paversti .svg į tekstūrą ir per OpenGl ES ant ekrano

Tiesa gali ne per c++ viską daryti jei nebūtina, per scriptus ir prezentacines progamas paprasčiau būtų viską realizuoti :) Tutorialų mažokai, bet esu matęs, pabandysiu surasti ir įdėsiu į šį atsakymą :).

Gali bandyti naudotis SDL bibliotekomis. SDL turi labai daug naudingų funkcijų, labai patogiai galima žaidimukus programuoti, nes turi gerą sąryšį su OpenGL. Šiuo atveju tau užteks SDL rendererio manau, jei gerai pamenu galima tiesiogiai įkrauti .svg failus. Yra tik vienas labai rimtas niuansas su grafika ant RPi: X desktope nėra hardware acceleration, nes X neveikia per EGL, o RPi GPU tik per EGL ir gali, todėl reikia atitinkamai programuoti per specialias bibliotekas, kad ekraną sukurti. Todėl paprastai per SDL padarius gali neveikti tiesiog, o aš pats niekad nebandžiau RPi desktope SDL re

Pavojus prarasti duomenis egzistuoja visada, tai, kad nebepalaikoma xp, nepaveiks tikrai to. Vieną kartą windowsai gali neuzsikrauti dėl disko gedimo arba nepriežiūros (greičiau jau nuo netvarkos darymo su softu). Na tavo tėvukai nemanau kad su tuo kompu daug kanors darys apart bankų, mokesčių mokėjimų, emailų ir pan. Tuomet užteks gerai sutvarkyto softo, antivirusinės ir tas xp kompas dar tiek pat laikys drąsiai jei nenusprogs silikonai nuo amžiaus. Iš esmės nepalaikomi xp reiškia: daugiau jokių update ir saugumo skylių lopymu (tik reikia atminti, jog virusus 90% įsileidžia patys vartotojai

Kadangi pc skirtas daugiau editinimui, tai sakyčiau verta investuoti ne į 4770k, o 4970k cpu. Jis turi smarvės multithreaded darbams. Grajų irgi nenuskriausi, o ir greitai išeis nauji grafikos API (pvz DirectX 12), tai tas cpu dar geriau pasitarnaus. To cpu socketas berods kitas, tai ir motininę kitokią reikės imti. Aušintuvas geras, dar gali pasižiūrėti Be Quiet! Shadow Rock 2 (arba 3), tie turi masyvius radiatorius, tai gali užsimesti pora galingesnių aušintuvų (pvz kurie dedasi ant jau paminėto Noctua NH-D14), manau gera kombinacija gautųsi.

Linuxai man asmeniškai visiškai pakeitė Windowsus, kadangi nelabai geiminu ir nedaug dirbu su tokiom programom kaip after effects. Bet ir ant linuxu pagrajinti neblogų žaidimų galima ir pakaitalus daugeliui programų rasti nėra sunku. Todėl jei neturi rimtų priežaščių likti prie Windowsų, vien Ubuntu turėti bus tikrai pilnavertis variantas. Viskas priklauso nuo poreikių :). Jei vis dėlto planuoji dual boot darytis tai procesas labai paprastas: pirma įsirašai Windowsus, paskui Ubuntu, leidi Ubuntu perrašyti boot sektorių, o bootloaderis turėtų aptikti Windowsus automatiškai, kurią os norėsi pa

Antras variantas daug paprastesnis, tiesiog pasidaryk tą langa ir su mygtuko paspaudimu išsikviesk CreateWindow(); ar kažką tokio. Tik tiek galiu patart, nes jokios info nedavei, nei API nei ko panašaus ir tikiesi, kad magiškai sprendimą pateiks kasnors :D.

Nevisada naudojamas kodas yra tavo kodas, todėl debuginti nevisada yra variantas, kartais tiesiog negali, būna tokių situacijų sočiai. Manau implementerio atveju explicit panaudoti ir užkirsti kelią tokioms klaidoms yra būtinybė, klientas nežinos kuom skiriasi tie konstruktoriai, jei dokumentacija ir prototipas nieko nepasakys (nors tikrai turėtų). Implementerio uždavinys visada yra rašyti funkcionalų ir paprastai naudojamą kodą. Išleisi tarkim closed source API, ir planuoji debug simbolius įkompiliuoti, kad pažiūrėtų klientas kuris konstruktorius iškviečiamas? Nemanau. Taigi prieš įžūliai ats

Čia pavyzdys yra, o ne kodas iš realaus projekto. Savaime aišku, kad čia lengva.

Gelbėja nuo ne to konstruktoriaus iškvietimo, kurio nereikia, neleisdamas tau iškviesti to konstruktoriaus atitinkamomis sąlygomis. Manau sunkoka būtų rasti klaidą, jeigu iš dviejų panašių konstruktorių iškviestum ne tą, o tada kodas lyg ir veikia, bet lyg ir ne :). pvz. #include <iostream> #include <string> using namespace std; class Obj { public: explicit Obj(int a) { eilute = "int"; } explicit Obj(char a) { eilute = "char"; } string eilute; }; int main() { Obj a = 's'; // Mes errora, bet jeigu

Serverių nuoma manau variantas geras. Jeigu kompanijos serveriuose taip sparčiai auga duomenys ir neįmanoma vytis patiems tai reikia galimybės plėsti serverio pajėgumą pagal poreikį, savo serverį turėdamas taip nepadarysi, nebent patinka žiūrėti kaip pinigai dideliais kiekiais eina serverių klasės hdd (paprasti desktopo hdd palūš nuo tokių apkrovų) ir cpu pirkimui, o ir hdd tokie ir Xeonai, kaip žinia nėra pigus reikalas :).

Kai iškvieti fstream::open() arba fstream'o kontruktoriu kodo bloke, tai jis liks atidarytas iki pat to bloko galo, tada iškviečiamas destruktorius. Atidarydamas faila tu informuoji OS, kad failas yra naudojamas, todėl OS neleidžia su tuo failu nieko daryti niekam išskyrus tam fstream'ui, kol tas failas nėra uždaromas. Todėl visada, net kai ir nebūtina, patariu priprasti iškarto iškviesti fstream::close(), kad nebūtų tokių netyčiukų :).