Здравствуйте, Left2, Вы писали:

L>TDesC&) — надо её разыменовать, типа *str, а вот чтобы получить неконстантный (TDes&) надо вызвать метод Des, вот так вот: str->Des().

Ну в этом нет ничего необычного или неожиданного. Таки модифицировать строку или просто использовать в функциональном стиле -- очень разная работа с данными. Это только в STL делают вид, что накладных расходов в этом вопросе не существует

Ну а названия классов всё равно у всех свои. Один хрен привыкать

Здравствуйте, Left2, Вы писали:

L>Вот статья. Если сильно нужен хедер, скажи — попробую выдрать из SDK
L>http://newlc.com/Using-Symbian-OS-String.html

Спасибо.
Я посмотрел эту статью. Я так понял, что это надстройка над средствами ОС для работы со строками...
Ну привинтили эффективные строчки на автоматических буферах и на буферах аллокированых как-то специально в ОС. Я так понял, что конструкция _LIT( KText, "XXX" ) как-то размещает статический объект непосредственно в ПЗУ устройства?
Собственно люди хотели все статические строки иметь один раз и сразу в ПЗУ. ИМХО вполне понятное желание для этой ОС...

Здравствуйте, jazzer, Вы писали:

E>>Приношу всем читателям данной темы свои извинения. Тема разрослась слишком сильно, чтобы продолжать ее отслеживать. Поэтому вынужден от нее отписаться. Если кто-то захочет задать мне какой-то вопрос по данной теме -- постараюсь ответить в привате.

J>И чего? Я в пустоту все это писал, что ли?

Почему же, я прочитал. Начинать новый виток повторения одних и тех же аргументов нет смысла.

А принцип "его писали не мы" -- это вот отсюда: http://www.lohnet.org/~hornlo/mutterings/wdjef/

...But another group within Microsoft discovered a fatal flaw in DDE: they didn’t write it!...

