/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
Apache
Fra : Klaus Petersen


Dato : 14-12-03 20:30

Hej ng.

Er der nogen her der har prøvet at compile Apache HTTP server?

Den compiler fint indtil til sidst, hvor den skriver:

Creating Version Resource
'awk' blev ikke genkendt som en intern eller ekstern kommando,
et program eller en batchfil.
Error executing c:\windows\system32\cmd.exe.

Apache.exe - 1 error(s), 0 warning(s)

Jeg bruger Visual Studio 6.0.

Klaus.



 
 
Jakob Møbjerg Nielse~ (14-12-2003)
Kommentar
Fra : Jakob Møbjerg Nielse~


Dato : 14-12-03 20:34

Klaus Petersen wrote:
> Creating Version Resource
> 'awk' blev ikke genkendt som en intern eller ekstern kommando,
> et program eller en batchfil.

Du mangfler awk, der er et kendt *NIX program. Prøv at installere
cygwin, så skulle du gerne få fat i det.

--
Jakob Møbjerg Nielsen | "Nine-tenths of the universe is the
jakob@dataloger.dk | knowledge of the position and direction
http://www.jakobnielsen.dk/ | of everything in the other tenth."
| -- Terry Pratchett, Thief of Time



Jacob Bunk Nielsen (14-12-2003)
Kommentar
Fra : Jacob Bunk Nielsen


Dato : 14-12-03 20:36

"Klaus Petersen" <spectual2@getTOnet.dk> writes:

> Er der nogen her der har prøvet at compile Apache HTTP server?

Ja, jeg har da. Bare aldrig under Windows

> Den compiler fint indtil til sidst, hvor den skriver:
>
> Creating Version Resource
> 'awk' blev ikke genkendt som en intern eller ekstern kommando,
> et program eller en batchfil.

Du mangler awk.

Du har nok i øvrigt bedre held med at få hjælp ovre i Apache-gruppen
eller i en af Windows-grupperne.

--
Jacob - www.bunk.cc
Backed up the system lately?

Troels Arvin (14-12-2003)
Kommentar
Fra : Troels Arvin


Dato : 14-12-03 20:52

On Sun, 14 Dec 2003 20:29:51 +0100, Klaus Petersen wrote:

> 'awk' blev ikke genkendt som en intern eller ekstern kommando, et
> program eller en batchfil.

Hvis jeg var dig, ville jeg installere "MSYS": http://www.mingw.org/

Det er en samling af de mest basale unix-build hjælpeværktøjer. Efter
lidt tilretninger af din PATH, skulle fx. awk findes i din sti, og
problemet, du nævner, gå væk.

Man kan vælge flere forskellige grader af komplethed og bleeding-edge
agtighed mht. msys, men min bud er, at følgende fil er god for dig:
http://prdownloads.sf.net/mingw/MSYS-1.0.10-rc-3.exe?download - Ellers:
læs nogle relevante sider på mingw.org-sitet.

Du kan evt. supplere med MinGW, hvis du ud over MSYS ønsker en god,
gratis compiler til Windows. MSYS+MinGW er et alternativ til den mere
omfattende "Cygwin" programsamling, og MSYS+MinGW har bl.a. den fordel, at
de resulterende programmer ikke er afhængig af en særlig
unix-emulerings-DLL. Supplerer man MSYS+MinGW med et IDE såsom Dev-C++
(eller måske MinGW Developer Studio[2]?), har man et ret godt, gratis
udviklingsmiljø på Windows.

Note 1:
Dev-C++:
http://www.bloodshed.net/devcpp.html

Note 2:
MinGW Developer Studio:
http://www.parinya.ca/
Har ikke personlige erfaringer med denne. Har nogen det?

--
Greetings from Troels Arvin, Copenhagen, Denmark


Nicolai Hansen (15-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 15-12-03 11:53

> Du kan evt. supplere med MinGW, hvis du ud over MSYS ønsker en god,
> gratis compiler til Windows. MSYS+MinGW er et alternativ til den mere
> omfattende "Cygwin" programsamling, og MSYS+MinGW har bl.a. den fordel, at
> de resulterende programmer ikke er afhængig af en særlig
> unix-emulerings-DLL. Supplerer man MSYS+MinGW med et IDE såsom Dev-C++
> (eller måske MinGW Developer Studio[2]?), har man et ret godt, gratis
> udviklingsmiljø på Windows.
>
> Note 1:
> Dev-C++:
> http://www.bloodshed.net/devcpp.html
>
> Note 2:
> MinGW Developer Studio:
> http://www.parinya.ca/
> Har ikke personlige erfaringer med denne. Har nogen det?

Kun med MinGW som er en super compiler (iflg benchmarks markedets
suverænt bedste compiler). Jeg er en af den slags programmører som
bruger notepad og kommando linier :)
Men jeg har hørt masser af gode ting om Dev-C++

