Насколько нужно кодеру знание стандартной библиотеки.
С аргументацией плиз.

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

А>Насколько нужно кодеру знание стандартной библиотеки.
А>С аргументацией плиз.

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

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

А>Насколько нужно кодеру знание стандартной библиотеки.
А>С аргументацией плиз.

Если работаешь в одной упряжке в солидной конторе над солидным проектом
то придется STL знать

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

КВА>Если работаешь в одной упряжке в солидной конторе над солидным проектом
КВА>то придется STL знать

Я бы не был столь категоричен — например, при разработке "солидных проектов" под Windows Mobile 2002-2003 в "солидной конторе" STL отсутствует в принципе, так как нет исключений ("самопальные" порты, конечно, есть, но это несколько не то). Да и компилятор eVC3/eVC4 соответствует предпоследнему (1998 года) стандарту еще меньше, чем VC6.

Здравствуйте, Аноним,

Зачастую под стандартной бибиотекой имеют ввиду не STDLIB, а STL.
Знание обязательно

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

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

А>>Насколько нужно кодеру знание стандартной библиотеки.
А>>С аргументацией плиз.

G>Нужно. Потому что это часть языка, при чем очень важная и широкоиспользуемая.

Что в ней важного? Анологичный функционал есть и у других либ, которые многим приятней, чем STDLIB.

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

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

А>>Насколько нужно кодеру знание стандартной библиотеки.
А>>С аргументацией плиз.

КВА>Если работаешь в одной упряжке в солидной конторе над солидным проектом
КВА>то придется STL знать

Так же, как и ATL, WTL, MFC и еще много страшных слов.
Почему именно STDLIB?

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

А>Насколько нужно кодеру знание стандартной библиотеки.
А>С аргументацией плиз.

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

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

А>Почему именно STDLIB?

Потому что она является "узаконенной" частью языка (а не "сторонней" библиотекой) — такой же как for, if, while, try и иже с ними.

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

PVA>Здравствуйте, Аноним,

PVA>Зачастую под стандартной бибиотекой имеют ввиду не STDLIB, а STL.
PVA>Знание обязательно
Внесем ясность.

в C есть C Standard Library

в C++ есть С++ Standard Library, которая состоит из:
С Standard Library,
Language Support Library, <-*
Diagnostics Library, |
General Utilities Library, |
Strings Library, |-- По старинке называют STL, хотя это названия нет в стандарте
Iterators Library, |
Algorithms Library, |
Numerics Library, <-*
Localization Library,
и Input/Output Library (часто называют iostreams)

А знать нужно все обязательно.

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

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

А>>Почему именно STDLIB?

SDB>Потому что она является "узаконенной" частью языка (а не "сторонней" библиотекой) — такой же как for, if, while, try и иже с ними.

rm -rf /usr/include/g++

Сделайте тоже самое с for, if, while, try.

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

А>Насколько нужно кодеру знание стандартной библиотеки.
А>С аргументацией плиз.

Знание стандартной библиотеки хорошему программисту на C++ крайне желательно, хотя бы потому что в ней содержится большое количество концепций, без знания которых сложно говорить об умении хорошо программировать на C++. Это и итераторы, и понятия concept/model of, и соответствующие категории контейнеров, и целый ряд приемов, использованных при проектировании стандартных библиотек... В общем, по моему мнению умение хорошо программировать на C++ коррелирует со знанием концепций, использованных в STL, соответственно, интервьюируя кандидатов, я обращаю на это внимание.

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

А>Насколько нужно кодеру знание стандартной библиотеки.
А>С аргументацией плиз.

Хе-Хе.
Кодеру знать нужно ровно то, что от него требует работодатель. Хороший же программист просто не сможет не знать стандартную библиотеку. Вот будет ли он её пользовать и в каком обьёме от этого слабо зависит.

wrote:

> SDB>Потому что она является "узаконенной" частью языка (а не
> "сторонней" библиотекой) — такой же как for, if, while, try и иже с ними.
> rm -rf /usr/include/g++
> Сделайте тоже самое с for, if, while, try.

rm -Rf c:/program\ files/Microsoft\ Visual\ Studio\ .NET\ 2003

А если серьзно, то некая вещь без stdlib называться С++ не может, так
как не соответствует его Стандарту.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

А>Насколько нужно кодеру знание стандартной библиотеки.
А>С аргументацией плиз.

Я так понимаю, что уважаемый Аноним придерживается мнения, что эти знания не нужны. Если я прав, то нельзя ли привести свою аргументацию плиз. А то получается игра в одни ворота...

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

AC>Хе-Хе.
AC>Кодеру знать нужно ровно то, что от него требует работодатель. Хороший же программист просто не сможет не знать стандартную библиотеку. Вот будет ли он её пользовать и в каком обьёме от этого слабо зависит.

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

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

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

