Здравствуйте, Андрей Коростелев, Вы писали:

АК>Я не против собственных велосипедов как класса. Однако на практике принятие решение о написании собственных библиотек взмен использования стандартных зачастую диктуется не недостатками последних, а тем что "софт плох, потому что что его писали не мы".

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

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

Для мелких, ИМХО, в вопросе STL всё упирается совсем в другой вопрос

Автор: Erop
Дата: 23.08.07

.

Но по многим вопросам можно действовать непрагамтически. В том числе и в области STL + буст...
Это обычно в области STL неспецифично

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

RO>Как это на платформе может не оказаться шаблонов? Там может не оказаться аппаратной поддержки исключений, там может быть мало памяти и т. д., но не платформа же сама реализует шаблоны? Шаблоны — это просто удобный такой кодогенератор, который работает отнюдь не во время исполнения программы, а во время компиляции, а это может происходить и на более другой нормальной платформе.

"А включаешь не работает". Шаблоны в доступном компилере были в режиме беты
Что бы было, если спользовать компилятор в C -- не известно. ИМХО легко могло бы не сойтись и отлаживаться очень неудобно.

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

B>Я не адекватен
B>У меня уйдет точно больше времени.
B>Насколько больше — это сильно зависит от самобытности контейнеров.
B>Предела самобытности не существует

Ну значит твой удел -- конторы, которые буст + STL
А вообще-то, по моему вот опыту, полезно при приходе нового программиста, тратить время не на обучение его библиотекам, а на обучение его принятой в группе практике программирования, в том числе и с использованием фирменных библиотек. Тем более, что они все с хелпами там и примерами...
Короче трудность не в библиотеках, а в практике, обычно. Практика-то она как бы очень разной бывает

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

E>Ну значит твой удел -- конторы, которые буст + STL

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

А для тебя будет трагедией, если ты приходишь в фирму, а там boost с STL'ем ?

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

R>И даже после того, как это станет частью стандарта и будут входить в поставку компилятора, это не будет мешать людям ещё как минимум лет 10 говорить, что это всё лажа/криво/медленно/сделано ламерами/не поддерживается на наших компиляторах/может не поддерживаться на компиляторах, на которые нам могут сказать перейти...
R>Особенно в контексте С++.

Да, только тогда эти люди должны будут объяснять, почему они не пользуются стандартными вещами.
В VC.6.0 есть, например, auto_ptr, почти как стандартный, но отгрести мелких проблем с его использованием можно без проблем. А все потому, что в VC.6.0 у auto_ptr нет метода reset. Т.е., если при работе в нормальных условиях ты написал по простоте и с надеждой на лушее:

auto_ptr< My > ptr( new My() );
...
ptr.reset();

то при переходе на VC.6.0 тебе придется все эти вызовы заменить на:

ptr = auto_ptr< My >();

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

А все потому, что в VC.6.0 auto_ptr появился еще до выхода стандарта.

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

R>Стандартная проблма — это управление не памятью, а управление ресурсами. На этой маленькой детали просела и Java и С#. С памятью-то всё хорошо (более менее, пока не умничаешь и делаешь что и все). А вот с остальными ресурсами — проблема. И код типа:

R>

R>...
R>mutex1.lock();
R>try
R>{
R>  mutex2.lock();
R>  try
R>  {
R>    ...
R>  }
R>  finally
R>  {
R>    mutex2.unlock();
R>  }
R>}
R>finally
R>{
R>  mutex1.unlock();
R>}
R>

R>совсем не производит впечатления. Уж извините, но на С это и то более удачно смотрится.

R>И С++ в этом плане предлагает как раз универсальное решение — это скопе-семантика + конструктор/деструктор. И умные указатели есть воплощение этого универсального решения.
R>Единственное чего не хватает, так это scoped/shared_handle/resource. Но надо надеяться, что у каждого желающего уже есть свой.

R>з.ы. с++/cli сделал ещё один шаг вперёд в этом направлении. Там ко всем вкусностям C#/Java (в плане управления ресурсами) добавлена ещё и скопе-семантика и "синхронный деструктор". Убийца!

Я то же долгое время думал, что управление памятью -- это часть проблемы управления ресурсами. Может быть где-то на высоком уровне абстракции это и так, но на практике лучше иметь отдельное стандартное решение для управления памятью (GC + возможность ручного управления) и набор решений для управления ресурсами.

Вот, можно взять несколько языков с GC, но особых проблем с управлением ресурсами там не много. В C# есть конструкция using.

В Ruby можно использовать блоки кода для scoped-ресурсов:

def lock_and_do_something( mutex, &blk )
  mutex.lock
  blk.call
ensure
  mutex.unlock
end
...
lock_and_do_something( mutex1 ) do
  lock_and_do_something( mutex2 ) do
    ...
  end
end

В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:

scope class Lock
  {
  this( Mutex m )
    {
      m_ = m;
      m_.lock;
    }
  ~this()
    {
      m_.unlock;
    }
  }
...
scope Lock l( mutex1 );
mutex2.lock;
scope(exit) mutex2.unlock;
...

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

Вот поэтому я с сарказмом и говорю о стандартных решениях стандартных проблем.

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

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

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

E>Конечно если ты уж решился на "шаблоны по полной", то есть набрал "подходящий для использования шаблонов" персонал (ну либо ты сам "подходящий"), и решил, что если компилятор С++ на платформе плохо поддерживает шаблоны, то это не твоя платфорома, а если клиенту нужен код под такой компилятор, то это не твой клиент, то да. Риски от использования STL сильно снижаются и тогда и заметная часть буста приемлема тоже.
E>А вот если ты пока что не решился на "шаблоны по полной", то STL конечно неоправданно оптимистическое решение. Только и всего.

R>>А если хочется использовать, то это вполне уже можно делать и сейчас (и уже как лет 5 точно).
E>Ну скорее если можешь себе позволить

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


Такая проблема есть. Естественно изначально надо сделать ряд предположений. Причём они касаются далеко не только шаблонов в С++. Шаблоны в С++ — это только верхушка айсберга.
Можно сделать минимум предположений. Но работать в такой обстановке будет на порядок труднее, когда нельзя ни на что полагаться. Зато код [в идеале] будет действительно мало от чего зависеть.
Можно сделать много предположений. Тогда работать будет на порядок проще. Зато код будет зависимым.
И тут получается стандартная палка о двух концах. Самые крайние позиции скорее всего абсурдны. Основной вопрос — кто где найдёт для себя золотую середину.

Если идти в сторону снижения предположений дальше, то скорее всего выбором будет С, а не С++, и уж точно не Java/C#. Не С99, а С89. Так же, если это сетевое приложение, то рассчитывать надо на модемное дайл-апное подключение. На ОС вообще надежды мало. Всё надо делать самому — включая юзер-левел тридинг и т.д... Разработка превращается в сущий ад — всё что хочешь сделать, и что сделать быстро, ты сделать не можешь.

Если идти в сторону увеличения предположений. То выбором будет С++ с полной поддержкорй шаблонов, а то и C#. ОС только одна. Сеть быстрая. И т.д. Разработка превращается в удовольствие. Но работать будет только на этой платформе...

Т.ч. с стоим выводом согласен — проблема не в шаблонах.

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

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

R>>И даже после того, как это станет частью стандарта и будут входить в поставку компилятора, это не будет мешать людям ещё как минимум лет 10 говорить, что это всё лажа/криво/медленно/сделано ламерами/не поддерживается на наших компиляторах/может не поддерживаться на компиляторах, на которые нам могут сказать перейти...
R>>Особенно в контексте С++.

E>Да, только тогда эти люди должны будут объяснять, почему они не пользуются стандартными вещами.

Потому что:

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

E>то при переходе на VC.6.0 тебе придется все эти вызовы заменить на:

"при переходе на VC.6.0" сейчас звучит забавно





E>Я то же долгое время думал, что управление памятью -- это часть проблемы управления ресурсами. Может быть где-то на высоком уровне абстракции это и так, но на практике лучше иметь отдельное стандартное решение для управления памятью (GC + возможность ручного управления) и набор решений для управления ресурсами.

Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
С++ будет одним из первых — если примут GC в стандарт, либо С++ + Boehm GC.

А чем умные-указатели не разновидность GC?


E>Вот, можно взять несколько языков с GC, но особых проблем с управлением ресурсами там не много. В C# есть конструкция using.

Это всё равно, что в С есть free(), поэтому проблем с управлением памятью там нет


E>В Ruby можно использовать блоки кода для scoped-ресурсов:

E>В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:

Это уже лучше, но это в точности до константы тоже, что и в С++.



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

Для управления scoped ресурсами (в т.ч. памятью) решение С++ имхо близко к идеалу.
Для shred ресурсов появляется некое неудобство в необходимости везде использовать shared_ptr вместо простого указателя.
Моя лично практика применения RAII для управления всеми типов ресурсов в проектах на С++ показывает, что подход не имеет существенных минусов и достаточно адекватен.


А в языках со сборкой мусора своих проблем тоже хватает — в Java, например, патчем догружади WeakRef...

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

R>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
MS CLI. Но это монстр ещё тот.

Erop wrote:

> Так писать нельзя:

> shared_ptr<T> p1 = CreateT();
> T* p2 = p1.get();
> shared_ptr<T> p3 = p2;

Можно, только что ты хочешь этим сказать??

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

R>>>И даже после того, как это станет частью стандарта и будут входить в поставку компилятора, это не будет мешать людям ещё как минимум лет 10 говорить, что это всё лажа/криво/медленно/сделано ламерами/не поддерживается на наших компиляторах/может не поддерживаться на компиляторах, на которые нам могут сказать перейти...
R>>>Особенно в контексте С++.

E>>Да, только тогда эти люди должны будут объяснять, почему они не пользуются стандартными вещами.

R>Потому что:
R>

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

Эти аргументы идут в лес без реальных доказательств превосходства самописных или других нестандартных решений по каким-либо критериям (скорость, exception safety, thread safety, компилируемость и пр.).

Насколько я помню по различным историям на RSDN случаи, когда люди отказывались от STL и получали серьезный прирост производительности. В Философии Программирования когда-то был рассказ о системе обработки информации о переговорах в биллинге какого-то мобильного оператора.

К сожалению, случаи, когда STL поставляется с какими-то глюками, случаются. Тут недавно DEADBEAF приводил ссылки на блоги MS-овских разработчиков VC, так там был пример просада производительности в STL из VC++8.0.

E>>то при переходе на VC.6.0 тебе придется все эти вызовы заменить на:

R>"при переходе на VC.6.0" сейчас звучит забавно

А вот мне, периодически, грусно.


E>>Я то же долгое время думал, что управление памятью -- это часть проблемы управления ресурсами. Может быть где-то на высоком уровне абстракции это и так, но на практике лучше иметь отдельное стандартное решение для управления памятью (GC + возможность ручного управления) и набор решений для управления ресурсами.

R>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.

D

R>С++ будет одним из первых — если примут GC в стандарт, либо С++ + Boehm GC.

R>А чем умные-указатели не разновидность GC?

Из-за различия в принципах работы.

E>>В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:

R>Это уже лучше, но это в точности до константы тоже, что и в С++.

Передергивание
В C++ (стандартном) нет finally и нет scope(exit) (который в D может быть разным).

R>Моя лично практика применения RAII для управления всеми типов ресурсов в проектах на С++ показывает, что подход не имеет существенных минусов и достаточно адекватен.

Ну тут я с тобой буду согласен до того момента, как придется совмещать RAII и управление памятью.

Я в последний год-полтора столкнулся с несколькими случаями, когда GC сильно бы облегчил жизнь и сделал бы мою работу гораздо проще. В двух случаях это было сопряжение с ACE-овскими штуками. Когда внешние по отношению к ACE-овским Event_Handler-ам объекты должны были держать ссылки на эти Event_Handler-ы. Но проблема была в том, что когда Event_Handler обнаруживал разрыв соединения и должен был отключится от реактора и исчезнуть. Но так, чтобы не повисла ссылка на него. С другой стороны, клиент Event_Handler-а мог завершить свою работу до разрыва соединения. И тогда Event_Handler должен был исчезнуть уже без опасений за ссылки на него.

Еще один случай -- попытка сделать объект, производный от FOX-овского виджета и агента. Оказалось, что как только FOX-овский виджет закрывается, соответствующий ему объект сразу уничтожается. Без какой-либо возможности отложенных действий (агент не мог исчезнуть в одночасье).

Во всех этих случаях GC был бы идеальным решением.

А в остальном да, RAII очень классная штука.

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

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

R>>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
S>MS CLI. Но это монстр ещё тот.

Это читерство. CLI — это не язык, а платформа.
Вопрос — есть ли эта возможность в каком-либо языке.
З.Ы. наверное правильнее MS .NET, либо ISO CLI.

Кстати, если ты про delete для управляемых объектов в c++/cli, то это ж вроде только вызов синхронного деструктора, а само освобождение памяти по прежнему делается GC.

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

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

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

R>>>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
S>>MS CLI. Но это монстр ещё тот.

R>Это читерство. CLI — это не язык, а платформа.
CLI — язык со своим синтаксисом.
.NET — платформа для CLI.

R>Вопрос — есть ли эта возможность в каком-либо языке.
R>З.Ы. наверное правильнее MS .NET, либо ISO CLI.

R>Кстати, если ты про delete для управляемых объектов в c++/cli, то это ж вроде только вызов синхронного деструктора, а само освобождение памяти по прежнему делается GC.
Нет, я про то, что можно использовать как managed, так и unmanaged.

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

R>Если идти в сторону снижения предположений дальше, то скорее всего выбором будет С, а не С++, и уж точно не Java/C#. Не С99, а С89. Так же, если это сетевое приложение, то рассчитывать надо на модемное дайл-апное подключение. На ОС вообще надежды мало. Всё надо делать самому — включая юзер-левел тридинг и т.д... Разработка превращается в сущий ад — всё что хочешь сделать, и что сделать быстро, ты сделать не можешь.

R>Если идти в сторону увеличения предположений. То выбором будет С++ с полной поддержкорй шаблонов, а то и C#. ОС только одна. Сеть быстрая. И т.д. Разработка превращается в удовольствие. Но работать будет только на этой платформе...

R>Т.ч. с стоим выводом согласен — проблема не в шаблонах.

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

Скажем используешь ты многопоточногсть. А на другой платформе с этим какие-то особенности. Ну, если ты использовал многопоточность как-то так, что надо поправить какой-то уровень абстрагирнования от реализации многопоточности, то это один разговор. А если тебе весь код переписывать надо -- то другой.

Соответсвенно, если ты используешь библиотеку шаблонных контейнеров, чпроектированных так, что их легко переписать на случай без шаблонов, или бех пробвинутых шаблонов, то проблема одного масштаба выходит. А если надо переписывать весь код -- то совсем другого.

К сожалению, STL так спроектирован, что при его последовательном использовании для абстрагирования от шаблонов прийдётся переписывать весь код

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

E>Во всех этих случаях GC был бы идеальным решением.
Ну, вообще-то, тут всё понятно что делать. Эти объекты какие-то уведомления наверное же рассылают о своей смерти? Или как-то можно проверить, что объект уже сдох? По хэндлу там, скажем?

