պատմեմ ձեզ ինչ ահաւոր սխալ եմ արել վերջերս։

ուրեմն, մեծ ընկերութիւնները հակուած են պահել իրենց դատա֊սենթրները, ուր պիտի տարբեր խնդիրներ լուծեն՝ հովացման, սնուցման կայուն լինելու, նաեւ պիտի անձնակազմ ունենան, որ էդ ամէնի հետ կարողանայ աշխատել։ հաճոյքը թանկ ա, ու միտում կայ հնարաւորը տանել ամպեր, աութսորս անել, եւ գլխացաւանքից ազատուել։ սակայն ամէն֊ամէնը չի լինի տանել, բացի գաղտնիութիւնից կան նաեւ ֆիզիկայի եւ տարածութեան սահմանափակումներ՝ օրինակ mount արածդ հեռակայ դիսկի հետ չես ուզում դանդաղ աշխատել։

ինչեւէ, էդ մեծ սերուերնոցները պահելիս ժամանակ առ ժամանակ լինում ա որ պէտք ա դրանք անջատուեն։ լրիւ։ ու գործը կանգնի։ կարելի ա, իհարկէ, եւ առանց անջատուելու, բայց անհամեմատ աւելի թանկ ա որ նոյնիսկ այդ մեծ ընկերութիւններն իրենց թոյլ տալ չեն կարող։ իսկ անջատելը բովանդակալից ու ժամանակատար պրոցես ա, ու այդ մասին չեմ ուզում գրել, այլ իմ սխալի մասին։

սերուերնոցից դուրս կան մարդկանց workstation մեքենաներ, որոնց վրայ լինուքս ա եւ մասնագիտական ծրագրակազմ։ տան պանակը, ինչպէս եւ այլ գործ անելու պանակները՝ հեռակայ են, կպնում են աւտոմատ, ըստ անհրաժեշտութեան։ մո՞ւտք ես գործում օհ՝ քեզ տան պանակ ա պէտք՝ այդ պահին էլ օհ֊ն այն կը կպցնի հեռաւոր ռեսուրսից։

հիմա, եթէ դատա ցենտրը, եւ storage անջատելու հարց ա լինում՝ user workstation֊ները, մեծ հաւանականութեամբ, կախուած վիճակում են լինելու՝ nfs share֊եր չգտնելու պատճառով։ ու չի էլ լինի դրանք հեռավար վերամեկնարկել, զի դրանց վրայ reboot մեծ մասամբ չի աշխատի։ օհը֊ կը փորձի անջատել սերուիսներ, բայց կան պրոցեսներ, որ հնարաւոր չի լինի անջատել՝ ըստ դիզայնի։

այդ պատճառով մտածեցի էս անգամ սէնց բան անել՝ սիրում եմ at հրամանը։ կարող ես ասել՝ վաղը, էս ժամին, սէնց բան արա։ մտածեցի՝ պատրաստեմ վաղը, էս ժամին, երբ ենթակառուցուածքների ծառայութիւնները վերադարձուած լինեն՝ մեքենաները վերբեռնելու հրաման։

հարցն այն ա, որ ինչպէս ասացի՝ վերբեռելու սովորական հրամանը, որ համակարգի տարբեր ծառայութիւնները կանգնեցնում ա՝ դժուար աշխատէր մեքենաների մեծ մասի վրայ՝ համարեա գրեթէ անջատուած վիճակում էին մնալու։ ու ապա պէտք կը լինէր հատ հատ մօտենալ, ձեռքով վերբեռնել։

այդ պատճառով մտածեցի օգտագործել լինուքս միջուկի հնարաւորութիւնը՝ /proc ֊ն օգտագործելով ստիպել միջուկին անջատել եւ միացնել համակարգիչը, ինչպէս կանէիք «ռիսեթի» կոճակը սեղմելով։ էդ կոպտութիւնը մեղմելու համար նաեւ կարելի ա միջուկին նոյն միջոցներով ստիպել ֆայլային համակարգի բուֆերները նախապէս գրել, որ այդ ֆայլային համակարգը մինիմալ վնասուածքներ ստանայ, կամ չստանայ։

այսպէս, ես մտածեցի որ at֊ն կը կանչի էդ լինուքսի հնարաւորուիթւը՝ հարդուեր ռիսեթ անելու։

