|
| C programmering Fra : Rasmus Ladekjær Pede~ |
Dato : 27-11-01 22:45 |
|
Hej.
Jeg vil gerne lære at programmere. Jeg kan lidt HTML og lide Visual Basic,
men jeg vill gerne lære at skrive et andet sprog, da jeg syntes det er noget
møg at Visual Basic kun kan bruges på Windiws Pc'er. Hvad kan i anbefale ?
C, C++, Java eller andet ?
| |
Jakob Møbjerg Nielse~ (28-11-2001)
| Kommentar Fra : Jakob Møbjerg Nielse~ |
Dato : 28-11-01 00:02 |
|
> Hvad kan i anbefale ?
> C, C++, Java eller andet ?
Det kommer helt an på hvad du vil lære. Hvis du vil lære principperne
ved objekt-orientering, så bør du starte med Java da det (stadig) er et
rent objektorienteret sprog.
Når du så har forstået hvad OO går ud på, kan du fx "avancere" til
C++. Der er ikke så langt da sprogene ligner hinanden en del (eller
rettere: syntakserne ligner hinanden).
Hvis du beslutter dig for at lære C++, så få for alt i verden fat i en
god bog der overhovedet ikke beskæftiger sig med C. Det forvirrer mere
end det gavner. Jeg blev introduceret til C++ gennem "Accelerated C++"
af Andrew Koenig og Barbara E. Moo ([ISBN] 0-201-70353-X). Det er en god
bog og jeg vil til hver en tid anbefale den til begyndere.
Ang. Java, så kan jeg ikke rigtigt anbefale nogen bøger, for mine
lærebøger var mildest talt elendige.
Men prøv at skrive lidt mere om hvad du kunne tænke dig at lave af
programmer. Det KAN jo være at OO slet ikke er noget for dig (selvom jeg
tvivler
--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"
| |
Jesper Louis Anderse~ (28-11-2001)
| Kommentar Fra : Jesper Louis Anderse~ |
Dato : 28-11-01 00:13 |
|
On Wed, 28 Nov 2001 00:02:06 +0100,
Jakob Møbjerg Nielsen <jakob@dataloger.dk> wrote:
>> Hvad kan i anbefale ?
>> C, C++, Java eller andet ?
>
> Det kommer helt an på hvad du vil lære. Hvis du vil lære principperne
> ved objekt-orientering, så bør du starte med Java da det (stadig) er et
> rent objektorienteret sprog.
Java har primitive typer. Det er ikke rent.
--
Jesper
| |
Jakob Møbjerg Nielse~ (28-11-2001)
| Kommentar Fra : Jakob Møbjerg Nielse~ |
Dato : 28-11-01 00:56 |
|
> Java har primitive typer. Det er ikke rent.
Nitpicker
--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"
| |
Bertel Lund Hansen (28-11-2001)
| Kommentar Fra : Bertel Lund Hansen |
Dato : 28-11-01 07:26 |
| | |
Jakob Møbjerg Nielse~ (28-11-2001)
| Kommentar Fra : Jakob Møbjerg Nielse~ |
Dato : 28-11-01 11:31 |
|
> Kender du et rent OO-sprog der er udbredt.
Smalltalk, Eiffel og Ruby.
--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"
| |
Mikkel Bjerg (28-11-2001)
| Kommentar Fra : Mikkel Bjerg |
Dato : 28-11-01 12:01 |
|
Jakob Møbjerg Nielsen wrote:
>
> > Kender du et rent OO-sprog der er udbredt.
>
> Smalltalk, Eiffel og Ruby.
>
Self
--
MVH
Mikkel Bjerg
| |
Bertel Lund Hansen (28-11-2001)
| Kommentar Fra : Bertel Lund Hansen |
Dato : 28-11-01 19:42 |
| | |
Jakob Møbjerg Nielse~ (28-11-2001)
| Kommentar Fra : Jakob Møbjerg Nielse~ |
Dato : 28-11-01 20:58 |
|
> Hvor udbredt er de?
Findes der et mål for det? Jeg ved i hvert fald at Smalltalk bruges en
del. Eiffel bruges også af nogle, men vist ikke af så mange som
Smalltalk. Eiffel er lidt specielt i og med at man skriver nogle pre- og
postconditions i koden. Det skulle dermed være lettere at undgå
dumhedsfejl (Design by Contract -
http://www.eiffel.com/doc/manuals/technology/contract/).
--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"
| |
Bertel Lund Hansen (28-11-2001)
| Kommentar Fra : Bertel Lund Hansen |
Dato : 28-11-01 22:01 |
|
Jakob Møbjerg Nielsen skrev:
>Ang. Java, så kan jeg ikke rigtigt anbefale nogen bøger, for mine
>lærebøger var mildest talt elendige.
"Java by Dissection", "Java, The Complete Reference" eller "Java,
How to Program" er gode på hver sin måde. Jeg kan fortælle
nærmere om dem hvis jeg bliver spurgt i Java-gruppen eller evt. i
en mail.
--
Bertel
http://lundhansen.dk/bertel/ FIDUSO: http://fiduso.dk/
| |
Thorbjørn Ravn Ander~ (28-11-2001)
| Kommentar Fra : Thorbjørn Ravn Ander~ |
Dato : 28-11-01 00:54 |
|
"Rasmus Ladekjær Pedersen" <ladekjaer@get2net.dk> writes:
> Hej.
>
> Jeg vil gerne lære at programmere. Jeg kan lidt HTML og lide Visual Basic,
> men jeg vill gerne lære at skrive et andet sprog, da jeg syntes det er noget
> møg at Visual Basic kun kan bruges på Windiws Pc'er. Hvad kan i anbefale ?
> C, C++, Java eller andet ?
Proev at kigge paa
http://www.tuxedo.org/~esr/faqs/hacker-howto.html#BASIC_SKILLS
Hans syn paa hvordan man kan laere sig at programmere, er ikke helt uefne.
--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"
http://bigfoot.com/~thunderbear
| |
Rasmus Ladekjær Pede~ (28-11-2001)
| Kommentar Fra : Rasmus Ladekjær Pede~ |
Dato : 28-11-01 22:35 |
|
Jeg er ikke helt med.
Hvad er objekt-orientering programmering, såden helt præsic?
mvh Rasmus.
| |
Jakob Møbjerg Nielse~ (29-11-2001)
| Kommentar Fra : Jakob Møbjerg Nielse~ |
Dato : 29-11-01 11:27 |
|
> Jeg er ikke helt med.
> Hvad er objekt-orientering programmering, såden helt præsic?
Det er at du har alt din kode samlet i objekter. Forestil dig at du vil
lave et fodbold program. Der har du fx et "hoved"-objekt, et hold-objekt
og et kamp-objekt.
Hold-objektet indeholder informationer om holdet, såsom navn, liga, og
hvad man ellers kan finde på (nu er jeg ikke den store fodbold fan .
Desuden indeholder hold-objektet en liste med kamp-objekter. Hver gang
en ny kamp er spillet, tilføjes et kamp-objekt til listen vha.
funktioner i hold-objektet.
Kamp-objektet indeholder data om en enkelt kamp, dvs. hvem der blev
spillet mod, resultatet og hvor der blev spillet. Den kan selvfølgelig
også indeholde noget om hvor mange tilskuereder var, vejret osv.
Da hold-objektet indeholder en masse kamp-objekter kan man nu finde en
masse ting; hvor mange folk har betalt for at se dem, hvor mange kampe
har de vundet/spillet, gennemsnitvejret, hvem de har spillet mest mod,
osv. Men vigtigst er det: Hoved-objektet der skal have disse oplysninger
kigger IKKE ind i kamplisten i hold-objektet. Hold-objektet skal derimod
have en masse funktioner der kan trække disse informationer ud, fx
getNumberOfMatches(), der returnerer antal spillede kampe.
http://www.holub.com/goodies/what_is_an_object.html
http://catalog.com/softinfo/objects.html
PS: I virkeligheden vil man nok smide hold og kampinformationer i en
database, men metoden her med objekter fungerer fint.
--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"
| |
Bertel Lund Hansen (29-11-2001)
| Kommentar Fra : Bertel Lund Hansen |
Dato : 29-11-01 15:03 |
|
Jakob Møbjerg Nielsen skrev:
>Da hold-objektet indeholder en masse kamp-objekter kan man nu finde en
>masse ting;
Og den største fidus: Man koder en holdklasse én gang for alle.
Derefter opretter man nemt lige så mange forskellige objekter
deraf som man gider styre i sit program.
I sekventiel programmering kan man i nogen grad dele kode ved at
lave subrutiner, men så skal man vare sig for at det kun er det
rigtige holds variable der justeres.
--
Bertel
http://lundhansen.dk/bertel/ FIDUSO: http://fiduso.dk/
| |
Anders Melchiorsen (01-12-2001)
| Kommentar Fra : Anders Melchiorsen |
Dato : 01-12-01 13:26 |
|
Bertel Lund Hansen <nospam@lundhansen.dk> skrev den 29-Nov-01:
> I sekventiel programmering kan man i nogen grad dele kode ved at
> lave subrutiner, men så skal man vare sig for at det kun er det
> rigtige holds variable der justeres.
Det er vel bare at udvide alle funktioner med et "this" argument, som
peger på objektets hukommelsesstruktur, ganske som C++ compilere
typisk gør.
--
Regards, Anders
....if a Microsoft product fails, who do you sue?
| |
Thomas Lykkeberg (01-12-2001)
| Kommentar Fra : Thomas Lykkeberg |
Dato : 01-12-01 15:04 |
|
On Thu, 29 Nov 2001 11:27:25 +0100, "Jakob Møbjerg Nielsen"
<jakob@dataloger.dk> wrote:
>> Jeg er ikke helt med.
>> Hvad er objekt-orientering programmering, såden helt præsic?
>
>Det er at du har alt din kode samlet i objekter.
Ja, det er jo ulykkeligvis den gængse misforståelse af hvad objekt
orienteret programmering handler om. Man kan kort beskrive
objektorienteret programmering som nogle hoved punkter.
- Objekter
- Nedarving
- Polymorfi
Nedarving har du selv forklaret fint, men det er jo ikke det eneste,
og specielt ikke den stærke side af OOP. Polyformi som kort kan
betegnes som det at funktioner kan have forskellig virkning alt efter
hvilken situation de anvendes i. Selve det med at nedbryde ens program
i objekter bruges hele tiden i alm. C, blot på en lidt mere kompleks
måde end C++ tilbyder, nedarving kan også nemt implementeres i C, men
polymorfi derimod, det kan jeg ikke umiddelbart se at man nemt slipper
ud af.
/Thomas
| |
Mogens Hansen (01-12-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 01-12-01 16:15 |
|
"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
> måde end C++ tilbyder, nedarving kan også nemt implementeres i C, men
> polymorfi derimod, det kan jeg ikke umiddelbart se at man nemt slipper
> ud af.
Det kan man "sagtens".
Se f.eks. anvendelsen af Microsoft COM fra C.
Det er ikke direkte understøttet som et koncept i sproget.
Venlig hilsen
Mogens Hansen
| |
Thomas Lykkeberg (01-12-2001)
| Kommentar Fra : Thomas Lykkeberg |
Dato : 01-12-01 16:38 |
|
On Sat, 1 Dec 2001 16:15:17 +0100, "Mogens Hansen"
<mogens_h@dk-online.dk> wrote:
>Det kan man "sagtens".
>Se f.eks. anvendelsen af Microsoft COM fra C.
>Det er ikke direkte understøttet som et koncept i sproget.
Hvordan finder man run-time ud af hvilken type en funktion eksempelvis
bliver kaldt med?
/Thomas
| |
Mogens Hansen (01-12-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 01-12-01 17:15 |
|
"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
> Hvordan finder man run-time ud af hvilken type en funktion eksempelvis
> bliver kaldt med?
Generelt: alt hvad man kan i C++ kan man også i C og assembler. Der findes
C++ compilere der oversætter til C og C++ compilere der oversætter til
assembler.
Det er blot ikke lige så nemt og direkte som i C++.
Man kan gøre præcist som C++ compilere typisk gør (det er ikke testet og
compileret):
// class my_class
// {
// public:
// virtual void func1(void) = 0;
// virtual void func2(int arg1, float arg2);
// };
struct my_class;
typedef struct my_class_vtbl
{
// virtual void my_class::func1(void);
void (func1*)(my_class*);
// virtual int my_class::func2(int arg1, float arg2);
void (func2*)(my_class*, int, float);
};
typedef struct my_class
{
my_class_vtbl* vtbl;
} my_class;
// class my_derived1 : public my_class
// {
// public:
// my_derived(int i);
// virtual void func1(void);
// virtual void func2(int arg1, float arg2);
// int i;
// };
typedef struct my_derived1
{
my_class_vtbl* vtbl;
int i;
} my_derived1;
void my_derived1_func1(void);
void my_derived1_func2(int, float);
// my_derived1::my_derived(int i);
void my_derived1_constructor(my_derived* my_obj, int i)
{
my_obj->vtbl->func1 = my_derived_func1;
my_obj->vtbl->func2 = my_derived_func2;
my_obj->i = i;
}
void call_func1(my_class* my_obj)
{
// my_obj->func1();
my_obj->vtbl->func1(my_obj);
}
void call_func2(my_class* my_obj, int arg1, float arg2)
{
// my_obj->func2(arg1, arg2);
my_obj->vtbl->func2(my_obj, arg1, arg2);
}
void foo(void)
{
// my_derived1 md1(1);
my_derived1 md1;
my_derived1_constructor(&md1);
// md1.func1();
call_func1(&md1);
}
Se bogen
Inside the C++ Object Model
Stanley B. Lippman
ISBN: 0-201-83454-5
for en glimrende beskrivelse af dette og meget mere tilsvarende.
Venlig hilsen
Mogens Hansen
| |
Soeren Sandmann (01-12-2001)
| Kommentar Fra : Soeren Sandmann |
Dato : 01-12-01 18:04 |
|
"Mogens Hansen" <mogens_h@dk-online.dk> writes:
> // my_derived1::my_derived(int i);
> void my_derived1_constructor(my_derived* my_obj, int i)
> {
> my_obj->vtbl->func1 = my_derived_func1;
> my_obj->vtbl->func2 = my_derived_func2;
> my_obj->i = i;
> }
Det er lidt ironisk at det (i hvert fald på linux) giver væsentligt
kortere opstartstid at implementere virtuelle funktioner på den
måde. Problemet er at g++ genererer hvad der svarer til:
typedef struct vtbl {
const void (* f1) ( ... );
...;
} vtbl;
vtbl my_vtable = { my_f1, ... };
og det betyder at alle funktionspointerne giver anledning til en
relokering på opstartstidspunktet hvis klassen ligger i et dynamisk
bibliotek. Relokeringer kan komme til at dominere opstartstiden hvis
biblioteket indeholder mange klasser, sådan som QT og KDE gør det.
Med eksplicitte initialiseringer af funktionspointerne kan
relokeringen udskydes til der rent faktisk er brug for klassen,
hvilket ofte vil sige "aldrig".
| |
Mogens Hansen (01-12-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 01-12-01 18:23 |
|
"Soeren Sandmann" <sandmann@daimi.au.dk> wrote in message
news:ye8d71yrhxb.fsf@alex.daimi.au.dk...
> Det er lidt ironisk at det (i hvert fald på linux) giver væsentligt
> kortere opstartstid at implementere virtuelle funktioner på den
> måde. Problemet er at g++ genererer hvad der svarer til:
>
> typedef struct vtbl {
> const void (* f1) ( ... );
> ...;
> } vtbl;
>
> vtbl my_vtable = { my_f1, ... };
Det er den typiske implementering i de fleste compilere vil jeg mene.
>
> Med eksplicitte initialiseringer af funktionspointerne kan
> relokeringen udskydes til der rent faktisk er brug for klassen,
> hvilket ofte vil sige "aldrig".
Jeps. Specielt i forbindelse med dynamiske libraries med generelle
biblioteker som MFC og formodentlig Qt.
Og sammenhold det med at der ofte ikke er behov for at virtuelle metoder, så
er det rigtigt sjovt.
Ofte er det man har brug for "compile-time polymorphy" (f.eks. implementeret
med templates) i modsætning til "run-time polymorphy" (f.eks. implementeret
med virtuelle metoder).
Virtuelle metoder er rigtigt gode, når man har _brug_ for dem.
Men jeg ser at de anvendes mere end hvad der er behov for.
Venlig hilsen
Mogens Hansen
| |
Mogens Hansen (01-12-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 01-12-01 16:15 |
|
"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
> måde end C++ tilbyder, nedarving kan også nemt implementeres i C, men
> polymorfi derimod, det kan jeg ikke umiddelbart se at man nemt slipper
> ud af.
Det kan man "sagtens".
Se f.eks. anvendelsen af Microsoft COM fra C.
Det er ikke direkte understøttet som et koncept i sproget.
Venlig hilsen
Mogens Hansen
| |
Jakob Møbjerg Nielse~ (02-12-2001)
| Kommentar Fra : Jakob Møbjerg Nielse~ |
Dato : 02-12-01 05:39 |
|
> Ja, det er jo ulykkeligvis den gængse misforståelse af hvad objekt
> orienteret programmering handler om.
?? Gider du at forklare dig?
> Nedarving har du selv forklaret fint
Nope, det har jeg faktisk ikke rørt ved. Men det kan hurtigt fikses ved
at fjerne sig fra fodbolden og bruge det det sportsgrene med to hold.
Der kunne så være et ishockey objekt, et curling! objekt go et fedbold
objekt der hver især nedarver fra det generelle holdobjekt.
> men polymorfi derimod, det kan jeg ikke umiddelbart se at man nemt
> slipper ud af.
Det klares ved virtual funktionernes dynamic binding egenskaber; man kan
kalde en virtual funktion gennem en pointer og dermed har du dit
polymorfiske kald. Men det har Mogens forklaret meget bedre end jeg kan.
Især på det her tidspunkt
--
Jakob Møbjerg Nielsen
jakob@dataloger.dk
"Hey! He reminds me of someone who looks just like him. - Me"
| |
|
|