---

Hvad vil i sige er bedst? Microsoft Visual C++ eller Borlands C++ Builder?
-Anders

---

Nej wrote:

> Hvad vil i sige er bedst? Microsoft Visual C++ eller Borlands C++ Builder?
> -Anders


Du har netop startet en religionskrig!

Det er meget forskelligt hvad folk synes er bedst. Jeg bruger selv
Borland C++ Builder (BCB). I BCB er det meget nemt at lave
brugergrænsefladen. Dette kan gøres uden en eneste linie kode ved at
placere de forskellige komponenter hvor de skal være i vinduet. Desuden
følger BCB C++ standarden rimeligt godt.

I Microsoft Visual C++ (VC) skal man skrive en uhyrlig mængde kode for
at lave det mest simple. Desuden er Microsoft ved at opgive C++ i
forhold til deres eget sprog C#, og deres compiler følger ikke
standarden specielt godt.

Du kan for øvrigt downloade en trial version af BCB fra
http://www.borland.com/downloads/.

Ivan Johansen

---

Ja, det tænkte jeg nok ;)
> Du har netop startet en religionskrig!

---

Nej wrote:

> Hvad vil i sige er bedst? Microsoft Visual C++ eller Borlands C++ Builder?


g++



- Morten.

---

"Nej" <æmann@lort.kom> wrote in message

> Hvad vil i sige er bedst? Microsoft Visual C++ eller Borlands C++ Builder?


Hvad skal du lave, og hvad prioriterer du højt ?
Nogle forslag:
* Overholdelse af ISO C++ Standarden (C++Builder eller Intel C++. Ikke
Visual C++)
* GUI til MS-Windows (C++Builder)
* 2 lags database programmer (C++Builder)
* Høj performance (Visual C++ eller Intel C++)
* Device Driver til MS-Windows (Visual C++)
* MFC programmer (Visual C++)
* Mængden af tilgængelige bøger (Visual C++)
* Hvor udbredt er den (Visual C++)
der er sikkert mange andre parametre, der spiller en rolle

Jeg bruger selv Borland C++Builder V5.0 mest, alternativt Intel C++ som
virker god og sjældent Microsoft Visual C++. Mine behov er ikke nødvendigvis
i overensstemmelse med dine.
Først og fremmest vil jeg anbefale en relativ moderne C++ compiler, der
overholder ISO C++ Standarden rimeligt. Man vil kunne flytte koden fra den
ene compiler til den anden, hvis ens behov ændrer sig - og det gør de.
Alle compilere tilbyder specifikke "udvidelser" - vær opmærksom på hvornår
du bruger dem, og vær sikker på at man får en fordel ud af det.

Venlig hilsen

Mogens Hansen

---

Ok, da jeg er totalt nybegynder, og indtil videre kun har læst et af de der
hæfter til 60,- så skal der helst være mange bøger om den(det var vidst
Visual C++.)
Men når du skriver, at compileren ikke holder sig til standarden, betyder
det så, at det er sværere at lære eller hvad?
Engang langt ude i fremtiden kunne jeg godt tænke mig at komme til at lave
nogle spil eller noget(jaja, det er ikke let) men jeg er jo kun 15 så jeg
har masser af tid :) Jeg så også noget med, at Quake2 vidst nok var lavet i
Visual C++ eller sådan noget. Kan det passe?

-Anders;


> * Overholdelse af ISO C++ Standarden (C++Builder eller Intel C++. Ikke
> Visual C++)
> * GUI til MS-Windows (C++Builder)
> * 2 lags database programmer (C++Builder)
> * Høj performance (Visual C++ eller Intel C++)
> * Device Driver til MS-Windows (Visual C++)
> * MFC programmer (Visual C++)
> * Mængden af tilgængelige bøger (Visual C++)
> * Hvor udbredt er den (Visual C++)
> der er sikkert mange andre parametre, der spiller en rolle
>
> Jeg bruger selv Borland C++Builder V5.0 mest, alternativt Intel C++ som
> virker god og sjældent Microsoft Visual C++. Mine behov er ikke
nødvendigvis
> i overensstemmelse med dine.
> Først og fremmest vil jeg anbefale en relativ moderne C++ compiler, der
> overholder ISO C++ Standarden rimeligt. Man vil kunne flytte koden fra den
> ene compiler til den anden, hvis ens behov ændrer sig - og det gør de.
> Alle compilere tilbyder specifikke "udvidelser" - vær opmærksom på hvornår
> du bruger dem, og vær sikker på at man får en fordel ud af det.
>
> Venlig hilsen
>
> Mogens Hansen
>
>

---

Hejsa

"Yeah" <spasser@lol.dk> wrote in message
news:3c35fab5$0$5488$edfadb0f@dspool01.news.tele.dk...
> Ok, da jeg er totalt nybegynder, og indtil videre kun har læst et af de
der
> hæfter til 60,- så skal der helst være mange bøger om den(det var vidst
> Visual C++.)
> Men når du skriver, at compileren ikke holder sig til standarden, betyder
> det så, at det er sværere at lære eller hvad?

Hvis det er version 6.0, så er det største problem nok at den version af
standard-biblioteket
der følger med er meget forældet.
dette kan man imidlertidig rette op på, ved at installere en ny, som kan
hentes gratis
fra www.stlport.org..
hvis du har 7.0(beta) så er det ikke noget problem.

selve oversætterens største problem er i forbindelse specialisering af
templates(det kan ingen af dem).
Jeg har ikke umiddelbart hørt om andre væsentlige problemer med den...
Jeg tror næppe det vil have indflydelse på din indlæring.

> Engang langt ude i fremtiden kunne jeg godt tænke mig at komme til at lave
> nogle spil eller noget(jaja, det er ikke let) men jeg er jo kun 15 så jeg
> har masser af tid :) Jeg så også noget med, at Quake2 vidst nok var lavet
i
> Visual C++ eller sådan noget. Kan det passe?

Ja, men husk på at Q1-3 er alle skrevet i rent C...
det er vist først for nyligt han har givet sig i bedrift med C++....
Sourcen er lige blevet frigivet, det er med et VC projekt.


mvh Jonas

---

Ok. Det er vel bedst at have en compiler, som ligger tæt på standarden? Er
det lige meget om man bruger Visual C++ eller Borland C++ Builder, hvis man
vil lave spil(ja, det ligger _meget_ langt ude i fremtiden.)

-Anders;

---

Jonas Meyer Rasmussen wrote:

>
> Hvis det er version 6.0, så er det største problem nok at den version af
> standard-biblioteket
> der følger med er meget forældet.
> dette kan man imidlertidig rette op på, ved at installere en ny, som kan
> hentes gratis
> fra www.stlport.org..
> hvis du har 7.0(beta) så er det ikke noget problem.
>
> selve oversætterens største problem er i forbindelse specialisering af
> templates(det kan ingen af dem).
> Jeg har ikke umiddelbart hørt om andre væsentlige problemer med den...
> Jeg tror næppe det vil have indflydelse på din indlæring.

Prøv følgende program med Visual C++ og med nogle andre kompillere, så
vil du se en tydelig forskel:

#include <iostream>

int main(int argc, char* argv[])
{
int I = 0;
{
for(int I = 0; I < 10; I++);
if(I == 0)
std::cout << "This compiller follows the standard!\n";
else
std::cout << "This compiller doesn't follow the standard.\n"
"It must be Microsoft Visual C++\n";
}
return 0;
}

Jeg har desuden hørt om en hel del andre fejl i Visual C++, og Microsoft
nægter at rette dem. Kompilleren følger ikke engang prestandarden fra 1996.

Ivan Johansen

---

Sikke fjendsk du er over for MS..
heldigvis har du ikke helt ret :)

"Ivan Johansen" <NG@Padowan.dk> wrote in message
news:3C36245E.8060507@Padowan.dk...
[klip]
> #include <iostream>
>
> int main(int argc, char* argv[])
> {
> int I = 0;
> {
> for(int I = 0; I < 10; I++);
> if(I == 0)
> std::cout << "This compiller follows the standard!\n";
> else
> std::cout << "This compiller doesn't follow the standard.\n"
> "It must be Microsoft Visual C++\n";
> }
> return 0;
> }

Det er muligt at det ikke fungerer i deres 6.0 version af oversætteren, men
den nye, 7.0, kommer med
følgende advarsel når programmet oversættes:

Compiling...
test1.cpp
d:\code\test\test1.cpp(8) : warning C4288: nonstandard extension used : 'I'
: loop control variable declared in the for-loop is used outside the
for-loop scope; it conflicts with the declaration in the outer scope
d:\code\test\test1.cpp(7) : definition of 'I' used
d:\code\test\test1.cpp(5) : definition of 'I' ignored

Rimelig klar advarsel om hvad der sker.
ved at bruge oversætterflaget /Za, kan du slå deres udvidelser fra,
hvorefter programmet oversættes
uden advarsler, og kører præcis som man kan forvente ifølge standarden.

> Jeg har desuden hørt om en hel del andre fejl i Visual C++, og Microsoft
> nægter at rette dem. Kompilleren følger ikke engang prestandarden fra
1996.

De nægter at arbejde videre på 6.0 udgaven af oversætteren, og det kan man
vel ikke bebrejde dem?

De arbejder skam videre med den nyeste version af oversætteren...

mvh Jonas

---

"Jonas Meyer Rasmussen" <meyer_remove_@diku.dk> wrote

> Sikke fjendsk du er over for MS..
> heldigvis har du ikke helt ret :)
>

Nej, Ivan Johansen manglede en versions specifikation, for at være præcis.
Den senest releasede Microsoft C++ compiler er Visual C++ V6.0 SP 5, som
_ikke_ kan oversætte koden korrekt.
Microsoft Visual C++ .NET bliver frigivet 12. februar 2002.

>
> De arbejder skam videre med den nyeste version af oversætteren...
>

Microsoft Visual C++ .NET Release Candidate 1 er væsentligt bedre end
Microsoft Visual C++ V6.0 - hvilket i sig selv ikke siger så meget.
Microsoft Visual C++ .NET Release Candidate 1 er væsentligt dårligere end
hvad man forventer af en state of the art C++ compiler i relation til
overholdelse af C++ Standarden.
Det er relativt nemt at lave _nyttig_ C++ kode, der ikke oversætter med
Microsoft Visual C++ .NET Release Candidate 1. Kode der uden problemer
oversætter med Borland C++Builder V5.0, Intel C++ V5.0.1, gcc 2.96, Comeau
og givetvis mange andre releasede C++ compilere.
Det betyder naturligvis ikke at Microsoft Visual C++ .NET er en ubrugelig
compiler.

Man kan på nyhedsgrupper se personer, der er ansvarlige for Visual C++ .NET
fortælle hvorfor de ikke er compliant. Jeg har ikke lige et link her. Det er
åbenlyst at support for .NET, CLR og IL ikke overraskende er højere
prioriteret end overholdelse af den 3 år gamle ISO C++ Standard.
Men der er for så vidt ikke nogen grund til at være sur på Microsoft - man
kan bare lade være med at bruge deres compiler, hvis man ikke bryder sig om
den af en eller anden grund.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:a15ac1$auq$1@news.cybercity.dk...

> Man kan på nyhedsgrupper se personer, der er ansvarlige for Visual C++
..NET
> fortælle hvorfor de ikke er compliant. Jeg har ikke lige et link her.

Søg efter

Ronald Laeremans
ronlaere@microsoft.com

han har nogle forklaringer.

Venlig hilsen

Mogens Hansen

---

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

> Man kan på nyhedsgrupper se personer, der er ansvarlige for Visual C++
..NET
> fortælle hvorfor de ikke er compliant. Jeg har ikke lige et link her.

Et væsentligt link er
http://groups.google.com/groups?hl=da&threadm=OfLQCbctAHA.504%40tkmsftngp05&
rnum=2&prev=/groups%3Fq%3Dronlaere%2540microsoft.com%2Bconform%26hl%3Dda%26s
elm%3DOfLQCbctAHA.504%2540tkmsftngp05%26rnum%3D2

Venlig hilsen

Mogens Hansen

---

Hejsa Mogens.

Ganske interessant.

Du har uden tvivl ret i at det er skidt at der har været så lang tid om at
komme efter det.

Men jeg vil dog stadig komme med den påstand, at hvis man er nybegynder, så
er mangler ron laeremans listede i postet, for komplicerede til man
overhovedet kan forstå hvad det er.
og det vil derfor ikke påvirke ens indlæring.
Ej heller senere, for hvis man har sætter sig ind i delvise klasse template
specialiseringer,
så kan man næsten ikke undgå at se et rama-skrig om at ms ikke understøtter
det :)

mvh Jonas


"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:a168f1$14g5$1@news.cybercity.dk...
>
> "Mogens Hansen" <mogens_h@dk-online.dk> wrote
>
> > Man kan på nyhedsgrupper se personer, der er ansvarlige for Visual C++
> .NET
> > fortælle hvorfor de ikke er compliant. Jeg har ikke lige et link her.
>
> Et væsentligt link er
>
http://groups.google.com/groups?hl=da&threadm=OfLQCbctAHA.504%40tkmsftngp05&
>
rnum=2&prev=/groups%3Fq%3Dronlaere%2540microsoft.com%2Bconform%26hl%3Dda%26s
> elm%3DOfLQCbctAHA.504%2540tkmsftngp05%26rnum%3D2
>
> Venlig hilsen
>
> Mogens Hansen
>
>

---

"Jonas Meyer Rasmussen" <meyer_remove_@diku.dk> wrote

> Du har uden tvivl ret i at det er skidt at der har været så lang tid om at
> komme efter det.
>

Med Visual C++ .NET RC1 er de ikke kommet efter det endnu.

>
> Men jeg vil dog stadig komme med den påstand, at hvis man er nybegynder,
så
> er mangler ron laeremans listede i postet, for komplicerede til man
> overhovedet kan forstå hvad det er.
> og det vil derfor ikke påvirke ens indlæring.

Det vil ikke påvirke ens indlæring i væsentlig grad.
Men tag en god moderne begynderbog som "Accelerated C++" af Andrew König og
Barbara Moo.
Tag koden fra bogen (som kan downloades), og tæl hvor mange undtagelser der
er i ganske almindelig simpelt moderne C++, for forskellige compilere, på
grund af manglende overholdelse af C++ Standarden for simple ting.

GCC: 13 betingede
compileringer
Microsoft Visual C++ V6.0 (mindst SP4 !): 101 betingelde compileringer
Borland C++Builder V5.0: 1 betinget compilering

Det spiller en rolle for indlæringen. Ikke i en sådan grad at man ikke kan
eller bør anvende Microsoft Visual C++, man alligevel så meget så jeg syntes
at Microsoft burde kunne gøre det væsentligt bedre.

Venlig hilsen

Mogens Hansen

---

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

> Tag koden fra bogen (som kan downloades), og tæl hvor mange undtagelser
der
> er i ganske almindelig simpelt moderne C++, for forskellige compilere, på
> grund af manglende overholdelse af C++ Standarden for simple ting.
>
> GCC: 13
betingede
> compileringer

Jeg burde naturligvis have angivet at der er tale om gcc 2.95.2.
Der er altså ikke tale om nogen ny compiler.
Jeg ved ikke hvordan gcc 3.0.x er i forhold til - men formodentligt bedre
(færre betingede compileringer).

> Microsoft Visual C++ V6.0 (mindst SP4 !): 101 betingelde compileringer
> Borland C++Builder V5.0: 1 betinget compilering
>

I objektivitetens og nysgerrighedens tjeneste, har jeg også prøvet:
Microsoft Visual C++ .NET RC1: 0 betingede compileringer

Det kun bekræfter mit hidtidige indtryk og udsagn. Bl.a.:
* Microsoft Visual C++ V6.0 har dårlig overholdelse af C++ Standarden,
selv for simpel, moderne C++, i forhold til andre ikke specielt nye
compilere. Et udsagn der på mange virker provokerende, men formodentligt
bliver mere accepteret når Visual C++ .NET frigives.
* Microsoft Visual C++ .NET er væsentligt forbedret. Den er dog ikke på
niveau med hvad jeg forventer af en moderne professionel state-of-the art
C++ compiler. F.eks. afholder manglende partial template specialisering een
fra at prøve og anvende nye spændende og _nyttige_ programmerings teknikker
(se f.eks. "Modern C++ Design: Generic Programming and Design Patterns
Applied", Andrei Alexandrescu, ISBN: 0-201-70431-5). Det er andre kvaliteter
og egenskaber den udmærker sig på.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev den 11-Jan-02:

> "Mogens Hansen" <mogens_h@dk-online.dk> wrote
>
> > GCC: 13 betingede compileringer
>
> Jeg ved ikke hvordan gcc 3.0.x er i forhold til - men formodentligt bedre
> (færre betingede compileringer).

Samtlige gcc-relaterede betingelser ser således ud:

#ifndef __GNUC__
#include <ios>
#endif

- og <ios> følger med min gcc 3.0.1, så den klarer sig også igennem
med 0 betingede compileringer.


Anders.

---

Jonas Meyer Rasmussen wrote:

> Sikke fjendsk du er over for MS..
> heldigvis har du ikke helt ret :)

Det var nu ikke for at være fjendsk, men der er en grund til at jeg
foretrækker Borlands compiller. :)


> Det er muligt at det ikke fungerer i deres 6.0 version af oversætteren, men
> den nye, 7.0, kommer med
> følgende advarsel når programmet oversættes:

Okay, jeg indrømmer at jeg kun har testet med version 6, men fejlen har
være der altid og skulle være rettet for længe siden. Det er dog altid
noget at de endeligt har fået rettet den i version 7.

Ivan Johansen

---

"Jonas Meyer Rasmussen" <meyer_remove_@diku.dk> wrote

>
> Hvis det er version 6.0, så er det største problem nok at den version af
> standard-biblioteket
> der følger med er meget forældet.

Standard biblioteket er temmeligt forældet.
Jeg vil dog være forsigtig med at underkende den indsats som P.J. Plauger og
Pete Becker fra Dinkumware har lavet for at få STL til at virke nogenlunde
fornuftigt, og på den baggrund frikende compileren.
Jeg har set at Scott Meyers siger nogenlunde det samme i "Effective STL",
men jeg er bestemt ikke entydigt enig i.

>
> selve oversætterens største problem er i forbindelse specialisering af
> templates(det kan ingen af dem).
> Jeg har ikke umiddelbart hørt om andre væsentlige problemer med den...

Hvad med f.eks.
* manglende understøttelse for covariant return type
* scope in for statement
* operator new returnerer 0 i stedet for at smide std::bad_alloc
for blot at nævne nogle eksempler. Det ligger i compileren og ikke i
standard biblioteket, og det er noget der har ligger fast _længe_.

> Jeg tror næppe det vil have indflydelse på din indlæring.

Ikke det første stykke tid.


Venlig hilsen

Mogens Hansen

---

"Yeah" <spasser@lol.dk> wrote

> Ok, da jeg er totalt nybegynder, og indtil videre kun har læst et af de
der
> hæfter til 60,- så skal der helst være mange bøger om den(det var vidst
> Visual C++.)
> Men når du skriver, at compileren ikke holder sig til standarden, betyder
> det så, at det er sværere at lære eller hvad?

Det betyder ikke _meget_ for indlæringen.
Det betyder noget for hvor svær det er om man lærer moderne C++ eller
klassisk C++.

Jo mere man skriver sin kode i overensstemmelse med C++ Standarden, des
nemmere er at flytte den til en anden compiler eller platform. Man siger at
koden så er portabel.

Det er langt mere væsentligert hvad du bruger til at lære fra, end hvilken
compiler du bruger.
Hvis du føler at du kan læse en bog på engelsk, vil jeg anbefale dig at få
fat på
Accelerated C++
Andrew Koenig, Barbara Moo
ISBN 0-201-70353-X
den er enestående god - og husk at lav øvelserne!
Den koster ca. 350 kr.
I længden kommer man under ingen omstændigheder uden om engelske bøger.

Du kan udemærket bruge Microsoft Visual C++, GCC (som kan hentes gratis)
eller Borland C++ (som kan hentes gratis som kommando-linie værktøj fra
www.borland.com) til at lave øvelserne i bogen med.

Du skal også være opmærksom på at der findes meget andet end Standard C++.
Bøger (som f.eks. ovennævnte) behandler ikke disse ting.
Dels findes der mange gode portable biblioteker til forskellige formål
(f.eks. netværk, multi-threading, database etc.)
Der findes også mange også mange væsentlige ikke portable. F.eks. vil det
nok være fornuftigt at kigge på DirectX, hvis man vil skrive spil til
MS-Windows platformen.

> Jeg så også noget med, at Quake2 vidst nok var lavet i
> Visual C++ eller sådan noget. Kan det passe?
>

Ja, det kan nemt passe (hvis Quake2 er et MS-Windows 32 bit program), men
jeg ved det ikke.
Der er utroligt meget software, der er skrevet med Microsoft Visual C++.
Blandt dens gode egenskaber er at den er god til at få programmer til at
køre hurtigt - og det er meget væsentligt for spil.

Venlig hilsen

Mogens Hansen

---

On Thu, 3 Jan 2002 18:04:04 +0100, Nej wrote:

>Hvad vil i sige er bedst? Microsoft Visual C++ eller Borlands C++ Builder?

Sprogmæssigt har de gået hver deres vej og holder stejlt på
deres dialekt, hvis du vil have den rene vare skal du nok gå GCC
(GNU Compiler Collection), der strengt holder sig til
standarden.

De har begge deres fejl og svagheder, men Builder (når man først
får lært den at kende og hvis den altså kan lide en) er en bedre
VDE, dens visuelle builder er en af de bedste på det
kommercielle marked.

Det eneste positive jeg kan sige om Visual C++ er at Redmond nok
er på vej imod C# (kan beskrives som en konsekvensløs Java
look-a-like)....har haft mine sammenstød med værktøjet og det er
som regl blevet til en Visual C++ sejr ... det har gerne
resultetet i at jeg har fået nok og har lavet skidtet vha GCC
eller VisualAge C++.

Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark
flywheel@illogical.dk
http://www.illogical.dk
Press any key to continue or any other key to quit

---

