"Martin Sebor" <sebor@roguewave.com> wrote in message
news:39D3E857.37810475@roguewave.com...
> While it may not be explicitly prohibited, I disagree that it's a good
> idea -- doing so prevents explicitly instantiating the container on a
> type that lacks a default constructor (objects stored in the standard
> containers must satisfy the CopyConstructible and Assignable
> requirement, and some others in certain cases, but not necessarily the
> DefaultConstructible one).

This brings me to a question. Wouldn't it be nice if standard containers
specified which container member functions need various levels of support
from the element type?


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              ]

Andrei Alexandrescu <andrewalex@hotmail.com> wrote:
+ "Martin Sebor" <sebor@roguewave.com> wrote in message
+ news:39D3E857.37810475@roguewave.com...
+ > While it may not be explicitly prohibited, I disagree that it's a good
+ > idea -- doing so prevents explicitly instantiating the container on a
+ > type that lacks a default constructor (objects stored in the standard
+ > containers must satisfy the CopyConstructible and Assignable
+ > requirement, and some others in certain cases, but not necessarily the
+ > DefaultConstructible one).
+
+ This brings me to a question. Wouldn't it be nice if standard containers
+ specified which container member functions need various levels of support
+ from the element type?

Check out the latest version of SGI's STL, or any of the projects that
use it.  They've added "concept checks" that perform some compile-time
checks of, well, concepts.  For example, the vector<> declaration starts off

    template <class _Tp, class _Alloc = allocator<_Tp> >
    class vector : protected _Vector_base<_Tp, _Alloc>
    {
      // requirements:

        __STL_CLASS_REQUIRES(_Tp, _Assignable);

    .....
    };

After the preprocessor has its way with that last line, there are some
template instantiations that will fail to compile if the element type isn't
"Assignable".  The minor code generated by the checks should be elided by
any half-decent optimizing compiler.

Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

---
[ 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              ]

"Phil Edwards" <pedwards@dmapub.dma.org> wrote in message
news:8r3i7e$52r$1@dmapub.dma.org...
> Check out the latest version of SGI's STL, or any of the projects that
> use it.  They've added "concept checks" that perform some compile-time
> checks of, well, concepts.  For example, the vector<> declaration starts
off
>
>     template <class _Tp, class _Alloc = allocator<_Tp> >
>     class vector : protected _Vector_base<_Tp, _Alloc>
>     {
>       // requirements:
>
>         __STL_CLASS_REQUIRES(_Tp, _Assignable);
>
>     .....
>     };

Please reread my question. I was referring to the standard (not an
implementation), and I was asking for specifications at the member function
level, not at class level.


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              ]

Andrei Alexandrescu <andrewalex@hotmail.com> wrote:
+ "Phil Edwards" <pedwards@dmapub.dma.org> wrote in message
+ news:8r3i7e$52r$1@dmapub.dma.org...
+ > Check out the latest version of SGI's STL, or any of the projects that
+ > use it.  They've added "concept checks" that perform some compile-time
+ > checks of, well, concepts.  For example, the vector<> declaration starts
+ off
+ >
+ >     template <class _Tp, class _Alloc = allocator<_Tp> >
+ >     class vector : protected _Vector_base<_Tp, _Alloc>
+ >     {
+ >       // requirements:
+ >
+ >         __STL_CLASS_REQUIRES(_Tp, _Assignable);
+ >
+ >     .....
+ >     };
+
+ Please reread my question. I was referring to the standard (not an
+ implementation), and I was asking for specifications at the member function
+ level, not at class level.

Oh, I understood both of those points.  As to the first, my understanding
is that standardization is primarily supposed to codify existing practice.
This practice looks like a good place to start, and gives us (the community)
one data point as to an example implementation.

As to the second point... the SGI checks do indeed havesome checks at the
member function level.  I just picked the first check in the code that I
came to.  :-)


Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

---
[ 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              ]

In article <dil8zsdpvlv.fsf@isolde.research.att.com>,
  Matthew Austern <austern@research.att.com> wrote:
> the_wid@my-deja.com (Tom) writes:
>
> > I am unsure as to whether the standard forbids the use of incomplete
> > types as the template parameter in declarations of containers.
>
> It does.  17.4.3.6, paragraph 2, says that "In particular, the effects
> are indefined ... if an incomplete type (3.9) is used as a template
> argument when instantiating a template component."  Note that this
> applies to all standard library templates, not just to containers.
OK, what about another question that Tom asked:

> The standard defines the list::resize function like this:
>
> void resize(size_type sz, T c = T());
>
> STLport defines the list::resize function like this:
>
>   void resize(size_type __new_size, const _Tp& __x);
>   void resize(size_type __new_size) { this->resize(__new_size, _Tp());
> }
>
> So it goes for overloads instead of a default, which is fine by the
> standard

Is that in fact "fine by the standard?" Is an implementation allowed
change from a function with a default, to two overloaded functions
(leaving aside for a moment that "const T&" has different semantics from
"T").

--
Jim
This message was posted using plain text only.  Any hyperlinks you may
see were added by other parties without my permission.
I do not endorse any products or services that may be hyperlinked to
this message.


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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Hyslop wrote:
>
> In article <dil8zsdpvlv.fsf@isolde.research.att.com>,
>   Matthew Austern <austern@research.att.com> wrote:
...
> > The standard defines the list::resize function like this:
> >
> > void resize(size_type sz, T c = T());
> >
> > STLport defines the list::resize function like this:
> >
> >   void resize(size_type __new_size, const _Tp& __x);
> >   void resize(size_type __new_size) { this->resize(__new_size, _Tp());
> > }
> >
> > So it goes for overloads instead of a default, which is fine by the
> > standard
>
> Is that in fact "fine by the standard?" Is an implementation allowed
> change from a function with a default, to two overloaded functions
> (leaving aside for a moment that "const T&" has different semantics from
> "T").

17.4.4.4p2:
"An implementation can declare additional non-virtual member function
signatures within a class:
...
-- by replacing a member function signature with default values by two
or more member function signatures with equivalent behavior;"

In addition to being allowed, it's also a good idea: it means that if
_Tp doesn't have a default constructor, you can still use the version of
resize() that doesn't require one. The version which does is not
supposed to be instantiated unless it's actually used. Therefore, the
fact that it can't be instantiated doesn't prevent the use of
std::list<T>.

---
[ 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              ]

On Wed, 27 Sep 2000 17:01:51 CST, Jim Hyslop <jim.hyslop@leitch.com>
wrote:
>>
>> So it goes for overloads instead of a default, which is fine by the
>> standard
>
>Is that in fact "fine by the standard?" Is an implementation allowed
>change from a function with a default, to two overloaded functions
>(leaving aside for a moment that "const T&" has different semantics from
>"T").

Yes: 17.4.4.4 (using my new, unfortunately non-copy-and-paste (grrr)
standard).

This has the side effect that the types of all non-virtual standard
member functions are undefined, since implementers are allowed to add
as many default arguments as they like. This doesn't apply to virtual
or global functions though.

Tom

---
[ 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              ]

James Kuyper wrote:
>
> Jim Hyslop wrote:
> >
> > In article <dil8zsdpvlv.fsf@isolde.research.att.com>,
> >   Matthew Austern <austern@research.att.com> wrote:
> ...
> > > The standard defines the list::resize function like this:
> > >
> > > void resize(size_type sz, T c = T());
> > >
> > > STLport defines the list::resize function like this:
> > >
> > >   void resize(size_type __new_size, const _Tp& __x);
> > >   void resize(size_type __new_size) { this->resize(__new_size, _Tp());
> > > }
> > >
> > > So it goes for overloads instead of a default, which is fine by the
> > > standard
> >
> > Is that in fact "fine by the standard?" Is an implementation allowed
> > change from a function with a default, to two overloaded functions
> > (leaving aside for a moment that "const T&" has different semantics from
> > "T").
>
> 17.4.4.4p2:
> "An implementation can declare additional non-virtual member function
> signatures within a class:
> ...
> -- by replacing a member function signature with default values by two
> or more member function signatures with equivalent behavior;"
>
> In addition to being allowed, it's also a good idea: it means that if
> _Tp doesn't have a default constructor, you can still use the version of
> resize() that doesn't require one. The version which does is not
> supposed to be instantiated unless it's actually used. Therefore, the
> fact that it can't be instantiated doesn't prevent the use of
> std::list<T>.

While it may not be explicitly prohibited, I disagree that it's a good
idea -- doing so prevents explicitly instantiating the container on a
type that lacks a default constructor (objects stored in the standard
containers must satisfy the CopyConstructible and Assignable
requirement, and some others in certain cases, but not necessarily the
DefaultConstructible one).

Since default arguments are not considered during explicit instantiation
the function specified by the standard instantiates just fine (it is, of
course, still illegal to call the function without specifying the second
argument). You can still call the function so long as you provide a
value for the default argument.

Regards
Martin

---
[ 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              ]

I am unsure as to whether the standard forbids the use of incomplete
types as the template parameter in declarations of containers.

Consider:

struct A
{
 std::list<A> alist;
};

Now, the Dinkumware library shipped with MSVC kicks up an incomplete
type error, while STLport doesn't.

The standard defines the list::resize function like this:

void resize(size_type sz, T c = T());

STLport defines the list::resize function like this:

  void resize(size_type __new_size, const _Tp& __x);
  void resize(size_type __new_size) { this->resize(__new_size, _Tp());
}

So it goes for overloads instead of a default, which is fine by the
standard, but it also uses a const T& argument to allow it to work
with an incomplete type. Is this conforming? And if not, why does
resize require a T rather than a const T&. assign and the constructor
both use a const T& parameter - perhaps this is a defect? It is
certainly a nice feature to be able to declare a container of an
incomplete type with a conforming implementation with a high QOI.

Tom

---
[ 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              ]