SEAL Forum Index SEAL
The SEAL Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

C vs CPP
Goto page 1, 2  Next
 
Post new topic   Reply to topic    SEAL Forum Index -> Seal 3.0 Development
View previous topic :: View next topic  
Author Message
ganesh



Joined: 11 Jul 2002
Posts: 133
Location: Vancouver, BC, CA

PostPosted: Fri Jul 12, 2002 4:07 am    Post subject: C vs CPP Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Fri Jul 12, 2002 4:23 am    Post subject: We already had that. Reply with quote

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?
Back to top
View user's profile Send private message
ganesh



Joined: 11 Jul 2002
Posts: 133
Location: Vancouver, BC, CA

PostPosted: Fri Jul 12, 2002 5:15 am    Post subject: Reply with quote

Exactly,

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

Quote:

Why bother with a complete Seal rewrite when you can reuse thousands of lines of code?


To do a cleanup. Seal at present is a mess.

Quote:

This is why KDE is still ahead of Gnome in terms of development inertia


I dont think so. KDE is way too heavy. Too many classes, too complex. It hardly takes a newbie to get to grips with the gtk design.

Anyway, Ill be writing a basic GUI and shall post it in a few days.[/quote]
_________________
Ganesh lives @
www.iamganesh.com
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
w_w_n_uk



Joined: 25 Oct 2001
Posts: 177
Location: England, Hemel Hempstead

PostPosted: Fri Jul 12, 2002 11:00 am    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
ganesh



Joined: 11 Jul 2002
Posts: 133
Location: Vancouver, BC, CA

PostPosted: Fri Jul 12, 2002 1:37 pm    Post subject: Reply with quote

Piece of cake;

Code:


struct lz
{
char *text1;
char *text2;
void (*encode)(void);

};

void myencode(void)
{
printf("in my encode");

}

int main()
{
struct lz lz_obj;

lz_obj.encode = myencode;

lz_obj.text1 = "test1";
lz_obj.text2 = "test2";

lz_obj.encode();

return 0;
}



Try running the program, it should show "in my encode"

Thats why you must use a constructor kind of function

Code:


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

}

//to create an object;

lz *lz_obj = lz_new();




Got it ??[/code]
_________________
Ganesh lives @
www.iamganesh.com
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
w_w_n_uk



Joined: 25 Oct 2001
Posts: 177
Location: England, Hemel Hempstead

PostPosted: Fri Jul 12, 2002 1:56 pm    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
w_w_n_uk



Joined: 25 Oct 2001
Posts: 177
Location: England, Hemel Hempstead

PostPosted: Fri Jul 12, 2002 2:09 pm    Post subject: Reply with quote

#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...
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Sat Jul 13, 2002 2:32 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
BadSector
Administrator


Joined: 24 Oct 2001
Posts: 328
Location: Greece, Samos

PostPosted: Sun Jul 14, 2002 5:22 pm    Post subject: Reply with quote

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/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Mon Jul 15, 2002 4:53 am    Post subject: Decisions Reply with quote

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.

Quote:
KDE is way too heavy. Too many classes, too complex. It hardly takes a newbie to get to grips with the gtk design.

I have coded with QT and gtk, and while I must admit I like the gtk design, I'd also say that it is bloated on some nuts and bolts. (gobject, for starters - who needs reference counting?) And while KDE may be bloated in one or another way, C++ is certainly not the source of this bloat.

BS.: You're right again. We shall not make a decision to let it bite us later. C++ doesn't force anyone to play its rules. We can and should use C or C++ as appropriate.
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Mon Jul 15, 2002 10:43 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
orudge
Administrator


Joined: 07 Oct 2001
Posts: 1331
Location: United Kingdom

PostPosted: Wed Jul 24, 2002 5:43 am    Post subject: Reply with quote

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):
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger
ganesh



Joined: 11 Jul 2002
Posts: 133
Location: Vancouver, BC, CA

PostPosted: Wed Jul 24, 2002 5:47 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
vbAlex



Joined: 22 Oct 2003
Posts: 3
Location: Michigan

PostPosted: Thu Oct 23, 2003 6:11 pm    Post subject: C++ all the way Reply with quote

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 Mr Green

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...

Code:

class widget {
  public:
    void init(); //Initializes widget
    void kill(); //Deinitializes widget
    void size(int height, int width); //Sizes or resizes the widget
    void update(); //Makes the widget update it's display area

  private:
    //Private stuff here -- nothing off-hand -- maybe pixelUpdate to
    //  write to a single pixel in the widget or something -- if that's
    //  the case, then implement bounds checking ;)
};


You get the idea... We don't use a constructor because it might be a little sketchy with the subclassing, and there will be cases in which you won't want to init the object right off... E.G. a large application could include declarations for all of it's widgets in one file, and init them only when they're needed. No deconstructor for similar reasons, mostly the subclassing complications.

You notice the size and update declarations... In reality, the widget would describe, well, a widget with propertys and methods which would cascade down to widgets which didn't redefine such propertys/methods (think CSS-ish.) For example, it could simply define a sizable box. Ok, getting back to the size/update description... The size procedure would, in theory, resize the object on the screen. And the update procedure would make the object paint itself back onto the screen (E.G. if you drag a window over it, then off, you'd call the update procedure to have it repaint what the window covered up.)

As you can see, this is a very limited implementation. You'd want to add procedures to move the object in the X and Y planes, maybe some kind of event trapping system, and of course custom per-widget procedures, such as setFontSize() for a textbox widget, and so on.

This appears to be the technique Microsoft employs in Windows, and however much I wish they had never enabled Windows to access the internet, I must say, that particular part of their operating system was done right.

Ok, now I take off my professional suit... I'm tired... Sorry if this wasn't clearly explained Mr Green, and sorry if I duplicated other info in other posts, which I probably did - but again, no flames please .
_________________
+--------------------------------------+
Email: vbAlexDOSMan@Yahoo.com
Website: http://www.vbAlex.com/ (Not up yet)

Chat:
> AIM: vbAlexDOSMan
> ICQ: 271781078
> Jabber: IReadYourEmail@Jabber.org/Gaim
> MSN: vbAlexDOSMan@Hotmail.com
> Yahoo: vbAlexDOSMan@Yahoo.com

Projects:
> EEL: http://www.sourceforge.net/projects/eel
> Forum Plus: http://www.sourceforge.net/projects/forumplus

Code is free speech, so free it up!
+---------------------------------------+
Back to top
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger
Michaelo



Joined: 05 Feb 2004
Posts: 1

PostPosted: Thu Feb 05, 2004 8:39 pm    Post subject: 2 Cents Worth Reply with quote

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)
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    SEAL Forum Index -> Seal 3.0 Development All times are GMT - 7 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group