[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.
Why?
-Jim
>
> 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