mboost-dp1
unknown
.net er jo meget lækkert.
ligesom C/C++ og VB var for 10 år siden..!
synes C# er let at gå til, og der er mange lækre funktioner (i 2.0 - 1.0 manglede mange features efter min mening)
men alt i alt synes jeg så også at man i udviklingen (både med java og .net og de andre der er på markedet)
begår een stor fejl..!
for hver gang de finder på noget nyt, så kræver det mere CPU power, og flere ressourcer.
og efter min mening betyder flere ressourcer, og mere CPU power. mere strøm, og krav om hurtigere og bedre computere..!
jeg håber at udviklingen snart tænker over i de baner, for synes det er ved at være for meget at man nærmest bliver tvunget til at købe 3ghz++ og en gig ram, og et 4000 kr's grafikkort, bare for at kunne installere vista (når det nu kommer)
og flere og flere applikationer også krævere mere og mere..!
hvis man f.eks valgte at udvikle i assembler, tjaa. det ville godt nok kræve 7-8 gange mere tid at lave programmet, men tilgengæld ville det kræve en 10'e del ressourcer.
dog vil jeg gerne tilføje at jeg selv prøver at følge med. og jeg kan da også programmere i C#, så 100% modstander er jeg da ikke (måske fordi at livet er for kort til assembler)
men det ville da være lækkert hvis .net 4.0 (om 3 år :) )
var gjort mere effektiv
ligesom C/C++ og VB var for 10 år siden..!
synes C# er let at gå til, og der er mange lækre funktioner (i 2.0 - 1.0 manglede mange features efter min mening)
men alt i alt synes jeg så også at man i udviklingen (både med java og .net og de andre der er på markedet)
begår een stor fejl..!
for hver gang de finder på noget nyt, så kræver det mere CPU power, og flere ressourcer.
og efter min mening betyder flere ressourcer, og mere CPU power. mere strøm, og krav om hurtigere og bedre computere..!
jeg håber at udviklingen snart tænker over i de baner, for synes det er ved at være for meget at man nærmest bliver tvunget til at købe 3ghz++ og en gig ram, og et 4000 kr's grafikkort, bare for at kunne installere vista (når det nu kommer)
og flere og flere applikationer også krævere mere og mere..!
hvis man f.eks valgte at udvikle i assembler, tjaa. det ville godt nok kræve 7-8 gange mere tid at lave programmet, men tilgengæld ville det kræve en 10'e del ressourcer.
dog vil jeg gerne tilføje at jeg selv prøver at følge med. og jeg kan da også programmere i C#, så 100% modstander er jeg da ikke (måske fordi at livet er for kort til assembler)
men det ville da være lækkert hvis .net 4.0 (om 3 år :) )
var gjort mere effektiv
Øh din første påstand giver ikke så meget mening.
.Net er IKKE et programmeringssprog med et framework.
Du kan sagtens lave .net programmering i C#, VB, Python, C++ osv.
Problemmet med assembler er at det er absolut de aller færreste udviklere der har evnerne til at kode assembler på et niveau der kan hamle op med de compilere vi anvender i dag.
Problemmet med assembler er så også et det kun kan bruges på den ene CPU man har lært det til, f.eks. C/C++ kan bruges på utroligt mange forskellige CPU arkitekturer.
Det du kunne tænke dig i udviklingen er skam sket, tro mig hvis du to de compilere vi brugte for 15 år siden, og prøvede at compile programmer idag, ville du opdage de var meget langsommere, end hvis de blev compilet med nutidens compilere.
Men de programmer vi bruger i dag er bare meget mere komplexe end de var dengang.
For mange år siden spillede jeg Great Giana Sisters på min Amiga 500, og det kørte fint. I dag spiller jeg Oblivion på min P4 3.4 GHz med 1 GB ram, og det trækker SÅ MEGET tænder ud af min maskinen. Men spillet er så ufatteligt meget mere komplex og natur tro end Great Giana Sisters.
Se evt. også på Fly simulatorer, se på raytracing programmer. Prøv at sammenlign Imagine fra Amigaen, med f.eks. 3d Studio Max idag. Eller Interword på Amigaen med Open Office, eller en gammel soundtrakker player med et MP3 afspiller program.
Der er skam en virkelig god grund til at man har brug for mere CPU kraft idag, end for 15 år siden.
Jeg kan ikke give dig ret i at det kan svare sig at bruge 10 gange så meget tid på udvikling for at spare lidt i resource på maskinerne. Prøv at tænk dig hvad et spil firma skal havde for et spil hvis det tager 10 gange så længe at udvikle, og tænk på hvor meget længere tid det ville tage at få nye produkter på markedet, og til hvilken merpris.
p.s. Jeg er selv gammel assembler koder fra C64 og senere i flere år på Amigaen (jeg talte flydende Mc680x0 dengang), men i dag har jeg ganske enkelt ikke tid til det, og intel's assembler syntax er så irriterende i forhold til Mc680x0 syntaxen.
.Net er IKKE et programmeringssprog med et framework.
Du kan sagtens lave .net programmering i C#, VB, Python, C++ osv.
Problemmet med assembler er at det er absolut de aller færreste udviklere der har evnerne til at kode assembler på et niveau der kan hamle op med de compilere vi anvender i dag.
Problemmet med assembler er så også et det kun kan bruges på den ene CPU man har lært det til, f.eks. C/C++ kan bruges på utroligt mange forskellige CPU arkitekturer.
Det du kunne tænke dig i udviklingen er skam sket, tro mig hvis du to de compilere vi brugte for 15 år siden, og prøvede at compile programmer idag, ville du opdage de var meget langsommere, end hvis de blev compilet med nutidens compilere.
Men de programmer vi bruger i dag er bare meget mere komplexe end de var dengang.
For mange år siden spillede jeg Great Giana Sisters på min Amiga 500, og det kørte fint. I dag spiller jeg Oblivion på min P4 3.4 GHz med 1 GB ram, og det trækker SÅ MEGET tænder ud af min maskinen. Men spillet er så ufatteligt meget mere komplex og natur tro end Great Giana Sisters.
Se evt. også på Fly simulatorer, se på raytracing programmer. Prøv at sammenlign Imagine fra Amigaen, med f.eks. 3d Studio Max idag. Eller Interword på Amigaen med Open Office, eller en gammel soundtrakker player med et MP3 afspiller program.
Der er skam en virkelig god grund til at man har brug for mere CPU kraft idag, end for 15 år siden.
Jeg kan ikke give dig ret i at det kan svare sig at bruge 10 gange så meget tid på udvikling for at spare lidt i resource på maskinerne. Prøv at tænk dig hvad et spil firma skal havde for et spil hvis det tager 10 gange så længe at udvikle, og tænk på hvor meget længere tid det ville tage at få nye produkter på markedet, og til hvilken merpris.
p.s. Jeg er selv gammel assembler koder fra C64 og senere i flere år på Amigaen (jeg talte flydende Mc680x0 dengang), men i dag har jeg ganske enkelt ikke tid til det, og intel's assembler syntax er så irriterende i forhold til Mc680x0 syntaxen.
Jeg glæder mig virkeligt til .net 3.0 det bliver fedt når man direkte i sin kode kan bruge SQL lignende syntax til at søge i collections, brug af lambda syntax osv. Der sker virkeligt ting.
Håber bare det også kommer til vb.net som jeg er tvunget til at bruge på arbejdet.
p.s. #2 det er nok MEGET urealistisk at det sker.
Håber bare det også kommer til vb.net som jeg er tvunget til at bruge på arbejdet.
p.s. #2 det er nok MEGET urealistisk at det sker.
#5
Helt enig, det er bare for sejt.
Et lille eksempel til dem der ikke kende Linq:
public void Linq1()
{
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
var lowNums =
from n in numbers
where n < 5
select n;
Console.WriteLine("Numbers < 5:");
foreach (var x in lowNums)
{
Console.WriteLine(x);
}
}
Result
Numbers < 5:
4
1
3
2
0
Det gør dælme livet nemmere for os udviklere.
Helt enig, det er bare for sejt.
Et lille eksempel til dem der ikke kende Linq:
public void Linq1()
{
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
var lowNums =
from n in numbers
where n < 5
select n;
Console.WriteLine("Numbers < 5:");
foreach (var x in lowNums)
{
Console.WriteLine(x);
}
}
Result
Numbers < 5:
4
1
3
2
0
Det gør dælme livet nemmere for os udviklere.
Som jeg også nævner i nyheden er det yderst tvilsomt at (X/D)LinQ kommer med i udgivelsen af mange grunde. Men som udgangspunkt fordi det ikke kan nå at komme med i Vista udgivelsen her til efteråret. Derudover er der stadig mange åbne punkter omkring lambda syntaxen infered variabler. Men der er ingen tvivl om at LinQ (når det kommer) vil ændre utrolig meget. Man skal huske på at DLinQ (Altså evne til at kunne query sit datalag direkte i koden) blot er en "extension" til LinQ. Det kan laves til at understøtte alle former for objekter og fx (DlinQ) i XML filer. Extension methods er bestemt heller ikke uinteressant (At kunne "klistre" funktionalitet på et udvalgt hieraki af klasser uden fx at bruge "sin ene nedarvnings mulighed")
Ang. diskussionen omkring hastighed og assembler. Nu er det bare extra tid det vil tage i asm (x10..hvad med 1000x?). Problemet er også at det vil være tæt på umuligt. Det vil svare lidt til at skulle bygge et højhus af sandkorn. I teorien muligt, men i praksis....
[Edit] Nu så jeg #6 har lavet et query ex. Her er et på extension methods
class Program
{
static void Main(string[] args)
{
string str = "Hej med dig";
Console.WriteLine(str.DeleteSomeChars(2));
}
};
public static class MyCustomHelpers
{
public static string DeleteSomeChars(this string text, int numbersToDelete)
{
return text.Remove(text.Length - 1 - numbersToDelete, numbersToDelete);
}
}
Vi "extender" altså klassen string (angivet på første parameter) som vi så samtdig modtager instansen af til videre behandling samt en parameter (numbersToDelete)
Ang. diskussionen omkring hastighed og assembler. Nu er det bare extra tid det vil tage i asm (x10..hvad med 1000x?). Problemet er også at det vil være tæt på umuligt. Det vil svare lidt til at skulle bygge et højhus af sandkorn. I teorien muligt, men i praksis....
[Edit] Nu så jeg #6 har lavet et query ex. Her er et på extension methods
class Program
{
static void Main(string[] args)
{
string str = "Hej med dig";
Console.WriteLine(str.DeleteSomeChars(2));
}
};
public static class MyCustomHelpers
{
public static string DeleteSomeChars(this string text, int numbersToDelete)
{
return text.Remove(text.Length - 1 - numbersToDelete, numbersToDelete);
}
}
Vi "extender" altså klassen string (angivet på første parameter) som vi så samtdig modtager instansen af til videre behandling samt en parameter (numbersToDelete)
#disky.
siger heller ikke på noget tidspunkt at det ville kunne svare sig at bruge 10 gange så lang tid at lave det i assembler.
siger at HVIS man valgte at GØRE det, så ville spil der måske kræver 3GHZ og 1 Gig ram, måske kunnenøjes med at kræve 2GHZ, og 512 mb ram..
måske lidt overdrevet, men stadig tror jeg ikke at det lyder helt urealistisk.
man kan måske sammenligne det lidt med Playstation eller Xbox.
det er forholdsvis langsomme computere.. (xbox = 733 Mhz fandt jeg lige ud af :) ) men de kan stadigvæk godt trække spil, som ser utrolig godt ud..!
og er meget komplexe (nu spiller jeg ikke meget computerspil, så kan ikke nævne nogle rigtig gode eksempler :) )
men du må give mig ret i at grunden til at man kan lave spillet så godt til en konsol, det kan kun være pga at det er bedre kode, en det spiludviklerne bruger på Pc'en.
siger heller ikke på noget tidspunkt at det ville kunne svare sig at bruge 10 gange så lang tid at lave det i assembler.
siger at HVIS man valgte at GØRE det, så ville spil der måske kræver 3GHZ og 1 Gig ram, måske kunnenøjes med at kræve 2GHZ, og 512 mb ram..
måske lidt overdrevet, men stadig tror jeg ikke at det lyder helt urealistisk.
man kan måske sammenligne det lidt med Playstation eller Xbox.
det er forholdsvis langsomme computere.. (xbox = 733 Mhz fandt jeg lige ud af :) ) men de kan stadigvæk godt trække spil, som ser utrolig godt ud..!
og er meget komplexe (nu spiller jeg ikke meget computerspil, så kan ikke nævne nogle rigtig gode eksempler :) )
men du må give mig ret i at grunden til at man kan lave spillet så godt til en konsol, det kan kun være pga at det er bedre kode, en det spiludviklerne bruger på Pc'en.
#9
Nej den holder desværre ikke. Base koden til PC og XBOX/PS2 spil er stort set den samme i mange tilfælde. Det er naturligvis controller portering, Bitmap down/up sizing men grundlæggende er de ens. Grunden til en Xbox kan klare sig med 733 mHz er bl.a et stærkt grafikkort, opløsning, samt at de 733 Mhz ikke er sammenlignelige med fx en PIII 733 mhz.
men du må give mig ret i at grunden til at man kan lave spillet så godt til en konsol, det kan kun være pga at det er bedre kode, en det spiludviklerne bruger på Pc'en.
Nej den holder desværre ikke. Base koden til PC og XBOX/PS2 spil er stort set den samme i mange tilfælde. Det er naturligvis controller portering, Bitmap down/up sizing men grundlæggende er de ens. Grunden til en Xbox kan klare sig med 733 mHz er bl.a et stærkt grafikkort, opløsning, samt at de 733 Mhz ikke er sammenlignelige med fx en PIII 733 mhz.
Glæder mig til .NET 3.0, hvor man bl.a. kan teste sin kode i workflow diagrammer, hvilket giver et fantastisk overblik.
XAML er også ganske interessant - XML kode der beskriver design, og som kan smides frem og tilbage mellem designer og programmør, og bedst af alt, designet bliver 100% som designeren havde tænkt sig.
XAML er også ganske interessant - XML kode der beskriver design, og som kan smides frem og tilbage mellem designer og programmør, og bedst af alt, designet bliver 100% som designeren havde tænkt sig.
Arhh flere ting i .NET fremworket?.
Vil det så også sige, at disse ting standardiseres under ECMA?
Eller var blot noget man gjorde med de første teknologier, for lige at tysse på de værste kritikere?.
Det er jeg virkeligt spændt på. For hvis de begynder at spæde op, med ting de ikke standardisere åbent, bliver .NET langt mere skadeligt end Java er blevet beskyldt for. Men vil lige se hvad der sker.
Mono og .DOTGNU folkene vil dog presse på for at få ALT implementeret, om Microsoft vil det eller ej. ECMA standardiseringen af de nye ting, kan jo så indikere om de første ting standardiseringer blot var spil for galleriet... ;)
Vil det så også sige, at disse ting standardiseres under ECMA?
Eller var blot noget man gjorde med de første teknologier, for lige at tysse på de værste kritikere?.
Det er jeg virkeligt spændt på. For hvis de begynder at spæde op, med ting de ikke standardisere åbent, bliver .NET langt mere skadeligt end Java er blevet beskyldt for. Men vil lige se hvad der sker.
Mono og .DOTGNU folkene vil dog presse på for at få ALT implementeret, om Microsoft vil det eller ej. ECMA standardiseringen af de nye ting, kan jo så indikere om de første ting standardiseringer blot var spil for galleriet... ;)
#13 - ECMA standarden er blevet og bliver løbende opdateret og det kunne du også godt have fundet ud af. Jeg tror endda at det ville have taget dig mindre tid at slå dette op end at støve world domination teorien af.
#6 - Sammenlignet med
@number = ( 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 );
print join("\n", grep { $_ < 5 } @number);
? ;o)
J/k. Jeg har bare ikke rigtig set lyset mht linq. Det minder mig om noget jeg ikke ka li (sqlprep). Egentlig krummede jeg allerede tæer da jeg hørte om nogle af detaljerne for generics. Oh well...
#0 - Det er da godt at være fri for WinFX navnet. Ikke forvirrende.
#6 - Sammenlignet med
@number = ( 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 );
print join("\n", grep { $_ < 5 } @number);
? ;o)
J/k. Jeg har bare ikke rigtig set lyset mht linq. Det minder mig om noget jeg ikke ka li (sqlprep). Egentlig krummede jeg allerede tæer da jeg hørte om nogle af detaljerne for generics. Oh well...
#0 - Det er da godt at være fri for WinFX navnet. Ikke forvirrende.
#13 sKIDROw
Mig bekendt er det kun CLI og C#, der er ECMA-standarder. Mange af de andre teknologier, der er i .NET-frameworket såsom ASP.NET og ADO.NET er ikke en del af disse ECMA-standarder. Der kan potentielt opstå problemer med patenter på disse teknologier. Du kan selv se hvad Mono har at sige om det her.
Mig bekendt er det kun CLI og C#, der er ECMA-standarder. Mange af de andre teknologier, der er i .NET-frameworket såsom ASP.NET og ADO.NET er ikke en del af disse ECMA-standarder. Der kan potentielt opstå problemer med patenter på disse teknologier. Du kan selv se hvad Mono har at sige om det her.
#16
Ja så bekræfter du jo en del, af det jeg var inde på.
Altså at der selektiv vælges, hvad der skal standardiseres offentligt, og hvad der bliver beholdt lukket.
Virker som lidt spil for galleriet så.. :)
Men godt at Mono har forstået vigtigheden af, at alle elementer af .NET skal implementeres overhovedet.
Ja så bekræfter du jo en del, af det jeg var inde på.
Altså at der selektiv vælges, hvad der skal standardiseres offentligt, og hvad der bliver beholdt lukket.
Virker som lidt spil for galleriet så.. :)
Men godt at Mono har forstået vigtigheden af, at alle elementer af .NET skal implementeres overhovedet.
#9 Mcnovy
Nu er det jo stadigvæk således at det vil tage alt for lang tid, til at det kunne betale sig.
Det kunne godt være at man ville kunne spille spil på lidt forældet hardware istedt for noget nyere. Men så hellere opgradere sin computer en gang til anden, end at købe spil til 6-700 kr stykket. Tror iøvrigt også det første ville være billigere.. ;P
Mht konsoller vs. computere. Først og fremmest kan man ikke måle ydelse på en processor på dens clockfrekvens. Det har vi både set med AMD's processorer, og Intels Celeron processor. Amd's kørte hurtigt med lav clockfrekvens, og Celeron processoren kørte at lort, selv med 2,8 ghz.
Og så er den helt store forskel jo også, at når man skriver til en konsol, så skriver man til noget specifikt hardware.
På pc'en skal man tage højde for alverdens ting. Du kan også se på nogle spil, ydes der bedre på nogle kort, end andre, selvom de måske er lige gode i benchmarkprogrammer.
Mange gange er det pga. firmaet bag kortet har en større pengepung end det konkurrende firma. Så laver man understøttelsen lige lidt bedre.
Hvis man kun har en slags hardware man skal skrive kode til, kan man som standard få mere mere ud af maskinen, end hvis man skal skrive til 100 forskellige setups.
Nu er det jo stadigvæk således at det vil tage alt for lang tid, til at det kunne betale sig.
Det kunne godt være at man ville kunne spille spil på lidt forældet hardware istedt for noget nyere. Men så hellere opgradere sin computer en gang til anden, end at købe spil til 6-700 kr stykket. Tror iøvrigt også det første ville være billigere.. ;P
Mht konsoller vs. computere. Først og fremmest kan man ikke måle ydelse på en processor på dens clockfrekvens. Det har vi både set med AMD's processorer, og Intels Celeron processor. Amd's kørte hurtigt med lav clockfrekvens, og Celeron processoren kørte at lort, selv med 2,8 ghz.
Og så er den helt store forskel jo også, at når man skriver til en konsol, så skriver man til noget specifikt hardware.
På pc'en skal man tage højde for alverdens ting. Du kan også se på nogle spil, ydes der bedre på nogle kort, end andre, selvom de måske er lige gode i benchmarkprogrammer.
Mange gange er det pga. firmaet bag kortet har en større pengepung end det konkurrende firma. Så laver man understøttelsen lige lidt bedre.
Hvis man kun har en slags hardware man skal skrive kode til, kan man som standard få mere mere ud af maskinen, end hvis man skal skrive til 100 forskellige setups.
#2 de understøtter faktisk freebsd, søg efter rotor
http://www.microsoft.com/downloads/details.aspx?Fa...
->
http://msdn.microsoft.com/msdnmag/issues/02/07/Sha...
:)
http://www.microsoft.com/downloads/details.aspx?Fa...
->
http://msdn.microsoft.com/msdnmag/issues/02/07/Sha...
:)
http://channel9.msdn.com/showpost.aspx?postid=2021...
kan btw anbefales, anders hejlsberg (danskeren der er chief arcitect for C# og dlinq ) snakker om dlinq mm.
kan btw anbefales, anders hejlsberg (danskeren der er chief arcitect for C# og dlinq ) snakker om dlinq mm.
Linq står for "Language INtegrated Query".
Microsoft har 2 dokumenter om hhv. DLinq og XLinq, hvis der er nogle der er interesserede i at læse om hvordan man bruger det og hvad det kan (ja i word-format):
DLinq
XLinq
De har også frigivet et preview af en C# 3.0 compiler så man kan lege med Linq, den kan findes på deres Linq-side: http://msdn.microsoft.com/netframework/future/linq...
Microsoft har 2 dokumenter om hhv. DLinq og XLinq, hvis der er nogle der er interesserede i at læse om hvordan man bruger det og hvad det kan (ja i word-format):
DLinq
XLinq
De har også frigivet et preview af en C# 3.0 compiler så man kan lege med Linq, den kan findes på deres Linq-side: http://msdn.microsoft.com/netframework/future/linq...
neat nok med .NET 3.
Håber snart de er ved at have udryddet alle deres html fejl i asp.net delen, da der er virkelig meget som bare er fucked up (hvem fandt på at bruge <font> i et xhtml dokument?).
Derudover mangler jeg også noget mere brugeraccess to at ændre kerne-komponenter i primært asp.net delen, fordi at jeg er træt af predefineret output (dette bør ikke forfindes, overhovedet).
Så mangler det bare at communitiet tager sig sammen og får alle de gamle skrammel guides fra .NET 1.0 fjernet. Og derudover stemmer jeg for en lov som gør VB(.NET) ulovligt for evigt i hele verden.
Håber snart de er ved at have udryddet alle deres html fejl i asp.net delen, da der er virkelig meget som bare er fucked up (hvem fandt på at bruge <font> i et xhtml dokument?).
Derudover mangler jeg også noget mere brugeraccess to at ændre kerne-komponenter i primært asp.net delen, fordi at jeg er træt af predefineret output (dette bør ikke forfindes, overhovedet).
Så mangler det bare at communitiet tager sig sammen og får alle de gamle skrammel guides fra .NET 1.0 fjernet. Og derudover stemmer jeg for en lov som gør VB(.NET) ulovligt for evigt i hele verden.
#23
Nu er der stor forskel på VB og VB.net, først nævnte må man for min skyld gerne afskaffe, sidstnævnte er der ingen grund til at afskaffe, det er et udemærket sprog at kode i, selvom jeg dog personligt foretrækker C#, men sig det til min arbejdsgiver.
Faktisk gør VS2005 det nemmere at kode i VB.net end C#.net da den gør mange ting nemmere at indtaste (ja jeg er doven og lader IDE'en stå for indrykning osv).
Nu er der stor forskel på VB og VB.net, først nævnte må man for min skyld gerne afskaffe, sidstnævnte er der ingen grund til at afskaffe, det er et udemærket sprog at kode i, selvom jeg dog personligt foretrækker C#, men sig det til min arbejdsgiver.
Faktisk gør VS2005 det nemmere at kode i VB.net end C#.net da den gør mange ting nemmere at indtaste (ja jeg er doven og lader IDE'en stå for indrykning osv).
#6
Hvad er styrken ved din roede metode, som ikke findes i?:
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
foreach (int n in numbers)
Console.Write(n < 5 ? n + "\n": "");
Jeg kan se det smarte i at lave sql queries direkte i koden, men at bruge det til at linq til at erstatte allerede eksisterende funktionalitet i C# eller andre sprog giver ingen mening. Og det KAN ikke være hurtigere at bruge endnu et abstraktionslag, end at lave en lille foreach løkke (lykke?) til at løse problemet. Jeg ved ikke om man forestiller sig at man vil joine arraylists etc. som man gør i sql, men jeg kan ikke lige se det anvendelige.
Sqlqueries med linq ja tak, men C# kode erstattet af linq vil jeg gerne være fri for... 100 kr. på at ovenstående er lettere at læse for de fleste kodeaber end et linq udtryk.
[edit]
ups, sorry... lagde ikke mærke til at der var en der havde fået samme ide som mig.
Hvad er styrken ved din roede metode, som ikke findes i?:
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
foreach (int n in numbers)
Console.Write(n < 5 ? n + "\n": "");
Jeg kan se det smarte i at lave sql queries direkte i koden, men at bruge det til at linq til at erstatte allerede eksisterende funktionalitet i C# eller andre sprog giver ingen mening. Og det KAN ikke være hurtigere at bruge endnu et abstraktionslag, end at lave en lille foreach løkke (lykke?) til at løse problemet. Jeg ved ikke om man forestiller sig at man vil joine arraylists etc. som man gør i sql, men jeg kan ikke lige se det anvendelige.
Sqlqueries med linq ja tak, men C# kode erstattet af linq vil jeg gerne være fri for... 100 kr. på at ovenstående er lettere at læse for de fleste kodeaber end et linq udtryk.
[edit]
ups, sorry... lagde ikke mærke til at der var en der havde fået samme ide som mig.
#26
Læs lige #22, #6 er bare et eksempel der viser folk der IKKE ved hvad LINQ er, hvad det er. Ikke en super deluxe løsning på det.
Men måske kender du til www.google.com prøv at søg efter 'linq example' der, så finder du nok ting og sager. :)
Men både du og #14 skulle tage en kigger på:
http://www.codeproject.com/dotnet/ALookAtLinq.asp
Som er en artikel om emnet, der også har mere avancerede queries som eksempler.
F.eks.:
var peopleWithoutLives = from poster in mostActive
group poster by (poster.numberOfPosts / 5000) into postGroup
orderby postGroup.Key descending
select postGroup;
Dejligt nemt og læseligt.
Læs lige #22, #6 er bare et eksempel der viser folk der IKKE ved hvad LINQ er, hvad det er. Ikke en super deluxe løsning på det.
Men måske kender du til www.google.com prøv at søg efter 'linq example' der, så finder du nok ting og sager. :)
Men både du og #14 skulle tage en kigger på:
http://www.codeproject.com/dotnet/ALookAtLinq.asp
Som er en artikel om emnet, der også har mere avancerede queries som eksempler.
F.eks.:
var peopleWithoutLives = from poster in mostActive
group poster by (poster.numberOfPosts / 5000) into postGroup
orderby postGroup.Key descending
select postGroup;
Dejligt nemt og læseligt.
#28 eller evt her
http://msdn.microsoft.com/vcsharp/future/linqsampl...
der er lidt eksempler på mange af områderne det rent faktisk dækker over :)
http://msdn.microsoft.com/vcsharp/future/linqsampl...
der er lidt eksempler på mange af områderne det rent faktisk dækker over :)
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.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund