C/Gobject vs C++

donderdag 6 september 2001 23:55

Moderator Devschuur®

Demotivational Speaker

kijk eens aan, nog een voorbeeld van een stel programmeurs die de Tao duidelijk (nog) niet bemeesteren

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

left part of the evil twins

Op donderdag 06 september 2001 17:37 schreef OiSyN het volgende:
kijk eens aan, nog een voorbeeld van een stel programmeurs die de Tao duidelijk (nog) niet bemeesteren

ROFL

En on-topic over de GObject vs. C++ kwestie:

We hebben het hier vorige week al even over gehad, en ook toen zag ik het nut al niet. Het hele onderwerp is eigenlijk je reinste onzin, want je emuleert helemaal geen C++ vanuit C: je geeft structs op een gefakete manier memberfuncties, meer niet.

En da's wel heel leuk, maar het belangrijkste punt van C++ kun je niet faken: VIRTUAL. Geen virtual destructors, geen virtual functie overloads, geen abstract baseclasses, geen interfaces. Tevens heb je geen member-access control en andere typische OOP dingen. Inheritance kun je faken door aggregatie, maar het blijft toch anders. C is niet OOP. Punt.

De vraag is dus eigenlijk niet of ze C sneller vonden dan C++ of zo want dat is het niet per definitie, alleen als je exceptions en RTTI/virtual gebruikt krijg je overhead. Ik denk dat ze gewoon vonden dat ze 95% van de C++ functionaliteit niet nodig hadden, en die 5% (memberfuncties) liever emuleerden zodat het framework zowel compatible met C als C++ bleef omdat je dan een veel grotere userbase hebt.

My 2 cents.

vrijdag 7 september 2001 11:15

Acties:

Verwijderd

Op donderdag 06 september 2001 23:55 schreef curry684 het volgende:
En da's wel heel leuk, maar het belangrijkste punt van C++ kun je niet faken: VIRTUAL. Geen virtual destructors, geen virtual functie overloads, geen abstract baseclasses, geen interfaces. Tevens heb je geen member-access control en andere typische OOP dingen. Inheritance kun je faken door aggregatie, maar het blijft toch anders. C is niet OOP. Punt.

Kijk nu eens in beelze's code. Volgens mij wordt hier een virtual methode scene_selected gedefinieerd:

code:

struct _GtkSceneListClass
{
    GtkWidgetClass parent_class;

    void (*scene_selected) (GtkWidget *widget, gint scene_num);
};

vrijdag 7 september 2001 11:53

Acties:

left part of the evil twins

Op vrijdag 07 september 2001 11:15 schreef mietje het volgende:
Kijk nu eens in beelze's code. Volgens mij wordt hier een virtual methode scene_selected gedefinieerd:

Ware het niet dat de compiler er geen probleem mee heeft als je deze 'class' instantieert zonder de method te implementeren (bye-bye abstractie/interfaces), en dat ik in de afgeleide class (die ik niet kan afleiden: bye-bye inheritance) graag een default parameter wil toevoegen waardoor de virtual functie in de base class hidden wordt (wat de base-functie niet kan hiden: bye-bye virtual). Oh en ik wil natuurlijk in de afgeleide functie ook de originele implementatie aanroepen dmv. 'BaseClass::Function(...)', wat niet kan omdat er geen virtual function table is.

Your point?

vrijdag 7 september 2001 11:56

Acties:

Verwijderd

Topicstarter

/me snapt er ff niks van....

Wat is het hele nut van virtual methodes?

Het feit dat ik daar het nut niet van inzie en dat ik uberhaupt niet weet wat het is zal ook wel eraan meehelpen dat ik niet zoveel verschil tussen C++ en C/GObject zie

vrijdag 7 september 2001 12:03

Acties:

left part of the evil twins

Ik zal het eens proberen te tonen, ik wil graag een C versie van de volgende code zien die op dezelfde manier functioneert van buitenaf (alle functies doen iets printen als ze niet pure virtual zijn of hier gedefinieerd):

code:

class A
{
public:
  virtual   ~A();
  virtual void  Function() = 0;
};

class B : virtual public A
{
public:
  virtual   ~B();   
};

class C : virtual public A
{
public:
  virtual void  Function();
};

class D : public B, public C
{
public:
  virtual   ~D();
  virtual void  Function(int Blah = 5)  
    {
    printf("Hoi");
    C::Function();
    }
};

int main()
{
B*    Object1 = new D;
C*    Object2 = new D;
Object1->Function();
Object2->Function();
(dynamic_cast<D*>Object1)->Function(10);
delete Object1;
delete Object2;
}

Ik ben benieuwd....

vrijdag 7 september 2001 12:28

Acties:

Verwijderd

Op vrijdag 07 september 2001 11:53 schreef curry684 het volgende:
Ware het niet dat de compiler er geen probleem mee heeft als je deze 'class' instantieert zonder de method te implementeren

Klopt, als je OOP in een non-OOP taal simuleert zul je initialisaties met de hand moeten doen die een OO-taal automatisch doet.

Oh en ik wil natuurlijk in de afgeleide functie ook de originele implementatie aanroepen dmv. 'BaseClass::Function(...)', wat niet kan omdat er geen virtual function table is.

Er is dus wel een vtable

Als je goed naar de code kijkt, zie je dat er voor elke nieuwe class twee structs gedefinieerd worden. Een object-struct die de object aggregaten definieert, en een class-struct die een vtable implementeert. Via die cast macro's kan zowel een object als een object-class ge-upcast/downcast worden.

vrijdag 7 september 2001 13:15

Acties:

vrijdag 7 september 2001 13:33

Moderator Devschuur®

Demotivational Speaker

Wat ik nog niet snap is het volgende:

Op donderdag 06 september 2001 10:18 schreef mietje het volgende:

[..]

Dat was wel duidelijk. De problemen liggen niet bij de taal maar bij het linken van object files.

C++ heeft operator en function overloading, wat betekent dat een C++ functienaam niet een-op-een vertaald kan worden naar een assembly label. Hieruit volgt dan een C++ compiler een name-mangling scheme moet toepassen om de niet-unieke C++ functienamen om te zetten naar unieke assembly labels.

Het probleem ligt nu bij deze name-mangling schemes: Niet alle compilers passen de zelfde methode toe. Dit betekent dat libraries en object files gecompileerd met de ene compiler, niet bruikbaar zijn voor een compiler die een ander scheme toepast.

Als je wilt linken met andere in C geschreven software, dan moet je dus een setje functies definieren waarvan gebruik wordt gemaakt. Volgens jou is de reden dat ze geen C++ hebben gebruikt omdat ze een functie wilde implementeren waarmee vervolgens niet gelinkt kon worden, omdat die C++-functienaam gemangled wordt. Klopt dat tot dus ver?

Als dat zo is, dan zie ik het probleem niet. Als ik bijvoorbeeld de c-functie void doeIets (int arg1, int arg2) moet definieren, en ik geef de voorkeur aan C++, dan maak ik gewoon een C++ bestandje met het volgende:

doeiets.cpp:

code:

extern "C" void doeIets (int arg1, int arg2);

void doeIets (int arg1, int arg2)
{
    // hier kun je dus heel leuk klassen instantieren en
    // gebruik maken van andere leuke C++ mogelijkheden
}

Dit is dus gewoon een C++-functie die niet gemangled wordt

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

left part of the evil twins

Op vrijdag 07 september 2001 12:28 schreef mietje het volgende:
Er is dus wel een vtable Als je goed naar de code kijkt, zie je dat er voor elke nieuwe class twee structs gedefinieerd worden. Een object-struct die de object aggregaten definieert, en een class-struct die een vtable implementeert. Via die cast macro's kan zowel een object als een object-class ge-upcast/downcast worden.

Okee, leuke hack waarmee je deels een beetje C++ functionaliteit emuleert ten koste van enorm veel overhead en resources. Pak dan meteen C++.

I don't see the point.

vrijdag 7 september 2001 13:58

Acties:

Xiphalon

Misschien leuk om te weten, maar de 1e C++ compilers (met virtual methods) 'compileerden' de C++ code naar C...

't zal dus wel mogelijk moeten zijn om alle C++ constructies in C te maken.

bdw, heeft iemand nog zo'n compiler?? of kan er ergens een vinden?

vrijdag 7 september 2001 14:20

Acties:

Verwijderd

Op vrijdag 07 september 2001 13:15 schreef OiSyN het volgende:
Als je wilt linken met andere in C geschreven software, dan moet je dus een setje functies definieren waarvan gebruik wordt gemaakt. Volgens jou is de reden dat ze geen C++ hebben gebruikt omdat ze een functie wilde implementeren waarmee vervolgens niet gelinkt kon worden, omdat die C++-functienaam gemangled wordt. Klopt dat tot dus ver?