ինչ եղաւ իրականում՝ շատ բան չփոխեց, բայց աւելի հետաքրքիր դարձրեց եղածը՝ թիմից մէկը անտեղեակ լինելով իմ լուծման մասին, որոշեց անջատել բոլոր workstation֊ները ձեռքով։ քայլեց, բոլորը֊բոլորը գտաւ եւ անջատեց։ մինչեւ սերուերնոց անջատելը։ ու պատրաստւում էր յետոյ հատ հատ միացնել։

իսկ միացրեց աւելի ուշ, քան իմ at֊ին ասած ժամանակն էր։ ես ենթադրել էի, որ at֊ն ստարտ լինի, կը մտածի՝ լաւ, ժամն անցել ա, երեւի էլ չանեմ, էն ժամին պիտի անէի։

բայց պարզուեց, մեքենաների ուղիղ կէսը (հետաքրքիր ա, որ էդպէս եղաւ բաշխումը), ընկան ռեբութ լուփի մէջ։ միանում էին, միանում էր at դեմոնը, at֊ն տեսնում էր որ քանի ժամ առաջ թասկ ունի դրուած, ու այն դե՛ռ չի կատարուել, պանիկո՛ւմ էր, ու սկսում էր շտապ էդ թասքը կատարել։

իսկ թասքը՝ իմ մեղքի մասը՝ կտրուկ թասք ա՝ անջատում էր կարգիչն աւելի արագ, քան at֊ն հասցնում էր իր մատեանում գրել, որ գործն արուած ա։ յաջորդ անգամ միանում էր՝ տեսնում էր՝ ուշ ա, ժամը ժաիցմ անցել ա, իսկ գործն արուած չի՝ պանիկած էլի ընկնում էր կատարելուն՝ իսկ կատարելով չէր հասցնում նշել որպէս կատարուած։ (:

էսպէս, անասելու տառապել եմ 80 մեքենայի մօտենալով, եւ at֊ի հերթը մաքրելով։ հիւանդ գլխից, ինչպէս ասում են ռուսները՝ ոտքերն են ցաւում։ ինձ մօտ այդ ամէնից ոտքերը չցաւեցին, բայց գլուխը ցաւաց։

ինչպէս գիտենք, ճգնաժամային վիճակներում ամէնն ա աւելի բարդանում։ օրինակ՝ համավարակի պարագայում։

ու յիշեցի, որ նախկինում էլ ես կամ ինչ֊որ մէկը սխալներ անում էինք, ու տաս տարուայ մէջ մի երկու անգամ յիշում եմ, որ պէտք էր եղել բոլոր workstation֊ներին մօտենալ, մի երկու տող բան գրել։ ու դա ինձ նախկինում թւում էր շաաատ բարդ։

իսկ էսօր՝ գրեթէ ոչ մի մեքենայի մոնիտոր միացուած չէր։ ընդհանրապէս, գործի տեղը բաւական հետապոկալիպտիկ տպաւորութիւն էր թողնում։ մարդիկ կտրուկ վերցրել են մոնիտորները, ու թողելով ամէնը, ոնց կայ՝ հեռացել։ սեղաններին կային մարտ ցոյց տուող օրացոյցներ։ սեղաններին եւ լքուած ստեղնաշարերին փոշի էր նստել։ իսկ երբ դու չունես մոնիտոր՝ դա էն չի, որ մօտենում ես կարգչին, նստում բազկաթոռի մէջ, խելացի տեսքով գրում երկու հրաման, կարգիչը սկսում ա աշխատել, եւ շուրջդ ծապահարութիւններ են՝ փրկեցիր մարդկանց եւ վայելում ես փառքը։

չէ, մոնիտոր չկայ, եւ օգտատէր չկայ՝ քարշ տաս մոնիտորը հետդ, մի հատ էլ ստեղնաշար, եւ լարեր՝ այդ մոնիտորը միացնելու համար։ նաեւ տարբեր կարգիչներ ունեն տարբեր ձեւի վիդեօ քարտերի ելքեր՝ հետեւաբար՝ նաեւ մի քանի լար։ յետոյ մտնել սեղանի տակ, նայել ինչ ելքեր են, փոխել մոնիտորի լարը, միացնել այն, յետոյ անել գործդ, անջատել, անցնել յաջորդին։ առանց ծափահարութիւնների։

այդ ամէնը, ի դէպ, մի ուիք֊էնդ, որը… էս բարդ տարին ընկերութիւնը որոշեց մեղմել իր աշխատողներին պարգեւելով ազատ մի օր։ եւ փաստացի՝ լոնգ ուիքէնդ։ իսկ թարսի պէս, հէնց այդ գործը, մինչեւ նուիրատւութիւնն արդէն նախատեսուել էր անց կացնել հէնց այդ ուրբաթ օրուանից սկսած։ այսպիսով, երբ ողջ անձնակազմը ոչ միայն տանն էր, այլեւ վայելում էր երկար ուիքէնդ, երբ ընկերներս հաւաքուեցին դարգէթում պուտին ուտելու (դէ we bare bears֊ն եմ բացայայտել, իսկ էնտեղից իմացել կանադական պուտին ուտելիքի մասին, նաեւ կարճ հետազօտութիւնը բացայայտել ա որ այն կարելի ա պատուիրել դարգէթում), ես անց եմ կացրել փոշոտ սեղանների տակ։

իհարկէ, իմ խելքից։ բայց եւ նման սխալներ գրեթէ անխուսափելի են մեր գործում։ իսկ երբ երեւակում ես ժապաւէն՝ երբեմն կը սխալուես։ իսկ երբ կոդ ես գրում՝ երբեմն կը պայթեցնես։ կարճ ասած, ահա ձեզ իմ սխալը, որ իմանաք, ինչ ձեւ սխալներից կարելի ա խուսափել։

#սխալ #իւնիքս #ծրագրաւորում #տեքնոլոգիաներ #օպերացիոն_համակարգեր #պատմութիւն #անկապ

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

իւնիքս պրոցեսները ունենում են վիճակ։ օրինակ, կարող են լինել կանգնեցուած, կամ տուեալ պահին գործող։ կարող են լինել վրիպազէրծուող։

իսկ կարող են ունենալ պրոցեսների աղիւսակի մէջ որպէս D նշուած վիճակ, որի մասին ձեռնարկում ասւում ա՝ uninterraptible I/O wait։

ու uninterraptible ա այն բառացիօրէն՝ այն չի լինում ընդհատել։

հարցն այն ա, որ պրոցեսը՝ որը ծրագիր ա կատարման ընթացքում, անում ա տարբեր գործողութիւններ՝ օրինակ ինչ֊որ տուեալներ ա ստանում եւ մշակում։ մշակելու ալգորիթմը ձեւակերպում ա ծրագրաւորողը, իսկ ինչպէ՞ս ա տուեալներ ստանում՝ օրինակ դիսկից, կամ համացանցից։

դիսկից կամ համացանցից կարդալ ամէն ծրագիրը չպիտի կարողանայ՝ էդ օհ֊ի պարտականութիւնն ա՝ դիսկից մի բան կարդալ ու տալ ծրագրին։

այդ պատճառով ծրագիրը կանչում ա, դիցուք read() օհ֊ի API֊ի կանչ, ու երբ այն կանչում ա այդ ֆունկցիան, բնական ա, պիտի սպասի, մինչեւ օհ֊ը կարդայ, դիցուք մի բայթ, դիսկի որեւէ ֆայլից, ու տայ ծրագրին։ այս պահին արդէն ծրագիրը գործ չի անում՝ անում ա գործ կերնելը՝ միջուկը։

զի ժամանակակից օպերացիոն համակարգերը պետութեան կամ լուրջ կազմակերպութեան պէս են՝ ծրագիրը չի կարող ցանկացած ռեսուրսի դիմել, ինչպէս ընկերութեան աշխատողը չի կարող տեսնել HR֊ի կամ հաշուապահութեան տուեալները, իսկ ոստիկանութեան աշխատողը չի կարող առանց հատուկ հայցի դիմել փողոցային խցիկներից տուեալներ ստանալու համար։

այսպէս, DOS֊ի ծրագիրը փաստացի կարող էր օգտագործել համակարգի բոլոր հնարաւոր ռեսուրսները։ դա ծրագրին սովորաբար сходило с рук/it could get away with it հաջողւում էր առանց շատ խնդիրների, շնորհիւ նրա, որ այն միակ կատարուող ծրագիրն էր։

աւելի բեթար բարդ վիճակ էր windows95֊ոտ համակարգերում, ուր եւ ակտուալ էին BSOD֊ն ու viral դարձան վիրուսները։

բայց եւ աւելի հին, Unix համակարգերում, նման հարցերը վաղուց ինչ֊որ ձեւ լուծուած էին եւ էդ լուծումները դարձան մէյնսթրիմ այսօր (այլ հարց ա որ դրանք լուծելու այլ ժամանակակից տեսակէտներ կան)։

էսօր սովորական լուծումն այն ա, որ ծրագիրը չի կարող օգտագործել որեւէ ռեսուրս առանց օհ֊ի թոյլտւութեան, զի բոլոր ռեսուրսները՝ ֆայլերը, յիշողութիւնը, նկարչութիւնը (վիդեօ յիշողութիւնը), ցանցը՝ տրամադրում ա միջուկը, հաւանութիւն տալով ծրագրի հայտին, կամ մերժում ա, չի տրամադրում՝ համարելով որ այդ պրոցեսը (որն աշխատում այդ օգտատիրոջ անունից) չի կարող դիմել ռեսուրսի համար, կամ որ աւել ռեսուրս իրան չի հասնում՝ չափազանց շատ ա արդէն օգտագործել, եւ այլն։

այսպէս, նիշքից կարդալու համար, նախ պէտք ա օհ֊ին խնդրել այդ նիշքը տրամադրել, իսկ երբ այն թոյլ տայ՝ օկ, բացիր նիշքը, պիտի ամէն անգամ խնդրես օհ֊ին որ կարդայ, ու քեզ ասի ինչ ա մէջը գրուած։ ինքնուրոյն քիթդ խոթել դրա մէջ չես կարող՝ ամէնն արւում ա օհ֊ի միջոցով։

(windows֊ի աշխարհում դա սկսուեց windows nt֊ից, որն աւելի մասնագիտական, ոչ մէյնսթրիմ մայքրոսոֆթի օհ էր։։ իննսունականներին nt օգտագործող ծրագրաւորողները հպարտանում էին որ իրենց կարգիչներն անհամեմատ աւելի անխոցելի էին զանազան վիրուսների հանդէպ, իսկ windows 2000֊ից նոյն մօտեցումը կիրառուեց աւելի մէյնսթրիմ՝ ոչ միայն մասնագէտների համար։ իսկապէս, win{95,98} ընտանիքի օհ֊ի համար վիրուս գրելն առանձնապէս բարդ չէր՝ արա ինչ ուզում ես, ոչ ոք ձեռքերիդ չի խփի։ nt ընտանիքի օհ֊երի համար վիրուս գրելն արդէն էդքան տրիւիալ գործ չէր, բայց ինչպէս տեսնում ենք մինչ այսօր՝ լրիւ իրատեսական։)

հիմա հասանք այն պահին, որ խնդրում ենք օհ֊ից կարդալ բայթ՝ նիշքից։ ասացինք՝ read(), մեր ծրագիրն էս պահին այլեւս սպասում ա։ եթէ սպասելը երկար ա՝ դուք դա նկատում էք՝ ինտերֆէյսը սառում ա, երբ ծրագրաւորողը multithreaded ձեւով չի գրում։ սկսում էք կտացնել տարբեր տեղեր, եւ գիտէք, ձեր կտոցները պահւում են հատուկ բուֆերի մէջ, որը կոչւում ա message queue, որ յետոյ, երբ ծրագիրն վերսկսի աշխատանքը, էդ ձեր message֊ները պրոցես անի։

արեցինք read() ու այս պահին արդէն գնդակը միջուկի դաշտում ա, պիտի սպասենք մինչեւ մի բան վերադարձնի։ իսկ ի՞նչ անի էդ խեղճ միջուկը, եթէ էս պահին ֆայլը հասանելի չի՝ օրինակ դիսկն ա վատացել, ու չի պատասխանում, կամ դիսկը հեռավար ա, ու կապն ա անջատուել, եւ նիշքը չի երեւում։ կամ ցանցային այլ ռեսուրսից ենք օգտւում, ինտերնետ սոքեթից ենք բան կարդում։

էս էն պահն ա, երբ պրոցեսն ընդունում ա uninterraptible I/O wait կարգավիճակ։ ինչի՞ ա uninterraptible՝ հարցն այն ա, որ էդ պրոցեսը սպանել չի լինի, զի միջուկի ներսի կարդացող պրոցեսը, ըստ միջուկի ծրագրաւորողների սպանել չի կարելի։ այդ դէպքում՝ միջուկի պրոցեսի ընդհատումը կը բերի միջուկի յիշողութեան անկանխատեսելի վիճակին, որը կարող ա բերել ընդհանուր օպերացիոն համակարգի անկանխատեսելի վիճակին։ եւ միջուկի նախագծողները համարեցին (բնականաբար) որ աւելի լաւ ա թոյլ չտալ որոշ պրոցեսներ ընդհատել, կամ այդ ընդհատումը կարող ա բերել այն աղէտալի վիճակի, որ աւելի լաւ ա մարդը, եթէ իրան իսկապէս պէտք ա՝ կոճակը սեղմելով կարգիչը վերամեկնարկի։

ինչի՞ կոճակը սեղմելով՝ զի միջուկը ինքը չի կարող ազատուել, հիմնականում, այդ իր միջի չարաբաստիկ պրոցեսից՝ զի միջուկը չի կարող շարունակել նորմալ աշխատանք եթէ ընթերցող պրոցեսն ընդհատի։

հետեւաբար նման համակարգ չի էլ լինի հրամանով(shutdown, poweroff, halt) անջատել։

իրականում ֆուտբոլը կարող ա իսկապէս լինել լաւ մետաֆորա՝ պատկերացրէք, գնդակը միջուկի՝ այլ թիմի խաղացողների մօտ ա։ պիտի հետը մի բան անեն, նոր տշեն քեզ հետ։ եթէ ընդհատես սպասելդ, ասես՝ չէ, գնդակը պիտի հէնց հիմա յայտնուի ինձ մօտ, ապա էն խաղացողները, որ գնդակ էին տշում, կարող ա իրար խփեն, ընկնեն, վնասուեն՝ անկանխատեսելի ձեւով։ եւ տէնց վնասուած օհ ունենալ աւելի վտանգաւոր ա, քան կախած պրոցես։ այլընտրանքը՝ ձեռքով կոճակ սեղմելն՝ աւելի անվտանգ ա։

ծրագրաւորման ու տտ աշխարհի հետ, իրականում շատ լաւ բռնում են իրական կեանքի, կամ գրքերի սցենարները։ պատկերացրէք, գիքորը բերում ա սամովարը դնի տիրոջ սեղանին, զի պիտի սցենարով առաջնորդուի, բայց պարզւում ա՝ սեղան չկայ, սամովարի միջի տաք ջուրը թափւում ա՝ բոլորն այրուածքներ են ստանում։ ահա ձեզ զուգահեռ ծրագրաւորման օրինակ։

դէ մինչ։

#ծրագրաւորում #տեքնոլոգիաներ #գիքոր #սամովար #զուգահեռութիւն #միջուկ #կերնել #իւնիքս #օպերացիոն_համակարգեր #օհ #ծրագրակազմ

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

այլ խօսքերով՝ եթէ համակարգում պտտւում են անորոշ քանակի խնդիրներ, դժուար թէ ստացուի ապահովել համակարգի բոլոր գործառոյթների կատարման որոշակիութիւնը։ այդ պատճառով համակարգի կանխատեսելիութիւնը բարձրացնելու ամենապարզ լուծումն ա՝ դրա ֆունկցիոնալի սահմանափակումը։

աղբիւր

#տեքնոլոգիաներ #դիզայն #օպերացիոն_համակարգեր #նախագծում #ռուսերէն #որոշակիութիւն #ծրագրաւորում

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

շատ երկար ա rust֊ը քոմփայլ լինում մի թրեդով, իսկ ֆֆ֊ի թարմացումը իր հետ ռասթի թարմացում ա պահանջում։

մի թրեդով եմ անում որ ուրիշ գործեր անեմ կողքից, ու կարգիչը շատ չտանջուի։

ու մտածում եմ՝ էսա ֆֆ֊ն չլինի, ի՞նչ եմ անելու։

գտնելու եմ ինչ֊որ շատ թեթեւ բան՝ midori֊ի պէս, ու դէ այն կայքերի մեծ մասը չի բացի, դէ ես էլ չեմ մտնի էդ կայքերը։

երեւի տէնց։

առհասարակ, դա վատ մօտեցում չի։

ես ջս չեմ սիրում, ու ատում եմ երբ տաքանում են կարգիչները, ֆաներն են պտտում, ինչ ա թէ վեբ էջ են բացել։ ահաւոր հզօր կարգիչներ ունենք՝ ու վատնում են իրենց հզօրութիւնը էդ ձեւ ինտերպրետացուող կոդի վրայ։ էնպէս չի որ դանդաղ են կամ դանդաղում են։ վատ ա ամէնը։ ահաւոր։

ու տէնց։

#ոստայն #սարդոստայն #համացանց #ծրագրաւորման_լեզուներ #ծրագրաւորում #տեքնոլոգիաներ #կարիգչ #դիտարկիչ #զննիչ #ֆայրֆոքս #ինտերնետ

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

հաւէս յօդուած ա սա շատ՝ https://www.joelonsoftware.com/2001/12/11/back-to-basics/

իսկ օբերոնում վիրտը որոշել ա հրաժարուել պասկալական տողերից, ու կիրառել զրօյով աւարտուող տողեր։

սակայն, էդ տողերով կարիք չկայ միշտ վազել չափն իմանալու համար։ առանձին դաշտ էլ պէտք չի օգտագործել ու յիշողութեան մէջ մի տեղ պահել չափսը՝ քոմփայլերը գիտի տողի երկարութիւնը։

ու քոմփայլ թայմ թեստ կարող ա անել։ դիցուք վերցնենք էս ելատեքստը՝

MODULE tst;
IMPORT Out;

VAR i: SHORTINT;
str: ARRAY 1024 OF CHAR;

BEGIN

FOR i := 0 TO LEN(str) DO
Out.Int(i, 0); Out.Ln
END;

END tst.

այն քոմփայլ չի լինի՝

[2020-09-02 16:00:20] $ voc -m tst.Mod 
tst.Mod  Compiling tst.

9:   FOR i := 0 TO LEN(str) DO
^
pos   102  err 113  incompatible assignment

Module compilation failed.
[2020-09-02 16:00:21] $

voc֊ը որ դէպի C ա թարգմանում սորսը, շատ լաւ ա պատկերելու համար։ եթէ մենք ունենք՝

str: ARRAY 16 OF CHAR;

ապա ելքային C կոդը կը լինի՝

static CHAR tst_str[16];

միայն դա։

իսկ

FOR i := 0 TO LEN(str) DO

կը թարգմանուի որպէս՝

tst_i = 0;
while (tst_i <= 16) {

Երբ մենք գրում ենք տողի հետ աշխատող ֆունկցիա, մենք կարող ենք չիմանալ փոխանցուող տողի երկարութիւնը՝

MODULE tst2;

PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;

PROCEDURE test*;
VAR
s0: ARRAY 32 OF CHAR;
s1: ARRAY 64 OF CHAR;
BEGIN
addStrs(s0, s1);
END test;

END tst2.

եւ ապա սի կոդը կը լինի՝

static void tst2_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* here we think we can do smth useful */
}

void tst2_test (void)
{
CHAR s0[32];
CHAR s1[64];
tst2_addStrs((void*)s0, 32, (void*)s1, 64);
}

այսինքն՝ ֆունկցիան ստանում ա նաեւ տողի երկարութիւնը։ ու եթէ անել LEN(a) անմիջապէս՝ առանց ոչ մի հաշուարկ՝ ստանում ես տողի երկարութիւնը։

ապա ինչպէ՞ս են աշխատում դինամիկ տողերը։

MODULE tst3;

PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;

PROCEDURE test*(i: INTEGER);
VAR
s: ARRAY 32 OF CHAR;
ps: POINTER TO ARRAY OF CHAR;
BEGIN
NEW(ps, i);
addStrs(s, ps^);
END test;

END tst3.

ունենք մի հատ ստատիկ տող՝ s ու մի հատ դինամիկ տողի ցուցիչ՝ ps։ ps֊ի չափսը կը ստանանք որպէս ֆունկցիայի արգումենտ՝ էս պահին մեզ անյայտ ա։

առաջին ֆունկցիան մնում ա անփոփոխ, երկրորդը թարգմանւում ա սէնց՝

static void tst3_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* do smth useful here */
}

void tst3_test (INT16 i)
{
CHAR s[32];
struct {
ADDRESS len[1];
CHAR data[1];
} *ps = NIL;
ps = __NEWARR(NIL, 1, 1, 1, 1, ((ADDRESS)(i)));
tst3_addStrs((void*)s, 32, (void*)ps->data, ps->len[0]);
}

_NEWARR֊ն արդէն մի քիչ բարդ ֆունկցիա ա, որը ռանթայմի մաս ա։ բայց ընդհանուր առմամբ պարզ ա ինչ ա անում՝ հիփ֊ի մէջ ալոքէյթ ա անելու տող, եւ մեր ստացած ցուցիչն արդէն struct֊ի ա, որն ունի data դաշտ եւ len դաշտ։

սա ռանթայմ տեղեկատւութիւն ա, ու այս դէպքում արդէն մեզ պէտք ա պահել առանձին դաշտ տողի երկարութեան համար։

ու տէնց։

#օբերոն #ծրագրաւորում #տող #տողեր #պասկալ #սի #վիշապ #իրականացում #կազմարկում #կոմպիլյատոր #կոմպիլեատոր #կազմարկիչ

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)