c16db2ae   
   From: ulrich.eckhardt@dominolaser.com   
      
   Am 15.02.2012 22:35, schrieb P. Areias:   
   > There are classical confusions: why do you need .size()? I fail to see   
   > one application where it is needed (you have .start() and .finish()   
   > already don't you?).   
      
   Take a look at your own friendly operator<<. Also, imagine I needed to   
   convert this to a different container type, like e.g. a vector, which I   
   would like to allocate in advance to avoid reallocation and copying   
   repeatedly.   
      
      
   > There are also typical arguments for IO such as "This couples the   
   > container to one specific textual output format usable only in   
   > combination with std::iostreams" which contain two errors:   
   >   
   > 1) Really anything we may write is specific in one form. The data   
   > structure itself is specific.   
   > 2) Since it additionally uses an additional class, it does not   
   > preclude the client to use his own output function. It just provides a   
   > default function to write and read.   
      
   I understand the use of output for debugging, like e.g. Java's   
   toString() functions (If I remember the name correctly). However, input   
   is basically useless without a type that allows lossless roundtrip   
   conversions. As noted, std::string is not such a type, as an element   
   with a space inside will be considered as two elements when reading,   
   while the last element will be ignored and remain inside the input   
   buffer. This is the reason why serialization libraries exist, to make   
   such storage and retrieval correct, beyond the need to just dump   
   something to a stream for debugging purposes.   
      
   You are correct though, I can extend this to my delight. However, I   
   seriously question the use for the defaults you provide, because those   
   just don't work reliably. Let us agree to disagree on this point, it is   
   a matter of taste and a bit one of the specific requirements.   
      
      
   > The "range" constructors and other lacunae are just assumptions   
   > concerning what the client needs:   
   > "You **need** a range constructor but not IO!" What about a "sparse"   
   > constructor or a index-based constructor. Why stop with a range?   
      
   A range or sequence is an abstraction of a container. The content of any   
   container that supports traversal can be represented as a range. A   
   stream can be represented as a range. Also a sequence that is not stored   
   but computed on demand can be represented as a range. Providing a range   
   abstraction is one of the fundamental abstractions underneath the STL,   
   it allows you to write algorithms on top of a range and those algorithms   
   work regardless of where (or if) the underlying range is stored.   
      
      
   > 6)   
   > Further:   
   > - Missing swap().   
   >   
   > 6Ra) I don't need one.   
      
   Yes you need one in order to implement no-throw swap() for types   
   containing such a list. For any value type using dynamic allocation,   
   i.e. one where copying is both expensive and can fail, you basically   
   need a swap() implementation like you need a destructor or copy constructor.   
      
      
   > - Missing complexity guarantees/documentation.   
   >   
   > 6Rc) False. The **algorithm** has complexity guarantees not its   
   > implementation. It doesn't make sense to state that my AVL   
   > implementation has a lower access complexity than the one in the   
   > original paper. And there is documentation (not here of course...)   
      
   Your assignment has O(N+M) complexity for CPU and O(N) complexity for   
   memory. A version that is exception-safe will take O(N+M) of both CPU   
   and memory! Also, concerning the size, maintaining that size separately   
   will make retrieval an O(1) operation, otherwise it becomes an O(N)   
   operation.   
      
      
   Most of my objections to your container are a matter of style. As   
   mentioned above, we can simply disagree based on our personal   
   preferences. There are things though that are harder to argue against,   
   and those are about correctness, i.e. the actual bugs I pointed out.   
   There, the C++ standard library leaves you in the dust, because there   
   are multiple independent implementations that have proven their   
   stability in many different applications. Also, there are many useful   
   abstractions in the STL that allow writing code that simply can't be   
   written as elegantly and easily with your approach.   
      
   Sorry, I'm still not convinced.   
      
   Uli   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)