Voordeel van classes?

dinsdag 10 september 2002 17:24

Moderator Devschuur®

Demotivational Speaker

Gezien je post history neem ik aan dat je vooral met php werkt...

In php werk je met handles, bij bijvoorbeeld de file of de database functies. In principe werk je hier ook object georienteerd: zo'n handle kun je zien als een object. Het enige verschil tussen een class met functies en losse functies die zo'n handle accepteren is de syntax: de OO variant is imho veel leesbaarder:

PHP:

// met functies:
$db = mysql_connect_db (...);
$query = mysql_query ($db, ...);
while ($row = mysql_fetch_row ($query))
{
    ....
}

// in OO:
$db = new Database (...);
$query = $db->query (...);
while ($row = $query->fetchRow ())
{
    ...
}

Wat echter met losse functies en handlers veel moeilijker te realiseren is, zijn dingen als polymorphisme en inheritance (geloof trouwens ook niet dat dat met php kan). Maar dan zou ik je toch aanraden een boek/lap text over OO concepten door te nemen

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:

Ericston

En geen operator overloading. Function overloading is op een vieze manier (daarvoor is je class een black box

) wel mogelijk.

dinsdag 10 september 2002 17:28

Acties:

dinsdag 10 september 2002 17:43

Moderator Devschuur®

Demotivational Speaker

Ericston schreef op 10 september 2002 @ 17:24:
En geen operator overloading. Function overloading is op een vieze manier (daarvoor is je class een black box ) wel mogelijk.

operator overloading wordt in zoveel OO talen niet ondersteund, en is imho ook totaal geen vereiste van een OO taal

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

.oisyn schreef op 10 september 2002 @ 17:28:
operator overloading wordt in zoveel OO talen niet ondersteund, en is imho ook totaal geen vereiste van een OO taal

Je haalde zelf een stuk hierboven het concept leesbaar aan... vergelijk wat spul:

code:

MyString      l_String("bier");
l_String.Append('!');
l_String.Prepend("Drink ");
l_String.Append(" Da's meer plezier!");

MyVector     l_Vector1(2,5);
MyVector     l_Vector2(6,9);
MyVector     l_Vector3(l_Vector1);
l_Vector3.Add(l_Vector2);

met:

code:

MyString  l_String = "bier";
l_String          += "!";
l_String           = "Drink " + l_String + " Da's meer plezier!";

MyVector     l_Vector1(2,5);
MyVector     l_Vector2(6,9);
MyVector     l_Vector3 = l_Vector1 + l_Vector2;

De onderste variant is echt leesbaarder imho...

Ennuh ik illustreer hier ook nog het nut van classes

dinsdag 10 september 2002 18:02

Acties:

dinsdag 10 september 2002 18:03

f0pc0dert

De vraag wat het nut van classes is eigenlijk heel simpel te beantwoorden: anders kun je geen objecten maken

^</flauw>

Het voordeel in PHP van classes is imo niet meer dan je code onderbrengen onder een naampje (namespace)

Je zou bijvoorbeeld 2 classes kunnen hebben: File en Socket

PHP:

$s = new Socket ( 'blaat' ); // create socket connection to 'blaat'
$s->write ( 'hallo daar!' ); // write a string to the socket
$str = $s->read ( 256 );     // read 256 bytes from the socket

$f = new File ( 'blaat2' );  // open file 'blaat2'
$f->write ( 'hallo daar!' ); // write a string to the file
$str = $f->read ( 256 );     // read 256 bytes from the file

Je ziet hier dat je 2 "functions" read hebt, die beiden een andere invulling (moeten) hebben. Dat de functies dezelfde naam hebben maakt het een stuk leesbaarder, dan prependen met bijvoorbeeld:

PHP:

1
2
3

$str = socket_read ( $sd, 256 );
// of
$str = file_read ( $fd, 256 );

Er zijn nog een aantal principes die in PHP praktisch niet toe te passen

voorbeeldje daarvan is interfacing, waarbij je voor een class een 'mal' verzint die vertelt hoe een class in elkaar moet zitten. Andere onderdelen van een programma kunnen dan aan de hand van de interface erop 'rekenen' hoe een class in elkaar zit. Hoe de class verder ingevuld is, staat in principe niet verder vast dan de interface vertelt. Maar wat dat betreft zou je misschien meer naar Java (interfaces) of C++ (virtual classes) of C# (?) moeten kijken.

_edit:
Over de operator-overloading discussie is in dit topic nog e.e.a. gezegd. Was leuk en heel leerzaam

[ Voor 0% gewijzigd door drm op 10-09-2002 18:07 . Reden: operator overloading ]

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

dinsdag 10 september 2002 18:14

Moderator Devschuur®

Demotivational Speaker

Curry684: uiteraard, uiteraard, en ik ben ook ontzettend blij met de operator overloading van C++. Maar ik zie het niet als een OO concept

(en de reden om OO te coden gaat imho verder dan alleen leesbaarheid, zoals ik ook in mijn vorige post aangaf (de voorbeelden polymorphisme en inheritance)

)

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:

dinsdag 10 september 2002 18:24

Moderator Devschuur®