Если человек вливается в команду "псевдо-гуру" , то конечно ему прийдется использовать STL, но если человек вливается к коллектив более "продвинутых" парней (кто прошел путь "псевдо-гуру" ), то будет ездить на своих велосипедах. Так поступают крупные производители софта, например в игровой индустрии.

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

wrote:

> Если человек вливается в команду "псевдо-гуру" , то конечно ему
> прийдется использовать STL, но если человек вливается к коллектив
> более "продвинутых" парней (кто прошел путь "псевдо-гуру" ), то будет
> ездить на своих велосипедах. Так поступают крупные производители
> софта, например в игровой индустрии.

Производители игр обычно свои велосипеды не пишут, а пользуются готовыми
и проверенными. Например RogueWave.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C> wrote:

C>Производители игр обычно свои велосипеды не пишут, а пользуются готовыми
C>и проверенными. Например RogueWave.

Ага... Ну и как давно пошел в обиход RogueWave?
Видать до его появления все STL использовали?

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

C>Производители игр обычно свои велосипеды не пишут, а пользуются готовыми
C>и проверенными. Например RogueWave.

Только вот скоро RogueWave накроется и тогда посмотрим, кому лучше живется

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

jazzer wrote:

> C>Производители игр обычно свои велосипеды не пишут, а пользуются
> готовыми
> C>и проверенными. Например RogueWave.
> Только вот скоро RogueWave накроется и тогда посмотрим, кому лучше живется

Да он живее всех живых!

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>jazzer wrote:

>> C>Производители игр обычно свои велосипеды не пишут, а пользуются
>> готовыми
>> C>и проверенными. Например RogueWave.
>> Только вот скоро RogueWave накроется и тогда посмотрим, кому лучше живется

C>Да он живее всех живых!

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

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

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

А>Здравствуйте, Glоbus, Вы писали:

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

А>>>Насколько нужно кодеру знание стандартной библиотеки.
А>>>С аргументацией плиз.

G>>Нужно. Потому что это часть языка, при чем очень важная и широкоиспользуемая.

А>Что в ней важного? Анологичный функционал есть и у других либ, которые многим приятней, чем STDLIB.

Например? Что тебя в stdlib не устраивает?

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

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

C>>jazzer wrote:

>>> C>Производители игр обычно свои велосипеды не пишут, а пользуются
>>> готовыми
>>> C>и проверенными. Например RogueWave.
>>> Только вот скоро RogueWave накроется и тогда посмотрим, кому лучше живется

C>>Да он живее всех живых!

J>Да?
J>Ну позвони им, скажи, что хочешь еще лицензий прикупить — думаю, после разговора твое мнение радикально изменится.

Неужели так плохо все?

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

>>>> C>и проверенными. Например RogueWave.
>>>> Только вот скоро RogueWave накроется и тогда посмотрим, кому лучше живется

C>>>Да он живее всех живых!

J>>Да?
J>>Ну позвони им, скажи, что хочешь еще лицензий прикупить — думаю, после разговора твое мнение радикально изменится.

E>Неужели так плохо все?

По моим впечатлениям — очень.
Мы уже переехали по этому поводу на STL, хотя до этого прочно сидели на RW.

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

> Если человек вливается в команду "псевдо-гуру" , то конечно ему прийдется использовать STL, но если человек вливается к коллектив более "продвинутых" парней (кто прошел путь "псевдо-гуру" ), то будет ездить на своих велосипедах.

У вас карты устарели. Даже такие крупные производители программного обеспечения как Adobe, предпочитают использовать готовые велосипеды. См., например, сюда.

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

>> Если человек вливается в команду "псевдо-гуру" , то конечно ему прийдется использовать STL, но если человек вливается к коллектив более "продвинутых" парней (кто прошел путь "псевдо-гуру" ), то будет ездить на своих велосипедах.

ПК>У вас карты устарели. Даже такие крупные производители программного обеспечения как Adobe, предпочитают использовать готовые велосипеды. См., например, сюда.

И чего? А например Electronic Arts пишет кросс-платформенный код (чисто на своих велосипедах).
Или быть может SEGA, NINTENDO, NAMCO и т.д. использовали/используют STL?
1. Любой программист который делал по настоящему серьезный софт (например человек занимается кросс-платформенным GameDev-ом), на порядок выше любого бравого парня которых пишет т.с. "крупный" софт типа Adobe. Крупный то он крупный, но извиняюсь дуболомный. Ничего координально сложного в нем нет, и к тому же Adobe не очень считается с производительностью кода.
2. STL иделально подходит для софта т.с. среднего уровня сложности (читай выше про "псевдо-гуру").

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


