"Stanley Friesen [Contractor]" wrote:
>
> In article <t%Lm2.1024$Y6.1111@newscene.newscene.com>,
> Al Stevens <alstevens@midifitz.com> wrote:
> >
> >The examples in the document show a protected data member Container c; and
> >the text that explains the behavior of the public interface uses the c
> >object in its examples. I do not know whether this usage mandates that an
> >implementation must provide c or serves as an example.
>
> The latter only.  Not only is this only in an example, which in non-normative,
> but the overview section for the library specifically states that any private
> data member mentioned for library classes are for expository purposes only,
> and are not actually required.

Two points: this isn't in an example, and this isn't a private data
member. It's in the section defining the class interface, and it's a
protected data member.
---
[ 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              ]

Yes, but Container c is not shown as private.  It is shown as protected.  I
can't find anything in the standard which says it is only an example.

Stanley Friesen [Contractor] <stanley@West.Sun.COM> wrote in message
news:77irkr$37g@abyss.West.Sun.COM...
> Not only is this only in an example, which in non-normative,
>but the overview section for the library specifically states that any
private
>data member mentioned for library classes are for expository purposes only,
>and are not actually required.



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

Stanley Friesen [Contractor]<stanley@West.Sun.COM> wrote:
>Al Stevens <alstevens@midifitz.com> wrote:
>>
>>The examples in the document show a protected data member Container c; and
>>the text that explains the behavior of the public interface uses the c
>>object in its examples. I do not know whether this usage mandates that an
>>implementation must provide c or serves as an example.
>
>The latter only.  Not only is this only in an example, which in non-normative,
>but the overview section for the library specifically states that any private
>data member mentioned for library classes are for expository purposes only,
>and are not actually required.

False.  They appear in normative text, and they are not private.

Nonetheless, each entire adaptor is so trivial as to be "expository".
It's better to do your own than to derive from one that doesn't do
what you wan.t

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

AllanW@my-dejanews.com writes:

> Okay, I see 23.2.3.1 p1, 23.2.3.2 p1, and 23.2.3.3 p1, each with
> text showing public and protected elements of a container adaptor.
> All three have a protected element
>     Container c;
> and later paragraphs use c (for example, 23.2.3.2.1 p1 specifies that
> one of priority_queue's constructors calls c.begin(), c.end(), and
> comp, which is a protected Compare object).
>
> Is this normative? Throughout the standard, most of the fixed-font
> code snippets are not normative, so I kept expecting to see the
> words "Example" or "Note", or at least a comment along the lines of
> "//For exposition only" -- but this does not appear.
>
> Assuming it IS normative -- "c" was the best name they could come
> up with?

My interpretation is that it is normative: as you point out, there's
nothing in the standard to suggest otherwise.  And, of course, this is
user-visible, since users are permitted to inherit from standard
library classes.  In SGI's implementation those members are named 'c',
as the standard requires.

I don't think anyone intended for the names of those members to be
normative; I certainly don't remember any discussion of them in the
library working group.  I think this requirement just crept in.
---
[ 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 <t%Lm2.1024$Y6.1111@newscene.newscene.com>,
Al Stevens <alstevens@midifitz.com> wrote:
>
>The examples in the document show a protected data member Container c; and
>the text that explains the behavior of the public interface uses the c
>object in its examples. I do not know whether this usage mandates that an
>implementation must provide c or serves as an example.

The latter only.  Not only is this only in an example, which in non-normative,
but the overview section for the library specifically states that any private
data member mentioned for library classes are for expository purposes only,
and are not actually required.
---
[ 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              ]

<AllanW@my-dejanews.com> wrote:
>Okay, I see 23.2.3.1 p1, 23.2.3.2 p1, and 23.2.3.3 p1, each with
>text showing public and protected elements of a container adaptor.
>All three have a protected element
>    Container c; ...
>Is this normative? Throughout the standard, most of the fixed-font
>code snippets are not normative, so I kept expecting to see the
>words "Example" or "Note", or at least a comment along the lines of
>"//For exposition only" -- but this does not appear.
>
>Assuming it IS normative -- "c" was the best name they could come
>up with?

It's normative.  But the container adapters are just examples.
If one doesn't do _precisely_ what you want, copy the (inline)
implementation, rename it, and hack it into whatever shape
you like.

It's worth noting that protected data members are almost always
an indication of hasty design, this case not excepted.

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

I understand the basic principle of keeping adaptors (stacks, queues,
priority queues) simple, but why do they not have iterators?

Just about any container you'll use for one of these adaptors has an
iterator.  It's useful to be able to display the contents of an
adaptor for debugging, to be able to erase elements within the
adaptor, etc., or at least it would seem to be to me.  Is there some
reason I'm not seeing for not simply doing:

template <class Container>
class Stack
{
 public:
  typedef Container::iterator iterator;
  void erase(iterator iter)
    { baseContainer.erase(iter); }
 ...

};

Andrew Bell


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

Andrew Bell wrote:
>
> I understand the basic principle of keeping adaptors (stacks, queues,
> priority queues) simple, but why do they not have iterators?
>
> Just about any container you'll use for one of these adaptors has an
> iterator.  It's useful to be able to display the contents of an
> adaptor for debugging, to be able to erase elements within the
> adaptor, etc., or at least it would seem to be to me.  Is there some
> reason I'm not seeing for not simply doing:
>
> template <class Container>
> class Stack
> {
>         public:
>                 typedef Container::iterator iterator;
>                 void erase(iterator iter)
>                          { baseContainer.erase(iter); }
>         ...
>
> };

Generically, container adaptors need to keep their contents in a
particular order to work properly. I suspect that iterators were not
provided, in order to discourage people from mucking with the contents.
However, if you need to do so, one technique would be to derive your own
class from one of the standard adaptors. They each have a protected
member named c of type Container, and from the derived class you can get
access to it's iterators. I'd recommend against using any non-const
operations on those iterators; in paticular, don't erase elements!
---
[ 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              ]

Andrew Bell wrote:
>
> I understand the basic principle of keeping adaptors (stacks, queues,
> priority queues) simple, but why do they not have iterators?
>
> Just about any container you'll use for one of these adaptors has an
> iterator.  It's useful to be able to display the contents of an
> adaptor for debugging, to be able to erase elements within the
> adaptor, etc., or at least it would seem to be to me.  Is there some
> reason I'm not seeing for not simply doing:
>
> template <class Container>
> class Stack
> {
>         public:
>                 typedef Container::iterator iterator;
>                 void erase(iterator iter)
>                          { baseContainer.erase(iter); }
>         ...
>
> };
>

If you can erase things from the middle of a stack then it isn't a
stack, because it no longer promises LIFO access.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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              ]

