mboost-dp1
Bjarne Stroustrup
#1 http://www.simontoth.cz/en/system/files/images/bja... happy now? :)
Manden er genial nok til at være ligeglad med sådan noget :)
Manden er genial nok til at være ligeglad med sådan noget :)
cyandk (3) skrev:XorpiZ (1) skrev:Off-topic:
Han er godt nok ucharmerende.. hvornår gik de bluser der af mode? Starten af 90'erne? :D
Who the fuck cares hvordan han ser ud? Han kan sit kram og alt respekt for det.
Haha ja, jeg er enig. Han er fandme dygtig. Men jeg måtte alligevel smile lidt, da jeg så ham :D
Jeg synes både denne og version2s artikel forsøge at lave BT nyhed her. (Især overskriften er overdreven sprogbrug IMO) Måske er ordet nedstemt bare mere negativt i mine øjne end andres, men ja concepts er ikke med i C++0x. Men concepts er ikke med fordi de ikke er langt nok med implementering og ikke på grund af folk i standard komiteen ikke kan lide ideen. Selv Bjarne er enig i beslutningen om ikke at inkludere concepts.
#9
C++ har fin support for templates (Kaldet generics i C#). Stroustrup's concepts giver ikke bedre support for templates/generics, men bedre type-checking ved compile time og bedre fejl beskeder.
Mener du at C++'s templates er ligesom implementeringen af generics i Java? Hvis der er to sprog der ligner hinanden, så er det godt nok C# og Java.
C# er, for en lille sidebemærkning, da den største blanding af programmerings-paradigmer nogle sinde set - med en masse syntaktisk sukker. Jeg kan ikke se hvor C# er bedre end C++ - De kan slet ikke sammenlignes på den måde.
C++ har fin support for templates (Kaldet generics i C#). Stroustrup's concepts giver ikke bedre support for templates/generics, men bedre type-checking ved compile time og bedre fejl beskeder.
Mener du at C++'s templates er ligesom implementeringen af generics i Java? Hvis der er to sprog der ligner hinanden, så er det godt nok C# og Java.
C# er, for en lille sidebemærkning, da den største blanding af programmerings-paradigmer nogle sinde set - med en masse syntaktisk sukker. Jeg kan ikke se hvor C# er bedre end C++ - De kan slet ikke sammenlignes på den måde.
Du ved vel udemærket er du skal definere en template for hver eneste type du agter at benytte!Anderslm (10) skrev:C++ har fin support for templates (Kaldet generics i C#)
Hvor at generics i Java og C#, samt andre sprog, tillader en vilkårlig type.
Man kan sammenligne værktøj der benyttes til samme formål!Anderslm (10) skrev:Jeg kan ikke se hvor C# er bedre end C++ - De kan slet ikke sammenlignes på den måde.
windcape (11) skrev:Du ved vel udemærket er du skal definere en template for hver eneste type du agter at benytte!
Ikke korrekt.
Man definerer sin template en gang for enhver type.
Du tænker nok på at compileren genererer ny kode hver gang man bruger templaten for en ny type.
#9, #10 etc.:
Ja C++ templates er langt mere kraftfulde end C#'s generics, det kan der ikke være tvivl om. Men generics er tilstrækkelige til 95% af det man har brug for, efter min erfaring, og man har til gengæld:
a) langt mindre kompleksitet og noget federe syntaks,
b) langt bedre fejlbeskeder,
c) mulighed for instantiering JIT-time (ville svare til link-time med C++).
Java's generics er bare sukker for en type-cast. Nothing to see here. C#'s (og C++ templates) genererer rent faktisk optimeret kode til den enkelte situation.
Ja C++ templates er langt mere kraftfulde end C#'s generics, det kan der ikke være tvivl om. Men generics er tilstrækkelige til 95% af det man har brug for, efter min erfaring, og man har til gengæld:
a) langt mindre kompleksitet og noget federe syntaks,
b) langt bedre fejlbeskeder,
c) mulighed for instantiering JIT-time (ville svare til link-time med C++).
Java's generics er bare sukker for en type-cast. Nothing to see here. C#'s (og C++ templates) genererer rent faktisk optimeret kode til den enkelte situation.
#13, ja det er jeg til dels enig i. Som daglig bruger af C# er jeg dog ret glad for de forskellige paradigmer. De som brokker sig over det er vist mest folk som ikke bruger sproget; man kan jo bare holde sig fra de dele man ikke kan li', hvis det er det.
Altså hvis man ikke kan li' at se på numbers.Where(n => n < 100) kan man da bare lave en ny liste, løbe den første igennem og tilføje alle dem under 100 til den anden ;-).... 3-4 gange så meget kode, en anelse hurtigere og lidt sværere at læse. Så hvorfor? :-p
Altså hvis man ikke kan li' at se på numbers.Where(n => n < 100) kan man da bare lave en ny liste, løbe den første igennem og tilføje alle dem under 100 til den anden ;-).... 3-4 gange så meget kode, en anelse hurtigere og lidt sværere at læse. Så hvorfor? :-p
#15
på arbejdet har vi en livlig diskussion om Extension Methods er ok eller ej....
jeg elsker at bruge dem - de andre basher mig for det...
C# er fantastisk :D
på arbejdet har vi en livlig diskussion om Extension Methods er ok eller ej....
jeg elsker at bruge dem - de andre basher mig for det...
C# er fantastisk :D
Anderslm (10) skrev:#9
C++ har fin support for templates (Kaldet generics i C#). Stroustrup's concepts giver ikke bedre support for templates/generics, men bedre type-checking ved compile time og bedre fejl beskeder.
Concept-based overloading giver dig faktisk bedre support for generic programming i C++. Pt. skal man bruge type traits samt tag dispatching for at lave det samme; den concept baserede version vil i langt de fleste tilfælde være kortere og mere læsevenlig.
C++0x inkluderer static assertions, biblioteks udviklerne vil være
i stand til at lave de samme "concept" checks vh.a. type-traits og SFINAE (bliver benyttet af BOOST concept check), men i så fald bliver koden endnu mere ulæselig.
Man har iøvrigt valgt at inkludere flere type traits i standard biblioteket, men mange af dem er ikke helt klare. F.eks. er det ikke specifiseret hvornår std::tr1::is_pod<V>::value evaluere til true.
Smid dem en bog i hovedet omkring funktional programmering, og hvorfor det giver mere stabil kode?Montago (16) skrev:på arbejdet har vi en livlig diskussion om Extension Methods er ok eller ej....
jeg elsker at bruge dem - de andre basher mig for det...
var numbers = listOfXs.Where(x => x > 100)
Retunere jo en 'pratisk immutable' enumeration, hvor imod den lign. kode:
var numbers = new List<T>();
foreach(var x in listOfXs)
{
if(x > 100) { numbers.Add(x); }
}
jo kan have en række fejl, andre threads som måske ændre på numbers listen og hvad ved jeg.
arne_v (13) skrev:C++ understøtter vel flere paradigmer end C# ?
Så absolut!
C# vil gerne være med som et multi-paradigme sprog, men er det jo reelt set ikke - ser man med krakilske briller.
#18
At kalde Extension methods for funktionel programmering ?? Ahh er det ikke bare "omvendt" syntaktisk sukker for et statisk metode-kald ? Jo..
#14
STL vs Generics ? No brainer ;)
Noget jeg synes der er langt mere interessant fra Bjarne er hvorledes han ser kritisk på arkitektur.
Noget helt andet er at han angriber "hypede" sprog. Nu ved jeg ikke lige præcis hvilke sprog han umiddelbart angriber, men jeg vil give manden ret i - at der er noget forkert i at vi konstant skal tilføje nye elementer.
Noget der er rart ved C++ er at der ikke konstant rodes i sproget og der tilføjes nye elementer.
Jeg er ret kritisk overfor C# selvom jeg dagligt programmerer i det. Læs f.eks. denne korte liste: var, dynamics, linq, extension methods, default properties og meget mere. Der proppes konstant ned i sækken af nye "features" - og når 2010(VS) nu engang kommer frem - skal der nok blive "hyped" på bl.a. dynamics. Puha en grim tanke.
Til tider ville jeg ønske at vi vendte næsen retur mod C++. Det kan godt være at C++ er mere kompleks, men det tilbyder også så meget mere på de samme fundamentale principper.
Men funktionel programmering er jo netop at du indfanger logik i funktioner, istedet for inline kode!mrF0x (19) skrev:At kalde Extension methods for funktionel programmering ?? Ahh er det ikke bare "omvendt" syntaktisk sukker for et statisk metode-kald ? Jo..
Extension Methods er det pragmatiske svar på at indbygge funktionel programmering i et imperativt sprog. Samt at du kan benytte lambda expressions som parameter, noget du ikke kan i C++.
De fleste af disse "nye features" er bare biblioteks udvidelser.mrF0x (19) skrev:Læs f.eks. denne korte liste: var, dynamics, linq, extension methods, default properties og meget mere. Der proppes konstant ned i sækken af nye "features" - og når 2010(VS) nu engang kommer frem - skal der nok blive "hyped" på bl.a. dynamics. Puha en grim tanke.
Og dynamics er smart i forhold til at implementere f.eks. Python i .NET. Husk at mange spil allerede benytter noget lign. som f.eks. LUA sammen med C++ !
Fundamentale principper er ligegyldige, og betyder bare du skal skrive mere besværlig kode, uden enligt at opnå noget som helst.mrF0x (19) skrev:Til tider ville jeg ønske at vi vendte næsen retur mod C++. Det kan godt være at C++ er mere kompleks, men det tilbyder også så meget mere på de samme fundamentale principper.
Vi skal arbejde hen imod mindre imperativ programmering, og C# gør klart et bedre job en noget andet imperativt sprog so far!
Ja, hvis der var ordenlige generics ville folk måske benytte noget ala. List<T> istedet for Vectors med konstante typecasts!mrF0x (19) skrev:STL vs Generics ? No brainer ;)
windcape (20) skrev:Men funktionel programmering er jo netop at du indfanger logik i funktioner, istedet for inline kode!
Extension Methods er det pragmatiske svar på at indbygge funktionel programmering i et imperativt sprog. Samt at du kan benytte lambda expressions som parameter, noget du ikke kan i C++.
Og det er langt hen ad vejen det, der er problemet. Ikke akkurat fordi man kan bruge lambda expressions som parameter, men sammen med alle de andre ting (var, dynamics, linq osv.) kan du virkelig skrive kode, som er så forskelligartet at det bliver svært at vedligeholde. Bare prøv at tænk på, hvor mange måder du kan itterere over en collection på (Løkker, LINQ, Extension Methods).
windcape (20) skrev:
Fundamentale principper er ligegyldige, og betyder bare du skal skrive mere besværlig kode, uden enligt at opnå noget som helst.
Fundamentale principper er så absolut ikke ligegyldige. C# er ret så ligeglad med principper og tvinger derfor en til at skrive noget så selvmodsigende som "static class" hvis man skal bruge noget, som ikke passer ind i en klasse.
windcape (20) skrev:
Vi skal arbejde hen imod mindre imperativ programmering, og C# gør klart et bedre job en noget andet imperativt sprog so far!
Jeg ved ikke om jeg syntes vi skal arbejde hen imod mindre imperativ programmering, men mulighederne i f.eks. LINQ er spændende.
Jeg vil dog give dig ret i, at C# er et ganske udemærket sprog (Og programmerer også i det til daglig), men jeg kan stadig ikke lide at sammenligne det alt for meget med C++. C# er et high-level sprog, med en virtual machine (Ligesom med Java) og det egner sig utrolig godt til at lave userland programmer i - Og nærmest intet andet. C++ er et low/middle-level sprog og kan give dig en utrolig performance og kontrol, og med et framework som QT egner det sig lige så fint som C# til at lave userland applikationer med.
Det vi skal arbejde hen imod er ensartet kode - Ligegyldigt hvilket sprog der bruges. C# opfordrer, efter min mening, programmører til at skrive kode, som netop ikke er ensartet. Det skaber uenighed og besværliggører vedligeholdese og samarbejde. Hvornår skal man foreksempel bruge "var" - Og er det god skik? Hvad med LINQ vs. Extension methods? Og bør man overhovedet bruge lambda expressions?
Det handler om at skrive kode som et letlæseligt, ensartet og gør arbejdet effektivt. Alt for lidt af det kode jeg har overtaget fra andre i C# er nogle af de ting, og det er da muligt det er fordi dem der har skrevet det, ikke er dygtige nok - Men har et stykke software været igennem flere udviklere, kan man nærmest følge hvordan koden bliver mere og mere forskelligartet, som C# har fået flere og flere features med tiden. Det er som om C# bare propper mere og mere ned i værktøjskassen og jeg tror det forvirrer mere end det gavner.
Vedligeholdelse skal afhænge af selv-dokumenterede kode, og code-conventions, end sprog-specifikationer!Anderslm (21) skrev:kan du virkelig skrive kode, som er så forskelligartet at det bliver svært at vedligeholde.
Derudover er ting som users.Select(user => user.Age >= 30); meget mere selv dokumenterede end 5 linjer med en ny liste oprettelse, og en løkke!
Kun for folk der nægter at flytte sig ud af deres imperative tankegang, og ikke opsøge mulighederne ved de nye paradigmer.Anderslm (21) skrev:Det er som om C# bare propper mere og mere ned i værktøjskassen og jeg tror det forvirrer mere end det gavner.
Det er nemt nok, bare tænk dig om.Anderslm (21) skrev:Hvornår skal man foreksempel bruge "var" - Og er det god skik?
var bør kun bruges når det er nærmest er duck typing, som f.eks. ved:
- Instansisering
var windcape = new User("Windcape");- foreach iteration, eller lign block code
foreach(var user in users) {} using(var stream = File.Open("hi.txt")) {}Det er super produktivt ikke at skulle definere lange typer TO gange, og giver en mere overskuelig og læsbar kode.
var something = new SuperLongClassNameWith<SuperLongKey, AndSuperLongType>();
versus
SuperLongClassNameWith<SuperLongKey, AndSuperLongType> something = new SuperLongClassNameWith<SuperLongKey, AndSuperLongType>();
Anders Hejlberg har givet massere af eksempler på diverse konferencer det sidste års tid. Du bør benytte et LINQ query når det giver mening, og giver den mest simple og læsebare kode.Anderslm (21) skrev:Hvad med LINQ vs. Extension methods? Og bør man overhovedet bruge lambda expressions?
Extension methods giver også fint mening til funktionalitet som LINQs, et statisk bibliotek er jo bare besværligt. Kan virkelig ikke se hvorfor at man vil vælge den mest rodede tilgang.
Statisk (Java):
Collections.Sort(users);
Extension (C#):
users.Sort();
Og mht. lambda, sammenlign her med predicates og statisk kode:
(Java)
Collections.Sort(users, new Comparator<User>() {
// Læg mærke til at vi skal definere en type *sigh*
public int compare(User user1, User user2)
{
return user1.getAge() > user2.getAge();
}
});Lambda (C#):
users.Sort(user => user.Age)
Hvorfor at du nogen sinde ville have den lange kode forstår jeg så ikke.
Derudover giver extension methods jo netop mere ensartet kode, end at skrive predicates manuelt hver eneste gang, eller værrere, slet ikke benytte predicates/comperators!
Desværre hører C++ jo netop med til linjen af sprog som hellere ser at udviklerne bruger lang tid på at kode, og ikke kan skrive selv-forklarende kode, end at udvikle sproget.
Hvilket så giver det udslag, at udviklerne så bare benytter pointer magic o.lign. i sådan en grad at det er HELT UMULIGT at vedligeholde!
Derudover giver extension methods jo netop mere ensartet kode, end at skrive predicates manuelt hver eneste gang, eller værrere, slet ikke benytte predicates/comperators!
Desværre hører C++ jo netop med til linjen af sprog som hellere ser at udviklerne bruger lang tid på at kode, og ikke kan skrive selv-forklarende kode, end at udvikle sproget.
Hvilket så giver det udslag, at udviklerne så bare benytter pointer magic o.lign. i sådan en grad at det er HELT UMULIGT at vedligeholde!
Lambda er ikke særlig elegant hvis man skal implementere det på biblioteks niveau.Whoever (27) skrev:lamba expressions i Boost
Det bliver ligeså rodet kode som predicates i Java. Folk vælger simpelthen IKKE at bruge det fordi det er for rodet, og kræver et bibliotek i første omgang.
RAJensen (29) skrev:Lidt sejt at vide at det er Dansker der opfandt C++
Danskere er ret godt med på sprog fronten.
C++ : Bjarne S
Delphi og C# : Anders H
PHP : Rasmus L
RoR : David H H
(OK - RoR er så teknisk set ikke et sprog)
Finnerne er så til gengæld foran os på OS fronten.
windcape (9) skrev:Det er dog ret skuffende at det ikke kommer med. Rigtig support af generics,
C++ har haft en langt mere fleksibel form for generics i form af templates i ca. 20 år.
windcape (18) skrev:Smid dem en bog i hovedet omkring funktional programmering, og hvorfor det giver mere stabil kode?
Extension metoder har intet med funktionel programmering at gøre, så medmindre det er en meget tyk bog og hensigten er at slå dem ud, så hjælper det ikke.
Extension metoder har en lille smule til fælles med AOP.
windcape (18) skrev:var numbers = listOfXs.Where(x => x > 100)
Retunere jo en 'pratisk immutable' enumeration, hvor imod den lign. kode:
var numbers = new List<T>();
foreach(var x in listOfXs)
{
if(x > 100) { numbers.Add(x); }
}
jo kan have en række fejl, andre threads som måske ændre på numbers listen og hvad ved jeg.
numbers listen er en lokal variabel, så den er der ikke andre tråde som retter i.
Eksemplet kræver iøvrigt slet ikke extension metoder, da List<> har en FindAll metode, som gør noget tilsvarende.
windcape (20) skrev:Men funktionel programmering er jo netop at du indfanger logik i funktioner, istedet for inline kode!
Extension Methods er det pragmatiske svar på at indbygge funktionel programmering i et imperativt sprog.
Extensions metoder er præcis lige så imperative som alle andr metoder.
windcape (20) skrev:Vi skal arbejde hen imod mindre imperativ programmering, og C# gør klart et bedre job en noget andet imperativt sprog so far!
Der er mange som antager at fremtiden ligger i funktionelel sprog og ikke i imperative sprog.
Men indtil videre er det kun en interesant hypotese.
Og det er langtfra givet at det er bedre at tilføje funktionelle egenskaber til et ikke funktionelt sprog end at skifte sprog i forbindelse med et paradigme skifte.
Generelt har "do everything" sprogene ikke haft så stor success som de mere simple sprog.
windcape (20) skrev:Ja, hvis der var ordenlige generics ville folk måske benytte noget ala. List<T> istedet for Vectors med konstante typecasts!
Øh.
Hvornår caster du i.f.m. brug af STL vector ??
windcape (23) skrev:
Extension methods giver også fint mening til funktionalitet som LINQs, et statisk bibliotek er jo bare besværligt. Kan virkelig ikke se hvorfor at man vil vælge den mest rodede tilgang.
Statisk (Java):Collections.Sort(users);
Extension (C#):users.Sort();
List<> Sort er ikke en extension men et helt normalt member.
windcape (23) skrev:
Og mht. lambda, sammenlign her med predicates og statisk kode:
(Java)Collections.Sort(users, new Comparator<User>() {
// Læg mærke til at vi skal definere en type *sigh*
public int compare(User user1, User user2)
{
return user1.getAge() > user2.getAge();
}
});
Lambda (C#):users.Sort(user => user.Age)
Ingen tvivl om at funktioner som første klasses objekter er en god ting (lyder gyseligt på dansk).
Men det er altså lykkes dig at lave fejl i både Java og C# koden !
return user1.getAge() > user2.getAge();
->
return user1.getAge() - user2.getAge();
og:
users.Sort(user => user.Age);
->
users.Sort((u1,u2) => u1.Age - u2.Age);
windcape (32) skrev:
Vi diskuterede lambda og extension-methods. Hvad er der galt i nogle eksempler til at illustrere pointen?
Du kunne jo overveje at nærlæse det, måske ville du lære noget ;)
Forudsætter jo så at koden rent faktisk virker og relaterer sig til det som den påståes at relatere sig til.
Windscape der noget du totalt har misforstået hvis du mener at STL bruger tonsvis af typecasts ?
Der findes ikke funktioner i C#... period!
C# er stadigvæk på samme niveau som Java et rent objekt oritenteret sprog - og det eneste paradigme det reelt set overholder.
Jeg giver også C# at det er et godt sprog, men det bygger ikke på egne principper, men låner fra alle lejre. Det kan man så rynke på næsen af -hvilket jeg nok lidt gør må jeg erkende.
Noget der ikke kommer som overraskelse er at i den næste spec bliver det tilladt at skrive default værdier på metode erklæringer...
void Foo(bool show=true);
C++ syntaks.. Det bliver vist noget grimt pascal lignende med := i C#
Hov den manglede og mange har savnet den... LÆNGE! Så - gammel vin på nye flasker ikke sandt.
Så ja C# er god nok til Userland applikationer, men - men, det er stadigvæk C++ der tilbyder os den bedste performance og samtidig kan porteres mellem platforme.
Samtidig glemmer vi helt i diskussionen at hvor C++ er et sprog som varetages af en komité og en matematiker - så er C# et sprog som varetages (for det meste, altså ikke standarder) af et en virksomhed som lever af at sælge sin proprietære platform.
Der findes ikke funktioner i C#... period!
C# er stadigvæk på samme niveau som Java et rent objekt oritenteret sprog - og det eneste paradigme det reelt set overholder.
Jeg giver også C# at det er et godt sprog, men det bygger ikke på egne principper, men låner fra alle lejre. Det kan man så rynke på næsen af -hvilket jeg nok lidt gør må jeg erkende.
Noget der ikke kommer som overraskelse er at i den næste spec bliver det tilladt at skrive default værdier på metode erklæringer...
void Foo(bool show=true);
C++ syntaks.. Det bliver vist noget grimt pascal lignende med := i C#
Hov den manglede og mange har savnet den... LÆNGE! Så - gammel vin på nye flasker ikke sandt.
Så ja C# er god nok til Userland applikationer, men - men, det er stadigvæk C++ der tilbyder os den bedste performance og samtidig kan porteres mellem platforme.
Samtidig glemmer vi helt i diskussionen at hvor C++ er et sprog som varetages af en komité og en matematiker - så er C# et sprog som varetages (for det meste, altså ikke standarder) af et en virksomhed som lever af at sælge sin proprietære platform.
Jo, men der er ingen som har påstået andet.mrF0x (38) skrev:Så - gammel vin på nye flasker ikke sandt.
Language-purity er nok det største fejl man kan lave. Sprog er værktøjer, og bør optimeres derefter.
C# er hurtigere end C++ på visse punkter, så hold nu op med at snakke om performance.mrF0x (38) skrev:men, det er stadigvæk C++ der tilbyder os den bedste performance og samtidig kan porteres mellem platforme.
Og portability på source-niveau virker så ligegyldigt. Specielt når det typisk er baseret på preprocessor statements, og ikke abstraktion! Det er så dybt fustrende at læse #IF WIN , eller #IF LINUX over det hele i kode.
Samtidig låser du dig alt for nemt til en enkelt platform i C++, da der langtfra benyttes abstraktion nok på biblioteks niveau.
Nej C# er ikke hurtigere end C++.
Alt sker via JIT'en for det første.
For det andet virker C# hurtigere i det den kan håndtere mange små objekter af gangen grundet GC.
Når det så er sagt - så vil en dygtig C++ programmør til enhver tid kunne udvikle en memory management model som til enhver tid vil smadre C# i performance tests..
Skal du knuse tal er C++ også hurtigere. Dog skal du op i matematisk tunge applikationer før du ser et reelt spring i performance.
Microsoft anbefaler heller ikke at C# anvendes til tidskritiske applikationer.
En helt anden diskussion er at JIT er undskyld PISSE irriterende set fra kundens synspunkt.
Kunden opfatter ganske enkelt éns nye .NET software for langsom og klodset.
Så back to sqrt() med NGEN :-(
Alt sker via JIT'en for det første.
For det andet virker C# hurtigere i det den kan håndtere mange små objekter af gangen grundet GC.
Når det så er sagt - så vil en dygtig C++ programmør til enhver tid kunne udvikle en memory management model som til enhver tid vil smadre C# i performance tests..
Skal du knuse tal er C++ også hurtigere. Dog skal du op i matematisk tunge applikationer før du ser et reelt spring i performance.
Microsoft anbefaler heller ikke at C# anvendes til tidskritiske applikationer.
En helt anden diskussion er at JIT er undskyld PISSE irriterende set fra kundens synspunkt.
Kunden opfatter ganske enkelt éns nye .NET software for langsom og klodset.
Så back to sqrt() med NGEN :-(
Jo C# kan være hurtigere end C/C++, jeg mente det ikke for sjov. Og mange gange er de næsten lige hurtige! (Forskelle så små at det ikke er relevant)mrF0x (40) skrev:Nej C# er ikke hurtigere end C++.
Og nej, det er ikke om handlende garbage-collection!
Tag et kig ind på http://shootout.alioth.debian.org/
Jeg har ikke oplevet userland software i C# der var langsommere end C++mrF0x (40) skrev:Kunden opfatter ganske enkelt éns nye .NET software for langsom og klodset.
Hvis du havde sagt Java... så ja, Java er skrækkeligt.
#41: Den side du linker til, taler i mod dit argument. Grafen er logaritmisk, med centrum ved 1. C# kommer i alle tider over dette og op i 1 - 10 (som dog er meget fint). C++ ligger ofte under en og kun senere op i lidt over 1, hvor C# i samme område ligger i 3 - 10 området.
Den eneste situation hvor du vil have auto-genereret kode til at være "bedre" end selvskrevent kode er følgende:
1) Hvis den autogenererede kode er helt vildt god (Usandsynligt, da sådanne algoritmer altid vil til passe en generel situation hellere end en specifik).
2) Hvis den selvskrevne kode er noget bras (mere sandsynligt).
Den eneste situation hvor du vil have auto-genereret kode til at være "bedre" end selvskrevent kode er følgende:
1) Hvis den autogenererede kode er helt vildt god (Usandsynligt, da sådanne algoritmer altid vil til passe en generel situation hellere end en specifik).
2) Hvis den selvskrevne kode er noget bras (mere sandsynligt).
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