Mogens Hansen (15-12-2003)
Kommentar
Fra : Mogens Hansen


Dato : 15-12-03 21:47

"Nicolai Hansen" <nic@aub.dk> wrote:

[8<8<8<]
> Kun med MinGW som er en super compiler (iflg benchmarks markedets
> suverænt bedste compiler).

Jeg troede ikke at den suverænt bedste compiler fandtes.

Hvilke benchmarks henviser du til ?

I forhold til hvilke parametre er den bedst, f.eks.
* Overholdelse af C++ Standarden (bedre end Comeau ?)
* Performance i oversatte programmer (bedre end Intel C++ 8 ?)
* Oversættelses hastighed (bedre end Microsoft Visual C++ .NET 2003 ?)
* Mest produktiv til at lave GUI front-ends til databaser (bedre end
Borland C++Builder 6 ?)
* Bedste fejlmeddelelser
* Mest stabile
etc. ?

Venlig hilsen

Mogens Hansen



Troels Arvin (15-12-2003)
Kommentar
Fra : Troels Arvin


Dato : 15-12-03 21:54

On Mon, 15 Dec 2003 21:47:25 +0100, Mogens Hansen wrote:

>> Kun med MinGW som er en super compiler (iflg benchmarks markedets
>> suverænt bedste compiler).
>
> Jeg troede ikke at den suverænt bedste compiler fandtes.

Jeg synes også, at Nicolais ros var lidt unuanceret. Jeg har i
hvertfald aldrig hørt, at GCC skaber den allerhurtigste kode til
Intel-agtige CPUer.

MinGW==gcc kan tænkes at vinde på
- tilgængelighed over platforme
- pris
- minimering af bureaukrati (licens-halløj)

--
Greetings from Troels Arvin, Copenhagen, Denmark


Nicolai Hansen (16-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 16-12-03 13:34

Troels Arvin <troels@arvin.dk> wrote in message news:<pan.2003.12.15.20.53.55.389710@arvin.dk>...
> On Mon, 15 Dec 2003 21:47:25 +0100, Mogens Hansen wrote:
>
> >> Kun med MinGW som er en super compiler (iflg benchmarks markedets
> >> suverænt bedste compiler).
> >
> > Jeg troede ikke at den suverænt bedste compiler fandtes.
>
> Jeg synes også, at Nicolais ros var lidt unuanceret. Jeg har i
> hvertfald aldrig hørt, at GCC skaber den allerhurtigste kode til
> Intel-agtige CPUer.

Det var så også mest min egen mening :) Men jeg har læst mange
benchmarks som underbygger den (hastigheden på ting som QuickSort,
linked lists).
Og (bør bemærkes) jeg talte kun om compilere til Windows (med visuel
grænseflade og den slags - ikke til DOS programer).

Nicolai Hansen (16-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 16-12-03 08:54

> Hvilke benchmarks henviser du til ?

Puha, dem er der faktisk mange af. Google på compiler benchmarks, så
godt som alle jeg har set giver det samme billede. Jeg tænker især på
sammenligninger med Borland CCPB og MSVC++ som vel er de mest normale
-andre- compilere til noget visuelt windows.

http://www.willus.com/ccomp_benchmark.shtml?p1 (kom først op på
googlen)

Og ja, Intel's nye compiler er bedre.. men kan den ikke kun compile
til deres egen processor?

Ivan Johansen (16-12-2003)
Kommentar
Fra : Ivan Johansen


Dato : 16-12-03 09:17

Nicolai Hansen wrote:
>>Hvilke benchmarks henviser du til ?
> Puha, dem er der faktisk mange af. Google på compiler benchmarks, så
> godt som alle jeg har set giver det samme billede. Jeg tænker især på
> sammenligninger med Borland CCPB og MSVC++ som vel er de mest normale
> -andre- compilere til noget visuelt windows.

Så du mener at MinGW er hurtigere til at lave grafiske brugergrænseflader?

> http://www.willus.com/ccomp_benchmark.shtml?p1 (kom først op på
> googlen)
>
> Og ja, Intel's nye compiler er bedre.. men kan den ikke kun compile
> til deres egen processor?

Jeg har kun kigget kort på siden, men så vidt jeg kan se viser den kun
kørselstider. Og så vidt jeg kan se optimerede både Intel og VC bedre
end MinGW.

Ivan Johansen


Nicolai Hansen (16-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 16-12-03 15:11

> Så du mener at MinGW er hurtigere til at lave grafiske brugergrænseflader?

Nej - men jeg sammenligner med andre compilere til visuelle systemer
(MSVC++, BCPPB), ikke med linux eller dos compilere (det var det jeg
prøvede at sige). At lave en visuel brugergrænseflade (runtime) er jo
et spørgsmål om Windows, ikke om din compiler.

Ivan Johansen (16-12-2003)
Kommentar
Fra : Ivan Johansen


Dato : 16-12-03 15:49

Nicolai Hansen wrote:
>>Så du mener at MinGW er hurtigere til at lave grafiske brugergrænseflader?
> Nej - men jeg sammenligner med andre compilere til visuelle systemer
> (MSVC++, BCPPB), ikke med linux eller dos compilere (det var det jeg
> prøvede at sige). At lave en visuel brugergrænseflade (runtime) er jo
> et spørgsmål om Windows, ikke om din compiler.

Så du mener ikke at man kan lave noget visuelt under Linux? At lave
brugergrænseflade er ikke et spørgsmål om Windows men mere et spørgsmål
om udviklingsmiljø og delvist om compiler. Både BCB og VC.NET indeholder
udvidelser til C++ som gør det nemmere at lave brugergrænseflader.

Du sammenligner med andre compilere, men hvad sammenligner du? Hvor
hurtigt de compiler?

Det link du gav antyder at du måske mener hvor god compileren er til at
optimere det færdige program med hensyn til hastighed. Men når du kun
snakker visuelle systemer har jeg svært ved at se at det er relevant.

Ivan Johansen


Nicolai Hansen (17-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 17-12-03 08:01

> Så du mener ikke at man kan lave noget visuelt under Linux? At lave
> brugergrænseflade er ikke et spørgsmål om Windows men mere et spørgsmål
> om udviklingsmiljø og delvist om compiler. Både BCB og VC.NET indeholder
> udvidelser til C++ som gør det nemmere at lave brugergrænseflader.

Det nævner jeg intet om. Jeg snakker om at de skal sammenlignes på et
retfærdigt grundlag.
Jeg er interesseret i en compiler som opfylder flg krav:
1) Skal kunne køre på Windows
2) Det compilerede program skal kunne køre på Windows
3) Den skal kunne compilere en grafisk brugergrænseflade til Windows

Jeg snakker ikke om hvor let det er at lave brugegrænsefladen.

> Du sammenligner med andre compilere, men hvad sammenligner du? Hvor
> hurtigt de compiler?

Hvor god den resulterende performance er - især i tungere opgaver,
sorteringer, søgninger, floating point beregninger.

> Det link du gav antyder at du måske mener hvor god compileren er til at
> optimere det færdige program med hensyn til hastighed. Men når du kun
> snakker visuelle systemer har jeg svært ved at se at det er relevant.

Igen - kravet er at den skal kunne compilere et visuelt system. Hvis
du laver f.eks. en QuickSort af 500000 elementer er hastigheden i høj
grad afgørende - også selvom du har et visuelt system du skal trykke
en "start" knap i.

Ivan Johansen (17-12-2003)
Kommentar
Fra : Ivan Johansen


Dato : 17-12-03 08:54

Nicolai Hansen wrote:
> Det nævner jeg intet om. Jeg snakker om at de skal sammenlignes på et
> retfærdigt grundlag.
> Jeg er interesseret i en compiler som opfylder flg krav:
> 1) Skal kunne køre på Windows
> 2) Det compilerede program skal kunne køre på Windows
> 3) Den skal kunne compilere en grafisk brugergrænseflade til Windows
>
> Jeg snakker ikke om hvor let det er at lave brugegrænsefladen.

Så kan jeg ikke forstå hvorfor du bliver ved med at snakke om visuelle
systemer.

> Hvor god den resulterende performance er - især i tungere opgaver,
> sorteringer, søgninger, floating point beregninger.

Okay, det var det jeg ville vide. Det fremgik bestemt ikke klart.

> Igen - kravet er at den skal kunne compilere et visuelt system.

Jeg forstår ikke hvorfor du bliver ved med at snakke om visuelle
systemer, når du selv siger at det ikke har noget med brugergrænseflader
at gøre.

> Hvis
> du laver f.eks. en QuickSort af 500000 elementer er hastigheden i høj
> grad afgørende - også selvom du har et visuelt system du skal trykke
> en "start" knap i.

Men er det ikke ligegyldigt om der er en brugergrænseflade? Jeg forstår
heller ikke hvad dit link skulle vise. Der en kun lavet nogle får test
hvor MinGW ikke er den bedste i nogen af dem. Desuden er de fleste af
compilerne forældede.

Ivan Johansen


