|
|
 | Programmerings sprog
Fra : Anders Lund |
Dato : 31-08-02 19:44 |
|
Jeg kan allerede >lidt< java og c++, men ikke nok til at begå mig
ordentligt. Jeg kan flyende vbscript. Så jeg mangler lidt et sprog til at
lave små opgaver på min linux server, derfor overvejer jeg at lære mig selv
perl. Men er det det bedste valg, eller findes der noget bedre?
--
Mvh
Anders Lund
Anders@zaimGED.dk
Fjern geden fra min signatur!
| |
 Claus Rasmussen (31-08-2002)
| Kommentar
Fra : Claus Rasmussen |
Dato : 31-08-02 19:53 |
|
Anders Lund wrote:
> Jeg kan allerede >lidt< java og c++, men ikke nok til at begå mig
> ordentligt. Jeg kan flyende vbscript. Så jeg mangler lidt et sprog til at
> lave små opgaver på min linux server, derfor overvejer jeg at lære mig
> selv perl. Men er det det bedste valg, eller findes der noget bedre?
Nja. Alle sprog har hver deres fordele, så der er ikke noget sprog, der
er bedre end andre. Men du har noget at vælge i mellem:
bash
perl
python
ruby (nok ikke for begyndere)
Bash er lidt undervurderet som programmeringssprog, men jeg bruger det
oftest (og skifter så til perl, når det bliver for langhåret). bash har
dog den ulempe, at det kræver en hel del tid, at lære alle tricksene at
kende. Der er lidt introduktion til bash på SSLUGs sider, men ellers er
det småt med begyndervejledninger.
perl kender du.
Python er et "pænere" alternativ til perl, men er ikke så forfærdeligt
udbredt. Til gengæld er der en super god introduktion til python på
dens hjemmeside.
Ruby er et "rigtigt" objektorienteret sprog med en lidt besynderlig
syntax (det er en japaner, der har lavet det  , men der er ikke så
mange, der bruger det.
Hvis du vil have en anbefaling, så vælg perl. Det kan du bruge en masse
steder.
-Claus
| |
Povl H. Pedersen (31-08-2002)
| Kommentar
Fra : Povl H. Pedersen |
Dato : 31-08-02 19:54 |
|
On Sat, 31 Aug 2002 20:43:47 +0200,
Anders Lund <Anders@zaimGED.dk> wrote:
> Jeg kan allerede >lidt< java og c++, men ikke nok til at begå mig
> ordentligt. Jeg kan flyende vbscript. Så jeg mangler lidt et sprog til at
> lave små opgaver på min linux server, derfor overvejer jeg at lære mig selv
> perl. Men er det det bedste valg, eller findes der noget bedre?
Perl er godt. Men Python skulle ifølge mange være bedre.
Men når du først kan programmere er det ikke svært at
skifte sprog.
| |
Peter Mogensen (31-08-2002)
| Kommentar
Fra : Peter Mogensen |
Dato : 31-08-02 20:29 |
|
Anders Lund wrote:
> Jeg kan allerede >lidt< java og c++, men ikke nok til at begå mig
> ordentligt. Jeg kan flyende vbscript. Så jeg mangler lidt et sprog til at
> lave små opgaver på min linux server, derfor overvejer jeg at lære mig selv
> perl. Men er det det bedste valg, eller findes der noget bedre?
Der er ihvertfald nogle alternativer.
Perl: IMHO Genialt sprog. både til systemadministration, web og små
applikationer.
Python: Mere elegant og OO end Perl, men Perl føles bedre til lige at
strikke noget effektivt sammen.
PHP: Nemmere at lære hvis man kan C end Perl og Python. Selvom det er
beregnet til at være inline i (f.eks.) HTML-filer kan man sagtens lave
scripts og programmer i det. Jeg foretrækker nu Perl.
Tcl: Noget specielt sprog, men ofte brugt da det virker godt sammen med
Tk GUI toolkittet.
LISP/SCHEME: Der sker en del udvikling i guile fortiden i bl.a. Gnome
projektet.Nogen sværger til Emacs LISP (elisp) og angiveligt skulle man
kunne alt hvad man kan i Perl i elisp. (hvilket jeg gerne tror på, men
et reg-exp i elisp er mere indviklet ind i Perl, så ...nej :)
BASH: Var der en der sagde. Jo, man kan bruge det, men det er
langsommere (skal ofte starte andre programmer), mere usikkert og
error-prone.
Haskel: Nåerh nej.. Prolog ? 
| |
Bo Lorentsen (31-08-2002)
| Kommentar
Fra : Bo Lorentsen |
Dato : 31-08-02 22:44 |
|
In <3D711915.4070502@nospam.no>, Peter Mogensen wrote:
> Python: Mere elegant og OO end Perl, men Perl føles bedre til lige at
> strikke noget effektivt sammen.
Python er også lettere at læse når man kommer tilbage til koden et halvt
år efter for at rette dette eller hint
Som førstegangs sprog er Python en godt sprog der giver en lidt diciplin
uden at være for striks.
/BL
| |
 Peter Mogensen (31-08-2002)
| Kommentar
Fra : Peter Mogensen |
Dato : 31-08-02 23:01 |
|
Bo Lorentsen wrote:
> Python er også lettere at læse når man kommer tilbage til koden et halvt
> år efter for at rette dette eller hint
P.g.a. dens brug af indentering istedet for blokke/tuborg-klammer eller
lign. Det var bl.a. en af grundende til jeg mener pythin er mere elegant.
Det samme gælder for miranda vs. LISP.
> Som førstegangs sprog er Python en godt sprog der giver en lidt diciplin
> uden at være for striks.
Det er jeg skam helt enig i.
De har faktisk brugt python som indledende sprog på Odense Universitet
et par år (som erstatning fro Modula-2), men gik væk fra det bl.a.
p.g.a. at det er svært at lære folk algoritme kompleksitet med python da
dets datastrukturer ikke er simple arrays og pointere.
Peter
| |
Jens Kristian Soegaa~ (01-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 01-09-02 00:07 |
|
Peter Mogensen <apm-at-mutex-dot-dk@nospam.no> writes:
> P.g.a. dens brug af indentering istedet for blokke/tuborg-klammer
*brrrrrr*
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Jens Axel Søgaard (01-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 01-09-02 00:16 |
|
"Jens Kristian Soegaard" <jk@soegaard.net> skrev i en meddelelse news:znv28w6a.fsf@tdc.qwer.dk...
> Peter Mogensen <apm-at-mutex-dot-dk@nospam.no> writes:
>
> > P.g.a. dens brug af indentering istedet for blokke/tuborg-klammer
>
> *brrrrrr*
Har du prøvet at bruge det en hel dag?
Efter sigende vænner man sig til det lynhurtigt,
så længe man har en god editor.
--
Jens Axel Søgaard
| |
Klaus Alexander Seis~ (01-09-2002)
| Kommentar
Fra : Klaus Alexander Seis~ |
Dato : 01-09-02 06:04 |
|
Jens Axel Søgaard skrev:
>>> P.g.a. dens brug af indentering istedet for blokke/tuborg-
>>> klammer
>>
>> *brrrrrr*
>
> Har du prøvet at bruge det en hel dag?
> Efter sigende vænner man sig til det lynhurtigt, så længe man
> har en god editor.
Det gjorde jeg i hvert fald, selv om jeg var skeptisk inden jeg selv
fik prøvet. Nu synes jeg bare at indenteringen er med til at gøre
scriptene let læselige, og min editor sørger for at indentere når der
skal indenteres.
// Klaus
--
><> vandag, môre, altyd saam
| |
Lars Henriksen (01-09-2002)
| Kommentar
Fra : Lars Henriksen |
Dato : 01-09-02 02:37 |
|
Peter Mogensen wrote:
> Det er jeg skam helt enig i.
> De har faktisk brugt python som indledende sprog på Odense Universitet
> et par år (som erstatning fro Modula-2), men gik væk fra det bl.a.
> p.g.a. at det er svært at lære folk algoritme kompleksitet med python da
> dets datastrukturer ikke er simple arrays og pointere.
Ja, og nu er sproget Java?!?!. I kurser der omhandler kompleksitet og
algoritmer er koden ikke, (åbenbart!) så vigtig som induktive beviser.
lars
| |
Bo Lorentsen (04-09-2002)
| Kommentar
Fra : Bo Lorentsen |
Dato : 04-09-02 20:33 |
|
In <3D713C8B.3010004@nospam.no>, Peter Mogensen wrote:
> P.g.a. dens brug af indentering istedet for blokke/tuborg-klammer eller
> lign. Det var bl.a. en af grundende til jeg mener pythin er mere
> elegant. Det samme gælder for miranda vs. LISP.
> De har faktisk brugt python som indledende sprog på Odense Universitet
> et par år (som erstatning fro Modula-2), men gik væk fra det bl.a.
> p.g.a. at det er svært at lære folk algoritme kompleksitet med python da
> dets datastrukturer ikke er simple arrays og pointere.
Det er da et underligt argument ??? Jeg holder meget af både C og C++, men
jeg vil stadig mene at de ikke er gode til at træde barne sko I. Lige
netop algorithmer vil da være lægget i et sprog hvor man ikke skal tænke
maskin nært.
/BL
| |
Peter Mogensen (05-09-2002)
| Kommentar
Fra : Peter Mogensen |
Dato : 05-09-02 06:38 |
|
Bo Lorentsen wrote:
>>De har faktisk brugt python som indledende sprog på Odense Universitet
>>et par år (som erstatning fro Modula-2), men gik væk fra det bl.a.
>>p.g.a. at det er svært at lære folk algoritme kompleksitet med python da
>>dets datastrukturer ikke er simple arrays og pointere.
>
> Det er da et underligt argument ??? Jeg holder meget af både C og C++, men
> jeg vil stadig mene at de ikke er gode til at træde barne sko I. Lige
> netop algorithmer vil da være lægget i et sprog hvor man ikke skal tænke
> maskin nært.
Nej. Python er godt til at lære folk at programmere... også OO.
Men hvis du skal lære om data-strukturer og algoritme-kompleksitet, så
nytter det ikke noget at der nedenunder det du laver ligger helt andre
data-strukturer bestemt af runtime systemet.
Det er svært at måle kompleksiteten af en "insert" operation i et array,
hvis python alligevel implementerer det du laver i en linket liste.
Peter
| |
Bo Lorentsen (05-09-2002)
| Kommentar
Fra : Bo Lorentsen |
Dato : 05-09-02 21:25 |
|
In <3D76ED9A.5080304@nospam.not>, Peter Mogensen wrote:
> Nej. Python er godt til at lære folk at programmere... også OO. Men hvis
> du skal lære om data-strukturer og algoritme-kompleksitet, så nytter det
> ikke noget at der nedenunder det du laver ligger helt andre
> data-strukturer bestemt af runtime systemet. Det er svært at måle
> kompleksiteten af en "insert" operation i et array, hvis python
> alligevel implementerer det du laver i en linket liste.
Det er jeg med på, men hvis Java/.NET er alternertivet kan jeg ikke se at
det skulle være meget bedre, andet end at det er mere typesikkert
Det er min erfaring at pointere i et sprog kan tage temlig lang tid at
fatte, og det vil derfor være godt om man kunne bruge et sprog der ikke
udsatte en ny elev for disse, og hverken C eller C++ er særligt venlig på
dette område. Men er det maskin nære ting der skal læres, er C nok den
bedste portale assembler jeg kender
/BL
| |
Peter Mogensen (06-09-2002)
| Kommentar
Fra : Peter Mogensen |
Dato : 06-09-02 09:28 |
|
Bo Lorentsen wrote:
> Det er jeg med på, men hvis Java/.NET er alternertivet kan jeg ikke se at
> det skulle være meget bedre, andet end at det er mere typesikkert
Java har da pointere^H^H^H^H^H^H^Hreferencer ikk'?
Java har da arrays, ikk'?
Ganske vist mangler der pointer-aritmetik, men det er da et tåleligt
kompromis.
Personligt syntes jeg også de skulle have beholdt Modula-2 på OU^H^HSDU
- det er tilpas et facistisk sprog til at tampe ting ind i hovedet på 1.
semester studerende ... så ka' de lære det :)
Men kompromiset står mellem at have et godt pædagoisk sprog at lære folk
at programmere med (som python) og samtidig have et der kan bruges som
eksempel-sprog de det efterfølgende kursus om algoritmer og datastrukturer.
> Det er min erfaring at pointere i et sprog kan tage temlig lang tid at
> fatte, og det vil derfor være godt om man kunne bruge et sprog der ikke
> udsatte en ny elev for disse, og hverken C eller C++ er særligt venlig på
> dette område.
Hmm.. absolut ikke enig. Det er Datalogi/Datateknologi-uddannelsen vi
taler om. Man ska' sg* lære pointere! :)
C++ tilføjer dog unødig kompleksitet, C er udemærket, men ikke OO
(hvilket nok er godt at lære lidt af nu om dage). Det var nok også
problemet med Modula-2. Python er ikke godt til det efterfølgende kursus
(DM02). Kompromiset blev Java. Alt hvad der er svært med pointere findes
iøvrigt også med referencer i Java.
> Men er det maskin nære ting der skal læres, er C nok den
> bedste portale assembler jeg kender
Det er ikke assembler man skal lære. Man skal lære forskellen på arrays,
linkede lister, B-træer, hash-tabeller, heaps, stakke, prioritetskøer
o.s.v. Man SKAL bruge pointere.
Peter
| |
Lars Kongshøj (06-09-2002)
| Kommentar
Fra : Lars Kongshøj |
Dato : 06-09-02 12:18 |
| | |
Peter Mogensen (06-09-2002)
| Kommentar
Fra : Peter Mogensen |
Dato : 06-09-02 12:25 |
|
Lars Kongshøj wrote:
> Peter Mogensen wrote:
>
>>Java har da pointere^H^H^H^H^H^H^Hreferencer ikk'?
>
>
> Hægter!
Hehe... skulle du helt tilfældigvis være fra DIKU ? :)
Men tak,... du har måske givet mig et godt kompromis i en længere
diskussion med en kollega om hvad forskellen på pointere og referencer er.
"arhh.. så lad os da bare kalde det hele for hægter" :)
Peter
| |
Lars Kongshøj (07-09-2002)
| Kommentar
Fra : Lars Kongshøj |
Dato : 07-09-02 00:02 |
|
Peter Mogensen wrote:
> Lars Kongshøj wrote:
> > Peter Mogensen wrote:
> >>Java har da pointere^H^H^H^H^H^H^Hreferencer ikk'?
> > Hægter!
> Hehe... skulle du helt tilfældigvis være fra DIKU ? :)
Bingo...
--
Lars Kongshøj
Registrer dig som linux-bruger:
http://counter.li.org/enter-person.php
| |
Kent Friis (07-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 07-09-02 10:04 |
|
Den Fri, 06 Sep 2002 13:25:26 +0200 skrev Peter Mogensen:
>Lars Kongshøj wrote:
>> Peter Mogensen wrote:
>>
>>>Java har da pointere^H^H^H^H^H^H^Hreferencer ikk'?
>>
>>
>> Hægter!
>
>Hehe... skulle du helt tilfældigvis være fra DIKU ? :)
>
>Men tak,... du har måske givet mig et godt kompromis i en længere
>diskussion med en kollega om hvad forskellen på pointere og referencer er.
Den forklaring jeg har læst er:
Pointere kan pege på NULL, det kan referencer ikke.
Pointere kan sættes til at pege på et andet objekt, referencer bliver
ved med at pege på det objekt de pegede på da de blev oprettet.
Mvh
Kent
--
Linux 0.12 is out
Windows XP is now obsolete!!!
| |
Henry Vest (07-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 07-09-02 10:47 |
|
Kent Friis wrote:
> Den forklaring jeg har læst er:
>
> Pointere kan pege på NULL, det kan referencer ikke.
>
> Pointere kan sættes til at pege på et andet objekt, referencer bliver
> ved med at pege på det objekt de pegede på da de blev oprettet.
Den definition passer da i hvert fald slet ikke på Javas objektreferencer.
/Henry
| |
Kent Friis (07-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 07-09-02 14:32 |
|
Den Sat, 7 Sep 2002 11:46:39 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Den forklaring jeg har læst er:
>>
>> Pointere kan pege på NULL, det kan referencer ikke.
>>
>> Pointere kan sættes til at pege på et andet objekt, referencer bliver
>> ved med at pege på det objekt de pegede på da de blev oprettet.
>
>Den definition passer da i hvert fald slet ikke på Javas objektreferencer.
Det er de eneste forskelle jeg kender på pointere og referencer. Men så
har Java måske pointere i stedet for referencer?
(Jeg mente egentlig jeg hørte definitionen fra en java-programmør).
Mvh
Kent
--
The frozen north will hatch a flightless bird,
who will spread his wings and dominate the earth
And cause an empire by the sea to fall
To the astonishment, and delight of all.
| |
Jens Axel Søgaard (07-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 07-09-02 19:19 |
|
Kent Friis wrote:
> Den Sat, 7 Sep 2002 11:46:39 +0200 skrev Henry Vest:
>> Kent Friis wrote:
>>
>>> Den forklaring jeg har læst er:
>>>
>>> Pointere kan pege på NULL, det kan referencer ikke.
>>>
>>> Pointere kan sættes til at pege på et andet objekt,
>>> referencer bliver ved med at pege på det objekt de
>>> pegede på da de blev oprettet.
>>
>> Den definition passer da i hvert fald slet ikke på Javas
>> objektreferencer.
>
> Det er de eneste forskelle jeg kender på pointere og
> referencer. Men så har Java måske pointere i stedet for
> referencer?
Hvis variablen p er en pointer til et objekt indeholder den en adresse
på en plads i lageret, hvori et objekt er gemt.
Hvis r er en reference identificerer indholdet r *på-en-eller-anden-
uspecificeret-måde* et objekt. De forskellige Java-implementationer
håndterer referencer forskelligt.
Historisk er pointere blevet anvendt som referencer i sprog, hvor
referencer ikke er til stede (f.eks. C). Et problem med pointere er,
at typesystemet bliver sat ud af spillet, når man ikke ved andet om
en pointer end at den indeholder en lageradresse.
En reference er man altid sikker på, refererer til noget af den rigtige
type.
Fra comp.lang.java's FAQ:
6.10: Does Java have pointers?
No, no, a thousand times no. Java does not have pointers,
no way, no how, the daily email I get from people who think
differently not withstanding.
Java does have references. A reference is an abstract identifier
for an object. It is not a pointer. A reference tags a particular object
with a name in the Java virtual machine so that the programmer may
refer to it. How exactly the virtual machine implements references at
the level of machine code is VM-dependent and completely hidden from
the programmer in any case. Most VMs including Sun's use handles, not
pointers. A handle is a pointer to a pointer. At the level of machine code
in the CPU a reference is an address in memory where the address of the
object is stored. This way the objects can be moved around in memory
and only the master pointer needs to be updated rather than all references
to the object. This is completely hidden from the Java programmer, though.
Only the implementer of the virtual machine needs to worry about it. Indeed,
this is not the only way references can be implemented. Microsoft's VM
actually does use pointers rather than handles. Other schemes are possible.
--
Jens Axel Søgaard
| |
Kent Friis (07-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 07-09-02 20:16 |
|
Den Sat, 7 Sep 2002 20:18:52 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Den Sat, 7 Sep 2002 11:46:39 +0200 skrev Henry Vest:
>>> Kent Friis wrote:
>>>
>>>> Den forklaring jeg har læst er:
>>>>
>>>> Pointere kan pege på NULL, det kan referencer ikke.
>>>>
>>>> Pointere kan sættes til at pege på et andet objekt,
>>>> referencer bliver ved med at pege på det objekt de
>>>> pegede på da de blev oprettet.
>>>
>>> Den definition passer da i hvert fald slet ikke på Javas
>>> objektreferencer.
>>
>> Det er de eneste forskelle jeg kender på pointere og
>> referencer. Men så har Java måske pointere i stedet for
>> referencer?
>
>Hvis variablen p er en pointer til et objekt indeholder den en adresse
>på en plads i lageret, hvori et objekt er gemt.
>
>Hvis r er en reference identificerer indholdet r *på-en-eller-anden-
>uspecificeret-måde* et objekt. De forskellige Java-implementationer
>håndterer referencer forskelligt.
To referencer kan godt referere til det samme objekt, og derfor må der
nødvendigvis være en adresse involveret et sted.
>Historisk er pointere blevet anvendt som referencer i sprog, hvor
>referencer ikke er til stede (f.eks. C). Et problem med pointere er,
>at typesystemet bliver sat ud af spillet, når man ikke ved andet om
>en pointer end at den indeholder en lageradresse.
Vrøvl. En int * indeholder adressen på en int. At nogen sprog (fx C)
tillader at man omgår typesystemet er ikke pointerens skyld.
>En reference er man altid sikker på, refererer til noget af den rigtige
>type.
Hvis sproget ikke tillader at man omgår typesystemet, så er man lige
så sikker med en pointer.
Mvh
Kent
--
Which one is faster - Lotus Notes or Lotus Esprit?
| |
Jens Axel Søgaard (08-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 08-09-02 11:54 |
|
Kent Friis wrote:
> Den Sat, 7 Sep 2002 20:18:52 +0200 skrev Jens Axel
> Søgaard:
>> Kent Friis wrote:
>>> Den Sat, 7 Sep 2002 11:46:39 +0200 skrev Henry Vest:
>>>> Kent Friis wrote:
>> Hvis r er en reference identificerer indholdet r *på-en-
>> eller-anden- uspecificeret-måde* et objekt. De
>> forskellige Java-implementationer håndterer referencer
>> forskelligt.
>
> To referencer kan godt referere til det samme objekt, og
> derfor må der nødvendigvis være en adresse involveret et
> sted.
Men ikke en *lager*adresse.
Man kan snildt forestille sig et system, hvor alle objekter
i systemet får tildelt et fortløbende id-nummer.
Sammenligningsoperatoren kan så implementeres ved at
sammenligne de to id'er.
Det er klart, at systemet skal have adressen på objektet
et eller andet sted, men pointen er, at en reference
ikke udelukkende er en lageradresse.
> Vrøvl. En int * indeholder adressen på en int. At nogen
> sprog (fx C) tillader at man omgår typesystemet er ikke
> pointerens skyld.
Tilstrækkelig retfærdigt (fair nok).
>> En reference er man altid sikker på, refererer til noget
>> af den rigtige type.
>
> Hvis sproget ikke tillader at man omgår typesystemet, så
> er man lige så sikker med en pointer.
Ja. Men hvis man leger med og sætter "pointer" lig med
"noget som indeholder en lageradresse", så vil der opstå
problemer; hvis såfremt sproget tillader manipulation med
adresserne.
--
Jens Axel Søgaard
| |
Kent Friis (08-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 08-09-02 16:40 |
|
Den Sun, 8 Sep 2002 12:53:49 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Den Sat, 7 Sep 2002 20:18:52 +0200 skrev Jens Axel
>> Søgaard:
>>> Kent Friis wrote:
>>>> Den Sat, 7 Sep 2002 11:46:39 +0200 skrev Henry Vest:
>>>>> Kent Friis wrote:
>
>>> Hvis r er en reference identificerer indholdet r *på-en-
>>> eller-anden- uspecificeret-måde* et objekt. De
>>> forskellige Java-implementationer håndterer referencer
>>> forskelligt.
>>
>> To referencer kan godt referere til det samme objekt, og
>> derfor må der nødvendigvis være en adresse involveret et
>> sted.
>
>Men ikke en *lager*adresse.
>
>Man kan snildt forestille sig et system, hvor alle objekter
>i systemet får tildelt et fortløbende id-nummer.
>Sammenligningsoperatoren kan så implementeres ved at
>sammenligne de to id'er.
Hvis du sammenligner med pointere, vil det svare til flg.
class cls;
cls *x, *y;
if(x==y) {};
Altså en sammenligning mellem to pointere. Den sammenligning man normalt
vil ønske (når man IKKE arbejder med pointere) er derimod:
if(*x == *y)
og det er noget helt andet.
>Det er klart, at systemet skal have adressen på objektet
>et eller andet sted, men pointen er, at en reference
>ikke udelukkende er en lageradresse.
Ordet "pointer" siger heller ikke noget om hvordan den bærer sig ad
med at pege, kun at den peger på noget. Et sprog der ikke tillader at
man blander int's og pointere kunne sagtens implementere pointere på
en anden måde - programmøren vil ikke kunne se forskel.
Og når vi snakker programmeringssprog, så er det hvordan det virker
for programmøren der er vigtigt, ikke hvordan det er implementeret
inde bag ved. Hvis det var omvendt, ville vi jo ikke have noget der
hed "objektorienterede programmeringssprog", for det der ligger bag
ved er ren maskinkode. Og CPU'en er ikke objektorienteret.
>> Vrøvl. En int * indeholder adressen på en int. At nogen
>> sprog (fx C) tillader at man omgår typesystemet er ikke
>> pointerens skyld.
>
>Tilstrækkelig retfærdigt (fair nok).
>
>>> En reference er man altid sikker på, refererer til noget
>>> af den rigtige type.
>>
>> Hvis sproget ikke tillader at man omgår typesystemet, så
>> er man lige så sikker med en pointer.
>
>Ja. Men hvis man leger med og sætter "pointer" lig med
>"noget som indeholder en lageradresse", så vil der opstå
>problemer; hvis såfremt sproget tillader manipulation med
>adresserne.
Hvis et sprog tillader manipulation med referencer, vil man få et
tilsvarende problem.
Mvh
Kent
--
Mails skrevet før 12:00 skal læses med det forbehold, at hjernen først
forventes at være færdig med at boote på det tidspunkt, og indholdet
derfor kan indeholde random data der tilfældigvis lå i den
uinitializerede cache.
| |
Jens Axel Søgaard (08-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 08-09-02 19:26 |
|
Kent Friis wrote:
>> Man kan snildt forestille sig et system, hvor alle
>> objekter i systemet får tildelt et fortløbende id-nummer.
>> Sammenligningsoperatoren kan så implementeres ved at
>> sammenligne de to id'er.
>
> Hvis du sammenligner med pointere, vil det svare til flg.
>
> class cls;
> cls *x, *y;
> if(x==y) {};
Jeps - her undersøges om x og y har samme identititet.
> Altså en sammenligning mellem to pointere. Den
> sammenligning man normalt vil ønske (når man IKKE
> arbejder med pointere) er derimod:
>
> if(*x == *y)
Og her undersøges om x og y refererer til samme værdi.
> og det er noget helt andet.
Fuldstændig rigtigt - jeg tænkte på den første type sammenligning.
Den anden er sværere at have med at gøre med mindre man
begrænser sig til at sammenligne værdier af atomare typer.
Bare for at gøre tingene mere indviklet:
Der findes sprog, hvor strenge kan "interneres".
Runtime-systemet sørger for at alle enstavede
strenge får samme identitet. Det er smart i situationer,
hvor man skal sammenligne strenge for tiden for en identitets-
sammenligning afhænger ikke af længden af strengene.
Her vil der derfor ikke være forskel på sammenligningerne
x=y og *x=*y
--
Jens Axel Søgaard
| |
Kent Friis (08-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 08-09-02 21:42 |
|
Den Sun, 8 Sep 2002 20:25:50 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>
>>> Man kan snildt forestille sig et system, hvor alle
>>> objekter i systemet får tildelt et fortløbende id-nummer.
>>> Sammenligningsoperatoren kan så implementeres ved at
>>> sammenligne de to id'er.
>>
>> Hvis du sammenligner med pointere, vil det svare til flg.
>>
>> class cls;
>> cls *x, *y;
>> if(x==y) {};
>
>Jeps - her undersøges om x og y har samme identititet.
>
>> Altså en sammenligning mellem to pointere. Den
>> sammenligning man normalt vil ønske (når man IKKE
>> arbejder med pointere) er derimod:
>>
>> if(*x == *y)
>
>Og her undersøges om x og y refererer til samme værdi.
>
>> og det er noget helt andet.
>Fuldstændig rigtigt - jeg tænkte på den første type sammenligning.
Altså en pointer-sammenligning, ikke en værdi-sammenligning.
Hvis man ikke arbejder med pointere, har man da ikke brug for pointer-
sammenligninger.
>Den anden er sværere at have med at gøre med mindre man
>begrænser sig til at sammenligne værdier af atomare typer.
Eller simple klasser, eller programmøren har lavet en operator ==
Mvh
Kent
--
unsigned long main = 0xC8C70FF0;
| |
Jens Axel Søgaard (08-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 08-09-02 22:11 |
|
Kent Friis wrote:
> Den Sun, 8 Sep 2002 20:25:50 +0200 skrev Jens Axel
> Søgaard:
>> Kent Friis wrote:
>>
>>>> Man kan snildt forestille sig et system, hvor alle
>>>> objekter i systemet får tildelt et fortløbende id-
>>>> nummer. Sammenligningsoperatoren kan så implementeres
>>>> ved at sammenligne de to id'er.
>>>
>>> Hvis du sammenligner med pointere, vil det svare til
>>> flg.
>>>
>>> class cls;
>>> cls *x, *y;
>>> if(x==y) {};
>>
>> Jeps - her undersøges om x og y har samme identititet.
> Altså en pointer-sammenligning, ikke en værdi-
> sammenligning.
>
> Hvis man ikke arbejder med pointere, har man da ikke brug
> for pointer- sammenligninger.
Hvad mener du? Skal "ikke arbejder med pointere" forstås
som "når man arbejder med referencer"?
Man har altid brug for kunne undersøge om to objekter
har samme identitet. Dette gøres ved at sammenligne
referencerne.
Ofte tænker man ikke på, at man bruger referencer.
Eksempel:
Erklæringen (/sætningen)
String bar = "baz";
gør to ting. Der reserveres en plads (variabel) i lageret,
som sættes til at indeholde et objekt af typen String.
Dernæst reserveres der endnu en plads (variabel) i lageret,
hvis indhold er en reference til variablen, som indeholder
String-objektet. Navnet "bar" bindes nu til den plads,
som indeholder referencen.
--
Jens Axel Søgaard
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 18:48 |
|
Den Sun, 8 Sep 2002 23:10:39 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Den Sun, 8 Sep 2002 20:25:50 +0200 skrev Jens Axel
>> Søgaard:
>>> Kent Friis wrote:
>>>
>>>>> Man kan snildt forestille sig et system, hvor alle
>>>>> objekter i systemet får tildelt et fortløbende id-
>>>>> nummer. Sammenligningsoperatoren kan så implementeres
>>>>> ved at sammenligne de to id'er.
>>>>
>>>> Hvis du sammenligner med pointere, vil det svare til
>>>> flg.
>>>>
>>>> class cls;
>>>> cls *x, *y;
>>>> if(x==y) {};
>>>
>>> Jeps - her undersøges om x og y har samme identititet.
>
>> Altså en pointer-sammenligning, ikke en værdi-
>> sammenligning.
>>
>> Hvis man ikke arbejder med pointere, har man da ikke brug
>> for pointer- sammenligninger.
>
>Hvad mener du? Skal "ikke arbejder med pointere" forstås
>som "når man arbejder med referencer"?
Hvis man arbejder med referencer, eller hvis man arbejder med
almindelige variable.
>Man har altid brug for kunne undersøge om to objekter
>har samme identitet. Dette gøres ved at sammenligne
>referencerne.
Alle de gange jeg har haft brug for at sammenligne to objekter, har
jeg haft brug for at sammenligne værdien. Pointer-sammenligninger har
jeg kun haft brug for når jeg bruger pointere.
>Ofte tænker man ikke på, at man bruger referencer.
>
>Eksempel:
>
>Erklæringen (/sætningen)
>
> String bar = "baz";
>
>gør to ting. Der reserveres en plads (variabel) i lageret,
>som sættes til at indeholde et objekt af typen String.
>Dernæst reserveres der endnu en plads (variabel) i lageret,
>hvis indhold er en reference til variablen, som indeholder
>String-objektet. Navnet "bar" bindes nu til den plads,
>som indeholder referencen.
Den samme beskrivelse kunne bruges til pointere.
Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds
| |
Jens Axel Søgaard (09-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 09-09-02 19:29 |
|
Kent Friis wrote:
> Den Sun, 8 Sep 2002 23:10:39 +0200 skrev Jens Axel
> Søgaard:
>> Kent Friis wrote:
>>> Den Sun, 8 Sep 2002 20:25:50 +0200 skrev Jens Axel
>>> Søgaard:
>>>> Kent Friis wrote:
>>>>
>>>>>> Man kan snildt forestille sig et system, hvor alle
>>>>>> objekter i systemet får tildelt et fortløbende id-
>>>>>> nummer. Sammenligningsoperatoren kan så implementeres
>>>>>> ved at sammenligne de to id'er.
>>>>>
>>>>> Hvis du sammenligner med pointere, vil det svare til
>>>>> flg.
>>>>>
>>>>> class cls;
>>>>> cls *x, *y;
>>>>> if(x==y) {};
>>>>
>>>> Jeps - her undersøges om x og y har samme identititet.
>>
>>> Altså en pointer-sammenligning, ikke en værdi-
>>> sammenligning.
>>>
>>> Hvis man ikke arbejder med pointere, har man da ikke
>>> brug for pointer- sammenligninger.
>>
>> Hvad mener du? Skal "ikke arbejder med pointere" forstås
>> som "når man arbejder med referencer"?
>
> Hvis man arbejder med referencer, eller hvis man arbejder
> med almindelige variable.
Så har du til gengæld brug for at sammenligne referencer.
>> Man har altid brug for kunne undersøge om to objekter
>> har samme identitet. Dette gøres ved at sammenligne
>> referencerne.
>
> Alle de gange jeg har haft brug for at sammenligne to
> objekter, har jeg haft brug for at sammenligne værdien.
> Pointer-sammenligninger har jeg kun haft brug for når jeg
> bruger pointere.
Eksempel:
En bil er karakteriseret ved mærke, tophastighed og farve.
Lad nu o1 og o2 være disse instanser klassen bil:
o1: skoda, 10, gul
o2: skoda, 10, gul
Lad nu x og y være referencer til to henholdsvis o1 og o2.
Da referencerne x og y er forskellige er refererer de til
to forskellige biler.
Hvis du sammenligner de værdier x og y refererer til, får
du vide at de er ens; for som værdier er de o1 og o2 ens.
>> Ofte tænker man ikke på, at man bruger referencer.
[snip]
> Den samme beskrivelse kunne bruges til pointere.
Jeg forsøgte at finde ud af, hvad du mente med
"ikke arbejder med pointere".
--
Jens Axel Søgaard
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 19:57 |
|
Den Mon, 9 Sep 2002 20:28:30 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Den Sun, 8 Sep 2002 23:10:39 +0200 skrev Jens Axel
>> Søgaard:
>>> Kent Friis wrote:
>>>
>>>> Hvis man ikke arbejder med pointere, har man da ikke
>>>> brug for pointer- sammenligninger.
>>>
>>> Hvad mener du? Skal "ikke arbejder med pointere" forstås
>>> som "når man arbejder med referencer"?
>>
>> Hvis man arbejder med referencer, eller hvis man arbejder
>> med almindelige variable.
>
>Så har du til gengæld brug for at sammenligne referencer.
Nope, ikke en eneste gang so far.
>> Alle de gange jeg har haft brug for at sammenligne to
>> objekter, har jeg haft brug for at sammenligne værdien.
>> Pointer-sammenligninger har jeg kun haft brug for når jeg
>> bruger pointere.
>
>Eksempel:
>En bil er karakteriseret ved mærke, tophastighed og farve.
>Lad nu o1 og o2 være disse instanser klassen bil:
>
>o1: skoda, 10, gul
>o2: skoda, 10, gul
>
>Lad nu x og y være referencer til to henholdsvis o1 og o2.
>Da referencerne x og y er forskellige er refererer de til
>to forskellige biler.
Du glemte at udfylde bil.registreringsnr
Jeg betragter det som et dårligt eksempel. Hvis o1 kommer fra
databasen over efterlyste biler, og o2 kommer fra indtastningsfeltet,
så vil "er denne bil efterlyst" jo give false, fordi det er to
forskellige objekter. De repræsenterer bare den samme bil. Derfor
bruger man selvfølgelig værdi-sammenligning.
Mvh
Kent
--
echo f 0:0 ffff 0 | debug
| |
Jens Axel Søgaard (09-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 09-09-02 20:09 |
|
Kent Friis wrote:
>>> Hvis man arbejder med referencer, eller hvis man
>>> arbejder med almindelige variable.
>>
>> Så har du til gengæld brug for at sammenligne referencer.
>
> Nope, ikke en eneste gang so far.
>
>>> Alle de gange jeg har haft brug for at sammenligne to
>>> objekter, har jeg haft brug for at sammenligne værdien.
>>> Pointer-sammenligninger har jeg kun haft brug for når
>>> jeg bruger pointere.
>>
>> Eksempel:
>> En bil er karakteriseret ved mærke, tophastighed og
>> farve. Lad nu o1 og o2 være disse instanser klassen bil:
>>
>> o1: skoda, 10, gul
>> o2: skoda, 10, gul
>>
>> Lad nu x og y være referencer til to henholdsvis o1 og
>> o2. Da referencerne x og y er forskellige er refererer
>> de til to forskellige biler.
>
> Du glemte at udfylde bil.registreringsnr
>
> Jeg betragter det som et dårligt eksempel. Hvis o1 kommer
> fra databasen over efterlyste biler, og o2 kommer fra
> indtastningsfeltet, så vil "er denne bil efterlyst" jo
> give false, fordi det er to forskellige objekter. De
> repræsenterer bare den samme bil. Derfor bruger man
> selvfølgelig værdi-sammenligning.
De repræsenterer *ikke* samme bil. Den første ejes af Hansen,
den anden af Jensen. "Samme bil" er udelukkende et spørgsmål
om identitet - ikke værdi.
--
Jens Axel Søgaard
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 20:16 |
|
Den Mon, 9 Sep 2002 21:09:00 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>
>>>> Hvis man arbejder med referencer, eller hvis man
>>>> arbejder med almindelige variable.
>>>
>>> Så har du til gengæld brug for at sammenligne referencer.
>>
>> Nope, ikke en eneste gang so far.
>>
>>>> Alle de gange jeg har haft brug for at sammenligne to
>>>> objekter, har jeg haft brug for at sammenligne værdien.
>>>> Pointer-sammenligninger har jeg kun haft brug for når
>>>> jeg bruger pointere.
>>>
>>> Eksempel:
>>> En bil er karakteriseret ved mærke, tophastighed og
>>> farve. Lad nu o1 og o2 være disse instanser klassen bil:
>>>
>>> o1: skoda, 10, gul
>>> o2: skoda, 10, gul
>>>
>>> Lad nu x og y være referencer til to henholdsvis o1 og
>>> o2. Da referencerne x og y er forskellige er refererer
>>> de til to forskellige biler.
>>
>> Du glemte at udfylde bil.registreringsnr
>>
>> Jeg betragter det som et dårligt eksempel. Hvis o1 kommer
>> fra databasen over efterlyste biler, og o2 kommer fra
>> indtastningsfeltet, så vil "er denne bil efterlyst" jo
>> give false, fordi det er to forskellige objekter. De
>> repræsenterer bare den samme bil. Derfor bruger man
>> selvfølgelig værdi-sammenligning.
>
>De repræsenterer *ikke* samme bil. Den første ejes af Hansen,
>den anden af Jensen. "Samme bil" er udelukkende et spørgsmål
>om identitet - ikke værdi.
Hvordan vil du få den bil der returneres fra gui.showdialog() og
den bil der returneres fra db.getnext() til at være den samme
"identitet", i det tilfælde at det rent faktisk er den efterlyste
bil der er tale om?
Mvh
Kent
--
Exception 0E in module IFSMGR.VXD
Press control-alt-delete to reboot
| |
Jens Axel Søgaard (09-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 09-09-02 20:56 |
|
Kent Friis wrote:
> Hvordan vil du få den bil der returneres fra
> gui.showdialog() og den bil der returneres fra
> db.getnext() til at være den samme "identitet", i det
> tilfælde at det rent faktisk er den efterlyste bil der er
> tale om?
Hvis du ikke repræsenterer bilerne (de fysiske objekter) med
bil-instanser i dit kørende program, men derimod anvender
rækker i en tabel i en database, kan du ikke anvende
objektidentitet direkte til at afgøre om du står med samme bil.
I en database vil man normalt repræsentere identitet ved
hjælp af et fortløbende id-nummer. Det nemmeste er så
at sammenligne id-numrene.
Hvis man endelig vil bruge objektidentitet kan man opretholde
en id-nummer->objekt tabel, som getnext kan slå op i for
at sikre sig, at den returnerer en reference til det samme objekt
hver gang.
Hvad siger databasefolket: Hvordan gør I?
--
Jens Axel Søgaard
| |
Anders J. Munch (10-09-2002)
| Kommentar
Fra : Anders J. Munch |
Dato : 10-09-02 12:54 |
|
[XFUT dk.edb.programmering]
"Jens Axel Søgaard" <usenet@soegaard.net> wrote:
> Kent Friis wrote:
>
> > Hvordan vil du få den bil der returneres fra
> > gui.showdialog() og den bil der returneres fra
> > db.getnext() til at være den samme "identitet", i det
> > tilfælde at det rent faktisk er den efterlyste bil der er
> > tale om?
>
> Hvis du ikke repræsenterer bilerne (de fysiske objekter) med
> bil-instanser i dit kørende program, men derimod anvender
> rækker i en tabel i en database, kan du ikke anvende
> objektidentitet direkte til at afgøre om du står med samme bil.
>
> I en database vil man normalt repræsentere identitet ved
> hjælp af et fortløbende id-nummer. Det nemmeste er så
> at sammenligne id-numrene.
>
> Hvis man endelig vil bruge objektidentitet kan man opretholde
> en id-nummer->objekt tabel, som getnext kan slå op i for
> at sikre sig, at den returnerer en reference til det samme objekt
> hver gang.
>
> Hvad siger databasefolket: Hvordan gør I?
Kvalificerer sammenligningen.
Fuldfører sætningen:
"De to poster er identisk med hensyn til ...."
Hvis fuldførelsen er:
"... udseende."
så sammenlign mærke og farve.
Hvis fuldførelsen er:
"... at de repræsenterer den samme fysiske bil."
så fører det til spørgsmålet om hvordan man ved at det det er den samme
fysiske bil, og hvis svaret er registreringsnr., så må man jo tilføje et
registreringsnummer-felt.
Hvis fuldførelsen er:
"... at de stammer fra den operatør-indtastning/post-oprettelse."
så må man sørge for at der er et løbenr.-felt som bliver tildelt ved
oprettelsen.
Naturlig identitet er en illusion. Der findes kun ækvivalensrelationer.
mvh. Anders
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 16:58 |
|
Den Mon, 9 Sep 2002 21:55:48 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>
>> Hvordan vil du få den bil der returneres fra
>> gui.showdialog() og den bil der returneres fra
>> db.getnext() til at være den samme "identitet", i det
>> tilfælde at det rent faktisk er den efterlyste bil der er
>> tale om?
>
>Hvis du ikke repræsenterer bilerne (de fysiske objekter) med
>bil-instanser i dit kørende program, men derimod anvender
>rækker i en tabel i en database, kan du ikke anvende
>objektidentitet direkte til at afgøre om du står med samme bil.
Hvis det ene ligger som et objekt, og det andet kommer fra indtastnings-
dialogen, vil de heller ikke have samme identitet. Så kan du igen ikke
bruge identiteten til noget.
>I en database vil man normalt repræsentere identitet ved
>hjælp af et fortløbende id-nummer. Det nemmeste er så
>at sammenligne id-numrene.
>
>Hvis man endelig vil bruge objektidentitet kan man opretholde
>en id-nummer->objekt tabel, som getnext kan slå op i for
>at sikre sig, at den returnerer en reference til det samme objekt
>hver gang.
>
>Hvad siger databasefolket: Hvordan gør I?
Bruger nøglefeltet (fx. registreringsnummeret), som er en del af
objektet, og derfor virker værdi-sammenligning. Identitetssammenligning
gør ikke.
Mvh
Kent
--
Linux 0.12 is out
Windows XP is now obsolete!!!
| |
Jens Axel Søgaard (08-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 08-09-02 19:29 |
|
Kent Friis wrote:
> Og når vi snakker programmeringssprog, så er det hvordan
> det virker for programmøren der er vigtigt, ikke hvordan
> det er implementeret inde bag ved.
Præcis det er argumentet for at indføre referencer
fremfor pointere. Referencer er handicappede pointere.
>> Ja. Men hvis man leger med og sætter "pointer" lig med
>> "noget som indeholder en lageradresse", så vil der opstå
>> problemer; hvis såfremt sproget tillader manipulation med
>> adresserne.
>
> Hvis et sprog tillader manipulation med referencer, vil
> man få et tilsvarende problem.
Så ville det ikke være en reference.
--
Jens Axel Søgaard
| |
Kent Friis (08-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 08-09-02 21:49 |
|
Den Sun, 8 Sep 2002 20:29:05 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Og når vi snakker programmeringssprog, så er det hvordan
>> det virker for programmøren der er vigtigt, ikke hvordan
>> det er implementeret inde bag ved.
>
>Præcis det er argumentet for at indføre referencer
>fremfor pointere. Referencer er handicappede pointere.
Efter den forklaring jeg har fået her, er det java kalder "referencer"
bare pointere man ikke kan få lov til at blande sammen med int's
(p=0xdeadbeef, p+=45, p+=1 aka p++). Om man skal have lov til at blande
typerne på kryds og tværs, er noget sproget afgør, ikke en egenskab
ved typen. En int er jo også en int, uanset om man kan blande ints og
chars.
>>> Ja. Men hvis man leger med og sætter "pointer" lig med
>>> "noget som indeholder en lageradresse", så vil der opstå
>>> problemer; hvis såfremt sproget tillader manipulation med
>>> adresserne.
>>
>> Hvis et sprog tillader manipulation med referencer, vil
>> man få et tilsvarende problem.
>
>Så ville det ikke være en reference.
Ethvert sprog der tillader "asm { ... }" tillader manipulation med
referencer
Mvh
Kent
--
A Elbereth Gilthoniel, silivren penna míriel
o menel aglar elenath! Na-chaered palan-díriel
o galadhremmin ennorath, Fanuilos, le linnathon nef aear, sí nef aearon!
- Tolkien, "The Lord of the Rings"
| |
Jens Axel Søgaard (08-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 08-09-02 22:16 |
|
Kent Friis wrote:
> Den Sun, 8 Sep 2002 20:29:05 +0200 skrev Jens Axel
> Søgaard:
>> Kent Friis wrote:
>>> Og når vi snakker programmeringssprog, så er det hvordan
>>> det virker for programmøren der er vigtigt, ikke hvordan
>>> det er implementeret inde bag ved.
>>
>> Præcis det er argumentet for at indføre referencer
>> fremfor pointere. Referencer er handicappede pointere.
>
> Efter den forklaring jeg har fået her, er det java kalder
> "referencer" bare pointere man ikke kan få lov til at
> blande sammen med int's (p=0xdeadbeef, p+=45, p+=1 aka
> p++).
Det er også meningen det skal virke sådan.
Men du kan ikke vide om netop din Java implementerer
referencer ved hjælp af pointere eller ej.
--
Jens Axel Søgaard
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 18:50 |
|
Den Sun, 8 Sep 2002 23:15:48 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Den Sun, 8 Sep 2002 20:29:05 +0200 skrev Jens Axel
>> Søgaard:
>>> Kent Friis wrote:
>>>> Og når vi snakker programmeringssprog, så er det hvordan
>>>> det virker for programmøren der er vigtigt, ikke hvordan
>>>> det er implementeret inde bag ved.
>>>
>>> Præcis det er argumentet for at indføre referencer
>>> fremfor pointere. Referencer er handicappede pointere.
>>
>> Efter den forklaring jeg har fået her, er det java kalder
>> "referencer" bare pointere man ikke kan få lov til at
>> blande sammen med int's (p=0xdeadbeef, p+=45, p+=1 aka
>> p++).
>
>Det er også meningen det skal virke sådan.
Jamen så er det jo også pointere.
Meget i java er kopieret fra C++, men referencer har de åbenbart kun
kopieret navnet. Funktionaliteten svarer mere til pointere, end det
svarer til referencer i C++ (C++ har begge dele).
>Men du kan ikke vide om netop din Java implementerer
>referencer ved hjælp af pointere eller ej.
Det kan man reelt heller ikke vide med pointere i et ikke-maskinnært
sprog.
Mvh
Kent
--
Those who write "Optimized for Netscape" og "Best viewed with MSIE"
never figured out the difference between the WWW and a
Word Perfect 4.2 Document.
| |
Thorbjoern Ravn Ande~ (07-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 07-09-02 21:12 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Det er de eneste forskelle jeg kender på pointere og referencer. Men så
> har Java måske pointere i stedet for referencer?
| |
Kent Friis (07-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 07-09-02 21:52 |
|
Den 07 Sep 2002 22:11:40 +0200 skrev Thorbjoern Ravn Andersen:
>--=-=-=
>Content-Type: text/plain; charset=iso-8859-15
>Content-Transfer-Encoding: 8bit
>
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Det er de eneste forskelle jeg kender på pointere og referencer. Men så
>> har Java måske pointere i stedet for referencer?
>
>--=-=-=
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>
>En pointer peger (deraf navnet) på en fysisk adresse i lageret, enten
>fordi den er blevet sat til at pege på netop det sted "manuelt", eller
>fordi der er blevet tildelt en stump hukommelse som er placeret dette
>sted. Der er ingen garanti for at en pointer peger på noget
>fornuftigt, og specielt C-pointere er plaget meget af fejlagtige
>værdier, som det er meget krævende at fejlfinde og undgå.
At C tillader at man kan gøre hvadsomhelst ved en pointer betyder ikke
nødvendigvis at alle andre sprog skal gøre det på samme måde.
Et sprog der ikke tillader at blande int's og pointere, og som sikrer
at variable (incl. pointere) er initialiseret til 0, vil kun kunne
give en type pointer-fejl, nemlig null-pointer fejl.
>En reference i Java peger enten på et gyldigt objekt, eller på null,
Dvs. at man sagtens kan få null-pointer fejl i Java? Så kan jeg
virkelig ikke se fordelen i det sprog.
Den ting der irriterer mig mest i VB.NET er netop strukturen med at
alt er pointere, og man får sg* flere null-pointer fejl i VB, end man
gør i C. Og det kan slet ikke sammenlignes med C++, der behøver man slet
ikke at bruge pointere, og hvis man bruger referencer kan man ikke
få null-pointer fejl).
Mvh
Kent
--
The revolution has just begun.
| |
Thorbjoern Ravn Ande~ (08-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 08-09-02 12:00 |
|
leeloo@phreaker.net (Kent Friis) writes:
> At C tillader at man kan gøre hvadsomhelst ved en pointer betyder ikke
> nødvendigvis at alle andre sprog skal gøre det på samme måde.
| |
Kent Friis (08-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 08-09-02 16:48 |
|
Den 08 Sep 2002 12:59:54 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> At C tillader at man kan gøre hvadsomhelst ved en pointer betyder ikke
>> nødvendigvis at alle andre sprog skal gøre det på samme måde.
>
>Nejda. Her diskuterer vi forskellen, og en vigtig forskel i de
>typiske implementationer er at en pointer peger på en bestemt
>hukommelsesadresse, og en reference på et objekt der er placeret "et
>eller andet sted".
For mig at se er implementationen fuldstændig irrelevant, bare den
virker.
Og hvis en reference virker som en pointer (uanset hvordan den er
implementeret), så er det *fra programmørens synspunkt* en pointer.
>> Et sprog der ikke tillader at blande int's og pointere, og som sikrer
>> at variable (incl. pointere) er initialiseret til 0, vil kun kunne
>> give en type pointer-fejl, nemlig null-pointer fejl.
>>
>> >En reference i Java peger enten på et gyldigt objekt, eller på null,
>>
>> Dvs. at man sagtens kan få null-pointer fejl i Java? Så kan jeg
>> virkelig ikke se fordelen i det sprog.
>
>Selvfølgelig kan du få null-pointerfejl, eftersom en reference kan
>være uinitialiseret (hvilket er betydningen af null). Hvis du følger
>en sådan, får du en fejl.
Og derved forsvandt hele fordelen ved referencer frem for pointere.
>Hvis du tester først om den er forskellig fra null, er du garanteret
>at værdien er et gyldigt objekt.
>
>At du tillader dig at afskrive et sprog du ikke kender på så spinkelt
>et grundlag, undrer mig iøvrigt.
Falsk reklame er for mig ikke et spinkelt grundlag. Det er et tegn på
at man ikke kan stole på folk.
Det vigtiste argument jeg har hørt for at bruge java er netop at det
har referencer i stedet for pointere, så man slipper for null-pointer
fejl.
Men så ved jeg da det. Hvis jeg får lyst til at bruge et programmerings-
sprog med referencer, så tager jeg et sprog der garanterer at jeg ikke
får null-pointer fejl på referencer. Det gør C++ så vidt jeg har
forstået det.
(og hvis jeg ikke har noget problem med null-pointer fejl, så fortsætter
jeg med C).
>> Den ting der irriterer mig mest i VB.NET er netop strukturen med at
>> alt er pointere, og man får sg* flere null-pointer fejl i VB, end man
>> gør i C. Og det kan slet ikke sammenlignes med C++, der behøver man slet
>> ikke at bruge pointere, og hvis man bruger referencer kan man ikke
>> få null-pointer fejl).
>
>Omhyggelighed skader ikke.
>
>Hvorfor i alverden bruger din arbejdsplads VB.NET hvis I har så svært
>ved at bruge det?
Man tager en COBOL-programmør, og kalder ham "IT-chef"...
Mvh
Kent
--
"Handlingen blev afbrudt pga. computerens begrænsede effekt"
- Windows NT på en Pentium III 550 MHz
| |
Thorbjoern Ravn Ande~ (08-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 08-09-02 16:58 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Og hvis en reference virker som en pointer (uanset hvordan den er
> implementeret), så er det *fra programmørens synspunkt* en pointer.
| |
Kent Friis (08-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 08-09-02 17:53 |
|
Den 08 Sep 2002 17:58:17 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Og hvis en reference virker som en pointer (uanset hvordan den er
>> implementeret), så er det *fra programmørens synspunkt* en pointer.
>
>Forskellen er - som jeg nævnte tidligere - at hvis en reference er
>forskellig fra null, er du _garanteret_ at den peger på et gyldigt
>objekt. Herudover er det umanipulerbare pointere for resten.
Hvordan er det en forskel? Hvis et sprog ikke giver mulighed for
pointer-aritmetik, og iøvrigt altid initialiserer pointeren til
null, hvad forhindrer så at du også kan være garanteret at den
peger på et gyldig objekt?
>> >Selvfølgelig kan du få null-pointerfejl, eftersom en reference kan
>> >være uinitialiseret (hvilket er betydningen af null). Hvis du følger
>> >en sådan, får du en fejl.
>>
>> Og derved forsvandt hele fordelen ved referencer frem for pointere.
>
>Nej - enten kender du ikke C's pointerbegreb eller også kender du ikke
>Javas reference-begreb. Det lader til at være det sidste.
Jeg troede jeg kendte java's reference-begreb, men efter din forklaring,
har jeg ændret opfattelse til det der i Java hedder referencer svarer
til det der hedder pointere i C++ (dog med visse type-restriktioner,
som alt andet i java), og at java ikke har noget der svarer til det
der hedder referencer i C++.
Ellers må din forklaring jo ikke være god nok.
>> Det vigtiste argument jeg har hørt for at bruge java er netop at det
>> har referencer i stedet for pointere, så man slipper for null-pointer
>> fejl.
>
>Så har du ikke hørt ordentlig efter. Man slipper for _pointer_-fejl!
Hvis en pointer er initialiseret, og man ikke selv piller ved den,
så er pointerfejl = nullpointer-fejl.
>Altså at du har en eller anden int-værdi der peger ud i det blå, som
>du vælger at følge, og så har du problematikkken. Oftest får du
>disse værdier fordi du fedter med fx array-indeksering og forveksler <
>med <=. Eller løber ud over slutningen på en lokal variabel. Osv.
Det sker kun hvis du selv piller ved pointeren.
>> (og hvis jeg ikke har noget problem med null-pointer fejl, så fortsætter
>> jeg med C).
>
>Hvis man altid laver 100% korrekt kode, kan man kode i hvadsomhelst.
Og hvis man laver masser af null-pointer fejl, skal man holde sig til
et sprog som C++, hvor man kan bruge referencer og dermed være
garanteret at man ikke får null-pointer fejl.
Mvh
Kent
--
Object orientation: the idea, that humans find it easier to understand
"you.car.engine.start" than "start your car engine".
| |
Thorbjoern Ravn Ande~ (08-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 08-09-02 18:24 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Hvordan er det en forskel? Hvis et sprog ikke giver mulighed for
> pointer-aritmetik, og iøvrigt altid initialiserer pointeren til
> null, hvad forhindrer så at du også kan være garanteret at den
> peger på et gyldig objekt?
| |
Kent Friis (08-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 08-09-02 21:39 |
|
Den 08 Sep 2002 19:24:11 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Hvordan er det en forskel? Hvis et sprog ikke giver mulighed for
>> pointer-aritmetik, og iøvrigt altid initialiserer pointeren til
>> null, hvad forhindrer så at du også kan være garanteret at den
>> peger på et gyldig objekt?
>
>At en null-pointer ikke peger på et gyldigt objekt. Short and
>simple.
Det argument gælder jo også imod javas "referencer".
>(I teorien kunne null godt være på en tom Java.lang.Object, men det
>gør den altså ikke).
>> Jeg troede jeg kendte java's reference-begreb, men efter din forklaring,
>> har jeg ændret opfattelse til det der i Java hedder referencer svarer
>> til det der hedder pointere i C++ (dog med visse type-restriktioner,
>> som alt andet i java), og at java ikke har noget der svarer til det
>> der hedder referencer i C++.
>
>Jeg kender ikke C++ godt nok til at kunne vurdere om det er rigtigt.
>
>> Ellers må din forklaring jo ikke være god nok.
>
>Det er ikke usandsynligt. Det er svært altid at ramme rigtigt når man
>ikke kender modtagergruppens tekniske forudsætninger.
Nul kendskab til java, masser af kendskab til pointere.
>> >> Det vigtiste argument jeg har hørt for at bruge java er netop at det
>> >> har referencer i stedet for pointere, så man slipper for null-pointer
>> >> fejl.
>> >
>> >Så har du ikke hørt ordentlig efter. Man slipper for _pointer_-fejl!
>>
>> Hvis en pointer er initialiseret, og man ikke selv piller ved den,
>> så er pointerfejl = nullpointer-fejl.
>
>Javelja. Vil du være så venlig at definere "initialiseret".
At når man opretter en ny pointer så peger den på null, og ikke på
en tilfældig adresse.
>> >Hvis man altid laver 100% korrekt kode, kan man kode i hvadsomhelst.
>>
>> Og hvis man laver masser af null-pointer fejl, skal man holde sig til
>> et sprog som C++, hvor man kan bruge referencer og dermed være
>> garanteret at man ikke får null-pointer fejl.
>
>Hvad indeholder din referencevariabel inden du tildeler den en instans
>med et kald til new?
new bruger man da til pointere, ikke til referencer.
Mvh
Kent
--
echo f 0:0 ffff 0 | debug
| |
Thorbjoern Ravn Ande~ (08-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 08-09-02 22:07 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >> Hvordan er det en forskel? Hvis et sprog ikke giver mulighed for
> >> pointer-aritmetik, og iøvrigt altid initialiserer pointeren til
> >> null, hvad forhindrer så at du også kan være garanteret at den
> >> peger på et gyldig objekt?
> >
> >At en null-pointer ikke peger på et gyldigt objekt. Short and
> >simple.
>
> Det argument gælder jo også imod javas "referencer".
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 18:44 |
|
Den 08 Sep 2002 23:06:37 +0200 skrev Thorbjoern Ravn Andersen:
>> >> Hvordan er det en forskel? Hvis et sprog ikke giver mulighed for
>> >> pointer-aritmetik, og iøvrigt altid initialiserer pointeren til
>> >> null, hvad forhindrer så at du også kan være garanteret at den
>> >> peger på et gyldig objekt?
>> >
>> >At en null-pointer ikke peger på et gyldigt objekt. Short and
>> >simple.
>>
>> Det argument gælder jo også imod javas "referencer".
>
>Irrelevant til ovenstående spørgsmål.
Så må der være sket en misforståelse et sted. Jeg argumenterer for
at pointere og java's "referencer" er det samme, og så kan du da ikke
bare komme og sige "jamen en null-pointer peger ikke på et gyldigt
objekt". Det gør da overhovedet ingen forskel, for det gør den heller
ikke selvom man kalder pointeren for en "reference".
>pointere/referencer med værdien null peger IKKE til et gyldigt
>objekt. Uinitialiserede, også kaldet.
Lige præcis mit argument.
>> >Det er ikke usandsynligt. Det er svært altid at ramme rigtigt når man
>> >ikke kender modtagergruppens tekniske forudsætninger.
>>
>> Nul kendskab til java, masser af kendskab til pointere.
>
>Ok.
>
>> >Javelja. Vil du være så venlig at definere "initialiseret".
>>
>> At når man opretter en ny pointer så peger den på null, og ikke på
>> en tilfældig adresse.
>
>Javelja. Det havde jeg helt glemt, for i Java er objekt variable (der
>indeholder referencer) altid sat til null som standard. Herefte rkan
>man putte noget i dem med en passende new.
Det begreb hedder "pointere" i andre sprog.
>> >Hvad indeholder din referencevariabel inden du tildeler den en instans
>> >med et kald til new?
>>
>> new bruger man da til pointere, ikke til referencer.
>
>Java referencer gør man skam. Hvor skulle du ellers få objekterne
>fra?
Fx. ved at bruge dem i parametre til en funktion. Eller ved at sætte
dem til at pege på et eksisterende objekt (det sidste har jeg ikke lige
fattet ideen i, men folk har sikkert en god grund til at gøre det).
Mvh
Kent
--
F0 0F C7 C8 - Intel Pentium bug
| |
Henry Vest (09-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 09-09-02 19:06 |
|
Kent Friis wrote:
>>> new bruger man da til pointere, ikke til referencer.
>>
>>Java referencer gør man skam. Hvor skulle du ellers få objekterne
>>fra?
>
> Fx. ved at bruge dem i parametre til en funktion. Eller ved at sætte
> dem til at pege på et eksisterende objekt
Og hvordan skulle man så få dette eksisterende objekt? I Java, kun ved
hjælp af new!
/Henry
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 19:11 |
|
Den Mon, 9 Sep 2002 20:05:38 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>>>> new bruger man da til pointere, ikke til referencer.
>>>
>>>Java referencer gør man skam. Hvor skulle du ellers få objekterne
>>>fra?
>>
>> Fx. ved at bruge dem i parametre til en funktion. Eller ved at sætte
>> dem til at pege på et eksisterende objekt
>
>Og hvordan skulle man så få dette eksisterende objekt? I Java, kun ved
>hjælp af new!
Kan man ikke oprette en normal variabel? Som i:
class c {};
c foobar;
I så fald må jeg nok konkludere at java har nøjagtig samme fejltaglese
som VB.NET, at alt er pointere  Damn, der mistede jeg lige al respekt
for java.
Mvh
Kent
--
What was your username?
<Clicketyclick> - B.O.F.H.
| |
Thorbjoern Ravn Ande~ (09-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 09-09-02 19:30 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Kan man ikke oprette en normal variabel? Som i:
>
> class c {};
>
> c foobar;
Joda. Denne er nu sat til null.
Indhold får den først når du kalder new.
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 19:52 |
|
Den 09 Sep 2002 20:30:12 +0200 skrev Thorbjoern Ravn Andersen:
>--=-=-=
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Kan man ikke oprette en normal variabel? Som i:
>>
>> class c {};
>>
>> c foobar;
>
>Joda. Denne er nu sat til null.
Så er den jo ikke oprettet. I C++ vil foobar være et objekt af klassen
c, *ikke* en pointer.
>Indhold får den først når du kalder new.
Det svarer altså til:
class c {};
c * foobar;
c = new foobar;
>> I så fald må jeg nok konkludere at java har nøjagtig samme fejltaglese
>> som VB.NET, at alt er pointere Damn, der mistede jeg lige al respekt
>> for java.
>
>Jeg synes du skulle sætte dig bedre ind i ting før du udtaler dig så
>skråsikkert.
Jeg synes ellers i har brugt en masse tid på at forklare mig at jeg tog
fejl, og java indeholder pointere, de kalder dem bare noget andet.
(At et sprog indeholder pointere ser jeg ikke som noget negativt, men
at man tvinges til at bruge dem hele tiden, virker ekstremt tåbeligt).
Mvh
Kent
--
If I wanted a blue screen, I would type "xsetroot -solid blue"
- not D:\WINNT\SETUP
| |
Henry Vest (09-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 09-09-02 19:45 |
|
Kent Friis wrote:
> Kan man ikke oprette en normal variabel? Som i:
>
> class c {};
>
> c foobar;
Ikke når vi taler om en instans af en klasse. Eller jo, man kan godt
oprette en variabel (objektreference), men den peger ikke noget sted hen.
C foo;
// erklærer en objektreference foo af typen C (men laver ikke en instans af
klassen)
foo = new C();
// laver en instans af klassen C, og lader foo pege hen på den.
Dette kan også gøres i ét hug:
C foo = new C();
> I så fald må jeg nok konkludere at java har nøjagtig samme fejltaglese
> som VB.NET, at alt er pointere
Nej, ikke privitive. Man kan ikke have en reference/pointer til en primitv.
int x; // erklærer en variabel x
x = 9; //sætter denne variabel til 9
/Henry
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 20:00 |
|
Den Mon, 9 Sep 2002 20:45:19 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Kan man ikke oprette en normal variabel? Som i:
>>
>> class c {};
>>
>> c foobar;
>
>Ikke når vi taler om en instans af en klasse. Eller jo, man kan godt
>oprette en variabel (objektreference), men den peger ikke noget sted hen.
>
>C foo;
>// erklærer en objektreference foo af typen C (men laver ikke en instans af
>klassen)
>
>foo = new C();
>// laver en instans af klassen C, og lader foo pege hen på den.
>
>Dette kan også gøres i ét hug:
>C foo = new C();
Det begreb hedder i C++ pointere. Referencer er noget andet.
>> I så fald må jeg nok konkludere at java har nøjagtig samme fejltaglese
>> som VB.NET, at alt er pointere
>
>Nej, ikke privitive. Man kan ikke have en reference/pointer til en primitv.
Det var dog en underlig opdeling. I C++ er der ingen forskel, man kan
lave en pointer eller en reference til en int, nøjagtig lige så vel som
man kan lave en variabel af klassen c.
Mvh
Kent
--
IE is the only thing capable of making Netscape look good
- D. Spider in comp.os.linux.advocacy
| |
Henry Vest (09-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 09-09-02 21:58 |
|
Kent Friis wrote:
>>Nej, ikke privitive. Man kan ikke have en reference/pointer til en
>>primitv.
>
> Det var dog en underlig opdeling. I C++ er der ingen forskel, man kan
> lave en pointer eller en reference til en int,
Reelt kan man også lave en reference til en primitiv i Java, man laver bare
en wrapperklasse.
class MyInt {
int x;
}
MyInt i = new MyInt();
i.x = 99;
/Henry
| |
Thorbjoern Ravn Ande~ (09-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 09-09-02 19:26 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >> >> Hvordan er det en forskel? Hvis et sprog ikke giver mulighed for
> >> >> pointer-aritmetik, og iøvrigt altid initialiserer pointeren til
> >> >> null, hvad forhindrer så at du også kan være garanteret at den
> >> >> peger på et gyldig objekt?
> >> >
> >> >At en null-pointer ikke peger på et gyldigt objekt. Short and
> >> >simple.
> >>
> >> Det argument gælder jo også imod javas "referencer".
> >
> >Irrelevant til ovenstående spørgsmål.
>
> Så må der være sket en misforståelse et sted. Jeg argumenterer for
> at pointere og java's "referencer" er det samme, og så kan du da ikke
> bare komme og sige "jamen en null-pointer peger ikke på et gyldigt
> objekt". Det gør da overhovedet ingen forskel, for det gør den heller
> ikke selvom man kalder pointeren for en "reference".
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 19:49 |
|
Den 09 Sep 2002 20:26:10 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >> >> Hvordan er det en forskel? Hvis et sprog ikke giver mulighed for
>> >> >> pointer-aritmetik, og iøvrigt altid initialiserer pointeren til
>> >> >> null, hvad forhindrer så at du også kan være garanteret at den
>> >> >> peger på et gyldig objekt?
>> >> >
>> >> >At en null-pointer ikke peger på et gyldigt objekt. Short and
>> >> >simple.
>> >>
>> >> Det argument gælder jo også imod javas "referencer".
>> >
>> >Irrelevant til ovenstående spørgsmål.
>>
>> Så må der være sket en misforståelse et sted. Jeg argumenterer for
>> at pointere og java's "referencer" er det samme, og så kan du da ikke
>> bare komme og sige "jamen en null-pointer peger ikke på et gyldigt
>> objekt". Det gør da overhovedet ingen forskel, for det gør den heller
>> ikke selvom man kalder pointeren for en "reference".
>
>Grundlæggende er Javas referencer og C's pointere MEGET lig, og virker
>meget ens.
Netop, det man i java kalder referencer svarer (næsten) til det man
i C/C++ kalder pointere.
Så når en Java-sælger står overfor en flok C++ programmører, og
fortæller at Java ikke bruger pointere, men kun referencer, så
glemmer han altså at fortælle at det ikke har noget med referencer
(som C++ programmører kender dem) at gøre.
>Når det så er sagt, er der nogen få og vigtige forskelle. Pointere
>kan pege til en vilkårligt _hukommelsesadresse_ og kan frit veksles
>(svjh) med ints.
Nøjagtig som alle andre typer kan blandes næsten som man har lyst til
i C, ja.
En int hedder stadig en int, selvom man i java ikke kan stoppe et 'A'
ind i den (eller kan man?)
Ligeledes hedder en pointer i min ordbog stadig en pointer, selvom man
ikke kan stoppe et 7-tal ind i den.
>Referencer kan kun pege på ting retuneret fra "new"
>(altså valide objekter) eller null, og der er typecheck på at man ikke
>laver fusk med referencerne.
>
>Pointere kan også pege på null, men dette er værdien for
>"uinitialiseret" og vil på alle de systemer jeg kender [1] give en
>fejl hvis man følger det.
Nøjagtig som en "reference" i java der peger på null giver en fejl,
hvis man følger den.
Mvh
Kent
--
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
| |
Henry Vest (09-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 09-09-02 19:57 |
|
Kent Friis wrote:
> En int hedder stadig en int, selvom man i java ikke kan stoppe et 'A'
> ind i den (eller kan man?)
Det kan man for så vidt godt.
int x = 'A';
'A' er af typen char, der i Java er 2 bytes lang. Da en int er 4 bytes
lang, kan den sagtens indeholde en char.
Hvis man skriver ovenstående x ud, vil man få 65 ud på skærmen.
/Henry
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 20:06 |
|
Den Mon, 9 Sep 2002 20:56:54 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> En int hedder stadig en int, selvom man i java ikke kan stoppe et 'A'
>> ind i den (eller kan man?)
>
>Det kan man for så vidt godt.
>
>int x = 'A';
>
>'A' er af typen char, der i Java er 2 bytes lang. Da en int er 4 bytes
>lang, kan den sagtens indeholde en char.
>
>Hvis man skriver ovenstående x ud, vil man få 65 ud på skærmen.
Ok, jeg troede faktisk at java forhindrede at man fjumrer rundt i
typerne...
Mvh
Kent
--
F0 0F C7 C8 - Intel Pentium bug
| |
Henry Vest (09-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 09-09-02 20:17 |
|
Kent Friis wrote:
> Ok, jeg troede faktisk at java forhindrede at man fjumrer rundt i
> typerne...
Det gør den vel også. Men man kan naturligvis konventere mellem typer når
det "giver mening". En char er kortere end en int, derfor kan man uden
videre stoppe en char ind i en int. Det omvendte ville ikke uden videre gå
godt.
int x = 99;
char c;
c = i; // kompilefejl
Her skal man angive at der skal konventeres:
c = (char) i;
/Henry
| |
Thorbjoern Ravn Ande~ (09-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 09-09-02 21:53 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Ok, jeg troede faktisk at java forhindrede at man fjumrer rundt i
> typerne...
Bevidst design for at gøre det nemmere at lokke C programmører til at
bruge Java.
Bemærk iøvirgt at dette er basale typer. Javas objektsystem har intet
med dette at gøre som sådan, og alt nedarver fra java.lang.Object.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 17:03 |
|
Den 09 Sep 2002 22:53:08 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Ok, jeg troede faktisk at java forhindrede at man fjumrer rundt i
>> typerne...
>
>Bevidst design for at gøre det nemmere at lokke C programmører til at
>bruge Java.
>
>Bemærk iøvirgt at dette er basale typer. Javas objektsystem har intet
>med dette at gøre som sådan, og alt nedarver fra java.lang.Object.
Endnu en uhensigtsmæssighed i java. Det svarer til at sige at objekt
A og objekt B på et eller andet niveau er det samme.
Fx. en vittighed og en bil har på et eller andet niveau noget til
fælles. Det giver jo overhovedet ingen mening.
Derudover giver det også problemer med en grundlæggende OO-ting, nemlig
multipel arv. Det virker fint så længe at de to baseklasser ikke arver
fra den samme klasse, men så snart de arver fra den samme klasse, så
kommer problemet med om denne klasse skal findes en eller to gange i
hierakiet.
Så kan man naturligvis løse det som i VB, og bare lade være med at have
multipel arv, og så sige til programmørerne: "Hvis i har læst videre
end kapitel 2 i OO-bogen, så må I finde et rigtigt OO-sprog".
Mvh
Kent
--
Hvis man ikke kan lide klassisk musik, er det sandsynligvis fordi
lydkvaliteten er for dårlig. Klassisk musik kræver et godt anlæg.
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 17:41 |
|
Kent Friis wrote:
>>Bemærk iøvirgt at dette er basale typer. Javas objektsystem har intet
>>med dette at gøre som sådan, og alt nedarver fra java.lang.Object.
>
> Endnu en uhensigtsmæssighed i java.
Nej, tværtimod er der mange fordele ved det.
> Det svarer til at sige at objekt
> A og objekt B på et eller andet niveau er det samme.
Det vil sige at alle objekter har visse fællestræk, ja. Hvilket kan være
yderst anvendelig.
> Fx. en vittighed og en bil har på et eller andet niveau noget til
> fælles. Det giver jo overhovedet ingen mening.
Jo, i allerhøjeste grad.
> Så kan man naturligvis løse det som i VB, og bare lade være med at have
> multipel arv,
Java har heller ikke multipel arv.
/Henry
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 17:56 |
|
Henry Vest <henry_vest@get2net.dk> writes:
> > Så kan man naturligvis løse det som i VB, og bare lade være med at have
> > multipel arv,
>
> Java har heller ikke multipel arv.
Til gengaeld har det interfaces som kan give noget der ligner.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 18:40 |
|
Den Tue, 10 Sep 2002 18:41:09 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>>>Bemærk iøvirgt at dette er basale typer. Javas objektsystem har intet
>>>med dette at gøre som sådan, og alt nedarver fra java.lang.Object.
>>
>> Endnu en uhensigtsmæssighed i java.
>
>Nej, tværtimod er der mange fordele ved det.
Jeg har allerede nævnt et par ulemper, kan du også nævne nogen fordele?
Nogen der ikke kræver at man synes at Java er genialt for at kunne se
fordelen?
>> Det svarer til at sige at objekt
>> A og objekt B på et eller andet niveau er det samme.
>
>Det vil sige at alle objekter har visse fællestræk, ja. Hvilket kan være
>yderst anvendelig.
>
>> Fx. en vittighed og en bil har på et eller andet niveau noget til
>> fælles. Det giver jo overhovedet ingen mening.
>
>Jo, i allerhøjeste grad.
Ok, så forklar lige hvad en vittighed og en bil har tilfælles. (Så skal
jeg nok vise din forklaring til min mekaniker, og se om han er enig).
>> Så kan man naturligvis løse det som i VB, og bare lade være med at have
>> multipel arv,
>
>Java har heller ikke multipel arv.
Ok, dumpet som OO-sprog.
Mvh
Kent
--
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 18:41 |
|
Den 10 Sep 2002 18:56:19 +0200 skrev Thorbjoern Ravn Andersen:
>Henry Vest <henry_vest@get2net.dk> writes:
>
>> > Så kan man naturligvis løse det som i VB, og bare lade være med at have
>> > multipel arv,
>>
>> Java har heller ikke multipel arv.
>
>Til gengaeld har det interfaces som kan give noget der ligner.
Det er det jeg kalder "cut'n'paste arv". Du kan arve den første linie
int DoSomething(int x), men du kan ikke arve funktionaliteten. Denne
skal så cut'n'pastes, forudsat man overhovedet har sourcen til det man
arver fra.
Mvh
Kent
--
6.0 FDiv 3.0 = 1.999773462873 - Intel Pentium bug
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 18:59 |
|
Kent Friis wrote:
> Jeg har allerede nævnt et par ulemper, kan du også nævne nogen fordele?
Ja, det forhold at alle objekter i Java er instanser af en klasse der til
syvende og sidst arver fra samme klasse (i Java kaldet Object), gør at der
er visse basale metoder man kan kalde på ALLE objekter.
> Nogen der ikke kræver at man synes at Java er genialt for at kunne se
> fordelen?
Din fanatisme er utrolig.
> Ok, så forklar lige hvad en vittighed og en bil har tilfælles.
I Javas klasse Object er der defineret 11 metoder. Bl.a. toString() der gør
at man kan få en stringrepræsentation af alle objekter, equals() der
benyttes når man skal bestemme om to objekter er ens indholdsmæssigt,
clone() der benyttes når man skal lave en kopi af et objekt, notify() og
wait() der begge har at gøre med trådprogrammering.
> (Så skal
> jeg nok vise din forklaring til min mekaniker, og se om han er enig).
Er din mekaniker programmør?
/Henry
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 19:10 |
|
Den Tue, 10 Sep 2002 19:59:02 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Jeg har allerede nævnt et par ulemper, kan du også nævne nogen fordele?
>
>Ja, det forhold at alle objekter i Java er instanser af en klasse der til
>syvende og sidst arver fra samme klasse (i Java kaldet Object), gør at der
>er visse basale metoder man kan kalde på ALLE objekter.
Og det giver hvilken fordel?
VB har iøvrigt samme ulempe, og det medfører at der findes en
"tostring" metode på alle objekter, og derfor har man så været nødt
til at lave en tostring der blot returnerer navnet på typen (i.e.
totalt ubrugelig) på alle de klasser hvor en tostring ikke giver mening.
>> Nogen der ikke kræver at man synes at Java er genialt for at kunne se
>> fordelen?
>
>Din fanatisme er utrolig.
>
>> Ok, så forklar lige hvad en vittighed og en bil har tilfælles.
>
>I Javas klasse Object er der defineret 11 metoder. Bl.a. toString() der gør
>at man kan få en stringrepræsentation af alle objekter, equals() der
>benyttes når man skal bestemme om to objekter er ens indholdsmæssigt,
>clone() der benyttes når man skal lave en kopi af et objekt, notify() og
>wait() der begge har at gøre med trådprogrammering.
tostring: har jeg været inde på ovenfor, i forb. med VB.
equals: Hvad er der nu i vejen med if(a==b) ?
clone: Hvad er der nu i vejen med a=b; ?
notify,wait: hvad skal threads nu blandes ind i samtlige objekter for?
>> (Så skal
>> jeg nok vise din forklaring til min mekaniker, og se om han er enig).
>
>Er din mekaniker programmør?
Nej, netop ikke, men han har forstand på biler. Jeg forsøger at relatere
det til den virkelige verden.
Mvh
Kent
--
Desuden kan jeg ikke se nogen grund til at springe over hvor gærdet er
lavest, når man kan vente på at det alligevel bliver revet ned fordi
der skal bygges en omfartsvej...
- Claus Frørup og Asbjørn Christensen i dk.snak.
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 19:14 |
|
Den Tue, 10 Sep 2002 19:59:02 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Nogen der ikke kræver at man synes at Java er genialt for at kunne se
>> fordelen?
>
>Din fanatisme er utrolig.
Jeg startede faktisk med at være overrasket over at se at java har
pointere (det der i C++ hedder pointere, uanset hvad det hedder i java).
Jeg har altid hørt at Java har kopieret alle de gode ting fra C++ - og
så får jeg at vide af et par java-folk, at det tværtimod har kopieret
alle de ting jeg hader ved VB (Eller MS har kopieret dem fra Java).
Jeg troede java var godt, men det har jeg efterhånden (i denne
diskussion) fundet ud af at jeg er blevet snydt.
Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 19:16 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Det er det jeg kalder "cut'n'paste arv". Du kan arve den første linie
> int DoSomething(int x), men du kan ikke arve funktionaliteten. Denne
> skal så cut'n'pastes, forudsat man overhovedet har sourcen til det man
> arver fra.
Oeh, har du ikke tidligere udtalt at du ikke ved noget om Java?
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 19:22 |
|
Den 10 Sep 2002 20:16:28 +0200 skrev Thorbjoern Ravn Andersen:
>
>> Det er det jeg kalder "cut'n'paste arv". Du kan arve den første linie
>> int DoSomething(int x), men du kan ikke arve funktionaliteten. Denne
>> skal så cut'n'pastes, forudsat man overhovedet har sourcen til det man
>> arver fra.
>
>Oeh, har du ikke tidligere udtalt at du ikke ved noget om Java?
Nu har jeg tilfældigvis tidligere fået forklaret at "interface" i
Java virker præcist lige som "interface" i Visual Basic.
Har jeg misforstået noget?
Mvh
Kent
--
Hvis man ikke kan lide klassisk musik, er det sandsynligvis fordi
lydkvaliteten er for dårlig. Klassisk musik kræver et godt anlæg.
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 19:21 |
|
Kent Friis wrote:
> Og det giver hvilken fordel?
Visse metoder giver mening for alle objekter - derfor er det indlysende at
definere dem i en fælles "rod"-klasse.
> equals: Hvad er der nu i vejen med if(a==b) ?
Ingenting, men det betyder noget andet (tjekker for ens identitet).
> clone: Hvad er der nu i vejen med a=b; ?
Ingenting, men det betyder noget andet (kopierer objektreferencen, ikke
objektet).
> notify,wait: hvad skal threads nu blandes ind i samtlige objekter for?
Fordi samtlige objekter kan berøres af en tråd.
/Henry
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 19:24 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Jeg troede java var godt, men det har jeg efterhånden (i denne
> diskussion) fundet ud af at jeg er blevet snydt.
Har du lyst til at diskutere om sex er godt?
Du foreslaaes at proeve det, med en positiv holdning.
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 19:25 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Nu har jeg tilfældigvis tidligere fået forklaret at "interface" i
> Java virker præcist lige som "interface" i Visual Basic.
>
> Har jeg misforstået noget?
Aner det ikke. Jeg har aldrig kodet i VB. Det proever jeg at leve
med.
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 19:37 |
|
Den Tue, 10 Sep 2002 20:21:21 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Og det giver hvilken fordel?
>
>Visse metoder giver mening for alle objekter - derfor er det indlysende at
>definere dem i en fælles "rod"-klasse.
>
>> equals: Hvad er der nu i vejen med if(a==b) ?
>
>Ingenting, men det betyder noget andet (tjekker for ens identitet).
I C++ sammenligner det to objekter.
>> clone: Hvad er der nu i vejen med a=b; ?
>
>Ingenting, men det betyder noget andet (kopierer objektreferencen, ikke
>objektet).
Igen: I C++ bliver objektet kopieret.
Kun hvis man bruger pointere, virker det i C++ som du beskriver, men
ok, hvis alt er pointere[1] i Java, så er man jo nødt til at finde på
en omvej. Men så kan jeg ikke se hvorfor de ikke bare kan bruge
(*a)=(*b);
>> notify,wait: hvad skal threads nu blandes ind i samtlige objekter for?
>
>Fordi samtlige objekter kan berøres af en tråd.
Jeg troede at "tråd" skulle forstås i sammenhængen thread, altså en
måde at få nogle typer programmer til at lave flere ting på en gang.
Men det kan det ikke være, for så ville objekterne i alle de programmer
der ikke er multithreadede jo ikke blive berørt.
Mvh
Kent
[1] Kald dem bare referencer når i snakker sammen internt, men når i
snakker med en C eller især C++ programmør, er det absolut at en fordel
at sige pointer, for ikke at forvirre, så man tror at i snakker om det
der i C++ hedder referencer.
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 19:39 |
|
Den 10 Sep 2002 20:24:56 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Nu har jeg tilfældigvis tidligere fået forklaret at "interface" i
>> Java virker præcist lige som "interface" i Visual Basic.
>>
>> Har jeg misforstået noget?
>
>Aner det ikke. Jeg har aldrig kodet i VB. Det proever jeg at leve
>med.
Ja, men har jeg ret i at "interface" kun arver metodenavne og parametre,
og man så er nødt til at cut'n'paste indholdet af metoderne, eller har
jeg misforstået det?
Mvh
Kent
--
Those who write "Optimized for Netscape" og "Best viewed with MSIE"
never figured out the difference between the WWW and a
Word Perfect 4.2 Document.
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 19:53 |
|
Kent Friis wrote:
> en omvej. Men så kan jeg ikke se hvorfor de ikke bare kan bruge
> (*a)=(*b);
Fordi den notationsform slet ikke findes i Java.
> Jeg troede at "tråd" skulle forstås i sammenhængen thread, altså en
> måde at få nogle typer programmer til at lave flere ting på en gang.
Korrekt.
> Men det kan det ikke være, for så ville objekterne i alle de programmer
> der ikke er multithreadede jo ikke blive berørt.
Den forstod jeg ikke.
> [1] Kald dem bare referencer når i snakker sammen internt, men når i
> snakker med en C eller især C++ programmør, er det absolut at en fordel
> at sige pointer, for ikke at forvirre, så man tror at i snakker om det
> der i C++ hedder referencer.
Kald dem bare pointere internt, men når i snakker med Java-programmører så
kald dem (objekt)referencer ...
/Henry
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 19:58 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Jeg troede at "tråd" skulle forstås i sammenhængen thread, altså en
> måde at få nogle typer programmer til at lave flere ting på en gang.
> Men det kan det ikke være, for så ville objekterne i alle de programmer
> der ikke er multithreadede jo ikke blive berørt.
Multi-traadning i Java er meget nemt (og tillader brug af flere CPU'er
hvis operativsystemet understoetter det, og det problem der skal
loeses er paralleliserbart).
Kender du til multiprogrammering og hvorfor det er smart?
> [1] Kald dem bare referencer når i snakker sammen internt, men når i
> snakker med en C eller især C++ programmør, er det absolut at en fordel
> at sige pointer, for ikke at forvirre, så man tror at i snakker om det
> der i C++ hedder referencer.
Det hedder det nu engang i Java-verdenen.
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 19:59 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Ja, men har jeg ret i at "interface" kun arver metodenavne og parametre,
> og man så er nødt til at cut'n'paste indholdet af metoderne, eller har
> jeg misforstået det?
Jeg tror du har misforstaaet det. Et interface i java indeholder ikke kode.
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 19:59 |
|
Den Tue, 10 Sep 2002 20:52:55 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> en omvej. Men så kan jeg ikke se hvorfor de ikke bare kan bruge
>> (*a)=(*b);
>
>Fordi den notationsform slet ikke findes i Java.
Med "de" menes der "dem der opfandt java".
>> Jeg troede at "tråd" skulle forstås i sammenhængen thread, altså en
>> måde at få nogle typer programmer til at lave flere ting på en gang.
>
>Korrekt.
>
>> Men det kan det ikke være, for så ville objekterne i alle de programmer
>> der ikke er multithreadede jo ikke blive berørt.
>
>Den forstod jeg ikke.
Du skrev at alle objekter er berørte af tråde. Men objekter i et
program der ikke bruger threads, vil da ikke blive berørt af threads.
Mvh
Kent
--
unsigned long main = 0xC8C70FF0;
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 20:03 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Du skrev at alle objekter er berørte af tråde. Men objekter i et
> program der ikke bruger threads, vil da ikke blive berørt af threads.
Ikke aktuelt. Alle Java-programmer bruger threads.
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 20:05 |
|
Den 10 Sep 2002 20:57:53 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Jeg troede at "tråd" skulle forstås i sammenhængen thread, altså en
>> måde at få nogle typer programmer til at lave flere ting på en gang.
>> Men det kan det ikke være, for så ville objekterne i alle de programmer
>> der ikke er multithreadede jo ikke blive berørt.
>
>Multi-traadning i Java er meget nemt (og tillader brug af flere CPU'er
>hvis operativsystemet understoetter det, og det problem der skal
>loeses er paralleliserbart).
>
>Kender du til multiprogrammering og hvorfor det er smart?
Jeg kender lidt til det, og jeg ved hvorfor det ikke er smart,
sammenlignet med processer.
Jeg har ikke hørt nogen argumenter for hvorfor threads skulle være
smart, udover "windows er langsom til at oprette processer" (og det
skulle Solaris vist nok også være).
>> [1] Kald dem bare referencer når i snakker sammen internt, men når i
>> snakker med en C eller især C++ programmør, er det absolut at en fordel
>> at sige pointer, for ikke at forvirre, så man tror at i snakker om det
>> der i C++ hedder referencer.
>
>Det hedder det nu engang i Java-verdenen.
Ja, men når man forsøger at forklare en C++ programmør om Java, så
er man nødt til at bruge et sprog som denne forstår.
Eller siger du også "bare ligeud og til højre", når en tysker spørger
om "wie geht's zur Kaufmann?"
>Du maa huske at bruge ordet "referencer" naar du taler med Javafolk,
>da de ellers bliver forvirrede og ikke forstaar hvad du mener.
Jeg går ud fra at alle programmører ved hvad pointere er. Der skulle
ikke gerne være nogen begrebsforvirring, da pointer altid betyder
det samme.
Og hvis jeg skal bruge "referencer" når jeg snakker om pointere,
hvilket ord skal jeg så bruge når jeg snakker om (C++ style) referencer?
--
F0 0F C7 C8 - Intel Pentium bug
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 20:06 |
|
Den 10 Sep 2002 20:58:50 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Ja, men har jeg ret i at "interface" kun arver metodenavne og parametre,
>> og man så er nødt til at cut'n'paste indholdet af metoderne, eller har
>> jeg misforstået det?
>
>Jeg tror du har misforstaaet det. Et interface i java indeholder ikke kode.
Er det ikke også det jeg siger?
Man arver kun metodenavne og parametre.
Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 20:11 |
|
Den 10 Sep 2002 21:02:52 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Du skrev at alle objekter er berørte af tråde. Men objekter i et
>> program der ikke bruger threads, vil da ikke blive berørt af threads.
>
>Ikke aktuelt. Alle Java-programmer bruger threads.
Det var da det mest sindsyge programmeringssprog jeg nogensinde har
hørt om. Det skulle da meget gerne være et valg der foretages af
designeren / programmøren.
Og så passer det vist meget godt med et citat...
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 20:28 |
|
Kent Friis wrote:
> Jeg går ud fra at alle programmører ved hvad pointere er.
Hvorfor i al verden gør du det? En Java-programmør behøver ikke vide det.
En Perl-programmør behøver da vist heller ikke vide det. Og der er vist
heller ikke pointere i Javascript, VBScrip mv.
> Og hvis jeg skal bruge "referencer" når jeg snakker om pointere,
> hvilket ord skal jeg så bruge når jeg snakker om (C++ style) referencer?
Det må vel afhænge af hvilket sprog du taler om. Når du snakker om C++, så
snak om pointere og referencer. Når du snakker om Java, så snak om
referencer.
/Henry
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 20:22 |
|
Kent Friis wrote:
> Med "de" menes der "dem der opfandt java".
Du mener altså at denne notationsform er så ufattelig smart, at det er en
forbrydelse at gøre det på en anden måde.
> Du skrev at alle objekter er berørte af tråde.
Jeg skrev at det kunne de være.
> Men objekter i et
> program der ikke bruger threads, vil da ikke blive berørt af threads.
Og...?
/Henry
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 20:36 |
|
Den Tue, 10 Sep 2002 21:27:41 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Jeg går ud fra at alle programmører ved hvad pointere er.
>
>Hvorfor i al verden gør du det? En Java-programmør behøver ikke vide det.
Det er da kun fordi at Sun-folkene ikke kunne stave til pointer, og
så kaldte dem referencer i stedet for.
>En Perl-programmør behøver da vist heller ikke vide det. Og der er vist
>heller ikke pointere i Javascript, VBScrip mv.
"Perl-programmør" kan jeg måske godt acceptere, men i hvert fald
javascript er da noget som web-designere bruger til at genere folk med
(alle de popup-vinduer der skal forhindre at man opdager hvor grimt
deres website er, og sådan noget).
>> Og hvis jeg skal bruge "referencer" når jeg snakker om pointere,
>> hvilket ord skal jeg så bruge når jeg snakker om (C++ style) referencer?
>
>Det må vel afhænge af hvilket sprog du taler om. Når du snakker om C++, så
>snak om pointere og referencer. Når du snakker om Java, så snak om
>referencer.
Og når jeg står (stod) som totalt uvidende om Java, og hører på at
en Java-sælger skal fortælle C++ folk om alle fordelene ved Java?
Skal man så som C++ programmør lære at programmere Java, inden man
kan forstå hvad "sælgeren" snakker om?
Mvh
Kent
--
Indlæringskurven til Linux er stejl, til tider lodret... Men for katten
hvor er udsigten på toppen dog fantastisk
- Michael G. Vendelbo i dk.snak
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 20:45 |
|
Den Tue, 10 Sep 2002 21:22:17 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Med "de" menes der "dem der opfandt java".
>
>Du mener altså at denne notationsform er så ufattelig smart, at det er en
>forbrydelse at gøre det på en anden måde.
Nej, jeg mener at det ikke duer som argument for hvorfor man har brug
for object.equals og object.clone (det har man jo ikke, bare se på
C++). Og derfor er der heller ikke noget argument for hvorfor man har
brug for object.
Var det iøvrigt ikke en OO-lærer der sagde "Hvis I nogensinde laver en
klasse der hedder object, så er I dumpet"? En klasse og et objekt er
absolut ikke det samme.
>> Du skrev at alle objekter er berørte af tråde.
>
>Jeg skrev at det kunne de være.
Alle biler kan også være gule. Det beviser da ikke noget.
Mvh
Kent
--
Linux 0.12 is out
Windows XP is now obsolete!!!
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 20:45 |
|
Kent Friis wrote:
> Det er da kun fordi at Sun-folkene ikke kunne stave til pointer, og
> så kaldte dem referencer i stedet for.
Tja, eller fordi reference er et lige så godt ord.
> "Perl-programmør" kan jeg måske godt acceptere, men i hvert fald
> javascript er da noget som web-designere bruger til at genere folk med
Det kan nu også godt bruges til noget nyttigt. Det kan i øvrigt også bruges
som scriptsprog i ASP - men nu ved jeg godt at jeg har sagt et slemt
bandeord.
> (alle de popup-vinduer der skal forhindre at man opdager hvor grimt
> deres website er, og sådan noget).
He he, ja kender det godt.
/Henry
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 20:54 |
|
Kent Friis wrote:
> Nej, jeg mener at det ikke duer som argument for hvorfor man har brug
> for object.equals og object.clone
Det er altså den måde man har valgt at gøre det på i Java.
> Og derfor er der heller ikke noget argument for hvorfor man har
> brug for object.
Du mangler stadig notify og wait....
> Var det iøvrigt ikke en OO-lærer der sagde "Hvis I nogensinde laver en
> klasse der hedder object, så er I dumpet"?
Klassen hedder heller ikke object. Den hedder Object.
> En klasse og et objekt er
> absolut ikke det samme.
Det er der vist ingen der har påstået.
> Alle biler kan også være gule. Det beviser da ikke noget.
??
/Henry
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 21:33 |
|
Den Tue, 10 Sep 2002 21:44:41 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Det er da kun fordi at Sun-folkene ikke kunne stave til pointer, og
>> så kaldte dem referencer i stedet for.
>
>Tja, eller fordi reference er et lige så godt ord.
Det er det ikke, når det giver så meget forvirring. Åbenbart så meget
at selv folk der har forstand på Java siger at "Java har ikke pointere",
når det korrekte ville være "i Java hedder de ikke pointere".
Og det bliver absolut ikke bedre af at hugge et ord der betyder noget
andet i andre sprog.
Mvh
Kent
--
echo f 0:0 ffff 0 | debug
| |
Kent Friis (10-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 10-09-02 21:36 |
|
Den Tue, 10 Sep 2002 21:53:53 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Nej, jeg mener at det ikke duer som argument for hvorfor man har brug
>> for object.equals og object.clone
>
>Det er altså den måde man har valgt at gøre det på i Java.
>
>> Og derfor er der heller ikke noget argument for hvorfor man har
>> brug for object.
>
>Du mangler stadig notify og wait....
Dem må jeg så henføre under "tåbeligheder der overhovedet ingen
mening giver".
>> Var det iøvrigt ikke en OO-lærer der sagde "Hvis I nogensinde laver en
>> klasse der hedder object, så er I dumpet"?
>
>Klassen hedder heller ikke object. Den hedder Object.
Sorry, jeg har vist set for meget VB-kode. Men meningen er det samme.
>> En klasse og et objekt er
>> absolut ikke det samme.
>
>Det er der vist ingen der har påstået.
Og derfor kalder man ikke en klasse for Object.
Et objekt er en bestemt instans af en klasse. Det er IKKE en klasse.
Mvh
Kent
--
"Handlingen blev afbrudt pga. computerens begrænsede effekt"
- Windows NT på en Pentium III 550 MHz
| |
Henry Vest (10-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 10-09-02 22:13 |
|
Kent Friis wrote:
>>Du mangler stadig notify og wait....
>
> Dem må jeg så henføre under "tåbeligheder der overhovedet ingen
> mening giver".
Fordi sådan er det ikke i C++ ... Naturligvis giver det mening. Hvad er i
øvrigt din stærke modstand mod at alle klasser skal arve fra samme klasse,
den synes jeg ikke at have set noget argument for.
> Og derfor kalder man ikke en klasse for Object.
For det gør man ikke i C++ ...
> Et objekt er en bestemt instans af en klasse.
Ja vist.
/Henry
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 23:07 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >Kender du til multiprogrammering og hvorfor det er smart?
>
> Jeg kender lidt til det, og jeg ved hvorfor det ikke er smart,
> sammenlignet med processer.
Ok. Teoretisk kendskab. Vi lader det hvile der, med en bemærkning om
at threads er smarte.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 23:08 |
|
leeloo@phreaker.net (Kent Friis) writes:
> javascript er da noget som web-designere bruger til at genere folk med
> (alle de popup-vinduer der skal forhindre at man opdager hvor grimt
> deres website er, og sådan noget).
| |
Thorbjoern Ravn Ande~ (10-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 10-09-02 23:17 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >Ikke aktuelt. Alle Java-programmer bruger threads.
>
> Det var da det mest sindsyge programmeringssprog jeg nogensinde har
> hørt om. Det skulle da meget gerne være et valg der foretages af
> designeren / programmøren.
| |
Jens Axel Søgaard (10-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 10-09-02 23:52 |
|
Kent Friis wrote:
> Det er det ikke, når det giver så meget forvirring.
> Åbenbart så meget at selv folk der har forstand på Java
> siger at "Java har ikke pointere", når det korrekte ville
> være "i Java hedder de ikke pointere".
En pointer kan indeholde en vilkårlig lageradresse.
Det kan en reference ikke. Ergo er pointere mere
generelle end referencer.
Lad os prøve at betragte en pointer som en abstrakt
datatype.
Pointeroperationer:
1. pointer == pointer -> sandhedsværdi
2. pointer + tal -> pointer
3. tal -> pointer
4. pointer -> tal
Lad os så se på referencer:
1. reference == reference -> sandsværdi
2. mangler
3. mangler
4. mangler
Alt det man kan lave med en reference kan man lave med pointere.
Det er langt fra alt man kan lave en pointer, som man kan lave med
en reference.
Vil du nu påstå, at referencer er det samme som pointere?
I denne tråd har udtrykket "pille ved en pointer" optrådt. Hermed menes
2,3 og 4.
--
Jens Axel Søgaard
| |
Jens Axel Søgaard (10-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 10-09-02 23:56 |
|
Kent Friis wrote:
> Den 10 Sep 2002 20:58:50 +0200 skrev Thorbjoern Ravn
> Andersen:
>> leeloo@phreaker.net (Kent Friis) writes:
>>
>>> Ja, men har jeg ret i at "interface" kun arver
>>> metodenavne og parametre, og man så er nødt til at
>>> cut'n'paste indholdet af metoderne, eller har jeg
>>> misforstået det?
>>
>> Jeg tror du har misforstaaet det. Et interface i java
>> indeholder ikke kode.
>
> Er det ikke også det jeg siger?
>
> Man arver kun metodenavne og parametre.
Hvorfor vil du så cut'n'paste indholdet af metoderne?
--
Jens Axel Søgaard
| |
Jens Axel Søgaard (10-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 10-09-02 23:58 |
|
Thorbjoern Ravn Andersen wrote:
>>> "A computer is a state machine.
>>> Threads are for people who can't program state
>>> machines." - Alan Cox
Hvilken kontekst er der?
Kan det tænkes, at den gode Alan refererer til, at han
ikke kan bruge tråde, når han laver dele til kernen?
--
Jens Axel Søgaard
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 16:20 |
|
Den Tue, 10 Sep 2002 23:13:27 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>>>Du mangler stadig notify og wait....
>>
>> Dem må jeg så henføre under "tåbeligheder der overhovedet ingen
>> mening giver".
>
>Fordi sådan er det ikke i C++ ... Naturligvis giver det mening. Hvad er i
>øvrigt din stærke modstand mod at alle klasser skal arve fra samme klasse,
>den synes jeg ikke at have set noget argument for.
1. Det har ikke noget med virkeligheden at gøre. (Der er i hvert fald
endnu ikke nogen der har kunnet forklare mig hvad en bil og en vittighed
har tilfælles IRL).
2. Det giver problemer med multibel arv. At fjerne en så grunlæggende
OO-ting som multipel arv betragter jeg som en dårlig løsning på et
problem man reelt selv har skabt.
>> Og derfor kalder man ikke en klasse for Object.
>
>For det gør man ikke i C++ ...
Nej, fordi det IKKE er det samme.
>> Et objekt er en bestemt instans af en klasse.
>
>Ja vist.
DERFOR.
Mvh
Kent
--
Hvis man ikke kan lide klassisk musik, er det sandsynligvis fordi
lydkvaliteten er for dårlig. Klassisk musik kræver et godt anlæg.
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 16:24 |
|
Den 11 Sep 2002 00:06:40 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >Kender du til multiprogrammering og hvorfor det er smart?
>>
>> Jeg kender lidt til det, og jeg ved hvorfor det ikke er smart,
>> sammenlignet med processer.
>
>Ok. Teoretisk kendskab. Vi lader det hvile der, med en bemærkning om
>at threads er smarte.
Jeg har skam brugt threads adskillige gange. Og hver eneste gang har
konklusionen været "Fa*en til p*s, hvordan undgår vi det?" Fx. har jeg
været med til at omskrive en måneds arbejde, fordi systemet - efter at
være testet grundigt, og virkede uden problemer - overhovedet ikke
virkede på en maskine med en anden clockfrekvens.
Ikke en eneste gang har jeg oplevet at få noget positivt ud af at bruge
threads.
Din bemærkning om at "threads er smarte" får dig til at lyde som en
sælger i den nærmeste radio-TV butik. Kom med argumenter, hvis du vil
tages alvorligt.
Mvh
Kent
--
Those who write "Optimized for Netscape" og "Best viewed with MSIE"
never figured out the difference between the WWW and a
Word Perfect 4.2 Document.
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 16:25 |
|
Den 11 Sep 2002 00:07:42 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> javascript er da noget som web-designere bruger til at genere folk med
>> (alle de popup-vinduer der skal forhindre at man opdager hvor grimt
>> deres website er, og sådan noget).
>
>Skift til Mozilla - så kan du blive fri for disse.
Det har jeg skam allerede gjort. Men det ændrer ikke på at det er det
javascript bruges til.
Mvh
Kent
--
The frozen north will hatch a flightless bird,
who will spread his wings and dominate the earth
And cause an empire by the sea to fall
To the astonishment, and delight of all.
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 16:28 |
|
Den 11 Sep 2002 00:16:35 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >Ikke aktuelt. Alle Java-programmer bruger threads.
>>
>> Det var da det mest sindsyge programmeringssprog jeg nogensinde har
>> hørt om. Det skulle da meget gerne være et valg der foretages af
>> designeren / programmøren.
>
>Som standard køres Main-metoden i en thread. Dvs selv simple
>programmer kører i en trådet model - her kan programmøren bare se bort
>fra det.
"en thread" giver overhovedet ingen mening. Der skal være to, før et
program kan siges at bruge threads.
>> Og så passer det vist meget godt med et citat...
>>
>> "A computer is a state machine.
>> Threads are for people who can't program state machines."
>> - Alan Cox
>
>Jeg går ud fra at du ved hvad en tilstandsmaskine er?
Jeg ved hvad en state machine er, ja. Typisk en state-variabel, en
select(), og en switch proppet ind i en while-løkke. En
"tilstandsmaskine" lyder som en ordbogs-oversættelse fra folkene der
gav os "programmel", "maskinel" og "pegere"...
Mvh
Kent
--
If you think about it, Windows XP is actually the OS that
started as "Microsoft OS/2 NT 3.0"
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 16:34 |
|
Kent Friis wrote:
> Det har jeg skam allerede gjort. Men det ændrer ikke på at det er det
> javascript bruges til.
Som sagt: Det kan bruges til meget andet.
/Henry
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 16:43 |
|
Den Wed, 11 Sep 2002 00:57:35 +0200 skrev Jens Axel Søgaard:
>Thorbjoern Ravn Andersen wrote:
>
>>>> "A computer is a state machine.
>>>> Threads are for people who can't program state
>>>> machines." - Alan Cox
>
>Hvilken kontekst er der?
>
>Kan det tænkes, at den gode Alan refererer til, at han
>ikke kan bruge tråde, når han laver dele til kernen?
Nope, det var et whitepaper fra IBM om at Linux' scheduler havde
problemer med programmer med flere tusinde threads. Som jeg læser
det, forsøgte at fortælle at det var ikke Linux der havde et problem,
det var programmerne der var dårligt designede.
Mvh
Kent
--
Exception 0E in module IFSMGR.VXD
Press control-alt-delete to reboot
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 16:46 |
|
Den Wed, 11 Sep 2002 00:52:16 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>
>> Det er det ikke, når det giver så meget forvirring.
>> Åbenbart så meget at selv folk der har forstand på Java
>> siger at "Java har ikke pointere", når det korrekte ville
>> være "i Java hedder de ikke pointere".
>
>En pointer kan indeholde en vilkårlig lageradresse.
>Det kan en reference ikke. Ergo er pointere mere
>generelle end referencer.
>
>Lad os prøve at betragte en pointer som en abstrakt
>datatype.
>
>Pointeroperationer:
>
> 1. pointer == pointer -> sandhedsværdi
Ok.
> 2. pointer + tal -> pointer
> 3. tal -> pointer
> 4. pointer -> tal
De tre gælder i C, men ikke nødvendigvis i alle sprog. Fx. mener jeg
ikke at de er tilladt i Pascal (Turbo Pascal havde også pointere).
>Lad os så se på referencer:
>
> 1. reference == reference -> sandsværdi
> 2. mangler
> 3. mangler
> 4. mangler
>
>Alt det man kan lave med en reference kan man lave med pointere.
>Det er langt fra alt man kan lave en pointer, som man kan lave med
>en reference.
>
>Vil du nu påstå, at referencer er det samme som pointere?
Jeg påstår at det der i Java hedder referencer svarer mere til det
der i C++ hedder pointere, end det svarer til det der i C++ hedder
referencer.
Mvh
Kent
--
Gilthoniel, A Elbereth
Aiya elenion ancalima!
- Tolkien, "The Lord of the Rings"
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 16:47 |
|
Den Wed, 11 Sep 2002 00:55:43 +0200 skrev Jens Axel Søgaard:
>Kent Friis wrote:
>> Den 10 Sep 2002 20:58:50 +0200 skrev Thorbjoern Ravn
>> Andersen:
>>> leeloo@phreaker.net (Kent Friis) writes:
>>>
>>>> Ja, men har jeg ret i at "interface" kun arver
>>>> metodenavne og parametre, og man så er nødt til at
>>>> cut'n'paste indholdet af metoderne, eller har jeg
>>>> misforstået det?
>>>
>>> Jeg tror du har misforstaaet det. Et interface i java
>>> indeholder ikke kode.
>>
>> Er det ikke også det jeg siger?
>>
>> Man arver kun metodenavne og parametre.
>
>Hvorfor vil du så cut'n'paste indholdet af metoderne?
Fordi at ellers brokker compileren sig ("class must implement
method x"). Hvis det var rigtig arv, ville den blive arvet, og det
ville derfor ikke være nødvendigt med cut'n'paste.
Mvh
Kent
--
If you think about it, Windows XP is actually the OS that
started as "Microsoft OS/2 NT 3.0"
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 16:31 |
|
Kent Friis wrote:
> 1. Det har ikke noget med virkeligheden at gøre. (Der er i hvert fald
> endnu ikke nogen der har kunnet forklare mig hvad en bil og en vittighed
> har tilfælles IRL).
I programmeringssammenhæng giver det mening, og det er det relevante her.
Programmering er en model af virkeligheden, det ER ikke virkeligheden.
> 2. Det giver problemer med multibel arv.
Hvorfor det? En fælles rodklasse forhinder da ikke multibel arv, det er to
adskilte ting.
/Henry
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 17:08 |
|
Den Wed, 11 Sep 2002 17:30:34 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> 1. Det har ikke noget med virkeligheden at gøre. (Der er i hvert fald
>> endnu ikke nogen der har kunnet forklare mig hvad en bil og en vittighed
>> har tilfælles IRL).
>
>I programmeringssammenhæng giver det mening, og det er det relevante her.
>Programmering er en model af virkeligheden, det ER ikke virkeligheden.
En meget grundlæggende forskel. Ligesom hvis meterologer bruger vejret
Mars som model for beregning af om vi får solskin i morgen.
>> 2. Det giver problemer med multibel arv.
>
>Hvorfor det? En fælles rodklasse forhinder da ikke multibel arv, det er to
>adskilte ting.
Det forhindrer det ikke, nej, men det giver problemer. Problemer der
ikke er nemme at overskue, og derfor anbefaler lærere (mine gjorde i
hvert fald) at man *undgår* en fælles baseklasse.
Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Doom and
Quake run side by side
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 17:08 |
|
Den Wed, 11 Sep 2002 17:34:01 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Det har jeg skam allerede gjort. Men det ændrer ikke på at det er det
>> javascript bruges til.
>
>Som sagt: Det kan bruges til meget andet.
Jeps, det kan også bruges til at printe ud på toiletpapir
Mvh
Kent
--
IE is the only thing capable of making Netscape look good
- D. Spider in comp.os.linux.advocacy
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 17:14 |
|
Kent Friis wrote:
>>I programmeringssammenhæng giver det mening, og det er det relevante her.
>>Programmering er en model af virkeligheden, det ER ikke virkeligheden.
>
> En meget grundlæggende forskel. Ligesom hvis meterologer bruger vejret
> Mars som model for beregning af om vi får solskin i morgen.
Jeg forstår ikke hvor du vil hen med den bemærkning.
>>Hvorfor det? En fælles rodklasse forhinder da ikke multibel arv, det er to
>>adskilte ting.
>
> Det forhindrer det ikke, nej, men det giver problemer. Problemer der
> ikke er nemme at overskue,
Hvilke?
/Henry
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 17:16 |
|
Kent Friis wrote:
> Jeps, det kan også bruges til at printe ud på toiletpapir
Javascript kan faktisk også bruges til noget FORNUFTIGT. Der er ting som
jeg ikke kan se hvordan man skulle lave uden Javascript. I hvert fald ikke
på en fornuftig måde.
/Henry
| |
Morten Bo Johansen (11-09-2002)
| Kommentar
Fra : Morten Bo Johansen |
Dato : 11-09-02 18:02 |
|
Dette er en af de længste OT-tråde jeg har set i lang tid. Der
er intet Unix-specifikt jeres diskussion, så flyt det venligst
til dk.edb.programmering, thank you.
Morten
Henry Vest <henry_vest@get2net.dk> wrote:
HV> Kent Friis wrote:
>> Jeps, det kan også bruges til at printe ud på toiletpapir
HV> Javascript kan faktisk også bruges til noget FORNUFTIGT. Der er ting som
HV> jeg ikke kan se hvordan man skulle lave uden Javascript. I hvert fald ikke
HV> på en fornuftig måde.
HV> /Henry
| |
Jens Kristian Soegaa~ (11-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 11-09-02 19:08 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Jeg har skam brugt threads adskillige gange. Og hver eneste gang har
> konklusionen været "Fa*en til p*s, hvordan undgår vi det?" Fx. har jeg
> været med til at omskrive en måneds arbejde, fordi systemet - efter at
> være testet grundigt, og virkede uden problemer - overhovedet ikke
> virkede på en maskine med en anden clockfrekvens.
Har du overvejet, at det var fordi, at I ikke satte jer ind i
trådprogrammering før I begyndte?
Det lyder umidddelbart som et typisk problem der kan opstå, hvis man
har glemt at bruge diverse former for "låsning" mht. at sikre at kun
en tråd af gangen har skriveadgang til interne strukturer.
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Jens Axel Søgaard (11-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 11-09-02 19:17 |
|
Kent Friis wrote:
> Den Wed, 11 Sep 2002 00:52:16 +0200 skrev Jens Axel
> Søgaard:
>> Kent Friis wrote:
>>
>>> Det er det ikke, når det giver så meget forvirring.
>>> Åbenbart så meget at selv folk der har forstand på Java
>>> siger at "Java har ikke pointere", når det korrekte
>>> ville være "i Java hedder de ikke pointere".
> Jeg påstår at det der i Java hedder referencer svarer
> mere til det der i C++ hedder pointere, end det svarer
> til det der i C++ hedder referencer.
Ok.
--
Jens Axel Søgaard
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 19:22 |
|
Den Wed, 11 Sep 2002 18:14:03 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>>>I programmeringssammenhæng giver det mening, og det er det relevante her.
>>>Programmering er en model af virkeligheden, det ER ikke virkeligheden.
>>
>> En meget grundlæggende forskel. Ligesom hvis meterologer bruger vejret
>> Mars som model for beregning af om vi får solskin i morgen.
>
>Jeg forstår ikke hvor du vil hen med den bemærkning.
Man forsøger på at modellere virkeligheden, men programmeringssproget
tvinger en til at lave modellen grundlæggende forkert.
>>>Hvorfor det? En fælles rodklasse forhinder da ikke multibel arv, det er to
>>>adskilte ting.
>>
>> Det forhindrer det ikke, nej, men det giver problemer. Problemer der
>> ikke er nemme at overskue,
>
>Hvilke?
Har du ikke lært om OOP?
Man har to klasser B og C, der begge arver fra A. Så laver man en
klasse D, der arver fra både B og C. Skal D nu indeholde en eller to
kopier af A?
Det kan være svært at afgøre (nogengange kan det naturligvis også være
nemt at afgøre).
Mvh
Kent
--
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 19:33 |
|
Kent Friis wrote:
> Man forsøger på at modellere virkeligheden, men programmeringssproget
> tvinger en til at lave modellen grundlæggende forkert.
Hvad er det i Java (med en fælles baseklasse) der tvinger en til at lave en
forkert model?
> Man har to klasser B og C, der begge arver fra A. Så laver man en
> klasse D, der arver fra både B og C.
Kan man ikke gøre det i C++? I Java eksisterer problemet jo ikke, da man
ikke kan arve fra flere klasser.
/Henry
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 20:09 |
|
Den 11 Sep 2002 20:07:39 +0200 skrev Jens Kristian Soegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Jeg har skam brugt threads adskillige gange. Og hver eneste gang har
>> konklusionen været "Fa*en til p*s, hvordan undgår vi det?" Fx. har jeg
>> været med til at omskrive en måneds arbejde, fordi systemet - efter at
>> være testet grundigt, og virkede uden problemer - overhovedet ikke
>> virkede på en maskine med en anden clockfrekvens.
>
>Har du overvejet, at det var fordi, at I ikke satte jer ind i
>trådprogrammering før I begyndte?
Tja, hvis undervisning (datamatiker) plus erfaring fra tidligere
projekter ikke er nok, så ved jeg ikke hvad der skal til.
>Det lyder umidddelbart som et typisk problem der kan opstå, hvis man
>har glemt at bruge diverse former for "låsning" mht. at sikre at kun
>en tråd af gangen har skriveadgang til interne strukturer.
Det problem havde vi i starten, men den var nem at finde og løse.
På det tidspunkt havde vi tilføjet låsning hver gang programmet
lavede noget, og bortset fra at programmet kun kunne lave en ting
ad gangen, virkede det fint - på 233 MHz maskinen. Men stadig ikke
på 66 MHz maskinen.
Mvh
Kent
--
If you think about it, Windows XP is actually the OS that
started as "Microsoft OS/2 NT 3.0"
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 20:18 |
|
Den Wed, 11 Sep 2002 20:33:19 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Man forsøger på at modellere virkeligheden, men programmeringssproget
>> tvinger en til at lave modellen grundlæggende forkert.
>
>Hvad er det i Java (med en fælles baseklasse) der tvinger en til at lave en
>forkert model?
Virkeligheden: A og B har ikke noget tilfælles.
Java: A og B har "Object" tilfælles.
>> Man har to klasser B og C, der begge arver fra A. Så laver man en
>> klasse D, der arver fra både B og C.
>
>Kan man ikke gøre det i C++? I Java eksisterer problemet jo ikke, da man
>ikke kan arve fra flere klasser.
Man kan godt arve fra to klasser der arver fra samme base-klasse, jo,
men så skal man som sagt til at overveje om der skal være en eller to
af base-klassen.
Hvis man undgår at de arver fra samme base-klasse, så har man ikke
problemet.
(og nej, sproget kan ikke løse problemet, det afhænger af situationen
hvad der er rigtigt).
Mvh
Kent
--
8:16pm up 2:37, 1 user, load average: 101.21, 95.46, 55.85
164 processes: 62 sleeping, 102 running, 0 zombie, 0 stopped
With XMMS tugging along nicely, playing Vivaldi...
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 20:56 |
|
Kent Friis wrote:
> Virkeligheden: A og B har ikke noget tilfælles.
> Java: A og B har "Object" tilfælles.
Problemet?
Programmeringsmæssigt giver det mening at sige A og B har noget tilfælles.
Dit problem er rent teoretisk. Giv mig et praktisk eksempel på at det
skaber problemer.
/Henry
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 21:03 |
|
Den Wed, 11 Sep 2002 21:56:22 +0200 skrev Henry Vest:
>Kent Friis wrote:
>
>> Virkeligheden: A og B har ikke noget tilfælles.
>> Java: A og B har "Object" tilfælles.
>
>Problemet?
>
>Programmeringsmæssigt giver det mening at sige A og B har noget tilfælles.
>Dit problem er rent teoretisk. Giv mig et praktisk eksempel på at det
>skaber problemer.
Jeg havde både et teoretisk og et praktisk argument. Det der er det
teoretiske argument, det praktiske stod nedenunder.
Mvh
Kent
--
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
| |
Morten Bo Johansen (11-09-2002)
| Kommentar
Fra : Morten Bo Johansen |
Dato : 11-09-02 21:07 |
|
Henry Vest <henry_vest@get2net.dk> wrote:
HV> Kent Friis wrote:
>> Virkeligheden: A og B har ikke noget tilfælles.
>> Java: A og B har "Object" tilfælles.
HV> Problemet?
HV> Programmeringsmæssigt giver det mening at sige A og B har noget tilfælles.
HV> Dit problem er rent teoretisk. Giv mig et praktisk eksempel på at det
HV> skaber problemer.
Jeg gentager: det hører ikke hjemme her. Vær rar at læse
fundatsen for gruppen
http://www.usenet.dk/grupper.pl?dk.edb.system.unix
og flyt jeres diskussion til en relevant gruppe eller
til privat mail.
Nej, jeg er ikke moderator, men jeg betaler for min båndbredde.
Morten
| |
Jens Kristian Soegaa~ (11-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 11-09-02 21:20 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >Har du overvejet, at det var fordi, at I ikke satte jer ind i
> >trådprogrammering før I begyndte?
> Tja, hvis undervisning (datamatiker) plus erfaring fra tidligere
> projekter ikke er nok, så ved jeg ikke hvad der skal til.
At man har fået undervisning i fx objekt orienteret programmering,
hjælper jo ikke en meget i forbindelse med at løse problemstillinger
omkring flertrådet programmering.
> På det tidspunkt havde vi tilføjet låsning hver gang programmet
> lavede noget, og bortset fra at programmet kun kunne lave en ting
> ad gangen, virkede det fint - på 233 MHz maskinen. Men stadig ikke
> på 66 MHz maskinen.
Der må jo helt klart være tale om en fejl i jeres program eller i den
tråd-implementation, I benyttede jer af.
I dag vil du næppe se folk benytte heavy-weight processes på samme
måde som før tråde blev hverdag. Fx giver flertrådning en række
fordele i forbindelse med programmer der har en grafisk brugerflade.
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Jens Kristian Soegaa~ (11-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 11-09-02 21:24 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >Hvad er det i Java (med en fælles baseklasse) der tvinger en til at lave en
> >forkert model?
> Virkeligheden: A og B har ikke noget tilfælles.
> Java: A og B har "Object" tilfælles.
Jeg har på fornemmelsen, at du forsøger at blande analyse og design
sammen. Det er korrekt at du i en objekt-orienteret analyse forsøger
at få din model til at være så meget i overensstemmelse med
virkelighedens verden som muligt.
I din designfase derimod, er der ikke noget der forhindrer dig i at
lave "unaturlige" ting, som der kun er en ren teknisk argumentation
for. Hvis man ikke gjorde dette, ville man gøre det urealistisk svært
for en selv.
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 21:45 |
|
Den 11 Sep 2002 22:20:19 +0200 skrev Jens Kristian Soegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >Har du overvejet, at det var fordi, at I ikke satte jer ind i
>> >trådprogrammering før I begyndte?
>
>> Tja, hvis undervisning (datamatiker) plus erfaring fra tidligere
>> projekter ikke er nok, så ved jeg ikke hvad der skal til.
>
>At man har fået undervisning i fx objekt orienteret programmering,
>hjælper jo ikke en meget i forbindelse med at løse problemstillinger
>omkring flertrådet programmering.
Var det det jeg skrev?
Jeg pjækkede altså ikke fra alle andre timer end OO-programmering.
>> På det tidspunkt havde vi tilføjet låsning hver gang programmet
>> lavede noget, og bortset fra at programmet kun kunne lave en ting
>> ad gangen, virkede det fint - på 233 MHz maskinen. Men stadig ikke
>> på 66 MHz maskinen.
>
>Der må jo helt klart være tale om en fejl i jeres program eller i den
>tråd-implementation, I benyttede jer af.
Det ændrer ikke på at det stadig var hurtigere at omskrive koden til
ikke at bruge threads, end det var at debugge programmet.
>I dag vil du næppe se folk benytte heavy-weight processes på samme
>måde som før tråde blev hverdag. Fx giver flertrådning en række
>fordele i forbindelse med programmer der har en grafisk brugerflade.
Specielt windows-programmører er glade for threads. Og specielt windows
programmer har en tendens til at crashe. Der kunne nemt være en
sammenhæng.
Mvh
Kent
--
Gilthoniel, A Elbereth
Aiya elenion ancalima!
- Tolkien, "The Lord of the Rings"
| |
Kent Friis (11-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 11-09-02 21:47 |
|
Den 11 Sep 2002 22:23:43 +0200 skrev Jens Kristian Soegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >Hvad er det i Java (med en fælles baseklasse) der tvinger en til at lave en
>> >forkert model?
>
>> Virkeligheden: A og B har ikke noget tilfælles.
>> Java: A og B har "Object" tilfælles.
>
>Jeg har på fornemmelsen, at du forsøger at blande analyse og design
>sammen. Det er korrekt at du i en objekt-orienteret analyse forsøger
>at få din model til at være så meget i overensstemmelse med
>virkelighedens verden som muligt.
>
>I din designfase derimod, er der ikke noget der forhindrer dig i at
>lave "unaturlige" ting, som der kun er en ren teknisk argumentation
>for. Hvis man ikke gjorde dette, ville man gøre det urealistisk svært
>for en selv.
Jeg har ikke set andre argumenter end "det var den eneste måde sun-
folkene kunne finde ud af at lave det på". Det kalder jeg ikke en
ren teknisk argumentation. Jeg kalder det et tåbeligt argument.
Mvh
Kent
--
Is windows userfriendly? Nah, more like optimized for idiots.
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 21:54 |
|
Kent Friis wrote:
> Jeg havde både et teoretisk
Som ikke er et problem.
> og et praktisk argument. Det der er det
> teoretiske argument, det praktiske stod nedenunder.
Det er et problem hvis man har multipel arv måske, men da man ikke har det
i Java, er det ikke et problem i Java.
/Henry
| |
Henry Vest (11-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 11-09-02 22:00 |
|
Kent Friis wrote:
> Jeg har ikke set andre argumenter end "det var den eneste måde sun-
> folkene kunne finde ud af at lave det på". Det kalder jeg ikke en
> ren teknisk argumentation. Jeg kalder det et tåbeligt argument.
Jeg kalder det tåbeligt at argumentere mod noget, som du ikke har nogen som
helst teknisk begrundelse for at lave på en anden måde.
Og så FUT til dk.edb.programmering. Indrømmet, det skulle være sket for
længst.
/Henry
| |
Jens Kristian Soegaa~ (11-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 11-09-02 22:46 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >> Tja, hvis undervisning (datamatiker) plus erfaring fra tidligere
> >> projekter ikke er nok, så ved jeg ikke hvad der skal til.
> >At man har fået undervisning i fx objekt orienteret programmering,
> >hjælper jo ikke en meget i forbindelse med at løse problemstillinger
> >omkring flertrådet programmering.
> Var det det jeg skrev?
> Jeg pjækkede altså ikke fra alle andre timer end OO-programmering.
Du behøver ikke tage det personligt. Jeg ved ikke hvilke kurser
datamatikere har - jeg understreger bare, at det naturligvis er
nødvendigt at vide noget om XXX før man kan kaste sig ud i XXX. At man
har viden fra undervisning og tidligere projekter gør ikke
nødvendigvis en bedre til XXX, hvis man ikke har prøvet XXX før.
Det virker underligt at stemple noget så fundamentalt som
trådprogrammering som ubrugeligt, blot fordi man har haft en dårlig
oplevelse med ikke at kunne få et program til at virke.
> >Der må jo helt klart være tale om en fejl i jeres program eller i den
> >tråd-implementation, I benyttede jer af.
> Det ændrer ikke på at det stadig var hurtigere at omskrive koden til
> ikke at bruge threads, end det var at debugge programmet.
Hvilket kunne antyde at I havde designet programmets arkitektur
forkert!
Hvis man tænker "enkelt-trådet" når man programmer fler-trådet, så
bliver det naturligvis nemmere tilsidst at skrive det om til
enkelt-trådning, end at rette fejl indtil man når til et virkende
fler-trådet program.
> Specielt windows-programmører er glade for threads. Og specielt windows
> programmer har en tendens til at crashe. Der kunne nemt være en
> sammenhæng.
Det er jo en ubrugelig argumentation.
Årsagen til at Windows-programmører ser ud til at være mere "glade"
for tråde end fx Linux-programmører kan vel skyldes, at der indtil for
nyligt (dvs. inden for de allerseneste år) ikke fandtes et ordenligt
trådsystem i Linux...
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Jens Kristian Soegaa~ (11-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 11-09-02 22:48 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >I din designfase derimod, er der ikke noget der forhindrer dig i at
> >lave "unaturlige" ting, som der kun er en ren teknisk argumentation
> >for. Hvis man ikke gjorde dette, ville man gøre det urealistisk svært
> >for en selv.
> Jeg har ikke set andre argumenter end "det var den eneste måde sun-
> folkene kunne finde ud af at lave det på". Det kalder jeg ikke en
> ren teknisk argumentation. Jeg kalder det et tåbeligt argument.
Vi snakker vist ikke om det samme her.
Når jeg snakker om "designfase", snakker jeg om en fase som
programmørerne bag et nyt system gennemgår.
Der er _ikke_ tale om fase i udviklingen af et nyt sprog.
At alle objekter nedarver fra Object i Java skal du ikke tage som et
udtryk for, at Sun ikke kunne finde ud af at lave det anderledes. Det
er skam med vilje, at det er lavet sådan.
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Lars Kongshøj (11-09-2002)
| Kommentar
Fra : Lars Kongshøj |
Dato : 11-09-02 22:51 |
|
Kent Friis wrote:
> "en thread" giver overhovedet ingen mening. Der skal være to, før et
> program kan siges at bruge threads.
En søgning på "single-threaded" på google giver 50100 hits.
--
Lars Kongshøj
Registrer dig som linux-bruger:
http://counter.li.org/enter-person.php
| |
Lars Kongshøj (11-09-2002)
| Kommentar
Fra : Lars Kongshøj |
Dato : 11-09-02 23:03 |
|
Kent Friis wrote:
> Specielt windows-programmører er glade for threads. Og specielt windows
> programmer har en tendens til at crashe. Der kunne nemt være en
> sammenhæng.
Mit indtryk er at sammenhængen er at windowsprogrammører generelt er
dårligst uddannet.
Men derudover skal man selvfølgelig holde tungen lige i munden ved
multithreaded programmering.
--
Lars Kongshøj
Registrer dig som linux-bruger:
http://counter.li.org/enter-person.php
| |
Thorbjoern Ravn Ande~ (12-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 12-09-02 07:56 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Jeg har skam brugt threads adskillige gange. Og hver eneste gang har
> konklusionen været "Fa*en til p*s, hvordan undgår vi det?" Fx. har jeg
> været med til at omskrive en måneds arbejde, fordi systemet - efter at
> være testet grundigt, og virkede uden problemer - overhovedet ikke
> virkede på en maskine med en anden clockfrekvens.
Saa er det ikke lavet ordentligt, med semaforbeskyttede omraader og
lignende.
> Din bemærkning om at "threads er smarte" får dig til at lyde som en
> sælger i den nærmeste radio-TV butik. Kom med argumenter, hvis du vil
> tages alvorligt.
| |
Thorbjoern Ravn Ande~ (12-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 12-09-02 07:59 |
|
leeloo@phreaker.net (Kent Friis) writes:
> >> Ja, men har jeg ret i at "interface" kun arver metodenavne og parametre,
> >> og man så er nødt til at cut'n'paste indholdet af metoderne, eller har
> >> jeg misforstået det?
> >
> >Jeg tror du har misforstaaet det. Et interface i java indeholder ikke kode.
>
> Er det ikke også det jeg siger?
>
> Man arver kun metodenavne og parametre.
Et interface i Java er ikke et spoergsmaal om nedarv, men en kontrakt
hvor der garanteres at visse rutiner findes som specificeret.
Herved kan man erklaere variable med et givent interface som type, og
herefter tildele det alle de typer som implementerer interfacet. Det
er ikke nedarv, men noget helt andet.
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 17:59 |
|
Den 11 Sep 2002 23:46:18 +0200 skrev Jens Kristian Soegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >> Tja, hvis undervisning (datamatiker) plus erfaring fra tidligere
>> >> projekter ikke er nok, så ved jeg ikke hvad der skal til.
>
>> >At man har fået undervisning i fx objekt orienteret programmering,
>> >hjælper jo ikke en meget i forbindelse med at løse problemstillinger
>> >omkring flertrådet programmering.
>
>> Var det det jeg skrev?
>> Jeg pjækkede altså ikke fra alle andre timer end OO-programmering.
>
>Du behøver ikke tage det personligt. Jeg ved ikke hvilke kurser
>datamatikere har - jeg understreger bare, at det naturligvis er
>nødvendigt at vide noget om XXX før man kan kaste sig ud i XXX. At man
>har viden fra undervisning og tidligere projekter gør ikke
>nødvendigvis en bedre til XXX, hvis man ikke har prøvet XXX før.
Indtil videre har jeg været med til at lave et simpelt preemtive
multithreading library i C++ under DOS, samt brugt threads i Delphi og
VB, og været blandet ind i det (rådgivende) i Cobol.
Bortset fra librariet vi selv lavede (opgave på datamatiker), var ingen
af projekterne en success.
>Det virker underligt at stemple noget så fundamentalt som
>trådprogrammering som ubrugeligt, blot fordi man har haft en dårlig
>oplevelse med ikke at kunne få et program til at virke.
Jeg mener også at have teorien i orden (fra dengang vi selv lavede det
library), og har altså den opfattelse at threads garanterer bugs,
medmindre man har styr på hver eneste instruktion - program, libraries,
runtime, OS...
>> >Der må jo helt klart være tale om en fejl i jeres program eller i den
>> >tråd-implementation, I benyttede jer af.
>
>> Det ændrer ikke på at det stadig var hurtigere at omskrive koden til
>> ikke at bruge threads, end det var at debugge programmet.
>
>Hvilket kunne antyde at I havde designet programmets arkitektur
>forkert!
>
>Hvis man tænker "enkelt-trådet" når man programmer fler-trådet, så
>bliver det naturligvis nemmere tilsidst at skrive det om til
>enkelt-trådning, end at rette fejl indtil man når til et virkende
>fler-trådet program.
Programmet var skrevet som to separate dele, der skulle køre relativt
uafhængigt 90% af tiden (og låsningen skulle sikre at de ikke generede
hinanden de sidste 10% af tiden). Omskrivningen gik på at få lavet de
to dele om til en, baseret på select() til at styre hvilken del der
af programmet der skulle lave noget.
>> Specielt windows-programmører er glade for threads. Og specielt windows
>> programmer har en tendens til at crashe. Der kunne nemt være en
>> sammenhæng.
>
>Det er jo en ubrugelig argumentation.
Det beviser ikke noget, men det antyder at virkeligheden måske ikke
ligger så langt fra teorien ("threads medfører bugs")
>Årsagen til at Windows-programmører ser ud til at være mere "glade"
>for tråde end fx Linux-programmører kan vel skyldes, at der indtil for
>nyligt (dvs. inden for de allerseneste år) ikke fandtes et ordenligt
>trådsystem i Linux...
Efter en windows-bog om netop threads, skyldes det at windows er elendig
til at håndtere processer, at ting der rent logisk burde have været
lavet som processer er blevet lavet som threads i stedet for.
Og jeg har stadig ikke hørt nogen argumenter *for* threads.
Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Railroad
Tycoon II and Unreal Tournament run side by side
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 18:02 |
|
Den 11 Sep 2002 23:48:27 +0200 skrev Jens Kristian Soegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >I din designfase derimod, er der ikke noget der forhindrer dig i at
>> >lave "unaturlige" ting, som der kun er en ren teknisk argumentation
>> >for. Hvis man ikke gjorde dette, ville man gøre det urealistisk svært
>> >for en selv.
>
>> Jeg har ikke set andre argumenter end "det var den eneste måde sun-
>> folkene kunne finde ud af at lave det på". Det kalder jeg ikke en
>> ren teknisk argumentation. Jeg kalder det et tåbeligt argument.
>
>Vi snakker vist ikke om det samme her.
>
>Når jeg snakker om "designfase", snakker jeg om en fase som
>programmørerne bag et nyt system gennemgår.
>
>Der er _ikke_ tale om fase i udviklingen af et nyt sprog.
Det var ikke det jeg mente.
Jeg hentydede til "som der kun er ren teknisk argumentation for", og
i design-fasen ser jeg ikke nogen teknisk argumentation for at lade
klasser arver fra Object. Det eneste argument er at man ikke kan slippe
for det, hvis man bruger Java. Men så burde man måske se sig om efter
et programmeringssprog der lader programmøren bestemme, i stedet for et
der lader Sun bestemme.
>At alle objekter nedarver fra Object i Java skal du ikke tage som et
>udtryk for, at Sun ikke kunne finde ud af at lave det anderledes. Det
>er skam med vilje, at det er lavet sådan.
Det er fordi nogle programmører fra Sun synes at det er smart. Og det
skal alle andre programmører så bare indrette sig efter... Nej tak, så
vil jeg sg* hellere finde et sprog der indretter sig efter programmøren.
Mvh
kent
--
What was your username?
<Clicketyclick> - B.O.F.H.
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 18:03 |
|
Den Wed, 11 Sep 2002 23:51:24 +0200 skrev Lars Kongshøj:
>Kent Friis wrote:
>> "en thread" giver overhovedet ingen mening. Der skal være to, før et
>> program kan siges at bruge threads.
>
>En søgning på "single-threaded" på google giver 50100 hits.
Og? "single-threaded" er et helt normalt ord for programmer der ikke
bruger threads.
Mvh
Kent
--
Desuden kan jeg ikke se nogen grund til at springe over hvor gærdet er
lavest, når man kan vente på at det alligevel bliver revet ned fordi
der skal bygges en omfartsvej...
- Claus Frørup og Asbjørn Christensen i dk.snak.
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 18:05 |
|
Den Thu, 12 Sep 2002 00:03:25 +0200 skrev Lars Kongshøj:
>Kent Friis wrote:
>> Specielt windows-programmører er glade for threads. Og specielt windows
>> programmer har en tendens til at crashe. Der kunne nemt være en
>> sammenhæng.
>
>Mit indtryk er at sammenhængen er at windowsprogrammører generelt er
>dårligst uddannet.
Og derfor kan de kun finde ud af threads... Ja, det lyder ikke helt
ved siden af.
>Men derudover skal man selvfølgelig holde tungen lige i munden ved
>multithreaded programmering.
Nøjagtig som man skal, hvis man programmerer i assembler. Og derfor
bruger man selvfølgelig kun threads eller assembler i de få tilfælde
der ikke kan løses fornuftigt på anden vis.
Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 18:08 |
|
Den 12 Sep 2002 08:58:47 +0200 skrev Thorbjoern Ravn Andersen:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> >> Ja, men har jeg ret i at "interface" kun arver metodenavne og parametre,
>> >> og man så er nødt til at cut'n'paste indholdet af metoderne, eller har
>> >> jeg misforstået det?
>> >
>> >Jeg tror du har misforstaaet det. Et interface i java indeholder ikke kode.
>>
>> Er det ikke også det jeg siger?
>>
>> Man arver kun metodenavne og parametre.
>
>Et interface i Java er ikke et spoergsmaal om nedarv, men en kontrakt
>hvor der garanteres at visse rutiner findes som specificeret.
Men alligevel nævner folk altid interface som erstatning for multipel
arv.
I den sammenhæng er det netop cut'n'paste arv.
>Herved kan man erklaere variable med et givent interface som type, og
>herefter tildele det alle de typer som implementerer interfacet. Det
>er ikke nedarv, men noget helt andet.
Gid andre Java-programmører ville fatte det. Jeg kan godt se det smarte
i interface/implementation, men IKKE som erstatning for arv / multipel
arv.
>Det er faktisk ret fikst. Specielt med Collections og Iterators.
Enig.
Mvh
Kent
--
Mails skrevet før 12:00 skal læses med det forbehold, at hjernen først
forventes at være færdig med at boote på det tidspunkt, og indholdet
derfor kan indeholde random data der tilfældigvis lå i den
uinitializerede cache.
| |
Jens Kristian Soegaa~ (12-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 12-09-02 18:34 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Indtil videre har jeg været med til at lave et simpelt preemtive
> multithreading library i C++ under DOS, samt brugt threads i Delphi og
> VB, og været blandet ind i det (rådgivende) i Cobol.
> Bortset fra librariet vi selv lavede (opgave på datamatiker), var ingen
> af projekterne en success.
Jeg er ked af at sige det... men muligvis kunne der jo være andre
årsager til at programmerne ikke virkede end at det lige skulle være
trådning, der var inherent "dårligt".
> Jeg mener også at have teorien i orden (fra dengang vi selv lavede det
> library), og har altså den opfattelse at threads garanterer bugs,
> medmindre man har styr på hver eneste instruktion - program, libraries,
> runtime, OS...
Det vil jeg så gøre mig stærkt uenig i.
> Efter en windows-bog om netop threads, skyldes det at windows er elendig
> til at håndtere processer, at ting der rent logisk burde have været
> lavet som processer er blevet lavet som threads i stedet for.
Igen er din argumentation lidt ulden.
Jeg skriver, at Windows har en god tråd-implementation. Du skriver så,
at det skyldes at Windows er elendig til at håndtere processer.
Er det så ikke netop et argument _for_ trådning?
> Og jeg har stadig ikke hørt nogen argumenter *for* threads.
De gør livet 100 gange lettere når man skal programmere fx grafiske
brugerflader, serverdaemons, programmer der skal benytte mere end 1
cpu, osv.
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Jens Kristian Soegaa~ (12-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 12-09-02 18:36 |
|
leeloo@phreaker.net (Kent Friis) writes:
> i design-fasen ser jeg ikke nogen teknisk argumentation for at lade
> klasser arver fra Object.
Aha, du godtager altså ikke argumentet med, at der er diverse
funktioner som er rare at have for ethvert objekt? (omkring fx
trådning)
Har du en god teknisk argumentation _imod_ at lade alle klasser arve
fra Object? - for sådan en har jeg ikke hørt.
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 18:55 |
|
Den 12 Sep 2002 19:34:25 +0200 skrev Jens Kristian Soegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Indtil videre har jeg været med til at lave et simpelt preemtive
>> multithreading library i C++ under DOS, samt brugt threads i Delphi og
>> VB, og været blandet ind i det (rådgivende) i Cobol.
>
>> Bortset fra librariet vi selv lavede (opgave på datamatiker), var ingen
>> af projekterne en success.
>
>Jeg er ked af at sige det... men muligvis kunne der jo være andre
>årsager til at programmerne ikke virkede end at det lige skulle være
>trådning, der var inherent "dårligt".
Det er den eneste ting jeg kan se, der kan forklare at programmet
pludselig opfører sig underligt imens man står i et indtastningsfelt
(dvs. (den del af) programmet laver egnetlig ikke noget på det
tidspunkt, kun runtime'n).
>> Jeg mener også at have teorien i orden (fra dengang vi selv lavede det
>> library), og har altså den opfattelse at threads garanterer bugs,
>> medmindre man har styr på hver eneste instruktion - program, libraries,
>> runtime, OS...
>
>Det vil jeg så gøre mig stærkt uenig i.
Sjovt nok virkede det fint sålænge vi undgik at blande OS'et ind i det.
Alle de gange jeg har haft problemer, har der som minimum været et OS
og et antal libraries, som medførte en masse instruktioner vi ikke
havde kontrol over.
>> Efter en windows-bog om netop threads, skyldes det at windows er elendig
>> til at håndtere processer, at ting der rent logisk burde have været
>> lavet som processer er blevet lavet som threads i stedet for.
>
>Igen er din argumentation lidt ulden.
>
>Jeg skriver, at Windows har en god tråd-implementation. Du skriver så,
>at det skyldes at Windows er elendig til at håndtere processer.
>
>Er det så ikke netop et argument _for_ trådning?
Et argument for trådning under windows, jo. Men kun som en omvej fordi
den måde man egentlig ville have lavet det på ikke virker specielt godt
under windows.
>> Og jeg har stadig ikke hørt nogen argumenter *for* threads.
>
>De gør livet 100 gange lettere når man skal programmere fx grafiske
>brugerflader, serverdaemons, programmer der skal benytte mere end 1
>cpu, osv.
Threads er en dårlig ide til programmer der skal benytte mere end en
CPU. Jo, på PC'er og andet små-skravl virker det da fint, men så
snart man kommer op på NUMA-maskiner er threads uegnede, sammenlignet
med processer.
Hele forskellen på threads og processer er netop at threads bruger det
samme RAM-område, og når man har separat RAM pr. CPU, er det absolut
ikke nogen fordel.
Med grafiske brugergrænseflader har jeg kun set ulemper ved at blande
threads ind i det, men ok, det har jeg også kun forsøgt i VB, så hvis
du gerne vil, kan du da give Microsoft skylden i stedet
Daemons kan jeg i langt de fleste tilfælde ikke se den store fordel.
De har sjældent brug for at overskrive hinandens RAM-område, og derfor
er processer bedre.
Mvh
Kent
--
A Elbereth Gilthoniel, silivren penna míriel
o menel aglar elenath! Na-chaered palan-díriel
o galadhremmin ennorath, Fanuilos, le linnathon nef aear, sí nef aearon!
- Tolkien, "The Lord of the Rings"
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 18:59 |
|
Den 12 Sep 2002 19:35:57 +0200 skrev Jens Kristian Soegaard:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> i design-fasen ser jeg ikke nogen teknisk argumentation for at lade
>> klasser arver fra Object.
>
>Aha, du godtager altså ikke argumentet med, at der er diverse
>funktioner som er rare at have for ethvert objekt? (omkring fx
>trådning)
Da jeg mener at threads max har en fordel i 10% af programmer, mener
jeg naturligvis også at det kun er de klasser der oprettes i de
programmer der skal have disse metoder.
Og derudover har jeg vist været listen over metoder igennem, og
forklaret ved hver eneste hvorfor jeg ikke mener at den hører til i alle
klasser.
>Har du en god teknisk argumentation _imod_ at lade alle klasser arve
>fra Object? - for sådan en har jeg ikke hørt.
Teoretisk: Det stemmer ikke overens med virkeligheden
Praktisk: Det giver problemer med multipel arv.
Begge argumenter har jeg nævnt før. Du kan sikkert finde dem på google
hvis du vil have en længere (3-4 linier) forklaring.
Mvh
Kent
--
A Elbereth Gilthoniel, silivren penna míriel
o menel aglar elenath! Na-chaered palan-díriel
o galadhremmin ennorath, Fanuilos, le linnathon nef aear, sí nef aearon!
- Tolkien, "The Lord of the Rings"
| |
Klaus Alexander Seis~ (12-09-2002)
| Kommentar
Fra : Klaus Alexander Seis~ |
Dato : 12-09-02 18:52 |
|
Kent Friis skrev:
> Og? "single-threaded" er et helt normalt ord for programmer
> der ikke bruger threads.
Futter I ikke snart over i fx <news:dk.edb.programmering>?
// Klaus
--
><> vandag, môre, altyd saam
| |
Henry Vest (12-09-2002)
| Kommentar
Fra : Henry Vest |
Dato : 12-09-02 19:31 |
|
Kent Friis wrote:
> Teoretisk: Det stemmer ikke overens med virkeligheden
Kan være ligegyldigt hvis det kan løse et teknisk problem.
> Praktisk: Det giver problemer med multipel arv.
Ikke et problem i et sprog der ikke har multipel arv.
FUT: dk.edb.programmering
/Henry
| |
Thorbjoern Ravn Ande~ (12-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 12-09-02 19:57 |
|
Jens Kristian Soegaard <jk@soegaard.net> writes:
> Aha, du godtager altså ikke argumentet med, at der er diverse
> funktioner som er rare at have for ethvert objekt? (omkring fx
> trådning)
Det syntaktiske sukker omkring at alle Object-derivater kan bruges som
strenge vha toString har jeg været glad for tit. Især i situationer
som JSP-programmering hvor det ikke altid er lige let at få pudset en
debugger på en given kodelinie - man kan som regel altid finde det
sted hvor System.out.println kan smide en linie eller ti.
> Har du en god teknisk argumentation _imod_ at lade alle klasser arve
> fra Object? - for sådan en har jeg ikke hørt.
Det er også rart at man kan bruge Object som generel type for "her
kommer der noget".
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus
| |
Kent Friis (12-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 12-09-02 21:13 |
|
Den 12 Sep 2002 20:57:17 +0200 skrev Thorbjoern Ravn Andersen:
>Jens Kristian Soegaard <jk@soegaard.net> writes:
>
>> Aha, du godtager altså ikke argumentet med, at der er diverse
>> funktioner som er rare at have for ethvert objekt? (omkring fx
>> trådning)
>
>Det syntaktiske sukker omkring at alle Object-derivater kan bruges som
>strenge vha toString har jeg været glad for tit.
Men når man har en klasse der ikke kan konverteres til en streng, så
er man nødt blot at returnere et eller andet "garbage" - en tom
streng, eller som i halvdelen af systemklasserne i VB: returnere det
samme som x.gettype.tostring - og det beviser jo netop at tostring
er forkert placeret.
Mvh
Kent
--
Indlæringskurven til Linux er stejl, til tider lodret... Men for katten
hvor er udsigten på toppen dog fantastisk
- Michael G. Vendelbo i dk.snak
| |
Jens Kristian Soegaa~ (13-09-2002)
| Kommentar
Fra : Jens Kristian Soegaa~ |
Dato : 13-09-02 07:32 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Det er den eneste ting jeg kan se, der kan forklare at programmet
> pludselig opfører sig underligt imens man står i et indtastningsfelt
> (dvs. (den del af) programmet laver egnetlig ikke noget på det
Du har ikke overvejet at det kunne være en bug i jeres program?
> Sjovt nok virkede det fint sålænge vi undgik at blande OS'et ind i det.
> Alle de gange jeg har haft problemer, har der som minimum været et OS
> og et antal libraries, som medførte en masse instruktioner vi ikke
> havde kontrol over.
Har I husket kun at bruge reentrante funktioner? eller at lave låsning
omkring funktionskald?
> Et argument for trådning under windows, jo. Men kun som en omvej fordi
> den måde man egentlig ville have lavet det på ikke virker specielt godt
> under windows.
Jeg tror nu næppe det er derfor at trådning er meget brugt.
> Threads er en dårlig ide til programmer der skal benytte mere end en
> CPU. Jo, på PC'er og andet små-skravl virker det da fint,
Tjah, nu er det jo sådan set mest PC'ere og PC-lignende servere de
fleste programmerer til...
> men så
> snart man kommer op på NUMA-maskiner er threads uegnede, sammenlignet
> med processer.
Det synes jeg da ikke de er?
> Hele forskellen på threads og processer er netop at threads bruger det
> samme RAM-område,
Nej, det er ikke _hele_ forskellen.
> og når man har separat RAM pr. CPU, er det absolut
> ikke nogen fordel.
Læg mærke til:
1) I et trådbaseret program skal hvert tråd ikke nødvendigvis tilgå
de samme områder i rammen
2) I et trådbaseret program _kan_ hver tråd tilgå de andre trådes
områder i rammen
3) I et NUMA-system er der seperat RAM pr. CPU
4) I et NUMA-system er der adgang til _al_ RAM fra alle CPUer (det er
naturligvis langsommere at tilgå ram der ligger "langt væk" end det
der er tilknyttet samme CPU)
Det er naturligvis muligt at lave et program, som er flertrådet og
kører på en enkelt CPU (kan mange gange være nyttigt til at gøre det
nemmere at skrive programmet).
Det er også muligt at lave "almindelig" trådning. Hvis trådene ikke
har brug for at kommunikere med stor datamængder via RAM, vil det
fungere ganske udmærket!
> Med grafiske brugergrænseflader har jeg kun set ulemper ved at blande
> threads ind i det
Det er ellers langt den mest anvende metode i dag...
> Daemons kan jeg i langt de fleste tilfælde ikke se den store fordel.
> De har sjældent brug for at overskrive hinandens RAM-område, og derfor
> er processer bedre.
Ehm, har du nogensinde prøvet at skrive en daemon? (fx en newsserver,
crondaemon, maildaemon, dnsdaemon, whatever daemon)
FUT: dk.edb.programmering
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Peter Makholm (08-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 08-09-02 17:25 |
|
leeloo@phreaker.net (Kent Friis) writes:
>>Selvfølgelig kan du få null-pointerfejl, eftersom en reference kan
>>være uinitialiseret (hvilket er betydningen af null). Hvis du følger
>>en sådan, får du en fejl.
>
> Og derved forsvandt hele fordelen ved referencer frem for pointere.
Det er ganske normalt at variable kan være uinitialiseret. Det ville
da være underligt hvis variable indenholdende referencer opførte sig
anderledes.
Så det er næppe et problem med referencer som sådan, nærmere en
generel mulighed for at have uinitialiserede variable.
--
Peter Makholm | I laugh in the face of danger. Then I hide until
peter@makholm.net | it goes away
http://hacking.dk | -- Xander
| |
Peter Makholm (09-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 09-09-02 06:31 |
|
leeloo@phreaker.net (Kent Friis) writes:
> new bruger man da til pointere, ikke til referencer.
new bruges til at lave objekter hvad enten man så refererer til dem
med en pointer, en reference eller en anden magic cookie. Hvis du vil
have en pointer kan du bruge malloc eller venner.
--
Peter Makholm | I have something to say: It's better to burn in
peter@makholm.net | hell, than to fade away!
http://hacking.dk | -- Kurgan
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 18:52 |
|
Den Mon, 09 Sep 2002 07:31:28 +0200 skrev Peter Makholm:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> new bruger man da til pointere, ikke til referencer.
>
>new bruges til at lave objekter hvad enten man så refererer til dem
>med en pointer, en reference eller en anden magic cookie. Hvis du vil
>have en pointer kan du bruge malloc eller venner.
class c {
int dummy
}
// opret et objekt
c foo;
// opret en pointer, og sæt den til at pege på et objekt.
c * bar = new c;
malloc er bare C-versionen af new.
Mvh
Kent
--
If I wanted a blue screen, I would type "xsetroot -solid blue"
- not D:\WINNT\SETUP
| |
Peter Makholm (09-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 09-09-02 06:35 |
|
leeloo@phreaker.net (Kent Friis) writes:
> Hvis en pointer er initialiseret, og man ikke selv piller ved den,
> så er pointerfejl = nullpointer-fejl.
Er det inkluderet i at 'pille ved den' at kalde free?
Det er en evig fejlkilde ved pointere hvis man selv skal håndterer
allokering og deallokering af pointerer.
--
Peter Makholm | Emacs is the only modern general-purpose
peter@makholm.net | operating system that doesn't multitask
http://hacking.dk |
| |
Kent Friis (09-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 09-09-02 18:53 |
|
Den Mon, 09 Sep 2002 07:34:36 +0200 skrev Peter Makholm:
>leeloo@phreaker.net (Kent Friis) writes:
>
>> Hvis en pointer er initialiseret, og man ikke selv piller ved den,
>> så er pointerfejl = nullpointer-fejl.
>
>Er det inkluderet i at 'pille ved den' at kalde free?
En fornuftig free vil naturligvis selv sætte pointeren til at pege
på null (et af de få steder hvor C++ ikke er helt gennemtænk).
Mvh
Kent
--
Desuden kan jeg ikke se nogen grund til at springe over hvor gærdet er
lavest, når man kan vente på at det alligevel bliver revet ned fordi
der skal bygges en omfartsvej...
- Claus Frørup og Asbjørn Christensen i dk.snak.
| |
Jens Axel Søgaard (01-09-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 01-09-02 00:29 |
|
"Peter Mogensen" <apm-at-mutex-dot-dk@nospam.no> skrev i en meddelelse news:3D711915.4070502@nospam.no...
> LISP/SCHEME: Der sker en del udvikling i guile fortiden i bl.a. Gnome
> projektet.
Efter min mening er der mange Scheme-implementationer,
der ville være et bedre valg end Guile. For eksempel
MzScheme, ChezScheme eller Bigloo.
Til shell-programmering er ville jeg dog vælge scsh, som
er en Scheme-implementation specielt designet til formålet:
http://www.scsh.net
Jeg vil dog foreslå Anders at vælge Python eller Perl.
Men for de interesserede er her kort overblik over scsh:
Scsh is a variant of Scheme 48, an R5RS compliant new-tech
Scheme system, designed for writing useful standalone Unix
programs and shell scripts (but rather not for interactive
command use). Scsh spans a wide range of application,
from "script" applications usually handled with perl or sh,
to more standard systems applications usually written in C.
Scsh has two main components: a process notation for running
programs and setting up pipelines and redirections, and a complete
syscall library for low-level access to the operating system, i.e. to
POSIX, the least common denominator of more or less all Unices, plus
widely supported extensions such as symbolic links and BSD sockets.
Moreover, scsh provides an awk facility for pattern-directed computation
over streams of records, a rich facility for matching regular-expression
patterns in strings, event-based interrupt handling, user-level threads,
a futuristic module system, and an interactive environment. Scsh comes
with extensive documentation describing these and other features.
--
Jens Axel Søgaard
| |
Peter Makholm (02-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 02-09-02 07:20 |
|
Peter Mogensen <apm-at-mutex-dot-dk@nospam.no> writes:
> Perl: IMHO Genialt sprog. både til systemadministration, web og små
> applikationer.
Hvis du sigter på foden og tryker af, så skal perl nok sørge for at
kuglen når målet. Skriver du grim perlkode, er det selvfølgeligt svært
at læse et halvt år efter. Det samme gør sig dog gældende for alle
andre sprog.
OO-delen af perl er primært decideret uelegant hvis man interesserer
sig for hvordan det er implementeret.
Jeg løser mange ad hoc-opgaver med perl one-liners og arbejder med et
større system skrevet i perl (Sikkert på den store side af 15KLoC)
Dem der skriver rigtig grim perl-kode har ikke lært det af de rigtige
perl-bøger (Learning Perl og Programming Perl). Men der er
selvfølgelig nogen der bare ikke kan lide grep- og map-funktionerne
eller af man flytter betingelsen om bag et udtryk.
Manglen på et officielt switch-statement får også nogle til at flejne
ud.
> Python: Mere elegant og OO end Perl, men Perl føles bedre til lige at
> strikke noget effektivt sammen.
(Hmmm, måske skulle man skrive en obfuscator til python. På folks
udsagn om sproget lader det til at være umuligt.)
> Tcl: Noget specielt sprog, men ofte brugt da det virker godt sammen
> med Tk GUI toolkittet.
Jeg tror ikke at Tk er den gode undskyldning for Tcl mere. Perl- og
python-bindingerne skulle være fuldt ud lige så gode som
tcl-bindingerne.
Tcl er designet som et glue-sprog og er efter sigende god til at lime
andre ting sammen. Det er derfor også let at udvide sproget
syntaktisk.
Perl giver hvisser muligheder for at udvide syntaksen med Filters, men
jeg ved ikke hvor pænt det er og det er i hvert fald noget som ikke er
beregnet for begynderer.
> BASH: Var der en der sagde. Jo, man kan bruge det, men det er
> langsommere (skal ofte starte andre programmer), mere usikkert og
> error-prone.
Jeg tror sjældent at jeg bruger bash hvis det er mere indviklet end en
ydre løkke og en pipeline. Så kalder jeg også selvfølgelig også perl
hvor det er lettest.
perl, head, tail, cut, grep, sort, wc er dejlige lige at smide sammen
i en pipeline. Ting ville næsten fylde dobbelt så meget at skrive i ren
perl.
--
Peter Makholm | One thing you do is prevent good software from
peter@makholm.net | being written. Who can afford to do professional
http://hacking.dk | work for nothing?
| -- Bill Gates
| |
Claus Rasmussen (02-09-2002)
| Kommentar
Fra : Claus Rasmussen |
Dato : 02-09-02 19:28 |
|
Peter Makholm wrote:
> Manglen på et officielt switch-statement får også nogle til at flejne
> ud.
Mon ikke. Og så i perl, der ellers er det mest overlæssede sprog mht.
at give mulighed for at skrive det samme udtryk på 117 forskellige
måder. Larry har f.eks taget sig tid til at gøre både 'if (cond) stmt'
og 'stmt if (cond)' lovligt.
Ved du om der er håb for perl6 ?
-Claus
| |
Peter Makholm (02-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 02-09-02 20:52 |
|
Claus Rasmussen <clr@cc-consult.dk> writes:
> Peter Makholm wrote:
>
>> Manglen på et officielt switch-statement får også nogle til at flejne
>> ud.
>
> Mon ikke.
Men jeg fatter det ikke.
> Ved du om der er håb for perl6 ?
Jo, ifølge Apocalypse 4 kommer der en switch-ligende konstruktion i
perl6.
Jeg savner nu sjældent switch-statements. Jeg bliver meget gladere for
den nye smart match-operator som switch-konstruktionen kommer til at
bruge.
Den nye smart match-operator giver mulighed for at lade perl finde ud
af den rigtige måde at matche på. Så den bruger eq ved strenge og ==
ved tal og håndterer lister og arrays på en fornuftig måde.
--
Peter Makholm | Yes, you can fight it, but in the end the ultimate
peter@makholm.net | goal of life is to have fun
http://hacking.dk | -- Linus Torvalds
| |
Peter Makholm (04-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 04-09-02 21:08 |
|
Bo Lorentsen <bl@LUE.DK.spam.free> writes:
> jeg vil stadig mene at de ikke er gode til at træde barne sko I. Lige
> netop algorithmer vil da være lægget i et sprog hvor man ikke skal tænke
> maskin nært.
Det kommer nu an på ...
Algoritmik er nu engang lettest når man kan beregne kompleksiteter,
både på køretiden og på pladsforbruget. Især pladsforbruget kan være
svært at få et nøjagtigt overblik over hvis ens sprog er for højnivo.
Oplevelser som 'uhhh vi kan sorterer in-place' er også svært at opnå i
sprog hvor man ikke har styr på pladsforbruget.
Så i et rigtigt basis-algoritmikkursus bliver man nød til at tænke
maskinnært.
--
Peter Makholm | There are 10 kinds of people. Those who count in
peter@makholm.net | binary and those who don't
http://hacking.dk |
| |
Bo Lorentsen (05-09-2002)
| Kommentar
Fra : Bo Lorentsen |
Dato : 05-09-02 21:19 |
|
In <87y9ah4iy2.fsf@xyzzy.adsl.dk>, Peter Makholm wrote:
> Algoritmik er nu engang lettest når man kan beregne kompleksiteter, både
> på køretiden og på pladsforbruget. Især pladsforbruget kan være svært at
> få et nøjagtigt overblik over hvis ens sprog er for højnivo.
Tjaa, hvis det virkelig er det man ligger vægt på så har du ganske ret,
men hvad ved jeg om det, jeg er ikke så skolet
> Oplevelser som 'uhhh vi kan sorterer in-place' er også svært at opnå i
> sprog hvor man ikke har styr på pladsforbruget.
Det kan du jo have ret i, men i disse Java/.NET tider troede jeg ikke den slags
var "moderne"
> Så i et rigtigt basis-algoritmikkursus bliver man nød til at tænke
> maskinnært.
/BL
| |
Peter Makholm (05-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 05-09-02 07:01 |
|
Peter Mogensen <apm-at-mutex-dot-dk@nospam.not> writes:
> Nej. Python er godt til at lære folk at programmere... også OO.
Er python et godt sprog hvis folk skal lære andre
programeringsparadigmer end OO eller mente du 'dog kun OO'?
--
Peter Makholm | If you can't do any damage as root, are you still
peter@makholm.net | really root?
http://hacking.dk | -- Derek Gladding about SELinux
| |
Peter Makholm (05-09-2002)
| Kommentar
Fra : Peter Makholm |
Dato : 05-09-02 21:30 |
|
Bo Lorentsen <bl@LUE.DK.spam.free> writes:
> Tjaa, hvis det virkelig er det man ligger vægt på så har du ganske ret,
> men hvad ved jeg om det, jeg er ikke så skolet
Hvis man skal lære noget om algoritmik og kompleksitet så er det
nødvendigt at lægge vægt på det. Hvis man ikke vil lære noget om
kompleksitet kan man lige så godt undlade at lære noget om
allgoritmik.
>> Oplevelser som 'uhhh vi kan sorterer in-place' er også svært at opnå i
>> sprog hvor man ikke har styr på pladsforbruget.
> Det kan du jo have ret i, men i disse Java/.NET tider troede jeg ikke den slags
> var "moderne"
Det er altså noget man bliver nød til at tænke på når ens datamængder
skal måles i i MB eller GB. Så er det altså tvingende nødvendigt at
kunne sit håndværk og ikke bare følge med stømmen og bruge hvad der nu
er popsmart den dag.
(Gammel og bitter, mig? Jeg er aldeles ikke gammel)
--
Peter Makholm | We constantly have to keep in mind why natural
peter@makholm.net | languages are good at what they're good at. And to
http://hacking.dk | never forget that Perl is a human language first,
| and a computer language second
| |
Peter Dalgaard BSA (05-09-2002)
| Kommentar
Fra : Peter Dalgaard BSA |
Dato : 05-09-02 22:45 |
|
Peter Makholm <peter@makholm.net> writes:
> (Gammel og bitter, mig? Jeg er aldeles ikke gammel)
[Checker lige CV..... Aaaargh!!!! Det tør siges. Han var f'me ikke
engang begyndt at spise babymos da jeg startede på Dat 0!]
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
| |
Bo Lorentsen (05-09-2002)
| Kommentar
Fra : Bo Lorentsen |
Dato : 05-09-02 23:10 |
|
In <877ki06uxq.fsf@xyzzy.adsl.dk>, Peter Makholm wrote:
> Hvis man skal lære noget om algoritmik og kompleksitet så er det
> nødvendigt at lægge vægt på det. Hvis man ikke vil lære noget om
> kompleksitet kan man lige så godt undlade at lære noget om allgoritmik.
Ja det lyder sandeligt helt rigtig
> Det er altså noget man bliver nød til at tænke på når ens datamængder
> skal måles i i MB eller GB. Så er det altså tvingende nødvendigt at
> kunne sit håndværk og ikke bare følge med stømmen og bruge hvad der nu
> er popsmart den dag.
Har du fået klippet øjenbryn for nyligt ?
> (Gammel og bitter, mig? Jeg er aldeles ikke gammel)
/BL
| |
Peter Jespersen (31-08-2002)
| Kommentar
Fra : Peter Jespersen |
Dato : 31-08-02 23:27 |
|
On Sat, 31 Aug 2002 20:43:47 +0200, Anders Lund wrote:
>Jeg kan allerede >lidt< java og c++, men ikke nok til at begå mig
>ordentligt. Jeg kan flyende vbscript. Så jeg mangler lidt et sprog til at
>lave små opgaver på min linux server, derfor overvejer jeg at lære mig selv
>perl. Men er det det bedste valg, eller findes der noget bedre?
REXX er lige til at gå til....det er et såkaldt human orienteret sprog, for
eksempel vil say "Hello World" udskrive Hello World til std output, hvilket
gør det ganske let at gå til. Der findes for skellige varianter som NetREXX
hvor det for eksempel er muligt at kompilere til Java bytecode og Object REXX
der er en objekt orienteret variant.
IBM Object REXX er lige til at hente
http://www-3.ibm.com/software/ad/obj-rexx/
http://www.rexxla.org/
Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark, Linux User #221493
flywheel@illogical.dk
http://www.illogical.dk
Old programmers never die. They just branch to a new address.
| |
Kent Friis (31-08-2002)
| Kommentar
Fra : Kent Friis |
Dato : 31-08-02 23:27 |
|
Den Sat, 31 Aug 2002 22:27:29 +0200 (CEST) skrev Peter Jespersen:
>On Sat, 31 Aug 2002 20:43:47 +0200, Anders Lund wrote:
>
>>Jeg kan allerede >lidt< java og c++, men ikke nok til at begå mig
>>ordentligt. Jeg kan flyende vbscript. Så jeg mangler lidt et sprog til at
>>lave små opgaver på min linux server, derfor overvejer jeg at lære mig selv
>>perl. Men er det det bedste valg, eller findes der noget bedre?
>
>REXX er lige til at gå til....det er et såkaldt human orienteret sprog, for
>eksempel vil say "Hello World" udskrive Hello World til std output, hvilket
>gør det ganske let at gå til.
I så fald vil jeg prøve at forsætte den logiske tankegang, og gætte på
at write "Hello World", vil få den til at sente ordene til talesyntese-
enheden
Hvis endelig du skal bruge det argument, så må COBOL's "DISPLAY" være
den der er bedst valgt, og derfor er det det nemmeste sprog...
(et forsøg på at være objektiv, jeg betragter absolut ikke COBOL som
et godt sprog).
Mvh
Kent
--
Which one is faster - Lotus Notes or Lotus Esprit?
| |
Thorbjoern Ravn Ande~ (01-09-2002)
| Kommentar
Fra : Thorbjoern Ravn Ande~ |
Dato : 01-09-02 11:24 |
|
"Anders Lund" <Anders@zaimGED.dk> writes:
> Jeg kan allerede >lidt< java og c++, men ikke nok til at begå mig
> ordentligt. Jeg kan flyende vbscript. Så jeg mangler lidt et sprog til at
> lave små opgaver på min linux server, derfor overvejer jeg at lære mig selv
> perl. Men er det det bedste valg, eller findes der noget bedre?
Til små opgaver under Linux er Perl helt fint.
Du vil have glæde af at få dit lokale bibliotekt til at skaffe
"Learning Perl" hjem.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus
| |
|
|