---

En lille reklame: Boost (www.boost.org) har lige udgivet deres seneste
samling af libraries, der nu også omfatter et såkaldt lambda library.

For alle der har bøvlet med STL algoritmer og functors er det simpelt-
hen kræs. Se bare her:

int main() {
list<int> l;

l.push_back(0);
l.push_back(2);
l.push_back(4);

// Med STL - jeg vil godt udlove en øl til alle, der skal
// bruge mindre end 10 sekunder om at regne ud, hvad der
// søges efter her.
//
cout << *find_if(l.begin(), l.end(), bind1st(less_equal<int>(), 2))
<< endl;

// Med Lambda librariet - jeg vil godt udlove en øl til
// alle, der skal bruge mere end 10 sekunder om at regne
// ud, hvad der søges efter her.
//
cout << *find_if(l.begin(), l.end(), _1 >= 2) << endl;
}

De performance-målinger jeg indtil nu har prøvet med gcc 3.x viser, at
der _ikke_ er noget overhead som følge af at bruge lambda librariet.
Hverken i forhold til selv at skrive al koden i hånden eller i forhold
til STL udgaven.

Fryd !

-Claus

---

Er den samtidig blevet VC kompatibel?

> En lille reklame: Boost (www.boost.org) har lige udgivet deres seneste
> samling af libraries, der nu også omfatter et såkaldt lambda library.

---

"Rasmus Kaae" <macaw@WHATEVERMAKESYOUHAPPYhotmail.com> wrote

> Er den samtidig blevet VC kompatibel?
>

Var det ikke rimeligt at stille det modsatte spørgsmål ?
Altså, "Er VC blevet kompatibel med BLL ?".
Et positivt svar (for enhver compiler) vil have endnu mere nyttige
konsekvenser.

