Kompilatorer för C/C++

BeatBox->Där är vi nog av skilda åsikter verkar det som...

De flesta Windowsprogram som jag skapar på arbetet, är helt och hållet baserade på de "vanliga" standard och Win32 API grafiska komponenter. De skär sig inte alls på något sätt. Andra komponenter som jag använt, tex olika sockets mm. är rena funktionsbibliotek utan grafisk inblandning.

ActiveX komponenter och COM komponenter funkar i C++ Builder också!
(jag vågar inte svära på hur kompatibla de är mot Microsoft VS, men det är ju rena OCX och DLL filer man skapar, precis som det är tänkt med Active X och COM)

/T

De flesta Windowsprogram som jag skapar på arbetet, är helt och hållet baserade på de "vanliga" standard och Win32 API grafiska komponenter. De skär sig inte alls på något sätt. Andra komponenter som jag använt, tex olika sockets mm. är rena funktionsbibliotek utan grafisk inblandning.

Alla Borlands egna komponenter är ju bara en inkappsling av befintliga saker som finns som standard i windows. En socket i Buildern bygger på winsock. Vaför bygga ett eget skal runt allt istället för att t ex kapsla in allt mha COM ?

Prova att göra om ett formulär till en ActiveX och kör sedan den i IE. Fungerar otroligt dåligt.

ActiveX komponenter och COM komponenter funkar i C++ Builder också!

Visst funkar det men alla komponenter måste vara IDispatch-baserade. Inga vtable interface stöds av Builder. Väldigt dummt.

// BeatBox

Visst "funkar" vtable (VTable interface i BCB)

Börjar undra lite över vilken version av BCB du använt/kollat på.
I version 5 som jag har, funkar allt som jag provat klockrent, även ActiveX i Internet Explorer. Även COM+ event objekt osv.

Misstänker att du kanske menar att det blir problem om man ska flytta koden från BCB till Visual Studio eller?

En socket i Buildern bygger på winsock.

Javisst, det är ju objektorienterad programmering, och det är så det är uppbyggt...

Att kapsla i allt i ett COM objekt kanske bara är något som du rekommenderar, möjligtvis för en webbapplikation.

För en Windowsapplikation, så brukar man inte använda komponenter för grundfunktionerna, utan mer för standardiserade tilläggsfunktioner. Iof. är detta kraftigt beroende på applikationstyp.

/T

I version 5 som jag har, funkar allt som jag provat klockrent, även ActiveX i Internet Explorer.

Eftersom de meddelanden som skickas till Borlands egna kontroller är i många fall vm_user + xxx så funkar det inte alls i så bra. Jag gjorde en chatt en gång och då jag konverterade den till en ActiveX så slutade hälften av alla meddelanden att fungera. ActiveX-wrappern käkade upp meddelande så dom inte kom fram till min kontroll. Kollade själv detta med Spy.

Att kapsla i allt i ett COM objekt kanske bara är något som du rekommenderar, möjligtvis för en webbapplikation.

För en Windowsapplikation, så brukar man inte använda komponenter för grundfunktionerna, utan mer för standardiserade tilläggsfunktioner. Iof. är detta kraftigt beroende på applikationstyp.

Kanske inte allt behöver man kapsla in men jag tycker det är otroligt dummt gjort att hitta på ett eget format att lagra komponenter. I VB så kan man plocka in Winsock 2.0 som är en COM-ifiering av winsock. Fungerar alldeles utmärkt och går att använda från VB, Visual Studio och både Builer och Delphi om man skulle vilja det.

// BeatBox

Winsock 2.0 är ett API-bibliotek som inte har ett skit att göra med COM, ActiveX eller något liknande. Däremot så får man tillgång till funktionsanropen för BSD-sockets.

Som vi alla vet kanske så kan man plocka in Winsock Typelib:et i VB, dvs en COM-inkapsling av Winsock 2.0. Om man istället vill gå direkt på API funktionerna så kan man också göra det.

För att förklara igen så finns det alltså ett Typelib som heter Microsoft Winsock.

// BeatBox

Jag har ingen aning om vad du försöker få fram, eftersom Winsock både går att komma åt från MVS och BCB.

Winsock är ju dels ett API, dels en dll fil, winsock.dll, så där får jag nog säga att Chainsaw har "lite" fel.

Känner att den här diskussionen spårar ut rätt bra nu...

