Mobili versija | Apie | Visos naujienos | RSS | Kontaktai
 
Vartotojo vardas:
Slaptažodis:
Atsiminti
Login with a social network:

Jūsų požiūris

Aktyvios diskusijos

Ieškoti forume


Išsami paieška

 [ 20 pranešimai(ų) ] 
 
Naujos temos kūrimas Atsakyti į temą Pagrindinis diskusijų puslapis » Technologijos » Informacinės technologijos
Žinutė Autorius
  Standartinė   Parašytas: 2020-08-11, 22:34 
     
Bent jau pascal kalboje tai buvo vienas lengviausių būdų perimti vartotojo inputą - readkey funkcija. C turėjo getchar() ir getc(stdin). Tokią funkciją tiesiog numeti bet kur, ir visas sprendimas.
Realiai ankščiau daug programuotojai nesivargindavo, kad žmonėms būtų patogu, nes ne pensininkai ir angliakasiai prie kompų sėdėdavo. Pagrindinis dėmesys būdavo skirtas algoritmui, o ne vartotojo sąsajai. Dabar laikai kiti, ir dažnai sąsaja kuri prašo paspausti "OK" mygtuką užima šimtus eilučių kodo. O jei ne naudoja papildomą biblioteką tam, kuri užima tūkstančius eilučių kodo.
Aišku galime sau tai leisti nes kompiuteriai nėra tokie lėti kaip tais laikais kai tik atsirado ekranai.
  • 0




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 10:10 
     
conjurer rašė:
Bent jau pascal kalboje tai buvo vienas lengviausių būdų perimti vartotojo inputą - readkey funkcija. C turėjo getchar() ir getc(stdin). Tokią funkciją tiesiog numeti bet kur, ir visas sprendimas.
Realiai ankščiau daug programuotojai nesivargindavo, kad žmonėms būtų patogu, nes ne pensininkai ir angliakasiai prie kompų sėdėdavo. Pagrindinis dėmesys būdavo skirtas algoritmui, o ne vartotojo sąsajai. Dabar laikai kiti, ir dažnai sąsaja kuri prašo paspausti "OK" mygtuką užima šimtus eilučių kodo. O jei ne naudoja papildomą biblioteką tam, kuri užima tūkstančius eilučių kodo.
Aišku galime sau tai leisti nes kompiuteriai nėra tokie lėti kaip tais laikais kai tik atsirado ekranai.


Jei tau atrodo, kad dabar interfeisas patogesnis - nematei enterprise lygio programinės įrangos.

pigūs appsai po 1$ daromi patogiai, nes vartotojas jų nenaudos. Korporatyviniuose sprendimuose niekas nesivargina dėl to + pati logika sudėtinga. Tai išeina kažkokia painiava.
  • 0




Užsiregistravo: 2009-07-13, 13:38
Pranešimai: 4476
Reputacija: +1431
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 11:09 
     
HardAxe rašė:
Jei tau atrodo, kad dabar interfeisas patogesnis - nematei enterprise lygio programinės įrangos.

pigūs appsai po 1$ daromi patogiai, nes vartotojas jų nenaudos. Korporatyviniuose sprendimuose niekas nesivargina dėl to + pati logika sudėtinga. Tai išeina kažkokia painiava.


Visokių būna. Daug kas naudoja google docs. Kiti kas turi pinigų, nusiperka microsoft office, o tie kas turi proto naudoja Libreoffice. Bet kalbant apie programinę įrangą skirtą dirbti su specifiniais duomenimis, specifinėmis duombazėmis, tai taip įsivaizduoju, kad interfeisa gali būt užsilikę nuo praeito tūkstantmečio.

Tam tikra prasme yra pigiau apmokinti žmones dirbti komplikuota programine įranga, nei tą įrangą padaryti patogesnę. Žmones ar šiap ar taip reikės mokinti, o programuoti labai patogius interfeisus užima daug laiko, ir varžo vėlesnių funkcijų kūrimą. Be to senesnės programos, be krūvos modernių UX sprendimų dažnai veikia greičiau, ir tai yra vienas iš tikslų, kai nori didinti darbo efektyvumą. Jei darbuotojas turės laiko atsidaryti facebook, kol programos interfeisas dirbs, tai jis gali per ilgai užsiskrūlinti tenai.

Kita vertus tu gauni pinigus už tai kad dirbi "coorporate" programine įranga. Ir tu moki pinigus kad galėtum naudotis patogia programine įranga.
  • 0




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 15:27 
     
Kalba eina ne apie wordą, bet aukštesnio lygio sistemas - dokumentų valdymą (aka sharepoint sprendimus kuriuose gyvena tie dokumentai), visokias elektronines paslaugas, ypač iš institucijų pusės (epaslaugos, sodros portalai, elektroniai receptai) ir t.t. Kažka konkrečiau nebent pm papasakosiu :)

na... korporatyviniai sprendimai turi reikalavimus, kuriuos reikia tenkinti, jeigu kažkas nereikalavo patogaus UI o tik galimybę atlikti darbą, dažniausiai tuo ir pasibaigia.
Esu dirbęs prie ne vieno vidutinio/didelio projekto, tame tarpe visiškai naujo. Galutinio vartotojo poreikiai yra kažkelintoj vietoj.
Svarbiausia biznio logika ir pakenčiama greitaveika. Klientas tam neskiria pinigų, o gamintojas - laiko. Yra kontraktai kas turi veikti ir valio.
Šiuo atveji vartotojai - vidine sistema dirbantys įmonės darbuotojai, tai nėra civiliai klientai naudojantys sistemą.

Ir visa tai +/- apibūdina situaciją dokumentų valdymo, sveikatos, transporto, telekomunikacijų sektoriuj. Beveik be išimčių.

