[llvm-commits] [llvm] r149918 - in /llvm/trunk: include/llvm/Bitcode/ include/llvm/MC/ include/llvm/Support/ lib/Bitcode/Reader/ lib/Bitcode/Writer/ lib/MC/MCDisassembler/ lib/Support/ lib/Target/ARM/Disassembler/ lib/Target/MBlaze/Disassembler/

Jim Grosbach grosbach at apple.com
Tue Feb 7 14:33:41 PST 2012

On Feb 7, 2012, at 2:26 PM, Derek Schuff <dschuff at google.com> wrote:

> The problem is that fetching more data can cause the underlying structure (e.g. the storage pointer in the example) to be reallocated/resized.

That's an implementation detail. It's the exposed interface of the class and the semantics associated that I'm concerned with. As a user of the class, I should neither know nor care what's inside or how it works. In this case, the semantics we want to be able to express are whether the consumer of a MemoryObject can change the underlying data (write to the memory/file/shared object) or not.

> MutableArrayRef type classes are basically just glorified pointers and designed not to own the data; but the data has to be owned by something accessible to MemoryObject, and MemoryObject::readBytes would have to call a non-const method on whatever does own it. The behavior you're describing is like a const pointer (const char* foo) but the 'const' qualifier on a method basically means 'const char* const foo'

It means that the 'this' pointer is const qualified. Any additional semantics of the interface are convention up to the designer.

> We could of course keep const on the methods and do our game-playing by making all the data members of the StreamableMemoryObject mutable, but that's worse (IMO) than just having another class that's like MemoryObject but doesn't derive directly from it.



> On Tue, Feb 7, 2012 at 12:30 PM, Jim Grosbach <grosbach at apple.com> wrote:
> Why can't a const StreamableMemoryObject read in more information to satisfy a request? As I understand it, 'const' there is saying that the data won't be modified and not necessarily anything about what actions need to be taken to read it.
> From an implementation detail point of view, consider the following contrived example:
> $ cat foo.cpp
> #include <iostream>                                                              
> #include <vector>                                                                
> class myClass {                                                                  
>   unsigned *storage;                                                             
> public:                                                                          
>   myClass(unsigned *buffer) { storage = buffer; }                                
>   void write(unsigned val) const { *storage = val; }                             
>   unsigned read() const { return *storage; }                                     
>   void set(unsigned *buffer) { storage = buffer; }                               
> };                                                                               
> void foo(const myClass *p) {                                                     
>   p->write(5);                                                                   
>   std::cout << p->read() << std::endl;                                           
>   p->write(4);                                                                   
>   std::cout << p->read() << std::endl;                                           
>   // Can't do this due to 'const'                                                
>   // error: member function 'set' not viable: 'this' argument has type 'const myClass', but function is not marked const
>   //unsigned newbuf;                                                             
>   //p->set(&newbuf);                                                             
> }                                                                                
> int main(int argc, char *argv[]) {                                               
>   unsigned val;                                                                  
>   myClass X(&val);                                                               
>   foo(&X);                                                                       
> } 
> $ clang++ foo.cpp -o foo
> $ ./foo 
> 5
> 4

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120207/5c34e153/attachment.html>

More information about the llvm-commits mailing list