А>И чего? А например Electronic Arts пишет кросс-платформенный код (чисто на своих велосипедах).

Adobe тоже пишет кросс-платформенный код

А>1. Любой программист который делал по настоящему серьезный софт (например человек занимается кросс-платформенным GameDev-ом), на порядок выше любого бравого парня которых пишет т.с. "крупный" софт типа Adobe. Крупный то он крупный, но извиняюсь дуболомный. Ничего координально сложного в нем нет

Ну напиши свой растеризатор шрифтов хорошего качества и скажи насколько это просто

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

AJD>Ну напиши свой растеризатор шрифтов хорошего качества и скажи насколько это просто
А откуда информация, что растеризатор шрифтов у них написан на C++/STL? Особенно с учётом времени его появления и бессмысленностью переписывания.

Alexey Chen wrote:

> AJD>Ну напиши свой растеризатор шрифтов хорошего качества и скажи
> насколько это просто
> А откуда информация, что растеризатор шрифтов у них написан на
> C++/STL? Особенно с учётом времени его появления и бессмысленностью
> переписывания.

Они где-то писали в своей рассылке, что новый акробат (и акробат-ридер)
— полностью переписанные версии. В частности из-за этого они смогли
наконец-то выпустить полноценную версию для Линукса, до этого оно у них
не получалось из-за излишней кривости Линуксового растеризатора.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

AJD>Ну напиши свой растеризатор шрифтов хорошего качества и скажи насколько это просто

Ну не знаю как насчёт растеризатора шрифтов, но вот Adobe SVG viewer не очень хорошего качества программа.
Правда неизвестно использовали ли они STL и boost.

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

AJD>>Ну напиши свой растеризатор шрифтов хорошего качества и скажи насколько это просто
AC>А откуда информация, что растеризатор шрифтов у них написан на C++/STL? Особенно с учётом времени его появления и бессмысленностью переписывания.

Я не знаю написан ли он был на C++/STL. Мой коментарий был по поводу утверждения, что в Adobe ерундой занимаются, а _настоящие_пацаны_ гамезы пишут кросс-платформенные.

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

AJD>Я не знаю написан ли он был на C++/STL. Мой коментарий был по поводу утверждения, что в Adobe ерундой занимаются, а _настоящие_пацаны_ гамезы пишут кросс-платформенные.
Значит мы друг друга не поняли. Я же так понял, что Adobe вот пишет свой сложный кросплатформенный код на C++/STL и всё у них замечательно

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

ПК>> У вас карты устарели. Даже такие крупные производители программного обеспечения как Adobe, предпочитают использовать готовые велосипеды. См., например, сюда.

А> И чего?

Информация к размышлению.

А> А например Electronic Arts пишет кросс-платформенный код (чисто на своих велосипедах).

Я не могу сказать ничего определенного по поводу Electronic Arts в отношении истории использования STL для кросс-платформенного кода, но вот, например, их свежее объявление о работе:

Senior Software Engineer I

Do you want to work on leading game titles like James Bond, Godfather, and Tiger Woods Golf? At Electronic Arts in Redwood Shores, California, you will be responsible for being part of the engineering leadership on a development team working under a development director. You will be part of the game creation process, including architectural design, implementation, and debugging on multiple platforms. You will work on complex problems and will work closely with Designers, Artists and other Engineers to ship world class games.

<...>

TECHNICAL RECOMMENDATIONS

COM, XML, STL experience strongly considered

А>Или быть может SEGA, NINTENDO, NAMCO и т.д. использовали/используют STL?

Мне сложно говорить об этих компаниях, я никогда не общался с их разработчиками, однако мне известно, что многие российские и украинские производители игр используют STL и иногда boost. Если тебе этот вопрос, действительно, интересен, вот немного общей статистики (2001 г., соответственно, сейчас, по идее, будет больше):

In March 2001, I presented a roundtable at the Game Developer's Conference in San Jose. The roundtable was held an hour a day for each of the three days of the conference. The roundtable generated excellent and thought-provoking conversation among game developers using or considering the STL. Discussion centered on the best ways to get good STL performance and improve performance. We talked about common STL mistakes and how to avoid them. We also discussed various STL implementations, debugging issues, custom containers and allocators, as well as libraries similar to STL.

83 total people attended the roundtable. 79 of those attendees were software developers. Of the 79 developers, 74 had written STL code, and over 40% had used STL in shipped games, with an estimate of 50+ titles represented. Two-thirds of the developers reported using STL for games in progress.

А>1. Любой программист который делал по настоящему серьезный софт (например человек занимается кросс-платформенным GameDev-ом), на порядок выше любого бравого парня которых пишет т.с. "крупный" софт типа Adobe.

SGI, например, делает достаточно "серьезный софт", чтоб называть их продукцию "по настоящему серьезный софт"? К сожалению, критериев ты не привел, поэтому судить сложно...

А>2. STL иделально подходит для софта т.с. среднего уровня сложности (читай выше про "псевдо-гуру").

Это утверждение ты уже давал. Пока обоснований не последовало.

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

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

А>>Насколько нужно кодеру знание стандартной библиотеки.
А>>С аргументацией плиз.

ПК>Знание стандартной библиотеки хорошему программисту на C++ крайне желательно, хотя бы потому что в ней содержится большое количество концепций, без знания которых сложно говорить об умении хорошо программировать на C++. Это и итераторы, и понятия concept/model of, и соответствующие категории контейнеров, и целый ряд приемов, использованных при проектировании стандартных библиотек... В общем, по моему мнению умение хорошо программировать на C++ коррелирует со знанием концепций, использованных в STL, соответственно, интервьюируя кандидатов, я обращаю на это внимание.

Это не то же самое, что "знание STL". Я вообще не понимаю, что такое, "знание STL". Выучить наизусть все классы и их методы?
По-моему, лучше акцентировать внимание не на "знании STL", а на общем уровне программистской культуры.
Если речь идет о программировании на C++, то существует большое количество приёмов программировани и разного рода трюков на этом языке. Часть из них используется в конкретных реализациях STL.
Есть общетеоретические концепции, не связанные непосредственно с языком. Например, концепция инкапсуляции, или концепция абстрактных типов данных, и.т.п.
Если я не ошибаюсь, STL сама по себе ввела только одну новую (и важную) концепцию -- концепцию итераторов и алгоритмов.
По-моему, вот этого рода знания куда более ценны, чем "знание STL".

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Шахтер,

> ПК> Знание стандартной библиотеки хорошему программисту на C++ крайне желательно, хотя бы потому что в ней содержится большое количество концепций, без знания которых сложно говорить об умении хорошо программировать на C++. Это и итераторы, и понятия concept/model of, и соответствующие категории контейнеров, и целый ряд приемов, использованных при проектировании стандартных библиотек... В общем, по моему мнению умение хорошо программировать на C++ коррелирует со знанием концепций, использованных в STL, соответственно, интервьюируя кандидатов, я обращаю на это внимание.

> Это не то же самое, что "знание STL". Я вообще не понимаю, что такое, "знание STL". Выучить наизусть все классы и их методы?

Скорее, иметь понимание концепций, лежащих в основе, равно как и практический опыт их использования. Будет это достигнуто при освоении STL, или при использовании/разработке другой библиотеки — лично мне совершенно неважно. Просто (субъективный) опыт показывает, что некоторая корреляция между "знанием STL" и знанием/умением применять соответствующие концепции все-таки наблюдается. Т.е. если человек "знает STL", то вероятность, что он будет владеть соотвествующими идиомами выше, чем если он "STL не знает".

> По-моему, лучше акцентировать внимание не на "знании STL", а на общем уровне программистской культуры.

К сожалению, "общий уровень программистской культуры" сложно (невозможно?) выявить без проверки знания конкретных вещей. Одних заявлений о том, что человек обладает высоким уровнем общей программистской культуры мне недостаточно. STL в этом смысле, если, конечно, человек ее "знает", является хорошим предметом разговора для выявления этого самого уровня.

> Если речь идет о программировании на C++, то существует большое количество приёмов программировани и разного рода трюков на этом языке. Часть из них используется в конкретных реализациях STL.

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

> Есть общетеоретические концепции, не связанные непосредственно с языком. Например, концепция инкапсуляции, или концепция абстрактных типов данных, и.т.п.
> Если я не ошибаюсь, STL сама по себе ввела только одну новую (и важную) концепцию -- концепцию итераторов и алгоритмов.

Еще понятия concept/model of, выделение категорий контейнеров и итераторов (то, что, например, разработчики .Net Framework упустили напрочь), понятия функторов, и, таки да, итераторы и алгоритмы — без практического знания этой "алгебры" программист на C++ теряет очень много.

С другой стороны, я, естественно, совершенно не буду возражать, если на интервью человек скажет, что с STL работал мало/не работал вовсе, но зато понимает, как она устроена (и расскажет как именно), и расскажет, что он использовал или разрабатывал некоторую библиотеку, включающую аналогичные концепции. Контейнеры ATL/MFC или .Net Framework к таковым не относятся.

> По-моему, вот этого рода знания куда более ценны, чем "знание STL".

Рискуя повториться, скажу, что без опыта практического использования это не знания концепций, а знания о существовании концепций.

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

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

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

