mboost-dp1
low level programmering- den snart tabte kunst?
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Og hvordan mener du at delegates ikke gør det?arne_v (148) skrev:Det karakteristiske for closures (og det som navnet kommer fra !) er at de fanger konteksten fra hvor de blev created.
delegate() { }eller
() => {}har begge samme muligheder for at fange den kontekst de blev oprettet i!
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.
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.
Det er nemmere at illustrere forskllen mellem C function pointers, C# delegates og C# "closures" med et eksempel.
C function pointer:
En variant af C# delegate:
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:
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.
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.
#158
Og en variant som faktisk capture noget:
Eksemplet er ikke kønt, men jeg startede jo med et C function pointer eksempel så jeg var lidt begrænset.
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.
#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.
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.
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.
Og der er delegates som er!arne_v (161) skrev:De er ikke det samme.
Der er delegates som ikke er closures.
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.
Windcape (156) skrev:Og?
Så nu har du altså bestemt at når man snakker om delegates i .NET regi, snakker man aldrig omdelegate() { }
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.
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..
Når man snakker om delegates generelt i .NET, snakker man også om closures.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.
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
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.
Fordi at hvis man betragter en closure som noget der kan pege på en navngiven funktion, så er alle delegates pludselig closures.arne_v (171) skrev:Hvordan relaterer det spørgsmål sig til om hvorvidt delegates og closures er veldefinerede begreber?
Hvis man ikke gør, så er der forskel.
Closure er en veldefineret teoretisk ide. Delegates referer til noget som er sprogspecifikt implementeret i C#.arne_v (171) skrev:Hvordan relaterer det spørgsmål sig til om hvorvidt delegates og closures er veldefinerede begreber?
Alting er delegates i C#. Og man så mener at delegates også er closures, eller ej, afhænger tydeligvis af ens fortolkning af closures.
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.
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.
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.
Edit: Og jeg tror ikke det er noget der er unikt for visualstudio / intellisense.
#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!)
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!)
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?
10% (eller mindre) af software-udvikling er at skrive kode.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?
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.
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.
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
Prøv at sammenligne sprogene her http://tinodidriksen.com/2010/03/17/language-compa...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.
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.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
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)
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.
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.
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?
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?
onetreehell (188) skrev:Hvad var det nu din pointe var?
Længden af koden.
Hvilket er noget pjat. Det er kun fordi han er er vant til at udvikle på en anden måde.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.
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!
Du må gerne uddybe. Koden er jo let-læseligt (omend lang). Hvordan kan den være grim?onetreehell (188) skrev:Det er i øvrigt noget grim C kode han skriver
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%.
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.
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 (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.
I selve det at kode.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%.
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.
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.
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.
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 (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.
Tvivlsomt.arne_v (196) skrev:Nej. I hele udviklingen.
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.
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.