include

• 2024-08-10-24557272 – 2024-08-10
  

  գուցէ գիտէք, որ borland֊ը որ ստեղծել էր delphi֊ն, փորձեց object pascal֊ում եղած ֆիչըրները բերել c++։ ու բորլանդի c++֊ը տարբերւում ա սովորական c++֊ից նրանով, որ ունի այսպէս կոչուած closure֊ներ, կամ անոնիմ մեթոդներ։

  իրականում, եթէ գալիս ես օբերոնից՝ ոչ մի տարօրինակ բան չկայ, շատ նորմալ ֆունկցիոնալ ա։

  ահա օրինակ՝

  type
  TNotifyEvent = procedure(Sender: TObject) of object;
  
  TButton = class
  private
  FOnClick: TNotifyEvent;
  public
  procedure Click;
  property OnClick: TNotifyEvent read FOnClick write FOnClick;
  end;
  
  procedure TButton.Click;
  begin
  if Assigned(FOnClick) then
  FOnClick(Self);
  end;
  
  procedure MyButtonClick(Sender: TObject);
  begin
  WriteLn('Button clicked!');
  end;
  
  procedure SomeEntryPoint;
  var
  Button: TButton;
  begin
  Button := TButton.Create;
  Button.OnClick := @MyButtonClick;
  Button.Click;  // Outputs: Button clicked!
  Button.Free;
  end;
  

  TNotifyEvent֊ը ֆունկցիայի, պրոցեդուրայի տիպ ա։ յետոյ այդ տիպի պրոցեդուրա ա կարելի ստեղծել։

  Sender: Tobject ֊ը մեզ պէտք ա, որ իմանանք ով ա այդ event֊ը ուղարկել։ ինչի՞ ա ինքը TObject տիպի՝ որովհետեւ դա կլասսերի ծառի արմատն ա՝ ամէնը դրանից են ժառանգած, այսինքն՝ ամէնը կարելի ա դրան վերագրել։

  օրինակ, կարելի ա էսպէս իմանալ թէ ով ա՝

  if Sender is TButton then  // Check if the sender is a button
  begin
  if TButton(Sender).Name = 'Button1' then
  ShowMessage('Button 1 was clicked!')
  else if TButton(Sender).Name = 'Button2' then
  ShowMessage('Button 2 was clicked!');
  end
  else
  begin
  ShowMessage('Something else triggered this event!');
  end;
  

  տեսէք լրիւ օբերոնի runtime check անող IS ֊ն ա։

  Button(Sender).Name ֊ը թոյլ ա տալիս կարդալ էդ կոնկրէտ կոճակի անունը։ օրինակ, կարող ես կոճակի անունը դնել Button1, իսկ կարող ես օրինակ՝ processButton։

  Button֊ը իրականում ցուցիչ ա յիշողութեան մի տեղի, որ դատարկ ա։

  TButton.Create֊ը լցնում ա էդ տեղը, ստեղծում ա յիշողութեան մէջ դաշտերը, կլասը, ու վերադարձնում ա էդ պատրաստուած յիշողութեանը ցուցիչ։

  Button.OnClick֊ին կարողանում ենք վերագրել MyButtonClick ֆունկցիայի հասցէն։

  այդ OnClick֊ը pascal֊ի property ա, որը կայ իմ իմանալով միայն այլ անդրեաս հայլսբերգի լեզուի՝ c#֊ի մէջ։

  դրանից յետոյ Button.Click֊ը դա ա կանչելու։

  շատ օբերոնական ա, չէ՞։ (:

  ո՞նց ա դա արւում borland֊ի c++ դիալեկտով՝

  #include <vcl.h>
  #pragma hdrstop
  
  class TButton
  {
  private:
  typedef void __fastcall (__closure *TNotifyEvent)(TObject *Sender);
  TNotifyEvent FOnClick;
  public:
  void __fastcall Click()
  {
  if (FOnClick)
  FOnClick(this);
  }
  
  void __fastcall setOnClick(TNotifyEvent value)
  {
  FOnClick = value;
  }
  
  TNotifyEvent __fastcall getOnClick()
  {
  return FOnClick;
  }
  
  __property TNotifyEvent OnClick = {read=getOnClick, write=setOnClick};
  };
  
  void __fastcall MyButtonClick(TObject *Sender)
  {
  ShowMessage("Button clicked!");
  }
  
  int main()
  {
  TButton *Button = new TButton;
  Button->OnClick = MyButtonClick;
  Button->Click();  // Outputs: Button clicked!
  delete Button;
  return 0;
  }
  
  

  նախ, ահագին ոչ ընթերնելի ա, ինձ թւում ա։

  յետոյ, դէ մասնաւորապէս որովհետեւ fastcall֊ը նշանակում ա որ պասկալի ֆունկցիա ա կանչելու, զի ամբողջ գրադարանը (vcl֊ը կամ fmx֊ը) պասկալով ա գրուած։

  closure֊ը borland֊ի լուծումն ա որ մեթոդ փոյնթերն իմանայ this֊ի մասին։ ոնց pascal֊ում ա հնարաւոր։

  property֊ով են փորձում դէ property իրականացնել։

  հետաքրքիր ա, որ qt֊ն էլ ստանդարտ c++ չի՝ իրենք փաստացի նոր լեզու են ստեղծել, ու իրենց մօտ կայ moc (meta object compiler) որը յետոյ բերում ա qt֊ի կոդը ստանդարտ c++֊ի։ ու իրենք ունեն ինչ֊որ slot֊եր ու signal֊ներ որ էլի էմուլացնում են նոյն բանը՝ property֊ներ ու event֊ներ։

  gtk֊ում ստանդարտ c ա, ու դա աւելի ա դուրս գալիս։

  ի դէպ՝

  https://norayr.am/weblog/2021/04/18/2492083/ — այն մասին ա որ embarcadero֊ն այլեւս չի կարողանում իր c++ քոմփայլերը շարունակել, զի c++ ստանդարտն էնքան արագ ա շարժւում, որ չեն ձգում։ ու հիմա փաստացի մէյնթէյն են անում llvm֊ի փաթչեր։ llvm֊ի արտօնագիրն էլ թոյլ ա տալիս որ դա անեն։ աւաղ։ (:

  https://norayr.am/weblog/2021/04/19/2530704/

  #ծրագրաւորում #ծրագրաւորման_լեզուներ #տէք #պասկալ #օբերոն #pascal #oberon

  բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)

  ֊ի include pragma ծրագրաւորում ծրագրաւորման_լեզուներ տէք պասկալ օբերոն pascal oberon
