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

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


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

G>>Скороть (как показывает практика!) есть одна из наиболее критичных частей. прости старик, ты ошибаешся.

Y>Да???

Y>Вот смотрю я у себя на список установленных программ, и не вижу ни одной главной (или хотя бы основной) фичей которой была бы скорость работы. Даже более того не помню ни одной доминирующей на рынке программы которая была существнно быстрее конкурентов.

А не там смотришь. Самый простой способ — Информация о системе/программная среда/драйвера.
А еще могу и от себя добавить: поисковые системы, управление в реалном времени (к примеру ЧПУ), имитационное моделирование случайных и динамических процессов в реальном времени для управления (например так работают плазматроны: струя плазмы моделируется и выходной сигнал заводится на обратную связь). Я уже не говорю, про научные задачи, типа моделирование погоды, расчет генома или моделирование термоядерной реакции (кстати в Гидрометцентре и ЦЕРН используют суперкомпьютеры на P4 и компилятор Intel С++). Такие задачи в промышленности и науке возникают постоянно, и стоят они соответственно — хороший станок с ЧПУ стоит под несколько мегабаксов.

Y>Более того, смотрою я на процесс разработки соверемнных 3d игр — даже там скорость в целом не важна. Практически все современные игры можно ускорить на процентов 10-20 затратив процентов 10 денег от общего процесса разработки. Только экономически выгодней в мин. требованиях написать P43.2 вместо P42.8 и потратить эти деньги на маркетинг.....
Y>А в то что шаблоны при правильной арзитектуре могут дать прирост более 20% тоже не поверю.....
Y>Даже более того — разработка трехмерных игр для мобильных телефонов — даже там экономически выгодней порезать полигоны и урезать текстуры чем сидеть код оптимизировать.....
Вай, вай, вай! А на чем игры то пишут? Библиотеки что я видел — на С++. Я конечно видел мало, но все же мне кажется, что это делается не на Java.

Y>Назову я тебе даже больше, я тебе лучше скажу с чем я сейчас работаю.

Y>И так wintel, j2me, brew, мофан, PowerTV, PocketPC, PlamOS, Flash
Y>Языки — java, с/c++, ну и ActionScript
Это ты про это говорил, что рынок PC-платформ не самый большой?

Y>>>При правильном проектировании в ОПП интерфесов и классов за глаза хватает.
Y>>>Скорость — это в большенстве случаев не важно, да и не ускоряют шаблоны сильно...
Y>>>Так в чем премущество?