Aišku padaryti didelę sistemą jau savaime iššūkis. Padaryti didelę ir stabiliai veikiančia - pastangų reikalaujantis darbas. O jei dar nori patogios... Niekas neįperka tokio lygio personalo su projekto biudžetu :(

Tuo pačiu į galutinius klientus orientuotos sistemos kažkaip sugeba būti naudotinis (banko portalai ir t.t.).
  • +1




Užsiregistravo: 2009-07-13, 13:38
Pranešimai: 4476
Reputacija: +1431
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 16:42 
     
Kas galit parekomenduot online programavimo kursa arba knyga? Ketinu turet bishki laisvo laiko neuzilgo, gal reiketu tam isnaudot. As kazkiek kodinu, pagrinde C++ ir tam, kad butu galima is PC valdyt tai kas sukonstruota (ne, omenyje turiu ne arduino). Su algoritmu logika ir su sintakse viskas gal ir OK. Problema ta, kad mano kodinimas greiciau yra monkey see monkey do, as neturiu supratimo kaip turi but daroma tvarkingai, kaip kodint kad veiktu stabiliai ir t.t. I programuotojus nei dabar nei po to kandidatuot neketinu lyg ir, tiesiog noretusi turet bent koki supratima kaip turi atrodyt normalus kodas, kas yra gera praktika ir t.t.
  • 0




Užsiregistravo: 2015-07-11, 23:07
Pranešimai: 283
Reputacija: +157
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 18:21 
     
jull rašė:
Kas galit parekomenduot online programavimo kursa arba knyga?

O ką konkrečiai nori daryt? Gali viską daryti su C arba C++, bet kiekvienam dalykui yra geriausiai tinkanti aukštesnio lygio programavimo kalba. Jei nori kažką automatizuoti visada patogiau dirbti su interpretuojamom kalbom.
  • +2




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 19:18 
     
conjurer rašė:
jull rašė:
Kas galit parekomenduot online programavimo kursa arba knyga?

O ką konkrečiai nori daryt? Gali viską daryti su C arba C++, bet kiekvienam dalykui yra geriausiai tinkanti aukštesnio lygio programavimo kalba. Jei nori kažką automatizuoti visada patogiau dirbti su interpretuojamom kalbom.


Visu pirma noriu turet daugiau ziniu nei turiu dabar turbut... ir gal turet ju bent tiek, kad savo koda negeda kam nors parodyt butu, jei kada prisireiks.

C++ naudoju aplinkybiu priverstas, visokie sensoriu, servo kontroleriai, testavimo iranga dazniausiai turi C++ library, puse tik C++. Kazka esu viena ausim girdejes, kad cia ne visada geriausias pasirinkimas.

Viena ausim esu girdejes ir kuo skiriasi interpretuojama ir kompiliuojama kalbos. Kiek suprantu, interpretuojama labiau pritaikyta konkreciam tikslui, letesne. Man tas nera labai patrauklu, mano situacijoj kuo universaliau ir greiciau tuo geriau. Kad iliustruot koks mazdaug mano taskas, siuo metu salia lovos turiu (vieta kur as paprastai "gyvenu" nuo 8 iki 5 uzdaryta jau kelis menesius, atidarys gal rugseji, jei covid neisisiautes):

Endoskopo sviesos saltini
Judesio sekimo kamera
Toki CCS sensoriu, su kontroleriu
Signalu generatoriu
Osciloskopa

Visi programuojami/duomenys loginami skaitmeniu budu, visi turi nors C++ library. Iskyrus judesio sekimo kamera, nei vienas nenaudojamas pagal pirmine paskirti:) Paprastai prie sito bardako priklauso dar 3-5 servo, keli atskiri encoderiai ir t.t.(likes hardas per sunkus ir uzima per daug vietos kad parsitempciau namo). Viskas veikia vienoj dalinai automatizuotoj sistemoj. Sistema custom, pirma ir greiciausiai paskutine. Mano taskas yra kad visa tai veiktu kaip as noriu, logintu duomenis kuriu man reikia, skaiciuotu visokias dinamikas kinematikas, interpoliuotu, kad butu galima valdyt is klavos, kalibruot, keist parametrus ir t.t.

Siaip viskas veikia, bet mazai vilties, kad as, neturedamas net baziniu ziniu (paskutinis kodas kuri rasiau pries sita buvo turbo Paskaly, vidurinej mokykloj, daug metu atgal) visa tai darau kaip priklauso. Pats esu kitos srities inzinierius, tai zinau puikiai, kad tarp "siaip taip funkcionuoja" ir "padaryta kaip priklauso" yra didelis skirtumas. Tai as noreciau bent suprast, kas pas mano programinime yra tinkama praktika, o kas - kolhozinimas. To kas jau sukodinta as keist neketinu, bet ateity noreciau turet apie tai supratima.
  • 0




Užsiregistravo: 2015-07-11, 23:07
Pranešimai: 283
Reputacija: +157
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 20:42 
     
jull rašė:
Visu pirma noriu turet daugiau ziniu nei turiu dabar turbut... ir gal turet ju bent tiek, kad savo koda negeda kam nors parodyt butu, jei kada prisireiks.

Dėl to nesijaudink. Tavo kodas visada atrodys blogas kitiems, nes turėsi savo įpročių kurie nesutaps su kitų žmonių įpročiais. Kolega deda tuščia eilutę, po kiekvienos eilutės, ir dešimtis tuščių eilučių tarp funkcijų. Jam tai atrodo gražu, mane žiauriai užknisa. Taip pat visada buvo debatai, ar 4 tarpai, ar tabas. Simbolis "{" toje pačioje ar naujoje eilutėje. Dėl to dauguma projektų turi savo kodinimo standartus. Jei to nebūtų daug programuotojų išprotėtų arba nužudytų vieni kitus. Asmeniškai man nepatinka 80% profesionalių programuotojų kodo. Dalis priežasčių yra pagrįstos, dalis skonio reikalas.

jull rašė:
C++ naudoju aplinkybiu priverstas, visokie sensoriu, servo kontroleriai, testavimo iranga dazniausiai turi C++ library, puse tik C++. Kazka esu viena ausim girdejes, kad cia ne visada geriausias pasirinkimas.

