座標系クラスの内部型の要件を再整理

[yumetodo]

現状座標系クラス(point_c ( #2 ), size_c ( #26 ) , point3d_c( #25 ))は内部型の要件にstd::is_arithmeticがtrueであることを要求しているが、noexceptの対応( #38 )等も進んだので必要ないのかもしれない。

ここでこれらのクラスの内部型の要件を整理する

• 座標系クラスで最低限必要なことは何か(最低限ってなに？)
  • no throw move constructable
  • etc...
• 座標系クラスの機能をフルに使うにはなにが必要か
  • abs
  • hypot
  • operator + - * / == !=
  • etc...

[Nagarei]

とりあえず現状のpoint_cの実装を列挙

• 座標系クラスで最低限必要なこと(コンパイル可能である為の条件)
  • no throw move constructable/assignable
  • std::is_arithmetic::value == true
• 座標系クラスの機能をフルに使うにはなにが必要か
  • default/copy constructable
  • copy assignable
  • operator bool / operator !=(0) / operator !=(value_type)
  • std::ostream/wostream& operator<<(std::ostream/wostream&, value_type)
  • std::istream/wistream& operator>>(std::istream/wistream&, value_type)
  • operator -(単項)
  • operator + - += -=(value_type)
  • operator * / *= /=(some_arithmetic_type)
  • operator !=(value_type)
  • abs
  • hypot

std::is_arithmetic

上の条件を見るにこれがないとstd::stringもOKになってしまうんですがこれはどうなんでしょう？

[yumetodo]

上の条件を見るにこれがないとstd::stringもOKになってしまうんですがこれはどうなんでしょう？

あーー、そういえばそうだなぁ・・・・。やっぱりstd::is_arithmeticは外せないのか・・・。

無限精度整数ライブラリとか作る時ってstd::is_arithmeticを特殊化するのって普通なんだろうか。普通でないならあまり制約は掛けたくないです。ユーザー側でどうにかできるとはいえ

[Nagarei]

std::is_arithmeticを特殊化するのって普通なんだろうか

少なくともboost::rational(boostの分数ライブラリ)は特殊化されていないですね...。

[yumetodo]

もうstd::stringを使ったとしても自己責任ということで制約外してしまいます？

[Nagarei]

それでも良いと思います。

[yumetodo]

要件に

• std::is_floationg_pointがtrue又はdoubleにキャスト可能

も追加しないといけないな・・・、point_c限定ですが

[yumetodo]

作業してみましたが、どうでしょうか。問題なければ残り2つのクラスもやりますが。

追記 って肝心のclassのtemplate修正してない！

[Nagarei]

問題ないと思います。

[yumetodo]

では他も作業します

[yumetodo]

これで多分作業完了だと思います。