---

Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
er nået til:

typedef struct baseclass {
int x;
   int y;
} baseclass;

typedef struct subclass {
baseclass base;
   int z;
} subclass;

subclass obj;

herefter kan jeg tilgå indholdet med:

obj.base.x=0;
obj.base.y=0;
obj.z=0;

Men, kan jeg ændre koden på en måde, så jeg kan nøjes med obj.x=0;? Så
jeg slipper af med ".base", for det ser ikke helt så smart ud... Det
forekommer mig at jeg engang har set noget lignende vha en eller anden
kombination af struct og union, men jeg kan ikke huske hvordan.

Mvh
Kent

Ps: Lad nu være med at komme med "Brug Ada/Eiffel/Lisp/$favoritsprog i
stedet for".
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
> er nået til:

Du kan ikke programmere objekt orienteret i C, kun i C++ :)

> typedef struct baseclass {
> int x;
> int y;
> } baseclass;
>
> typedef struct subclass {
> baseclass base;
> int z;
> } subclass;
>
> subclass obj;
>
> herefter kan jeg tilgå indholdet med:
>
> obj.base.x=0;
> obj.base.y=0;
> obj.z=0;
>
> Men, kan jeg ændre koden på en måde, så jeg kan nøjes med obj.x=0;? Så
> jeg slipper af med ".base", for det ser ikke helt så smart ud... Det
> forekommer mig at jeg engang har set noget lignende vha en eller anden
> kombination af struct og union, men jeg kan ikke huske hvordan.

Nej, men i C++ kunne du bruger klasser:

class baseclass {
int x;
int y;
};

class subclass:public baseclass {
int z;
};

subclass obj;
obj.x=0;
obj.y=0;
obj.z=0;

/Nic

---

Den Sat, 31 Jan 2004 15:18:34 +0100 skrev Nicolai Hansen:
>> Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
>> er nået til:
>
>Du kan ikke programmere objekt orienteret i C, kun i C++ :)
[...]
>Nej, men i C++ kunne du bruger klasser:

Jeg tror du overså:

Ps: Lad nu være med at komme med "Brug Ada/Eiffel/Lisp/$favoritsprog i
stedet for".

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> Jeg tror du overså:
>
> Ps: Lad nu være med at komme med "Brug Ada/Eiffel/Lisp/$favoritsprog i
> stedet for".

Hehe nej jeg så det godt ;)
Det du ønsker kan mig bekendt bare ikke lade sig gøre :)

> Help test this great MMORPG game - http://www.eternal-lands.com/

Det må jeg prøve ;) er det noget du selv er med til at lave, eller
reklamerer du bare?

---

Den Sun, 1 Feb 2004 10:34:54 +0100 skrev Nicolai Hansen:
>> Jeg tror du overså:
>>
>> Ps: Lad nu være med at komme med "Brug Ada/Eiffel/Lisp/$favoritsprog i
>> stedet for".
>
>Hehe nej jeg så det godt ;)
>Det du ønsker kan mig bekendt bare ikke lade sig gøre :)
>
>> Help test this great MMORPG game - http://www.eternal-lands.com/
>
>Det må jeg prøve ;) er det noget du selv er med til at lave, eller
>reklamerer du bare?

En lille smule - mest forslag og sådan noget, men jeg har da været med
til at lave Makefile og et par bugfixes er det også blevet til.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> >> Help test this great MMORPG game - http://www.eternal-lands.com/
> >
> >Det må jeg prøve ;) er det noget du selv er med til at lave, eller
> >reklamerer du bare?
>
> En lille smule - mest forslag og sådan noget, men jeg har da været med
> til at lave Makefile og et par bugfixes er det også blevet til.

ser ok ud :)

---

Nicolai Hansen wrote:
>>Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
>>er nået til:
>
>
> Du kan ikke programmere objekt orienteret i C, kun i C++ :)

Vrøvl, man kan godt programere objekt orienteret i C.

At C++ så måske er bedre til formålet er en anden sag.

/b

---

> > Du kan ikke programmere objekt orienteret i C, kun i C++ :)
>
> Vrøvl, man kan godt programere objekt orienteret i C.

Jamen, så vis dog manden hvordan han laver nedarvning af structs i C ... og
når du er igang, vis mig hvordan jeg tilføjer virtuelle metoder i en struct,
det har jeg altid gerne ville vide ;)

---

"Nicolai Hansen" <nic@aub.dk> writes:

> > > Du kan ikke programmere objekt orienteret i C, kun i C++ :)
> >
> > Vrøvl, man kan godt programere objekt orienteret i C.
>
> Jamen, så vis dog manden hvordan han laver nedarvning af structs i C ... og
> når du er igang, vis mig hvordan jeg tilføjer virtuelle metoder i en struct,
> det har jeg altid gerne ville vide ;)

Se på GTK+

http://developer.gnome.org/doc/API/gtk/gtk.html
"GTK+ has a C-based object-oriented architecture that allows for
maximum flexibility."