"Peter Jespersen" <flywheel@illogical.dk> wrote in message
news:syljurryvyybtvpnyqx.gpe4lr2.pminews@news.tele.dk...
On Thu, 3 Jan 2002 18:04:04 +0100, Nej wrote:

> >Hvad vil i sige er bedst? Microsoft Visual C++ eller Borlands C++
Builder?
>
> Sprogmæssigt har de gået hver deres vej og holder stejlt på
> deres dialekt, hvis du vil have den rene vare skal du nok gå GCC
> (GNU Compiler Collection), der strengt holder sig til
> standarden.
>

Det er lidt upræcist. Der er 2 forskellige forhold, der gør sig gældende:
1. Compilerens evne til at oversætte ISO C++ Standard compliant kode
2. Compilerens evne til at oversætte kode med proprietære sprogudvidelser.

Det første punkt afgør hvor nemt det er at flytte kode til en compiler.
Det andet punkt afgør hvor nemt det er at flytte kode fra en compiler.

Jeg anser det første punkt for at være væsentligt, og man bør være klar over
hvornår man bevæger sig ind i det andet.

Det er rigtigt at såvel Microsoft Visual C++ og Borland C++Builder
indeholder mere eller mindre velbegrundede sprogudvidelser, og at de 2 ikke
er indbyrdes kompatible selv for lignende funktionalitet som f.eks.
"property". Det betyder dog ikke i sig selv, at de ikke er i stand til at
oversætte ISO C++ Standard compliant kode i større eller mindre grad.

De fleste (hvis ikke alle) C++ compilere jeg kender indeholder mere eller
mindre velbegrundede sprogudvidelser.
Dette gælder også GCC. Linux kernen skrevet med anvendelse af
sprogudvidelser som findes i GCC, og derfor kan Linux kernen ifølge Intel
ikke oversættes med Intel C++ V5.0.
Intel C++ indeholder så særlige udvidelser, der angiveligt gør det nemmere
at udnytte særlige egenskaber i Intel processorerne, såsom MMX og SIMD.
Det ændrer dog ikke på det faktum at Intel compileren hører til i gruppen af
compilere der kan oversætte mest ISO C++ Standard compliant kode.

Alle C++ compilere er i stand til at oversætte ISO C++ Standard compliant i
større eller mindre grad. Der findes så vidt jeg ved _ingen_ C++ compiler
der implementerer _hele_ standarder - heller ikke GCC. Men der findes mange
der er meget tæt på - så tæt på at det i praksis føles som om hele
standarden er implementeret. Det kan anbefales at vælge compilere som tager
ISO C++ Standarden alvorligt.

>
> det har gerne
> resultetet i at jeg har fået nok og har lavet skidtet vha GCC
>eller VisualAge C++.
>

IBM VisualAge for C++ indeholder også udvidelser.
Fra V4.0 var det f.eks. ikke nødvendigt at bruge header-filer og
"#include" - man blev faktisk rådet til at lade være i den dokumentation jeg
har læst.

Venlig hilsen

Mogens Hansen

---

On Fri, 4 Jan 2002 20:25:12 +0100,
Mogens Hansen <mogens_h@dk-online.dk> wrote:

> Alle C++ compilere er i stand til at oversætte ISO C++ Standard compliant i
> større eller mindre grad. Der findes så vidt jeg ved _ingen_ C++ compiler
> der implementerer _hele_ standarder - heller ikke GCC. Men der findes mange
> der er meget tæt på - så tæt på at det i praksis føles som om hele
> standarden er implementeret. Det kan anbefales at vælge compilere som tager
> ISO C++ Standarden alvorligt.

Er der nogen compiler der understøtter export?

--
Like a rat in a maze Anders Bo Rasmussen mailto:fuzz01@spamfilter.dk
The path before me lies Frimestervej 42 1.tv http://www.fuzz.dk
And the pattern never alters 2400 Kbh. NV
Until the rat dies.

---

"Anders Bo Rasmussen" <fuzz01@spamfilter.dk> wrote in message
news:slrna3c3d7.a5a.fuzz01@localhost.localdomain...
> On Fri, 4 Jan 2002 20:25:12 +0100,
> Mogens Hansen <mogens_h@dk-online.dk> wrote:
>
> > Alle C++ compilere er i stand til at oversætte ISO C++ Standard
compliant i
> > større eller mindre grad. Der findes så vidt jeg ved _ingen_ C++
compiler
> > der implementerer _hele_ standarder - heller ikke GCC. Men der findes
mange
> > der er meget tæt på - så tæt på at det i praksis føles som om hele
> > standarden er implementeret. Det kan anbefales at vælge compilere som
tager
> > ISO C++ Standarden alvorligt.
>
> Er der nogen compiler der understøtter export?
>

Ikke mig bekendt.
Comeau havde annonceret det til december 2001, men ser ikke ud til at have
gjort det.
Se
http://www.comeaucomputing.com/features.html#stilltocome

Venlig hilsen

Mogens Hansen

---

On Fri, 4 Jan 2002 21:32:54 +0100,
Mogens Hansen <mogens_h@dk-online.dk> wrote:

>> Er der nogen compiler der understøtter export?
>>
>
> Ikke mig bekendt.
> Comeau havde annonceret det til december 2001, men ser ikke ud til at have
> gjort det.
> Se
> http://www.comeaucomputing.com/features.html#stilltocome

Den compiler ligger også i en prisklasse, som er til at betale sig fra.
De virker dog meget selvglade på deres hjemmeside.

--
Like a rat in a maze Anders Bo Rasmussen mailto:fuzz01@spamfilter.dk
The path before me lies Frimestervej 42 1.tv http://www.fuzz.dk
And the pattern never alters 2400 Kbh. NV
Until the rat dies.

---

"Anders Bo Rasmussen" <fuzz01@spamfilter.dk> wrote
> On Fri, 4 Jan 2002 21:32:54 +0100,
> Mogens Hansen <mogens_h@dk-online.dk> wrote:
>
>
> Den compiler ligger også i en prisklasse, som er til at betale sig fra.

Ja, men det er en C++ til C compiler, og der er ikke noget Standard Library.
Det betyder at du skal have en anden compiler med tilhørende Standard
Library. På MS-Windows platformen kan man benytte Microsoft Visual C++ til
at oversætte C koden til binære filer. Dinkumware (www.dinkum.com) har et
Standard Library, der er garanteret til at virke sammen med Comeau
compileren.
Comeau compileren er rigtig god som reference compiler, hvis man er i tvivl
om noget er gyldig C++. Man skal være sikker i sin sag, før man siger den
tager fejl.
Den er også god på platforme, hvor man gerne vil bruge C++ og "kun" har
adgang til en C compiler.

> De virker dog meget selvglade på deres hjemmeside.
>

Det har de (Greg Comeau) al ret til at være, så vidt jeg kan vurdere.
Naturligvis sammen med EDG (www.edg.com), som laver front-enden. De er 3
mand der laver hvad der formodentlig er den bedste C++ front-end samt en
Fortran front-end og en Java front-end - det er flot.
Det er typisk et godt tegn, hvis en compiler er EDG baseret.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote
> På MS-Windows platformen kan man benytte Microsoft Visual C++ til
> at oversætte C koden til binære filer.

Og snart den gratis Borland C++ V5.5.1 kommando-linie compiler og muligvis
andre.

> Man skal være sikker i sin sag, før man siger den
> tager fejl.

