[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [CPROG] andre compilere end g++ ???



On Sun, Jan 26, 2003 at 12:13:22AM +0100, Marc Cromme wrote:
> Jeg har hørt/set et rygte et -eller andet sted - mon ikke deres egen
> webserver?? at de nu ønsker at bruge STLport som STL-implementering, så
> det kan vel bruges i frentiden. 
Tjoo... Jeg mener også at vi har forsøgt os med STLport på Windows
(fordi MSVC's STL implementation sutter). Vi havde nogle få problemer
med den, men alt i alt var det et ret godt.

> Men hvis compileren ikke er så fint, specielt på template-området, vil
> jeg aligeved ikke bruge den. Ved du noget om det ??
Jeg tror som sådan ikke at den har nogle problemer med templates. Det er
vi ihvertfald ikke stødt på den gang vi forsøgte at bruge den. Nu var
det ikke hele vores projekt vi forsøgte at oversætte, men kun små dele,
og dem åd dem, uden andre problemer end dem vi havde med STL
implementationen. Så det var positivt.

> Ideen er jo netop at prøve på at skrive porterbar kode, idet jeg ikke kan
> gå ud fra at alle der ønsker at køre den kan få deres administrator til at
> installere en GNU g++ - en slags service til brugerne. 
Uhha... Det er ikke specielt let at skrive porterbar C++ kode. Mest
fordi der er så mange ting der skal gå godt. Primært fordi der er så
stor forskel på STL implementationerne. Et andet problem er også hvor
god compileren er til namespaces. Tag f.eks. flg. kode:

void func() 
{
	mynamespace::type_t t;
	some_function(t);
}

Her skal compileren både lede efter some_function i :: namespacet, og i
mynamespace. Det er der ret stor forskel på hvor gode de forskellige
compilere er til. F.eks. er GCC ekstremt god til det (faktisk mistænker
jeg den for at være for god til det), og MSVC stinker til det. Intels
ligger sig et sted imellem :-)

> I øvrigt lærte jeg
> ved denne øvelse at G++ 3.2 rigtig nok er en fin compiler, men den lader
> nogle ting smutte igennem som for eksempel den native dec alpha brokker sig
> over - så det at bruge flere compilere under udviklingsforløbet hjælper
> med at skrive ANSI C++ (eller, hvis man bruger de forkerte compilere, et
> meget lille subset af ANSI C++ - det er ikke så smart...) 
Du kan få GCC til at være meget hidsig med fejlbeskeder og warnings.
F.eks. hvis du oversætte din kode med -ansi, så er du et stykke af
vejen. Hvis du så også bruger -pedantic, så giver den dig mange
fejlbeskeder, som ellers slipper igennem... Derudover er der ting som
uinitialiserede variable osv. som compileren kun opdager hvis du
kompilerer med -O osv.

> Men det er nu noget besværligt altid at hoppe platform, bare for at bruge
> en anden compiler, selvom jeg bruger autoconf-automake og cvs. Det nemmer
> min udviklingscyklus hvis jeg kan skrive noget kode , kompilere med den
> ene, kompilere med den anden, og checke ind bagefter, når det gik godt.
Løsningen på det er at lave et automatiseret build system. 

Det vi har gjort, er at vi har hele vores projekt i CVS. I gamle dage,
da projektet ikke var så stort, satte vi et build igang ved CVS-commit,
hvis der ikke allerede kørte et. Dvs. vi lavede en lille fil på et
NFS-share, som alle vores build maskiner så stod og pollede efter vha.
cron. Det virker ret godt, specielt fordi man meget hurtigt fik besked
om fejl osv, når man comittede ny kode... Ulæmpen er naturligvis at man
skal have lige så mange maskiner stående som man vil kompilere til :-)

-- 
/-----------------------------------------------------\
| Klaus S. Madsen      | "Failure is not an option... |
| ICQ: 45400164        |  It comes bundled with your  |
| www.hjernemadsen.org |  Microsoft products!"        |
\-----------------------------------------------------/


 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 20:09 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *