mboost-dp1

low level programmering- den snart tabte kunst?


Gå til bund
Gravatar #151 - Windcape
11. aug. 2011 02:35
arne_v (148) skrev:
Det karakteristiske for closures (og det som navnet kommer fra !) er at de fanger konteksten fra hvor de blev created.
Og hvordan mener du at delegates ikke gør det?

delegate() { }
eller
() => {}
har begge samme muligheder for at fange den kontekst de blev oprettet i!
Gravatar #152 - arne_v
11. aug. 2011 02:35
Windcape (147) skrev:
D kalder også deres closures for delegates!


Ikke som jeg læse D spec http://www.prowiki.org/upload/duser/spec_DMD_1.00.... sektionen "Delegates, Function Pointers, and Dynamic Closures". Tilsyneladende er closures også et special tilfælde af delegates i D.
Gravatar #153 - Windcape
11. aug. 2011 02:36
arne_v (149) skrev:
Givet #148 kan vi så udlede at du skal igang med at lære nogle high level sprog?
Er det ikke nærmere dig og onetreehell som skal genopfriske jeres .NET jargon?
Gravatar #154 - arne_v
11. aug. 2011 02:36
Windcape (151) skrev:
Og hvordan mener du at delegates ikke gør det?

delegate() { }
eller
() => {}
har begge samme muligheder for at fange den kontekst de blev oprettet i!


Ja.

Men det første eksempel er ikke en generel delegate men det special tilfælde af delegate som hedder en anonym metode.
Gravatar #155 - arne_v
11. aug. 2011 02:37
Windcape (153) skrev:
Er det ikke nærmere dig og onetreehell som skal genopfriske jeres .NET jargon?


Da vores jargon synes at matche C# spec, Wikipedia og Jon Skeet, så NEJ.
Gravatar #156 - Windcape
11. aug. 2011 02:38
arne_v (154) skrev:
Men det første eksempel er ikke en generel delegate men det special tilfælde af delegate som hedder en anonym metode.
Og?

Så nu har du altså bestemt at når man snakker om delegates i .NET regi, snakker man aldrig om
delegate() { }


Interassant.
Gravatar #157 - Windcape
11. aug. 2011 02:39
arne_v (155) skrev:
Da vores jargon synes at matche C# spec, Wikipedia og Jon Skeet, så NEJ.
De er jo alle 3 enige med mig i at "delegate() { }" også er en closure!
Gravatar #158 - arne_v
11. aug. 2011 02:47
Det er nemmere at illustrere forskllen mellem C function pointers, C# delegates og C# "closures" med et eksempel.

C function pointer:


#include <stdio.h>

typedef void (*fptr)(int a);

void f1(int a)
{
printf("f1: %d\n", a);
}

void f2(int a)
{
printf("f2: %d\n", a);
}

void test(fptr f)
{
f(123);
}

int main()
{
test(f1);
test(f2);
return 0;
}


En variant af C# delegate:


using System;

public class Program
{
public delegate void Del(int a);
public static void F1(int a)
{
Console.WriteLine("F1: " + a);
}
public static void F2(int a)
{
Console.WriteLine("F2: " + a);
}
public static void Test(Del d)
{
d(123);
}
public static void Main(string[] args)
{
Test(F1);
Test(F2);
Console.ReadKey();
}
}


Dette er tydeligvis en delegate. Det er også tydeligvis meget ens med en C function pointer. Og det er også tydeligvis ikke n closure, da konstruktionen ikke kan capture noget som helst.

En anden variant af C# delegate som bruger anonyme metoder:


using System;

public class Program
{
public delegate void Del(int a);
public static void Test(Del d)
{
d(123);
}
public static void Main(string[] args)
{
Test(delegate(int a) { Console.WriteLine("F1: " + a); } );
Test(delegate(int a) { Console.WriteLine("F2: " + a); } );
Console.ReadKey();
}
}


Dette er en delegate. Dette er relativt langt fra C function pointer. Og dette er en closure, da den potentielt kunne capture noget fra Main.


Gravatar #159 - arne_v
11. aug. 2011 02:48
#158

Og en variant som faktisk capture noget:


using System;

public class Program
{
public delegate void Del(int a);
public static void Test(Del d)
{
d(123);
}
public static void Main(string[] args)
{
int b = 456;
Test(delegate(int a) { Console.WriteLine("F1: " + a + " " + b); } );
Test(delegate(int a) { Console.WriteLine("F2: " + a + " " + b); } );
Console.ReadKey();
}
}


Eksemplet er ikke kønt, men jeg startede jo med et C function pointer eksempel så jeg var lidt begrænset.
Gravatar #160 - Windcape
11. aug. 2011 02:51
#158

Så delegates kan som sagt være closures (men er det ikke nødvendigvis), og delegates kan også være (named) function pointers (men er det ikke nødvendigvis).

Altså som sagt, jeg ser ingen grund til at betragte dem som 2 forskellige ting, når der ikke er angivet en præcis kontekst.

Og taget i betragtning at delegates i form af anonyme metoder er mere normalt i .NET, end delegates som function pointers (marshalling undtaget!), så er det jo en meget rimelig konklusion.

Gravatar #161 - arne_v
11. aug. 2011 02:52
Windcape (157) skrev:
De er jo alle 3 enige med mig i at "delegate() { }" også er en closure!


Ja.

Men det er der skam heller ikke nogen der har benægtet. Vi har hele tiden sagt at closures er delegates.

arne_v (137) skrev:
Fordi delegates i nogen sammenhæng herunder når de ligner C function pointer hvilket var konteksten ikke er closures.


onetreehell (139) skrev:
En delegate behøver ikke at være en closure!!!


Hvad vi ikke er enig med er dit udsagn:

Windcape (136) skrev:
Jeg undre mig over at du betragter det som 2 forskellige ting.


Windcape (142) skrev:

delegates er function pointers til named eller anonymous methods, og closures (i form af lambda expressions) er function pointers til named eller anonymous methods.

Very much same same!


De er ikke det samme.

Der er delegates som ikke er closures.
Gravatar #162 - Windcape
11. aug. 2011 02:54
arne_v (161) skrev:
De er ikke det samme.

Der er delegates som ikke er closures.
Og der er delegates som er!

Derfor er det jo meget relevant at spørge hvorfor du betragtede det som 2 forskellige ting, når der ikke var nogen kontekst som sagde at du snakkede om named-function-pointers, og ikke anonymous-method-closures.

Gravatar #163 - arne_v
11. aug. 2011 02:56
Windcape (156) skrev:
Og?

Så nu har du altså bestemt at når man snakker om delegates i .NET regi, snakker man aldrig om
delegate() { }


Interassant.


Når man skal vise at 2 begreber er forskellige er det nok at vise at der er 1 tilfælde hvor de er forskellige. Det er ikke nødvendigt at vise at de altid er forskellige.
Gravatar #164 - arne_v
11. aug. 2011 03:00
Windcape (160) skrev:
Altså som sagt, jeg ser ingen grund til at betragte dem som 2 forskellige ting, når der ikke er angivet en præcis kontekst.


Windcape (162) skrev:
Derfor er det jo meget relevant at spørge hvorfor du betragtede det som 2 forskellige ting, når der ikke var nogen kontekst som sagde at du snakkede om named-function-pointers, og ikke anonymous-method-closures.


Når man udtaler sig om X antager man normalt at man taler om X generelt ikke om special tilfælde af X.

Ellers kan det jo godt blive lidt forvirrende.

Eksempler:

Java og C# er ens (jeg kan godt skrive en metode som både er valid Java og C#).

Kørsel af C# giver en exception (jeg kan skriv et C# program som giver en exception).

O.s.v..

Gravatar #165 - Windcape
11. aug. 2011 03:00
#163

Når et begreb er tve-tydigt så er det relevant at forklare hvilken mening af ordet man benytter.

"En kvadrat er en rektangel, men en rektangel er ikke nødvendigvis en kvadrat"
Gravatar #166 - arne_v
11. aug. 2011 03:01
#164

Og der var iøvrigt angivet en kontekst nemlig C function pointers.

En kontekst hvor delegates ikke er closures.
Gravatar #167 - Windcape
11. aug. 2011 03:02
arne_v (164) skrev:
Når man udtaler sig om X antager man normalt at man taler om X generelt ikke om special tilfælde af X.