Klopt als een bus.

Als dat zo is, dan zie ik het probleem niet. Als ik bijvoorbeeld de c-functie void doeIets (int arg1, int arg2) moet definieren, en ik geef de voorkeur aan C++, dan maak ik gewoon een C++ bestandje met het volgende:

Ok, je gebruikt een extern declaratie, nu deze:

code:

1 2	int max(int a, int b) { return a >= b ? a : b; } double max(double a, double b) { return a >= b ? a : b; }

Of:

code:

class A {
public:
  virtual void doe_iets();
};

class B : public A {
public:
  virtual void doe_iets();
};

Je hebt nu de functie max() en de virtual method doe_iets() overloaded. In C++ hebben deze functies/methodes dus geen unieke naam, en het is niet zonder mangling mogelijk er in C een unieke naam van te maken.

Maw. je hebt alleen link-problemen als je functies niet als extern "C" declareren kunt, omdat ze overloaded zijn.

vrijdag 7 september 2001 14:21

Acties:

Sjonny

Fratser

De redenen die ik nog uit me hersens weet te persen van vroeger zijn

1) portability/compatibility, C++ is er pas sinds begin jaren 90 terwijl C uit de jaren 60/70 (

) komt.
hieruit volgt gelijk:
2) veel meer mensen kunnen C programmeren dan correct C++. En met correct bedoel ik dan het juist toepassen van al die OO methoden, wat een hele kunst is, en niet simpel weg je code copy/pasten in een class en zeggen dat het OO is.

verder vind ik dat deze manier van programmeren compleet ranzig is. die 95/5% opmerking is ook een beetje onzin, want er is steeds meer bij gebouwd, en steeds meer "ge-emuleerd" in C. al die ranzige casts met structs en pointers en weet ik ut wat ze allemaal aan het doen zijn.
Ik vind ook dat een heleboel bugs in gtk (zeker in het begin) aan deze manier van programmeren te wijten valt. in C++ is het veel makkelijker om structurele en modelleer bugs uit je code te halen dan met deze wirwar code.

daarentegen vind ik gnome wel fijner dan kde

The problem is in the part of your brain that handles intelligence.

vrijdag 7 september 2001 14:24

Acties:

roelio

fruitig, en fris.

[quote uit topic post]
Het exacte idee waarom dit ooit zo is gedaan ken ik niet. Ik ga ervan uit dat dit is gedaan omdat C gewoonweg sneller is dan C++, en C/Gobject is dan dus ook sneller dan C++.
[/qoute uit topic post]

dit gaat niet helemaal op. Als C sneller is als C++, dan hoeft C + GObject nog niet sneller te zijn als C++, want C++ is neem ik aan ook in C geschreven?
Dan heb je dus twee objectversies van C, welke dan de snelste is, is dan nog niet bekend!

AMD Phenom II X4 // 8 GB DDR2 // SAMSUNG 830 SSD // 840 EVO SSD // Daar is Sinterklaas alweer!!

vrijdag 7 september 2001 14:36

Acties:

Sjonny

Fratser

Op vrijdag 07 september 2001 14:24 schreef limoentje het volgende:

dit gaat niet helemaal op. Als C sneller is als C++, dan hoeft C + GObject nog niet sneller te zijn als C++, want C++ is neem ik aan ook in C geschreven?
Dan heb je dus twee objectversies van C, welke dan de snelste is, is dan nog niet bekend!

een c++ compiler is meestal (vast wel) in c geschreven. maar dat heeft natuurlijk geen kut te maken met hoe de compiler de executable code genereerd/optimized.

The problem is in the part of your brain that handles intelligence.

vrijdag 7 september 2001 14:43

Acties:

Verwijderd

Op vrijdag 07 september 2001 14:36 schreef Sjonny het volgende:
een c++ compiler is meestal (vast wel) in c geschreven. maar dat heeft natuurlijk geen kut te maken met hoe de compiler de executable code genereerd/optimized.

Zowat alle compilers worden ge-"bootstrapped". Dat betekent dat je eerst een compiler voor taal A in taal B schrijft, en vervolgens de compiler in taal A implementeert, en hem op de eerste compiler compileert.

Dus bootstrap:
1. (simpele) C++ compiler gescheven in bv. C
2. Herschrijf de C++ compiler in C++ en compileer hem op de compiler van stap 1.