Nicolai Hansen (18-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 18-12-03 11:04

> Så kan jeg ikke forstå hvorfor du bliver ved med at snakke om visuelle
> systemer.

Jeg snakker om et "sammenligningsgrundlag". Det er vigtigt at de ting
man sammenligner er sammenlignelige. Derfor sætter jeg nogle
mindstekrav til hvad der skal opfyldes. At kunne kompilere en visuel
grænseflade med API kald etc etc (og have de header filer og libraries
som understøtter dette let tilgængelige).

> > Hvor god den resulterende performance er - især i tungere opgaver,
> > sorteringer, søgninger, floating point beregninger.
>
> Okay, det var det jeg ville vide. Det fremgik bestemt ikke klart.

Nej, sorry. Det er det jeg roder mest med, så det var underforstået
for mig

> > Igen - kravet er at den skal kunne compilere et visuelt system.
>
> Jeg forstår ikke hvorfor du bliver ved med at snakke om visuelle
> systemer, når du selv siger at det ikke har noget med brugergrænseflader
> at gøre.

Det er for at undgå at drage sammenligninger mellem Borland C++ til
DOS, gcc til Linux og MSVC++. Disse er ret usammenlignelige i mine
øren. Også selvom det program man laver kan compiles på alle tre.

De benchmarks som jeg så flittigt har refereret til er flere år
gamle... Så MingW er nok blevet overhalet indenom af MSVC++ og især
Intel's nye compiler (som jeg så stadig mener kun kan lave programmer
til Intel processorer, og ikke f.eks. AMD, men jeg er ikke sikker i
denne påstand).

Ivan Johansen (18-12-2003)
Kommentar
Fra : Ivan Johansen


Dato : 18-12-03 12:10

Nicolai Hansen wrote:
> Jeg snakker om et "sammenligningsgrundlag". Det er vigtigt at de ting
> man sammenligner er sammenlignelige. Derfor sætter jeg nogle
> mindstekrav til hvad der skal opfyldes. At kunne kompilere en visuel
> grænseflade med API kald etc etc (og have de header filer og libraries
> som understøtter dette let tilgængelige).

Du får svært ved at finde en compiler som ikke kan bruges til at
programmere op imod et API.

> Det er for at undgå at drage sammenligninger mellem Borland C++ til
> DOS, gcc til Linux og MSVC++. Disse er ret usammenlignelige i mine
> øren. Også selvom det program man laver kan compiles på alle tre.

Både Borland C++ til DOS, gcc til Linux og MSVC kan lave visuelle
brugergrænseflader. Det du i virkeligheden mener er at du sammenligner
Windows-compilere.

> De benchmarks som jeg så flittigt har refereret til er flere år
> gamle... Så MingW er nok blevet overhalet indenom af MSVC++ og især
> Intel's nye compiler (som jeg så stadig mener kun kan lave programmer
> til Intel processorer, og ikke f.eks. AMD, men jeg er ikke sikker i
> denne påstand).

Jeg kan ikke se hvorfor Intels compiler ikke skulle kunne bruges til
AMDs processorer. Bort set fra MMX er det samme instruktionssæt.

Ivan Johansen


Mogens Hansen (18-12-2003)
Kommentar
Fra : Mogens Hansen


Dato : 18-12-03 20:40



"Nicolai Hansen" <nic@aub.dk> wrote:

[8<8<8<]
> > Jeg forstår ikke hvorfor du bliver ved med at snakke om visuelle
> > systemer, når du selv siger at det ikke har noget med brugergrænseflader
> > at gøre.
>
> Det er for at undgå at drage sammenligninger mellem Borland C++ til
> DOS, gcc til Linux og MSVC++. Disse er ret usammenlignelige i mine
> øren. Også selvom det program man laver kan compiles på alle tre.

Jeg antager at du mener den gratis Borland C++ V5.5, som er en 32 bit
Windows compiler.
Compileren er i sig selv en console applikation - hvilket ofte forveksles
med en DOS applikation.
Den compiler kan sagtens lave programmer med grafisk brugergrænseflade idet
du har adgang til Win32 API'et.
Det er naturligvis ikke så let som med den kommercielle udgave Borland
C++Builder - det er jo netop derfor Borland kræver penge for den.

>
> De benchmarks som jeg så flittigt har refereret til er flere år
> gamle... Så MingW er nok blevet overhalet indenom af MSVC++ og især
> Intel's nye compiler

Hvorfor giver du ikke et links til de benchmarks, selvom de er flere år
gamle ?
Flere af dem jeg fandt og har givet links til var flere år gamle, men kunne
heller ikke underbygge din påstand.

> (som jeg så stadig mener kun kan lave programmer
> til Intel processorer, og ikke f.eks. AMD, men jeg er ikke sikker i
> denne påstand)