Ellers kan det jo godt blive lidt forvirrende.
Når man snakker om delegates generelt i .NET, snakker man også om closures.

Det gør sig ihvertfald gældende på IRC, Twitter, StackOverflow og på samtlige konferencer jeg har været på, samt for samtlige personer jeg kender der arbejder med .NET
Gravatar #168 - arne_v
11. aug. 2011 03:03
#165

Hvis du kigger på #148 vil se at der er ikke nogen som helst tvetydighed.

Både delegates og closures er veldefinerede.
Gravatar #169 - Windcape
11. aug. 2011 03:08
#168

Så din mening er altså ikke at en closure kan pege på en named method.
Gravatar #170 - arne_v
11. aug. 2011 03:11
Windcape (167) skrev:

Når man snakker om delegates generelt i .NET, snakker man også om closures.

Det gør sig ihvertfald gældende på IRC, Twitter, StackOverflow og på samtlige konferencer jeg har været på, samt for samtlige personer jeg kender der arbejder med .NET


Det er sgu da pinligt for de steder at de ikke ved hvad delegates i C# er.

Men så er spørgsmålet naturligvis om det er rigtigt.

Se f.eks. dette spørgsmål fra idag på SO:
http://stackoverflow.com/questions/7011886/invokin...

Delegate: ja. Closure: nej.
Gravatar #171 - arne_v
11. aug. 2011 03:13
#169

Hvordan relaterer det spørgsmål sig til om hvorvidt delegates og closures er veldefinerede begreber?
Gravatar #172 - Windcape
11. aug. 2011 03:16
arne_v (171) skrev:
Hvordan relaterer det spørgsmål sig til om hvorvidt delegates og closures er veldefinerede begreber?
Fordi at hvis man betragter en closure som noget der kan pege på en navngiven funktion, så er alle delegates pludselig closures.

Hvis man ikke gør, så er der forskel.

arne_v (171) skrev:
Hvordan relaterer det spørgsmål sig til om hvorvidt delegates og closures er veldefinerede begreber?
Closure er en veldefineret teoretisk ide. Delegates referer til noget som er sprogspecifikt implementeret i C#.

Alting er delegates i C#. Og man så mener at delegates også er closures, eller ej, afhænger tydeligvis af ens fortolkning af closures.

Gravatar #173 - Windcape
11. aug. 2011 03:18
Spørgsmålet er simpelt. Er dette her 2 closures eller ej?


Foo(Bar)



Foo(() => Bar())
Gravatar #174 - arne_v
12. aug. 2011 02:28
Windcape (172) skrev:
Fordi at hvis man betragter en closure som noget der kan pege på en navngiven funktion, så er alle delegates pludselig closures.


Det er korrekt.

Men de 2 former for clojures i C# er jo begge højre side expressions, så man kan ikke assigne noget som helst til dem heller ikke navngivne funktioner.
Gravatar #175 - arne_v
12. aug. 2011 02:30
Windcape (172) skrev:
Alting er delegates i C#. Og man så mener at delegates også er closures, eller ej, afhænger tydeligvis af ens fortolkning af closures.


Men de definitioner som bruges i lidt bedre kilder siger alle sammen nej.
Gravatar #176 - arne_v
12. aug. 2011 02:34
Windcape (173) skrev:
Spørgsmålet er simpelt. Er dette her 2 closures eller ej?


Foo(Bar)



Foo(() => Bar())


Første eksempel er et kald af noget som kan være en normal metode, eller en delegate som ikke er en closure eller en delegate som er en closure med et argument som enten kan være en normal værdi eller eller en delegate som ikke er en closure eller en delegate som er en closure.

Andet eksempel er et kald af noget som kan være en normal metode, eller en delegate som ikke er en closure eller en delegate som er en closure med et argument som er en delegate der er en closure som kalder noget som kan være en normal metode eller eller en delegate som ikke er en closure eller en delegate som er en closure.

Hvis du angav erklæringerne af Foo og Bar kunne man se hvad det var.
Gravatar #177 - onetreehell
16. aug. 2011 11:44
Gravatar #178 - onetreehell
16. aug. 2011 12:52
Interessant artikel. Meget lang, dog. Det interessante står ved intellisense / visualstudio og det sidste 'afsnit'.

Edit: Og jeg tror ikke det er noget der er unikt for visualstudio / intellisense.
Gravatar #179 - Windcape
16. aug. 2011 13:17
#178

Det morsomme er nok at Visual Studio hovedsageligt bruges i job, hvor det at skrive kode ikke er det vigtigste.

De job hvor det vigtigste er at skrive en forbandet masse kode, i f.eks. C (C kræver altid sindsyge mængder kode, for den mindste funktionalitet), der er der stort set ingen værktøjer.

Jeg tror hippierne hader at være produktive. Tænk hvis de faktisk kunne lave mere , fordi de havde bedre værktøjer :o

(Derudover er WinForms, ligesom WebForms, noget der skal udrensning med ild!)
Gravatar #180 - Hubert
16. aug. 2011 13:26
Windcape (179) skrev:
#178

Det morsomme er nok at Visual Studio hovedsageligt bruges i job, hvor det at skrive kode ikke er det vigtigste.


Skal det forståes sådan at man bruger visual studio hvis man alligevel ikke skal lave noget vigtigt? Eller hvordan skal det forståes?
Gravatar #181 - Windcape
16. aug. 2011 13:28
Hubert (180) skrev:
Skal det forståes sådan at man bruger visual studio hvis man alligevel ikke skal lave noget vigtigt? Eller hvordan skal det forståes?
10% (eller mindre) af software-udvikling er at skrive kode.

Men jeg kan godt forstå det er svært at fatte som en supporter, til trods for at det er blevet diskutteret tusindevis af gangen på newz.dk over årene.
Gravatar #182 - onetreehell
16. aug. 2011 13:31
Windcape (179) skrev:
De job hvor det vigtigste er at skrive en forbandet masse kode, i f.eks. C (C kræver altid sindsyge mængder kode, for den mindste funktionalitet), der er der stort set ingen værktøjer.

Det ville lyde mere troværdigt hvis du faktisk havde erfaring i at skrive i C. Du har dog ret i at programmer skrevet i C nogle gange når op på høje linjetal.



Windcape (179) skrev:
Jeg tror hippierne hader at være produktive. Tænk hvis de faktisk kunne lave mere , fordi de havde bedre værktøjer :o

Ja, som han skriver var han pludselig mere produktiv i C, da han ikke længere skulle slås med autocompletion og slå små detaljer op i dokumentationen, og i stedet kunne overveje selve problemet og koden. Det er måske lige at stramme den at sige at notepad er et bedre værktøj end visualstudio, dog.

Edit: som han skriver tvinger intellisense programmøren en til at skreve programmet bottom-up.
Gravatar #183 - Hubert
16. aug. 2011 13:34
Windcape (181) skrev:
10% (eller mindre) af software-udvikling er at skrive kode.

Men jeg kan godt forstå det er svært at fatte som en supporter, til trods for at det er blevet diskutteret tusindevis af gangen på newz.dk over årene.


Jeg er omtrendt lige så meget supporter som jeg er udvikler...

Nu kunne det jo være fristende at komme ned på dit niveau men det er der vist ingen grund til... Du har jo vist indtil flere gange at du styrer det niveau bedre end de fleste
Gravatar #184 - Windcape
16. aug. 2011 13:34
onetreehell (182) skrev:
Det ville lyde mere troværdigt hvis du faktisk havde erfaring i at skrive i C. Du har dog ret i at programmer skrevet i C nogle gange når op på høje linjetal.
Prøv at sammenligne sprogene her http://tinodidriksen.com/2010/03/17/language-compa...

onetreehell (182) skrev:
Ja, som han skriver var han pludselig mere produktiv i C, da han ikke længere skulle slås med autocompletion og slå små detaljer op i dokumentationen
Det tager længere tid at slå dokumentation op når du arbejder med C, fordi du ikke har inline dokument (that means intellisense). Og hvis du skal bruge nye APIer, har du uden autocomplete, brug for at læse op (evt. printe, eller have 2 skærme) så du kan se hvordan du skal kalde metoderne, og hvilke arugmenter de skal have.