Jeg har ikke set den tage fejl endnu :)

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> Alle C++ compilere er i stand til at oversætte ISO C++ Standard compliant i
> større eller mindre grad. Der findes så vidt jeg ved _ingen_ C++ compiler
> der implementerer _hele_ standarder - heller ikke GCC. Men der findes mange
> der er meget tæt på - så tæt på at det i praksis føles som om hele
> standarden er implementeret. Det kan anbefales at vælge compilere som tager
> ISO C++ Standarden alvorligt.

Ved du hvilke ting mangler i gcc 3.0x ?

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote
>
>
> Ved du hvilke ting mangler i gcc 3.0x ?
>

Nej, jeg har ikke prøvet den.
Jeg har kun kørt med gcc 2.96, og der var primært et gammelt IO stream
bibliotek, der ikke var up-to-date.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> Nej, jeg har ikke prøvet den.

Øv, jeg troede lige jeg kunne få det forærende Den har et helt nyt
C++ lib, som er skrevet fra bunden af, og som skulle understøtte næsten
alt i standarten undtagen "export" (hvilke jo også er en sprog feature)


> Jeg har kun kørt med gcc 2.96, og der var primært et gammelt IO stream
> bibliotek, der ikke var up-to-date.

Der er en uautoriceret 2.95.3 version (fyyy) og den følger kun
standarten i STL ikke mht. streams. Man kommer dog dejlig tæt på med
"stlport" eller SGI STL 3.3 incl. deres streams lib.

/BL

---

Bo Lorentsen <bl@nospam.lue.dk> writes:

> Ved du hvilke ting mangler i gcc 3.0x ?

Fra <http://gcc.gnu.org/bugs.html#known>:

Missing features
================

We know some things are missing from G++.

The export keyword is not implemented.
--------------------------------------

Most C++ compilers (G++ included) do not yet implement export,
which is necessary for separate compilation of template declarations
and definitions. Without export, a template definition must be in
scope to be used. The obvious workaround is simply to place all
definitions in the header itself. Alternatively, the compilation unit
containing template definitions may be included from the header.

Two stage lookup in templates is not implemented.
-------------------------------------------------

[14.6] specifies how names are looked up inside a template. G++
does not do this correctly, but for most templates this will not be
noticeable.

---

"Nej" <æmann@lort.kom> wrote in message
news:3c348eff$0$38003$edfadb0f@dspool01.news.tele.dk...
> Hvad vil i sige er bedst? Microsoft Visual C++ eller Borlands C++ Builder?
> -Anders

Jeg har brugt Visual C ++ sporadisk, og har tidligere brugt bla. Borland C++
3.1 til DOS og 16 Bit. Windows.
Men ellers programmere jeg normalt ikke PC'ere til hverdag.

Jeg er nu blevet 'tvunget' til at bruge C++ Builder, men har stadig kun
meget begrænset erfaring med denne, og derfor vel ikke kompetent til at
sammenligne de to produkter. Men derfor kan jeg godt gøre forsøget

Jeg syntes at Visual C++ virker hurtigere både i udviklings miljøet, og den
genererede GUI code (load og opdatering).
Jeg syntes også at Visual C++ hurtigt til 'browse' efter hvor en identifier
er erklæret, hvor den bruges, og vise hvilke medlems funktioner den har.

Jeg kan slet slet ikke lide Borland's IDE hvor de forskellige dele af
miljøet er 'ikke modale pupup vinduer' (eller hvad det nu hedder), istedet
for en MDI frame med 'dock' bare vinduer. Men det er nok smag og behag.
Jeg syntes jeg bruger meget tid på at flytte rundt med de forskellige
vinduer i Builder, og er tvunget til at have så få programmer åben som
muligt. Ellers går det helt bare helt 'gjald'.

