---

Kan man ikke benytte static i en class ?
Eller hvordan gør man så hvis man har behov for at "huske" variabler fra
funktions kald til funktions kald ?

Jeg forsøger (som ny i c++, men ikke i c) at lave en rutine der læser fra
tastaturet tegn for tegn og gemme positionen af denne værdi i en static.

Nu er jeg begyndt at læse lidt c++ og kan se nogle store fordele ved at
benytte objekt-programmering istedet til dette formål, da jeg kan samle en
del gamle c-rutiner i en class. Men må jo nok erkende at dette er en ny måde
at programmere på og en helt anden måde at tænke på.

Jeg tænkte, at for at prøve at lære og forstå c++, ville jeg lave en class
over nogle rutiner jeg benytter i et alm. c-program og så ændre disse
rutiner til een class der gør det samme som de mange tidligere rutiner
gjorde. Mest for indlæringens skyld.

I min gamle kode brugte jeg en static variabel i min funktion, da denne
værdi skal huskes fra kald til kald i dette eks. fordi den benyttes til at
gemme tegnbuffer positionen.

Har en streng (char array) der indeholder de tastede tegn og en static (int)
der holder styr på hvor i strengen man er nået til.
Skal måske lige siges at programmet laver meget andet uden at vente på
tastatur.
Det vil ikke være en option at gå i et venteloop og vente på at strengen
bliver tastet færdig.

Når tast trykkes skal der kaldes en tastaturrutine der aflæser tasten og
udfra værdien gøre forskellige ting såsom at gemme i næste tegnbuffer,
slette, flytte etc.
Først når return tastes, overgives strengen til anden rutine der så
behandler denne streng.
Og så snart der ikke længere tastes noget, skal programmet vende tilbage i
main og undersøge alle de andre funktioner og udføre disse, hvis og så
fremt.....

Man kunne selvfølgelig lave globale variabler til formålet, men det er jo
noget sjusk, men dog måden jeg har løst det på i C versionen (char array
bufferen), sammen med min static int bufpos.

Skal siges det er til DOS og min compiler er Borland C++ 3.1.
Target maskinen er en 40mhz 80486 med DOS 6.

Allan

---

Den Sun, 20 Jul 2008 17:39:51 +0200 skrev Allan S. Olsen:
> Kan man ikke benytte static i en class ?
> Eller hvordan gør man så hvis man har behov for at "huske" variabler fra
> funktions kald til funktions kald ?
>
> I min gamle kode brugte jeg en static variabel i min funktion, da denne
> værdi skal huskes fra kald til kald i dette eks. fordi den benyttes til at
> gemme tegnbuffer positionen.

Du skal nok starte med at overveje hvem den skal huskes for... Hvis
du har ti instanser af din class, skal variablen så gælde på tværs
af alle instanser, eller skal den kun gælde for den ene instans?

I det sidste tilfælde (det mest normale), vil en variabel i class'en
nok være den mest oplagte løsning. Ned under protected: eller private:
- så er der ikke nogen udefra der kan pille ved den.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

> Du skal nok starte med at overveje hvem den skal huskes for... Hvis
> du har ti instanser af din class, skal variablen så gælde på tværs
> af alle instanser, eller skal den kun gælde for den ene instans?

Nej korrekt, det skal kun gælde for een instans.

> I det sidste tilfælde (det mest normale), vil en variabel i class'en
> nok være den mest oplagte løsning. Ned under protected: eller private:
> - så er der ikke nogen udefra der kan pille ved den.

Det vil jeg lege lidt med.
Tak for svar.

Allan

---

Den Mon, 21 Jul 2008 01:47:57 +0200 skrev Allan S. Olsen:
>> Du skal nok starte med at overveje hvem den skal huskes for... Hvis
>> du har ti instanser af din class, skal variablen så gælde på tværs
>> af alle instanser, eller skal den kun gælde for den ene instans?
>
> Nej korrekt, det skal kun gælde for een instans.

