🚀 go-pugleaf

In article 41o@news.rwth-aachen.de, fischer@Informatik.RWTH-Aachen.DE (Rainer Fischer) writes:
>In "Bjarne Stroustrup, The C++ programming language (german translation)"
>I found an example, which looks like this:
>
>struct base {
>  base *next;
>  static base *list;
>
>  base() {next = list; list = this};
>
>  virtual void function() = 0;
>  // ...
>};
>
>class derived : public base {
>  // ...
>public:
>  void function();
>  // ...
>};
>
>
>Two questions:
>
>1)  Does function() in class derived really override function() in base?

Yes.

>    Does the declaration in derived really say that function is not pure
>    virtual and not virtual at all? 

Yes, No. Since it has the same signature as a base-class virtual function,
it overrides that function and is virtual. That is, the derived-class
version is virtual whether you declare it virtual explicitly or not. It is
not pure virtual because it does not have "=0" as part of the declaration.

>    I get a linker error-message, when I
>    use such a construction without defining the overriding function, but
>    neither a compiler error nor a warning. Is this correct?

Yes. If you declare a non-pure virtual function, most implementations
require you to define it whether you call the function or not. The lack
of a definition is typically found during (one of) the linking phase(s).


>2)  What happens, when the very first object is created with a class
>    derived from base? The constructor of base assignes list to next, but
>    list is not yet initialized; so rubbish may be assigned to next. Is
>    there no need to initialize list first, e.g. base *base::list = 0; some-
>    where outside of base?

A static data member of a class requires a separate definition outside
the class. (The declaration inside the class is not a definition.)

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

fischer@Informatik.RWTH-Aachen.DE (Rainer Fischer) wrote:

>In "Bjarne Stroustrup, The C++ programming language (german translation)"
>I found an example, which looks like this:

>struct base {
>  base *next;
>  static base *list;

>  base() {next = list; list = this};

>  virtual void function() = 0;
>  // ...
>};

>class derived : public base {
>  // ...
>public:
>  void function();
>  // ...
>};


>Two questions:

>1)  Does function() in class derived really override function() in base?
>    Does the declaration in derived really say that function is not pure
>    virtual and not virtual at all? I get a linker error-message, when I
>    use such a construction without defining the overriding function, but
>    neither a compiler error nor a warning. Is this correct?

I'm not totally sure what you are asking here, but it all looks OK.

The virtualness of function is inherited from base. It perhaps  makes
the code easier to understand if the virtual keyword is added to
derived.

>2)  What happens, when the very first object is created with a class
>    derived from base? The constructor of base assignes list to next, but
>    list is not yet initialized; so rubbish may be assigned to next. Is
>    there no need to initialize list first, e.g. base *base::list = 0; some-
>    where outside of base? I get a compiler error, if I don't do it.

You should get a linker error rather than a compiler error if you
don't.

>Thanks in advance for any help,

>Rainer Fischer.
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

According to _STL Tutorial and Reference Guide_ by Musser and Saini
(a very good book, btw), the following functions are defined:

template <class T> void vector<t>::pop_back();
template <class T> void deque<t>::pop_back();
template <class T> void deque<t>::pop_front();
template <class T> void list<t>::pop_back();
template <class T> void list<t>::pop_front();

Other classes may have pop functions, I dunno.

Why don't the pop functions return a copy of the object before they
blow it away? Another possibility, I suppose, would be an auto_ptr<T>
so that the object is deleted if it's not used. An auto_ptr<T> is
about as efficient as deleting it in the pop function, it just changes
the time it's deleted (which isn't guaranteed anywhere I've read
anyway).

Why call the methods push and pop if it doesn't act like a stack?

It's not really a big deal (it's easy enough to write my own adapter).
I'm just curious.

	Thanks,

	Hayden Schultz
	Ptech, Inc.
	haydens@tiac.net
	hayden@ptechinc.com
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

In article <313BD2CA.7DBD@tiac.net> Hayden Schultz <haydens@tiac.net>
writes:

|> According to _STL Tutorial and Reference Guide_ by Musser and Saini
|> (a very good book, btw), the following functions are defined:

|> template <class T> void vector<t>::pop_back();
|> template <class T> void deque<t>::pop_back();
|> template <class T> void deque<t>::pop_front();
|> template <class T> void list<t>::pop_back();
|> template <class T> void list<t>::pop_front();

|> Other classes may have pop functions, I dunno.

|> Why don't the pop functions return a copy of the object before they
|> blow it away? Another possibility, I suppose, would be an auto_ptr<T>
|> so that the object is deleted if it's not used. An auto_ptr<T> is
|> about as efficient as deleting it in the pop function, it just changes
|> the time it's deleted (which isn't guaranteed anywhere I've read
|> anyway).

I suspect that no copy is returned because of performance reasons: to
return one would require making the copy in every case (whether it was
used or not), then destructing it.

I don't understand the remark concerning auto_ptr.  In order to return
an auto_ptr to the object, it would be necessary to allocate a new
copy of the object on the stack, then delete it.

I suppose some sort of intelligent reference could be returned, which
would destruct the object whenever it was destructed.  This might
still cause problems freeing the memory; I suppose that they would be
solvable.

But is it worth it?

|> Why call the methods push and pop if it doesn't act like a stack?

That is the real question.  A list is not a stack.  A deque is not a
stack.  A vector is not a stack.  The functions pop_front and pop_back
have nothing to do with the operation pop on a stack.  This is why it
is not worth the bother of having them return a value.  This is also
why it probably would have been better if they'd have had another
name. 
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

Hi,

Hayden Schultz (haydens@tiac.net) wrote:
: Why don't the pop functions return a copy of the object before they
: blow it away?

These containers are simply not intended to be used as stack (or queue)
directly. Instead, you can use 'stack<Container<T> >' or
'queue<Container<T> >' to use the class 'Container' as stack (or
queue). These adaptors can be implemented in terms of 'push_back()' and
'pop_back()'. However, 'stack<...>::pop()' also returns 'void'. The
reason is simple: If you need the value, you can get it with a sequence
of 'top()' and 'pop()' operations. Requiring that 'pop()' returns an
object would make it necessary to create this object which in turn can
be expensive. This way it is defined everything is possible
efficiently.

: Another possibility, I suppose, would be an auto_ptr<T>
: so that the object is deleted if it's not used. An auto_ptr<T> is
: about as efficient as deleting it in the pop function, it just changes
: the time it's deleted (which isn't guaranteed anywhere I've read
: anyway).

Note, that STL containers in general store objects, not pointers.
Returning an 'auto_ptr<T>' would require that pointers are stored. This
is inefficient e.g. if you want to store 'int's.

: Why call the methods push and pop if it doesn't act like a stack?

These functions are e.g. used to implement a stack adapter which acts
like a stack or a queue.
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.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 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]