En mand der skriver "I like typing" som mod-argument for at have templates, har jeg svært ved at tage seriøst. Selv C udviklere har vel templates/snippets (oh hai Emacs/vim)
Gravatar #185 - Windcape
16. aug. 2011 13:36
Hubert (183) skrev:
Jeg er omtrendt lige så meget supporter som jeg er udvikler...
Den job-beskrivelse du har givet før, er at du er supporter.

Så medmindre du har fået nyt arbejde, synes jeg det er en meget passende beskrivelse.
Gravatar #186 - Windcape
16. aug. 2011 13:43
Og forresten så er Petzolds beskrivelse af intellisense I Visual Studio temmelig uddateret.

Men mange af hans argumenter er morsomme. F.eks. når han ikke virker så glad for "You must define all variables before you use them.", til trods for at han godt kunne lide C.

C89 kræver jo netop at man definere alle sine variable som det første i en metode.
Gravatar #187 - Hubert
16. aug. 2011 13:57
Windcape (185) skrev:
Den job-beskrivelse du har givet før, er at du er supporter.

Så medmindre du har fået nyt arbejde, synes jeg det er en meget passende beskrivelse.


Hvor skulle jeg have givet den beskrivelse? Eller du mener måske at alle der arbejder med drift er supportere?
Gravatar #188 - onetreehell
16. aug. 2011 14:00
Windcape (186) skrev:
Men mange af hans argumenter er morsomme. F.eks. når han ikke virker så glad for "You must define all variables before you use them.", til trods for at han godt kunne lide C.

Sguda ikke mens man stadig er ved at skrive koden. Det er netop det at intellisense tvinger dig til at skrive bottom-up, altså starte med at skrive implementeringsdetaljerne før selve 'designet', han brokker sig over.

Jeg har kigget lidt på dit link. Det er en noget underlig artikel. Man kan godt se på hans C-kode at han er vant til at skrive C++. Det er i øvrigt noget grim C kode han skriver. Hvad var det nu din pointe var?
Gravatar #189 - Windcape
16. aug. 2011 14:11
onetreehell (188) skrev:
Hvad var det nu din pointe var?

Længden af koden.

onetreehell (188) skrev:
Det er netop det at intellisense tvinger dig til at skrive bottom-up, altså starte med at skrive implementeringsdetaljerne før selve 'designet', han brokker sig over.
Hvilket er noget pjat. Det er kun fordi han er er vant til at udvikle på en anden måde.

Du kan jo sagtens ignorer intellisense, og skrive kode der ikke compiler med det samme. (Uden at den er så træls som den åbenbart var for 6 år siden).

Derudover så har folk jo ingen problemer med at udvikle test-driven / test-first i C#/.NET. Hvilket vel ikke kan siges at være bottom-up udvikling på nogen måde!

onetreehell (188) skrev:
Det er i øvrigt noget grim C kode han skriver
Du må gerne uddybe. Koden er jo let-læseligt (omend lang). Hvordan kan den være grim?
Gravatar #190 - arne_v
16. aug. 2011 16:19
Windcape (185) skrev:

Den job-beskrivelse du har givet før, er at du er supporter.


What?

Hubert for flere gange forklaret at han arbejder med drift - system og netværks administration.

Men jeg kan ikke huske nogensinde at have set ham hævde at arbejde som supporter.

Gravatar #191 - arne_v
16. aug. 2011 16:37
Windcape (179) skrev:

C kræver altid sindsyge mængder kode, for den mindste funktionalitet


"sindsyge mængder" er et heftigt udtryk.