А>Если человек вливается в команду "псевдо-гуру" , то конечно ему прийдется использовать STL, но если человек вливается к коллектив более "продвинутых" парней (кто прошел путь "псевдо-гуру" ), то будет ездить на своих велосипедах. Так поступают крупные производители софта, например в игровой индустрии.

Можно озвучить названия "крупных производителей софта, например в игровой индустрии" ? \\человек из оной.

Соответствовать стандарту — далее ССт

Не пойму — о чем флейм: ССт или не ССт ?
ССт должны компилятор и стандартная библиотека. ССт для программиста — это использовать компиллятор и библиотеку, которые ССт. Это очень хорошо ? — ИМХО отлично.
Появляется легкость переносимости.

Ну а если вы пишите для какой-нибудь embeded platform ? Там компилятор такие коники выкидывает — мама не горюй. Там не то, что шаблоны, break глючат. Поэтому вопрос ССт или не ССт становится чисто риторический.

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

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

ПК>TECHNICAL RECOMMENDATIONS

ПК>COM, XML, STL experience strongly considered[/q]

Приехали! STL — нынче стал показателем пригодности (или быть может крутости) разработчика.
И чего в этом бредовом списке делает COM/XML? Какой полезный эффект имеют знания COM/XML скажем для разработчика игрушек под консоли?
Понятное дело, что такой человек будет клепать PC-диски (например startup) и подносить кофе.

А>>Или быть может SEGA, NINTENDO, NAMCO и т.д. использовали/используют STL?

ПК>Мне сложно говорить об этих компаниях, я никогда не общался с их разработчиками, однако мне известно, что многие российские и украинские производители игр используют STL и иногда boost.

Многие российские и украинские производители игр пишут код как правило PC-оnly (хотя, были жалкие потуги на консольном поприще, но как-то не очень успешно).
Вы хоть раз видели глюки, в игрушках под игровые консоли?
На PC этот процент большой (особенно в играх выпущенных в период 2000-2005, патчи стали нормой жизни) => делается вывод о качестве разработчика под PC и качестве разработчика под консоли.

Ради смеха стоит задуматься как бы выглядел патч, для игрушки прошитой на ROM?

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

D>Ради смеха стоит задуматься как бы выглядел патч, для игрушки прошитой на ROM?

А что, игрушку на ROM тоже окружает гора не совсем стабильного софта?

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

ПК>У вас карты устарели. Даже такие крупные производители программного обеспечения как Adobe, предпочитают использовать готовые велосипеды. См., например, сюда.

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

Я временами подумываю, а не показать ли этим долболомам как писать издательские системы.


Шучу... пока...

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

D>И чего в этом бредовом списке делает COM/XML? Какой полезный эффект имеют знания COM/XML скажем для разработчика игрушек под консоли?
D>Понятное дело, что такой человек будет клепать PC-диски (например startup) и подносить кофе.

Да, уж. Что можно делать со знанием DirectX-а основанного на КОМ при разработке игр для XBox?

Ну, а зачем может понадобится ХМЛ в конфиге сложной игры и предствить то себе страшно.



В общем, ты совсем заспорился. Это уже смешно.

D>Вы хоть раз видели глюки, в игрушках под игровые консоли?

А то? Что они святые что ли?

D>На PC этот процент большой (особенно в играх выпущенных в период 2000-2005, патчи стали нормой жизни) => делается вывод о качестве разработчика под PC и качестве разработчика под консоли.

Что-то я не понял. Я не в восторге от СТЛ, но не ужели в глюках игр виноват именно он? Или он делает кривыми PC, а те в свою очередь понижают качество игр?

ЗЫ

Я видел много кривости. И почти всегда в ней били виновны кривые руки программистов и тупые головы руководителей проектов выбравших средства разработки и технологии не обеспечивающие качеста. Если уж говорить о качестве, то в проу задуматься о целесообразности программирования на С++, а уж СТЛ тут точно ничего не решает.

VladD2 wrote:

> ПК>У вас карты устарели. Даже такие крупные производители программного
> обеспечения как Adobe, предпочитают использовать
> <http://opensource.adobe.com/&gt; готовые велосипеды. См., например, сюда
> <http://opensource.adobe.com/forest_8hpp-source.html&gt;.
> Ох-ох-ох. Очень плохая компания для примера. Адобовские продукты
> просто кишат глюками. Такое ощущение, что программируют у них
> исключительно дауны и китайцы с тремя классами образования. Если они
> еще и опенсорс пропагандируют, то лучше об этом умолчать. Все же не
> заслуживает опенсорс такой антирекламы.

Новый Акробат, кстати, очень даже ничего.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

D>>Ради смеха стоит задуматься как бы выглядел патч, для игрушки прошитой на ROM?