Intels compiler understøtter naturligvis ikke specielle AMD features, som
f.eks. 64 bit instruktioner til Athlon64 og Opteron (gcc gør, og Microsoft
gør i næste version).
Men det betyder langtfra at Intel C++ og AMD processorer er et problem.
Jeg kører Intel C++ bl.a. på en Athlon XP2200+ under MS-Windows og Linux
uden problemer, og programmerne den genererer eksekverer også udemærket.
Hvis man beder compileren om at generere instruktioner som AMD og ældre
Intel processorer ikke undestøtter, så kan det naturligvis give problemer.

Venlig hilsen

Mogens Hansen



Mogens Hansen (16-12-2003)
Kommentar
Fra : Mogens Hansen


Dato : 16-12-03 21:25


"Nicolai Hansen" <nic@aub.dk> wrote:

> Nej - men jeg sammenligner med andre compilere til visuelle systemer
> (MSVC++, BCPPB), ikke med linux eller dos compilere (det var det jeg
> prøvede at sige). At lave en visuel brugergrænseflade (runtime) er jo
> et spørgsmål om Windows, ikke om din compiler.

Bare for at undgå eventuelle misforståelser:
Intel C++ for Windows kan udemærket anvendes til at skrive programmer med
grafisk brugergrænseflade til MS-Windows platformen.

Det samme gælder formodentlig for enhver seriøs C eller C++ compiler til
MS-Windows, idet det må antages at man har fuld adgang til Win32 API'et.

Venlig hilsen

Mogens Hansen



Mogens Hansen (16-12-2003)
Kommentar
Fra : Mogens Hansen


Dato : 16-12-03 21:26

"Nicolai Hansen" <nic@aub.dk> wrote:
> > Hvilke benchmarks henviser du til ?
>
> Puha, dem er der faktisk mange af. Google på compiler benchmarks, så
> godt som alle jeg har set giver det samme billede. Jeg tænker især på
> sammenligninger med Borland CCPB og MSVC++ som vel er de mest normale
> -andre- compilere til noget visuelt windows.
>
> http://www.willus.com/ccomp_benchmark.shtml?p1 (kom først op på
> googlen)

Tak.

Den sammenligner
Borland C++ 5.5.1 (svarende til Borland C++Builder V5.0) (bcc)
Microsoft Visual C++ V6.0 (msvc)
Intel C++ V5.0 (icl)
MinGW, gcc 2.95-3.6 (mingw)
Digital Mars (tidligere Zortec, derefter Symantec - gammel og vist ikke
meget vedligeholdt)

Test BW1D (Norm PIII)
bcc: 1.49
icl: 1.0 (hurtigst)
msvc: 1.13
mingw: 1.52 (langsommest)

Test FEM2D (Norm PIII):
bcc: -
icl: 1.0 (hurtigst)
msvc: 1.04
mingw: 1.19 (langsommest)

Test LAME (Norm PIII):
bcc: 2.90 (langsommest)
intel: 1.0 (hurtigst)
msvc: 1.88
mingw: 1.71

I 2 af disse 3 målinger er MinGW den langsommeste og i ingen af de 3
målinger er MinGW den hurtigste.

Kan du på baggrund af den performance måling forklare os hvordan det
understøtter udsagnet om at MinGW "iflg benchmarks markedets suverænt bedste
compiler" ?


Bemærk at performance af det genererede program blot er een af mange
kvalitets parametre for en compiler.


Min pointe er ikke at gcc er nogen dårlig compiler - jeg bruger den selv med
fornøjelse.
Min pointe er blot at hvis man tror at den bedste C eller C++ compiler
findes, har man en meget firkantet verdensopfattelse.
For proprietære sprog (f.eks. Visual Basic eller Delphi) findes den bedste
(eneste) naturligvis.

Venlig hilsen

Mogens Hansen



Nicolai Hansen (17-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 17-12-03 07:55

> Kan du på baggrund af den performance måling forklare os hvordan det
> understøtter udsagnet om at MinGW "iflg benchmarks markedets suverænt bedste
> compiler" ?

Nej - men jeg har læst en del andre benchmarks som, for de flestes
vedkommende, har givet dette billede. Min egen personlige erfaring med
BCPPB, MSVC++ og MinGW er den samme som de benchmarks.

> Bemærk at performance af det genererede program blot er een af mange
> kvalitets parametre for en compiler.

Performance/filstørrelse er en ret god peger - selvfølgelig hvis det
grundliggende er i orden. Jeg tror nu ikke at der er nogen som helst
forskel mellem MSVC++ og MinGW i "overholdelse af C++ standarden". De
overholder den med ret stor sandsynlighed begge to 100%.

> Min pointe er ikke at gcc er nogen dårlig compiler - jeg bruger den selv med
> fornøjelse.
> Min pointe er blot at hvis man tror at den bedste C eller C++ compiler
> findes, har man en meget firkantet verdensopfattelse.
> For proprietære sprog (f.eks. Visual Basic eller Delphi) findes den bedste
> (eneste) naturligvis.

Min opfattelse bygger på mange ting. Et eksempel var at jeg rodede med
noget Direct3D grafik. Dette er selvfølgelig naturligt for MS
compileren. Det viste sig at være besværligt på grænsen til det
umulige med Borlands compiler. Men med MinGW var det lige så let som
på MSVC++. Egentligt ret imponerende, når man tænker på at det er
Microsoft der snakkes med her...

Men jeg vil pointere at det er min helt personlige, ganske subjektive,
mening. Hvem end der spurgte, spurgte om folks erfaringer med MinGW.
Og min QuickSort kører stadigvæk 10% hurtigere med MinGW end med
MSVC++ ;)

