cpptcl

cpptcl copied to clipboard

Hi there,

i did some work on cpptcl. let me know if you are interested.

• c++ variadic templates, remove a lot of boilerplate code
• remove a couple of map lookups for each function call (400% faster calls)
• tie Tcl channels to std::iostreams

nobody interested in free quality code?

You'll need to fix the cmake problem

I haven't tried it, but you might need to add some directives like:

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

i will figure it out. busy elsewhere currently.

You should be able to verify the build in your own repo if you go to https://github.com/bunker-bunk567/cpptcl/actions and enable the actions

are there any open applications that use cpptcl? i am fairly sure my version is no longer compatible and the test cases don't cover those discrepancies.

I'm not aware of any published ones, but FlightAware internally uses cpptcl extensively and if there is API breakage then that will likely be a very significant hurdle.

i think we might be going different ways then. unless someone is interested at your end to change the way of doing business i see no point trying to remain compatible.

if you have future plans for TCL, you have an opportunity to improve the quality of future code.

there is still the issue of the extra std::map lookup for the policy object at each function call, which is a big unnecessary heat generator. if you move the policy object into the callback object, you can get 5 times faster function calls (backwards compatible). also you can omit some other std::map lookups for the callback object itself if you make use of TCL's ClientData mechanism.

another issue is that cpptcl object() does not properly implement sharing and takes no advantage of TCL object sharing (creating and duplicating more than would be necessary). but that is likely going to cause some breakage.

I would not rule out accommodating some changes, since this seems like a big advance in the way templates are used. We can't pull it immediately into master, but if it were merged into a branch we could migrate to it.

we can just leave open this pull request without intending to merge it anywhere until we change our minds about it.

i am primarily interested in improving openboardview using cpptcl as a building block, but if somebody wants to work with me on something else, they can come here.

if you point me to an application that is not too large i would see if i can improve backwards compatibility myself. it would probably end up somewhere in the middle: backwards compatible with the style, but requiring some modifications due to technical limitations. or more precisely: it would make sense to be not 100% backwards compatible.

Perhaps splitting this PR into multiple smaller ones that are individually less disruptive to existing users would be an option?