2

私は現在、コンパイル済みのバイナリ/DLL (クロスプラットフォーム) を必要とする製品向けに、一般向けの C++ API を設計しています。私たちがサポートする任意の POD (該当する場合) をユーザーが使用できるようにする API を希望しますが、基本的な要件は最大限の柔軟性とバイナリ互換性です。私は CPLEX の API に少し似たようなことをしています (これはいくつかのインスピレーションの 1 つです)。しかし、型情報を指定する方法は、彼らが行った方法よりも優れている可能性があると考えています (IloInt、IloNum、IloAny、Ilo* に関して) Var など、リンクを参照(できれば) IloExtractable ブランチの場合) バイナリ互換性を台無しにすることはありません。私が間違っている？私は何かを考えていますが、それが何であるか思い出せません。または、それが機能する場合でも、ビジターまたはデコレーターのパターンのようなものに似ていると思いますが、タイプについては、誰かが私にこの件について教えてもらえますか? 私の目の前に、GoF によるデザイン パターンの本があります。

注: ここにある可能性のある構文エラーは、当面の問題の一部ではありません。

使用できないと思われるものの例とその理由:

おそらく..しかし、これは式ツリーで物事を複雑にする可能性があります。

template<typename ValueType>
Constraint : public Expression;

今後の展開に影響しそうです。

IntConstraint : public Expression;
LongConstraint : public Expression;
DoubleConstraint : public Expression;

罪のように醜く、多くの微妙な問題を引き起こす可能性があります。

union Value
{
 int AsInt,
 float AsFloat
};
class Constraint : public Expression
{
  public:
  Value GetValue(Edge);
  void SetValue(Value, Edge);
  void SetUpper(Value, Vertex);
  void SetLower(Value, Vertex);
  ...
};

編集: Mads Elvheim に応えて (そしてこのリンクを見つけた後)、テンプレートを自分の可能性から除外する必要がないことに気付きましたが、それが最善のアイデアであるかどうかはまだ確信が持てません - 少なくとも Constraints クラスについては（概念的には健全ですが）思ったほど明確ではないことを許してください。

API を使いやすくするために、bnf を使用して文法を定義しました (これは私にとってかなり新しい方法です)。これにより、式、制約、および制約と相互作用するその他のクラスの抽象構文ツリーが作成されました。他のクラスは Constraints とやり取りするため、いわば「ギリギリ」まで型情報をできるだけ多く渡すことは避けたいと思います.抽象化のレベルが欠けているように感じます。

CPLEX を研究していると、数値 (整数と実数) のドメイン、線形方程式の表現 (もちろん)、およびそれに応じて何が可能になるかに従って型をモデル化したという印象を受けます。

(どうやら私は新しいユーザーなので、複数のリンクを投稿することはできません。)

編集 2: 最初のステップとしてConstraintExpressionArgument、Constraint クラスと Expression クラスの間に a を挿入することにしました。これにより、操作する型を意識せずに式ツリー内の制約を識別できるようになります。

私が言及しなかったかもしれないもう 1 つの詳細は、Constraint クラスが単独では使用できない CPLEX とは異なり、私の Constraint クラスは現在使用可能なユーザー クラスですが、CPLEX と同様に、拡張の余地も残しておきたいということです (したがって、入力の問題)。 ..

とにかく、現時点では私は同等のものを持っています

class ConstraintExpressionArgument : public Expression;
template<typename ValueType>
class Constraint : public ConstraintExpressionArgument;
4

2 に答える 2

2

ほとんどのシステムでは、正確な範囲またはビット数が重要な場合に使用できる型定義を含む<types.h>またはヘッダーが提供されています。<inttypes.h>問題に継承を投げる正当な理由がわかりません。指定された型またはテンプレートの型が要件に一致しない場合は、std::numeric_limitsBoost のマクロと一緒に使用して、意味のあるコンパイル時のアサートを生成することもできます。BOOST_STATIC_ASSERT()要件は、整数と浮動小数点数、範囲、表現可能な最小値、精度などです。例:

#include <limits>
#include <inttypes.h>
#include <boost/static_assert.hpp>

template<class T, int bits> T Add(const T& a, const T& b)
{
    BOOST_STATIC_ASSERT( std::numeric_limits<T>::is_integer     );
    BOOST_STATIC_ASSERT( std::numeric_limits<T>::is_signed      );
    BOOST_STATIC_ASSERT( std::numeric_limits<T>::digits == bits );

    return a + b;
}

std::numeric_limits にすべての型が含まれていない場合は、テンプレートの特殊化を使用してそれらを拡張および実装します。

于 2009-10-14T00:23:21.963 に答える
0

そうですね、少なくとも今のところは、必要なものは揃っていると思います。

前述しました

class ConstraintExpressionArgument : public Expression;
template<typename ValueType>
class Constraint : public ConstraintExpressionArgument;

タイプを制約性から分離する正しい軌道に乗ってくれました。

于 2009-10-16T15:42:27.250 に答える