---

Hej ...

Jeg er i "konverterings" fasen mellem pascal og C til mikroprocessorere ...
jeg kan ikke rigtigt finde ud af at lave en sub routine ... hvor jeg i
pascal ville skrive

procedure calculate is
a = a + b // foreksempel ... bare noget fyld ...
end procedure

hvad gør man så i c ?

eller hvis jeg vil have noget ind og noget ud ....

procedure calculate ( byte in a, byte out b ) is
b = a *4
end procedure

Hvordan kunne dette evt. se ud ?

Compileren er Codevision AVR det er en Ansi C compiler hvis det betyder
noget ....

m.v.h.
l. madsen

---

On Fri, 19 Jul 2002 00:42:43 +0200, "Lasse Madsen"
<Lasse.madsen@elektronik.dk> wrote:

>procedure calculate is
>a = a + b // foreksempel ... bare noget fyld ...
>end procedure

void
calculate (void)
{
a+=b;
return;
}

>procedure calculate ( byte in a, byte out b ) is
>b = a *4
>end procedure

int
calculate (int a)
{
return a * 4;
}

Hold kæft hvor er C sjovere end Pascal.

Chris

---

"Chris" <dsl3353@vip.cybercity.dk> wrote in message
news:mmheju40eqag5qcraotoivlfp3bapls9nk@4ax.com...
> >procedure calculate is
> >a = a + b // foreksempel ... bare noget fyld ...
> >end procedure
>
> void
> calculate (void)
> {
> a+=b;
> return;
> }

Jeg er ikke helt med på hvorfor du sætte en return der? Kan man ikke bare
lade den løbe ud?

mvh
db

---

On Fri, 19 Jul 2002 01:08:20 +0200, "Daniel Blankensteiner"
<db@traceroute.dk> wrote:

>> void
>> calculate (void)
>> {
>> a+=b;
>> return;
>> }
>
>Jeg er ikke helt med på hvorfor du sætte en return der? Kan man ikke bare
>lade den løbe ud?

Jo, men det er god skik nu om dage at afslutte funktioner med
"return". Også selvom der ikke er noget at returnere.

Skal man lave en "pæn" C kodning, så slut hver funktion af med
"return". Måske er det snobberi, men sådan er jeg. Det er, efter min
mening, sjusk ikke at afslutte med "return". Men det er vel en
smagssag.

Chris

---

Chris skrev:

>Jo, men det er god skik nu om dage at afslutte funktioner med
>"return".

Den gode skik er gået sporløst hen over alle lærerne på min
datamatikeruddannelse - heldigvis.

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

---

Chris <dsl3353@vip.cybercity.dk> skrev:
>Skal man lave en "pæn" C kodning, så slut hver funktion af med
>"return".

Sludder og vrøvl.

>Det er, efter min
>mening, sjusk ikke at afslutte med "return". Men det er vel en
>smagssag.

Nej. En tom return i slutningen af en funktion er dårlig kodestil. Det
er unødvendigt støj og forvirrende. Andre udviklere vil, som fx Daniel
gjorde, undre sig over hvorfor du har ment den return var nødvendig og
dermed have mere besvær ved at læse og forstå koden.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

On Sat, 20 Jul 2002 03:50:59 +0200, Richard Flamsholt wrote:

> Chris <dsl3353@vip.cybercity.dk> skrev:
>>Skal man lave en "pæn" C kodning, så slut hver funktion af med "return".
>
> Sludder og vrøvl.
>
>>Det er, efter min
>>mening, sjusk ikke at afslutte med "return". Men det er vel en smagssag.
>
> Nej. En tom return i slutningen af en funktion er dårlig kodestil. Det
> er unødvendigt støj og forvirrende. Andre udviklere vil, som fx Daniel
> gjorde, undre sig over hvorfor du har ment den return var nødvendig og
> dermed have mere besvær ved at læse og forstå koden.

Set logisk på det, er en "tom" return det rigtige.
Den skal jo returnere "void". ik'

Som chris siger det er en smagssag. Vi kan også begynde at diskutere om
c-syntax er mere rigtig end vb-syntax. Jeg brækker mig over vb, men andre
skal da have lov til at synes om det. (losers :0)

---

Xlo0772 wrote:
> Set logisk på det, er en "tom" return det rigtige.
> Den skal jo returnere "void". ik'

Der er vist mere void over dette:


End dette:

return;



- Morten.

---

> Der er vist mere void over dette:
>
>
> End dette:
>
> return;

hehe, point taken.

Det kan jeg ikke rigtigt argumentere imod.
Så jeg må prøve at være lidt morsom.

Når man afslutter sit program, skal man huske at frigive det man ikke har
brugt. Dette gøres ved at kalde nedenstående funktion.

void Void(void) {
free((void*)Void);
}


PS: Iøvrigt. Hvorfor skal man afslutte sit program "pænt", når der alligevel
bliver ryddet op efter en. (en sandhed med modifikationer selvfølgelig)

---

Den Sat, 20 Jul 2002 20:15:09 +0200 skrev Xlo0772:
>PS: Iøvrigt. Hvorfor skal man afslutte sit program "pænt", når der alligevel
>bliver ryddet op efter en. (en sandhed med modifikationer selvfølgelig)

Fordi der nok skal være en eller anden der forsøger at compilere
programmet på et OS der ikke rydder op efter en (fx. DOS), eller blot
for at få en god vane. Det er jo ikke alle programmer der afsluttes,
og hvis ikke man frigiver tingene korrekt, så har man memory-leaks
og diverse andre -leaks.

