Re: orbOptions class - Usage from user code?

On Fri, 2019-08-02 at 14:19 +0200, Martin Ba via omniORB-list wrote:

> Is it meaningfully possible to use the `orbOptions` class from
> `omniORB4\internal\orbOptions.h` from regular user code?

Sorry for taking ages to reply to this. Maybe it's too late now, but
anyway...

It's generally best not to reach into the things in "internal", but
they are installed so application-level code can see them if it needs
to. There is no fundamental reason why you shouldn't use them.


> We have now the use case that we would need to add another option to
> the config file from our code, even when the file is already there.
> So I though it might be possible to use the class `omniOptions` from
> omniORB that parses the options file, instead of trying to
> approximate parsing it itself to "edit" it with an additional option.

So you intend to use the code to parse the file, then use the parsed
results to rewrite a new file with the same content plus some extra
things?  Aside from the problem of it being an "internal" class, the
other problem you would have is that it doesn't maintain comments or
whitespace structure from the config file, so if the user has added
comments to explain their edits, you will lose them.

Or are you trying to do something else?

> * Is there any specific downside when using an "internal" class,
> except
> that it obviously wasn't meant to be used from outside.
> 
> * omniOptions is a singleton:
> 
> That means I cannot create a local instance to do the file parsing,
> however seeing as `ORB_init` does a
> `orbOptions::singleton().reset();`
> at startup, I might just be able to use the singleton to pre-parse
> the config file anyway.

It's a singleton because each module that has some options registers
functions to handle the options with the singleton. That all happens at
static initialisation time, before main() is called. It has to handle
the fact that some options are in libraries other than the core, and so
may or may not be present.

If I understand what you are trying to do (and maybe I don't!), I think
you would probably be better off just writing some simple code to
rewrite the file, rather than trying to reuse orbOptions.

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --



_______________________________________________
omniORB-list mailing list
[email protected]
http://www.omniorb-support.com/mailman/listinfo/omniorb-list