API: тип ItemsNumber заменить на size_t ?
API: тип ItemsNumber заменить на size_t ?
предложение - не критичное.
может в функциях, где передается указатель на массив(*Item), и количество элементов (ItemsNumber), тип ItemsNumber заменить на size_t ?
например FarList , Info.Menu
балуюсь тут pvs-studio на предмет 64 битных приложений. ругается как раз на них.
может в функциях, где передается указатель на массив(*Item), и количество элементов (ItemsNumber), тип ItemsNumber заменить на size_t ?
например FarList , Info.Menu
балуюсь тут pvs-studio на предмет 64 битных приложений. ругается как раз на них.
- NightRoman
- Posts: 6034
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 20 times
- Been thanked: 49 times
- Contact:
Re: глобальный слом апи.
Погодите, а в чем именно проблема-то? Этот size_t - та еще помощь.. неудобно с ним порой работать.
Re: глобальный слом апи.
вот часть возможных замечаний.
http://www.viva64.com/ru/d/0036/print/
http://www.viva64.com/ru/d/0066/print/
http://www.viva64.com/ru/d/0040/print/
по сути - не "красиво" использовать не memsize типы при работе с памятью. ошибки могут быть при работе откомпилированного 64 битного кода.
с одной стороны - маловероятно что такие большие массивы будут передаваться в фар.
но если начинаешь у себ приводить к "хорошему стилю", спотыкаешься на вызовах функций фара
http://www.viva64.com/ru/d/0036/print/
http://www.viva64.com/ru/d/0066/print/
http://www.viva64.com/ru/d/0040/print/
по сути - не "красиво" использовать не memsize типы при работе с памятью. ошибки могут быть при работе откомпилированного 64 битного кода.
с одной стороны - маловероятно что такие большие массивы будут передаваться в фар.
но если начинаешь у себ приводить к "хорошему стилю", спотыкаешься на вызовах функций фара
- NightRoman
- Posts: 6034
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 20 times
- Been thanked: 49 times
- Contact:
Re: глобальный слом апи.
Может, дело вкуса, но из моего опыта использовать unsigned для индексов чего бы то ни было - это ставить себе грабли тут и там. Нужны отрицательные значения для таких переменных и все тут. При адресации памяти - почему нет? address, где i < 0 -- прекрасно, если это именно так и задумано. При итерации по массиву от конца к началу - почему нет? Надо остановиться, когда i < 0, при unsigned это будет затруднительно. Или задать "незаданный" индекс как -1, а не макс-намбер, и проверять на "незаданность" просто как i < 0, а не i == макс-намбер (гораздо легче ошибку сделать, кстати). И так далее, и так далее.
И как следствие, тот, кто задает количества как unsigned, тот себе злодей, имхо (и пользователям своим тоже, если это АПИ или библиотека какая).
И как следствие, тот, кто задает количества как unsigned, тот себе злодей, имхо (и пользователям своим тоже, если это АПИ или библиотека какая).
Re: глобальный слом апи.
поскольку оно воспринимается в штыки, да и часть переделок (если в фаре не использовать приведение типов) ведет просто к громаднейшим переделкам трогать не стоит. пока....DrKnS wrote:Запросто. Давай патч(или хотя бы список всех таких мест).
- DrKnS
- Posts: 5813
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 10 times
- Been thanked: 346 times
Re: глобальный слом апи.
Оно воспринимается сугубо положительно. Там уже в половине мест size_t.sonar wrote:поскольку оно воспринимается в штыки
Сейчас надо максимально окультурить api, т. к. потом будет поздно.sonar wrote:если в фаре не использовать приведение типов
Использовать приведение типов внутри фара - вполне подходящий вариант, внутренние переделки будут потом.
Так что стоит.
Только править надо аккуратно, т. к. там в некоторых местах внезапно встречается прелестный дизайн вида "а если передать в качестве индекса -1, то это типа текущий элемент".
- NightRoman
- Posts: 6034
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 20 times
- Been thanked: 49 times
- Contact:
Re: глобальный слом апи.
size_t должен использоваться там, где речь идет о размерах памяти, он именно для этого и был введен. Использовать его для любых количеств, а не количества байт - это использовать не по назначению - раз, огребать себе неудобства, о которых я писал - два. Там, где речь о памяти, обязательно давайте юзать size_t. А там, где речь о количестве объектов, давайте int (или что еще, но не unsigned и всяко не size_t тип).
"Давайте" означает "если б я была царица". А уж как вы дадите - вам видней.
"Давайте" означает "если б я была царица". А уж как вы дадите - вам видней.
-
- Posts: 3632
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 1 time
- Been thanked: 12 times
Re: глобальный слом апи.
Согласен с NightRoman. Не надо использовать платформенно-зависимые целые, где по смыслу, ожидается количество. Не зря же в x64 int остался 32-х разрядным.
-
- Posts: 3632
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 1 time
- Been thanked: 12 times
- DrKnS
- Posts: 5813
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 10 times
- Been thanked: 346 times
Re: глобальный слом апи.
Вот интересно, почему strlen() возвращает size_t? Почему все STL-контейнеры хранят количество элементов в size_t? Почему в Windows API для описания "количества" повсеместно используется DWORD?NightRoman wrote:А там, где речь о количестве объектов, давайте int (или что еще, но не unsigned и всяко не size_t тип).
Их проектировали неучи, не владеющие истинным Дао?
Чукча, извиняюсь, писатель? Роману не по нраву беззнаковость, а не размерность.Max Rusov wrote:Согласен с NightRoman. Не надо использовать платформенно-зависимые целые, где по смыслу, ожидается количество. Не зря же в x64 int остался 32-х разрядным.
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Re: глобальный слом апи.
А я вот тоже size_t не люблю, и слово такое мне не нравится. Другое дело, что когда размер области памяти возвращают - оно должно быть прекрасно и удивительно и 32 битами не ограничиваться. (unsgined __int64?)
P.S. И это, не надо путать апи и его реализацию. Если оно "в теории" лучше, пусть хотя бы в теории.
P.S. И это, не надо путать апи и его реализацию. Если оно "в теории" лучше, пусть хотя бы в теории.
Никто не знал, а я...
-
- Posts: 3632
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 1 time
- Been thanked: 12 times
Re: глобальный слом апи.
Windows использует LLP64 модель, поэтому логично ей следовать. Ведь Count обычно используется как верхняя граница цикла. Если он станет 64-х разрядным, то и итератор придется делать 64-х разрядным - далее везде. Это приводит к массе совершенно бессмысленной работы.