Jeg tror ikke der er nævneværdig forskel i hastigheden på den 'almindelige'
kode de to compilere gennerere, men Visual C's GUI klasse bibliotek MFC
virker hurtigere end Borlands, da Borland har en kraftigere indpakning af
Windows GDI.
Denne indpakning er lavet for at gøre det nemt at finde ud af hvilke metoder
en GUI komponent har, men det betyder sikkert noget 'dobbelt bogholderi'
skjult for den almindelige programmør, men som koster tid under runtime.
(Jeg har ikke helt gennemskuet hvordan Borland laver denne indkapsling, mens
man i MFC ikke kan undgå at se det fra tid til anden når man har lavet en
fejl og MFC laver en assertion nede midt i klassebliblioteket ;- (
Denne indkabsling i Borland betyder sikkert at de er nødt til at have en
kopi af den state information der er i det underligende Windows GDI, hvor
den gemmer på information om f.eks. font, og farver. Denne information
betyder vel at Borlands komponenter indeholder et væld af GDI objecter som
Pen og Brush, selv om de bruger samme farver som det vindue de er placeret
på, eller hvad ?

Denne indkabsling i Borland har den fordel at man kan lege med
indstilingerne i Object Inspector og derved se hvorledes tingende kommer til
at se ud uden at skrive en eneste linie kode. Hvor man i MFC typisk skal
sætte tingende op i koden.

Mht. online hjælp kan de begge være lidt rodet på hver sin måde.
I Borland er noget af hjælpen til Paschal istedet for til C++, og der skal
vælges en anden hjælpefil hvis man skal søge i Win32 SDK. Hjælpen er til
tider lidt mangelfuldt.
I Microsoft Visual C++ skal man huske at søge i de rigtige sets, ellers får
man informationer om VB Script, java, eller det der er være..
Men gennerelt syntes jeg at Visual C++ / MSDN giver meget mere information.

Mht. at 'man i Visual C++ skal skrive mere kode', mener jeg at der ikke er
den helt store forskel på den mængde kode som man selv skal skrive selv da
Class wisard gennerere en del kode. Dog indeholder et Visual C++ program
mere GUI kode end et builder program, hvilket betyder at man skal kunne
gennemskue dette for at kunne ryde op efter Class Wisarden hvis man har
fortrudt noget den har gennereret.
Men noget af den information som Visual C++ har i koden, gemmer Builder i
andre tekstfiler.

Begge Compilere har nogle lidt sære macro konstruktioner for at klistre GUI
delen sammen med koden.
Første gang jeg så noget Visual C++ kode, var jeg i tvivl om det var C++.
Borland forsøger med macroer at efterligne måden at indkludere Turbo Paschal
indkludere Units

Begge Compilere har deres eget klasse blibliotek som udover klasser til GUI,
indeholder klasser til Stenge, Lister, Containere, etc. som er forskellig
fra det som er STL.
Hvis man kode der skal bruges på begge compilere, ender jeg altid med en
uskøn sammenblanding af CString, AnsiString, BSTRING, std::string, char*
osv. Gode forslag modtages med glæde..

---

"Niels Erik Danielsen" <ned@post6.tele.dk> wrote

>
> Jeg syntes at Visual C++ virker hurtigere både i udviklings miljøet, og
den
> genererede GUI code (load og opdatering).
> Jeg syntes også at Visual C++ hurtigt til 'browse' efter hvor en
identifier
> er erklæret, hvor den bruges, og vise hvilke medlems funktioner den har.
>

C++Builder's browse funktion (CodeInsight) er bovlam!
Den er uhyggelig langsom, og finder ofte ikke noget af værdi - i hverfald
når man bevæger sig uden for VCL og ind i lidt mere avanceret C++ kode.
Slå den fra i "Tools|Editor Options" og tryk "Ctrl-Space" når du vil se om
den kan finde noget.
De lover at det bliver væsentligt bedre i C++Builder V6.0 - vi får at se.
Microsoft Visual Studio .NET er fantastisk god på det punkt.

> Jeg kan slet slet ikke lide Borland's IDE hvor de forskellige dele af
> miljøet er 'ikke modale pupup vinduer' (eller hvad det nu hedder), istedet
> for en MDI frame med 'dock' bare vinduer. Men det er nok smag og behag.
> Jeg syntes jeg bruger meget tid på at flytte rundt med de forskellige
> vinduer i Builder, og er tvunget til at have så få programmer åben som
> muligt. Ellers går det helt bare helt 'gjald'.
>

Hvis du bruger C++Builder V5.0, kan du definere forskellige desktop
opsætninger. Det syntes jeg hjælper på det.
Jeg har defineret opsætninger til:
* Almindelig edit
* Edit, hvor editoren er så stor som muligt
* Edit af grafisk brugergrænseflade
* Debug

> Jeg tror ikke der er nævneværdig forskel i hastigheden på den
'almindelige'
> kode de to compilere gennerere,

Mine målinger siger at programmer oversat med Borland C++ typisk kører halvt
så hurtigt som det samme program oversat med Visual C++.
Ofte lægger man ikke mærke til det, fordi det ikke er væsentligt når blot
tingene kører "hurtigt nok".

> men Visual C's GUI klasse bibliotek MFC
> virker hurtigere end Borlands, da Borland har en kraftigere indpakning af
> Windows GDI.

Nu snakker du entydigt biblioteker til GUI udvikling. Microsoft MFC i
forhold til Borland VCL.

I nogle målinger, som jeg forventer at offentliggøre i anden sammenhæng, har
jeg bl.a. undersøgt run-time performance for forskellige
programmeringsmodeller til GUI udvikling under MS-Windows.

Jeg har målt hvor mange Windows messages et program kan sende til sig selv
pr. tidsenhed og tælle hvor mange messages det har modtaget. Det er ikke en
typisk situation for et program, men siger alligevel noget om hvilken pris
man betaler for at øge abstraktionsniveauet.
Det typiske er jo at man betaler for højere abstraktion med dårligere
performance.

Resultatet er foreløbigt:

Library Compiler Rel. Performance
API MSVC 100,0 %
API Intel 99,8 %
API BCB 97,8 %
WTL MSVC 61,7 %
WTL Intel 50,3 %
OWL BC 47,3 %
MFC MSVC 41,1 %
MFC Intel 40,8 %
MFC BCB 22,0 %
VCL BCB 2,5 %

Højere værdi betyder bedre performance.

Hvor
API: MS-Windows 32 C API
WTL: Microsoft Windows Template Library
OWL: Borland Object Windows Library
MCF: Microsoft Foundation Classes
VCL: Borland Visual Component Library
MSVC: Microsoft Visual C++ V6.0
Intel: Intel C++ V5.0.1
BC: Borland C++ V5.02
BCB Borland C++Builder V5.0

Et par observationer:
Klassebibliotekerne giver typisk ca. en halvering af performance - altså en
klar abstraction penalty.
MFC kører halv så hurtigt med Borland C++Builder som med Microsoft eller
Intel compilerne (Intel compiler performance skal tages med et gran salt -
hele MFC er oversat med Microsoft, kun applikationen er oversat med Intel).
VCL kører væsentligt (20 gange) langsommere end andre klassebiblioteker.

Performance overheadet spiller ikke nødvendigvis en afgørende rolle. Dels
kører VCL typisk hurtigt nok, dels er målingen ikke et udtryk for et typisk
scenarie og dels er der andre faktorer end "blot" performance der spiller en
rolle for valget af programmerings grundlag.

> Denne indkabsling i Borland betyder sikkert at de er nødt til at have en
> kopi af den state information der er i det underligende Windows GDI, hvor
> den gemmer på information om f.eks. font, og farver. Denne information
> betyder vel at Borlands komponenter indeholder et væld af GDI objecter som
> Pen og Brush, selv om de bruger samme farver som det vindue de er placeret
> på, eller hvad ?
>

Det tror jeg egentligt ikke.

>
> Mht. at 'man i Visual C++ skal skrive mere kode', mener jeg at der ikke er
> den helt store forskel på den mængde kode som man selv skal skrive selv da
> Class wisard gennerere en del kode. Dog indeholder et Visual C++ program
> mere GUI kode end et builder program, hvilket betyder at man skal kunne
> gennemskue dette for at kunne ryde op efter Class Wisarden hvis man har
> fortrudt noget den har gennereret.
> Men noget af den information som Visual C++ har i koden, gemmer Builder i
> andre tekstfiler.
>

Nu snakker du udvikling af GUI.
Her mener jeg at der er en væsentlig forskel.
C++Builder generer næsten ikke noget kode (en erklæring, og måske en tom
funktion), når man visuelt redigerer brugergrænsefladen.
Jeg mener klart at Wizard, der generer store mængder kode og hvor der ikke
er fortrydelsesret har væsentlige problemer indbygget.
Jeg mener også at Microsoft selv har samme opfattelse.
Prøv at se hvordan Microsoft Visual Studio .NET ser ud.
Grundtanken i design af GUI (WinForm) er eksakt som Delphi og C++Builder.
Det er ikke overranskende, for det er samme person (danskeren Anders
Hejlsberg), der var arkitekten bag Delphi (og klassebiblioteket VCL), som
har designet væsentlige dele af Visual Studio .NET. Anders Hejlberg har også
sat sit tydelige præg på C#, 2-way visual editing (som Microsoft har betalt
Borland mange penge for at at bruge) og WinForm klassebiblioteket.

Jeg tager det som et udtryk for at udviklingsværktøjer som Delphi,
C++Builder, JBuilder og Visual Studio .NET anvender den bedste model for
udvikling af GUI, som industrien kender i dag.

Der er for mig ingen tvivl om at hvis man skal lave grafisk
brugergrænseflade til MS-Windows med anvendelse af C++, eller
brugergrænseflade til "business logic" skrevet i C++, så er Borland
C++Builder det mest oplagte bud. Det er klart enklere end at bruge MFC og
mere direkte end at lave COM interface som kan tilgåes fra en Visual Basic
baseret GUI.

Jeg mener at MFC reelt er død, og få vil savne det. Det har aldrig været
kendt for at være godt designet.

> Begge Compilere har nogle lidt sære macro konstruktioner for at klistre
GUI
> delen sammen med koden.
> Første gang jeg så noget Visual C++ kode, var jeg i tvivl om det var C++.
> Borland forsøger med macroer at efterligne måden at indkludere Turbo
Paschal
> indkludere Units
>

Det er forholdsvis lidt, og man kan lægge det meste i en separat
tekst-file, som typisk hedder *.BPF.
VCL baseret kode er uløseligt knyttet til Borland compileren - det må man
acceptere hvis man vil bruge det.

> Begge Compilere har deres eget klasse blibliotek som udover klasser til
GUI,
> indeholder klasser til Stenge, Lister, Containere, etc. som er forskellig
> fra det som er STL.
> Hvis man kode der skal bruges på begge compilere, ender jeg altid med en
> uskøn sammenblanding af CString, AnsiString, BSTRING, std::string, char*
> osv. Gode forslag modtages med glæde..
>

Ja, man gør bedst i at holde sig til Standard Library i sin
"business-logic", og så acceptere at der skal laves konverteringer når
tingene skal på bruger-grænseflade, over netværk eller i en database.
Det er et spørgsmål om at styre sine afhængigheder bevidst.

Venlig hilsen

Mogens Hansen

---

"Niels Erik Danielsen" <ned@post6.tele.dk> wrote

>
> Jeg syntes at Visual C++ virker hurtigere både i udviklings miljøet, og
den
> genererede GUI code (load og opdatering).
> Jeg syntes også at Visual C++ hurtigt til 'browse' efter hvor en
identifier
> er erklæret, hvor den bruges, og vise hvilke medlems funktioner den har.
>

C++Builder's browse funktion (CodeInsight) er bovlam!
Den er uhyggelig langsom, og finder ofte ikke noget af værdi - i hverfald
når man bevæger sig uden for VCL og ind i lidt mere avanceret C++ kode.
Slå den fra i "Tools|Editor Options" og tryk "Ctrl-Space" når du vil se om
den kan finde noget.
De lover at det bliver væsentligt bedre i C++Builder V6.0 - vi får at se.
Microsoft Visual Studio .NET er fantastisk god på det punkt.

> Jeg kan slet slet ikke lide Borland's IDE hvor de forskellige dele af
> miljøet er 'ikke modale pupup vinduer' (eller hvad det nu hedder), istedet
> for en MDI frame med 'dock' bare vinduer. Men det er nok smag og behag.
> Jeg syntes jeg bruger meget tid på at flytte rundt med de forskellige
> vinduer i Builder, og er tvunget til at have så få programmer åben som
> muligt. Ellers går det helt bare helt 'gjald'.
>

Hvis du bruger C++Builder V5.0, kan du definere forskellige desktop
opsætninger. Det syntes jeg hjælper på det.
Jeg har defineret opsætninger til:
* Almindelig edit
* Edit, hvor editoren er så stor som muligt
* Edit af grafisk brugergrænseflade
* Debug

> Jeg tror ikke der er nævneværdig forskel i hastigheden på den
'almindelige'
> kode de to compilere gennerere,

Mine målinger siger at programmer oversat med Borland C++ typisk kører halvt
så hurtigt som det samme program oversat med Visual C++.
Ofte lægger man ikke mærke til det, fordi det ikke er væsentligt når blot
tingene kører "hurtigt nok".

> men Visual C's GUI klasse bibliotek MFC
> virker hurtigere end Borlands, da Borland har en kraftigere indpakning af
> Windows GDI.

Nu snakker du entydigt biblioteker til GUI udvikling. Microsoft MFC i
forhold til Borland VCL.

I nogle målinger, som jeg forventer at offentliggøre i anden sammenhæng, har
jeg bl.a. undersøgt run-time performance for forskellige
programmeringsmodeller til GUI udvikling under MS-Windows.

Jeg har målt hvor mange Windows messages et program kan sende til sig selv
pr. tidsenhed og tælle hvor mange messages det har modtaget. Det er ikke en
typisk situation for et program, men siger alligevel noget om hvilken pris
man betaler for at øge abstraktionsniveauet.
Det typiske er jo at man betaler for højere abstraktion med dårligere
performance.

Resultatet er foreløbigt:

Library Compiler Rel. Performance
API MSVC 100,0 %
API Intel 99,8 %
API BCB 97,8 %
WTL MSVC 61,7 %
WTL Intel 50,3 %
OWL BC 47,3 %
MFC MSVC 41,1 %
MFC Intel 40,8 %
MFC BCB 22,0 %
VCL BCB 2,5 %

Højere værdi betyder bedre performance.

Hvor
API: MS-Windows 32 C API
WTL: Microsoft Windows Template Library
OWL: Borland Object Windows Library
MCF: Microsoft Foundation Classes
VCL: Borland Visual Component Library
MSVC: Microsoft Visual C++ V6.0
Intel: Intel C++ V5.0.1
BC: Borland C++ V5.02
BCB Borland C++Builder V5.0

Et par observationer:
Klassebibliotekerne giver typisk ca. en halvering af performance - altså en
klar abstraction penalty.
MFC kører halv så hurtigt med Borland C++Builder som med Microsoft eller
Intel compilerne (Intel compiler performance skal tages med et gran salt -
hele MFC er oversat med Microsoft, kun applikationen er oversat med Intel).
VCL kører væsentligt (20 gange) langsommere end andre klassebiblioteker.

Performance overheadet spiller ikke nødvendigvis en afgørende rolle. Dels
kører VCL typisk hurtigt nok, dels er målingen ikke et udtryk for et typisk
scenarie og dels er der andre faktorer end "blot" performance der spiller en
rolle for valget af programmerings grundlag.

> Denne indkabsling i Borland betyder sikkert at de er nødt til at have en
> kopi af den state information der er i det underligende Windows GDI, hvor
> den gemmer på information om f.eks. font, og farver. Denne information
> betyder vel at Borlands komponenter indeholder et væld af GDI objecter som
> Pen og Brush, selv om de bruger samme farver som det vindue de er placeret
> på, eller hvad ?
>

Det tror jeg egentligt ikke.

>
> Mht. at 'man i Visual C++ skal skrive mere kode', mener jeg at der ikke er
> den helt store forskel på den mængde kode som man selv skal skrive selv da
> Class wisard gennerere en del kode. Dog indeholder et Visual C++ program
> mere GUI kode end et builder program, hvilket betyder at man skal kunne
> gennemskue dette for at kunne ryde op efter Class Wisarden hvis man har
> fortrudt noget den har gennereret.
> Men noget af den information som Visual C++ har i koden, gemmer Builder i
> andre tekstfiler.
>

Nu snakker du udvikling af GUI.
Her mener jeg at der er en væsentlig forskel.
C++Builder generer næsten ikke noget kode (en erklæring, og måske en tom
funktion), når man visuelt redigerer brugergrænsefladen.
Jeg mener klart at Wizard, der generer store mængder kode og hvor der ikke
er fortrydelsesret har væsentlige problemer indbygget.
Jeg mener også at Microsoft selv har samme opfattelse.
Prøv at se hvordan Microsoft Visual Studio .NET ser ud.
Grundtanken i design af GUI (WinForm) er eksakt som Delphi og C++Builder.
Det er ikke overranskende, for det er samme person (danskeren Anders
Hejlsberg), der var arkitekten bag Delphi (og klassebiblioteket VCL), som
har designet væsentlige dele af Visual Studio .NET. Anders Hejlberg har også
sat sit tydelige præg på C#, 2-way visual editing (som Microsoft har betalt
Borland mange penge for at at bruge) og WinForm klassebiblioteket.