• 2021-07-26-4747610 – 2021-07-26
  

  այն օրը ցանցառներում խօսում էինք, ինձ թւում էր որ փայնֆոնի երկաթը համեմատելի ա իմ xperia xa2֊ի երկաթին։

  փորձեցի փնտրել համացանցում, բան չհասկացայ, բացի նրանից որ փայնֆոնինը՝ 1.152ghz֊նոց 4 հատ cortex a53 պրոցեսոր ունի, իսկ էքսպերիան՝ 8 հատ 2.2ghz֊նոց Qualcomm Snapdragon 630 ա (14 nm)։

  հիմա ի՞նչ ա սա մեզ ասում։

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

  հիմա հեռախօսներ, բեմահարթակում երեքն են՝ pinephone, xperia xa2, motorola droid4։

  ահա, փորձեցի չափել արագագործութիւնը ըստ մի պրոցեսորի՝

  droid4

  վերջին պրոցեսոր՝

  processor       : 1
  model name      : ARMv7 Processor rev 3 (v7l)
  BogoMIPS        : 598.42
  Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
  CPU implementer: 0x41
  CPU architecture: 7
  CPU variant     : 0x1
  CPU part        : 0xc09
  CPU revision    : 3
  
  Hardware        : Generic OMAP4 (Flattened Device Tree)
  Revision        : 0000
  Serial          : 0000000000000000
  

  pinephone

  վերջին պրոցեսոր՝

  processor       : 3
  BogoMIPS        : 48.00
  Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
  CPU implementer: 0x41
  CPU architecture: 8
  CPU variant     : 0x0
  CPU part        : 0xd03
  CPU revision    : 4
  

  xperia xa2

  պրոցեսոր՝

  Processor       : AArch64 Processor rev 4 (aarch64)
  

  (առանձին ու սկբից ա միայն գրած, այլ սարքերի վրայ այդպէս չի)

  վերջին պրոցեսոր՝

  processor       : 7
  BogoMIPS        : 38.40
  Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32
  CPU implementer: 0x51
  CPU architecture: 8
  CPU variant     : 0xa
  CPU part        : 0x801
  CPU revision    : 4
  

  ելատեքստ՝

  user@devuan-droid4:~/bench$ cat bench.cpp
  #include <stdio.h>
  
  class Fib
  {
  private:
  int _value;
  public:
  Fib(int n) { _value = n; }
  int value()
  {
  if(_value <= 2)
  return 1;
  Fib f1 = Fib(_value - 1);
  Fib f2 = Fib(_value - 2);
  return f1.value() + f2.value();
  }
  };
  
  int main()
  {
  for(int i=0; i<2; i++)
  {
  Fib x = Fib(40);
  printf("n=%d\n", x.value());
  }
  return 0;
  }
  

  արդիւնքներ՝

  xperia xa2

  [root@XperiaXA2-DualSIM ~]# time ./bench
  n=102334155
  n=102334155
  real    0m 10.02s
  user    0m 9.90s
  sys     0m 0.00s
  [root@XperiaXA2-DualSIM ~]#
  

  փայնֆոն՝

  user@devuan-pinephone:~/bench$ time ./bench
  n=102334155
  n=102334155
  
  real    0m13.109s
  user    0m13.065s
  sys     0m0.005s
  user@devuan-pinephone:~/bench$
  

  մոտորոլա դրոիդ4՝

  user@devuan-droid4:~/bench$ time ./bench
  n=102334155
  n=102334155
  
  real    0m16.393s
  user    0m15.783s
  sys     0m0.174s
  user@devuan-droid4:~/bench$
  

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

  երեքն էլ բաւական մօտ են արդիւնքներով։

  մի նկատողութիւն՝ էքսպերիան, աւելի ճիշտ՝ սէյլֆիշը, նորմալ լինուքս չի մնացած երկուսի պէս, ու openrepos֊ում մի gcc նախագիծ կայ, որը չկարողացայ էլ տեղակայել։ ու 64բիթ պրոցեսոր ունենալով, 32բիթ օհ ա քշում։ (իրականում aarch64 ճարտարապետութիւնը, բնաւ amd64֊ի պէս չի պահում համատեղելիութիւն 32բիթանի arm միջուկների հետ, պարզապէս այդ (ինչպէս եւ որոշ այլ չիպսեթները կատարում են ե՛ւ մի ե՛ւ միւս isa֊ին համապատասխան հրամաններ) մնացածը դեբիան են՝ փայնֆոնը՝ 64բիթ, դրոիդը՝ 32բիթ, ու ես սէյլֆիշի տակ թեստն արեցի droid֊ի վրայ ստացած բինար նիշքով։ եթէ հէնց էքսպերիայի վրայ կազմարկէի, ինձ թւում ա եւս մի հինգ֊տաս տոկոսի առաւելութիւն կը լինէր։

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

  բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)

  include տեք լինուքս թեստ հեռախօս խելախօս ֆիբոնաչի արագագործութիւն պրոցեսոր օպերացիոն_համակարգեր համակարգիչ կարգիչ