Mvh
Kent
--
8:16pm up 2:37, 1 user, load average: 101.21, 95.46, 55.85
164 processes: 62 sleeping, 102 running, 0 zombie, 0 stopped

With XMMS tugging along nicely, playing Vivaldi...

---

On Sat, 20 Jul 2002 20:12:34 +0200, Kent Friis wrote:

> Den Sat, 20 Jul 2002 20:15:09 +0200 skrev Xlo0772:
>>PS: Iøvrigt. Hvorfor skal man afslutte sit program "pænt", når der
>>alligevel bliver ryddet op efter en. (en sandhed med modifikationer
>>selvfølgelig)
>
> Fordi der nok skal være en eller anden der forsøger at compilere
> programmet på et OS der ikke rydder op efter en (fx. DOS), eller blot
> for at få en god vane. Det er jo ikke alle programmer der afsluttes, og
> hvis ikke man frigiver tingene korrekt, så har man memory-leaks og
> diverse andre -leaks.
>
> Mvh
> Kent

og hardware issues. Den med for god vane køber jeg, men ind imellem har
man lyst til at være lidt doven.

Jeg var fristet til at skrive,
"hvis man altså har et ordentligt OS af en mor" (underforstået Linux)
det blev til
"en sandhed med modifikationer"

Bare rolig jeg mente det ikke seriøst, og jeg skriver ikke programmer til
forsvaret.

---

> Når man afslutter sit program, skal man huske at frigive det man ikke har
> brugt. Dette gøres ved at kalde nedenstående funktion.
>
> void Void(void) {
> free((void*)Void);
> }
>
>
> PS: Iøvrigt. Hvorfor skal man afslutte sit program "pænt", når der
alligevel
> bliver ryddet op efter en. (en sandhed med modifikationer selvfølgelig)

Det skal man heller ikke nødvendigvis. malloc()'ed hukommelse vil altid
blive frigivet ved programafslutning iflg. ANSI-C -- uanset om OS'et har
resource tracking eller ej. Jeg har været ude for i en given situation at
spare over 30 sekunder i et mailprogram på at droppe nogle free()-løkker,
der ved programafslutning frigav tusindvis af allokeringer brugt til
header-information.

Når det er sagt, må jeg hellere lige pointere at det er et
specialtilfælde -- jeg vil under ingen omstændigheder nogensinde undlade at
frigive noget der *skal* frigives, fordi det OS jeg programmerer til
tilfældigvis har resource tracking.

--
Jacob Laursen (jlu@no-spam-kmd.dk)

---

"Jacob Laursen" <jlu@kmd.dk> wrote:

>Når det er sagt, må jeg hellere lige pointere at det er et
>specialtilfælde -- jeg vil under ingen omstændigheder nogensinde undlade at
>frigive noget der *skal* frigives, fordi det OS jeg programmerer til
>tilfældigvis har resource tracking.

Der findes da forhåbentlig ikke noget der bare minder om et generelt
anvendeligt OS som ikke frigiver ting som hovedlager og fil-relaterede
resurser når en process afsluttes. Det er et af de allervæsentligste
formål med et OS.

Selv DOS kunne det. Og det er jo en nødvendighed i ethvert OS der
understøtter at maskinen overhovedet kører fornuftigt videre hvis et
program dør i utide, fx pga. en adresseringsfejl.

Så i ethvert normalt OS (der findes undtagelser, men det er OS'er der ikke
er beregnet til at køre generelle programmer på) er de eneste fornuftige
grunde jeg umiddelbart kan komme på, til omhyggeligt at frigive resurser
lige inden et program slutter:
(a) at det kraftigt forøger den hjælp man kan få af værktøjer til at finde
"memory leaks" og lignende,
(b) at det kan gøre det nemmere at læse og forstå programmet, og
(c) at det kan lette livet for en programmør der måske senere får til
opgave at konvertere det program til et funktionsbibliotek som kan kaldes
af andre programmer på en sådan måde at der ikke automatisk bliver ryddet
op.

Men det kan også sagtens være rigtig fornuftig grunde.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Xlo0772 skrev:

>Set logisk på det, er en "tom" return det rigtige.

Nej. Return bruges når man skal forlade prosecuren i 'utide'. Det
virker forvirrende at sende det signal når den er slut.

Da jeg var barn morede vi os meget over en vittighed med en
tosseanstalt hvor alle tosserne efter tur kravlede op i
flagstangen for derefter når de kom ned, at nikke og udbryde "Ja,
det er rigtigt nok".
Forstanderen blev jo nysgerrig, men han ville ikke sættes i bås
med tosserne, så han ventede til om natten, sneg sig ud og
kravelede op i flagstangen med en lommelygte. Øverst oppe hang en
lille seddel hvorpå der stod: "Her ender flagstangen".

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

---

On Sat, 20 Jul 2002 19:54:56 +0200, Bertel Lund Hansen wrote:

> Xlo0772 skrev:
>
>>Set logisk på det, er en "tom" return det rigtige.
>
> Nej. Return bruges når man skal forlade prosecuren i 'utide'. Det virker
> forvirrende at sende det signal når den er slut.
>
hmm, mig bekendt bruger man ikke termen procedure i C, men ok, jeg er
også gammel pascal'er, så jeg forstår godt hvad du mener.

Definition - c-function :
return-type function-name(parameter-declarations)
{
declarations
statements
}