Så skal du ikke bruge static.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Allan S. Olsen wrote:
> Kan man ikke benytte static i en class ?
> Eller hvordan gør man så hvis man har behov for at "huske" variabler fra
> funktions kald til funktions kald ?
>
> Jeg forsøger (som ny i c++, men ikke i c) at lave en rutine der læser fra
> tastaturet tegn for tegn og gemme positionen af denne værdi i en static.
>
> Nu er jeg begyndt at læse lidt c++ og kan se nogle store fordele ved at
> benytte objekt-programmering istedet til dette formål, da jeg kan samle en
> del gamle c-rutiner i en class. Men må jo nok erkende at dette er en ny måde
> at programmere på og en helt anden måde at tænke på.
>
> Jeg tænkte, at for at prøve at lære og forstå c++, ville jeg lave en class
> over nogle rutiner jeg benytter i et alm. c-program og så ændre disse
> rutiner til een class der gør det samme som de mange tidligere rutiner
> gjorde. Mest for indlæringens skyld.

Se simpelt eksempel nedenfor.

> Skal siges det er til DOS og min compiler er Borland C++ 3.1.
> Target maskinen er en 40mhz 80486 med DOS 6.

Jeg tror ikke at det gør en forskel. De her dele af C++ har vist ikke
ændret sig.

Arne

====================================================

#include <iostream>

using namespace std;

class C
{
private:
static int clsfld;
int insfld;
public:
static void SetClsFld(int v);
static int GetClsFld();
void SetInsFld(int v);
int GetInsFld();
};

int C::clsfld;

void C::SetClsFld(int v)
{
clsfld = v;
}

int C::GetClsFld()
{
return clsfld;
}

void C::SetInsFld(int v)
{
insfld = v;
}

int C::GetInsFld()
{
return insfld;
}


int main()
{
C::SetClsFld(77);
cout << C::GetClsFld() << endl;
C o;
o.SetInsFld(88);
cout << o.GetInsFld() << endl;
C *p = new C();
p->SetInsFld(99);
cout << p->GetInsFld() << endl;
delete p;
return 0;
}

---

Takker for svar.

To ting måtte jeg dog ændre for at kunne køre det i BC 3.1

Jeg skulle tilføje et <dot> h efter iostream.

> #include <iostream>

Og jeg måtte udelade nedenstående linie. Ser ikke ud til at BC kender til
"using".

> using namespace std;

Nu er jeg ret ny i at læse og ikke mindst forstå class'er så bær over med
min uvidenhed.

Jeg kan se at der bliver erklæret en static int clsfld og to funktioner,
static void SetClsFld og static int GetClsFld.
Men jeg er ikke klar over hvorfor funktionerne erklæreres static ?

> class C
> {
> private:
> static int clsfld;
> int insfld;
> public:
> static void SetClsFld(int v);
> static int GetClsFld();
> void SetInsFld(int v);
> int GetInsFld();
> };
>
> int C::clsfld;


Ydermere så linien int C::clsfld, den har jeg tolket som en "global"
variabel tilhørende class'en C, og den reelle variabel der bruges til at
aggere for den static som erklæres i private som static int clsfld. Eller
hva' ?

Jeg troede ellers ikke at man kunne benytte class'en C uden at lave en
arbejdskopi i hukommelsen som du gør ved main med C o og C *p new C();
Faktisk havde jeg tolket det som om man SKAL lave en arbejds kopi som eks. C
o og kalde class' rutiner vha o.SetClsFld etc.
Men du kalder flere steder med formen C::<funk> og det uden at compileren
brokker sig.

Pyh, jeg forstå ret meget mere C end C++.

Håber du kan give en (kort men fyldig) forklaring på dette, da jeg er på bar
bund her.
Der er sgu noget om det der fortælles med, at har man først lært C så er det
svært at lære C++.
Jeg er enig og på nippet til at droppe C++. Men sproget har så mange lækre
features som det vil være fedt at forstå og bruge, så der er vel ikke andet
for at bare klø på.

Allan

---

Allan S. Olsen wrote:
> To ting måtte jeg dog ændre for at kunne køre det i BC 3.1
>
> Jeg skulle tilføje et <dot> h efter iostream.
>
>> #include <iostream>
>
> Og jeg måtte udelade nedenstående linie. Ser ikke ud til at BC kender til
> "using".
>
>> using namespace std;

