Topic: Additional template parm to auto_ptr
Author: Jonathan Biggar <jon@floorboard.com>
Date: 1999/01/27 Raw View
Matt Austern wrote:
> In any case, the answer is that this is not conforming. Section
> 17.4.4.3, paragraph 3: "A global function cannot be declared by the
> implementation as taking additional default arguments."
>
> (Interestingly, though, 17.4.4.4, paragraph 2, says that member
> functions *are* allowed to have additional arguments with default
> values.)
My guess is that the standard says that because global functions with
extra default arguments would cause portability problems with overload
resolution vs user defined functions with the same name. This problem
doesn't occur with member functions.
--
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@localhost.localdomain.COM (Siemel Naran)
Date: 1999/01/27 Raw View
On 27 Jan 1999 17:00:11 GMT, Jonathan Biggar <jon@floorboard.com> wrote:
>Matt Austern wrote:
>> (Interestingly, though, 17.4.4.4, paragraph 2, says that member
>> functions *are* allowed to have additional arguments with default
>> values.)
>My guess is that the standard says that because global functions with
>extra default arguments would cause portability problems with overload
>resolution vs user defined functions with the same name. This problem
>doesn't occur with member functions.
I suppose this absence of problem is because you can't write functions
like this,
template <class Container>
void f(void (Container::*push_back(const int&));
// 'push_back' refers to the actual function Container::push_back
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Scott Meyers" <smeyers@aristeia.com>
Date: 1999/01/28 Raw View
Siemel Naran <sbnaran@localhost.localdomain.COM> wrote in message news:slrn7aul0p.6u8.sbnaran@localhost.localdomain...
>I suppose this absence of problem is because you can't write functions
>like this,
>
> template <class Container>
> void f(void (Container::*push_back(const int&));
> // 'push_back' refers to the actual function Container::push_back
I'll bite: why not?
Scott
Scott Meyers, Ph.D. Voice: 503/638-6028
Author: Effective C++ CD Fax: 503/638-6614
Effective C++ Email: smeyers@aristeia.com
More Effective C++ WWW: http://www.aristeia.com/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1999/01/29 Raw View
In article <36AF42A3.F0865714@floorboard.com>,
Jonathan Biggar <jon@floorboard.com> wrote:
>
> Matt Austern wrote:
> > In any case, the answer is that this is not conforming. Section
> > 17.4.4.3, paragraph 3: "A global function cannot be declared by the
> > implementation as taking additional default arguments."
> >
> > (Interestingly, though, 17.4.4.4, paragraph 2, says that member
> > functions *are* allowed to have additional arguments with default
> > values.)
>
> My guess is that the standard says that because global functions with
> extra default arguments would cause portability problems with overload
> resolution vs user defined functions with the same name. This problem
> doesn't occur with member functions.
Interesting. Once this section was pointed out to me, my take on
it was that code might use a pointer-to-function to call the global
function. But user code can't construct a pointer-to-function
unless it knows the number and types of the parameters and the
return type.
Of course, these same problems occur with pointer-to-member-function.
Perhaps that wasn't considered as critical?
----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1999/01/26 Raw View
In article <fxtaez7e0fg.fsf@isolde.engr.sgi.com>,
Matt Austern <austern@sgi.com> wrote:
> AllanW@my-dejanews.com writes:
>
> > > > Can an algorithm supply default parameters while still being
> > > > compliant?
> > >
> > > No. Only class templates may have default arguments, not function
> > > templates. Section 14.1, paragraph 9: "A default template-argument
> > > shall not be specified in a function template declaration or a
> > > function template definition, nor in the template-parameter-list of a
> > > member of a class template."
> >
> > That's not what I meant. Can an algorithm supply default function
> > parameter values while still being compliant? Such as pred or count
> > in the function prototype shown above.
>
> I don't see how it could, unless the template parameter were also
> defaulted (which would violate the rule in 14.1, paragraph 9). I
> don't see any way to declare such a default that is valid C++.
That paragraph still isn't about what I'm talking about. I don't
mean template parameters to template functions, I mean function
parameters.
In my example (which you removed) pred and count were not template
parameters, they were function parameters. Here's a better example
taken from the same library function, to demonstrate what I mean.
The standard specifies:
template<class ForwardIterator, class BinaryPredicate>
ForwardIterator adjacent_find(ForwardIterator first,
ForwardIterator last, BinaryPredicate pred);
Suppose that a compiler's library declared this function instead:
template<class ForwardIterator, class BinaryPredicate>
ForwardIterator adjacent_find(ForwardIterator first,
ForwardIterator last, BinaryPredicate pred,
int count=2);
The definition would search for COUNT objects in a row where pred
is true. When count==2 (the default), it would search for two
adjacent objects where pred(a,b) is true. When count==3 (which
cannot happen "by accident"), it would search for three adjacent
objects where pred(a,b) and pred(b,c) are both true. And so on.
Note that we've introduced a new function parameter with a
default value, but we have NOT introduced a new template
parameter at all (and thus not violated 14.1 p9).
Is it compliant? Anyone?
----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@dirac.ceg.uiuc.edu (Siemel Naran)
Date: 1999/01/26 Raw View
On 26 Jan 1999 18:17:33 GMT, AllanW@my-dejanews.com
> template<class ForwardIterator, class BinaryPredicate>
> ForwardIterator adjacent_find(ForwardIterator first,
> ForwardIterator last, BinaryPredicate pred,
> int count=2);
>Is it compliant? Anyone?
It's probably not compliant because one can write a function
template <class Iter, class Pred>
void f(Iter (*)(Iter,Iter,Pred,int));
Now your function 'adjacent_find' matches f(...), whereas it
should not. This is the same reasoning we used to rule
default template parameters as non-standard.
As for whether anyone is going to write functions like f(...),
I think the answer is #false. So default function and default
template arguments still seem reasonable to me.
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1999/01/27 Raw View
AllanW@my-dejanews.com writes:
> In my example (which you removed) pred and count were not template
> parameters, they were function parameters. Here's a better example
> taken from the same library function, to demonstrate what I mean.
>
> The standard specifies:
>
> template<class ForwardIterator, class BinaryPredicate>
> ForwardIterator adjacent_find(ForwardIterator first,
> ForwardIterator last, BinaryPredicate pred);
>
> Suppose that a compiler's library declared this function instead:
>
> template<class ForwardIterator, class BinaryPredicate>
> ForwardIterator adjacent_find(ForwardIterator first,
> ForwardIterator last, BinaryPredicate pred,
> int count=2);
Ah, sorry; I thought you were talking about defaulting the
function object pred in the example above.
In any case, the answer is that this is not conforming. Section
17.4.4.3, paragraph 3: "A global function cannot be declared by the
implementation as taking additional default arguments."
(Interestingly, though, 17.4.4.4, paragraph 2, says that member
functions *are* allowed to have additional arguments with default
values.)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1999/01/25 Raw View
AllanW@my-dejanews.com writes:
> > > Can an algorithm supply default parameters while still being
> > > compliant?
> >
> > No. Only class templates may have default arguments, not function
> > templates. Section 14.1, paragraph 9: "A default template-argument
> > shall not be specified in a function template declaration or a
> > function template definition, nor in the template-parameter-list of a
> > member of a class template."
>
> That's not what I meant. Can an algorithm supply default function
> parameter values while still being compliant? Such as pred or count
> in the function prototype shown above.
I don't see how it could, unless the template parameter were also
defaulted (which would violate the rule in 14.1, paragraph 9). I
don't see any way to declare such a default that is valid C++.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: dietmar.kuehl@claas-solutions.de
Date: 1999/01/24 Raw View
Hi,
In article <slrn7ac7mi.9h7.sbnaran@localhost.localdomain>,
sbnaran@uiuc.edu wrote:
> As an aside, why is there an ambiguity if auto_ptr has two template
> arguments, the second one defaulted? I think that the second f(...)
> should be chosen, no questions. The first one expects an auto_ptr
> with one template argument; the second one exepects an auto_ptr wiht
> two template arguments.
Well, this is what egcs reported when I tried certain combinations of the
functions. It at least made some sense to me: Both functions are equally good
matches, non is better to the other. Of course, my first idea ws that there is
actually no problem and I was somewhat surprised by the compiler message and
then just tried to make sense out of it...
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1999/01/20 Raw View
<Dietmar_Kuehl@my-dejanews.com> wrote:
> ncm@nospam.cantrip.org (Nathan Myers) wrote:
>> In general, it appears that implementers are allowed to add
>> extra defaulted parameters to standard class templates. Nobody
>> has yet identified any conforming program which compiles or runs
>> differently as a result of such an extension.
>
>... I proposed overloading of template
>functions taking template template arguments with different numbers of
>template arguments. ...:
>
> #include <iostream>
> #include <memory>
>
> template <template <typename T> tmpl>
> void f(tmpl<int> const &) { std::cout << "one argument\n"; }
> template <typename TT, template <typename T, typename S> tmpl>
> void f(tmpl<int, TT> const &) { std::cout << "two arguments\n"; }
>
> int main() { f(std::auto_ptr<int>(0)); }
>
>If this is legal C++, it would either produce a different result depending on
>the number of arguments or it would fail to compiler (due to an ambiguity
>between the two version of 'f()') if the 'auto_ptr' has an additional default
>argument.
I agree. I don't know, either, whether it's legal C++. A close
reading of the IS might tell us, if somebody wanted to essay it.
It might not, also; the text describing template template parameters
is pretty sketchy.
>> It's not clear you're doing your customers any favors, though, by
>> adding the parameter instead of providing a separate class.
>
>Well, it makes sharing code between different versions of the library
>easier. For example, I would expect that it is possible to add certain
>thread safety to IOStreams without changing most of the code. If I have
>to use two different classes for this, it is not possible to easily
>share the code (that is source sharing, because the instantiations would
>differ). Sharing of code has definitely advantages... (not only less work
>but also the code is normally more stable because it is "tested" by more
>users). --
Yes, for a large component like iostreams it would probably be better
to have a template parameter rather than to replicate the whole bloody
thing. For something like auto_ptr<>, though, the balance is clearly
in favor of replacement.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
Date: 1999/01/20 Raw View
AllanW@my-dejanews.com writes:
> In article <slrn79vl94.s0.sbnaran@localhost.localdomain>,
> sbnaran@uiuc.edu wrote:
> >
> > On 15 Jan 1999 22:20:15 GMT, Matt Austern <austern@sgi.com> wrote:
> >
> > >The *proposed* answer is yes. I believe it's universally accepted in
> > >the library working group that nothing in the standard explicitly says
> > >an implementor may provide extra (defaulted) parameters and that
> > >nothing explicitly says that an implementor may not. It's in keeping
> > >with the sort of freedom that implementors are already granted
> > >explicitly in Claus 17, but it seems to be a separate issue.
> >
> > Yes, this sounds reasonable. However, a conforming program should
> > not use these additional parameters, at least not directly.
>
> Correct. Source code that uses the extra parameters wouldn't be a
> conforming program.
>
> > So how does a conforming program use the additional parameters?
>
> It doesn't.
Then, how about the program provided by dietmar.kuehl ?
--
Gabriel Dos Reis, <dosreis@cmla.ens-cachan.fr>
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)
Date: 1999/01/20 Raw View
On 19 Jan 99 01:00:52 GMT, AllanW@my-dejanews.com
> sbnaran@uiuc.edu wrote:
>> On 15 Jan 1999 22:20:15 GMT, Matt Austern <austern@sgi.com> wrote:
>> >The *proposed* answer is yes. I believe it's universally accepted in
>> >the library working group that nothing in the standard explicitly says
>> >an implementor may provide extra (defaulted) parameters and that
>> >nothing explicitly says that an implementor may not. It's in keeping
>> >with the sort of freedom that implementors are already granted
>> >explicitly in Claus 17, but it seems to be a separate issue.
>> Yes, this sounds reasonable. However, a conforming program should
>> not use these additional parameters, at least not directly.
>
>Correct. Source code that uses the extra parameters wouldn't be a
>conforming program.
I read Dietmar Kuehl's demonstration that the extra parameter could
lead to non-conforming code. Suppose you write a function that
takes a template template parameter:
template <template <class,class> class Thing>
void function(Thing<int>);
The above declaration makes sense because class Thing could have a
default parameter, so it does not have to be declared with two
parameters in the function argument list. Eg,
std::vector<int> v;
function(v);
// calls function(Thing<int>)
// with Thing==std::vector
// and the unnamed parameters as T1==int and T2==std::allocator<int>
Now our class std::auto_ptr<T> should never be a candidate for
the above function because it has one template parameter.
Hence this call should fail:
std::auto_ptr<int> a;
function(a);
// calls function(Thing<int>)
// with Thing==std::auto_ptr
// and the unnamed parameters as T1==int and T2==???
No-one knows what the unnamed parameter T2 should be. But if a
certain implementation invested std::auto_ptr with a default
second parameter, then it would be a candidate for the function
'function' with T2 as the default parameter.
Here's an example that employs overloading to make unpredictable
programs. Note that this program is conforming, so it should
have predictable results:
template <template <class> class Thing>
void function(Thing<int>);
template <template <class,class> class Thing>
void function(Thing<int>);
int main() {
std::auto_ptr<int> a;
function(3,a);
}
Because std::auto_ptr has one template argument, it should not
match the second 'function'. So instead, it matches the first
function, with Thing==std::auto_ptr and T1==int.
But if std::auto_ptr has two template arguments, the second one
defaulted, then the second 'function' matches with
Thing==std::auto_ptr and T1==int, T2==__default.
>> So how does a conforming program use the additional parameters?
>
>It doesn't. The extra parameters are provided for reasons that do
>not affect conforming programs, such as:
>
> 1) Local extensions. These can make programs perform better and/or
> add additional features, at the cost of being non-conforming.
Please give an example.
> 2) Library use. The library might decide to implement class A in
> terms of class B, by giving class B an extra template parameter.
> The default value for this extra parameter causes class B to
> behave as documented in the standard; some different value
> causes it to behave the way class A would have acted.
Can one use a typedef?
namespace std {
template <class T, class X> class __auto_vector { ... };
struct __auto_ptr { ... };
template <class T> typedef auto_vector<T,__auto_ptr> auto_ptr;
}
Names beginning with one or two underscores are reserved for the
implementation, so conforming code should never use
"__auto_vector". Instead, clients will always use "auto_ptr",
and this meets the requirement of one template parameter.
Templated typedefs seem to be allowed by the BNF grammar, but
neither of my two compilers (egcs and como) allow it.
Incidentally, if the string returned by type_info::name() were
standardized, we would still not get predictable results. Eg,
typeid(std::auto_ptr<int>()).name()
could return "std::auto_ptr<int>" or
"std::__auto_vector<int,std::__auto_ptr>".
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1999/01/20 Raw View
In article <slrn7a7urt.buq.sbnaran@fermi.ceg.uiuc.edu>,
sbnaran@KILL.uiuc.edu wrote:
> On 19 Jan 99 01:00:52 GMT, AllanW@my-dejanews.com
> > sbnaran@uiuc.edu wrote:
> >> Yes, this sounds reasonable. However, a conforming program should
> >> not use these additional parameters, at least not directly.
> >
> >Correct. Source code that uses the extra parameters wouldn't be a
> >conforming program.
>
> I read Dietmar Kuehl's demonstration that the extra parameter could
> lead to non-conforming code. Suppose you write a function that
> takes a template template parameter:
> template <template <class,class> class Thing>
> void function(Thing<int>);
To be honest, I'm in slightly over my head, here. I've never used
the keyword "template" inside a template argument list; I didn't
even know it was legal.
> The above declaration makes sense because class Thing could have a
> default parameter, so it does not have to be declared with two
> parameters in the function argument list. Eg,
> std::vector<int> v;
> function(v);
> // calls function(Thing<int>)
> // with Thing==std::vector
> // and the unnamed parameters as T1==int and T2==std::allocator<int>
Would it be possible to do so without the nested "template"
keyword? Something like
template <class Thing>
void function(Thing<int>);
> Now our class std::auto_ptr<T> should never be a candidate for
> the above function because it has one template parameter.
> Hence this call should fail:
> std::auto_ptr<int> a;
> function(a);
> // calls function(Thing<int>)
> // with Thing==std::auto_ptr
> // and the unnamed parameters as T1==int and T2==???
> No-one knows what the unnamed parameter T2 should be. But if a
> certain implementation invested std::auto_ptr with a default
> second parameter, then it would be a candidate for the function
> 'function' with T2 as the default parameter.
Okay, I think I see how template<template...> works. New to me.
> Here's an example that employs overloading to make unpredictable
> programs. Note that this program is conforming, so it should
> have predictable results:
>
> template <template <class> class Thing>
> void function(Thing<int>);
>
> template <template <class,class> class Thing>
> void function(Thing<int>);
>
> int main() {
> std::auto_ptr<int> a;
> function(3,a);
> }
>
> Because std::auto_ptr has one template argument, it should not
> match the second 'function'. So instead, it matches the first
> function, with Thing==std::auto_ptr and T1==int.
>
> But if std::auto_ptr has two template arguments, the second one
> defaulted, then the second 'function' matches with
> Thing==std::auto_ptr and T1==int, T2==__default.
If this is true, then you have disproved my point. It seems
unlikely to happen in typical portable programs, but even one
counter-example proves that the idea isn't "invisible to the
user" as I had expected it to be.
> >> So how does a conforming program use the additional parameters?
> >
> >It doesn't. The extra parameters are provided for reasons that do
> >not affect conforming programs, such as:
> >
> > 1) Local extensions. These can make programs perform better and/or
> > add additional features, at the cost of being non-conforming.
>
> Please give an example.
Hypothetical example; I don't know of any implementation that does
this. The standard dictates that one of the overloaded versions of
transform() looks like this:
template<class InputIterator, class OutputIterator,
class UnaryOperation>
OutputIterator transform(
InputIterator first,
InputIterator last,
OutputIterator result,
UnaryOperation op);
Until you demonstrated the mistake, I had assumed that an
implementation would be able to satisfy this requirement with
an overloaded function like this:
template <class T> struct _no_op : public unary_function<T,T> {
T operator()(const T&t) const { return t; }
template<class InputIterator, class OutputIterator,
class UnaryOperation1, class UnaryOperation2)
OutputIterator transform(
InputIterator first,
InputIterator last,
OutputIterator result,
UnaryOperation1 op1,
UnaryOperation2 op2=_no_op<typename op1::result_type>);
Calling this with 5 parameters would invoke
*result = op2(op1(*element));
on each element in [first, last). This would make the program
non-compliant, but it might be useful for programs that do not
have to be portable. But, calling this with 4 parameters would
default to op2==_no_op, which would be equivalent to the
behavior documented in the standard.
The same thing could happen with additional function parameters
with default values. For instance, the standard calls for two
overloaded versions of adjacent_find:
template<class FwdIter>
adjacent_find(FwdIter i1, FwdIter i2);
template<class FwdIter,class BinPred>
adjacent_find(FwdIter i1, FwdIter i2, BinPred pred);
I had assumed that a library could satisfy this with one
version of adjacent_find with default parameters:
template<class FwdIter,class BinPred>
adjacent_find(
FwdIter i1,
FwdIter i2,
BinPred pred=equal_to<
typename iterator_traits<FwdIter>::value_type>,
int count=2);
Calling this with two arguments causes the algorithm to search for
two contiguous items that are equal, as required by the standard
for calls to adjacent_find() with two arguments. Calling it with
three arguments causes the algorithm to search for two contiguous
items where pred(first, second) is true, as required by the standard
for calls to adjacent_find with three arguments. Calling it with
four arguments allows the user to specify the number of "in-a-row"
items; for instance, we can find three 7's in a row. This is not
specified in the standard, so specifying it's value would make a
program non-compliant.
Can an algorithm supply default parameters while still being
compliant?
> > 2) Library use. The library might decide to implement class A in
> > terms of class B, by giving class B an extra template parameter.
> > The default value for this extra parameter causes class B to
> > behave as documented in the standard; some different value
> > causes it to behave the way class A would have acted.
>
> Can one use a typedef?
>
> namespace std {
> template <class T, class X> class __auto_vector { ... };
> struct __auto_ptr { ... };
> template <class T> typedef auto_vector<T,__auto_ptr> auto_ptr;
> }
>
> Names beginning with one or two underscores are reserved for the
> implementation, so conforming code should never use
> "__auto_vector". Instead, clients will always use "auto_ptr",
> and this meets the requirement of one template parameter.
I'm not an expert (obviously!), but to me this looks both
sensible and legal.
> Templated typedefs seem to be allowed by the BNF grammar, but
> neither of my two compilers (egcs and como) allow it.
Which doesn't mean too much yet. You don't consider either of these
compilers to be 100% conformant, do you?
> Incidentally, if the string returned by type_info::name() were
> standardized, we would still not get predictable results. Eg,
> typeid(std::auto_ptr<int>()).name()
> could return "std::auto_ptr<int>" or
> "std::__auto_vector<int,std::__auto_ptr>".
That's true, but I don't think we're ever going to standardize
what the names look like. It's enough to specify that the names
are human-readable, consistent, and unambiguous. So long as all
auto_ptr's returned the same value, there would be no problem.
----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1999/01/21 Raw View
><Dietmar_Kuehl@my-dejanews.com> wrote:
>> template <template <typename T> tmpl>
>> void f(tmpl<int> const &) { std::cout << "one argument\n"; }
>> template <typename TT, template <typename T, typename S> tmpl>
>> void f(tmpl<int, TT> const &) { std::cout << "two arguments\n"; }
>>
>> int main() { f(std::auto_ptr<int>(0)); }
>>
>>If this is legal C++, it would either produce a different result depending on
>>the number of arguments or it would fail to compiler (due to an ambiguity
>>between the two version of 'f()') if the 'auto_ptr' has an additional default
>>argument.
As an aside, why is there an ambiguity if auto_ptr has two template
arguments, the second one defaulted? I think that the second f(...)
should be chosen, no questions. The first one expects an auto_ptr
with one template argument; the second one exepects an auto_ptr wiht
two template arguments.
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1999/01/21 Raw View
AllanW@my-dejanews.com writes:
> I had assumed that a library could satisfy this with one
> version of adjacent_find with default parameters:
>
> template<class FwdIter,class BinPred>
> adjacent_find(
> FwdIter i1,
> FwdIter i2,
> BinPred pred=equal_to<
> typename iterator_traits<FwdIter>::value_type>,
> int count=2);
>
> Calling this with two arguments causes the algorithm to search for
> two contiguous items that are equal, as required by the standard
> for calls to adjacent_find() with two arguments. Calling it with
> three arguments causes the algorithm to search for two contiguous
> items where pred(first, second) is true, as required by the standard
> for calls to adjacent_find with three arguments. Calling it with
> four arguments allows the user to specify the number of "in-a-row"
> items; for instance, we can find three 7's in a row. This is not
> specified in the standard, so specifying it's value would make a
> program non-compliant.
>
> Can an algorithm supply default parameters while still being
> compliant?
No. Only class templates may have default arguments, not function
templates. Section 14.1, paragraph 9: "A default template-argument
shall not be specified in a function template declaration or a
function template definition, nor in the template-parameter-list of a
member of a class template."
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@localhost.localdomain.COM (Siemel Naran)
Date: 1999/01/21 Raw View
On 21 Jan 99 04:33:03 GMT, Matt Austern <austern@sgi.com> wrote:
>AllanW@my-dejanews.com writes:
>> Can an algorithm supply default parameters while still being
>> compliant?
>No. Only class templates may have default arguments, not function
>templates. Section 14.1, paragraph 9: "A default template-argument
>shall not be specified in a function template declaration or a
>function template definition, nor in the template-parameter-list of a
>member of a class template."
Indeed, the standard says this. But default arguments for function
templates should be allowed because there is no reason to disallow
them. They might be useful in some cases too, but in the majority
of cases, template argument deduction would render them useless.
Bjarne Stroustrup assures us that this was an oversight and that a
bug defect is in the works. Here is a reference:
Re: Q: templates and default argument syntax
Author: Bjarne Stroustrup
Date: 1998/10/17
Forums: comp.lang.c++.moderated, comp.lang.c++, comp.std.c++
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1999/01/22 Raw View
In article <fxthftlemrz.fsf@isolde.engr.sgi.com>,
Matt Austern <austern@sgi.com> wrote:
> AllanW@my-dejanews.com writes:
>
> > I had assumed that a library could satisfy this with one
> > version of adjacent_find with default parameters:
> >
> > template<class FwdIter,class BinPred>
> > adjacent_find(
> > FwdIter i1,
> > FwdIter i2,
> > BinPred pred=equal_to<
> > typename iterator_traits<FwdIter>::value_type>,
> > int count=2);
> >
> > Calling this with two arguments causes the algorithm to search for
> > two contiguous items that are equal, as required by the standard
> > for calls to adjacent_find() with two arguments. Calling it with
> > three arguments causes the algorithm to search for two contiguous
> > items where pred(first, second) is true, as required by the standard
> > for calls to adjacent_find with three arguments. Calling it with
> > four arguments allows the user to specify the number of "in-a-row"
> > items; for instance, we can find three 7's in a row. This is not
> > specified in the standard, so specifying it's value would make a
> > program non-compliant.
> >
> > Can an algorithm supply default parameters while still being
> > compliant?
>
> No. Only class templates may have default arguments, not function
> templates. Section 14.1, paragraph 9: "A default template-argument
> shall not be specified in a function template declaration or a
> function template definition, nor in the template-parameter-list of a
> member of a class template."
That's not what I meant. Can an algorithm supply default function
parameter values while still being compliant? Such as pred or count
in the function prototype shown above.
----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1999/01/19 Raw View
In article <slrn79vl94.s0.sbnaran@localhost.localdomain>,
sbnaran@uiuc.edu wrote:
>
> On 15 Jan 1999 22:20:15 GMT, Matt Austern <austern@sgi.com> wrote:
>
> >The *proposed* answer is yes. I believe it's universally accepted in
> >the library working group that nothing in the standard explicitly says
> >an implementor may provide extra (defaulted) parameters and that
> >nothing explicitly says that an implementor may not. It's in keeping
> >with the sort of freedom that implementors are already granted
> >explicitly in Claus 17, but it seems to be a separate issue.
>
> Yes, this sounds reasonable. However, a conforming program should
> not use these additional parameters, at least not directly.
Correct. Source code that uses the extra parameters wouldn't be a
conforming program.
> So how does a conforming program use the additional parameters?
It doesn't. The extra parameters are provided for reasons that do
not affect conforming programs, such as:
1) Local extensions. These can make programs perform better and/or
add additional features, at the cost of being non-conforming.
2) Library use. The library might decide to implement class A in
terms of class B, by giving class B an extra template parameter.
The default value for this extra parameter causes class B to
behave as documented in the standard; some different value
causes it to behave the way class A would have acted.
----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: abrahams@spam.motu.com (David Abrahams)
Date: 1999/01/15 Raw View
On 14 Jan 99 17:15:28 GMT, Valentin Bonnard <bonnardv@pratique.fr>
wrote:
>Andrei Alexandrescu wrote:
>
>> Say I want to provide an auto_ptr implementation.
>> If I add a supplemental template parameter to auto_ptr and provide a default
>> for it, will that implementation be standard-compliant? Thanks.
>
>I think it's an open library issue. The proposed answer is no.
As far as I remember the answer is yes. At least that's one reason
I've always heard given that it is illegal to forward-declare things
in namespace std.
-D
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: dietmar.kuehl@claas-solutions.de
Date: 1999/01/15 Raw View
Hi,
In article <369EA448.6DC095D4@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> Valentin Bonnard wrote:
> > I think it's an open library issue. The proposed answer is no.
Hm... This would not be my preference: I was thinking to use an extra
template argument to allow the user selection of thread safe versions of the
template classes. Of course, it the resulting classes would be outside the
standard and it would thus also be possible to use for example a different
namespace instead. Maybe this this the better choice anyway (in some global
header a namespace alias chould then be selected to determine whether a
thread safe version is to be used....).
> Could a strictly conforming program detect the existence of the extra
> parameter (assuming it's name stays within the reserved namespace)? If
> not, the as-if rule cover it.#include <iostream>
I think this is a strictly conforming program (well, I'm not sure whether
'auto_ptr' is really declared in the header <memory> but everything else
should be OK):
#include <iostream>
#include <memory>
template <template <typename T> class tmpl>
void f(tmpl<int> const &) { std::cout << "one argument\n"; }
template <typename TT, template <typename T, typename S> class tmpl>
void f(tmpl<int, TT> const &) { std::cout << "two arguments\n"; }
int main()
{
f(std::auto_ptr<int>(0));
}
Unless it is prohibited to overload functions with template template
arguments differing in the number of template arguments, this code should
compile if 'auto_ptr' has only one template argument and it should either
write "two arguments" or fail to compile due to an ambiguity between the
first and the second version of 'f()' if 'auto_ptr' has a hidden template
argument with a default value. Unfortunately, I can't verify this with any
compiler I have available: Most compiler don't have support for template
template arguments and the one with this support (egcs) does what I expected
in the case of two arguments (ie. it produces an ambiguity error) but fails
to compile the code if there is only one template argument (it apparently
tries to use the two argument version of 'f()' for whatever reason in this
case). Maybe someone can come up with a better example (ie. one which shows
the difference with currently available compilers...). --
<mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1999/01/15 Raw View
abrahams@spam.motu.com (David Abrahams) writes:
> On 14 Jan 99 17:15:28 GMT, Valentin Bonnard <bonnardv@pratique.fr>
> wrote:
>
> >Andrei Alexandrescu wrote:
> >
> >> Say I want to provide an auto_ptr implementation.
> >> If I add a supplemental template parameter to auto_ptr and provide a default
> >> for it, will that implementation be standard-compliant? Thanks.
> >
> >I think it's an open library issue. The proposed answer is no.
>
> As far as I remember the answer is yes. At least that's one reason
> I've always heard given that it is illegal to forward-declare things
> in namespace std.
The *proposed* answer is yes. I believe it's universally accepted in
the library working group that nothing in the standard explicitly says
an implementor may provide extra (defaulted) parameters and that
nothing explicitly says that an implementor may not. It's in keeping
with the sort of freedom that implementors are already granted
explicitly in Claus 17, but it seems to be a separate issue.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1999/01/16 Raw View
James Kuyper <kuyper@wizard.net> wrote:
>Valentin Bonnard wrote:
>> Andrei Alexandrescu wrote:
>>
>> > Say I want to provide an auto_ptr implementation.
>> > If I add a supplemental template parameter to auto_ptr and provide a
>> > default for it, will that implementation be standard-compliant? Thanks.
>>
>> I think it's an open library issue. The proposed answer is no.
>
>Could a strictly conforming program detect the existence of the extra
>parameter (assuming it's name stays within the reserved namespace)? If
>not, the as-if rule cover it.
In general, it appears that implementers are allowed to add
extra defaulted parameters to standard class templates. Nobody
has yet identified any conforming program which compiles or runs
differently as a result of such an extension.
It's not clear you're doing your customers any favors, though, by
adding the parameter instead of providing a separate class. You
make it harder for them to tell what in your library is standard
and portable, and what is not, with no corresponding benefit.
(Certain unethical companies prefer it that way, of course.)
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@localhost.localdomain.COM (Siemel Naran)
Date: 1999/01/16 Raw View
On 15 Jan 1999 22:20:15 GMT, Matt Austern <austern@sgi.com> wrote:
>The *proposed* answer is yes. I believe it's universally accepted in
>the library working group that nothing in the standard explicitly says
>an implementor may provide extra (defaulted) parameters and that
>nothing explicitly says that an implementor may not. It's in keeping
>with the sort of freedom that implementors are already granted
>explicitly in Claus 17, but it seems to be a separate issue.
Yes, this sounds reasonable. However, a conforming program should
not use these additional parameters, at least not directly. Eg,
say we have this:
struct __extra { };
template <class T, class Extra=__extra>
class auto_ptr { };
It is not legal to write a program like this:
std::auto_ptr<int,int> k;
So then how do we use the additional parameters? I was thinking
of making a typedef, but this is not quite right.
typedef int std::__extra;
std::auto_ptr<int> k;
So how does a conforming program use the additional parameters?
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Dietmar_Kuehl@my-dejanews.com
Date: 1999/01/17 Raw View
Hi,
In article <77ojv6$205$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> In general, it appears that implementers are allowed to add
> extra defaulted parameters to standard class templates. Nobody
> has yet identified any conforming program which compiles or runs
> differently as a result of such an extension.
In another article to this newsgroup I proposed overloading of template
functions taking template template arguments with different numbers of
template arguments. However, I don't know whether this is indeed legal C++.
Basically it looks like this:
#include <iostream>
#include <memory>
template <template <typename T> tmpl>
void f(tmpl<int> const &) { std::cout << "one argument\n"; }
template <typename TT, template <typename T, typename S> tmpl>
void f(tmpl<int, TT> const &) { std::cout << "two arguments\n"; }
int main() { f(std::auto_ptr<int>(0)); }
If this is legal C++, it would either produce a different result depending on
the number of arguments or it would fail to compiler (due to an ambiguity
between the two version of 'f()') if the 'auto_ptr' has an additional default
argument.
> It's not clear you're doing your customers any favors, though, by
> adding the parameter instead of providing a separate class. You
> make it harder for them to tell what in your library is standard
> and portable, and what is not, with no corresponding benefit.
> (Certain unethical companies prefer it that way, of course.)
Well, it makes sharing code between different versions of the library easier.
For example, I would expect that it is possible to add certain thread safety
to IOStreams without changing most of the code. If I have to use two
different classes for this, it is not possible to easily share the code (that
is source sharing, because the instantiations would differ). Sharing of code
has definitely advantages... (not only less work but also the code is
normally more stable because it is "tested" by more users). --
<mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1999/01/18 Raw View
Siemel Naran<sbnaran@uiuc.edu> wrote:
>
>So how does a conforming program use the additional parameters?
It doesn't. If you use vendor extensions, your program is not portable
anyway, so why would you care if it conforms?
In practice, of course, we all use various extensions in real programs,
and the conscientious among us confine the non-conforming parts of our
programs to (more-or-less) easily-separable modules.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1999/01/14 Raw View
Andrei Alexandrescu wrote:
> Say I want to provide an auto_ptr implementation.
> If I add a supplemental template parameter to auto_ptr and provide a default
> for it, will that implementation be standard-compliant? Thanks.
I think it's an open library issue. The proposed answer is no.
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/01/15 Raw View
Valentin Bonnard wrote:
>
> Andrei Alexandrescu wrote:
>
> > Say I want to provide an auto_ptr implementation.
> > If I add a supplemental template parameter to auto_ptr and provide a default
> > for it, will that implementation be standard-compliant? Thanks.
>
> I think it's an open library issue. The proposed answer is no.
Could a strictly conforming program detect the existence of the extra
parameter (assuming it's name stays within the reserved namespace)? If
not, the as-if rule cover it.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Andrei Alexandrescu" <alexandrescua@micromodeling.com>
Date: 1999/01/13 Raw View
Hello,
Say I want to provide an auto_ptr implementation.
If I add a supplemental template parameter to auto_ptr and provide a default
for it, will that implementation be standard-compliant? Thanks.
Cheers,
Andrei
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1999/01/14 Raw View
In article <369ccf93.0@10.1.1.65>,
"Andrei Alexandrescu" <alexandrescua@micromodeling.com> wrote:
> Hello,
Hi!
> Say I want to provide an auto_ptr implementation.
Okay: "I want to provide an auto_ptr implementation."
...that was silly... :)
> If I add a supplemental template parameter to auto_ptr and provide a default
> for it, will that implementation be standard-compliant? Thanks.
Conforming code wouldn't use the additional parameter, so it would
always use your default. Assuming this works, conforming code
wouldn't be able to tell the difference -- so even if this isn't
explicitly allowed, it ought to be valid because of the as-if rule.
I think that this WOULD be standard-compliant.
> Cheers,
Was on NBC, but it's been cancelled. But check your listings for a
local station with syndicated reruns; in the greater Los Angeles
area, it's on KTLA channel 5 at night (I think about 11:00 PM).
---
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]