Jump to content

Kā konkrēti izpaužas C++ valodas tuvums "dzelžiem".


Raimonds1
 Share

Recommended Posts

Ja jāatbild uz tēmas nosaukumā uzdoto jautājumu - tad nekā. Dzelžu valoda ir ASM un tikai. Par ASM augstāka līmeņa progammēšanas valodas darbojas ar konkrētās OS API, nevis ar ASM, programmēšanas valoda (kompilators) ir abstrakcijas līmenis starp OS API un konkrēto valodu. Ja vēlies iepazīt konkrēta dzelža ASM līmeni, tad vis efektīvākais būs tieši konkrētā dzelža ASM, nekas cits. No otras puses, ASMā konkrētam dzelzim vari rakstīt no ļoti daudzām valodām, tai skaitā arī visu nopeltajā Delphi XE, FreePascal etc, C++ nav vienīgais variants...

 

Ja interesē konkrētu dzelžu ASM, tad jāizprot konkrēto dzelžu ASM. Augstāka līmeņa valodas tad nebūs way to go :)

 

Pašlaik liekas, ka šī tēma būs bezgalīga :)

Labots - rubb
Link to comment
Share on other sites

AndrisBB

Bet vaitad OS tev atļaus piekļūt "dzelžiem" arī no ASM? Tikuntā būs jālieto OS API. Tad sanāk ka neviena programēšnas valoda nav tuva dzelžiem, ja programa darbojas iekš OS, tanī pašā laikā jebkura programa, kura darbojas "pa tiešo" uz CPU būs dzelžu līmenī, pat C# var tik kompilets un "pa tiešo" darbināts uz ARM

Labots - AndrisBB
Link to comment
Share on other sites

rubb, un ko darīt, ja nekādas OS nemaz nav? Arī tādos gadījumos C, C++ neviens neliedz izmantot.

 

Kamēr dzejoju, viens otrs izdomāja palabot savu postu :crazy: :crazy: :close_tema:


Labāk pastāstiet, kā lai no malas paskatās, kas pa SPI vadiem skrien… Ja konkrētāk, tad man nav īsti skaidrs, kā noteikt, kur sākas un kur beidzas baita pārraide.

Labots - binary
Link to comment
Share on other sites

AndrisBB

Ar logic analyzer, ja tāds bij tavs jautājums

man ir tāds, bet ir arī lētāki un labāki

Labots - AndrisBB
Link to comment
Share on other sites

Nē nē, tas neder, tas būtu tāpat kā sūtīt meilus ar disketēm, uz kurām uzlikts mobilais, kurš wāzē rāda, uz kurieni jāved tās disketes tos meilus. Man vajag softwārisku risinājumu. Blenžu protokola aprakstā un nespēju iebraukt, kurā brīdī kaut kāda nebūt sinhronizācija [ne]notiek, pieņemot, ka SS netiek iepīts.

 

vot tev, high level stuff… Ar kaut kādu C# es to simtu gadu nespētu realizēt (stipri šaubos, ka C# kaut kas jēdzīgs spēs ietilpt 512/1024 baitos un darboties ar 32 baitu RAMu).

Labots - binary
Link to comment
Share on other sites

AndrisBB

Tev ir 32 baitu vai kilobaitu rams? Minimālās prasības priekš .Net Micro ir te

SPI jau ir tīri vienkārš:

  • Māsters uzliek SS low
  • Palaiz Clock siglālu
  • Slave nolasa MOSI atkarībā no modes (rising edge/faling/etc) uz attiecīgā clock edge
  • Masters lasa no MISO
  • Māsters uzliek SS high

 

Nu ja chipam ir JTAG, tad arī tas var kautkādā mērā palīdzēt, kas tev par MCU?

Labots - AndrisBB
Link to comment
Share on other sites

ieleja, parādi man 40 centus vērtu 2x3 mm lielu čipu ar 512KB RAM, kas uzturā lieto skaitāmus mikroampērus ;)

Edit: Ai, sorry, tu tur kaut ko ar 512 baitiem salīdzini. Nē, nav šitam uzdevumam čips ar 512B RAM. Un nevajag arī.

 