Ja - de 2 ting kom til med ANSI C++ i 1998 og BC++ 3.1 er vel først
i 90'erne.

> Jeg kan se at der bliver erklæret en static int clsfld og to funktioner,
> static void SetClsFld og static int GetClsFld.
> Men jeg er ikke klar over hvorfor funktionerne erklæreres static ?
>
>> class C
>> {
>> private:
>> static int clsfld;
>> int insfld;
>> public:
>> static void SetClsFld(int v);
>> static int GetClsFld();
>> void SetInsFld(int v);
>> int GetInsFld();
>> };
>>
>> int C::clsfld;

Jeg ville illustrere 2 forskellige løsninger (tilsvarende
betragtninger i anden anden post):
* clsfld eksisterer kun i en enkelt udgave
* der en insfld for hver instans af klassen

> Ydermere så linien int C::clsfld, den har jeg tolket som en "global"
> variabel tilhørende class'en C, og den reelle variabel der bruges til at
> aggere for den static som erklæres i private som static int clsfld. Eller
> hva' ?

int C::clsfld; er implementatione af static int clsfld;.

Og hvis den var public ville det være en global variabel, men det
er den ikke.

> Jeg troede ellers ikke at man kunne benytte class'en C uden at lave en
> arbejdskopi i hukommelsen som du gør ved main med C o og C *p new C();
> Faktisk havde jeg tolket det som om man SKAL lave en arbejds kopi som eks. C
> o og kalde class' rutiner vha o.SetClsFld etc.
> Men du kalder flere steder med formen C::<funk> og det uden at compileren
> brokker sig.

Det kan man når metoden er static !

Arne

---

Allan S. Olsen skrev:

> To ting måtte jeg dog ændre for at kunne køre det i BC 3.1
> Jeg skulle tilføje et <dot> h efter iostream.
> #include <iostream>

> Og jeg måtte udelade nedenstående linie. Ser ikke ud til at BC kender til
> "using".

Du kan hente Borlands C++ version 5.5 gratis, og den lider ikke
af de to nævnte fejl. Hvis jeg husker ret, fandt jeg den på
Borlands hjemmeside, og man skal vist registrere sig, men det er
gratis.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Allan S. Olsen skrev:
>> To ting måtte jeg dog ændre for at kunne køre det i BC 3.1
>> Jeg skulle tilføje et <dot> h efter iostream.
>> #include <iostream>
>
>> Og jeg måtte udelade nedenstående linie. Ser ikke ud til at BC kender til
>> "using".
>
> Du kan hente Borlands C++ version 5.5 gratis, og den lider ikke
> af de to nævnte fejl. Hvis jeg husker ret, fandt jeg den på
> Borlands hjemmeside, og man skal vist registrere sig, men det er
> gratis.

Den kan stadig hentes:

http://cc.codegear.com/free/cppbuilder

Arne

---

Arne Vajhøj wrote:
> Bertel Lund Hansen wrote:
>> Allan S. Olsen skrev:
>>> To ting måtte jeg dog ændre for at kunne køre det i BC 3.1
>>> Jeg skulle tilføje et <dot> h efter iostream.
>>> #include <iostream>
>>
>>> Og jeg måtte udelade nedenstående linie. Ser ikke ud til at BC kender
>>> til "using".
>>
>> Du kan hente Borlands C++ version 5.5 gratis, og den lider ikke
>> af de to nævnte fejl. Hvis jeg husker ret, fandt jeg den på
>> Borlands hjemmeside, og man skal vist registrere sig, men det er
>> gratis.
>
> Den kan stadig hentes:
>
> http://cc.codegear.com/free/cppbuilder

Men jeg vil anbefale en GCC MinGW i stedet for.

https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780

Arne

---

>> Den kan stadig hentes:
>>
>> http://cc.codegear.com/free/cppbuilder
>
> Men jeg vil anbefale en GCC MinGW i stedet for.
>
> https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780

Har lige hentet dem begge.

Men kun fået BC'en til at virke.
Desværre kan den slet ikke compile noget af min gamle kildetekst uden fejl.

Så'h jeg tror lige pt jeg fortsætter med BC3.1 til mine "gamle" programmer.
Igen så skal det færdige program jo køre på en ren DOS maskine med DOS 6.
Så den gamle compiler er som ikke så dårlig endda til dette formål.

Jeg vil så nok forsøge at benytte BC55 til nyere ting, hvis jeg en dag får
mod på at lave GUI programmer a'la windows applikationer o.l.

Tak for info.

Allan

---

Allan S. Olsen wrote:
>>> Den kan stadig hentes:
>>>
>>> http://cc.codegear.com/free/cppbuilder
>> Men jeg vil anbefale en GCC MinGW i stedet for.
>>
>> https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780
>
> Har lige hentet dem begge.
>
> Men kun fået BC'en til at virke.
> Desværre kan den slet ikke compile noget af min gamle kildetekst uden fejl.
>
> Så'h jeg tror lige pt jeg fortsætter med BC3.1 til mine "gamle" programmer.
> Igen så skal det færdige program jo køre på en ren DOS maskine med DOS 6.
> Så den gamle compiler er som ikke så dårlig endda til dette formål.
>
> Jeg vil så nok forsøge at benytte BC55 til nyere ting, hvis jeg en dag får
> mod på at lave GUI programmer a'la windows applikationer o.l.

Jeg tror ikke at hverken BCC 5.x eller GCC MinGW kan generere
16 bit executables.

Dertil er din gamle BC nok så god som den kan blive.

Eneste alternativ jeg kan tænke på er at snyde med en
GCC DJGPP som kører under DOS men som reelt switcher
til protected mode.

Arne

---

> Jeg tror ikke at hverken BCC 5.x eller GCC MinGW kan generere
> 16 bit executables.
>
> Dertil er din gamle BC nok så god som den kan blive.
>
> Eneste alternativ jeg kan tænke på er at snyde med en
> GCC DJGPP som kører under DOS men som reelt switcher
> til protected mode.
>

Nå nu har jeg haft lidt mere tid til at lege med BCC55.
Sådan set ikke noget dårligt software. Virker stort set nøjagtigt som den
gamle "bcc" cmdline i BC31.

Jeg havde selvfølgelig ikke fået sat CFG filerne op til mit environment og
så snart det var gjort OG jeg havde fået lavet en PATH til BCC55 så kunne
jeg sagtens kompile mine gamle kildeteskter.
Men når det er sagt, så kan den nye BCC55 ikke bruges til 16-bit, for der er
ikke længere support for tilgang til de 2 cpu instruktioner INP og OUTP.
(Var at finde i CONIO.H og DOS.H)
Hvilket er 2 kommandoer jeg bruger konstant i mit 16-bit projekt, da jeg
kommunikere med nogle IO-kort som er tilsluttet PC'en.
Hvilket var een af årsagerne til at min "Keyboard-rutine" ikke måtte hænge
og vente på input.
Det er alfa og omega at programmet kontinuerligt aftaster hændelser fra
disse IO-kort for dernæst at udføre hvad der skal gøres, upåagtet af man er
igang med at indtaste noget til programmet.

Min keyboard rutine er nemlig bare en alternativ måde at få programmet til
at gøre ting som normalt "hænder" via IO-kortene.

Forresten mht static: Da jeg bladrede frem i min lærebog, så var der
selvfølgelig eksempler på brug af static og efter at have læst afsnittet, så
kunne jeg langt bedre forstå det du viste i dit eksempel. Men du skal have
tak for hjælpen alligevel. Tror dog det tager noget tid at vænne mig til
Class'er.
Har jo altid brugt struct som eneste mulighed for at "samle" noget. Og har
virkelig brugt det meget i mit projekt til IO-kort.
Min næste opgave bliver at forsøge at skille disse struct ad og lave
class'er istedet.

