Topic: basic_ios copyfmt method


Author: kuehl@ramsen.informatik.uni-konstanz.de (Dietmar Kuehl)
Date: Sat, 11 Nov 2000 03:32:32 GMT
Raw View
Hi,
scottgregory@my-deja.com wrote:
: Their shipped rw/iosbase file has the method
: class _RWSTDExport ios_base
: {
: public:
:     ios_base& copyfmt(const ios_base& rhs);
: ...
: }

Although I have a similar method in my implementation (to avoid providing
access to private date in 'ios_base' to 'basic_ios'), it is named
differently (ie. with an internal name): There is no 'copyfmt()' function
defined by the standard for 'std::ios_base'.

: and the header <ios> has this subclass

:   template<class charT, class traits>
:   class _RWSTDExportTemplate basic_ios : public ios_base
:   {
: ...
:     typedef basic_ios<charT, traits>           ios_type;
: ...
:     ios_type& copyfmt(const ios_type& rhs);
: }

: Now when I compile with +w (extra warnings), the compiler complains that
: basic_ios method copyfmt hides the method on the base class ios_base.

I would consider this to be a flaw in the implementation: The standard
headers should produce neither an error, of course, nor warnings. The
latter does not seem to be so obvious to all vendors... Actually, I
would prefer my implementation would never produce warning messages
from the standard headers except when a user misuses some feature even
if the highest warning level is turned on. Unfortunately, there is no
way to work around some warnings emitted by gcc's -Weffc++ due to the
standard interfaces (the return types of some stream iterator increment
operators is warned about).

: And they do indeed have different signatures.

It is just a warning. I think it should be fixed but it is no error.

: So ?  Is this a compiler or header file non-conformity?  Or something
: else that I have missed.

It is a conforming implementation but it is a quality of implementation
issue: A really good implementation would produce no warnings unless
the user misuses some features. However, until the implementation is
really conforming, my guess is that the focus is on the conformance
issue rather than on the quality. ... and a compiler is free to issue
as much diagnostics as it wishes without violating the standard as long
as the executable is created with the prescribed behavior: Only if the
compiler fails to issue a diagnostic in a case where it is required to
issue one, it would be a problem.
--
<mailto:dietmar_kuehl@yahoo.de>
<http://www.fmi.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: "Valentin Bonnard" <Valentin.Bonnard@free.fr>
Date: Sat, 11 Nov 2000 00:49:35 CST
Raw View
> Unfortunately, there is no
> way to work around some warnings emitted by gcc's -Weffc++ due to the
> standard interfaces (the return types of some stream iterator increment
> operators is warned about).

The header don't have to be fixed, they aren't faulty.

A compiler shouldn't emit warnings due to problems inside <header files>.
(In case of doubt, when the cause of the problem isn't known for
sure, a warning should be emited.)

The compiler should be fixed. Doing anything else is pure bugware.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: scottgregory@my-deja.com
Date: 2000/11/10
Raw View
Hello;

Trying to understand the standard and my vendors implementation thereof.

My compiler is Sun Forte 6.0 (CC 5.1).

They ship the Rogue Wave standard library, and it is there that I am
having warnings, that I have related to Sun, but am wondering if it is
the compiler or the code at fault for violating the standard.

Their shipped rw/iosbase file has the method
class _RWSTDExport ios_base
{
public:
    ios_base& copyfmt(const ios_base& rhs);
...
}

and the header <ios> has this subclass

  template<class charT, class traits>
  class _RWSTDExportTemplate basic_ios : public ios_base
  {
...
    typedef basic_ios<charT, traits>           ios_type;
...
    ios_type& copyfmt(const ios_type& rhs);
}

Now when I compile with +w (extra warnings), the compiler complains that
basic_ios method copyfmt hides the method on the base class ios_base.
And they do indeed have different signatures.

So ?  Is this a compiler or header file non-conformity?  Or something
else that I have missed.

Thanks!
sdg


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]