Свежие комментарии

>> Как тут уже написали, libc - часть системы. Есть всегда.
То бишь, free() всегда один... <<
это если связывание статическое.
А если не статическое, то будет ровно тот же "бардак и катастрофа" что и у мелкомягких.

не так ли?

прикладной код вообще не должен делать никаких предположений относительно реализации.
Сегодня у тебя там open(...), а завтра - sopen() какой-нибудь или ещё какая хрень.

Так что херня - это когда один "аллокирует", а другой - "деаллокирует"... а потом третий сидит и "рвёт на ж. волосы" в попытках развязать этот порочный круг.

Я затрудняюсь насчет счастливого конца. GNU+STLport - скорее всего счастливого конца не будет.
А связь со сложностью такая, что STL в интерфейсах - можно, а как обеспечить работу разных имплементаций (не строго одной с экспортом, а именно разных) - непонятно.

Вот как офигачить простые структуры данных без ассоциированного с ними инстанционированного кода - более-менее понятно, берешь и офигачиваешь, всего-то надо смещения полей данных одинаковые по всему коду.

Про Дельфи плохо знаю, а смешать C, Fortran и Pascal можно без особых проблем.

Даже если экспортировать.
Компонент1 использует MS STL и его экспортирует. Поставляется в бинарном виде...
Компонент2 использует GNU STL и его экспортирует. Поставляется и в исходниках тоже, но компилируется только gcc :)
Приложение использует STLport и готово что-то поимпортировать.....

Ужас же, нах.

C++ получился слишком сложным языком, на мой взгляд. Ну я вот лично давно отчаялся за ним даже следить, но ведь это говорят и те, кто следит.

STL в интерфейсах - вообще зло.

Ну, тогда тот, кто по недомыслию линкуется с двумя версиями crt...

Ну а как - вот пришел 3rd-party DLL, с чем он там слинкован - вовсе неведомо...

Касаемо практики - как я тут уже написал в каментах, это именно такой вызов, который позволяет "аллоцировать ресурс", отдать его вызвавшему коду, а дальше заняться другими делами.
Скажем, с open() это была бы такая нормальная практика, хэндл открытого файла можно (в некоторых системах) и в другой процесс передать....

Кучи разные(наверняка уже кто-то ответил).
Вы видели, например у std::vector, второй шаблонный параметр?

template < class T, class Allocator = allocator > class vector;
А сам объект allocator'а, можно передавать в конструкторах.

Вот, как раз для борьбы с разными кучами при разных CRT, можно использовать одинаковые allocator'ы (в частности при использовании STL).

>> Но при этом - нет никаких проблем слинковать в приложение сразу две эти библиотеки <<
что-то я не понял прикола.
В чём проблема ? - релизная и дебагная компиляция транслируют тот же malloc/free в разные символические имена ?
Ну, тогда тот, кто по недомыслию линкуется с двумя версиями crt, сам себе Злобный Баклан Буратино.
Если же символические имена будут одинаковые, то проблем быть не должно даже в случае линковки с двумя либами (возьмётся первая попавшаяся).

Так всегда и везде было. В той же джаве можно подсунуть две версии одного и того же класса и тоже никто не возбухнет (есть там какие-то механизмы, но ими, кажется, реально никто не пользуется. да и предназначены они для другого).

-+-
>> А, да, сухой остаток, сижу выпиливаю в LibRaw зеркальный вызов, который будет освобождать аллоцированное строго правильным освободителем. Две строчки кода, блин. <<
на мой взгляд это вообще плохая практика когда "аллоцирцет ресурс" один агент (библиотека, напр.) а освобождает его - другой (клиентский код, напр.), поелику нарушает принцип "loosely coupled" и прочие CRC.

так что вообще-то это ты не прав, а не мелкомяХкие.

Да, но это уже поведение более высокого уровня, непосредственно к структуре блоков памяти не должно иметь отношения.

new/malloc могут брать памяти больше чем было запрошено, то есть malloc(x) захватит p размером x+i и вернет указатель на p+i, в p[0-i] служебная инфа.
Чтобы не делать этого для мелких блоков, можно держать несколько куч с быстрым определением из какой кучи данный блок.

Сомневаюсь правда, что такое сделают чтобы кто-то мог смешивать delete/free. :)

Фатального наверное нет, но если был выделен обьект - деструктор отрабатывать не должен. Хотя возможно в каких-то рантаймах это делают.

Не, я о том, что просто аллокатор действительно несложно переопределить, а вот с плюсами гемороя в этом месте слишком уж много и лучше бы доверить это дело libstdc++ или как ее там зовут.

Граждане, ну malloc/free так еще можно заменить, но ведь есть new/delete.

> Заметим себе, что под вендами чудесным образом поведение программы у меня меняется от включения отладки по memory leak. Очень сексуально, когда релизная версия работает, а отладочная - нет.

Если я верно понимаю, то ты говоришь не о смешении разных crt в рамках одного процесса, а именно о замене crt release на crt debug. Если это так, то вообще при переходе от release к debug разные интересные вещи происходят. Ошибки проявляющиеся в релизе могут не происходить в дебаге, обычно воспроизводимость в дебаге намного лучше. В дебаге аллоцируемая память заполняется константой, кроме того адреса будут немного другими при запуске, поэтому ошибки на указателях по другому будут себя вести, от оптимизации кода тоже изменения в адресах будут, вобщем всякие чудесные ошибки при работе с памятью могут в дебаге и релизе отличаться. Такая проблема была всегда - рано или поздно выскакивает какая-нибудь заковыристая проблема которая плохо воспроизводится и при попытке отладки ускользает.