Свежие комментарии
| Title | Comment |
|---|---|
| Да, к вопросу об инженерной практике. Проблема в том, что п |
Да, к вопросу об инженерной практике. Проблема в том, что проблемный вызов сделан именно для того, чтобы отвязать время жизни одного объекта (результата обработки RAW) от жизни другого (распаковщика RAW). Распаковщик отстрелил результат и пошел обрабатывать другой файл, например. То бишь вполне жизненная задача, по заявкам телезрителей сделаная. |
| И при этом, кстати, fclose() версии 6 обнаружив FILE* версии |
И при этом, кстати, fclose() версии 6 обнаружив FILE* версии 7 может склеить ласты, и это будет уже не на этапе линковки, а на рантайме. Ну хоть внятная диагностика возможна, а не просто падение, но от этого не сильно легче. |
| Да тоже ничего хорошего. fclose() версии 7 должен закрыть р |
Да тоже ничего хорошего. fclose() версии 7 должен закрыть результат fopen() версии 6 или нет? А c версиями наоборот? То бишь, кроме symbols (т.е. точек входа/функций) надо еще данные версионировать. В-принципе, хорошая идея, только вот боюсь "срыв колпака моментально". |
| Их конечно несколько. Их даже на одной машине может быть нес |
Их конечно несколько. Их даже на одной машине может быть несколько. Просто механизм динамической линковки другой - тот же free() в рамках процесса будет один. А откуда он взялся, из системной библиотеки, или я jmalloc подсунул для скорости или, наоборот, еще какой *alloc для отладки - это уже другой вопрос. Уж у malloc/free, по счастью, даже потенциальных проблем с интерфейсом нет в рамках одной битности. Понятно, что грабли есть и на таком пути - когда вызывающее приложение получает не просто хэндл (FILE* или void* или результат open), а с чем-то вроде stat(), но это лечится версионированием "DLL" и stat все одно будет один (а если два "DLL" просят stat() от разных версий - то не слинкуется). |
| версионирование экспортируемых символов -- ещё лучше. |
версионирование экспортируемых символов -- ещё лучше. |
| нет, просто есть versioned symbols. Что в glibc, что в соляр |
нет, просто есть versioned symbols. Что в glibc, что в солярисе, что в FreeBSD. |
| Все-таки, я не понимаю, если у меня вот такой вот код: int |
Все-таки, я не понимаю, если у меня вот такой вот код: Я смирюсь с этим, куда деваться, но это полная херня. Принципиальной разницы между результатом malloc() (реальный случай) и этим примером - я не вижу. |
| У этой структуры в последней версии размер изменился, вобщем |
У этой структуры в последней версии размер изменился, вобщем что-то дописывают. Вообще стандартная библиотека не совсем стандартная, там куча всего дополнительного и это не только к windows относится, это везде так. Посмотрел в wikipedia - оказывается под unix их наплодили уже несколько. |
| Не-не. Источники проблем конечно есть, но это все разовые по |
Не-не. off_t, который был 32 бита, а стал 64. На эту тему все-таки был вялый секс, который впрочем версионированием libc вполне лечится (как оно лечится в Linux - отдельная грустная история, по поводу которой я уже возмущался). То же самое предстоит с time_t и эти часы уже тикают. |
| В API которые я видел обычно сразу подобные вещи оговаривают |
В API которые я видел обычно сразу подобные вещи оговаривают, поставщик DLL должен четко описать это. Если он дает делать все что угодно и не закрывает интерфейсы памяти и доступ к crt объектам значит он как бы намекает на то что вы должны подстроится под меня и теперь это ваша проблема. Вот пример из реальной жизни - подобный подход проповедует API AutoCAD, но они выпускают обновления API с заметным опозданием от версий VS. Пришлось поддерживать проект в старой студии, чтобы все это работало. Мне кажется, при проектировании библиотек лучше сразу решать эту проблему и отказываться от жесткой привязки. |
| Версионирование DLL/.SO - есть благо, сменил ABI - увеличь н |
Версионирование DLL/.SO - есть благо, сменил ABI - увеличь номерок. А программа, без дополнительных ужимок со стороны программиста, должна линковаться только со своим major version number (а minor - типа багфиксы с сохранением ABI) Оно должно быть не 100% жестким, должен быть механизм ручного оверрайда (чтобы ту же отладочную библиотеку аллокации подсунуть), но по дефолту обязано работать. |
| источник проблем при смене версии libc я видел ровно один ра |
источник проблем при смене версии libc я видел ровно один раз. Но это была Oracle которая сама себя высекла. Они там в процессе инсталляции перелинковывали приложение из объектников. А тут при смене версии о совместимости по объектникам никто не позаботился - старые слинкованные бинарники работают, старые исходники после компиляции работают и ладно. |
| А зачем ее менять? Языку 40 лет, чему там меняться? Внутренн |
А зачем ее менять? Языку 40 лет, чему там меняться? Внутреннюю реализацию можно оптимизировать, но API-то неизменен. Не "любая сложная система", а "хреново спроектированная сложная система". У любой хорошо спроектированной сложной системы есть блоки, интерфейсы между которыми менять никогда не приходится, и заменять такой блок целиком можно, не боясь что что-то сломается в соседнем блоке. Что удивительно, Microsoft на протяжении четверти века поддерживала стандартный API MS-DOS. И все прекрасно работало. И новые возможности добавлялись (сеть, длинные имена файлов) и работать старым программам это не мешало. |
| Но другого выхода просто нет. Именно поэтому сейчас winsxs з |
Но другого выхода просто нет. Именно поэтому сейчас winsxs занимает например у меня почти 5 gb, но там конечно не только crt. Даже с .net они вынуждены менять версию, но там сделали хитро - они CLR (низкий уровень) меняли всего один раз - в версии 2.0 добавили generics, а .net 3, 3.5 и 4 это добавление новых классов, а старые они видимо не трогают. |
| Не, ничего она такого особенного с собой не тянет, всякий li |
Не, ничего она такого особенного с собой не тянет, всякий libc уж точно системный. |
| Вот мне удивительно, что общеупотребительные объекты, вроде |
Вот мне удивительно, что общеупотребительные объекты, вроде того же FILE* - несовместимы между собой. Непривычный я к этому. |
| Вот с этим согласен - бесит именно то что линкуется и потом |
Вот с этим согласен - бесит именно то что линкуется и потом не работает. А магически заменить одну библиотеку на новую версию, чтобы все было идеально - это утопия и источник проблем, правильно что сделали четкое связывание по версиям. |
| > У меня под FreeBSD8/x64 работает антиспам, собранный (со в |
> У меня под FreeBSD8/x64 работает антиспам, собранный (со всеми .so/dll) под FreeBSD5/x32 и отлично же работает..... Я не очень понял - речь идет о программе собранной для bsd5 32-бита, она тянет с собой все необходимые библиотеки. Ты ее копируешь на 64-битную более новую систему и она тоже работает. Верно? Ну так она все необходимое с собой несет. Вот если ты откроешь в 32-битной системе состояние процесса и посмотришь список подключенных модулей и версии и тоже проделаешь в 64-битной системе - ты увидишь отличия? |
| Про твой пример с зависимостями: app -> libtiff app -> libjp |
Про твой пример с зависимостями: Все будет работать, каждый со своей библиотекой. А если начнете работать с объектами crt одной версии (объекты кучи, FILE* и пр.) из другой все рухнет. Задача разработчика библиотеки, которую он выпускает во внешний мир обеспечить безопасный интерфейс и описать правила как этого добиться. |
| Разработчик дает тебе: module.dll, module.lib, module.h mod |
Разработчик дает тебе: module.dll, module.lib, module.h module.dll зависит от crt_ver1.dll и это ты не изменишь, нельзя и не правильно подменять версии библиотек, т.к. они отличаются. Другой вариант - он вообще может статически с ней слинковаться, тогда crt_ver1.dll не должна присутствовать в системе, но это так уже почти никто не делает. Далее, если module.dll сделал выделение памяти и дал тебе указатель, а твоя crt имеет другую версию, то куча у тебя другая и при освобождении памяти будет падение. |
| Не, внутри *моего* проекта проблем как бы нет. Речь идет о |
Не, внутри *моего* проекта проблем как бы нет. Речь идет о том, как должен себя вести поставщик DLL. Ну то есть понятно - сам породил, так сам и убивай, но если это убивай состоит из free(), то обидно как-то. |
| <i>а есть ли альтернативы этому, чтобы всё работало и не кус |
а есть ли альтернативы этому, чтобы всё работало и не кусало друг друга? Меня бесит ситуация, когда линкуется и не работает. Пусть уж лучше не линкуется (в смысле - динамическим линкером, на рантайме). |
| FILE* часть crt и она должна быть скрыта. Если такого слишко |
FILE* часть crt и она должна быть скрыта. Если такого слишком много, то наверное правильно требовать совпадения crt. Мне кажется зачастую можно обойтись без открытия наружу FILE* - ведь речь идет о взаимодействии библиотеки и пользователя. Внутри вашего проекта отдельные модули конечно лучше согласовать, чтобы о подобном не думать, а снаружи давать доступ без подобных вольностей. Если внутри есть модуль который развивается кем-то как-то параллельно, то лучше минимизировать его интерфейс. Но это конечно общие слова, но в принципе о подобном приходится рано или поздно задумываться. Это понимаешь мир native кода со всеми перелестями. |
| Не, ну я последние лет 15 или около того, как разделямые биб |
Не, ну я последние лет 15 или около того, как разделямые библиотеки в Linux/FreeBSD появились, собираю все с зависимостями от того что на машине есть, потом эти зависимости апгрейдю (в рамках сохранения ABI, естественно, там есть понятные грабли вроде "размер структуры поменялся") по одной - и не жужжу. То бишь описанные вверху грабли - для меня внове. |
| верно, я и говорю, что _сменили_ ) Просто получается, что од |
верно, я и говорю, что _сменили_ ) Другой вопрос - а есть ли альтернативы этому, чтобы всё работало и не кусало друг друга?... похоже, что нет... |
| Я не понимаю. Вот есть разработчик библиотеки, он дает мне |
Я не понимаю. Вот есть разработчик библиотеки, он дает мне DLL + .H (+lib, естественно), как-то он его скомпилировал. Либо нужно все это версионирование DLL/библиотек энфорсить и просто не давать скомпилироваться (слинковаться) не с тем рантаймом, либо все должно работать. А как сейчас - и не энфорсят и не работает. Если у меня есть libtiff, собранный VC6 (и зависимый от того рантайма), плюс libjpeg, собранный VC8 (и зависимый от другого рантайма), то я правильно понимаю, что VC2010 мое приложение с ними слинкует, будет зависимость от третьего рантайма, а работать оно будет, скорее всего, ужасающе? У меня под FreeBSD8/x64 работает антиспам, собранный (со всеми .so/dll) под FreeBSD5/x32 и отлично же работает..... |
| Я не могу ничего сказать о unix, но это странно очень. Видим |
Я не могу ничего сказать о unix, но это странно очень. Видимо libc там просто заморожена и почти не меняется. Любая сложная система при малейшей замене компоненты требует смены версии, гарантировать работу очень сложно, только если это довольно простой набор функций. |
| Не, ну это же усраться. Кроме аллокатора есть же и другие |
Не, ну это же усраться. Кроме аллокатора есть же и другие объекты, ну там файловые хэндлы (которые int) или FILE* И че, если какая-то DLL-ка вернула мне результат fopen() чтобы я с ним покувыркался, то не факт что у меня оттуда fread() получится. Йобнуться можно. |
| Как тут уже написали, libc - часть системы. Есть всегда. То |
Как тут уже написали, libc - часть системы. Есть всегда. Я могу его подменить (отладочной библиотекой аллокации, например), но для всего приложения (процесса) сразу. Вот с stdc++ бывает веселее и со всякими темплейтами - тоже. |
| Насчет веревок и ноги не понял? При разработке принято изол |
Насчет веревок и ноги не понял? При разработке принято изолировать код на модули - это просто архитектура и дизайн. Естественно в рамках одного большого проекта модули скорее всего будут поддерживаться параллельно и везде все будет на одной crt и нативно юзать классы как хотят. Но какие-то проекты могут быть сторонними или по каким-то иным причинам быть в другом окружении - вот тут надо думать обо всех этих проблемах. Плохо что сама среда c++/с никак тут не помогает. В managed языках я думаю такой проблемы быть не должно в принципе - нет совместимости нет компиляции. |
Pages
