[LyX/master] Fix header.

[Scott Kostyshak]

On Sat, Feb 29, 2020 at 02:56:19PM -0500, Richard Kimberly Heck wrote:
> On 2/29/20 12:38 PM, Scott Kostyshak wrote:
> > On Sat, Feb 29, 2020 at 05:45:29AM +0100, Richard Kimberly Heck wrote:
> >> commit 4460df329226ab5e72adab0ff764b7496022bbbd
> >> Author: Richard Kimberly Heck <rikiheck at lyx.org>
> >> Date:   Fri Feb 28 23:52:06 2020 -0500
> >>
> >>     Fix header.
> >> ---
> >>  src/support/Systemcall.h |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/src/support/Systemcall.h b/src/support/Systemcall.h
> >> index d3d2189..537a701 100644
> >> --- a/src/support/Systemcall.h
> >> +++ b/src/support/Systemcall.h
> >> @@ -15,7 +15,7 @@
> >>  #ifndef SYSTEMCALL_H
> >>  #define SYSTEMCALL_H
> >>  
> >> -#include <string>
> >> +#include "strfwd.h"
> >>  
> >>  namespace lyx {
> >>  namespace support {
> >> -- 
> >> lyx-cvs mailing list
> >> lyx-cvs at lists.lyx.org
> >> http://lists.lyx.org/mailman/listinfo/lyx-cvs
> > What was broken? Did it produce a warning?
> 
> We generally try not to include <string> in header files.

Why not? I read through git log strfwd.h to try to answer this question
myself but couldn't figure it out. I also tried reading through the file
itself but could not understand why we prefer including this header over
<string> if the purpose is to use std::string (as seems the case in
src/support/Systemcall.h)

> That's why
> strfwd.h exists.


> > When when I remove that header completely, I don't get a compilation
> > error. Is it just by luck (e.g., something else happens to triggers
> > loading the header)?
> I noticed this, too, but I'm not sure why it doesn't fail. The
> empty_string() method is what we
> need here, so it seems a good idea to include this header.

OK.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200229/5aaee342/attachment-0001.asc>