类声明中有符号/无符号修饰符的提议 [英] Proposal for signed/unsigned modifier in class declarations

查看:85
本文介绍了类声明中有符号/无符号修饰符的提议的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,


这是我发给新闻组的第一篇文章。

我想得到一些关于我正在考虑的提案的反馈关于


---提案开始---


建议添加

签名/无符号修饰符到类声明

到下一版C ++编程语言


摘要


本文档描述了在基类上启用有符号/无符号

修饰符的建议语法,以允许同一类的有符号/无符号版本
,只有轻微的行为更改。这将允许

更简单的高级数字类的实现,即TR1(和TR2)接受的




语义


该类可以声明为已签名,未签名或

无。如果未指定signed或unsigned,则无法使用signed / unsigned

说明符来创建对象。

当使用signed或unsigned modifier创建对象时,

使用默认语义(在类

声明中指定签名/未签名)。


成员函数可以指定为签名或未签名或

无。这会使成员函数特别重载已签名或

无符号版本的类。当没有使用这些修饰符时,

该方法可用于有符号和无符号类型。

当只有单个成员函数时,显式声明为signed或
使用
unsigned,另一种类型不能使用此成员函数。

参见Synatx。


当未使用有符号/无符号规范时类声明

正常行为保留。不能声明任何成员函数

签名/未签名且类名不能与signed / unsigned

修饰符一起使用以创建对象。


未派生签名/未签名的灵活性。使用修饰符其他

比不同类型的默认产量。


语法


类声明扩展_ability_指定它是

签名或未签名:


C类签署{...};



class C unsigned {...};


然后对象的方法可以为签名或未签名的方法重载

版本:


C级签名{

void M()签名;

void M()unsigned;

};

C级签名{

void M(); //与签名相同在这里使用

void M()unsigned;

};

C类签名{

void M( );

void M()签名; //错误:签名版已经宣布

};

C级签名{

void M(); //签名和未签名的一个版本

};

C签名{

void M()unsigned; //无法从签名类型调用M

};

C类签名{

void M()已签名; //无法从无符号类型调用M

};


对象创建:


class C signed { ......};

C c; //与signed C c相同的类型

签名C c; //与C c相同的类型

unsigned C c; //具有与signed C c不同的类型


class C unsigned {...};

C c; //与unsigned C c相同的类型

签名C c; //具有与unsigned C c不同的类型

unsigned C c; //与C c相同的类型


class C {...};

C c;

签署C c; //语法错误

unsigned C c; //语法错误


问题


没有人知道。可以看到当前符合规范的代码没有问题,因为

已签名和未签名的不允许在拟议的地方。


---提案结束---


我知道术语不正确它需要一个适当的

措辞,但这只是初步考虑。

你觉得怎么样?是否值得尝试提交?


---

Jan Ringo1, Tr **** @ MX-3.cz
http://Tringi.MX-3.cz

Hello everybody,

this is my first post to a newsgroup at all.
I would like to get some feedback on one proposal I am thinking about:

--- begin of proposal ---

Proposal to add
signed/unsigned modifier to class declarations
to next revision of C++ programming language

Abstract

This document describes proposed syntax that enable signed/unsigned
modifiers on base classes in order to allow signed/unsigned versions
of the same class with only minor behavioral changes. This will allow
much simpler implementation of advanced numeric classes that are about
to be accepted for TR1 (and TR2).

Semantics

The class can be declared either to be signed, to be unsigned or
none. When neither signed or unsigned is specified an signed/unsigned
specifier cannot be used to create an object.
When either signed nor unsigned modifier is used to create an object,
the default semantics is used (signed/unsigned specified in class
declaration).

Member functions can be specified to be either signed or unsigned or
none. This overloads the member function specificaly for signed or
unsigned version of the class. When none of these modifiers is used,
the method is available for both signed and unsigned types.
When only single member function, explicitly declared as signed or
unsigned is used, the other type cannot use this member function.
See Synatx.

When signed/unsigned specification is not used on the class declaration
the normal behavior retains. No member function can be declared
signed/unsigned and the class name cannot be used with signed/unsigned
modifier in order to create an object.

The signed/unsigned flexibility is not derived. Using modifier other
than default yields in different type.