Ivan Johansen (17-12-2003)
Kommentar
Fra : Ivan Johansen


Dato : 17-12-03 09:11

Nicolai Hansen wrote:
> Performance/filstørrelse er en ret god peger

På hvad? Mener du at performance/filstørrelse fortæller noget om resten
af kompileren, f.eks. kompileringstid.

> - selvfølgelig hvis det
> grundliggende er i orden. Jeg tror nu ikke at der er nogen som helst
> forskel mellem MSVC++ og MinGW i "overholdelse af C++ standarden". De
> overholder den med ret stor sandsynlighed begge to 100%.

Ingen af dem overholder standarden 100%. Jeg tror kun af det er Comeau
C++ som kan påstå at de overholder standarden 100%. Den side du henviste
til bruger MSVC 6 som er meget langt fra at overholde standarden. MSVC 7
følger den noget bedre, lige som g++ 3 vist også følger standarden
rimelig godt. Men der er stadig et stykke op til 100%.

Ivan Johansen


Mogens Hansen (17-12-2003)
Kommentar
Fra : Mogens Hansen


Dato : 17-12-03 21:32


"Nicolai Hansen" <nic@aub.dk> wrote in message
news:d96764ff.0312162255.3ef8313e@posting.google.com...
> > Kan du på baggrund af den performance måling forklare os hvordan det
> > understøtter udsagnet om at MinGW "iflg benchmarks markedets suverænt
bedste
> > compiler" ?
>
> Nej - men jeg har læst en del andre benchmarks som, for de flestes
> vedkommende, har givet dette billede. Min egen personlige erfaring med
> BCPPB, MSVC++ og MinGW er den samme som de benchmarks.

Når du kender en del benchmarks der understøtter din påstand er der så nogen
særlig grund til at du netop valgte een som ikke understøttede den ?


Via Google fandt jeg nogle benchmarks, f.eks.:

http://www.yasrt.org/benchmark.html
I de 19 tests var MinGW konsekvent langsommere end Microsoft Visual C++
V6.0, Microsoft Visual C++ V7.0 (.NET Beta 2) og Intel C++ V5.0

http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
Selvom det er en sammenligning mellem Intel C++ og gcc (ikke Microsoft eller
Borland), viser de fleste test at Intel compileren genererer den hurtigste
kode (somme tider _meget_ hurtigere) og sommetider genererer gcc lidt
hurtigere programmer.

http://www.cr0.net:8040/code/crypto/aesbench/
I nogle test generer gcc hurtigere programmer end Microsoft.
I gennemsnit generer Microsoft compileren hurtigere programmer end gcc.
I alle test generer Intel compileren den hurtigste kode.
Bemærk at Microsoft compileren er væsentligt ældre end gcc


Jeg var ude af stand til at finde een benchmark, der indikerer at MinGW bare
nogenlunde konsekvent genererer kode der kører hurtigere end Microsoft
Visual C++ compileren.
Jeg var ude af stand til at finde noget der tilnærmelsesvis kan
retfærdiggøre dit udsagn om "iflg benchmarks markedets suverænt bedste
compiler" - ihvertfald hvis man alene kigger på køretids performance er det
oversatte program.

>
> > Bemærk at performance af det genererede program blot er een af mange
> > kvalitets parametre for en compiler.
>
> Performance/filstørrelse er en ret god peger - selvfølgelig hvis det
> grundliggende er i orden. Jeg tror nu ikke at der er nogen som helst
> forskel mellem MSVC++ og MinGW i "overholdelse af C++ standarden". De
> overholder den med ret stor sandsynlighed begge to 100%.

Det er ikke tilfældet.
Kun een C++ compiler påståes at overholde C++ Standarden 100 % (Comeau).

Der er adskellige steder hvor såvel nyeste Microsoft (.NET 2003) som nyeste
gcc (3.3) ikke er 100 % compliant i forhold til C++ standarden (f.eks.
two-phase lookup).
For begge gælder det dog at de er vældigt gode til overholdelse af C++
sprogstandarden - bedre end deres forgængere.