<edit>
Dit heeft als voordeel dat je de correctheid van de compiler kunt bewijzen:
3. Compileer de C++ compiler nu op de compiler van stap 2.
4. Vergelijk de gegenereerde code uit stap 2. en stap 3. byte voor byte. Als er verschillen zijn is de compiler niet correct geimplementeerd.
</edit>

vrijdag 7 september 2001 14:48

Acties:

Orphix

C is _niet_ sneller dan C++. code als int a = b + c; zal in beiden gevallen even snel zijn. Als je C++ op deze manier wil emuleren dan heb je echter 1 nadeel: de C compiler weet niet dat je OOP aan het doen bent. Een C++ compiler kent de taal constructies die daarvoor mogelijk zijn en zal die waar nodig zoveel mogelijk optimaliseren (bv geen vtable gebruiken als er maar 1 mogelijkheid is).
Volgens mij is het gewoon nostalgie van de Gnome programmeurs en weigeren ze C++ te gebruiken maar vinden ze OO in een GUI omgeving toch wel handig

vrijdag 7 september 2001 15:00

Acties:

Verwijderd

Op vrijdag 07 september 2001 14:48 schreef Orphix het volgende:
Volgens mij is het gewoon nostalgie van de Gnome programmeurs en weigeren ze C++ te gebruiken maar vinden ze OO in een GUI omgeving toch wel handig

Het heeft dus echt met link problemen en het niet willen binden aan een bepaalde compiler te maken. Exact de zelfde reden waarom de linux kernel niet in C++ maar in C geimplementeerd is. Of die reden echt geldig is, of dat er gewoon een gestandariseerd name-mangling scheme voor C++ compilers moet komen valt natuurlijk te bediscussieren.

vrijdag 7 september 2001 17:50

Acties:

vrijdag 7 september 2001 17:53

Moderator Devschuur®

Demotivational Speaker

Op vrijdag 07 september 2001 14:20 schreef mietje het volgende:

[..]

Klopt als een bus.
[..]

Ok, je gebruikt een extern declaratie, nu deze:
code:
1
2
int max(int a, int b) { return a >= b ? a : b; }
double max(double a, double b) { return a >= b ? a : b; }
Of:
code:
1
2
3
4
5
6
7
8
9
class A {
public:
  virtual void doe_iets();
};

class B : public A {
public:
  virtual void doe_iets();
};
Je hebt nu de functie max() en de virtual method doe_iets() overloaded. In C++ hebben deze functies/methodes dus geen unieke naam, en het is niet zonder mangling mogelijk er in C een unieke naam van te maken.

Maw. je hebt alleen link-problemen als je functies niet als extern "C" declareren kunt, omdat ze overloaded zijn.

Je begrijpt me volgens mij niet helemaal. Want waarom zou je overloaded functies met een c-lib willen linken? Dat spoort gewoon niet.
Met dat doeIets () voorbeeld bedoelde ik dat er een zootje C object files (of een library) waren die refereren naar de functie doeIets (). Jij bouwt een proggie dat gebruik maakt van die object files, en dus moet je een functie doeIets () implementeren. Het heeft totaal geen nut om doeIets () te overloaden, omdat die C object files niet een overgeloade doeIets () kunnen gebruiken. Maar om ALLES gelijk in C te programmeren slaat in principe ook nergens op, omdat je C++ en C object files prima met elkaar kunt mixen.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

vrijdag 7 september 2001 18:13

Moderator Devschuur®

Demotivational Speaker

Op vrijdag 07 september 2001 14:48 schreef Orphix het volgende:
C is _niet_ sneller dan C++. code als int a = b + c; zal in beiden gevallen even snel zijn. Als je C++ op deze manier wil emuleren dan heb je echter 1 nadeel: de C compiler weet niet dat je OOP aan het doen bent. Een C++ compiler kent de taal constructies die daarvoor mogelijk zijn en zal die waar nodig zoveel mogelijk optimaliseren (bv geen vtable gebruiken als er maar 1 mogelijkheid is).
Volgens mij is het gewoon nostalgie van de Gnome programmeurs en weigeren ze C++ te gebruiken maar vinden ze OO in een GUI omgeving toch wel handig

in die richting zaten mijn gedachten idd ook

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

