Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
At 3:21pm -0500 Tue, 15 Nov 2011, Kohei Yoshida wrote: sc/inc/cell.hxx |4 ++-- sc/source/core/data/cell2.cxx | 10 ++ 2 files changed, 12 insertions(+), 2 deletions(-) New commits: commit 87be97a31d8686e3e6e976bb5585b32c096ca19d Author: Kohei Yoshidakohei.yosh...@suse.com Date: Tue Nov 15 15:20:13 2011 -0500 Make these two methods non-inline. From the curious cat: why? As I slowly code, are there coding guidelines of which I should be aware but have missed? Are you working toward keeping signatures in one place and definitions/instantiations in another? Thanks, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
Hi Kevin, On Wed, Nov 16, 2011 at 12:21 AM, Kevin Hunter hunt...@earlham.edu wrote: From the curious cat: why? Because that made it easier to debug whatever I was debugging. Plus, I don't believe in those implicitly inline methods, especially in headers that are included by millions. Imagine if you have to re-compile hundreds of source files every time you change the header... Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
At 12:28am -0500 Wed, 16 Nov 2011, Kohei Yoshida wrote: On Wed, Nov 16, 2011 at 12:21 AM, Kevin Hunter wrote: From the curious cat: why? Because that made it easier to debug whatever I was debugging. Plus, I don't believe in those implicitly inline methods, especially in headers that are included by millions. Imagine if you have to re-compile hundreds of source files every time you change the header... Heh, been there, done that. /Doing/ that as I type. And still compiling that ... Thanks for the info. Would you like me to do similar, as I note them while working on/learning notes? Kevin P.S. Still compiling, because of a header change. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
On Wed, 2011-11-16 at 00:36 -0500, Kevin Hunter wrote: Thanks for the info. Would you like me to do similar, as I note them while working on/learning notes? I would encourage you to not do this style of implicit inlining in your code, sure, but I wouldn't want you go wild and start editing a bunch of headers just for the sake of it. This is not a definite rule; use your best judgment is what I would say. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
On 11/16/2011 06:45 AM, Kohei Yoshida wrote: I would encourage you to not do this style of implicit inlining in your code, sure, but I wouldn't want you go wild and start editing a bunch of headers just for the sake of it. While we are at it: Not inlining functions can be especially beneficial for functions that are exported from a library. For example, not inlining the destructor of a class with virtual functions gives the compiler a definite place to put the vtable, so it need not be duplicated across all the libraries that derive from that class. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
Hi Kohei, On Friday, 2011-11-11 12:17:21 -0500, Kohei Yoshida wrote: commit eaea417bfdf8d06df2b7f2e42c904c32ce77e871 Removing the mixed comparison flag, which is no longer needed. Isn't that needed for MATCH and ([HV])LOOKUP with mixed data such as 1,2,3,b,c,d when queried for a would return the last less_or_equal position, hence 3? Or are we now on a good track where when querying for string we always return #N/A if the less_or_equal match is numeric (and vice versa)? Thanks. Reverted. Will try to come up with a different approach then. IMHO (correct me if I'm wrong) for the sorted range lookup Excel returns #N/A if the search is of type Text and the last element found for less_or_equal is of type Number. This is also what ODFF/OpenFormula defines, for example for VLOOKUP http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1018436_715980110 My question was more in the direction if, when the mixed lookup is removed, we return the correct results for those spreadsheet functions accordind to ODFF. If yes, then the removal is fine. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgp6aPkD6ppJF.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
Hi Kohei, On Thursday, 2011-11-10 12:49:29 -0800, Kohei Yoshida wrote: commit eaea417bfdf8d06df2b7f2e42c904c32ce77e871 Author: Kohei Yoshida kohei.yosh...@suse.com Date: Thu Nov 10 15:45:53 2011 -0500 Removing the mixed comparison flag, which is no longer needed. This flag was introduced years ago to deal with Excel's behavior on incorrectly sorted data range. But later versions of Excel no longer follow that behavior keeping this flag would make the evaluation code unnecessarily more complex hard to adopt to multi-item matching. Isn't that needed for MATCH and ([HV])LOOKUP with mixed data such as 1,2,3,b,c,d when queried for a would return the last less_or_equal position, hence 3? Or are we now on a good track where when querying for string we always return #N/A if the less_or_equal match is numeric (and vice versa)? Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpMLqpstyCPG.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source
On Fri, 2011-11-11 at 15:41 +0100, Eike Rathke wrote: Hi Kohei, On Thursday, 2011-11-10 12:49:29 -0800, Kohei Yoshida wrote: commit eaea417bfdf8d06df2b7f2e42c904c32ce77e871 Author: Kohei Yoshida kohei.yosh...@suse.com Date: Thu Nov 10 15:45:53 2011 -0500 Removing the mixed comparison flag, which is no longer needed. This flag was introduced years ago to deal with Excel's behavior on incorrectly sorted data range. But later versions of Excel no longer follow that behavior keeping this flag would make the evaluation code unnecessarily more complex hard to adopt to multi-item matching. Isn't that needed for MATCH and ([HV])LOOKUP with mixed data such as 1,2,3,b,c,d when queried for a would return the last less_or_equal position, hence 3? Or are we now on a good track where when querying for string we always return #N/A if the less_or_equal match is numeric (and vice versa)? Thanks. Reverted. Will try to come up with a different approach then. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