Demotivational Speaker

drm schreef op 10 september 2002 @ 18:02:
C++ (virtual classes)

een virtual class (virtual base class eigenlijk) is wat anders dan inheritance en abstraction wat jij bedoelt, en is alleen van belang als de inheritance graaf cyclisch is (B extends A; C extends A; D extends B, C - class D heeft nu 2 base classes A). Is ook alleen maar mogelijk met multiple inheritance

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

Topicstarter

Ik heb het ff vlugtig doorgelezen, maar snap het nog steeds niet, ook met een functie kan je goede data returnen en bepaalde data processen zonder dat de rest van je scripts daar de dupe van zijn (indien je natuurlijk goed programmeert) maar als je een include maakt maak je dus als het ware ook een class welliswaar dat het dan geen class genoemd wordt

dinsdag 10 september 2002 18:48

Acties:

Glimi

Designer Drugs

Verwijderd schreef op 10 september 2002 @ 18:24:
Ik heb het ff vlugtig doorgelezen, maar snap het nog steeds niet, ook met een functie kan je goede data returnen en bepaalde data processen zonder dat de rest van je scripts daar de dupe van zijn (indien je natuurlijk goed programmeert) maar als je een include maakt maak je dus als het ware ook een class welliswaar dat het dan geen class genoemd wordt

PHP is zo kreupel als ome joop qua OO. Geen Polymorphisme

Echter wat PHP wel kan met classes en jij niet met je includes:

-Ik heb een include die een GoedeBelastingControleur moet voorstellen en een die een KloteBelastingControleur moet voorstellen. Beiden moeten ze gaan conroleren op een boekhouding ( stel in dit geval een array )

PHP:

include( "GoedeBelastingControleur.inc" );
include( "KloteBelastingControleur.inc" );

controleer( someBoekhouding );

Hoe weet PHP in jesusnaam nu dat hij de functie uit KloteBelastingControleur of uit GoedeBelastingControleur moet nemen? Dat weet hij niet, en daarom geeft hij een function redeclaration error. Wat doe jij dan. Bij GoedeBelastingControleur noem je hem goedecontorleer( ) en bij KloteBelastingControleur slechtecontroleer( ) oid. Maar daarmee ga je je business logica in de naam gooien en houdt je dus niet de details van de functie verborgen voor mensen die hem gebruiken! Met OO kan dit wel omdat je dan de functie van de classe aanspreekt.

PHP:

1 2	goedeControleur->controleer( someBoekhouding ); kloteControleur->controleer( someBoekhouding );

-Inheritance, hoe wou je dat gaan doen met je includes?

dinsdag 10 september 2002 19:11

Acties:

LordLarry

Aut disce aut discede

Begin eerst maar eens met een echte programmeer taal, dan praten we verder.

En vooral niet zo'n taal als php waarbij het de gewoonte is html en php onbeperkt door elkaar te mixen, oftewel de UI en de logica.

We adore chaos because we like to restore order - M.C. Escher

dinsdag 10 september 2002 19:51

Acties:

dinsdag 10 september 2002 22:00

Because he doesn't row...

Glimi schreef op 10 september 2002 @ 18:48:
[...]

PHP is zo kreupel als ome joop qua OO. Geen Polymorphisme

PHP heeft polymorphisme niet rechtstreeks nodig omdat het weak typed is. Wat dacht je hier van?

PHP:

class A {
    function A () {
        print('A constructed<BR>');
    }

    function foo() {
        print('A::foo()<BR>');
    }

    function ola() {
        print('A::ola()<BR>');
    }
}

class B extends A {
    function B() {
        A::A();
        print('B constructed<BR>');
    }

    function foo() {
        print('B::foo()<BR>');
    }
}

// Here we do something on an A object
function blah(&$classA) {
    $classA->foo();
    $classA->ola();
}

$b = new B();
blah($b);

En dit geeft PHP ook wel weer leuke mogelijkheden (hoewel ik het wel liever als strong typed had gezien...) Maar code zoals dit is bv al behoorlijk lastig om in C++ te maken:

PHP:

    function dispatch($action, &$vars) {
        if ($action != '' && isSet($this->registry[$action])) {
            $entry = &$this->registry[$action];
            
            $params = array();
            foreach($entry['params'] AS $k => $v) {
                if (isSet($vars[$k])) {
                    $params[$k] = $vars[$k];
                } else if ($v != '') {
                    $params[$k] = $v;
                } else {
                    //error
                    return false;
                }
            }

            if (is_object($obj = &$this->factory($entry['class']))) {
                return $obj->$entry['function']($this->pass, $params);
            } else return false;
        } else {
            return false;
        }
    }

    function &factory($classname) {
        $classpath = 'class/'.$classname.'.class.php';

        if (file_exists($classpath)) {
            require_once($classpath);
            $obj = &new $classname($this->pass);
            return $obj;
        } else return false;
    }

Ik programmeer prima OO in PHP, heb nu zelfs een heel framework van classes gemaakt. Dit is mijn standaard index.php:

PHP:

    require_once('class/system/main.class.php');

    $Main = new Main($HTTP_SESSION_VARS, $HTTP_GET_VARS, $HTTP_POST_VARS);
    $Main->start();

