Arduino: File base class needed for Arduino

[PaulStoffregen]

Arduino needs a File (and maybe a Dir) base class, similar to Stream, Print, Client & Server, so that libraries which actually use files can be given a hardware-neutral File object. Ideally, a library like a JPEG decoder would be able to use a File from SPIFFS or SD or Bridge or USB Host Shield or any other library which provides access to files.

As mentioned on #2281, here is a new issue to discuss how this might be achieved. Ideally, Arduino's core libraries for AVR, SAM, SAMD, and ESP8266 & ESP32, and Teensy, ChipKit, Photon & Energia could all use this same File base class, as we all currently do with Print & Stream, so that users of all our platforms can have File providing and File using libraries "just work". :-)

[tofrnr]

I would appreciate more to have a FILE* base instead which is cstdio compatible (for SD file system and stream) and decline and deprecate all Arduino "File" bucklings for the future.

[tonton81]

+1 for File and Dir class :)

[PaulStoffregen]

Just wanted to follow up regarding the idea to implement File more efficiently (mentioned on the Arduino dev mail list). Is this github issue ok to discuss, or should we use the Arduino dev list?

Even if virtual functions and polymorphism are used, we really do need a File (and maybe Dir) base class in Arduino, so libraries using File can work with any other library providing File.

[devyte]

It is ok to discuss here. Actually, the ball is in my court atm, I have been asked to provide an outline for a templated design. I already have an ongoing discussion with a work collegue, and I have an idea of what it should look like.
About a base class, you're making the same mistake others make, by thinking that a base class would make File usable by others. In the template world, it is the interface that is important (I.e.: how is the class meant to be used), as opposed to who its ancestor is (what the class is).

[earlephilhower]

Love the idea of defining an interface, but Stream and Print are presently full classes, not templates. Would File being a template change the way folks would have to use it (vs. what they have to do today w/a Stream where they just subclass and implement the overrides)?

[PaulStoffregen]

I hope you'll also consider whether templates really offer performance improvement over "devirtualization" by the compiler. On Teensy, we've found the gcc 5.4 does a good job of removing the vtable overhead when the constructors are defined with "constexpr".

[drmpf]

I would also vote for a non-template solution.
C++ templates quickly become un-readable/un-usable for a novice (like
myself)
and so would not fit with Arduino as a 'beginner's'  micro.

On 30/01/2018 2:23 PM, Paul Stoffregen wrote:
>

I hope you'll also consider whether templates really offer performance
improvement over "devirtualization" by the compiler. On Teensy, we've
found the gcc 5.4 does a good job of removing the vtable overhead when
the constructors are defined with "constexpr".

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/4201#issuecomment-361464972,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFq3-bOK00MMKFyymOGbTIFIV3dqVUy_ks5tPos8gaJpZM4RlW4R.

[PaulStoffregen]

Any progress or news to share on the alternative to polymorphism?

I don't want to be impatient. Arduino has used the same File class in SD & Bridge for years. A few weeks is not much time by comparison. But I am hoping we can move forward this month (February 2018) with something. Personally, I am ok with polymorphism & virtual functions if something better is not found.

[PaulStoffregen]

Are you still working on the a non-polymorphism approach? If not, maybe it's time to start trying to move forward with the traditional Arduino polymorphism way?

[devyte]

Yes, it hasn't been dropped. I had an extended trip, so there was a pause, but I'll be working on it again this week.
Please don't become impatient. I think this is the first chance for a full redesign, and the only reason the discussion has come up is because of the many different filesystem implementations out there. If this is adopted, it could set a precedent for improved design guidelines for other Arduino objects.
Let's do things right.

[PaulStoffregen]

Any more progress on this?

While I want to be patient, soon I need to begin work on supporting USB memory sticks....

[PaulStoffregen]

Two months have passed, or close to 3 if counting from the beginning of the conversation on Arduino's developer mail list on December 28, 2017, though the suggestion to wait for coming up with a template-based approach started on January 19 and this issue was opened on January 20.

Now we're at March 21. Will you ever show us this template idea?

I want to begin really working on porting libraries in April. Is that too soon? Am I being unreasonable?

[Misiu]

@PaulStoffregen @devyte would this solve problem with name collision described here: https://github.com/esp8266/Arduino/issues/3819

[PaulStoffregen]

@Misiu - That only solves a small but important subset of the problem. You can include either of those in a sketch and use File. But you can't create a library that actually does something with File (eg, a JPEG decoder) that can accept any File. It's a good quick fix which allows many programs to compile with the existing libraries. But it's a poor long-term solution for the Arduino ecosystem.

[earlephilhower]

5525 implements a compatible File/Filesystem interface for SPIFFS and SD(SDFS) (and LittleFS in #5511).

When that lands, I think this can be closed.

[earlephilhower]

Closing since we now have SD, SDFS, SPIFFS, (and soon LittleFS) all using a common, compatible File class.