Насчет шаблонов — странный спор. Факт в том, что они есть и грамотное их использование приносит пользу. То что без них можно обойтись и писать не хуже бесспорно, писали же как то и до ассемблера, но отрицать их — просто смешно!
В С++ шаблоны позвляют, по крайней мере, реализовать автомаическое управление памятью и удобные коллекции.
Мне очень приятно, что можно написать list<int> mylist; и получит список, содержащий ИМЕННО int`ы, причем на каждый элемент списка будет занимать РОВНО по 12 байт.
Если кому-то и не важно, что он точно знает сколько памяти тратит каждый программный примитив, то он не пробовал индексировать базу в 50ГБ, хранить индекс в памяти и перемещаться по нему в произвольном порядке (по опыту, скажу скажу, что ссылки на виртуальную память и страничный файл отметаются сразу — очен уж тормозно, ниже всяких планок).
Если же, работаешь в реальном времени, то запоешь еще не так, когда у тебя не 2ГБ адресов, а 64МБ ФИЗИЧЕСКОГО ОЗУ (это такие микросхемки. В осях РВ обычно не нет виртуальной памяти, сделано для увеличения никому не нужной скорости)

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

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

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


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

G>>>Скороть (как показывает практика!) есть одна из наиболее критичных частей. прости старик, ты ошибаешся.

Y>>Да???

Y>>Вот смотрю я у себя на список установленных программ, и не вижу ни одной главной (или хотя бы основной) фичей которой была бы скорость работы. Даже более того не помню ни одной доминирующей на рынке программы которая была существнно быстрее конкурентов.

L>А не там смотришь. Самый простой способ — Информация о системе/программная среда/драйвера.

Хех, драйвера я себе не выбираю..... Да и пофиг мне какие у меня драйвера..... Как и среднестатестическому юзверю — т.е. человку на которых мы зарабатываем деньги....

L>А еще могу и от себя добавить: поисковые системы, управление в реалном времени (к примеру ЧПУ), имитационное моделирование случайных и динамических процессов в реальном времени для управления (например так работают плазматроны: струя плазмы моделируется и выходной сигнал заводится на обратную связь). Я уже не говорю, про научные задачи, типа моделирование погоды, расчет генома или моделирование термоядерной реакции (кстати в Гидрометцентре и ЦЕРН используют суперкомпьютеры на P4 и компилятор Intel С++). Такие задачи в промышленности и науке возникают постоянно, и стоят они соответственно — хороший станок с ЧПУ стоит под несколько мегабаксов.


Угу, а давай теперь сравним объемы рынка. Того котоый ты описал, и хотябы объем рынка текстовых процессоров.... Думается мне второе сейчас продовать быгоднее — отношение затраты/прибыль — меньше....

Y>>Более того, смотрою я на процесс разработки соверемнных 3d игр — даже там скорость в целом не важна. Практически все современные игры можно ускорить на процентов 10-20 затратив процентов 10 денег от общего процесса разработки. Только экономически выгодней в мин. требованиях написать P43.2 вместо P42.8 и потратить эти деньги на маркетинг.....
Y>>А в то что шаблоны при правильной арзитектуре могут дать прирост более 20% тоже не поверю.....
Y>>Даже более того — разработка трехмерных игр для мобильных телефонов — даже там экономически выгодней порезать полигоны и урезать текстуры чем сидеть код оптимизировать.....
L>Вай, вай, вай! А на чем игры то пишут? Библиотеки что я видел — на С++. Я конечно видел мало, но все же мне кажется, что это делается не на Java.


На С++ безусловно.

Только почему скажитем в HL2 не используется ни STL, ни контейнеры на шаблонах? Наверно в Valve глупые программисты сидят, игры писать не умеют?
Я уже не говорю о Кваке которая на чистом С написанна.

А обвинять IDSoftware что они деньги зарабатывать не умеют вы надеюсь не будите?

И еще, ради общей информаци — в данный момент продающихся j2me приложений около 1800-2500, а вот BREW (это C/C++) около 200-300. Там правда свои нюансы, но таки показатель...


Y>>Назову я тебе даже больше, я тебе лучше скажу с чем я сейчас работаю.

Y>>И так wintel, j2me, brew, мофан, PowerTV, PocketPC, PlamOS, Flash
Y>>Языки — java, с/c++, ну и ActionScript
L>Это ты про это говорил, что рынок PC-платформ не самый большой?

Да. Сколько там сейчас персоналок в мире — по моему около миллиарда?
А вот сотовых телефонов — 6 миллиардов. А планы на ближайщий год — еще миллиард продать. А современный телефон — это полноценный комп считай....
Я уже не говорю про налоонники и смартфоны....

Y>>>>При правильном проектировании в ОПП интерфесов и классов за глаза хватает.
Y>>>>Скорость — это в большенстве случаев не важно, да и не ускоряют шаблоны сильно...
Y>>>>Так в чем премущество?

L>Насчет шаблонов — странный спор. Факт в том, что они есть и грамотное их использование приносит пользу. То что без них можно обойтись и писать не хуже бесспорно, писали же как то и до ассемблера, но отрицать их — просто смешно!

А кто их отрицает. Я просто говорю, что по моему опыту использование их экономически не оправданно. ЭКОНОМИЧЕСКИ! А что удобно, так возможно.....

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

L>В С++ шаблоны позвляют, по крайней мере, реализовать автомаическое управление памятью и удобные коллекции.
L>Мне очень приятно, что можно написать list<int> mylist; и получит список, содержащий ИМЕННО int`ы, причем на каждый элемент списка будет занимать РОВНО по 12 байт.
L>Если кому-то и не важно, что он точно знает сколько памяти тратит каждый программный примитив, то он не пробовал индексировать базу в 50ГБ,
хранить индекс в памяти и перемещаться по нему в произвольном порядке (по опыту, скажу скажу, что ссылки на виртуальную память и страничный файл отметаются сразу — очен уж тормозно, ниже всяких планок).


