From: dave@boostpro.com   
      
   on Tue Oct 04 2011, nmm1-AT-cam.ac.uk wrote:   
      
   > Nobody claimed that it was difficult to use for that.  The evidence   
   > was that nobody other than you had found it very useful - after all,   
   > pretty well ALL it provides over basic C++ arrays is more control   
   > over allocation, and that's a negligible part of a serious multi-   
   > dimensional array class.   
      
   Meh.  It does what it does reasonably well.  I don't expect more of it.   
   I suppose if you're writing a heavy-duty matrix class, managing   
   underlying storage won't be a big part of what you do, but it's could   
   still be useful to leverage the built-in containers.   
      
   >>> It is extremely under-specified, and seriously ambiguous in a lot   
   >>> of important (if edge-case) aspects, even more than the C++ language.   
   >>   
   >> I think you are mistaken.  There are areas where C++03's library is   
   >> underspecified, but they're not the areas you're pointing at.   
   >   
   > Grrk.   
      
   ? translation please.   
      
   > While it's a hell of a lot better than C, POSIX or OpenMP, a lot of my   
   > queries "Is this practice explicitly defined or definitely   
   > unsupported" end up with the answer "Neither".  See below.   
      
   I looked below but didn't see.   
      
   >> In the case of containers, in C++03, copyability is always required of a   
   >> container's element type, and therefore any container operation is   
   >> allowed to make a copy.   
   >   
   > Even constant queries?   
      
   Yes.  Copying is a constant operation.   
      
   > Oh, come now!   
      
   ? QOI.  The standard is long enough; we don't need to spend words   
   forbidding implementors from doing things that no implementor in his   
   right mind would do anyway.   
      
   > Though I do accept that there is nothing that forbids those from doing   
   > that ....  That issue is serious enough in itself (see below about   
   > locks and RDMA).  I will expand my previous examples, as I am not sure   
   > they were clear enough.   
   >   
   > The sorting example relates to whether an argument passed to the   
   > comparison function may be a copy,   
      
   QOI.  No implementor in his right mind would make a copy solely for the   
   purposes of comparison.   
      
   > not whether copying is used for the actual rearrangement.  I don't   
   > particular care whether it can be or can't be - all I am saying is   
   > that it isn't specified, and does matter in practical programs.   
   >   
   > The lock and RDMA issue is that an object containing such a thing may   
   > be copied only at times the lock or memory is not in use.   
      
   Hm?  C++11 locks are move-only, i.e. can't be copied.  If you want to   
   prevent copying, use a move-only type.   
      
   > Very obviously to someone with suitable implementation experience,   
   > there are some operations that should never be called if they are in   
   > use, but there are lots of others where there is no obvious reason why   
   > not.  Let's say element 42 is in use, and I want to swap elements 13   
   > and 69, which are not.  Legal, illegal, or well, eagle?   
      
   Hm?  If you want to write a sort-RDMA algorithm that checks to see which   
   elements are "in use" and does something appropriate, be my guest.  I   
   don't think it's reasonable to expect std::sort to accomodate that sort   
   of check.   
      
   >> It depends what you're worried about.  If you're worried that your   
   >> objects may be copied, and you're using a component that requires your   
   >> object to be copyable, and you're not willing to trust your vendor's QOI   
   >> to avoid unnecessary copies, you'd better not use the standard library   
   >> at all.   
   >   
   > These issues matter for scientific computing,   
      
   Yes.  Copies take time and scientific computing can't afford to waste   
   time.   
      
   > a good half of which has used parallelism for a decade,   
      
   Yes.   
      
   > and the proportion is increasing - even simple MPI-1 non-blocking   
   > transfers bring in the RDMA issue.   
      
   I've done a little MPI programming, and am fairly sure that whatever   
   mechanism is used for messaging, be it RDMA or something else, that is   
   hidden under MPI's abstraction layer.   
      
   > But it's very serious even for non-scientific programming in C++11,   
   > because any clean threaded code is likely to want to use containers   
   > across threads, with synchronised rearrangement but unsynchronised   
   > access.  So where does the boundary lie?   
      
   Sorry, I don't even know what you're asking.   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ 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)