Hehe, kan het duidelijker?

Acties:

Verwijderd

Hehe, kan het duidelijker?

mja, als je nou niks nuttigs doet in je class dan heb je alleen een bestand en het instantiëren van een class extra...

dinsdag 10 september 2002 22:07

Acties:

dinsdag 10 september 2002 22:20

f0pc0dert

.oisyn:
een virtual class (virtual base class eigenlijk) is wat anders dan inheritance en abstraction wat jij bedoelt, en is alleen van belang als de inheritance graaf cyclisch is (B extends A; C extends A; D extends B, C - class D heeft nu 2 base classes A). Is ook alleen maar mogelijk met multiple inheritance

Ik dacht dat virtual classes virtual methods moesten bevatten, en dat virtual methods methods waren waarvan de body nog niet geimplementeerd waren en daarmee dus (tot op zekere hoogte) een equivalent van de Java abstract methods.... vandaar de paralell die trok tussen interfaces en virtual classes.

Misschien wel niet terecht (afgezien van het feit dat je in C++ zowel virtual als non-virtual methods in een class mag declareren), maar ik geloof dat ik dat dan niet helemaal begrepen heb, so teach me

_{* drm pakt alvast Bjarne er even bij}

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

dinsdag 10 september 2002 22:23

drm schreef op 10 september 2002 @ 22:07:
Ik dacht dat virtual classes virtual methods moesten bevatten

Dat is correct.

en dat virtual methods methods waren waarvan de body nog niet geimplementeerd waren en daarmee dus (tot op zekere hoogte) een equivalent van de Java abstract methods....

Nee, virtual methods zijn simpelweg dynamisch gebonden methoden (wat ze in Java dus altijd zijn). Pure-virtual methods zijn virtual methods zonder implementatie ("virtual void m() = 0") en die zijn dus wel te vergelijken met abstracte methoden in Java.

Denk er trouwens aan dat je in C++ ook nog virtual inheritance hebt, wat wil zeggen dat de body van een base class die meerdere keren ge-erft wordt, slechts eenmaal in het afgeleide object terecht komt. Dat fenomeen bestaat in Java niet, omdat door het gebruik van single implementation inherintance de implementatie van een base class maar een keer gebruikt kan worden.

Misschien wel niet terecht (afgezien van het feit dat je in C++ zowel virtual als non-virtual methods in een class mag declareren), maar ik geloof dat ik dat dan niet helemaal begrepen heb, so teach me