Ifølge dokumentationen
(http://www.boost.org/libs/lambda/doc/ar01s07.html#id2808094) , virker det
med
* GCC 3.0.4
* KCC 4.0f with EDG 2.43.1
* GCC 2.96 (fails with one test case, the exception_test.cpp results in an
internal compiler error. )

Ifølge tidligere dokumentation
(http://lambda.cs.utu.fi/supported_compilers.html), har
* MS Visual C++ 6.0 sp3
* Intel C++ 4.5
* Metroworks IDE 4.0 build 0356
fundamentale problemer, så de ikke kan bruges

Venlig hilsen

Mogens Hansen

---

> Var det ikke rimeligt at stille det modsatte spørgsmål ?
> Altså, "Er VC blevet kompatibel med BLL ?".
> Et positivt svar (for enhver compiler) vil have endnu mere nyttige
> konsekvenser.

Meget muligt, men jeg ser ikke det store problem i at bruge dinkum ware frem
for boost, det var mest i relation til denne "reklame".

> Ifølge dokumentationen
> (http://www.boost.org/libs/lambda/doc/ar01s07.html#id2808094) , virker det
> med
> * GCC 3.0.4
> * KCC 4.0f with EDG 2.43.1
> * GCC 2.96 (fails with one test case, the exception_test.cpp results in
an
> internal compiler error. )

Hvilket vil sige at de hovedsagligt satser på opensource-agtige miljøer

> Ifølge tidligere dokumentation
> (http://lambda.cs.utu.fi/supported_compilers.html), har
> * MS Visual C++ 6.0 sp3
> * Intel C++ 4.5
> * Metroworks IDE 4.0 build 0356
> fundamentale problemer, så de ikke kan bruges

det er vel ikke decideret kompilerne der har problemer, de har bare undladt
at understøtte de features af C++ som boost udnytter.

---

"Rasmus Kaae" <macaw@WHATEVERMAKESYOUHAPPYhotmail.com> writes:

> > Var det ikke rimeligt at stille det modsatte spørgsmål ?
> > Altså, "Er VC blevet kompatibel med BLL ?".
> > Et positivt svar (for enhver compiler) vil have endnu mere nyttige
> > konsekvenser.
>
> Meget muligt, men jeg ser ikke det store problem i at bruge dinkum ware frem
> for boost, det var mest i relation til denne "reklame".

Det er det måske ikke for dig, men hvis det lambda bibliotek nu virker
så fint, som det ser ud til i det eksempel der blev givet, så er det da
absolut ikke noget at kimse af.

En nybegynder vil da have meget lettere ved at forstå hvad det betyder..

>
> > Ifølge dokumentationen
> > (http://www.boost.org/libs/lambda/doc/ar01s07.html#id2808094) , virker det
> > med
> > * GCC 3.0.4
> > * KCC 4.0f with EDG 2.43.1
> > * GCC 2.96 (fails with one test case, the exception_test.cpp results in
> an
> > internal compiler error. )
>
> Hvilket vil sige at de hovedsagligt satser på opensource-agtige miljøer

Vås!

boost satser ikke på nogen som helst platforme/miljøer, men på c++.

KCC, er da vist også en fuldt kommerciel oversætter..


mvh
Jonas Meyer Rasmussen

---

Jonas Meyer Rasmussen wrote:
> "Rasmus Kaae" <macaw@WHATEVERMAKESYOUHAPPYhotmail.com> writes:
>
>
> Vås!
>
> boost satser ikke på nogen som helst platforme/miljøer, men på c++.
>
> KCC, er da vist også en fuldt kommerciel oversætter..
>

Yep, nok en af de allerdyreste (og bedste).

/David

---

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
> Jonas Meyer Rasmussen wrote:

> >
> > KCC, er da vist også en fuldt kommerciel oversætter..
> >
>
> Yep, nok en af de allerdyreste (og bedste).
>

Det er KAI compileren ?
Den blev købt af Intel, og bliver lavet mere :(
Se http://www.intel.com/software/products/kcc/public_support.htm

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote

> Den blev købt af Intel, og bliver lavet mere :(

Der skulle naturligvis har stået "..., og bliver _ikke_ lavet mere :("

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> "Mogens Hansen" <mogens_h@dk-online.dk> wrote
>
>
>>Den blev købt af Intel, og bliver lavet mere :(
>
>
> Der skulle naturligvis har stået "..., og bliver _ikke_ lavet mere :("
>

Yep. Det vidste jeg egentligt godt :)

Det _var_ en af de bedste compilere. Men der sker en opblomstring for
øjeblikket. Om et år eller to vil vi have væsentligt bedre C++
compilere. Dels hvad angår frontends men også backends, selvom det egt.
ikke har noget med C++ at gøre. Der er bare mange af de teknologier som
kun har eksisteret i dyre industrial strength compilere før, der er
begyndt at sive ned i billigere, og endda gratis og/eller frie compilere.

/David

---

> > Hvilket vil sige at de hovedsagligt satser på opensource-agtige miljøer

>
> Vås!
>
> boost satser ikke på nogen som helst platforme/miljøer, men på c++.
>
> KCC, er da vist også en fuldt kommerciel oversætter..

Alle de virksomheder jeg har været i kontakt med gennem mit arbejde som
programmør har udelukkende anvendt MS Visual C++ til deres C++ projekter.
KCC er muligvis en bedre / anderledes kompiler men har ikke været tilstede i
de virksomheder jeg har arbejdet for.

---

Rasmus Kaae wrote:
>
>
> Alle de virksomheder jeg har været i kontakt med gennem mit arbejde som
> programmør har udelukkende anvendt MS Visual C++ til deres C++ projekter.
> KCC er muligvis en bedre / anderledes kompiler men har ikke været tilstede i
> de virksomheder jeg har arbejdet for.
>
>

Det siger mere om de virksomheder end noget andet.

/David

---

> > Alle de virksomheder jeg har været i kontakt med gennem mit arbejde som
> > programmør har udelukkende anvendt MS Visual C++ til deres C++
projekter.
> > KCC er muligvis en bedre / anderledes kompiler men har ikke været
tilstede i
> > de virksomheder jeg har arbejdet for.

> Det siger mere om de virksomheder end noget andet.

Hvad mener du? At det er forkert af dem at satse på den markedsførende
compiler til windows-platformen?

---

Rasmus Kaae wrote:
>>>Alle de virksomheder jeg har været i kontakt med gennem mit arbejde som
>>>programmør har udelukkende anvendt MS Visual C++ til deres C++
>>
> projekter.
>
>>>KCC er muligvis en bedre / anderledes kompiler men har ikke været
>>
> tilstede i
>
>>>de virksomheder jeg har arbejdet for.
>>
>
>>Det siger mere om de virksomheder end noget andet.
>
>
> Hvad mener du? At det er forkert af dem at satse på den markedsførende
> compiler til windows-platformen?
>
>

Hvad mener du med "markedsførende"? Det betyder normalt at man
markedsfører noget, altså, reklamere for det. Jeg går ud fra at du mener
den compiler til Windows som der er solgt flest af, eller lignende. I
så fald, ja, det er forkert af dem at satse på den. Der er væsentligt
bedre compilere til Windows. Hvis man kræver kompatibilitet med
Microsoft's compiler kan man endda vælge Intel's compiler, som genererer
bedre kode, giver bedre fejlmeddelelser, og er væsentligt mere compliant
med standarden. Under alle omstændigheder er det ikke et C++ projekt,
hvis det kræver en MS-kompatibel compiler. For det er ikke C++ de har
implementeret. Det er C++ minus en masse plus en masse andet.

Og hvis det ikke lige er fordi man skal bruge en MS-kompatibel compiler,
er det endnu flere, og væsentligt bedre compilere til rådighed. Så ja,
jeg vil mene det er forkert at vælge Microsofts compiler, uanset om den
er førende på markedet eller ej.

/David

---

> Hvad mener du med "markedsførende"? Det betyder normalt at man
> markedsfører noget, altså, reklamere for det. Jeg går ud fra at du mener
> den compiler til Windows som der er solgt flest af, eller lignende. I
> så fald, ja, det er forkert af dem at satse på den. Der er væsentligt
> bedre compilere til Windows. Hvis man kræver kompatibilitet med
> Microsoft's compiler kan man endda vælge Intel's compiler, som genererer
> bedre kode, giver bedre fejlmeddelelser, og er væsentligt mere compliant
> med standarden. Under alle omstændigheder er det ikke et C++ projekt,
> hvis det kræver en MS-kompatibel compiler. For det er ikke C++ de har
> implementeret. Det er C++ minus en masse plus en masse andet.

(Slå ordet markedsførende op hvis du er i tvivl - lad være med at "svine"
andre til pgra. din uvidenhed).

Du mener så personligt, at den mest solgte windows compiler ikke er værd at
satse på for en virksomhed? Men at virksomheden istedet skal investere tid
(og dermed penge) i at finde den helt geniale løsning?
Mht. Intel C++ så er det jo bare en compiler, dvs. der mangler alt udenoms
miljø som følger med MS VC++

> Og hvis det ikke lige er fordi man skal bruge en MS-kompatibel compiler,
> er det endnu flere, og væsentligt bedre compilere til rådighed. Så ja,
> jeg vil mene det er forkert at vælge Microsofts compiler, uanset om den
> er førende på markedet eller ej.

---

"Rasmus Kaae" <macaw@WHATEVERMAKESYOUHAPPYhotmail.com> wrote

> Mht. Intel C++ så er det jo bare en compiler, dvs. der mangler alt udenoms
> miljø som følger med MS VC++

Har du selv prøvet Intel C++ for Windows ?
Jeg har en licens og bruger den jævnligt.

Hvis du har prøvet Intel C++ for Windows, vil du se at den integrerer
fuldstændigt med Visual C++ V6, men erstatter "blot" selve Microsoft
compileren, hvilket klart er en forbedring. Udviklingsmiljø, debugger
biblioteker etc. er uændret.
Det betyder naturligvis at man _både_ skal have Visual C++ V6 _og_ Intel C++
for Windows.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:3cea2da2$1@lxcs1.manbw.dk...
>
> "Rasmus Kaae" <macaw@WHATEVERMAKESYOUHAPPYhotmail.com> wrote
>
> > Mht. Intel C++ så er det jo bare en compiler, dvs. der mangler alt
udenoms
> > miljø som følger med MS VC++
>
> Har du selv prøvet Intel C++ for Windows ?
> Jeg har en licens og bruger den jævnligt.

Jeg har prøvet evalueringsversionen og vurderede at det til mine egne
projekter ikek var nødvendigt at investere i den.

> Hvis du har prøvet Intel C++ for Windows, vil du se at den integrerer
> fuldstændigt med Visual C++ V6, men erstatter "blot" selve Microsoft
> compileren, hvilket klart er en forbedring. Udviklingsmiljø, debugger
> biblioteker etc. er uændret.
> Det betyder naturligvis at man _både_ skal have Visual C++ V6 _og_ Intel
C++
> for Windows.

---

"David Rasmussen" <pinkfloydhomer@yahoo.com> wrote

> Og hvis det ikke lige er fordi man skal bruge en MS-kompatibel compiler,
> er det endnu flere, og væsentligt bedre compilere til rådighed. Så ja,
> jeg vil mene det er forkert at vælge Microsofts compiler, uanset om den
> er førende på markedet eller ej.
>

Det er min erfaring, at det gør en væsentlig forskel hvordan man tænker på
sit projekt og sig selv.

Tag 2 grupper af udsagn:
* "Det er et MS-Windows program, som er udviklet med C++"
* "Det er en COM komponent, som er udviklet med C++"
* "Jeg er MS-Windows programmør, som anvender C++"

i forhold til

* "Det er et C++ program, der skal køre under MS-Windows"
* "Det er funktionalitet implementeret i C++, og stillet til rådighed for
andre sprog via COM"
* "Jeg er C++ programmør, der udvikler under MS-Windows"

(Oven i det kommer naturligvis kommer naturligvis andre udsagn såsom "Det er
et <skriv dit applikationsdomæne her> program", der skal puttes ind i
prioritetsrækkefølgen.)

Hvis man mest kan kende sig selv og sin hverdag i den øverste gruppe af
udsagn, er det væsentligt nemmere at vælge af bruge Microsoft Visual C++ på
godt og ondt.
Det er min opfattelse, at man slipper for mange bekymringer og meget tvivl,
hvis man mest kan kende sig selv i den første gruppe.

Venlig hilsen

Mogens Hansen

---

Rasmus Kaae wrote:

>> Ifølge dokumentationen
>> (http://www.boost.org/libs/lambda/doc/ar01s07.html#id2808094) , virker
>> det med
>> * GCC 3.0.4
>> * KCC 4.0f with EDG 2.43.1
>> * GCC 2.96 (fails with one test case, the exception_test.cpp results in
> an
>> internal compiler error. )
>
> Hvilket vil sige at de hovedsagligt satser på opensource-agtige miljøer
>

Vrøvl. Boost satser på, at compilerne overholder standarden og forsøger
at lave work-arounds for de compilere, der ikke gør. At boost virker så
godt med GCC sammenlignet med VC siger EMM mere om Microsofts commitment
til standarden end om boost evt. preferencer for open-source miljøer.

Faktisk er det min opfattelse, at de fleste boost folk arbejder på Windows
platformen til daglig (men nok ikke med VC, hvis de kan slippe). Filerne
hedder f.eks alle .hpp eller .cpp til efternavn.


>> Ifølge tidligere dokumentation
>> (http://lambda.cs.utu.fi/supported_compilers.html), har
>> * MS Visual C++ 6.0 sp3
>> * Intel C++ 4.5
>> * Metroworks IDE 4.0 build 0356
>> fundamentale problemer, så de ikke kan bruges
>
> det er vel ikke decideret kompilerne der har problemer, de har bare
> undladt at understøtte de features af C++ som boost udnytter.

De har undladt at understøtte de features, der findes i standarden.

Jeg kan tilføje, at den nyeste version af EDG front-enden, der findes
i en beta-udgave af Comeaus compiler nu understøtter standarden 100%.

EDG er et lille 5 personers firma mens Microsoft har titusindevis. Så
når Microsofts VC ikke kan levere varen er det simpelthen fordi, at
Microsoft har _valgt_ ikke at understøtte standarden.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote
>
> EDG er et lille 5 personers firma mens Microsoft har titusindevis.

EDG er 3 personer:
Steve Adamczyk
John Spicer
Daveed Vandevoorde
Se f.eks. http://www.vandevoorde.com/Resume/
De 3 laver samtidig en Java front-end og så vidt jeg husker en Cobol
front-end. Det er imponerende.

Man skal nok _ikke_ forvente at der er størrelsesordener flere hos Microsoft
der arbejder med front-enden i Microsoft Visual C++.

Der arbejdede ca. 200 mand totalt (udvikling, test, dokumentation etc.) på
udviklingen af Visual C++ V1.0 ifølge bogen
Dynamics of Software Development
Jim McCarthy
ISBN 1-55615-823-8
Microsoft Press, 1995

Jim McCarthy var en af lederne hos Microsoft i forbindelse med udviklingen
af Visual C++ V1.0
Iøvrigt en glimrende og spændende bog, både ud fra et projektledelses
synspunkt og fra et C++ arkæologisk synspunkt.

> Så
> når Microsofts VC ikke kan levere varen er det simpelthen fordi, at
> Microsoft har _valgt_ ikke at understøtte standarden.

Enig.
Noget tyder dog på at de i næste version har _valgt_ at understøtte C++
Standarden langt bedre (det følger fint i tråd med at V7 er langt bedre end
V6 med hensyn til overholdelse af C++ Standarden).
Bl.a. siger Microsoft at de uden problemer vil kunne oversætte Boost og
Loki.
Sjovt nok _tror_ jeg for en gang skyld på Microsoft.
Men lad os nu vente og se hvad og hvornår de faktisk leverer varen.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

[snip spændende læsning om EDG]

>> Så
>> når Microsofts VC ikke kan levere varen er det simpelthen fordi, at
>> Microsoft har _valgt_ ikke at understøtte standarden.
>
> Enig.
> Noget tyder dog på at de i næste version har _valgt_ at understøtte C++
> Standarden langt bedre (det følger fint i tråd med at V7 er langt bedre
> end V6 med hensyn til overholdelse af C++ Standarden).
> Bl.a. siger Microsoft at de uden problemer vil kunne oversætte Boost og
> Loki.
> Sjovt nok _tror_ jeg for en gang skyld på Microsoft.

Det gør jeg faktisk også: De har lige ansat Stan Lipmann og... øh... ham
med "Guru Question of the Week" på comp.lang.c++.moderated . De skal nok
ikke arbejde med selve kompileren, men ansættelsen af to standarddrenge
tyder på, at de i fremtiden har tænkt sig at gøre noget ved deres support
af C++.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ac5gnh$gng$1@sunsite.dk...
> Mogens Hansen wrote:
>
> Det gør jeg faktisk også: De har lige ansat Stan Lipmann og... øh... ham
> med "Guru Question of the Week" på comp.lang.c++.moderated .

Netop:
Stan Lipmann er arkitekt på Visual C++ compileren
Herb Sutter er C++ Community Liason

Jeg hørte for en måned siden de 2 samtidigt "stå skoleret" (på en pæn måde),
overfor nogle hundrede personer (blandt dem en lang række prominete C++
personer som Bjarne Stroustrup, Andrei Alexandrescu, Jim Coplien, Nico
Jusitto, Dietmar Kuhl etc.), for hvorfor de havde valgt at arbejde for
Microsoft, og hvad de forventede at udrette. Franciss Glassborow ledte
"slaget". Det lød troværdigt.
Ved samme lejlighed (ACCU Spring Conference 2002, se www.accu.org) talte jeg
med Herb Sutter og med en af dem der laver C++ front-enden i Visual C++.
Det er derfra jeg har min _tro_ på at Microsoft er mere indstillet på at
understøtte C++ Standarden seriøst.
Tænkt hvis man kan tage de gode egenskaber fra Microsoft Visual C++ (f.eks.
god performance i den generede kode, stor stabilitet) og kombinere det med
en god C++ implementering.
Det vil oprigtigt glæde mig, for jeg har altid ment at så stort et firma som
Microsoft har et moralsk ansvar (ja, ja - jeg _er_ naiv), for som Pipi
Langstrømpe siger: "Den der er vældig stærk skal også være vældig rar".

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> "Claus Rasmussen" <clr@cc-consult.dk> wrote in message
>
>> Mogens Hansen wrote:
>>
>> Det gør jeg faktisk også: De har lige ansat Stan Lipmann og... øh... ham
>> med "Guru Question of the Week" på comp.lang.c++.moderated .
>
> Netop:
> Stan Lipmann er arkitekt på Visual C++ compileren
> Herb Sutter er C++ Community Liason
>
> Jeg hørte for en måned siden de 2 samtidigt "stå skoleret" (på en pæn
> måde), overfor nogle hundrede personer (blandt dem en lang række prominete
> C++ personer som Bjarne Stroustrup, Andrei Alexandrescu, Jim Coplien, Nico
> Jusitto, Dietmar Kuhl etc.), for hvorfor de havde valgt at arbejde for
> Microsoft, og hvad de forventede at udrette. Franciss Glassborow ledte
> "slaget". Det lød troværdigt.

Det gad jeg godt have hørt. Dvs. jeg har hørt lidt af ekkoet fra den debat,
og mit indtryk svarer til dit: At Microsoft nu faktisk ser ud til at mene
det.


> Ved samme lejlighed (ACCU Spring Conference 2002, se www.accu.org) talte
> jeg med Herb Sutter og med en af dem der laver C++ front-enden i Visual
> C++. Det er derfra jeg har min _tro_ på at Microsoft er mere indstillet på
> at understøtte C++ Standarden seriøst.
> Tænkt hvis man kan tage de gode egenskaber fra Microsoft Visual C++
> (f.eks. god performance i den generede kode, stor stabilitet) og kombinere
> det med en god C++ implementering.

Som linux bruger er jeg lidt ligeglad. Bortset fra, at Microsoft har så
stor en markedsandel at VC bliver dén laveste fællesnævner man ikke har
råd til at ignorere, hvilket så igen betyder at alle holder sig tilbage
med at udnytte faciliteter i C++, der ikke er understøttet af VC - bort-
set fra Boost selvfølgelig

(det må sgu' da osse være pinligt, at et open-source produkt som GCC slår
Microsoft helt af banen når det handler om at opfylde standarden).


> Det vil oprigtigt glæde mig, for jeg har altid ment at så stort et firma
> som Microsoft har et moralsk ansvar (ja, ja - jeg _er_ naiv), for som Pipi
> Langstrømpe siger: "Den der er vældig stærk skal også være vældig rar".

Pippi er meget, meget klog (og stærk)

-Claus

---

"Rasmus Kaae" <macaw@WHATEVERMAKESYOUHAPPYhotmail.com> wrote

> > Var det ikke rimeligt at stille det modsatte spørgsmål ?
> > Altså, "Er VC blevet kompatibel med BLL ?".
> > Et positivt svar (for enhver compiler) vil have endnu mere nyttige
> > konsekvenser.
>
> Meget muligt, men jeg ser ikke det store problem i at bruge dinkum ware
frem
> for boost, det var mest i relation til denne "reklame".
>

Det forekommer mig at du roder lidt rundt i forholdet mellem Dinkum og
boost.
Man kan ikke "bruge Dinkum frem for boost".

C++ er en specifikation (præcist ISO/IEC 14882:1998).
Man kan opfatte den som 2 dele: Core Language og Standard Library.

Dinkum er leverandør af biblioteker der (ofte tilnærmelsesvis, men så
afgjort seriøst) overholder konkrete specifikationer.
Et sæt af disse biblioteker er de C++ Standard Library implementeringer, der
følger med forskellige versioner af Microsoft Visual C++, og som også
leveres til en række andre C++ compilere.
Dinkum har desuden nogle biblioteker der ligger uden for Standard Library,
men ikke noget der svarer til Boost. Se eventuelt www.dinkum.com.

Et andet bud på en implementering af C++ Standard Library er STLPort (se
www.stlport.org), som f.eks. kan anvendes sammen med Microsoft Visual C++ i
stedet for den Dinkum implementering der følger med.
STLPort indeholder også funktionalitet, der ligger uden for C++ standarden -
f.eks hash-containere.

Boost (se www.boost.org) er _ikke_ en implementering af C++ Standard
Library.
Boost er et bibliotek (eller en samling af biblioteker), der antager at man
fra andet sted har en implementering af C++ specifikationen, som Boost så
bygger ovenpå.
Boost er således en række ekstra funktionalitet til C++.
Boost er generelt moderne C++ biblioteker af høj kvalitet, der er skrevet og
peer-reviewet af meget kvalificerede folk.
Samtidig er det også et bud på nogle ting, der muligvis kan komme med i
næste version af C++ Standarden.

> > Ifølge dokumentationen
> > (http://www.boost.org/libs/lambda/doc/ar01s07.html#id2808094) , virker
det
> > med
> > * GCC 3.0.4
> > * KCC 4.0f with EDG 2.43.1
> > * GCC 2.96 (fails with one test case, the exception_test.cpp results
in
> an
> > internal compiler error. )
>
> Hvilket vil sige at de hovedsagligt satser på opensource-agtige miljøer

>

Nej.
KCC er ikke opensource. Sourcen til EDG er kommercielt tilgængeligt -
formodentlig for et anseeligt beløb.
Boost stiller ofte krav til at C++ compileren indeholder en meget stor del
C++ specifikationen.

> > Ifølge tidligere dokumentation
> > (http://lambda.cs.utu.fi/supported_compilers.html), har
> > * MS Visual C++ 6.0 sp3
> > * Intel C++ 4.5
> > * Metroworks IDE 4.0 build 0356
> > fundamentale problemer, så de ikke kan bruges
>
> det er vel ikke decideret kompilerne der har problemer, de har bare
undladt
> at understøtte de features af C++ som boost udnytter.
>

Det er så afgjort compilerne der har problemer, i og med de ikke
understøtter tilstrækkeligt meget af C++ standarden til at det er muligt at
anvende dem til at oversætte lambda biblioteket.
Såfremt biblioteket alene afhænger af C++ standarden, er det entydigt
compilerens problem, hvis den ikke er i stand til at oversætte biblioteket.
Det kræver naturligvis altid en konkret analyse, at afgøre om det er en fejl
i biblioteket eller i compileren, men der er ingen tvivl om at Lambda
biblioteket har til hensigt kun at afhænge af C++ Standarden, og at det er
meget kompetente personer, der har været involveret i arbejdet.

Venlig hilsen

Mogens Hansen

---

Rasmus Kaae wrote:
>>Var det ikke rimeligt at stille det modsatte spørgsmål ?
>>Altså, "Er VC blevet kompatibel med BLL ?".
>>Et positivt svar (for enhver compiler) vil have endnu mere nyttige
>>konsekvenser.
>
>
> Meget muligt, men jeg ser ikke det store problem i at bruge dinkum ware frem
> for boost, det var mest i relation til denne "reklame".
>

Hvad har dinkumware med boost at gøre? Dinkumware laver et
standarbibliotek, boost er et bibliotek af ting der ikke findes i
standarden, men som folkene bag (hvoraf mange er i C++
standardiseringskomiteen) håber kan komme med ved næste standardisering.

>
>>Ifølge dokumentationen
>>(http://www.boost.org/libs/lambda/doc/ar01s07.html#id2808094) , virker det
>>med
>> * GCC 3.0.4
>> * KCC 4.0f with EDG 2.43.1
>> * GCC 2.96 (fails with one test case, the exception_test.cpp results in
>
> an
>
>>internal compiler error. )
>
>
> Hvilket vil sige at de hovedsagligt satser på opensource-agtige miljøer
>

Nej, det vil sige at de "satser" på compilere hvor de kan få det de
gerne vil have, til at virke. De laver standard-compliant kode, og laver
så nogle workarounds der hvor det ikke er for uoverkommeligt. Det er det
åbenbart med MSVC. Det er ikke boosts skyld. Det er MS' skyld.

>
>>Ifølge tidligere dokumentation
>>(http://lambda.cs.utu.fi/supported_compilers.html), har
>> * MS Visual C++ 6.0 sp3
>> * Intel C++ 4.5
>> * Metroworks IDE 4.0 build 0356
>>fundamentale problemer, så de ikke kan bruges
>
>
> det er vel ikke decideret kompilerne der har problemer, de har bare undladt

Jo.

> at understøtte de features af C++ som boost udnytter.
>
>

Øh, ja, og som er defineret i standarden. Hvis de "bare har undladt at
understøtte de features", så er det da i høj grad compilerenes problem.

/David

---

Rasmus Kaae wrote:
> Er den samtidig blevet VC kompatibel?
>

Du mener, er VC efterhånden blevet så lidt ukompatibel at det er
overkommeligt at få boost til at compile på den?

/David

---

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
in message news:3CE57C9D.9020200@gmx.spam.egg.sausage.and.spam.net...
> Rasmus Kaae wrote:
> > Er den samtidig blevet VC kompatibel?
> >
>
> Du mener, er VC efterhånden blevet så lidt ukompatibel at det er
> overkommeligt at få boost til at compile på den?

Jeg mener om Boost er kompatibel med VC (i den rækkefølge).

---

"Rasmus Kaae" <macaw@WHATEVERMAKESYOUHAPPYhotmail.com> wrote

> "David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net>
wrote
> > Du mener, er VC efterhånden blevet så lidt ukompatibel at det er
> > overkommeligt at få boost til at compile på den?
>
> Jeg mener om Boost er kompatibel med VC (i den rækkefølge).
>

I varierende grad. Se http://www.boost.org/status/cs-win32.html

Venlig hilsen

Mogens Hansen

---

Rasmus Kaae wrote:
> "David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
> in message news:3CE57C9D.9020200@gmx.spam.egg.sausage.and.spam.net...
>
>>Rasmus Kaae wrote:
>>
>>>Er den samtidig blevet VC kompatibel?
>>>
>>
>>Du mener, er VC efterhånden blevet så lidt ukompatibel at det er
>>overkommeligt at få boost til at compile på den?
>
>
> Jeg mener om Boost er kompatibel med VC (i den rækkefølge).
>
>

Boost er jo ikke kompatibel med specifikke compilere, men med C++
sproget som det blev standardiseret i 1998. Hvis en compiler
implementere denne standard, så virker boost. Hvis ikke, så virker det
ikke, men så kan man vel heller ikke kalde det for en C++ compiler.

/David

---

---

"Anders Borum" <ander@diku.dk> wrote

> Jeg har samme erfaring, men det siger vel ikke specielt meget om KCC.
>

Jeg har gennem årene anvendt mange forskellige C++ compilere - primært fordi
forskellige compilere har forskellige egenskaber.

> Personligt ville jeg meget gerne migrere til en anden oversætter, men man
> bliver vænnet til nogle meget lækre detaljer i MSVC. Hvis man benytter sig
> af ActiveX er det fx. utrolig rart (for mig uundværligt) med præprocessor
> direktivet #import.

Da jeg for år tilbage analyserede de sprogudvidelser som Microsoft havde
lavet til Visual C++ for at understøtte COM, nåede jeg frem til at de uden
ulempe var fuldstændigt overflødige een som alle.
Microsoft kunne have implementeret dem på anden måde, som ikke krævede
ændringer af C++ compilerne, til glæde for alle.

F.eks.
#import:
Det hører ikke hjemme i sproget, men i build miljøet: man har en ActiveX
control (eller rettere et typelibrary i en eller anden form), og fra det
skal der laves en header-fil som så kan includeres.

__uuidof:
Kunne være lavet med en mindre updatering af IDL compileren (så den også
sputtede en template specialisering ud), hvis C++ kompileren på det
tidspunkt havde har en tilstrækkelig god C++ template implementering.

_com_ptr_t:
Kunne være lavet som et klassebibliotek - hvilken det også er blevet gjort
mange gange f.eks. i ATL.

Tænk lige over at de overflødige sprogudvidelser som Microsoft indførte for
at gøre COM udvikling nemmere, dels gjorde det umuligt at flytte koden til
andre compilere (selvom Microsoft på et tidspunkt prøvede at implementere
COM på forskellige Unix og Linux systemer) og de i dag er lige så døde som
COM, set i lyset af at .NET er blevet lanceret. Der er så et nyt sæt
sprogudvidelser til .NET, som også er diskutable.

[snip]
> Findes #import til andre oversættere eller kan man få særskilte
> præprocesorer der understøtter det?
>

Formodentligt ikke - og specielt ikke efter .NET er lanceret.
Men prøv at se hvordan andre udviklingsmiljøer løser samme opgave.
Prøv f.eks. at downloade en trial udgave af Borland C++Builder, og se hvad
du syntes om dens måde at håndtere ActiveX controller på.
Det er altid spændende at se hvordan andre har gjort, og danne sin egen
mening om de forskellige mulige løsninger.

Venlig hilsen

Mogens Hansen

---

---

"Anders Borum" <ander@diku.dk> wrote

>
> Er det ikke hårdt at kalde COM for dødt. COM og COM+ er fuldt understøttet
> i .NET og vi vil sikkert se nye programmer der trækker på gamle
> komponenter i årevis.
>

Nej, det syntes jeg egentligt ikke. Så vidt jeg husker, omtaler f.eks. Don
Box også COM som dødt på TechNetcast (men jeg kan tage fejl).

Jeg mener at COM (meget fornuftigt) er temmeligt dødt som anbefalet
hjørnesten i arkitekturen i nyudviklede applikationer og komponenter.
Det er i hverfald anderledes end for 3 år siden, hvor jeg hørte COM
anbefalet som fundamentet (ja, nærmest en forudsætning) for komponentbaseret
udvikling.

Opfatter du COM som spræl-levende idag ?

Hvad forstår du ved "fuldt understøttet i .NET" ?

..NET har som run-time miljø meget fornuftigt mulighed for inter-operate med
COM, både så .NET kan bruge COM og COM kan bruge .NET komponenter på en nem
måde.

Man kan stadig udvikle egentlige COM komponenter med Visual C++ .NET, men
det kan man ikke med de andre sprog i Visual Studio .NET (VB.NET, C# og J#),
da de kun kan generere MSIL assemblies. Der findes ikke en fuld native .NET
alternativ til COM+ (forstået som MTS + en sjat), men jeg _gætter_ da på at
det kommer.

Fortiden dør langsomt, og man slæber rundt på den i lang tid.
Derfor er der god grund til at overveje konsekvenserne af det man gør så
grundigt som muligt.
Det vi sidder og laver idag, bliver fremtidens kedelige fortid.

COM havde sin berettigelse til nogle ting, men det havde så afgjort også
sine ulemper.


Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:acboug$8ee$1@news.cybercity.dk...
[klip]
> Jeg mener at COM (meget fornuftigt) er temmeligt dødt som anbefalet
> hjørnesten i arkitekturen i nyudviklede applikationer og komponenter.
> Det er i hverfald anderledes end for 3 år siden, hvor jeg hørte COM
> anbefalet som fundamentet (ja, nærmest en forudsætning) for
komponentbaseret
> udvikling.
>
> Opfatter du COM som spræl-levende idag ?

Jeg opfatter det ikke som den friskeste fisk i IT-havet. Men der findes
en masse rigtig nyttige komponenter derude som nok skal blive brugt,
selvom det ikke har det officielle .NET® stempel.

> Hvad forstår du ved "fuldt understøttet i .NET" ?

Jeg mente bare at .NET-applikationer kan være COM-klienter i bred
forstand. Som du kan læse fokuserer jeg meget på muligheden for at
benytte gamle komponenter. Dette vil give COM en lang og sej alderdom,
på linie med Cobol.

Jeg tror du har ret i at komponentbaseret udvikling til MS-platforme
vil tage udgangspunkt i .NET i kommende år. Jeg beklagede mig blot
over dit stærke ordvalg mht. den ældre teknologi med den lidt svage
puls.

[klip]
> Fortiden dør langsomt, og man slæber rundt på den i lang tid.
> Derfor er der god grund til at overveje konsekvenserne af det man gør så
> grundigt som muligt.
> Det vi sidder og laver idag, bliver fremtidens kedelige fortid.
> COM havde sin berettigelse til nogle ting, men det havde så afgjort også
> sine ulemper.

Der er heldigvis også få eksempler på en mindre kedelig fortid. twm er
stadig en meget udbredt windows-manager.

---

Anders Borum <ander@diku.dk> writes:

> Findes #import til andre oversættere eller kan man få særskilte
> præprocesorer der understøtter det?

GCC har et #import direktiv, omend det nok betyder noget andet end
hvad du snakker om.

Det er "arvet" fra Objective-C, og er ligesom #include, bortset fra at
det kun vil inkludere samme fil en gang. Man får en advarsel, fordi
man kan få samme funktionalitet på en standard måde ved at indsætte
include guards i headerfilen.