Hey Nan

I've been playing around with my own object framework which was inspired by the work you and Thomas did but I
was wondering about the constructor/destructor call overhead.

If you have many objects with inheritance and empty constructors/destructors ( apart from the the superclass call )
how big would the performance hit be realistically? I thought the virtual calls that your object framework uses would
have a fairly heafty penalty but they don't, would the constructor/destructor overhead be similarly insignificant overall?

Any insights welcome

Maelstrom
Posted on 2002-09-19 23:24:07 by Maelstrom
Constructors and Destructors are one-time deals.

Yes, there is more processor overhead, nesting backwards thru the inheritance tree, but this is minor since its a one time sur-charge. If you design an object to be created and destory *very* frequently, it shouldnt have an inheritance background to begin with, rather a new base class, writen to handle this kinda operation...

I hope this is what your getting at?

(( PS: Glad your *inspired* keep me informed if you like ;) ))

:alright:
NaN
Posted on 2002-09-20 22:51:56 by NaN
Cheers Nan :alright:

Thats what I wanted to know and I have to agree with what you said.

I was trying to eliminate any constructors/destructors that didn't do anything which
is fairly easy to do for constructors in my framework but destructors are another matter
entirely since they're virtual. I could do it by checking the destructor vptr but I don't
think it's worth it.

Anyway my framework supports static, virtual, and inline methods as well as embedded and referenced objects.



.CLASS name, base

m_data1 dd ?
m_data2 dd ?

.OBJECT name, type

.OBJECT_PTR name, type

.STATIC name, argcount

.VIRTUAL name, argcount

.VIRTUAL_PTR name, argcount ; pure virtuals

.INLINE name, dest:=<eax>
mov dest, [this].m_data1
endm

.ENDC


The argument count doesn't include the 'this' ptr, that is automatically added by the framework.

I've tried to automate as much as possible to reduce typing and human error, so :-

- class templates are generated by a macro - used to initialize the object when created.
- constructors/destructors automatically superclass their base versions.
- constructors/destructors automatically initialize/destroy any embedded objects.
- methods are automatically found no matter where in the inheritance tree they exist.
- methods automatically setup the this ptr

Methods are defined with macros to help with automation



.METHOD class, method, args
; locals go here
.ENTER
; your code goes here
.RET val
.ENDM


Objects can be created dynamically or statically and calling methods is easy



.NEW class, dest

.CREATE class, dest

.CSomeClass this, method, args


The same interface will call any method, if you change a static method to a virtual method, simply
recompile and it automatically updates - no need to change the code.

Literal string and floating point arguments are also supported.

:grin:
Maelstrom
Posted on 2002-09-21 03:06:07 by Maelstrom
Im impressed...

You truely seem to be on your own path ;) . I follow what your doing, and would be interested in seeing it sometime... At anyrate keep up the good work!! Im way to busy to continue my work at the moment, but if your model is superior to ours, you will have my fullest backing ;)

My goal was to get the ASM community thinking "objects doesnt *have* to come from M$", and getting highly tuned ASM classes produced for reusability for mondain things; such as writing an ASM equivalent to a HyperText Link in the client area of some application. A simple Object can be created to accept a caption and a link on creation, and have the same template spew out as many links as you need.. with no worry of "managing" them all.

At any rate, please keep up the work and keep me informed.

Good Job.
:alright:
NaN
Posted on 2002-09-24 22:56:03 by NaN
In my programming language, costructors/destructors are called only for the specified object but not for the ones it inherits.

I came to this decision when in a object I needed to include two sub-objects, but only one was really used (basing on certain circumstances), while the other was eventually activated later. To remove the unnecessary overhead (of CPU and eventually allocated heap) I then decided to use this system by default.. which I also find more "clear" and "intuitive", personally. I will call the constructors/destructors of the sub-objects in the constructor/destructor of the main object, if necessary. For me objects have to be simply data structs with associated inline methods (meant as "macros"), I don't want any extra overhead than I specify there to be. I don't keep any vtable.. for me methods are always simply macros to be inlined. These macros can then pass the "this" pointer to routines that do the big work.. or can call them indirectly via explicitly defined function pointers (here we return functionally to vtables, overriding, etc..). In substance the struct is totally defined by the programmer, and nothing is hiddenly added.

A question now.. why languages like C++ don't share the same choice that I've made? I think that any automatism should be removed when it may be detrimental.. and that things should be kept as simple and basic as possible.

But I'd like to hear other philosophical views on the subject.

Maelstrom: congrats for your work.. that extends the already great work made by NaN and Thomas. :alright:
Posted on 2002-09-25 04:16:17 by Maverick
Thanks for your comments.

I'm still trying to iron out a few problems with my sledgehammer but it seems to work fairly well so far.

Maverick

What you described for your OOP intrigues me and I would like to hear more if you don't mind.

I'm also for removing as much overhead as possible which is why I implemented inline methods and was trying to eliminate any empty constructors/destructors.

The automation I've included in my OOP was done to eliminate human error ( stop me from stuffing up ) in things like the object template which contains the virtual ptrs and is used to initialize the object when it's created - critcal stuff.

Also do you think a macro framework is sufficient or should a more advanced object creator app be written to generate the code - without hiding anything of course?

As for why C++ or others don't think this way, probably because they don't have to. It's not as if the competition is forcing them to be quicker, only more productive. The 'CPUs are fast enough' excuse seems to be recycled everytime a new processor is released. Just because the CPUs are fast enough to run bloated code doesn't mean that they should have to. Obviously, productivity is the number one concern since that costs money, but what about the end user, shouldn't we get quality code instead of quantity code. Now I'm not saying that these languages suck but imagine how much more powerful they could become with a little TLC in the OOP department.

Anyway thats my rant over, I'll release the framework when it's more stable.

:grin:
Maelstrom
Posted on 2002-09-25 19:26:27 by Maelstrom
Hi Maelstrom,
Also do you think a macro framework is sufficient or should a more advanced object creator app be written to generate the code - without hiding anything of course?

I would have said the second..but then I've seen the MACRO work of ingenious coders like you, NaN, Thomas, bitRAKE and others.. and I understood I can't reply to this question. ;)
I think MACROs would be more comfortable, but a preprocessor more powerful.. I don't know the limit of MACROs, because I've never been a big fan of them, since the most complex (and e.g. nested) implementations quite hide stuff (I prefer to look at a 1:1 source).

As for why C++ or others don't think this way, probably because they don't have to. It's not as if the competition is forcing them to be quicker, only more productive. The 'CPUs are fast enough' excuse seems to be recycled everytime a new processor is released.

Recently I've discovered the language Oberon, which "impressed" me because it has many important similarities with my own language, at least when it comes to modularity. One thing that disappointed me about it though was that Nicholas Wirth (the creator of Oberon*, Modula* and Pascal languages) **edit: no, it wasn't he the one that added most of the OOP bloat ;) ** went a lot far about OOP overhead when he added this functionality to the latest Oberon version.. killing (for some) an otherwise very interesting language. A lot of coders (wrongly) think that OOP = bloat, or anyway slower than non-OOP, which is not true at all. It's just a more modular, compact, cleaner and sometimes even more efficient (because of the nature of L1 caches, and the locality of reference that OOP promotes) way to express the same identical code.

Just because the CPUs are fast enough to run bloated code doesn't mean that they should have to.

I couldn't agree more.

Obviously, productivity is the number one concern since that costs money, but what about the end user, shouldn't we get quality code instead of quantity code.

Yup, but calling by yourself the constructors/destructors of "sub-objects" (sorry for the terminology, I'm quite self-taught) doesn't cost too much development time, in my experience.. and helps having a more direct and intuitive idea of what is really happening.

Now I'm not saying that these languages suck but imagine how much more powerful they could become with a little TLC in the OOP department.

TLC = ? :)
Posted on 2002-09-27 03:32:30 by Maverick

TLC = ? :)



    [*]TLC Tender Loving Care
    [*]TLC The Learning Channel
    [*]TLC Tables & Ladders & Chairs (pro wrestling)
    [*]TLC Tactical Leaders Course
    [*]TLC Tailored Logistics Corporation (defense contractor specializing in the development of component overhaul kits)
    [*]TLC T-Boz, Left Eye, & Chili (the group TLC)
    [*]TLC Teacher Leadership Council (Mormon Church)
    [*]TLC Teaching/Learning Center
    [*]TLC Team Leadership Center
    [*]TLC Teen Life Conference
    [*]TLC Telecommunication Line Controller
    [*]TLC Telecomunicazioni
    [*]TLC Telephone Line Control
    [*]TLC Ternary Linear Code
    [*]TLC Texas Logistics Corporation
    [*]TLC The Learning Company
    [*]TLC The Library Corporation
    [*]TLC Therapeutic Lifestyle Change
    [*]TLC Thin Layer Chromatography
    [*]TLC Thunderbird Language Center (AGSIM, Glendale, AZ, USA)
    [*]TLC Toastmasters Learning Center
    [*]TLC Tomatoes, Lettuce, and Cheese
    [*]TLC Total Lack of Consideration
    [*]TLC Total Logistic Control
    [*]TLC Total Lung Capacity
    [*]TLC Toyota Land Cruiser
    [*]TLC Trades and Labor Council of Western Australia
    [*]TLC Traffic Light Chart (integrated three-tiered reporting system/format)
    [*]TLC Traffic Load Control
    [*]TLC Trafikledningscentral
    [*]TLC Transformer-rectifier Line Contactor
    [*]TLC Transgender Liberation and Care
    [*]TLC Transmission Line Coupler
    [*]TLC Transport-, Informatik-, Logistik-Consulting GmbH
    [*]TLC Tratado de Libre Comercio (English: NAFTA)
    [*]TLC Trilateral Commission
    [*]TLC Trinity Lutheran College


    :grin:
Posted on 2002-09-27 03:59:15 by bazik
Ah.. now I get it. :grin:
Posted on 2002-09-27 04:07:04 by Maverick
Maverick

I would have said the second..but then I've seen the MACRO work of ingenious coders like you, NaN, Thomas, bitRAKE and others.. and I understood I can't reply to this question.


Awww, you say the nicest things :grin:

While it's true a lot can be done with macros, to achieve everything that I would like my object framework to handle will probably require an object creation app. It's not to say that macros couldn't do it, but as you stated, a preprocessor would be more powerful. Just looking for other opinions.

When you talk about calling the constructors/destructors of sub-objects do you mean ...

1. A class the object is derived from, or
2. A class that is embedded into the object

In my framework the constructors are called automatically from inside the macro. At present my constructors don't take any arguments but I want them to. The problem with automatically calling them is it makes it difficult to pass arguments down the inheritance tree since the macro doesn't know what to pass. This can easily be fixed by manually calling the constructors, but that means I would need multiple constructors ( for different argument counts, fairly easy with name mangling ) or always pass arguments even if unnecessary. The only downside is forgetting to call the constructors/destructors and wondering why the code turned into custard, but if that's all I stuffed up I'd be very happy.

I think I'll have a play with an object app, I've got lots of ideas in my head and need to get some of them out ( need the room ) :grin:

Squashed another bug in the OOP framework with my trusty sledgehammer so it's a little closer to being released, just want to thrash it a bit more.

Maelstrom
Posted on 2002-09-28 06:21:13 by Maelstrom
Hi Maelstrom,
When you talk about calling the constructors/destructors of sub-objects do you mean ...

1. A class the object is derived from, or
2. A class that is embedded into the object

I mean like having a struct inside another struct. Sorry for my English, it's not my native language. With struct, of course, I mean not only data but also methods.

Good luck with your work :alright:

Gotta run now. :(
Posted on 2002-09-28 15:46:40 by Maverick

While it's true a lot can be done with macros, to achieve everything that I would like my object framework to handle will probably require an object creation app. It's not to say that macros couldn't do it, but as you stated, a preprocessor would be more powerful. Just looking for other opinions.


Well my standing opinion is go for it ;)

When we first designed our model, we deliberately avoided such things. We wanted it to all be compile time and be more like how the world is use to it. However, I think it took on a mild welcome cause because of the macro madness. Its alot of 'new' symbols to get acustom to, and while they are simple, they can be enough to intimidate the currious.

That being said, I say give it a try. Our reasoning seemed sound at the time, we expected people to favour compile time over an EXE that will effectively hide a layer of abstraction from the programmer. It made sence since we all program in ASM anyways, but perhaps having such things is just what people might prefer.

At any rate, there will become more *unique* selection for someone new to all this to try out, and perhaps learn to like.

After all, my friend likes Crown Royal Wiskey, and I like Jameson's Irish Wiskey. We both insist our's is better than the other's, but at the end of the day, we are both drunk ;)

Keep up the good work...
:alright:
NaN
Posted on 2002-09-30 23:04:34 by NaN
Go, go, go, guys. This is good stuff.
Posted on 2002-10-05 09:42:02 by drhowarddrfine
Agreed :alright:

Perhaps you could also write a convertor for old OOP files? :rolleyes:
Posted on 2002-10-05 10:36:54 by Qweerdy
Hey guys check out my OOP framework progress thread ( how do you add thread links :confused: )

I'll post the framework there when I'm happy with it.

And give me some feedback.

Qweerdy

I'll look into writing a simple converter, it depends on how much code exists out there that uses
NaNs OOP model

:alright:
Maelstrom
Posted on 2002-10-08 21:10:05 by Maelstrom