Description:
Discussion about C++ language, library, standards. (Moderated)
|
|
|
Standard citation difficulties for enum declarations and definitions.
|
| |
Pardon the difficulty in reading what should be in front of my face. C ++0X refers to the n3000 draft for the rest of this post. 1) forward-declaration of enumerations, e.g. enum test; C++0X n3000 appears to allow forward declarations (as an opaque enum- declaration; dcl.enum p3, in spite of dcl.enum p4) C99 6.7.2.3p2... more »
|
|
|
Library Issue #180 - what is so special about basic_string::replace
|
| |
The insert() and erase() members of basic_string were changed from taking iterators to taking const_iterators. However, the replace members were not. Library issue #180 says: "We did not make the change in replace, because this change would affect the implementation because the string may be written into. This... more »
|
|
|
N3000 unclear about basic_string::assign members
|
| |
The container requirements in clause 23.2.1 [container.requirements.genera l] states that a containers allocator can be replaced by copy assignment and move assignment, depending on iterator_traits. For basic_string we also have assign(const basic_string& str) and assign(basic_string&& str) member functions (21.4.6.3... more »
|
|
|
n-th element of pack expansion syntax proposal
|
| |
As mentioned in a post of comp.std.c++: [link] there's a need for some way to get the nth element of a pack expansion; however, the above post claims: This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous... more »
|
|
|
Creation of atomic_futures
|
| |
30.6.8/1 ([futures.atomic_future]/1) in N3000 says The class template atomic_future defines a type for asynchronous return objects. An atomic_future object can only be created by use of a promise (30.6.5) or packaged_task (30.6.10) object. However, promises and packaged_tasks, like asyncs, return std::future... more »
|
|
|
Motivation for atomic_future
|
| |
The only motivation I can find for atomic_future is this (from N2997): The need for an atomic_future arose from the fact that the move constructor and both assigments made the shared_future much more error prone to use a single instance from multiple threads. But such use is required when more... more »
|
|
|
Does std::launch::sync permit speculative execution?
|
| |
When std::async is invoked with a std::launch::sync policy, must the invocation of the async function be deferred until a wait or get? That is, given auto f = std::async(std::launch::sync() , f); ... f.get(); must execution of f be deferred until get is called, or may f be executed earlier? N2973, which is presumably a document that was used as background for the... more »
|
|
|
How do allocators become unequal?
|
| |
In C++98 the allocator requirements [lib.allocator.requirements] contains a special permission for standard containers: "All instances of a given allocator type are required to be interchangeable and always compare equal to each other." For C++0x this sentence has been removed, obviously with the intention... more »
|
|
|
UDL's in the C++0x library
|
| |
Currently, the draft C++0x library has no user-defined literals. It seems wasteful to include them as a language feature but not include the ability to use them for standard types. There are only two types I really feel need UDLs - complex<T> (a suffix 'i' for imaginary values) and basic_string (a suffix 's'), and defining UDLs for them would be 7... more »
|
|
|
The behavior of streambuf::seekoff
|
| |
It seems like return type of this function is a tad cloudy in the case where the last parameter is both std::ios_base::out and std::ios_base::in . To put it simply, is the returned offset the calculated offset of the in marker or out marker?
|
|
|
|