Hvis man har den regel, at man altid returnerer "return-type", så er det
da på ingen måde forkert, at skrive "return;" i slutningen på en
funktion, som returnerer void.

Det er en del af Chris' kodningsstil.

Personligt mener jeg det er uskik, at i det hele taget have funktioner
der returnerer void.

Det er en del af min kodningsstil.

Du har en anden kodningsstil. Det skal du have lov til. Go in peace.

---

Xlo0772 skrev:

>hmm, mig bekendt bruger man ikke termen procedure i C, men ok, jeg er
>også gammel pascal'er, så jeg forstår godt hvad du mener.

Korrekt, men jeg brugte det for at understrege at der ikke er
behov for return.

>Hvis man har den regel, at man altid returnerer "return-type", så er det
>da på ingen måde forkert, at skrive "return;" i slutningen på en
>funktion, som returnerer void.

Næ nej. Det er heller ikke forkert at bruge {{ }} i stedet for
{}.

> Det er en del af Chris' kodningsstil.

Du udviser en accept af en anden stil - modsat Chris:

   men det er god skik nu om dage at afslutte funktioner med
   "return".

Hans postulat er grebet ud af den blå luft. Hvor mange tror du
bruger dette ekstra "return"? Det er første gang jeg hører om
det.

>Personligt mener jeg det er uskik, at i det hele taget have funktioner
>der returnerer void.

Det forstår jeg ikke at du mener.

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

---

Den Sat, 20 Jul 2002 22:01:08 +0200 skrev Bertel Lund Hansen:
>Xlo0772 skrev:
>
>>Personligt mener jeg det er uskik, at i det hele taget have funktioner
>>der returnerer void.
>
>Det forstår jeg ikke at du mener.

Argumentet er, at en funktion altid kan gå godt eller skidt, så om
ikke andet er man nødt til at returnere en status-kode. Fx. i stdio:

int fclose(FILE * stream);

Egentlig kunne den lige så godt returnere void, og den vil da også i
langt de fleste tilfælde blive brugt somom den returnerede void, men
teoretisk kan fclose() faktisk godt fejle, og dette vises ved at
returnere EOF i stedet for 0 (og så naturligvis sætte errno).

Mvh
Kent
--
The frozen north will hatch a flightless bird,
who will spread his wings and dominate the earth
And cause an empire by the sea to fall
To the astonishment, and delight of all.

---

Kent Friis <leeloo@phreaker.net> skrev:
> Argumentet er, at en funktion altid kan gå godt eller skidt, så om
> ikke andet er man nødt til at returnere en status-kode. Fx. i stdio:
>
> int fclose(FILE * stream);
>
> Egentlig kunne den lige så godt returnere void,

Nej, absolut ikke. Hvis det er en fil man har skrevet til, er det af
afgørende betydning at tjekke returværdien fordi skrivefejl (f.eks.
pga. fuld disk) ikke behøver at vise sig før man lukker filen.

> og den vil da også i
> langt de fleste tilfælde blive brugt somom den returnerede void,

Forhåbentlig ikke!

> men
> teoretisk kan fclose() faktisk godt fejle, og dette vises ved at
> returnere EOF i stedet for 0 (og så naturligvis sætte errno).

Forkert. Den returnerer -1 ved fejl.

---

Byrial Jensen <bjensen@nospam.dk> skrev:
> Kent Friis <leeloo@phreaker.net> skrev:
>
>> teoretisk kan fclose() faktisk godt fejle, og dette vises ved at
>> returnere EOF i stedet for 0 (og så naturligvis sætte errno).
>
> Forkert. Den returnerer -1 ved fejl.

Der var jeg lidt for hurtig. fclose() returnerer ganske rigtigt EOF
ved fejl. Jeg tænkte på close() som returnerer -1 ved fejl.

---

Den Sat, 20 Jul 2002 22:11:30 GMT skrev Byrial Jensen:
>Kent Friis <leeloo@phreaker.net> skrev:
>> Argumentet er, at en funktion altid kan gå godt eller skidt, så om
>> ikke andet er man nødt til at returnere en status-kode. Fx. i stdio:
>>
>> int fclose(FILE * stream);
>>
>> Egentlig kunne den lige så godt returnere void,
>
>Nej, absolut ikke. Hvis det er en fil man har skrevet til, er det af
>afgørende betydning at tjekke returværdien fordi skrivefejl (f.eks.
>pga. fuld disk) ikke behøver at vise sig før man lukker filen.

Det var ment som et eksempel. Find selv på et bedre...

>> og den vil da også i
>> langt de fleste tilfælde blive brugt somom den returnerede void,
>
>Forhåbentlig ikke!

Det er faktisk begrænset hvor lang tid det er siden jeg første gang så
nogen anbefale at man checker retur-værdien på fclose, og det har aldrig
været nævnt i undervisningen dengang jeg gik på datamatiker. Derfor må
jeg gå ud fra at der er mange andre der heller ikke ved det, og som ikke
lige har læst det obskure website, hvor jeg så anbefalingen.

Derudover: Ok, så er det konstateret at fclose() fejlede, hvad skal
programmet så gøre ved et? Hvad kan det gøre?

Mvh
Kent
--
.~. .~.
/V\ From Palm Pilot to S/390 /V\
// \\ Truly scalable operating system // \\
/( )\ Linux /( )\
^^-^^ ^^-^^

---

leeloo@phreaker.net (Kent Friis) writes:

