size-t

问题 This question already has answers here : C standard regarding sizeof overflowing size_t (1 answer) What is the maximum size of an array in C? (7 answers) Can calloc() allocate more than SIZE_MAX in total? (7 answers) Closed 1 year ago . Is size_t guaranteed to be large enough to represent size of any type? According to this reference: size_t can store the maximum size of a theoretically possible object of any type (including array). This is generally a reliable reference but I could not find

问题 Do I need to use size_t always when indexing an array even if the array is not big enough to exceed the size of an int? It's not a question about when I should use size_t . I just want to know if, for example, a program having 2GB of available memory (all of these fields can be indexed by an int32) but with this memory being (virtual memory) assigned to the "fields" 14GB - 16GB of the computer's RAM. Would it always fail when indexing the memory if I used an int32 instead of a size_t (or an

问题 According to C++ - should you size_t with a regular array? § 18.2 6 The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object. I don't understand why this guarantees a type size_t to be big enough for an array index or big enough to represent the number of elements in an array. For example: int array[1000]; for (size_t i = 0; i < 1000; ++i) { } It seems unrelated to me why a "large enough number to contain the size in

问题 This question already has answers here : What's the best way to do a reverse 'for' loop with an unsigned index? (20 answers) Closed 5 years ago . When I put the following in my program: for (size_t i = VectorOfStructs.size()-1; i > 0; i--) It works correctly but does "i" will never equal 0. So, I cannot access the first element (VectorOfStructs[0]). If I change it to: for (size_t i = VectorOfStructs.size()-1; i > -1; i--) The program doesn't even enter the for loop! But, if I change it to the

问题 So I'm using size_t instead of int in any indexing for loop to prevent negative indices. But when counting down, this leads to an overflow: for (size_t i = 10; i >= 0; --i) { // Do something, f.ex. array[i] = i } What would be a nice way to prevent this? Using int instead? Using i == 0 as the termination condition? (This would however not work if I need the 0) I'd appreciate any feedback! 回答1: for (size_t i = 10; i <= 10; --i) // do something When overflow do happens, it will round to the

问题 So I'm using size_t instead of int in any indexing for loop to prevent negative indices. But when counting down, this leads to an overflow: for (size_t i = 10; i >= 0; --i) { // Do something, f.ex. array[i] = i } What would be a nice way to prevent this? Using int instead? Using i == 0 as the termination condition? (This would however not work if I need the 0) I'd appreciate any feedback! 回答1: for (size_t i = 10; i <= 10; --i) // do something When overflow do happens, it will round to the

来源： https://stackoverflow.com/questions/40807833/sending-size-t-type-data-with-mpi

问题 I'm refactoring a library and trying to get rid of many gcc warnings. The big part of these warning are about signed / unsigned comparison and are related to the usage of size_t . The library works on 64 bit Linux systems. A programmer used -1 as the special value similar to std::string::npos . There are many places in the library where code looks like this: class AnnotationBase { public: size_t m_offset = -1; size_t m_length = -1; } ... AnnotationBase foo(const std::string& text, const

问题 I'm refactoring a library and trying to get rid of many gcc warnings. The big part of these warning are about signed / unsigned comparison and are related to the usage of size_t . The library works on 64 bit Linux systems. A programmer used -1 as the special value similar to std::string::npos . There are many places in the library where code looks like this: class AnnotationBase { public: size_t m_offset = -1; size_t m_length = -1; } ... AnnotationBase foo(const std::string& text, const

问题 I'm investigating a standard for my team around using size_t vs int (or long , etc). The biggest drawback I've seen pointed out is that taking the difference of two size_t objects can cause problems (I'm unsure of specific problems -- maybe something wasn't 2s complemented and the signed/unsigned angers the compiler). I wrote a quick program in C++ using the V120 VS2013 compiler that allowed me to do the following: #include <iostream> main() { size_t a = 10; size_t b = 100; int result = a - b