From f97b37a3162c15eca54d2171c36c75125ad3754e Mon Sep 17 00:00:00 2001 From: William S Fulton Date: Tue, 3 Mar 2020 19:23:46 +0000 Subject: [PATCH] Minor formatting fixes in Lua.html --- Doc/Manual/Lua.html | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/Doc/Manual/Lua.html b/Doc/Manual/Lua.html index 60f7e1775..80807baf4 100644 --- a/Doc/Manual/Lua.html +++ b/Doc/Manual/Lua.html @@ -145,7 +145,7 @@ The -elua option puts all the C function wrappers and variable get/set The following table list the additional commandline options available for the Lua module. They can also be seen by using:

-
+
 swig -lua -help 
 

 
@@ -747,7 +747,8 @@ Stout
 

 Class data members are accessed in the same manner as C structures. Static class members present a special problem for Lua, as Lua doesn't have support for such features. Therefore, SWIG generates wrappers that try to work around some of these issues. To illustrate, suppose you have a class like this:
 

-
class Spam {
+
+class Spam {
 public:
   static void foo();
   static int bar;
@@ -756,7 +757,7 @@ public:
 

 In Lua, C++ static members can be accessed as follows:
 

-
+
 > example.Spam.foo()            -- calling Spam::foo()
 > a=example.Spam.bar            -- reading Spam::bar 
 > example.Spam.bar=b            -- writing to Spam::bar
@@ -774,7 +775,7 @@ It is not (currently) possible to access static members of an instance:
 Compatibility Note: In versions prior to SWIG-3.0.0 only the following names would work:
 

 
-
+
 > example.Spam_foo()            -- calling Spam::foo()
 > a=example.Spam_bar            -- reading Spam::bar 
 > example.Spam_bar=b            -- writing to Spam::bar
@@ -964,7 +965,8 @@ When wrapped, it works like you expect:
 

 One restriction with operator overloading support is that SWIG is not able to fully handle operators that aren't defined as part of the class. For example, if you had code like this
 

-
class Complex {
+
+class Complex {
 ...
 friend Complex operator+(double, const Complex &c);
 ...
@@ -973,7 +975,8 @@ friend Complex operator+(double, const Complex &c);
 

 then SWIG doesn't know what to do with the friend function--in fact, it simply ignores it and issues a warning. You can still wrap the operator, but you may have to encapsulate it in a special function. For example:
 

-
%rename(Complex_add_dc) operator+(double, const Complex &);
+
+%rename(Complex_add_dc) operator+(double, const Complex &);
 ...
 Complex operator+(double, const Complex &c);
 

@@ -1446,6 +1449,7 @@ Those names are in a form $classname_$symbolname and are added to the s
 If %nspace is enabled, then class namespace is taken as scope. If there is no namespace, or %nspace is disabled,
 then module is considered a class namespace.

 
 Consider the following C++ code 

+
 
%module example
 %nspace MyWorld::Test;
 namespace MyWorld {
@@ -1486,6 +1490,7 @@ surrounding scope without any prefixing. Pretending that Test2 is a struct, not
 
 
 The internal organization of inheritance has changed. 
 Consider the following C++ code:

+
 
%module example
 class Base {
   public:
@@ -1502,6 +1507,7 @@ were squashed and added to corresponding derived class ST: Everything f
 was copied to .fn table of class Derived and so on. This was a recursive procedure, so in the end the whole
 inheritance tree of derived class was squashed into derived class. 

 
 That means that any changes done to class Base after module initialization wouldn't affect class Derived:

+
 
 base = example.Base()
 der = example.Derived()
@@ -1516,6 +1522,8 @@ nil
 

 
 This behaviour was changed. Now unless -squash-bases option is provided, Derived store a list of it's bases and if some symbol is not found in it's own service tables
 then its bases are searched for it. Option -squash-bases will effectively return old behaviour.
+

+
 
 > print(der.new_func) -- Now it works
 function