= Сообщение: 60 из 1947 =========================================== RU.BINKD = От : Yuri Myakotin 2:5020/4441.1 18 Oct 13 18:09:18 Кому : Pavel Gulchouck 18 Oct 13 18:09:18 Тема : То ли лыжи не едут... FGHI : area://RU.BINKD?msgid=2:5020/4441.1+5261410f На : area://RU.BINKD?msgid=2:463/68+52611d4f = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hello Pavel!
Friday October 18 2013 14:36, Pavel Gulchouck wrote to Yuri Myakotin:
PG> Заранее неизвестно, какие знают, а какие нет. PG> Сейчас может не знать, а в следующей версии уже узнать, и будет ошибка PG> компиляции. В MSVC в подобном случае просто лишний варнинг на предмет переопределения выйдет и все.
PG> Или вот, как показал Роман, в VC200 _findfirst() PG> возвращает long - если прописать intptr_t, там будет warning, а PG> возможно, и крэш, если вдруг где-то окажется, что long 64-битный, а PG> intptr_t 32-битный. Hу как вариант - использовать собственный тип, и сделать его через кучку дефайнов для разных компиляторов и режимов.
YM>> И везде при работе с размерами использовать тип size_t, а не int. PG> Тоже плохо. PG> Например, у fseek() второй параметр именно long, а никак не size_t. Это тоже не тот случай - там 2 отдельных функции, у которых четко заданы размеры параметров и они не зависят от режима компилятора - _fseek() и _fseek64() (второй на практике нужен для работы с 4+гб файлами онли)
PG> Не использовать int для хэндлов - очень уж радикально. PG> Функции open()/read()/write()/close() используют именно int, и это PG> закреплено в стандарте ANSI C. Hу они-то да. Я имел в виду winapi тип HANDLE. Который в 64бит уже совсем не int.
See all in Hell, Yuri --- Мессагомаратель 1.1.5-b20110320 * Origin: Убей человека. Прежде всего в самом себе. (2:5020/4441.1)