ГВ>А что, игрушку на ROM тоже окружает гора не совсем стабильного софта?

Не понял формулировки вопроса .

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

VD>Да, уж. Что можно делать со знанием DirectX-а основанного на КОМ при разработке игр для XBox?

На XBox свет клином не сошелся. Как эти знания пригодятся для программирования под PS2/3/P, Nintendo DS, Nintendo GameCube, GBA.

VD>Ну, а зачем может понадобится ХМЛ в конфиге сложной игры и предствить то себе страшно.
Обычно юзают бинарный формат. "Тоже самое дерево, но только дешевле". Это для PC совсем расслабились.

VD>

VD>В общем, ты совсем заспорился. Это уже смешно.

Я бы так не сказал.

D>>Вы хоть раз видели глюки, в игрушках под игровые консоли?

VD>А то? Что они святые что ли?

Примеры! Я не видел.

D>>На PC этот процент большой (особенно в играх выпущенных в период 2000-2005, патчи стали нормой жизни) => делается вывод о качестве разработчика под PC и качестве разработчика под консоли.

VD>Что-то я не понял. Я не в восторге от СТЛ, но не ужели в глюках игр виноват именно он? Или он делает кривыми PC, а те в свою очередь понижают качество игр?

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

VD>ЗЫ

VD>Я видел много кривости. И почти всегда в ней били виновны кривые руки программистов и тупые головы руководителей проектов выбравших средства разработки и технологии не обеспечивающие качеста. Если уж говорить о качестве, то в проу задуматься о целесообразности программирования на С++, а уж СТЛ тут точно ничего не решает.

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

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

D>>>Ради смеха стоит задуматься как бы выглядел патч, для игрушки прошитой на ROM?
ГВ>>А что, игрушку на ROM тоже окружает гора не совсем стабильного софта?
D>Не понял формулировки вопроса .

Ну как... Игрушку на PC окружает гора вечно "живых" эксплореров, офисов, непонятно-каких-версий-сервис-паков для ОС. В общем, довольно взрывоопасная смесь. У ПЗУ-шных игрушек такая же ситуация?

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

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

VD>>Да, уж. Что можно делать со знанием DirectX-а основанного на КОМ при разработке игр для XBox?

D>На XBox свет клином не сошелся. Как эти знания пригодятся для программирования под PS2/3/P, Nintendo DS, Nintendo GameCube, GBA.

Надо привлекать мозг для анализа требований работадателя. Если написано КОМ, ..., то работать ты будишь в том числе и с PC или с XBox. Остальные рассуждения можно выбрасить, так как они не имеют смысла.

В общем, не нужно пытаться думать за работадателя. Просто прийми как данность. Он знает что ему нужно, и ты должен удовлетворять его требованиям или искать другую работу.

VD>>Ну, а зачем может понадобится ХМЛ в конфиге сложной игры и предствить то себе страшно.
D>Обычно юзают бинарный формат.

Обычно тех кто для конфигов "юзают бинарный формат" ласково называют дебилами.

D> "Тоже самое дерево, но только дешевле". Это для PC совсем расслабились.

Тут опять же тоже что в первом случае. Не тебе решать что нужно работадателю. Если он тебе сказал ХМЛ, то будешь или учить ХМЛ или искать другую работу. А свои рассуждения оставь для посиделок за пивом.

D>Я бы так не сказал.

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

D>Примеры! Я не видел.

Зависание консолей. Вылеты в играх. Достаточно? Зайди на разные фанатские сайты погляди форумы. Специальной коллекции багов в чужом коде у меня нет ни для консолей, ни для PC.

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

Особенно было бы интересно узнать о статистике зависимости багов от применения СТЛ. Пока что для меня это вообще звучит очень странно (мягко говоря).

D>Очень многие бросаются писать код с использованием STL не прочитав пару толстенных книжек (или хотябы стандарт) вседствии получаем глюгообразный продукт.

Очень многие бросаются писать код вообще нихрена не зная

Автор:
Дата: 14.06.05

. Причем тут СТЛ?

D> Еще есть одна неприятная особенность "не-гуру", они умудряются так писать с использованием STL, что произоводительность кода где-то на уровне интерпретируемого языка (может быть VB6?).

Зашибись! То есть, если эти негуры начнут разрабатывать свои коллекции вместо того чтобы взяь готовые, то они сразу поднимут качество софта? Потрясающая логика. А мне-то казалось, что чем меьше эти негуры наколбасят коду, тем лучше.

В общем, если проблема в неучах и ламерах, то может быть их просто не допускать до создания сложного кода, а не валить все на СТЛ?

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

