File base class needed for Arduino #4201
Comments
|
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. |
|
+1 for File and Dir class :) |
|
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. |
|
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. |
|
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)? |
|
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". |
|
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
<#4201 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFq3-bOK00MMKFyymOGbTIFIV3dqVUy_ks5tPos8gaJpZM4RlW4R>.
|
|
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. |
|
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? |
|
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. |
|
Any more progress on this? While I want to be patient, soon I need to begin work on supporting USB memory sticks.... |
|
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? |
|
@PaulStoffregen @devyte would this solve problem with name collision described here: #3819 |
|
@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. |
…rn SSL (#4273) BearSSL (https://www.bearssl.org) is a TLS(SSL) library written by Thomas Pornin that is optimized for lower-memory embedded systems like the ESP8266. It supports a wide variety of modern ciphers and is unique in that it doesn't perform any memory allocations during operation (which is the unfortunate bane of the current axTLS). BearSSL is also absolutely focused on security and by default performs all its security checks on x.509 certificates during the connection phase (but if you want to be insecure and dangerous, that's possible too). While it does support unidirectional SSL buffers, like axTLS, as implemented the ESP8266 wrappers only support bidirectional buffers. These bidirectional buffers avoid deadlocks in protocols which don't have well separated receive and transmit periods. This patch adds several classes which allow connecting to TLS servers using this library in almost the same way as axTLS: BearSSL::WiFiClientSecure - WiFiClient that supports TLS BearSSL::WiFiServerSecure - WiFiServer supporting TLS and client certs It also introduces objects for PEM/DER encoded keys and certificates: BearSSLX509List - x.509 Certificate (list) for general use BearSSLPrivateKey - RSA or EC private key BearSSLPublicKey - RSA or EC public key (i.e. from a public website) Finally, it adds a Certificate Authority store object which lets BearSSL access a set of trusted CA certificates on SPIFFS to allow it to verify the identity of any remote site on the Internet, without requiring RAM except for the single matching certificate. CertStoreSPIFFSBearSSL - Certificate store utility Client certificates are supported for the BearSSL::WiFiClientSecure, and what's more the BearSSL::WiFiServerSecure can also *require* remote clients to have a trusted certificate signed by a specific CA (or yourself with self-signing CAs). Maximum Fragment Length Negotiation probing and usage are supported, but be aware that most sites on the Internet don't support it yet. When available, you can reduce the memory footprint of the SSL client or server dramatically (i.e. down to 2-8KB vs. the ~22KB required for a full 16K receive fragment and 512b send fragment). You can also manually set a smaller fragment size and guarantee at your protocol level all data will fit within it. Examples are included to show the usage of these new features. axTLS has been moved to its own namespace, "axtls". A default "using" clause allows existing apps to run using axTLS without any changes. The BearSSL::WiFi{client,server}Secure implements the axTLS client/server API which lets many end user applications take advantage of BearSSL with few or no changes. The BearSSL static library used presently is stored at https://github.com/earlephilhower/bearssl-esp8266 and can be built using the standard ESP8266 toolchain.
|
Closing since we now have SD, SDFS, SPIFFS, (and soon LittleFS) all using a common, compatible File class. |
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". :-)
The text was updated successfully, but these errors were encountered: