Latest post of the previous page:
Windows использует LLP64 модель, поэтому логично ей следовать. Ведь Count обычно используется как верхняя граница цикла. Если он станет 64-х разрядным, то и итератор придется делать 64-х разрядным - далее везде. Это приводит к массе совершенно бессмысленной работы.API: тип ItemsNumber заменить на size_t ?
Re: глобальный слом апи.
size_t как раз и нужен в этой дебильной модели. иначе хватило бы long.Max Rusov wrote:Windows использует LLP64 модель, поэтому логично ей следовать.
лично я согласен с тем что нужно везде использовать size_t. Считать что у вас отрицательное число элементов чего то - это нонсенс.
Ну, а если совсем плохо, то тогда использовать ssize_t.
- NightRoman
- Posts: 6184
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Re: глобальный слом апи.
Все, что перечислено, я считаю далеко неидеальным и с тяжелым наследием и кармой. Проектировали неучи? Риторический вопрос. Кроме того, они проектировали не в вакууме, а с учетом факторов, о которых мы можем не знать, а потому не обладать правом грамотной критики.DrKnS wrote:Вот интересно, почему strlen() возвращает size_t? Почему все STL-контейнеры хранят количество элементов в size_t? Почему в Windows API для описания "количества" повсеместно используется DWORD?
Их проектировали неучи, не владеющие истинным Дао?
В .NET API, который проектировался гораздо позже, чем все перечисленное, везде в коллекциях количество и индексация реализованы через int (а именно, Int32). Длина строк - тоже. Тоже интересно, почему? Может, уже с учетом предыдущего опыта?
- NightRoman
- Posts: 6184
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Re: глобальный слом апи.
Нет, это математика. Отрицательные числа вообще почему есть? Потому что есть понятие разности. Если первое количество меньше второго, появляется отрицательное число при разности. Это количество? В каком-то смысле - да. В математическом. А в программном если это будет все задано еще unsigned типом, начинаются еще нюансы и ошибки.GrAnD wrote:Считать что у вас отрицательное число элементов чего то - это нонсенс.
- NightRoman
- Posts: 6184
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Re: глобальный слом апи.
Вобщем, я за то, чтобы количества элементов в коллекциях разного рода в Фар АПИ были заданы, как int. Все это для отображения в UI, в конечном итоге. Приведите пример хоть чего-нибудь в UI, чтобы оно было больше 2 миллиардов с копейками и при этом имело практический смысл. Мне такое в голову не приходит. И дело тут не в мощности компов и размерах памяти машин. Дело в человеческих возможностях, нет никакого смысла вываливать в UI что-то, что около 2 миллиардов или больше, человек это не асилит.
Re: глобальный слом апи.
Прошу модераторов отпочковать этот оффтопик в соответствующую тему.
При использовании signed типа выражающего количество - увеличивается число проверок.
Ошибки происходят не из-за типа, а из-за программиста. Тип же должен выражать логическую сущность объекта, и если что то не бывает отрицательным для него надо использовать беззнаковый тип.NightRoman wrote:А в программном если это будет все задано еще unsigned типом, начинаются еще нюансы и ошибки.
При использовании signed типа выражающего количество - увеличивается число проверок.
Code: Select all
void do_something(size_t index) {
if (index < array.size())
...
}
void do_something(int index) {
if (index >=0 && index < array.size())
...
}
- NightRoman
- Posts: 6184
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Re: глобальный слом апи.
Спорно. В одном месте увеличивается, в другом уменьшается. Ты привел одно место. Я могу привести другие. Но не хочется. У меня нет цели кого-то в чем-то переубедить.При использовании signed типа выражающего количество - увеличивается число проверок.
Да, и с некоторыми типами некоторые программисты совершают больше ошибок. Я совершаю больше ошибок, когда работаю с unsigned. Это просто факт из моего опыта. Потому я и не хочу unsigned в Фар АПИ для количеств. У других другой опыт, хорошо. Делимся опытом, взвешиваем плюсы и минусы (каламбур, однако).Ошибки происходят не из-за типа, а из-за программиста.
Re: глобальный слом апи.
в атаче патч на сборку 1930.
исправлены места в api где в структурах передается указатель и количество.
исправлены места в api где в структурах передается указатель и количество.
- Attachments
-
- far1930.7z
- (1.97 KiB) Downloaded 133 times
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: глобальный слом апи.
Спорить не буду. Я тоже раньше так считал, пока не начал портировать под x64 проект на >20M исходников. Понимание приходит с опытом.GrAnD wrote:size_t как раз и нужен в этой дебильной модели. иначе хватило бы long
Re: глобальный слом апи.
О том, что нужно активно использовать MEMSIZE типы я понял, когда портировал под x64 несколько библиотек. Понимание точно приходит с опытом.Max Rusov wrote:Спорить не буду. Я тоже раньше так считал, пока не начал портировать под x64 проект на >20M исходников. Понимание приходит с опытом.
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: глобальный слом апи.
Когда речь идет о размере памяти - несомненно. Когда о количестве - нет.GrAnD wrote:...нужно активно использовать MEMSIZE типы ...
Re: API: тип ItemsNumber заменить на size_t ?
Я понимаю.
Max Rusov адепт паскаля, NightRoman - C#.
Мы разговариваем немного на разных языках. Но когда дело доходит до С++ с банальным STL ваши аргументы теряются.
собирая под x64 в цикле:
вы получите как минимум 2 ворнинга на счет знаковости и размерности. И это вам скажу не я, со мной можно спорить, а компилятор. Поэтому давайте не будем теоретизировать а исходить из реалий жизни.
Max Rusov адепт паскаля, NightRoman - C#.
Мы разговариваем немного на разных языках. Но когда дело доходит до С++ с банальным STL ваши аргументы теряются.
собирая под x64 в цикле:
Code: Select all
vector<Obj> array;
for (int i = 0; i < array.size(); ++i)
...
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: API: тип ItemsNumber заменить на size_t ?
А вот если бы Count (Size) _не_ был size_t, то все было бы хорошо. Т.е. твой пример как раз подтверждает ошибочность использования данного типа. Но, согласен, все зависит от библиотек. Т.е. теперь вы будете везде в исходниках менять int на size_t? Удачи.
- NightRoman
- Posts: 6184
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Re: API: тип ItemsNumber заменить на size_t ?
Вовсе не на разных. С++ у меня основной язык по работе. Да и Фарнет представляет из себя раппер всего АПИ Фара, написанный на C++/CLI вообще-то. Это врочем означает, что рапнуть придется один раз и забыть (еще раз под Фар 3). Остальное под Фар я пишу на C# и там будет все int, и это хорошо.GrAnD wrote:Max Rusov адепт паскаля, NightRoman - C#.
Мы разговариваем немного на разных языках. Но когда дело доходит до С++ с банальным STL ваши аргументы теряются.
Last edited by NightRoman on Thu 24 Mar, 2011 10:21, edited 1 time in total.