Getter按值返回字符串 - 好还是坏？ [英] Getter returning strings by value -- good or bad?

问题描述

我想知道为什么库实现者经常使用
使getter函数按值返回字符串

（副本） 。例如，在boost :: filesystem中，

leaf（）函数按值返回std :: string。

Gnome :: Vfs :: FileInfo :: get_name （）。


这不是不必要的开销吗？我还可以通过引用const-string返回
并避免

复制字符串，对吗？这就是我总是这么做的事情，并且效果很好。

好​​吧，对于字符串来说，它可能不是一个

表现受到打击，但是对于更复杂的对象，我会认为返回副本是个坏主意。


我在问因为我有这个场景：

我有一个名为File的类，它定义了一个

接口，用于访问有关文件的信息。

其状态主要由

Gnome :: Vfs :: FileInfo对象定义。

文件界面中的许多函数只是

包装器;他们将调用委托给封装的

FileInfo对象。


一个这样的例子是函数get_name（），其中

返回文件名。它的实现类似于

这个：


Glib :: ustring文件:: get_name（）const {

返回m_finfo_ptr - > get_name（）;

}


我之前想要像这样实现它：


const油嘴:: ustring和放大器; File :: get_name（）const {

return m_finfo_ptr-> get_name（）;

}


警告，因为我是
引用一个临时的（FileInfo :: get_name（）

返回一个name-string的副本，实际上是

为什么会出现这个问题）。


但是回到第一个版本：


Glib :: ustring File :: get_name（）const {

返回m_finfo_ptr-> get_name（）;

}


这里创建了多少副本？

FileInfo :: get_name（）会创建一个副本，然后我会返回该副本的副本，对吗？那太糟糕了！


请有人对此有所了解。


问候，

马蒂亚斯

Hi,

I was wondering why library implementors often
make getter functions return strings by value
(copies). For example, in boost::filesystem the
leaf() function returns an std::string by value.
So does Gnome::Vfs::FileInfo::get_name().

Isn''t that unnecessary overhead? I could as well
return by reference to const-string and avoid
copying the string, right? That''s what I always
do, and it works quite well.
Okay, for strings it''s maybe not that of a
performance hit, but with more complex objects I''d
reckon it''s a bad idea to return copies.

I''m asking because I have this scenario:
I have a class called File, which defines an
interface for accessing information about a file.
Its state is mostly defined by a
Gnome::Vfs::FileInfo object.
Many functions in the File interface are just
wrappers; they delegate calls to the encapsulated
FileInfo object.

One such example is a function get_name(), which
returns the name of a file. It''s implemented like
this:

Glib::ustring File::get_name() const {
return m_finfo_ptr->get_name();
}

I previously wanted to implement it like this:

const Glib::ustring& File::get_name() const {
return m_finfo_ptr->get_name();
}

That however issues a warning, because I''m
referencing a temporary (FileInfo::get_name()
returns a copy of the name-string, that''s actually
why this question came up).

But back to the first version:

Glib::ustring File::get_name() const {
return m_finfo_ptr->get_name();
}

How many copies are created here?
FileInfo::get_name() creates a copy, and I''m then
returning a copy of that copy, right? That''s terrible!

Please, someone shed some light on this.

Regards,
Matthias

推荐答案

Matthias Kaeppler写道：

Matthias Kaeppler wrote:

我想知道为什么库实现者经常制作getter函数
返回字符串价值（副本）。例如，在boost :: filesystem中，
leaf（）函数按值返回std :: string。那么Gnome :: Vfs :: FileInfo :: get_name（）。

这不是不必要的开销吗？我还可以通过引用返回
const-string并避免复制字符串，对吗？ [...]

I was wondering why library implementors often make getter functions
return strings by value (copies). For example, in boost::filesystem the
leaf() function returns an std::string by value. So does
Gnome::Vfs::FileInfo::get_name().

Isn''t that unnecessary overhead? I could as well return by reference to
const-string and avoid copying the string, right? [...]

这将是什么参考，以及如何在多元化的
线程程序中获得成功？按值返回一个字符串是完全正常的

a成员函数调用临时，但返回一个引用是

最有可能是......


编译器可以进行优化，但是他们无法为您修复损坏的代码。请记住

:-)

V

What would that be a reference to, and how is it going to fare in a multi-
threaded program? Returning a string by value is perfectly fine from
a member function called for a temporary, but returning a reference is
most likely isn''t...

Compilers can optimize but they can''t fix broken code for you. Keep that
in mind :-)

V

Victor Bazarov写道：

Victor Bazarov wrote:

这会是什么参考，以及如何在多线程程序中获得成功？
一个临时的成员函数返回一个字符串是完全没问题的，但返回一个引用很可能不是......


嗯，这将是一个已经存在的物品的参考。

已经存在。像这样：


类FileInfo {

私有：

Glib :: ustring名称;

public：

const Glib :: ustring& get_name（）const {

返回名称;

}

};


我不喜欢不知道为什么这是多线程

环境中的问题。返回的引用是对const的

引用，所以你无论如何都不能写它;

你不需要锁定这个对象和几个

线程可以随意读取它而不会破坏
完整性。

编译器可以进行优化，但它们无法为您修复损坏的代码。记住这一点:-)


我不知道上面的代码在哪里被破坏了。

V

What would that be a reference to, and how is it going to fare in a multi-
threaded program? Returning a string by value is perfectly fine from
a member function called for a temporary, but returning a reference is
most likely isn''t...
Well, it would be a reference to an object which
already exists. Like this:

class FileInfo {
private:
Glib::ustring name;
public:
const Glib::ustring& get_name() const {
return name;
}
};

I don''t see why this is a problem in multithreaded
environments. The reference returned is a
reference to const, so you can''t write it anyway;
you don''t need a lock on this object and several
threads may read it at will without breaking
integrity.
Compilers can optimize but they can''t fix broken code for you. Keep that
in mind :-)
I don''t see where the code above is broken.

V

Matthias Kaeppler写道：

Matthias Kaeppler wrote:

Victor Bazarov写道：

Victor Bazarov wrote:

这是什么意思，如何在多线程程序中获得成功？
一个临时的成员函数返回一个字符串是完全没问题的，但返回一个引用很可能不是......

What would that be a reference to, and how is it going to fare in a
multi-
threaded program? Returning a string by value is perfectly fine from
a member function called for a temporary, but returning a reference is
most likely isn''t...

嗯，它将是对已经存在的对象的引用。像这样：

类FileInfo {
私人：
Glib :: ustring名称;
公开：
const Glib :: ustring& get_name（）const {
返回名称;
}
};

我不明白为什么这是多线程环境中的问题。返回的
引用是对const的引用，所以无论如何你都不能写它
;你不需要对这个物体进行锁定，并且几个线程可以随意读取它而不会破坏完整性。

Well, it would be a reference to an object which already exists. Like this:

class FileInfo {
private:
Glib::ustring name;
public:
const Glib::ustring& get_name() const {
return name;
}
};

I don''t see why this is a problem in multithreaded environments. The
reference returned is a reference to const, so you can''t write it
anyway; you don''t need a lock on this object and several threads may
read it at will without breaking integrity.

是的，但如果其中一个线程想写信给它，读者会不会等待，不是吗？但是如果他们决定使用这个引用而没有

锁定它，那么如果有人在某些作家线程中更改了

的内容，会发生什么呢？ />

Yes, but if one of the threads wants to write to it, the readers would
have to wait, no? But if they decided to use the reference without
locking it, what''s going to happen if somebody changes the contents of
that value in some writer thread?

编译器可以进行优化，但是他们无法为您修复损坏的代码。请记住： - ）

Compilers can optimize but they can''t fix broken code for you. Keep that
in mind :-)

我没看到上面代码被破坏的地方。

I don''t see where the code above is broken.

上面的代码没有做任何事情因此它不能被打破。现在，想象

有人写道


std :: string const& sr = someclass（）。somememberreturningaconstref（）;


a临时消失，'sr''一旦定义就变为无效。

It如果按值返回一个字符串会比较困难。


V

The code above doesn''t do anything hence it can''t be broken. Now, imagine
somebody writes

std::string const& sr = someclass().somememberreturningaconstref();

a temporary is gone and ''sr'' has become invalid as soon as it was defined.
It''s more difficult if you return a string by value.

V

这篇关于Getter按值返回字符串 - 好还是坏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！