Hi Kay, On Wednesday 31 October 2007 16:59, Kay Ramme wrote:
> >> I would be surprised if anybody is against removing it. Please go ahead > >> replacing VOS with SAL, though there are places where there is no SAL > >> counterpart yet (e.g. IMutex as mentioned by Philipp, or the VOS timer). > > > > Exactly :-) So far I'm (locally) introducing the missing functionality > > in salhelper, I hope it's a good place? Either way, I'll ask for review > > when nearer to the state in which I want it ;-) > > Let me draw a quick picture of my understanding of SAL, SALhelper etc. > > +----------------------------------------+ > | SALhelper: requires SAL, C++ ABI | > +----------------------------------------+ > | C++ SAL: requires SAL, self contained | > +- - - - - - - - - - - - - - - - - - - - + > | SAL: C' ABI | > +----------------------------------------+ > > ----- == module border > - - - == C'/C++ border > > VOS mostly overlaps with SAL (C / C++), therefor missing functionality > in SAL wrt replacing VOS should likely go into SAL and not into > SALhelper. I think I would only put it into SALhelper in case I can not > implement it SAL like (C' like implementation and a C++ inline wrapper) > in a reasonable simple way. From what I saw so far, VOS overlaps even with salhelper - it is nicely visible with salhelper::ReferenceObject. The abstract base class, rtl::IReference (Reference interface), is defined in SAL (C++), but the ReferenceObject (an implementation of IReference) is in salhelper. It has its meaning - SAL (C++) so far does not export any method of any class (it provides just what is inline in the headers), and thus no virtual method. I guess that the reason behind this was the ever-changing C++ ABI in the past, but it's just a guess ;-) [The vos counterpart of the rtl::IReference and salhelper::ReferenceObject is vos::IReference and vos::OReference.] I'll be probably forced to do something similar with the vos::IMutex and vos::OMutex - osl::IMutex as the virtual base class, and salhelper::MutexObject as the implementation, because virtual acquire()/release() are needed for the SolarMutex (as pointed out by Philipp). Or implement it directly in VCL, as Philipp proposed - I have to check if SolarMutex is really the only thing that needs IMutex. Another example was vos::ExtCommandLine - a class that implements access to command line arguments, but with the addition that an argument starting with @ is treated as a file containing more arguments. I guess this is too high-level for sal itself, but for salhelper it seems to me as bearable. > SALhelper seems to be a little unsorted regarding its purpose, though. But of course I might be completely wrong, this is just what I got from reading the sources :-) - so it might happen that I'll find another problems and another solutions for them, move the classes here and there, etc., so please take the above as preliminary. Regards, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
