"Objective-C" kalbos populiarumas išaugo "iOS" kūrėjų dėka

Verta nepamiršti, jog naudojant Objetive-C su ja dauguma programuotojų taip pat ir C kodą deda.

nieks to c kodo nededa, 99% (.99?) kodo objc, gali det jei nori, bet retai kada reikia. Beje c++ kodas taip pat leidziamas.

Na, jeigu ten daro kažką smulkaus tai jo Nekalbu apie mokyklinius projektus ir kokias mini programėles iOS, gal biški ne į temą ir pakomentavau nes turėjau mintyje ne tik iOS, bet ir OS X

Įdomu žinoti, kuria kalba (C++ vs objec.-C) parašytas kodas yra sparčiau vykdomas. Kas susiduriate su objektiniu programavimu, galėtų pasisakyti iš patirties.

Hoppipolla as ir turejau omeny Mac OS X ir tikrai ne mokyklinius projektus. kurmis, nieks nesuka galvos del tu keliu procentu efektyvumo, objc daug patogesnis, naudoji c++ tik jei reikia, bet tas buna gana retai. Greiciau c++ zinoma, nes tai zemesnio lygio kalba, asm butu dar greiciau bet nieks nevargsta su juo, nebent tau tie keli procentai sudaro skirtuma. Kai atsirado objc 2.0 properciai, garbage collector'ius ir t.t. dar maziau vargo liko programuojant. Pabandyk su asm parasyt aplikacija... laiko svaistymas. Kai tuo tarpu su objc susitampai butonus, prikabini action'us ir veikia, plius pateiktas visas kitas funkcionalumas: iCloud, failines duombazes, nustatymu failai, darbas su nuotraukom, undo/redo mechanizmai, controlai, visu ne neisvardysi, praktiskai viskas ko reikia - tas yra, nera - ieskai ir naudoji kad ir c/c++ koda.

Bet tai tie kaip tu pavadinai susitampymai ir tt čia yra ne kalbos privalumas, o XCode ant tiek gerai išdirbtas, jog generuoja kodą tvarkingai.

Kalba su tuo susijusi, kadangi elementus surisi butent su kode aprasytomis reiksmemis. Pati kalba be ispletimu ir irankiu butu mazai ko verta. Renkantis kalba reikia 90% skirti demesio butent i irankius ir framework'u funkcionaluma, ypac i taip kaip framework'ai suprojektuoti, pati kalba tai pagrinde sintakse ir semantika. Jei kalba ismokt galima per 2 dienas, tai galimybiu kalbos kartu su visais irankiais ir frameworkais gali uztrukti ir metus ar ilgiau.

C++ taip pat turi GUI programavimo kalbą Qt. O ji taip pat turi grafini GUI kūrimo įranki. Nors pačiam teko tik šiek tiek žiūrinėti, bet rimtai nenaudojau, nes tingėjau ant jos mokytis dirbti. Paviršutiniškai paskaičiau apie objc ir susidariau nuomonę, kad ji be Mac biblioteku nelabai skiriasi nuo C ar C++, tad naudojama tik ant Mac dėl tu bibliotekų. O visur kitur naudojama C arba C++.

Esi dares kazka su Objectyve C , Cocos 2D , Level Helper ? As pats programuot gerai tai nelabai. Pilkosios lasteles kazkaip ne tokio tipo, bet gal kam ir pritaikomos, jei komandoj. Gal net galeciau koki uzsakyma suorganizuot is FFG, gal ir siaip turiu ideju ka butent but galima suprogmamuot, kad bent kazkas pirktu, bet nelabai moku

Shinigami, Qt super dalykas yra, teko programuot. Tik jo ateitis dabar neaiski, nes Nokia nupirko Trolltech. Jei kodini su C++ tai tik Qt ir rekomenduociau. Taip, ObjC panasi i C ar C++, bet sakyciau pranasesne kalba, turinti daugiau ka pasiulyt, taciau tik Mac. _alvydas_, Su Cocos 2D ir Level Helper dirbt neteko, pagrinde Mac OS X programos, bet yra teke ir iOS app kurti.

, žemo lygio kalba - nebūtinai greitesnė. Teoriškai su asembleriu gali susiprogramuoti JIT, tail recursion, profiliavimu paremtą branch prediction, skirtingą kodo lygiavimą priklausomai nuo CPU pipelining savybių, dynamic inlining, cache preloading, variable aliasing/renaming ir t.t.. Bet niekas taip nedaro - nes faktiškai tai reikštų naujos virtualios mašinos su nauju P-kodu kūrimą. Senas geras pavyzdys: kažkada programuotojų labai mėgta sukeitimo operacija XOR AX,BX; XOR BX,AX su kiekviena architektūra pradedant nuo 386 yra vis neefektyvesnė. Modernūs kompiliatoriai ir JIT'ai dažniausiai ją sugeba pakeisti į NOP arba bent išvarto, kad AX ir BX taptų nepriklausomais kintamaisiais, o patį sukeitimą sumakaluoja su aplinkiniu kodu taip, kad jis gautųsi vos ne nieko nekainuojanti šalutinė pasekmė arba bent gerai lygiagretintųsi (neblokuotų magistralės, kai jos reikia kitiems skaičiavimams, neinvaliduotų kešo ir t.t.). Kur naudojami sudėtingi ir ilgai trunkantys matematiniai skaičiavimai (modeliavimuose ir pan.), neretai C ar asembleriu parašytas kodas perrašinėjamas Fortranu arba Java būtent dėl efektyvumo. Be to, dažniausiai tas greičių skirtumas nėra kritinis faktorius - tad specializuotos (ir atitinkamai - sudėtingesnės) bibliotekos naudojamos tik tuomet, kai jų tikrai reikia (pvz., kad minimizuotų GC). Juk nenaudosi LinearlyAlignedInt16Vector su visais jo apribojimais, kai užduočiai pilnai pakanka paprasčiausio ArrayList<Integer>?