终极效率 [英] Ultimate Efficiency
问题描述
你的程序开始于：
int main（无效）;
现在，在main中，你想要叫一个功能。你想要的这个特殊功能要调用
来定义一个Taste类型的本地对象，然后按值返回这个本地
对象。
主要是调用了这个函数，你要做的是绑定一个
引用从Taste返回的对象，然后继续使用它
就像如果它在main中被定义为本地对象。
这里的第一个限制是标准声明你可以绑定
从函数返回的对象只有一个* const *参考。
总而言之，你只需要创建一个对象。没有临时工。没有副本。
但是......实际上你将有3个对象：
1：函数中定义的局部变量
2：临时返回
3：你必须在main中创建另一个对象并复制临时对象，以便
来减轻常数。
我在几分钟之前编写了以下代码并编译并运行宏。
我已经尽力了让代码尽可能不繁琐阅读，所以
请稍等一下：
#include< iostream>
class Taste
{
public：
static unsigned char amount_ever;
static unsigned char amount_currently;
int mouth;
unsigned char age;
void Swallow（void）
{
口+ = 2;
}
口味（无效）：口（ 7），年龄（14岁）
{
++ amount_ever;
++ am ount_currently;
}
Taste（Taste&原文）
{
mouth = original.mouth;
age = original.age;
++ amount_ever;
++ amount_currently;
}
~品味（无效）
{
--amount_currently;
}
};
unsigned char Taste :: amount_ever = 0;
unsigned char Taste :: amount_currently = 0;
Taste Powder（无效）
{
口感奶油;
cream.age = 4;
cream.Swallow（）;
返回奶油;
}
int main（无效）
{
const Taste& yacht = Powder（）;
Taste& boat = const_cast< Taste&>（游艇）;
//现在我们有了我们想要的东西，一个本地变量。
boat.age = 12;
boat.Swallow（）;
std :: cout<< 金额： << （int）Taste :: amount_ever<< std :: endl
<< 当前金额： << （int）Taste :: amount_currently
<< std :: endl;
std :: system（" PAUSE"）;
}
现在第一件事是第一件事：
我要假设抛弃那个常量并编辑对象
是未定义的行为。
任何人都可以提出任何争论，为什么你首先要绑定到
* const *参考？！我会等待这个
问题的答案，然后我自己决定抛弃常量是
" moral"
继续：
使用上面的代码，通过抛弃constness，我的目标是
amount_ever == 2.令我高兴的是，它来了up 1 !!
显然，* my *编译器还没有创建一个临时的，它已经返回了函数中定义的实际本地对象的
。这导致我......
为什么这个优化到底是什么？编译器行为，而不是
run-of-the mill编译器行为？!!任何人都可以向我提供任何
参数，为什么函数应该复制局部变量然后
返回副本，而不是只返回局部变量本身？！
这是我的想法：
我的目标非常明确。在我看来，我知道并且完全相信我只能用1个对象做我想做的事情，而不是
3！不考虑标准，我相信C ++作为一种优秀的
编程语言应该能够实现这一目标，它应该是运行 -
-the-磨"编译器行为，而不是优化编译器
行为。
-JKop
JKop写道：
你的程序开始于：
int main（void）;
现在，在main中，你想调用一个函数。你想要调用的这个特殊函数定义一个Taste类型的本地对象，然后按值返回这个本地
对象。
主要是，调用了这个函数，你是什么的想要做的是绑定一个
引用从Taste返回的对象，然后继续使用它就像在main中定义为本地对象一样。
这里的第一个限制是标准声明你可以将从函数返回的对象仅绑定到* const *引用。
总而言之，你只需要创建一个对象。没有临时工。没有副本。
但是......实际上你将有3个对象：
1：函数中定义的局部变量
< 2：临时返回
3：你必须在main中创建另一个对象并复制临时对象以减轻constness。
或者你可以通过引用传递你的对象。你忘记了吗？
现在第一件事就是第一件事：
我要假装抛弃那个常量和编辑对象
是未定义的行为。
任何人都可以提出任何争论，为什么你首先要绑定到
* const *引用？！在我自己决定抛弃常量是否为道德之前，我会等待这个问题的答案。
通过抛弃constness，你使用一个非const引用到一个
临时值，它将在末尾被销毁。游艇范围。另外
这种hackery意味着程序员并不确切知道他想要做什么。
<继续：
使用上面的代码，通过抛弃constness，我的目标是
amount_ever == 2.令我高兴的是，它出现了1 !!显然，* my *编译器还没有创建临时的，它已经返回了函数中定义的实际本地对象。这导致我......
为什么这个优化到底是什么？编译器行为，而不是普通的工具。编译器行为？!!任何人都可以向我提供任何关于为什么函数应该复制局部变量然后返回副本而不仅仅返回局部变量本身的参数？
你为什么期望它是2？临时应该具有值1 for
amount_ever和amount_currently。
本地变量在其范围的末尾被销毁。其他任何事情
将违反C ++规则。
这是我的想法：
我的目标非常明确。在我看来，我知道并且完全相信我应该只用1个对象做我想做的事情，而不是
3！
我的建议是慢慢，彻底地阅读最新的ISO C ++
书。
不考虑标准，我认为C ++作为一种优秀的编程语言应该能够实现这一目标，它应该是运行 - 磨机。编译器行为，而不是优化编译器
行为。
:-)如果你有空间/运行时效率问题，你应该通过
参考（使用指针或引用）。它与C ++
无关，但正确使用它。
问候，
Ioannis Vranos
Ioannis Vranos发布：
或者您可以通过引用从main传递您的对象。你忘记了吗？
函数已经写好了。从这个角度来看待它。
我认为函数本身应该有义务使用b / b
声明变量并给予它更清晰回来了。你可以选择让返回的对象死掉，或者通过将它绑定到一个引用来延长它的生命。
通过抛弃constness，你对游艇范围结束时将被销毁的
临时使用非const引用。
正是我的意图。无论如何，船和游艇都有相同的范围，所以
那里没有问题。
你为什么期望它是2？对于amount_ever和amount_current，临时值应该为1
。
临时应该吗？
amount_ever和amount_currently是静态的
Tasete :: amount_ever
我原以为它是2，因为我的粉末功能应该已经制作了一份本地对象的副本，然后返回副本，也就是临时副本。这个
会将计数带到2.
本地变量在其范围的末尾被销毁。其他任何东西都会违反C ++规则。
首先你说amount_ever应该是1.
现在你说它会反对C ++规则返回本地
对象，表明应该将局部变量复制到临时
并暂时返回。这使得计数达到2.
A）暂不行。返回局部变量。 amount_ever = 1
B）创造临时性。暂时回来。 amount_ever = 2
-JKop
JKop< NU ** @ NULL.NULL>在新闻中写道：w8 ***************** @ news.indigo.ie：
Ioannis Vranos发布：
< blockquote class =post_quotes>或者你可以通过引用从main传递你的对象。你有没有忘记
那个？
这个函数已经写好了。从这个角度来看待它。
我认为函数本身应该有义务声明变量并将其返回，这样更清晰。您有选择让退回的对象死亡，或者通过将其绑定到参考来延长其寿命。
或者为什么不：
品味游艇（Powder（））;
并让返回值优化处理额外的品味副本
哪些可以消除？
Your program begins at:
int main(void);
Now, in main, you want to call a function. This particular function you want
to call defines a local object of type Taste, and then returns this local
object by value.
In main, having called this function, what you want to do is bind a
reference to the object returned from Taste and then continue on and use it
just as if it were defined in main as a local object.
The first restriction here is that the Standard declares that you can bind
the object returned from a function only to a *const* reference.
Altogether, you want just 1 object to be created. No temporaries. No copies.
But... in actual fact you''re going to have 3 objects:
1: The local variable defined in the function
2: The temporary returned
3: You''ll have to create another object in main and copy the temporary so as
to alleviate the constness.
I wrote the following code a few mins ago and it compiles and runs grand.
I''ve tried my best to make the code as non-tedious as possible to read, so
please just give it a glance over:
#include <iostream>
class Taste
{
public:
static unsigned char amount_ever;
static unsigned char amount_currently;
int mouth;
unsigned char age;
void Swallow(void)
{
mouth += 2;
}
Taste(void) : mouth(7), age(14)
{
++amount_ever;
++amount_currently;
}
Taste(Taste& original)
{
mouth = original.mouth;
age = original.age;
++amount_ever;
++amount_currently;
}
~Taste(void)
{
--amount_currently;
}
};
unsigned char Taste::amount_ever = 0;
unsigned char Taste::amount_currently = 0;
Taste Powder(void)
{
Taste cream;
cream.age = 4;
cream.Swallow();
return cream;
}
int main(void)
{
const Taste& yacht = Powder();
Taste& boat = const_cast<Taste&>(yacht);
//Now we have what we wanted, a local variable in main.
boat.age = 12;
boat.Swallow();
std::cout << "Amount ever: " << (int)Taste::amount_ever << std::endl
<< "Amount currently: " << (int)Taste::amount_currently
<< std::endl;
std::system("PAUSE");
}
Now first thing''s first:
I''m going to presume that casting away that constness and editing the object
is undefined behaviour.
Can anyone come up with any argument as to why the hell you''ve to bind to a
*const* reference in the first place?! I''ll wait for an answer to this
question before I decide for myself if casting away the constness is
"moral".
Moving on:
With the above code, by casting away the constness, I was aiming for
amount_ever == 2. To my delight, it came up 1!!
Obviously, *my* compiler has not created a temporary, it has returned the
actual local object defined in the function. Which leads me to...
Why the hell is this "optimization" compiler behaviour, as opposed to
"run-of-the-mill" compiler behaviour?!! Can anyone supply me with any
arguments as to why a function should copy the local variable and then
return the copy, as opposed to just returning the local variable itself?!
Here''s my thoughts:
My objective is very clear. In my mind, I know and trully believe that I
should be able to do what I want to do with just the 1 object, as opposed to
3! Without regard to the Standard, I believe that C++ as an excellent
programming language should be able to achieve this, that it should be "run-
of-the-mill" compiler behaviour, as opposed to "optimization" compiler
behaviour.
-JKop
JKop wrote:
Your program begins at:
int main(void);
Now, in main, you want to call a function. This particular function you want
to call defines a local object of type Taste, and then returns this local
object by value.
In main, having called this function, what you want to do is bind a
reference to the object returned from Taste and then continue on and use it
just as if it were defined in main as a local object.
The first restriction here is that the Standard declares that you can bind
the object returned from a function only to a *const* reference.
Altogether, you want just 1 object to be created. No temporaries. No copies.
But... in actual fact you''re going to have 3 objects:
1: The local variable defined in the function
2: The temporary returned
3: You''ll have to create another object in main and copy the temporary so as
to alleviate the constness.
Or you can pass your object from main by reference. Did you forget that?
Now first thing''s first:
I''m going to presume that casting away that constness and editing the object
is undefined behaviour.
Can anyone come up with any argument as to why the hell you''ve to bind to a
*const* reference in the first place?! I''ll wait for an answer to this
question before I decide for myself if casting away the constness is
"moral".
By casting away the constness, you use a non-const reference to a
temporary which is going to be destroyed at the end of yacht scope. Also
this kind of hackery means that the programmer doesn''t know exactly what
he wants to do.
Moving on:
With the above code, by casting away the constness, I was aiming for
amount_ever == 2. To my delight, it came up 1!!
Obviously, *my* compiler has not created a temporary, it has returned the
actual local object defined in the function. Which leads me to...
Why the hell is this "optimization" compiler behaviour, as opposed to
"run-of-the-mill" compiler behaviour?!! Can anyone supply me with any
arguments as to why a function should copy the local variable and then
return the copy, as opposed to just returning the local variable itself?!
Why did you expect it to be 2? The temporary should have the value 1 for
both amount_ever ans amount_currently.
The local variable is destroyed at the end of its scope. Anything else
would be against C++ rules.
Here''s my thoughts:
My objective is very clear. In my mind, I know and trully believe that I
should be able to do what I want to do with just the 1 object, as opposed to
3!
My suggestion is to have a slow, thorough read of an up to date ISO C++
book.
Without regard to the Standard, I believe that C++ as an excellent
programming language should be able to achieve this, that it should be "run-
of-the-mill" compiler behaviour, as opposed to "optimization" compiler
behaviour.
:-) If you have space/run-time efficiency concerns you should pass by
reference (using pointers or references). It has nothing to do with C++
but with the proper use of it.
Regards,
Ioannis Vranos
Ioannis Vranos posted:
Or you can pass your object from main by reference. Did you forget
that?
The function''s already written. Look at it from that point of view.
I think it''s cleaner that the function itself should have the obligation of
declaring the variable and giving it back. You have the choice to just let
the returned object die, or prolong its life by binding it to a reference.
By casting away the constness, you use a non-const reference to a
temporary which is going to be destroyed at the end of yacht scope.
Exactly my intention. boat and yacht have the same scope in anyway, so
there''s no problem there.
Why did you expect it to be 2? The temporary should have the value 1
for both amount_ever ans amount_currently.
The temporary should?
amount_ever and amount_currently are static
Tasete::amount_ever
I was expecting it to be 2 because my Powder function "should" have made a
copy of its local object and then returned the copy, aka a temporary. This
would bring the count to 2.
The local variable is destroyed at the end of its scope. Anything else
would be against C++ rules.
First you said that amount_ever should be 1.
Now you''re saying that it would be against C++ rules to return the local
object, indicating that the local variable should be copied to a temporary
and the temporary be returned. This brings the count to 2.
A) No temporary. Return local variable. amount_ever = 1
B) Create temporay. Return temporary. amount_ever = 2
-JKop
JKop <NU**@NULL.NULL> wrote in news:w8*****************@news.indigo.ie:
Ioannis Vranos posted:Or you can pass your object from main by reference. Did you forget
that?
The function''s already written. Look at it from that point of view.
I think it''s cleaner that the function itself should have the
obligation of declaring the variable and giving it back. You have the
choice to just let the returned object die, or prolong its life by
binding it to a reference.
Or why not:
Taste yacht(Powder());
And let the Return Value Optimization deal with the extra copies of Taste
which can be eliminated?
这篇关于终极效率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