Syntax

The class declaration is extended of _ability_ to specify it either
as signed or unsigned:

class C signed { ... };
or
class C unsigned { ... };

The object''s methods then can be overloaded for signed or unsigned
version:

class C signed {
void M () signed;
void M () unsigned;
};
class C signed {
void M (); // the same as if "signed" was used here
void M () unsigned;
};
class C signed {
void M ();
void M () signed; // error: signed version already declared
};
class C signed {
void M (); // one version for both signed and unsigned
};
class C signed {
void M () unsigned; // unable to call M from signed type
};
class C signed {
void M () signed; // unable to call M from unsigned type
};

Object creation:

class C signed { ... };
C c; // the same type as "signed C c"
signed C c; // the same type as "C c"
unsigned C c; // has different type than "signed C c"

class C unsigned { ... };
C c; // the same type as "unsigned C c"
signed C c; // has different type than "unsigned C c"
unsigned C c; // the same type as "C c"

class C { ... };
C c;
signed C c; // syntax error
unsigned C c; // syntax error

Problems

None known. No problems with current conforming code is seen because
"signed" and "unsigned" are not allowed at proposed places.

--- end of proposal ---

I know that the terminology is not correct and that it would need a proper
wording, but this is just for initial consideration.
So what do you think? Is it worth trying to submit?

---
Jan Ringo1, Tr****@MX-3.cz
http://Tringi.MX-3.cz

推荐答案



你可以声明

class unsigned_C {...};

class signed_C {...};


有什么区别给你的方法?

你的方法对此有什么好处吗?


问候

Thorsten


Jan Ringo ??写道:
Hi,
you could declare
class unsigned_C {...};
class signed_C {...};

What''s the difference to your approach ?
Does your approach have any advantages to this ?

Regards
Thorsten

Jan Ringo?? wrote:

大家好,


这是我发给新闻组的第一篇文章。

我想得到一些关于我正在考虑的提案的反馈


---提案开头---


建议将

有符号/无符号修饰符添加到类声明中

到下一版本的C ++编程语言


摘要


本文档描述了在基类上启用有符号/无符号

修饰符的建议语法,以允许签名/未签名版本

同一类,只有轻微的行为改变。这将允许

更简单的高级数字类的实现,即TR1(和TR2)接受的




语义


该类可以声明为已签名,未签名或

无。如果未指定signed或unsigned,则无法使用signed / unsigned

说明符来创建对象。

当使用signed或unsigned modifier创建对象时,

使用默认语义(在类

声明中指定签名/未签名)。


成员函数可以指定为签名或未签名或

无。这会使成员函数特别重载已签名或

无符号版本的类。当没有使用这些修饰符时,

该方法可用于有符号和无符号类型。

当只有单个成员函数时,显式声明为signed或
使用
unsigned,另一种类型不能使用此成员函数。

参见Synatx。


当未使用有符号/无符号规范时类

声明正常行为保留。没有成员函数可以是

声明为signed / unsigned,并且类名不能与

signed / unsigned修饰符一起使用以创建对象。


未派生签名/未签名的灵活性。使用修饰符其他

比不同类型的默认产量。


语法


类声明扩展_ability_指定它是

签名或未签名:


C类签署{...};



class C unsigned {...};


然后对象的方法可以为签名或未签名的方法重载

版本:


C级签名{

void M()签名;

void M()unsigned;

};

C级签名{

void M(); //与签名相同在这里使用

void M()unsigned;

};

C类签名{

void M( );

void M()签名; //错误:签名版已经宣布

};

C级签名{

void M(); //签名和未签名的一个版本

};

C签名{

void M()unsigned; //无法从签名类型调用M

};

C类签名{

void M()已签名; //无法从无符号类型调用M

};


对象创建:


class C signed { ......};

C c; //与signed C c相同的类型

签名C c; //与C c相同的类型

unsigned C c; //具有与signed C c不同的类型


class C unsigned {...};

C c; //与unsigned C c相同的类型

签名C c; //具有与unsigned C c不同的类型

unsigned C c; //与C c相同的类型


class C {...};

C c;

签署C c; //语法错误

unsigned C c; //语法错误


问题


没有人知道。可以看到当前符合规范的代码没有问题,因为

已签名和未签名的不允许在拟议的地方。


---提案结束---


我知道术语不正确它需要一个适当的

措辞,但这只是初步考虑。

你觉得怎么样?是否值得尝试提交?


---

Jan Ringo ??, Tr **** @ MX-3.cz
http://tringi.MX-3.cz


首先,减少代码重复。你只会写一次大部分操作符

,并重载那些需要不同的操作符。例如,

无符号除法可能比签名除法更简单。对于无符号类型,

less-than运算符也更简单。


我已经看到TR1数字类型的一些提议,其中签名版本是

派生自未签名版本(不确定它是什么,我找不到它现在是
)。这是另一种选择,但它是否真的是正确的方法?


毕竟,它也是语法糖,可以利用

库定义数字类型更简单,更直观(特别是对于

初学者)。


---

Jan Ringo1, Tr **** @ MX-3.cz
http://Tringi.MX-3.cz


---

Dne Sat,2007年2月3日23:46:32 +0100 Thorsten Kiefer

< to ***** @ usenet.cnntp.orgnapsal / -a:
First of all, less code duplication. You would write most of the operators
only once and overloaded those that needs to be different. For example,
unsigned division can be a little simpler than signed division. The
less-than operator is also simpler for unsigned types.

I have seen some proposals for TR1 numeric types where signed version is
derived from unsigned version (not sure what it was, I cannot find it
now). This is one alternative but is it really right way to do that?

After all, it is also syntactic sugar that would make use of
library-defined numeric types easier and more intuitive (especially for
beginners).

---
Jan Ringo1, Tr****@MX-3.cz
http://Tringi.MX-3.cz

---
Dne Sat, 03 Feb 2007 23:46:32 +0100 Thorsten Kiefer
<to*****@usenet.cnntp.orgnapsal/-a:

您好,

您可以声明

class unsigned_C {...};

class signed_C {.. 。};


您的方法有什么不同?

您的方法对此有何益处?


问候

Thorsten


Jan Ringo1写道:
Hi,
you could declare
class unsigned_C {...};
class signed_C {...};

What''s the difference to your approach ?
Does your approach have any advantages to this ?

Regards
Thorsten

Jan Ringo1 wrote:

> Hel大家好,这是我在新闻组中的第一篇文章。
我想得到一些关于我正在考虑的提案的反馈

---提议开始---

建议将
signed / unsigned修饰符添加到类声明中
下一版C ++编程语言

摘要

本文档描述了在基类上启用有符号/无符号
修饰符的建议语法,以便允许同一类的有符号/无符号版本只有轻微的行为改变。这将允许
更简单地实现高级数字类,这些类可以接受TR1(和TR2)。

语义学/>
该类可以声明为已签名,无符号或无。如果未指定signed或unsigned,则
signed / unsigned
说明符不能用于创建对象。
当使用signed或unsigned modifier创建
对象时,
使用默认语义(在类
声明中指定签名/未签名)。

成员函数可以指定为有符号或无符号或
无。这会使成员函数特别重载已签名或
无符号版本的类。当没有使用这些修饰符时,
该方法可用于有符号和无符号类型。
当只使用单个成员函数,显式声明为signed或
unsigned时,另一种类型不能使用此成员函数。
请参阅Synatx。

当类/
声明中未使用签名/未签名规范时,正常行为将保留。没有成员函数可以声明为有符号/无符号,并且类名不能与
signed / unsigned修饰符一起使用以创建对象。

签名/未签名的灵活性是不是派生的。使用修饰符其他
比默认的不同类型的产量。

语法

类声明扩展为_ability_以指定
为signed或unsigned :C类签名{...};

C类未签名{...};

对象的方法然后可以为签名或未签名版本重载
版本:
C类签名{
void M()签名;
void M()unsigned;
}; C类签名{
void M(); //与签名相同在这里使用
void M()unsigned;
};
C类签名{
void M();
void M()signed; //错误:签名版已经宣布
};
C类签名{
void M(); //签名和签名的一个版本
};
C类签名{
void M()unsigned; //无法从签名类型调用M
};
C类签名{
void M()signed; //无法从无符号类型调用M
};