Думается мне это чисто маркетенговые проблемы. Неужели реально при постановки задачи было решено что увеличение требовних к памяти (сколько там сейчас гиг тоит — баксов 200 всего?) стоит лишних забот программиста? Было ли посчитано что дешевле — увеличить количество памяти или тратить время на оптимизацию?

L>Если же, работаешь в реальном времени, то запоешь еще не так, когда у тебя не 2ГБ адресов, а 64МБ ФИЗИЧЕСКОГО ОЗУ (это такие микросхемки. В осях РВ обычно не нет виртуальной памяти, сделано для увеличения никому не нужной скорости)

И что? Я вот сейчас пишу трехмерные игры под 4 мега ОЗУ. При грамотной реализации без всяких шаблонов хватает на ура.

Поймите — при желании можно посидеть над оптимизацией первого квака и впихнуть его в 640 кб. Но кому это нужно?


Какая гланая задача разработчика — затратить усилий по меньше, продать по дороже!

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

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


L>>А еще могу и от себя добавить: поисковые системы, управление в реалном времени (к примеру ЧПУ)...

Y>Угу, а давай теперь сравним объемы рынка. Того котоый ты описал, и хотябы объем рынка текстовых процессоров.... Думается мне второе сейчас продовать быгоднее — отношение затраты/прибыль — меньше....
Ну, насчет текстовых процессоров, то рынок конечно немалый, только попасть на него трудно. Скорей невозможно, и мы все знаем почему, но жа это неважно... Просто дело не объеме рынка, а в том, что покупатели у нас разные.

Y>>>Более того, смотрою я на процесс разработки соверемнных 3d игр — даже там скорость в целом не важна. Практически все современные игры можно ускорить на процентов 10-20 затратив процентов 10 денег от общего процесса разработки. Только экономически выгодней в мин. требованиях написать P43.2 вместо P42.8 и потратить эти деньги на маркетинг.....
Y>>>А в то что шаблоны при правильной арзитектуре могут дать прирост более 20% тоже не поверю.....
Y>>>Даже более того — разработка трехмерных игр для мобильных телефонов — даже там экономически выгодней порезать полигоны и урезать текстуры чем сидеть код оптимизировать.....
L>>Вай, вай, вай! А на чем игры то пишут? Библиотеки что я видел — на С++. Я конечно видел мало, но все же мне кажется, что это делается не на Java.


Y>На С++ безусловно.

Y>Только почему скажитем в HL2 не используется ни STL, ни контейнеры на шаблонах? Наверно в Valve глупые программисты сидят, игры писать не умеют?
Y>Я уже не говорю о Кваке которая на чистом С написанна.

Y>А обвинять IDSoftware что они деньги зарабатывать не умеют вы надеюсь не будите?
На счет HL2 не знаю,но про 1-й скажу: это единственная новая игра, которая сносно работала на моем стареньком Cyrix 233, с 32 МБ ОЗУ, так что над оптимизацией кода они потрудились неплохо. Если в Valve не использовали STL, значит им было удобней написать что-то свое — проверенное и надежное.

Y>>>Назову я тебе даже больше, я тебе лучше скажу с чем я сейчас работаю.

Y>>>И так wintel, j2me, brew, мофан, PowerTV, PocketPC, PlamOS, Flash
Y>>>Языки — java, с/c++, ну и ActionScript
L>>Это ты про это говорил, что рынок PC-платформ не самый большой?

Y>Да. Сколько там сейчас персоналок в мире — по моему около миллиарда?
Y>А вот сотовых телефонов — 6 миллиардов. А планы на ближайщий год — еще миллиард продать. А современный телефон — это полноценный комп считай....
Да не совсем полноценный. Скажем так: "рабочая станция"

L>>В С++ шаблоны позвляют, по крайней мере, реализовать автомаическое управление памятью и удобные коллекции.
L>>Мне очень приятно, что можно написать list<int> mylist; и получит список, содержащий ИМЕННО int`ы, причем на каждый элемент списка будет занимать РОВНО по 12 байт.
L>>Если кому-то и не важно, что он точно знает сколько памяти тратит каждый программный примитив, то он не пробовал индексировать базу в 50ГБ,
Y>хранить индекс в памяти и перемещаться по нему в произвольном порядке (по опыту, скажу скажу, что ссылки на виртуальную память и страничный файл отметаются сразу — очен уж тормозно, ниже всяких планок).


Y>Думается мне это чисто маркетенговые проблемы. Неужели реально при постановки задачи было решено что увеличение требовних к памяти (сколько там сейчас гиг тоит — баксов 200 всего?) стоит лишних забот программиста? Было ли посчитано что дешевле — увеличить количество памяти или тратить время на оптимизацию?
Не соглашусь. К сожалению, проблема в том, что иногда размер индекса первышает размер адресного пространства...

L>>Если же, работаешь в реальном времени, то запоешь еще не так, когда у тебя не 2ГБ адресов, а 64МБ ФИЗИЧЕСКОГО ОЗУ (это такие микросхемки. В осях РВ обычно не нет виртуальной памяти, сделано для увеличения никому не нужной скорости)

Y>И что? Я вот сейчас пишу трехмерные игры под 4 мега ОЗУ. При грамотной реализации без всяких шаблонов хватает на ура.
3D игры это не RealTime.

И вообще, весь спор из-за того, что мы заняты в разных областях, отсюда и непонимание.

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

Y>>А обвинять IDSoftware что они деньги зарабатывать не умеют вы надеюсь не будите?
L>На счет HL2 не знаю,но про 1-й скажу: это единственная новая игра, которая сносно работала на моем стареньком Cyrix 233, с 32 МБ ОЗУ, так что над оптимизацией кода они потрудились неплохо. Если в Valve не использовали STL, значит им было удобней написать что-то свое — проверенное и надежное.

Во-во, умные люди...

Y>>>>Назову я тебе даже больше, я тебе лучше скажу с чем я сейчас работаю.

Y>>>>И так wintel, j2me, brew, мофан, PowerTV, PocketPC, PlamOS, Flash
Y>>>>Языки — java, с/c++, ну и ActionScript
L>>>Это ты про это говорил, что рынок PC-платформ не самый большой?

Y>>Да. Сколько там сейчас персоналок в мире — по моему около миллиарда?
Y>>А вот сотовых телефонов — 6 миллиардов. А планы на ближайщий год — еще миллиард продать. А современный телефон — это полноценный комп считай....
L>Да не совсем полноценный. Скажем так: "рабочая станция"

Согласен.

L>>>В С++ шаблоны позвляют, по крайней мере, реализовать автомаическое управление памятью и удобные коллекции.
L>>>Мне очень приятно, что можно написать list<int> mylist; и получит список, содержащий ИМЕННО int`ы, причем на каждый элемент списка будет занимать РОВНО по 12 байт.
L>>>Если кому-то и не важно, что он точно знает сколько памяти тратит каждый программный примитив, то он не пробовал индексировать базу в 50ГБ,
Y>>хранить индекс в памяти и перемещаться по нему в произвольном порядке (по опыту, скажу скажу, что ссылки на виртуальную память и страничный файл отметаются сразу — очен уж тормозно, ниже всяких планок).


Y>>Думается мне это чисто маркетенговые проблемы. Неужели реально при постановки задачи было решено что увеличение требовних к памяти (сколько там сейчас гиг тоит — баксов 200 всего?) стоит лишних забот программиста? Было ли посчитано что дешевле — увеличить количество памяти или тратить время на оптимизацию?
L>Не соглашусь. К сожалению, проблема в том, что иногда размер индекса первышает размер адресного пространства...