Op vrijdag 07 september 2001 17:50 schreef OiSyN het volgende:
Je begrijpt me volgens mij niet helemaal. Want waarom zou je overloaded functies met een c-lib willen linken? Dat spoort gewoon niet.

Ik begrijp je wel, maar het gaat er niet om dat we code willen implementeren in C, maar dat we op eoa. manier C++ name mangling willen voorkomen. Even een voorbeeldje zodat je het begrijpt.

Je hebt een project met programmeurs Jan en Piet. Jan werkt met compiler x++ en Piet werkt met compiler y++. Compiler x++ mangelt onze virtuals void A::doe_iets(); en void B::doe_iets() naar assembly labels _A_void_doe$iets_void en _B_void_doe$iets_void.

Compiler y++ leest de headers die door Jan geschreven zijn, en genereert labels __Cls_A0doe_iets0 en __Cls_B0doe_iets0. Piet krijgt geen compiler errors als hij zijn code compileert, maar de linker zal een heleboel unresolved symbols melden als Piet met Jan's libraries linkt...

vrijdag 7 september 2001 18:20

Acties:

vrijdag 7 september 2001 18:22

Moderator Devschuur®

Demotivational Speaker

ja maar waarom zou je dat van soort functies NIET willen dat ze gemangled worden? Het zijn toch alleen maar C++ files die ze kunnen gebruiken, en geen C-files

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

vrijdag 7 september 2001 18:51

Moderator Devschuur®

Demotivational Speaker

oooooh wacht ik denk al dat ik het begrijp

ze schrijven dus een lib, maar omdat iedereen verschillende compilers gebruikt (wat me niet logisch lijkt, aangezien de meeste linux programmeurs toch wel gcc gebruiken), en omdat al die verschillende compilers anders manglen, schrijven ze het in C zodat iedereen met elke compiler die lib kan gebruiken

zo goed?

let wel dat er ook c-compilers zijn die c-functies anders manglen (dus bijv. ZONDER underscore ervoor enzo)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

Op vrijdag 07 september 2001 18:22 schreef OiSyN het volgende:
zo goed?

Precies

let wel dat er ook c-compilers zijn die c-functies anders manglen (dus bijv. ZONDER underscore ervoor enzo)

Klopt, maar dat is zo goed als altijd met een optie van de compiler te beinvloeden. Name mangling is een stuk ingewikkelder, en tot nu toe probeert zowat elke compilerproducent zijn oplossing als de standaard door te drukken.

Nog even benadrukken: ik ben helemaal niet overtuigd van die argumenten, maar ze zijn niet irrationeel. Ik programmeer zelf een stuk liever in C++ dan in C.

vrijdag 7 september 2001 22:05

Acties:

Verwijderd

Topicstarter

Op vrijdag 07 september 2001 18:22 schreef OiSyN het volgende:
(wat me niet logisch lijkt, aangezien de meeste linux programmeurs toch wel gcc gebruiken)

Nietes

Er zijn drie:
egcs (egcs++)
gcc (g++)
cc (c++)

En die zijn waarschijnlijk niet compatible..... Ik heb er in elk geval vaak genoeg problemen over gelezen...

Voor kernels is officieel egcs (!!!!!) nog steeds aangeraden als standaard compiler. Sommige distros leveren egcs mee (mandrake?) anderen leveren gcc (redhat)..... cc is de BSD-licensed C-compiler en is voornamelijk in de BSDs meegeleverd maar wordt ook in redhat meegeleverd, geloof ik....

Met een prog als Gtk+, wat onder zowel BSD als linux wil draaien, dus vrij irri

zaterdag 8 september 2001 00:15

Acties:

Verwijderd

Tijd voor COM

Ik heb zelf alleen nog maar de eerste paar bladzijden van de specificatie gelezen, maar het lijkt erop dat dit typisch van die problemen zijn die COM op zou moeten lossen.

zaterdag 8 september 2001 00:22

Acties:

Verwijderd

Misschien moet je dan even door bladeren naar het gedeelte waar ze uitleggen op welk platform waar com nu echt praktish is in te zetten...

zaterdag 8 september 2001 02:25

Acties:

zaterdag 8 september 2001 04:36

Moderator Devschuur®

Demotivational Speaker

Op zaterdag 08 september 2001 00:15 schreef Sneech het volgende:
Tijd voor COM

Ik heb zelf alleen nog maar de eerste paar bladzijden van de specificatie gelezen, maar het lijkt erop dat dit typisch van die problemen zijn die COM op zou moeten lossen.

