язык Си массивы

[_Bers]

Сообщение от alexzk

Потому что я не вим мастер, и пишу на форуме . В иде я бы конечно прочел варнинги компилера и / или статик анализера и исправил - не велика беда.

не нужно видеть ворнинги,
что бы понимать:
размер массива не может быть отрицательным.

Сообщение от alexzk

Кстати, вы пробовали в qt проекте использовать std ? - ад адов, у кт все размеры int - я задолбался приводить типы там

в qt вообще многое через одно место сделано.

[Croessmah]

Сообщение от _Bers

на чем было основано их утверждение.

Думаю, имеется ввиду разница между

for(int i = 0; i < size; ++i) {
  //arr[i]
}

и

for(int *pb = arr, *pe = arr + size; pb != pe; ++pb) {
   //*pb
}

но по кускам из книги судить сложно,
нужно видеть намного больше текста.

[_Bers]

Сообщение от Croessmah

C++ Core Guidlines говорит так:

Reason To avoid signed/unsigned confusion. To enable better optimization. To enable better error detection.

про оптимизацию как то очень сомнительно.
хотелось бы где нибудь более развернутый ответ-подтверждение их тезиса.

про диагностику ошибок - это бред.

они собрались диагностировать ошибки,
которых вообще не было бы,
не используй они знаковых там,
где их быть не должно по смыслу.

это называется самому себе создать проблему.
а потом героически её решать.

[Croessmah]

не используй они знаковых там,
где их быть не должно по смыслу.

В этом есть ряд проблем.
Например, разница двух указателей - ptrdiff_t, т.е. тип знаковый,
скорее всего, по размеру это знаковый size_t.
То есть, создав массив с количеством элементов большим,
чем влезит в тип ptrdiff_t, то, очевидно, получаем проблему.
Многие реализации просто не дают создать массив c
количеством элементов больше, чем влезит в ptrdiff_t.
Итого, у нас есть размер с size_t, но использовать его мы не можем по полной.
Например, многие реализации векторов/строк основаны
на трех указателях, и определяют размер как

size_type size() const noexcept //size_type скорее всего будет size_t
{
   return finish - start;//разница указателей - ptrdiff_t
}

По поводу бреда в личку к Страуструпа и в коммитет. Core Guidelines в разработке.

[_Bers]

Сообщение от Croessmah

В этом есть ряд проблем.
Например, разница двух указателей - ptrdiff_t, т.е. тип знаковый,
скорее всего, по размеру это знаковый size_t.
То есть, создав массив с количеством элементов большим,
чем влезит в тип ptrdiff_t, то, очевидно, получаем проблему.
Многие реализации просто не дают создать массив c
количеством элементов больше, чем влезит в ptrdiff_t.
Итого, у нас есть размер с size_t, но использовать его мы не можем по полной.

в действительности существуют
зависящие от реализации ограничения
на размеры различных контейнеров.

но их не существует для массивов.

стандарт говорит,
что в случае переполнения ptrdiff_t,
поведение не определено.

[Croessmah]

Сообщение от _Bers

стандарт говорит,
что в случае переполнения ptrdiff_t,
поведение не определено.

Именно. Избавившись от одной проблемы - приобретем другую.
Лично я вопросы использования signed/unsigned решаю
для каждого конкретного случая отдельно.
Слепое следование какому-то одному правилу только навредит.

[_Bers]

Сообщение от Croessmah

Именно. Избавившись от одной проблемы - приобретем другую.
Лично я вопросы использования signed/unsigned решаю
для каждого конкретного случая отдельно.
Слепое следование какому-то одному правилу только навредит.

вы не поняли.

это - не проблема знаковости/беззнаковости
индексов для массивов.

это - проблема адресной арифметики указателей вообще.

тут ещё нужно постараться сделать так,
что бы вообще нарваться на переполнение ptrdiff_t

вот смотрите,
я использовал даже не std::size_t,
а unsigned

причем, даже не максимальный:

#include <iostream>
#include <limits>

char arr[4294967294];

int main()
{
    std::cout <<"максимальный размер массива на данной платформе составляет " 
        << std::numeric_limits<unsigned>::max() 
    << "байт\n";
}

/tmp/ccvIzVsE.o: In function `__static_initialization_and_destruction_0':
/usr/include/c++/5/iostream:74:(.text.startup+0x45): relocation truncated to fit: R_X86_64_32 against `.bss'
/usr/include/c++/5/iostream:74:(.text.startup+0x54): relocation truncated to fit: R_X86_64_32 against `.bss'
collect2: error: ld returned 1 exit status

можете попробовать использовать положительный дипазон int:

char arr[2147483646];

Error(s):
Kill signal (SIGKILL)

мы видим - проблема глубже,
чем просто переполнение ptrdiff_t

фактически, всплывают нюансы,
которые не дают нам спокойно работать с большими массивами.

в таком ключе можно сказать,
что и какого нибудь 16 битного инта будет за глаза.

но если так,
то это должен быть беззнаковый 16 битный инт.

речь не о слепом следовании правилам.
а о здравом смысле.

[_Bers]

Сообщение от Croessmah

По поводу бреда в личку к Страуструпа и в коммитет. Core Guidelines в разработке.

бред является бредом безотносительно тому,
что об этом думает Страуструп и Ко.

не помню,
что бы они хоть как то раскрыли бы этот момент.

весьма примечательно,
что язык с++ противоречит их собственным рекомендациям.

стандарт говорит:
в качестве типа данных для индексов массива
используется std::size_t

это называется:
"давайте юзать для индексов std::size_t,
а всем остальным скажем: юзайте инт"

худшее, что может сделать мыслящий человек,
это слепо следовать за авторитетами.

[Croessmah]

Сообщение от _Bers

тут ещё нужно постараться сделать так,
что бы вообще нарваться на переполнение ptrdiff_t

Вы же сами сказали

Сообщение от _Bers

диапазон допустимых положительных значений
получается в два раза меньше

а теперь пишите, что этого еще нужно добиться.

Kill signal (SIGKILL)

Стек маленький был.

речь не о слепом следовании правилам.
а о здравом смысле.

А зддравый смысл подсказывает, что надо думать самому.

Кстати, вот еще глупцы такие же правила написали в Google C++ Style Guide:
https://google.github.io/styleguide/...#Integer_Types
Люди, не дружащие со здравым смыслом (среди них Александресску, Саттер, Страуструп, Майерс и т.д.), тоже говорят о том же самом:
https://www.youtube.com/watch?v=Puio5dly9N8#t=733

Сообщение от _Bers

не помню,
что бы они хоть как то раскрыли бы этот момент.

Danger – unsigned types used here!
Why are unsigned integers error prone?
Если просто обобщить, то увеличивается число возможных ошибок,
поэтому обращение с беззнаковыми числами требует
больших усилий и большей осторожности.
Но это относится к любому аспекту языка,
который чреват ошибками, например, голым указателям.

[Croessmah]

Сообщение от _Bers

худшее, что может сделать мыслящий человек,
это слепо следовать за авторитетами.

Еще большей глупостью является слепое следование за не авторитетом.