ну и далее по тексту. (русский перевод можно найти здесь: http://dibr.nnov.ru/print_issue020901.html).

Здравствуйте, eao197, Вы писали:

E>А принцип "его писали не мы" -- это вот отсюда: http://www.lohnet.org/~hornlo/mutterings/wdjef/

я читал эту статью. Она, безусловно, смешная, но к бусту имеет мало отношения.
Еще раз повторю — если у тебя на примете есть библиотека, достойная быть принятой в Стандарт — закинь ее в Буст, в чем проблема?
Практически каждый раз, когда я вижу предложение принять библиотеку в буст — она исходет не от человека, который уже что-то в буст закинул.
Ну нету там такого принципа, понимаешь, нету.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:

.>>>>Дык храни просто указатели, weak_ptr просто позволяет обнаруживать умирание объекта. Просто указатели в принципе не могут.
E>>>Ну так от них неудобно потом к shared_ptr возвращаться

E>Просто перечитай внимательно...
Перечитал, пришел к выводу, что под "ними" можно понимать как голые указатели, так и слабые.
Причем я понял так, что ты именно про слабые говорил.

Ладно, проехали. Похоже, изначальная тема потерялась в процессе

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop, Вы писали:

E>Ну много проблем разных. Главная в том, что STL не имеет никаких средств для манипуляции аллокаторами памяти. Надо тогда везде векторы специально специфицировать, это где-то забудут...

typedef спасет отца русской демократии

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Smal, Вы писали:

S>Хотя последнее время приходится много на этом c++/cli программировать. Хорошо, что хоть не на C# .
C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
Использовать его для основной разработки глупость.

Здравствуйте, Erop, Вы писали:

E>А если бы был у тебя GC, а объекты бы всё равно разрушались?
Такого в нормальных средах с ГЦ не бывает.

E>Например по причине отгрузки DLL со всеми её статическими данными...
ГЫ! Код и связанные с ним статические данные без разрешения ГЦ никуда не уберешь...

Здравствуйте, Erop, Вы писали:

E>>>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста
J>>есть такая штука — code review (она ведь у вас есть, не так ли?)

E>А всё равно трудно. Например приходится поддерживать формальную какую-то структуру на тему о том, что можно, что нельзя, обучать экспертов, и т. д.

Естественно, а без этого никуда и безо всякого буста. Кто-то же должен обоснованно принимать решения, где какая библиотека пригодна.
Ясное дело, что на откуп студентам такие решения отдавать не будешь.

E>>>В этом смысле своя библиотека радикально лучше управляема и поддерживаема.
J>>во-первых, буст
E>
Ну не дописал в браузере же нет подсветки синтаксиса
Думаю, я хотел сказать нечто вроде того, что написал ниже насчет тестируемости и переносимости.

J>>А вот на это у нас как раз строгий запрет. Если меняется версия какой-либо библиотеки, которая используется в нескольких компонентах — все компоненты переезжают на нее одновременно.
E>Так это и обозначает, что надо всюду таскать с собой самый актуальный буст
ну да, без него не скомпилируется
уж такой С++, если заюзал библиотеку — придется ее таскать

J>>Рефакторить существующий код тоже сплошь и рядом запрещено административно.
J>>Ибо "оно сейчас в таком виде работает и приносит деньги."
E>И это правильно!!!
E>Тут, как и везде в инженерной деятельности, нужен разумный компромис
Либо правильно, либо разумный компромисс

E>>>Идея в том, что если в конторе нормально поставлено дело и она старая, то тами без буста и без STL всё более или менее нормально. А что ненормально -- выпрямляют, безотносительно к внедрению STL'я.
J>>Чаще менее нормально, чем более. И выпрямлять ни у кого духа не хватает, наоборот, ненормальность объявляется священной коровой

E>Ну это обычно портит экономическую эффективность. Ну либо на самом деле всё хорошо.
Я уже сказал, во что выливается следование этой политике. В ночные бдения.
Экономическую эффективность программера, знаешь ли, довольно трудно подсчитать.
Вот он протрахается с кривой библиотекой вдвое-втрое дольше, чем он написал бы это на бусте, засажает багов благодаря кривой ахитектуре местной священной коровы и будет с ними разбираться потом еще месяц, а потом ему в конце года скажут — да ты, брат, просто программмер хреновый, а библиотека у нас замечательная.

E>Скажем если контора смогла выпустить пять версий продукта, то она более или менее владеет своим кодом. А всякие идеологические соображения -- это только идеологические соображения.
Очень оптимистичные вещи ты говоришь
А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
E>На самом деле код -- это всегда инструменты + соглашения + люди, которые этим всем пользуются. Без коллектива код мёртв. А что подходит тому или иному коллективу -- вопрос очень непростой.
Тут соглашусь.

J>>Буст в этом смысле довольно неплох, кстати — там уже существует куча workarounds для разных странных платформ, и часто бывает так, что (если у тебя экхотическая платформа) один из этих хаков тебе подойдет (хаки эти включаются/выключаются соответствующими дефайнами в config.hpp). Буст все-таки разрабатывается и тестируется довольно интенсивно, особенно библиотеки общего назначения типа умных указателей и т.п. Пользователей буста все же всяко больше, чем любой доморощенной библиотеки, и условиях, в которых попробовали буст погонять, тоже больше, чем для самописной.

E>Ну я вот буст переносить не пробовал.
А ты попробуй Вдруг понравится

E>А с STL имел проблемы регулярно
С STL нельзя иметь проблемы, это странички из Стандарта.
С какой именно реализацией у тебя были проблемы? STLPort пробовал? Еще какие-нть пробовал? Почему остановились именно на той, с которой проблемы?

J>>имхо, написать код, который будет нормально работать и с исключениями, и без, по-человечески невозможно.
E>Ты не понял. Нужно написать такой код, который легко модифицировать так, чтобы не было исключений...
E>Но это правда непросто. Это требует довольно комплексного подхода...
Если не исключения — значит, коды возврата, правильно? Других выходов я не вижу. Ну разве что сразу abort звать
Код на исключениях и на кодах возврата отличается радикально.

E>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...
какого еще глобального goto? у тебя весь код в одной функции, что ли?

E>>>

---

E>>>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения
E>>>Мне так кажется, что решения должны быть либо ориентированы на какую-то мегамногопроцессорную платформу, но тогда надо совсем другой язык писать, наверное функциональный какой-то, либо должна быть поддержка распараллеливания на каком-то очень высоком уровне. Типа на уровне запроса. Но тогда это скорее не к языку, а к ОС и библиотекам...

J>>Не, это именно к языку. Пока не определена семантика базовых операций в многопоточном окружении — никакая библиотека тебе не поможет, останется только молиться, что у тебя все сработает правильно. Так что комитет занимается очень правильным делом.
E>Ну де факто на платформах, где есть многопоточность вообще, реализация языка всё определила уже. Ну есть там несколько тонких мест, вроде синглетона Майерса, ну и что? ИМХО сам по себе синглетон, в том числе и Майерса не нужен

Ну не скажи. Не на всех платформах есть атомарные типы и тому подобные низкоуровневые вещи. Мьютексы — да, на всех почти есть, но каждый инт защищать мьютексом — смерти подобно. А без этого тебе никто ничего не гарантирует, можно и аппаратное исключение словить. Или volatile, например, где-то заточен под то, чтобы все корректно работало со многими потоками, а где-то — нет.
Еще есть такая штука, как переупорядочивание инструкций, которое по стандарту компилятор имеет право делать. Я думаю, ты сам понимаешь, что будет, если мьютексы начать захватывать в другом порядке.
Ну и так далее.

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

J>>А насчет языка для супер-параллельности — посмотри на Clik Думаю, тебе понравится
E>Да их много
Просто это расширенный С. Или я опечатался, наверное, Cilk. Как-то так, в общем. Экспериментальная академическая разработка, использует кражу задач (work stealing).

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Alex Alexandrov, Вы писали:

AA>>К сожалению, да. И в этом плане, внешний счетчик выглядит безопаснее внутреннего, так как кто попало не может захватить указатель, нарастив ссылку. Ибо как с подсчетом ссылок основная забава при работе в довольно большой команде — это отлов циклических "захватов". Обнаруживается, как правило, в самый неподходящий момент и иногда ведет к серьезным изменениям в дизайне...

E>А как shared_ptr помогает от циклического захвата ссылок? "Кто-нибудь" -- это очень мощный персонаж обычно

Например, если кому-нибудь для инициализации передается некоторый интерфейс а-ля I*Site, который не предназначен для запоминания инициализирующимся, то передача голого указателя, на который нельзя просто так нарастить ссылку, может внести ясность. Впрочем, пользы от этого мало, ибо "мощный персонаж" может сконструировать другой shared_ptr и все становится совсем весело. Но сразу.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Smal, Вы писали:

S>>Хотя последнее время приходится много на этом c++/cli программировать. Хорошо, что хоть не на C# .
WH> C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
WH>Использовать его для основной разработки глупость.

Объясни, почему. Есть проекты, где основной язык разработки — C++/CLI. Смотри Phonenix, например.

Здравствуйте, Erop, Вы писали:

E>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста

grep --recursive --include=*.cpp --include=*.h -h "#include.*boost" * | sort | uniq
#include <boost/algorithm/string/case_conv.hpp>
#include <boost/bind.hpp>
#include <boost/crc.hpp>
#include <boost/cstdint.hpp>
#include <boost/filesystem/convenience.hpp>
#include <boost/filesystem/operations.hpp>
#include <boost/filesystem/path.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/noncopyable.hpp>
#include <boost/scoped_array.hpp>
#include <boost/scoped_ptr.hpp>
#include <boost/smart_ptr.hpp>
#include <boost/thread/condition.hpp>
#include <boost/thread/mutex.hpp>

Ы?

E>Ну я в реальной жизни встречал запрет в такой форме: "обоснуй, пожалуйста, выгоду от использования предлагаемого средства"
А в чем проблема? Ну разве что вопрошающий не воспринимает то что ему говорят... но это показатель к увольнению...

E>У меня есть заметный опыт в переносе кода на разные платформы. А у нашей конторы такого опыта вообще вагоны. В том числе на экзотические и довольно убогие. Среди убогих были и такие,
E>где не было возможности иметь конструкторы статических объектов и такие,
Статические объекты однозначно зло.
Но это уже отдельный флейм.
E>гед не было исключений, и такие,
А вот это засада еще та... Ибо для того чтобы жить без них нужно писать код совершенно иначе чем с ними.
И это совершенно иначе мне очень не нравится.
E>где шаблоны были не супер.
Насколько не супер? Скажем относительно VC++6.
E>ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.
А что там особо крутого? Ну не считая boost::mpl

E>Второй источник гемора -- это конечно исключения. Но при некотором подходе к использованию исключений можно получить все адвантез, и при этом не сильно попасть, в случае, если таки надо от исключений избавится.
Боюсь избавится от исключений куда сложнее чем от шаблонов...

E>Ну, например, ты делаешь плагин или библиотеку какую и уже автоматически зависишь по рантайму, скажем...
Я вот знаю одну библиотеку написанную на С++ с шаблонами и исключениями при том имеющею Сшный интерфейс...
Прекрасно живет в so'шках и dll'ках...

E>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения
E>Мне так кажется, что решения должны быть либо ориентированы на какую-то мегамногопроцессорную платформу, но тогда надо совсем другой язык писать, наверное функциональный какой-то, либо должна быть поддержка распараллеливания на каком-то очень высоком уровне. Типа на уровне запроса. Но тогда это скорее не к языку, а к ОС и библиотекам...
Качественно это можно сделать только виртуальной машиной которая по совместительству еще и ОС.
Но это совершенно отдельная история.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, eao197, Вы писали:

E>>А принцип "его писали не мы" -- это вот отсюда: http://www.lohnet.org/~hornlo/mutterings/wdjef/

J>я читал эту статью. Она, безусловно, смешная, но к бусту имеет мало отношения.

Это как посмотреть.

J>Еще раз повторю — если у тебя на примете есть библиотека, достойная быть принятой в Стандарт — закинь ее в Буст, в чем проблема?

Я тут вот о чем подумал по дороге домой: ну вот станет boost::regex частью стандарта. Ну и все, feature freeze на ближайшие N лет. А разные Greta и PCRE продолжат развиваться и улучшаться.

А на счет закидывать -- у меня на свои OpenSource проекты здоровья уже не хватает. А здесь столько гораздо более умных C++ников и бустоводов сидит и хоть бы кто, например, сделал для буста аналог RubyGems.

Здравствуйте, alexeiz, Вы писали:

WH>> C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
WH>>Использовать его для основной разработки глупость.
A>Объясни, почему.
Лучше ты объясни какие преимущества дает С++/CLI из-за которых стоит отказаться от ReSharper'а?
Вот для немерле можно легко выкатить сиписок, а вот для C++/CLI

A>Есть проекты, где основной язык разработки — C++/CLI. Смотри Phonenix, например.
И чем они обосновывают этот выбор?

Здравствуйте, WolfHound, Вы писали:

E>>А если бы был у тебя GC, а объекты бы всё равно разрушались?
WH>Такого в нормальных средах с ГЦ не бывает.
Ну библиотека-то сторонняя...

E>>Например по причине отгрузки DLL со всеми её статическими данными...
WH>ГЫ! Код и связанные с ним статические данные без разрешения ГЦ никуда не уберешь...
Как так не уберёшь? FreeLibrary позовёшь и очень даже уберёшь...

Конечно если ты сторонней библиотеке можешь навязать использование твоего GC то да. А если не можешь?

Здравствуйте, jazzer, Вы писали:

E>>А всё равно трудно. Например приходится поддерживать формальную какую-то структуру на тему о том, что можно, что нельзя, обучать экспертов, и т. д.
J>Естественно, а без этого никуда и безо всякого буста. Кто-то же должен обоснованно принимать решения, где какая библиотека пригодна.
Ну а так прийдётся ещё и для довольно большого буста эту инфраструктуру поддерживать. Если тебе всего-то и надо, что контейнеры с умными указателями и работа с памятью и файлами, например, то не факт, что это дешевле, чем свою библиотеку поддерживать

E>>Так это и обозначает, что надо всюду таскать с собой самый актуальный буст
J>ну да, без него не скомпилируется
J>уж такой С++, если заюзал библиотеку — придется ее таскать
Ну это значит "и поддерживать". Я уже не говорю о том, что если ты разрабатываешь библиотеку под линукс, то тебе надо ещё и с хостом одной версией буста пользоваться

E>>Тут, как и везде в инженерной деятельности, нужен разумный компромис
J>Либо правильно, либо разумный компромисс
Нет. В инженерной деятельности всегда и только компромисс. "Правильно" просто не бывает
Собственно в этом у нас и есть с тобой расхождение. Я понимаю, что ничегоне бывает забесплатно и всё всегда компромисс, а тебе кажется, что бывают абсолютные истины. Скажем такая: "буст лучше всех альтернатив"

E>>Ну это обычно портит экономическую эффективность. Ну либо на самом деле всё хорошо.
J>Экономическую эффективность программера, знаешь ли, довольно трудно подсчитать.
Ну одного конкретного программера да, может быть, а вот процесса разработки -- запросто. И если у людей без буста получилось экономически эффективно разработать чего-то, то таки не нужен им буст, однако

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

J>А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
Ты не знаешь продуктов, которые пережили более 5 версий?
MS Word
Adobe Photoshop
Mac OS
OmniPage
The Bat
gcc правда пока только 4 версии пережил, но есть таки надежда
1С
WinDVD Pro
Nero
Lingvo
Даже "Герои меча и магии" кажется уже 5 версий набрали (если с KingsBounty считать )

Может ты просто в нормальных конторах не работал?

E>>Ну я вот буст переносить не пробовал.
J>А ты попробуй Вдруг понравится
Ну если ты оплатишь...

J>С STL нельзя иметь проблемы, это странички из Стандарта.
Ну уж я не знаю что там можно, а что нельзя, но проблемы бывают
J>С какой именно реализацией у тебя были проблемы? STLPort пробовал? Еще какие-нть пробовал? Почему остановились именно на той, с которой проблемы?
Потому что STL обычно поменять нельзя
STLPort тоже фигурировал...

Про то, что ты не видишь других альтернатив я поскипал, извнини, но я их просто использовал на практике

E>>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...
J>какого еще глобального goto? у тебя весь код в одной функции, что ли?
Обычно есть возможность прихранить состояние стека, и потом вернуться туда же, но на другую метку. Если его нет сразу (хотя обычно есть), нет проблем реализовать на асме...

E>>>>

---

J>Еще есть такая штука, как переупорядочивание инструкций, которое по стандарту компилятор имеет право делать. Я думаю, ты сам понимаешь, что будет, если мьютексы начать захватывать в другом порядке.
Вообще-то есть ещё и переупорядочивание инструкций в процессоре...
J>Ну и так далее.
Я тебе так скажу. Я думаю, что пстандартизация в этих вопросах не прибавит переносимости

J>Нужна поддержка со стороны языка, короче, без нее никуда, никакая библиотека не спасет, только молиться останется либо на каждый чих забирать мьютекс, что убьет производительность на корню.

Ну пока что на многопоточных платформах как-то обходятся
Я не спорю, что можно бы и добавить что-то в стандарт про многопоточность, но насущной необходимости не вижу

Здравствуйте, WolfHound, Вы писали:

WH>Ы?
Ещё бывают зависимости между хедерами. Да и в хедерах много чего бывает...

E>>Ну я в реальной жизни встречал запрет в такой форме: "обоснуй, пожалуйста, выгоду от использования предлагаемого средства"
WH>А в чем проблема? Ну разве что вопрошающий не воспринимает то что ему говорят... но это показатель к увольнению...

Обычно спрашивает начальник, и при этом они с подчинённым энтузиастом буста/STL/Дельфи или ещё чего не понимают друг друга. Началинк оперирует языком экономической эффективности разработки и поддержки, а подчинённый оперирует идеологическими соображениями. Ну типа того, что он лично думает, что при использовании буста он запрограммирует это в пять раз быстрее. Обычно ошибается, кстати.

WH>Статические объекты однозначно зло.
WH>Но это уже отдельный флейм.
Очень конструктивно. Я знаю вагон успешных программ, где есть статические объекты. Мало того, я знаю, что комитет по C++ всё ещё не объявил слово static устаревшим...
Так что это действительно флейм.

Во всяком случае если мне инженер скажет, что для улучшения наших программ надо извести все статические объекты и перейти на буст я его тоно пошлю

WH>И это совершенно иначе мне очень не нравится.
Ну а вот и не совсем так дела обстоят
E>>где шаблоны были не супер.
WH>Насколько не супер? Скажем относительно VC++6.
Сильно хуже.
E>>ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.
WH>А что там особо крутого? Ну не считая boost::mpl
Да? Ну, например, параметры шаблона не передаются рекусивно.
Скажем так написать нельзя:

template<class T> myData { std::vector<T> data; };

Скажут, что T не определён

WH>Боюсь избавится от исключений куда сложнее чем от шаблонов...
От шаблонов в стиле STL избавится невозможно!!!

WH>Я вот знаю одну библиотеку написанную на С++ с шаблонами и исключениями при том имеющею Сшный интерфейс...
WH>Прекрасно живет в so'шках и dll'ках...
Да? А если ты хочешь чтобы она разделяла рантайм с основным приложением. Скажем из соображений общей кучи? Это что касается DLL
А что касается SO, то ты просто не пробовал взять эту SO и хост, собранный с другим STL. Попробуй -- узнаешь много нового

WH>Качественно это можно сделать только виртуальной машиной которая по совместительству еще и ОС.
Это ещё почему? Зачем для распараллеливаемого функционального языка ОС и VM?
WH>Но это совершенно отдельная история.
ИМХО это просто заблужления, а не история

Здравствуйте, Alex Alexandrov, Вы писали:

AA>...ибо "мощный персонаж" может сконструировать другой shared_ptr и все становится совсем весело. Но сразу.

Всё так, только выделенное не обязательно. ИМХО ты персонажа всё-таки недооцениваешь

Здравствуйте, jazzer, Вы писали:

E>>Ну много проблем разных. Главная в том, что STL не имеет никаких средств для манипуляции аллокаторами памяти. Надо тогда везде векторы специально специфицировать, это где-то забудут...

J>typedef спасет отца русской демократии

Прости, какой typedef?

А если в программе есть объекты разных типов? В том числе и массивы таких объектов?

Здравствуйте, jazzer, Вы писали:

E>>Ну много проблем разных. Главная в том, что STL не имеет никаких средств для манипуляции аллокаторами памяти. Надо тогда везде векторы специально специфицировать, это где-то забудут...
J>typedef спасет отца русской демократии
Не спасет.

Во-первых, statefull-аллокаторы в STL нормально работать не будут.
Во-вторых, можно нарваться на засады с методом swap(), если аллокаторы будут иметь несовпадающий тип.
В-третьих, в STL аллокаторы не могут возвращать умные указатели (в Стандарте гвоздями прибиты простые указатели).

Я в итоге свою либу написал