COM is voor mietjes

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

Op vrijdag 07 september 2001 22:05 schreef beelzebubu het volgende:
Er zijn drie:
egcs (egcs++)
gcc (g++)
cc (c++)

En die zijn waarschijnlijk niet compatible..... Ik heb er in elk geval vaak genoeg problemen over gelezen...

Het zit nog ingewikkelder in elkaar. De originele unix C compiler was cc. Stalmann (GNU) en het FSF compiler team produceerde een vervanger gcc. Binnen het team ontstond (natuurlijk) onenigheid wat resulteerde in forks zoals gcc2. Een deel van deze forks verenigde zich in '97 tot het egcs team (olv. Cygnus, nu onderdeel van RedHat). Sinds '99 zijn ook de hoofdforks gcc en egcs officieel weer gemerged onder de noemer gcc, waarbij het egcs team de leiding heeft. Het lijkt wel politiek...

Het komt erop neer dat cc en gcc echt verschillen, terwijl egcs en gcc vanaf versie 2.95 compatible (identiek) zijn.

zaterdag 8 september 2001 13:49

Acties:

left part of the evil twins

Op zaterdag 08 september 2001 00:15 schreef Sneech het volgende:
Tijd voor COM

Ik heb zelf alleen nog maar de eerste paar bladzijden van de specificatie gelezen, maar het lijkt erop dat dit typisch van die problemen zijn die COM op zou moeten lossen.

Vorig jaar heeft een Microsoft-woordvoerder zich op de TechEd officieel verontschuldigd (!!!) voor dat ze de wereld opgezadeld hebben met de ramp die (D)COM heet.

Trek je conclusies.

zaterdag 8 september 2001 15:11

Acties:

Verwijderd

Op zaterdag 08 september 2001 13:49 schreef curry684 het volgende:
Vorig jaar heeft een Microsoft-woordvoerder zich op de TechEd officieel verontschuldigd (!!!) voor dat ze de wereld opgezadeld hebben met de ramp die (D)COM heet.
Trek je conclusies.

Dit jaar vroeg don box wie er allemaal een DCOM applicatie successvol uit gerold had, goed handjes de lucht in ('n stuk of 50 ofzo in 'n zaal waar +-2000man in zat?) ,"Wow, they are *ALL* here!!"

zaterdag 8 september 2001 17:05

Acties:

zondag 16 september 2001 17:05

Moderator Devschuur®

Demotivational Speaker

Op zaterdag 08 september 2001 15:11 schreef Yarvieh het volgende:

[..]

Dit jaar vroeg don box wie er allemaal een DCOM applicatie successvol uit gerold had, goed handjes de lucht in ('n stuk of 50 ofzo in 'n zaal waar +-2000man in zat?) ,"Wow, they are *ALL* here!!"

ROFL

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

Beetje oude thread, maar hoe heeft Microsoft hier op gereageerd ?
Beweren ze nog steeds dat (D)COM 'Da Bomb' is, of zijn ze inmiddels wat minder enthousiast ?
Wordt DX9 bijvoorbeeld wel weer gewoon COM ?

zondag 16 september 2001 17:45

Acties:

Verwijderd

COM is dodig wat microsoft aangaat geloof ik, .NET is het nieuwe wondermiddel.Ik heb DX al niet echt meer gevolgd na dx3 maar zijn ze van COM afgestapt dan, nee toch? Ik dacht laatst iets te lezen dat je in .NET met dx9 niet meer door de com interop hoefde maar ik kan het nu nergens meer terug vinden dus de kans dat ik me 't verbeeld heb is ook nog wel een beetje aanwezig

maandag 17 september 2001 01:13

Acties:

left part of the evil twins

Op zondag 16 september 2001 17:05 schreef Sneech het volgende:
Beetje oude thread, maar hoe heeft Microsoft hier op gereageerd ?
Beweren ze nog steeds dat (D)COM 'Da Bomb' is, of zijn ze inmiddels wat minder enthousiast ?
Wordt DX9 bijvoorbeeld wel weer gewoon COM ?

Uit de posts van Yarvieh en mij kun je wel afleiden hoe ze erover denken. Fyi Don Box is een hoge pief van MS.

maandag 17 september 2001 01:14

Acties:

Verwijderd