Andrew Bell wrote:

> I understand the basic principle of keeping adaptors (stacks, queues,
> priority queues) simple, but why do they not have iterators?
>
> Just about any container you'll use for one of these adaptors has an
> iterator.  It's useful to be able to display the contents of an
> adaptor for debugging, to be able to erase elements within the
> adaptor, etc., or at least it would seem to be to me.

Then just use the containners directly and forget about the
adaptators. They don't provide additionnal services, then are
just there to express thongs such as 'I will only use this list
as a stack and you might change list to vector if it's more
efficient'.

Allowing iterators to escape completly breaks this property,
breaks the fact that only FIFO (resp FILO) access is allowed...

Or write your own adaptators, it's trivial.

The only problem I have with these adaptators is the lack
of typedef for their template parameters.

--

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              ]

In article <36994386.35E25ECC@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
[Explaining why adapters don't have iterators]
> However, if you need to do so, one technique would be to derive your own
> class from one of the standard adaptors. They each have a protected
> member named c of type Container, and from the derived class you can get
> access to it's iterators. I'd recommend against using any non-const
> operations on those iterators; in paticular, don't erase elements!

Is this a particular implementation? Or does the standard actually say
that the adaptors must have a protected member named c, which is the
underlying container?

(I don't have my standard near me today)

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

In article <36994386.35E25ECC@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
[Explaining why adapters don't have iterators]
> However, if you need to do so, one technique would be to derive your own
> class from one of the standard adaptors. They each have a protected
> member named c of type Container, and from the derived class you can get
> access to it's iterators. I'd recommend against using any non-const
> operations on those iterators; in paticular, don't erase elements!

Okay, I see 23.2.3.1 p1, 23.2.3.2 p1, and 23.2.3.3 p1, each with
text showing public and protected elements of a container adaptor.
All three have a protected element
    Container c;
and later paragraphs use c (for example, 23.2.3.2.1 p1 specifies that
one of priority_queue's constructors calls c.begin(), c.end(), and
comp, which is a protected Compare object).

Is this normative? Throughout the standard, most of the fixed-font
code snippets are not normative, so I kept expecting to see the
words "Example" or "Note", or at least a comment along the lines of
"//For exposition only" -- but this does not appear.

Assuming it IS normative -- "c" was the best name they could come
up with?

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

AllanW@my-dejanews.com wrote:
>
> In article <36994386.35E25ECC@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> [Explaining why adapters don't have iterators]
> > However, if you need to do so, one technique would be to derive your own
> > class from one of the standard adaptors. They each have a protected
> > member named c of type Container, and from the derived class you can get
> > access to it's iterators. I'd recommend against using any non-const
> > operations on those iterators; in paticular, don't erase elements!
>
> Is this a particular implementation? Or does the standard actually say
> that the adaptors must have a protected member named c, which is the
> underlying container?
>
> (I don't have my standard near me today)

The standard does specify a protected member named 'c'. It's unclear to
me whether that should be considered an implmentation example or an
actual requirement, but I think the latter. As an example, it would have
been more appropriate to make it private.


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

>Is this a particular implementation? Or does the standard actually say
>that the adaptors must have a protected member named c, which is the
>underlying container?

The examples in the document show a protected data member Container c; and
the text that explains the behavior of the public interface uses the c
object in its examples. I do not know whether this usage mandates that an
implementation must provide c or serves as an example.
---
[ 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              ]