Kompilatorer för C/C++

Om alla objekt är ett COM-objekt... Innebär inte det en ruskig overhead varje gång som man skapar ett nytt objekt? Trots allt så är det inte bara den vanliga kedjan att allokera minne, köra konstruktor och sånt larv - objektet måste genomgå hela COM-proceduren också.

>Du måste också installera dina egenutvecklade VCL:er också.
Det går ju att kompilera in allt i exefilen.

Försökte hitta lite information om COM och .Net. Men jag tycker dom beskriver .Net och Com som två skillda saker. Har inte använt .Net så jag kan säkert missuppfattat någon av alla dessa nya förkortningar. .Net verkar hursomhelst ganska intressant.

http://arstechnica.com/paedia/n/net/net-5.html
"For the time being, at any rate, pure .NET can't replace COM. It does become, however, a legacy technology."

Upgrading to Microsoft .NET
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/callcomcomp.asp
"There are two key concepts that make it much easier to move from COM development to .NET development without any loss of code base or productivity
.NET components can call COM components.
COM components can call .NET components."

http://msdn.microsoft.com/msdnmag/issues/01/08/Interop/Interop.asp
"The demise of COM has been greatly exaggerated"

I första artikeln beskriver dom det så här :

COM is all native code, and requires programmers to be conscious of many low-level details which make development using the full power of the technology more burdensome. .NET makes these issues disappear. It takes care of the details for you.

