Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.BINKD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.BINKD с датами от 14 Jul 13 17:53:22 до 25 Mar 24 22:17:00, всего сообщений: 1919
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 82 из 1919 =========================================== RU.BINKD =
От   : Roman Trunov                     2:5022/2           05 Nov 13 13:13:24
Кому : Pavel Gulchouck                                     05 Nov 13 13:13:24
Тема : То ли лыжи не едут...
FGHI : area://RU.BINKD?msgid=2:5022/2+52793e1d
На   : area://RU.BINKD?msgid=2:463/68+5278a0df
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Hello Pavel!

PG> А есть ли там fseeko() и ftello() или что-то вместо них?

Да, _fseeki64 и _ftelli64, это как раз без проблем через #define, _stat64 _fstat64 аналогично. strtoumax - в 2010 есть аналог _strtoui64 (опять просто через define), в совсем ранних MSVC такого нет, но можно выкрутиться через _atoi64 (полный синтаксис strtoxxx, по моему, нигде не используется) или дать свою реализацию.

RT>> В общем, некоторый прогресс у меня есть, под MSVC 10.0/2010 оно уже
RT>> собирается правильно, сейчас нужно еще доделать сборку под более
RT>> ранними версиями MSVC (собранное 10.0 не работает под Win2K как
RT>> минимум). И еще я бы хотел перетрясти использование системных #include
RT>> (stdio.h и т.п.) в основном коде. По моему сформировавшемуся с годами
RT>> мнению - в подобных кросс-платформенных проектах там их быть не
RT>> должно. Все модули (хотя бы из "корня" проекта,
RT>> про платформо-зависимые костыли пока можно не говорить) должны
RT>> начинаться с #include "sys.h", а уже в нем должен инклюдиться
RT>> джентельменский набор системных хеадеров - с учетом всех HAVE_xxx и
RT>> наших переопределений. А то сейчас уже начинает наблюдаться бардак.
RT>> "sys.h" постепенно обрастает хаками и редефайнами стандартных функций,
RT>> между тем часть модулей его включало, часть не включало, часть
RT>> включало опосредованно на хз-каком уровне вложенности из другого
RT>> инклуда в неизвестно каком порядке по отношению к переопределяемому
RT>> термину, и т.п. Hекоторое время назад я уже заловил переопределение
RT>> O_BINARY в 0 там, где он должен быть ненулевым (хорошо, этот модуль
RT>> его вроде не использовал) и считаю, что подобный бардак надо пресекать
RT>> в зародыше.

PG> По идее, там должно определяться только то, чего нет в системе.
PG> Тот же O_BINARY определяется после "#ifndef O_BINARY". Если в системе нет
PG> понятия "binary", т.е. всё и так по умолчанию открывается как binary, то
PG> O_BINARY логично определять именно в 0, чтобы не возникло проблем - разве
PG> нет? Как иначе?

Это ты сейчас рассказываешь про идеальный случай, а на практике со временем образуется полный бардак из-за становящихся неотслеживаемыми неявных зависимостей, склероза старых разработчиков и невнимательности новых (я даже не про binkd, любой большой проект постепенно приходит в эту фазу). Hапример (что реально было) - в sys.h переопределили O_BINARY (под #ifndef) - все хорошо, но! забыли сделать #include <fcntl.h>. Теперь все начинает зависить от того, сделал ли #include <fcntl.h> основной .c-модуль и в каком порядке - до или после "sys.h" (причем любой из этих файлов может заинклюдится и косвенно на n-ном уровне вложенности). Если сделал и раньше, то все хорошо, если позже - как минимум предупреждение компилятора про переопределение, в худшем случае (если у компилятора оно тоже под #ifndef) - неправильное определение. И самая засада, если программист вообще забыл про #include <fcntl.h> в основном модуле. Оно же не ругается! Тихо подставило нолик и задумчиво глючит...

Вот чтобы немного упорядочить все эти ужасы, я считаю нужным собирать 90% ОСHОВHЫХ системных инклюдов в аналоге sys.h, чтобы была единая точка их слияния и переопределения. И stdio.h туда же - он нужен всем, зачем писать его 1000 раз в каждом файле? А поддерживать, когда все единообразно собрано в одном месте, гораздо проще. Да, 90%, не 100% - какие-то редкие вещи, которые нужны одному модулю и не переопределяются, можно и не включать. Hо вообще - чем меньше #include <something.h> внутри .c файлов, тем лучше. Потребовалось что-то глобальное заменить - добавили в sys.h и забыли, и не надо бегать по всем модулям искать, как оно там включается-определяется... Плюс быстрее компилится, если включить precompiled header на "sys.h".

Собственно, дело еще и в том, что из-за фокусов дядюшки Билли и введения boff_t "sys.h" стал нужен практически всем. Поэтому дополнительно возникает желание заодно немного расширить его функции и упорядочить существующий бардак с инклудами. Это я так, предупреждаю заранее, чтобы потом не было вопросов, что я там напрограммировал :)

Roman

--- GoldED+/W32 1.1.0
* Origin: ...fwrote().  That's the past tense of fwrite() (2:5022/2)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.066219 секунды