Functie's onder C++

[Verwijderd]

Ik heb een vraag of het mogelijk is om uit de volgende functie een waarde naar main() door te sturen om hem daar in een "if" functie te gebruiken.

void SetHoofdstraat( char kleur )
{
unsigned char licht;

// rechtse kant:
licht = inportb( PA );
licht &= 0xF8;// licht uit
switch( kleur )
{
case ROOD:
licht |= P2; // rood aan
break;
case ORANJE:
licht |= P1; // oranje aan
break;
case GROEN:
licht |= P0; // groen aan
break;

}
/* Hier moet dan iets komen dat de waarde van "licht" naar main() stuurt.
}

In main roep ik deze functie aan met bv.:
SetHoofdstraat( ROOD);
Dan heeft "licht" de waarde P2 gekregen.
En deze waarde wil ik dan combineren met met bv. "licht2" aan de hand van licht & licht2 = licht3

[Verwijderd]

Functies kunnen waardes terugsturen naar de caller (returnen):

code:

int keertwee (int param)
{
    int x;
    x = param * 2;
    return x;
}

int main ()
{
    int blaat;
    blaat = keertwee(4);
    // blaat is nu 8
}

Dit is trouwens _nogal_ basic, dus lees eens wat tutorials/boeken.

[Verwijderd]

Op zondag 09 september 2001 17:49 schreef Sneech het volgende:
Functies kunnen waardes terugsturen naar de caller (returnen):
[..code..]
Dit is trouwens _nogal_ basic, dus lees eens wat tutorials/boeken.

Dit kan veeeeeeeeeeel leuker

[kloot-mode aan]

code:

void keertwee (int *param)
{
    *param *= 2;
}

int main ()
{
    int blaat=4;
    keertwee(&blaat);
    // blaat is nu 8
}

Of laten we meteen C++ gaan gebruiken

code:

void keertwee (int &param)
{
    param *= 2;
}

int main ()
{
    int blaat=4;
    keertwee(blaat);
    // blaat is nu 8
}

Dat is pas code
[/kloot-mode aan]

Eigenlijk best wel een onzinnig topic ja

[marcusk]

Ok, nu in asm

[Verwijderd]

beelzebubu:

Sjonge jonge jij met je klootmode , tuurlijk had ik ook kunnen schrijven:

code:

int main ()
{
    int blaat = 8;
    // blaat is nu 8
}

Maar daar schiet de topicstarter niet veel mee op. Mijn code was ultra-simpel en liet alleen even een functie zien die een waarde returnde.

Sommige mensen..

[.oisyn]

Op zondag 09 september 2001 19:05 schreef marcusk het volgende:
Ok, nu in asm

wheeeheeehehe

code:

void keertwee (int & waarde)
{
    __asm
    {
      mov eax, [OFFSET waarde]
      shl [eax], 1
    }
}

int main ()
{
    int blaat = 4;

    __asm
    {
      push OFFSET blaat;
      call keertwee
      add esp, 4
    }
}

[.oisyn]

Op zondag 09 september 2001 19:35 schreef Sneech het volgende:
beelzebubu:

Sjonge jonge jij met je klootmode

Zeg jij even nix! De enige reacties die ik van jou de afgelopen week heb gezien waaren ook niet bepaald behulpzaam

[Verwijderd]

Op zondag 09 september 2001 20:04 schreef OiSyN het volgende:

[..]

Zeg jij even nix! De enige reacties die ik van jou de afgelopen week heb gezien waaren ook niet bepaald behulpzaam

Als dat al zo is, geeft hem dat absoluut niet het recht mijn in dit geval wel behulpzame reactie af te zeiken.

En kun je misschien wat links geven naar mijn foute reacties dan ?

[Verwijderd]

Op zondag 09 september 2001 21:08 schreef Sneech het volgende:
Als dat al zo is, geeft hem dat absoluut niet het recht mijn in dit geval wel behulpzame reactie af te zeiken.

En kun je misschien wat links geven naar mijn foute reacties dan ?

Sneech, relax ff. Dit is een board met veel newbies, maar er zitten ook enkele (zeer) ervaren programmeurs tussen. Iedere ervaren programmeur heeft zijn eigen stijl van programmeren, en zijn eigen prioriteiten. Ik persoonlijk leg bv. de nadruk op compatability van code, zodat ze makkelijk geport kan worden. Andere programmeurs leggen meer de nadruk op optimalisatie in tijd en/of ruimte.

Zo kun je dus wel eens een aanvaring krijgen met een andere ervaren programmeur, als je de nadruk te veel op je persoonlijke prioriteiten legt bij het beantwoorden van een post. Dat is vanuit de optiek van die ander dan lelijk of een hack of noem maar op. Dat is iedereen in kwestie wel eens overkomen.

Het kan echter ook anders. Juist omdat de ervaren programmeurs op dit board vanuit verschillende invalshoeken komen, kunnen zelfs die ervaren programmeurs iets van elkaar leren. Met name de afgelopen paar dagen waren er weer wat interessante C(++) topics, waarin de sfeer zeer goed was ondanks dat men het soms niet met elkaar eens was of elkaar niet begreep.

Ik roep je dan ook op om in je posts naast je technische bijdrage (die zeer wel gerespecteerd wordt), ook een positieve bijdrage te doen aan de sfeer op het board.

Ik realiseer me dat wij in het recente verleden ook iets gehad hebben wat je als een aanvaring zou kunnen beschouwen. Als je mijn opmerkingen persoonlijk hebt opgevat, bied ik je hierbij mijn veronschuldigingen aan.

Zand erover en in een goede sfeer door, ok?

[.oisyn]

Op zondag 09 september 2001 21:08 schreef Sneech het volgende:

[..]

Als dat al zo is, geeft hem dat absoluut niet het recht mijn in dit geval wel behulpzame reactie af te zeiken.

En kun je misschien wat links geven naar mijn foute reacties dan ?

hij zeikt je reactie niet af, en als je denkt dat ie dat wel doet dan ligt het toch volledig aan jezelf

bovendien staat er een bij, ik weet niet hoe jij dat opvat maar wij doen dat meestal om aan te geven dat je het niet verkeerd bedoelt

[Verwijderd]

Op zondag 09 september 2001 21:54 schreef mietje een hele lap text (die overigens minstens net zo toepasbaar is op de persoon die bovenin deze thread het opeens nodig vond met zijn zogenoemde 'kloot-mode' op mij te reageren)

Ik ben het voor een groot deel niet eens met je analyse van mijn gedrag, maar het feit alleen al dat je zo'n indruk van mij krijgt, is voor mij genoeg reden om me voor te nemen in de toekomst misschien iets minder snel geirriteerd/opvliegend te reageren. Let wel, ik maak absoluut geen verontschuldigingen voor eerder geposte berichten, aangezien die naar mijn mening nog steeds volledig op hun plaats waren.

[.oisyn]

jongens we gaan wel erg offtopic
laten we als heren de draad weer oppakken

[marcusk]

[ontopic]

code:

__asm
    {
      push OFFSET blaat;
      call keertwee
      add esp, 4
    }

waarvoor is die add esp, 4 ?

[edit]
oh, om het ge-push-de te 'semi-poppen' zeker ?

[Verwijderd]

Das inderdaad om de parameters weer van de stack te vegen.

[Verwijderd]

Op zondag 09 september 2001 19:35 schreef Sneech een heleboel

Relax Sneech.

Er staat "kloot-mode" bij en dat is absoluut niet naar jou toe bedoeld, het is alleen bedoeld als "deze post is een geintje ertussendoor"....

Kan bovendien nog eens van pas komen als een functie meerdere values moet returnen (wat vrij moeilijk is in C zonder met pointers te gaan klooien)....

Ik bedoelde er absoluut niets persoonlijks mee, dus

[Verwijderd]

Op zondag 09 september 2001 19:05 schreef marcusk het volgende:
Ok, nu in asm

Op zondag 09 september 2001 20:01 schreef OiSyN het volgende:
wheeeheeehehe
[..heleboel code..]

Ohmaaigaaaaaaaaaaaaawd

Waar blijven de benchmarks

[Verwijderd]

't compileerd niet zo fijn, maare raken we met een shl onze signed bit niet kwijt?

[.oisyn]

Op maandag 10 september 2001 00:39 schreef Yarvieh het volgende:
't compileerd niet zo fijn, maare raken we met een shl onze signed bit niet kwijt?

dat is alleen als je naar rechts wil shiften (dwz, delen door 2)

daarvoor heb je shr (logical shift right) voor zero-extension en sar (arithmetical shift right) voor sign-extension

Wat compileerde er trouwens niet fijn? Die shl [eax], 1 zeker niet...
dat moet shl dword ptr [eax], 1 zijn idd... verder zou ie het goed moeten doen

[.oisyn]

Op maandag 10 september 2001 00:27 schreef beelzebubu het volgende:

[..]

Kan bovendien nog eens van pas komen als een functie meerdere values moet returnen (wat vrij moeilijk is in C zonder met pointers te gaan klooien)....

en dan te bedenken dat sommige mensen de superinefficiente manier gebruiken door alles in een struct/class te gooien en die te returnen (dus niet mbv pointer, maar gewoon return structure;)

dit bijvoorbeeld:

code:

class Matrix
{
private:
    float m[4][4];

public:
    Matrix operator * (const Matrix & m) const
    {
      Matrix r;
      // doe de vermenigvuldiging en zet het antwoord in r

      return r;
    }
}

en dan zeggen ze: "ja das mooi, want dan kun je dit doen:"

code:

Matrix m1, m2, m3;

m3 = m1 * m2;

daarom pleit ik nog altijd voor een operator overloading in de vorm van

code:

void operator * (Matrix & result, const Matrix & m1, const Matrix &m2);

zodat m1 = m2 * m3 wordt aangeroepen als

code:

operator * (m1, m2, m3);

een gemis van C++ eigenlijk...

[Verwijderd]

mov eax, [OFFSET waarde] en die call keertwee kan ie niet zo waarderen..

[Verwijderd]

Op maandag 10 september 2001 01:11 schreef OiSyN het volgende:
daarom pleit ik nog altijd voor een operator overloading in de vorm van

code:

void operator * (Matrix & result, const Matrix & m1, const Matrix &m2);

zodat m1 = m2 * m3 wordt aangeroepen als

code:

operator * (m1, m2, m3);

een gemis van C++ eigenlijk...

Mij lijkt zo'n operator een beetje overbodig, omdat ie alleen voor vrij specifieke gevallen echt handig zou zijn, en er wel weer een hele nieuwe operator functie met bijbehorende syntax bijkomt.

[Verwijderd]

Op maandag 10 september 2001 01:11 schreef OiSyN het volgende:
en dan te bedenken dat sommige mensen de superinefficiente manier gebruiken door alles in een struct/class te gooien en die te returnen (dus niet mbv pointer, maar gewoon return structure;)

...

een gemis van C++ eigenlijk...

Eumz, het is een goede OO-praktijk, en zeker een goede C++ praktijk, om de representatie te scheiden van het object. Op deze manier implementeer je (ook) copy-on-demand, en de overhead van dit soort operaties is dan niet veel groter als die van operaties die pointers returnen in C.

code:

class _MatrixRep {
friend class Matrix;
private:
  float _m[4][4];
};

class Matrix {
private:
  _MatrixRep *_rep;
};

[Verwijderd]

Op maandag 10 september 2001 10:52 schreef mietje een heleboel

Dan kan je net zo goed een pointer naar Matric returnen, waarom zo moeilijk doen?

Pointers bestaan niet voor niks

[Verwijderd]

Op maandag 10 september 2001 11:01 schreef beelzebubu het volgende:

Dan kan je net zo goed een pointer naar Matric returnen, waarom zo moeilijk doen?

Pointers bestaan niet voor niks

In C++ zijn "blote" pointers eeevil Ze zouden bijvoorbeeld NULL kunnen zijn.

Op de manier zoals ik voorstel kun je de allocatie en deallocatie van de _MatrixRep automatiseren, (met reference counting bv.). Je kunt simpelweg code schrijven als Matrix c= a + b; en je hebt niet meer overhead dan wanneer je met pointers zou werken.

[Verwijderd]

[Of laten we meteen C++ gaan gebruiken

code:

void keertwee (int &param)
{
    param *= 2;
}

int main ()
{
    int blaat=4;
    keertwee(blaat);
    // blaat is nu 8
}

Heel fijn allemaal, maar ik had eigenlijk een vraagje. Waarom is het

code:

&param

ipv

code:

param

. Zal vast wel iets simpels zijn, maarja, ik ben c++ newbie dussss.

[Verwijderd]

void keertwee(int param)
oproepen betekent dat je een van de waarde en die in param plaatst, en dat er binnen de functie maaltwee met die kopie gewerkt wordt.

void keertwee(int &param)
oproepen betekent dat je het adres van de waarde in param plaatst, zodat er binnen de functie met de originele waarde gewerkt wordt.

Dit noemt men overigens een referentie (parameter).

code:

#include <iostream>

using namespace std;

void x2copy(int param) { param<<= 1; }
void x2ref(int &param) { param<<= 1; }

int main() {
  int blaat= 2;

  x2copy(blaat);
  cout << blaat << endl;
  // Output: 2, de waarde van blaat werd NIET gewijzigd,
  // er werd met een kopie van blaat gewerkt.

  x2ref(blaat);
  cout << blaat << endl;
  // Output: 4, de waarde van blaat werd WEL gewijzigd,
  // er werd met het adres van blaat gewerkt.

  return 0;
}

<edit>paste eet een < op :)</edit>

[Sponz]

Dat heet refenrce argument, is functioneel hetzelfde als een pointer argument, maar ziet er netter uit.

(dit is dus een reply voor ceidhof)

[drm]

mietje:
(...)

code:

/* ... */
void x2copy(int param) { param<= 1; }
void x2ref(int &param) { param<= 1; }
/* ... */

Laten we daar dan

code:

void x2copy(int param) { param<<= 1; }
void x2ref(int &param) { param<<= 1; }

van maken
Anders gebeurt er nog niks

[drm]

Op maandag 10 september 2001 11:41 schreef Sponz het volgende:
Dat heet refenrce argument, is functioneel hetzelfde als een pointer argument, maar ziet er netter uit.

(dit is dus een reply voor ceidhof)

Oh?

Zullen we dit eens met een reference argument proberen?
_{leesbare, nette code daar gelaten}

code:

char *mystrcpy ( const char *src, char *dest )
{
   while ( ( *(dest++) = *(src++) ) != '\0' )
    ;
   return dest;
}

_[edit:typo]

[Sponz]

Het werkt niet met array's, is dat je punt

[curry684]

Op maandag 10 september 2001 01:11 schreef OiSyN het volgende:
daarom pleit ik nog altijd voor een operator overloading in de vorm van

code:

void operator * (Matrix & result, const Matrix & m1, const Matrix &m2);

zodat m1 = m2 * m3 wordt aangeroepen als

code:

operator * (m1, m2, m3);

een gemis van C++ eigenlijk...

De vriendelijke implementatie is dan ook:

code:

typedef struct
  {
  int          m_Values[4][4];
  int          m_ReferenceCount;
  } t_Matrix;

class Matrix
{
public:  // Methods
              Matrix();
              Matrix(const Matrix &p_Original);
  explicit      Matrix(t_Matrix* p_Matrix);

  ...

private:    // Properties
  t_Matrix*    m_Matrix;
};

OOP correct, copy on demand, CPU-vriendelijk. What more could you want?

(oeps zie net dat mietje ook al iets van deze strekking meldde)

[curry684]

Op maandag 10 september 2001 11:41 schreef Sponz het volgende:
Dat heet refenrce argument, is functioneel hetzelfde als een pointer argument, maar ziet er netter uit.

(dit is dus een reply voor ceidhof)

NEEEEEEEE!!!!!
Een reference is NIET hetzelfde als een pointer!

Een reference parameter heeft syntactisch dezelfde aanroep (pointer niet), en een reference is BESCHERMD, oftewel hij wijst altijd naar een object van het correcte type. Je kunt geen references wegcasten of naar shit of zelfs NUL laten wijzen.

Ter illustratie:

code:

int ByPointerCall(int *Integer);
{
// Let op de dereference
return *Integer * 2;
}

int ByReferenceCall(int &Integer)
{
// Hoeft niet te dereferencen
return Integer * 2;
}

int main()
{
int  Value = 4;

// Let op het verschil in aanroep:
ByPointerCall(&Integer);
ByReferenceCall(Integer);

// Tevens kan het volgende wel (access violation):
ByPointerCall((int*)45453789);

// En dit niet (compiler error):
ByReferenceCall((int&)7234847237);

return 0;
}

[Sponz]

Ik zeg dat het functioneel het zelfde is, ik zeg niet dat het het zelfde is.

[.oisyn]

Op maandag 10 september 2001 10:52 schreef mietje het volgende:

[..]

Eumz, het is een goede OO-praktijk, en zeker een goede C++ praktijk, om de representatie te scheiden van het object. Op deze manier implementeer je (ook) copy-on-demand, en de overhead van dit soort operaties is dan niet veel groter als die van operaties die pointers returnen in C.

code:

class _MatrixRep {
friend class Matrix;
private:
  float _m[4][4];
};

class Matrix {
private:
  _MatrixRep *_rep;
};

Dan ken jij zeker de overhead van new/delete niet. Daar hou ik niet van, zeker niet als iets snel moet zijn.
.edit: geldt ook voor curry

Daarom maak ik ook liever gebruik van constructies als

code:

class Matrix
{
    void mul (const Matrix & m1, const Matrix & m2);
};

int main ()
{
    Matrix m1, m2, m3;

    ...
    m1.mul (m2, m3);
}

Dat dit niet echt netjes OO is zal mij aan me kont roesten (ik vind het hele OO gebeuren sowieso al opgeblazen), het is iig de snelste methode

[drm]

Op maandag 10 september 2001 11:58 schreef Sponz het volgende:
Het werkt niet met array's, is dat je punt

Mijn punt is dat een pointer fundamenteel een andere betekenis heeft dan een reference.

en pointer != array

Op maandag 10 september 2001 12:21 schreef Sponz het volgende:
Ik zeg dat het functioneel het zelfde is, ik zeg niet dat het het zelfde is.

en dus is het functioneel ook niet hetzelfde, simpelweg omdat je er niet slechts hetzelfde mee kan, en het inhoudelijk een andere werking heeft.

zoals curry648 ook al zei:

Een reference parameter heeft syntactisch dezelfde aanroep (pointer niet), en een reference is BESCHERMD, oftewel hij wijst altijd naar een object van het correcte type. Je kunt geen references wegcasten of naar shit of zelfs NUL laten wijzen.

[Verwijderd]

Op maandag 10 september 2001 12:43 schreef OiSyN het volgende:
Dan ken jij zeker de overhead van new/delete niet. Daar hou ik niet van, zeker niet als iets snel moet zijn.
.edit: geldt ook voor curry

...

Dat dit niet echt netjes OO is zal mij aan me kont roesten (ik vind het hele OO gebeuren sowieso al opgeblazen), het is iig de snelste methode

Ik ken de overhead van new/delete. Het punt is, dat je met copy-on-demand alleen een Matrix object hoeft te newen/deleten, en dat is maar een pointer wrapper. De _MatrixRep zul je ook in C code moeten mallocen/freeen. (De std::string class is precies op deze manier geimplementeerd.)

Als ik vanmiddag wat tijd heb schrijf ik een benchmark

[Verwijderd]

Op maandag 10 september 2001 12:14 schreef curry684 het volgende:
Je kunt geen references wegcasten of naar shit of zelfs NUL laten wijzen.

Dat jij het niet kan, betekent niet dat het onmogelijk is:

code:

int & i = *(static_cast<int*>(NULL));

Tada !

[curry684]

Op maandag 10 september 2001 12:43 schreef OiSyN het volgende:
Daarom maak ik ook liever gebruik van constructies als

code:

class Matrix
{
    void mul (const Matrix & m1, const Matrix & m2);
};

int main ()
{
    Matrix m1, m2, m3;

    ...
    m1.mul (m2, m3);
}

Het lijkt mij persoonlijk sterk dat dit veel sneller is dan goede ultradunne classes met const-by-ref copy-on-demand semantics. Misschien in dit specifieke geval wel maar zodra je een functiecall ermee doet ben je die minieme winst alweer kwijt.

[.oisyn]

je maakt toch gebruik van new of niet? Anders snap ik jou idee niet helemaal...

en zoals iemand het op flipcode.com een keer mooi zei:

If life where a game show there would be buzzer noises to go with this comment. And not the good ones.

Using the heap and ref counted pointers for simple operations like this is NOT going to make your code faster.

It will make you code slower and harder to use.

Try it in a timed test if you don't belive me.

[drm]

Sneech:
(...)

code:

int & i = *(static_cast<int*>(NULL));

(...)

*ouch*

[Verwijderd]

Op maandag 10 september 2001 11:13 schreef ceidhof het volgende:

[..]

Heel fijn allemaal, maar ik had eigenlijk een vraagje. Waarom is het

code:

&param

ipv

code:

param

. Zal vast wel iets simpels zijn, maarja, ik ben c++ newbie dussss.

ik roep het aan met keertwee(int nummer);

&param is de integer "nummer" zelf. param is een copy van "nummer"

Vergelijk het volgende:

code:

void keertwee(int num)
{
  num *= 2;
}

met

code:

void keertwee(int &num)
{
  num *= 2;
}

Als ik nu het volgende doe

code:

int main()
{
  int nummer = 2;
  keertwee(nummer);
}

dan blijft nummer 2 met de eerste functie, maar met de tweede wordt ie vier. Want bij de eerste vermingvuldig je de copy met twee, je doet niks met nummer zelf. Die blijft dus twee. Bij de tweede vermenigvuldig je nummer zelf met twee, dus wordt het 4.

Snappez-vous?

[Sponz]

Op maandag 10 september 2001 13:23 schreef beelzebubu het volgende:

[..]

code:

void keertwee(int &num)
{
  num *= 2;
}

Is functioneel gelijk aan:

code:

void keertwee(int *num)
{
  *num *= 2;
}

Dat probeerde ik dus duidelijk te maken.

[drm]

Op maandag 10 september 2001 13:31 schreef Sponz het volgende:

[..]

Is functioneel gelijk aan:

code:

void keertwee(int *num)
{
  *num *= 2;
}

Dat probeerde ik dus duidelijk te maken.

in dit geval != in alle gevallen.
Pas op met generaliserende uitspraken, daar kunnen beginners zich aan vast gaan houden. Dat bedoelde ik duidelijk te maken.
No offense verder

[Verwijderd]

Op maandag 10 september 2001 13:31 schreef Sponz het volgende:

[..]

Is functioneel gelijk aan:

code:

void keertwee(int *num)
{
  *num *= 2;
}

Dat probeerde ik dus duidelijk te maken.

Nee, want het is een extra pointer.

&num is de variabele zelf, *num is een pointer naar de variabele en num is een copy van de variabele.

Dat is niet hetzelfde!

[curry684]

Op maandag 10 september 2001 13:39 schreef drm het volgende:
in dit geval != in alle gevallen.
Pas op met generaliserende uitspraken, daar kunnen beginners zich aan vast gaan houden. Dat bedoelde ik duidelijk te maken.
No offense verder

Sowieso gelden alle uitspraken over pointers en references hierboven alleen in het geval dat het over een object gaat waarvan de developer de unary * en & operators niet heeft ge-overload

code:

class Matrix
{
...
  inline operator*()     { return NULL; }
  inline operator&()     { return new Matrix; }
...
};

[Verwijderd]

Het begint mij helemaal te duizelen, reference en pointers

[Primal]

Op maandag 10 september 2001 13:48 schreef beelzebubu het volgende:

[..]

Nee, want het is een extra pointer.

&num is de variabele zelf, *num is een pointer naar de variabele en num is een copy van de variabele.

Misschien dat ik iets mis hoor , maar een reference is GEEN kopie van de variabele. Het adres van de variabele wordt doorgegeven.
Maar zoals ik al zei, misschien mis ik iets in deze hele discussie.

[Verwijderd]

Hier de bench

code:

#include <ctime>
#include <iostream>

using namespace std;

const int    MATRIX_DIM=     10,
            TESTS=      1000000;


class _MatrixRep {
friend class Matrix;
private:
  unsigned  _refs;
  float    _m[MATRIX_DIM][MATRIX_DIM];

  void _copy(const _MatrixRep& m)
    { for(int i= 0; i < MATRIX_DIM; ++i)
      for(int j= 0; j < MATRIX_DIM; ++j)
        _m[i][j]= m._m[i][j];
    }

  void _add(const _MatrixRep& m)
    { for(int i= 0; i < MATRIX_DIM; ++i)
      for(int j= 0; j < MATRIX_DIM; ++j)
        _m[i][j]+= m._m[i][j];
    }
  void _add(const _MatrixRep& a, const _MatrixRep& b)
    { for(int i= 0; i < MATRIX_DIM; ++i)
      for(int j= 0; j < MATRIX_DIM; ++j)
        _m[i][j]= a._m[i][j] + b._m[i][j];
    }

  _MatrixRep() : _refs(1) {}
};

class Matrix {
private:
  _MatrixRep    *_rep;

  void _drop()
    { if(_rep) {
      if(!--_rep->_refs) {
        delete _rep;
        _rep= 0;
      }
    }
    }

  void _copy(const _MatrixRep* mrp)
    { _drop();
    _rep= new _MatrixRep;
    _rep->_copy(*mrp);
    }


public:
  Matrix() : _rep(0) {}
  Matrix(const Matrix& m) : _rep(m._rep) { if(_rep) ++_rep->_refs; }
  ~Matrix() { _drop(); }

  Matrix& operator += (const Matrix& m)
    { if(_rep) {
      if(m._rep) {
        if(_rep->_refs > 1) _copy(m._rep);
        _rep->_add(*m._rep);
      }
    } else if(m._rep) {
      _rep= m._rep;
      ++_rep->_refs;
    }
    return *this;
    }

  Matrix operator + (const Matrix& m) const
    { Matrix ret;
    if(_rep) {
      if(m._rep) {
        ret._rep= new _MatrixRep;
        ret._rep->_add(*_rep,*m._rep);
      } else {
        ret._rep= _rep;
        ++ret._rep->_refs;
      }
    } else if(m._rep) {
      ret._rep= m._rep;
      ++ret._rep->_refs;
    }
    return ret;
    }

  float operator () (int row, int col) const
    { return _rep ? _rep->_m[row][col] : 0.0; }
  float& operator () (int row, int col)
    { if(!_rep) _rep= new _MatrixRep;
    return _rep->_m[row][col];
    }
};

inline void fillMatrix(Matrix& m, float val) {
  for(int i= 0; i < MATRIX_DIM; ++i)
    for(int j= 0; j < MATRIX_DIM; ++j)
    m(i,j)= val + i + j;
}

int main() {
  Matrix a, b, c, d;
  fillMatrix(a,0.0);
  fillMatrix(b,10.0);
  fillMatrix(c,100.0);

  clock_t time= clock();
  for(int test= TESTS; test; --test) {
    d= a;
    d+= b;
    d+= c;
  }
  cout << "operator += : " << static_cast<double>(clock() - time) / TESTS << endl;

  time= clock();
  for(int test= TESTS; test; --test)
    d= a + b + c;
  cout << "operator +  : " << static_cast<double>(clock() - time) / TESTS << endl;

  return 0;
}

Output voor 100000 10x10 Matrices:

operator += : 4.37
operator + : 6.44

voor 100000 4x4 Matrices:

operator += : 0.72
operator + : 2.26

We zien dus dat bij weinig operaties (4x4 Matrix) de overhead significant is (~ 3x). Hoe groter het aantal operaties (10x10 Matrix), hoe minder de overhead telt (~ 1.5x).

(Ja, de code is in 10 minuten elkaar geflansd )

[curry684]

Op maandag 10 september 2001 14:13 schreef ceidhof het volgende:
Het begint mij helemaal te duizelen, reference en pointers

Het is dan ook het moeilijkste punt van C++ voor beginners, voornamelijk omdat iedereen er constant op wijst dat het zo moeilijk is.

Het is eigenlijk heel simpel:
- Een pointer is een 'wegwijzer'. Hij wijst naar iets van een bepaald type, en dat was het. Geen garantie wordt gegeven dat er op de plek waar hij naar wijst feitelijk het betreffende ding staat.
- Een reference is een 'verwijzing'. Geen fysiek ding dus zoals de pointer, maar iets dat je aan een functie mee kunt geven om duidelijk te maken waar die functie z'n data kan vinden. In plaats van fysieke data (pointer of object) geef je enkel een hint mee waar de fysieke data staat.

Ter illustratie: stel we hebben de volgende class:

code:

class BigMomma
{
  int      Fat[10000];
};

Deze class is 40000 bytes groot. Stel nu de volgende 3 functies:

code:

void SlapMomma(BigMomma SomeMomma);    // By value
void SlapMomma(BigMomma* SomeMomma);   // By pointer
void SlapMomma(BigMomma &SomeMomma);   // By reference

De eerste zal bij iedere functieaanroep het hele object kopieren (40000 bytes!!!). Dit willen we natuurlijk niet want daar wordt het allemaal teringlangzaam van.

In het tweede geval geven we een pointer mee. Deze is (bijna altijd) 4 bytes, en dus weinig tot geen kopieeroverhead. Over het algemeen gebruik je deze variant als je het object met new hebt aangemaakt en er enkel een pointer naar hebt, bijvoorbeeld:

code:

BigMomma*     MyMomma = new BigMomma;

Als je het object op de stack hebt zitten of als membervariabele of weet ik het wat, in ieder geval niet als pointer, zul je de derde variant gebruiken (by reference). Bijvoorbeeld:

code:

BigMomma    MyMomma;
SlapMomma(MyMomma);

In plaats van een kopie of een pointer mee te geven, vertel je de functie nu waar het origineel staat.

Nadeel/voordeel van deze aanpak is dat de functie echt op het origineel werkt, en die dus ook kan wijzigen. Indien dit niet mag declareer je de functie als volgt:

code:

void SlapMomma(const BigMomma &SomeMomma);

Nu krijgt de functieimplementatie een compilererror als ie iets wil veranderen in het object (het object is constant gemaakt).

[Korben]

Op maandag 10 september 2001 10:52 schreef mietje het volgende:

[..]

Eumz, het is een goede OO-praktijk, en zeker een goede C++ praktijk, om de representatie te scheiden van het object. Op deze manier implementeer je (ook) copy-on-demand, en de overhead van dit soort operaties is dan niet veel groter als die van operaties die pointers returnen in C.

code:

class _MatrixRep {
friend class Matrix;
private:
  float _m[4][4];
};

class Matrix {
private:
  _MatrixRep *_rep;
};

Hmm... dus als ik een venster class wil maken doe ik dit:

code:

class aw_window;
class aw_window_rep;

class aw_window // let niet op de naam
{
public:
   aw_window();
   ~aw_window();

protected:
   aw_window_rep rep;
};

class aw_window_rep
{
friend class aw_window;

public:
   aw_window_rep();
   ~aw_window_rep();

protected:
   char *text;
   bool active;
   bool modal;
   bool dirty;

   IRECT *win_rect;
   IRECT *client_rect;
   IRECT *spacing_rect;

   BITMAP *buffer;
   BITMAP *canvas;
};

Nou, om eerlijk te zijn flikker ik liever die data members gewoon in de class. Een goed gebruik in programmeren in het algemeen (vooral bij OOP) is het verdelen van je source over meerdere files. Als je dan dus niet nadenkt bij het feit dat je data members in die representation class staan, ga je bij het veranderen of controleren van je members eerst kijken in de class zelf. Om je (als je flink wazig bent na 48 uur onafgebroken coden) rot te schrikken en te denken dat je een memory leak hebt omdat je data members foetsie zijn.

code:

Error: class 'aw_window' has no member named 'active' (196, aw_window.cc)

Maar goed, het is dus maar welke stijl je gewend bent. Om het zo te zeggen: M$ mensen doen het niet, dus ik ook niet. Nou weet ik dat veel mensen zullen zeggen: 'M$ mensen kunnen niet programmeren', maar dat is imo complete bullshit. Voor diegenen die in VB programmeren (ik ook soms), ik heb nog nooit zoiets aangeroepen:

code:

Form1.Members.ListView1.Members.ListItems.Members(1).SubItems(1).Members = "bert"

Dus is het ook nog es niet echt praktisch. Eèn van de doelen van C++ was toch data abstraction? Dat heb je dan idd wel, met als resultaat dat je meer moet nadenken over wat die code nou weer doet, en hoe je 'm dan moet aanpassen. En weer een VB-voorbeeld: typ je bvb Form1., krijg je een member info box met alleen de tekst 'Members'. Fijn, daar heb je zoiets voor.

[Verwijderd]

Op maandag 10 september 2001 15:38 schreef Xenophage het volgende:
Nou, om eerlijk te zijn flikker ik liever die data members gewoon in de class. Een goed gebruik in programmeren in het algemeen (vooral bij OOP) is het verdelen van je source over meerdere files. Als je dan dus niet nadenkt bij het feit dat je data members in die representation class staan, ga je bij het veranderen of controleren van je members eerst kijken in de class zelf. Om je (als je flink wazig bent na 48 uur onafgebroken coden) rot te schrikken en te denken dat je een memory leak hebt omdat je data members foetsie zijn.

Als je naar m'n benchmark code kijkt zie je dat de Matrix class getters/setters/operators heeft voor alle bewerkingen op de _MatrixRep. Voor de programmeur die de code gebruikt, is het niet zichtbaar dat de representatie gescheiden is van het object (de STL std::string werkt ook zo).

Nog eens benadrukken: dit is een manier om copy-on-demand te implementeren. Het scheiden van representatie en object veroorzaakt dus snellere code, want een _MatrixRep object hoeft alleen geconstrueerd/gekopieerd te worden wanneer het gewijzigd wordt, identieke Matrix objecten verwijzen naar één _MatrixRep object.

[.oisyn]

Op maandag 10 september 2001 14:52 schreef mietje een benchmark (van lelijke code, maar das subjectief ), waar we nix aan hebben, want als je gaat benchen vergelijk je meestal MEERDERE methodes om te kijken welke het snelst is, dus niet alleen die van jezelf

na ja, de quote zegt genoeg denk ik

ik zal wel effe een bench maken die beide methodes test

.edit: damn man ik zit je code nu effe mooi neer te zetten, maar ik hoop echt niet dat jij IRL ook zo code, want er is werkelijk geen touw aan vast te knopen

.edit2: en for the sake of readability, gebruik asjeblieft NULL ipv 0

[.oisyn]

okee mijn bench is af
mijn code staat hier

met 1.000.000 iteraties op mijn athlon classic 800

in de debug build:

code:

mietje : 6.980000 secs
oisyn  : 1.210000 secs

in de release build:

code:

mietje : 1.210000 secs
oisyn  : 0.330000 secs

en dan heb ik mietjes code nog geoptimized ook (ik heb gemaakt dat rep nooit NULL kan zijn, dat scheelt een hoop checks)

need i say more

[farlane]

Op maandag 10 september 2001 17:32 schreef OiSyN het volgende:

...
en for the sake of readability, gebruik asjeblieft NULL ipv 0
...

Hmm...waarom maakt dit code leesbaarder? Redelijk subjectief. (Ik vind NULL in code lelijk/onnodig)

[.oisyn]

Op maandag 10 september 2001 18:35 schreef farlane het volgende:

[..]

Hmm...waarom maakt dit code leesbaarder? Redelijk subjectief. (Ik vind NULL in code lelijk/onnodig)

oh ze hebben NULL voor niets gedefined?

Door iets op NULL te zetten weet je dat het om een pointer gaat, en dus niet om een integer of floating point primitive

code:

int * pi;

...

i = 0;

vind ik persoonlijk erg fout. Het kan namelijk gezien worden als een tiepfout en dat de programmeur eigenlijk bedoelde *i = 0;
OF hij heeft i fout gedeclareerd en bedoelde dus niet dat het een pointer was, dus int i;

Bovendien, als je dat ziet zou je ook kunnen doen

code:

i = 1;

wat dus helemaal nergens op slaat (dit geeft overigens een warning). Als je echt een int op het adres 1 wilt hebben dan doe je maar

code:

i = (int *)1;
of
i = (int *)0x00000001; // <-- mijn persoonlijke voorkeur

conclusie: 0 is een integer en NULL is een pointer naar niks (ook al hebben ze dezelfde waarde voor de compiler)

[Verwijderd]

[b]Op maandag 10 september 2001 18:29 schreef OiSyN een heleboel:

Waar is die van mij gebleven

[.oisyn]

Op maandag 10 september 2001 19:52 schreef beelzebubu het volgende:

[..]

Waar is die van mij gebleven

jij hebt helemaal geen code geschreven

Als je kijkt naar mijn benchmark, dan zie je dat het over de reacties van deze post van mij ging

Gepost door OiSyN op maandag 10 september 2001 01:11

[Verwijderd]

Op maandag 10 september 2001 20:18 schreef OiSyN het volgende:

jij hebt helemaal geen code geschreven

Oh dit ging over matrices

Sorry

[farlane]

oh ze hebben NULL voor niets gedefined?

Sterker nog, als ik er op zoek in mijn VC dir komt ie 23 (!)keer voor. Ze hebben em dus 23 keer voor nix gedefined.

code:

int * pi;
...
i = 0;

vind ik persoonlijk erg fout.

Mee eens. Dat zou moeten zijn:

code:

int * pi = 0;

Ik zie dan dat het een pointer is en ik heb em meteen een waarde gegeven. (geen ongeinitialiseerde variabelen meer itt wat jouw code doet)

Ik vind dat erg duidelijk. Wat ik zei, subjectief.

[.oisyn]

Op maandag 10 september 2001 20:51 schreef farlane het volgende:

[..]

Sterker nog, als ik er op zoek in mijn VC dir komt ie 23 (!)keer voor. Ze hebben em dus 23 keer voor nix gedefined.

de 'ze' zijn hier wel de ANSI C mensen, en geloof me, die hebben er vast wel over nagedacht

[..]

Mee eens. Dat zou moeten zijn:

code:

int * pi = 0;

Ik zie dan dat het een pointer is en ik heb em meteen een waarde gegeven. (geen ongeinitialiseerde variabelen meer itt wat jouw code doet)

Ik vind dat erg duidelijk. Wat ik zei, subjectief.

met die ... bedoel ik dat daar code staat die wellicht wel iets met i kan doen

ga maar eens kijken naar de code van Mietje, daar zie je op een gegeven moment _rep = 0;
Zo naar de code kijkend weet je NIET dat _rep een pointer is, en als er _rep = NULL had gestaan, dan zie je dus gelijk dat het WEL een pointer is.

Code is in principe leesbaar dat als je naar een klein stukje kijkt je ongeveer kan bepalen wat wat is, en dus NIET als je van te voren weet wat de variabelen weet

[farlane]

Die ...

code:

void _drop()
    { if(_rep) {
      if(!--_rep->_refs) {
        delete _rep;
        _rep= 0;
      }
    }
    }

bedoel je? Vind ik nog wel gaan eigenlijk. (Voornamelijk die 'delete' die het een en ander verraadt )

Zijn code lijkt veel op die hocus pocus die je veel in de STL vindt. Niet echt geschreven om leesbaar te zijn verwacht ik.

Naja, ik kan me voorstellen dat je die 'infamous NULL macro' wilt gebruiken. Persoonlijk vind ik 'em weinig toevoegen.

[edit]
lelijke spelfout

[Verwijderd]

Om ff op die null zooi terug te komen
Ik heb gewoon een typedef gemaakt die je weer zere pinken bespaard van op de caps drukken
Is heel simpel ding maar toch beter voor de gezondheid

#define null NULL

Ik haat echt dat overdreven capslock gebruik van M$

[.oisyn]

Op maandag 10 september 2001 21:55 schreef Liquidus het volgende:
Om ff op die null zooi terug te komen
Ik heb gewoon een typedef gemaakt die je weer zere pinken bespaard van op de caps drukken
Is heel simpel ding maar toch beter voor de gezondheid

#define null NULL

Ik haat echt dat overdreven capslock gebruik van M$

Haha, java pansy

Maar NULL is niet van M$ hoor

Persoonlijk doe ik mijn defines altijd in hoofdletters, dan weet ik dat het een define of een constante is (en vele mensen met mij), maar das subjectief natuurlijk

Maar ik wil nou wel even weten wat curry en Mietje te zeggen hebben over mijn benchmark

[farlane]

#define is geen typedef maar een macro. Een typedef is een typedef.

[Orphix]

Ik geloof dat het niet een hele eerlijke vergelijking is, jij weet ook wel dat er bij de operator+ met objecten word rondgegooid alsof het niks. Een operator*= zou al veel effectiever zijn. En bovendien is mietje's versie efficienter in ruimtegebruik (al vraag ik me af wanneer je zoveel identieke matrices hebt) en meer features is over het algemeen langzamer.

[Verwijderd]

In het algemeen:

• In C++ is het niet gebruikelijk met NULL te werken. Het is in C++ gegarandeerd dat een null-pointer waarde 0 heeft. NULL is dan ook nergens gedefinieerd in de C++ headers.
• Ik heb geen readable code willen produceren, ik heb het, zoals al gemeld, in 10 minuten onder werktijd in elkaar geflansd.

Over de snelheid:
• Ik heb een benchmark gemaakt die het verschil laat zien tussen werken met dummy objecten die dynamisch door de compiler worden gegenereerd en weer vernietigd (+ operator), tov. werken met referenties (+= operator).
• Ik heb niet geprobeerd snelle code te schrijven, het ging me enkel en alleen erom het bovengenoemde verschil aan te tonen, wat dus vrij klein is als er echt met de objectrepresenentaties gewerkt moet worden.
• Als je m'n code tweakt zodat een copy-on-demand geen copy-on-demand meer is, is alle copy-on-demand code overhead. (Door altijd een _rep te alloceren, dat kan alleen efficient met een static _MatrixRep, maar dat was me te veel werk; ik weet niet wat je precies gedaan hebt).

[.oisyn]

Op dinsdag 11 september 2001 00:20 schreef Orphix het volgende:
Ik geloof dat het niet een hele eerlijke vergelijking is, jij weet ook wel dat er bij de operator+ met objecten word rondgegooid alsof het niks. Een operator*= zou al veel effectiever zijn. En bovendien is mietje's versie efficienter in ruimtegebruik (al vraag ik me af wanneer je zoveel identieke matrices hebt) en meer features is over het algemeen langzamer.

Ja maar we hadden het juist over de implementatie van een + of * om dat efficient te implementeren, en DUS zei ik dat ik een void operator * (result, operand1, operand2) constructie mistte in C++.

Bovendien hadden we het niet over ruimtegebruik, we hadden het over snelheid, en dat is ook meerdere keren ter sprake gekomen. Maar net als jij zegt, ik ben nog nooit tegen gekomen dat ik een matrix alleen kopieerde zonder er verder wat mee te doen, en geloof me, mijn matrix en vector klassen gebruik ik veeeeeeeeeeeel

maar ik heb trouwens nog geen reactie van zowel Mietje als Curry gezien... vraag me af wat ze te zeggen hebben

[.oisyn]

Op dinsdag 11 september 2001 00:25 schreef mietje het volgende:
In het algemeen:
• In C++ is het niet gebruikelijk met NULL te werken. Het is in C++ gegarandeerd dat een null-pointer waarde 0 heeft. NULL is dan ook nergens gedefinieerd in de C++ headers.

dan moet je mij toch eens uitleggen waarom bijna iedereen het gebruikt

.edit: ik heb eens in mijn C++ headers gekeken, en ik moet je toch sterk ongelijk geven: in bijna ELKE C++ header wordt NULL gedefinieerd, in alle 4 implementaties die ik hier op mijn hdd heb staan (MSVC, DJGPP, ARM C++, devkitgba)

• Ik heb geen readable code willen produceren, ik heb het, zoals al gemeld, in 10 minuten onder werktijd in elkaar geflansd.

leesbare code kan ik net zo snel schrijven als niet-leesbare code, en jij ook wel denk ik, dus ik vind het maar een slap excuus (tenzij je het in notepad hebt gedaan natuurlijk)

Over de snelheid:
• Ik heb een benchmark gemaakt die het verschil laat zien tussen werken met dummy objecten die dynamisch door de compiler worden gegenereerd en weer vernietigd (+ operator), tov. werken met referenties (+= operator).

en wat wilde je hiermee bewijzen dan? Het ging om mijn implementatie en die van jou, dus ik snap je even niet

• Ik heb niet geprobeerd snelle code te schrijven, het ging me enkel en alleen erom het bovengenoemde verschil aan te tonen, wat dus vrij klein is als er echt met de objectrepresenentaties gewerkt moet worden.

maar wat ik probeerde aan te tonen is dat je absoluut GEEN gebruik van new/delete moet maken als je snelle code wilt schrijven

• Als je m'n code tweakt zodat een copy-on-demand geen copy-on-demand meer is, is alle copy-on-demand code overhead. (Door altijd een _rep te alloceren, dat kan alleen efficient met een static _MatrixRep, maar dat was me te veel werk; ik weet niet wat je precies gedaan hebt).

als je mijn code leest, dan zie je dat ik niet elke keer een MatrixRep alloceer, maar een globale MatrixRep gebruik die start met een count groter dan 1, dus die nooit kan worden aangepast of gedelete. Als je een nieuwe Matrix maakt dan wijst ie automatisch naar deze globale matrix, dus er is juist overhead verdwenen (de check of rep NULL is of niet)

[curry684]

Op dinsdag 11 september 2001 00:34 schreef OiSyN het volgende:
maar ik heb trouwens nog geen reactie van zowel Mietje als Curry gezien... vraag me af wat ze te zeggen hebben

Hee soms hebben mensen ook even andere dingen te doen dan ander de computer te nerden okee?

Maar ik verwijs je terug naar een van mijn postings eerder op de dag als afdoende antwoord:

Het lijkt mij persoonlijk sterk dat dit veel sneller is dan goede ultradunne classes met const-by-ref copy-on-demand semantics. Misschien in dit specifieke geval wel maar zodra je een functiecall ermee doet ben je die minieme winst alweer kwijt.

Schrijf maar een realworld programma met tientallen classes die een stapel rekenwerk verrichten op je matrixen en gebruik dan zowel de copy-on-demand Matrix als de 'dumb copy' variant. Een straight-run benchmark doet de implementatie simpelweg geen eer aan.

You'll learn to love it...

Overigens geldt dit natuurlijk alleen voor data-storage classes die veel heen en weer worden geslingerd en niet voor dingen waarvan je er in de runtime van je programma maar enkele aanmaakt met een enorme lifetime (zoals die _aw_window wat wel een erg slecht voorbeeld was). Ik gebruik zelf copy-on-demand niet alleen voor string-classes maar bijvoorbeeld ook voor variants, time-containers, binary containers e.d. Niet voor MyMainWindow of MyNetworkManager natuurlijk

[Verwijderd]

Op dinsdag 11 september 2001 00:36 schreef OiSyN het volgende:
dan moet je mij toch eens uitleggen waarom bijna iedereen het gebruikt

NULL is een C archaisme uit de tijd dat een null-pointer op bepaalde architecturen bv. waarde 0xffffffff kon hebben. Toen moest je wel. In C++ is een null-pointer gegarandeerd 0, dus NULL is volledig onnodig. Het komt dus door C-programmeurs die moeite hebben oude gewoontes af te leren

leesbare code kan ik net zo snel schrijven als niet-leesbare code, en jij ook wel denk ik, dus ik vind het maar een slap excuus (tenzij je het in notepad hebt gedaan natuurlijk)

In vim Zo erg vind ik het zelf trouwens ook niet, ik kom nu eenmaal uit de unix wereld, en daar is die "STL"-achtige coding style toch de doorsnee (en ook 0 ipv. NULL).

maar wat ik probeerde aan te tonen is dat je absoluut GEEN gebruik van new/delete moet maken als je snelle code wilt schrijven

Dat ben ik helemaal met je eens. Dat betekent dus meteen dat je met array-representaties van dynamische structuren zoals linked lists en trees moet gaan zitten violen, waarbij je pointers indexen in de array's zijn, enz. Daar heb ik geen zin meer in, daar krijg ik fortran nachtmerries van.

Ik ben meer van het type goed genoeg, ik ga niet elk stukje code zitten bummen. Dan produceer ik liever herbruikbare, algemeen toepasbare code. Dit is voor mij persoonlijk overigens ook de reden om C++ boven C te verkiezen, bij C kom je maar heel moeilijk boven het abstractieniveau van de machine uit, en het verleidt je constant te gaan optimaliseren.

als je mijn code leest, dan zie je dat ik niet elke keer een MatrixRep alloceer, maar een globale MatrixRep gebruik die start met een count groter dan 1, dus die nooit kan worden aangepast of gedelete. Als je een nieuwe Matrix maakt dan wijst ie automatisch naar deze globale matrix, dus er is juist overhead verdwenen (de check of rep NULL is of niet)

Ah, dat bedoelde ik dus, dat was me te veel werk, ik was begonnen null-pointers en had niet veel tijd meer Ik zou die _MatrixRep overigens niet als globaal maar als private static binnen Matrix gedefinieerd hebben. (Ik kan hem niet lezen trouwens )

[.oisyn]

Op dinsdag 11 september 2001 01:11 schreef mietje het volgende:

NULL is een C archaisme uit de tijd dat een null-pointer op bepaalde architecturen bv. waarde 0xffffffff kon hebben. Toen moest je wel. In C++ is een null-pointer gegarandeerd 0, dus NULL is volledig onnodig. Het komt dus door C-programmeurs die moeite hebben oude gewoontes af te leren

lees ook even mijn edit in mijn vorige post

Dat ben ik helemaal met je eens. Dat betekent dus meteen dat je met array-representaties van dynamische structuren zoals linked lists en trees moet gaan zitten violen, waarbij je pointers indexen in de array's zijn, enz. Daar heb ik geen zin meer in, daar krijg ik fortran nachtmerries van.

i know what you mean

Ik ben meer van het type goed genoeg, ik ga niet elk stukje code zitten bummen. Dan produceer ik liever herbruikbare, algemeen toepasbare code. Dit is voor mij persoonlijk overigens ook de reden om C++ boven C te verkiezen, bij C kom je maar heel moeilijk boven het abstractieniveau van de machine uit, en het verleidt je constant te gaan optimaliseren.

Ik ook hoor, als ik een gewone windows applicatie schrijf dan boeit het me ook niet, maar over het algemeen ben ik bezig met spellen en/of computer graphics, en ja, dan zijn dat soort constructies echt uit den boze, en dan lap ik de meeste OO regels aan mijn laars

Ah, dat bedoelde ik dus, dat was me te veel werk, ik was begonnen null-pointers en had niet veel tijd meer Ik zou die _MatrixRep overigens niet als globaal maar als private static binnen Matrix gedefinieerd hebben. (Ik kan hem niet lezen trouwens )

Hij is ook private static, maar alleen in de klasse MatrixRep

[Verwijderd]

Op dinsdag 11 september 2001 01:18 schreef OiSyN het volgende:
lees ook even mijn edit in mijn vorige post

Echt in een C++ standaard header? (die bij libc++ hoort en niet bij libc) Het is iig. geen macro die gedefinieerd moet zijn volgens de standaard. (Dat C++ garandeert dat een pointerwaarde 0 een trap/segfault veroorzaakt is wel deel van de standaard.)

Het lijkt me toch echt vreemd, dat in C++ officieel het gebruik van een macro aangeraden wordt.

[curry684]

Op dinsdag 11 september 2001 01:11 schreef mietje het volgende:
NULL is een C archaisme uit de tijd dat een null-pointer op bepaalde architecturen bv. waarde 0xffffffff kon hebben. Toen moest je wel. In C++ is een null-pointer gegarandeerd 0, dus NULL is volledig onnodig. Het komt dus door C-programmeurs die moeite hebben oude gewoontes af te leren

Uhhhhhh ik heb nooit een regel C geprogrammeerd (okee niet veel in ieder geval ) maar gebruik puur voor het onderscheid tussen pointers en values wel altijd NULL. Het voordeel binnen C++ imho is dat je variabeledeclaraties vaak in een compleet andere file staan dan de plek waar je 'm gebruikt, en binnen de volgende constructor heeft NULL denk ik een goede meerwaarde:

code:

MyClass::MyClass()
{
// Initialize properties
m_Manager     = NULL;
m_Allocator = NULL;
m_Parent       = NULL;
m_InternalIndex  = 0;
m_RandomSeed     = 0;
}

Je ziet tenminste in 1 oogopslag wat de pointers zijn.

Just my 2 cents.

[Korben]

Op dinsdag 11 september 2001 00:36 schreef OiSyN het volgende:

.edit: ik heb eens in mijn C++ headers gekeken, en ik moet je toch sterk ongelijk geven: in bijna ELKE C++ header wordt NULL gedefinieerd, in alle 4 implementaties die ik hier op mijn hdd heb staan (MSVC, DJGPP, ARM C++, devkitgba)

Tja, en toch... toch denken sommige libs slim te zijn

code:

#undef NULL

Leuk...

[Korben]

Op maandag 10 september 2001 18:35 schreef farlane het volgende:

Hmm...waarom maakt dit code leesbaarder? Redelijk subjectief. (Ik vind NULL in code lelijk/onnodig)

Ja maar als je bug aan het opsporen bent, kan het zijn dat NULL duidelijker is, omdat NULL een soort van magische pointer lijkt te zijn. Persoonlijk vindt ik - in vergelijkingen - dit nog duidelijker:

code:

if (!bert)
{
   // bert == NULL
}

En iets wat volgens mij al gepost is (maar ik doe het lekker nog een keer):

code:

a = 0;
b = 0;
d = 0.0;
e = 0.0;
p = NULL;
q = NULL;

Hier zie je heel duidelijk dat p en q pointers zijn, en dat a en b chars, ints of longs zijn. En d en e natuurlijk floats/doubles.

[drm]

Op maandag 10 september 2001 22:58 schreef farlane het volgende:
#define is geen typedef maar een macro. Een typedef is een typedef.

*ding*dong*. Maar waar hangt nu de klepel?

Een #define is een preprocessor-directive.

code:

#define  _SJAAK   0

_SJAAK is geen macro.

code:

#define  _SJAAK(a)  (a/12)

_SJAAK is een macro, want dit betekent dat de compiler alle _SJAAK() aanroepen vervangt door (argument/12).

mietje:

[..]

Echt in een C++ standaard header? (die bij libc++ hoort en niet bij libc) Het is iig. geen macro die gedefinieerd moet zijn volgens de standaard. (Dat C++ garandeert dat een pointerwaarde 0 een trap/segfault veroorzaakt is wel deel van de standaard.)

Het lijkt me toch echt vreemd, dat in C++ officieel het gebruik van een macro aangeraden wordt.

Het lijkt mij echt vreemd, dat wanneer een macro het leven van de (mede)programmeur gewoon wat makkelijker maakt, er mensen zijn die schreeuwen dat macro's geen std c++ zijn. Lekker belangrijk.
Iedereen weet wat NULL inhoudt, dus waarom zou je het niet gebruiken?

(en ik vind het de code een stuk leesbaarder maken, maar dat ff daar gelaten)

[Verwijderd]

Op dinsdag 11 september 2001 08:55 schreef drm het volgende:
Het lijkt mij echt vreemd, dat wanneer een macro het leven van de (mede)programmeur gewoon wat makkelijker maakt, er mensen zijn die schreeuwen dat macro's geen std c++ zijn. Lekker belangrijk.
Iedereen weet wat NULL inhoudt, dus waarom zou je het niet gebruiken?

In C++ zijn macro's (of hoe je ze ook noemen wilt) uit den boze. Je kunt constantes definieren en inlinen, features die speciaal bedacht zijn om het gebruik van macro's te vermijden.

(en ik vind het de code een stuk leesbaarder maken, maar dat ff daar gelaten)

Ah, mijn stokpaardje dus NULL is leesbaarder dan 0? Ok, dan is dit dus de bedoeling:

#define ONE 1
#define TWO 2
#define ADD +
#define END ;
#define ASSIGN =
#define NUMBER int

NUMBER X ASSIGN ONE ADD TWO END

Duidelijk toch, het lijkt wel cobol, en perfecte C++. Dit is ad extremis, maar je begrijpt dat ik van mening ben dat dit soort dingen code niet leesbaarder maakt.

[curry684]

Op dinsdag 11 september 2001 10:27 schreef mietje het volgende:
In C++ zijn macro's (of hoe je ze ook noemen wilt) uit den boze. Je kunt constantes definieren en inlinen, features die speciaal bedacht zijn om het gebruik van macro's te vermijden.

Wat een onzin. Macro's zijn VEEL krachtiger dan inline global methods, omdat ze kunnen tokenpasten. Ik gebruik heel veel helpermacro's bij enumerated switches e.d., bijv.:

code:

#define MCaseThrow(p_ExceptionName, p_Text)     \
  case e_Enum##p_ExceptionName: throw MyPrefix##p_ExceptionName((#p_Text))

switch(l_ReturnType)
  {
  MCaseThrow(Blahdiblah, L"Probleem bij dinges");
  MCaseThrow(BlahEnZo, L"Probleem bij andere dinges");
  MCaseThrow(BlahZooi, L"Probleem bij iemand's dingetje");

  // En zo 30 keer...
  }

Kijk een macro is vaak niet mooi, en voor constantes inderdaad niet de correcte C++ oplossing. Indien goed gebruikt zijn ze echter ZEKER niet uit den boze.

[.oisyn]

Op dinsdag 11 september 2001 10:27 schreef mietje het volgende:

[..]

In C++ zijn macro's (of hoe je ze ook noemen wilt) uit den boze. Je kunt constantes definieren en inlinen, features die speciaal bedacht zijn om het gebruik van macro's te vermijden.

Uit den boze?!?! Jij hebt zeker nooit gewerkt met verschillende build settings gewerkt, dus dat je verschillende delen van je code aan/uit kan zetten door een #define op 0 of 1 te zetten.
En assert () gebruik je zeker ook nooit?

Ah, mijn stokpaardje dus NULL is leesbaarder dan 0? Ok, dan is dit dus de bedoeling:

#define ONE 1
#define TWO 2
#define ADD +
#define END ;
#define ASSIGN =
#define NUMBER int

NUMBER X ASSIGN ONE ADD TWO END

of je begrijpt het gewoon niet, of je wilt het begrijpen. Ik legde net uit (en andere mensen hier ook) dat je met NULL het verschil tussen een int en een pointer kan zien. Dan moet je niet #define ONE 1 ofoiets gaan doen, want dan is dat hele verschil weg

Duidelijk toch, het lijkt wel cobol, en perfecte C++. Dit is ad extremis, maar je begrijpt dat ik van mening ben dat dit soort dingen code niet leesbaarder maakt.

Nou niet echt duidelijk, en idd niet leesbaar, en ik kan me ook niet iemand voorstellen die zoiets gebruikt

[Verwijderd]

Op dinsdag 11 september 2001 12:37 schreef curry684 het volgende:

code:

#define MCaseThrow(p_ExceptionName, p_Text)     \
  case e_Enum##p_ExceptionName: throw MyPrefix##p_ExceptionName((#p_Text))

switch(l_ReturnType)
  {
  MCaseThrow(Blahdiblah, L"Probleem bij dinges");
  MCaseThrow(BlahEnZo, L"Probleem bij andere dinges");
  MCaseThrow(BlahZooi, L"Probleem bij iemand's dingetje");

  // En zo 30 keer...
  }

Vind je die code nu echt leesbaar? Is het echt zoveel werk een kortere naam voor je objects te verzinnen? Dan hoef je geen macro's te schrijven die je tiepwerk besparen ten koste van leesbaarheid (dat is namelijk het enige wat die macro doet, tiepwerk besparen).

Inderdaad zijn macro's handig, maar ze worden echt afgeraden in C++ omdat er geen typechecking gebeurt. Voor zeer speciale zaken zoals fout-regelnummers en het genereren van library-namen kun je niet zonder, maar voor de rest kun je stellen dat het gebruik van macro's in C++ kludges zijn.

[farlane]

Een #define is een preprocessor-directive.

Klopt. Ik beweerde ook niet anders.

code:

#define  _SJAAK   0

_SJAAK is geen macro.

Het is nog minder een typedef.
(Hoe noem jij dit eigenlijk wel dan?)

code:

#define  _SJAAK(a)  (a/12)

_SJAAK is een macro, want dit betekent dat de compiler alle _SJAAK() aanroepen vervangt door (argument/12).

De compiler? Het was toch een preprocessor directive?

Als ik schrijf:

code:

#define MAX_SIZE 100

char a[MAX_SIZE]={0};

Is het volgens jou geen macro. Toch wordt MAX_SIZE overal in het programma door 100 vervangen. (door de preprocessor wel te verstaan).

[drm]

Je hebt gelijk. In de oorspronkelijke terminologie heet dat ook een macro. Ik zal de verkeerde boeken wel gelezen hebben...

excuses

farlane:
De compiler? Het was toch een preprocessor directive?

daar ga ik maar niet op in.

[farlane]

Ik zal de verkeerde boeken wel gelezen hebben...

Die meneer in je sig heeft nog wel een leuke

daar ga ik maar niet op in.

Waarom niet?

[.oisyn]

jezus man stelletje miereneukers, jullie verkrachten de hele topic

[Sponz]

Op dinsdag 11 september 2001 08:32 schreef Xenophage het volgende:

[..]

En iets wat volgens mij al gepost is (maar ik doe het lekker nog een keer):

code:

a = 0;
b = 0;
d = 0.0;
e = 0.0;
p = NULL;
q = NULL;

Hier zie je heel duidelijk dat p en q pointers zijn, en dat a en b chars, ints of longs zijn. En d en e natuurlijk floats/doubles.

In mijn ogen behoorlijk onduidelijk...

Want het maakt nogal veel uit of je nou met een long of char bv een loopje gaat maken.

Het meest leesbare bereik je (mijns inziens) door een naming convention toe te passen, door bijvoorbeeld de indentifier vooraf te laten gaan door een type indicatie (bv iLoop is een int, cLetter is een char, piInteger een pointer naar een int ect).

Ben je ook van het NULL/0 geleuter af.

[farlane]

Op dinsdag 11 september 2001 14:49 schreef OiSyN het volgende:
jezus man stelletje miereneukers, jullie verkrachten de hele topic

pardon

[.oisyn]

Op dinsdag 11 september 2001 14:55 schreef farlane het volgende:

[..]

pardon

kom op heej je wilt toch niet zeggen dat dat serieus ergens over ging, wat nou een macro is en wat niet, en wat door de preprocessor wordt gedaan en wat door de compiler. Dat is gewoon simpelweg elkaar afzeiken op kleinse onbenullige dingetjes, oftewel: miereneuken

[Verwijderd]

Op dinsdag 11 september 2001 15:01 schreef OiSyN het volgende:

[..]

kom op heej je wilt toch niet zeggen dat dat serieus ergens over ging, wat nou een macro is en wat niet, en wat door de preprocessor wordt gedaan en wat door de compiler. Dat is gewoon simpelweg elkaar afzeiken op kleinse onbenullige dingetjes, oftewel: miereneuken

Precies....

[farlane]

...oftewel: miereneuken..

Ik bedoelde ook eigenlijk pardon in de sfeer van 'excuses voor het verkrachten van je topic'. Drukte me niet helemaal duidelijk uit...pardon. ( )

(Alhoewel drm wel met klepels e.d. begon te smijten)

[.oisyn]

Op dinsdag 11 september 2001 15:05 schreef farlane het volgende:

[..]

Ik bedoelde ook eigenlijk pardon in de sfeer van 'excuses voor het verkrachten van je topic'. Drukte me niet helemaal duidelijk uit...pardon. ( )

(Alhoewel drm wel met klepels e.d. begon te smijten)

ah zo, dan begreep ik je verkeerd

pardon

[Verwijderd]

ECS40-B, Spring 2001, UCD
Pointers
Like C, but different mechanism for allocation.* Deference with *
* Integer 0 can be cast to any pointer type. Represents a pointer to nothing. Old C NULL macro is depreciated.
* Use new and delete to manage dynamic memory.
* Different constant pointers using const (§5.4).
Ref: Stroustrup 5.1

I sure hope this settles it

[drm]

Op dinsdag 11 september 2001 14:45 schreef farlane het volgende:

Die meneer in je sig heeft nog wel een leuke

Die meneer in mijn sig heeft het gek genoeg nooit over macro's in zijn boek.

Waarom niet?

Omdat, wanneer ik het over een compiler heb, heb ik het over een programma dat een preprocessordeel en een compilerdeel bevat, hoe ambigu het ook klinkt.

[Korben]

Op dinsdag 11 september 2001 14:50 schreef Sponz het volgende:

[..]

In mijn ogen behoorlijk onduidelijk...

Want het maakt nogal veel uit of je nou met een long of char bv een loopje gaat maken.

Het meest leesbare bereik je (mijns inziens) door een naming convention toe te passen, door bijvoorbeeld de indentifier vooraf te laten gaan door een type indicatie (bv iLoop is een int, cLetter is een char, piInteger een pointer naar een int ect).

Ben je ook van het NULL/0 geleuter af.

Ja maar als je naar deze twee stukken code kijkt:

1:

code:

a = 0;
b = 0;
c = 0;
d = 0;
p = 0;
q = 0;

2:

code:

a = 0;
b = 0;
c = 0.0;
d = 0.0;
p = NULL;
q = NULL;

Alletwee compilen foutloos, alleen is bij stukje twee iig globaal duidelijk wat de typen zijn (a/b integer, c/d floating point, p/q pointer).

En persoonlijk heb ik de schijt aan naming conventions. Ik vind van die hoofdletters midden in een woord gewoon lelijk, en al helemaal bij C/C++, waar de rest van alle vars/functies ook gewoon in kleine letters is. Ik bedoel, zeg nou zelf, dit staat toch niet mooi:

code:

LPBITMAPINFOHEADER lpbmihBert;

Je moet eerst zes letters typen voordat je uiteindelijk bij de 'naam' komt. Vrij omsl8ig, nmm. Dan vind ik dit toch beter:

code:

LPBITMAPINFOHEADER bert_info_header;

Maar goed, dat ligt allemaal aan je eigen stijl, en wie ben ik om jullie stijl te beoordelen. Hij zuigt natuurlijk wel als ie niet op de mijne lijkt, maar goed...

[Verwijderd]

Op dinsdag 11 september 2001 15:29 schreef drm het volgende:
Die meneer in mijn sig heeft het gek genoeg nooit over macro's in zijn boek.

Grappig zeg, ik post net een quote met een reference naar paragraaf 5.1 van zijn beroemde boek...

[.oisyn]

Op dinsdag 11 september 2001 15:14 schreef mietje het volgende:

-------
ECS40-B, Spring 2001, UCD
Pointers
Like C, but different mechanism for allocation.* Deference with *
* Integer 0 can be cast to any pointer type. Represents a pointer to nothing. Old C NULL macro is depreciated.
* Use new and delete to manage dynamic memory.
* Different constant pointers using const (§5.4).
Ref: Stroustrup 5.1
-------

I sure hope this settles it

alsof ik een artikel/stuk tekst geloof waar tiepfouten in staan

[farlane]

Die meneer in mijn sig heeft het gek genoeg nooit over macro's in zijn boek.

blz 88 van de derde versie staat wat over macro's (en de NULL macro).

[Verwijderd]

Op dinsdag 11 september 2001 15:48 schreef OiSyN het volgende:
alsof ik een artikel/stuk tekst geloof waar tiepfouten in staan

Tja, als iedereen royaal met de copyrights strooit, moet ik wel het materiaal van een professor quoten (UCD = University of California. Davis)