いいたいことをズバズバ言えないつらさですな。
プアな環境でも、連結リストやハッシュテーブルはフツウに使うべきなのです。
なので、可変長データの可変長リストが必要なら、リストへのポインタをリストに持たせるだけで実装できます。
組み込みというのは、シビアそうでいい加減なところがあります。それは、終了することを考えなくて良いことです。
なんでかというと、一度入った電源はいつかならずOFFされるからです。
私が実際にみた装置のソフトウェアでは、環境変数(のようなもの)を登録するハッシュテーブルに対して、要素の追加関数は実装されていましたが、削除関数は実装されていませんでした。元になったライブラリは市販されていたもので、わざと消した跡がありました。
この例はベタなCで実装されたものですが、別のC++の例ではoperator newをオーバーロードしているのに、operator deleteをオーバーロードしていない実装もありました。これは２例見たことがあります。
当然のことながらfreeの無いmallocもあります。使わない関数を作ってもプログラム容量を圧迫するだけのことです。
話が完全に逸れてしまいましたが、リストやハッシュで書き直せば、コードが５文の１くらいになって、ソースの数が激減。メモリ使用効率も劇的に向上することが明らかであっても、なかなか言い出せません。
世の中には、自分の経験だけでとんでもない偏見を持ち、かつ権力を得た、お山の大将が多数いるのです。
もし、軽はずみに、
ハッシュテーブルで書けば検索時間はlog(n)のオーダに抑えられて、メモリ効率はざっくり５倍、コードサイズが小さくなる分と合わせれば１０分の１程度のメモリ使用量になるはずです。しかもソースの量が3分の１になってさらにifやらswitch～caseがほぼ皆無になりますので、テスト対象のパスが激減します。
などと言うとどうなるか。プライドを傷つけられた大将は、ありとあらゆる知識を動員して反論してきます。お山の対象というのは、天邪鬼なのです。
コードが小さくなってパスが減ってもそれは表面的なもので、デバッグが大変になる。ハッシュやリンクリストがバグったらとんでもないバグになる。たとえば配列のテーブルのインデクス計算がバグって隣の領域を破壊したとしても検証と再現が容易で影響の見積もりも可能だが、ややこしいポインタ演算がバグった場合の挙動は再現性が低く、また引き起こされる現象も複雑なパターンを示す。それを見てすぐにバグの原因箇所が分かる銀の弾がありますか？
リストやハッシュテーブルの操作関数群の完全性を保証するためのテストは容易に書く事が出来ない。特に細かいメモリの確保～解放に、提供されたメモリ管理ライブラリが耐えられるかどうかの慎重な評価が必要となる。その分の工数を含めて今後の保守の省力化につながりますか？
メモリの使用効率が向上するといっても、最大使用量が変わらなければ必要メモリ量は結局同じであり、モジュールに割り当てられるメモリ量を減らしてもらうことは出来ない。また誤動作したときに、配列なら定義した以上の領域を占有することはないが、動的に管理すると無尽蔵にメモリを取得しようとし、他のモジュールに迷惑をかけることも充分ありえる。メモリ不足が発生したときの動作はどのように定義しますか？
こういう事態を避けるためには、メリットをデメリットとして説明するのがうまい説明方法です。イカの太字部分に注目です。
ハッシュテーブルで書いたとしても、最悪値では線形検索と同じ程度の性能しか出ません。ハッシュ関数をうまく書く事が出来れば、log(n)のオーダの性能向上の余地はあります。
→ハッシュ関数のチューニングが釣りえさ。職人さんほどチューニング要素が好き。
動的メモリ管理にしても結局最大サイズは変わりませんが、起動直後の消費量を小さく抑えることができるかもしれません。起動直後の消費量を抑えたとしても何の効果も無いかもしれません。
→起動直後というベテランさんしか詳しい状況知らなさそうな部分にスポットライトをあてることで自尊心を満足してもらう。この説明に対して『まぁそれほどでもないが、起動直後は～～の処理があってメモリ確保が頻繁におこるから、こちら側のモジュールでは実はあまりメモリを取らない方が良いわけではあるが・・・』などと反応したらこっちのものです。
ハッシュテーブルとリスト構造で、最上位関数部分の実装はコンパクトになりますが、代わりにライブラリ部分が肥大化してしまいます。上位関数の実装者にはライブラリ部分のメンテは難しいかもしれませんので、下位関数の担当部署にお願いしたほうがいいかもしれません。もしかしたらテストも分業となってしまい、トータルの工数は増えてしまうかもしれません。
→普段ライブラリ利用側の実装ばかりの面倒を見ていることに問題意識のある大将さんなら、ライブラリの面倒をみるという毛色の違う仕事を若い衆にやらせたいと思うはずです。ですがいざというときの逃げ場としての分業体制の提案は重要となる場合があります。
考えすぎだと言うかも知れませんが、ちりも積もればなんとやらです。大きな意思決定を変えさせることは、下っ端あるいは傭兵の我々には困難ですが、巨大タンカーも小さなタグボートで方向転換できる例があります。つまりそういうことです。相手が気まぐれオレンジロードならどうにもなりませんが、天邪鬼なら反対の反対は賛成なのだ、なのです。
