CHICKEN will be able to access the module using the (declare
(uses modulename)) CHICKEN Scheme form.
+
The SWIG chicken module has support for exceptions thrown from + C or C++ code to be caught in scheme. + See Exception handling with %exception + for more information about declaring exceptions in the interface file. +
+ +Chicken supports both the SWIG_exception(int code, const char *msg) interface
+ as well as a SWIG_ThrowException(C_word val) function for throwing exceptions from
+ inside the %exception blocks. SWIG_exception will throw a list consiting of the code
+ (as an integer) and the message. Both of these will throw an exception using (abort),
+ which can be handled by (handle-exceptions). See
+ Chicken manual on Exceptions
+ and SFRI-12. Since the exception values are thrown
+ directly, if (condition-case) is used to catch an exception the exception will come through in the val () case.
+
The following simple module
+ +
+%module exception_test
+
+%inline %{
+ void test_throw(int i) throws (int) {
+ if (i == 1) throw 15;
+ }
+%}
+could be run with
+ ++(handle-exceptions exvar (if (= exvar 15) (print "Correct!") (print "Threw something else " exvar)) (test-throw 1)) +
The author of TinyCLOS, Gregor Kiczales, describes TinyCLOS as: -
-Almost all good Scheme books describe how to use metaobjects and @@ -275,7 +315,7 @@
-@@ -289,7 +329,7 @@ much simpler csc or csc.bat.
-@@ -303,7 +343,7 @@ loadable module.
-@@ -312,13 +352,13 @@ in example.i and the C functions being wrapped are in example_impl.c.
-- $ swig -chicken example.i - $ csc -svk example.scm example_impl.c example_wrap.c - $ csi example.so test_script.scm --
+$ swig -chicken example.i +$ csc -svk example.scm example_impl.c example_wrap.c +$ csi example.so test_script.scm ++
You must be careful not to name the example_impl.c file example.c because @@ -331,20 +371,20 @@ be accessable to the loader. You might need to set LD_LIBRARY_PATH.
-Again, we can easily use csc to build a binary.
-- $ swig -chicken example.i - $ csc -vk example.scm example_impl.c example_wrap.c test_script.scm -o example - $ ./example --
+$ swig -chicken example.i +$ csc -vk example.scm example_impl.c example_wrap.c test_script.scm -o example +$ ./example ++
@@ -353,7 +393,7 @@
Lib/chicken/chicken.swg.
@@ -383,17 +423,42 @@
wrapper code calls the function
SWIG_ConvertPtr(C_word s, void **result, swig_type_info *type, int flags),
passing a pointer to a struct representing the expected pointer
- type.
+ type. flags is either zero or SWIG_POINTER_DISOWN (see below).
If the owner flag in the SWIG_NewPointerObj is 1, NewPointerObj will add a + finalizer to the type which will call the destructor or delete method of + that type. The destructor and delete functions are no longer exported for + use in scheme code, instead SWIG and chicken completly manage pointers. +
+ +In situations where SWIG knows that a function is returning a type that should
+ be garbage collected, SWIG will automaticly set the owner flag to 1. For other functions,
+ The %newobject directive must be specified for functions whose return values
+ should be garbage collected. See
+ Object ownership and %newobject for more information.
+
In situations where a C or C++ function will assume ownership of a pointer, and thus + chicken should no longer garbage collect this type, SWIG provides the DISOWN input typemap. + After applying this typemap (see the Typemaps chapter for more information on how to apply typemaps), + any pointer that gets passed in will no longer be garbage collected. + An object is disowned by passing the SWIG_POINTER_DISOWN flag to SWIG_ConvertPtr. + Warning: Since the lifetime of the object is now controlled by the underlying code, the object might + get deleted while the scheme code still holds a pointer to it. Further use of this pointer + can lead to a crash. +
+ +