Re: Constraints on value type of iterators in two iterator ctors
of sequences missing
On 4/25/07 3:51 AM, in article
1177493160.051591.251220@n15g2000prd.googlegroups.com, "James Kanze"
<james.kanze@gmail.com> wrote:
In response to a recent posting in comp.lang.c++, Gennaro Proto
raised a question as to the requirements concerning the value
type of the iterator used to instantiate the two iterator form
of the constructor. The actual example was:
unsigned char buffer[ N ] ;
// Fill buffer...
std::string s( buffer, buffer + N ) ;
This works with all implementations I have tried, but his
question was: is it guaranteed, and regretfully, I could find no
definitive answer in the standard. The section on this
constructor in the definition of std::basic_string forward to
the sequence requirements ([sequence.reqmts]), where all that is
said is that "X(i,j)" has a post condition that "isze() ==
distance between i and j", and that it "constructs a sequence
equal to the range [i,j)"; previous text constrains i and j to
satisfy input iterator requirements, and to be a valid range.
Obviously, buffer, buffer + N, above, meets all those
requirements. But...
1. Shouldn't there be at least the requirement that the
iterator value type be convertible to the value type of the
container? As written, things like:
void * a[] = { &x, &y, &z } ;
std::string s( a, a + 3 ) ;
or:
class C {
C( int ) ;
} ;
C a[] = { C(1), C(2), C(3) } ;
std::string s( a, a + 3 ) ;
would not seem to be forbidden.
Neither construction of "s" is forbidden - though both are likely to caus=
e a
compiler error. According to the requirements for a Input Iterator (as
listed in table 89 - all references are to n2134), an Input Iterator for =
a
type T - upon dereferencing - must return an object that is, at the very
least, convertible to T. Since neither a pointer-to-void nor the
user-defined "C" class in the example above is convertible to the
container's value_type (char), then in neither case has the caller provid=
ed
a suitable Input Iterator type to construct the object.
Now, an argument that fails to meet the Standard's requirements for a Inp=
ut
Iterator type - does not necessarily fail to construct the object. For on=
e
reason, a container will fall back to its other constructors in such a
situation - and check whether any of its other constructors are able to
accept the arguments as provided. And for another, more important reason,
the Standard allows an implementation to decide on its own what an accept=
al
Input Iterator type is - and therefore to accept (practically) any kind o=
f
argument type as a qualifying input iterator, if the implementation so
chooses:
"The extent to which an implementation determines that a type cannot be a=
n
input iterator is unspecified, except that as a minimum integral types sh=
all
not qualify as input iterators." [=A723.1.1/11]
2. What is actually meant by "constructs a sequence equal to"?
Consider:
double d[] = { 3.14, -0.1 } ;
std::string s( d, d + 2 ) ;
Is this legal? If not, why not? But if so, if I read the
text na=EFvely, the implementation is required to ensure
that
std::equals( s.begin(), s.end(), d )
returns true, which is going to be more than just difficult.
Not really. This code:
double d[] = { 3.14, -0.1 } ;
std::string s( d, d + 2 ) ;
bool result = equal( s.begin(), s.end(), d, std::equal_to<char>());
std::cout << "d == s is " << std::boolalpha << result << "\n";
produces this output:
d == s is true
Meaning that the initializing values and the initial values in this examp=
le
are equal - once the types have been "normalized" to match each other and
the the type of item stored in the container.
I would propose the following modifications:
In [sequence.reqmts]:
1. In paragraph 3, the text concerning i and j be amended to
read:
i and j denote iterators of the same type satisfying
input iterator requirements, [i, j) denotes a valid
range, and the value type of i and j be implicitly
convertible to the value type of the container
The current requirement is actually "convertible" not "implicitly
convertible" so some ground would be lost with this change.
2. In the entry concerning X(i, j) in table 82, the third
column be changed to:
post size() == distance between i and j
constructs a sequence such that each element of the
sequence is equal to the corresponding element of
the sequence [i, j), converted to the value type of
the container.
The reworded requirement seems to be too restrictive - it explicitly
requires that the source and container value types be convertible in at
least one direction - even though the actual requirement is that the two
types merely be equality-comparable. After all, in C++ it is possible to
test whether two objects of different types are equal - even if it is not
possible to convert between them.
3. In the entries concerning a.insert(p,i,j) and
a.assign(i,j), the text "copies of elements in [i,j)" be
replaced by "elements equal to the elements which would
be present in X(i,j)".
The subjective expression is never explicitly resolved - so it leaves the
reader in a state of suspense: "the elements which would be present in
X(I,j)...if only - if only what exactly? I eventually realized that the p=
ast
tense was the problem - the construction of X(I,J) is actually meant to b=
e
contemporaneous and hypothetical, not past and contrary-to-fact. So the
paragraph is stating that insertion is the same as construction when it
comes to Standard containers. Yet the Standard already goes on in some
length on this topic (starting at =A721.1.1/9 and following) that additio=
nal
wording seems unneeded here.
In [associative.requmts]:
1. In paragraph 7, the text concerning i and j be changed to:
i and j denote iterators of the same type satisfying
input iterator requirements, [i, j) denotes a valid
range, and the value type of i and j be convertible
to the value type of the container
(Note that the current text requires that the iterators
"refer to elemens of value_type". This is overly
constraining, as it is sufficient that the be implicitly
convertible to value_type. It is, in fact, a frequent idiom
in my own code to initialize a const map with something
like:
typedef std::map< std::string, int > Map ;
struct MapInit
{
char const* key ;
int value ;
operator Map::value_type() const
{
return Map::value_type( std::string( key ), value ) ;
}
} ;
MapInit const init[] =
{
{ "one", 1 },
{ "two", 2 },
{ "five", 5 } ,
} ;
Map m( init, init + 3 ) ;
It seems reasonable to me that this be supported.)
But a std::pair<char *, int> is not convertible (implicitly or otherwise)=
to
std::pair<std::string, int> - which is the map's value_type in the above
program. So even if you get want you wish for - and the the Standard did
adopt your proposed change - you would still not get what you want in ter=
ms
of this program.
Interestingly enough, the text concerning the constructor in
table 84 already seems to allow for implicit conversion, since
an "element" can effectively be inserted into the container any
time it is convertible to value type.
Yes, objects that are convertible to the associative container's value_ty=
pe
may be inserted on an individual basis into the container - but only obje=
cts
of value_type proper may be inserted en masse by passing a range of
iterators. Perhaps the differing requirements represents a compromise.
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]