AndrisBB, 32 baiti. Zinu, ka SPI ir vienkāršs. Bet izskatās, ka neesi lāgā lasījis komentārus - SS nav. Ir tikai SCK un MISO (vai MOSI, hz, nav svarīgi). Nevajag man nekādus JTAG un ko tik vēl tur ne - vajag no tā MISO (vai MOSI) sūkt datus, apstrādāt un padot tālāk (vairs ne caur SPI) reālā laikā.


 

 

kas tev par MCU

attiny10, esi tādu redzējis? :sarkasms:

Labots - binary
Link to comment
Share on other sites

AndrisBB

Kas tad tos datus nolasa un pārsūta tālāk, māsters vai tu pievieno kautko "ārēju"?

....

Ā, sapratu problēmu. Tev nonstopā tiek pārsūtīti datu pa SPI un tu gribi pieslēgties un izspiegot kas tiek pārsūtīts, bet nevari saprast kur baitam sākums kur beigas?

Labots - AndrisBB
Link to comment
Share on other sites

HIGH-Zen

Tad ir jādefinē kas ir masīvs. Tu piemēram vari pateikt CPU vienā instrukcijā saskaitīt pirmo integer masīva elementu ar otro un saglabāt rezultātu trešajā, bet tu nevari saskaitit pirmo bitu ar otro un saglabāt trešajā, tātad CPU nevar veikt tiešas operācijas bitu līmenī. To var izdarī vairākos etapos, bet ne vienā operācijā

Tiešas operācijas protams nevar. Un saskaitīt arī īsti nesanāks, tā kā biti var būt tikai 0 vai 1, tad tajā trešajā bitā nebūs vietas ja saskaitīs 1 un 1. Ar atsevišķiem bitiem varētu veikt tikai bitu operācijas.

 

Te aizgāja offtopiks vairāk par to, ka biedrs Vilx- ir pārliecināts, ka int, float un char nav abstrakcijas. Tur es viņam nepiekrītu. Int tips, piemēram, ir abstrakcija, pat tā izmērs baitos ir atkarīgs no C/C++ implementācijas.

0x61 var būt int vai short = 97 vai tikpat labi char = 'a', reāli datorā tie ir vienkārši baiti, kas sastāv no bitiem un lai ar tiem strādātu tiek izmantotas šīs abstrakcijas.

 

Link to comment
Share on other sites

Nē, AndrisBB, nav pieejas, citādi man nevajadzētu domāt, kā tos datus pārķert un padot tālāk "pa savam".


HIGH-Zen, inti, shorti, floati ir natīvi datu tipi, t.i., tādi, ko CPU "saprot" un spēj apstrādāt. Nēnu labi, ir arhitektūras, kurās šie tipi varbūt nav natīvi (konkrēti float) - tur jā, tur tāds tips varētu tikt uzskatīts par abstrakciju, tādu kā "syntactic sugar" salīdzinoši sarežģītām softwāriski implementētām lietām. Bet atrast arhitektūru, kam chari, shorti, inti būtu abstrakcijas - nu nez, nenāk prātā tādas.


Bits, starp citu, gan nav natīvs tips. Un "bitu masīvi" jeb "booleanu masīvi" tiek implementēti mazliet sarežģītākā veidā nekā jebkuri citi masīvi.

Link to comment
Share on other sites

Te aizgāja offtopiks vairāk par to, ka biedrs Vilx- ir pārliecināts, ka int, float un char nav abstrakcijas. Tur es viņam nepiekrītu. Int tips, piemēram, ir abstrakcija, pat tā izmērs baitos ir atkarīgs no C/C++ implementācijas.

Hmm... nu, faktiski Tev ir taisnība - C/C++ kompilatori var ar šiem tipiem darīt, ko grib. De facto gan tie vienmēr atbilst hardware datu tipiem.
Link to comment
Share on other sites

AndrisBB

Tad jau arī tu nezini vai tur nav pielietoti kautkādi encodingi, hamming codi utt.

Piemēram, ja man vajadzētu tā nonstopā pārsūtīt, tad es vismaz pielietotu kautkādas error correction metodes, vismaz base64 vai kko tamlīdzīgu sākuma/beigu noteikšanai, jo tā vienkārši sinhronizācijai pēc clock jau nevar uzticēties

