By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,948 Members | 1,573 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,948 IT Pros & Developers. It's quick & easy.

std::swap and exceptions

P: n/a
Can I assume that std::swap will not throw when it is used to swap
std::string objects?
In the standard it says that the swap() std::string member function runs
in constant time.
I didn't see anything that said that swapping strings was guaranteed to
not throw though. But it would seem
that a constant time swap ought not to throw though. I can't really see
a way to implement one that does throw without
deliberately sabotaging it at least :)

So can I assume std::swap won't throw for strings?

-Davis

Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
In article <3F***************@mail.com>, Davis King
<da*******@mail.com> wrote:

| Can I assume that std::swap will not throw when it is used to swap
| std::string objects?
| In the standard it says that the swap() std::string member function runs
| in constant time.
| I didn't see anything that said that swapping strings was guaranteed to
| not throw though. But it would seem
| that a constant time swap ought not to throw though. I can't really see
| a way to implement one that does throw without
| deliberately sabotaging it at least :)
|
| So can I assume std::swap won't throw for strings?

swap will not throw for strings.

21.3/2 says:

| The template class basic_string conforms to the requirements of a
| Sequence, as specified in ( lib.sequence.reqmts ).

23.1.1 - Sequences [lib.sequence.reqmts], paragraph 1 says:

| A sequence is a kind of container ...

23.1 - Container requirements , paragraph 10 says:

| Unless otherwise specified ...

| no swap() function throws an exception unless that exception is thrown
| by the copy constructor or assignment operator of the container's
| Compare object (if any; see lib.associative.reqmts ).

string has no compare object. And I have not found in section 21
anything that specifies otherwise ... except:

20.1.5 - Allocator requirements, paragraphs 4 and 5:

| -4- Implementations of containers described in this International
| Standard are permitted to assume that their Allocator template
| parameter meets the following two additional requirements beyond those
| in Table ??.
| All instances of a given allocator type are required to be
| interchangeable and always compare equal to each other.
| The typedef members pointer ,const_pointer ,size_type , and
| difference_type are required to be T* ,Tconst* ,size_t , and ptrdiff_t
| , respectively.
|
| -5- Implementors are encouraged to supply libraries that can accept
| allocators that encapsulate more general memory models and that support
| non-equal instances. In such implementations, any requirements imposed
| on allocators by containers beyond those requirements that appear in
| Table ??, and the semantics of containers and algorithms when allocator
| instances compare non-equal, are implementation-defined.

So string (basic_string<char> - defaulted allocator) may not throw
because the default allocator will always compare equal. If a user
supplies a user-defined allocator into basic_string that does not
compare equal among instances, the library may not support it, and if
it does, it may support it by having a swap that throws (though
personally that would not be my first choice).

As long as you're dealing literally with string (the typedef) then I
believe it is safe to assume swap is nothrow.

--
Howard Hinnant
Metrowerks
Jul 19 '05 #2

P: n/a


Howard Hinnant wrote:
In article <3F***************@mail.com>, Davis King
<da*******@mail.com> wrote:
<snip>
| So can I assume std::swap won't throw for strings?
<snip>

As long as you're dealing literally with string (the typedef) then I
believe it is safe to assume swap is nothrow.


That's what I was hoping.
Thanks, for the explanation :)

-Davis

Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.