Men man i forbindelse med estimation antager man normalt at det kræver ca. 2.5 gange så mang elinier i C som i Ada/Java/C++ (og C# ligger nok sammen med de 3).

Windcape (179) skrev:

der er der stort set ingen værktøjer.

Jeg tror hippierne hader at være produktive. Tænk hvis de faktisk kunne lave mere , fordi de havde bedre værktøjer :o


For det første, så er der tools. Også til C og C++. Visual Studio, Eclipse, Xcode, Emacs etc..

For det andet så er det ikke så vigtigt igen. Samme estimations metodikker antager at editor->text IDE sparer ca. 7.5% og at text IDE->GUI IDE også sparer ca. 7.5%.

Forskellene mellem forskellige GUI IDE må ligge nede omkring 1-2%.

Gravatar #192 - arne_v
16. aug. 2011 16:53
Windcape (184) skrev:

Prøv at sammenligne sprogene her http://tinodidriksen.com/2010/03/17/language-compa...


Windcape (189) skrev:
Længden af koden.


C kode er normalt længere.

Det er en naturlig konsekvens af at gå ned i abstraktionsniveau.

Windcape (189) skrev:
Du må gerne uddybe. Koden er jo let-læseligt (omend lang). Hvordan kan den være grim?


Jeg er heller ikke for begejstret for koden. Brugen af ftell, multiple fgets gør koden unødigvendigt svær at læse efter min mening.
Gravatar #193 - Windcape
16. aug. 2011 17:01
arne_v (192) skrev:
Jeg er heller ikke for begejstret for koden. Brugen af ftell, multiple fgets gør koden unødigvendigt svær at læse efter min mening.
Og hvad er alternativet da? At benytte eksterne biblioteker? Sammenlignen var jo på længden af koden, som derfor nødvendigvis skulle være med standard biblioteker.

arne_v (191) skrev:
For det andet så er det ikke så vigtigt igen. Samme estimations metodikker antager at editor->text IDE sparer ca. 7.5% og at text IDE->GUI IDE også sparer ca. 7.5%.
I selve det at kode.

Hvad med refactoring? Og kom ikke og sig du tager search&replace refactoring seriøst!

Ligeledes er intellisense jo ikke bare autocomplete, det er også indbygget snippets, så man ikke skal selv skrive gængs kode selv.
Gravatar #194 - arne_v
16. aug. 2011 17:07
Windcape (186) skrev:

Og forresten så er Petzolds beskrivelse af intellisense I Visual Studio temmelig uddateret.


Selvom har har kastet sig lidt over .NET er hans hjemmebase vel stadig Win32 API og Visual Studio 6.
Gravatar #195 - arne_v
16. aug. 2011 17:10
Windcape (186) skrev:

C89 kræver jo netop at man definere alle sine variable som det første i en metode.


Nej.

I C89 skal variable erklæres i toppen af en blok. Den blok kan være en funktion, men kan også være andet.

Andre sprog kræver variabel erklæring i toppen bl.a. Fortran og Pascal.
Gravatar #196 - arne_v
16. aug. 2011 17:10
Windcape (193) skrev:
I selve det at kode.


Nej. I hele udviklingen.
Gravatar #197 - arne_v
16. aug. 2011 17:19
Windcape (193) skrev:

Og hvad er alternativet da? At benytte eksterne biblioteker? Sammenlignen var jo på længden af koden, som derfor nødvendigvis skulle være med standard biblioteker.


Naturligvis skal det være med standard bibliotek.

Men ingen af de andre sprog bruger noget som ligner ftell. Det burde heller ikke være nødvendigt i C. Og brugen af det virker meget mystisk på mig.

Samme med de 2 fgets kald. Men jeg formoder at det skyldes håndteringen af når linien er længere end buffer.
Gravatar #198 - Windcape
16. aug. 2011 17:29
arne_v (195) skrev:
I C89 skal variable erklæres i toppen af en blok. Den blok kan være en funktion, men kan også være andet.
Og hvad er forskellen? Det er stadigvæk usandsynligt grimt. I C# kan du bare skrive "var id = ..." midt i det hele, uden at det er et problem. Det kan du ikke i C.

arne_v (196) skrev:
Nej. I hele udviklingen.
Tvivlsomt.

Værktøjer der ikke kan lave refactoring baseret på expression trees, vil jo på ingen måde kunne refactor navnet på en metode, samt alt brug af den i 100 forskellige filer.

Og at bruge search&replace til refactoring (som er helt normalt for PHP udviklere!) er simpelthen useriøst.
Gravatar #199 - arne_v
16. aug. 2011 17:43
Windcape (198) skrev:

Og hvad er forskellen? Det er stadigvæk usandsynligt grimt.


Der er nogen udviklere som foretrækker at at være 100% korrekt og andre for hvem "noget i den retning" er godt nok.
Gravatar #200 - arne_v
16. aug. 2011 17:44
Windcape (198) skrev:

Tvivlsomt.


Det er hvad research indenfor emnet viser.

Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login