> Derudover: Ok, så er det konstateret at fclose() fejlede, hvad skal
> programmet så gøre ved et? Hvad kan det gøre?

Som minimum fortælle brugeren at der opstod en fejl, så han bliver
opmærksom på at hans data muligvis ikke er blevet gemt.

---

Soeren Sandmann <sandmann@daimi.au.dk> skrev:
> leeloo@phreaker.net (Kent Friis) writes:
>
>> Derudover: Ok, så er det konstateret at fclose() fejlede, hvad skal
>> programmet så gøre ved et? Hvad kan det gøre?
>
> Som minimum fortælle brugeren at der opstod en fejl, så han bliver
> opmærksom på at hans data muligvis ikke er blevet gemt.

Bestemt. Afhængigt af situationen kunne man også f.eks.:
- skrive hændelsen i en fejllog
- afslutte programudførelsen
- forsøge at sikre data på anden måde, f.eks. ved at undlade at
slette originalen hvis der er tale om kopiering.

---

On Sat, 20 Jul 2002 22:01:08 +0200, Bertel Lund Hansen wrote:

> Xlo0772 skrev:
>
>>hmm, mig bekendt bruger man ikke termen procedure i C, men ok, jeg er
>>også gammel pascal'er, så jeg forstår godt hvad du mener.
>
> Korrekt, men jeg brugte det for at understrege at der ikke er behov for
> return.

Tænkte det nok. En af de ting, der oprindeligt tiltalte mig med C, var
netop at alt var funktioner, derfor kan jeg godt blive lidt pedantisk
hvad det angår.

>>Hvis man har den regel, at man altid returnerer "return-type", så er det
>>da på ingen måde forkert, at skrive "return;" i slutningen på en
>>funktion, som returnerer void.
>
> Næ nej. Det er heller ikke forkert at bruge {{ }} i stedet for {}.

heheh, nej det kan du have ret i. men jeg vil dog mene, at så går det hen
og bliver skummelt.
Skummelt C : http://www.es.ioccc.org/whowon.html

>> Det er en del af Chris' kodningsstil.
>
> Du udviser en accept af en anden stil - modsat Chris:
>
>    men det er god skik nu om dage at afslutte funktioner med "return".
>
> Hans postulat er grebet ud af den blå luft. Hvor mange tror du bruger
> dette ekstra "return"? Det er første gang jeg hører om det.

Indrømmet, jeg har ikke selv nogensinde brugt det. og jeg ved heller ikke
hvor han får det "nu om dage" fra??
Og tak for komplimentet, jeg prøver meget ihærdigt at forstå og acceptere
andre, fordi ingen forstår eller accepterer mig.

>>Personligt mener jeg det er uskik, at i det hele taget have funktioner
>>der returnerer void.
>
> Det forstår jeg ikke at du mener.

INGEN forstår mig!! buhuu

uskik var måske heller ikke det rigtige ord, en uskik jeg taget fra
Chris, som også vil give os den uskik at skrive nonsens kode (Chris du er
en skurk), men meningen er lidt hen af det samme.

Jeg skal prøve at forklare mit synspunkt.

Konsekvent skriver jeg funktioner som returnerer en fejlkode, som angiver
om der er noget, der er gået galt.
Special tilfælde er
- indeks funktioner. som returnerer et indeks, hvor -1 angiver fejl
- matematiske funktioner, som returnerer evalueringen af en formel, der
ikke kan/bør give anledning til fejl. Hvis der er issues som division
med nul, eller andet, så må det skrives om til en funktion, der returnerer
en fejlkode, og overfører resultat gennem parameterlisten.

Min teori : Når man er konskvent med at returnere en fejlkode, bliver man
tvunget til at overveje fejlsituationer, og koden bliver forhåbentlig
mere robust.

Jeg må da indrømme, at ind imellem er kommet til at skrive en funktion,
hvor simpelthen intet kan gå galt. At returnere en fejlkode i sådant tilfælde
er rimelig tåbeligt. Det er et dilemma, jeg ikke rigtiugt kan forholde
mig til. Det ender altid med at jeg skriver koden om, så noget kan gå
galt.

Så for mig er det en "uskik". For andre som håndterer fejl på en anden
måde, har ikke mine bekymringer.

/xlo

---

Xlo0772 skrev:

>Konsekvent skriver jeg funktioner som returnerer en fejlkode, som angiver
>om der er noget, der er gået galt.

Det er jo yderst fornuftigt. Hvis du havde skrevet det, havde jeg
næppe brokket mig.

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

---

Xlo0772 <no.mail@mail.no> skrev:

> Definition - c-function :
> return-type function-name(parameter-declarations)
> {
> declarations
> statements
> }

Det svarer nu ikke helt til den definition af en C-funktion som jeg
kender fra C-standarden:

(6.9.1) function-definition:
declaration-specifiers declarator declaration-list-opt compound-statement

Af specifikke forskelle kan nævnes:

- en funktion kan erklæres "inline" og "static" (declaration-specifiers
i ovenstående) hvilket ikke kan kaldes en del af return-type.
- Argumenternes typer kan erklæres efter den første declarator
(declaration-list-opt) (Det vil sige K&R- eller pre-ANSI-stil).
- Der er intent krav om deklarationer før sætninger i funktionskroppen.

---

On Sun, 21 Jul 2002 00:01:00 +0200, Byrial Jensen wrote:

