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

>>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>>
>> S>Кроме производительности. А формально — да, подходит.
>>
>> А какие проблемы с производительностью?

S>Дак вполне очевидные — при удалении умных указателей придется шариться по спискам объектов, на которые ссылаешься, вычищать оттуда себя. Потом бежать по спискам подписчиков, уведомлять их о своей кончине.

По спискам шариться не надо — next и prev у элемента имеются.
По спискам подписчиков тут бегать не надо вообще.
Если ты сделаешь замеры, то увидишь, что такой указатель будет работать быстрее обычного.

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

RO>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

Это помогает под виндой.
Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста. И ничуть не запарится. Так что какой там интерфейс -- не суть. Тем более, что любой интерфейс можно завернуть в автогенерённый переходник. Проблема в доступности symbols друг друга.

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

J>Кривизна, конечно (кто там говорил, что сахар не нужен?), но зато можно в эту структуру всякие другие вещи засунуть, к ним ко всем будет обращение через MyVector<int>. Например, MyVector<int>::iterator.

Ну вот мы STL и не используем...

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

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

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

А, это было про мерзкую платформу без поддержки даже базовых вещей... Тады ой

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

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

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

J>>Кривизна, конечно (кто там говорил, что сахар не нужен?), но зато можно в эту структуру всякие другие вещи засунуть, к ним ко всем будет обращение через MyVector<int>. Например, MyVector<int>::iterator.

E>Ну вот мы STL и не используем...

А причем тут STL? Это — кривизна С++ в плане отсутствия template typedef, эта беда с абсолютно любыми шаблонами.
Разве что у вас библиотека нешаблонная совсем (на макросах?), тогда да.

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

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

J>А причем тут STL? Это — кривизна С++ в плане отсутствия template typedef, эта беда с абсолютно любыми шаблонами.
J>Разве что у вас библиотека нешаблонная совсем (на макросах?), тогда да.

Ну контейнеры у нас шаблонные, но для обсуждаемой функциональности template typedef не требуется

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

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

J>>А причем тут STL? Это — кривизна С++ в плане отсутствия template typedef, эта беда с абсолютно любыми шаблонами.
J>>Разве что у вас библиотека нешаблонная совсем (на макросах?), тогда да.

E>Ну контейнеры у нас шаблонные, но для обсуждаемой функциональности template typedef не требуется
ну или требуемая функциональность вцементирована, тогда тоже да

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

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

Я пересмотрел свою позицию, действительно, ваши задачи могут быть более требовательны к средствам чем те, которые предоставляет STL+Boost. Все таки правило частное решение лучше общего никто не отменял. Ваше частное решение явно заточено под ваши задачи и связанную с ними проблематику, конечно при условии что ваш фреймворк предоставляет как минимум не худший сервис, чем тот же STL. Я думаю что программисты у вас деляться на те, кто разрабатывает и поддерживает фреймворк, и те кто его используют (прикладные): просто было бы нехорошо чтобы те же приладники время от времени полгядывали в сторону "запрещенного" STL+Boost пуская слюни конечно из тех, кто раньше его учили и использовали.

Еще интересно знать, отказались ли вы от совершенно стандартных средств, таких как strXXX, memXXX, malloc и проч. Т.е. при вашем подходе было бы уместно ожидать, что стандартных библиотек вообще не используется.

И все же избранный вами подход доказывает только одно правило: без STL можно хорошо жить. Но никак не опровергает обратного!

Я бы по такому пути не пошел. И никому бы не советовал. А вы не доказали обратного — не жили на STL+Boost как минимум. Так что ваши советы слишком однобоко обоснованы, слишком похоже на какое-то исключения из правил в рамках обстоятельств финансирования, политики и проч..

А так я полностью согласен с вашим правилом я тоже когда-то жил неплоха без STL и проч. писал велосипеды.. Кто через это не проходил?

V>>А нафига? По твоим постам я понял, у тебя свободного времени просто тонна и ты не знаешь как по извратнее бы его потратить.
E>Не знаю я, что такое "поизвратнее". Одна из текущих задач, стоящих перед моей группой звучит так: "Разработать лучший в мире ХХХ, с беспрецедентно высоким качеством YYY". На это можно потратить всё свободное и несвободное время. И STL и boost тут не помогут, увы

Почему не помогут? Неплохие концепцие, которые показали себя и зарекомендовали. ПОчему их категорически нельзя использовать?

V>>Я во всем желаю видеть выгоду. У меня из личностных ценностей не только деньги.
E>ИМХО это внутреннипротевоечивый посыл Но общий смысл моего возражения очень прост. Если изучение STL ценность для тебя, то ты просто не пойдёшь в нашу контору. Спроси на собеседовании используют ли в конторео STL или нет

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

E>Ну а если тебе реально интересно посмотреть на наш фреймворк, то надо просто пройти собеседование и попасть в отдел исследований и разработок

Да хоть на интерфейсы какие-нибудь то взглянуть можно? Под подпиской о неразглашении?

E>Контролируемым фактором я считаю планирование производимых работ и хорошее ими управление. А ты значит надеешься на флюктуации? Ну-ну

