You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current version of RDoc, when searching for class definition APIs such as rb_define_class and rb_define_method in a C file, if a match is found in that file, it seems to only accept the class and method definitions in that file.
This means that no matter how the method is defined in other C files, it will be ignored.
A mechanism will needed that to first gather elements from the C file and determine whether they are properly defined as classes. In this case, the parse tree would be desirable. rb_xYYY variables used as object entities are basically the global variables, so they must be declared as extern when defining classes at the C level. However, this way does not work in outer method definitions (#pack/#unpack, etc.) because these "global variables" are not defined as classes.
In C, global variables must be initialized. A popular solution is to do the initialization in a single C file.
This allows you to initialize variables as needed.
#defineGLOBAL_VARIABLE_DEFINE// without extern
#include"global.h"
In Ruby, C's global variables are definitions, which means they have a different meaning than initialization.
Now below, definition in single file, RDoc is well parse here:
/* * call-seq: * bar -> nil * * It is a test.*/static VALUE
foo_bar(VALUE self)
{
return Qnil;
}
voidInit_foo()
{
rb_cFoo = rb_define_class("Foo", rb_cObject);
rb_define_method(rb_cFoo, "bar", foo_bar, 0);
}
However, a library that could become a small framework (such as image processing) is unlikely to be a single C file.
That is, it needs to be improved.
Below is a typical way I write it, and it is an example of an extension library that uses Professor Oura's FFT in Ruby.
The compiler passes it, but RDoc doesn't.
The RDoc parser only checks words, not C syntax.
Therefore, it seems possible to write code that is passed by the compiler but ignored by the RDoc parser.
If it's readable, it's a bit "fashionable".
In the current version of RDoc, when searching for class definition APIs such as
rb_define_class
andrb_define_method
in a C file, if a match is found in that file, it seems to only accept the class and method definitions in that file.This means that no matter how the method is defined in other C files, it will be ignored.
A mechanism will needed that to first gather elements from the C file and determine whether they are properly defined as classes. In this case, the parse tree would be desirable.
rb_xYYY
variables used as object entities are basically the global variables, so they must be declared asextern
when defining classes at the C level. However, this way does not work in outer method definitions (#pack/#unpack, etc.) because these "global variables" are not defined as classes.In C, global variables must be initialized. A popular solution is to do the initialization in a single C file.
This allows you to initialize variables as needed.
In Ruby, C's global variables are definitions, which means they have a different meaning than initialization.
Now below, definition in single file, RDoc is well parse here:
However, a library that could become a small framework (such as image processing) is unlikely to be a single C file.
That is, it needs to be improved.
Below is a typical way I write it, and it is an example of an extension library that uses Professor Oura's FFT in Ruby.
The compiler passes it, but RDoc doesn't.
It is expected that more extension libraries with this syntax will be available in the future. You may want to reconsider RDoc as well.
The text was updated successfully, but these errors were encountered: