PB9 and Objects

[Bob Zale]

"Macro = No stack frame which is 1 meg and  function call = slower"


Functions can't possibly have a 1 MEG stack frame.  The physical limit is 64K as the extreme maximum, typically much, much less (like tens or hundreds of bytes).  You're probably thinking of a THREAD stack frame.

Best regards,

Bob Zale
PowerBASIC Inc.

[James C. Fuller]

"Macro = No stack frame which is 1 meg and  function call = slower"


Functions can't possibly have a 1 MEG stack frame.  The physical limit is 64K as the extreme maximum, typically much, much less (like tens or hundreds of bytes).  You're probably thinking of a THREAD stack frame.

Best regards,

Bob Zale
PowerBASIC Inc.

No I got it from here??


http://www.powerbasic.com/support/help/pbwin/index.htm

James

[Bob Zale]

Each time a THREAD is created, a stack section (default=1M) is allocated for all functions/methods to use.  No new stack memory is allocated for each function/method invocation.

Bob

[Edwin Knoppert]

Question is if a BASIC programmer should worrie about details on that a level.
I don't.. just like the register stuff.

Like a said, a call to Instr() or Mid$() are functions too, 'overhead' any way.
You would gain only one wrapper, your custom function.
So what's the point.. unless you write all code in assembly.

[James C. Fuller]

Like a said, a call to Instr() or Mid$() are functions too, 'overhead' any way.

Not necessarily true and probably not. There is no need for a full stack frame on internal calls.

James

[Edwin Knoppert]

I already thought i would get this response, what about your function calling another custom procedure?

It's really a nonsense discussion.
Maybe suitable for rocket sience..

[Theo Gottwald]

The time, the final API Call for the clipboard uses is much longer, then the MACRO or the Function at that place.

And alltogether, there is not even in phantasie a scenario thinkable in which any of these timedifferences would play any role hehehe.
At least not for the Clipboard call.

Even in very high time-critical situations, the calling of a PB Sub or Function is not a problem and can even be an advantage because of the use and new Assignement of REGISTER Variables.

MACROS are in theory faster, but it really depends on the situation, because the CPU caching (strategy?) and the REGISTER usage plays a role.

In the situation with the Clipboard from before, none of all these aspects is of any real Usage, because we don't need to read or set the Clipboard >100.000 times each seconds.
Or did I miss something here :-).

[Paul Squires]

Macro? Function? blah blah blah.... none of that is important because I JUST GOT MY PB9 !!!! 

I'll be tucked away for a week playing with this thing. Sweeeeeeeeeeet!

[Bob Zale]

I believe that calls for a Woo-Hoo!   Ok, so I'm just a tiny bit biased...  {smile}  Thanks for kind words and the excitement.

Bob Zale
PowerBASIC Inc.

[Theo Gottwald]

I I'd also like just to get a nice house or a farm on the countryside,
have a computer, the new PB 9, a whirlpool - somebody who looks for alldays work ....

And then do a some month not much more then just enhance all my old ( old is everything before PB 9 :-) ) Code with the new possibilities.

But we'll see when it can happen.

[Paul Squires]

Theo, good point - I wish also that I could update all of my old code. I thought about a couple of them last night but I think that I am not going to bother. I'll use PB9 in my next project rather than try to retrofit it into my old code. There's never a shortage of new projects! 

Maybe I'll win the lottery and then be able to program full time!

[José Roca]

 
Apparently, I'm one of the few that are using the new COM support for COM programming instead of OOP

[Paul Squires]

  I'll have a HUGE need for COM in my next programming project. It will involve a lot of Word, Excel and Outlook manipulation.... but, for now, I'll be using COM for OOP. Baby steps for me. My brain can only handle so much.

[José Roca]

 
To save you some head scratching, don't try to use EXCEL with direct calls; use OBJECT GET/CALL... Although EXCEL's type library lists dual interfaces, they return pointers to the dispatch interfaces, so trying to use them will end in frustration and GPFs.

[Paul Breen]

Jose says he is doing com without oop and the new pb9 has oop that is com. I know that there is oop without com in other languages but I would like some clarification about the new pb9 oop. Is the new implementation of objects in pb9 exclusively com technology that is packaged in a clever way?
Is all of oop in powerbasic just com in a easy to use syntax? Does this mean that there is some advantage of oop that is not in the new compiler because of how it was implemented? Even strong advocates of oop like the inventor of python think that multiple inheritance causes more trouble than it solves so I am not looking for something like that.

I am attracted to the idea that powerbasic has used a proven "off the shelf" technology from Microsoft if I have the right understanding. Do I?