Так вперед, к 64 битной архитектуре..... Сейчас вроде цены на нее вполне допустимые....

L>>>Если же, работаешь в реальном времени, то запоешь еще не так, когда у тебя не 2ГБ адресов, а 64МБ ФИЗИЧЕСКОГО ОЗУ (это такие микросхемки. В осях РВ обычно не нет виртуальной памяти, сделано для увеличения никому не нужной скорости)

Y>>И что? Я вот сейчас пишу трехмерные игры под 4 мега ОЗУ. При грамотной реализации без всяких шаблонов хватает на ура.
L>3D игры это не RealTime.

L>И вообще, весь спор из-за того, что мы заняты в разных областях, отсюда и непонимание


Да какой спор, чистой воды флейм а не спор. Потому как вопрос спора не сформулирован. Если его сформулировать — то спорить будет не о чем....

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

Y>Да??? В видать сильно отстал от жизни. Не подскажите в какой именно части спецификации языка С++ упоминается STL?

Отстал. Причем сильно.

Даже как-то неловко читать ваши измышления про шаблоны...

И вопрос у вас странный. Вы Стандарт С++ вообще видели?

Там треть посвящена именно стандартной библиотеке — смотрите разделы с 17 по 27.

Здравствуйте, Аноним, Вы писали:
А>Не надо делать временные переменные типа str,str1...для того чтобы результат преобразования передать функции,
А>если ошибка — возбуждается исключение. Не надо проверять на ошибку возвращаемое значение.
А>Главное — они всегда есть в любом компиляторе дельфи сразу! Не надо искать какие то половинчатые решения для таких элементарны вещей а можно максимально сконцентрироваться на задаче, не создавать переменных которых не должно быть по логике вещей.

Лично я никогда не гемороился с такими вещами, взял и написал себе на всю оставшуюся жизнь всяческие преобразователи, легко заменяемые и настраиваемые... на С++, никаких исключений, так что, товарищь Аноним, если Вы усмотрели счастье в том, что кто-то за Вас решил какую-либо задачу... это говорит... а может и не говорит... Впрочем, ну да ладно, оставайтесь при своем счастье)!
PS:вся функциональность Паскаля имеется в С, а в С++ вся С, не стоит говорить о языке, если суть проблемы совсем в другом...

Здравствуйте, Young, Вы писали:
Y>И что? Я вот сейчас пишу трехмерные игры под 4 мега ОЗУ. При грамотной реализации без всяких шаблонов хватает на ура.
Зачем шаблоны в играх? И откуда такая нелюбовь к шаблонам? (кто-то из под палки заставляет всюду писать на шаблонах, что от них уже тошнит?). вопрос жизни и смерти, шаблоны, это такая невероятно опасная, постыдная штука, кроме того, она совершенно экономически не выгодная! пишем свой контейнер , но не дай Бог где встречу vector<int>, потеряем кучу бабок!

Y>Поймите — при желании можно посидеть над оптимизацией первого квака и впихнуть его в 640 кб. Но кому это нужно?
прямая экономическая выгода — вместо 2х CD, у нас 1, вместо 10Мб выкаченого из инета, у нас 5-8... это пример с оптимизацией, конкретные цифры с потолка...

Y>Какая гланая задача разработчика — затратить усилий по меньше, продать по дороже!

Для этого и придумали шаблоны

Y>Если шаблоны в этом помогают — по ради бога, но наиболее часто я вижу использование шаблонов там где это не выгодно.
Я уже горю от нетерпения, чтобы услышать это место, кто посмел использовать шаблон, и это вылилось в невыгодную ситуацию!?

Y>Нет бы завести масивчик на мего 10 и с ним работать, нет делают хитрые списки. Ладно если было жесткое огриничение по памяти. Так не, нету его. А таки все равно лепят.
Где нужен простой массив, там делаем массив... а где список, там и список...