<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 7, 2012, at 2:26 PM, Derek Schuff <<a href="mailto:dschuff@google.com">dschuff@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">The problem is that fetching more data can cause the underlying structure (e.g. the storage pointer in the example) to be reallocated/resized. </blockquote><div><br></div><div>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.</div><br><blockquote type="cite">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'</blockquote><div><br></div><div>It means that the 'this' pointer is const qualified. Any additional semantics of the interface are convention up to the designer.</div><br><blockquote type="cite"><div>
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.</div></blockquote><div><br></div><div>Why?</div><div><br></div><div>-Jim</div><br><blockquote type="cite"><div>
<br><div class="gmail_quote">On Tue, Feb 7, 2012 at 12:30 PM, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br></div><div>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.</div>
<div><br></div><div>From an implementation detail point of view, consider the following contrived example:</div><div><br></div><div><div>$ cat foo.cpp</div><div><div><div>#include <iostream> </div>
<div>#include <vector> </div><div>class myClass { </div><div> unsigned *storage; </div>
<div>public: </div><div> myClass(unsigned *buffer) { storage = buffer; } </div><div> </div>
<div> void write(unsigned val) const { *storage = val; } </div><div> unsigned read() const { return *storage; } </div><div> void set(unsigned *buffer) { storage = buffer; } </div>
<div>}; </div><div> </div><div>void foo(const myClass *p) { </div>
<div> p->write(5); </div><div> std::cout << p->read() << std::endl; </div><div> p->write(4); </div>
<div> std::cout << p->read() << std::endl; </div><div> // Can't do this due to 'const' </div><div> // error: member function 'set' not viable: 'this' argument has type 'const myClass', but function is not marked const</div>
<div> //unsigned newbuf; </div><div> //p->set(&newbuf); </div><div>} </div>
<div> </div><div>int main(int argc, char *argv[]) { </div><div> unsigned val; </div>
<div> myClass X(&val); </div><div> foo(&X); </div><div>} </div></div></div><div>
$ clang++ foo.cpp -o foo</div><div><div>$ ./foo </div><div>5</div><div>4</div></div><div><br></div></div></div></div></blockquote></div></div>
</blockquote></div><br></body></html>