like the dynamic loader on your system does not support dlsym to
> report a symbol not exported by the lib itself, but only indirectly by a
> lib the first lib links against.
Note that you can check what the dynamic loader does by doing
LD_DEBUG=symbols command (see LD_DEBUG=help /bin/tr
dified for Windows, so that it does not
create symlinks, but instead it copies a file if the one in solver/ is newer.
That would still require 'make dev-install' after every change, but I expect
it should be reasonably fast, quite convenient to use, and probably the be
or is there a bigger problem?
[1] http://pastebin.com/S06cqSX6
[2]
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&full-log=1334074224.6419
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@li
on't know if the debug-draw is still usefull this
> way. I don't understand why this was done.
I don't either, but your patch looks good to me, so I've pushed it, thank
you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mai
mp;rEntries) const;
Why is that? Changing the return value to a reference argument makes the API
worse and it seems like an unnecessary change to me.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.fr
mails
from the Clang tinderbox, where the watchdog eventually kills it, so this is
just to point you to the reason for it.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
014d35597a37c3220c261e35ae to just
> add a break at the end of line 251.
>
> could it be useful to push this on 3.5 branch this trivial fix ?
Pushed.
Note that it is a good practice to always end each 'case' with break (or
add /*fallthrough intended*/ ) so that the problem
t copied it from those few lines above, where there is the
same duplication.
> I've got not idea, if we can just remove WB_DOCKABLE or if it should be
> replaced by another constant.
>
> Any advice ?
I think you can simply remove one of the duplicates.
--
Lubos Lunak
l.lu...
So because of the 2 things noticed, I think there should be both and so
> just replace "1" by "2" and have "SERVICE_NAME2" as second operand.
>
> Perhaps I'm wrong or missed something, any idea ?
No, your analysis look
ot
> that large, so I attached it to this mail.
Looks ok to me, pushed, thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 06 of April 2012, Lubos Lunak wrote:
> I'm aware only of these cases where the explicit
> OUString ctor is needed:
>
> - return statements (because of the gcc bug)
> - tool String class (because that one itself is obsolete and uses should be
> converted to OUSt
t does #include
.
PS: I think you didn't want to include the solenv/gbuild/LinkTarget.mk change
in the patch.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
please tell me. I'm aware only of these cases where the explicit
OUString ctor is needed:
- return statements (because of the gcc bug)
- tool String class (because that one itself is obsolete and uses should be
converted to OUString)
- when OUString object is really needed, e.g. with t
inally going to offer my build machine for this if
needed (it's got nothing to do during the nights anyway, and more than one
rebuild and repack daily probably shouldn't be needed). I have no idea about
the storage requirements of this or the time needed for reasonable repacking,
but if th
is undefined if the comparison
evaluates to true or false (depends on string literal duplicates merging).
Which is why this would be a problem, but compilers warn about this.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
OUString anyway, and
it'd also require that person to actually not test the code. So hopefully
very unlikely and IMO not worth the inconvenience.
There'd be also the possibility of getting a warning about comparing const
char* pointers into the compilers, but
to have
> an overloaded operator== and to force bar.equalsfoo("").
Quite possibly yes :). Why would you want the explicit less convenient way?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ctRegistry_getMutex() gets a warning with Clang that can be
cleanly fixed only by breaking binary compatibility).
Do we have something for either of these?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
inherits from XInterface in 3 different ways, and I wonder what the point of
the explicit casts is. I'll go with thinking the casts are pointless historic
garbage and try plain call to acquire(), it shouldn't make it worse.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wednesday 04 of April 2012, Daniel Bankston wrote:
> Lubos Lunak wrote:
> > It seems to me you are correct. I've added !IsEmpty() check to the if(),
> > which should do what the original author wanted.
>
> I'm still a little worried about that aClip object t
est it and add to 3-5
> > too.
>
> I assume a7eb227cfcd783ffdccdcec9b56451fb54c26eb6 and
> c813c009479db3fab58fc48740ab8f80ceb93a26, but Luboš should know the
> details.
Yes, but they need 174a1d3c3da7457884a2f79016e8a9375fd5297e fi
On Tuesday 03 of April 2012, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Michael Meeks wrote:
> > On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
> > > On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> > > > (SAL_REINTERPRET_CAST is not used an
On Tuesday 03 of April 2012, Michael Meeks wrote:
> On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
> > On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> > > (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that can
> > > be binned outright.)
> &g
minserter.hxx directly into rtl/ustring.hxx
(hopefully I'm right that it won't break anything in practice), so if you now
need to know what 'foo' is, just do
SAL_DEBUG( "foo is " << foo );
The git commit hook will reject commits with these debug outputs lef
fix is trivial
here, but still).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 03 of April 2012, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Daniel Bankston [danthedev] wrote:
> > Hello, everyone,
> >
> > I have attached my patches for EasyHack Bug 46610.
>
> Looks good to me, I only removed the return's at the end of functi
age should probably be checked by someone more knowledgeable and
> experienced than me. Maybe it is nothing, but it is probably worth
> checking to be sure.
It seems to me you are correct. I've added !IsEmpty() check to the if(),
which should do what the o
strings (literals, or statically initialized and const
> std::string objects), it could put them all together into one instance in
> const data section.
I doubt any compiler we use treats std::string specially, I'd expect it's a
normal class for it just like any other.
--
based only on valgrind or if you had some
documents where the sizes didn't exactly match what the spec says.
Miklos has already fixed Read_UL(), but your patch lists more places. Could
you check why those places needed the change and make them read the proper
sizes according to what the
e, pushed, thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Sunday 01 of April 2012, Rafael Dominguez wrote:
> 0001-Replace-List-with-std-vector-EPPTHyperlink.patch
Looks good, pushed, thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
h
On Sunday 01 of April 2012, R Skinner wrote:
> On 03/31/12 18:49, Lubos Lunak wrote:
> > If you use the Clang compiler, then I somehow doubt you'll manage to
> > get 3.4.5 working with that. In fact I'm even surprised the link mentions
> > 3.5 as usable with C
"/" shows things like
nodepath = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("/")) + nodepath;
where the / string instance can be avoided completely. My changes won't do
anything about the long-lived / instances though, so there indeed one shared
instance may take care of all
htly to avoid the copy in the OUString constructor and pushed,
thank you.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
WW8AttributeOutput::FormatULSpace(), we apparently do write
sprmPFContextualSpacing as 2 bytes, which seems wrong.
So could you please explain why you decided to fix the problem this way?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice maili
On Thursday 29 of March 2012, Caolán McNamara wrote:
> On Thu, 2012-03-29 at 16:56 +0200, Lubos Lunak wrote:
> > Is there any need to run UI stuff during build? IOW, can't we simply
> > globally force using headless for everything during build?
>
> Unix has the env S
On Tuesday 20 of March 2012, Lubos Lunak wrote:
> - C++11 deprecates it and instead introduces a noexcept keyword which
> forbids the function to throw anything
>
> I'm not strongly biased either way, but what we have right now are really
> just pretty comments on function
hen I somehow doubt you'll manage to get
3.4.5 working with that. In fact I'm even surprised the link mentions 3.5 as
usable with Clang, since I had to do several fixes in master this month to
get LO compile and run with Clang on Linux.
--
Lubos Lunak
l.lu...@suse.cz
as
disabling the canvas caused the internal cairo to be dragged in by things
depending on it.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wednesday 21 of March 2012, Lubos Lunak wrote:
> On Monday 19 of March 2012, Michael Meeks wrote:
> > On Mon, 2012-03-19 at 07:33 +0100, Lubos Lunak wrote:
> > > Oh, I see. I've already noticed this myself, and that's a good
> > > explanation for Voreppe&#x
generating broken .d files (although IIRC the problem was generating Windows
paths rather than Unix paths).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 29 of March 2012, Lubos Lunak wrote:
> hwpfilter/CppunitTest_hwpfilter_test_hwpfilter.mk |1 +
> 1 file changed, 1 insertion(+)
>
> New commits:
> commit 61d6d08667e03271604007fe602063c08e0e8608
> Author: Luboš Luňák
> Date: Thu Mar 29 16:52:42 2012 +0200
&
On Tuesday 27 of March 2012, Matúš Kukan wrote:
> On 26 March 2012 17:31, Lubos Lunak wrote:
> > [ build srs ]
> > /builds/tinderbox/libo-master/basctl/source/basicide/basicprint.src cpp:
> > line 31, Fatal error: Cannot open include file "svx/svxids.hrc"
that the SDK must
be registered as default with Visual Studio (in the menu: Microsoft Windows
SDK 7.1 -> Visual Studio Registration -> Windows SDK Configuration Tool).
You can also have a look at configure.in to see what the check actually looks
for.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
de777c0cbb4d90c7f6bdcd831bf3 this problem is now visible in
> i18npool. I fixed it in master as part of
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=15bd35e4f2646ef0bba
>0cc24d171989c9e3ac6e4
>
> Attached patch is aimed to solve this problem for 3-5 branch.
Looks ok t
On Monday 26 of March 2012, Norbert Thiebaud wrote:
> On Mon, Mar 26, 2012 at 10:43 AM, Lubos Lunak wrote:
> > I have reverted the above commit in 3-5, the 3-5 tinderbox page is red
> > enough.
>
> The commit above only implement no_dep correctly.. it does not force
> you
77c0cbb4d90c7f6bdcd831bf3
> >
> > and updated the @6-fast and @15-Prague Win32 tinderboxes to use that.
>
> I would not do that so quickly. gbuild does not seem to be ready for
> --disable-dependency-tracking.
> If you get error in i18npool
I have reverted the above commit in
opies the .h file
needs to be used even with --disable-dependency-tracking (if there's one), or
there needs to be an early invoked make target that copies everything that
should be copied, or this .h copying idea needs to be dropped.
--
Lubos Lunak
l.lu...@suse.cz
_
On Friday 23 of March 2012, Lubos Lunak wrote:
> On Thursday 22 of March 2012, Norbert Thiebaud wrote:
> > --- a/solenv/gbuild/gbuild.mk
> > +++ b/solenv/gbuild/gbuild.mk
> > @@ -113,8 +113,12 @@ endif
> >
> > # for clean, setuplocal and removelocal goals we s
gt; gb_FULLDEPS := $(true)
> endif
Is this the same like should be with --disable-dependency-tracking, except
that it seems it does not with gbuild?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 19 of March 2012, Michael Meeks wrote:
> On Mon, 2012-03-19 at 07:33 +0100, Lubos Lunak wrote:
> > Oh, I see. I've already noticed this myself, and that's a good
> > explanation for Voreppe's (lack of) builds. That's a rather bad bug for
> > ti
uilds, or we can say we follow the C++11/Boost/etc. trend and
not use them, in which case we can have one macro for portable way of saying
noexcept and have an EasyHack for removing the other specifications. BTW, it
should be also noted that SAL_THROW() expands to nothing with gcc.
Op
On Tuesday 20 of March 2012, Caolán McNamara wrote:
> On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:
> > Before I start experimenting with more stuff in OUString that might look
> > a bit like operator+= , what exactly is so irritating about operator= or
> > operator+
oils this,
> > anyway.)
>
> And the += operator irritates me.
Before I start experimenting with more stuff in OUString that might look a
bit like operator+= , what exactly is so irritating about operator= or
operator+= in OUString and why?
methods from that file that no longer exist
> in the source.
That will not work reliably, unless your process also verifies that they are
really unused in all configurations. The list is generated from one
configuration and a manual check is needed that each item is in
On Monday 19 of March 2012, Stephan Bergmann wrote:
> On 03/19/2012 07:27 AM, Lubos Lunak wrote:
> > Or, actually, seeing that _rtl_uString is marked as internal by the
> > doxygen doc, it looks like it might be doable even now. Something to add
> > to my TODO list for maki
;
> so I guess there is some kind of corruption in the string "pThis" that
> is being passed around.
The this=0x29 suggests that the string is inside another type that is
referenced using a null pointer. Check out the gdb backtrace and search for
where an
ra bonus points if the code fits to one line and doesn't look like a
madness written by somebody in a maniacal "proper C++(tm)"-induced frenzy.)
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.or
On Monday 19 of March 2012, Noel Grandin wrote:
> On 2012-03-19 08:27, Lubos Lunak wrote:
> > That said, I myself dislike the buffer class. I doubt its
> > preallocation is a significant requirement for good performance
> > (especially given it's only 16 characters).
anything there. Hmm, except that this CMS_DLL_BUILD defining
is done in MSVC project file, so I assume that's not used for gcc build. I
suppose the lcms2 build should add -DCMS_DLL_BUILD to CPPFLAGS when not doing
msvc build?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 19 of March 2012, Matúš Kukan wrote:
> On 18 March 2012 21:03, Lubos Lunak wrote:
> > MSVC/Windows build fails at the very end with an error about emserlo.dll
> > missing, probably caused by the recent embedserv conversion to gbuild. As
> > this is seem to be buil
OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
> > to OUStringBuffer::SearchBackward(...)?
No. As said above, if the addition is justified, for consistency it should be
modeled after OUString, not String.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
27;ve pasted at
http://pastebin.ca/2129689 the log for 'make' after first running 'make
embedserv.clean' (there's other stuff being needlessly rebuilt for whatever
reason). At the end of the log there's also a find command showing that the
library has been built, b
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1332055201.31263#14239
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
at touches lcms2 even with a
ten-foot pole does this define). Is the attached patch a good way to solve
the problem as well? I don't know what the usual idiom of handling this is,
so I'd like somebody to check.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/lcms2/lcms2-windows-export
"registration of SDK with Visual Studio [2008] seems to
> be the answer". How do I do that?
in the menu: Microsoft Windows SDK 7.1 -> Visual Studio Registration ->
Windows SDK Configuration Tool
--
Lubos Lunak
l.lu...@suse.cz
ere have
been only master commits from me (heh...), you most probably need to either
update or do a clean rebuild (I think I've noticed this one as well and it
needed 'make offapi.clean').
--
Lubos Lunak
l.lu...@suse.cz
___
L
On Saturday 17 of March 2012, Lubos Lunak wrote:
> svx/inc/svx/sdrpaintwindow.hxx |3 +++
> 1 file changed, 3 insertions(+)
>
> New commits:
> commit 9865a0d430da8948210a2cd9d4bae08e6023f4c8
> Author: Luboš Luňák
> Date: Sat Mar 17 08:39:26 2012 +0100
>
>
compiler and switched to it,
and it seems one of its nice features should be the ability to analyze and
rewrite code, in which case a change like this or e.g. the 'str.length() ==
0' -> 'str.isEmpty()' change could be done reliably by writting some clang
code. I still need
ably want
77ee92a6bd8f40022ab03325d158de4b67a41dd0 , which I think only made it to 3-5
branch but not 3-5-1, in which case you probably want
ee67c55260ec7723c39606955ccdbd3e2934935a .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
Li
or clang-3.1r152540. So it looks like we
can either just enable the warning and selectively disable it, or we can have
a configure check if some older gcc version has the problem (well, given that
#pragma diagnostic is recent with gcc, it'll need an #ifdef anyway).
$ g++ -Wall dtor
On Monday 12 of March 2012, Stephan Bergmann wrote:
> On 03/12/2012 03:09 PM, Lubos Lunak wrote:
...
> Looks like a misunderstanding whether hidden visibility is intended for
> "remove unnecessary entries from dynamic symbol tables (but keeping
> certain symbols exported to no
On Monday 12 of March 2012, Michael Stahl wrote:
> On 12/03/12 15:09, Lubos Lunak wrote:
> > Windows/MSVC experts
...
> applying logic to how C++ features interact with linkers on various
> platforms is generally a futile endeavour.
Works fine for me :).
> > Assuming th
libo/sal/qa/rtl/strings/test_ostring_stringliterals.cxx(103)
>
> : error C2440: '' : cannot convert from 'const char
>
> []' to 'rtl::OString'
> No constructor could take the source type, or constructor
> overload resolution was ambiguous
> [
Windows/MSVC experts
On Monday 12 of March 2012, Stephan Bergmann wrote:
> On 03/10/2012 04:39 PM, Lubos Lunak wrote:
> > commit 34f8495dd948e2ad9d64c2c19110e69840cefd1a
> > Author: Luboš Luňák
> > Date: Sat Mar 10 15:37:02 2012 +0100
> >
> > exported te
TL_CONSTASCII_STRINGPARAM( "bar" ))
+ foo.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "bar" ))
that this will be soon obsolete by these changes and easily replaced by plain
foo == "bar"
(Do we have an Easy Hack asking for the above, so that I change it? I
couldn&#
al, I think there are more
important problems than having a homebrewn build system that seems to work
good enough), but even handwritting Makefile files could have probably won
such "fair" comparison.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 28 of February 2012, Lubos Lunak wrote:
> I'd like to revisit the choice of considering string literals to be either
> ASCII or UTF-8, as discussed in the thread about removing
> RTL_CONSTASCII_USTRINGPARAM. While I was ambivalent about it, I now think
> we should g
On Wednesday 29 of February 2012, Caolán McNamara wrote:
> On Wed, 2012-02-29 at 17:11 +0100, Lubos Lunak wrote:
> > Do we actually have code that tries to gracefully handle running out of
> > memory? Because if not, and I doubt we realistically do[*]
>
> Its not O[U]String
On Wednesday 29 of February 2012, Lionel Elie Mamane wrote:
>So here's the patch for a boost-free OUString, with manually
>implemented const_iterator.
> +OSL_ASSERT( p <= s->getLength() );
OSL_ASSERT() is obsolete, use normal assert().
--
Lubos Lu
On Wednesday 29 of February 2012, Stephan Bergmann wrote:
> On 02/29/2012 03:28 PM, Lubos Lunak wrote:
> > On Wednesday 29 of February 2012, Stephan Bergmann wrote:
> >> However, there are also situations where bad input (malicious or
> >> otherwise) would cause an appli
does not really need it in OUString ctors.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
xt time the larger string can cause
running out of memory when appending to OUStringBuffer, when invokend with
OUString's operator+, or any other of those functions that OSL_ENSURE the
allocation result and are done with it.
--
Lubos Lunak
l.lu...@suse.cz
_
ions
- with today's systems (overcommitting, etc.) it is rather pointless to guard
against allocation failures
Does somebody see a good reason not to just remove it?
--
Lubos Lunak
l.lu...@suse.cz
From e1e3406cb73559c7760f0e28965a8bb0c4c19b4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo
ments,
which can be satisfied by providing a notice and our source code.
Specifically, I think section 5 of LGPLv3 applies here.
But the proper solution to this problem is finding somebody who can't say
IANAL and thus should be able to provide a founded answer. I would be
surprised
On Thursday 23 of February 2012, Stephan Bergmann wrote:
> On 02/23/2012 05:08 PM, Lubos Lunak wrote:
> > commit 437fe5a11f68d1848c49121394f16f09611b made me notice that we
> > actually build with -std=c++0x and not -std=gnu++0x, which I think would
> > make more sense a
s are disabled.
Any objections to switching to gnu++0x ?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
, which avoids the ambiguity in all the other places where
the value passed is const.
BTW, the two ctor variants even do different things, despite looking
semantically equivalent at a first look, so this looks like misdesigned API
to me.
--
Lubos Lunak
l.lu...@suse.cz
hing that
is not intended to be changed, so the second const does serve a purpose and
theoretically this form is actually the correct one, but in practice people
do not bother with the second const for the convenience of less typing and
easier
odata.
It is doable with a macro [*], but then we're back at the beginning of this
RTL_CONSTASCII_USTRINGPARAM discussion.
[*] http://www.macieira.org/blog/2011/07/qstring-improved/
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
On Thursday 09 of February 2012, Lubos Lunak wrote:
> Actually, no need for a week, this one is reasonably simple. Therefore I
> challenge RTL_CONSTASCII_USTRINGPARAM to a fight to the death. Its death,
> that is.
>
> Attached is a patch that removes the need for RTL_CONSTASC
d, since I'm already asking, is the Windows performance the reason include
files are scattered this way? E.g. in sw/ I find this actually rather
annoying, some .hxx files are in inc/, some next to .cxx sources, Writer
AFAIK does not really export anything anyway, and I always have to jump
around ju
nd while I've eventually found a way to do it, based on
http://www.macieira.org/blog/2011/07/initialising-an-array-with-cx0x-using-constexpr-and-variadic-templates/
,
see attachment, it turns out to be unusable in practice. Maybe later.
--
Lubos Lunak
l.lu...@suse.cz
// With gcc-4.5.1
es of the latter to become
> uses of the former; so if you seek consistency across a function, it
> might be better to replace other occurrences of sal_True/False than to
> do the opposite).
Moreover, although the change technically keeps the code the same, it
slightly breaks the semantics
ere.)
Everywhere, eventually. If it can work for ctors, it should work everywhere
else too.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 10 of February 2012, Stephan Bergmann wrote:
> On 02/10/2012 12:18 PM, Lubos Lunak wrote:
> > This is sal/, so the library needs to maintain binary compatibility,
> > does it not? That requires adding the OUString overload rather than
> > fixing the exiting func
On Friday 10 of February 2012, Stephan Bergmann wrote:
> On 02/10/2012 11:30 AM, Lubos Lunak wrote:
> > +/**
> > + * @overload
> > + * @since LibreOffice 3.6
> > + */
> > +oslGenericFunction SAL_CALL getFunctionSymbol( const
> > ::rtl::O
On Friday 10 of February 2012, Stephan Bergmann wrote:
> On 02/09/2012 06:16 PM, Lubos Lunak wrote:
> > Attached is a patch that removes the need for
> > RTL_CONSTASCII_USTRINGPARAM (henceafter called 'macro', because it annoys
> > me to write this even in it
On Thursday 09 of February 2012, Caolán McNamara wrote:
> On Thu, 2012-02-09 at 18:16 +0100, Lubos Lunak wrote:
> > suggests that OString in fact does not stop at \0's when handling
> > strings. I'm kind of baffled by this, I personally consider it a flaw
> > that a
On Thursday 09 of February 2012, Lubos Lunak wrote:
> On Thursday 09 of February 2012, Michael Meeks wrote:
> > Personally, I'd -love- someone to rename ~all of these
> > RTL_USTR() or RTL_STR() or somesuch - we have enough pointlessly hard to
> > read and indent co
401 - 500 of 726 matches
Mail list logo