Jeg tager det som et udtryk for at udviklingsværktøjer som Delphi,
C++Builder, JBuilder og Visual Studio .NET anvender den bedste model for
udvikling af GUI, som industrien kender i dag.

Der er for mig ingen tvivl om at hvis man skal lave grafisk
brugergrænseflade til MS-Windows med anvendelse af C++, eller
brugergrænseflade til "business logic" skrevet i C++, så er Borland
C++Builder det mest oplagte bud. Det er klart enklere end at bruge MFC og
mere direkte end at lave COM interface som kan tilgåes fra en Visual Basic
baseret GUI.

Jeg mener at MFC reelt er død, og få vil savne det. Det har aldrig været
kendt for at være godt designet.

> Begge Compilere har nogle lidt sære macro konstruktioner for at klistre
GUI
> delen sammen med koden.
> Første gang jeg så noget Visual C++ kode, var jeg i tvivl om det var C++.
> Borland forsøger med macroer at efterligne måden at indkludere Turbo
Paschal
> indkludere Units
>

Det er forholdsvis lidt, og man kan lægge det meste i en separat
tekst-file, som typisk hedder *.BPF.
VCL baseret kode er uløseligt knyttet til Borland compileren - det må man
acceptere hvis man vil bruge det.

> Begge Compilere har deres eget klasse blibliotek som udover klasser til
GUI,
> indeholder klasser til Stenge, Lister, Containere, etc. som er forskellig
> fra det som er STL.
> Hvis man kode der skal bruges på begge compilere, ender jeg altid med en
> uskøn sammenblanding af CString, AnsiString, BSTRING, std::string, char*
> osv. Gode forslag modtages med glæde..
>

Ja, man gør bedst i at holde sig til Standard Library i sin
"business-logic", og så acceptere at der skal laves konverteringer når
tingene skal på bruger-grænseflade, over netværk eller i en database.
Det er et spørgsmål om at styre sine afhængigheder bevidst.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:a16uh3$1vnr$2@news.cybercity.dk...

> Det typiske er jo at man betaler for højere abstraktion med dårligere
> performance.

> Resultatet er foreløbigt:
>
> Library Compiler Rel. Performance
> API MSVC 100,0 %
> MFC MSVC 41,1 %
> VCL BCB 2,5 %

Det var noget af en forskel !


> C++Builder generer næsten ikke noget kode (en erklæring, og måske en tom
> funktion), når man visuelt redigerer brugergrænsefladen.
> Jeg mener klart at Wizard, der generer store mængder kode og hvor der ikke
> er fortrydelsesret har væsentlige problemer indbygget.
> Jeg mener også at Microsoft selv har samme opfattelse.
> Prøv at se hvordan Microsoft Visual Studio .NET ser ud.

Er den frigivet, eller er den i beta ?

> Grundtanken i design af GUI (WinForm) er eksakt som Delphi og C++Builder.
> Det er ikke overranskende, for det er samme person (danskeren Anders
> Hejlsberg), der var arkitekten bag Delphi (og klassebiblioteket VCL), som
> har designet væsentlige dele af Visual Studio .NET. Anders Hejlberg har
også
> sat sit tydelige præg på C#, 2-way visual editing (som Microsoft har
betalt
> Borland mange penge for at at bruge) og WinForm klassebiblioteket.

Spørgsmål ?
'WinForm' erstatter det MFC, eller hur ?
Og indeholder Visual Studio .NET så både en C++ compiler og en C# fortolker
(til erstatning for Visual J++som vist ikke slog an) ?
Bruger Visual Studio .NET C++ og C# begge klasse biblioteket 'WinForm' ?
Bruger 'WinForm' STL istedet for Microsoft specifikke Streng og container
klasser ?

---

Hejsa.

"Niels Erik Danielsen" <ned@post6.tele.dk> wrote in message
news:3c3c87bf$0$269$edfadb0f@dspool01.news.tele.dk...
> 'WinForm' erstatter det MFC, eller hur ?

WinForms er et klassebibliotek til .NET platformen, hvor MFC er et
klassebibliotek til C++.

> Og indeholder Visual Studio .NET så både en C++ compiler og en C#
fortolker

Ja.
C# er dog ikke fortolket men oversat.

og så er der to oversættere i VS.NET
en "managed C++", der gør det muligt at oversætte kode der skal køre på .Net
platformen. Det er tydeligvis
en modificeret version, da .net ikke svarer helt overens med C++... f.eks.
er der som du nok har gættet en garbage collector.
og så en native C++ oversætter, der oversætter til ren maskinkode.

> (til erstatning for Visual J++som vist ikke slog an) ?

Jeg tror MS vil blive fornærmet over den beskrivelse.. der er _meget_ mere i
..NET og C#

> Bruger Visual Studio .NET C++ og C# begge klasse biblioteket 'WinForm' ?
Ja, Managed C++ og C#. Ikke native C++.

> Bruger 'WinForm' STL istedet for Microsoft specifikke Streng og container
> klasser ?
..net platformen har sit eget klassebibliotek.
Hvorvidt man kan bruge STL i managed C++ kode, ved jeg ikke.

mvh Jonas

---

"Niels Erik Danielsen" <ned@post6.tele.dk> wrote in message
news:3c3c87bf$0$269$edfadb0f@dspool01.news.tele.dk...
>
> "Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
> news:a16uh3$1vnr$2@news.cybercity.dk...
>

>
> Det var noget af en forskel !
>

Ja.
Men performance er jo ikke den eneste parameter.
Det er et atypisk scenarie, så man skal passe på med at ekstrapolere.


> > Prøv at se hvordan Microsoft Visual Studio .NET ser ud.
>
> Er den frigivet, eller er den i beta ?
>

Den findes som Release Candidate.
Den frigives reelt den 13 februar.

>
> Spørgsmål ?
> 'WinForm' erstatter det MFC, eller hur ?

Jo, det kan man vel godt sige.

> Og indeholder Visual Studio .NET så både en C++ compiler og en C#
fortolker
> (til erstatning for Visual J++som vist ikke slog an) ?

C# bliver compileret til MSIL (Microsoft Intermediate Language - svarer
rundt regnet til Java Bytecode).
J++ er genopstået som J#, som gør det muligt at bruge Java syntaks til at
skrive .NET programmer.

> Bruger Visual Studio .NET C++ og C# begge klasse biblioteket 'WinForm' ?

Både og.
C++ findes i en "Managed C++" som kan bruges til at skrive .NET programmer
med.
Det er temmeligt forskelligt fra ISO C++: f.eks. single-rooted hierachy,
garbage collection etc. som i C#.
"Managed C++" og C# bruger samme klassebibliotek, som findes i .NET
platformen
"WinForm" er den del af det klassebibliotek, der benyttes til at lave GUI
applikationer til afvikling på klient-maskinen - altså tykke klienter.
Der findes dog ikke en visuel interaktiv GUI designer til "Managed C++".
Det leveres af Microsoft kun til C#, Visual Basic .NET og J#. Så WinForm, er
ikke lige så nemt at bruge fra "Managed C++".
Man kan formodentlig bruge det programmatisk i "Managed C++" - det giver
bare ikke nogen mening. Det er bedre at skrive brugergrænseflade til .NET
med C#.

> Bruger 'WinForm' STL istedet for Microsoft specifikke Streng og container
> klasser ?
>

Nej, alle klasserne i .NET (ikke kun WinForm) er specikke for .NET fordi de
skal deles mellem de forskellige programmeringssprog.
Derfor giver ISO C++ Standard Library ikke rigtigt nogen mening på .NET
platformen.
Der er f.eks. ikke nogen af sprogene der understøtter noget der ligner
templates. Det siges dog at C# med tiden formodentlig vil få noget
lignende - men mere er vist ikke offentliggjort.

Man kan med Visual C++ .NET binde ISO C++ og Managed C++ sammen, således at
funktionalitet skrevet i ISO C++ kan stilles til rådighed for f.eks. C#
programmer.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Hvis du bruger C++Builder V5.0, kan du definere forskellige desktop
> opsætninger. Det syntes jeg hjælper på det.

Hvordan gør man det?

> Mine målinger siger at programmer oversat med Borland C++ typisk kører halvt
> så hurtigt som det samme program oversat med Visual C++.

Det er også min erfaring (well Builder kode er ca. halvt så hurtigt
som både GCC og Borlands egen pre-Builder compiler. Jeg har ikke
testet mod Visual C++).

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> > Hvis du bruger C++Builder V5.0, kan du definere forskellige desktop
> > opsætninger. Det syntes jeg hjælper på det.
>
> Hvordan gør man det?
>

Man bruger toolbaren "Desktops" (hvor der er en drop-down list, og 2
knapper)
Stil cursoren i drop-down listens edit-kontrol og trk F1, så får du en
beskrivelse af funktionaliteten.

Venlig hilsen

Mogens Hansen

---