> Xlo0772 <no.mail@mail.no> skrev:
>
>> Definition - c-function :
>> return-type function-name(parameter-declarations) {
>> declarations
>> statements
>> }
>> }
> Det svarer nu ikke helt til den definition af en C-funktion som jeg
> kender fra C-standarden:
>
> (6.9.1) function-definition:
> declaration-specifiers declarator declaration-list-opt
> compound-statement
>
> Af specifikke forskelle kan nævnes:
>
> - en funktion kan erklæres "inline" og "static" (declaration-specifiers
> i ovenstående) hvilket ikke kan kaldes en del af return-type.
> - Argumenternes typer kan erklæres efter den første declarator
> (declaration-list-opt) (Det vil sige K&R- eller pre-ANSI-stil).
> - Der er intent krav om deklarationer før sætninger i funktionskroppen.

Det er nok meget godt du fik rettet op det. Lasse skulle jo nødig blive
forvirret over min noget upræcise definition.

Bare lige for at undgå misforståelser, hvilken standard henviser din
definition til. Jeg husker ikke function-specifier "inline", defineret i
Ansi-C (den fra 1988). Men standarden er jo senere blevet revideret, og
jeg må indrømme jeg har ikke lige fulgt op på det.

---

Xlo0772 <no.mail@mail.no> skrev:

> Det er nok meget godt du fik rettet op det. Lasse skulle jo nødig blive
> forvirret over min noget upræcise definition.
>
> Bare lige for at undgå misforståelser, hvilken standard henviser din
> definition til.

C99 (ISO/IEC 9899:1999). Når jeg bruger C uden nærmere angivelse er
det altid den gældende/nyeste standard som jeg tænker på.

> Jeg husker ikke function-specifier "inline", defineret i
> Ansi-C (den fra 1988). Men standarden er jo senere blevet revideret, og
> jeg må indrømme jeg har ikke lige fulgt op på det.

Ja, "inline" er ny C99. Det er også nyt i C99 at det gamle krav om
deklarationer før sætninger er ophævet.

---

On Sun, 21 Jul 2002 09:19:54 +0200, Byrial Jensen wrote:

> Xlo0772 <no.mail@mail.no> skrev:
>
>> Det er nok meget godt du fik rettet op det. Lasse skulle jo nødig blive
>> forvirret over min noget upræcise definition.
>>
>> Bare lige for at undgå misforståelser, hvilken standard henviser din
>> definition til.
>
> C99 (ISO/IEC 9899:1999). Når jeg bruger C uden nærmere angivelse er det
> altid den gældende/nyeste standard som jeg tænker på.
>

ok, du kan din C.

Kan du så ikke afgøre sagen:

> void
> calculate (void)
> {
> a+=b;
> return;
> }

Skal Chris have lov til, at bruge "return;" i slutningen af sin funktion.?

---

Xlo0772 <no.mail@mail.no> skrev:
> On Sun, 21 Jul 2002 09:19:54 +0200, Byrial Jensen wrote:
>
> ok, du kan din C.
>
> Kan du så ikke afgøre sagen:
>
>> void
>> calculate (void)
>> {
>> a+=b;
>> return;
>> }
>
> Skal Chris have lov til, at bruge "return;" i slutningen af sin funktion.?

Der er ikke noget formelt forkert i det, men jeg ville hverken
gøre det selv eller tilråde andre at gøre det da det ikke er
normal praksis i C-programmer (i hvert fald ikke i nogen som jeg
har set). Og når man afviger fra normal praksis eller fra hvad
der normalt ventes, gør man uværgeligt programmet sværere at
læse.

---

On Mon, 22 Jul 2002 11:49:50 +0200, Byrial Jensen wrote:

> Der er ikke noget formelt forkert i det, men jeg ville hverken gøre det
> selv eller tilråde andre at gøre det da det ikke er normal praksis i
> C-programmer (i hvert fald ikke i nogen som jeg har set). Og når man
> afviger fra normal praksis eller fra hvad der normalt ventes, gør man
> uværgeligt programmet sværere at læse.

Det kan jeg ikke andet, end at være enig i det.

Iøvrigt, jeg prøvede at compile nedenstående to c-filer
(med gcc 2.96, og default compile options), for at se om der var et
fysisk argument for, at unlade overflødige return's;

test1.c :
---------
void abc(void) {
}

void main(void) {
abc();
}
-----------------

test2.c
-------
void abc(void) {
return;
}

void main(void) {
abc();
}
----------------


Det gav 1 byte forskel i størrelsen. Så det bidrager rent faktisk også
til bloating af softwaren.

Men bortset fra det er der vist ikke nogen fysisk forskel. Stripper man
koden for debug-information, kommer de ned på samme størrelse.

/xlo

---

"Xlo0772" <no.mail@mail.no> wrote

[snip]
> void main(void) {

Det har _aldrig_ været tilladt at "main" returnerer andet end "int".

[snip]
> Det gav 1 byte forskel i størrelsen. Så det bidrager rent faktisk også
> til bloating af softwaren.
>

Ok.

> Men bortset fra det er der vist ikke nogen fysisk forskel. Stripper man
> koden for debug-information, kommer de ned på samme størrelse.

Så bidrager det jo netop _ikke_ med en ændring af størrelsen.
Det lyder rimeligt at debug informationen afhænger af hvor mange linier der
er i source koden.

Venlig hilsen

Mogens Hansen

---

On Tue, 23 Jul 2002 06:53:09 +0200, Mogens Hansen wrote:
> [snip]
>> void main(void) {
>
> Det har _aldrig_ været tilladt at "main" returnerer andet end "int".

Nej, compileren brokkede sig også, men jeg havde ikke slået
-pedantic-errors option til, så jeg fik et program ud af det alligevel.

>> Men bortset fra det er der vist ikke nogen fysisk forskel. Stripper man
>> koden for debug-information, kommer de ned på samme størrelse.
>
> Så bidrager det jo netop _ikke_ med en ændring af størrelsen. Det lyder
> rimeligt at debug informationen afhænger af hvor mange linier der er i
> source koden.

Omend lidt klodset formuleret, var det også det jeg mente med "ikke nogen
fysisk forskel" -> "ikke nogen forskel på koden som bliver udført".

Og med hensyn til ændring af størrelsen. Hvor mange husker lige,
at strippe sit program for debug-info, når man mener at det er færdigt.
Mit gæt er, ikke særlig mange. Selv har jeg kun gjort det en gang, sjusket
som jeg er, fordi det absolut skulle ned på en diskette, hvor der ellers ikke
ville have været plads.

/xlo

---

Xlo0772 skrev:

>Og med hensyn til ændring af størrelsen. Hvor mange husker lige,
>at strippe sit program for debug-info, når man mener at det er færdigt.

Mindst én.

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

---

On Tue, 23 Jul 2002 08:09:16 +0200, Bertel Lund Hansen wrote:

> Xlo0772 skrev:
>
>>Og med hensyn til ændring af størrelsen. Hvor mange husker lige, at
>>strippe sit program for debug-info, når man mener at det er færdigt.
>
> Mindst én.

:) lad mig gætte.

Du er en af dem, og du skriver programmer til din PDA.

Og du er en ivrig læser af "Nerd boy"
(http://nerdboy.port5.com/ : ascii humor)

---

Xlo0772 skrev:

>Du er en af dem

Ja.

>og du skriver programmer til din PDA.

?

Jeg har i Pascal brugt {-$D-} og når programmet så var færdigt,
fjernede jeg det forreste minus. Det gør det til et legalt
compilerdirektiv der slår debugkoden fra. Jeg har endnu ikke
nogen fast vane i C++.

>Og du er en ivrig læser af "Nerd boy"

Nej.

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

---

On Tue, 23 Jul 2002 19:17:09 +0200, Bertel Lund Hansen wrote:
>>og du skriver programmer til din PDA.
> ?
Ok, forkert gættet. Min formodning var, hvis du gik op i størrelsen på
den resulterende kode, så måtte du skrive programmer til små enheder.
PDA=Personal Digital Assistant, d.v.s. PalmPilot og den slags, hvor man
må være sparsom med pladsen.

> Jeg har i Pascal brugt {-$D-} og når programmet så var færdigt, fjernede
> jeg det forreste minus. Det gør det til et legalt compilerdirektiv der
> slår debugkoden fra. Jeg har endnu ikke nogen fast vane i C++.

Rimelig fikst. Og interessant - udfra min tro på det almindelige menneskes
uendelige dovenskab (mest baseret på personlig erfaring), så formoder
jeg, at debugkoden er fjernet af nødvendighed. Så du har nok kodet Pascal
dengang Turbo Vision var sagen. Det forklarer, at du ikke nævner C, og
nok er sprunget direkte til C++.

>>Og du er en ivrig læser af "Nerd boy"
> Nej.
Forkert igen, nok en anden form for humor. Bruger ikke, og er nok
slet ikke interesseret i PDA'er, eller andre små himstregimser?
Muligvis skippet C fuldstændig? Hmm, passer ikke lige på nogen
stereotype profiler, jeg kan sammensætte oven i hovedet.
Og jeg er løbet tør for gætterier.

Nå, nu vil jeg sætte en seddel på min skærm, hvor på der står
"her ender diskussionen". Den vil jeg kigge på en gang imellem, når jeg
blander mig i et "basalt spørgsmål".

/xlo

---

Xlo0772 skrev:

>Ok, forkert gættet. Min formodning var, hvis du gik op i størrelsen på
>den resulterende kode, så måtte du skrive programmer til små enheder.
>PDA=Personal Digital Assistant, d.v.s. PalmPilot og den slags, hvor man
>må være sparsom med pladsen.

Det spiller nok ind at min første computer var en Poly88 - en
8-bit maskine med 24 KB ram hvoraf ca. halvdelen forsvandt hvis
jeg loadede Basic eller Asm.

>Rimelig fikst. Og interessant - udfra min tro på det almindelige menneskes
>uendelige dovenskab (mest baseret på personlig erfaring), så formoder
>jeg, at debugkoden er fjernet af nødvendighed.

Nej, af et generelt ønske om at reducere filstørrelserne. Dette
ønske har jeg stadig selv om jeg p.t. råder over 160 GB
harddiskplads alt i alt.

>Så du har nok kodet Pascal dengang Turbo Vision var sagen.

Næ, det kom nu først til senere. Turbopascal var min indgang til
Pascal.

>Det forklarer, at du ikke nævner C, og nok er sprunget direkte til C++.

Niks. Jeg startede med at lære C i to semestre og lærte først C++
på valgfag sidste semester.

>Bruger ikke, og er nok slet ikke interesseret i PDA'er

Korrekt.

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

---

Xlo0772 <no.mail@mail.no> skrev:
> Og med hensyn til ændring af størrelsen. Hvor mange husker lige,
> at strippe sit program for debug-info, når man mener at det er færdigt.

Hvorfor skulle man "huske" at gøre det? Debug-information er en god
ting at have hvis programmet skulle gå ned, blive stoppet af en ikke
opfyldt "assert" eller på anden måde vise sig at indeholde fejl.

---

On Tue, 23 Jul 2002 10:42:50 +0200, Byrial Jensen wrote:

> Xlo0772 <no.mail@mail.no> skrev:
>> Og med hensyn til ændring af størrelsen. Hvor mange husker lige, at
>> strippe sit program for debug-info, når man mener at det er færdigt.
>
> Hvorfor skulle man "huske" at gøre det? Debug-information er en god ting
> at have hvis programmet skulle gå ned, blive stoppet af en ikke opfyldt
> "assert" eller på anden måde vise sig at indeholde fejl.

Så er det heller ikke færdigt.

At huske det, må være op til den en enkelte, hvis han/hun har brug for det.

Men bortset fra det, er jeg fuldstændig enig. Jeg ville nødig undvære den
extra information.

---

Den Tue, 23 Jul 2002 18:55:14 +0200 skrev Xlo0772:
>On Tue, 23 Jul 2002 10:42:50 +0200, Byrial Jensen wrote:
>
>> Xlo0772 <no.mail@mail.no> skrev:
>>> Og med hensyn til ændring af størrelsen. Hvor mange husker lige, at
>>> strippe sit program for debug-info, når man mener at det er færdigt.
>>
>> Hvorfor skulle man "huske" at gøre det? Debug-information er en god ting
>> at have hvis programmet skulle gå ned, blive stoppet af en ikke opfyldt
>> "assert" eller på anden måde vise sig at indeholde fejl.
>
>Så er det heller ikke færdigt.

Og windows er færdigt i år 3472?

Mvh
Kent
--
If you think about it, Windows XP is actually the OS that
started as "Microsoft OS/2 NT 3.0"

---

Xlo0772 <no.mail@mail.no> skrev:
> On Tue, 23 Jul 2002 10:42:50 +0200, Byrial Jensen wrote:
>> Xlo0772 <no.mail@mail.no> skrev:
>>> Og med hensyn til ændring af størrelsen. Hvor mange husker lige, at
>>> strippe sit program for debug-info, når man mener at det er færdigt.
>>
>> Hvorfor skulle man "huske" at gøre det? Debug-information er en god ting
>> at have hvis programmet skulle gå ned, blive stoppet af en ikke opfyldt
>> "assert" eller på anden måde vise sig at indeholde fejl.
>
> Så er det heller ikke færdigt.

Ja så. så tror jeg ikke at jeg kender nogen færdige programmer.

---

On Tue, 23 Jul 2002 20:09:47 +0200, Byrial Jensen wrote:

> Xlo0772 <no.mail@mail.no> skrev:
>> On Tue, 23 Jul 2002 10:42:50 +0200, Byrial Jensen wrote:
>>> Xlo0772 <no.mail@mail.no> skrev:
>>>> Og med hensyn til ændring af størrelsen. Hvor mange husker lige, at
>>>> strippe sit program for debug-info, når man mener at det er færdigt.
>>>
>>> Hvorfor skulle man "huske" at gøre det? Debug-information er en god
>>> ting at have hvis programmet skulle gå ned, blive stoppet af en ikke
>>> opfyldt "assert" eller på anden måde vise sig at indeholde fejl.
>>
>> Så er det heller ikke færdigt.
>
> Ja så. så tror jeg ikke at jeg kender nogen færdige programmer.

#include <stdio.h>
int main(void) {
return printf("Du vandt\n");
}

---

Xlo0772 <no.mail@mail.no> wrote:

>On Tue, 23 Jul 2002 20:09:47 +0200, Byrial Jensen wrote:
>
>> Xlo0772 <no.mail@mail.no> skrev:
>>> On Tue, 23 Jul 2002 10:42:50 +0200, Byrial Jensen wrote:
>>>> Xlo0772 <no.mail@mail.no> skrev:
>>>>> Og med hensyn til ændring af størrelsen. Hvor mange husker lige, at
>>>>> strippe sit program for debug-info, når man mener at det er færdigt.
>>>>
>>>> Hvorfor skulle man "huske" at gøre det? Debug-information er en god
>>>> ting at have hvis programmet skulle gå ned, blive stoppet af en ikke
>>>> opfyldt "assert" eller på anden måde vise sig at indeholde fejl.
>>>
>>> Så er det heller ikke færdigt.
>>
>> Ja så. så tror jeg ikke at jeg kender nogen færdige programmer.
>
>#include <stdio.h>
>int main(void) {
> return printf("Du vandt\n");
>}

At returnere 9 fra main er naturligvis ikke noget der gør det til et
ikke-korrekt standard C program, men i praktisk brug er det utvivlsomt en
fejl at programmet ikke returnerer EXIT_SUCCESS når det i øvrigt har kørt
tilfredsstillende.

Så det var et næsten færdigt program
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

On Tue, 23 Jul 2002 23:58:20 +0200, Jesper Dybdal wrote:
>
> Xlo0772 <no.mail@mail.no> wrote:
>
>>On Tue, 23 Jul 2002 20:09:47 +0200, Byrial Jensen wrote:
>>
>>> Xlo0772 <no.mail@mail.no> skrev:
>>>> On Tue, 23 Jul 2002 10:42:50 +0200, Byrial Jensen wrote:
>>>>> Xlo0772 <no.mail@mail.no> skrev:
>>>>>> Og med hensyn til ændring af størrelsen. Hvor mange husker lige, at
>>>>>> strippe sit program for debug-info, når man mener at det er
>>>>>> færdigt.
>>>>>
>>>>> Hvorfor skulle man "huske" at gøre det? Debug-information er en god
>>>>> ting at have hvis programmet skulle gå ned, blive stoppet af en ikke
>>>>> opfyldt "assert" eller på anden måde vise sig at indeholde fejl.
>>>>
>>>> Så er det heller ikke færdigt.
>>>
>>> Ja så. så tror jeg ikke at jeg kender nogen færdige programmer.
>>
>>#include <stdio.h>
>>int main(void) {
>> return printf("Du vandt\n");
>>}
> At returnere 9 fra main er naturligvis ikke noget der gør det til et
> ikke-korrekt standard C program, men i praktisk brug er det utvivlsomt
> en fejl at programmet ikke returnerer EXIT_SUCCESS når det i øvrigt har
> kørt tilfredsstillende.
>
> Så det var et næsten færdigt program

heheh, programmet er skam færdigt, og der er en pointe i det.
Det er en joke, tænkt som en afslutning på den lange række af
udvekslinger med ligegyldigheder (som jeg vist har lovet Richard,
at holde mig fra), blandet med spydigheder og sarkasme, som efter min
mening er kørt lidt af sporet. Jeg håber at Byrial, med hans expertice
indenfor C, vil kunne se det morsomme i den (joken).

Der er ingen foreskrifter, som siger at et program skal afslutte med
EXIT_SUCCESS eller 0, når det iøvrigt har kørt tilfredstillende. Et
"fejlfrit" program kører altid "tilfredsstillende". Den værdi programmet
returnerer signallerer blot den interne tilstand af programmet. Som der
står i en af mine gamle lærebøger, vedr. returværdi fra et program:
Citat: "Conventionally, a return value of 0 signals that all is well;
non-zero values usually signal abnormal situations."

Joken er at programmet skriver "Du vandt", og signallerer en abnorm
situation. Det er ligesom, når man siger "jeg får ret, du får fred"
(eller er det omvendt) Beskeden er "vi kan blive ved til dommedag, uden
at komme til enighed, lad os bare stoppe det her".

/xlo

---

Xlo0772 <no.mail@mail.no> skrev:
>Set logisk på det, er en "tom" return det rigtige.

Sådanne "logiske" betragtninger bør foregå indenfor sprogets rammer:

Det er meget basal viden at funktioner automatisk returnerer, selv uden
en explicit return i bunden. Derfor hjælper man ingen ved at skære den
automatiske opførsel ud i pap.

Logisk set er "tmp=a;tmp=tmp+b;a=tmp" måske det rigtige for "a+=b", men
brugen af den lange konstruktion vil ligeledes kun forvirre.

>Vi kan også begynde at diskutere om
>c-syntax er mere rigtig end vb-syntax.

Gruppen dk.edb.programmering.c er beregnet på at diskutere programmer,
kodestil osv i C (og C++), ikke VB. VB-syntax er aldeles ligegyldig, med
mindre man sammenligner konstruktioner i de to sprog.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

On Sun, 21 Jul 2002 00:12:53 +0200, Richard Flamsholt wrote:

> Xlo0772 <no.mail@mail.no> skrev:
>>Set logisk på det, er en "tom" return det rigtige.
>
> Sådanne "logiske" betragtninger bør foregå indenfor sprogets rammer:

Undskyld. jeg passer bedre på en anden gang.

> Det er meget basal viden at funktioner automatisk returnerer, selv uden
> en explicit return i bunden. Derfor hjælper man ingen ved at skære den
> automatiske opførsel ud i pap.
>
> Logisk set er "tmp=a;tmp=tmp+b;a=tmp" måske det rigtige for "a+=b", men
> brugen af den lange konstruktion vil ligeledes kun forvirre.

okay

>>Vi kan også begynde at diskutere om
>>c-syntax er mere rigtig end vb-syntax.
>
> Gruppen dk.edb.programmering.c er beregnet på at diskutere programmer,
> kodestil osv i C (og C++), ikke VB. VB-syntax er aldeles ligegyldig, med
> mindre man sammenligner konstruktioner i de to sprog.

undskyld, aldrig mere nævne VB i denne NG, jeg lover.

undskyld, jeg kunne ikke lade være.

/xlo

---

Lasse Madsen wrote:

> Hej ...
>
> Jeg er i "konverterings" fasen mellem pascal og C til mikroprocessorere ...
> jeg kan ikke rigtigt finde ud af at lave en sub routine ... hvor jeg i
> pascal ville skrive
>
> procedure calculate is
> a = a + b // foreksempel ... bare noget fyld ...
> end procedure


Det har aldrig været Pascal. Det ligner mere Basic.


> hvad gør man så i c ?


Prøv med:
void calculate(void)
{
a += b;
}


> eller hvis jeg vil have noget ind og noget ud ....
>
> procedure calculate ( byte in a, byte out b ) is
> b = a *4
> end procedure
>
> Hvordan kunne dette evt. se ud ?


Hvis du vil have dem som parametre:

void calculate(unsigned char a, unsigned char *b)
{
*b = a * 4;
}

En bedre måde er dog nok at returnere værdien i stedet:

unsigned char calculate(unsigned char a)
{
return a*4;
}


Ivan Johansen