C++11 in LibreOffice

> On Mon, Jul 16, 2012 at 12:15 PM, János Uray <[hidden email]> wrote:
>> I have a simple question.
>> Can I use C++11 in LibreOffice development? Or at least some parts of C++11?
>
> The short answer is, no, not yet.  We still need to support compilers
> that don't support C++11 fully.  I think that, eventually we'll be
> able to start using C++11 features in our code base, but it'll take a
> while before we get to that point.
>
> I hope this answers your question.
>
> Kohei

> On 07/17/2012 05:11 AM, Lubos Lunak wrote:
>>
>>   So, as long as we require to build LO with MSVC, we can revisit the
>> question
>> of hard-depending on C++11 in, uhm, let's be optimistic and say 3 years.
>> IOW,
>> we can probably get there faster by ditching backwards ABI compatibility
>> with
>> LO4 and switching to a different compiler for Windows.
>
>
> What I'm curious is how the binaries generated from different compilers
> compare on Windows.  If their performances are more or less comparable, then
> I could care less whether we stick with MSVC or gcc (or clang if it's
> available on Windows).  But if MSVC still produces more optimized binaries,
> then I would be reluctant to support switching to a different compiler
> (though my voice is only one head count, easily overruled by the majority
> votes when it comes down to it).
>
> Kohei
>

> On 07/17/2012 05:11 AM, Lubos Lunak wrote:
>>   So, as long as we require to build LO with MSVC, we can revisit the question
>> of hard-depending on C++11 in, uhm, let's be optimistic and say 3 years. IOW,
>> we can probably get there faster by ditching backwards ABI compatibility with
>> LO4 and switching to a different compiler for Windows.
>
> What I'm curious is how the binaries generated from different compilers
> compare on Windows.  If their performances are more or less comparable,
> then I could care less whether we stick with MSVC or gcc (or clang if
> it's available on Windows).  But if MSVC still produces more optimized
> binaries, then I would be reluctant to support switching to a different
> compiler (though my voice is only one head count, easily overruled by
> the majority votes when it comes down to it).

> On Thu, Jul 19, 2012 at 08:59:34AM -0400, Kohei Yoshida wrote:
>> On Thu, Jul 19, 2012 at 7:45 AM, Michael Stahl <[hidden email]> wrote:
>>
>>> i don't believe an office suite will benefit all that much from
>>> sophisticated compiler optimizations;
>>
>> It's certainly your opinion. But I tend think that, any binary
>> generated from a compiler could use the benefit of compiler
>> optimization. I find it hard to believe that somehow an "office suite"
>> category is an exception. But maybe it's just me.
>
> I think Michael was suggesting that our prouct is IO-bound and not that
> CPU-bound anyway. While that isnt completely the case for the area you work on
> it is a valid assumption for the product as a whole.

>
> On Thu, 2012-07-19 at 16:04 +0200, Michael Stahl wrote:
>> i'm saying it doesn't benefit from the "sophisticated" optimizations that
>> vendor compilers like SunStudio or Intel do that speed up your BLAS
>> stuff with gigabytes of floating point arrays by X times because office
>> suites don't contain gigabytes of floating point arrays.
>
>         So - Kohei has been working for years to turn Calc spreadsheets into
> gigabyte arrays of floating point numbers - precisely to take advantage
> of this sort of optimisation :-)
>
>         Having said that, I totally agree, our problems are 95% algorithmic,
> and fiddling with compiler optimiser settings is the last refuge of the
> desperate man ;-)
>
>         The thing that concerns me about gcc vs. MSVC++ is not the speed of the
> generated code, but it's size (which impacts startup performance, I/O
> load, memory use etc.). If you checkout the tables you linked the binary
> size column is quite stark:
>
>         http://www.willus.com/ccomp_benchmark2.shtml?p18+s12
>         http://www.willus.com/ccomp_benchmark2.shtml?p14+s12
>
>         in several cases a 2x growth. So - clearly this would need benchmarking
> various ways to see what the story is there with -Os etc.
>
>         IMHO it's well worth looking at a gcc cross-compiled solution for
> Windows though; if only to use really fast, fully repeatable, Free
> Software tooling; though it'd be nice to use an enterprise / maintained
> cross-compiler - where is cygnus when you need them :-)
>
>         All the best,
>
>                 Michael.
>
> --
> [hidden email]  <><, Pseudo Engineer, itinerant idiot
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

> Hi there,
>
> On Thu, 2012-07-19 at 11:21 -0500, Yi Ding wrote:
>> +1 ...
>> +1 ...
>> +1 ...
>
>         Thanks for your encouragement, but this is a developers list :-) which
> of these do you want to work on ? There is low-hanging fruit everywhere
> for developers to focus on - which would you like to look into ? Startup
> performance for example: reducing the configmgr thrash by tweaking that
> code to allow us to split out settings that are not commonly needed eg.
> the labels data would give a measureable boost to startup. It requires
> only a hacker - is it you ? :-)
>
>         All the best,
>
>                 Michael.
>
> --
> [hidden email]  <><, Pseudo Engineer, itinerant idiot
>

> On 20/07/12 16:31, Yi Ding wrote:
>> Fair point. :-) Let me see if I can get a build working on Windows
>> this weekend.  I see on the wiki that building with VS 2010 is not yet
>> supported:
>>
>> http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies
>>
>> Is this information still current?
>
> yes it is; there is actually a patch for MSVC2010 attached here:
> https://bugs.freedesktop.org/show_bug.cgi?id=30655
>
> but it is quite outdated and apparently even when it was written there
> was some CLR thing that didn't work.
>
> if you know the MSVC toolchain well then you could try to get that to
> work, and it would be very useful, but you will probably have to spend
> some time on it; currently only MSVC 2008 is known to work.