unsigned u = 0;
    int i = 0;
    u = i;
    i = u;
    // msvc80sp1 уровень предупреждений 4 — ни одного варнинга. Хотя оба из присваиваний могут вызвать проблемы...

    std::vector<int> v (3);
    for (size_t i = v.size() - 1; i >= 0; --i)
        std::cout << v[i];

я считаю, что правильнее внимательнее относиться к коду, а не пытаться компенсировать лень использованием знаковых типов

знаковые типы просто-напросто чаще "прощают" беспечное отношение к коду

#ifdef _DEBUG
typedef int MYLIB_SIZE;
#else
typedef unsigned int MYLIB_SIZE;
#endif

void foo(MYLIB_SIZE size) {
  assert(size >= 0);
}

AL>>>unsigned someCounter = 99;
AL>>>while(--someCounter >= 0)
AL>>>{
AL>>>  //ooops! infinite loop here
AL>>>} 
AL>>>

int a[N];
int* p = a + N;

while (--p >= a)
  *p = 0;

int a[N];
int* p = a + N;

while (p > a)
  *--p = 0;

unsigned someCounter = 99;
while(someCounter > 0) {
  --someCounter
  ...
}

unsigned someCounter = 99;
while(someCounter-- > 0) {
  ...
}

unsigned a=...;   
unsigned b=...;

a+=b;

if( a<b ) 
  { //overflow  
   ... 
  }

bool CharIsXXX(char c)
 {
  static const bool table[256]={...};

  return table[(unsigned char)c];
 }

АТ>Во-вторых, в обычной арифметике в общем случае при вычитании двух N-битных чисел получается N+1-битное число. Это относится в одинаковой мере и к знаковым и к беззнаковым типам. То использование знаковых типов, которое пропагандируют тут противники беззнаковых, это в большинстве своем попытка закрыть глаза на существование этой проблемы на основании того, что работая рядом с "центром" диапазона знаковых чисел мы якобы находимся в болшей безопасности, чем работая рядом с "краем" беззнакового диапазона. Это ложная безопасность. С точки зрения достижения такой безопасности, всем следовало бы пользоваться самым большим знаковым типом ('long' или в C99 'long long') и это было бы самым "безопасным" и "защищенным от ошибок" вариантом. А все остальные типы объявим ненужными, предназначеннными для "экономии битов" в рамках разных (и, без сомнения, преждевременных) оптимизаций.

void f(int i)
{
  assert(i > 0);
  // ...
}

// во всех 100 местах, где вызывается f()
assert(x > y)
f(x - y);

unsigned someCounter = 99;
while(--someCounter >= 0)
{
  //ooops! infinite loop here
}

class Line
 {
   int a,b; // [a,b] a<=b

  public:

   Line(int a_,int b_) { if( a_<=b_ ) a=a_,b=b_; else a=b_,b=a_; }

   // Нормализация хороша ещё и тем, что облегчает реализацию других операций с отрезком

   unsigned length() const { return unsigned(b)-unsigned(a); }
 };


int a,b,c,d;

Line(a,b).length() < Line(c,d).length()

Теперь предлагаю посмотреть на это дело с другой стороны.
В конце концов переносимость C++ программ -- это миф.
Попробуйте написать сложную программу, которая легко переживёт перенос на платформу сильно другой разрядности. Скажем из 32-бит в 16?
Нифига у вас не выйдет. Всё равно переполнения будут вас преследовать и всякие другие проблемы.

int Count;
...
assert(Count >= 0);

E>P.S. Андрею Тарасевичу — большой респект

struct bitz
{
    unsigned u : 1; // принимает значения 0 и 1
    int      i : 1; // принимает значения... сюрприз! 0 и -1, потому что старший (единственный) бит - знаковый
};

Вот скажем такая простая штука, как unsigned(-1) % 10 уже равна неизвестно чему)

R>    unsigned u = 0;
R>    int i = 0;
R>    u = i;
R>    i = u;
R>    // msvc80sp1 уровень предупреждений 4 — ни одного варнинга. Хотя оба из присваиваний могут вызвать проблемы...
R>

R>    std::vector<int> v (3);
R>    for (size_t i = v.size() - 1; i >= 0; --i)
R>        std::cout << v[i];
R>

    std::vector<int> v (3);
    for (size_t i = v.size() - 1; i!=size_t(-1) ; --i)
        std::cout << v[i];

    std::vector<int> v (3);
    for (size_t i = v.size() ; i-- ;)
        std::cout << v[i];

R>

my_vector vec(10);
//vec[-1] == vec[9]

bool ab_less_than_cd = b-a < d-c; // интуитивно понятное (справедливо только для signed)

bool ab_less_than_cd = b+c < a+d; // для случая unsigned, избавились от вычитания... что за величины такие странные: b+c? a+d?

bool ab_less_than_cd = (int)(b-a) < (int)(d-c); // мы утверждаем, что разность - знаковая величина.
// Окей, как насчёт unsigned short или unsigned long? Нужно ввести некий signed_cast, приводящий к знаковому типу подходящего размера

bool ab_less_than_cd = a<b && (d<=c || b-a<d-c) || b<=a && (c<d || c-d<=a-b); // код, свободный от граничных условий... ничерта не понятный и возможно, с ошибками

inline unsigned length(unsigned x, unsigned y){return x>y?x-y:y-x;}

bool ab_less_than_cd = length(a, b) < length(c, d);

bool ab_less_than_cd = b+c < a+d; // для случая unsigned, избавились от вычитания... и величины не более странные, чем 
b-a, d-c

4.10. Советы
...
[18] Избегайте беззнаковой арифметики; § 4.4.
[19] С подозрением относитесь к преобразованиям из signed в unsigned и из unsigned в signed; § В.6.2.6.

void SetWeights(int Count, double Weight)
{
  assert(Count > 0);
  assert(Weight > 0.);
  ...
}

#ifdef _DEBUG
  ...
#else // Release-конфигурация
  #define assert(Cond) __assume(Cond)
#endif

АТ>>int a[N];
АТ>>int* p = a + N;

АТ>>while (--p >= a)
АТ>>  *p = 0;

int f1(int)
{
    return -1;
}

unsigned f2(unsigned)
{
    int i = -1;
    return i;
}

unsigned f3(unsigned i, unsigned i2)
{
    return i - i2;
}

int main()
{
    int i = -1;

    f1(i);
    f2(i);
    f3(1, 2);
}

bool f5();

int main()
{
    if (-1 == f5());
}

void f(unsigned x)
{
    if ((int)x < 0) // something bad
}

void f(int i)
{
  if(i < 0 || i >= cont.size())
     return;
}

void f(unsigned i)
{
  if(i >= cont.size())
     return;
}

void func(char *p,size_t s)
 {
  for(int i=0; i<s ;i++) p[i]=0;
 }

АТ>int a[N];
АТ>int* p = a + N;

АТ>while (p > a)
АТ>  *--p = 0;
АТ>

АТ>unsigned someCounter = 99;
АТ>while(someCounter > 0) {
АТ>  --someCounter
АТ>  ...
АТ>}
АТ>

int a[N];
for( int i = N - 1; i >= 0; i-- ) {
    a[i] = 0;
}

unsigned f(unsigned n, int s)
{
    . . . ?
}

int i;
int size;
assert( 0 <= size );

if( 0 <= i && i < size ) {
    Do1();
}

if( unsigned( i ) < unsigned( size ) ) {
    Do2();
}

E>про то и вопрос. От чего в языке фортран или там паскаль массивы было удобно итерировать знаковым индексом, а в C++ + STL стало так трудно и опасно?

var a: array[-1..1] of whatever;
. . .
a[-2] = 0;

E>Действительно и там и там нельзя сделать "лишний шаг"

int i = . . .;
if(i >= 0)
{
    a[i] = 123; // ладно, так можно...
}

T* p = . . .;
if(p >= first) // Всем искренне желаю, чтоб это всегда выполнялось.
{              // Ибо иначе UB. Причем есть вполне реальная угроза аппаратного исключения
    *p = 123;  // при загрузке в регистр сомнительного указателя (вдруг массив попал в самое начало странички).
}              // Или ОС обругает за выход за границу дозволенной памяти (хотя это тоже маловероятно).

E>Забавно, кстати, что сами авторы STL пожоже это тоже чувствовали. Потому что понаписали всяких for_each

E>В принципе я их понимаю. Так как простой for() при использовании итераторов и unsigned индексов действительно становится неудобным и опасным

for(int i = 0; i < n; i += k)
{
    . . . a[i] . . .
}

E>Ну правда может

E>int step = 15;
E>for( int i = array.size() - 1; i >=0; i -= step )
E>    array[i] = i;
E>

E>А что ты будешь делать в случае unsigned?

unsigned step = 15;
for(unsigned i = array.size() - 1; i < array.size(); i -= step)
  array[i] = i;

unsigned step = 15;
for(unsigned i = array.size() + nstep - 1; i >= nstep; ) {
  i -= step;
  array[i] = i;
}

if (array.size() > 0) {
  unsigned step = 15;
  for(unsigned i = array.size() - 1; ; i -= nstep) {
    array[i] = i;
    if (i < nstep)
      break;
  }
}

unsigned update = 5;
unsigned stored = 5;
unsigned tolerance= 10;
bool const changed 
            = update > stored + tolerance
              ||
              update < stored - tolerance;

R>>

АТ>

R>Хороший пример

R>

unsigned int i = 3;
unsigned int j = 5;
int r = i-j;
std::cout << "r = " << r << std::endl;

r = -2

E>>unsigned int i = 3;
E>>unsigned int j = 5;
E>>int r = i-j;
E>>std::cout << "r = " << r << std::endl;
E>>

E>>r = -2
E>>

4.7.3
If the destination type is signed, the value is unchanged if it can be represented in the destination type (and
bit-field width); otherwise, the value is implementation-defined.

• затрачу время на собственно конвертацию;
  
• потрачу в два раза больше времени на вычитание;
  
• не смогу удобно свалить производную в файл и посмотреть Paint’ом.