V>>Вы случайно не велосипеды выпускаете?
E>Мы случайно учимся быть взаимовежливыми.
Прошу прощения Я всегда за взаимовежливость, прошу не щитать мои посты наездами или провокациями на свещенную войну. Я действительно хочу понять, так сказать добраться до истины, поэтому иногда слишком резок.. ну уж простите

E>А у вас оборт по торговле ПО хотя бы $10 000 000 сулчайно превосходит?
У нас ПО не торгуют, вот в чем наверное загвоздка вся. У нас оно вылизывается, и уровень разработки хороший. Но софт для внутреннего использования, поэтому нам пофиг что использовать, лишь бы работало, было удобно и самое главное — это высокий уровень сопровождения, поэтому выбор стандартных средств вместо написания новых есть хорошо

>>>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>>>
>>> S>Кроме производительности. А формально — да, подходит.
>>>
>>> А какие проблемы с производительностью?
>
> S>Дак вполне очевидные — при удалении умных указателей придется шариться по спискам объектов, на которые ссылаешься, вычищать оттуда себя. Потом бежать по спискам подписчиков, уведомлять их о своей кончине.
>
> По спискам шариться не надо — next и prev у элемента имеются.
> По спискам подписчиков тут бегать не надо вообще.
> Если ты сделаешь замеры, то увидишь, что такой указатель будет работать быстрее обычного.

Тогда я видимо не вполне понимаю о чем речь. Как я понимаю, при удалении объект должен обойти весь список умных указателей своего типа и обнулить/как то еще пометить как невалидные все указатели, ссылающиеся на его объект. Или речь идет о чем-то другом?

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

V>Я думаю что программисты у вас деляться на те, кто разрабатывает и поддерживает фреймворк, и те кто его используют (прикладные): просто было бы нехорошо чтобы те же приладники время от времени полгядывали в сторону "запрещенного" STL+Boost пуская слюни конечно из тех, кто раньше его учили и использовали.

Конечно есть программисты, которые поддерживают фреймворк. Но это не значит, что остальные не знают про STL и boost

V>Еще интересно знать, отказались ли вы от совершенно стандартных средств, таких как strXXX, memXXX, malloc и проч. Т.е. при вашем подходе было бы уместно ожидать, что стандартных библиотек вообще не используется.
Ну мы постепенно отказываемся от всяких стандартных библиотек...

V>И все же избранный вами подход доказывает только одно правило: без STL можно хорошо жить. Но никак не опровергает обратного!
Конечно. Только то, что STL нифига не ключевая технология успеха
Кроме того в STL есть свои проблемы и свои косяки. Можно обсудить разные конкретные обстоятельства, но где-то тут уже был такой флейм. Лично мне в STL контейнерах не больше всего ненравятся три обстоятельства
1) Элементы должны иметь семантику значения
2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.

V>Я бы по такому пути не пошел. И никому бы не советовал. А вы не доказали обратного — не жили на STL+Boost как минимум. Так что ваши советы слишком однобоко обоснованы, слишком похоже на какое-то исключения из правил в рамках обстоятельств финансирования, политики и проч..

Ну у нас были разработки, базирующиеся на STL. Нам не понравилось
КРоме того мы отказались не только от STL, но и от MFC, от PowerPlant, и много от чего ещё
Кроме того у нас есть большой опыт роаботы с партнёрами и аутсорсерами. И там тоже всё однозначно. STL как-то неудачно спроектирвоан в смысле управления командой разработчиков, ИМХО

V>Почему не помогут? Неплохие концепции, которые показали себя и зарекомендовали. Почему их категорически нельзя использовать?
Да не "нальзя", а "надо объяснить зачем". При таком подходе внезапно выясняется, что реальных аргументов при выборе "фирменный фреймворк" vs "STL" нет, за редким довольно исключением

V>Ну если деньги будут платить очень неплохие деньги, то пойду Фиг с ним с STL Просто может так получиться, что я буду не в восторге от того, чем вы его заменяете, а может получиться и наоборот, кто знает Это ж раньше времени никак не узнать.. Правда за очень хорошие деньги готов буду и смириться..

Ну "очень хорошие деньги" будут работать против экономической эффективности отказа от STL. Но реально среди программистов нет спроса на "использование STL в конторе".

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

ИМХО в дешевизне поддержки и развития больше всех заинтересованы производители коробочного ПО, продаваемого большими тиражами

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

E>>Ну контейнеры у нас шаблонные, но для обсуждаемой функциональности template typedef не требуется
J>ну или требуемая функциональность вцементирована, тогда тоже да

Ну слово "вцементированна" -- это всего лишь эмоуиональная оценка. Мне больше нравится слово "поддержана"

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

WH>>Такого в нормальных средах с ГЦ не бывает.
E>Ну библиотека-то сторонняя...
И?

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

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

Ты показал полное не знание того как работают всякие жабы и дот неты.

Там один ГЦ и один рантайм на всех навязывается просто автоматически. И ничего с этим сделать нельзя.
Благодоря этому не возникает никаких проблем с тем где объект создан.
Нет проблем с полетами исключений между модулями.
...

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

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

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

E>Обычно ошибается, кстати.
Но-но. Подобные приемчики оставь для нюбов. На меня они не действуют.

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

WH>>И это совершенно иначе мне очень не нравится.
E>Ну а вот и не совсем так дела обстоят
Вот только я ни разу не видил код который живет и с исключениями и без.

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

WH>>Прекрасно живет в so'шках и dll'ках...
E>Да? А если ты хочешь чтобы она разделяла рантайм с основным приложением. Скажем из соображений общей кучи? Это что касается DLL
В данном случае это нафиг не нужно.
Но если очень хочется эту либу можно собрать как угодно. Хоть статически прилиньковать.

E>А что касается SO, то ты просто не пробовал взять эту SO и хост, собранный с другим STL. Попробуй -- узнаешь много нового
Это сильно зависит от того как so'шку собирать.
Я однажды собрал so'шку которая работала под кучей линухов без перекомпиляции... а там не только разные STL'и...

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

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

WH>Там один ГЦ и один рантайм на всех навязывается просто автоматически. И ничего с этим сделать нельзя.
WH>Благодоря этому не возникает никаких проблем с тем где объект создан.
WH>Нет проблем с полетами исключений между модулями.
WH>...

А если библиотека не дотнетовская?

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

E>>Ещё бывают зависимости между хедерами. Да и в хедерах много чего бывает...
WH>А в чем проблема то?
WH>Точно также можно отгрепать сторонние либы.
Ну пролема в том, что всё это надо делать, тестировать то, что это всё ещё работает, в том числе и с новыми версиями либ и т. д.
ИМХО свои контейнеры дешевле в поддержке...

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

E>>Обычно ошибается, кстати.
WH>Но-но. Подобные приемчики оставь для нюбов. На меня они не действуют.
А кто такие "нюбы" и какие приёмчики?
Я просто делюсь своим опытом...

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

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

WH>ИМХО гораздо легче чем от исключений.
Э-э-э? Как? Переписать весь код?
Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?

WH>Но если очень хочется эту либу можно собрать как угодно. Хоть статически прилиньковать.
Ну если ты можешь предоставить клиенту возможность самому переносить твоё изделиен на его платыорму/рантайм/средство разработки, то всё ещё проще будет у тебя...

WH>Я однажды собрал so'шку которая работала под кучей линухов без перекомпиляции... а там не только разные STL'и...
Это тонкий вопрос поро разные STLи... Вообще-то с gcc обычно стандартный комплект идёт...
Сколько версий gcc шло с этой "кучей Linux'ов"?
Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...

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

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

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

Это ещё от чего?
Есть какие-то принципиальные ограничения или ты не знаешь как это сделать?

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


>>>>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>>>>
>>>> S>Кроме производительности. А формально — да, подходит.
>>>>
>>>> А какие проблемы с производительностью?
>>
>> S>Дак вполне очевидные — при удалении умных указателей придется шариться по спискам объектов, на которые ссылаешься, вычищать оттуда себя. Потом бежать по спискам подписчиков, уведомлять их о своей кончине.
>>
>> По спискам шариться не надо — next и prev у элемента имеются.
>> По спискам подписчиков тут бегать не надо вообще.
>> Если ты сделаешь замеры, то увидишь, что такой указатель будет работать быстрее обычного.

S>Тогда я видимо не вполне понимаю о чем речь. Как я понимаю, при удалении объект должен обойти весь список умных указателей своего типа и обнулить/как то еще пометить как невалидные все указатели, ссылающиеся на его объект. Или речь идет о чем-то другом?

При удалении *объекта*, но не при удалении *указателя*, как ты написал.
И при удалении объекта надо обходить не весь список умных указателей своего типа, а весь список умных указателей, которые ссылались на этот объект.

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

E>А если библиотека не дотнетовская?
Тогда интероп. Но это отдельные пляски с бубном.
Главное то что если библиотека .НЕТовская то никаких проблем нет.

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

E>Ну пролема в том, что всё это надо делать, тестировать то, что это всё ещё работает, в том числе и с новыми версиями либ и т. д.
E>ИМХО свои контейнеры дешевле в поддержке...
Автоматические тесты не пишем принципиально?

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

E>Ну такое радикальное утверждение он вряд ли обоснует.
У меня получается. Но тут нужно говорить предметно, а не вобщем.
И результат избавления от всяких там статиков и синглетонов всегда оказывался положительным.

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

E>Э-э-э? Как? Переписать весь код?
E>Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?
И что? Если это не понимает компилятор С++ то это уже скорее компилятор С. И тогда тебе нужно писать на С.

E>Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...
Угу... мне это конечно же приснилось...

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

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

E>Это помогает под виндой.
E>Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста. И ничуть не запарится. Так что какой там интерфейс -- не суть. Тем более, что любой интерфейс можно завернуть в автогенерённый переходник. Проблема в доступности symbols друг друга.

so/dll не должны зависеть от языка. Представляю, как ты вызовешь из Perl функцию с замангленным именем, которая бросает исключения.