1

With C++ operator overloads, it is possible to create a class which emulates a pointer type, so I was experimenting with abstracting FILE read operations with this approach.

class FilePointer
{
    FILE* file;
    size_t position;
    FilePointer (FILE* file, size_t position)
    {
        this->file = file;
        this->position = position;
    };
    public:
    FilePointer (FILE* file)
    {
        this->file = file;
        this->position = 0;
    };
    FilePointer operator+ (size_t offset)
    {
        return FilePointer(file,position + offset);
    };
    FilePointer operator++ () // Prefix : ++FilePointer
    {
        position++;
        return *this;
    };
    FilePointer operator++ (int) // Postfix : FilePointer++
    {
        FilePointer before = *this;
        position++;
        return before;
    };
    FilePointer operator+= (size_t offset)
    {
        position += offset;
        return *this;
    };
    uint8_t operator* ()
    {
        fseek(file,position,SEEK_SET);
        Uint8 out;
        fread(&out,1,1,file);
        return out;
    };
    uint8_t operator[] (size_t offset)
    {
        return *(*this + offset);
    };

};

As can be seen in the above code snippet I was able to find out how to differentiate between the variations of increment operator so that given FilePointer f; f++ and ++f would behave intuitively.

What if I want to use this class for file writes, though? Currently I can grab a byte uint8_t something = f[0]; and it works, but if I want to "set" something, i.e. f[0] = 100;, the overloads as they are will not work for this.

Aside from whether or not this is "good practice" (though feel free to weigh in about that too), is there a way to implement this behavior in operator overloads for a class? 

uint8_t n = f[0];
n++;
f[0] = n;

Or, getting even fancier, something like this:

f[1]++;

One way I imagine it could be done is by implementing yet another class which represents a "dereferenced FilePointer", but was curious if it is possible to do with only the overloads in the FilePointer class itself.

rsethc
  • 2,485
  • 2
  • 17
  • 27
  • 4
    Fyi, ideally your `FilePointer operator++ () ` should return a reference to `*this`, not a copy. `FilePointer& operator++ ()`. Likewise with `operator +=`. There is [a very well done Q/A on stackoverflow](https://stackoverflow.com/questions/4421706/what-are-the-basic-rules-and-idioms-for-operator-overloading). Worth the read. – WhozCraig May 28 '19 at 16:38
  • 5
    Returning a proxy is the only way to do this: the `f[x]` expression will be evaluated first, and must evaluate to _something_ for which `f[x] = 100` or `++f[x]` or whatever makes sense. There's no way for the `operator[]` to know anything about the expression in which is is being invoked (apart from whether `f` is a const ref, or whatever) – Useless May 28 '19 at 16:39
  • You are aware of [this post](https://stackoverflow.com/questions/4421706/what-are-the-basic-rules-and-idioms-for-operator-overloading), are you? – πάντα ῥεῖ May 28 '19 at 16:47
  • 1
    It seems more practical to add iterator management rather than the [] management – bruno May 28 '19 at 16:47

2 Answers2

2

One way I imagine it could be done is by implementing yet another class which represents a "dereferenced FilePointer"

That's pretty much the only way to do it. It'd be an object of a "proxy type" that can be converted to uint8_t (possibly implicitly in a case like this, although in general I loath implicit conversions) but can also be assigned to.

It would have to be constructed with a FilePointer*, and be a friend so that it can invoke the appropriate "write" functionality.

It's going to be a bit minging, though, because it could become "dangling" very quickly, writing in the wrong place. You could also store the current position at the time the proxy object is constructed, and seek back to that position iff necessary at the time of writing. But all that seeking is not very performant.

Also reading one byte at a time is sloooooow.

Overall though your attempt is admirable, I would advise against the approach overall. You can at least wrap FILE* in a nice class that does fclose for you if it goes out of scope.

but was curious if it is possible to do with only the overloads in the FilePointer class itself.

I don't think so. Whatever you return from operator[] needs some magic state that can accept a value to "set" and connect to the FILE* machinery. Returning a uint8_t is simply never going to allow you to do that.

Hatted Rooster
  • 35,759
  • 6
  • 62
  • 122
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • 1
    @SombreroChicken :P – Lightness Races in Orbit May 28 '19 at 17:33
  • 1
    Makes a lot of sense, including about the performance. I usually would use the C standard file I/O directly (hence why you see `FILE*` within that class) and was just mainly curious in C++ what it would take to completely abstract away file I/O like this. I have basically no plan to actually use this in a production code base but it's neat to see what you can get away with in the language. – rsethc May 29 '19 at 02:23
0

Another approach to improve the performance of 1 character writes might be that your proxy file pointer is actually a buffer that collects a number of assignments somehow, and then spools them all to the file on destruction.

One thing to be aware of with the proxy approach is the caller could keep hold of a number of your proxy objects using auto or auto&, and attempt to update them out of order. I don't think there is an efficient way to resolve this issue.

Also, what about operator --? Though the c++ library does have the concept of one-way iterators. perhaps iterators are the better metaphor?

Gem Taylor
  • 5,381
  • 1
  • 9
  • 27