Bij deze. Eigenlijk zijn statisch gebonden methoden (en dan bedoel ik NIET Java's static methods, maar de tegenhanger van de 'virtual' ofwel dynamisch gebonden methoden) nergens goed voor. Ze bestaan waarschijnlijk vanwege de theorethische hogere efficientie (directe versus indirecte function call), maar in de praktijk is daar weinig van te merken.

Acties:

dinsdag 10 september 2002 22:25

Because he doesn't row...

ik denk dat je in de war bent met een "abstract" class, dat een class is die een of meer pure virtual (abstract) functions bevat. Als je hier van inherit wordt het een abstract base class, ofwel de bekende afkorting "abc". Dit is vergelijkbaar (maar zeer zeker niet hetzelfde) als een java interface.

Acties:

dinsdag 10 september 2002 22:32

Because he doesn't row...

Verwijderd schreef op 10 september 2002 @ 22:00:
[...]

mja, als je nou niks nuttigs doet in je class dan heb je alleen een bestand en het instantiëren van een class extra...

Nou als voobeeld dat je dus wel degelijk goed OO kan proggen in PHP, dit is mn main dan:

PHP:

require_once('include/constants.inc.php');
require_once('include/register.inc.php');

require_once('class/system/session.class.php');
require_once('class/system/dispatcher.class.php');
require_once('class/system/output.class.php');
require_once('class/system/database.class.php');

class Main {

    var $getVars;
    var $postVars;

    var $CSession;
    var $CDatabase;
    var $COutput;
    var $CDispatcher;

    function Main(&$session, &$getVars, &$postVars) {
        $this->getVars = &$getVars;
        $this->postVars = &$postVars;
        
        $this->CSession =& new Session($session);
        $this->CDispatcher =& new Dispatcher($this);
        $this->CDatabase =& new Database(C_DB_HOST, C_DB_USER, C_DB_PASS, C_DB_NAME);
        $this->COutput =& new Output();

        register($this->CDispatcher);
    }

    function connectDatabase() {
        if (!$this->CDatabase->connect()) {
            $this->COutput->dieError('Databeest heeft vandaag geen zin om uit zijn grot te komen. (database down)');
        }
    }

    function redirect($url) {
        header('location: '.$url);
        die();
    }

    function clientIP() {
        return $this->CSession->getip();
    }

    function start() {
        if (!isSet($this->getVars['action'])) $this->getVars['action'] = 'default';
        $this->connectDatabase();

        if (!$this->CDispatcher->dispatch($this->getVars['action'], $this->getVars)) {
            $this->COutput->dieError('Failed to dispatch action.');
        }

        $this->CDatabase->disconnect();
        $this->COutput->flush(isSet($this->getVars['l']));
    }
}

Acties:

dinsdag 10 september 2002 22:33

Because he doesn't row...

Soultaker schreef op 10 september 2002 @ 22:20:
Ze bestaan waarschijnlijk vanwege de theorethische hogere efficientie (directe versus indirecte function call), maar in de praktijk is daar weinig van te merken.

Dit stukje:

Why are member functions not virtual by default?
Because many classes are not designed to be used as base classes. For example, see class complex.
Also, objects of a class with a virtual function require space needed by the virtual function call mechanism - typically one word per object. This overhead can be significant, and can get in the way of layout compatibility with data from other languages (e.g. C and Fortran).

hier:
http://www.research.att.com/~bs/bs_faq2.html#virtual

[ Voor 0% gewijzigd door Zoijar op 10-09-2002 22:34 . Reden: verkeerde link ]

Acties:

dinsdag 10 september 2002 22:42

f0pc0dert

Soultaker:
Dat is correct.

Dat scheelt alvast

Nee, virtual methods zijn simpelweg dynamisch gebonden methoden (wat ze in Java dus altijd zijn). Pure-virtual methods zijn virtual methods zonder implementatie ("virtual void m() = 0") en die zijn dus wel te vergelijken met abstracte methoden in Java.

Denk er trouwens aan dat je in C++ ook nog virtual inheritance hebt, wat wil zeggen dat de body van een base class die meerdere keren ge-erft wordt, slechts eenmaal in het afgeleide object terecht komt. Dat fenomeen bestaat in Java niet, omdat door het gebruik van single implementation inherintance de implementatie van een base class maar een keer gebruikt kan worden.

Dat lees ik hier inderdaad net ook...

Bij deze. Eigenlijk zijn statisch gebonden methoden (en dan bedoel ik NIET Java's static methods, maar de tegenhanger van de 'virtual' ofwel dynamisch gebonden methoden) nergens goed voor. Ze bestaan waarschijnlijk vanwege de theorethische hogere efficientie (directe versus indirecte function call), maar in de praktijk is daar weinig van te merken.

Kun je me het verschil uitleggen tussen dynamisch en statisch gebonden functies?

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

dinsdag 10 september 2002 22:44

Because he doesn't row...

drm schreef op 10 september 2002 @ 22:33:
Kun je me het verschil uitleggen tussen dynamisch en statisch gebonden functies?

http://www.cs.wustl.edu/~schmidt/PDF/C++-dynamic-binding4.pdf

Acties:

dinsdag 10 september 2002 22:46

drm schreef op 10 september 2002 @ 22:33:
Kun je me het verschil uitleggen tussen dynamisch en statisch gebonden functies?

Dat is het makkelijkst uit te leggen met een voorbeeldje (in C++ code):

code:

  class Base
  {
    public:
      void m1();
      virtual void m2();
  };

  class Derived : Base
  {
      void m1();
      virtual void m2();
  };

  void Base::m1() { cout << "Base::m1()" << endl; }
  void Base::m2() { cout << "Base::m2()" << endl; }
  void Derived::m1() { cout << "Derived::m1()" << endl; }
  void Derived::m2() { cout << "Derived::m2()" << endl; }

  int main()
  {
    Derived d;
    Base &b = d;
    b.m1(); b.m2();
  }

Dit print, als het goed is (op typefouten e.d. na) "Base::m1()" en Derived::m2()". De niet-virtuele methode wordt statisch afgehandeld; de aan te roepen functie wordt bij het compileren vastgesteld. Dat is dus m1 van base. Wat voor waarde 'b' ook heeft, er wordt altijd Base::m1 op aangeroepen.

De functie die uitgevoerd moet worden voor m2() wordt echter at runtime bepaald (hij is dynamisch gebonden). Afhankelijk van welk object 'b' is, kan een andere methode worden geselecteerd.

Technisch gezien werkt dit niet zo ingewikkeld, vandaar dat het gebruikelijk is om binnen een OO ontwerp virtual methods te gebruiken. De compiler genereert voor elke klasse met virtuele methoden een virtual table, met daarin een rij voor elke methode en het adres van de functie die daarbij hoort. Alle objecten met virtuele methoden hebben een extra attribuut, de virtual table pointer (wat deze objecten iets, meestal 4 bytes, groter maakt dus). Bij het uitvoeren van een virtuele methode wordt niet naar een vast adres gesprongen, maar naar het adres dat in de virtual table van het huidige object staat.

Dit heeft twee implicaties: ten eerste, objecten met dynamisch gebonden methoden zijn iets groter (wat voor kleine objecten zoals bijvoorbeeld 2-dimensionale vectoren erg onwenselijk is) en het aanroepen van dynamisch gebonden methoden is iets ingewikkelder (in plaats van naar een statisch adres springen, moet de processor eerst de virtual table pointer ophalen, daar een getal bij optellen, de pointer op die locatie uit geheugen halen en daar tenslotte naar toe springen).

Acties:

dinsdag 10 september 2002 22:50

Zoijar schreef op 10 september 2002 @ 22:42:
http://www.cs.wustl.edu/~schmidt/PDF/C++-dynamic-binding4.pdf

Eikel die je bent!

Zit ik me daar verrot te typen...

Wel een goed document trouwens; kort, volledig, correct, etc.

Acties:

elgringo

2 woorden: object georienteerd

if broken it is, fix it you should

dinsdag 10 september 2002 22:52

Acties:

dinsdag 10 september 2002 22:54

elgringo schreef op 10 september 2002 @ 22:50:
2 woorden: object georienteerd

2 zinnen: waar heb je 't in godsnaam over en wat bedoel je hiermee?

Acties:

Verwijderd

Zoijar schreef op 10 september 2002 @ 22:25:
Nou als voobeeld dat je dus wel degelijk goed OO kan proggen in PHP, dit is mn main dan:

bij mij werkt het met modules, op ongeveer deze manier...

PHP:

<?php
error_reporting(E_ALL);
include("config.php");

$modules = array();
if($dir = opendir(MODDIR)){
  while(($file = readdir($dir)) !== false) {
    if(!is_dir($file)){
      $modules[] = str_replace(MODPREFIX, "", str_replace(MODEXTENSION, "", $file));
      require_once(MODDIR . "/" . $file);
    }
  }  
  closedir($dir);
}

class module {
  var $core;
  function module(&$core){
    $this->core = &$core;
  }
}

class core {
  function core($m) {
    $n = count($m);
    for($i = 0; $i < $n; $i++){
      $this->{$m[$i]} = &new $m[$i]($this);
    }
  }
}


$c = new core($modules);
$c->main->errors = $errors;
$c->db->dbConnect("*****", "*******", "******");
$c->session->setHandler();
$c->session->start();
$c->ubb->assignTags();
$c->build->constructMenu($menuitems);
$c->user->checkCookie();
$c->gz->start();
$c->build->getActiveUsers();
$c->build->output();
$c->gz->gzDocOut();
?>

dinsdag 10 september 2002 22:54

Acties:

dinsdag 10 september 2002 22:55

f0pc0dert

Aha... Interesting

helemaal duidelijk

_edit
Als reactie op Soultaker 's verhaal, dus....

* drm leest nog ff linkje van Zoijar

[ Voor 0% gewijzigd door drm op 10-09-2002 22:56 . Reden: quickreply ]

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

elgringo

Soultaker schreef op 10 september 2002 @ 22:52:
[...]

2 zinnen: waar heb je 't in godsnaam over en wat bedoel je hiermee?

das het voordeel van classes.

een class is een blauwdruk van een object (in c++ en java, php, ed.). dus als je gebruik gaat maken van classes maak je blauwdrukken van objecten. Hier kan je x aantal objecten van maken en dan ben je OO bezig.

if broken it is, fix it you should

dinsdag 10 september 2002 22:57

Acties:

dinsdag 10 september 2002 23:03

Because he doesn't row...

Soultaker schreef op 10 september 2002 @ 22:46:
[...]

Eikel die je bent! Zit ik me daar verrot te typen...

Wel een goed document trouwens; kort, volledig, correct, etc.

Muwahahaha

lol...sorry...google + "dynamic binding"

Acties:

dinsdag 10 september 2002 23:05

Because he doesn't row...

Verwijderd schreef op 10 september 2002 @ 22:54:
[...]

bij mij werkt het met modules, op ongeveer deze manier...

Ah ja, ik heb hier wel is wat stukjes gelezen over die manier met van die core class afleiden, en dan modules te laden die je via die core kan aanspreken dan. Ziet er wel goed uit

Acties:

dinsdag 10 september 2002 23:06

elgringo schreef op 10 september 2002 @ 22:55:
das het voordeel van classes.

een class is een blauwdruk van een object (in c++ en java, php, ed.). dus als je gebruik gaat maken van classes maak je blauwdrukken van objecten. Hier kan je x aantal objecten van maken en dan ben je OO bezig.

Ahhhh, ok. Dat lijkt er meer op.

Ik had al aangenomen dat de topicstarter "Wat is het voordeel van object-georienteerd programmeren" bedoelde, want OOP zonder klassen te gebruiken of klassen gebruiken zonder OO te programmeren, is natuurlijk niet nuttig.

Acties:

Verwijderd

Zoijar schreef op 10 september 2002 @ 23:03:
Ah ja, ik heb hier wel is wat stukjes gelezen over die manier met van die core class afleiden, en dan modules te laden die je via die core kan aanspreken dan. Ziet er wel goed uit

thx, en je bedoeld waarschijnlijk dit topic: [rml][ PHP] Extenden van een class (onb. naam)[/rml]
daar heb ik min of meer de core structuur van afgekeken tijdje geleden...

maar goed, dat gaat vrij offtopic, tijd om te gaan slapen...

dinsdag 10 september 2002 23:14

Acties:

woensdag 11 september 2002 00:00

f0pc0dert

* drm heeft weer wat geleerd...

damn C++ is veel te interessant om je in het dagelijks leven met PHP bezig te houden

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

woensdag 11 september 2002 00:52

Because he doesn't row...

Ja PHP is een toy-language hehe

Acties:

woensdag 11 september 2002 01:12

f0pc0dert

tja, er is niet zo veel ruimte voor C++ in een webdesign bedrijfje, he

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

dusty

Celebrate Life!

OO in PHP wordt hier ontzettend overgewaardeerd, de enige positieve reden waarom je wel eens OO "wilt" gebruiken in PHP heeft Glimi gegeven.

Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR

woensdag 11 september 2002 01:30

Acties:

woensdag 11 september 2002 09:08

Moderator Devschuur®

Demotivational Speaker

drm schreef op 11 september 2002 @ 00:52:
tja, er is niet zo veel ruimte voor C++ in een webdesign bedrijfje, he

met C++ kun je ook CGI apps bouwen

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:

whoami

Om nog eens terug te komen op de vraag van de topicstarter.

Classes zorgen ervoor dat je :
- je data kunt encapsuleren en je een abstractie kunt maken van uw data en de daarop werkende functies. Je kunt bv. een class Persoon hebben. Iedere persoon heeft een naam , een voornaam en een geboortedatum bv, en iedere persoon kan zijn naam zeggen.
Je kunt dus een class Persoon maken met die 'properties' en een functie 'Zegnaam' bv. Als je goed bezig bent, zorg je ervoor dat die 'properties' niet rechtstreeks van buiten de class te benaderen zijn.
- Herbruikbaarheid van code. Naast een class Persoon, kun je een class Werknemer hebben. Een Werknemer is eigenlijk een persoon en heeft dus ook een naam, voornaam en geboortedatum. Je kunt dus eigenlijk een class Werknemer maken die afgeleid is van de class Persoon en al die eigenschappen van persoon overneemt en er nog extra eigenschappen aan toevoegt. (Bv. loon).

Als je je in OO gaat verdiepen, dan zul je zeker de termen encapsulation, data-hiding en inheritance tegenkomen (welke ik hier summier heb proberen uit te leggen). Daarnaast zul je ook de term polymorphisme (welke hier ook al een paar keer gevallen is) tegenkomen.

https://fgheysels.github.io/

woensdag 11 september 2002 09:11

Acties:

elgringo

Zoijar schreef op 11 september 2002 @ 00:00:
Ja PHP is een toy-language hehe

maar redelijk krachtig....

Het enige verschil is dat php niet als standalone gebruikt kan worden en altijd een php parser nodig heeft. Deze kan weer in apache zitten of als commandline.

Maar je kunt er veel mee en het is absoluut niet zo moeilijk als C++

if broken it is, fix it you should

woensdag 11 september 2002 09:17

Acties:

woensdag 11 september 2002 10:44

f0pc0dert

.oisyn:
met C++ kun je ook CGI apps bouwen

Uiteraard, i know, maar 't voordeel van PHP is dat (wanneer je iig een _beetje_ progervaring hebt) het binnen een paar weken/maanden te leren is. Gaat met C++ niet erg op. En debuggen kost dan ben ik bang een beetje te veel tijd van de baas

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

left part of the evil twins

.oisyn schreef op 10 september 2002 @ 18:14:
een virtual class (virtual base class eigenlijk) is wat anders dan inheritance en abstraction wat jij bedoelt, en is alleen van belang als de inheritance graaf cyclisch is (B extends A; C extends A; D extends B, C - class D heeft nu 2 base classes A). Is ook alleen maar mogelijk met multiple inheritance

offtopic:
En oisyn is de winner in de categorie 'Hoe leg ik een simpel concept zo moeilijk mogelijk uit'!!!

woensdag 11 september 2002 14:57

Acties:

Verwijderd

Topicstarter

tis denk ik idd handig als ik er eens een boek over ga aanschaffen

woensdag 11 september 2002 14:59

Acties:

whoami

Verwijderd schreef op 11 september 2002 @ 14:57:
tis denk ik idd handig als ik er eens een boek over ga aanschaffen

Ik denk ook dat dat het beste is...
Succes.

https://fgheysels.github.io/

woensdag 11 september 2002 15:41

Acties:

woensdag 11 september 2002 16:44

elgringo schreef op 11 september 2002 @ 09:11:Maar je kunt er veel mee en het is absoluut niet zo moeilijk als C++

Helaas zie ik mensen in PHP dan ook de meest slechte code schrijven. Ik vraag me dan ook wel eens af of het een voordeel is dat in PHP 'alles kan'. Het bevordert het schrijven van veilige, efficiente of onderhoudbare code absoluut niet.

Uiteraard is PHP eenvoudiger te leren en sneller te schrijven dan vergelijkbare code in (bijvoorbeeld) C++, maar een programmeur die code van hoge kwaliteit schrijft in PHP, zou naar mijn idee weinig moeite hebben met geavanceerdere programmeertalen.

Acties:

left part of the evil twins

Soultaker schreef op 10 september 2002 @ 22:20:
Bij deze. Eigenlijk zijn statisch gebonden methoden (en dan bedoel ik NIET Java's static methods, maar de tegenhanger van de 'virtual' ofwel dynamisch gebonden methoden) nergens goed voor. Ze bestaan waarschijnlijk vanwege de theorethische hogere efficientie (directe versus indirecte function call), maar in de praktijk is daar weinig van te merken.

Hmmmm ik heb er lang geleden een benchmarkje op gedraaid, en daar kwam gemiddeld een factor 2 in verschil op uit in het voordeel van non-virtual calls (onder VC6)

woensdag 11 september 2002 16:55

Acties:

woensdag 11 september 2002 17:19

curry684 schreef op 11 september 2002 @ 16:44:
Hmmmm ik heb er lang geleden een benchmarkje op gedraaid, en daar kwam gemiddeld een factor 2 in verschil op uit in het voordeel van non-virtual calls (onder VC6)

Daar vallen twee kanttekeningen bij te plaatsen. Ten eerste bestaat een typisch programma maar voor een deel uit calls en is die factor twee in de praktijk misschien vrij onbelangrijk (en zou een alternatief voor virtual methods waarschijnlijk meer overhead opleveren). Ten tweede zijn niet alle calls op virtual methods daadwerkelijk indirect. Wanneer de compiler het most-derived type van een object at compile time vast kan stellen, wordt natuurlijk gewoon een directe call gedaan.

Acties:

left part of the evil twins

Ten eerste bestaat een typisch programma maar voor een deel uit calls

Mwah wel voor het grootste gedeelte hoor... uiteindelijk is een programma niet veel meer dan het enorm veel calls doen totdat er uiteindelijk ergens een API/stdlib in geschoven wordt (met een call

en is die factor twee in de praktijk misschien vrij onbelangrijk (en zou een alternatief voor virtual methods waarschijnlijk meer overhead opleveren).

Nog steeds geen excuus om niet in principe je best te doen zo min mogelijk functies overbodig virtual te maken. C++ is geen taal voor beginners, en daarom heb je de keuze: het kan soms zelfs nuttig zijn om een overloaded functie niet virtual te maken...

Bovendien heeft Java trouwens ook virtual methods maar definieert men ze daar andersom: je maakt een functie non-virtual en non-overloadable dmv het keyword final.

Wanneer de compiler het most-derived type van een object at compile time vast kan stellen, wordt natuurlijk gewoon een directe call gedaan.

Klopt, dat kwam bij de bench ook naar voren... zodra ik de compiler voldoende om de tuin had geleid kwam die verdubbeling in executietijd pas eruit

woensdag 11 september 2002 18:03

Acties:

Verwijderd

curry684 schreef op 11 september 2002 @ 17:19:
Mwah wel voor het grootste gedeelte hoor... uiteindelijk is een programma niet veel meer dan het enorm veel calls doen totdat er uiteindelijk ergens een API/stdlib in geschoven wordt (met een call ).

En om dat te voorkomen hebben we weer een ander keyword tot onze beschikking: inline. Inlining voorkomt dat een groot deel van de tijd in een OO-applicatie wordt besteed aan triviale method calls. Inlining (ook van virtuals) kan een tijdsbesparing van wel 12% opleveren.

woensdag 11 september 2002 18:07

Acties:

left part of the evil twins

Heheh counting down.... als je een jaar geleden begon over het nut van inline hiero kreeg je meteen 10 man over je heen die beweerden dat compilers van tegenwoordig inlinen van functies overbodig maken. Ikzelf doe het nog wel consequent waar het nuttig is... maar misschien ben ik wel old-school

Overigens is een inline virtual call eigenlijk een contradictio in terminis...

Maar een goede compiler zou er op zich doorheen moeten kunnen komen in sommige gevallen.

woensdag 11 september 2002 18:10

Acties:

Verwijderd

curry684 schreef op 11 september 2002 @ 17:19:

C++ is geen taal voor beginners

Waarom zou je niet beginne bij het moeilijkste kan de rest tenminste mee valle.
Ik ben zelf ook begonnen met C++ en dat beviel me prima

woensdag 11 september 2002 18:20

Acties:

Verwijderd

curry684 schreef op 11 september 2002 @ 18:07:
Heheh counting down.... als je een jaar geleden begon over het nut van inline hiero kreeg je meteen 10 man over je heen die beweerden dat compilers van tegenwoordig inlinen van functies overbodig maken. Ikzelf doe het nog wel consequent waar het nuttig is... maar misschien ben ik wel old-school

Er is bij veel compilers een optimizing-optie om alle methods in je source te inlinen, maar dat is geen standaard gedrag. Als je portable software wilt schrijven die ongeveer de zelfde prestaties levert op verschillende platforms zul je dus met de hand moeten inlinen.

Overigens is een inline virtual call eigenlijk een contradictio in terminis... Maar een goede compiler zou er op zich doorheen moeten kunnen komen in sommige gevallen.

Nee hoor, echt niet. Een virtual method wordt alleen via de vtable aangeroepen als het type van het betreffende object niet bekend is tijdens compile-time. Door een virtual te inlinen kan de compiler dus in alle gevallen waar het type wel bekend is, die methode ook daadwerkelijk inlinen in je code. (Dit merk je al heel snel aan virtual destructors, omdat die de destructor van de baseclass ook aanroepen. Het type van die baseclass destructor is bekend, dus...)

edit:
ff een voorbeeld

C++:

// Pseudocode

class StringBase {
// Abstract base class for all string types.
public:
    typedef std::size_t size_type;

    virtual size_type length() const = 0;
    virtual void print(std::ostream&) const = 0;
    virtual ~StringBase() {}
};

class AsciiString : public StringBase {
public:
    virtual StringBase::size_type length() const { return _len; }
};

class UnicodeString : public StringBase {
public:
    virtual StringBase::size_type length() const { return _len; }
};

int main() {
    AsciiString str("BeefCake");
    StringBase::size_type len= str.length();  // inlined virtual call
    // inlined virtual destructor call
}

woensdag 11 september 2002 18:40

Acties:

woensdag 11 september 2002 18:50

Moderator Devschuur®

Demotivational Speaker

drm schreef op 11 september 2002 @ 09:17:
[...]

Uiteraard, i know, maar 't voordeel van PHP is dat (wanneer je iig een _beetje_ progervaring hebt) het binnen een paar weken/maanden te leren is. Gaat met C++ niet erg op. En debuggen kost dan ben ik bang een beetje te veel tijd van de baas

't was ook niet bedoeld als serieuze opmerking... imho ben je gewoon idioot als je een website bouwt mbv c++ (tenzij iets heel efficient moet gebeuren natuurlijk)

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:

woensdag 11 september 2002 19:08

Moderator Devschuur®

Demotivational Speaker

curry684 schreef op 11 september 2002 @ 10:44:
[...]

offtopic:
En oisyn is de winner in de categorie 'Hoe leg ik een simpel concept zo moeilijk mogelijk uit'!!!

ja ik heb dat soms... wat win ik nu?

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:

woensdag 11 september 2002 20:33

curry684 schreef op 11 september 2002 @ 17:19:
Mwah wel voor het grootste gedeelte hoor... uiteindelijk is een programma niet veel meer dan het enorm veel calls doen totdat er uiteindelijk ergens een API/stdlib in geschoven wordt (met een call ).

Accoord maar de daadwerlijke call (de 'CALL' instructie op een x86 processor) is maar een deel van het geheel (argumenten op de stack plaatsen, registers bewaren, branchen, argumenten van de stack, code uitvoeren, return value instellen, registers herstellen) dus het verschil tussen een indirecte call en een directe call zal gemiddeld genomen niet zo veel schelen.

Die factor 2 lijkt me dan ook wat aan de hoge kant. Ik vermoed dat je eerder je compiler zo ver om de tuin hebt geleid, dat die eerste keer functies kon inlinen en later ze volledig indirect uit moest voeren. Dat is natuurlijk geen eerlijke vergelijking.

Als je denkt meer dan een factor 1.2 te kunnen halen, post dan maar wat sample code.

Acties:

donderdag 12 september 2002 12:38

Moderator Devschuur®

Demotivational Speaker

Soultaker: vergeet niet dat je bij een call naar een virtuele functie 3 levels van indirectie hebt. Allereerst moet de waarde van de pointer/reference uit het geheugen gehaald worden (1). Dan wordt de locatie van de vtable opgehaald (2), en dan wordt het adres van de functie uit de vtable gehaald (3).

code:

// stel dat op ebp+8 (de eerste parameter van de huidige functie) een
pointer naar een klasse staat, waarop je een functie aan gaat roepen
(zonder parameters)


// non-virtual:
push dword ptr [ebp+8]   // de pointer
call Klasse_eenFunctie


// virtual
mov eax, [ebp+8]         // de pointer
push eax                 // de eerste parameter
mov eax, [eax]           // de vtable
call [eax+Klasse_eenFunctie_vtable_index] // functie adres

[ebp+8] bevindt zich iig bijna zeker weten in de cache, omdat dat de stack is.
Datgene waar [ebp+8] heen wijst (dus de contents van een instantie van een klasse) hoeft niet per se in de cache te staan.
Hetzelfde geldt voor de vtable. Ook is branche-prediction in het geval van de virtual methode totaal niet mogelijk, dus instructions kunnen niet van te voren gefetched worden (in tegenstelling tot de non-virtual methode die zich op een absoluut adres bevindt).

De pipelines van tegenwoordig zijn behoorlijk lang (ik meen zo rond de 10 a 20 instructies), dus een virtual aanroep zorgt voor enorme stalls (hij is namelijk volledig afhankelijk van de vorige instructie, en pas als die instructie klaar is kunnen de instructies van die functie worden gefetched... dus dat is equivalent aan 10 tot 20 nop's).

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

Verwijderd schreef op 11 september 2002 @ 18:20:
Nee hoor, echt niet. Een virtual method wordt alleen via de vtable aangeroepen als het type van het betreffende object niet bekend is tijdens compile-time.

Maar gezien de wondere wereld van multithreading kun je eigenlijk alleen garanderen dat een object van een bepaald type is als ie enkel en alleen op de stack bestaat. Heap objects zijn eigenlijk altijd uit den boze om het type te kunnen voorspellen.

Oh en VC en BCB hebben allebei een optie 'Inline functions when appropriate'.