POV-Ray : Newsgroups : povray.programming : Object oriented POV scene language? : Re: Object oriented POV scene language? Server Time
28 Jul 2024 16:32:35 EDT (-0400)
  Re: Object oriented POV scene language?  
From: Thorsten Froehlich
Date: 24 Jul 2000 08:52:43
Message: <397c3c1b@news.povray.org>
In article <B5A11995.1927%dav### [at] maccom> , David <dav### [at] maccom>
wrote:

>    Can a struct have functions as well is vars? Can a struct have protected
> members? Can a struct have inheritance? Are structs encapsulated? Ect.

You can have all of it, also it obviously won't look the same.  Take a look
at the operating system you are running (Mac OS, I presume).  In particular,
look at the Window Manager. There is (in reverse order for better reading):

struct WindowRecord {
 GrafPort       port;
 short        windowKind;
 Boolean       visible;
 ...
};

struct GrafPort {
 short        device;
 BitMap        portBits;
 Rect        portRect;
 ...
};

struct BitMap {
 Ptr        baseAddr;
 short        rowBytes;
 Rect        bounds;
};


Now, as C++ classes this could look like:

class WindowRecord {
private:
 GrafPort       port;
 short        windowKind;
 Boolean       visible;
 ...
};

class GrafPort {
private:
 short        device;
 BitMap        portBits;
 Rect        portRect;
 ...
};

class BitMap {
private:
 Ptr        baseAddr;
 short        rowBytes;
 Rect        bounds;
};

typedef WindowRecord *      WindowPtr;


Instead of having functions in here, this example shows that you do _not_
even need function pointers (also C++ does it this way) to get OOP.  All you
need is a well defined interface, and every call then just does this:

WindowPtr win = NewWindow(...);

SetWindowTitle(win, "My Title");

DisposeWindow(win);


While in C++ this would look like:

Window *win = new Window(...);

win->SetTitle("My title");

delete win;


If you want private data members, and as a good OOP principle is to disallow
access to all direct data members anyway, and to use accessor functions you
would get:

// in the "public" header, you do this
typedef struct OpaqueWindowPtr *      WindowRef;
// while in the private header you would do this
typedef WindowRecord *      WindowPtr;
// this allows you to have both working, it is just a matter of a few simple
// "tricks" in C


WindowRef win = NewWindow(...);

SetWindowTitle(win, "My Title");

DisposeWindow(win);


Now, all you functions need to do is to cast the win pointer they receive to
WindowPtr and they can use it as they did before.  By not exporting function
prototypes of functions, you make these functions "private".  In C you could
always do so by declaring a function "static".

As you can see, most OOP support is "included" in C, and additionally, the
code above was (like the original Mac OS) done in Pascal!  And the above
code is actual code, the first part as it has been until now, and the later
(windowRef) as it is when using the Carbon APIs.

The difference and reason for C++ to exists is to make these "features" of C
more accessible and integrated into the language, which allows greater
flexibility and speed.  Of course there are templates and multiple
inheritance in C++, but with the simple C preprocessors directives, even
templates are possible.  The only thing really missing is operator
overloading...

Anyway, this discussion has little to do with OOP, more with the
implementation of support for OOP in various languages - in some (like Java)
OOP is nearly enforced, while others like C leave it to the programmer to
write in good OOP style.   BTW, the Java Virtual Machine is not written in
C++, but C...


      Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.