Jeg gad nok vide hvor meget tid de kunne have sparet i deres udvikling
af GTK+ hvis de havde valgt et sprog der understøttede OO.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-´` -. ;:-. | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Den 01 Feb 2004 10:44:05 +0100 skrev Kim Hansen:
>"Nicolai Hansen" <nic@aub.dk> writes:
>
>> > > Du kan ikke programmere objekt orienteret i C, kun i C++ :)
>> >
>> > Vrøvl, man kan godt programere objekt orienteret i C.
>>
>> Jamen, så vis dog manden hvordan han laver nedarvning af structs i C ... og
>> når du er igang, vis mig hvordan jeg tilføjer virtuelle metoder i en struct,
>> det har jeg altid gerne ville vide ;)
>
>Se på GTK+
>
>http://developer.gnome.org/doc/API/gtk/gtk.html
> "GTK+ has a C-based object-oriented architecture that allows for
> maximum flexibility."
>
>Jeg gad nok vide hvor meget tid de kunne have sparet i deres udvikling
>af GTK+ hvis de havde valgt et sprog der understøttede OO.

Ikke meget, hvis man medregner kurser i C++ til samtlige programmørerne,
og de programmører der foretrækker C nok ville forlade projektet, og man
skal dele C++-folkene med KDE-folkene, og C-folkene nok ville starte
deres eget projekt, fordi der ikke fandtes noget tilsvarende der virker
fornuftigt fra C (det har efter sigende altid væred KDE's store
problem, hvis ikke man bruger C++ så er det bare ærgerligt).

Med andre ord, det eneste man ville have fået ud af det var en
konkurrent til QT/KDE. Det forsøgte man iøvrigt også på med Harmony-
projektet, du kan jo kigge på hvornår de bliver færdige i forhold til
GTK+ folkene.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Den Sun, 1 Feb 2004 10:28:00 +0100 skrev Nicolai Hansen:
>> > Du kan ikke programmere objekt orienteret i C, kun i C++ :)
>>
>> Vrøvl, man kan godt programere objekt orienteret i C.
>
>Jamen, så vis dog manden hvordan han laver nedarvning af structs i C ... og
>når du er igang, vis mig hvordan jeg tilføjer virtuelle metoder i en struct,
>det har jeg altid gerne ville vide ;)

virtuelle metoder behøver han ikke vise, dem har jeg styr på.

obj->vtable.paint();

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> virtuelle metoder behøver han ikke vise, dem har jeg styr på.
>
> obj->vtable.paint();

I rest my case ;)

---

"Kent Friis" <leeloo@phreaker.net> wrote:

[8<8<8<]
> obj->vtable.paint();

nærmere
(*obj->vtable[paint_func_index])(obj);

hvis det skal svare til virtuelle metoder, eller kommer man til at mangle
objektet i "paint".

Venlig hilsen

Mogens Hansen

---

Den Sun, 1 Feb 2004 12:22:41 +0100 skrev Mogens Hansen:
>
>"Kent Friis" <leeloo@phreaker.net> wrote:
>
>[8<8<8<]
>> obj->vtable.paint();
>
>nærmere
> (*obj->vtable[paint_func_index])(obj);
>
>hvis det skal svare til virtuelle metoder, eller kommer man til at mangle
>objektet i "paint".

Du har ret i at jeg glemte "this"-pointeren, det plejer at være
compilerens opgave at fange den slags...

Og så skal det vist være obj.vtable->paint, det er vtable der er
pointeren, ikke obj.

Men nu foretrækker jeg godt nok at bruge en struct vtable from for
et array, så paint_func_index passer ikke ind.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Man kunne vel lave noget i retning af

#define BASE int x; int y;
typedef struct baseclass { BASE } baseclass;

#define SUB BASE int z;
typedef struct subclass { SUB } subclass;

int main()
{
subclass obj;

obj.x=0;
obj.y=0;
obj.z=0;

return 0;
}

nedarvning af #defines! *G*

---

Den Sun, 1 Feb 2004 12:49:19 +0100 skrev Nicolai Hansen:
>Man kunne vel lave noget i retning af
>
>#define BASE int x; int y;
>typedef struct baseclass { BASE } baseclass;
>
>#define SUB BASE int z;
>typedef struct subclass { SUB } subclass;
>
>int main()
>{
> subclass obj;
>
> obj.x=0;
> obj.y=0;
> obj.z=0;
>
> return 0;
>}
>
>nedarvning af #defines! *G*

Jo tak... Godt nok påstås det at CPP er turing-komplet, men ligefrem
nedarvning?

Iøvrigt ligger den ret tæt på en af mine egne forsøg:

/* main.c */

typedef struck baseclass {
#include "baseclass.h"
} baseclass;

typedef struct subclass {
#include "subclass.h"
} subclass;

/* baseclass.h */

int x;
int y;

/* subclass.h */

#include "baseclass.h"
int z;

En anelse mere læselig IMHO, men stadig langt ude...

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Nicolai Hansen" <nic@aub.dk> wrote:
> > > Du kan ikke programmere objekt orienteret i C, kun i C++ :)

Hvad med Java, C#, Python, Delphi etc. ?

Naturligvis kan man programmere objekt orienteret i et sprog der ikke har
direkte understøttelse for det (selv i assembler).
Det er blot mere besværligt end at anvende et sprog med direkte
understøttelse.

Man kan undre sig over hvorfor man ønsker at gøre det - men det er en anden
snak.

> >
> > Vrøvl, man kan godt programere objekt orienteret i C.
>
> Jamen, så vis dog manden hvordan han laver nedarvning af structs i C ...

Det har Bertel Brander allerede givet et bud på (selvom det ikke er kønt).


> og
> når du er igang, vis mig hvordan jeg tilføjer virtuelle metoder i en
struct,
> det har jeg altid gerne ville vide ;)

Lad os kalde det run-time polymofi i steder for virtuelle metoder.
Virtuelle metoder er een af C++'s måder at understøtte run-time polymorfi
direkte på.

Man kan naturligvis lave run-time polymofi med C og struct.
Kig på hvordan en C++ compiler implementerer det, så har du svaret.
Kig eventuelt på output fra C++ compilere, der kan generere C kode.

Venlig hilsen

Mogens Hansen

---

> > > > Du kan ikke programmere objekt orienteret i C, kun i C++ :)
>
> Hvad med Java, C#, Python, Delphi etc. ?

Jajaja, den del lå i spørgsmålet

> Naturligvis kan man programmere objekt orienteret i et sprog der ikke har
> direkte understøttelse for det (selv i assembler).
> Det er blot mere besværligt end at anvende et sprog med direkte
> understøttelse.

Du har ret; jeg var mere ovre i at svare jfr nedenstående:
> Man kan undre sig over hvorfor man ønsker at gøre det - men det er en
anden
> snak.

---

Den Sun, 1 Feb 2004 12:22:48 +0100 skrev Mogens Hansen:
>
>"Nicolai Hansen" <nic@aub.dk> wrote:
>> > > Du kan ikke programmere objekt orienteret i C, kun i C++ :)
>
>Hvad med Java, C#, Python, Delphi etc. ?
>
>Naturligvis kan man programmere objekt orienteret i et sprog der ikke har
>direkte understøttelse for det (selv i assembler).
>Det er blot mere besværligt end at anvende et sprog med direkte
>understøttelse.
>
>Man kan undre sig over hvorfor man ønsker at gøre det - men det er en anden
>snak.

Der er mange der har forsøgt at overbevise mig om at objekt-orienteret
programmering er smart, men hvis det betyder at man skal kassere sin
compiler, sin viden, og al den kode man allerede har skrevet, så
forsvinder det smarte sg* ret hurtigt.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Kent Friis" <leeloo@phreaker.net> wrote:
> Den Sun, 1 Feb 2004 12:22:48 +0100 skrev Mogens Hansen:

[8<8<8<]
> >Man kan undre sig over hvorfor man ønsker at gøre det - men det er en
anden
> >snak.
>
> Der er mange der har forsøgt at overbevise mig om at objekt-orienteret
> programmering er smart, men hvis det betyder at man skal kassere sin
> compiler, sin viden, og al den kode man allerede har skrevet, så
> forsvinder det smarte sg* ret hurtigt.

Hvorfor skulle man dog kassere alt det ?
Hvilken compiler bruger du ?
Det er meget almindeligt at en compiler både understøtter C og C++.

Man kan da bare bygge videre på det man allerede ved og har lavet.

Man kan dog undre sig over at man vil lave alle mulige krumpspring (med
mindre pæne makroer eller includes der er lidt langt ude) for at undgå at
bruge et sprog der direkte understøtter objekt orienteret programmering,
hvis det er objekt orienteret programmering man gerne vil lave.
Men dig og det ...

Venlig hilsen

Mogens Hansen

---

Den Sun, 1 Feb 2004 14:48:58 +0100 skrev Mogens Hansen:
>
>"Kent Friis" <leeloo@phreaker.net> wrote:
>> Den Sun, 1 Feb 2004 12:22:48 +0100 skrev Mogens Hansen:
>
>[8<8<8<]
>> >Man kan undre sig over hvorfor man ønsker at gøre det - men det er en
>anden
>> >snak.
>>
>> Der er mange der har forsøgt at overbevise mig om at objekt-orienteret
>> programmering er smart, men hvis det betyder at man skal kassere sin
>> compiler, sin viden, og al den kode man allerede har skrevet, så
>> forsvinder det smarte sg* ret hurtigt.
>
>Hvorfor skulle man dog kassere alt det ?

Det var et forsøg på at sige at hvis det betyder at man skal til at
lære et nyt sprog, så glem det.

>Hvilken compiler bruger du ?
>Det er meget almindeligt at en compiler både understøtter C og C++.

Men C++ har også et par mangler i forhold til mine krav, så det ville
nærmere blive et af de rigtige(tm) OO-sprog, hvis jeg absolut skulle
skifte.

>Man kan da bare bygge videre på det man allerede ved og har lavet.

Den klump kode her laver beregningen, så dem lader vi blive ved med
at være C, de skal bare puttes ind i constructoren som er skrevet
i (fx) Eiffel - det bliver sg* en underlig blanding.

>Man kan dog undre sig over at man vil lave alle mulige krumpspring (med
>mindre pæne makroer eller includes der er lidt langt ude)

Det var netop de makroer og includes jeg ville undgå.

>for at undgå at
>bruge et sprog der direkte understøtter objekt orienteret programmering,
>hvis det er objekt orienteret programmering man gerne vil lave.

Jeg har endnu ikke fundet et OO-sprog jeg kan forliges med.

Og jeg mener stadig at OO er ubrugeligt hvis det ikke kan fungere
sammen med det sprog man nu engang bruger.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> Og jeg mener stadig at OO er ubrugeligt hvis det ikke kan fungere
> sammen med det sprog man nu engang bruger.

Jamen, enhver C++ compiler skal da kunne kompilere et C program også.

Sådan som jeg selv normalt programmerer C/C++ er det ihvertfald en skøn
blanding, og sådan tror jeg de fleste som har programmeret C før C++ blev
kendt/populært har det (Mogens undtaget! *g*) ;)

Jeg laver mine klasser og den slags med fin C++, men resten af programmet i
mere almindelig C. Ok, jeg kan også finde på ting med templates, men kun når
jeg virkelig er i et skidt humør ;)

---

Den Sun, 1 Feb 2004 16:48:20 +0100 skrev Nicolai Hansen:
>> Og jeg mener stadig at OO er ubrugeligt hvis det ikke kan fungere
>> sammen med det sprog man nu engang bruger.
>
>Jamen, enhver C++ compiler skal da kunne kompilere et C program også.

int main() {
int class=0;
   return class;
}

>Sådan som jeg selv normalt programmerer C/C++ er det ihvertfald en skøn
>blanding, og sådan tror jeg de fleste som har programmeret C før C++ blev
>kendt/populært har det (Mogens undtaget! *g*) ;)
>
>Jeg laver mine klasser og den slags med fin C++, men resten af programmet i
>mere almindelig C. Ok, jeg kan også finde på ting med templates, men kun når
>jeg virkelig er i et skidt humør ;)

Det var sådan en blanding jeg lærte på datamatiker, og det er årsagen
til at jeg holder mig *langt* væk fra C++ idag.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> >Jamen, enhver C++ compiler skal da kunne kompilere et C program også.
>
> int main() {
> int class=0;
> return class;
> }

ok :)
der er undtagelser til alle regler hehe

> >Sådan som jeg selv normalt programmerer C/C++ er det ihvertfald en skøn
> >blanding, og sådan tror jeg de fleste som har programmeret C før C++ blev
> >kendt/populært har det (Mogens undtaget! *g*) ;)
> >
> >Jeg laver mine klasser og den slags med fin C++, men resten af programmet
i
> >mere almindelig C. Ok, jeg kan også finde på ting med templates, men kun
når
> >jeg virkelig er i et skidt humør ;)
>
> Det var sådan en blanding jeg lærte på datamatiker, og det er årsagen
> til at jeg holder mig *langt* væk fra C++ idag.

Hmmm.. forstår ikke hvorfor, men det er jo din egen sag :)
Synes bare det er lidt forkert at lave krumspring for at programmere noget
objekt-lignende næsten-orienteret kode i C :)

---

Den Mon, 2 Feb 2004 15:52:38 +0100 skrev Nicolai Hansen:
>> >Jamen, enhver C++ compiler skal da kunne kompilere et C program også.
>>
>> int main() {
>> int class=0;
>> return class;
>> }
>
>ok :)
>der er undtagelser til alle regler hehe

Der er også et par af de nye ting i C99, som ikke findes i C++

>> >Sådan som jeg selv normalt programmerer C/C++ er det ihvertfald en skøn
>> >blanding, og sådan tror jeg de fleste som har programmeret C før C++ blev
>> >kendt/populært har det (Mogens undtaget! *g*) ;)
>> >
>> >Jeg laver mine klasser og den slags med fin C++, men resten af programmet
>i
>> >mere almindelig C. Ok, jeg kan også finde på ting med templates, men kun
>når
>> >jeg virkelig er i et skidt humør ;)
>>
>> Det var sådan en blanding jeg lærte på datamatiker, og det er årsagen
>> til at jeg holder mig *langt* væk fra C++ idag.
>
>Hmmm.. forstår ikke hvorfor, men det er jo din egen sag :)
>Synes bare det er lidt forkert at lave krumspring for at programmere noget
>objekt-lignende næsten-orienteret kode i C :)

Så er det objekt-orienterede måske ikke så smart alligevel?

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> Så er det objekt-orienterede måske ikke så smart alligevel?

Uha, det er en farlig udtalelse - hvis Mogens læser det, så falder der
brænde ned ;) hehehe

---

In article <401ebc79$0$27359$edfadb0f@dread16.news.tele.dk>,
Nicolai Hansen wrote:

>> Så er det objekt-orienterede måske ikke så smart alligevel?
>
> Uha, det er en farlig udtalelse - hvis Mogens læser det, så falder der
> brænde ned ;) hehehe

Betragter man en operationel semantik for et sprog med objekter, saa
bliver man hurtigt ked af det. Det er mange smaa irriterende regler
man tilfoejer til sprog ved at tilfoere dem objekter. Der findes
alternative metoder til at loese de samme problemer som OO loeser. Naar
det er sagt lader det til at massen foretraekker sprog med Objekter.
Muligvis fordi det er nemmere at arbejde med den abstraktion for nogen.
Det er det imidlertid ikke for mig.


--
j.

---

> mange smaa irriterende regler
> man tilfoejer til sprog ved at tilfoere dem objekter.

Hvad tænker du på?


> Der findes
> alternative metoder til at loese de samme problemer som OO loeser.

Spændende, kan du uddybe ?

---

> Der findes
> alternative metoder til at loese de samme problemer som OO loeser.

Ok, jeg prøver lige at være lidt mere konstruktiv :

Indkapsling: Noget lignende kan opnås non-oo ved at lave get/set metoder til
sine data i et modul, og hvis man husker at kalde en init metode har man
noget der ligner en constructor.

Arv / polymorfi : Dette hjælper til med at få større grad af kodegenbrug.
Dette kunne man efterligne lidt (non-oo) ved at bryde sin funktionalitet ned
i små funktioner, og så håbe at der var noget der kunne genbruges på tværs
af systemet.

Er det på dette plan dit argument skulle forstås, eller ... ?

tpt

---

In article <401fc161$0$94994$edfadb0f@dread11.news.tele.dk>,
Troels Thomsen wrote:

>> Der findes
>> alternative metoder til at loese de samme problemer som OO loeser.
>
> Ok, jeg prøver lige at være lidt mere konstruktiv :

Du er lidt derhenad hvor mit argument skulle forstaas. Naar vi snakker
om objekt-orienteret programmering snakker vi i virkeligheden om to
ting. Vi snakker om de redskaber som et givent programmeringssprog
stiller til raadighed for os i forbindelse med klassificering af
funktioner (metoder) og data (fields). Det vaere sig muligheden for
at skjule visse af disse ting for hinanden, generalisere over bestemte
typer, inddeling i klassehierakier, funktionspolymorfi samt klasse-
polymorfi. Samtidig er OO et udtryk for en given abstrakt tankegang
naar programmet designes. Naar jeg snakker om alternative metoder er
jeg ikke interesseret i at kopiere tankegangen (som jeg ikke tror paa
i forbindelse med softwareudvikling), men derimod funktionaliteten i
redskaberne der stilles til raadighed.

Der er ting der lader sig beskrive glimrende i klassehierakier. En af
disse er grafiske brugergraenseflader. Der er ogsaa problemer der er
svaere at beskrive i klassehierakier. Men - det gaelder for stort set
alle systemer der soeger at opdele kildekode for at oege overskuelig-
heden og gennemtvinge anvendelse af visse graenseflader.

Et af de redskaber man snakker om er, som du naevner, indkapsling og
abstraktion. Ideen er at man kan skjule irrelevante dele af koden for
andre programmoerer. Baade for at forsimple det de skal overskue, men
ogsaa for at nedbringe det navnerum (scope/namespace) der er gaeldende.
Samtidig kan man skjule en underliggende implementation (abstraktion),
saaledes at denne kan skiftes ud paa et senere tidspunkt uden at det
paavirker resten af programmet.

For at tage et konkret modulsystem har jeg valgt at beskrive det system
som programmeringssproget Standard ML besidder. Fordelen er at i stedet
for en raekke henkastede ideer faar du et indblik i et samlet system,
der ikke umiddelbart har nogen mangler.

Grundstenen i systemet er en saakaldt signatur. Det er en abstrakt
beskrivelse (specifikation) af et eller andet begreb. I dette tilfaelde
repraesentationen af en maengde:

+----------------------
signature SET =
sig

type e
type t

val empty : t

val insert : e * t -> t
val remove : e * t -> t
val sub : t * t -> t

val union : t * t -> t
val intersection : t * t ->

val find : e * t -> bool

val equal : t * t -> bool

end
+------------------

Maengder (SETs) er givet ved at de har en type for elementer (type e),
en type for maengder af disse elementer (type t), den tomme maengde
(empty, der har typen t). Dernaest foelger en raekke operationer paa
maengder. Man kan indsaette elementer i maengder (insert er en funktion
der som input tager et element og en maengde og som output returnerer
en maengde). Man kan fjerne dem. Man kan lave maengdesubtraktion. Man
kan lave forenings- og faellesmaengde. Man kan spoerge til om et givet
element er i en maengde. Til sidst kan man spoerge om hvorvidt to
maengder er ens.

En given implementation af en saadan signatur kaldes en structure.
Man kan saa tvinge en structure til at opfylde en given specifikation.

structure Set :> SET =
struct
...
end

Herved har du opnaaet at du, med en anden tankegang end OO, har
mulighederne for indkapsling og abstraktion. Vi er i ovenstaaende kun
i stand til at tilgaa de funktioner som vores specifikation stiller
til raadighed. Samtidig har vi abstraheret hvorledes typen t er re-
praesenteret (Det kunne vaere en haegtet liste, et (binary) tree eller
en hashtabel).

Standard ML har ikke et subtypebegreb og har derfor ikke
klassehierakier. Det betyder at begrebet arv ikke rigtigt giver mening.
Polymorfi har det dog. Det kommer vi tilbage til.

Modularisering foregaar med et begreb der hedder functors. En functor
en en funktion fra structures til structures. Erklaerer vi eksempeltvist
en signatur for ordning:

signature ORDERING =
sig
type t

val leq : t * t -> bool
val eq : t * t -> bool
end

og goer heltal (Integers) til et medlem af denne:

structure IntOrdering : ORDERING =
struct

type t = int

fun leq(x,y) = x <= y
fun eq(x,y) = x = y

end

Kan vi lave en functor, der som input tager et structure der opfylder
ORDERING signaturen og som output producerer en structure, der opfylder
maengesignaturen SET:

functor BinarySetFn (O : ORDERING) : SET =
struct
...
end

Vi kan saa lave en struktur for maengder af heltal ved at stykke alt
det her sammen:

structure IntSet = BinarySetFn(IntOrdering)

Det er ikke helt ulig templates i C++. Forskellen er simpelthen bare at
du benytter en anden metode til at dele din kode op i smaa
structures/ functors og saa stykker du dem sammen til et faerdigt
program. I stedet for at inddele dit program i klasser og lade dem
interagere med hinanden.

Polymorfi findes i mange former. En af dem er muligheden for at i
C++ at erklaere en funktion med samme navn, men med forskellige input-
typer:

double pow(int x, int y);
double pow(double x, int y);
....

En anden mulighed er at have polymorfien parametrisk via en template:

template <typename T>
foo bar(T t, int x) {...} /* Modulo syntax, jeg koder meget lidt C++ */

Det foerste har Standard ML ikke direkte (man skal oprette en ny type
der eksplicit er en slags union af ints og doubles), det andet har
Standard ML dog. Endda implicit. Kodestumpen:

template <typename T>
T identitiy(T t) { return T; }

er i Standard ML beskrevet som:

fun identity x = x

Den har typen identity : \alpha -> \alpha, da der ikke er nogen
restriktioner paa hvad x er for noget. Den vaesentlige forskel er at
i C++ angiver man explicit at en type er parametrisk polymorf, hvor man
i Standard ML lader oversaetteren gennemskue det automatisk. Der kommer
typefejl, hvis man bruger det forkert. Det betyder ogsaa at man i C++
kan lave nogle ting man ikke kan i Standard ML paa det her omraade, da
man explicit kan angivi typerne.

Jeg vil hen til at ovenstaaende kan benyttes, sammen med functors, til
at lave polymorfi i programmer. Du kan netop anvende dette til at
abstrahere typen du anvender i en container class af en eller anden
type (eksempeltvist et SET), proviso at det du vil gemme i din
containerclass opfylder at det kan ordnes (altsaa her en implementation
i en structure der opfylder ORDERING signaturen).

Konklusion: Jeg vil ikke emulere OO i et sprog der ikke har redskaberne
til at behandle OO korrekt. Jeg vil derimod have en anden grundliggende
tankegang for hvorledes man modulariserer sit program og benytte denne
anden metode som grundliggende tankegang i programmets opbygning. Hvis
man forsoeger at presse OO-tankegangen ned over eksempeltvist Standard
MLs modulsystem af signaturer/structures/functors, saa gaar det grue-
ligt galt.

Jeg haaber du har faaet noget ud af svaret.

--
j.

---

"Jesper Louis Andersen" <jlouis@miracle.mongers.org> wrote:
> >> Der findes
> >> alternative metoder til at loese de samme problemer som OO loeser.
[...]
> For at tage et konkret modulsystem har jeg valgt at beskrive det system
> som programmeringssproget Standard ML besidder. Fordelen er at i stedet
> for en raekke henkastede ideer faar du et indblik i et samlet system,
> der ikke umiddelbart har nogen mangler.
>
> Grundstenen i systemet er en saakaldt signatur.

SML signaturer er ikke et alternativ til OO.
SML signaturer _er_ OO.

mvh. Anders

---

In article <4020d2e2$0$95070$edfadb0f@dread11.news.tele.dk>,
Anders J. Munch wrote:

> SML signaturer er ikke et alternativ til OO.
> SML signaturer _er_ OO.

Den maa du meget gerne uddybe. SML har ikke subtyping og mange af de
metoder du benytter for at faa kodegenbrug svarer til at man i C++
kaster omkring sig med templates hvor man end kan. Jeg vil mene at
OO er mere end at du kan indkapsle og abstrahere nogle tilfaeldige
funktioner. Derudover min kaephest igen: OO er ikke veldefineret og
at kalde det er paradigme er ogsaa overdrevet. Det har stort set samme
overdrivelsesmoment som Asepect Oriented Programming.




--
j.

---

"Jesper Louis Andersen" <jlouis@miracle.mongers.org> wrote:
> In article <4020d2e2$0$95070$edfadb0f@dread11.news.tele.dk>,
> Anders J. Munch wrote:
>
> > SML signaturer er ikke et alternativ til OO.
> > SML signaturer _er_ OO.
>
> Den maa du meget gerne uddybe. SML har ikke subtyping og mange af de
> metoder du benytter for at faa kodegenbrug svarer til at man i C++
> kaster omkring sig med templates hvor man end kan. Jeg vil mene at
> OO er mere end at du kan indkapsle og abstrahere nogle tilfaeldige
> funktioner. Derudover min kaephest igen: OO er ikke veldefineret og
> at kalde det er paradigme er ogsaa overdrevet. Det har stort set samme
> overdrivelsesmoment som Asepect Oriented Programming.

Kernen i objekt-orientering er køretids-polymorfi. At forskellige
objekter, når sendt den samme besked, kan reagere forskelligt. Der er
mange definitioner på objekt-orientering, men en definition der ikke
forlanger polymorfi har jeg endnu ikke set.

Så kan man diskutere, hvad der ellers skal klistres på. Det gør man
sædvanligvis ved at studere sit foretrukne OO-sprog, skrive en lang
checkliste med de ting man kan li' ved sproget, og så ellers insistere
på at andre sprog ikke er "rigtigt" OO hvis de ikke kan levere alt
hvad der står på checklisten.

Hvis man forlanger klasser, så udelukkes delegation-baserede sprog.
Hvis man forlanger nedarvning, så udelukkes Emerald.
Hvis man forlanger data hiding, så udelukkes Python.

Ergo er det noget pjat at forlange klasser, nedarvning eller data
hiding. Det eneste der reelt skal til for at kunne skrive programmer i
en objekt-orienteret stil, det er polymorfi.

Det er rigtigt at der findes mange definitioner på
objekt-orientering. Men min er den rigtige

Derimod kan ti vilde heste ikke formå mig til at have en mening om
hvad der er og hvad der ikke er et paradigme...

mvh. Anders

---

Anders J. Munch wrote:

> Det er rigtigt at der findes mange definitioner på
> objekt-orientering. Men min er den rigtige

Måske kender du?

<http://www.paulgraham.com/reesoo.html>

I modsat fald er Jonathan Rees' beskrivelse
af de dele objectorintering består af særdeles
interessant.

--
Jens Axel Søgaard

---

"Jesper Louis Andersen" <jlouis@miracle.mongers.org> wrote in message
news:slrnc1vphm.bk.jlouis@miracle.mongers.org...
> In article <401fc161$0$94994$edfadb0f@dread11.news.tele.dk>,
[....]
> structure IntSet = BinarySetFn(IntOrdering)
>
> Det er ikke helt ulig templates i C++. Forskellen er simpelthen bare at
> du benytter en anden metode til at dele din kode op i smaa
> structures/ functors og saa stykker du dem sammen til et faerdigt
> program. I stedet for at inddele dit program i klasser og lade dem
> interagere med hinanden.

Men hvad pokker er forskellen?
Signatur -> interface( c++ klasse med rent pure virtual funktioner)
Structure -> klasse der implementerer et interface(arver fra det, og
implementerer alle funktioner)
Functor -> template klasse

Givetvis, så er der en masse ting C++ kan, som er valgt
fra i sml's signatur/structur/functor ting, men få som
ikke eksisterer i c++ - den eneste jeg umiddelbart kan
komme i tanke om er den udefinerede type i signaturen - det
kan man ikke i c++.

Jeg syntes Anders har ret - Det er objektorientering. Objekterne bliver
blot defineret som abstrakte typer, i signaturen, istedet for
instanser af selve klassen.

Se blot
http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=set.html
(klik på det hvide billede) -
Den opdeling, som sml skaber er også
til stede her, i standard biblioteket af C++.

Og ja, functors/templates er givet vis ude over det objekt orienterede i
løsningen,
men det ændrer da ikke på at grundstenene er objektorienterede?


mvh Jonas

---

In article <bvrgqh$1cb3$1@munin.diku.dk>, Jonas Meyer wrote:

> Men hvad pokker er forskellen?

Vi snakker forbi hinanden tror jeg. I min definition er templates ikke
en del af OO-paradigmet. Hvis det var, kan eksempeltvist Java
(indtil for nylig) ikke have vaeret et OO-sprog.

> Signatur -> interface( c++ klasse med rent pure virtual funktioner)
> Structure -> klasse der implementerer et interface(arver fra det, og
> implementerer alle funktioner)
> Functor -> template klasse

C++ meget store styrke er at det ikke dikterer en bestemt stilart. Du
kan, hvis du vil, godt programmere det i en anden stil end den ''rene''
OO (igen med reference til at templates ikke eksisterer i OO). Dit
hieraki er ikke bygget af subtyping (arv) men af templateklasser og det
synes jeg er meget forskelligt.

> Jeg syntes Anders har ret - Det er objektorientering.
> Objekterne bliver blot defineret som abstrakte typer,
> i signaturen, istedet for instanser af selve klassen.

Det er interessant at i har en anden opfattelse her, synes jeg.

> Og ja, functors/templates er givet vis ude over det
> objekt orienterede i løsningen,
> men det ændrer da ikke på at grundstenene er objektorienterede?

Der er absolut ligheder. indkapsling og abstraktion er til stede i
stort set alle modulsystemer, da det i sagens natur blandt andet er
omdrejningspunktet naar programkode skal opdeles til mindre overskuelige
dele.

Det der irriterer mig ved OO er subtyping. Og kun det. At der er veje
uden om det i C++ er bare en af de ting der goer at sproget klarer sig
saa godt. Hvis jeg selv skulle vaelge sprog til en opgave ville det
nok ikke blive C++, men paa den anden side er det ikke et sprog jeg
decideret hader som pesten. Det bias kan vaere vaesentligt at have med
naar man vurderer mit synspunkt.


--
j.

---

Jeg er enig i at SML og funktionelle sprog generelt stiller en "måde at
tænke på" til rådighed som jeg gerne så tilgængelig i mit daglige arbejde.
Jeg vil dog ikke kalde den overlegen i forhold til OO, slet ikke.
Det forekommer mig at når jeg tænker på et problem i SML, tænker jeg mere i
strømme af information hvor jeg i C++ primært tænker i objekter.
Begge sprog har syntaktiske ulemper, synes jeg. C++ templates giver en
kringlet syntaks når man bevæger sig ud det helt basale. Her er eksempelvis
SML's pattern matching meget lettere at gennemskue. Til gengæld giver infix
funktioner og o-operationer somme tider sætninger i SML der sætter store
krav til programmøren. Af og til skal man nærmest sidde med en
associativitets- og præcedenstabel for at kunne gennemskue et udtryk.

Kristian



"Jesper Louis Andersen" <jlouis@miracle.mongers.org> wrote in message
news:slrnc1vphm.bk.jlouis@miracle.mongers.org...
> In article <401fc161$0$94994$edfadb0f@dread11.news.tele.dk>,
> Troels Thomsen wrote:
>
> >> Der findes
> >> alternative metoder til at loese de samme problemer som OO loeser.
> >
> > Ok, jeg prøver lige at være lidt mere konstruktiv :
>
> Du er lidt derhenad hvor mit argument skulle forstaas. Naar vi snakker
> om objekt-orienteret programmering snakker vi i virkeligheden om to
> ting. Vi snakker om de redskaber som et givent programmeringssprog
> stiller til raadighed for os i forbindelse med klassificering af
> funktioner (metoder) og data (fields). Det vaere sig muligheden for
> at skjule visse af disse ting for hinanden, generalisere over bestemte
> typer, inddeling i klassehierakier, funktionspolymorfi samt klasse-
> polymorfi. Samtidig er OO et udtryk for en given abstrakt tankegang
> naar programmet designes. Naar jeg snakker om alternative metoder er
> jeg ikke interesseret i at kopiere tankegangen (som jeg ikke tror paa
> i forbindelse med softwareudvikling), men derimod funktionaliteten i
> redskaberne der stilles til raadighed.

---

"Jesper Louis Andersen" <jlouis@miracle.mongers.org> skrev:
> Der findes
> alternative metoder til at loese de samme problemer som OO loeser. Naar
> det er sagt lader det til at massen foretraekker sprog med Objekter.
> Muligvis fordi det er nemmere at arbejde med den abstraktion for nogen.
> Det er det imidlertid ikke for mig.

Objektorienteret programmering giver i hvert fald et fornuftigt
abstraktionsniveau, som kan være yderst anvendeligt, når man skal
modelere ting fra den "virkelige" verden i et softwaresystem ;-D

--
Michael Banzon
http://southbound.dk/
http://southbound.dk/blog/

---

> > Så er det objekt-orienterede måske ikke så smart alligevel?
>
> Uha, det er en farlig udtalelse - hvis Mogens læser det, så falder der
> brænde ned ;) hehehe

I "gamle" dage da jeg programmerede Turbo Pascal (et desværre næstent uddødt
sprog) havde jeg ikke ret svært ved at gå over til OOP i TP da den mulighed
kom. Men synes i dag at forskellen mellem C og C++ er lidt for stor.. men
måske bare mig :(

/René

---

> Men C++ har også et par mangler i forhold til mine krav, så det ville
> nærmere blive et af de rigtige(tm) OO-sprog, hvis jeg absolut skulle
> skifte.

Jeg forstår ikke din argumentation. Det, du forsøger at opnå kan tydeligvis
klares let med c++. Dertil kommer at du _netop_ ikke behøver at "kassere" al
din viden da du med meget få undtagelser kan skrive ren c-kode og blot bruge
de nødvendige c++ overbygninger som eksempelvis klasser.

Kristian

---

Den Wed, 4 Feb 2004 21:36:20 +0100 skrev Kristian Dupont:
>> Men C++ har også et par mangler i forhold til mine krav, så det ville
>> nærmere blive et af de rigtige(tm) OO-sprog, hvis jeg absolut skulle
>> skifte.
>
>Jeg forstår ikke din argumentation. Det, du forsøger at opnå kan tydeligvis
>klares let med c++.

Nej, det som *dette* spørgsmål gik ud på, kan tydeligvis klares let
med c++.

Et eksempel der (mig bekendt) ikke kan lade sig gøre i C++ er at
erklære en const virtual, på samme måde som en metode.

>Dertil kommer at du _netop_ ikke behøver at "kassere" al
>din viden da du med meget få undtagelser kan skrive ren c-kode og blot bruge
>de nødvendige c++ overbygninger som eksempelvis klasser.

Det har jeg prøvet. Den sammenblanding ødelægger begge dele.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Kent Friis" <leeloo@phreaker.net> wrote:

> Et eksempel der (mig bekendt) ikke kan lade sig gøre i C++ er at
> erklære en const virtual, på samme måde som en metode.

Hvad mener du ?
Jeg forstår det ikke.

const og virtual er 2 uafhængige ting, som frit kan kombineres.

Er det noget i stil med:

class foo
{
void foo_func1();
void foo_func2() const;
virtual void foo_func3();
virtual void foo_func4() const;
};

No problem - bare gør det.

Venlig hilsen

Mogens Hansen

---

Den Thu, 5 Feb 2004 06:48:31 +0100 skrev Mogens Hansen:
>
>"Kent Friis" <leeloo@phreaker.net> wrote:
>
>> Et eksempel der (mig bekendt) ikke kan lade sig gøre i C++ er at
>> erklære en const virtual, på samme måde som en metode.
>
>Hvad mener du ?
>Jeg forstår det ikke.
>
>const og virtual er 2 uafhængige ting, som frit kan kombineres.
>
>Er det noget i stil med:
>
>class foo
>{
> void foo_func1();
> void foo_func2() const;
> virtual void foo_func3();
> virtual void foo_func4() const;
>};

Nej, ikke en funktion. En konstant:

class enemy {
virtual const int attack = 0;
}

class fighter : enemy {
virtual const int attack = 7;
}

int main() {
enemy * attacker = new fighter;
   
   player.health -= enemy->attack;
}

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Kent Friis" <leeloo@phreaker.net> wrote in message
news:bvtrcn$605$2@sunsite.dk...
> Den Thu, 5 Feb 2004 06:48:31 +0100 skrev Mogens Hansen:
> >
> >"Kent Friis" <leeloo@phreaker.net> wrote:
> >
> >> Et eksempel der (mig bekendt) ikke kan lade sig gøre i C++ er at
> >> erklære en const virtual, på samme måde som en metode.
> >
> >Hvad mener du ?
> >Jeg forstår det ikke.
> >
> >const og virtual er 2 uafhængige ting, som frit kan kombineres.
> >
> >Er det noget i stil med:
> >
> >class foo
> >{
> > void foo_func1();
> > void foo_func2() const;
> > virtual void foo_func3();
> > virtual void foo_func4() const;
> >};
>
> Nej, ikke en funktion. En konstant:
>
> class enemy {
> virtual const int attack = 0;
> }
>
> class fighter : enemy {
> virtual const int attack = 7;
> }
>
> int main() {
> enemy * attacker = new fighter;
>
> player.health -= enemy->attack;
> }

Nej, konstanter kan ikke være virtuelle på den måde.

Du kan sagtens finde masser af eksempler på ting du ikke kan i C++.
Det er ikke i sig selv væsentligt, hvis man ikke siger hvilken sammenhæng
det er væsentligt at kunne et eller andet i.

Man kan kigge på hvordan man kan opnå samme effekt.
Det eksempel du viser kan jeg ikke se kræver særlig direkte understøttelse i
sproget - det er nemt og direkte at lave.

Du kan f.eks. skrive

class enemy
{
public:
virtual int attack() const
{ return 0; }
};

class fighter : public enemy
{
public:
virtual int attack() const
{ return 7; }
};

int main()
{
enemy* attacker = new fighter;
player.health -= attacker->attack();
}

eller du kan skrive

class enemy
{
public:
enemy(int attack_arg = 0) :
attack(attack_arg) {}
const int attack;
};

class fighter : public enemy
{
public:
fighter() :
enemy(7) {}
};

int main()
{
enemy* attacker = new fighter;
player.health -= attacker->attack;
}

Hvad er det for et problem du prøver at løse ?
Hvilken rolle spiller det om det er en funktion, eller en variabel ?


I dit eksempel ville jeg måske endda hellere være bekymret for at virtual
metoder kun afhænger af een type.
Man kunne nemt forestille sig at udfaldet af angrebet både afhænger af
afgriberen (f.eks. fighter) og den der bliver angrebet (f.eks. king,
knight).
Selvom multimethods ikke er direkte understøttet i C++, findes der
adskillige udemærkede måder at gøre det på.


Venlig hilsen

Mogens Hansen

---

Den Thu, 5 Feb 2004 21:17:55 +0100 skrev Mogens Hansen:
>
>"Kent Friis" <leeloo@phreaker.net> wrote in message
>news:bvtrcn$605$2@sunsite.dk...
>>
>> Nej, ikke en funktion. En konstant:
>>
>> class enemy {
>> virtual const int attack = 0;
>> }
>>
>> class fighter : enemy {
>> virtual const int attack = 7;
>> }
>>
>> int main() {
>> enemy * attacker = new fighter;
>>
>> player.health -= enemy->attack;
>> }
>
>Nej, konstanter kan ikke være virtuelle på den måde.

Tak, så havde jeg ret.

>Du kan sagtens finde masser af eksempler på ting du ikke kan i C++.
>Det er ikke i sig selv væsentligt, hvis man ikke siger hvilken sammenhæng
>det er væsentligt at kunne et eller andet i.

Nu vidste jeg på forhånd at C++ ikke ville opfylde mine krav, så derfor
var det slet ikke en del af det oprindelige spørgsmål. I C kan jeg
sagtens smide mine konstanter over i struct vtable, og derfor var der
ingen grund til at spørge om det.

>Man kan kigge på hvordan man kan opnå samme effekt.
>Det eksempel du viser kan jeg ikke se kræver særlig direkte understøttelse i
>sproget - det er nemt og direkte at lave.

<Cut at bruge metoder i stedet for konstanter>

>eller du kan skrive
>
>class enemy
>{
>public:
> enemy(int attack_arg = 0) :
> attack(attack_arg) {}
> const int attack;
>};
>
>class fighter : public enemy
>{
>public:
> fighter() :
> enemy(7) {}
>};

Ok, den ser til gengæld fornuftig ud, bort set fra at initaliserings-
listen på enemy's constructor bliver meget lang til et komplet spil,
men det er jo blot et spørgsmål om formatering.

>Hvad er det for et problem du prøver at løse ?

At skrive programmet så det passer til designet, fremfor at tilrette
designet til begrænsninger i sproget.

>Hvilken rolle spiller det om det er en funktion, eller en variabel ?

Hvis ikke sproget passer til min tankegang, så vælger jeg et andet
sprog.

Det er endnu ikke lykkedes mig at finde et OO-sprog som jeg kan
finde mig i, hvorimod C passer rimelig godt til min tankegang (når
det skal være mere kompliceret end et shell-script).

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
>
> Nu vidste jeg på forhånd at C++ ikke ville opfylde mine krav, så derfor
> var det slet ikke en del af det oprindelige spørgsmål. I C kan jeg
> sagtens smide mine konstanter over i struct vtable, og derfor var der
> ingen grund til at spørge om det.

Helt ærligt. Om man kalder det en konstant eller en funktion som
returnerer en konstant, det kan vel gå ud på et. Forskellen er blot lidt
syntaks.

>>Hvad er det for et problem du prøver at løse ?
>
> At skrive programmet så det passer til designet, fremfor at tilrette
> designet til begrænsninger i sproget.

Designet er for mig at se det samme uanset om man kalder det en konstant
eller en funktion.

---

Den Thu, 05 Feb 2004 23:31:10 +0100 skrev Byrial Jensen:
>Kent Friis wrote:
>>
>> Nu vidste jeg på forhånd at C++ ikke ville opfylde mine krav, så derfor
>> var det slet ikke en del af det oprindelige spørgsmål. I C kan jeg
>> sagtens smide mine konstanter over i struct vtable, og derfor var der
>> ingen grund til at spørge om det.
>
>Helt ærligt. Om man kalder det en konstant eller en funktion som
>returnerer en konstant, det kan vel gå ud på et. Forskellen er blot lidt
>syntaks.

Ikke når man er perfektionist.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Kent Friis" <leeloo@phreaker.net> wrote in message
news:bvucjg$pnn$1@sunsite.dk...
> Den Thu, 5 Feb 2004 21:17:55 +0100 skrev Mogens Hansen:
> >

[8<8<8<]
> >Nej, konstanter kan ikke være virtuelle på den måde.
>
> Tak, så havde jeg ret.

Og .... ?
Det er, som vist, en anden måde man laver det på.

[8<8<8<]
> Nu vidste jeg på forhånd at C++ ikke ville opfylde mine krav, så derfor
> var det slet ikke en del af det oprindelige spørgsmål.

Naturligvis.

> I C kan jeg
> sagtens smide mine konstanter over i struct vtable, og derfor var der
> ingen grund til at spørge om det.

Prøv at vis hvordan du gør - altså konkret kode.
Prøv så at argumentere for at det er simplere, lette at vedligeholde, mere
effektivt eller på anden måde bedre i C end i C++ for et objekt orienteret
design svarende til det du skitserede med enemy og figther.
Prøv så til sidst at fortælle os hvorfor det ikke er, eller simpelt kan
gøres til lovligt C++ kode.

[8<8<8<]
> >Hvad er det for et problem du prøver at løse ?
>
> At skrive programmet så det passer til designet, fremfor at tilrette
> designet til begrænsninger i sproget.

Hvilke begrænsninger snakker du om ?
På hvilken måde understøtter C "virtuelle konstanter" (forstået som
konstanter der varierer med typen i et objekt orienteret arvehieraki) mere
direkte end C++ ?

Programmering har altid været noget med at lave et design der matcher
problem domainet og løsnings domainet. Designet er således påvirket både af
problem domainet og løsnings domainet.
Et design for samme problem vil ofte se forskelligt ud i f.eks. C, C++,
Java, Python etc.
Der er vist ikke udsigt til at det bliver anderledes foreløbigt.

Se eventuelt bogen
Multi-Paradigm DESIGN for C++
James O. Coplien
ISBN 0-201-82467-1
for en glimrende beskrivelse af dette.

>
> >Hvilken rolle spiller det om det er en funktion, eller en variabel ?
>
> Hvis ikke sproget passer til min tankegang, så vælger jeg et andet
> sprog.

Vi prøver igen: Hvilken rolle spiller det for designet om det er en funktion
eller en variabel ?

>
> Det er endnu ikke lykkedes mig at finde et OO-sprog som jeg kan
> finde mig i, hvorimod C passer rimelig godt til min tankegang (når
> det skal være mere kompliceret end et shell-script).

Hmm...
Jeg opfattede dit oprindeligt spørgsmål modsat:
Du havde et problem som du gerne ville modelere objekt orienteret, og kunne
ikke få C til at understøtte din tankegang godt.

Venlig hilsen

Mogens Hansen

---

Den Fri, 6 Feb 2004 01:21:08 +0100 skrev Mogens Hansen:
>
>"Kent Friis" <leeloo@phreaker.net> wrote in message
>news:bvucjg$pnn$1@sunsite.dk...
>> Den Thu, 5 Feb 2004 21:17:55 +0100 skrev Mogens Hansen:
>> >
>
>[8<8<8<]
>> >Nej, konstanter kan ikke være virtuelle på den måde.
>>
>> Tak, så havde jeg ret.
>
>Og .... ?
>Det er, som vist, en anden måde man laver det på.

Ja, men det ville jo have været dumt hvis det viste sig at mit eksempel
på hvad man ikke kan gøre rent faktisk virkere

>[8<8<8<]
>> Nu vidste jeg på forhånd at C++ ikke ville opfylde mine krav, så derfor
>> var det slet ikke en del af det oprindelige spørgsmål.
>
>Naturligvis.
>
>> I C kan jeg
>> sagtens smide mine konstanter over i struct vtable, og derfor var der
>> ingen grund til at spørge om det.
>
>Prøv at vis hvordan du gør - altså konkret kode.
>Prøv så at argumentere for at det er simplere, lette at vedligeholde, mere
>effektivt eller på anden måde bedre i C end i C++ for et objekt orienteret
>design svarende til det du skitserede med enemy og figther.

Jeg siger ikke det er hverken simplere eller lettere at vedligeholde end
C++ kode, hvis man er C++ programmør. Men for mig der har haft dårlige
erfaringer med C++ under min uddannelse, er C++ uinteressant. Og det
er mit primære argument for IKKE at bruge C++.

>> >Hvad er det for et problem du prøver at løse ?
>>
>> At skrive programmet så det passer til designet, fremfor at tilrette
>> designet til begrænsninger i sproget.
>
>Hvilke begrænsninger snakker du om ?
>På hvilken måde understøtter C "virtuelle konstanter" (forstået som
>konstanter der varierer med typen i et objekt orienteret arvehieraki) mere
>direkte end C++ ?

Fordelen er at da jeg selv definerer struct vtable, kan jeg putte alle
de ting derover, som jeg har lyst til. Det kan man ikke i C++, der må
man følge sprogets begrænsninger.

>> >Hvilken rolle spiller det om det er en funktion, eller en variabel ?
>>
>> Hvis ikke sproget passer til min tankegang, så vælger jeg et andet
>> sprog.
>
>Vi prøver igen: Hvilken rolle spiller det for designet om det er en funktion
>eller en variabel ?

Jeg vil hellere bruge et sprog hvor jeg kan skrive tingene på den
måde jeg mener dem. Indtil jeg finder det sprog, holder jeg mig til
C.

Jeg siger ikke at C er den optimale måde at gøre det på, men jeg
gider ikke at lære et nyt sprog der heller ikke kan det jeg vil,
sålænge der stadig er sprog jeg slet ikke har undersøgt hvad de kan
bruges til.

>> Det er endnu ikke lykkedes mig at finde et OO-sprog som jeg kan
>> finde mig i, hvorimod C passer rimelig godt til min tankegang (når
>> det skal være mere kompliceret end et shell-script).
>
>Hmm...
>Jeg opfattede dit oprindeligt spørgsmål modsat:
>Du havde et problem som du gerne ville modelere objekt orienteret, og kunne
>ikke få C til at understøtte din tankegang godt.

Nej, jeg ville skrive en stump kode, som jeg var næsten sikker på at
jeg havde set gjort andre steder, og så ville jeg lige høre
C-eksperterne om hvordan det nu lige var man gjorde. Jeg måtte
dog konstatere at jeg tog fejl, det kan ikke lade sig gøre. Jeg
forsøgte bevidst at undgå denne diskussion ved at skrive at jeg ikke var
interesseret i at høre at det er nemmere i andre sprog. Det er jeg sg*
udemærket klar over, men alligevel bliver folk ved med at spørge
hvorfor jeg ikke bruger C++, og så nævner jeg nogen af grundene.

Det mest utrolige er at der ikke er nogen Java-folk der har blandet
sig...

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Kent Friis" <leeloo@phreaker.net> wrote:

[8<8<8<]
> Fordelen er at da jeg selv definerer struct vtable, kan jeg putte alle
> de ting derover, som jeg har lyst til. Det kan man ikke i C++, der må
> man følge sprogets begrænsninger.

Du må altså have mig undskyldt - jeg har svært ved at følge dig.
I hvilket programmeringssprog skal man ikke følge dets begrænsninger ?
Hvilken struct er det du kan skrive i C men ikke i C++ ?

[8<8<8<]
> Det er jeg sg*
> udemærket klar over, men alligevel bliver folk ved med at spørge
> hvorfor jeg ikke bruger C++,

Jeg er naturligvis personligt ligeglad med hvad du bruger.
Så længe du har det godt med det, og så længe programmerne ikke har mulighed
for at påvirke min hverdag i negativ retning.

> og så nævner jeg nogen af grundene.

Og gør dermed argumenterne til genstand for offentlig diskution.

Venlig hilsen

Mogens Hansen

---

Den Fri, 6 Feb 2004 22:02:33 +0100 skrev Mogens Hansen:
>
>"Kent Friis" <leeloo@phreaker.net> wrote:
>
>[8<8<8<]
>> Fordelen er at da jeg selv definerer struct vtable, kan jeg putte alle
>> de ting derover, som jeg har lyst til. Det kan man ikke i C++, der må
>> man følge sprogets begrænsninger.
>
>Du må altså have mig undskyldt - jeg har svært ved at følge dig.
>I hvilket programmeringssprog skal man ikke følge dets begrænsninger ?

Hvis man vælger sprog efter opgaven.

>Hvilken struct er det du kan skrive i C men ikke i C++ ?

Hvad var det fordelen var ved C++, når man begynder at bruge structs
i stedet for klasser?

>[8<8<8<]
>> Det er jeg sg*
>> udemærket klar over, men alligevel bliver folk ved med at spørge
>> hvorfor jeg ikke bruger C++,
>
>Jeg er naturligvis personligt ligeglad med hvad du bruger.
>Så længe du har det godt med det, og så længe programmerne ikke har mulighed
>for at påvirke min hverdag i negativ retning.

Hvis endelig jeg lavede programmer der havde mulighed for at påvirke
din hverdag, ville de påvirke den meget mere i negativ retning hvis
jeg skulle bruge C++. Fordi at C++ ikke lige er min kop te, og derfor
ville jeg ikke tage opgaven alvorligt.

>> og så nævner jeg nogen af grundene.
>
>Og gør dermed argumenterne til genstand for offentlig diskution.

Hvis I ikke vil vide dem, så lad være med at spørge.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Kent Friis" <leeloo@phreaker.net> wrote:
> Den Fri, 6 Feb 2004 22:02:33 +0100 skrev Mogens Hansen:
> >
> >"Kent Friis" <leeloo@phreaker.net> wrote:
> >
> >[8<8<8<]
> >> Fordelen er at da jeg selv definerer struct vtable, kan jeg putte alle
> >> de ting derover, som jeg har lyst til. Det kan man ikke i C++, der må
> >> man følge sprogets begrænsninger.
> >
> >Du må altså have mig undskyldt - jeg har svært ved at følge dig.
> >I hvilket programmeringssprog skal man ikke følge dets begrænsninger ?
>
> Hvis man vælger sprog efter opgaven.

Man er _altid_ man underlagt det valgte sprogs begrænsninger - uanset
opgaven.

De begrænsninger du syntes at henvise til i C++ findes _ikke_.

>
> >Hvilken struct er det du kan skrive i C men ikke i C++ ?
>
> Hvad var det fordelen var ved C++, når man begynder at bruge structs
> i stedet for klasser?

Mit spørgsmål om hvilke struct man kan skrive i C men ikke i C++, var ikke
starten på en diskution om hvad der er det bedste design ud fra et eller
andet kriterium.
Det var en reaktion på dit absolutte udsagn "Det kan man ikke i C++", som er
ubetinget forkert.

Iøvrigt:
I C++ er struct og klasser _eksakt_ det samme, bortset fra default access
niveau.
En struct kan sagtens have constructor/destructor, virtuelle metoder, arve
fra noget andet ect.
Så skelnen er ikke væsentlig.

Hvis man har brug for struct uden arv, virtuelle metoder etc. er der absolut
ingen problemer med det i C++.
Det har endda et selvstændigt navn: POD (Plain Old Data), som har garanteret
særlige egenskaber for at sikre at det opfører sig som en struct i C.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
>>Den Fri, 6 Feb 2004 22:02:33 +0100 skrev Mogens Hansen:
>
>>>Hvilken struct er det du kan skrive i C men ikke i C++ ?

Så vidt jeg ved: structs hvis sidste medlem er et array uden
størrelsesangivelse som for eksempel:

struct s
{
int n;
double d[];
};

> Hvis man har brug for struct uden arv, virtuelle metoder etc. er der absolut
> ingen problemer med det i C++.
> Det har endda et selvstændigt navn: POD (Plain Old Data), som har garanteret
> særlige egenskaber for at sikre at det opfører sig som en struct i C.

Hvad er det for særlige egenskaber du tænker på? De eneste "særlige"
ting ved structs i C som jeg kan komme på, er at struct'ens adresse
efter typekonvertering skal være identisk med det første medlems adresse
og omvendt, og at et medlem som er erklæret før et andet medlem, skal
have en lavere adresse end det andet medlem.

---

"Byrial Jensen" <bjensen@nospam.dk> wrote in message
news:4024B101.5090200@nospam.dk...
> Mogens Hansen wrote:
> >>Den Fri, 6 Feb 2004 22:02:33 +0100 skrev Mogens Hansen:
> >
> >>>Hvilken struct er det du kan skrive i C men ikke i C++ ?
>
> Så vidt jeg ved: structs hvis sidste medlem er et array uden
> størrelsesangivelse som for eksempel:
>
> struct s
> {
> int n;
> double d[];
> };

Det er vist rigtigt - fordi "d" er en incomplete type.

Man kan nemt (og efter min mening sikrere) lavet det (stort set) tilsvarende
med

struct s
{
int n;
vector<double> d;
};

[8<8<8<]
> Hvad er det for særlige egenskaber du tænker på?

[8<8<8<]
> ...og at et medlem som er erklæret før et andet medlem, skal
> have en lavere adresse end det andet medlem.

Det var netop det jeg tænkte på og at medlemmerne skal ligge i
sammenhængende hukommelse.

Forholdet mellem rækkenfølgen medlemmer er erklæret og adresserne gælder
ikke hen over access specifier i C++.

Garantien om sammenhængende hukommelse kan ikke opretholdes i forbindelse
med multiple, virtuel arv.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> "Byrial Jensen" <bjensen@nospam.dk> wrote in message

>>Hvad er det for særlige egenskaber du tænker på?
>
>>...og at et medlem som er erklæret før et andet medlem, skal
>>have en lavere adresse end det andet medlem.
>
> Det var netop det jeg tænkte på og at medlemmerne skal ligge i
> sammenhængende hukommelse.

Hvad med C's garanti for at en structs første element har samme adresse
som struct'en selv. Gælder den i C++?

I C en den garanti for eksempel praktisk når man sorterer en array af
struct med qsort() hvis man kan placere sorteringsnøglen som første
element i struct'en.

---

"Byrial Jensen" <bjensen@nospam.dk> wrote:

[8<8<8<]
> Hvad med C's garanti for at en structs første element har samme adresse
> som struct'en selv. Gælder den i C++?

Ja, det gælder også i C++ for POD typer.
§9.2-17 i C++ Standarden siger:
A pointer to a POD-struct object, suitably converted using a
reinterpret_cast, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides) and vice versa.

For ikke POD typer ved man det ikke.
Det er f.eks. implementeringsspecifikt om pointeren til den virtuelle
funktions tabel (vptr - hvis typen har virtuelle metoder, og det er
implementeret med en typisk vtable) ligger i starten eller slutningen af
strukturen.

Venlig hilsen

Mogens Hansen

---

Kent Friis wrote:
> Det mest utrolige er at der ikke er nogen Java-folk der har blandet
> sig...

Der er vel ikke så mange af dem i d.e.p.c ...

---

Den Sat, 07 Feb 2004 01:07:34 +0100 skrev Byrial Jensen:
>Kent Friis wrote:
>> Det mest utrolige er at der ikke er nogen Java-folk der har blandet
>> sig...
>
>Der er vel ikke så mange af dem i d.e.p.c ...

Det var der sidst jeg kaldte deres "referencer" for pointere med
et andet navn.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

In article <c01efn$bsn$1@sunsite.dk>, Kent Friis wrote:

> Det var der sidst jeg kaldte deres "referencer" for pointere med
> et andet navn.

Det er da ogsaa synd at sige at referencer og pointere er det samme.
Der er semantiske forskelle paa de to. Naar det er sagt, saa er pointere
et superset af referencer.

Jeg ville foretraekke at de 2 begreber holdes adskilt fra hinanden, men
jeg kan godt forstaa din generalisering.


--
j.

---

Den Sat, 7 Feb 2004 17:29:46 +0100 skrev Jesper Louis Andersen:
>In article <c01efn$bsn$1@sunsite.dk>, Kent Friis wrote:
>
>> Det var der sidst jeg kaldte deres "referencer" for pointere med
>> et andet navn.
>
>Det er da ogsaa synd at sige at referencer og pointere er det samme.
>Der er semantiske forskelle paa de to. Naar det er sagt, saa er pointere
>et superset af referencer.

Når man har lært C++, og skal forstå Javas referencer, så er det
helt klart en fordel at se dem som pointere med et andet navn, fremfor
at tro at der er tale om det der i C++ hedder referencer.

Ellers står man komplet uforstående overfor NullReferenceException,
når man ved at en reference[1] altid peger på et gyldigt objekt.

Mvh
Kent

[1] altså det der i C++ hedder referencer.
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

> Når man har lært C++, og skal forstå Javas referencer, så er det
> helt klart en fordel at se dem som pointere med et andet navn, fremfor
> at tro at der er tale om det der i C++ hedder referencer.
>
> Ellers står man komplet uforstående overfor NullReferenceException,
> når man ved at en reference[1] altid peger på et gyldigt objekt.
>
> Mvh
> Kent
>
> [1] altså det der i C++ hedder referencer.

Med fare for at blive bidt i næsen ;) Er det dybest set ikke C++ der
er gal på den?
Der er (i denne sammenhæng) tre slags data:
1) en pointer (void* object)
2) en anden slags pointer (Object* object)
3) en ikke-pointer (Object object)

C/C++ skelner, som _ikke_ type-sikre sprog ikke imellem 1) og 2). Det
gør derimod f.eks. Delphi (og sikkert også Java men min Java viden er
ikke så stor; jeg droppede det efter tyvende forgæves forsøg på at
definere en global konstant).

Nu er jeg ikke den mest lærde person, men burde navnene ikke være
1) pointer
2) reference
3) instance
?

---

In article <d96764ff.0402082345.7e412445@posting.google.com>,
Nicolai Hansen wrote:

> Med fare for at blive bidt i næsen ;) Er det dybest set ikke C++ der
> er gal på den?

Det, der adskiller pointerne/referencenerne/whatever fra hinanden er
hvilke operationer du kan lave paa dem. Nogen gange tillades
pointeraritmetik, andre gange har man en not-null invariant. Det er
lidt op og ned alt efter sprog.


--
j.

---

> class enemy {
> virtual const int attack = 0;
> }
>
> class fighter : enemy {
> virtual const int attack = 7;
> }
>
> int main() {
> enemy * attacker = new fighter;
>    
>    player.health -= enemy->attack;
> }

Klares dette ikke med noget static?
Er ikke helt 100% på syntaxen så jeg vil ikke skrive et eksempel.

---

Den 5 Feb 2004 23:58:37 -0800 skrev Nicolai Hansen:
>> class enemy {
>> virtual const int attack = 0;
>> }
>>
>> class fighter : enemy {
>> virtual const int attack = 7;
>> }
>>
>> int main() {
>> enemy * attacker = new fighter;
>>    
>>    player.health -= enemy->attack;
>> }
>
>Klares dette ikke med noget static?
>Er ikke helt 100% på syntaxen så jeg vil ikke skrive et eksempel.

Static kan mig bekendt ikke virtual'es.

Mvh
KEnt
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Anders J. Munch" <andersjm@dancontrol.dk> writes:

>>"Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
>> "Anders J. Munch" <andersjm@dancontrol.dk> writes:
>>
>> > Det eneste man behøver at få øje på er typeerklæringen, "void*".
>>
>> Den står et andet sted.
>
> Jeg har aldrig begået en typefejl fordi jeg ikke var klar over at en
> variabel eller parameter var af type void*. Derimod har jeg oplevet
> den tidligere beskrevne uerklæret-malloc fejl i kode skrevet til at
> oversætte som både C og C++.
>
> Måske er din erfaring anderledes.

Nej den kan sagtens være den samme som din, jeg bruger blot generelt
og specifikt omvendt:

Jeg har aldrig begået en uerklæret-malloc fejl i kode skrevet til at
oversætte som både C og C++. Derimod har jeg oplevet typefejl ved
brug af variable eller parametre der var af type void*.

Generelt gør jeg flittigt brug af compilernes advarselsflag, snarere
end at omskrive koden for at tvinge fejl frem. For eksempel skriver
jeg gladeligt

if (a == 1)

i stedet for

if (1 == a)

selvom kun sidstnævnte giver en fejl hvis man kommer til at skrive "="
i stedet for "==". Førstnævnte vil give en advarsel hvilket er godt
nok for mig. Tilsvarende compiler jeg med flag der advarer mod kald
af funktioner uden prototype, snarere end skrive koden så typeusikre
operationer ikke fremgår eksplicit.

---

> Et eksempel der (mig bekendt) ikke kan lade sig gøre i C++ er at
> erklære en const virtual, på samme måde som en metode.
>
> [...]
>
> Det har jeg prøvet. Den sammenblanding ødelægger begge dele.

Med respekt,
det forekommer mig at du søger argumenter for ikke at bruge c++. Hvis du
ikke bryder dig om sproget synes jeg ikke at du skal tvinge dig selv til at
bruge det. Jeg pointerede blot at du kan opnå (i hvert fald) det, du spurgte
om ved blot at rename din source fil til .cpp og skrive "class" hist og her.
Korrekt, c og c++ er ikke 100% kompatible. Men det kan næppe udgøre så store
problemer at det bedre kan betale sig at skifte til et andet sprog. Og med
hensyn til virtuelle konstanter så er jeg ikke helt sikker på hvad en sådan
skulle kunne eller hvordan den skulle fungere. En væsentlig del af
indkapsling er at man laver accessor metoder til at tilgå sine fields og det
ville jeg også gøre med en konstant. Disse kan godt være virtuelle.

Kristian

---

Den Thu, 5 Feb 2004 09:24:20 +0100 skrev Kristian Dupont:
>> Et eksempel der (mig bekendt) ikke kan lade sig gøre i C++ er at
>> erklære en const virtual, på samme måde som en metode.
>>
>> [...]
>>
>> Det har jeg prøvet. Den sammenblanding ødelægger begge dele.
>
>Med respekt,
>det forekommer mig at du søger argumenter for ikke at bruge c++.

Nope, jeg har masser af argumenter for ikke at bruge C++. Ikke
argumenter der kan overbevise andre (for det ønsker jeg ikke), men
argumenter for at JEG ikke bruger det.

>Hvis du
>ikke bryder dig om sproget synes jeg ikke at du skal tvinge dig selv til at
>bruge det. Jeg pointerede blot at du kan opnå (i hvert fald) det, du spurgte
>om ved blot at rename din source fil til .cpp

Bland lige cpp (C pre-processor) uden om, tak.

>og skrive "class" hist og her.
>Korrekt, c og c++ er ikke 100% kompatible. Men det kan næppe udgøre så store
>problemer at det bedre kan betale sig at skifte til et andet sprog. Og med
>hensyn til virtuelle konstanter så er jeg ikke helt sikker på hvad en sådan
>skulle kunne eller hvordan den skulle fungere. En væsentlig del af
>indkapsling er at man laver accessor metoder til at tilgå sine fields og det
>ville jeg også gøre med en konstant. Disse kan godt være virtuelle.

Det ville jeg så til gengæld kalde at slå en skrue i med en hammer. Ikke
umuligt, men heller ikke den rigtige måde at gøre det på.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

"Anders J. Munch" <andersjm@dancontrol.dk> writes:

> Et brud på typesystemet er når den dynamiske type ikke er en delmængde
> af den statiske type. Det er der ikke tale om her.

Det kan der sagtens være. C's typesystem ved det ikke. Derfor bør
det fremgå eksplicit af koden.

> Det eneste man behøver at få øje på er typeerklæringen, "void*".

Den står et andet sted. I andre situationer behøver man ikke kigge på
typeerklæringen, compileren vil fange fejlen, med mindre man eksplicit
på stedet beder om andet. Den farlige implicite konvertering er en
anormalitet i sproget, og derfor en fejlkilde.

---

>"Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
> "Anders J. Munch" <andersjm@dancontrol.dk> writes:
>
> > Det eneste man behøver at få øje på er typeerklæringen, "void*".
>
> Den står et andet sted.

Jeg har aldrig begået en typefejl fordi jeg ikke var klar over at en
variabel eller parameter var af type void*. Derimod har jeg oplevet
den tidligere beskrevne uerklæret-malloc fejl i kode skrevet til at
oversætte som både C og C++.

Måske er din erfaring anderledes.

mvh. Anders
..

---

Kristian Dupont wrote:
>>Men C++ har også et par mangler i forhold til mine krav, så det ville
>>nærmere blive et af de rigtige(tm) OO-sprog, hvis jeg absolut skulle
>>skifte.
>
>
> Jeg forstår ikke din argumentation. Det, du forsøger at opnå kan tydeligvis
> klares let med c++. Dertil kommer at du _netop_ ikke behøver at "kassere" al
> din viden da du med meget få undtagelser kan skrive ren c-kode og blot bruge
> de nødvendige c++ overbygninger som eksempelvis klasser.
>

Det er efter min mening en dårlig idé at bilde folk ind at C++ blot er
en lille udvidelse til C, at man i C++ laver programmer som i C men
tilføjer et par klasser. "Desværre" ligner syntaxen i C++ meget den i C,
hvilket får nogen til at mene at de to sprog stort set er det samme,
hvor C++ blot kan lidt mere (klasser).

C og C++ er meget forskellige sprog, meget af den viden du har som C
programør er ubrugelig i C++. Hvis man vil blive en god C++ programør og
drage fordel af C++'s fordele skal man lære at programere i C++.

Jeg selv har programmeret i C i > 10 år, og føler mig stadig mest hjemme
i C, og foretrækker derfor C til mine egne små projekter. Jeg prøver at
lære C++ og er sikker på at jeg om nogle år vil have lært så meget at
jeg vil foretrække C++.

/b

---

> Det er efter min mening en dårlig idé at bilde folk ind at C++ blot er
> en lille udvidelse til C, at man i C++ laver programmer som i C men
> tilføjer et par klasser.

Også efter min.

> "Desværre" ligner syntaxen i C++ meget den i C,
> hvilket får nogen til at mene at de to sprog stort set er det samme,
> hvor C++ blot kan lidt mere (klasser).

Korrekt. Jeg har selv rodet med en masse kode der befinder sig på et
irriterende mellemstadie - c kode men med klasser. Rigtig mange synes for
eksempel at mene at templates er en helt speciel og avanceret feature i c++
som kun kan bruges til noget i helt utroligt specielle tilfælde.

> C og C++ er meget forskellige sprog, meget af den viden du har som C
> programør er ubrugelig i C++. Hvis man vil blive en god C++ programør og
> drage fordel af C++'s fordele skal man lære at programere i C++.

Jeg er helt enig. Grunden til at jeg skrev som jeg gjorde var at vedkommende
synes opsat på at opfinde den dybe tallerken selv - nemlig at lave et
klassesystem i c. Det er, mener jeg, ikke nødvendigt da man _kan_ opnå dette
ved blot at bruge den del af c++ og ellers skrive c kode.

> Jeg selv har programmeret i C i > 10 år, og føler mig stadig mest hjemme
> i C, og foretrækker derfor C til mine egne små projekter. Jeg prøver at
> lære C++ og er sikker på at jeg om nogle år vil have lært så meget at
> jeg vil foretrække C++.

Med en god bog behøver du ikke at bruge så længe :)

Kristian

---

Kristian Dupont wrote:
>
>>"Desværre" ligner syntaxen i C++ meget den i C,
>>hvilket får nogen til at mene at de to sprog stort set er det samme,
>>hvor C++ blot kan lidt mere (klasser).
>
>
> Korrekt. Jeg har selv rodet med en masse kode der befinder sig på et
> irriterende mellemstadie - c kode men med klasser. Rigtig mange synes for
> eksempel at mene at templates er en helt speciel og avanceret feature i c++
> som kun kan bruges til noget i helt utroligt specielle tilfælde.

Så lad være med at foreslå folk at putte lidt klasser ind i C.

>
>>C og C++ er meget forskellige sprog, meget af den viden du har som C
>>programør er ubrugelig i C++. Hvis man vil blive en god C++ programør og
>>drage fordel af C++'s fordele skal man lære at programere i C++.
>
>
> Jeg er helt enig. Grunden til at jeg skrev som jeg gjorde var at vedkommende
> synes opsat på at opfinde den dybe tallerken selv - nemlig at lave et
> klassesystem i c. Det er, mener jeg, ikke nødvendigt da man _kan_ opnå dette
> ved blot at bruge den del af c++ og ellers skrive c kode.

Her opfordrer du jo netop folk til at lave "kode der befinder sig på et
irriterende mellemstadie - c kode men med klasser".

>
>>Jeg selv har programmeret i C i > 10 år, og føler mig stadig mest hjemme
>>i C, og foretrækker derfor C til mine egne små projekter. Jeg prøver at
>>lære C++ og er sikker på at jeg om nogle år vil have lært så meget at
>>jeg vil foretrække C++.
>
>
> Med en god bog behøver du ikke at bruge så længe :)
>

Netop bøger fortæller en del om forskellen på C og C++; hvis du
spørger en C programør hvilken bog man bør læse for at lære C vil
han sansynlivis svare K&R II på 200 - 300 sider. En C++ programør
vil lave en liste med 4 -> 6 bøger på 1000 -> 1200 sider.


/b

---

"Bertel Brander" <bertel@post4.tele.dk> wrote:
> Kristian Dupont wrote:
> >
> >>"Desværre" ligner syntaxen i C++ meget den i C,
> >>hvilket får nogen til at mene at de to sprog stort set er det samme,
> >>hvor C++ blot kan lidt mere (klasser).
> >
> >
> > Korrekt. Jeg har selv rodet med en masse kode der befinder sig på et
> > irriterende mellemstadie - c kode men med klasser. Rigtig mange synes
for
> > eksempel at mene at templates er en helt speciel og avanceret feature i
c++
> > som kun kan bruges til noget i helt utroligt specielle tilfælde.
>
> Så lad være med at foreslå folk at putte lidt klasser ind i C.

Hvis man kan C i forvejen, og ønsker at lære C++ så er det vel vanskeligt at
undgå at overgangen bliver en løbende process, hvor man starter lidt
forsigtigt og forhåbenligt ender med noget man kan kalde moderne C++.

Hvis folk ikke kender C i forvejen, og ønsker at lære C++ så kan man ligeså
godt lære moderne C++ direkte.

Undervejs vil der for begge grupper gælde at man skal lære hvordan man
bruger de forskellige faciliteter hensigtsmæssigt, og at man i den process
sommetider kommer til at gå for langt (f.eks. klasse hierakier skal mindst
være 7 niveauer dybe, og helst bruge virtuel multiple arv eller alle
funktioner skal være virtuelle - bare for en sikkerheds skyld) og sommetider
for kort (vi gør sgu lige det datamedlem public).


[8<8<8<]
> > Med en god bog behøver du ikke at bruge så længe :)
> >
>
> Netop bøger fortæller en del om forskellen på C og C++; hvis du
> spørger en C programør hvilken bog man bør læse for at lære C vil
> han sansynlivis svare K&R II på 200 - 300 sider. En C++ programør
> vil lave en liste med 4 -> 6 bøger på 1000 -> 1200 sider.

Det er ikke blot et sprogspørgsmål.
En rimeligt komplet beskrivelse af sproget, som f.eks. C++ Standarden, siger
stort set intet om hvordan man bruger det hensigtsmæssigt, og det er
urimeligt at forvente at man selv kan udlede det.
Det er et spørgsmål om at opbygge viden om hvordan man designer systemer
hensigtsmæssigt med et givent værktøj.
At udvikle store systemer kræver stor viden - f.eks. mange bøger.

På trods af at Python af mange anses for et simpelt sprog, har jeg 4 bøger
på tilsammen over 2800 sider stående.
Men det er ikke sprogbeskrivelsen der fylder det meste.
Det er beskrivelsen af hvordan man løser almindeligt forekommende problemer
effektivt i Python - altså hvordan man tænker Pythonic.
Det er beskrivelsen af hvordan bruger konkrete biblioteker til GUI, Web,
database adgang etc.

Tilsvarende kan man sige om design patterns, som jeg har adskilligt 1000
sider stående om.
Dokumentationen til Microsoft .NET ønsker jeg ikke at tabe over tæerne.

Venlig hilsen

Mogens Hansen

---

"Anders J. Munch" <andersjm@dancontrol.dk> writes:

> Problemet - at en stærkt typet void* vil fremprovokere casts så
> nettoresultatet bliver reduceret typesikkerhed - gælder naturligvis
> også for C99, eksemplerne er bare lidt længere.

Det skal opvejes mod at brud på typesystemet bliver eksplicitte, og
derved både lettere at få øje på, og mere oplagte at prøve at undgå.

Det er selvfølgelig svært at bevise, men jeg vil tro at ANSI
kommiteens beslutning er skyld i flere fejl end den har elimineret.

Jeg vil personligt anbefale at man for læselighedens skyld altid gør
typebrud eksplicitte (med union eller cast), selv når sproget tillader
at de er implicitte. Jeg ved godt at det råd er mod konsensus i
comp.lang.c, men jeg tror det skyldes et ønske i den gruppe om at
distancere sig fra C++.

> Grunden til at stærkt typet void* i C++ ikke generer nogen, er at
> void* så sjældent bliver brugt i C++.

Også at C++ casts er mere specifikke. I almindelig C++ kode optræder
præcis samme[1] situation med downcasts:

Base* base = new Derived; // Upcast, implicit.
Derived* derived = static_cast<Derived*> (base); // Downcast, eksplicit.

Hvis "base" er en int eller en ureleateret pointertype vil anden linie
give en compile-time fejl. Der lukkes altså ikke op for andre
konverteringer, end den der i C ville være implicit.

Footnotes:
[1] Forstået som at void kan ses som en implicit superklasse
til alle andre typer.

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
> "Anders J. Munch" <andersjm@dancontrol.dk> writes:
>
> > Problemet - at en stærkt typet void* vil fremprovokere casts så
> > nettoresultatet bliver reduceret typesikkerhed - gælder naturligvis
> > også for C99, eksemplerne er bare lidt længere.
>
> Det skal opvejes mod at brud på typesystemet bliver eksplicitte, og
> derved både lettere at få øje på, og mere oplagte at prøve at undgå.

Et brud på typesystemet er når den dynamiske type ikke er en delmængde
af den statiske type. Det er der ikke tale om her. Manuelt
administreret typesikkerhed ville jeg snarere kalde det.

Det eneste man behøver at få øje på er typeerklæringen, "void*". Så
ved man i C at det automatiske typecheck er sat delvist ud af kraft
for den pågældende variabel. Da void* ikke kan bruges til andet, er
det let nok at lokalisere manuelt administreret typesikkerhed ved at
se efter anvendelser af den type.

>
> > Grunden til at stærkt typet void* i C++ ikke generer nogen, er at
> > void* så sjældent bliver brugt i C++.
>
> Også at C++ casts er mere specifikke. I almindelig C++ kode optræder
> præcis samme[1] situation med downcasts:

Sandt nok.

mvh. Anders

---

nic@aub.dk (Nicolai Hansen) writes:

> Der er (i denne sammenhæng) tre slags data:
> 1) en pointer (void* object)
> 2) en anden slags pointer (Object* object)
> 3) en ikke-pointer (Object object)
>
> C/C++ skelner, som _ikke_ type-sikre sprog ikke imellem 1) og 2).

C har et gabene typehul hvor void* (og kun void*) kan konverteres til
hvad som helst. Det har C++ ikke.

Hullet blev _indført_ af ANSI C kommiteen for at slippe for at skulle
caste resultatet af "malloc". På det tidspunkt havde C++ allerede
"new", og en mere seriøs holdning til statisk typecheck, så det blev
ikke importeret fra ANSI C.

Det er et af de få steder hvor ANSI C kommiteen gjorde sproget
ringere.

---

Per Abrahamsen wrote:
> nic@aub.dk (Nicolai Hansen) writes:
>
>
>>Der er (i denne sammenhæng) tre slags data:
>>1) en pointer (void* object)
>>2) en anden slags pointer (Object* object)
>>3) en ikke-pointer (Object object)
>>
>>C/C++ skelner, som _ikke_ type-sikre sprog ikke imellem 1) og 2).
>
>
> C har et gabene typehul hvor void* (og kun void*) kan konverteres til
> hvad som helst. Det har C++ ikke.
>
> Hullet blev _indført_ af ANSI C kommiteen for at slippe for at skulle
> caste resultatet af "malloc". På det tidspunkt havde C++ allerede
> "new", og en mere seriøs holdning til statisk typecheck, så det blev
> ikke importeret fra ANSI C.
>
> Det er et af de få steder hvor ANSI C kommiteen gjorde sproget
> ringere.

Så vidt jeg ved indførte man void * for at have en generisk type
som man kunne bruge i stedet for char * som man brugte i starten.
Om det er en forringelse er vel et spørgsmål om smag og behag,
jeg ville kalde det et fremskridt.

/b

---

"Per Abrahamsen" <abraham@dina.kvl.dk> skrev:
>
> C har et gabene typehul hvor void* (og kun void*) kan konverteres til
> hvad som helst. Det har C++ ikke.

Det er ikke altid det strammeste typesystem der giver de mest
typesikre programmer. Sammenlign
(1) struct S *s = malloc(sizeof(struct S));
med
(2) struct S *s = (struct S*) malloc(sizeof(struct S));

Hvis sproget tvinger programmøren til at skrive (2) i stedet for (1),
så forringes typesikkerheden. Som det ses fx hvis der ikke er nogen
prototype for malloc.

>
> Det er et af de få steder hvor ANSI C kommiteen gjorde sproget
> ringere.

Det kan så diskuteres.

mvh. Anders

---

Bertel Brander <bertel@post4.tele.dk> writes:

> Så vidt jeg ved indførte man void * for at have en generisk type
> som man kunne bruge i stedet for char * som man brugte i starten.

void* er et fremskridt, implicit konvertering af void* til alle andre
pointertyper er et tilbageskridt.

void* er ældre end ANSI C, om den stammer fra sene udgaver af pcc
eller blev importeret fra C++ ved jeg ikke.

---

"Anders J. Munch" <andersjm@inbound.dk> writes:

> "Per Abrahamsen" <abraham@dina.kvl.dk> skrev:
>>
>> C har et gabene typehul hvor void* (og kun void*) kan konverteres til
>> hvad som helst. Det har C++ ikke.
>
> Det er ikke altid det strammeste typesystem der giver de mest
> typesikre programmer. Sammenlign
> (1) struct S *s = malloc(sizeof(struct S));
> med
> (2) struct S *s = (struct S*) malloc(sizeof(struct S));
>
> Hvis sproget tvinger programmøren til at skrive (2) i stedet for (1),
> så forringes typesikkerheden. Som det ses fx hvis der ikke er nogen
> prototype for malloc.

Og "int" har en anden størrelse end pointere.

Er det stadig legalt at kalde uerklærede funktioner i C99?

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
>
> Er det stadig legalt at kalde uerklærede funktioner i C99?
>

Mjnej. Der skal en prototype til, men en fuld erklæring med
argumenttyper er ikke påkrævet.

- Anders

---

Anders J. Munch wrote:
> "Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
>
>>Er det stadig legalt at kalde uerklærede funktioner i C99?
>
> Mjnej.

Mhjo, se afsnit "6.5.2.2 Function calls".

Dette er et korrekt C99-program:

include <stdio.h>
int main ()
{
return fun (42);
}
int fun (int i)
{
printf ("%d\n", i);
return 0;
}

> Der skal en prototype til, men en fuld erklæring med
> argumenttyper er ikke påkrævet.

Øh, den forstod jeg ikke. En funktionsprototype er en fuld erklæring med
argumenttyper. Citat fra C99: "A function prototype is a declaration
of a function that declares the types of its parameters.".

---

"Byrial Jensen" <bjensen@nospam.dk> wrote:
> Anders J. Munch wrote:
> > Der skal en prototype til, men en fuld erklæring med
> > argumenttyper er ikke påkrævet.
>
> Øh, den forstod jeg ikke. En funktionsprototype er en fuld erklæring med
> argumenttyper. Citat fra C99: "A function prototype is a declaration
> of a function that declares the types of its parameters.".
>

Det lyder som om jeg har byttet om på ordene "prototype" og
"erklæring", beklager.

mvh. Anders

---

Per Abrahamsen wrote:
> Er det stadig legalt at kalde uerklærede funktioner i C99?

Ja.

---

"Anders J. Munch" <andersjm@dancontrol.dk> writes:

> "Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
>>
>> Er det stadig legalt at kalde uerklærede funktioner i C99?
>>
>
> Mjnej. Der skal en prototype til, men en fuld erklæring med
> argumenttyper er ikke påkrævet.

Så C99 ville fange fejlen i eksemplet.

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
>
> Så C99 ville fange fejlen i eksemplet.
>

Jeps. Synd at de folk der specificerede void* i C89 glemte at prøve
deres eksempler af på en C99 compiler ...

Problemet - at en stærkt typet void* vil fremprovokere casts så
nettoresultatet bliver reduceret typesikkerhed - gælder naturligvis
også for C99, eksemplerne er bare lidt længere.

Grunden til at stærkt typet void* i C++ ikke generer nogen, er at
void* så sjældent bliver brugt i C++.

mvh. Anders

---

leeloo@phreaker.net (Kent Friis) writes:

> Den Sat, 31 Jan 2004 15:18:34 +0100 skrev Nicolai Hansen:
>>> Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
>>> er nået til:
>>
>>Du kan ikke programmere objekt orienteret i C, kun i C++ :)
> [...]
>>Nej, men i C++ kunne du bruger klasser:
>
> Jeg tror du overså:
>
> Ps: Lad nu være med at komme med "Brug Ada/Eiffel/Lisp/$favoritsprog i
> stedet for".

Den feature du mangler er præcis den der ledte til at "C with Classes"
blev skabt. "C with Classes" blev senere omdøbt til C++. Men du kan
stadig bruge C++ som om det bare var "C med klasser", derfor er det et
mere oplagt valg end de anre sprog du nævner.

---

leeloo@phreaker.net (Kent Friis) writes:

> Der er mange der har forsøgt at overbevise mig om at objekt-orienteret
> programmering er smart, men hvis det betyder at man skal kassere sin
> compiler, sin viden, og al den kode man allerede har skrevet, så
> forsvinder det smarte sg* ret hurtigt.

En vigtig grund til at C++ er så udbredt er at man som C programmør
netop _ikke_ skal kassere sin viden og al den kode man allerede har
skrevet.

At bruge C++ som "et bedre C" er efter min mening helt fint.

At genopfinde C++ i C er derimod tåbeligt, efter min altid ydmyge
mening.

---

Den Wed, 04 Feb 2004 19:26:49 +0100 skrev Per Abrahamsen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Der er mange der har forsøgt at overbevise mig om at objekt-orienteret
>> programmering er smart, men hvis det betyder at man skal kassere sin
>> compiler, sin viden, og al den kode man allerede har skrevet, så
>> forsvinder det smarte sg* ret hurtigt.
>
>En vigtig grund til at C++ er så udbredt er at man som C programmør
>netop _ikke_ skal kassere sin viden og al den kode man allerede har
>skrevet.
>
>At bruge C++ som "et bedre C" er efter min mening helt fint.

Det var sådan jeg lærte det, og jeg har holdt mig fra C++ lige siden.

Indtil den dag jeg får tid og lyst til at lære rigtig C++, holder jeg
mig langt væk fra C++.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Bertel Brander <bertel@post4.tele.dk> writes:

> Jeg selv har programmeret i C i > 10 år, og føler mig stadig mest hjemme
> i C, og foretrækker derfor C til mine egne små projekter.

Men hvad er problemer med at bruge C++ til dine små C projekter?

Hvis du ikke lige har brug for C99 udvidelser (der ikke er i alle C
compilere, og er i nogen C++ compilere) kan en C++ compiler fint
bruges til at udvikle C kode i. Det har lidt bedre typecheck (intet
"(void*) til hvad som helst" typehul for eksempel), og du kan begynde
at bruge C++ features efterhånden som du lærer dem at kende, og støder
på problemer hvor de oplagt simplificerer koden.

C++ er et multi-paradigme sprog, der er intet krav om at man skal
skrive object orientered eller generisk. Det er værktøjer du kan
bruge hvis det er en fordel, eller lade være.

Kernighan og Ritchie brugte en C++ compiler til alle eksempler i anden
udgave af _The C Programming Language_, så det kan fint lade sig gøre.

---

Per Abrahamsen wrote:
> Bertel Brander <bertel@post4.tele.dk> writes:
>
>
>>Jeg selv har programmeret i C i > 10 år, og føler mig stadig mest hjemme
>>i C, og foretrækker derfor C til mine egne små projekter.
>
>
> Men hvad er problemer med at bruge C++ til dine små C projekter?
>

Problemet er at lave programmer i et sprog der hverken er C eller
C++, hvilket bliver noget rod.

Du starter med at putte en klasse ind, så finder du ud af at du
skal bruge new/delete i stedet for malloc/realloc/free, så bliver
du nødt til at lave dine fprintf's og fread om til << og >> for
at understøtte dine klasser, så skal du lige bruge en std::map
til erstatning for dit hjemmelavede træ, og så skal der lige
bruges et par templates og til slut ender du med noget rod.

Jeg har brugt C++ til nogle små projekter, som f.ex. min editor.

/b

---

"Bertel Brander" <bertel@post4.tele.dk> wrote:
> Per Abrahamsen wrote:
> > Bertel Brander <bertel@post4.tele.dk> writes:
> >
> >
> >>Jeg selv har programmeret i C i > 10 år, og føler mig stadig mest hjemme
> >>i C, og foretrækker derfor C til mine egne små projekter.
> >
> >
> > Men hvad er problemer med at bruge C++ til dine små C projekter?
> >
>
> Problemet er at lave programmer i et sprog der hverken er C eller
> C++, hvilket bliver noget rod.
>
> Du starter med at putte en klasse ind, så finder du ud af at du
> skal bruge new/delete i stedet for malloc/realloc/free,

Og ...
Er det underligt eller forkert ?

Senere finder man ud af at man slet ikke skal bruge new/delete så meget som
man troede

> så bliver
> du nødt til at lave dine fprintf's og fread om til << og >> for
> at understøtte dine klasser,

Hvordan fik du fprintf og fread til at understøtte dine strukturer der
skulle skrives og læses ?

> så skal du lige bruge en std::map

jep, og finder ud af at det er nemmere. Altså en forbedring.

> til erstatning for dit hjemmelavede træ, og så skal der lige
> bruges et par templates og til slut ender du med noget rod.

Dine hjemmelavede træer bliver vel ikke lige pludselig til noget rod af sig
selv ?
Det kan være at de startede med at være noget rod, men det er nok mere
sandsynligt at de forekommer at være noget rod fordi man opdager at det kan
gøres meget nemmere med std::map.

Generelt kan vel ikke undgå den situation, at man kommer tilbage til noget
kode andre (ikke en selv naturligvis ) har skrevet for 4 år siden og
kigger på det med den erfaring man har bygget op i mellemtiden, og syntes at
det kan gøres bedre, pænere, simplere.
Det er blot ikke et argument for ikke løbende at prøve at forbedre sig.

Venlig hilsen

Mogens Hansen

---

Bertel Brander <bertel@post4.tele.dk> writes:

> Du starter med at putte en klasse ind,

Fint nok.

> så finder du ud af at du
> skal bruge new/delete i stedet for malloc/realloc/free,

Hvisd du vil bruge C++ constructors of destructors. Ellers ikke. Du
kan sagtens fortsætte med at bruge C constructors og destructors som
du plejer, e.g.

Foo* foo_create ();
void foo_free (Foo* foo);

Men hvis du syntes din kode bliver kønnere af at skrive

Foo* foo = new Foo ();

i stedet for

Foo* foo = foo_create ();

kan du jo gøre det.


Hvis du slet ikke har brug for constructors og destructors fortsætte
du bare med at bruge malloc/free i rå form.

> så bliver du nødt til at lave dine fprintf's og fread om til << og
> >> for at understøtte dine klasser,

Næh, du kan fortsat bruge dine C funktion

void foo_print (Foo* foo);

til at skrive dine klasser ud som i C. Eller hvis de er simple

printf ("Hello %d %d world", foo->a, foo->b);

Skift kun til >> og << hvis det gør koden lettere at forstå.

> så skal du lige bruge en std::map til erstatning for dit
> hjemmelavede træ,

Hvorfor det, hvis dit hjemmelavede træ fungerer? Med mindre map
simplificerer din kode.

> og til slut ender du med noget rod.

Det kan jeg slet ikke se, så længe man sørger for at hver eneste
"transformation" gør koden simplere.

---

leeloo@phreaker.net (Kent Friis) writes:

> Hvad var det fordelen var ved C++, når man begynder at bruge structs
> i stedet for klasser?

As man i C++ alternativt kan stave "struct" som "class" hører nok til
de mindst væsentlige ændringer i forhold til C.

Men helt konkret så er der stadig den fordel at du får et elegant svar
på det spørgsmål der startede denne tråd:

struct Foo
{
int a;
int b;
};

struct Bar : public Foo
{
double x;
double y;
};

Bar bar;

bar.a = 1;
bax.x = 2.2;

Se nedarvning uden brug af "class". Og hvis du har lyst til at have
en "vtable" member af Foo med alt muligt i, kan du sagtens det.

Præcis som i C, bare med den feature du efterspurgte.

---

Kent Friis wrote:
> typedef struct baseclass {
> int x;
>    int y;
> } baseclass;
>
> typedef struct subclass {
> baseclass base;
>    int z;
> } subclass;
>
> subclass obj;
>
> herefter kan jeg tilgå indholdet med:
>
> obj.base.x=0;
> obj.base.y=0;
> obj.z=0;
>
> Men, kan jeg ændre koden på en måde, så jeg kan nøjes med obj.x=0;?

Hvad med sådan noget som det her?

typedef struct baseclass {
int x;
int y;
} baseclass;

typedef struct subclass {
baseclass base;
int &x = base.x;
int &y = base.y;
int z;
} subclass;


- nu er jeg ikke den store c-koder, men burde det ikke virke?


Med venlig hilsen,
\\Mikkel Gjoel

---

[ s971661@spammesillystudent.dtu.dk ]

[ ... ]

> - nu er jeg ikke den store c-koder, men burde det ikke virke?


Såsnart man får references i C





ivr
--
<html><form><input type crash></form></html>

---

Kent Friis wrote:

> Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
> er nået til:
>
> typedef struct baseclass {
> int x;
>    int y;
> } baseclass;
>
> typedef struct subclass {
> baseclass base;
>    int z;
> } subclass;
>
> subclass obj;
>
> herefter kan jeg tilgå indholdet med:
>
> obj.base.x=0;
> obj.base.y=0;
> obj.z=0;
>
> Men, kan jeg ændre koden på en måde, så jeg kan nøjes med obj.x=0;? Så
> jeg slipper af med ".base", for det ser ikke helt så smart ud... Det
> forekommer mig at jeg engang har set noget lignende vha en eller anden
> kombination af struct og union, men jeg kan ikke huske hvordan.
>

Jeg er bange for at der ikke rigtig findes en ordentlig
løsning i C.

Jeg kunne lige komme i tanke om:

#define BASE \
int x; \
int y;

typedef struct baseclass
{
BASE
}baseclass;

typedef struct subclass
{
BASE
int z;
}subclass;

Kønt er det vist ikke, men det burde virke.

/b

---

Den Sat, 31 Jan 2004 23:52:16 +0100 skrev Bertel Brander:
>Kent Friis wrote:
>
>> Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
>> er nået til:
>>
>> Men, kan jeg ændre koden på en måde, så jeg kan nøjes med obj.x=0;? Så
>> jeg slipper af med ".base", for det ser ikke helt så smart ud... Det
>> forekommer mig at jeg engang har set noget lignende vha en eller anden
>> kombination af struct og union, men jeg kan ikke huske hvordan.
>>
>
>Jeg er bange for at der ikke rigtig findes en ordentlig
>løsning i C.
>
>Jeg kunne lige komme i tanke om:
>
>#define BASE \
> int x; \
> int y;
>
>typedef struct baseclass
>{
> BASE
>}baseclass;
>
>typedef struct subclass
>{
> BASE
> int z;
>}subclass;
>
>Kønt er det vist ikke, men det burde virke.

Ikke kønnere end mit eget forsøg med at putte indholdet af struct'en
ind i en #include...

Man kan jo også bare cut'n'paste indholdet af baseclass over i
subclass, men det bliver også umuligt at vedligeholde.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

On Sat, 31 Jan 2004 12:32:55 +0000 (UTC), Kent Friis wrote:
>
> Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
> er nået til:
>
> typedef struct baseclass {
> int x;
>    int y;
> } baseclass;
>
> typedef struct subclass {
> baseclass base;
>    int z;
> } subclass;
>
> subclass obj;
>
> herefter kan jeg tilgå indholdet med:
>
> obj.base.x=0;
> obj.base.y=0;
> obj.z=0;
>
> Men, kan jeg ændre koden på en måde, så jeg kan nøjes med obj.x=0;? Så
> jeg slipper af med ".base", for det ser ikke helt så smart ud... Det
> forekommer mig at jeg engang har set noget lignende vha en eller anden
> kombination af struct og union, men jeg kan ikke huske hvordan.

Hvis navnene er mere sigende, saa kan du goere

typedef struct baseclass_ {
   int element1;
   int element2;
} baseclass;

typedef struct subclass_ {
   baseclass base;
   int element3;
} subclass;

#define element1 base.element1
#define element2 base.element2

subclass obj;

Og du kan nu tilgaa inholdet som

obj.element1 = 0;
obj.element2 = 0;
obj.element3 = 0;

--
Jesper Skriver, CCIE #5456, FreeBSD committer

---

Den 31 Jan 2004 23:02:21 GMT skrev Jesper Skriver:
>On Sat, 31 Jan 2004 12:32:55 +0000 (UTC), Kent Friis wrote:
>>
>> Jeg sidder og roder med lidt objekt-orienteret programmering i C, og
>> er nået til:
>>
>> typedef struct baseclass {
>> int x;
>>    int y;
>> } baseclass;
>>
>> typedef struct subclass {
>> baseclass base;
>>    int z;
>> } subclass;
>>
>> subclass obj;
>>
>> herefter kan jeg tilgå indholdet med:
>>
>> obj.base.x=0;
>> obj.base.y=0;
>> obj.z=0;
>>
>> Men, kan jeg ændre koden på en måde, så jeg kan nøjes med obj.x=0;? Så
>> jeg slipper af med ".base", for det ser ikke helt så smart ud... Det
>> forekommer mig at jeg engang har set noget lignende vha en eller anden
>> kombination af struct og union, men jeg kan ikke huske hvordan.
>
>Hvis navnene er mere sigende, saa kan du goere
>
>typedef struct baseclass_ {
>   int element1;
>   int element2;
>} baseclass;
>
>typedef struct subclass_ {
>   baseclass base;
>   int element3;
>} subclass;
>
>#define element1 base.element1
>#define element2 base.element2
>
>subclass obj;
>
>Og du kan nu tilgaa inholdet som
>
>obj.element1 = 0;
>obj.element2 = 0;
>obj.element3 = 0;

Ødelægger de defines det ikke for baseclass? Selvom eksemplet kun
indeholder et enkelt objekjt, vil et normalt program typisk indeholder
indtil flere objekter af hver klasse.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

In article <bvg79n$1l3$1@sunsite.dk>, Kent Friis wrote:

> Ps: Lad nu være med at komme med "Brug Ada/Eiffel/Lisp/$favoritsprog i
> stedet for".

Det du umiddelbart skal forvente er, at du ikke kan opnaa den samme
kodekompakthed og hastighed som et sprog der kender til subtyping og
ved hvordan det skal optimere paa det. Man kan dog vaere villig til at
tage den hastighedsnedsaettelse, hvis det loeser andre problemer.

Foerst skal du forstaa at begrebet OO er misbrugt. Se:

http://www.paulgraham.com/reesoo.html

Da du specifikt har valgt at kigge paa subtyping, saa kaster vi os
over det problem. Foerst skal du vaelge hvilken form for subtyping
du tillader. Enkel nedarvning? Multipel Nedarvning? og dernaest hvordan
metodekald udfoeres (Dynamisk som Java eller statisk som C++ (default)).

Multipel nedarvning er ondt, saa vi restringerer lige til enkel
nedarving. Vi ved nu at alle klasser har hoejest _en_ parent og vi
benaevner denne med _parent i klassen. Vi laver saa funktioner i stil
med:

void
setXFooBar(struct foobar *class, int x)
{
   class->x = x;
}

og hvis foobar ikke har y:

void
setYFooBar(struct foobar *class, int x)
{
   setYFooBarParent(class->_parent, y);
}

Det virker og det er statiske metodekald. Hvis vi skal have dynamiske
metodekald skal du have funktionspointerarrays til metoderne. Et array
per klasse. Og saa en pointer til funktionspointerarrayet.

struct foobar {
   fparray *fp; /* Set this to the fparray for class foobar */
   ... *_parent;
   ...
}

Funktionspointerarrayet skal udformes saaledes at der ikke kan vaere
overlap mellem forskellige funktioner og saadan at du ved at eksempel-
vist setX er kald nummer 5. Saa bliver det noget nasty noget i retning
af:

void
setX(void *class, int x)
{
   (class->fp[5])(class, x); /* Jeg glemmer altid hvordan man
               laver funktionskald via pointere
               i C. Jeg plejer at slaa det op
               og det her er nok ikke rigtigt
             */
}

Og der bliver en del ting at holde styr paa. Til gengaeld har du
en implementation der ligger ret taet op af hvordan man rent faktisk
laver de her ting. En NULL value i fp[5] kunne foere til en videre
indirektion op i hierakiet, men saa skal du have en OOcall() wrapper
ind i ovenstaaende. Det er muligt der findes et lettere trick, men
ovenstaaende vil virke.

Caveat'en er at man skal skrive _mange_ liniers kode for at faa det
hele til at virke. Dem havde man sparet i et sprog der havde indbygget
subtyping, men det er jo ikke scope for det her. Man kunne ogsaa have
den holdning at subtyping er noget arveligt lort der bare skal vaek
og den sidder undertegnede med.

Ovenstaaende er nok lidt rodet. Relevante kapitler i boeger om
compilerdesign og behandling af subtyping i sprog vil nok vaere
gode at kigge paa foerst.

Et andet alternativ er at se paa hvad de kaere Gnome-folk goer. De har
stort set en komplet implementation til deres desktop environment.

--
j.

---

Den Sun, 1 Feb 2004 04:06:26 +0100 skrev Jesper Louis Andersen:
>In article <bvg79n$1l3$1@sunsite.dk>, Kent Friis wrote:
>
>> Ps: Lad nu være med at komme med "Brug Ada/Eiffel/Lisp/$favoritsprog i
>> stedet for".
>
>Det du umiddelbart skal forvente er, at du ikke kan opnaa den samme
>kodekompakthed og hastighed som et sprog der kender til subtyping og
>ved hvordan det skal optimere paa det. Man kan dog vaere villig til at
>tage den hastighedsnedsaettelse, hvis det loeser andre problemer.
>
>Foerst skal du forstaa at begrebet OO er misbrugt. Se:
>
>http://www.paulgraham.com/reesoo.html

Ja, men fordelen her er at afhængig af ens synspunkt så opfylder C
enten ingen eller alle punkterne (på samme måde som assembler
nødvendigvis må opfylde alle punkterne, hvis det skal kunne lade sig
gøre at lave et OO-sprog der opfylder alle punkterne).

>Da du specifikt har valgt at kigge paa subtyping, saa kaster vi os
>over det problem. Foerst skal du vaelge hvilken form for subtyping
>du tillader. Enkel nedarvning? Multipel Nedarvning? og dernaest hvordan
>metodekald udfoeres (Dynamisk som Java eller statisk som C++ (default)).
>
>Multipel nedarvning er ondt, saa vi restringerer lige til enkel
>nedarving. Vi ved nu at alle klasser har hoejest _en_ parent og vi
>benaevner denne med _parent i klassen. Vi laver saa funktioner i stil
>med:

Multipel arv holder jeg mig fra, indtil videre. Det ser ret håbløst
ud uden compilerens hjælp, og selv Sun opgav det da de lavede Java...

>Det virker og det er statiske metodekald. Hvis vi skal have dynamiske
>metodekald skal du have funktionspointerarrays til metoderne. Et array
>per klasse. Og saa en pointer til funktionspointerarrayet.
>
>struct foobar {
>   fparray *fp; /* Set this to the fparray for class foobar */
>   ... *_parent;
>   ...
>}

Det er nemmere med en struct i stedet for et array.

>Og der bliver en del ting at holde styr paa. Til gengaeld har du
>en implementation der ligger ret taet op af hvordan man rent faktisk
>laver de her ting. En NULL value i fp[5] kunne foere til en videre
>indirektion op i hierakiet, men saa skal du have en OOcall() wrapper
>ind i ovenstaaende. Det er muligt der findes et lettere trick, men
>ovenstaaende vil virke.

Det er lettere at sørge for at vtable struct'en er udfyldt med
pointeren til base-class'ens funktion.

>Caveat'en er at man skal skrive _mange_ liniers kode for at faa det
>hele til at virke. Dem havde man sparet i et sprog der havde indbygget
>subtyping, men det er jo ikke scope for det her. Man kunne ogsaa have
>den holdning at subtyping er noget arveligt lort der bare skal vaek
>og den sidder undertegnede med.

Til et spil hvor man fx har mange forskellige monstre der opfører
sig forskelligt, er det IMHO en rar ting, at man bare kan kalde
monster->vtable.attack(), og så være ligeglad med hvilket monster
der er tale om.

>Et andet alternativ er at se paa hvad de kaere Gnome-folk goer. De har
>stort set en komplet implementation til deres desktop environment.

Jeg ved det, men spørgsmålet var egentlig ret simpelt for en der
har 100% styr på structs og unions (jeg har ikke selv helt styr på
unions), så hvis nogen her kan svare på det oprindelige, simple
spørgsmål, så er det en del nemmere end at skulle til at gennemrode
adskillige 1000 liniers gtk+ og gnome kode for at finde ud af hvordan
de gør. Og "Det kan man ikke, du bliver nødt til at have .base med" er
også et ok svar, forudsat at svareren ved at man ikke kan.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
> Jeg ved det, men spørgsmålet var egentlig ret simpelt for en der
> har 100% styr på structs og unions (jeg har ikke selv helt styr på
> unions),

Er der noget galt i at tænke på en union som en struct, hvor
kun et felt er i brug ad gangen?

--
Jens Axel Søgaard

---

Den Sun, 01 Feb 2004 13:42:12 +0100 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Jeg ved det, men spørgsmålet var egentlig ret simpelt for en der
>> har 100% styr på structs og unions (jeg har ikke selv helt styr på
>> unions),
>
>Er der noget galt i at tænke på en union som en struct, hvor
>kun et felt er i brug ad gangen?

Jeg ved godt hvordan man bruger dem, overordnet set, men det forekommer
mig at de kan noget fancy med "unnamed fields", som jeg ikke har styr
på.

(Hmm, google siger godt nok noget om at unnamed unions er en C++ ting).

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:

> Den Sun, 01 Feb 2004 13:42:12 +0100 skrev Jens Axel Søgaard:
>
>>Kent Friis wrote:
>>
>>>Jeg ved det, men spørgsmålet var egentlig ret simpelt for en der
>>>har 100% styr på structs og unions (jeg har ikke selv helt styr på
>>>unions),
>>
>>Er der noget galt i at tænke på en union som en struct, hvor
>>kun et felt er i brug ad gangen?
>
>
> Jeg ved godt hvordan man bruger dem, overordnet set, men det forekommer
> mig at de kan noget fancy med "unnamed fields", som jeg ikke har styr
> på.
>
Det jeg kender til unnamed fields er:

typedef struct foo
{
int x;
struct
{
int y;
double z;
};
}foo;

Jeg er ikke sikker på at alle kompilere understøtter det.
Det bliver mest brugt med en union, hvor x fortæller om
det er y eller z der er i brug. Men metoden kan (måske)
også bruges med struct.

/b

---

Den Sun, 01 Feb 2004 15:04:59 +0100 skrev Bertel Brander:
>Kent Friis wrote:
>
>> Den Sun, 01 Feb 2004 13:42:12 +0100 skrev Jens Axel Søgaard:
>>
>>>Kent Friis wrote:
>>>
>>>>Jeg ved det, men spørgsmålet var egentlig ret simpelt for en der
>>>>har 100% styr på structs og unions (jeg har ikke selv helt styr på
>>>>unions),
>>>
>>>Er der noget galt i at tænke på en union som en struct, hvor
>>>kun et felt er i brug ad gangen?
>>
>>
>> Jeg ved godt hvordan man bruger dem, overordnet set, men det forekommer
>> mig at de kan noget fancy med "unnamed fields", som jeg ikke har styr
>> på.
>>
>Det jeg kender til unnamed fields er:
>
>typedef struct foo
>{
> int x;
> struct
> {
> int y;
> double z;
> };
>}foo;

GCC giver:
oop.c:9: warning: unnamed struct/union that defines no instances

Men bort set fra det, så er det næsten det jeg er ude efter, jeg vil
bare bruge en eksisterende struct som unnamed, så jeg kan tilgå
foo.x og foo.y uden at det skal være foo.bar.y

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

>>Det jeg kender til unnamed fields er:
>>
>>typedef struct foo
>>{
>> int x;
>> struct
>> {
>> int y;
>> double z;
>> };
>>}foo;
>
>
> GCC giver:
> oop.c:9: warning: unnamed struct/union that defines no instances
>
> Men bort set fra det, så er det næsten det jeg er ude efter, jeg vil
> bare bruge en eksisterende struct som unnamed, så jeg kan tilgå
> foo.x og foo.y uden at det skal være foo.bar.y

Man kan desværre ikke bruge:

typedef struct base
{
int x;
int y;
}base;

typedef struct sub
{
base;
int z;
}sub;

Hvilket vist er det du er ude efter.

Så man er tilbage til #defines:

#define base \
struct \
{\
int x;\
int y;\
}

typedef struct sub
{
base;
int z;
}sub;

/b

---

Den Sun, 01 Feb 2004 17:40:14 +0100 skrev Bertel Brander:
>>>Det jeg kender til unnamed fields er:
>>>
>>>typedef struct foo
>>>{
>>> int x;
>>> struct
>>> {
>>> int y;
>>> double z;
>>> };
>>>}foo;
>>
>>
>> GCC giver:
>> oop.c:9: warning: unnamed struct/union that defines no instances
>>
>> Men bort set fra det, så er det næsten det jeg er ude efter, jeg vil
>> bare bruge en eksisterende struct som unnamed, så jeg kan tilgå
>> foo.x og foo.y uden at det skal være foo.bar.y
>
>Man kan desværre ikke bruge:
>
>typedef struct base
>{
> int x;
> int y;
>}base;
>
>typedef struct sub
>{
> base;
> int z;
>}sub;
>
>Hvilket vist er det du er ude efter.

Lige præcis, men jeg mente man kunne med en eller anden kombination
af structs og unions. Åbenbart ikke...

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
> Jeg ved godt hvordan man bruger dem, overordnet set, men det forekommer
> mig at de kan noget fancy med "unnamed fields", som jeg ikke har styr
> på.

Man kan have bitfelter uden navn i structs i C, men de kan ikke bruges
til noget - man kan ikke referere til dem når ikke har et navn - så dem
kommer du ikke langt med her.

> (Hmm, google siger godt nok noget om at unnamed unions er en C++ ting).

Det er noget andet end "unnamed bit field", og google har ret: De findes
ikke i C.