tclOO & C api

[oleg.o....@gmail.com]

Hi, all.

Folk, help me please with some questions about tcloo:
- Is a performance of tcloo methods the same as ordinary proc?
- Is a performance of tcloo methods the same as proc that exported from a namespace?
- Can i call tcloo methods and access object variables from C as easy as an ordinary proc and variables?
- Can i implement some tcloo object in C as easy as an ordinary proc?

P.S. i didn't find much info about tcloo & C.

[oleg.o....@gmail.com]

I will try to explain my questions about tcloo & C api more precise.
When i said about easiness of using tcloo from C i mean including a situation with coroutines. Where we should do some extra (not so simple) work to call a proc with coroutine inside from C because of NRE. Do tcloo have some pitfalls like this?

[oleg.o....@gmail.com]

My project now at a state of a choice of a future development path. Now i understand that i try to implement something that looks like lite objects on the top of namespaces. So, now is a right point to move to a tclOO if they match criteria of easy of use from/in C code and performance(vs namespace procs).

[Rich]

If you introspect some TclOO objects, you'll find they are specially
named namespaces in the ::oo namespace:

$ rlwrap tclsh
% oo::class create test {
constructor {} { puts "Created [namespace current]" }
}
::test
% ::test new
Created ::oo::Obj14
::oo::Obj14
%

So it would seem that Tcl level performance would be not much different
from existing namespace bound procs.

As for access from C code, on that I can't comment.

[Ashok]

As you can see for yourself using [time], raw namespace proc calls are
faster than oo method calls, about 20% on my system. Of course, relative
to the "real work" you do within the method/proc, the actual numbers are
in the noise. More important, by the time you use namespace features to
implement what you expect from a basic oo system, you'll find TclOO to
be significantly faster. You can check this with any of the existing
classical namespace based oo implementations from the Wiki.

Regarding C access to TclOO, see some of TDBC driver sources, e.g.
https://core.tcl-lang.org/tdbcodbc/file?name=generic/tdbcodbc.c&ci=tip

/Ashok

[rene]

I would say you better use some tcl code to create classes and call methods.
You can see a mix of tcl and C-code p.e. in http://chiselapp.com/user/rene/repository/tko in file generic/tkoWidget.c

HTH
rene

[Donal K. Fellows]

On Tuesday, 23 March 2021 at 12:06:18 UTC, oleg.o....@gmail.com wrote:
> Folk, help me please with some questions about tcloo:
> - Is a performance of tcloo methods the same as ordinary proc?

Probably a little slower, as it takes more work to manage the stack frames. There's more going on under the covers (to enable calling superclass implementations via [next], etc.) and that's not free. But it depends on what you're doing; there are scenarios where it's possible to make back the performance due to TclOO having a variable resolver that you can (slightly) program.

> - Is a performance of tcloo methods the same as proc that exported from a namespace?

The additional cost of an exported procedure is very very small, so I expect my answer above to still hold.

> - Can i call tcloo methods and access object variables from C as easy as an ordinary proc and variables?

Calling methods from C is a bit messy; the supported interface is via Tcl_Eval() or Tcl_EvalObjv(). Directly calling a method is categorically not supported; they depend on having a context handle that can't be minted by user code (because it hooks into the non-recursive execution engine and uses trickery to get fast memory management).

Variables are just variables in the object's namespace.

If you're thinking of doing a lot of this, try doing a hybrid class, where you have non-exported methods in C that implement the bits you can't do any other way, and exported methods in Tcl to tie things together into a nice interface. That's one of the easiest ways to implement an object that participates in a coroutine in a complex way: writing NRE-aware C code isn't particularly easy.

> - Can i implement some tcloo object in C as easy as an ordinary proc?

Pretty close. Tcl_NewMethod() is conceptually much like Tcl_CreateObjCommand(), but the type signature of main implementation function is different (there's an additional parameter, the context, which describes what the current object is and what the current method call chain is) and the way you pass the implementation function in is a bit different too. Inside the implementation function, you mostly have to be careful to not assume the number of arguments used to “name” your call; that's non-constant (unavoidably). There's an API function to tell you how many arguments are your name (expected to be 2 or 1, for [$obj methName ...] vs [next ...]).

There's multiple options for how you attach C structures to an object, some of which properly associate with a particular method and others go more directly on the object (and can be shared between cooperating C methods). The distinction has to be made because the state of a method is not the state of an object; classes can be inherited from, and that adds a lot of complexity if you're not careful.

Donal.

[oleg.o....@gmail.com]

вторник, 30 марта 2021 г. в 18:22:19 UTC+3, Donal K. Fellows:

> writing NRE-aware C code isn't particularly easy.

That's sad. I thought that NRE related only to coroutines :-(. [voice from the crowd] We want tcl to be easy to program from C :-).

[Christian Gollwitzer]

Am 18.05.21 um 09:33 schrieb oleg.o....@gmail.com:

> вторник, 30 марта 2021 г. в 18:22:19 UTC+3, Donal K. Fellows:
>> writing NRE-aware C code isn't particularly easy.
> That's sad. I thought that NRE related only to coroutines :-(.

Basically that's what it is.

[voice from the crowd] We want tcl to be easy to program from C :-).
>

C does not have coroutines [*], so Tcl has to "fake" them, which
unfortunately means to transform the whole program logic. You can still
easily add new commands in Tcl from C. The hard part is to write a C
command which can execute Tcl, i.e. a callback. In this callback you
cannot yield, unless the C command is written in NRE style, which is hard.

Christian


[*] most modern C++ DOES have it, but that's a different story and it
only came recently

[Oleg Nemanov]

вторник, 18 мая 2021 г. в 12:06:32 UTC+3, Christian Gollwitzer:

> C does not have coroutines [*], so Tcl has to "fake" them, which
> unfortunately means to transform the whole program logic. You can still
> easily add new commands in Tcl from C. The hard part is to write a C
> command which can execute Tcl, i.e. a callback. In this callback you
> cannot yield, unless the C command is written in NRE style, which is hard.

Isn't this makes embedding tcl more hard?

> [*] most modern C++ DOES have it, but that's a different story and it
> only came recently

No-no. C++ is terrible almost completely :-).

[Don Porter]

On 5/18/21 9:13 AM, Oleg Nemanov wrote:
> вторник, 18 мая 2021 г. в 12:06:32 UTC+3, Christian Gollwitzer:
>> C does not have coroutines [*], so Tcl has to "fake" them, which
>> unfortunately means to transform the whole program logic. You can still
>> easily add new commands in Tcl from C. The hard part is to write a C
>> command which can execute Tcl, i.e. a callback. In this callback you
>> cannot yield, unless the C command is written in NRE style, which is hard.
>
> Isn't this makes embedding tcl more hard?

"Embedding Tcl" is a completely different topic.

Does it make writing C command procedures that implement new Tcl
commands more difficult?

1) Simple things are still simple. No change required.

2) More complex things -- commands that evaluate a script value as part
of their functioning -- need to be revised in order to support [yield],
etc. in the script values they evaluate.

2a) If your extension command doesn't care about [yield], etc. again no
change is necessary.
2b) The revision of a command procedure from the old way to the new is
a fairly mechanical transformation with plenty of examples to follow.

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|