[patch] Removal of strfwd.h (was: When to use strfwd.h)

Enrico Forestieri forenr at lyx.org
Thu Oct 3 22:50:59 UTC 2024


On Thu, Oct 03, 2024 at 11:33:18PM +0200, Pavel Sanda wrote:
>On Thu, Oct 03, 2024 at 11:05:03PM +0200, Enrico Forestieri wrote:
>> On Thu, Oct 03, 2024 at 10:04:04PM +0200, Enrico Forestieri wrote:
>> >
>> > On Thu, Oct 03, 2024 at 03:57:56PM +0200, Pavel Sanda wrote:
>> > > On Thu, Oct 03, 2024 at 01:35:55AM +0200, Enrico Forestieri wrote:
>> > > > And, after adding "#include <string>" to src/support/trivstring.h as
>> > > > suggested, it fails in this new way:
>> > >
>> > > Adding "#include <ostream>" makes cygwin happy?
>> >
>> > It helps. Compilation proceeds until the following failure:
>>
>> However, applying the attached patch it compiles and works fine.
>> See https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg219747.html for
>> the reason the patch is right.
>
>I was going to ask whether adding #include "support/trivstring.h" into 
>Format.h would work.

Yes, but trivstring.h has also to be included into Converter.h, maybe 
both guarded by "#ifdef STD_STRING_USES_COW"

>With removal of strfwd I moved
>+#ifdef STD_STRING_USES_COW
>+template<typename Char> class trivial_string;
>+typedef trivial_string<char> trivstring;
>+typedef trivial_string<char_type> trivdocstring;
>+#else
>+typedef std::string trivstring;
>+typedef docstring trivdocstring;
>+#endif
>
>into docstring.h.
>
>But I don't like it there as all trivstring stuff should imho go into 
>trivstring.h.
>Before I was afraid what will break, but as I broke cygwin anyway, 
>maybe it's time
>to get rid of this from docstring?

I am not sure what you mean. I don't think that it is right breaking 
compilation on systems where std::string uses cow, given that the 
solution is actually very simple.

As regards cygwin, compilation was broken because of our incorrect 
assumption about cow. However, it helped pinpointing this issue.

Anyway, I would like to apply the attached patch that actually checks 
whether std::string uses cow instead of inferring it from 
_GLIBCXX_USE_CXX11_ABI. Of course, the check cannot be performed when 
cross-compiling and in such a case the code assumes cow is used, as 
before.

-- 
Enrico
-------------- next part --------------
diff --git a/config/lyxinclude.m4 b/config/lyxinclude.m4
index 03e40581c9..c84c751c65 100644
--- a/config/lyxinclude.m4
+++ b/config/lyxinclude.m4
@@ -283,7 +283,34 @@ if test $lyx_cv_lib_stdcxx = "yes" ; then
   if test $lyx_cv_lib_stdcxx_cxx11_abi = "yes" ; then
     AC_DEFINE(USE_GLIBCXX_CXX11_ABI, 1, [use GNU libstdc++ with C++11 ABI])
   else
-    AC_DEFINE(STD_STRING_USES_COW, 1, [std::string uses copy-on-write])
+    AC_LANG_PUSH(C++)
+    AC_RUN_IFELSE([AC_LANG_PROGRAM([[
+#include <iostream>
+#include <string>
+bool stdstring_supports_cow()
+{
+   //make sure the string is longer than the size of potential
+   //implementation of small-string.
+   std::string s1 = "012345678901234567890123456789"
+                    "012345678901234567890123456789"
+                    "012345678901234567890123456789"
+                    "012345678901234567890123456789"
+                    "012345678901234567890123456789";
+   std::string s2 = s1;
+   std::string s3 = s2;
+   bool result1 = s1.data() == s2.data();
+   bool result2 = s1.data() == s3.data();
+   s2[0] = 'X';
+   bool result3 = s1.data() != s2.data();
+   bool result4 = s1.data() == s3.data();
+   s3[0] = 'X';
+   bool result5 = s1.data() != s3.data();
+   return result1 && result2 && result3 && result4 && result5;
+}
+    ]], [[if (stdstring_supports_cow()) exit(1);]])],[],
+    [AC_DEFINE(STD_STRING_USES_COW, 1, [std::string uses copy-on-write])]
+    [AC_DEFINE(STD_STRING_USES_COW, 1, [std::string uses copy-on-write])])
+    AC_LANG_PUSH(C++)
   fi
 else
   if test $lyx_cv_prog_clang = "yes" ; then


More information about the lyx-devel mailing list