Здравствуйте, Lipatov, Вы писали:
L>Здравствуйте, Young, Вы писали:
Y>>STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки.... L>Интересно, и почем же это зло? Шаблоны есть в последнем стандарте языка. MS и Borland их реализует, так, что же еще надо?
Охх, если бы MS и Борландом все ограничивалось....
L>С портировании на другие языки — проблема, но те приимущества, которые они дают в C++, все с лихвой перекрывают. Если кто-то скажет, что никаких преимуществ нет, тот никогда не использовал шаблоны! (если не считать каких-нибудь халявных курсовиков в институте). Насчет раздуывания кода при использовании шаблонов, то вы не задумывались, сколько кода генерируется в языках позволяющих реализовывать сложные алгоритмы одной строчкой?
Шаблоны ухудшают читабельность кода. Это уже зло которое можно мало простить.
Сколько кода получить в результирующим бинарнике и как быстро он будет работать, как показывает практика, вещи не критичные с экнономической точки зрения.
А вот возможнось взять и пренести прогу под десяток платформ и под три языка, причем это сделать очень быстро и с возможностью разпаралелить на пяток программистов — вот это экономически выгодно.
Да и ей богу не вижу я премуществ.
При правильном проектировании в ОПП интерфесов и классов за глаза хватает.
Скорость — это в большенстве случаев не важно, да и не ускоряют шаблоны сильно...
Так в чем премущество?
Y>>Я предпочту видеть собственный класс вектор и класс коллекцию, и не вижу чем это хуже (а критерий объективный мне известен один — экономический) чем шаблоны..... L>Что значит собственный класс-вектор или класс-коллекция? Не заметил чтобы программеры утруждали себя созданием таких вещей, используют стандартные и не задумываются! А среди них шаблоны — сомое лучшее и безопасное решение.
И абсолютно не портируемуе.
А на счет утруждали....
Очень занимательно смотреть — как люди пишут шаблонные обертки над STL чтобы не наступать на грабли которые в нем зарыты, и иметь возможность переходить от одниз STL к другим....
Я как минимум знаю два крупных проекты, где люди после определенных проблем таки писали обвертки......
P.S. Хотя каждый смотрит со своей колокольни....... Но я мало представляю случаев когда в написании программы может сильно понадобиться шаблоны и это ускорит написание ее.
Y>>STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки....
Y>>Я предпочту видеть собственный класс вектор и класс коллекцию, и не вижу чем это хуже (а критерий объективный мне известен один — экономический) чем шаблоны.....
_>А теперь давай спомним с чего все начиналось.
А ты посмотри на англоязычное название форума...
_>Дельфи это почти счастье — вот я и попробовал показать что бывает очень даже несчастье. Причем многие люди, кто активно работает с VCL, говорят, что и он несчастье. Про невозможность решить приведенные мною задачи в одну строчку и говорить не приходится...
Нууу...это скучно, понятно что наиболее удобный язык это тот который наиболее экономически оправдан.....
Здравствуйте, Young, Вы писали:
Y>Здравствуйте, Lipatov, Вы писали:
L>>Здравствуйте, Young, Вы писали:
Y>>>STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки.... L>>Интересно, и почем же это зло? Шаблоны есть в последнем стандарте языка. MS и Borland их реализует, так, что же еще надо?
Y>Охх, если бы MS и Борландом все ограничивалось....
Ok, добавим к списку Intel (кстати самый быстрый из компиляторов С++)
Y>Шаблоны ухудшают читабельность кода. Это уже зло которое можно мало простить.
Это Вас страшный вид внутренностей STL наверное пугает. А на самом деле читабельнось только
улучшается т.к. пропадают бесконечные приведения типов (как например при работе с коллекциями в Object Pascal)
Y>А вот возможнось взять и пренести прогу под десяток платформ и под три языка, причем это сделать очень быстро и с возможностью разпаралелить на пяток программистов — вот это экономически выгодно.
Если программисты знают толк в C++, то можно
Здравствуйте, Lipatov, Вы писали:
L>Здравствуйте, Young, Вы писали:
Y>>Здравствуйте, Lipatov, Вы писали:
L>>>Здравствуйте, Young, Вы писали:
Y>>>>STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки.... L>>>Интересно, и почем же это зло? Шаблоны есть в последнем стандарте языка. MS и Borland их реализует, так, что же еще надо?
Y>>Охх, если бы MS и Борландом все ограничивалось.... L>Ok, добавим к списку Intel (кстати самый быстрый из компиляторов С++)
Угу, и ограничем свой рынок только PC платформами..... А учитывая что в количественном отношении этот рынок не самый емкий — это не лучшиый вариант....
Y>>Шаблоны ухудшают читабельность кода. Это уже зло которое можно мало простить. L>Это Вас страшный вид внутренностей STL наверное пугает. А на самом деле читабельнось только L>улучшается т.к. пропадают бесконечные приведения типов (как например при работе с коллекциями в Object Pascal)
Y>>А вот возможнось взять и пренести прогу под десяток платформ и под три языка, причем это сделать очень быстро и с возможностью разпаралелить на пяток программистов — вот это экономически выгодно. L>Если программисты знают толк в C++, то можно
Можно, только не выгодно....
Надеюсь если вы согласны — если взять один проект который изначально проеетировался с шаблонами и без и нанять программиста и поставить задачи
1. Разобраться в проекте
2. Внести туда существенные изменения
3. Портировать на другую платформу(язык)
Как показывает практика на проект с шаблонами требуетться больше времени — что опять не выгодно.....
А вот большого прироста скорости разработки при использовании шаблонов я не замечал.....
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, _vovin, Вы писали:
_>>Я предпочитаю язык, в котором указанные задачи решаются следующим образом: _>>
_>>(1 to: 100 by: n) inject: 0 into: [:sum :e | sum + e]
_>>
_>>
_>>collection select: [:each | each > 0]
_>>
U>И ты считаешь этот код более читабельным, чем традиционный? U>Возможно, конечно, это объясняется отсутствием привычки, но по-моему этот код ужасен, т.к. чтобы его понять требуется нехило напрячь извилины, хотя задачка совсем простенькая. Как будет выглядеть подобный код в более сложных случаях, я даже представить боюсь.
Ты в курсе, что человеческому мозгу достаточно часов 20, чтобы адаптироваться к новому, не слишком сложному занятию? Единственный тормоз — это предубеждение, субъективный фактор.
Второй пример вообще читается почти как натуральный язык:
Из объекта collection выбрать элементы each, такие что each > 0.
Здравствуйте, _vovin, Вы писали:
_>Ты в курсе, что человеческому мозгу достаточно часов 20, чтобы адаптироваться к новому, не слишком сложному занятию? Единственный тормоз — это предубеждение, субъективный фактор.
Может быть, хотя и выглядит сильно оптимистично.
_>Второй пример вообще читается почти как натуральный язык: _>Из объекта collection выбрать элементы each, такие что each > 0.
То что ты хочешь, по-моему, сильно похоже на SQL, который может быть очень удобен и прост на несложных выборках, но в сложных случаях он явно куда хуже отлаживается, чем традиционный код.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, _vovin, Вы писали:
_>>Ты в курсе, что человеческому мозгу достаточно часов 20, чтобы адаптироваться к новому, не слишком сложному занятию? Единственный тормоз — это предубеждение, субъективный фактор.
U>Может быть, хотя и выглядит сильно оптимистично.
Именно так. Если у тебя есть желание, ты можешь освоить все что угодно и достаточно быстро. Особенно если это что-то дает новые преимущества.
Но если ты настроен категорично — "это синтаксис читается ужасно, он мне никогда не понравится" — тогда ты прав, лично тебе это не покатит, может даже затормозит работу.
_>>Второй пример вообще читается почти как натуральный язык: _>>Из объекта collection выбрать элементы each, такие что each > 0.
U>То что ты хочешь, по-моему, сильно похоже на SQL, который может быть очень удобен и прост на несложных выборках, но в сложных случаях он явно куда хуже отлаживается, чем традиционный код.
Ты так говоришь, как будто речь идет о недоязыке и недовозможностях.
Между тем в этой среде отладка такая, что в ней можно просматривать/модифицировать состояние любых объектов, на лету модифицировать методы и классы, добавлять новые методы/классы/атрибуты и т.д.
И даже refactoring работает работает живьем на коде, выполняющемся в данный момент в другом потоке. Изменения, есс-но, применяются моментально.
Когда я работаю на Java в IDEA я чувствую себя как в наручниках.
Здравствуйте, _vovin, Вы писали:
_>Ты так говоришь, как будто речь идет о недоязыке и недовозможностях. _>Между тем в этой среде отладка такая, что в ней можно просматривать/модифицировать состояние любых объектов, на лету модифицировать методы и классы, добавлять новые методы/классы/атрибуты и т.д. _>И даже refactoring работает работает живьем на коде, выполняющемся в данный момент в другом потоке. Изменения, есс-но, применяются моментально. _>Когда я работаю на Java в IDEA я чувствую себя как в наручниках.
О какой среде речь? И почему, если она такая удобная, используешь Java?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, _vovin, Вы писали:
_>>Ты так говоришь, как будто речь идет о недоязыке и недовозможностях. _>>Между тем в этой среде отладка такая, что в ней можно просматривать/модифицировать состояние любых объектов, на лету модифицировать методы и классы, добавлять новые методы/классы/атрибуты и т.д. _>>И даже refactoring работает работает живьем на коде, выполняющемся в данный момент в другом потоке. Изменения, есс-но, применяются моментально. _>>Когда я работаю на Java в IDEA я чувствую себя как в наручниках.
U>О какой среде речь? И почему, если она такая удобная, используешь Java?
Dolphin Smalltalk или VisualWorks Smalltalk.
Java, потому что работа такая.
Здравствуйте, _vovin, Вы писали:
_>Dolphin Smalltalk или VisualWorks Smalltalk.
Никогда бы не подумал, что в Smalltalk'е подобный синтаксис. А почему, если в Smalltalk'е все так хорошо, его, насколько я знаю, очень редко используют в реальных проектах?
Здравствуйте, Young, Вы писали:
Y>Надеюсь если вы согласны — если взять один проект который изначально проеетировался с шаблонами и без и нанять программиста и поставить задачи Y>1. Разобраться в проекте Y>2. Внести туда существенные изменения Y>3. Портировать на другую платформу(язык)
Y>Как показывает практика на проект с шаблонами требуетться больше времени — что опять не выгодно.....
Y>А вот большого прироста скорости разработки при использовании шаблонов я не замечал.....
Не буду про шаблоны, а вот про дженерики только положительные эмоции. И скорость на проект с ними намного меньше, т.к. это классы с неопределенными типами, все премущества ООП и подсказки после запятой.
Применять теже вектора тоже нужно с умом, т.к. скорость заполнения указателей намного выше чем некоторой большой структуры, и затраты на поиск намного меньше чем на MOVSW и Realloc.
А по поводу переносимости это конечно вопрос но думаю не столь долгий, т.к. код абстрактный.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, _vovin, Вы писали:
_>>Dolphin Smalltalk или VisualWorks Smalltalk.
U>Никогда бы не подумал, что в Smalltalk'е подобный синтаксис. А почему, если в Smalltalk'е все так хорошо, его, насколько я знаю, очень редко используют в реальных проектах?
Ну скажем там не все так хорошо. Есть объективные недостатки, но оценивая возможность быстрого создания качественного ПО, он сильно опережает популярные ныне технологии.
Самым сильным тормозом является инерция. Все ПО сейчас производится на основе принципов Unix-подобной системы. Файлы, исходные тексты, компиляция, компоновка, запуске. Smalltalk сильно выбивается из подобной структуры. Точнее он предоставляет собой новую, более продвинутую систему.
Как сказал Dan Ingalls, ОС это то, что нельзя реализовать средствами языки, и такого не должно быть.
То, что мы видим сейчас в .NET и Longhorn, является малым шажком в направлении Smalltalk как системы. В частности WinFS это уже не плоская файловая система, а что-то более похожая на объектное хранилище. И так далее.
Здравствуйте, _vovin, Вы писали:
_>Ну скажем там не все так хорошо. Есть объективные недостатки, но оценивая возможность быстрого создания качественного ПО, он сильно опережает популярные ныне технологии.
А можно немного подробнее про недостатки по сравнению с тем же .Net? Одной инерцией нельзя объяснить крайне редкое коммерческое использование Smalltalk'а.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, _vovin, Вы писали:
_>>Ну скажем там не все так хорошо. Есть объективные недостатки, но оценивая возможность быстрого создания качественного ПО, он сильно опережает популярные ныне технологии.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, _vovin, Вы писали:
_>>Ну скажем там не все так хорошо. Есть объективные недостатки, но оценивая возможность быстрого создания качественного ПО, он сильно опережает популярные ныне технологии.
U>А можно немного подробнее про недостатки по сравнению с тем же .Net? Одной инерцией нельзя объяснить крайне редкое коммерческое использование Smalltalk'а.
Инерция тут в двух смыслах. Первый это инерция программистов и менеджмента. Второе это технологическая инерция. В целом все растет из самодостаточности и самоизолированности Smalltalk.
А недостатки примерно следующие:
Разработка приложений осуществляется в едином объектном пространстве, где вместе существуют и объекты приложения и инструменты разработки. На диске это выглядит как один image-файл. Создание конечного приложения осуществляется декомпозицией объектной системы, а не компоновкой модулей, как при обычном подходе.
Ограниченные возможности интеграции с внешними системами. Допустим, нельзя скомпилизовать один файл и прилинковать его к проекту, написанному на другом языке. Возможен только аналог Interop.
Динамическая типизация многим кажется ненадежной.
Непривычный для многих синтаксис.
У языка нет хозяина, больших денег и активного маркетинга. Показателен пример VB и Java — языков для чайников (всмысле программистов) и тостеров (всмысле приборов) соответственно.
К слову сказать, некоторые недостатки одновременно являются и достоинствами. Т.е. все имеет свои плюсы и минусы. Например мне нравится (и я вижу от этого существенный выигрыш) синтаксис, динамическая типизация, единая объектная среда...
Здравствуйте, _vovin, Вы писали:
_>Инерция тут в двух смыслах. Первый это инерция программистов и менеджмента. Второе это технологическая инерция. В целом все растет из самодостаточности и самоизолированности Smalltalk. _>А недостатки примерно следующие: _>[list] _>
Разработка приложений осуществляется в едином объектном пространстве, где вместе существуют и объекты приложения и инструменты разработки. На диске это выглядит как один image-файл. Создание конечного приложения осуществляется декомпозицией объектной системы, а не компоновкой модулей, как при обычном подходе.
Не понял. Т.е. все приложения Smalltalk'а лежат в одном месте в общем надпространстве имен?
_>
Ограниченные возможности интеграции с внешними системами. Допустим, нельзя скомпилизовать один файл и прилинковать его к проекту, написанному на другом языке. Возможен только аналог Interop.
Т.е. нет механизма подобного механизму dll?
_>
Динамическая типизация многим кажется ненадежной.
Статической вообще нет что ли? Компилятор соответствия типов вообще не проверяет?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, _vovin, Вы писали:
_>>Инерция тут в двух смыслах. Первый это инерция программистов и менеджмента. Второе это технологическая инерция. В целом все растет из самодостаточности и самоизолированности Smalltalk. _>>А недостатки примерно следующие: _>>[list] _>>
Разработка приложений осуществляется в едином объектном пространстве, где вместе существуют и объекты приложения и инструменты разработки. На диске это выглядит как один image-файл. Создание конечного приложения осуществляется декомпозицией объектной системы, а не компоновкой модулей, как при обычном подходе.
U>Не понял. Т.е. все приложения Smalltalk'а лежат в одном месте в общем надпространстве имен?
Могут лежать. Smalltalk это общее пространство объектов. У тебя есть инструменты типа инспектора, браузера классов, отладчика с т.д., с помощью которых ты можешь создавать приложения или модифицировать сами эти инструменты. Также есть инструменты сохранения частей кода на диске/репозитории — в виде packages или еще как-то.
Разработка обычно идет так — в свой development image загружается нужный package и с ним идет работа. Image можно сохранять, он представляет собой снимок твоей текущей работы, вплоть до состояния отладчика и текущей выполняемой командой. Но image это вещь в себе, чтобы сохранить проект или вести совместную разработку используются именно packages. Синхронизация может идти через файлы или через версионный контроль.
_>>
Ограниченные возможности интеграции с внешними системами. Допустим, нельзя скомпилизовать один файл и прилинковать его к проекту, написанному на другом языке. Возможен только аналог Interop.
U>Т.е. нет механизма подобного механизму dll?
Есс-но что-то подобное есть, но как всегда намного лучше.
Можно части кода приложения хранить в бинарном виде отдельно и загружать/выгружать их в любой момент времени. В том числе во время работы приложения можно загрузить новую версию package, все пропатчится на лету.
Таким образом можно задеплоить AppServer не удаляя из image инструменты разработки. Для того, чтобы проапгрейдить сервер, можно удаленно зайти на сервер, открыть в приложении окно версионного контроля, загрузить из репозитория последнюю версию, и все, приложение продолжает непрерывную работу.
Еще типичный вариант. При возникновении исключения в AppServer посылается уведомление по почте. После чего заходишь на сервер, видишь окно отладчика в точке возникновения исключения, разбираешь проблему, вносишь все необходимые изменения и закидываешь их на версионный контроль. Буквально одним махом прошли все этапы исправления бага.
_>>
Динамическая типизация многим кажется ненадежной.
U>Статической вообще нет что ли? Компилятор соответствия типов вообще не проверяет?
Динамическая она и есть отрицание статической. Контроль типов осуществляет на этапе выполнения.
Причем ошибки типизации появляются достаточно редко. Примерно так же, как NullPointerException в Java, или даже реже. Причин тут может быть несколько. Это и выразительность синтаксиса (keyword selectors это фактически документация); и то что между вводом текста программы и его выполнением проходит обычно несколько секунд; и что отладчик можно использовать как инструмент разработки — вводишь одну строчку, запускаешь, выдает исключение "метод не найдет", говоришь создать такой метод, вводишь текст нового метода, продолжаешь выполнение, опять исключение и т.д. — то есть та же компиляция, только уже стопроцентно вылавливающая все глюки, nil мимо не проскочит, виден весь контекст выполнения...
Здравствуйте, Young, Вы писали:
Y>Здравствуйте, Lipatov, Вы писали:
L>>Здравствуйте, Young, Вы писали:
Y>>>STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки.... L>>Интересно, и почем же это зло? Шаблоны есть в последнем стандарте языка. MS и Borland их реализует, так, что же еще надо?
Y>Охх, если бы MS и Борландом все ограничивалось....
А можешь еще че-нить назвать? Ну есть конечно еще компилеры под плюсы, но я чето нечасто сталкивался с задачей перекомпилить программу каким-нить экзотическим компилятором
L>>С портировании на другие языки — проблема, но те приимущества, которые они дают в C++, все с лихвой перекрывают. Если кто-то скажет, что никаких преимуществ нет, тот никогда не использовал шаблоны! (если не считать каких-нибудь халявных курсовиков в институте). Насчет раздуывания кода при использовании шаблонов, то вы не задумывались, сколько кода генерируется в языках позволяющих реализовывать сложные алгоритмы одной строчкой?
Y>Шаблоны ухудшают читабельность кода. Это уже зло которое можно мало простить.
Заблуждение
Y>Сколько кода получить в результирующим бинарнике и как быстро он будет работать, как показывает практика, вещи не критичные с экнономической точки зрения.
Скороть (как показывает практика!) есть одна из наиболее критичных частей. прости старик, ты ошибаешся.
Y>А вот возможнось взять и пренести прогу под десяток платформ и под три языка, причем это сделать очень быстро и с возможностью разпаралелить на пяток программистов — вот это экономически выгодно.
А кому это надо? Ты часто переносил? Это экзотика — десяток платформ. Ты наверное и не назовешь десяток платформ. А насчет трех языков — ну перенеси мне ее на бейсик или смол-ток с чего бы то ни было. Я думаю тут дельфы и си на равных — одинаково геморно и АБСОЛЮТНО ненужно.
Y>Да и ей богу не вижу я премуществ.
Пагано
Y>При правильном проектировании в ОПП интерфесов и классов за глаза хватает. Y>Скорость — это в большенстве случаев не важно, да и не ускоряют шаблоны сильно... Y>Так в чем премущество?
"Скорость — не важно" = см. выше.
Преимущество в том что за тебя уже все написали. Не все, но многое. Ваще сила шаблонов в том что они приспособлены для классов и типов которых еще нет в помине, что позволяет очень гибко и быстро расширять программу.
Y>>>Я предпочту видеть собственный класс вектор и класс коллекцию, и не вижу чем это хуже (а критерий объективный мне известен один — экономический) чем шаблоны..... L>>Что значит собственный класс-вектор или класс-коллекция? Не заметил чтобы программеры утруждали себя созданием таких вещей, используют стандартные и не задумываются! А среди них шаблоны — сомое лучшее и безопасное решение.
Y>И абсолютно не портируемуе.
Куда не портируемые?
Y>А на счет утруждали.... Y>Очень занимательно смотреть — как люди пишут шаблонные обертки над STL чтобы не наступать на грабли которые в нем зарыты, и иметь возможность переходить от одниз STL к другим.... Y>Я как минимум знаю два крупных проекты, где люди после определенных проблем таки писали обвертки......
А я вот не знаю ни одного. СТЛ и шаблоны ваще — это часть стандарта плюсов. Не слышал еще нареканий. Могут быть кривые реализации СТЛ (например в 6-й студии был один грешок), но это опять же никак не влияет на идею.
Y>P.S. Хотя каждый смотрит со своей колокольни....... Но я мало представляю случаев когда в написании программы может сильно понадобиться шаблоны и это ускорит написание ее.
Значит ты крупнее 3х окошек с кнопками и убогой логикой ничего не писал.
L>>>С портировании на другие языки — проблема, но те приимущества, которые они дают в C++, все с лихвой перекрывают. Если кто-то скажет, что никаких преимуществ нет, тот никогда не использовал шаблоны! (если не считать каких-нибудь халявных курсовиков в институте). Насчет раздуывания кода при использовании шаблонов, то вы не задумывались, сколько кода генерируется в языках позволяющих реализовывать сложные алгоритмы одной строчкой?
Y>>Шаблоны ухудшают читабельность кода. Это уже зло которое можно мало простить.
G>Заблуждение
Мотивация?
Y>>Сколько кода получить в результирующим бинарнике и как быстро он будет работать, как показывает практика, вещи не критичные с экнономической точки зрения.
G>Скороть (как показывает практика!) есть одна из наиболее критичных частей. прости старик, ты ошибаешся.
Да???
Вот смотрю я у себя на список установленных программ, и не вижу ни одной главной (или хотя бы основной) фичей которой была бы скорость работы. Даже более того не помню ни одной доминирующей на рынке программы которая была существнно быстрее конкурентов.
Более того, смотрою я на процесс разработки соверемнных 3d игр — даже там скорость в целом не важна. Практически все современные игры можно ускорить на процентов 10-20 затратив процентов 10 денег от общего процесса разработки. Только экономически выгодней в мин. требованиях написать P43.2 вместо P42.8 и потратить эти деньги на маркетинг.....
А в то что шаблоны при правильной арзитектуре могут дать прирост более 20% тоже не поверю.....
Даже более того — разработка трехмерных игр для мобильных телефонов — даже там экономически выгодней порезать полигоны и урезать текстуры чем сидеть код оптимизировать.....
Y>>А вот возможнось взять и пренести прогу под десяток платформ и под три языка, причем это сделать очень быстро и с возможностью разпаралелить на пяток программистов — вот это экономически выгодно.
G>А кому это надо? Ты часто переносил? Это экзотика — десяток платформ. Ты наверное и не назовешь десяток платформ. А насчет трех языков — ну перенеси мне ее на бейсик или смол-ток с чего бы то ни было. Я думаю тут дельфы и си на равных — одинаково геморно и АБСОЛЮТНО ненужно.
Хех.
Назову я тебе даже больше, я тебе лучше скажу с чем я сейчас работаю.
И так wintel, j2me, brew, мофан, PowerTV, PocketPC, PlamOS, Flash
Языки — java, с/c++, ну и ActionScript
Y>>Да и ей богу не вижу я премуществ.
G>Пагано
А мотивированно?
Y>>При правильном проектировании в ОПП интерфесов и классов за глаза хватает. Y>>Скорость — это в большенстве случаев не важно, да и не ускоряют шаблоны сильно... Y>>Так в чем премущество?
G>"Скорость — не важно" = см. выше. G>Преимущество в том что за тебя уже все написали. Не все, но многое. Ваще сила шаблонов в том что они приспособлены для классов и типов которых еще нет в помине, что позволяет очень гибко и быстро расширять программу.
Угу, а без шаблонов гибко и быстро расширять программу нельзя?
Хех....
Y>>>>Я предпочту видеть собственный класс вектор и класс коллекцию, и не вижу чем это хуже (а критерий объективный мне известен один — экономический) чем шаблоны..... L>>>Что значит собственный класс-вектор или класс-коллекция? Не заметил чтобы программеры утруждали себя созданием таких вещей, используют стандартные и не задумываются! А среди них шаблоны — сомое лучшее и безопасное решение.
Y>>И абсолютно не портируемуе.
G>Куда не портируемые?
С с/c++ на java к примеру.
Y>>А на счет утруждали.... Y>>Очень занимательно смотреть — как люди пишут шаблонные обертки над STL чтобы не наступать на грабли которые в нем зарыты, и иметь возможность переходить от одниз STL к другим.... Y>>Я как минимум знаю два крупных проекты, где люди после определенных проблем таки писали обвертки......
G>А я вот не знаю ни одного. СТЛ и шаблоны ваще — это часть стандарта плюсов. Не слышал еще нареканий. Могут быть кривые реализации СТЛ (например в 6-й студии был один грешок), но это опять же никак не влияет на идею.
Да??? В видать сильно отстал от жизни. Не подскажите в какой именно части спецификации языка С++ упоминается STL?
Y>>P.S. Хотя каждый смотрит со своей колокольни....... Но я мало представляю случаев когда в написании программы может сильно понадобиться шаблоны и это ускорит написание ее.
G>Значит ты крупнее 3х окошек с кнопками и убогой логикой ничего не писал.
Вам конечно виднее....
Хотя окошки с кнопками я действительно уже давно не писал....