Jag tror diskussionen i sig hänger på om man gillar Visual Studio, eller BCB. jag föredrar den senare.

/T

Diskussionen handlade om hur pass bra Bulder är integrerad med övriga Windows. Jag påstod att Builder är ett jättebra alternativ så länge som man håller sig i den "världen". Builder fungerar inte så lysande om man ska ner och gräva i meddelandehantering och sådant på en djupare nivå än bara användandet av komponenter. Om man inte är ute efter nått annat så kanske Builder är bra att använda. Builder har dock bara anpassat sig efter Windows istället för att utnyttja Windows fullt ut vilket jag tycker är trist.

Jag föredrar också Builder så länge man ska göra applikationer som inte ska interaggera med nått annat, typ låta IE vara host åt sin ActiveX. Builder är dock väldigt klumpigt om man ska göra nått lite större projekt, men och andra sidan så är det nog inte tänkt att man ska använda Builder på det sättet heller.

// BeatBox

[OT]

så där får jag nog säga att Chainsaw har "lite" fel

Nja... Winsock är ju från början till slut ett plagiat av BSD-sockets... om det sen i sin API-skepnad är .dll:er eller ej spelar inte så stor roll. Åtkomsten är är ju densamma oavsett vilken miljö man kodar i. Hur sen BCB eller MS-studio lirar är nog lite beroende på hur man använder grejerna oxå. ;)

[/OT]

Mina åsikter

[OT]
Jag håller med BeatBox. Det vore mycket bättre om det var baserat på COM-komponenter, eftersom man då kunde använda samma komponenter i alla utvecklingsmiljöer utan problem. Som det är nu kan man inte ens använda C++ Builder-komponenter i Delphi, vilket är förkastligt med tanke på att man kan göra det motsatta. Jag är dock säker på att det finns en historisk förklaring till VCL. När det skapades var antagligen inte COM något alternativ. Fast det är ingen ursäkt till att det inte kan ändras. VCL har ändrats minimalt sen första versionen.

Själv tycker jag inte om att använda C++ Builder av många skäl. Det är klumpigt, långsamt, dåligt utformat. Men framför allt, det kraschar ofta av oförklarliga orsaker. När det kraschar visas ett felmeddelande som inte ger någon indikation alls på vad felet är, sedan fortsätter allt som om ingenting har hänt eller ett nytt felmeddelande kommer upp. Det värsta är att många av felen i C++ Builder finns kvar i version efter version. De släpper högst ett Service Pack för varje version, vilket fixar till några fel och introducerar några nya. Samma visa är det med nya versioner.

Jag använder version 5 och vågar inte samt har inte råd att uppgradera till version 6. I Borlands nyhetsgrupper står det om alla hemska fel som finns.
Bland annat:
- Det går inte att kompilera Pascal-kod. Detta fixar man med en nedladdningsbar fix.
- Kompilatorn ger inget radnummer till rader efter ”break”.
- Det är tre gånger så långsamt som version 5.
- Det fortsätter att krascha lite då och då.
- Många gamla fel finns kvar.

Uppgraderingen kostar 4000 kr.

Re: Mina åsikter

Ursprungligen av Swey [OT]
Det vore mycket bättre om det var baserat på COM-komponenter, eftersom man då kunde använda samma komponenter i alla utvecklingsmiljöer utan problem.

Det går väl att använda COM-komponenter eller?

Re: Re: Mina åsikter

Ursprungligen av jt
Det går väl att använda COM-komponenter eller?

Jo, visst. Som det står i tidigare inlägg.

Re: Re: Re: Mina åsikter

Ursprungligen av Swey
Jo, visst. Som det står i tidigare inlägg.

Om det nu går att anväda Com-komponenter och jag antar att det även går att skapa dessa. Då kan ju tex även Delphi använda dina komponeter skapade i CBuilder vad är då problemet?

Använder mest Delphi och försöker undivka com-komponenter, tycker alltid man lyckas få problem när dom ska/har installeras hos klienten.

Jag känner att det börjar bli lite förvirrat.

Använder man C++ Builder så använder man VCL. VCL-komponenter skapade i C++ Builder går inte att använda i Delphi.

Visserligen kan man skapa COM-komponenter i C++ Builder också, men VCL är mycket enklare och mer anpassat till just C++ Builder. Dessutom har jag aldrig skapat någon COM-komponent. :)

Nu är det en ihopblandning av VCL komponenter och COM komponenter...

/T

Om det nu går att anväda Com-komponenter och jag antar att det även går att skapa dessa. Då kan ju tex även Delphi använda dina komponeter skapade i CBuilder vad är då problemet?

Då har vi två utvecklingsmiljöer. Vad gör du om du sitter med Builder och ska göra nått som ska användas i Visual Interdev ?

Använder mest Delphi och försöker undivka com-komponenter, tycker alltid man lyckas få problem när dom ska/har installeras hos klienten.

Precis ! Det är precis det den här debatten handlat om hela tiden. Så länge man håller sig till Delphi eller Bulder så fungerar det jättebra men om man ska interaggera med Windows på en lite djupare nivå så funkar det inte så lysande.

Som sagt var tidigare... Bilder och Delphi är jättebra om man ska göra små applikationer baserat på de VCL:er som följer med. Prova att t ex utvecka en multi-layer drivrutin för t ex ett ljudkort i Builder eller Delphi.

// BeatBox

Då har vi två utvecklingsmiljöer. Vad gör du om du sitter med Builder och ska göra nått som ska användas i Visual Interdev ?

Stöder Visual Interdev ActiveX(com-komponenter) så bör det inte vara några problem. Det finns många Vcl-komponenter som även säljs i en ActiveX version till Visual Basic,Visual C++.... .

Precis ! Det är precis det den här debatten handlat om hela tiden. Så länge man håller sig till Delphi eller Bulder så fungerar det jättebra men om man ska interaggera med Windows på en lite djupare nivå så funkar det inte så lysande.

De problem jag tänkte på har inget med utvecklingsverktyg att göra utan är mer ett allmänt problem med ActiveX komponenter.

Stöder Visual Interdev ActiveX(com-komponenter) så bör det inte vara några problem. Det finns många Vcl-komponenter som även säljs i en ActiveX version till Visual Basic,Visual C++.... .

Jo, men om du gör nått eget som ska användas i Visuual Interdev ? Hur gör du då ? Du packar den som en ActiveX givetvis.... problemet är bara att ActiveX-containern som håller din VCL filtrerar bort en massa meddelanden så att de inte når fram till din VCL. Du upptäcker till din fasa att den RichControl som du använder inte alls fungerar i "AvtiveX-packningen". Det är bara att köra Spy++ för att verifiera att containern suger åt sig meddelanden och släpper inte dom vidare till din VCL.

De problem jag tänkte på har inget med utvecklingsverktyg att göra utan är mer ett allmänt problem med ActiveX komponenter.

Eftersom teknologin är utvecklad av Microsoft och fungerar alldeles ypperligt så ligger ju problemet hos Buildern. Föressten... hela nya .NET bygger på COM.

// BeatBox

Det finns säkert buggar/problem i BCB.

De problem jag skriver om har att göra med installation odyl av program som använder ActiveX.
1. Man måste installera dessa. Det räcker inte att skicka med Exe-filen.
2. En annan version av activeX komponent installeras på samma maskin vilket har lett till problem.
3. Diverse problem med Registret i windows
Vissa av problemen kan säkert bero på felaktiga installations/avinstallations program. Men använder man inte ActiveX utan bara "native" komponenter (tex Vcl) så slipper man dessa problem.

>Föressten... hela nya .NET bygger på COM.
Jag har fått intrycket att det är precis tvärtom :-). Att .Net stöder COM teknologin men att Microsoft sakta överger den.

Lite mycket OT, avslutar nog denna disskusion nu.

De problem jag skriver om har att göra med installation odyl av program som använder ActiveX.

1. Du måste också installera dina egenutvecklade VCL:er också.

2. Löst i .NET

3. Också löst i .NET

Jag har fått intrycket att det är precis tvärtom :-). Att .Net stöder COM teknologin men att Microsoft sakta överger den.

Det skulle man inte direkt kunna påstå att Microsoft gör :-) I .NET är allt COM-komponenter fast man har nu dolt det för programmeraren. Dock är det COM som används under ytan. :-)
Läs om .NET i Microsoft Journal så får du se. (eller i MSDN... där står det faktiskt en del om .NET). Dock överger dom MFC, men det kanske inte va det du tänkte på. VB6 överger dom också.

// BeatBox