• 2016-08-29-2177590 – 2016-08-29
  

  today we were discussing different spacecraft accidents caused by/related to software, discussed Arian-5 case, and I remembered a Soviet case, where there was a problem with decimal separator and Fortran compiler. Decimal separator in USSR was comma, but in Fortran code it should be the dot.

  Also, Fortran compiler did not consider using comma instead of the dot as an error, but as different code. And my friend said - the same is possible to do in C++ - and sent me the illustration.

  #include <iostream>
  using namespace std;
  int main()
  {
  cout << "Hello World" << endl;
  if (1,2!=1.2)
  {
  cout << (1,2) << endl;
  }
  return 0;
  }
  

  if you run it, you’ll get

  Hello World
  2
  

  (:

  #safety #programming #mistakes #safe #c++ #code #example #programming-languages #programming_languages #arian #fortran #source

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

  include safety programming mistakes safe c code example programming-languages programming_languages arian fortran source
• 2015-02-27-1314839 – 2015-02-27
  

  Now, modular programming is possible in C, but only if the programmer sticks to some fairly rigid rules:

  • Exactly one header file per module. The header should contain the function prototypes and typedef declarations to be exported, and nothing else (except comments).
  • The comments in a header file should be all that an external caller needs to know about the module. There should never be any need for writers to know anything about the module except what is contained in the header file.
  • Every module must import its own header file, as a consistency check.
  • Each module should contain #include lines for anything being imported from another module, together with comments showing what is being imported. The comments should be kept up-to-date. There should be no reliance on hidden imports which occur as a consequence of the nested #include lines which typically occur when a header file needs to import a type definition or a constant from elsewhere.
  • Function prototypes should not be used except in header files. (This rule is needed because C has no mechanism for checking that a function is implemented in the same module as its prototype; so that the use of a prototype can mask a “missing function” error.)
  • Every global variable in a module, and every function other than the functions exported via the header file, should be declared static.
  • The compiler warning “function call without prototype” should be enabled, and any warning should be treated as an error.
  • For each prototype given in a header file, the programmer should check that a non-private (i.e. non-static, in the usual C terminology) function with precisely the same name has its implementation in the same module. (Unfortunately, the nature of the C language makes an automatic check impossible.)
  • Any use of grep should be viewed with suspicion. If a prototype is not in the obvious place, that’s probably an error.
  • Ideally, programmers working in a team should not have access to one another’s source files. They should share only object modules and header files.

  http://www.modulaware.com/mdlt35.htm

  #programming #modularity #modular-programming #modules #C #modula #modula2 #oberon #consistency #safety

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

  include include programming modularity modular-programming modules C modula modula2 oberon consistency safety
• 2013-10-27-416205 – 2013-10-27
  

  https://groups.google.com/forum/#!topic/comp.lang.oberon/8Bmb20Ds8Cg

  #programming #usenet #1993 #oberon #c #libc #ulms-oberon-compiler #programming-languages #hello-world #write #printf #setlocale

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

  include include include define define programming usenet 1993 oberon c libc ulms-oberon-compiler programming-languages hello-world write printf setlocale