Re: [dev] VOS removal
Hi Philipp, > while I`d generally agree, there is the infamous Solarmutex of vcl which > is a derivative of the vos::IMutex interface and needs that to do > refcounting. I don`t think sal`s Mutex class has virtual methods. > > Of course you could move that interface out of vos to vcl, if the > SolarMutex is the only instance left that actually needs that derivation. Oh, please let's do it. The VOS mutex had the advantage of being able to, for instance, add additional code in non-product builds to find code with wrong locking behavior. I miss this from the very time we moved to the OSL mutex ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VOS removal
Hi, while I`d generally agree, there is the infamous Solarmutex of vcl which is a derivative of the vos::IMutex interface and needs that to do refcounting. I don`t think sal`s Mutex class has virtual methods. Of course you could move that interface out of vos to vcl, if the SolarMutex is the only instance left that actually needs that derivation. Just my 2 cents, pl Jan Holesovsky wrote: Luckily, so far it was 1:1, but you are right, I'll try to collect cases where it is not if they appear on the way ;-) -- If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. -- Author unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VOS removal
Hi Michael, On Wednesday 24 October 2007, Michael Meeks wrote: > > VOS is a deprecated module (library), and all its functionality is > > handled in SAL these days. Indeed, VOS is now in fact just a wrapper > > over SAL's functions/classes. > > > > I wonder: Is anybody against removing it for good? I'm now in VCL, going > > quite quickly, but in case somebody is against it, please tell me... > > When I've looked at doing this incrementally in various cases (that I > now can't remember) - it was clear that for some things the VOS API was > fairly pleasant to use, where the sal API was unpleasant. > > So, I guess extending the sal API at the same time might be worthwhile > - but you'll need to persuade sb who is (AFAIR) still on vacation. Luckily, so far it was 1:1, but you are right, I'll try to collect cases where it is not if they appear on the way ;-) Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] VOS removal
Hi, VOS is a deprecated module (library), and all its functionality is handled in SAL these days. Indeed, VOS is now in fact just a wrapper over SAL's functions/classes. I wonder: Is anybody against removing it for good? I'm now in VCL, going quite quickly, but in case somebody is against it, please tell me... Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] build failed in cli_ure
Hello I'm trying build sourcecode 680m233 in Windows XP. I have configured build and run bootstap "./configure --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio .NET 2003/Common7/Vc7" --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.5.0_05" --with-mspdb-path="/cygdrive/c/Program Files/Microsoft Visual Studio .NET 2003/Common7/IDE" --with-midl-path="/cygdrive/c/Program Files/Microsoft Visual Studio .NET 2003/Common7/Tools/Bin" --with-csc-path="/cygdrive/c/WINDOWS/Microsoft.NET/Framework\v2.0.50727" --with-frame-home="/cygdrive/c/Program Files/Microsoft Visual Studio .NET 2003/SDK\v1.1" --disable-mozilla --with-use-shell=tcsh --with-psdk-home="/cygdrive/c/Program Files/Microsoft Platform SDK for Windows Server 2003 R2" --with-ant-home="/cygdrive/e/software/ant17" --with-build-version=BLFS --with-package-format=native --with-cups --without-myspell-dicts --disable-fontooo --disable-gnome-vfs --without-fonts --disable-neon" cd .. ./bootstrap dmake till now its fine, after some time I got following error = Building project cli_ure = /cygdrive/d/newOOo/SRC680_m233/cli_ure/inc mkout -- version: 1.7 - /cygdrive/d/newOOo/SRC680_m233/cli_ure/source - /usr/bin/cp.exe -p cliuno.snk ../wntmsci10.pro/bin/cliuno.snk /cygdrive/d/newOOo/SRC680_m233/cli_ure/version - /usr/bin/cp.exe version.txt ../wntmsci10.pro/bin/cliureversion.mk /cygdrive/d/newOOo/SRC680_m233/cli_ure/source/basetypes - /usr/bin/cp.exe -p assembly.cs ../../wntmsci10.pro/misc/assembly_ure_basetypes.cs echo ' \ [assembly:System.Reflection.AssemblyVersion( "1.0.7.0")] \ [assembly:System.Reflection.AssemblyKeyFile(@"../../wntmsci10.pro/bin/cliuno.snk")]' \ >> ../../wntmsci10.pro/misc/assembly_ure_basetypes.csguw.exe csc -warnaserror+ -incremental- -noconfig -o \ -target:library \ -out:../../wntmsci10.pro/bin/cli_basetypes.dll \ -reference:System.dll \ uno/Any.cs uno/BoundAttribute.cs uno/ExceptionAttribute.cs uno/ParameterizedTypeAttribute.cs uno/TypeParametersAttribute.cs uno/TypeArgumentsAttribute.cs uno/OnewayAttribute.csun o/PolymorphicType.cs../../wntmsci10.pro/misc/assembly_ure_basetypes.cs Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42 for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727 Copyright (C) Microsoft Corporation 2001-2005. All rights reserved. d:\newOOo\SRC680_m233\cli_ure\wntmsci10.pro\misc\assembly_ure_basetypes.cs(3,77): error CS1699: Warning as Error: Use command line option '/keyfile' or appropriate project settings instead of 'System.Reflection.AssemblyKeyFile' error CS1606: Assembly signing failed; output may not be signed -- The system cannot find the file specified. dmake: Error code 1, while making '../../wntmsci10.pro/bin/cli_basetypes.dll' ---* tg_merge.mk *--- ERROR: Error 65280 occurred while making /cygdrive/d/newOOo/SRC680_m233/cli_ure/ source/basetypes dmake: Error code 1, while making 'build_instsetoo_native' ---* *--- what should I do now to remove that error Please help me Thanks Satish Bejgum
[dev] crack-addled string hackery fun
I was playing around with strings to see if there was a route to elide
the constructors of OString and OUStrings especially for global const
strings initialised during startup
So e.g.
static const CONST_AGG_OSTRING(sGlobal, "::");
and
static const CONST_AGG_OUSTRING(TMP, "TMP");
which are, respectively, a thing called sGlobal which can be used fairly
transparently as a const OString and TMP as a const OUString. Both are
created on the stack without a constructor call and avoid duplication of
the string literal itself. I'm not sure it's worth it, but it's sort of
fun.
Clearly as mentioned in the inline comment OUStrings are a challenge so
a real world impl have mess around with per-compiler wchar_t prefixes
and size checks like icu does, and/or hack around with -fshort-wchar
like mozilla appears to do. The horror follows...
#ifndef _STRINGHACK_HXX_
#define _STRINGHACK_HXX_
#include
#include
namespace rtl
{
class OString;
class OUString;
}
template struct const_OString
{
struct internal_String
{
oslInterlockedCount refCount;
sal_Int32 length;
sal_Charbuffer[LENGTH];
};
union
{
const internal_String* pRealData;
rtl_String* pData;
};
const internal_String aData;
operator rtl::OString() const
{
return *(reinterpret_cast(this));
}
};
#define CONST_AGG_OSTRING( name, constAsciiStr ) \
const_OString name = \
{{&name.aData}, {0x4000|1, \
((sal_Int32)sizeof(constAsciiStr)-1), \
constAsciiStr}}
//The downside here is that gcc L wchar_t is 32bit by default,
//-fshort-wchar can hack it to 16bits. Some other compilers default to
// 16bit or have alternative prefixes see:
// http://bugs.icu-project.org/trac/ticket/2957
#ifdef SAL_UNICODE_NOTEQUAL_WCHAR_T
#define CONST_AGG_OUSTRING( name, constAsciiStr ) \
::rtl::OUString name(RTL_CONSTASCII_USTRINGPARAM(constAsciiStr))
#else
template struct const_OUString
{
struct internal_String
{
oslInterlockedCount refCount;
sal_Int32 length;
wchar_t buffer[LENGTH];
};
union
{
const internal_String* pRealData;
rtl_uString* pData;
};
const internal_String aData;
operator rtl::OUString() const
{
return *(reinterpret_cast(this));
}
};
#define CONST_AGG_OUSTRING( name, constAsciiStr ) \
const_OUString name = \
{{&name.aData}, {0x4000|1, \
((sal_Int32)(sizeof(L##constAsciiStr)/sizeof(wchar_t))-1), \
L##constAsciiStr}}
#endif
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