Op maandag 17 september 2001 01:13 schreef curry684 het volgende:
Uit de posts van Yarvieh en mij kun je wel afleiden hoe ze erover denken. Fyi Don Box is een hoge pief van MS.

FYI Don Box werkt niet bij ms, hij is mede oprichter van developmentor.com, heeft dacht ik ook nooit voor ms gewerkt maar daar ben ik niet helemaal zeker van.

maandag 17 september 2001 01:52

Acties:

maandag 17 september 2001 02:05

Moderator Devschuur®

Demotivational Speaker

FYI dit is idd een oude thread

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

left part of the evil twins

Op maandag 17 september 2001 01:14 schreef Yarvieh het volgende:
FYI Don Box werkt niet bij ms, hij is mede oprichter van developmentor.com, heeft dacht ik ook nooit voor ms gewerkt maar daar ben ik niet helemaal zeker van.

Oepsie mea culpa... in de war met iemand anders dan (deze gozer ken ik dus niet).

Die quote van mij kwam trouwens wel van een MS-official

maandag 17 september 2001 02:16

Acties:

Verwijderd

Op maandag 17 september 2001 02:05 schreef curry684 het volgende:
deze gozer ken ik dus niet.

Schrijver van het com-essentials boekje wat in de boekenkast hoort te staan van iedere com programeur? (naja de c++ lui dan, gaat de vb lui ver boven de pet)

Plezante gast ook om naar te luisteren, zoek iemand in je buurt op die afgelopen jaar naar teched geweest is die moet zo'n dvdtje hebben met wat lezingen van die dude..

maandag 17 september 2001 02:39

Acties:

left part of the evil twins

Op maandag 17 september 2001 02:16 schreef Yarvieh het volgende:
Schrijver van het com-essentials boekje wat in de boekenkast hoort te staan van iedere com programeur? (naja de c++ lui dan, gaat de vb lui ver boven de pet)

Ik ben geen COM programmeur, net zoals ik niet meer voor de Commodore 64 en de Amiga programmeer. Anachronismen zijn aan mij niet besteed...

maandag 17 september 2001 12:11

Acties:

maandag 17 september 2001 12:55

() => {};

Op vrijdag 07 september 2001 14:48 schreef Orphix het volgende:
Volgens mij is het gewoon nostalgie van de Gnome programmeurs en weigeren ze C++ te gebruiken maar vinden ze OO in een GUI omgeving toch wel handig

Hmm dat hoeft helemaal niet. Om maar een goed voorbeeld te noemen: Windows. De API is op zich niet OO. Anders zou je bvb om een window te showen, dit moeten doen:

code:

// is wel hypothetisch, dus geen commentaar op de manier
// waarop het wordt gedaan

(window *)hWnd->ShowWindow(SW_SHOW);

Het feit dat het niet zo is, geeft al aan dat de externe laag van de API (ie de laag die toegankelijk is voor applicaties) niet OO is. Sommige mensen opperen dat dat was om de functionaliteit van VB te kunnen implementeren, maar de aller-allereerste Windows progjes werden in non-OO talen geschreven (denk aan C, Pascal). Het zou best wel kunnen dat dit stukje code:

code:

1	ShowWindow(hWnd, SW_SHOW);

Dit aanroept:

code:

1	window_stack[hWnd]->show(SW_SHOW);

Of zoiets. Terwijl dit waarschijnlijker is:

code:

// namen zijn natuurlijk fictief hier, maar de echte coders
// snappen waar het om gaat

window_stack[hWnd]->show_state = SW_SHOW;
swap(window_stack[hWnd], window_stack[0]);

Allemaal leuk en aardig, maar wat bedoel ik hiermee: dat je geen OO nodig hebt om een GUI te proggen. Toegegeven, met OO is het op sommige punten makkelijker. Maar ik zelf had een non-OO GUI sneller aan de praat dan mijn OO GUI, die ik nog steeds niet zover heb. Dat kwam eerder door de vele bugs dan door de hoeveelheid code. Alhoewel je bij OO natuurlijk soms wel last hebt van code overhead.

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?

Acties:

Verwijderd

Op maandag 17 september 2001 12:11 schreef Xenophage het volgende:
code:
1
swap(window_stack[hWnd], window_stack[0]);