Если так, то заводишь прокси-объект, которым и владеет твоя часть программы. А сам прокси убивается когда на него больше нет ссылок и грохает управляемый им объект, перед этим.
Ну а когда управляемый объект присылант уведомление, что он разрушен, то прокси это дело запоминает и остаётся в таком вот получдохшем состоянии...

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

B>А для тебя будет трагедией, если ты приходишь в фирму, а там boost с STL'ем ?
Нет. Я ими иногда пользуюсь даже.
Просто они мне кажутся часто не лучшим выбором.

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

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

E>>>Ну "умный указатель" уже и так стал стандартным решением. То, что его не было в STL ничего хорошего о STL, ИМХО, не говорит...
J>>Это вообще ничего про СТЛ не говорит. В СТЛ был auto_ptr, его хватало для кучи вещей.
E>К чему лицемерие? Мы же все знаем, что речь идёт на самом деле о конструкции std::vector<xxx::shared_ptr<my_fat_class> >...
Я не знал, честно!
Если мне это было нужно, я всегда пользовался std::vector<my_fat_class*> с явным временем жизни.
Более того, я на полную катушку использовал std::vector<xxx::auto_ptr<my_fat_class> > (естественно, с соответствующей версией СТЛ), потому что мне вектор нужен был просто для удобного хранения, и я никогда не пытался его сортировать или делать еще что-то в этом роде.

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

нет, корень ситуации с почти любой фичей, которая существовала к 98-му году, но не попала в стандартную библиотеку (например, хеши) — это огромное желание получить наконец стандарт. Иначе мы бы первой версии стандарта ждали бы до 2009 года.

E>Короче, сейчас у любой вменяемой конторы есть способ где-то взять какой-то sharel_ptr или разработать самостоятельно. ЗАДЁШЕВО. И пользоваться им с радостью...
Не сказал бы, что это настолько простая вещь, чтоб ее можно было задешево разработать самостоятельно.
Особенно если контора не нацелена на работу с нормальными программистами, а предпочитает брать студентов.

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

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

>> Так писать нельзя:
.>

>> shared_ptr<T> p1 = CreateT();
>> T* p2 = p1.get();
>> shared_ptr<T> p3 = p2;
.>

.>Можно, только что ты хочешь этим сказать??

А разве не получится проблем с владением?
Если я модефицирую код так:

T* p2 = p1.get();
shared_ptr<T> p3 = p2;
{
    shared_ptr<T> p1 = CreateT();
    p2 = p1.get();
    p3 = p2;
}
p3->my_method();

ничего не взорвётся?

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

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

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

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

R>>>>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
S>>>MS CLI. Но это монстр ещё тот.

R>>Это читерство. CLI — это не язык, а платформа.
S>CLI — язык со своим синтаксисом.
S>.NET — платформа для CLI.

Не путаешь с c++/cli?
А как тогда называется платформа, которую стандартизировала ISO? И каков синтаксис у языка CLI?

R>>Вопрос — есть ли эта возможность в каком-либо языке.
R>>З.Ы. наверное правильнее MS .NET, либо ISO CLI.

R>>Кстати, если ты про delete для управляемых объектов в c++/cli, то это ж вроде только вызов синхронного деструктора, а само освобождение памяти по прежнему делается GC.
S>Нет, я про то, что можно использовать как managed, так и unmanaged.

Хммм. Ну это не совсем то, что я имел в виду. Т.к. никакой объект нельзя либо подвергнуть GC, либо удалить явно.

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

[]

R>>Это читерство. CLI — это не язык, а платформа.
S>CLI — язык со своим синтаксисом.

строго говоря, cli — common language infrastructure

ты имеешь ввиду c++/cli?

S>.NET — платформа для CLI.

имплементация

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

B>>Ну там где память критична (микроконтроллеры, firmware и пр...) там и подходы совсем иные.
B>>Там вообще до сих пор С с ассемблером властвуют

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

Шаред птр в данном случае — абсолютно не критичны Правда практически обычно используют интрузивные шаред птр.