Fortfarande bygger det på COM men för programmeraren så syns det inte lika mycket längre. COM componenter kan inte köras rakt av i .NET. Du kan ju fortfarande göra COM componenter (eller .NET componenter mha ATL.

Mer finns att läsa i en artikel av Don Box (COM gurun nummer 1)

Längst ned säger han så här om .NET :

As this column has shown, the CLR provides significant benefits to developers who are using COM today. Virtually all aspects of the COM programming model have survived (interfaces, classes, attributes, context, and so on). Some may consider COM dead simply because CLR objects don't rely on IUnknown-compliant vptrs/vtbls. I look at the CLR as breathing new life into the programming model that I've spent the last seven years of my life working with, and I know there are other programmers out there who share this sentiment.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/com1200.asp

Nog om detta....

// BeatBox

Chainsaw-> Du har helt rätt. En COM komponent är inget annat än en .dll fil som man i programmet gör en koppling till. Detta skapar en hel del overhead. Därför så brukar man i "rena" Windowsprogram använda dessa ganska sparsamt, samt vid speciella tillfällen.

Däremot så är komponenter vid webbapplikationer lite annorlunda, eftersom dessa laddas och cachas, och sedan "finns där"

Jag förstår inte alls Beatbox, inte heller hans argument. Builder klarar COM och COM+ komponenter galant. Att det sedan blir strul i olika utvecklingsmiljöer är möjligt, men rent policymässigt håller man sig till utvecklingsmiljöer så man slipper dessa problem.

Det går jättebra att skapa drivrutiner och VxD's med Builder, jag gör det ofta i arbetet. Och servic'es funkar ypperligt också...

Att en gridcontrol (eller annat grafiskt gränssnitt för den delen) inte funkar i en komponent, antagerligen för något klassarv från en annan grafisk komponent, så är det ditt fel som programmerare. Man ska ju inte lägga in sådana saker i komponenter som inte stöds fullt ut eller följer standard. Då har man ju missat hele poängen.

Komponenter i .Net funkar lite annorlunda, då de är "självbeskrivande" för op-systemet, och inte behöver registreras. Man kopierar bara in komponenterna i den mapp man vill ha dom, sedan är det bara att "köra" på.

"gamla" komponenter funkar som vanligt. Även om man kör .Net applikationer på datorn. (som i alla XP installationer, där de samsas)

/T

Du har helt rätt. En COM komponent är inget annat än en .dll fil som man i programmet gör en koppling till. Detta skapar en hel del overhead. Därför så brukar man i "rena" Windowsprogram använda dessa ganska sparsamt, samt vid speciella tillfällen.

En DLL är bara en packetering av typlibet. För övringt så är de flesta lite större progam uppbyggda mha COM. Kolla t ex på WORD, Excells eller IE:s automationmodell.

Jag förstår inte alls Beatbox, inte heller hans argument. Builder klarar COM och COM+ komponenter galant.

Hur gör du t ex en egen klassfabrik i Builder ? Eller en Universial delegator ? Eller en egen Moniker ?

Komponenter i .Net funkar lite annorlunda, då de är "självbeskrivande" för op-systemet, och inte behöver registreras.

Det kan man bestämma. Det är därför det nya begreppet "Assembly" har införts.

"gamla" komponenter funkar som vanligt. Även om man kör .Net applikationer på datorn. (som i alla XP installationer, där de samsas)

För övrigt så levereras .NET CLR:en inte med XP som default.

// BeatBox

I Word och Excel och andra Windowsprogram så används komponenterna ofta inte för programmets huvuduppgift, utan mer för saker som stavning, utskrift, sök mm.
Visserligen så är i stort sett hela IE en komponent...

Klassfabrik i Builder är Class Factory, en instansiering av CoClass. det gör man enklast med Wizard'en.

Monikers med CoCreate eller mkclass ev. med DCOM

COM/COM+ mm. funkar i C++ Builder, inget snack om saken, men jag börjar förstå vad du är ute efter, nämligen kompatibilitet mellan utvecklingsplattformarna?

Jag kan även hålla med om att man utnyttjar hela Windows som plattform bättre med Visual Studio, men när man som jag (eller vårat företag) skapar programvaror som är väldigt självständiga, så är inte kravet stort att använda Visual Studio (även om vi använder det också)

Jag har helt enkelft fastnat för C++ Builder för att det är så kraftig objektorientering, ända ut i de grafiska detaljerna. Gränssnittet fixar man på nolltid, och kan då lägga krutet på kodningen i egna funktioner/metoder.

Men detta är iof. en smaksak. Kommer antagerligen inom kort köra .Net, fast då med C++ och kompilering i native kod, dvs. inte använda MSIL/CLR. Vi är nämligen ganska maskinnära med de signalsystem (flygdata, telemetri) vi skapar.

Kanske mindre projekt med C# i ren .Net anda...

/T

Jag kan inte prata för andra, men den lilla programmering i C++ som mitt företag gör är enbart skrivet i C++ Builder och för plattformat som stödjer STL. Någon idiot före oss valde att använda Visual C++ och MFC, vilket har resulterat i en total katastrof eftersom hela klassbiblioteket uppmuntrar till dålig hantering av klasser, objektorientering, namngivning och andra saker. För att inte tala om den katastrofzon till människa som valde VB framför allt annat, vilket lett till enorma buggfixar tack vare icke-OO-system och -kod.

Tack gode gud för att jag själv får jobba med Java. Det enda som hade varit bättre vore Python.

Eftersom STL är en del av C++ standarden så förstår jag inte riktigt.

Någon idiot före oss valde att använda Visual C++ och MFC, vilket har resulterat i en total katastrof eftersom hela klassbiblioteket uppmuntrar till dålig hantering av klasser, objektorientering, namngivning och andra saker

Det blir ju lätt så om man inte följer document-view konceptet. En klass som lagar data och en klass som visar UI:t. Det står beskrivet i MFC-böcker hur man ska göra.

// BeatBox

Håller med Chainsaw, MFC's hela upplägg är mycket underligt med tanke på objektorientering. När man skapar ett Windows program med MFC så ser det ut som en blandning av C och C++, en massa "rena" funktionsanrop utan någon klaskoppling.

I min branch så funkar inte Java, iof. bara för att jag/vi helt enkelt inte kan använda det, eftersom prestanda och maskinnära funktioner är ett måste i realtidsimplementeringar...

/T

När man skapar ett Windows program med MFC så ser det ut som en blandning av C och C++, en massa "rena" funktionsanrop utan någon klaskoppling.

Man har en dokumentklass som håller data och en vyklass som presenterar UI:t. Om du upplever MFC på detta sätt som du besktiver så använder du MFC helt fel.

// BeatBox

Okej, säg att vi har en dokumentklass och en vyklass. Det saknas en enormt viktig komponent här: controllern. Säg att du ska klistra in lite text någonstans. Vilken av objekten sköter det, hur går det till och varför?

Let's face it, MFC är ingen höjdare. Inkapslingen är nära nog noll, vilket ju givetvis är helt fel. Försök bara att sätta texten på en label till fet genom att använda de metoder som det objektet har.

Försök bara att sätta texten på en label till fet genom att använda de metoder som det objektet har.

CFont är annars en MFC klass som sköter detta. CStatic ärver från klassen CWnd. CWnd inehåller metoden SetFont som tar ett CFont objekt. Obektorienterat och bra !

// BeatBox

Okey beatbox, du verkar kunna MFC, så känn på den här:

Du vet säkert hur man laddar en bitmap från en fil och visar den med MFC. Det är några rader, speciellt vid 256 färgers bitmappar.

I C++ Builder gör man följande ("otroligt" objektanpassat)

Image->Picture->LoadFromFile("smile.bmp");

Visst, det är säkert ungefär samma kod som finns bakom i hjälpklasser och dess källkoder, men poängen här är att det funkar helt och hållet bakom ridåerna. Som programmerare är detta en njutning.

Är jag inte nöjd med dessa klasser, så kan man ju fixa en egen wrapper, med egna metoder.

/T

Visst, det är säkert ungefär samma kod som finns bakom i hjälpklasser och dess källkoder, men poängen här är att det funkar helt och hållet bakom ridåerna. Som programmerare är detta en njutning.

Om man jämför MFC och Builder så är dessa uppbyggda ungefär på samma sätt. Man har en root-klass som ärvs ned till någonting annat som i sin tur ärvs ned till en 3:e sak. På samma sätt funkar det i MFC.

T ex

MFC :

CBitmap ärver från CGdiObject som ärver från CObject.

I Builder :

TImage ärver från TComponent som ärver från TObject.

Troligtvis så har Builder och Delphi kikat på MFC:s arkitektur. MFC 1.0 släpptes April 92. Första versionen av Delphi kom 95.

// BeatBox

Så vad *är* koden för att göra text i en label fet eller för att ladda en bild? VCL-klasserna har ju den äkta inkapslade objekt->Font->Bold = true; för i stort sett alla operationer. Andra roliga experiment kan vara att skapa en ny kontroll under körning, exempelvis en klass vid namn AndBlock som ärver från TImage. I Builder gör man en new, talar om left+top+width+height och sedan bara fungerar det. Funkar det på liknande sätt i MFC, eller?

CBitmap::LoadBitmap(ResursID eller sökväg)

CStatic::SetFont(CFont* pFont, BOOL bRedraw = TRUE );

Här kan man implemtntera ett eget fontobject som kan göra precis vad som helst.

I Builder gör man en new, talar om left+top+width+height och sedan bara fungerar det. Funkar det på liknande sätt i MFC, eller?

CEdit* pEdit = new CEdit;
pEdit->Create(ES_MULTILINE | WS_CHILD | WS_VISIBLEWS_TABSTOP | WS_BORDER,
CRect(10, 10, 100, 100), this, 1);

CRect (left, top, right, botom)

// BeatBox

Men det försvann visst lite, eller?

CBitmap::LoadBitmap()

Laddar ju bara en bitmap. Kod behövs för att den ska visas, med BitBlt, eller?

Samma med

CStatic::SetFont()

Man måste väl gå omvägen via LOGFONT? och där sätta .lfWeight? ytterligare kod. Det blir inga enraderslösningar.

Det är ju dessa omvägar man slipper med perfekt inkapsling, som i Builder (som Chainsaw nämnde)

objekt->Font->Bold = true;

Kan ytterligare tilläggas att händelsehanterare skapas automatiskt för dessa objekt, dvs om jag klickar, drar musen osv. över bitmappen eller den statiska texten, så finns de där automatiskt.

/T

C++ Builder är underbart. Allting är objektorienterat och inkapslat så väl att man kan glömma bort att det är Windows man programmerar för. Dock är det inte användbart med tanke på vad jag skrivit tidigare.

MFC är utformat för C-programmerare som är vana vid att programmera för Windows i C, och vill kunna använda klasser utan att behöva lära sig något. Alla funktioner och klasser har samma namn som C-motsvarigheten och fungerar också på samma sätt. MFC är helt enkelt inget bra designat klassbibliotek.

Välj inte MFC eller BCB utan något annat. Vad vet jag dock inte.

MFC är utformat för C-programmerare som är vana vid att programmera för Windows i C,

Kan det månne bero på att API:et är i C? :e

Men jag håller med, trots min något ringa erfarenhet av MFC. Tycker att det verkar tämligen tunggrott med detta objektorienterade "lager" ovanpå en rent strukturerad kärna... BCB har löst det snyggt med OOP:n, medans MFC kanske är bra för rapid solutions om man bara öser på i ren windows miljö. Gjorde nyss ett tetrisspel som proj-uppgift, det tog inte lång stund att bygga upp mina egna klasser (som lätt kan implementeras i vilken annan normal OOP miljö som helst), det som tog tid var att implementera det
i det #@!¤ MFC med sina doc/view (krav av examinatorn) ;)

:birp

MFC är utformat för C-programmerare som är vana vid att programmera för Windows i C, och vill kunna använda klasser utan att behöva lära sig något.

Om man tittat på klassdiagrammet i Builder och klassdiagrammet i MFC så är dessa nästan på pricken lika. Bara det att MFC kom 92 och första versionen av Delphi kom 95. OO är lite mer än aggretion och arv, men det kanske du vet redan. Eller ?

MFC är inte direkt bra. Det är ganska bökigt att göra saker, men nu va det den djupa integrationen med Windows vi egentligen pratatde om. Och tyvärr så måste man ned på Win32 nivå.

Pew :

Gjorde nyss ett tetrisspel som proj-uppgift, det tog inte lång stund att bygga upp mina egna klasser (som lätt kan implementeras i vilken annan normal OOP miljö som helst), det som tog tid var att implementera det
i det #@!¤ MFC med sina doc/view (krav av examinatorn)

Jag kan hålla med om att MFC har en rätt hög tröskel innan man förstår det här med doc-view konceptet. Om man inte förstår det blir allt en enda soppa och det slutar med att man lägger allt i vyn.
Microsoft själva säger ju att dom ska sluta supporta MFC pga införandet av .NET.

Toonster :

Kan ytterligare tilläggas att händelsehanterare skapas automatiskt för dessa objekt, dvs om jag klickar, drar musen osv. över bitmappen eller den statiska texten, så finns de där automatiskt.

Visst är det snyggt då Borland löst det så att då man t ex klickar på en bild så skickas inte VW_BTNCLICK (standard windows event) utan WM_USER + XXX ? Det är precis därför hälften av eventen försvinner om man packeterar den som en AvtiveX. Förklarade det tidigare men jag tror inte det gick hem.

// BeatBox