Topic: Defect report: Default modes missing from basic_fstream member specifications


Author: do-not-spam-benh@bwsint.com (Ben Hutchings)
Date: Mon, 5 Apr 2004 18:34:02 +0000 (UTC)
Raw View
Pete Becker wrote:
> Ben Hutchings wrote:
>>
>> [ Note: Forwarded to C++ Committee. -sdc ]
>>
>> The second parameters of the non-default constructor and of the open
>> member function for basic_fstream, named "mode", are optional
>> according to the class declaration in 27.8.1.11 [lib.fstream].  The
>> specifications of these members in 27.8.1.12 [lib.fstream.cons] and
>> 27.8.1.13 lib.fstream.members] disagree with this, though the
>> constructor declaration has the "explicit" function-specifier implying
>> that it is intended to be callable with one argument.
>>
>
> Well, sort of. The underlying notion is that you can't repeat a default
> argument:

Sure.

<snip>
> The style adopted in the standard is to make class and template synopses
> look pretty much like definitions, and for the detailed descriptions of
> the functions to begin with declarations that look more like the actual
> function definition.

That may have been the intent, but it doesn't seem to have happened.

> So the above class would be documented in the standard like this:
>
> 1.1 Class C
>
> class C
> {
> public:
> void f(int i = 3);
> void g(int i = 3);
> };
>
> 1.1.1 C members
>
>  void C::f(int i)
>
>  (description goes here)
>
>  void C::g(int i)
>
>  (description goes here)

The standard never (so far as I can see) uses qualified names in the
descriptions of member functions.  It also uses the "explicit" and
"virtual" function specifiers in some descriptions (I counted 30 and
10 instances respectively) though they are not allowed in out-of-line
member function definitions.  I'm quite happy with this and I'd be
happier still if those function specifiers were consistently repeated
in the descriptions.

> In small examples like this it's clear what's going on. In larger ones
> (like basic_fstream) it's much easier to lose track of the default
> arguments. On the other hand, repeating default arguments (or mentioning
> them in the description) means that the same information is presented
> twice, leading to the same kind of maintenance problems as having two
> functions in your program that are supposed to do the same thing: it's
> easy to change one and forget about the other.

I'm not sure what your argument is here.  If you are saying that the
default arguments shouldn't be repeated so that there is isn't
duplication, I would disagree because the parameter types and names
have to be duplicated anyway.  If you are saying that the repetition
*has* led to an error in this case, I would agree that this seems to
be a reasonable explanation.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Ben Hutchings <do-not-spam-benh@bwsint.com>
Date: Thu, 1 Apr 2004 16:10:36 +0000 (UTC)
Raw View
[ Note: Forwarded to C++ Committee. -sdc ]

The second parameters of the non-default constructor and of the open
member function for basic_fstream, named "mode", are optional
according to the class declaration in 27.8.1.11 [lib.fstream].  The
specifications of these members in 27.8.1.12 [lib.fstream.cons] and
27.8.1.13 lib.fstream.members] disagree with this, though the
constructor declaration has the "explicit" function-specifier implying
that it is intended to be callable with one argument.


[ 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.jamesd.demon.co.uk/csc/faq.html                       ]