]> git.draconx.ca Git - gob-dx.git/blobdiff - doc/gob.1.in
Release 1.0.1
[gob-dx.git] / doc / gob.1.in
index aa9b45de618de30806d56a30813987d063aec455..9e1ce35bf0c19b3981d67c523aa00ff2d7351dc9 100644 (file)
@@ -22,19 +22,13 @@ is in spirit similar to things like lex or yacc.
 .SH OPTIONS
 .PP
 .TP
-.B -?
-.TP
-.B -h
-.TP
-.B --help
+.B -? -h --help
 Display a simple help screen.
 .TP
 .B --version
 Display version information (note, --version was not added until 0.92.0)
 .TP
-.B -w
-.TP
-.B --exit-on-warn
+.B -w --exit-on-warn
 Exit with an error code even when you encounter a warning.
 .TP
 .B --no-exit-on-warn
@@ -70,14 +64,12 @@ define the private data structure at the point in the .c source where
 the class definition begins.  This option implicitly negates
 --always-private-header
 .TP
-.B -n
-.TP
-.B --no-write
+.B -n --no-write
 Do not write any output files, just check syntax of the input file.
 .TP
 .B --no-lines
 Do not print out the '#line' statements into the output.  Useful for debugging
-the autogenerated generated code.
+the auto-generated generated code.
 .TP
 .B --no-self-alias
 Do not create the Self and SelfClass type aliases and the SELF, IS_SELF
@@ -341,7 +333,7 @@ take up more space in the file and it may become more cluttered.
 .PP
 The data is zeroed out after being destroyed.  This is to make debugging easier
 in case your code might try to access an already destroyed object.  In case
-you have overriden the destroy method, your code will be run first and
+you have overridden the destroy method, your code will be run first and
 only then will the destructors be called.  You should not however make any
 assumptions about the order at which the destructors are called.  If you have
 interdependencies between destructors for different data members, you will
@@ -434,7 +426,7 @@ is just like
   set { self->foo = ARG; };
 
 .fi
-Similiarly,
+Similarly,
 .nf
 
   private char * foo;
@@ -637,7 +629,9 @@ signal just like a public method.  Example:
          ...
   }
   
+.fi
 or
+.nf
 
   signal last NONE(NONE) void foo(self);
 
@@ -724,13 +718,13 @@ function.  For example:
   }
 .fi
 Thus you see that the "_foo" method still generates the method "my_object_foo"
-just as "foo" would generate.  You can turn off this behaviour if you depend
-on the old (pre 0.93.5) behaviour with the --no-kill-underscores option.  This
+just as "foo" would generate.  You can turn off this behavior if you depend
+on the old (pre 0.93.5) behavior with the --no-kill-underscores option.  This
 also means that if both "_foo" and "foo" are defined, it is treated as a
 conflict.
 .PP
 This does not apply to override methods.  Override methods are special beasts
-and this is not neccessary and would make the code behave in weird ways.
+and this is not necessary and would make the code behave in weird ways.
 .PP
 Making new objects:
 .PP
@@ -752,7 +746,7 @@ Self alias casts:
 .PP
 There are some standard casts defined for you.  Instead of using the full
 macros inside the .c file, you can use SELF, IS_SELF and SELF_CLASS.  Using
-these makes it easier to for example change classnames around.
+these makes it easier to for example change class names around.
 .PP
 Self alias types:
 .PP
@@ -809,7 +803,7 @@ compile with a C++ compiler.
 
 .SH IDENTIFIER CONFLICTS
 .PP
-Gob will need to define some local varibles and functions in the generated
+Gob will need to define some local variables and functions in the generated
 files, so you need to take some precaution not to conflict with these.  The
 general rule of thumb is that all of these start with three underscores.  There
 is one, "parent_class" which doesn't because it's intended for use in your
@@ -824,7 +818,7 @@ PARENT_HANDLER macro.  In fact avoiding all names with three underscores is
 the best policy when working with gob.
 .PP
 Also note that starting with version 0.93.5, method names that start with a
-an underscore are eqivalent to the names without the initial underscore.  This
+an underscore are equivalent to the names without the initial underscore.  This
 is done to avoid conflicts with the aliases.  Thus you can define the method
 as "_name", if "name" happens to be some standard library function.  This is
 the same as defining it as "name" except that the local alias will be "_name"
@@ -852,7 +846,7 @@ indented any number of tabs or spaces and you can use the short method name
 without the type prefix.  Gob will automatically try to extract these and
 translate to full names and put them in the output source file.  An example
 would be:
-.fi
+.nf
 
   class Gtk:Button:Example from Gtk:Button {
           /**
@@ -872,7 +866,7 @@ would be:
 
 .fi
 If the function you are documenting is a signal or a virtual then it will
-be documentating the wrapper that starts that virtual function or emits
+be documenting the wrapper that starts that virtual function or emits
 that signal.
 
 .SH DEALING WITH CIRCULAR HEADERS
@@ -939,7 +933,7 @@ program.
 
 .SH BUGS
 .PP
-Also the lexer does not actually parse the C code, so I'm sure that some corner
+The lexer does not actually parse the C code, so I'm sure that some corner
 cases or maybe even some not so corner cases of C syntax might confuse gob
 completely.  If you find any, send me the source that makes it go gaga and I'll
 try to make the lexer try to handle it properly, but no promises.
@@ -978,6 +972,25 @@ Basically, if you use gob, just don't use the C preprocessor too extensively.
 Comments will not get through to the generated files unless inside C code.
 This makes using something like gtk-doc harder.  However I'm planning to
 fix this somehow.
+.PP
+The short name aliases are actually implemented as pointers to functions.  Thus
+if you want to get the pointer of a function using the short name alias you
+can't use the '&'.  Thus:
+.nf
+
+  void (*foo)(Self *);
+
+  /* this will NOT work */
+  foo = &short_name;
+
+  /* this will work */
+  foo = short_name;
+
+  /* Both of these will work */
+  foo = &my_class_long_name;
+  foo = my_class_long_name;
+
+.fi
 
 .SH AUTHOR
 .PP