Re: sorting 5million minute data: choose std::list or std::vector
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:kJWdnYasP_suWMTQnZ2dnUVZ8oCdnZ2d@giganews.com...
On 14/02/2011 22:38, Ian Collins wrote:
On 02/15/11 11:29 AM, Paavo Helde wrote:
Pete Becker<pete@versatilecoding.com> wrote in news:2011021415103940206-
pete@versatilecodingcom:
On 2011-02-14 14:03:02 -0500, Paavo Helde said:
I would certainly prefer std::string to use a signed type for
size_type.
For example, the npos value -1 would be something much more concrete
and
would be representable in any signed type, regardless of whether the
string::size_type is 32 or 64 bit.
I don't get the point here. -1 is representable in every unsigned type.
It doesn't matter whether the underlying size_type is 32 or 64 bits.
#include<string>
#include<iostream>
int main() {
std::string s = "abc";
// unsigned used because "indexes are not negative"
unsigned int k = s.find('x');
if (k==s.npos) {
std::cout<< "ok\n";
} else {
std::cout<< "FAIL\n";
}
}
This works fine if size_type is the same size than unsigned int (e.g.
32bit), but fails in a common 64-bit compilation.
Even worse, if you were to use unsigned long, it will work on Unix and
Unix like 64 bit systems, but fail on windows.
If npos was signed and -1, then this would work fine with "int k",
regardless of the size of std::string::size_type. Actually, it seems to
work fine with "int k" even now in a 64-bit MSVC compilation, but this
involves unsigned -> signed conversion of an out-of-range value and is
thus implementation-defined behavior.
Currently the correct solution is to use std::string::size_type instead
of int or unsigned int. However, this is an extra piece of detail to
follow and not so easy to get correct at first attempt. If I know that
my
app is only dealing with ordinary strings, easily addressable by a plain
int, why should I need to take care about such details?
I've often wondered why std::string find doesn't return an iterator, to
be consistent with std::find and container find methods. Then there
would be no need for std::string::npos.
What's the big deal? Just use std::string::size_type (I do). On a
related note typedef is a powerful C++ tool and a decent C++ programmer
should be using it a lot (I do).
People in the "use int everywhere" camp are lazy fuckers who no doubt
prefer "int" because it only involves typing 3 characters .. oh no teh
source codez doesn't fit in my editor windowz.. must use "int".
On the contrary its people who use STL everywhere who are lazy.
Do you think you alone are the only person who uses typedef? You didn't even
know what it meant a month a go ref your reply to the following:
<quote>
You suggest you know assembly so surely you know how you create a class
type in ASM. You simply typedef the construct in whatever segment you
choose.
What the f**k are you talking about?
</quote>
You are in the use STL everywhere camp because you feel it is tried and
tested and safe and it often removes the burden of responsibility.
Personally I normally use unsigned int for array indexing but I don't think
this is a 'one solution for all situations'. You seem to prefer the 'one
solution for all situations' way of thinking i.e: always use std::vector,
always use std::string, arrays are always zero based indexed. This is a
person who can't be bother to check for bounds or do memory allocation and
IMO is a lazy thinker.