0.3.2から #include<LovyanGFX.h>の解釈経路が異なる場合がある about lovyangfx HOT 12 CLOSED

LovyanGFXでファイルシステム関連の機能を有効にしたい場合は、LovyanGFXより先にincludeをしておく必要があります。

#include <SD.h>          // SDを使いたい場合
#include <SPIFFS.h>      // SPIFFSを使いたい場合
#include <LovyanGFX.hpp> // 最後にLovyanGFXをincludeする

M5Stack.hにはSD.hのincludeが含まれているので、上記のSD.hをincludeするのと同様の効果があります。

何故こんなことになっているかというと…
描画ライブラリがファイルシステム(SD.h/SPIFFS.h等)に依存されると困る、という利用シーンがあるため、
"LovyanGFXより前にincludeされている場合に限り、FS関連機能をifdefで追加する" という方法にしたのです。
ご指摘の 0.3.2 より前のバージョンでは、 FS.h だけはincludeしていたのですが、
ArduinoESP32とは別のファイルシステムを使おうとした場合に FS.h が衝突を起こしたため、
このincludeも廃止する事にしました。

LovyanGFX内ではFS関連のincludeを書きたくないが、FS関連の機能は提供したい。
これをうまく解決する実装方法が他にないか…アイデア募集中です…

from lovyangfx.

なるほどそういう経緯でしたか。

解決案としては
ファイルシステム依存する部分はLGFX_Sprite自体のメソッドとして持たずに別クラス(friend classとする)、別ファイルとして分離 (SD用[A]、SPIFFS用[B]それぞれ) し LovyanGFX.h 内には含めない。
利用者側が明示的に A or B をインクルードして使用とかどうでしょ?

from lovyangfx.

@GOB52
やはりそういう形が素直になりますよね…。
ちゃんと分離するなら別クラスにすべき内容だとは思うのですが、出来ればLGFXのメソッドとして提供したい…と思っていまして…うむむ…。
ちなみに基底クラスの方にある drawJpgFile等のメソッドはファイルを分けて lgfx_filesystem_support.hpp にまとめています。（ちょっと奇抜な方法で有効化しています…）

from lovyangfx.

includeの仕方によらず型の情報が矛盾しないようにするためには別にする位しかないような気もします。

発端は自プロジェクトでのLovyanGFXのバージョンを0.2.7から0.3.4に上げた際に発生したクラッシュでした。(LGFX_Spriteのメソッド呼び出しで発生)
そこから発生バージョンの検証、再現するミニマムなコードの作成と検証を経て気がついた次第です。

メソッドとして提供を満たした上で型情報矛盾を起こさないような方策を、こちらでも研究してみますね。

from lovyangfx.

あぁ…そちらでも問題が発生してしまいましたか…。
LovyanGFX型の形がコンパイル単位で異なってしまうために、
派生クラスのLGFX_Spriteも その影響を受けてしまうのです…ね…。
致命的な問題であるとは認識しているのですが…さてどうしましょうか…

from lovyangfx.

@GOB52
developブランチを更新してみました。
従来はメンバとしてFileWrapperのインスタンスを保持していたのですが、これがヘッダのinclude状況によってインスタンスのサイズが変化してしまう原因になっていたので、ポインタの形でLGFXBaseクラスに持たせるようにしてみました。
とりあえずは これでコンパイル単位でインスタンスの形が異なってしまうという状況は避けられるのではないか…と…思います…。

from lovyangfx.

@lovyan03

develop版試してみました。 当方のクラッシュは起こらなくなりました。

が、依然経路の違いでLGFX_SpriteにcreateFromBmpFileを持った物と持っていない物の混在が生じます。
class内部のメソッドテーブルの相違によって予期せぬ挙動を引き起こしたりしませんかね?
仮想関数(vtable)ではないので大丈夫なのかしら。
C++詳細仕様にそこまで詳しくないのでにんともかんとも。

from lovyangfx.

はい、それに関しては確かに依然としてコンパイル単位でメソッドの有無が異なるという状態にはなりますが、リンカが調整してくれる部分なので大丈夫なはずです。

なお根本的な問題として「include順に依存して変化するクラス」というのがアウトという意見もあります…
ツライ…(:3 」∠)

from lovyangfx.

なるほど、その辺りの解決はうまくやってくれるんですね。

なお根本的な問題として「include順に依存して変化するクラス」というのがアウトという意見もあります…

エレガントな解法はないものかなぁ。

from lovyangfx.

そうですね…引数にSDやSPIFFSを要求する関数があるので難しいんですよね…
（M5DisplayやTFT_eSPIで実装されてるメソッドと同じものをLovyanGFXでも提供しようとしているため）

「LovyanGFX内ではSDやSPIFFSをincludeさせたくない」
「しかしSDやSPIFFSを引数に受け取るメソッドは提供したい」
要求自体が矛盾しているんですよね（汗

from lovyangfx.

@GOB52
この問題の修正を含む新しいリリース ver0.3.5を作成しました。
お時間あるときにお試し頂ければ幸いです。
よろしくお願いいたします～。

from lovyangfx.

@lovyan03
当方のプロジェクトにおけるハングが 0.3.5 にて解消されたことを確認いたしました。
リンクエラーの件でお騒がせしてすいません。
対応ありがとうございました!

from lovyangfx.