Bug 65899 - std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private
Summary: std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 5.1.0
: P3 trivial
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-27 12:00 UTC by bastian.beischer
Modified: 2015-04-27 12:17 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bastian.beischer 2015-04-27 12:00:38 UTC
I'm trying to compile code with GCC 5.1.0 which makes use of the good ole:

#define private public

hack (for some reason). I know, I know, but it's not my code and I'd like it to compile out of the box...

Now the issue is this: In GCC 5.1.0's version of the sstream header one finds the following:

  template<typename _CharT, typename _Traits, typename _Alloc>
    class basic_stringbuf : public basic_streambuf<_CharT, _Traits>
    {
      struct __xfer_bufptrs;
    public:
      // Types:
      typedef _CharT                                    char_type;
      typedef _Traits                                   traits_type;

[...]

    private:

[...]

      struct __xfer_bufptrs
      {

[...]


The problem is that the member __xfer_bufptrs is implicitly private when it's declared but then later it's expliclity marked private.

Then, due to the #define private public, the second one turns public but the first one does not and there's a conflict leading to this error:

/usr/include/c++/5.1.0/sstream:335:7: error: ‘struct std::basic_stringbuf<_CharT, _Traits, _Alloc>::__xfer_bufptrs’ redeclared with different access
       struct __xfer_bufptrs
       ^


Any chance to mark the first instance private explicitly?
Comment 1 Jonathan Wakely 2015-04-27 12:14:24 UTC
No. Use -fno-access-control which does it properly.
Comment 2 Jonathan Wakely 2015-04-27 12:17:22 UTC
Ugh, -fno-access-control doesn't prevent the error.

Then I suggest using -include sstream, so that stringstream is included before some idiot comes along and redefines a keyword.

But I'm not interested in supporting -Dprivate=public, it's just wrong.