siv3d / siv8 Goto Github PK

他のチェックと同様に #error を利用して早期にエラーを報告するか、該当するものがない場合にもマクロ自体は提供するべきだと思われます

Siv3D/OpenSiv3D#836

備考
OpenSiv3D v0.6のリポジトリでツールを試したところ、Siv3Dオリジナルのコードより、サードパーティーのコードのほうがコーディングスタイルが統一されてないことが多い印象でした。

GLFWでは生のX11を使っていますが、X11のAPIは機能が不十分でIMEなどの対応には限界がありました。
Flutterでも同様の理由でGtkに乗り換えています。
flutter/flutter#54860

そのためv0.8ではX11をラップし機能を強化したGtkを使うことを提案します。

1. （質問）コンセプト HasAsArray が typename Type::value_type を要求していますが、意図したものですか？　代わりに .asArray() の戻り値 R に typename R::value_type と typename R::allocator_type を要求するべきだと思います。
2. コンセプト HasAsArray が常に lvalue に対する .asArray() の呼び出しを要求していますが、完全転送して呼び出せることを要求するべきです。
3. （質問）Array::Array(size_type size, Arg::generator_<Fty> generator) などのテンプレートパラメータ制約で、ジェネレータの戻り値が要素の型と完全に一致することを要求していますが、それでは不便だと思います。「要素の型に変換可能」に制約を緩めたほうが良いと思いますが、どうでしょうか？
4. .all() と .any() について、std::predicate<Fty, value_type> の制約がありますが、これでは右辺値参照を受け取るような関数（オブジェクト）が制約を満たしてしまいます。右辺値参照を受け取るような関数が渡されたところで適用はできないので、エラーが出ることには変わりませんが、この場合は標準ライブラリのヘッダからエラーが出るので、わかりにくいものとなります。std::predicate<Fty, const value_type&> にするべきです。

# include <Siv3D.hpp>

struct Test
{
    // using value_type = int32;  // 1.

    Array<int32> asArray() &&  // 2.
    {
        return {};
    }
};

void Main()
{
    const Array a(Test{});  // 1. 2.
    const Array<int64> b(10, Arg::generator = [x = 0]() mutable { return x++; });  // 3.

    // b.all([](int32&& x) { return x == 0; });  // 4.
}

1. 2. の変更例

// Siv3D/Array.hpp
namespace s3d
{
	template <class Type>
	concept ArrayLike = requires(Type&& t)
	{
		Array<typename std::remove_cvref_t<Type>::value_type, typename std::remove_cvref_t<Type>::allocator_type>{ std::forward<Type>(t) };
	};

	template <class Type>
	concept HasAsArray = requires(Type&& t)
	{
		{ std::forward<Type>(t).asArray() } -> ArrayLike;
	};
}

追加する機能の内容 | Describe the solution you'd like

namespace s3d
{
	template <class Type> struct Vector2D;
	using Float2	= Vector2D<float>;
	using Vec2		= Vector2D<double>;
}

	template <class Type>
	inline constexpr typename Vector2D<Type>::value_type Vector2D<Type>::dot(const Vector2D v) const noexcept
	{
		return x * v.x + y * v.y;
	}

	template <class Type>
	inline constexpr typename Vector2D<Type>::value_type Vector2D<Type>::cross(const Vector2D v) const noexcept
	{
		return x * v.y - y * v.x;
	}

v0.6のdot/crossの実装では、value_typeに丸められる仕様になっている。すると以下のような結果を得る

Vec2D v1;
Fload2D f1;

f1.dot(v1) ;// => 戻り値の型はdoubleではなくfloat

C++として考えたとき、floatはdoubleに昇格されるので[conv.fpprom]、この戻り値の型もdoubleであるべきかに思える

一方で数学的に考えたとき、有効桁数の問題からfloatとdoubleではfloatのほうが精度が低いのでfloatのままでいいとも考えられる。

いずれにせよ、v0.6系ではVector2D<T>とVector2D<U>のdot/crossメンバ関数が定義されてなかったので、型変換コンストラクタを間に挟むわかりくい実装となっていたことがこの問題を潜在的なものにしていたと考えられうる

• dot/crossの精度問題について結論をだす
• Vector2DとVector2D`のdot/crossメンバ関数が定義される

その機能の追加によって解決する問題 | Is your feature request related to a problem? Please describe.

• 型を意識せずに内積/外積が計算できる
• Siv3D/OpenSiv3D#848 のような実装を容易にする

備考 | Additional context

• ref: https://gist.github.com/Reputeless/3ae414cace581526bf7771745aad181b