mboost-dp1
unknown
har dog været til salg via forhandlere på edbpriser.dk et stykke tid nu siden uge 8
http://www.edbpriser.dk/software/software-top10.as...
http://www.edbpriser.dk/software/software-top10.as...
var også den dyreste jeg linkede til :)
synes priserne er ok, når man tænker på alle de nice ting man får.
synes priserne er ok, når man tænker på alle de nice ting man får.
hvad er der egentlig i kassen, hvis man køber visual c++ standard (til ca. 1000,-) ?
Er det kun en cd og en licens, eller er der også manual og lign. med ?
Er det kun en cd og en licens, eller er der også manual og lign. med ?
<STRONG>sKIDROw</STRONG>:syntax fremhævning i en tekst editor en weird ide? (ja kan den også, der er da INGEN der tvinger dig til at lave det visualt)
=>skidrow
Hvad mener du så med "visuel programmering, mærkelig idé!". Ville du hellere sidde og programmere dine user-interfaces fra scratch?? Eller du mener måske <STRONG>ikke</STRONG> at grafiske user-interfaces er kommet for at blive? ;)
Hvad mener du så med "visuel programmering, mærkelig idé!". Ville du hellere sidde og programmere dine user-interfaces fra scratch?? Eller du mener måske <STRONG>ikke</STRONG> at grafiske user-interfaces er kommet for at blive? ;)
=>skidrow
Jeg forstår det stadig ikke!
som jeg forstår det, mener du, at al kodning skal ske fra en tekst editor, dvs, at for at lave en knap (ingen funktionalitet, kun knappen) på en form, vil du foretrække at sidde og skrive denne kode fra bunden (hvilket indebærer positionering og dimensionering af knappen) i stedet for bare at trække en knap ud på en form. Der er jo en stor forskel på det der er "programmets udseende" og det der er programmets logik. for logikken bliver jo stadig kodet i en teksteditor.
Det er selvfølgelig muligt at sidde og kode sine win32 interfaces fra scratch ved at benytte win32 API'et, men den tid du bruger på at kode disse trivielle ting, ville du nok hellere bruge på at kode det der i virkeligheden er relevant, nemlig den logik der skal ligge bag dit program.
Hvis du ikke er enig i dette, så er det mit indtryk at du koder for lidt :)
Jeg forstår det stadig ikke!
som jeg forstår det, mener du, at al kodning skal ske fra en tekst editor, dvs, at for at lave en knap (ingen funktionalitet, kun knappen) på en form, vil du foretrække at sidde og skrive denne kode fra bunden (hvilket indebærer positionering og dimensionering af knappen) i stedet for bare at trække en knap ud på en form. Der er jo en stor forskel på det der er "programmets udseende" og det der er programmets logik. for logikken bliver jo stadig kodet i en teksteditor.
Det er selvfølgelig muligt at sidde og kode sine win32 interfaces fra scratch ved at benytte win32 API'et, men den tid du bruger på at kode disse trivielle ting, ville du nok hellere bruge på at kode det der i virkeligheden er relevant, nemlig den logik der skal ligge bag dit program.
Hvis du ikke er enig i dette, så er det mit indtryk at du koder for lidt :)
#12 bob:
En af ulemperne ved bare at trække en knap ind på plads, hive et par tekstfelter et sted hen og så videre er, at man ikke på en nem måde kan genbruge funktionaliteterne i f.eks. OOP og OOD, da programmerne selv har deres fine idéer om, hvordan man da lige kan bruge 47 linjer på at plastre hver enkelt knap ind på plads, i stedet for at lave en factory til den slags ting.
Det er til en vis grad fint nok at bruge træk-og-slip-gui-design (ja, det er et ordspil), men det holder ikke i længden, når tingene skal optimeres.
En af ulemperne ved bare at trække en knap ind på plads, hive et par tekstfelter et sted hen og så videre er, at man ikke på en nem måde kan genbruge funktionaliteterne i f.eks. OOP og OOD, da programmerne selv har deres fine idéer om, hvordan man da lige kan bruge 47 linjer på at plastre hver enkelt knap ind på plads, i stedet for at lave en factory til den slags ting.
Det er til en vis grad fint nok at bruge træk-og-slip-gui-design (ja, det er et ordspil), men det holder ikke i længden, når tingene skal optimeres.
#13 Hektor:
Heller ikke her er jeg enig :D
Jeg kan ikke se hvordan OOP eller kodegenbrug kan blive et problem. For hvis man gør som god OO foreskriver det, så opbygger man selvfølgelig sit program med et presentation layer, et business layer og et data access layer. Dvs. at man ikke sovser GUI-koden ind i logikkoden.
Jeg kan overhovedet ikke se hvordan det at bruge en factory til at konstruere GUI elementer, kan ændre på dette?
Heller ikke her er jeg enig :D
Jeg kan ikke se hvordan OOP eller kodegenbrug kan blive et problem. For hvis man gør som god OO foreskriver det, så opbygger man selvfølgelig sit program med et presentation layer, et business layer og et data access layer. Dvs. at man ikke sovser GUI-koden ind i logikkoden.
Jeg kan overhovedet ikke se hvordan det at bruge en factory til at konstruere GUI elementer, kan ændre på dette?
#14 bob:
Jeg har et program, hvor jeg skal bruge ca. 85 billedelementer. Hvis jeg lod min IDE bestemme, hvordan de skulle placeres i programmet, ville jeg få 85 x 14 linjer kode == 1.190 linjer kode - alene til det.
Jeg har derimod lavet en simpel factory-metode til at lave og placere billedelementerne, og den metode fylder 7 linjer. For hver af de 85 billedelementer kalder jeg den metode, hvilket giver 92 linjer kode. Det er et eksempel på, hvorfor man skal bruge sine patterns, når det kan betale sig.
Jeg har brugt IDE'en gui-dims til at lave en grov prototype, så jeg havde noget at gå ud fra, og derefter har jeg så lavet det fra bunden igen, og skåret 1.098 linjer kode væk fra min GUI. Ja, min gui er adskilt, det mønster kaldes Model-View-Control, og er et af de første man lærer - men det ændrer ikke på, at man sagtens kan bruge et factory-pattern internt i view for at simplificere koden.
Det kan også sagtens tænkes, at jeg husker forkert, og at det ikke er et factory-pattern, jeg bruger.
Jeg har et program, hvor jeg skal bruge ca. 85 billedelementer. Hvis jeg lod min IDE bestemme, hvordan de skulle placeres i programmet, ville jeg få 85 x 14 linjer kode == 1.190 linjer kode - alene til det.
Jeg har derimod lavet en simpel factory-metode til at lave og placere billedelementerne, og den metode fylder 7 linjer. For hver af de 85 billedelementer kalder jeg den metode, hvilket giver 92 linjer kode. Det er et eksempel på, hvorfor man skal bruge sine patterns, når det kan betale sig.
Jeg har brugt IDE'en gui-dims til at lave en grov prototype, så jeg havde noget at gå ud fra, og derefter har jeg så lavet det fra bunden igen, og skåret 1.098 linjer kode væk fra min GUI. Ja, min gui er adskilt, det mønster kaldes Model-View-Control, og er et af de første man lærer - men det ændrer ikke på, at man sagtens kan bruge et factory-pattern internt i view for at simplificere koden.
Det kan også sagtens tænkes, at jeg husker forkert, og at det ikke er et factory-pattern, jeg bruger.
#15 Hektor:
Men eksemplet du nævner, tror jeg at vi igen nærmer os hinanden.
I dit eksempel skal du have placeret 85 grafiske elementer på dit GUI. Der findes i de forskellige visuelle udviklingsmiljøer (f.eks. visual studio) en del User Interface kontroller, som netop gør det, at de indpakker Win32 API'et, for at lave opgaver som f.eks. at placere en knap på en form til en simpel opgave. De UI-kontroller der medfølger i disse pakker, er som regel kun nok til de mest grundlæggende opgaver, men man kan jo selv lave nye. Her mener jeg at vi så nærmer hinanden, da den factory du har lavet groft set vil svare til en UI kontrol. Man ville med sikkerhed kunne finde en 3. parts komponent, som kunne løse netop dit problem.
Jeg er også temmelig sikker på, at den factory du har lavet, bygger videre på nogle af de grafiske kontroller der var i det udviklingsmiljø du nu måtte bruge.
Og så er vi tilbage ved udgangspunktet, som var, at visuelle værktøjer ikke holder! Jeg vil blive ved med at fastholde, at det eneste de visuelle værktøjer gør, er at fjerne/simplificere de opgaver, som alligevel ikke er kernen i problemet/løsningen, hvorved man får mere tid og overskud til at fokusere på det der i virkeligheden er kernen i problemet!
Men eksemplet du nævner, tror jeg at vi igen nærmer os hinanden.
I dit eksempel skal du have placeret 85 grafiske elementer på dit GUI. Der findes i de forskellige visuelle udviklingsmiljøer (f.eks. visual studio) en del User Interface kontroller, som netop gør det, at de indpakker Win32 API'et, for at lave opgaver som f.eks. at placere en knap på en form til en simpel opgave. De UI-kontroller der medfølger i disse pakker, er som regel kun nok til de mest grundlæggende opgaver, men man kan jo selv lave nye. Her mener jeg at vi så nærmer hinanden, da den factory du har lavet groft set vil svare til en UI kontrol. Man ville med sikkerhed kunne finde en 3. parts komponent, som kunne løse netop dit problem.
Jeg er også temmelig sikker på, at den factory du har lavet, bygger videre på nogle af de grafiske kontroller der var i det udviklingsmiljø du nu måtte bruge.
Og så er vi tilbage ved udgangspunktet, som var, at visuelle værktøjer ikke holder! Jeg vil blive ved med at fastholde, at det eneste de visuelle værktøjer gør, er at fjerne/simplificere de opgaver, som alligevel ikke er kernen i problemet/løsningen, hvorved man får mere tid og overskud til at fokusere på det der i virkeligheden er kernen i problemet!
=>Bob
Se Hektors glimrende indlæg... ;o)
IDE'er laver spaghettikode, og laver bestemt heller ikke specielt optimeret kode...
Selv noget så simpelt som html kan ikke laves i IDE programmer...
Sovsen bliver enorm sammenlignet med den du selv ville have skrevet, og er tit fuldt med fejl... :o/
Se Hektors glimrende indlæg... ;o)
IDE'er laver spaghettikode, og laver bestemt heller ikke specielt optimeret kode...
Selv noget så simpelt som html kan ikke laves i IDE programmer...
Sovsen bliver enorm sammenlignet med den du selv ville have skrevet, og er tit fuldt med fejl... :o/
=> skidrow
Jeg giver dig fuldstændig ret i, at HTML skal skrives i hånden og ikke ved hjælpe af værktøjer som FrontPage eller lignende. Jeg snakker udelukkende om Win32 apps og GUI's til disse. Her får du ikke mere optimeret kode, ved selv at kode GUI'en fra bunden!
Jeg giver dig fuldstændig ret i, at HTML skal skrives i hånden og ikke ved hjælpe af værktøjer som FrontPage eller lignende. Jeg snakker udelukkende om Win32 apps og GUI's til disse. Her får du ikke mere optimeret kode, ved selv at kode GUI'en fra bunden!
skidrow, du kan ikke lave ALT fra tekst editoren i vs.net? (tsk tsk, kan sq sagtens lade sig gøre, du kan tilmed fjerne alt undtaget tekst feltet, men ok du vil jo brokke dig over alt der har med ms at gøre, så kommer ikke bag på mig)
flame flame, gidder ikke spilde tid på at læse det
flame flame, gidder ikke spilde tid på at læse det
Nu er det vist ved at være på tide at jeg blander mig lidt i denne diskussion, for de argumenter der holdes i luften er lidt for platte....
GUI designer laver spaghettikode...
for det første er GUI'en ikke det tunge applikatinerne... hvis det er det er det ihvertfald fordi man tænker med røven, eller andre sydlige lægmesdele...
så ud over at GUI designeren er der som en HJLÆP for programmøren, og her tænker jeg ikke på bumsede teenagere, med fedtet hår, der sidder på deres flade, foran skærmen, men på de folk der sidder rundt omkring i virksomhederne der skal producerer noget for den løn de får....
RAD development er vejen frem, det er der slet ikke noget at diskuterer om, for det eliminerer en masse småfejl, og gør i det heletager debugging nemmere.
programmering er IKKE at klikke sig til en knap!
Hvis det KAN være så simpel hvorfor så gøre det sværre, hvis det var det man ville kunne man da bare skrive hele sin kode i asm (eller bruge linux...)
Jeg har et program, hvor jeg skal bruge ca. 85 billedelementer:tja så er spørgsmålet egentlig om du har lavet et program eller en farvepallette... Det eneste eksempel hvor jeg kunne forestille mig at man ville bruge så mage billeder var hvis man prøver at lave et skin til sit program, og så er et argument... hvorfor det, blev GUI'en nemmere at forstå for brugeren???
Ja det var så lige lidt luft frit fra hoften...
(Ge'me your best shot)
GUI designer laver spaghettikode...
for det første er GUI'en ikke det tunge applikatinerne... hvis det er det er det ihvertfald fordi man tænker med røven, eller andre sydlige lægmesdele...
så ud over at GUI designeren er der som en HJLÆP for programmøren, og her tænker jeg ikke på bumsede teenagere, med fedtet hår, der sidder på deres flade, foran skærmen, men på de folk der sidder rundt omkring i virksomhederne der skal producerer noget for den løn de får....
RAD development er vejen frem, det er der slet ikke noget at diskuterer om, for det eliminerer en masse småfejl, og gør i det heletager debugging nemmere.
programmering er IKKE at klikke sig til en knap!
Hvis det KAN være så simpel hvorfor så gøre det sværre, hvis det var det man ville kunne man da bare skrive hele sin kode i asm (eller bruge linux...)
Jeg har et program, hvor jeg skal bruge ca. 85 billedelementer:tja så er spørgsmålet egentlig om du har lavet et program eller en farvepallette... Det eneste eksempel hvor jeg kunne forestille mig at man ville bruge så mage billeder var hvis man prøver at lave et skin til sit program, og så er et argument... hvorfor det, blev GUI'en nemmere at forstå for brugeren???
Ja det var så lige lidt luft frit fra hoften...
(Ge'me your best shot)
#22 bob:
Nej, det er ikke en kapitulation. Min pointe er, at selvom du eller jeg ikke kan optimere koden generere af en gui-builder, så er det ikke ensbetydende med, en MEGET sejere/dygtigere programmør end vi to ikke kan optimere det. Jeg er ikke en specielt god programmør, men jeg vil være enddog meget overrasket, hvis du kan finde en gui-builder, der laver kode, der er så god, at jeg ikke kan optimere dets resultat (underforudsætning af, at jeg kan sproget selvfølgelig). Det samme gør sig selvfølgelig også gældende for andre programmører og udviklere - især som deres evner vokser.
Nej, det er ikke en kapitulation. Min pointe er, at selvom du eller jeg ikke kan optimere koden generere af en gui-builder, så er det ikke ensbetydende med, en MEGET sejere/dygtigere programmør end vi to ikke kan optimere det. Jeg er ikke en specielt god programmør, men jeg vil være enddog meget overrasket, hvis du kan finde en gui-builder, der laver kode, der er så god, at jeg ikke kan optimere dets resultat (underforudsætning af, at jeg kan sproget selvfølgelig). Det samme gør sig selvfølgelig også gældende for andre programmører og udviklere - især som deres evner vokser.
#23 Hektor
Hvis vi antager at diskutionen kun drejer sig om almindelige brugerflader i windows programmer (altså ikke spil o.l.), så vil jeg gætte på at 99.9% af de programmører der laver denne type applikationer anvender de visuelle værktøjer de har til rådighed. For det første er de GUI elementer man har til rådighed i MS's udviklingsværktøjer så top-optimeret, at man ikke har et reelt behov for at forbedre det og for det andet er der jo ingen grund til at lave noget, som en anden alleree har lavet (faktisk i en udgave der er bedre end 99.9% af verdens programmører ville være i stand til) (... var kodegenbrug egentligt ikke dit problem i starten af denne diskution?). Og hvis man nu endeligt satte sig ned og kodede sit eget super-ekstra-mega-optimerede GUI Komponent bibliotek, ja så har man jo bare lavet sit eget lille visuelle udviklingsværktøj! :)
Dem der så er så super-seje, at de sidder og optimerer GUI programmering... ja, de sidder sq nok hos MS og laver denne type programmering til deres udviklingsværktøjer! :D
Hvis vi antager at diskutionen kun drejer sig om almindelige brugerflader i windows programmer (altså ikke spil o.l.), så vil jeg gætte på at 99.9% af de programmører der laver denne type applikationer anvender de visuelle værktøjer de har til rådighed. For det første er de GUI elementer man har til rådighed i MS's udviklingsværktøjer så top-optimeret, at man ikke har et reelt behov for at forbedre det og for det andet er der jo ingen grund til at lave noget, som en anden alleree har lavet (faktisk i en udgave der er bedre end 99.9% af verdens programmører ville være i stand til) (... var kodegenbrug egentligt ikke dit problem i starten af denne diskution?). Og hvis man nu endeligt satte sig ned og kodede sit eget super-ekstra-mega-optimerede GUI Komponent bibliotek, ja så har man jo bare lavet sit eget lille visuelle udviklingsværktøj! :)
Dem der så er så super-seje, at de sidder og optimerer GUI programmering... ja, de sidder sq nok hos MS og laver denne type programmering til deres udviklingsværktøjer! :D
#24 bob:
Hmm ... det tyder på, at vi snakker RET meget forbi hinanden.
Du snakker tilsyneladende om gui-komponenterne (knapper, menuer osv), mens jeg snakker om opbygningen af en brugerflade vha disse. Jeg kan ikke optimere rutinerne indbygget i funktionerne, men når en gui-builder bruger 14 linjer kode, for blot at placere et element på en brugerflade, og jeg kan lave en factory-metode, der kan gøre det samme på 7, så er det en optimering - både i hastighed, plads og læsevenlighed i koden.
Igen - jeg snakker ikke om at forbedre de komponenter, en gui er bygget op af, jeg snakker om selve opbygningen af den - lidt ligesom at lægge et puslespil, hvor brikkerne skal lægges på plads. Håber at det gør det lidt tydeligere.
Hmm ... det tyder på, at vi snakker RET meget forbi hinanden.
Du snakker tilsyneladende om gui-komponenterne (knapper, menuer osv), mens jeg snakker om opbygningen af en brugerflade vha disse. Jeg kan ikke optimere rutinerne indbygget i funktionerne, men når en gui-builder bruger 14 linjer kode, for blot at placere et element på en brugerflade, og jeg kan lave en factory-metode, der kan gøre det samme på 7, så er det en optimering - både i hastighed, plads og læsevenlighed i koden.
Igen - jeg snakker ikke om at forbedre de komponenter, en gui er bygget op af, jeg snakker om selve opbygningen af den - lidt ligesom at lægge et puslespil, hvor brikkerne skal lægges på plads. Håber at det gør det lidt tydeligere.
#26 frank42:
Det er fuldstændigt rigtigt, og jeg er på ingen måde i stand til at vide, om compileren foretrækker den ene eller den anden type kode, og hvad der afvikles hurtigts, men når jeg engang om 16 måneder skal kigge på koden igen, så ved jeg godt, hvad der er hurtigst at overskue - det er de 92 linjer.
Det er fuldstændigt rigtigt, og jeg er på ingen måde i stand til at vide, om compileren foretrækker den ene eller den anden type kode, og hvad der afvikles hurtigts, men når jeg engang om 16 måneder skal kigge på koden igen, så ved jeg godt, hvad der er hurtigst at overskue - det er de 92 linjer.
#25 Hektor
Ok, så har vi snakket forbi hinanden. Det er jo hvad der kan ske i disse fora :)
Men som en sidste disput, vil jeg <STRONG>ikke</STRONG> give dig ret i, at færrer antal linier nødvendigvis giver hverken mere læsbar kode, eller mere optimeret kode. Mht. læsbarhed, så kan kode blive så kompakt, at den næste der kommer og kigger på skal sidde og skille det ad igen for at finde ud af hvad der sker. Mht. optimeret kode, så vil kompileren i sidste ende ofte opnå det samme resultat (hurra for moderne kompilerteknologi!). Men lad nu det ligge... ;)
Ok, så har vi snakket forbi hinanden. Det er jo hvad der kan ske i disse fora :)
Men som en sidste disput, vil jeg <STRONG>ikke</STRONG> give dig ret i, at færrer antal linier nødvendigvis giver hverken mere læsbar kode, eller mere optimeret kode. Mht. læsbarhed, så kan kode blive så kompakt, at den næste der kommer og kigger på skal sidde og skille det ad igen for at finde ud af hvad der sker. Mht. optimeret kode, så vil kompileren i sidste ende ofte opnå det samme resultat (hurra for moderne kompilerteknologi!). Men lad nu det ligge... ;)
bob:
det er korrekt at compilerne er ret gode idag.
Men de kan stadigvæk ikke håndtere dårlige udviklere.
Skal man tune noget ordentligt gør man det til sidst, ved brug af en Profiler, så man kun bruger tid på at optimere de metoder som reelt bruger tiden.
det er korrekt at compilerne er ret gode idag.
Men de kan stadigvæk ikke håndtere dårlige udviklere.
Skal man tune noget ordentligt gør man det til sidst, ved brug af en Profiler, så man kun bruger tid på at optimere de metoder som reelt bruger tiden.
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