向类的构造函数添加虚拟参数来解决调用歧义是否违反任何规则?

发布于 2024-09-09 21:59:57 字数 524 浏览 1 评论 0原文

采用以下类和两个对象定义:

class Rect{
 public:
  enum centimeter;
  enum meter;
  Rect(double len,double wid,enum centimeter){
   length=(len/100);
   width=(wid/100);
  }
  Rect(int len,int wid,enum meter){
   length=len;
   width=wid;
  }
  //rest of implementation
 private:
  double length;//in meters
  double width;//in meters
};
Rect obj1(10,5,Rect::centimeter());
Rect obj2(10,5,Rect::meter());

前面的两个构造函数具有虚拟枚举参数,以解决这些虚拟参数不存在时导致的调用歧义。现在,尽管可以在这里使用命名构造函数,但如果我坚持使用这些虚拟参数,这是否违反了我应该注意的任何编码规则?

take following class and two object definitions:

class Rect{
 public:
  enum centimeter;
  enum meter;
  Rect(double len,double wid,enum centimeter){
   length=(len/100);
   width=(wid/100);
  }
  Rect(int len,int wid,enum meter){
   length=len;
   width=wid;
  }
  //rest of implementation
 private:
  double length;//in meters
  double width;//in meters
};
Rect obj1(10,5,Rect::centimeter());
Rect obj2(10,5,Rect::meter());

two previous constructors have dummy enum parameters to solve calling ambiguity caused in case these dummy parameters didn't exist. Now in spite of possibility of using named constructors here, if I insist on using these dummy parameters, does this violate any coding rule that I should be aware of ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

夏雨凉 2024-09-16 21:59:57

我觉得这违反了我的口味。我会这样编码:

enum Unit {
  Centimeter = 100, 
  Meter      = 1
};

Rect(int len, int wid, Unit unit) {
  length = len / (int) unit;
  width = wid / (int) unit;
}

Rect obj1(10, 5, Rect::Centimeter);
Rect obj2(10, 5, Rect::Meter);

I think it violates my taste. I would code it like this:

enum Unit {
  Centimeter = 100, 
  Meter      = 1
};

Rect(int len, int wid, Unit unit) {
  length = len / (int) unit;
  width = wid / (int) unit;
}

Rect obj1(10, 5, Rect::Centimeter);
Rect obj2(10, 5, Rect::Meter);
等往事风中吹 2024-09-16 21:59:57

BOOST_STRONG_TYPEDEF 可能是这里的答案。

BOOST_STRONG_TYPEDEF( double, Meter )
BOOST_STRONG_TYPEDEF( double, Centimeters)
BOOST_STRONG_TYPEDEF( double, Furlongs)

class Rect
{
 public:
  Rect(Meter len, Meter wid) : length(len), width(wid) 
  {};

  Rect(Centimeter len, Centimeter wid) : length(len/100), width(wid/100) 
  {};
}

Rect obj1(Meter(10),Meter(5));
Rect obj1(Centimeter(10),Centimeter(5));

BOOST_STRONG_TYPEDEF could be the answer here.

BOOST_STRONG_TYPEDEF( double, Meter )
BOOST_STRONG_TYPEDEF( double, Centimeters)
BOOST_STRONG_TYPEDEF( double, Furlongs)

class Rect
{
 public:
  Rect(Meter len, Meter wid) : length(len), width(wid) 
  {};

  Rect(Centimeter len, Centimeter wid) : length(len/100), width(wid/100) 
  {};
}

Rect obj1(Meter(10),Meter(5));
Rect obj1(Centimeter(10),Centimeter(5));
梦途 2024-09-16 21:59:57

STL 使用该习惯用法来代替概念来区分迭代器类型。

STL uses that idiom to differentiate iterator types in lieu of concepts.

久而酒知 2024-09-16 21:59:57

不能说这违反了规则,但是......它不容易阅读。

为什么不能声明 a

enum metrics {
  centimeter,
  meter
};

并将其用作构造函数参数?或者

class Rect {
public:
  static Rect CreateWithMeters(int width, int height);
  static Rect CreateWithCentimenets(int width, int height);
}

根据我的口味,两者都比当前代码更好。

Can't say this breaks a rule, but... It isn't easy to read.

Why can't you declare a

enum metrics {
  centimeter,
  meter
};

and use it as the constructor parameter? Or it can be

class Rect {
public:
  static Rect CreateWithMeters(int width, int height);
  static Rect CreateWithCentimenets(int width, int height);
}

Either is better than current code at my taste.

樱&纷飞 2024-09-16 21:59:57
Rect(int len,int wid,enum centimeter){
  length=(len/100);
  width=(wid/100);
}

除了其他人写的之外,这个逻辑很糟糕,因为 Rect(99,99,Rect::centimeter()) 等于 Rect(0,0,Rect::centimeter( ))

如果您在内部存储米,请不要提供厘米的接口,无论是这种方式还是任何其他方式。

Rect(int len,int wid,enum centimeter){
  length=(len/100);
  width=(wid/100);
}

In addition to what others wrote, this logic is bad, because Rect(99,99,Rect::centimeter()) is equal to Rect(0,0,Rect::centimeter()).

If you are storing meters internally, do not provide an interface with centimetres, not this way nor any other way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文