SEAL

[ganesh]

C vs CPP
---------

I have two ideas on implementing the Infrastructure. A C way and a CPP way.


General Ideas
-------------
( Most of you must be familiar with this already )

In CPP / JAVA :

For an object,
OBJECT.METHOD(ARGUMENTS)

For an object pointer,
OBJECT->METHOD(ARGUMENTS).

In the C-OO way,
METHOD ( OBJECT , ARGUMENTS )

Cool, uh ?


Implementation
----------------

In C,

//The super widget, all widgets are derivatives of this one
class stkWidget
{
public :
set_xy(int a,int b);
set_caption(char *);
virtual void draw();

private :
int x,y,w,h;
char *caption;
BITMAP *src;
(void*)(draw_function)(void*);

};

class stkButton
{

public :
void draw();
void set_clickable();

}

class stkCheckBox
{
public :
void draw();
void set_state();

}



You may ask, what is the function pointer draw_function for ?
This is for a theming engine. You have a theme driver that holds only
the drawing functions. You may have people wanting to draw buttons differently
etc..., The idea is to keep the working of the CheckBox separate from
the UI. Somebody can write a Glass Driver and now all your widgets are
bitmaps, etc...

I think the current seal does something like this. Havent checked the sources.

With the above infrastucture, I can _bet_ that this is not C++ code,
the main body code is all C, we only use the inheritance and classes etc..
Also we dont have to explicitly define a constructor. Thats it. Below
you will see how to overcome that too.

=============================================
The C way.

This is the most portable way to do a GUI. And there isnt any valid point
for using this (even speed).

The members with underscores are private ones.

struct stkWidget
{

(void*)(set_xy)(int a,int b);
(void*)(set_caption)(char *);
(void*)(draw)();


int _x,_y,_w,_h;
char *_caption;
BITMAP *_src;
(void*)(_draw_function)(void*);

};


struct stkButton
{

(void*)(draw)();
(void*)(set_clickable)();

struct _stkWidget;
}



So we make a "constructor" C function called,
stk_*_new(..);

So for a new button,
stk_button_new ()
{
stkButton *obj;

obj = malloc(sizeof(stkButton));
obj->_stkWidget = malloc(sizeof(stkWidget));

obj->draw = obj->_stkWidget->draw;

blah...blah....blah
}

Infact we can have a stk_new_widget() function to use above where
we have,
_draw_function = draw;

This is exactly the same as the very above CPP code. In fact this is
_much_ faster than the C code, beacause we use func pointers, and do
not have a call stack draw->_draw_function. When we call draw,
it calls _draw_function by default.


So I want your comments on this. In the C way, we have to remember to point
everything to make the inheritance happen, while in the Cpp
way it is done automatically.
_________________
Ganesh lives @
www.iamganesh.com

[llogiq]

Look at the board SEAL Forum Index -> General -> A radical proposal.

C may be faster (actually it isn't neccessarily), but it's a PITA to code object-oriented. This is why KDE is still ahead of Gnome in terms of development inertia. Fast code comes from good design, no matter what language one uses.

If you prefer to code C, well, we can also try and port Gnome to dos. Why bother with a complete Seal rewrite when you can reuse thousands of lines of code?

[ganesh]

Exactly,

to use the classes of C++ and not anything else, we need to rewrite most of it.

[w_w_n_uk]

How says C cant have a nice OOP look at the basic OOP i made

int main()
{
lz_obj.file1 = "file1";
lz_obj.file2 = "file2";
lz_obj.encode();
return 0;
}

what do you all think and is in C no C++ used
btw lz_obj.encode(); if a function
_________________
leon pegg
W_W_N_UK@YAHOO.CO.UK
When Hell is full, the dead will walk the earth...

[ganesh]

Piece of cake;

[w_w_n_uk]

Sopt on infact i thort you got my code somehow at first.
one thing i dont get is the reason for this

lz * lz_new(void)
{
lz *obj=NULL;
obj = malloc(sizeof(lz));
obj->encode = myencode;

}

//to create an object;

lz *lz_obj = lz_new();

could you pls explan it for me.

with this kind of OOP in C there is no need to use C++
as this OOP would make code very clean. i think it would be g8t used
for objects in seal3 eg for a window we could have

settings like this
window.height = 100;
window.width = 100;
window.caption = "window caption";
window.Name = "window_name";
ect..
then to do stuff to windows like this
window.create(owner);
window.hide;
window.show;
ect..
this would not be hard to implement...

BTW i was going to paste my code
and i thort it was a good idea
just started playing with struc and thort would be g8t to use a struc
for OOP so i implemented a simple design and got it working
tell me what you think of my idea
_________________
leon pegg
W_W_N_UK@YAHOO.CO.UK
When Hell is full, the dead will walk the earth...

[w_w_n_uk]

#include <stddef.h>
#include <stdio.h>

int * enc(void)
{
printf("encode called");
return NULL;
}

struct lz{
char* file1;
char* file2;
int *(*encode)(void);
}lz_obj;

struct lz lz_obj = { NULL, NULL, enc };

int main()
{
lz_obj.file1 = "file1";
lz_obj.file2 = "file2";
lz_obj.encode();
return 0;
}
_________________
leon pegg
W_W_N_UK@YAHOO.CO.UK
When Hell is full, the dead will walk the earth...

[_xduffy_]

Well, first of all, we've already have had this discussion c vs c++ and all that, and we've decided for C++ ok?
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com

[BadSector]

taking a decision doesn't mean that this decision cannot be changed, especially when it is for good purpose.
_________________
main(){printf("Hello, world!n"); return 0;}
Bad Sector - http://www.bsector.cjb.net/

[llogiq]

Are we here for a flamewar or for a good neat discussion? C++ essentially does the same thing you describe, it just adds some syntactig sugar on top. There's a good reason C++ exists, if only that people don't have to code object-oriented by hand. I've done it, even in assembly (and I really enjoyed it! ), but remember we want to read the code afterwards.

[_xduffy_]

I still think C++ i appropriate for all the GUI related bits and C for the more "kernel" related ones...

The reasons are obvious... or at least we've talked about it before..
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com

[orudge]

I agree with xduffy's last comment here - we can use C for the main kernel functions, etc, but C++ for the GUI-type functions (eg, windows, buttons, menus, etc).
_________________
Owen Rudge
http://www.owenrudge.net/

Currently Playing (last time I was online, anyway):

[ganesh]

Exactly,

we are using classes and nothing more from C++. You dont even have to link to the C++ libs.

BTW, all the libraries we use are C libs. So basically its C code in a class member function.

What do we call this Object C ? (OK, theres another lang with a similar name objective C)
_________________
Ganesh lives @
www.iamganesh.com

[vbAlex]

I think it'd be better to use C++ rather than C. Sorry if some of this has been said before, but I don't think any one person can read all the forum posts

So, in C++, we can have a base widget which would serve as a superclass for the real widget classes, such as textboxes, buttons, and checkboxes. I don't have much experience in C++, although I know the concepts, so please don't flame me if this is FUBARed...

[Michaelo]

C is unquestionably faster. It generates faster, tighter code.

More to the point is the compiler… after all it interprets you code and actually produces the executable. So the argument over which language is futile.

Interestingly enough if you remove the GUI and just want to write code to do the work as with a kernel … you must choose C or Assembly but you would never choose C++ or Basic.

Large corporations choose program languages to produce programs (including windozs) quickly. They have no real interest in quality or stability. They can always fix the problem down the road... so I suggest you choose quality and stability.

At the end of the day you will choose a language based on your ability to program in it and not on its ability to produce the best code. How many people do you know who code in assembly?

Mike

(and yes I program in C)