Begrijp ik het goed dat je hiermee probeert aan te geven dat een window naar de voorgrond word gehaald ?
Als dat zo is, is een swapje niet genoeg, maar moeten alle windows tussen hWnd en 0, en 0 zelf, een index naar achteren geschoven worden.
Ander krijg je het effect dat als je een window ver achterin aanklikt, dat je huidige foregroundwindow helemaal naar achteren floept, terwijl ie natuurlijk positie 1 (in jouw windowstack) zou moeten hebben.

maandag 17 september 2001 13:34

Acties:

maandag 17 september 2001 13:40

() => {};

<zucht> Ik zei dus:

namen zijn natuurlijk fictief hier, maar de echte coders snappen waar het om gaat

Maar goed, als je het per se zo wilt... Dan moet ten eerste de z-order niet in window_stack worden opgeslagen, aangezien hWnd daar aan 'gebonden' is. Dus moeten we het zo doen:

NB: Ik ga geen commentaar er bij zetten. Understand it or don't.

code:

int window_count;
window **window_stack;
long    *zorder;

int get_zorder(long hWnd)
{
  int i;

  for (i = 0; i < window_count; i++)
  {
    if (zorder[i] == hWnd)
    {
    return i;
    }
  }

  // bug!
  return -1;
}

int bring_to_front(long hWnd)
{
  int i;
 
  if (!window_stack[hWnd])
  {
    // bug!
    return 1;
  }

  for (i = 0; i < find_zorder(hWnd); i++)
  {
    zorder[i + 1] = zorder[i];
  }
  zorder[0] = hWnd;
}

Nou blij?

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?

Acties:

Verwijderd

Op maandag 17 september 2001 13:34 schreef Xenophage het volgende:
Nou blij?

Hardstikke

En speciaal voor jouw zal ik hier ook ff een stukje van mn javascript window manager neerplompen ( ik comment overigens wel (want ik ben een brave coder

) ):

code:

// make visible if hidden

    if (this.getStyleItem("visibility") == "hidden")
        this.setStyleItem("visibility", "visible");

// put on top of other windows if nescessary

    if (this.getStyleItem("zIndex") != 100)
    {
        // push windows that are before this one in the z-index stack to the back
            for (var i = 0; i < mWindows.length; i++)
                if (mWindows[i].getStyleItem("zIndex") > this.getStyleItem("zIndex"))
                    mWindows[i].setStyleItem("zIndex", mWindows[i].getStyleItem("zIndex") - 1);

        // place this window on top of the z-index stack
            this.setStyleItem ("zIndex", 100);
    }

maandag 17 september 2001 13:58

Acties:

maandag 17 september 2001 17:16

() => {};

Braaf codertje hoor...

Ik doe mijn comment alleen altijd in het engels, dus...

code:

int window_count;
window **window_stack;   // pointer naar pointers
long    *zorder;

/* get_zorder(): retrieves the z-order index of a window
   -------------
   params:
   hWnd     (long): hWnd of the window to look up
 
   returns: (int)
   resulting index, -1 if not found

   variables:
   i         (int): loop counter
*/
int get_zorder(long hWnd)
{
  int i;

  // window_count is the number of visible windows
  for (i = 0; i < window_count; i++)
  {
    if (zorder[i] == hWnd)
    {
    // yay, i found one!
    return i;
    }
  }

  // bug!
  return -1;
}

/* bring_to_front(): brings a window to the front of the
               z-order stack
   ----------------
   params:     
   hWnd     (long): hWnd of window to z-order

   returns: (int)
   nonzero on success, zero on failure

   variables:
   i           (int): loop counter
*/
int bring_to_front(long hWnd)
{
  int i;
 
  // see if window element hWnd is a valid pointer \
     (ie not NULL)
  if (!window_stack[hWnd])
  {
    // bug!
    return 1;
  }

  // shift back every element one place
  for (i = 0; i < find_zorder(hWnd); i++)
  {
    zorder[i + 1] = zorder[i];
  }

  // set first element to be hWnd.
  zorder[0] = hWnd;

  return 0;
}

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?

Acties:

left part of the evil twins

Op maandag 17 september 2001 12:11 schreef Xenophage het volgende:
Hmm dat hoeft helemaal niet. Om maar een goed voorbeeld te noemen: Windows. De API is op zich niet OO.

En daarom heeft Microsoft de MFC. Het doet geen kut extra, het encapsuleert alleen zo laag mogelijk de API zodat je een class om je handles hebt.

* curry684 heeft een teringhekel aan MFC.

dinsdag 18 september 2001 09:13

Acties: