I'm pleased to announce the first version of the C++/Tcl library:
This library allows to easily write C++ extensions for Tcl and to embed
Tcl interpreters in C++ programs.
The C++/Tcl library is extremely easy to use and does not require any
additional tools or processing steps. Basic examples are:
Looks like serious fun. What license do you plan to apply? Haven't
found anything but the Copyright notice.
| The C++/Tcl library is extremely easy to use and does not require
| any additional tools or processing steps.
Well, I wouldn't call the Boost `nothing' :-)
On a first glance, besides the CPPTCL_MODULE macro, a CPPTCL_PACKAGE
macro would be useful, which would have an additional `char *version'
argument to call Tcl_PkgProvide() with. Useful for those who think in
terms of packages rather than plain shared libraries.
Ralf Fassel wrote:
> * Maciej Sobczak <no....@no.spam.com>
> | http://cpptcl.sourceforge.net/
> Looks like serious fun. What license do you plan to apply? Haven't
> found anything but the Copyright notice.
Errr... The license is in each source file.
// Permission to copy, use, modify, sell and distribute this software
// is granted provided this copyright notice appears in all copies.
// This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
This is the shortest I found (in fact, this is taken from one of Boost
libraries) that may be translated into:
- do what you want, but
- do not claim that you wrote the original stuff (keep my (c) in sources
and feel free to add your own if you modify them), and
- do not sue me.
In particular, feel *free* to use it in any commercial project (in
original or modified form). The (c) stuff is required only in source
code, so the license claims absolutely nothing from the resulting
binaries. Your clients do not need to know nor care.
In other words, this the most relaxed open-source license that still
allows me to show it as my own work. Any other license I've seen had
some restrictions that I found unnecessary or even destructive.
> | The C++/Tcl library is extremely easy to use and does not require
> | any additional tools or processing steps.
> Well, I wouldn't call the Boost `nothing' :-)
OK, I thought about source pre-processors.
> On a first glance, besides the CPPTCL_MODULE macro, a CPPTCL_PACKAGE
> macro would be useful, which would have an additional `char *version'
> argument to call Tcl_PkgProvide() with. Useful for those who think in
> terms of packages rather than plain shared libraries.
Right. Noted, this will go to the next release.
Thank you very much,
| Errr... The license is in each source file.
ACK. How about adding a plain-text `License' (or `license.terms', as
TCL includes it) file to the distro, containing just this text again?
Quite common among open source projects to include such a file.
It couldn't hurt to include the license info on the WWW pages, too,
for those of us trying to determine whether the project is usable in a
commercial non-GPL environment.
> I'm pleased to announce the first version of the C++/Tcl library:
Looks very cool... I guess this might be a good time to point out that
I have a similar library (currently released under GPL) within a
system that I've designed for running visual psychophysics
home page: http://www.klab.caltech.edu/rjpeters/groovx/
source download: http://www.klab.caltech.edu/rjpeters/code/
latest version: http://www.klab.caltech.edu/rjpeters/code/groovx_20041123.tar.gz
README file: http://www.klab.caltech.edu/rjpeters/groovx/readme.html
TUTORIAL file: http://www.klab.caltech.edu/rjpeters/groovx/tutorial.html
cvs browser: http://www.klab.caltech.edu/rjpeters/cvsbrowser/
After looking at cpptcl.sourceforge.net, I think there is a lot in
common between the two systems, ultimately providing this main feature:
* You can do simple, one line Tcl command definitions from C++, where
you basically just have to supply the command name and some C++
function pointer, and then a series of template mechanisms
automagically set up a suitable Tcl wrapper.
Other goodies in common:
* a C++ class that wraps Tcl_Interp
* a C++ class that wraps Tcl_Obj
* automatic translation between C++ exceptions and error codes
(i.e. C++ exceptions get caught at callback boundaries and are
translated to Tcl error return codes, while Tcl errors in some
interp->eval() are translated to C++ exceptions)
* a system for converting back and forth between Tcl_Obj's and C++
A couple things that I think are different in my system (at least
after a first glance at cpptcl):
* I have also a C++ class that wraps Tcl lists (so you can do simple
list->insert(), list->append(), etc.). Many of the list functions
are templates that will take any C++ type, and automatically convert
it to a suitable Tcl_Obj; similarly functions for retrieving
elements from the list are also templates that can convert back to a
C++ type on the way out of the list.
* I have a tighter integration with a memory-management for C++ types
that should have 'reference' rather than 'value' semantics. This
involves the dreaded (gasp!) mother-of-all-base classes approach
(it's probably possible to soften this requirement, but I haven't
had the need yet in my own work), which essentially injects a
ref-counting base class. A systemwide registry (ObjDb) maps live
objects to unique integer id values; then, any such uid can be used
as a handle within Tcl to the live object. There is never any danger
of dangling pointers, since if the object has disappeared and you
try to reference it from Tcl, you'll simply get a polite message
stating that the object is no longer around in the registry.
This is coupled with smart pointers for strong- and weak- reference
counting. There are C++/Tcl conversion routines that know to do the
* to get a Ref<MyClass> from a Tcl value, first extract an integer
uid from that value, then look up that uid in the ObjDb, then
get a pointer to base class (Object*), then try to safely
dynamic_cast it to a MyClass*, and finally make a smart pointer
* to return a Ref<MyClass> back to Tcl, simply return its uid
This obviates the need for factory() and sink() call policies in
cpptcl (but of course it also implies a dependency on a top-level
It makes it easy to not worry about whether objects were initially
created inside C++ (e.g. as members of some other object) or by an
explicit Tcl call; either way, the objects can be manipulated
through their associated Tcl commands.
* My C++/Tcl library is all rolled up with the rest of my visual
psychophysics code, which might not be interesting to a general Tcl
audience ;) But, it's also not dependent on any other C++ libraries
(like boost)... here are the external dependencies shown by 'ldd' on
my linux box:
libreadline.so.4 => /usr/lib/libreadline.so.4 (0x062dd000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x006f5000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x002d1000)
libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x04a95000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x04a1e000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00119000)
libz.so.1 => /usr/lib/libz.so.1 (0x00107000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x0032a000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00511000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x00542000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x06717000)
libtcl8.5.so => /home/rjpeters/local/tcl8.5a1/lib/libtcl8.5.so (0xf6b2f000)
libtk8.5.so => /home/rjpeters/local/tcl8.5a1/lib/libtk8.5.so (0xf6a63000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0034a000)
libm.so.6 => /lib/tls/libm.so.6 (0x00dd6000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00320000)
libc.so.6 => /lib/tls/libc.so.6 (0x00cad000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x001f6000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xf6320000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0x00566000)
libdl.so.2 => /lib/libdl.so.2 (0x00101000)
libasound.so.2 => /lib/libasound.so.2 (0x0666e000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x001e2000)
Robert J. Peters, Ph.D. Computation & Neural Systems
rjpeters at klab dot caltech dot edu Caltech
www.klab.caltech.edu/rjpeters/ Mail Code 139-74
(626) 395-2882 Pasadena, CA 91125