对象创建:
C类签名{...};
C c; //与signed C c相同的类型
签名C c; //与C c相同的类型
无符号C c; //具有与signed C c不同的类型

C c; //与unsigned C c相同的类型
签名C c; //具有与unsigned C c不同的类型
无符号C c; //与C c相同的类型

C类{...};
C c;
签名C c; //语法错误
unsigned C c; //语法错误

问题

没有人知道。可以看到当前符合规范的代码没有问题,因为
已签名。和未签名的不允许在拟议的地方。

---提案结束---

我知道术语不正确,需要一个
正确的措辞,但这只是初步考虑。
那你觉得怎么样?是否值得尝试提交?

--- Jan Ringo1, Tr **** @ MX-3.cz
http://Tringi.MX- 3.cz


Jan Ringo ??写道:
Jan Ringo?? wrote:

首先,减少代码重复。你只会写一次大部分操作符

,并重载那些需要不同的操作符。例如,

无符号除法可能比签名除法更简单。对于无符号类型,

less-than运算符也更简单。
First of all, less code duplication. You would write most of the operators
only once and overloaded those that needs to be different. For example,
unsigned division can be a little simpler than signed division. The
less-than operator is also simpler for unsigned types.



我怀疑你可以在签名类中重用未签名的代码。

示例:

class Mathtools签名{

static signed int add(signed int a,signed int b){

return primitive_add(a,b);

}

};

要重复使用,你会写:

class Mathtools unsigned {

static unsigned int add( unsigned int a,unsigned int b){

return(unsigned)add((signed)a,(signed)b);

}

};

/ *假设签名的添加在无符号版本中可用* /


一个想法是让编译生成第二个类定义为默认值,

你可以覆盖/超载默认行为。

这是你的意思吗?

如果没有,请给一个更好的例子。

I doubt that you can reuse unsigned-code in the signed-class.
Example :
class Mathtools signed {
static signed int add(signed int a,signed int b){
return primitive_add(a,b);
}
};
To reuse this you would write:
class Mathtools unsigned {
static unsigned int add(unsigned int a,unsigned int b){
return (unsigned)add((signed)a,(signed)b);
}
};
/* presuming that the signed add is available in the unsigned version */

An idea would be to make the compile generate the second class definition as default,
where you can override/overload the default behaviour.
It this what you mean ?
If not, please give a better example.


>

我看过TR1数字类型的一些提案,其中签名版本是

der从未签名的版本(不知道它是什么,我找不到它现在是
)。这是另一种选择,但它是否真的是正确的方法呢?
>
I have seen some proposals for TR1 numeric types where signed version is
derived from unsigned version (not sure what it was, I cannot find it
now). This is one alternative but is it really right way to do that?



在这种情况下,派生类包含有符号和无符号版本。

我认为这不是你想要的。

In that case the derived class contains both signed and unsigned versions.
I think that''s not what you want.


>

毕竟,它也是语法糖,可以利用

库定义的数值类型更简单,更直观(特别是对于

初学者)。
>
After all, it is also syntactic sugar that would make use of
library-defined numeric types easier and more intuitive (especially for
beginners).



如何使用模板?


模板< class X>

class Mathtools {

静态X add(X a,X b){

返回a + b; <获得签名版本:

Mathtools< signed int>: :add(1,2);

获取未签名的版本:

Mathtools< unsigned int> :: add(1,2);


如果你需要,你仍然可以专门化模板:

模板<浮动>

类Mathtools {

static X add(X a,X b){

返回my_fancy_float_a dder(a,b);

}

};


请原谅我语法错误,因为我们正在谈论原则,语法目前并不重要。

How about using templates ?

template<class X>
class Mathtools {
static X add(X a,X b){
return a + b;
}
};

To get the signed version :
Mathtools<signed int>::add(1,2);
To get the unsigned version :
Mathtools<unsigned int>::add(1,2);

And you can still specialize the template, if you need to :
template<float>
class Mathtools {
static X add(X a,X b){
return my_fancy_float_adder(a,b);
}
};

Please forgive me syntactic errors, as we are talking about principles, syntax is unimportant at the moment.


---

Jan Ringo ??, Tr **** @ MX-3.cz
http://Tringi.MX-3.cz


这篇关于类声明中有符号/无符号修饰符的提议的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