Prøv at se nedenstående. Jeg har rigtigt mange struct's der er pointere til
andre struct's som så igen er pointere til andre igen osv.
Kan man i det hele taget dette med Class'er ? Men ok, hvis man laver sin
kode ordentligt er der vel heller ikke behov for det.
Årsagen til jeg har gjort det sådan er at nogle data er constants, andre
bliver ændret hele tiden. Nogle er "fælles" (både constant'er og variable)
etc.
Men ved at overgive een hovedpointer til mine funktioner, har jeg tilgang
til alle, lad os kalde det "objekters" data, da jeg har mange objekter, som
har lidt af det hele.
Hele moliviten bliver så til sidst samlet i en overordnet struct's, som jeg
så kan overgive til mine behandlene funktioner. Disse kan så udfra
"hovedpointeren" pege sig frem til de ønskede data. Sikkert en besværlig
måde men jeg kendte jo ikke til C++ da jeg startede op på projektet.


Allan

--begin--

struct blinkcontrol
{
struct io_OutpRG const *Lmp;
UBYTE Gl;
};

struct spskvar
{
UBYTE IndkV;
UBYTE IndkH;
UBYTE Retn;
TIME_T Start;
UBYTE Koer;
UBYTE Fejl;
UBYTE Magz;
#ifdef __BS_H
struct bsbl * BsBl;
#endif
};

struct spsk
{
struct io_InpHV const *Indk;
struct io_Outp const *Motor;
struct io_Inp const *Knap;
struct io_InpHV const *Knap2;
struct spskvar *Var;
struct io_OutpHV const *Lmp;
};

struct spskconst
{
UBYTE Ant;
UBYTE MaxKoer;
UBYTE ScrWrite;
struct io_Inp const *Fknap;
struct io_Outp const *OmstLmp;
UBYTE Type;
};

struct spskdef
{
UBYTE FlagOmst;
UBYTE FlagMagz;
UBYTE Fejl;
UBYTE Oplaas;
UBYTE OvStrp;
UBYTE CkOvStrp;
TIME_T OvStrpStart;
TIME_T CkOvStrpStart;
UBYTE BlinkSpskGl;
UBYTE BlinkSpskFejlGl;
struct spskconst const * Const;
struct spsk * Spsk;
struct Magazin * MainMagz;
struct Magazin * FirstMagz;
struct Magazin * PrevMagz;
struct Magazin * RemoveMagz;
struct blink * Blink;
struct blinkcontrol * BlinkCtrl;
};

--end--

---

Allan S. Olsen wrote:
> Men når det er sagt, så kan den nye BCC55 ikke bruges til 16-bit, for der er
> ikke længere support for tilgang til de 2 cpu instruktioner INP og OUTP.
> (Var at finde i CONIO.H og DOS.H)
> Hvilket er 2 kommandoer jeg bruger konstant i mit 16-bit projekt, da jeg
> kommunikere med nogle IO-kort som er tilsluttet PC'en.
> Hvilket var een af årsagerne til at min "Keyboard-rutine" ikke måtte hænge
> og vente på input.
> Det er alfa og omega at programmet kontinuerligt aftaster hændelser fra
> disse IO-kort for dernæst at udføre hvad der skal gøres, upåagtet af man er
> igang med at indtaste noget til programmet.

Det ville man jo nok lave multithreaded i nyere styre systemer end DOS.

> Har jo altid brugt struct som eneste mulighed for at "samle" noget. Og har
> virkelig brugt det meget i mit projekt til IO-kort.
> Min næste opgave bliver at forsøge at skille disse struct ad og lave
> class'er istedet.

Faktisk er forskellen på struct og class lille i C++. En struct i C kan
mere end en struct i C. Du kan have metoder etc. i structs. Eneste
forskel er at default access is public for struct og private for class.

Men jeg må indrømme at jeg normalt altid bruger struct som man gør i C
og class til andet.

> Prøv at se nedenstående. Jeg har rigtigt mange struct's der er pointere til
> andre struct's som så igen er pointere til andre igen osv.
> Kan man i det hele taget dette med Class'er ?

Selvfølgelig.

Men det skal nok omstruktureres en del hvis det skal blive pæn C++.

Der skal nok laves en del indkapsling.

Arne