D>А это много уже обсуждалось. Для того чтобы писать грамотный код на C++, нужно пройти огонь, воду и медные трубы.

Нужно. Но к сожалению и это не страхует от серьезных ошибок.

И все же... Причем тут СТЛ?

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

C>Новый Акробат, кстати, очень даже ничего.

Ты Индизайн поробуй использовать.

Акробат тоже без проблем падает и глючит на постскрипте порождаемом МС-овскими дровами.

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

VD>Обычно тех кто для конфигов "юзают бинарный формат" ласково называют дебилами.

Представь конфиг для игры под GBA в XML. Как правило есть конвертор XML -> некий свой портируемый бинарный формат, чтобы небыло потери времени на написание своего XML-парсера под платформу X.

VD>Зависание консолей. Вылеты в играх. Достаточно? Зайди на разные фанатские сайты погляди форумы. Специальной коллекции багов в чужом коде у меня нет ни для консолей, ни для PC.

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

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

Зайди на разные фанатские сайты погляди форумы, сравни кол-во багов под консоли и PC.

VD>Особенно было бы интересно узнать о статистике зависимости багов от применения СТЛ. Пока что для меня это вообще звучит очень странно (мягко говоря).

VD>Очень многие бросаются писать код вообще нихрена не зная

Автор:
Дата: 14.06.05

. Причем тут СТЛ?

Про это ничего сказать немогу, я не заводил эту тему. Вот мое сообщение: http://www.rsdn.ru/Forum/Message.aspx?mid=1222078&amp;only=1

Автор: Denis2005
Дата: 14.06.05

— где идет утверждение, что STL виноват в глюках? Я удивляюсь, что понимание его концепций стало показателем просвещенности программиста в клане C++.

D>> Еще есть одна неприятная особенность "не-гуру", они умудряются так писать с использованием STL, что произоводительность кода где-то на уровне интерпретируемого языка (может быть VB6?).

VD>Зашибись! То есть, если эти негуры начнут разрабатывать свои коллекции вместо того чтобы взяь готовые, то они сразу поднимут качество софта? Потрясающая логика. А мне-то казалось, что чем меьше эти негуры наколбасят коду, тем лучше.

Начнут писать велосипеды (контейнеры, итераторы и т.д.) -> начнут потихоньку прозревать -> повышется качество софта.

VD>В общем, если проблема в неучах и ламерах, то может быть их просто не допускать до создания сложного кода, а не валить все на СТЛ?

Кто валит?

VD>СТЛ плох не тем что им пользуются бездари. Он плох невнятностью названий (плохой терминологией), некоторой непродуманностью. Тяжеловестностью некоторых идеом. Все это сто раз тут обсуждалось. Одни считают это нормальным, другие убогим. Но уж пугать то им точно не стоит.

D>>А это много уже обсуждалось. Для того чтобы писать грамотный код на C++, нужно пройти огонь, воду и медные трубы.

VD>Нужно. Но к сожалению и это не страхует от серьезных ошибок.

VD>И все же... Причем тут СТЛ?


Влад, ты извини, но тебя заело на вопросе: "Причем тут СТЛ?".
Для меня это просто не показатель высококвалифицированного программиста.

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

ГВ>Ну как... Игрушку на PC окружает гора вечно "живых" эксплореров, офисов, непонятно-каких-версий-сервис-паков для ОС. В общем, довольно взрывоопасная смесь. У ПЗУ-шных игрушек такая же ситуация?

Как правило из окружения простейший т.с. BIOS, и больше ничего. Беспорно это большой плюс в плане стабильности.

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

Офис и эксплорер (живой) не влияет на глюки в PC-играх.

Denis2005,

> ПК>TECHNICAL RECOMMENDATIONS
> ПК>COM, XML, STL experience strongly considered[/q]

> Приехали! STL — нынче стал показателем пригодности (или быть может крутости) разработчика.

Да, это именно то, с чем ты изволишь спорить. И пока ограничиваешься голословными заявлениями, и нерелевантными ссылками на консоли.

> И чего в этом бредовом списке делает COM/XML? Какой полезный эффект имеют знания COM/XML скажем для разработчика игрушек под консоли?

Не думаю, что данная позиция нацелена исключительно на консоли. Но что это меняет? Консоли традиционно отстают в плане используемых инструментов...

> Понятное дело, что такой человек будет клепать PC-диски (например startup) и подносить кофе.

Это очень сильно расходится с тем, что написано в объявлении (как в части одноплатформенности, так и в части о подношении кофе). Вот выдержки, если ты даже поленился сходить по ссылке:

<...> you will be responsible for being part of the engineering leadership on a development team working under a development director. You will be part of the game creation process, including architectural design, implementation, and debugging on multiple platforms. You will work on complex problems and will work closely with Designers, Artists and other Engineers to ship world class games.

