Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #7618

Re: Deriving from concrete types like std::list

Followups directed to: comp.lang.c++

Show all headers | View raw

Alexander Bartolich wrote:

> Kai-Uwe Bux wrote:
>> [...]
>> I do not understand the phrase "deduce the behavior of the class from its
>> methods alone". What I can  see is that the implementation via derivation
>> from std::list< Stmt* > prevents StmtList from imposing any sort of
>> restriction on the content of the list of statements that is considered
>> allowed: client code can append and erase in the list at will. What I
>> fail to see is why that is wrong.
> 
> Oh. That's fundamental. *scratches-head*
> Well, let's say that somewhere in your program you have the line
> 
>   theStmtList->push_back(foo_stmt);
> 
> and a few thousand lines away you have
> 
>   theStmtList->push_back(bar_stmt);
> 
> Well, actually you have lot's of those lines. In a lot of different
> places. But that's OK, you have it under control. Until one day your
> program crashes because a stupid user dared to insert an invalid
> statement instance. So you add error checking.
> 
>   if (theStmtList->isValid(foo_stmt))
>     theStmtList->push_back(foo_stmt);
>   else
>     theStmtList->error("Your foo_stmt stinks.");
> 
> Problem is, your program still crashes. Because you forgot to fix
> all occurences of that push_back. Fortunately your editor can search
> strings across all source files. No problem.
> 
> A few months later the program starts to crash again. What happened?
> Well, the new team member added a few push_back of his own, but
> without error handling. Turns out that the documentation of StmtList
> was never updated to include the requirement of calling isValid.
> 
> ...
> 
> A few years later, after lots of changes to validation and error
> handling, the documentation is still outdated, and your code is an
> inconsistent mess. Some parts use the new error handling, other
> parts the old version, and there are also places where the error
> handling itself is erroneous. You know you should really have
> consolidate this years ago, but now it's too late.

You have a point. What you say is that _very_ likely one would want 
additional restrictions on the content (which std::list< Stmt* > cannot 
enforce). In this particular case, I can sympathise with that: I would 
conjecture that null pointers are _not_ allowed in a StmtList. Such a 
constraint is not enforced by StmtList as it stands.


>>> [...]
>>> The second argument is not so nice: your code does not actually work.
>>> That is, your claim that »a statement list *is* a list« is false.
>>> Hint: how many methods of std::list are declared virtual?
>>
>> No methods in std::list< Stmt* > are virtual. But how would that
>> matter? In the code shown, there is no attempt at overriding any
>> of them.
> 
> Oh. That's also fundamental. Let's say you have
> 
>   void foo(std::list<Stmt*>* myList)
>   {
>     // ...
>     delete myList;
>   }
> 
> What happens when you pass an instance of StmtList to foo?

UB.

> What can you do that programmers working with your code do not fall
> into this trap?

You document it - just as the many instances of UB in the standard library.

> What exactly is the advantage of your design, if you cannot actually
> use instances of StmtList in place of std::list<Stmt*>?

Actually, you can. E.g.:

  void clear_list ( std::list< Stmt* > & stmt_list ) { ... }
  ...
  StmtList stmt_list;
  ...
  foo( stmt_list );

What is UB is just deleting a StmtList* through std::list< Stmt* >*. The 
claim that, therefore, you cannot use instances of StmtList in place of 
std::list< Stmt* > is too strong.

Whether the restriction on deletion is a serious matter depends very much on 
local coding guidelines and code base.


Best,

Kai-Uwe Bux

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Deriving from concrete types like std::list Urs Thuermann <urs@isnogud.escape.de> - 2011-07-07 14:02 +0200
  Re: Deriving from concrete types like std::list Leigh Johnston <leigh@i42.co.uk> - 2011-07-07 14:04 +0100
  Re: Deriving from concrete types like std::list Alexander Bartolich <alexander.bartolich@gmx.at> - 2011-07-07 13:42 +0000
    Re: Deriving from concrete types like std::list Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-07-07 22:23 +0200
      Re: Deriving from concrete types like std::list Alexander Bartolich <alexander.bartolich@gmx.at> - 2011-07-07 22:04 +0000
        Re: Deriving from concrete types like std::list Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-07-08 01:16 +0200
    Re: Deriving from concrete types like std::list red floyd <redfloyd@gmail.com> - 2011-07-08 11:23 -0700
      Re: Deriving from concrete types like std::list "Balog Pal" <pasa@lib.hu> - 2011-07-08 20:30 +0200
        Re: Deriving from concrete types like std::list "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-07-08 21:16 +0200
        Re: Deriving from concrete types like std::list red floyd <redfloyd@gmail.com> - 2011-07-08 14:53 -0700
          Re: Deriving from concrete types like std::list "Balog Pal" <pasa@lib.hu> - 2011-07-09 10:33 +0200
            Re: Deriving from concrete types like std::list Leigh Johnston <leigh@i42.co.uk> - 2011-07-09 10:59 +0100
  Re: Deriving from concrete types like std::list "Bo Persson" <bop@gmb.dk> - 2011-07-07 19:12 +0200
  Re: Deriving from concrete types like std::list "MikeP" <mp011011@some.org> - 2011-07-07 15:51 -0500

csiph-web