openframeworks / openframeworks/openFrameworks
ofDirectory ofFile ofBuffer confusion
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 10.4k
- Forks
- 2.6k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 9
Description
Hi there,
I tried to load text files in some folder by using the ofDirectory -> ofFile -> ofBuffer chain but the buffer was always empty:
ofDirectory dir;
dir.open("folder");
dir.allowExt("txt");
dir.sort();
ofBuffer buffer = dir.getFile(0).readToBuffer();
ofLogVerbose("buffer") << buffer.getText(); //always empty
The file itself is just fine. If I open the file directly without ofDirectory it works. Or if I use ofBufferFromFile().
ofFile file;
file.open("folder/test.txt");
ofBuffer buffer = file.readToBuffer();
ofLogVerbose("text") << buffer.getText(); //works
ofBuffer buffer = ofBufferFromFile(dir.getFile(0).getAbsolutePath()); //works too
It also doesn't matter if I use readToFile() or pass the file into the constructor directly like in the examples ofBuffer buffer(file).
Additionally to this problem I think the naming is quite confusing. I expected sth. like ofFile::getBuffer() and only found ofFile::getFileBuffer() which returns some internal buffer format basic_filebuf<char>. The examples only shows ofBuffer buffer(file) which uses some indirect chained conversion (?). The filename <-> ofBuffer helper methods are really useful but maybe should also accept ofFiles and not just the path as a string.
I'm happy to work on this but would like to discuss it first.
Best,
Felix
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the reported ofDirectory, ofFile, and ofBuffer chain from the issue, then inspect the related APIs and their existing examples. Done means the directory-derived file loads text consistently with direct file loading, with the API behavior and naming concerns addressed or clearly separated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100