Se eventuelt beskrivelserne af hvad de siger kommer i næste version
(Microsoft Whidbey og gcc 3.4) hvis du er i tvivl.
Se også
http://boost.sourceforge.net/regression-logs/
for et eksempel på forskelle der faktisk spiller en rolle, hvis du skulle
være i tvivl.
(Vigtigt: Boost er _ikke_ en comformance test, og den der scorer højest er
ikke nødvendigvis den mest conformant.)

For de 2 compilere som benchmarken du henviste til testede (Microsoft Visual
C++ V6.0 og gcc 2.95) gælder det at der var væsentlige afgivelse fra C++
standarden, som faktisk spiller en rolle for almindelige simple programmer
(Se eventuelt source koden til bogen "Accelerated C++" hvis du er i tvivl -
www.acceleratedcpp.com).
Især har Microsoft Visual C++ V6.0 urimelig dårlig overholdelse af C++
standarden.
Selvom det er et udsagn som visse brugere i sin tid openerede kraftigt imod,
anser jeg det for et objektivt faktum (et synspunkt som iøvrigt deles af
folk i Microsoft Visual C++ udviklingsteamet som jeg har talt med eller hørt
tale om det - 2 af arkitekterne og 1 der laver front-enden).
gcc 2.95 havde f.eks. en gammel (ikke template baseret) implementering af
iostream biblioteket.


[8<8<8<]
> Men jeg vil pointere at det er min helt personlige, ganske subjektive,
> mening.

Netop - din personlige mening er naturligvis glimrende at høre.
Men med udsagnet "iflg benchmarks markedets suverænt bedste compiler" får du
det til at fremstå som en objektiv sandhed, hvilket det naturligvis ikke er
(og ikke kan være).

Venlig hilsen

Mogens Hansen



Klaus Petersen (17-12-2003)
Kommentar
Fra : Klaus Petersen


Dato : 17-12-03 21:58

> <snip><omfattende argumentation der konkluderer at msvc7 compileren
generelt er den bedste></snip>

Kan man få msvc7 compileren til at compile programmer til linux?

Hvis ikke er den ubrugelig til mit formål.



Mogens Hansen (17-12-2003)
Kommentar
Fra : Mogens Hansen


Dato : 17-12-03 22:37


"Klaus Petersen" <spectual2@getTOnet.dk> wrote:
> > <snip><omfattende argumentation der konkluderer at msvc7 compileren
> generelt er den bedste></snip>

Hvorfra får du opfattelsen af at jeg (dit indlæg er follow-up til mit)
konkluderer at MSVC 7 compileren generelt er den bedste ?
I relation til Microsoft's compilere omtaler jeg V6 og V7.1.
Jeg konkluderer ikke at nogen som helst compiler generelt er den bedste -
netop fordi sådan en konklusion ikke kan drages.


> Kan man få msvc7 compileren til at compile programmer til linux?
>
> Hvis ikke er den ubrugelig til mit formål.

Så brug en anden - der er heldigvis adskellige gode bud at vælge mellem.
(Jeg skal nok undlade at bemærke at du i det oprindelige indlæg nævnte at du
bruger Visual Studio 6.0)

Venlig hilsen

Mogens Hansen



Klaus Petersen (18-12-2003)
Kommentar
Fra : Klaus Petersen


Dato : 18-12-03 23:42


> Hvorfra får du opfattelsen af at jeg (dit indlæg er follow-up til mit)
> konkluderer at MSVC 7 compileren generelt er den bedste ?
> I relation til Microsoft's compilere omtaler jeg V6 og V7.1.
> Jeg konkluderer ikke at nogen som helst compiler generelt er den bedste -
> netop fordi sådan en konklusion ikke kan drages.

Jo bevares... men et eller andet skulle jeg skrive mellem min <snip> og
</snip>.

> > Kan man få msvc7 compileren til at compile programmer til linux?
> >
> > Hvis ikke er den ubrugelig til mit formål.

> Så brug en anden - der er heldigvis adskellige gode bud at vælge mellem.

.... var det så et nej?.... :o}

> (Jeg skal nok undlade at bemærke at du i det oprindelige indlæg nævnte at
du
> bruger Visual Studio 6.0)

Ja ... det kommer sig af at jeg skal lege med apache på en linux platform,
men da jeg endnu ikke har opsat maskinen, der skal køre det, bruger jeg
"ventetiden" til at lege med apache på en windows platform.

Koden er i store dele det samme om man kører den på windows eller linux.



Nicolai Hansen (19-12-2003)
Kommentar
Fra : Nicolai Hansen