Labots - AndrisBB
Link to comment
Share on other sites

 

 

C/C++ kompilatori var ar šiem tipiem darīt, ko grib

Tā gluži nebūs, C/C++ standarts apraksta skaitlisko tipu minimālos izmērus bitos, kā arī šo tipu izmēru salīdzinājumu ar citu tipu izmēriem (piemēram, int ir vismaz 16 biti un ne mazāks par short, short ir vismaz 16 biti un ne mazāks par char utt).


 

 

Tad jau arī tu nezini vai tur nav pielietoti kautkādi encodingi, hamming codi utt.

Vienīgais, ko es zinu - ka pa turieni skrien sakarīgi dati. Daļai datu ir skaidrojumi, daļai - labākajā gadījumā minējumi, kas tas varētu būt. Mani interesē tikai tie, kam ir skaidrojumi (t.i., tajos ir viss man nepieciešamais).

Link to comment
Share on other sites

AndrisBB

Pārāk liela neskaidrība, lai varētu izdarīt kautkādus minējumus. Parādi vismaz kautkādu piemēru un kontekstu.

Labots - AndrisBB
Link to comment
Share on other sites

Nu tad jālien zem segas un jāļauj lielajiem vīriem turpināt spamu par to, kas ir un kas nav tuvs dzelžiem. Nav ko te spamot par kaut kādiem "SPI snifferis iekš C++" u.c. muļķībām. Neba nu autors tagad reāli ķersies pie dzelžu laušanas…

  • Patīk 1
Link to comment
Share on other sites

AndrisBB

Ja tev ir skaidrs kas tiek pārsūīts, tad uz katru clock edge nosamplo MISO/MOSI un pārsūti uz PC. Pamēģino atkost kā tiek apzīmēts "paketes" sākums/beigas, pectam var domāt tālāk.

Link to comment
Share on other sites

Raimonds1

 

 

Labāk pastāstiet, kā lai no malas paskatās, kas pa SPI vadiem skrien… Ja konkrētāk, tad man nav īsti skaidrs, kā noteikt, kur sākas un kur beidzas baita pārraide.
 

 

Bija kaut kāda filma un tur viens džeks izmeklētājiem iesmērēja pierādījumu, ko vajadzēja skanēt ar skaneri. Tad nu tas pierādījums (kaut kāds akmens vai koka gabals) bija tā uztaisīts, ka tā attēla aprakstošās bināras virknes patiesībā saturēja vīrusu un komandu tā izpildei.


 

 

Neba nu autors tagad reāli ķersies pie dzelžu laušanas…

 

Autors fantazē par tēmu, lasa un mēģina saprast literatūru un meklē jaunu pieeju un viss. 


 

 

Pašlaik liekas, ka šī tēma būs bezgalīga

 

Un kas tur slikts, ceļš arī ir vērtība, ne tikai gatavs projekts. 

Link to comment
Share on other sites

Atbildot uz sākotnējo autora postu - manā skatījumā tas kādas skaitļu vērtības var aprakstīt ar C/C++ datu tipi nav tas, par ko es teiktu ka C++ ir tuvu dzelžiem. Visi tie int/char/float/.. ir tikai nelieas abstrakcijas pār tipiem ar kuriem var CPU operēt. Ja tev ļoti gribās ar nelielu daudzumu koda tu vari mierīgi operēt arī lieliem un precīziem skaitļiem (1000 ciparu lieliem). Tā nav problēma.

 

C/C++ (un citas līdzīgas valodas kā Pascal) ir tuvu dzelžiem tāpēc, ka tās nedera neko lieku un papildus - tās ļauj precīzi manipulēt ar atmiņu un to ko CPU darīs rakstot kodu. Respektīvi visu datu izvietojums atmiņā būs tieši tāds kā tu norādīsi, nevis kaut kāds GC (garbage collector) tur pa vidu maisīsies un pārvietos atmiņu. Un tas ko CPU darīs ir precīzi norādāms kodā - nav nekādu interpretatoru vai JIT pa vidu. Uz C valodu var skatīies kā augsta līmeņa assembleri. Protams, rakstot asemblerā tev būs lielāka kontrole pār instrukcijām, kuras izpilda CPU. C ir drusku augstāka līmeņa kods, bet tomēr joprojām pietiekami zemu lai tu zinātu ko CPU darīs izpildot tavu kodu. C++ jau ir daudz augstāk. Moderni kompilatori cenšas būt efektīvi (zero cost abstractions), bet bieži vien tas viņiem nesanāk un pa vidu tur saģenerējas melnas briesmas.

