Rishabh Yadav Junior Undergraduate Department of Electronics Engineering IIT (BHU), Varanasi Varanasi-221005 India
---------- Forwarded message ---------- From: Rishabh Yadav <[email protected]> Date: Mon, Jun 2, 2014 at 11:21 AM Subject: Re: [Gnucap-devel] Gnucap Comprehensive Help System Implementation Details To: al davis <[email protected]> Instead of storing the string in a variable we can define a separate function in plugins which can access the string stored in comment section.What advantages it have? 1.With respect to basic implementation,the need to search the source file will be eliminated. 2.At the same time,we will not face any performance issues when loading plugins even for large set of data. Disadvantage 1.User should have the source file of a plugin to get the help manual of that plugin. What I want to have is like consider a source file of a plugin XYZ /*Help Manual help on plugin */ class CMD_XYZ:public CMD{ public: void do_it(CS& Cmd, CARD_LIST* Scope){ //plugin procedure } void printhelp(){ //Parse the string in comment section and present to the user } Call to help function for this plugin will directly go to the printhelp() method. A command can be looked in command_dispatcher by CKT_BASE* c = command_dispatcher[what]; then c->do_it(cmd,Scope) is used to execute the command.Do we have something similar for help? I read that help_dispatcher are there just like command_dispatcher and they can be used but then I think we will have to define a new subclass of help and install in the help_dispatcher.But I am not sure how to use it? Rishabh Yadav Junior Undergraduate Department of Electronics Engineering IIT (BHU), Varanasi Varanasi-221005 India On Mon, Jun 2, 2014 at 6:07 AM, al davis <[email protected]> wrote: > On Thursday 29 May 2014, Rishabh Yadav wrote: > > as we are storing the help text which is a string in a > > variable,so this string will be embedded in the compiled > > shared object(.so) files.So,this string will always get > > loaded whenever the plugin will be loaded.As the string may > > be of any length so if 100 plugins are loaded at the same > > time then loading of 100 help strings may cause performance > > issues and if user don't need the help manual then efforts > > to load help string will go waste. > > In the simple case it is not much data, and it is a lot easier > than searching for files. It is probably less data than a > single instance of a device. > > For a full manual with examples, you have a point. A user may > or may not choose to install the full documentation. > > Why not do both? .. simple help built in and full manual in > separate files. The simple one can just print the string. The > full manual in separate files should be in texinfo format. You > will need a way to install it, find it, search it, ..... > > _______________________________________________ > Gnucap-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnucap-devel > _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
