Hvad er årsagen til, at mange programmører vælger at lave deres Windows-programmer i C++ istedet for i Delphi?
De eneste argumenter jeg har hørt er: "C++ kan bruges til andet end Windows", men mit spørgsmål lyder jo på WINDOWS-programmer, du kan alligevel ikke compile din C++ source til et Windows-program i f.eks. Linux bare sådan uden videre (så skal du have en emulator, og så kan Delphi også klare det).
Det andet argument jeg har hørt er: "C++ er meget større og stærkere". Mit spørgsmål til den lyder så: Bruger du måske en skovl når du skal tage salt/sukker, eller bruger du en teske? Det er meget muligt, at teskeen ikke er så stor og ikke kan tage så meget, men den er da meget mere velegnet til den opgave den nu engang er lavet til, end skovlen (som jo er mere velegnet til de lidt størrer "projekter" som der med en teske vil tage endu længere tid at lave).
Så hvorfor bruge C++ til Windows-programmer, når Delphi er langt mere velegnet?
Med delphi har man tendens til at fokusere på skærmbilleder istedet for et fornuftigt fundament. Med c/c++ er det omvendt (naturligvis min personlige observation..).
Jeg ville bl.a. vælge c/c++ på grund af syntaksen. Jeg bryder mig ikke om pascal/delphi syntaks.
En anden god grund til at vælge c/c++ er at de begge er standardiseret hos nogle organisationer - så har man mulighed for at skifte leverandør hvis man ikke er tilfreds eller leverandøren bliver opkøbt/går konkurs. (Mig bekendt er pascal/delphi ikke standardiseret ?)
Efter min mening så er de to væsentligste grunde til at C++ er så meget mere udbredt end Delphi at:
1) De fleste studerende idag lærer C/C++ (efterhånden dog en del Java i stedetfor) mens meget få studerende lærer Pascal/Delphi (i modsætning til for 20 år siden).
2) Mange Windows baserede firmaer foretrækker software fra Microsoft i stedet for 3. part (Borland).
Det er en religion. Jeg har selv programmeret mange år i Delphi, og det er et rigtigt fedt udviklingsmiljø. soreno har en pointe, men jeg mener at det skyldes at der nok er flere der starter i VB/Delphi end i c++. I teorien kan du lave alt i begge sprog. c++ har dog den fordel, at alle MS eksempler kommer i c++ og (!)VB.
Jeg vil også mene, at c++ er et bedre fundament til "seriøs erhvervprogrammering". Ikke fordi sproget nødvendigvis giver en fordel, men fordi MS c++ næsten er en de-facto standard. Til GUI programmering kan man jo så bruge ... VB *sorry folks*
Inprise har det vist nok hårdt økonomisk, og de har før udvist en eksemplarisk evne til ikke at rette fejl i produktet over flere år. Jeg har ikke den samme lange erfaring og dybtgående kendskab med MS udviklingsprodukter til at kunne udtale mig om det samme her.
jens >> Nej, jeg ved ikke hvad sysutils.pas er for'n fætter. Jeg har søgt lidt men kan ikke finde nogen form for dokumentation. Det kan jeg derimod hvis jeg søger på f.eks. stdlib og stdio.. Hvad kan sysutils ?
arne >> Jeg er tilhænger af et frit valg (og fri software). Derfor ser jeg gerne flere leverandører af (næsten) samme produkt. Men set med virksomhedsbrillerne så er det jo bare at følge strømmen og bruge Microsofts produkter - det er sikkert mest givende. Set men fremtidsbrillerne (de er godt nok lidt duggede..) så der intet der er sikkert. Heller ikke at Microsoft ikke bliver holdt i strammere tøjler, bliver splittet op osv.
Men spørgsmålet gik jo på hvorfor der laves så meget mere C++ end Delphi til Windows.
Og der tror jeg ikke at "hvis MS VC++ forsvandt så kan vi vælge en anden C++ compiler" har nogen som helst betydning for beslutnings-processen.
Det bunder mere i hvad de ansatte kan (minimering af uddannelses omkostninger) og gøre-som-alle-andre/satse-på-det-sikre/minimere-antal-leverandører (og der vinder Microsoft over Borland - og om man kan lide det eller ej, om man tror det er godt for IT industrien eller ej, om det holder på langt sigt eller ej - det er ret ligegyldigt, det betyder noget hos beslutningstagerne idag).
Jeg har helt sikkert ikke samme erfaring med Delphi og C++ "All Around" som I har gutter, dog synes jeg alligevel at jeg bor indskyde at rent grafisk (Inc. OpenGL) er Delphi et MEGET hurtigt og effektivt sprog, blandt andet fordi at Delphi bliver kompilet glimrende men ogsaa fordi at den er i stand til at kompile rent assembler kode. Grunden til at jeg kraftigt vil understrege dette er at jeg ofte hore folk udtale at Delphi ikke er hurtig/staerk nok til blandt andet spilbranchen og andre grafiske sammenhaenge - og det er og bliver en stor misforstaelse. Grunden til at Delphi ikke bliver anvendt saa meget i spilbranchen er fordi at store 3D applikationer som 3D Studio Max, Maya, SoftImage, Lighwave osv. er alle skrevet i C/C++. Det vil derfor blive lidt af en omvej at skrive plugins, editore osv. der har direkte tilgang til disse applikationer, hvis man bruger andre sprog end C/C++. Da spilbranchen er en stresset It branche er dette derfor en meget vigtig faktor da tid og deadlines betyder ufattelig mange penge. Saa min konklusion er at det ikke kun er paa grund af et sprogs styrke, men paa grund af tidsnod og selvfolig de kaere alt afgorende penge der bestemmer om et firma (branche) vaelger sprog!!!
Soren Klit Lambaek Teesside University of Middlesbrough
Det tager da dobbelt så lang tid at udvikle Windows-programmer med VC++ (selv med MFC og dens Delphi-lignende miljø (dialog-editoren). Jeg vil vædde med, at hvis vi tager 2 programmører, som begge taster lige hurtigt, en der er rigtig godt inde i C++, brug af Visual C++ og evt. MFC eller hvad han vælger at bruge, og en anden der er lige så god til Delphi, som den først nævnte programmør er god til Visual C++, og er lige så god til Pascal, som den først nævnte programmør er god til C++, og de begge 2 er lige godt inde i OpenGL eller DirectX, og giver dem til opgave, at lave et Windows-baseret 3D-modelleringsprogram via OpenGL eller DirectX, så vil Delphi-programmøren være først færdig.
Hvis de derimod skulle udvikle et spil, som ikke har nogen windows-lignende GUI, men udelukkende fokuserer grafik, så vil de blive færdig på samme tid, men C++ programmøren har arbejdet mere "behageligt" end Delphi-programmøren. Men i det øjeblik der bliver kastet en GUI ind i programmet, så vinder Delphi.
Jeg vælger kun at programmerer i Pascal, pga. Delphi. Hvis jeg derimod fik valget mellem at programmerer i Turbo Pascal eller i Turbo C++, vil jeg vælge Turbo C++, eftersom C++ er det mest behagelige sprog. Bruger dog ikke Borland C++ Builder, selvom det har C++ OG et Delphi-miljø, fordi at det simpelthen er blevet for bøvlet at arbejde med... Jeg ved ikke hvorfor, men det er som om at Pascal simpelthen er SKABT til Delphi, og ikke til noget som helst andet, og at Delphi-miljøet ikke er skabt til andet end Pascal, og at proppe et andet sprog ind (som f.eks. C++) kun gør det mere bøvlet at arbejde med...
Her er hvad jeg mener man skal bruge de forskellige værktøjer til:
Delphi: 1. Windows-programmer der benytter sig af Windows-lignende GUI.
C++: 1. Windows-programmer der udelukkende fokuserer på grafik (ikke grafik- editorer, de indeholder stadig Windows-lignende GUI, men rent grafik).
2. Til styring af div. elektronik (f.eks. at programmerer en maskine til at gøre et eller andet).
Java: Til udvikling af applikationer til håndholdte og mobil-telefoner (hertil kan C++ også anvendes, men foretrækker Java til dette område, eftersom jeg så ikke behøver at skrive koden om, hvis jeg skal udvikle til 2 forskellige håndholdte).
At bruge Java til at udvikle Windows-applikationer, eller at Delphi til at udvikle applikationer til håndholdte eller til styring af maskiner dur simpelthen ikke. Selvom alle sprogende KAN anvendes til alle dele (Delphi KAN godt bruges til at udvikle programmer til styring af maskiner eller til applikationer på håndholdte), så mener jeg stadig man skal holde dem adskildt, og lade dem klare hver sit arbejde. C++ er godt til all-around samt til GUI-opbygning, men da Delphi kom på banen, blev den altså bedst til GUI, og så er det vel at foretrække den (da den er bedst til det), C++ til noget andet, og Java til noget helt 3.
Lige et lille spørgsmål.... Nu har jeg arbejdet med ASP i mange år (3-4) og syntaksen minder meget om (Delphi)/Visual Basic Men her på det sidste års tid har jeg arbejdet rigtig meget med JavaScript, hvor dens syntaks minder meget om C++
Hvad ville jeres råd være om hvilket sprog man skulle vælge at gå igang med. Jeg har hentet programmet: Dev-C++ dvs., jeg faktisk har valgt c++ men er det det rigtige valg? Jeg har tænkt mig at lave online (windows) programmer, spil osv.. (i længere sigt, når jeg har specialiseret mig)
Vælg c++! Hvis du vil lave spil, så er c++ stort set det eneste rigtige. Det er standardsproget i spil-industrien og derfor også det sprog, hvor langt det meste eksempelkode til spil eksisterer i.
dcgeek>> "...vil jeg vælge Turbo C++, eftersom C++ er det mest behagelige sprog..." Det der er mest behaglig for dig behover jo nodvendigvis ikke at vaere ligesaa behaglig for en andre - Det er vel en smagssag, som er helt op til den enkelte programmor!!! Du naevner senere at du ville vaelge C++ til Windows-programmer der udelukkende fokusere paa grafik - Hvorfor? Efter min mening er C++ ikke mere rigtigt at bruge til grafik end foreksempel Delphi - og det har absolut intet med GUI at gore!!! Grafik og GUI har abolut intet med hinanden at gore, skal jeg gentage Grafik og GUI har absolut intet med hinanden at gore!!! :-))
Det vidste jeg godt, jeg mener bare, at når man programmerer i grafik, så glemmer du alt om GUI (som du selv nævner GUI og grafik er ikke det samme, nej, du bruger heller ikke drag'n drop når du programmerer grafik, det gør du derimod når du designer User Interface).
Derfor vil jeg vælge C++ hvis mine programmer udelukkende fokuserer på grafik, for så behøver jeg ikke at tage højde for GUI, så skal jeg *kun* kigge på min kode, og kan glemme alt om GUI-design. Men igen, jeg vil KUN programmerer i C++ hvis det er programmer der ikke fokuserer så meget på GUI, men med funktioner (f.eks. til styring af maskiner, det er ikke særlig ofte du ser GUI'en der).
Jeg bruger kun Pascal pga. Delphi. Mener tilgengæld at Delphi-miljøet er SKABT til Pascal, og ikke til C++ som med Borland C++ Builder. Kort sagt er min mening:
Pascal er KUN godt pga. Delphi, og Delphi er KUN godt pga. Pascal (dvs. INGEN c++ i Delphi-miljøet som i Borland C++ Builder og INGEN Pascal i "rent-kode-miljøer" (som f.eks. i Dev-c++, FreePascal, Turbo Pascal og andre "kun-rent-kode-miljøer")).
Selvfolig har du ret i at det kunne forvirre en ikke saa erfaren programmor med en et GUI miljo, hvis han eller hun kun er interesseret i at udvikle "rent" grafisk baseret applikationer (altsaa programmer uden Bruger Interface), men jeg ser det nu kun som en mega fordel. Naar jeg taenker paa alle de smaa-test, hvor jeg lige har brugt en TScrollBar, eller en TPanel osv. for hurtigt at teste en lille del i en storre sammenhaeng, har det kun vaeret en fordel at kunne (en stor lettelse) at man lige kunne bruge en eller anden komponent til at i forbindelse med en lyn-test!!!
Men for lige at komme tilbage til emnet: Hvorfor bruger man C++ til udvikling af almindelige Windows-programmer, når Delphi er langt stærkere og hurtigere på det området?
dcgeek >> Prøv at være lidt mere konkret (for at spore os tilbage på emnet). Hvad er det helt præcist der gør Delphi "stærkere og hurtigere" (i stikord) ?
Det der gør Delphi stærkere og hurtigere på det område (og KUN på det område, mener jeg) er, at du kan se hvordan dit program vil komme til at se ud under design-time, du behøver ikke at compile og køre programmet for hver gang du har placeret en ny button, for at teste om den er placeret rigtigt, samtidig med, at du bare kan dobbeltklikke på hver enkelte button, panel eller whatever, og kun se koden for det du vil til at arbejde med, og ikke 800 andre liniers kode (jo, hvis du scroller frem og tilbage). Mange WYSIWYG programmer har den ulempe, at din frihed bliver begrænset, og du kan ikke gå ind og ændre på de forskellige komponenter, det kan du i Delphi, der er tilhørende .pas filer med, og det er faktisk kun programmøren af det enkelte komponent der bestemmer, om du skal have lov til at ændre komponentet eller ej, og ikke programmet (som f.eks. hvis han kun vælger at inkludere en .dcu fil, så kan du ikke ændre komponenten, men det er programmøren af komponenten der bestemmer det, og ikke Delphi).
Du må da indrømme, at det er langt hurtigere og mere logisk at klikke på en button på et faneblad, og placere den på et af de dialogs som dit program indeholder, og trække og slippe den til det sted du vil have den placeret istedet for at se 100 % rent kode og hver gang du vil have en ny button, skal du oprette den, og skrive 12,42, hallo, hvordan skal jeg så kunne se hvor jeg placerer min button? Så skal jeg til at compile HVER evig eneste gang!
Okay, jeg ved godt, at Microsoft Visual C++ indeolder en dialog-editor, som kan det samme som i Delphi, der er bare 2 ulemper ved den i forhold til Delphi:
1. Når man arbejde med helt almindelige "windows-standard" komponenter som buttons, panels etc. skal du til at skrive et hav af koder for at få det ønskede resultat, f.eks. kan du i Delphi skrive: label1.caption := 'hej'; Kan du gøre det i Visual C++? Nej! Du kan ikke bare placere en label, og så skrive label1->caption = "hej"; jeg kan ikke huske hvad man skal skrive i C++, men det var i hvertfald meget mere koder der skulle skrives, bare for at få 'hej' til at stå i en label.
2. Når du compiler dine projekter i Visual C++, får du udover projekt-fil(er) en hel masse andre filer, der kun indirekte har noget at gøre med dit projekt. Lad os sige at du gemmer dit arbejde som du har lavet i Delphi, der bliver lavet en projekt-fil samt et antal pas (og evt. form-filer) alt efter hvad der indgår i dit program. Hvis dit program indeholder 3 vinduer, kommer der 3 .pas og 3.frm filer og en .dpr fil (som er projekt-filen, der "holder sammen" på dine 3 andre filer). Det er jo meget logisk. I Visual C++ kommer der 5-10 andre filer, som du ikke har haft noget med at gøre.
Det er på den måde jeg mener at Delphi er hurtigere og stærkere end C++.
kan vi prøve at få Visual Basic med ind i billedet?
Så vidt jeg ved er det da også et meget udbredt programmerings sprog..??
dcgeek >> som du skriver kan man i delphi bare skrive label1.caption := "hej"; og i C++ skal man skrive et hav af koder før man kan få programmet til at udskrive et "hej".... Men hvordan er det i Visual Basic - er det også så enkelt?
dcgeek m.fl. >>> Visual C++ og MFC: Sæt tekst på en button f.eks. Button.SetWindowText("Det kræver sgu da ikke mange koder ???");
Visual C++ genererer en del temporærer filer, men hvilke oversættere gør ikke det ? Temporære filer skal ikke distribueres. En færdig applikation kan godt bestå af en enkelt exe-fil !
C++ vs Delphi vs Visual Basic vs ... Hvor mange seriøse applikationer er skrevet i andet end C/C++ ??? Hvor mange operativsystemer ???
Mange seriøse programmer er skrevet i Delphi. Spørg selv borrisholt, sidste år vise han mig et program på sin bærbare, som kan styre et hotel... Hedder Picasso... Og koster 500.000 kr. - borrisholt - var det ikke det programmet kostede? Du ved det program du viste mig i sommerferien sidste år?
Nå, anyway, det var ihvertfald et stort, dyrt program - og udviklet i Delphi! Og kom ikke og sig det ikke var "seriøst", så tror jeg sq du får borrisholt på nakken :)
Jeg har ikke noget særligt kendskab til Delphi, men arbejder selv med Visual C++ / MFC .
Det kunne være interessant at vide, om Delphi er en udvidelse af Pascal eller om det er et udviklingsmiljø og Windows-framework til sproget Pascal.
For hvad er det vi skal diskutere... C++ vs Pascal eller Visual Studio vs Delphi ?
Til dcgeek vil jeg lige sige, at et programs størrelse og pris ikke nødvendigvis har noget med kvalitet at gøre. Ellers ville "Amanda" jo ha' været en stor success ;-)
Delphi er et Borland produkt - en IDE med libraries etc..
Sproget som vistnok ifølge en anden i denne tråd hedder Object Pascal er Pascal med Borlands extensions (og de extensions er ret omfattende i forhold til ISO Pascal).
Hvem var det der en gang sagde "Man bliver for gammel til det der c:=c+1;"? :)
Lad mig med det samme sige at jeg er stor tilhænger af Delphi, så fik vi den på plads! :)
Jeg har nu gennem 2-3 år programmeret i Delphi, og hver eneste gang har jeg nydt det venlige brugerinterface, hjælpe-systemet (som dejligt nok, ikke ligger online), den læsevenlige kode og ikke mindst muligheden for at udvikle applikationer utrolig hurtigt. Jeg har flere gange haft denne diskussion med en kammerat. Han har ofte argumenteret for at man har bedre styr på sin kode når man selv skriver den fra bunden. Prøv lige at forklar manden ideen bag properties og events. Det hedder at holde styr på sine komponenter! ;) Når nu han er så glad for at skrive koden fra brunden, så har jeg også prøvet at forklare ham at man ikke behøver at bruge VCL'en i Delphi. Man kan sagtens komme til at skrive alt den skide kode som C++ programmørerne skal tvinges til at skrive hver gang. "Men du skriver jo ikke dine applikationer fra starten, du bruger VCL'en!" Selvfølgelig gør jeg da det! Hvis jeg skal hente min nye computer hos et eller andet firma der ligger 50 km væk, så tager jeg da heller ikke cyklen, så bliver det da en biltur! Okay, bilen fylder mere, den bruger mere benzin og man kommer i dårlig kondition. Fint nok, men:
Gør det noget at en applikation fylder lidt mere end den behøver (bil i forhold til cykel)? Gør det noget at en applikation tager lidt flere ram end den behøver (benzin forbrug)? Gør det noget at man skriver mindre kode selv (dårlig kondition)?
Nej, vel! I det mindste får folkene med bilerne mere søvn og er lidt friskere til at køre nye steder hen næste dag, hvor folk med cykler har ømme muskler og også lige skal have lappet cyklen... Med andre ord: Folk med Delphi får mere tid til at gå nye veje og udforske nye elementer i omkring programmering. Folk med C++ er måske ikke helt færdige næste dag og hvis de er, så finder man dem trætte og så skulle der alligevel en patch på til sidst... ;)
Nu håber jeg ikke jeg har fornærmet nogen alt for meget... Ved godt at i alle i forvejen får for lidt søvn. Include(GeeksWhoNeedSleep, [hermandsen]);, men lidt humor skal der da være plads til! Se bare posttidspunktet for dette indlæg! :)
Håber også I forstår min lille sammenligning! ;)
Dilleberg spurte hvor mange seriøse applikationer der er skrevet i Delphi... Tjaaa... Et sted du måske kan sammenligne lidt er på SourceForge.net http://sourceforge.net/softwaremap/trove_list.php?form_cat=160 Her er lidt over 10.000 projektet skrevet i C, næsten 10.000 projekter skrevet i C++ og næsten 1.000 projekter i Delphi/Kylix (der ligger også et par hundrede stykker under Pascal og Object Pascal).
Hvis vi siger at det er statestikken verdenen over, multipliceret med en eller anden faktor (groft sagt), så har vi en hulens masse projekter i C/C++ og en kun en brøkdel Delphi-projekter. Betyder det at C++ har noget som Delphi ikke har? Til dels, ja... Delphi mangler f.eks. muligheden for at linke drivers. En mulighed de færeste nok får brug for, men alligevel! Her tror jeg dog den store forskel findes pga. standarden rundt omkring i verdenen... Nogen bruger Windows, andre Linux, nogle helt andre Mac osv. Windows er den mest udbredte, hvilket betyder at den bruges af flest mennesker. C++ er den mest udbredte inden for programmering og bruges derfor af flest mennesker. Logisk!
Dilleberg, du spurte også hvor mange Operativ Systemer der var skrevet i Delphi. Nu ville det nok ikke være helt nemt at skrive et OS i Delphi eftersom Delphi er skrevet til Windows, men i Pascal så da... Jeg ved ikke præcist hvor mange, men kan da nævne et! Et OpenSource projekt ved navn Delphine har sat sig ind for at skrive et OS i Delphi! :) http://sourceforge.net/projects/delphine/
I sidste ende må jeg nok indrømme at jeg nok har lidt den samme holdning som dcgeek. Sproget kommer an på opgaven. En mulighed nogen måske overser af og til er at koble de to sprog sammen og bygge en app med lidt fra det ene sprog og lidt fra det andet sprog. Her synes jeg selv at et godt eksempel er programmet Miranda-ICQ. http://sourceforge.net/projects/miranda-icq/ Det meste af selve programmet er skrevet i C og alt hvad der ellers hedder GUI er skrevet i Delphi. Hele projektet er så koblet sammen vha. diverse dll-filer og hvad ved jeg... En ide flere måske burde tage i brug! :)
En kammerat (samme som jeg havde religionskrig med tidligere) spurte mig en gang om jeg ikke havde lyst til at lave en Config-app til et program han havde lavet (et program til åbning af andre programmer vha. globale hotkeys). Hans program var nemlig skrevet i C og var fuldstændig uden GUI. Skulle han så konfigurere det måtte han selv skrive de rette indstillinger i en dertilhørende dat-fil af et hjemmelavet format. Jeg var på med det samme og de levede lykkeligt til deres dages ende... Eller i hvert fald til Blue Screen of Death! :)
Nu er det vist på tide jeg kommer i seng, for jeg kan efterhånden mærke at jeg få skrevet mere end jeg får fortalt... Øhhhh!?
God nat alle i glade programmørere. May the source be with you! ;)
I så fald mener jeg at diskussionen drejer sig om udviklingsmiljøer. Og hvad skal man så måle på ??? - Er det muligheden for at lave standard applikationer ? - Er det muligheden for at lave komponenter (ActiveX / COM) ? - Er det IDE'ens GUI ? - Er det programmets hastighed/størrelse ? - Er det portabilitet ? - Er det standardisering ? - Er det producenten ? (Ikke helt uvæsentlig, synes jeg, da mange betragter det som et minus, hvis producenten hedder Microsoft ;-)
Som sagt kender jeg kun Microsoft Visual C++/MFC. Findes der tilsvarende miljøer fra andre producenter ?
Søde venner .. JEg har nogen gange andet at tage mig til end at side og chatte med jer :-)
Jeg har også et kammera der skal passes :-)
Nå anyway. Det er rigtigt jeg professionelt, arbejder med et proukt det hedder Picasso. Prisen er vist nærmer 100.000 for en instalation. Med det kan styre et hotel, og gør det mange steder her i landet, og enkelte steder i :Norge og Svergie samt Frankrig.
Det der gør delphi stærkt frem for fx. MFC er alle de ekstra ting der er med til Delphi som man selv skal skrive til MFC. OG jo jeg har programmeret MFC.
Et ander godt eksempel er fx hvis du en en label vil skrive hvad klokken er gør du sådan her i DElphi :
Label1.Caption := 'Klokken er : ' + TimeToStr(Now);
Generelt ligger der i sysutils.pas en masse rare konveterings ting. Samt ting "man ikke kan undvære"
Et nemt lille Delphi eks er liste alle filer i et bestemt biblotek :
procedure TForm1.FormCreate(Sender: TObject); var res : Word; SearchRec : TSearchRec; begin res := FindFirst('*.*', faAnyFile, SearchRec); while res = 0 do begin Memo1.Lines.Add(SearchRec.Name); Res := FindNext(SearchRec); end; FindClose(SearchRec); end;
Det kunne jeg da godt tænke mig at se i MFC
Ellers er der sådan et kalsisk eks som at ligge lys/mørke på en JPEG billede :
Lad mig LIGE SLÅ HELT FAST Delphi laver SMå exefiler MFC Laver STORE.
1) Åben VSC++ 2) Nyt MFC Projekt. 3) Smid en knap på. Nå du klikke på den kommer der en messagebox frem. 4) Kompiler og LINK STATISK !!!!! (Delphi er statisk linket)
Kommentarer: Dette er en del af en lille applikation i Dialogform. Dialogen indeholder - et editfelt til indtastning af directorynavn. Feltet er tilknyttet en streng m_strDir - en listbox til at vise directoryets indhold. Listboxen er tilknyttet et objekt af typen CListBox, m_lbContent - en knap, Update, som tilknyttes en messagehandler, OnUpdate. Dvs OnUpdate kaldes når der trykkes på knappen.
Alle kontroller er anbragt i dialogen med den grafiske dialogeditor, dvs ingen kryptiske koordinater. Ovenstående kode er det eneste jeg har skrevet.
UpdateData(TRUE) overfører data fra kontrollen til de interne variable. UpdateData(FALSE) overfører data fra de interne variable til kontrollerne.
Filstørrelser: MFC statisk linket (som *.lib) 20 KB (20480 bytes) MFC dynamisk linket (som *.dll) 204 KB (208896 bytes)
Anslået tid til udvikling: 5 minutter
Nu var jeg så heldig, at CListBox'en har den ønskede funktionalitet ;-), men hvis det skal gøres som i Jens' eksempel vil det se sådan her ud: void CListDirDlg::OnUpdate() { UpdateData(TRUE); m_lbContent.ResetContent(); struct _finddata_t fdFileinfo; CString strMask = m_strDir + _T("*.*"); long lHandle = _tfindfirst(strMask,&fdFileinfo); if (lHandle != -1) { do m_lbContent.AddString(fdFileinfo.name); while (_tfindnext(lHandle,&fdFileinfo) != -1); _findclose(lHandle); } UpdateData(FALSE); }
Kommentar: Lister alt, både filer og directories (herunder . og ..) Men en passende filtrering er selvfølgelig mulig.
Borland altså bedere fat i den med GUI'en. Generaliseringen opstår her, fordi man ikke i væsenlig grad kan stille C++ Builder op i mod Delpi.
Den det med størelsen kan man komme ud over ved at bruge et program der kan pakke exe filen. Det bringer en gennemsnitligt Delphi program ned til 25% af størelsen. Og alt andet lige betyder det vel ikke så meget ?
Diverse tests viser at Delphi erlige så hurtig som C++ til at exekvere.
Det har tidligere været spurgt om Delphi findes til flere OS'er. Her er svaret ja. Den fås også til Linux. Men der hedder den Kylix, men er ellers det samme.
Og Kylix er desuden også C++ builder til Linux og hvorfor vælge nu når man har gang i Borland tingene, programmerne kan jo laves halvt i hvert, ikke at jeg ser nogen grund til at bruge Delphi delen når man også har builder delen, hvis man ikke havde builderen så er det noget nemmere med Delphi, så kunne man stadig hos borland linke det sammen med C++ kode.
Mig bekendt kan du debugge det samme i begge sprog ... For den sags skyld grave linje nummerer ud, samt callstack hvis dit program generer en AV. Det kan man både i delphi og C++.
Mit påstulat var at Delphi er meget nemmere at kode noget i, og det kræver meget mere kode i MFC.
Hvis du ønsker at knalde en hurtig GUI sammen er Delphi eller Builder da et stærkere værktøj end VC++, men hvis det er det eneste du ønsker at opnå hvorfor så ikke bare krybe til korset og bruge VB.
Min pointe var at VC++ ' debugger er Delphi / builder's overlegen.
Nu er det noget tid siden jeg har kodet Delphi (version 5.0) så muligvis debuggeren er forbedret. Men - VC++ har den eneste debugger jeg kender til der er i stand til at debugge flertrådede programmer med et fornuftigt resultat, automatic watches, evaluate & modify, breakpoints o.s.v er andre debuggere klart overlegent, at dette muligvis skyldes at MS benytter sig af nogle hemmelige system hooks som konkurrenterne ikke kender til er jeg sådan set lige glad med.
Jeg finder ikke grund til at uddybe mere, hvis du har arbejdet med begge applikationer og ikke mener VC++ debugger er overlegen så er det vel din egen sag.
>>miknil For mig virker det som om du har svært ved at forsvare din egen sag. Det kunne jo være at du selv to fejl!? :)
Jeg har endnu ikke haft problemer med at debugge flere trået programmer i Delphi, og jeg mener da selv at have haft samtlige af dine beskrevne funktioner, til hjælp! Breakpoints, Evaluate & Modify, Automatic watches, debugging ned i den enkelte funktion, Just-in-time-debugger... Samtidig gør Delphi hæftig brug af typer, hvilket betyder at compileren fortæller dig om der er den mindste fejl i koden, inden du kører programmet! Det kan også let undgåes vha. TypeCasting, eller konvertering via pointere. Har du dog vendt dig til Delphi's typer, så finder du sandsynligvis aldrig grund til at skulle bruge andet! :)
Delphi's klasse-heraki er også noget man klart bør fremhæve! :)
Jeg er af den opfattelse at VC++ debugger er *klart* overlegen, jeg har brugt begge i længere perioder og haft den bedste oplevelse med VC++'s. Watches, evaluate & modify ... er implementeret i alle seriøse debuggere, blot ikke så elegant og lettilgængeligt som i VC++, det er muligt at man også i Delphi kan debugge externe DLL'er, hooke op på en kørende applikation/service o.s.v - det er bare mest elegant i VC++. Jeg vil påtage mig at debugge et IP/OOP com objekt i VC++, men aldrig i Delphi. Klasse hierakiet i delphi er da udemærket, det er det sådan set også i VC++, Java o.s.v.
Det er naturligvis en subjektiv opfattelse, men jeg finder ObjectPascal alt for restriktiv, rigtige pointere er hvad der skal til.
>hermandsen "hvilket betyder at compileren fortæller dig om der er den mindste fejl i koden" Er groft forsimplet,compileren kan kun hjælpe dig med syntax fejl, semantiske fejl må du ha en debugger til at hjælpe dig med. Fejl i (mine) C++ programmer skyldes sjældent type systemet, der er Delphi's )for mig) stærke typesystem bare en klods om benet.
>jans B "Summa sumarum er at udvikling tiden ER længere i C++" holder altså ikke.
For dig er udviklingstiden kortere i Delphi, det er fordi du skriver GUI programmer, for mig er udviklingstiden kortere i C++, og debuggeren er om ikke den primære grund til valg af udviklingsværktøj så ihvertfald blandt de vigtigeste.
Uden iøvrigt at skulle gøre mig klog på emnet debugging i Delphi versus debugging i VC++.
Så er det forkert at "Er groft forsimplet,compileren kan kun hjælpe dig med syntax fejl, semantiske fejl må du ha en debugger til at hjælpe dig med.".
Både syntax og semantiske fejl findes af compileren. Logiske fejl finde i debuggeren. Visse ting som er semantiske fejl i Delphi vil være logiske fejl i VC++.
Når man skal vælge programmerings sprog og udviklingsværktøjer til et projekt er det min erfaring at en liste som at nedenstående kan hjælpe - vigtigste spørgsmål er først :
- Hvilke værktøjer har udviklerne erfaring med - Hvilken type af appliktaion er der tale om (GUI, Server ?) - Hvilken platform skal der afvikles på (f.eks. flere forskellige) - Hvilke eksisterende komponenter eller systemer skal der integreres mod
Som jeg ser det er det vigtigste hvad udvilerne har erfaring med, den tid det tager at lære et nyt sprog eller et nyt værktøj vil med stor sandsynlighed "æde" en hvilken som helst besparelse man kan opnå ved at vælge et nyt værktøj. Med mindre det selvfølgeligt er et meget stort projekt (10+ mandår).
Jeg skal lige tilføje at jeg selv er inkarneret tilhænger af VisualStudio C++, jeg udvikler primært ikke-GUI (Server) ting, hvor jeg synes C++ er rigtigt godt. Og uanset hvad man mener om Microsoft så må jeg give miknil ret i at debuggeren i Visual Studio rykker for vildt . . .
Øhm, som jeg ser det, er Delphi hurtigere, fordi man kan lave programmet med musen. Det er jo bare en stor omgang drag'n'drop, og så måske et par linier kode rundt omkring. Det er vel fordi andre allerede har gjort arbejdet med at skrive al koden, nu skal man så bare ændre på nogle properties.
>narrr Hvilken type programmer udvikler du ? Hvis programmering kun drejede sig om drag'n'drop, så var jeg ikke programmør.
Lad mig nævne en anden (efter min mening) fordel ved Visual Studio: I mit firma udvikler vi, foruden i C++/MFC, også i en proprietær version af C, men anvender ikke desto mindre Visual Studio til at administrere projekterne og compilere med en anden C-oversætter. Er det noget man kan trimme Delphi til ?
Jeg udvikler plug-ins (dll'er) til en 3.parts applikation og disse plug-ins kræver en bestemt opsætning af compileren for at fungere. Men heldigvis leverer 3.parts udvikleren en wizard med til Visual Studio, således at opsætningen altid er korrekt. Hvordan forholder Delphi sig til det ?
dilleberg >> Dit spm forstod jeg ikke helt ! Om Delphi kan oversættet andet end Object Pascal ?
Den der med DLL filer er jeg heller ikke helt frisk på hvad du mener med ? Fordi selvfølgelig kan du lave DLL filer i Delphi. Det er du formentlig ikke i tvivl om. Men den der med en bestemt opsætning hvad er det ? Jo jeg ved godt hvad en opsætning er ....
Jens B> Som jeg ser det, er Visual Studio bl.a. et (avanceret) interface til en make-fil. Jeg antager at make-fil begrebet er kendt. Derfor kan man faktisk specificere en vilkårlig compiler, hvis det er det man har brug for.
Vedr. opsætning, så kan Visual Studio f.eks. generere ActiveX komponenter, DLL'er, MFC baserede exe-filer, Win32 API baserede exe-filer, statisk/dynamisk linkede etc, som hver især kræver bestemte indstillinger. I mit eget tilfælde, kræves at en række funktioner (f.eks entry-point) er eksporterede, for at "moder"-programmet kan kommunikere med plug-in'en, at include- og lib-path er korrekt, at struct-alignment er korrekt, osv. Alt det sørger den medfølgende wizard for.
VC er meget konfigurerbart, man kan lave alle de "uundværlige" macro'er i VBA og putte det hele ind i sin egen toolbar, eller lave sine egne plug-ins i C++ (eller endda i Delphi). Se evt Codeguru og Codeproject som har masser af den slags nyttige småting.
>>arne_v Det er så det sted jeg mener at Delphi's geniale type-kontrol slår stærkt i gennem! Det er da logisk at du ikke må tildele en heltalsvariabel et reel værdi! Den skal afrundes, trunkteres eller behandles på en eller anden måde...
Jeg er også glad for at Delphi har to former for division! "/" og "div"...
/ giver et resultat i reelle tal. div giver et resultat i hele tal.
Er det fordi C++ folket er bange for at skrive for meget at de kun bruger "/"? Jeg ved godt at "begin end;" er længere end "{ }", meeen jeg tror nu ikke man slider sit tastatur op fordi man bruge Delphi frem for C++! ;)
En anden ting... Jeg hører ofte C++-programmørere sige at Pascal's syntaks er grim/uoverskuelig!? Hvorfor?
Personligt har jeg altid ment at det bedste var begin xxxend, fordi det nogen gange gør koden mere lætlæselig end både begin end og {}.
Hvis man kigger lidt på nyere sprog og antager at mennesker lærer af deres fejl, så vil jeg konkludere at fejl ved suspekte assignments er en god ting men at der ikke er behov for to divisioner.
Det her er jo ikke en diskution om hvilket sprog der er bedst... Men en åben religionskamp mellem tilhængere af Microsoft og Borland. Vi bør jo nok se på de rå ISO standardiserede sprog c++ og Object Pascal istedet, og hertil må jeg jo tilføje at jeg intet videre har udvilklet i object pascal.
Grunden til jeg valgte C++ var sprogets åbenlyse mange muligheder, for det første er det et sprog der når du mestre det, ja bare kender det ordentligt, gør det nemt at skifte til stort set hvilket som helst andet sprog (og nej her taler jeg ikke om Nedre Mongolsk, Kinesisk eller Svensk). C++'s objekt orienterede overflade, samt det faktum at man godt styr over hukommelses håndteringen.
Button1->Caption = "blah blah";
Som den også ses i C++ har intet med sproget at gøre. Hvis i vil sammenligne C++ med Object Pascal så gør det på ren ISO, og ikke hvad forskellige 1. og 3. parts compilere vil. For jeg mener Microsoft er jo ikke de eneste der laver C++ compilere, Intel, Borland, osv. gør det jo også, hvor mange der fremstiller OP compilere ved jeg ikke.
Så var der en der i et svagt øjeblik nævnte Visual Basic, ja der er kun en ting at sige, grav det ned, smid det væk, brænd det, udryd det. VB er et sprog som med al respekt, tilhører midaldrende folkeskole lærere der hungre efter at kunne lære deres elever bare lidt om computere/programmer. VB er simpelt, så simpelt så mange rollinger har valgt at forpeste os med I love u lignende pis fra det sprog. VB er en ringe performer (C++ fordel), har en rodet syntaks (en anden af C++ stærke sider), Ikke objekt Orienteret (C++ er), Ringe hukommelses håndtering og kontrol over den mængde hukommelse ens programmer bruger (C++ stærk side), VB har ingen egentlig kontrol med porte (i ved hvad jeg vil skrive).... Jeg kunne blive ved, det har intet med C++ vs. OP at gøre men så er den hybel med VB og ja bare tag ASP med i graven, færdig.
Denne diskution har været et par gange på eksperten, og denneher gang vil jeg give mit besyv med.
Min filosofi med hensyn til programmeringssprog er: Et programmeringssprog er et værktøj programmøren vælger til at udføre en vis opgave. Man kan sige at man har en værktøjskasse, hvori værktøjet er programmeringssprog som: C++, Delphi, C#, Jave etc.
Så efter min mening skal man selv lade folk bestemme om de vil bruge en hammer eller en rørtang til at slå søm i med. De får valget mellem disse to stykker værktøj, men kan ikke fortryde uden at kulle starte forfra. Hammeren er hurtigere og mere sikker, og kan tage større søm, men rørtangen lå tæætere meget på. C++ er sværre at lære men samtig hurtigere og mere stabilt (Hammeren) mens Delphi er let og lære men samtidig knap så hurtigt og knap stabilt(rørtangen).
I starten går det godt med at slå søm i med rørtangen men pludselig kommer du til nogle store søm du ikke kan slå i. Hvad vil du så gøre? Du må enten opgive projektet, starte forfra.
Jeg har personligt valgt at programmere i Delphi (startede rigtig med basis C og lidt videre til C++) og det er simpelthen fordi jeg synes at Delphi er mere overskueligt end C++.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