Link to comment
Share on other sites

Raimonds1

Es tā sāku domāt, vai tik nav jāsāk ar C valodu. 

 

Te no citas tēmas par C/C++

http://www.boot.lv/forums/index.php?/topic/103719-kadas-programmesanas-valodas-lai-apgust/?hl=bibliot%C4%93kas

 

 

 

* programmeeshanas valoda C (nevis C++) - ar sho viennoziimiigi vislabaak sapratiisi, kas iisteniibaa ir "iistaa" programmeeshana. Ja saakumaa liekas par sarezhgjiitu, tad, iespeejams, maaciibu meerkjos noder paseedeet pie PASCAL, peec kura nebuusgruuti paarsleegties uz C, jo ideja tiem ir taa pati

 

 

 

Izvairiities ieteiktu no dziljas C++ apguushanas, jo tas ir ljoti nesakaartots, murgains, sarezhgjiits un tam muusdienaas ir zudusi arii jeega. Jeega no shiis saimes paliek tikai C un C# katram savaa nishaa. Abiem neapshaubaami eertaakaa un citaadi labaakaa izstraades vide ir Visual Studio. Jaapieziimee, ka ar Visual Studio un C# paliidziibu buus arii visvieglaak saakt darboties ar datu baazeem, iipashi, protams, Microsoft SQL.
 

 

 

 

Kaa jau es ieprieksh teicu C++ tieshaam ir nevajadziigi samudzinaats! C ir daudz vienkaarshaaks un ar skaidru ideju. Kaada veel atminjas daliishana? Pachuksteeshu vienu lietu - C/C++ labi programmeri vispaar nepieljauj warningus. T.i., piemeeram, Visual Studio uzliek "Treat warnings as errors". Shaadaa veidaa kompilators nemaz nekompilees liikus kodus un 24 stundu laikaa buusi sapratis kas ir kas ar pointeriem. Par neiespeejamiibu atrast kljuudu... nu nevajag, ja! IDE taa pati Visual Studio un debugoshanas iespeejas tieshi taas pashas kas Tev VB .NET. Kur probleema atrast kljuudas? Bet ar to C ir taa... kameer neiebrauksi, labumu nesapratiisi! Savulaik pats baigi labi orienteejos Pascal un Delphi un C galiigi nebija eerts. Bet dazhu sakariigu chomu un intereses izzinaat vadiits piespiedu sevi ar domu "iebraukshu un, ja nebuus taa kaa shie staasta, tad palikshu pie taa pasha Delphi". Nu, iebraucu... Un, paldies - atpakalj uz tiemi skatiities negribaas!
 
Link to comment
Share on other sites

Vēlreiz uzsveru - citam māte, citam meita, citam kleita. Objektīvi skatoties, iemācīties programmēt var ar jebkuru valodu, un tas, cik labs programmētājs Tu būsi, nav absolūti atkarīgs no tā, ar kuru valodu sāksi.

 

Tāpat arī šitie valodu kariņi par tēmu "valoda X rullz, bet valoda Y saks" ir vienkārši bērnišķīgi.

 

Tā kā C++ ir diezgan labi atpakaļsavietojams ar C (t.i. jebkura C programma ir arī C++ programma), tad vari arī sākt ar C, un pēc tam paņemt klāt C++. Vai otrādi. :)

 

Sāc ar to valodu, kura pašam izskatās interesantāka, un pofig par to, ko citi saka. :)

Link to comment
Share on other sites

Raimonds1

Es kaut kā no tiem ticības kariem esmu noticējis tam, ka viena veida pieeja ietekmē domāšanu un traucē uztvert cita veida valodu, bezatbildīgi izturēties pret pieraksta veidu, programmas organizēšanu utt.

 

laikam jau paliks C un C++ lēnām un no sākuma

Link to comment
Share on other sites

Mezavecis

Galvenais neaizmirst, ka plika mācīšanās bez praktiska pielietojuma ir izniekots laiks.

  • Patīk 1
Link to comment
Share on other sites

Mezavecis

Neviens ar pliku grāmatas,tutoriāļa izlasīšanu nav kļuvis par speciālistu jebkurā jomā. 

 

Ja tiešām gribi pārzināt valodu, tev ir praktiski jāveic reāli uzdevumi, un bez reālas programmēšanas apgūtās zināšanas nebūs pilnvērtīgas. Reālā programmēšanas ir praktiska darbošanās reālam mērķim, nevis niekoties ar testa piemēriem. 

Labots - Mezavecis
  • Patīk 1
Link to comment
Share on other sites

Raimonds1
(labots)

Es to saprotu. Vispirms jau jāapgūst, kas ir kas. Te vienā tēmā bija diskusija par tv, kur tv procesors graudainam attēlam pārejas punktus vai trūkstošos "kadrus  izveidojot, pieķēpā ar kaut kādu pārejas krāsu starp tiem, tādējadi to bildi "uzlabojot"

 

Tad nu praktiski - cik bitu ir tiem blakuspunktiem, kā tas vērtības ielasa programmā un pēc kādiem kritērijiem dod to pārejas krasu (kodu) - pēc tā, kas ir apkārt, cik tuvu pavisam cita krāsa, kur skaitās ēnas. Kur tur pointeri, kur array, kur mainīgie, kur darbības ar tiem utt. vai arī kaut kādā augsta līmeņa programmā uzraksta - get colour from point 345 to 347.

Labots - Raimonds1
Link to comment
Share on other sites

Mezavecis

Praktiski būtu patstāvīgi uzrakstīt koda rindiņas, kas arī darbojas. Izdomāt uzdevumus nav nekāda māksla. Konkrētais piemērs ir neizpildāms, jo tur pārāk daudz nezināmie. Programmēšanā izplūduši un neskaidri uzdevumi nozīmē 100% neveiksmi.

 

 

P.S. Filozofija diemžēl nav savietojama ar eksaktām zināšanām.

Labots - Mezavecis
Link to comment
Share on other sites

Raimonds1
(labots)

Kāpēc tikai gatavs izpildīts uzdevums skaitās kaut kas vērtīgs?

 

Kur tur ir filozofija? Izveidojam triviālu piemēru un mēginam saprast, ar kuriem C valodas rīkiem to risināt.

 

Vispirms definējam, ar ko atšķiras 50Hz televizors no 400Hz televizora.

Es domāju, ka ar kadru skaitu sekundē. Ir šajā definīcijā kļūdas Y/N? Ir kaut kādi paplašinājumi, ka tur tas kadrs kaut kā nemainās viss, bet pa daļām vai kā - es nezinu.

 

Domājam tālāk. Veidojam maksimāli vienkāršu modeli - melnbaltu attēla punktu nosaka 8 bitu rindiņa - no balta līdz melnam kopā 256 varianti. Tā ir, nav, nezinu, domāju tikai modeli. Ir kaut kādi papildinājumi, kāpēc modelis aplams?

 

Tagad definējam to, kas ir attēla ņirboņa un kas ir tas labums no 400Hz. Laikam taču iespēja pāreju no pilnīgi melna uz baltu vai no 58 uz 107 tajos liekajos kadros piesmērēt ar visādiem starpstāvokļiem starp 58 un 107. Der šis pieņēmums modelim vai neder vai pilnīgi citādi to dara?

 

Tagad iedomājamies tādu attēla gabalu 8x8 punkti, kur katram punktam ir vērtība A pirmajā 50Hz kadrā un vērtība B otrajā 50Hz kadrā.  400Hz tv - tur ir vēl 7 kadri starp tiem diviem.

 

Domājam , pēc kādiem principiem vajadzētu veidot tās 7 vērtības.

1. Kāda ir sākuma un beigu vērtība.

2. Kas notiek blakuspunktos.

 

Pēc pirmā kritērija - jāātņem un jādabū starpība, kas ir 49, sanāk, katrs kadrs ik pa 7 klāt un notiek plūdena pāreja. vajadzīgas darbības C realizē - vispirms dabū starpību un tad izdala. Ko izmanto, kā to pieraksta C valodā? Ko tad, ja precīzi nedalās?

 

Pēc otrā kritērija - kas notiek blakus - vai tas punkts ir vienas diezgan vienveidīgas attēla detaļas vidū, vai pie malas? Pēc kādiem algoritimiem tad taisīt to pāreju?

 

Citi jautājumi - kā ielasīt lielāku bildi, kā to dalīt - kvadrātos, strīpās, apmēram viena toņa laukumos, kā to pārvērst instrukcijās.

 

Nu apmēram tā es to saprotu, kā to reāli varētu darīt, lasījis neesmu, bet ieinteresēja, izlasīšu.

 

Kaut kas no šitā punktu izklāsta varētu tikt izmantots kustīgu objektu atpazīšanai un vienveidīgi kustīgu  objektu (koki vējā ) atšķiršanai no jauniem objektiem.

Labots - Raimonds1
Link to comment
Share on other sites

Skaņas un attēla apstrādes programmatūru labāk nepiesaukt. Vismaz iesākumā. Tā galīgi nav trūkstošo vietu aizķēpāšana ar kaut ko. Ja šeit sākotnēji diskusija bija par  "int" un "float" formātiem, tad skaņas un attēla apstrādes programmu matemātiskie modeļi lieto, piemēram, tādus jēdzienus kā ortogonāli vektori n dimensiju telpā. Vot pamēģini ko tādu iztēloties! Un pēc tam vēl uzrakstīt softu, kas ar tādām lietām operē! Bet skaņas un attēlu apstrādes programmas to vien dara. Bet kāds, kurš pašlaik cenšas tikt skaidrībā par "int" un "float" formātiem, to nosauc par tukšo vietu aizķēpāšanu!

  • Patīk 2
Link to comment
Share on other sites

Mezavecis

Tavs piemērs ne tuvu nav triviāls, jo video attēlošanā pa vidu ir daudz un dažādi etapi. Triviāli būtu paņemt parastu attēlu un mēģināt no krāsainas bildes uztaisīt melnbaltu ar un bez pelēkiem toņiem. Lūk tas būtu triviāls un visiem saprotams uzdevums, ja tiešām gribas programmēt grafiskas lietas.

 

Man nav pārliecība, ka šīs teorijas kaut kad iedzīvināsi dzīvē. Esmu daudz redzējis teorētiķus, kas izvirza mērķus, bet tālāk par spriedelējumiem un augstiem mērķiem nav sasnieguši. Par cilvēku spriež tikai pēc darbiem. Ja kāds nolēmis būt par programmētāju vai vismaz mācēt programmēt, tad tikai darbi liecinās par šīs vēlmes nopietnību. Nu nevar uzreiz būvēt tiltu, ja nav pat lieveni mājas priekšā neprot taisīt. Analoģiski ar pliku algoritmu nespēsi neko uzprogrammēt, ja nepratīsi, kā programmēšanas rīkus izmantot. 

 

Arī salikt objektu nav tas pats, kas uzkonstruēt objektu. 

 

Kāpēc tikai gatavs izpildīts uzdevums skaitās kaut kas vērtīgs?
Link to comment
Share on other sites

Raimonds1
(labots)

Es mēģinu atrast jaunu pieeju sākuma zināšanu ieguvei. Tādu, kas atšķiras no pašlaik pieejamiem.

 

Viens jautājums būtu - cik tālu var trivializēt kaut kādu procesu, lai to izskaidrot būtu gana vienkārši un , pie viena, netiktu pazaudēts tas pamats, uz kura balstās sarežģītas lietas.

 

Nu labi, pikseļu pieķēpāšana nebija labs piemērs, paņemsim kustīga objekta atpazīšanu.

Labots - Raimonds1
Link to comment
Share on other sites

Mezavecis

Viss jaunais ir aizmirsts vecais. Jāsāk ar vienkāršu lietu, ko izprotam, un tad tālāk būvējam modeli un tā realizāciju. Programmējot attēlus un video ir jābūt ļoti labai izpratnei par attēlu apstrādi. Trivializēt nevar no konteksta izrautas kompleksas lietas, kur pa vidu vēl ir datu pārraide, kompresija un izlikties, ka to nav un galarezultāts nesaturēs visas funkcijas. 

 

Es nojaušu, ka matemātiķim-teorētiķim aprakstot jebkuru procesu ar formulām, liekas, ka to pašu var tādā pašā veidā materializēt ar koda palīdzību.  Pat vienkāršs integrālis izskatās pavisam savādāk.

 

Darbā kolēģis taisa sejas atpazīšanas aplikācijas un tur jāiegulda kaudze laika, lai vispār saprastu, kā tas darbojas un kā realizēt. Tas ir vairāku gadu darbs šajā virzienā, lai tiešām varētu iegūt darbojošu rezultātu ar visām programmēšanās priekšzināšanām.

Labots - Mezavecis
  • Patīk 1
Link to comment
Share on other sites

 

 

Galvenais neaizmirst, ka plika mācīšanās bez praktiska pielietojuma ir izniekots laiks.

Nu es gan tā neteiktu, kā reiz "plika mācīšanās" nereti dod krietni labākus rezultātus nekā spiešana uz "pratisku pielietojumu". Vienā gadījumā cilvēks cenšas saprast, kas ir kas, kas kā strādā utt, otrā gadījumā - truli sasniegt kaut kādu nebūt rezultātu. Tajā otrajā gadījumā nereti tad arī rodas koda gabali, kuru vieta būtu miskastē, nevis reālā produkcijas vidē.

 

Tas, protams, pieņemot, ka ar "pratisku pielietojumu" bija domāts kaut kāds reāls, praktiski noderīgs softs, nevis elementārs paša izdomāts uzdevums, kurš pēc atrisināšanas tiek nolikts plauktiņā "pabeigts un aizmirsts" (un nav svarīgi, vai tā atrisināšana prasījusi 1h, 1d vai 1w).

Link to comment
Share on other sites

Mezavecis

Kādus rezultātus? Lai varētu gudri par teoriju patērzēt forumā un tēlot ekspertu (lasīt: tukšmuldētāju) tēmā C# vs. Java? Tā trulā rezultātu sasniegšana nozīmē to, kā mērķis izvēlēts nepareizi, piemēram, taisīt kārtošanas algoritmu, kas jau miljons variācijās jau uztaisīts un izdomāts. Kā jau minēju iepriekš, testa piemēri vai testa progas ir laba lieta treniņam, bet tas nevar būt pašmērķis, lai tagad kļūtu par speciālistu.  

 

 

kā reiz "plika mācīšanās" nereti dod krietni labākus rezultātus nekā spiešana uz "pratisku pielietojumu".
 

 

Kas vieglāk uztverams - lasāmgabals vai Pyton valoda? Jāpierod, ka visa tehniskā dokumentācija būs tikai angļu valodā, kā jau visur pasaulē tas ir pieņemts.  Ir labi dažādi apraksti un grāmatas, bet tā kā joprojām neesi nodefinējis, ko tu gribi mācīties un kāpēc, tad kaut ko ieteikt nevarēs.

 

 

Palasīju šo, man šitas nez kāpēc šķiet vieglāk uztverams, kā C pieraksts 
 
Link to comment
Share on other sites

Raimonds1

Tu visu velc uz baigo konkrētību, termiņiem, iznākumu, rezultātu.

Tas ne vienmēr ir tas, kas vajadzīgs.

 

Reizēm vajag apzināt visādus variantus, reizēm meklējot un skatoties kaut ko vienu, nonāk pie cita rezultāta.

man nekādi projekti nav jānodod un nekādi kursa darbi nav jāpilda, es varu relaksēti prātot par kaut kādu tur attēla pikseļu ķēpāšanu, tad palasīt atsauksmes, atcerēties kaut ko par skaitļu rindām un fantazēt par kaut ko citu.


 

 

Kas vieglāk uztverams - lasāmgabals vai Pyton valoda?

 

tieši pats koda pieraksts 

Link to comment
Share on other sites

Mezavecis

Kāds tad būs sausais atlikums no nekonkrētas rīcības? Droši vien pavārīšanās pa tēmu un pēc mēneša viss būs aizmirsts.

 

Lai pafantazētu, nav pat C++ jāmācās. Pietiek palasīt Žila Verna romānus un fantāzijai pietiks. Mūsdienu variācijā youtube pilns ar dažādiem fantastikas "projektiem" kā bezjēdzīgi nosist laiku.

Link to comment
Share on other sites

Raimonds1
(labots)

Es saprotu, ka C un C++ nav Tavi valodu favorīti.

Un tam 

 

Jāpierod, ka visa tehniskā dokumentācija būs tikai angļu valodā, kā jau visur pasaulē tas ir pieņemts

 

 

ir vismaz 3 iespējamie secinājumi.

1. Man tiešām vēl jāmācās speciālā angļu valoda.

2. Lai orientētos un mācitos, tā specifiskā valoda ir jāzina visiem, kas mācās programmēt.

3. Latvijas speciālisti par Assembleri un C tik tiešām neko visiem plaši pieejamu nav uzrakstījuši vai iztulkojuši. Tas būtu svarīgi tieši sākumposmā.

 

Lasot Jūsu strīdus par programmēšanu, man ir radies tāds neiesaistita cilvēka viedoklis, ka katrs savas zināšanas ir ieguvis lepnā vientulībā, cik nu varējis, pats studējot literatūru un programmējot un tik daudzveidīgus un pretrunīgus uzskatus par to, kas labs, kas slikts, es neesmu redzējis nevienā nozarē. Elektronikā ir daudz vienkāršāk. Oma likums ir Oma likums un Būla algebra ir Būla algebra.

http://veikals.drukatava.lv/lv/books/book/137/ziedonis-bunzs-ciparu-elektronika

 

Te piemēram, viss ir skaidrs, kur glabā datus, kur izvada, kā apstrādā.


 

 

Kas vieglāk uztverams - lasāmgabals vai Pyton valoda?

 

Arī tādi sīkumi, kā l un 1 piemēram vai iekavas iekavās. 


Vej, kur C valodā parādās rūpe par resursiem

http://www.tutorialspoint.com/cprogramming/c_bit_fields.htm

 

Now, the above structure will require 4 bytes of memory space for status variable but only 2 bits will be used to store the values. If you will use up to 32 variables each one with a width of 1 bit , then also status structure will use 4 bytes, but as soon as you will have 33 variables, then it will allocate next slot of the memory and it will start using 8 bytes. Let us check the following example to understand the concept:  tur ir piemērs.

Labots - Raimonds1
Link to comment
Share on other sites

Mezavecis

Es programmēju arī C++, ja ir tāda nepieciešamība, bet ikdienā ņemos ar C# vai Java. Favorīts ir C#, jo tas pārklāj lielāko daļu no vajadzībām. Tas gan nemaina programmēšanas principus. Protams, C# nav jānodarbojas ar atmiņas dalīšanu, bet gluži aizmirst par resursiem nedrīkst.

 

Ja cilvēks nezina angļu valodu, tad kā programmētājam nav izredžu attīstīties. Jebkura padziļināta literatūra, tehniskā dokumentācija ir tikai angliski. Tāpēc arī neviens netulko, jo visi uzskata par pašsaprotamu to zināt. Tāpat kā ārstiem jāzina ķīmija un zāļu nosaukumi ir latīņu valodā. Ir arī daudz materiālu krievu valodā, bet ar to var tikt cauri līdz zināmam brīdim.

 

Es zināšanas esmu pats apguvis programmējot nopietnos programmēšanas kantoros pie nopietniem reāliem risinājumiem. Ja to uzskata par vientulību, tad acīmredzot grūti kaut ko iebilst ekspertam. Tāpēc arī ir tiek kategoriska nostāja pret mākoņu zīmēšanu. Katram ir sava vieta. Ja neprot, negrib vai nespēj programmēt, tad jādara lietas, kuras ir pa spēkam, nevis tēlot ķīmiķi, fiziķi un matemātiķi lasot gudrus materiālus. 

 

 

katrs savas zināšanas ir ieguvis lepnā vientulībā, cik nu varējis, pats studējot literatūru un programmējot
Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...