DEF FN ...

6 posts in thread

• Peter Goldmann <5080> · Text 7758 · w8 · inlagg

  1987-11-19 20:01

  Ärende: DEF FN ...

  Härom dagen började jag att peta lite i filtrans/QZ/T .806 för att få skärmen släckt när jag loggade ut. Eftersom jag börjat lite med QB så fick jag ideen att man skulle prova att funktionisera hela BASIC programmet - d v s att i princip alla instruktioner var av typen DEF FN. Fördelen med det är ju att man slipper hålla reda på radnummer i programmet som helhet - bara inom funktionen. Man kan då bygga upp hela programmen med sk strukturerad programmering. Man har då en huvudfunktion som normalt är sk huvudprogrammet DEF FNHuvud Z=FNFörst detta Z=FNSedan detta Z=FNDärefter detta Z=FNSlutligen detta Return 0 FNEND Z=FNHuvud Eftersom jag inte programmerar så ofta skulle jag uppskatta om någon ville lämna lite formella tips och kommentarer på följande: Hur hanteras ON ERROR exvis om man trycker ned PF-tangenter - hur vidarebefordrar man hanteringen från dessa väl så nästade funktioner om det genomförs konsekvent - hur undviker man att minnet blir fullt - p g a att för många nivåer lätt kan ge en uppsjö av pekare. Formellt är ju en FN uppbyggd av: Z = FNNamnet(Parameter_1,Parameter_2, .... ,Parameter_N) och där FN deklareras: DEF FNNamnet(P1,P2, ... ,Pn) Rad1 Rad2 Rad3 Return Q1 Rad10 Rad20 Rad30 Return Q2 . . . Rad1n Rad2n Rad3n Return Qn FNEND Beroende på förlopp kommer då Z=Qx när funktionen lämnas. Om man ej klarar att helt formalisera detta - finns det knep för hur man kan överföra ett goto-värde till huvudfunktionen? Dvs RETURN Hopp Och i huvudprogrammet Z=Hopp GOTO Hopp Anledningen till att detta kan vara intressant är att om man har en knutpunkt dit man medvetet styr hopp så upphäver man därmed faran med spagettisyndromet. Naturligtvis kan man sätta sig ned och testa - men det är ju bättre om vi hjälps åt - målet skulle vara att få BASICII att fungera som om BASICEN vore radnummerlös. Då uppnås två saker 1) Det är lättare att editera i radnummerförsedda rader - eftersom de INOM funktionen hålls ihop av radnumrena. Man kan då lätt flytta block och hitta till rader vart som helst i programmet. 2) Radnumrenas funktion har i stort upphävts - man har gjort sig närmast oberoende av dem. Dessutom kan man återanvända fungerande funktioner - man får ett med tiden svällande bibliotek av väl inkörda funktioner ... som kan överföras till PC och återanvändas där. I QB får man bara anropa funktioner som redan deklarerats - därför måste man göra tvärt emot som man är van i BASICII. Man definierar då först alla funktioner man använder och har huvud- programmet sist. Eftersom detta går att göra för både BASICII och QB kan man ju om man tänker köra båda rätta sig efter de BEGRÄNSNINGAR som QB påtvingar en.
  • Stefan Gartz <2600> · Text 7765 · w8 · kommentar

    1987-11-20 07:52

    Ärende: DEF FN ...

    Angående återhopp i funktion Ex: 100 DEF FNTest(Par1,Par2) LOCAL X,Y,Z 110 !Statusvariabel = Testq = global 120 ON Testq+1 GOTO 130,200,300 130 ! Del 1 140 xxxx 150 xxxx 160 Testq=1 :RETURN 0 200 ! Del 2 210 xxxx 220 xxxx 230 Testq=2 :RETURN 0 300 ! Del 3 310 xxxx 320 xxxx 330 Testq=0 :RETURN 0 340 FNEND Vill du spara lokala variabler så kan du stoppa dom i en global sträng innan du hoppar ut och ta fram dom igen vid nytt anrop Mvh Sgz
  • Kristoffer Eriksson <5357> · Text 7776 · w8 · kommentar

    1987-11-22 03:02

    Ärende: DEF FN ...

    ON ERROR GOTO är lokal i funktionerna i Basic-II. Om man har satt en ON ERROR GOTO i funktionen FNA och anropar FNB där en annan ON ERROR GOTO sätts, så kommer åter den första ON ERROR GOTO att träda i kraft när FNB avslutas och programflödet återvänder till FNA. Om FNB inte innehåller någon ON ERROR GOTO kommer den ON ERROR GOTO som gäller i FNA även att gälla i FNB, så att om ett fel (t ex från PF-tangent i INPUT) uppstår i FNB hamnar man i FNA:s felrutin. Detta kan man till nöds använda för att vidarebefordra fel till anropande rutiner. Det har förstås en del begränsningar. Man kan t ex inte ta hand om vissa fel i samma funktion som felet uppstod i, medan andra får fortsätta uppåt i "hierarkin", för det skulle ju kräva en ON ERROR GOTO-rutin som kollar vad det var för fel. Och man kan bara svårligen hantera "mjuka" fel på detta sätt. Med mjuka fel menar jag sånt som orimliga inmatnigsvärden, som man upp- täcker med IF-satser i motsats till fel som utlöses av Basic självt. Ett sätt att göra detta är att när ett sådan felsituation upptäcks utlösa ett vanligt Basic-fel, t ex genom att försöka beräkna 1/0. Jag inte säker på hur QB klarar denna metod heller. Det normala sättet är i stället att meddela anropande funktion (FNA) om ett fel som uppstått i FNB genom att avsluta FNB med RETURN, och indi- kera feltillståndet antingen med retur-värdet, eller i en global variabel, som kontrolleras av FNA, typ: 1) Resultat=FNA : IF Felkod THEN <Felhantering> 2) Resultat=FNA : IF Resultat<0 THEN <Felhantering> 3) IF FNA THEN <Felhantering> I 1) är returvärdet från FNA dess resultat, och variabeln Felkod sätts till något värde skilt från 0 om något fel uppstod (varvid antagligen Resultat inte innehåller något vettigt). Helst använder man förstås samma variabel för felkoden till alla funktioner. I 2) används returvärdet både som resultat från FNA och som felin- dikator. Detta går förstås bara om vissa värden omöjligt kan vara giltiga resultatet från FNA, så att det finns något att indikera fel med. I 3) har vi en funktion FNA som enbart returnerar en rätt-eller- fel-indikation, och inget resultat. Den kanske bara skriver ut något på en fil t ex. Eventuellt kan det vara resultatet som läggs i en global variabel. Sen finns det förstås mellanting. Sättet att indikera fel hänger också nära samman med hur man returnerar funktionens resultat. Hela tiden finns möjligheten för den funktion som anropade FNA att också göra RETURN och i sin tur överlämna felet till den funktion som anropade den här. Varje funktion hanterar de fel som den kan göra något åt, och överlämnar de knepigare fallen (oftast de vars behandling kräver större överblick över situationen) till överordnade funktioner. På någon nivå brukar det finnas funktioner som beslutar om att vissa fel måste åtgärdas av användaren och skriver ut felmeddelanden och kanske frågar vad som ska göras. Det kan även förekomma panik-fel på lägre nivåer som omedelbart skriver ut fel och stoppar. Men lågnivåfunktioner bör så långt möjligt låta bli utskrifter och liknande om de ska gå att återvända i andra program där kanske felhanteringen mot användaren bedrivs på något annat sätt, eller där ett fel som i ett program är "dödligt", kan hanteras mjukare av ett annat eller kräver vissa åtgärder av högre funktioner innan programmet kan tillåtas dö, typ borttagning av bara delvis färdiga filer. Felmeddelanden bör givetvis hanteras av en särskild funktion, så att utseende och eventuellt kvittering blir enhetlig. Angående minnesbehovet, så ska det inte vara några problem så länge man inte använder väldigt rekursiva funktioner, eller har mycket ont om ledigt minne. Någon GOTO Hopp finns som bekant inte i BasicII. Man använder i stället ON Hopp GOTO nnn,mmm,kkk... Fast ännu hellre undviker man förstås helt att använda GOTO. Du ha väl läst programmeringstipps i MSG och ABC-bladet om smart användning av WHILE-WEND och dylikt? Om man har en situation där programmet ska välja mellan ett antal olika och inte helt korta alternativ, kan man hellre än att smacka in alla alternativen i en funktion, dela upp det på olika funktioner typ: DEF FNMiddag(Maträtt,Foo,Bar) IF Maträtt=1 THEN RETURN FNPannkakamedketchup IF Maträtt=2 THEN RETURN FNPrinskorvssockerkaka IF Maträtt=3 THEN RETURN FNPizzamedglass FNEND
    • Kristoffer Eriksson <5357> · Text 7777 · w8 · kommentar

      1987-11-22 03:05

      Ärende: DEF FN ...

      (forts.) Dvs, gör en mångradig IF-sats (som ju inte ens kan skrivas ordentligt i BasicII) till en funktion som väljer mellan andra funktioner.
      • Johan Olofsson <5809> · Text 7792 · w8 · kommentar

        1987-11-22 22:40

        Ärende: Flerradiga IF-satser

        Frågan är om det ofta inte är mindre tidsödande att göra "flerradiga IF-satser" som WHILE-satser? Intuitivt antar jag att funktionsanrop tar längre tid att exekvera? Däremot är det oftast tydligare att använda funktionsanrop i stället för kluriga konstruktioner av typen: WHILE x ... IF 0 WEND ELSE WHILE 0 ... IF 0 WEND Det krävs lite "tungvricknings-tänkande" för att genomskåda sånt här. Exempel: (Pascal:) IF x THEN BEGIN ... END ELSE ... ; (Basic II:) WHILE B<=C Aflag = A = OldB = B B = IF 0 WEND : B = C ! Genomförs om B > C (Pascal:) IF x THEN BEGIN ... END ELSE BEGIN ... END ; (BasicII:) WHILE Aflag ! Utförs om Aflag är satt IF 0 WEND ELSE WHILE 0 ! Genomlöps endast om Aflag _ej_ var satt från början ... IF 0 WEND
        • Kristoffer Eriksson <5357> · Text 7825 · w8 · kommentar

          1987-11-29 02:41

          Ärende: Flerradiga IF-satser

          Jag tänkte mig användningen av val-funktioner mest i sammanhang med mer än två alternativ plus att alternativen är lite längre än enstaka rader. Då blir ju WHILE-WEND-metoden ännu mera tungvrickande, och knappast snabbare heller. Funktionsmetoden kan vara snyggare till och med när man har ett språk som faktiskt tillåter flerradiga och flerfaldiga IF-satser. Det blir nämligen mindre grötigt "huvudflöde" på den plats IF-satsen skulle varit. I ett språk som FORTH uppmuntras denna metod särskilt. Ett funktionsanrop tar f ö ca 0.85 millisekunder med funktionen FNA%=1% och 0.96 ms med FNA%(X%)=1 enligt vad jag får fram. Den funktion man skulle använda till en valsituation skulle förstås vara mer komplicerad, men det är ju själva den extra anropstiden som är det intressanta här.