[Os-project-managers] The one started this latest round...

Horand Gassmann Horand.Gassmann at DAL.CA
Thu Jan 12 15:56:53 EST 2012


Horand Gassmann <Horand.Gassmann at Dal.Ca> wrote:

> Let me perhaps try to summarize, in the hopes that this might make  
> it easier for you.
>
> First, the problem is that we need an OSInstance object both in  
> OSServiceMethods and in OSSolverService (if we want to print  
> something). We have been making osinstance a data member of  
> oscommandline, which is available everywhere, and is being passed  
> from one routine to the next. Since oscommandline also contains an  
> osil string (along with the name of the OSiL file), this seemed like  
> a clean extension. (OSOptionsStruc did not contain the osinstance,  
> but did contain the osil string.)
>
> We populate the osinstance in the oscommandline element in the  
> nonstandard constructor of OSServiceMethods. There we new an  
> OSiLReader, read the osil string into the OSiLReader's m_osinstance  
> element (which is private), and somehow associate it with the  
> oscommandline object.
>
> I have been doing a shallow copy (duplicating just the pointer), but  
> that leads to a segfault, because I need to destroy the OSiLReader  
> at the end of the constructor.
>
> Alternatives are:
>
> 1. allocate the OSiLReader in the OSSolverService and pass it around  
> as an argument of OSServiceMethods
> 2. make the OSiLReader an element of OSServiceMethods
> 3. make osilreader->m_osinstance a public member, so that I can NULLify it
> 4. write a (public) method osilreader->nullifyInstance() that has  
> the same effect
> 5. do a deep copy of osinstance
>
> 5. is my least favorite method. OSInstance objects are large, and  
> copying them is going to take lots of time. I think 1. and 2. are  
> the only real options, but perhaps there is something I have not yet  
> thought of.

As I read this again it occurs to me that this is very similar to the  
problem Walter Weldon raised in ticket 48. I am not sure that I agree  
a deep copy s the answer, but it is a bit frustrating to know that  
elements read in a reader (OSiLReader, OSoLReader, OSrLReader,  
OSCommandLineReader) are only available while the reader is active. I  
have a feeling that this is shortsighted and wrong. I think all my  
problems would be solved if we could make use of smart pointers, such  
as auto_ptr:

http://www.gotw.ca/publications/using_auto_ptr_effectively.htm

Unfortunately it seems that this would change the API and so push us  
into version 3.0.

Cheers

gus



More information about the Os-project-managers mailing list