Dato : 19-12-03 08:45

> > > Kan man få msvc7 compileren til at compile programmer til linux?
> > >
> > > Hvis ikke er den ubrugelig til mit formål.
>
> > Så brug en anden - der er heldigvis adskellige gode bud at vælge mellem.
>
> ... var det så et nej?.... :o}

Det ligger lidt i navnet ;) "MS"="Microsoft" ... Ville de mon
nogensinde lave noget til Linux? (ok, jeg tar den i mig igen, hvis der
er penge at tjene ku de jo nok finde på det)

> Ja ... det kommer sig af at jeg skal lege med apache på en linux platform,
> men da jeg endnu ikke har opsat maskinen, der skal køre det, bruger jeg
> "ventetiden" til at lege med apache på en windows platform.
>
> Koden er i store dele det samme om man kører den på windows eller linux.

Jeg kompilerede min apache på linux ved at skrive "make" og håbe det
bedste ;)
(ja, den kører :p)

Mogens Hansen (19-12-2003)
Kommentar
Fra : Mogens Hansen


Dato : 19-12-03 16:48


"Klaus Petersen" <spectual2@getTOnet.dk> wrote:

>
> > Hvorfra får du opfattelsen af at jeg (dit indlæg er follow-up til
> > mit) konkluderer at MSVC 7 compileren generelt er den bedste ? I
> > relation til Microsoft's compilere omtaler jeg V6 og V7.1. Jeg
> > konkluderer ikke at nogen som helst compiler generelt er den bedste
> > - netop fordi sådan en konklusion ikke kan drages.
>
> Jo bevares... men et eller andet skulle jeg skrive mellem min <snip>
> og </snip>.

Mit væsentligste punkt var at jeg ikke konkluderede hvilken compiler der var
bedst.
Så lige for at understrege det endnu en gang:
Den generelt bedste C++ compiler findes ikke.
Ud fra et sæt af krav (f.eks. platform understøttelse, processor
understøttelse) og prioriteringer (f.eks. performance af genereret kode,
kodestørrelse, programmør produktivitet, pris) er det muligt at vurdere
compilere i forhold til hinanden.


[8<8<8<]
> Koden er i store dele det samme om man kører den på windows eller
> linux.

Nemlig - og det er væsentligt.
Du burde derfor kunne bruge en compiler fra en leverandør (f.eks. Microsoft)
på MS-Windows og en compiler fra en helt anden leverandør (f.eks. GNU) på
Linux, hvis man finder det optimalt. Man kan også vælge at bruge samme
leverandør på begge platforme (f.eks. GNU eller Intel).

Det spiller ikke den store rolle, og valget kan ændre sig over tid.

Venlig hilsen

Mogens Hansen



Klaus Petersen (19-12-2003)
Kommentar
Fra : Klaus Petersen


Dato : 19-12-03 17:58

> Du burde derfor kunne bruge en compiler fra en leverandør (f.eks.
Microsoft)
> på MS-Windows og en compiler fra en helt anden leverandør (f.eks. GNU) på
> Linux, hvis man finder det optimalt. Man kan også vælge at bruge samme
> leverandør på begge platforme (f.eks. GNU eller Intel).
>
> Det spiller ikke den store rolle, og valget kan ændre sig over tid.

Ja præcis. Og inden jeg har hittet ud af hvordan apache hænger sammen er der
nok kommet en compiler mere til linux



Per Abrahamsen (18-12-2003)
Kommentar
Fra : Per Abrahamsen


Dato : 18-12-03 18:04

nic@aub.dk (Nicolai Hansen) writes:

> Nej - men jeg har læst en del andre benchmarks som, for de flestes
> vedkommende, har givet dette billede. Min egen personlige erfaring med
> BCPPB, MSVC++ og MinGW er den samme som de benchmarks.

Sjovt nok producerer MinGW også den hurtigste kode af (Borland, Intel,
GNU og Microsoft) for mit program. Men det er altså en undtagelse,
næsten alle andre jeg er stødt på finder at Intel er vinderen.

Det er sådan set heller ikke overraskende, det er en generel trend at
producenten af CPU'en også har den compiler der producerer den
hurtigste kode. I hvert fald for CPU'er der bliver solgt på
hastighed. Det er ikke så overraskende, CPU og compiler er ofte
udviklet "sammen", og hastighed af genereret kode er normalt den
vigtigste parameter for CPU-leverandør-compilere

For GNU, Borland og Microsoft er der mange andre parametre der er
vigtigere. For GNU er portabilitet vigtigst, for Borland og Microsoft
er "programmer productivity" vigtigst.

Søg
Reklame
Statistik
Spørgsmål : 177580
Tips : 31968
Nyheder : 719565
Indlæg : 6409081
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste