问题描述
在最近关于什么用于新项目的讨论中，
整合了两个以前单独的团队的工作，我们得到了我们各自的
主题字符串实现。一个团队用自己的字符串滚动了
而另一个团队使用了std :: string。使用本土字符串（和向量）
的原因主要是引用计数和
portabillity，但我认为这几天几乎所有STL
实现使用refcounted字符串并且STL可用对于大多数平台来说是
。
当我们回到用我的编译器测试时（MSVC ++ 6 with
最新的补丁程序级别的字符串被重新计算，但在另一个团队
导致'的计算机（.net）字符串未被重新计算。你们中的任何人都知道
a网页或网站在各种平台上整合有关STL
实施的信息，或者是否有人有关于该网站的特定
信息Windows，WinCE，Symbian，Mac上的STL状态
或Linux？
感谢您的帮助，
-joe
In recent discussions relating to what to use for a new project which
integrated the work of two, previously seperate, teams we got to the
subject of our respective string implementations. One team rolled
their own strings while the other used the std::string. Reasons for
using the home-grown strings(and vectors) were mainly refcounting and
portabillity, but I thought that these days almost all STL
implementations used refcounted strings and that the STL was available
for most platforms.
When we got back to test things out with my compiler (MSVC++ 6 with
the latest patch-level) strings were refcounted but on the other team
lead''s computer (.net) strings were not refcounted. Do any of you know
a webpage or site that consolidates information about the STL
implementations on various platforms or does anyone have specific
information about the state of the STL on Windows, WinCE, Symbian, Mac
or Linux?
Thanks for any help,
-joe
推荐答案
由于线程问题，
std :: string在VC.NET中已更改。然而，
那种OT。
std::string was changed in VC.NET because of threading issues. However,
that''s kind of OT.
我没有具体的信息，但我的理解是通过谈话
到另一个C ++库实施者是每个人都在移动''std :: string''的引用计数实现。
基本上，原因是接口不是真的合适
实际上甚至提到了一个注释中的引用计数
（如果我没记错的话）这种实现方式是
）。这有点与
的历史有关，当所有内容都成为模板时，字符串类被提升了。
[可能]多线程的事情变得更加复杂/>
环境，其中引用计数方法实际上需要在各个地方使用
互斥锁，这会显着增加成本。
我还没有验证了结果，但显然结论是
复制字符串是可以接受的，并且可以通过小字符串 - 优化（简单地嵌入）来进一步降低成本
如果字符串对象小于例如32个字符，则字符串在
中直接为字符串对象。对于
非常大的字符串，您可能希望通过引用传递它们
或通过共享指针 - 至少在它们是不可变的时候。
-
< mailto：di *********** @ yahoo.com> < http://www.dietmar-kuehl.de/>
< http://www.contendix.com> - 软件开发&咨询
I don''t have specific information but my understanding from talking
to the other C++ library implementers is that everybody is moving
away from reference counted implementations of ''std::string''.
Essentially, the reason is that the interface is not really suitable
for this kind of implementation despite the fact that the specification
in the standard actually even mentions reference counting in a note
(if I remember correctly). This is somewhat related to the history of
the string class which was vamped up when everything became a template.
Things are further complicated in [potentially] multi-threaded
environments where the reference counting approach effectively requires
mutex locks in various places which significantly increases the costs.
I haven''t verified the results but apparently the conclusion is that
copying strings is acceptable and the costs can be further reduced
by the "small string"-optimization (which simply embeds the string in
the string object directly if it is smaller than eg. 32 chars). For
really large strings you probably want to pass them around by reference
or through a shared pointer - at least when they are immutable.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
我想虽然使用了原子增量器和减量器
$ b可以使用$ b代替互斥锁，并且可以在大多数b
处理器上使用它们。我在Windows新闻组上询问了他们的理由是什么？b $ b可能不仅仅是使用提供的Interlocked功能而且
还没有真正得到回应。也许我认为原子fcns对于refcounted对象真正需要的是什么？那将是不幸的，因为我认为这是我们的内部解决方案。
我还没有验证结果，但显然结论是
复制字符串是可接受的并且可以通过小字符串优化来进一步降低成本（如果字符串对象小于例如32个字符，则直接将字符串直接嵌入字符串对象中）。对于
非常大的字符串，您可能希望通过引用或通过共享指针传递它们 - 至少在它们是不可变的时候。
I thought though that the use of atomic incrementors and decrementors
could be used in place of a mutex and that they were available on most
processors. I asked on the Windows newsgroup about what their reasons
might have been to not just use the provided Interlocked functions but
havn''t really gotten a response. Maybe I am wrong that atomic fcns are
all that are really needed for refcounted objects? That would be
unfortunate as I think this is our internal solution.
I haven''t verified the results but apparently the conclusion is that
copying strings is acceptable and the costs can be further reduced
by the "small string"-optimization (which simply embeds the string in
the string object directly if it is smaller than eg. 32 chars). For
really large strings you probably want to pass them around by reference
or through a shared pointer - at least when they are immutable.
这是有道理的我猜，虽然引用计数似乎更多
有效。我希望Smarter Brains Than Mine已经考虑了大多数STL实施中的必要问题并且相应地采取了行动
。无论如何，感谢您的回复。
-joe
This makes sense I guess although refcounting seems so much more
efficient. My hope is that Smarter Brains Than Mine have considered
the necessary issues in most STL implementations and acted
accordingly. Anyway, thanks for your response.
-joe
这篇关于std :: string和refcounting的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！