Is std::vector<T>::size_type guaranteed to be the same type as
std::vector<U>::size_type?
To be more explicit, given
void f(T, U);
and
std::vector<Tvt;
std::vector<Uvu;
which have the same size, can I write
for (std::vector<T>::size_type i = 0; i < vt.size(); ++i) f(vt[i],
vu[i]);
or should I write
for (std::vector<T>::size_type i = 0; i < vt.size(); ++i) f(vt[i],
vu[static_cast<std::vector<U>::size_type>(i)]);
Thank you.
13  7575 
On 2007-10-09 23:18, t.****@liv.ac.uk wrote:
Is std::vector<T>::size_type guaranteed to be the same type as
std::vector<U>::size_type?
To be more explicit, given
void f(T, U);
and
std::vector<Tvt;
std::vector<Uvu;
which have the same size, can I write
for (std::vector<T>::size_type i = 0; i < vt.size(); ++i) f(vt[i],
vu[i]);
or should I write
for (std::vector<T>::size_type i = 0; i < vt.size(); ++i) f(vt[i],
vu[static_cast<std::vector<U>::size_type>(i)]);
I can not find any such guarantee in the standard, but I would be *very*
surprised if they were of different. First, there is no reason to make
them different and second, it is difficult to make them differ for T and
U without having them depend on T and U in some way (which would be the
same as making assumptions about the types T and U). Most implementation
probably uses size_t as std::vector<T>::size_type.
--
Erik Wikström t.****@liv.ac.uk wrote:
Is std::vector<T>::size_type guaranteed to be the same type as
std::vector<U>::size_type?
No. (But in practice, they will all be the same as std::size_t.)
To be more explicit, given
void f(T, U);
and
std::vector<Tvt;
std::vector<Uvu;
which have the same size, can I write
for (std::vector<T>::size_type i = 0; i < vt.size(); ++i) f(vt[i],
vu[i]);
Yes.
or should I write
for (std::vector<T>::size_type i = 0; i < vt.size(); ++i) f(vt[i],
vu[static_cast<std::vector<U>::size_type>(i)]);
No.
To be more explicit: since you promise that the two vectors have the same
length, std::vector<T>::size_type and std::vector<U>::size_type are large
enough to represent it. Also, both types are guaranteed to be unsigned
integral types. Therefore, the assignment is well-defined.
Best
Kai-Uwe Bux
Erik Wikström wrote:
Most implementation
probably uses size_t as std::vector<T>::size_type.
Can size_t be safely assumed to be of the same size and
type as std::vector<T>::size_type?
The former is just a lot easier to write, which is why
I'm tempted to use it instead of the latter.
Btw, I have noticed that neither gcc nor VC++ require you
to write it like "std::size_t", but just "size_t" is ok
(without any 'using'). Is this also standard?
Juha Nieminen wrote:
Erik Wikström wrote:
>Most implementation
probably uses size_t as std::vector<T>::size_type.
Can size_t be safely assumed to be of the same size and
type as std::vector<T>::size_type?
You can "safely" assume that. But it is not guaranteed. In any case, as long
as the sizes of all your vectors are representable by std::size_t, you
should be fine anyway since then size_type and std::size_t will convert
into one another without changing the values.
The former is just a lot easier to write, which is why
I'm tempted to use it instead of the latter.
Hm, poor form. It is shorter, but it looses meaning. With size_type, you
keep track as to what the variable is supposed to represent.
Btw, I have noticed that neither gcc nor VC++ require you
to write it like "std::size_t", but just "size_t" is ok
(without any 'using'). Is this also standard?
No.
Best
Kai-Uwe Bux
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:fe**********@murdoch.acc.Virginia.EDU...
Juha Nieminen wrote:
>Erik Wikström wrote:
>>Most implementation
probably uses size_t as std::vector<T>::size_type.
Can size_t be safely assumed to be of the same size and
type as std::vector<T>::size_type?
You can "safely" assume that. But it is not guaranteed. In any case, as
long
as the sizes of all your vectors are representable by std::size_t, you
should be fine anyway since then size_type and std::size_t will convert
into one another without changing the values.
> The former is just a lot easier to write, which is why
I'm tempted to use it instead of the latter.
Hm, poor form. It is shorter, but it looses meaning. With size_type, you
keep track as to what the variable is supposed to represent.
> Btw, I have noticed that neither gcc nor VC++ require you
to write it like "std::size_t", but just "size_t" is ok
(without any 'using'). Is this also standard?
No.
It will be in C++0X, because it is de facto a widespread practice
in C++98.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
P.J. Plauger wrote:
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:fe**********@murdoch.acc.Virginia.EDU...
[...]
Btw, I have noticed that neither gcc nor VC++ require you
to write it like "std::size_t", but just "size_t" is ok
(without any 'using'). Is this also standard?
No.
It will be in C++0X, because it is de facto a widespread practice
in C++98.
It's the case in C++ 98 as well if you include <stddef.h>,
rather than <cstddef>.
My own rule to date has been to only use the .h forms of the
C headers, since I know what I'm getting with them. For the
<c...forms, the standard said one thing, and all
implementations did something else, so I run the risk of
accidentally having code break when (or if) an
implementation does decide to become conform.
Just curious, but with the change in the upcoming standard,
will there be any difference between the .h headers and the
<c...headers. Or do we just have two different names for
the same thing for historical reasons.
--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
t.h...@liv.ac.uk wrote:
Is std::vector<T>::size_type guaranteed to be the same type as
std::vector<U>::size_type?
They're both guaranteed to be size_t. Which is what I use;
why obfuscate by suggesting that they might be something
different?
--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 10 Oct, 09:48, James Kanze <james.ka...@gmail.comwrote:
>
They're both guaranteed to be size_t. Which is what I use;
why obfuscate by suggesting that they might be something
different?
Thank you. I didn't want to obfuscate, I just didn't know...
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@19g2000hsx.googlegro ups.com...
P.J. Plauger wrote:
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:fe**********@murdoch.acc.Virginia.EDU...
[...]
Btw, I have noticed that neither gcc nor VC++ require you
to write it like "std::size_t", but just "size_t" is ok
(without any 'using'). Is this also standard?
No.
It will be in C++0X, because it is de facto a widespread practice
in C++98.
It's the case in C++ 98 as well if you include <stddef.h>,
rather than <cstddef>.
My own rule to date has been to only use the .h forms of the
C headers, since I know what I'm getting with them.
[pjp] Do you? The C++ Standard says that the *.h forms must
declare all names in namespace std, then hoist them to the global
namespace with individual using declarations. A few meticulous
implementations do this, but most leave the *.h forms in their
traditional forms as inherited from older C compilers. So when
you include <stdio.hyou *might* get std::printf and printf,
or you *might* get just printf.
For the
<c...forms, the standard said one thing, and all
implementations did something else, so I run the risk of
accidentally having code break when (or if) an
implementation does decide to become conform.
[pjp] Not all implementations, but most do. We can configure
our headers to fully conform or work the way our compiler
vendor customers want. Guess which way we choose.
Just curious, but with the change in the upcoming standard,
will there be any difference between the .h headers and the
<c...headers. Or do we just have two different names for
the same thing for historical reasons.
[pjp] The new rule is:
-- If you want to assuredly declare printf, include <stdio.h>
(but you might also declare std::printf).
-- If you want to assuredly declare std::printf, include
<cstdio(but you might also declare printf).
That happens to reflect the reality of *all* existing
implementations, so the next C++ Standard will actually
codify existing practice instead of trying to dictate a
practice that most vendors found they could not comply
with.
HTH,
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com t.****@liv.ac.uk wrote:
On 10 Oct, 09:48, James Kanze <james.ka...@gmail.comwrote:
>>
They're both guaranteed to be size_t. Which is what I use;
why obfuscate by suggesting that they might be something
different?
Thank you. I didn't want to obfuscate, I just didn't know...
Using vector::size_type is _not_ obfuscation. It's perfectly fine.
Moreover, as it has been discussed elsethread, there is no guarantee that
vector::size_type is std::size_t. [23.2.4/2] lists size_type as
implementation defined.
The next standard will guarantee size_type to be std::size_t.
Best
Kai-Uwe Bux
P.J. Plauger wrote:
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@19g2000hsx.googlegro ups.com...
P.J. Plauger wrote:
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:fe**********@murdoch.acc.Virginia.EDU...
[...]
Btw, I have noticed that neither gcc nor VC++ require you
to write it like "std::size_t", but just "size_t" is ok
(without any 'using'). Is this also standard?
No.
It will be in C++0X, because it is de facto a widespread practice
in C++98.
It's the case in C++ 98 as well if you include <stddef.h>,
rather than <cstddef>.
My own rule to date has been to only use the .h forms of the
C headers, since I know what I'm getting with them.
[pjp] Do you?
Probably not, but I feel like I do:-). They are, after all, the
C headers, and I know what C gives me. (I guess I think of them
more or less like I think of the Posix headers: something
outside of the language, defined in C.)
The C++ Standard says that the *.h forms must
declare all names in namespace std, then hoist them to the global
namespace with individual using declarations. A few meticulous
implementations do this, but most leave the *.h forms in their
traditional forms as inherited from older C compilers. So when
you include <stdio.hyou *might* get std::printf and printf,
or you *might* get just printf.
For the
<c...forms, the standard said one thing, and all
implementations did something else, so I run the risk of
accidentally having code break when (or if) an
implementation does decide to become conform.
[pjp] Not all implementations, but most do. We can configure
our headers to fully conform or work the way our compiler
vendor customers want. Guess which way we choose.
I can imagine.
In practice, I'm used to writing time(NULL), and not
std::time(NULL). So the risk of accident is greater if I choose
the std:: forms---I'm likely to accidentally fall back into my
old habits. If I can count on at least one of my compilers
complaining, immediately, fine; I'll quickly adjust. If I
can't, the error is likely to persist. And while I've not tried
lately, the last time I tried, neither Sun CC nor g++ (under
Solaris) complained. I've long argued that we should also have
Comeau with your library on hand, even if only as a double check
measure, but management here finds that needing to support two
compilers is already one too many.
Just curious, but with the change in the upcoming standard,
will there be any difference between the .h headers and the
<c...headers. Or do we just have two different names for
the same thing for historical reasons.
[pjp] The new rule is:
-- If you want to assuredly declare printf, include <stdio.h>
(but you might also declare std::printf).
-- If you want to assuredly declare std::printf, include
<cstdio(but you might also declare printf).
In other words, and implementation is allowed to make them the
same, but it could also implement them so that the intersection
is only the macros.
That happens to reflect the reality of *all* existing
implementations, so the next C++ Standard will actually
codify existing practice instead of trying to dictate a
practice that most vendors found they could not comply
with.
I'm not sure I like this. It means that there is still one more
thing that might work with some compilers, but not with others.
If I had my druthers, the committee would just require that both
the declarations with and without std:: be available in both
headers: that shouldn't break any existing code (or at least no
more that the current proposal would break, since that would be
a legal implementation under the current proposal), and would
mean that if it compiles with one implementation, it should
compile with all.
--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Kai-Uwe Bux wrote:
t.****@liv.ac.uk wrote:
On 10 Oct, 09:48, James Kanze <james.ka...@gmail.comwrote:
They're both guaranteed to be size_t. Which is what I use;
why obfuscate by suggesting that they might be something
different?
Thank you. I didn't want to obfuscate, I just didn't know...
Using vector::size_type is _not_ obfuscation. It's perfectly fine.
I think he took my comment too seriously:-). Using size_type
does suggest some sort of genericity or dependency on vector,
which of course isn't there unless you're using a vector with a
specialized allocator, or you're writing a template which will
work with a container with a non-standard allocator. (In
template code designed to work with all containers, I do use
size_type.)
Moreover, as it has been discussed elsethread, there is no guarantee that
vector::size_type is std::size_t. [23.2.4/2] lists size_type as
implementation defined.
I didn't see it elsewhere, but the standard definitely requires
vector<int>::size_type to be size_t. Even now.
The next standard will guarantee size_type to be std::size_t.
I don't think there is any change here. I don't know for sure
what the next version of the standard will require, but the
current one definitly requires vector::size_type to be
Allocator::size_type, and for the standard allocator,
allocator::size_type is required to be size_t. The difference
only becomes an issue if you are using custom allocators.
--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Oct 11, 1:04 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
I don't think there is any change here. I don't know for sure
what the next version of the standard will require, but the
current one definitly requires vector::size_type to be
Allocator::size_type, and for the standard allocator,
allocator::size_type is required to be size_t. The difference
only becomes an issue if you are using custom allocators.
That's what I thought, but as it turned it out that requirement was
removed for all containers except basic_string prior to the 1998
standardization.
See my article elsethread.
If you have information to the contrary, please share;
The only thing I have is my copy of ISO 14882:1998. In §20.4.1,
The default allocator, you have:
template< class T class allocator {
public:
typedef size_t size_type ;
...
} ;
But you're right that the standard doesn't seem to require it to
be used.
Not requiring its use doesn't really make sense, of
course---suppose I instantiate vector with an allocator where
size_type is an extended unsigned integer, for example---but
then, not much related to allocators makes sense.
also, if anyone has hard information about the rumours about
reversing that decision in C++0x then that would certainly
also be nice!
Agreed. It does seem strange.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Michael |
last post by:
Should i write:
for(size_t i=0;i<vec.size();i++) doSumfink();
or
for(int i=0;i<vec.size();i++) doSumfink();
fanks
mike
|
by: Johann Gerell |
last post by:
I have this iterator:
class CFileIterator : public std::iterator<std::input_iterator_tag,
const std::wstring>
{
public:
CFileIterator(const std::wstring& wildcardPath);
....
};
|
by: Aaron |
last post by:
I'm trying to get an average of a long and a std::vector::size_type, but keep
getting 0 for some reason.
I've tried the following:
float avg = some_long / some_vec.size();
float avg =...
|
by: Daniel J Watkins |
last post by:
Hi,
Some runtime memory exceptions are being exhibited with some code I've
written. Can you clarify the following with you to see if my understanding
of the principles under question are...
|
by: Chris Dams |
last post by:
Dear all,
I found out that the program
#include<vector>
using namespace std;
int main()
{ vector<int*> v(2,0);
|
by: craig |
last post by:
I've declared the following as a "vector" of "lists" using STL
vector< list<Edge*> >
I've tried many ways to add objects to this but can't figure out how to
do it. Does anyone have any tips,...
|
by: subramanian100in |
last post by:
In the standard library vector, the ctor
explicit vector::vector(size_type __n)
is declared as explicit. I am unable to get
the reason for it being declared as explicit.
Kindly clarify with an...
|
by: barcaroller |
last post by:
In the boost::program_options tutorial, the author included the following
code:
cout << "Input files are: "
<< vm.as< vector<string()
<< "\n";
Basically, he is trying to print a vector...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
