Re: [Libreoffice] [2nd attempt] Cleaning sal/inc/osl/file.hxx
On Thu, 2011-04-28 at 21:29 +0200, Chr. Rossmanith wrote: Removing the enum RC from FileBase and using the osl_File_ prefixed names instead means, that there are no ClassDerivedFromFileBase::E_None's (et al) but only osl_File_XXX everywhere. Only if it is used anywhere ? :-) of course in a gnumake world, hopefully a quick incremental re-compile would tell us. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [2nd attempt] Cleaning sal/inc/osl/file.hxx
Am 26.04.2011 20:34, schrieb Thorsten Behrens: Chr. Rossmanith wrote: Maybe it helps to put the question a second time? Sure, makes a lot of sense to me. Go for it! :) And I'll replace the wrapper functions like getSystemPathFromFileURL with the wrapped functions osl_getSystemPathFromFileURL. Vetos? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [2nd attempt] Cleaning sal/inc/osl/file.hxx
Hi there,
On Thu, 2011-04-28 at 09:10 +0200, Chr. Rossmanith wrote:
And I'll replace the wrapper functions like getSystemPathFromFileURL
with the wrapped functions osl_getSystemPathFromFileURL.
Um - I wouldn't do that. Particularly because these hide the impl.
details of the string - which are not that pleasant anyway:
static inline RC getSystemPathFromFileURL( const ::rtl::OUString
ustrFileURL, ::rtl::OUString ustrSystemPath )
{
return (RC) osl_getSystemPathFromFileURL( ustrFileURL.pData,
ustrSystemPath.pData );
}
will end up in-lined anyway; and just maps from the C++ to the C style
API.
No problem / inefficiency there. [ assuming you were proposing removing
them ;-].
HTH,
Michael.
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [2nd attempt] Cleaning sal/inc/osl/file.hxx
Hi, after removing all redundant #defines from file.hxx I had a look at the enum RC. At a first glance it seems that e.g. E_None is used only in pyuno_module.cxx (and in some comments in file.hxx) and could be replaced by the value osl_File_E_None from file.h. So put into a single question: Can the enum be removed as well? Removing the enum RC from FileBase and using the osl_File_ prefixed names instead means, that there are no ClassDerivedFromFileBase::E_None's (et al) but only osl_File_XXX everywhere. Could that lead to problems? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [2nd attempt] Cleaning sal/inc/osl/file.hxx
Maybe it helps to put the question a second time? Christina Am 20.04.2011 21:10, schrieb Christina Roßmanith: Hi, after removing all redundant #defines from file.hxx (last change not yet pushed - build is going on) I had a look at the enum RC. At a first glance it seems that e.g. E_None is used only in pyuno_module.cxx (and in some comments in file.hxx) and could be replaced by the value osl_File_E_None from file.h. So put into a single question: Can the enum be removed as well? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [2nd attempt] Cleaning sal/inc/osl/file.hxx
Chr. Rossmanith wrote: Maybe it helps to put the question a second time? Sure, makes a lot of sense to me. Go for it! :) -- Thorsten pgpyKQEwt9SJx.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