Viena ausim esu girdejes ir kuo skiriasi interpretuojama ir kompiliuojama kalbos. Kiek suprantu, interpretuojama labiau pritaikyta konkreciam tikslui, letesne. Man tas nera labai patrauklu, mano situacijoj kuo universaliau ir greiciau tuo geriau.

Na priklauso. Interpretuojamą kodą šiek tiek lengviau migruoti tarp operacinių sistemų. Bet nepanašu kad tau tai aktualu. Kompiliuotas kodas dažniausiai greičiau veikia. Bet interpretuojamą lengviau taisyti, nes nereikia kompiliuoti po kiekvieno pataisymo. Taigi python yra viena geriausių programavimo kalbų pradžiai. Ji gan greita, jos sintaksė skatina rašyti gražiai atrodantį kodą, ir tavo atveju yra daug bibliotekų įvairiems įrenginiams. Raspberrypi tai viena iš pagrindinių kalbų, su kuria valdoma elektronika. Tačiau jei rašai kodą su C++ (o gal ir C), tai rašyk toliau. Sugaiši daugiau laiko, bet geriau mokėsi programuoti.

jull rašė:
Visi programuojami/duomenys loginami skaitmeniu budu, visi turi nors C++ library. Iskyrus judesio sekimo kamera, nei vienas nenaudojamas pagal pirmine paskirti:) Paprastai prie sito bardako priklauso dar 3-5 servo, keli atskiri encoderiai ir t.t.(likes hardas per sunkus ir uzima per daug vietos kad parsitempciau namo). Mano taskas yra kad visa tai veiktu kaip as noriu, logintu duomenis kuriu man reikia, skaiciuotu visokias dinamikas kinematikas, interpoliuotu, kad butu galima valdyt is klavos, kalibruot ir t.t.


jull rašė:
Siaip viskas veikia, bet mazai vilties, kad as, neturedamas net baziniu ziniu (paskutinis kodas kuri rasiau pries sita buvo turbo Paskaly, vidurinej mokykloj, daug metu atgal) visa tai darau kaip priklauso. Pats esu kitos srities inzinierius, tai zinau puikiai, kad tarp "siaip taip funkcionuoja" ir "padaryta kaip priklauso" yra didelis skirtumas. Tai as noreciau bent suprast, kas pas mano programinime yra tinkama praktika, o kas - kolhozinimas. To kas jau sukodinta as keist neketinu, bet ateity noreciau turet apie tai supratima.


Programavime nėra tokio dalyko kaip universalaus standarto kaip reikia rašyti kodą. Taip priklauso nuo daug dalykų. Vienas iš pagrindinių, kiek žmonių dirbs su tuo kodu. Jei daug, reikia stengtis kurtis objektinį kodą. Jei ne, procedūrinis yra patogesnis, ir minimaliai greitesnis. Kitas dalykas, ar tu nori padaryti veikiančią programą, ar biblioteką, kurią gali pritaikyti skirtingoms programoms. Daug gero modernaus kodo yra bibliotekos. Pvz webkit biblioteka naudojama chrome, opera, brave naršyklėse. Nesvarbu kurią naršyklę iš jų naudosi, puslapiai elgsis daug maž taip pat. Taigi jei planuoji rašyti softą, kurį planuoji platinti, kad kiti galėtų juo naudotis, labiau apsimoka jį kurti kaip biblioteką. Dar vienas niuansas duomenų apsikeitimas. Jei loginamus duomenis atvaizduos kitą programinė įrangą, gali rinktis tarp skirtingų duomenų formatų, nuo plaintext, iki json/yml/xml. Tam tikro tipo duomenims gal net savo formatą galima suskurti, jei niekas kitas netinka. Čia tik tiek galiu pasakyti dėl tavo projekto nes daugiau nelabai įsivaizduoju ką jis daro.

Dėl bendrų dalykų, tai galiu išvardinti kelis kuriuos rekomenduoju:

* Naudok kodo versijavimo sistemą. Ankščiau buvo kažkas populiaru, kažkas, ne, bet dabar yra GIT. Ir nėra geresnės sistemos. Jei viską darai lokaliai, savo kodo kataloge inicializuoji gitą, ir po pakeitimų pridedi modifikuotus failus, ir komitini. Gali naudoti githubą, bet tai nėra būtina. Asmeniškai mėgstu gitwebįrankį, jis žiauriai greitas, ir bent jau man patogesnis nei githubas. Rekomenduoju paskaititi šitą knygą https://git-scm.com/book/en/v2, bet nebūtinai visą. Jei dirbsi lokaliai užtenka 3 pirmų skyrių, juose yra visi info kaip veikia GIT'as.

* Turėk patogų buildinimo skriptą. Tavo atveju reikia makefile apsirašyti taip, kad kompiliavimas būtų vienos komandos/vieno paspaudimo reikalas. Kompiliavimas su gcc komandinėje eilutėje nėra gera praktika. Jei naudoji kokį IDE, reikia apsižėti kaip jis gali dirbti su makefile.

* Naudok unit testerius. Čia gal būt sudėtingiausia dalykas, bet viena geriausių programavimo praktikų. Pasirašai funkciją, pasirašai jai unit testą. Kikeviena kalba turi savo bibliotekas/softą tam. Įsivaizduok, turi funkciją konvertuoti temperatūrą iš F į C. Testas būtų paduoti tai funkcijai tokias reiškmes kaip -8000, 0, 30, "labas". Kiekvienu atveju turi apsirašyti norimą funkcijos elgesį. Po kiekvieno kompiliavimo yra gera praktika paleisti unit testerį, kuris gana greitai parodys kokios funkcijos elgiasi neteisingai. Užima laiko, bet dingsta didesnė dalis bugų.

* Turėk savo kodinimo stilių, ir visada juo vadovaukis savo projekte. Jei projektas turi aprašytą savo stilių, naudok jį. Tai yra ar naudosi tarpus ar tabus, jei tarpus, tai 2, 3, ar 4. Kaip aprašai funkcijų pavadinimus? CapitalCase, camelCase, lower_case. Praktiškai visi organizaciniai dalykai, nuo programos ir kodo failų pavadinimų, iki to kaip atrodo kodas. Jei viskas bus daug maž vienoda, kodas visada atrodys gerai.

* Naudok klaidų gaudymo mechanizmus. Pvz nori atidaryti failą ar resursą. Pirmas žingsnis yra patikrinti ar tas resursas egzistuoja, bet tai gali būtų papildomi systemcall'ai. Tačiau kai atidarinėji failą verta naudoti try-catch mechanizmą. Jei atidarinėji resursą irgi verta pasiaiškinti ką galima catchinti, ir kokią klaidą raportuoti.

* NIEKADA nepasitikėk userio inputu, nes jei tas useris esi tu. https://wpollock.com/AJava/TesterInABar.txt. Jei yra galimybė apriboti userio inputą, jį verta apriboti. Jei priimami stringai iš jo, reikia juos tikrinti. Jei gali įvesti failo pavadinimą, reikia būti labai atsargiu. Jei dirbama su tinklu ar alokuojama atmintis, reikia gerai apgalvoti kas gali būti blogai tame. Čia nėra griežtų taisyklių. Asmeniškai mėgstu apriboti galimus simbolius su regex'u.

* Venk rekursijos. O jei negali jos išvengti, apribok ją. Jei manai kad tavo tavo funkcija turėjo susitvarkyti greičiau nes per milijoną ciklų, stabdyk rekursiją po milijono iteracijų.

* Nera svarbu, bet apsimoka patestuoti programos vykdomus "sytemcalls". Linuxe tai galima atlikti su programa strace, o windows deje nesidomiu, tai nieko nepasakysiu tuo klausimų. Strace atveju galima nustatyti kokie systemcalls buvo daromi, ir kiek laiko jie užtruko. Kartais pamatai, kad programa pradeda dirbti su resursai, su kurias net nenori dirbti, ir nuo čia galima spręsti potencialius lėtumo sprendimus. Taip pat ir library calls (linuxe ltrace).

* Jei nori kurti daugiakalbį projektą naudok gettext. Nėra nieko geriau, o savadarbiai sprendimai dažnai turi visas tris problema kurias gettext sprendžia - veikia lėtai, nepalaiko skirtingų daugiskaitos formų, yra nepatogūs versti.

Sakyčiau čia yra pagrindiniai dalykai. Visa kita jau kalbos niuansai. Pythonas tave verčia rašyti gražų kodą, nes jis kitaip neveikia. Ruby verčia tave kurti kodą taip kaip kuria kiti nes tokia jo filosofija (praktiškai religija). PHP yra visiškas bardakas, ir jame gerą kodą parašyti yra sunkiausia. Kai dirbi su C/C++ gerą kodą sunku parašyti, nes ne visada panaudosi geriausią algoritmą. Dėl to kartais viena integruota php funkcija geriau veiks, nei neoptimalus algoritmas parašytas su C. Kol įsigilini į funkciją kurią darai, ir randi visas alternatyvas, ir išsirenki geriausią, tavo kodas bus geras.
  • +2




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 22:40 
     
conjurer rašė:
Čia tik tiek galiu pasakyti dėl tavo projekto nes daugiau nelabai įsivaizduoju ką jis daro.


Naudojamas testint kelias susijusias idejas medical devices srityje ir tiek, nieko ten nei labai gudraus, nei labai isbaigto. Robotine + motion trackinama sistema testavimui, taip galetume apibendrint. Viesint pats negaliu, institucija paviesins kai baigsis triju metu moratoriumas po galutiniu rezultatu atidavimo.

Siaip, sita projekta as uzbaigsiu su tom ziniom kurias turiu, sekanciam, jei toks bus ir vis dar teks jam kodint paciam, noreciau daryt zinodamas daugiau.


conjurer rašė:
The first customer walks into the bar and asks where the bathroom is. The bar catches fire and burns to the ground.


:) skamba pazystamai.

Maza dali is to ka parasei esu girdejes, kai ka uzteko ziniu suprast, likusia dali pagooglinsiu.

Dekui, kad nepatingejai parasyt, bandysiu gilintis ir vadovautis.
  • +1



Paskutinį kartą redagavo jull 2020-08-13, 00:12. Iš viso redaguota 5 kartus.


Užsiregistravo: 2015-07-11, 23:07
Pranešimai: 283
Reputacija: +157
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-12, 23:18 
     
Dar vienas pastebėjimas gero programavimo: netikėk kitais programuotojais. :)

Ne karto teko skaityti komentarus kuriuose yra ginčijamasi ar "tas dalykas" yra gerai ar blogai. Pav.:
buvo ginčas, ar galima naudoti "unsignet int" ar geriau visur naudoti "int". Kai kas net kratosi pamatęs "unsignet int", kitas programuotojas kaip tik jį dažnai naudoja.
Mano nuomone "unsignet int" yra įrankis tinkantis tam tikram darbui. Jei tu juo nemoki naudotis tai nėra įrankio problema. Dažnai net nėra realaus skirtumo ar tu naudosi "int" ar "unsignet int". Viskas priklauso nuo konkrečios situacijos, o ne nuo įrankio. Bet ginčai čia nesustojantys ir be atsakymo.
  • 0


_________________
Propaganda


Vartotojo avataras

Užsiregistravo: 2010-07-29, 19:55
Pranešimai: 5517
Reputacija: +1720
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 00:13 
     
jull rašė:
likusia dali pagooglinsiu

Jei ko labai nesupratai, galiu patikslinti.
Jei darbas skirtas prisidėti Raides prie vardo, C/C++ tinkamiausios kalbos mano nuomone. Žemesnio lygio visada yra labiau mokslinės. Be to, mano nuomone, jei dirbama su medicina, Unit testai yra privalomi.


Shinigami rašė:
Dar vienas pastebėjimas gero programavimo: netikėk kitais programuotojais. :)

Ne karto teko skaityti komentarus kuriuose yra ginčijamasi ar "tas dalykas" yra gerai ar blogai. Pav.:
buvo ginčas, ar galima naudoti "unsignet int" ar geriau visur naudoti "int". Kai kas net kratosi pamatęs "unsignet int", kitas programuotojas kaip tik jį dažnai naudoja.
Mano nuomone "unsignet int" yra įrankis tinkantis tam tikram darbui. Jei tu juo nemoki naudotis tai nėra įrankio problema. Dažnai net nėra realaus skirtumo ar tu naudosi "int" ar "unsignet int". Viskas priklauso nuo konkrečios situacijos, o ne nuo įrankio. Bet ginčai čia nesustojantys ir be atsakymo.



Nu čia labai paprastas atsakymas. Jei nežinai kas gali būti per skaičiuos, naudoji signed. Jei žinai kad tai bus tik teigiamas, ir žinai jo maksimalią įmanoma reikšmę kartais apsimoka naudoti unsigned, kad nereikėtų paties int ilginti.

Viena iš įdomesnių problemų yra Y2k38, kuri atsiranda dėl signed int 32 naudojimo. Dėl to 2038 metų sausio devynioliktą dieną prasideda 1901 metų gruodžio trylikta. Tai atsitinka dėl "integer overflow", kuris pasikeičia į pačia ankščiausią datą, kurią galima išsaugoti 32 bitų singned integeriu. Taigi šiuo atveju norint padaryti kompiuterius ilgiau veikiančius būtų gerai tą integerį pakeisti į unsigned, bet tada ankčiausia data kurią galime aprašyti bus 1970 sausio pirma. Taigi abu variantai gana absurdiški, bet unsigned ilgiau veiks (iki 2106 vasario), ir kai kas tai gali naudoti kaip sprendimą.
Labiau verta pereiti prie 64 bitų integerio. Bet šiuo atveju net neverta žiūrėti į unsigned, nes tai būtų gana kvailas sprendimas - datas galėtum aprašyti tik nuo 1970 metų, nors ir labai toli į ateitį. Jei turi signed 64 bitų integerį, gali aprašyti datas senesnes nei spėjamas visatos amžius, ir tokias kurių saulės sistema neišgyvens. Taigi to kaip ir užtenka.

Kitas dalykas yra kai tu sukuri sistemą su produktais, ir produktai turi savo ID, kas yra skaitinė reikšmė. Tokiu atveju aš visom keturiom esu už unsigned, nes neigiamų nenaudoji, ir gauni dvigubai daugiau skaičių saugoti produkto ID.

Bet visgi nesuprantu kaip dėl to galima ginčytis. Situacija diktuoja ko tau reikia. Aišku tie kas nesupranta skirtumo, jiems geriau rašyti tik "int", kas standartiškai turi ženklą.
Nors mano nuomone, jei nesupranti tokio skirtumo, naudok aukšto lygio kalbą, kuri įvertina tai ką tu darai, ir pataiso tavo klaidas. Pvz PHP susikuri bet kokį kintamąjį, grūdi į jį ką nori, kiek nori. Svarbu php konfigūracijos parametro "memory_limit" neviršyji.
  • +1




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 01:37 
     
coursera neblogas python kursas yra.
Šiuo metu rekomenduočiau mokytis programuoti būtent pytonu, be rimtų argumentų,tiesiog mano tokia nuomuonė. Pakankamai lankstus, funkcionalus ir tuo pačiu paprastas.

clean code - klasikinė knyga, kurią perskaitęs ar šiaip pavartęs pradėsi rašyti truputį gražesnį kodą. Turbūt verta paskaityti, nepaisant kokia kalba programuoji.

taip pat siūlyčiau paskaityti kažką apie testavimą, ypač test driven development. Jeigu atrodo perdaug sudėtinga, gal tada ir neskaityk, nežinau koks tavo programavimo lygis. Bet gyvenimą tai palengvina.
Pvz: https://books.google.se/books/about/Tes ... edir_esc=y
Jeigu trumpai, tai iš kur žinai, kad veikia, ką parašei? TDD nors ir atrodo sudėtinga, bet labai labia paspartina darbo procesą, kai įvaldai mąstymą. Ypač lengva bus pereiti, jeigu dirbi prie projekto vienas, be kolegų.

Sakai bibliotekos C/C++? Nežinau ką tiksliai darai, kaip pavizdį paimsiu arduino.
Arduino gali susiprogramuoti su C, pasijungti visus sensorius ir t.t., tada paleisti duomenis per UART protokolą į kompą, o kompe tavęs niekas nebeverčia naudoti C. Gali imti python ir ateinančius duomenis interpretuoti, analizuoti. C palik tik tai daliai, kur tikrai jos reikia.

ai dar aip conjurer rašė, GIT yra privaloma. Kažkaip net nepagalvojau apie galimybę gyventi be jo. Tiesa intelliJ (JAVA redaktorius) turiu vietinę įstoriją, bet GIT`as (mercurial, SVN, CVS) yra gėris, ypač kol mokaisi.
  • +2




Užsiregistravo: 2009-07-13, 13:38
Pranešimai: 4476
Reputacija: +1431
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 09:06 
     
Kiek aš pastebėjau, su unsigned dažniausiai problemų bando rasti tie kas į c++ ateina iš c kalbos, nes c kalboje yra įprasta apie klaidas informuoti neigiamais skaičiais. Pav. jei funkcija turi gražinti kažkieno dydi, o dydis visados bus teigiamas skaičius, tai tada gražina neigiamus skaičius jei negali gražinti dydžio. Todėl jie praktiškai nenaudoja unsigned ir nėra įpratę jo naudoti ir jei jų paklausi apie gera programavimą jie visais dievais prisiekinės kad negalima naudoti unsigned. Bet skirtingai nuo c kalbos c++ turi Exception klase pranešimams apie klaidas, bet dauguma ateinančių iš c kalbos nemoka ir dėl to nenori jos naudoti.
Ne karta mačiau blogų kuriuose teigia, kad Exception naudojimas yra blogas programavimo stilius arba šiaip yra blogis. :)

Dabar baigiau žiūrėti šituos video apie OpenGL. Kiek girdėjau dirbo garsioje žaidimų kūrimo įmonėje, tad galvojau kad jau turi geras žinias apie OpenGL. Šiaip video geri ir suprantami, bet man nepatiko keli dalykai. Pirmose serijose sakė, kad nenaudoja GLfloat, naudoja tik float. Bet paskutinėse jo serijose kur jau kodas profesionalesnis visur naudojo GLfloat ir nemačiau niekur float. Tai dabar suprask. Naudoti float ar GLfloat. Geriau pasidomėjęs sužinojau kad geriau visur kur informacija skirta perkelti į GPU reikia naudoti GLfloat, nes tai padidina portabilu. Nes, nors daugumoje sistemų float yra 32 bitų, bet yra sistemų kuriose jis gali būti 16 ar 64 bitų. Tuo tarpų GLfloat užtikrins kad jis yra visada 32 bitu. Bet visur kitur, kur informacija nėra skirta perdavimui į GPU geriau naudoti float arba susikurti savo headers failą kuriame aprašysi savo MyFloat ir užtikrinsi kad jis visada butu 32 bitų, arba MyInt kad jis visada butu 32 bitų jei tau reikia tik 32 bitų int kintamųjų.

Arba šitas *.h or *.hpp for your class definitions taip pat daugiau stiliaus reikalas, bet labai dažnai C++ bibliotekos naudoja .h, o ne .hpp
  • 0


_________________
Propaganda


Vartotojo avataras

Užsiregistravo: 2010-07-29, 19:55
Pranešimai: 5517
Reputacija: +1720
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 10:55 
     
Shinigami rašė:
Kiek aš pastebėjau, su unsigned dažniausiai problemų bando rasti tie kas į c++ ateina iš c kalbos, nes c kalboje yra įprasta apie klaidas informuoti neigiamais skaičiais. Pav. jei funkcija turi gražinti kažkieno dydi, o dydis visados bus teigiamas skaičius, tai tada gražina neigiamus skaičius jei negali gražinti dydžio. Todėl jie praktiškai nenaudoja unsigned ir nėra įpratę jo naudoti ir jei jų paklausi apie gera programavimą jie visais dievais prisiekinės kad negalima naudoti unsigned. Bet skirtingai nuo c kalbos c++ turi Exception klase pranešimams apie klaidas, bet dauguma ateinančių iš c kalbos nemoka ir dėl to nenori jos naudoti.
Ne karta mačiau blogų kuriuose teigia, kad Exception naudojimas yra blogas programavimo stilius arba šiaip yra blogis. :)

Asmeniškai pagrinde dirbu su linux, nes windows, tai kaip konsolė žaidimams.
Linuxe pagrindinė kalba yra C, ir systemcall ir Clib atsakymai bus signed int. Bet kai rašaisi savas funkcijas net su c gali apsibrėžti, kad bus gražinamas 0, jei nieko neįvyko, ir bet koks didesnis skaičius, jei kažkas įvyko. Kitos funkcijos labai priklauso nuo konteksto. Jei funkcija gražina laipsnius, ne kelvinais, būtina naudoti signed, jei gražina laiką praėjusį nuo įvykio, nematau prasmės naudoti unsigned, nebent kuri laiko mašiną.
Didžiausia problema signed integerių naudojimas, yra greitesnis overflow. Kas gali sukelti labai brangių problemų.
  • 0




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 11:00 
     
Nuo 26 iki 31 sekundės, vienas geriausių patarimų tiem kas mokinasi programuoti:


  • 0




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 11:12 
     
šiaip pagrindinis dalykas su progarmavimu, tai reikia skirti kažkiek valandų, kad persilaužti su mąstymu. Vieniem bus greičiau, kitiem lėčiau, bet visiem +/- tos pačios problemos iškyla.

Bent man taip pasirodė, kai žmona bandė truputį programuoti pytonu neseniai ir erzinosi lygiai tose pačiose vietose kaip aš vaikystėje su paskaliu. Įvedimas išvedimas, kelių matmenų masyvai ir t.t.

Taigi nebijok, jei nesiseka. Jeigu tęsi, tai kas sunku šiandien bus lengva po mėnesio.
  • +3




Užsiregistravo: 2009-07-13, 13:38
Pranešimai: 4476
Reputacija: +1431
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 13:58 
     
conjurer rašė:
Jei ko labai nesupratai, galiu patikslinti.
Jei darbas skirtas prisidėti Raides prie vardo, C/C++ tinkamiausios kalbos mano nuomone. Žemesnio lygio visada yra labiau mokslinės. Be to, mano nuomone, jei dirbama su medicina, Unit testai yra privalomi.


Gal ne tai kad nesupratau, neturiu ziniu apie daug ka. Kad ir tavo sitam poste minimi Unit testai. Nu taip, testuoju as savo funkcijas, paprastai kai jos jau labai aiskiai bugina:) tik kazin ar tai reikia daryt prisirasant kitu funkciju savo kode, prisikuriant fake logu ir t.t. Is tavo posto galima primest, kad egzistuoja geresni budai tai daryt, reiskia reikes googlint...

Jei tau tikrai nesunku, gal galetum placiau papasakot apie makefile? Sitoj vietoj balta deme, kad sukompilinciau as tiesiog spaudziu ctrl+f7 ir Visual studio padaro likusia "black magic" dali.

Su makefile esu susidures viena karta, beflashindamas kazkuri is mazu kontroleriuku, attiny gal kazkuri. Internete rastos instrukcijos neveike su mano programeriu, reikejo kazka pasikeist tenai. Tai tiek ir neziniu.

HardAxe rašė:


Dekui ir tau, knygas radau, butinai paziuresiu.

HardAxe rašė:
Sakai bibliotekos C/C++? Nežinau ką tiksliai darai, kaip pavizdį paimsiu arduino.
Arduino gali susiprogramuoti su C, pasijungti visus sensorius ir t.t., tada paleisti duomenis per UART protokolą į kompą, o kompe tavęs niekas nebeverčia naudoti C. Gali imti python ir ateinančius duomenis interpretuoti, analizuoti. C palik tik tai daliai, kur tikrai jos reikia.


Matai, jei jau kazkas, ka turi sistemoj turi gamintojo kontroleri ir biblioteka jam, tai kazin, ar tai bus daiktas, kuri tiesiog gali pajungt prie kazko panasaus i arduino ir isnaudot visa jo funcionaluma:) Jei ir galesi, tai jauciu nebus lengviau nei kontroliuot tiesiai is PC. Plius, toks (PC-PLC-PLC+sensorius?) komponavimas apsunkina to pacio kontroles kodo modifikavima, daug patogiau kai viskas yra vienoj vietoj. Aisku, jei naudosi koki prietaiseli, su tarkim, analoginiu outputu ar kokiu I2C, tai nelabai kas daugiau ir lieka nei taip daryt.

Kalbant apie tavo pavyzdyje minima arduino... Kaip ir didzioji dalis musu turbut su juo as pazaidziau kuri laika, net naudojau kokius pirmus puse metu manipuliatoriaus kontrolei. Mano manymu didziausias jo trukumas yra debugerio nebuvimas. Antras pagal diduma - UART su savo 5Mbps greiciu, labai daug kam to tikrai neuzteks. Rezultate as jo atsisakiau ir gerai padariau, gavosi greiciau, patikimiau, modifikavimas patogesnis, maziau laidu, jungciu ir t.t. Plius ismokau kazko naujo.
  • 0




Užsiregistravo: 2015-07-11, 23:07
Pranešimai: 283
Reputacija: +157
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-13, 14:49 
     
jull rašė:
Gal ne tai kad nesupratau, neturiu ziniu apie daug ka. Kad ir tavo sitam poste minimi Unit testai. Nu taip, testuoju as savo funkcijas, paprastai kai jos jau labai aiskiai bugina:) tik kazin ar tai reikia daryt prisirasant kitu funkciju savo kode, prisikuriant fake logu ir t.t. Is tavo posto galima primest, kad egzistuoja geresni budai tai daryt, reiskia reikes googlint...


Testų pagrindas, yra kita programa, kuri bando tavo funkciją su visom reikšmėm. Dažnai mažam projektui nėra sunku pačiam greit pasirašyt savo unit testerį (pvz dirbant su bash). Tačiau jei nori tai daryti su jau parašytu softu, c++ turi krūvą: https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C++. Čia jau realiai reikia pasibandyti kelis, asmeniškai su C++ daug nėra tekę dirbti. Kad ir ką naudotum, reikės apsirašyti kokio atsakymo tikiesi iš funkcijos.

jull rašė:
Jei tau tikrai nesunku, gal galetum placiau papasakot apie makefile? Sitoj vietoj balta deme, kad sukompilinciau as tiesiog spaudziu ctrl+f7 ir Visual studio padaro likusia "black magic" dali.

Su makefile esu susidures viena karta, beflashindamas kazkuri is mazu kontroleriuku, attiny gal kazkuri. Internete rastos instrukcijos neveike su mano programeriu, reikejo kazka pasikeist tenai. Tai tiek ir neziniu.


Tavo atveju kai naudoji Visual studio, ir kodo su niekuo nesidalinsi, tik exe failą, makefile yra beprasmis. Jis reikalingas tada kai nori dalintis kodą, nes ne visi turi prabangą pirktis brangius kodinimo toolsus. Kol univeras duoda licenciją, ar nusipiratauji asmeniniam naudojimui viskas pakenčiama, bet kai dirbi įmonėje, kartais būna per brangu naudotis mokamu softu, ypač kai yra nemokamos alternatyvos.

Make file veikimas yra paprastas. Tu nueinį į katalogą kuriame yra kodas, ir parašai "make". Komanda "make" susiranda "makefile" failą, ir vykdo standartinį scenarijų. Gali apsirašyti papildomus scenarijus. Dažnai būna aprašoma "clean" scenarijus, kuris išvalo ".o" failus.
Linuxe beveik visos programos kurios yra kompiliuojamos iš kodo, susikompiliuoja tokius principu. Parašai "make" - sukompiliuoja kodą, parašai "make install" - įdeda sukompiliuotus failus ten kur jie turi būti.

Bet čia yra linuxų dalykas, jei naudoji windows, to nelabai turi. Realiai tavo visual studio išsaugotas projektas turi kažkokią alternatyvą to makefile.
  • +1




Užsiregistravo: 2010-12-29, 01:01
Pranešimai: 505
Reputacija: +199
   
 
Į viršų
  Standartinė   Parašytas: 2020-08-15, 10:37 
     
Radau C++ kalbos vietą kurioje 90% programuotojų "klysta". Tai yra pointeriai. Pointeriai turi tris užrašymo stilius.
1) int* p1;
2) int *p2;
3) int * p3;
Didžioji dauguma naudoja 1 stilių (bent aš internete mačiau dažniausiai šį stilių), bet šis stilius iš visu trijų stilių yra pats neteisingiausias. Pirmu atvejų atrodo, kad čia yra užrašytas kad kuriamas int tipo poineris, bet taip nėra. Pav.: dažnai vienoje eilutėje yra sukuriamas ne vienas to pačio tipo kintamasis.
1. int p1, p2, p3, p4;
Šiame užrašyme visi kintamieji yra int tipo. Bet kas bus jei bandysime taip sukurti pointerius?
2. int* p1, p2, p3, p4;
Naujokas galvos kad visi kintamieji yra int tipo pointeriai, bet ištiesų tik p1 yra pointeris. p2, p3, ir p4 yra paprasti int tipo kintamieji, o ne pointeriai. Norint kad visi kintamieji butu pointeriai reikia rašyti taip:
3. int* p1, *p2, *p3, *p4;
Man šitoks užrašymas negražiai atrodo. Kodėl p1 be žvaigždutės, kai visi kiti su žvaigždutėmis? Nevienodas stilius vienoje eilutėje. Bei šitas pavyzdys rodo kad žvaigždutė ir int neturi jokio ryšio ir žvaigždutė nepriklauso prie int. Jį yra kintamojo dalis. Todėl geriau butu užrašyti šitaip.
4. int *p1, *p2, *p3, *p4;
Todėl antras stilius yra tikslesnis nei pirmasis, bet jis taip pat nėra tikslus.
Kintamasis turi viena kintama savybę, tai yra kintamojo reikšmė.
Kodas:
int p1 = 3;
p1 = 5; // Pakeičiame kintamojo reikšme iš 3 į 5.

Tuo tarpu pointeris turi dvi kintamas savybes, nes pointeris saugo reikšmės adresą, o ne pačio reikšmę. Todėl galime keisti kintamojo reikšme ir galime keisti adresą į kuri veda kintamasis.
Kodas:
int var = 9;
int *p2 = 3;
*p2 = 5; // pakeičiame kintamojo reikšme iš 3 į 5.
p2 = &var; // pakeičiame adresą į kuri veda kintamasis. Dabar p2 ves į var kintamojo reikšmę ir bus lygus 9.


C++ turi raktažodi "const". Kuris neleidžia keisti kintamojo.
5. const int p1 = 1, p2 = 2;
Skirtingai nei žvaigždutės atvejų tiek p1, tiek p2 bus const int. Todėl raktažodis "const" yra "int" dalis ir juos galima keisti vietomis nekeičiant reikšmės.
6. int const p1 = 1, p2 = 2;
Tiek p1, tiek p2 bus const int tipo.
Kodas:
int i1 = 1, const i2 = 2;
   
std::cout << "I1: " << i1 << std::endl;
std::cout << "I2: " << i2 << std::endl;

i1 = 3;
i2 = 4;

std::cout << "I1: " << i1 << std::endl;
std::cout << "I2: " << i2 << std::endl;

Šitame kode "const" neturi jokios įtakos kintamojo i2 redagavimui. Visual studio paskutinėje eilutėje išspausdino 4. Todėl jei nori kad tavo kintamasis butu konstanta raktažodis "const" turi būti priešais int arba iš kart už jo. Tuo tarpų kuriant pointerį reikia kad tarp žvaigždutė ir kintamojo vardo, nebūtu kito kintamojo.

Kodas:
    int var1 = 1;
    int var2 = 2;
    int var3 = 3;
    int var4 = 4;

    int * p1 = &var1;
    int const * p2 = &var2;
    int * const p3 = &var3;
    int const * const p4 = &var4;
   
    std::cout << "P1: " << *p1 << std::endl; // P1: 1
    std::cout << "P2: " << *p2 << std::endl; // P2: 2
    std::cout << "P3: " << *p3 << std::endl; // P3: 3
    std::cout << "P4: " << *p4 << std::endl; // P4: 4

    *p1 = 5;
    // *p2 = 6; ERROR: expression must be a modifiable lvalue
    *p3 = 7;
    // *p4 = 8; ERROR: expression must be a modifiable lvalue

    std::cout << "P1: " << *p1 << std::endl; // P1: 5
    std::cout << "P2: " << *p2 << std::endl; // P2: 2
    std::cout << "P3: " << *p3 << std::endl; // P3: 7
    std::cout << "P4: " << *p4 << std::endl; // P4: 4

    // Taigi, kadangi priešais p2 ir p4 yra "int const" reikšmių į kurias veda pointeris negalime keisti. Bet p1 ir p3 reikšmes galima keisti.
    p1 = &var4;
    p2 = &var3;
    // p3 = &var2; ERROR: expression must be a modifiable lvalue
    // p4 = &var1; ERROR: expression must be a modifiable lvalue

    std::cout << "P1: " << *p1 << std::endl; // P1: 4
    std::cout << "P2: " << *p2 << std::endl; // P2: 7
    std::cout << "P3: " << *p3 << std::endl; // P3: 7
    std::cout << "P4: " << *p4 << std::endl; // P4: 4


Kaip rašiau pradžioje pirmasis stilius yra netinkamas, nes juo negalime vienodai aprašyti dviejų ir daugiau pointerių. Todėl čia apie jį daugiau nerašysiu ir dėl to naudosiu "int const" užrašymą.
p1 ir p2 pointerius galima užrašyti tiek antru, tiek trečių stiliumi, bet p3 ir p4 galima užrašyti tik trečių stiliumi.

Išvados:
1) Pirmas stilius netinka nes juo negali aprašyti daugiau nei vieno kintamojo vienoje eilutėje ir žvaigždutė neturi nieko bendro su informacijos tipu.
2) Antras stilius netinka nes su juo nepadarysi pointerio kad butu galima pakeisti pointerio adresą.
3) Tik trečias stilius tinka visais atvejais.

Bet kažkodėl dažniausiai naudojamas pirmasis stilius, nors jis mažiausiai tikslus ir pradedančiuosius klaidinantis. Tai rodo, kad net profesionalus programuotojas ne visada gali išmokinti teisingai. Žinoma, jis vis tiek išmokins geriau nei pats išmoksi iš knygų ar interneto.
  • +1


_________________
Propaganda


Vartotojo avataras

Užsiregistravo: 2010-07-29, 19:55
Pranešimai: 5517
Reputacija: +1720
   
 
Į viršų
Rodyti paskutinius pranešimus:
Rūšiuoti pagal
 


Naujos temos kūrimas Atsakyti į temą  [ 20 pranešimai(ų) ] 

Visos datos yra UTC + 2 valandos [ DST ]


Dabar prisijungę

Vartotojai naršantys šį forumą: Registruotų vartotojų nėra ir 9 svečių


Jūs negalite kurti naujų temų šiame forume
Jūs negalite atsakinėti į temas šiame forume
Jūs negalite redaguoti savo pranešimų šiame forume
Jūs negalite trinti savo pranešimų šiame forume
 

Ieškoti:
Pereiti į:
 
 

Reputation System ©'