PROFESSIONAL PREREQUISITES:

Level-headed leader in a fast-paced, changing development environment

Able to lead and inspire other engineers and set a positive, professional example under pressure

Understand the demanding requirements of finishing high-quality commercial products on time

Extreme flexibility in problem solving and working with other engineers on multiple projects

Expert in design, coding, debugging, consulting, on any required platform

Committed to training, reviewing, and mentoring junior engineers

TECHNICAL REQUIREMENTS:

10 years programming experience

5 years experience creating retail software products

3 years of C++ experience

Algebra, Trigonometry, 3D math skills, rendering skills

Able to create technical designs that lead to well structured software

Ability to quickly learn new hardware platforms

Able to test, debug, and extend other Software Engineer's code competently

Understanding of memory management, multiple processor use, and runtime optimization

OTHER DUTIES:

Regularly assist in completing projects that are undergoing schedule-jeopardizing change.

Create leading edge reusable technologies, both systems and engines if required.

Constantly innovate how to improve product quality as well as group productivity.

Provide technical and staffing recommendations and decisions to Production team.

Interview and evaluate other engineering candidates

Это по-твоему выглядит как требования к разносчику кофе? Я бы сказал, что это набор требований к инженеру, нанимаемому на достаточно высокую позицию.

> На PC этот процент большой (особенно в играх выпущенных в период 2000-2005, патчи стали нормой жизни) => делается вывод о качестве разработчика под PC и качестве разработчика под консоли.

Неверный вывод из недостаточных посылок, с некачественным анализом.

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

D>Представь конфиг для игры под GBA в XML. Как правило есть конвертор XML -> некий свой портируемый бинарный формат, чтобы небыло потери времени на написание своего XML-парсера под платформу X.

Представить конфиг на XML проблем нет. Но вот представить придурков перекодирующих ХМЛ в бинарный, да еще переносимый формат... И это еще я сильно не люблю ХМЛ... применяемый не по назначению.

D>Да, действительно вохможно для XBox случаи были,

Ну, да. Для них негры пишут ламеря...

D> эта консоль больше по духу к PC и мигрировали под нее ex-PC-девелоперы.

Да, да... дух это свято.

D>Зайди на разные фанатские сайты погляди форумы, сравни кол-во багов под консоли и PC.

Поделись как сравнить? Да и ты вроде говорил, что оных нет кроме как под ПиСи.


D>Про это ничего сказать немогу, я не заводил эту тему.

Тема тут не причем. Это просто замечательный случай подвернулся. Поверь... посредственности и лама всегда море.

D>Начнут писать велосипеды (контейнеры, итераторы и т.д.) -> начнут потихоньку прозревать -> повышется качество софта.

А... я то думал как отках от СТЛ может помочь повышению уровня знаний программистов... Самому-то не смешно?

VD>>В общем, если проблема в неучах и ламерах, то может быть их просто не допускать до создания сложного кода, а не валить все на СТЛ?

D>Кто валит?

Да? Хороший вопрос.

VD>>И все же... Причем тут СТЛ?

D>

Во-во.

D>Влад, ты извини, но тебя заело на вопросе: "Причем тут СТЛ?".

Ты знаешь, мне просто действительно не нравится СТЛ, но вот так обвинять эту библиотеку во всех смертных...

D>Для меня это просто не показатель высококвалифицированного программиста.

Да причем тут квалификация? Просто зачем уж так валить все на...

На пленуме ЦК... Выходит Сталин и говорит...
— Во всем виноваты евреи и велосипидисты!
С одного из первых рядов... робкий голос...
— А велосипидисты то тут причем?
— Я знал, что по первому вопросу прений не буедет.

>> Приехали! STL — нынче стал показателем пригодности (или быть может крутости) разработчика.

ПК>Да, это именно то, с чем ты изволишь спорить. И пока ограничиваешься голословными заявлениями, и нерелевантными ссылками на консоли.

Не очень убедительно, но зато на русском и от российского разработкика: http://www.dtf.ru/forum/thread.php?id=66631, и вот в частности почему: http://www.dtf.ru/forum/thread.php?id=67301.

ПК>Не думаю, что данная позиция нацелена исключительно на консоли. Но что это меняет? Консоли традиционно отстают в плане используемых инструментов...



ПК>Это по-твоему выглядит как требования к разносчику кофе? Я бы сказал, что это набор требований к инженеру, нанимаемому на достаточно высокую позицию.

На мой взгляд такие "TECHNICAL REQUIREMENTS" больше подходят для тим-лидера середнячка, который просто должен кое-как контролировать процесс разработки. Особенно понравилось: "3 years of C++ experience" .