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

I>>>>Практически все алгОритмы с которыми я сталкивался, будучи портироваными на С++ не давали преимущества. Это пройденый этап.
IID>>>Не верю (c) Можно пример алгоритма ?
I>>Вряд ли. Это алгоритмы например для роутинга оптической сети.
CC>Это разумеется офигенно много говорит нам о том, что за алгоритм и как он был реализован.

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

I>>Ничего. Открой свой мега проект на с++ и покажи тамошние строки.
CC>И? Ты давай мысль развивай, приводи аргументацию почему А плохо а Б хорошо. А вынуть и показать — это к детям в песочнице.

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

I>>Кроме того, дотнет ограничивает девелопера, что дает возможность оптимизировать местами очень не слабо.
CC>Скорее не даёт применять некоторые С++ техники для алгоритмической оптимизации.

Есть другие техники, не обязательно пользовать сиплюсные для оптимизации.

I>>Внятно отвечай. Деструктор что ли сам выполнится на другом ядре ?
CC>А зачем ему на другом ядре выполняться? Мне надо детерминизм а не бардак в программе.

Т.е. перформанс не интересует ? Как ты быстро то отступил.

CC>Головой. Или работать головой уже считается чем то зазорным?
CC>Фреймворков под С++ написано тоже порядком. Рутинные операции автоматизированы.

Ну какой то задел у С++ есть, лет через пять эт фреймворки устареют.

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

I>>Когда то сайты клепали пользуя с++ на стороне сервера. Ты не в курсе ?
CC>C++ никогда не позиционировался как язык для вебсерверов. Это не его стихия изначально. То, что он занимал эту нишу до появления более удобного инструмента говорит лишь о том, что на то время лучшей альтернативы не было.
CC>Вот и всё.

С серверными приложениями будет тоже самое, только времени понадобится побольше.

M>> S>Не успеет мясо нарасти. Как только начинает наростать, так чтото меняется.
M>> S>Запомни, пока технология в руках микрософта — не жди хоть какойто долговременной стабилизации и "наращивания мяса". Это банально невыгодно.

M>> DirectX. Уже в 11-й версии.
S>И оно установится и заработает под XP?
S>Впрочем слово "уже" говорит само за себя.

Шеридан. Я повторю свой диагноз. Ты — клинический идиот. XP — это операционка, вышедшая 7 (семь) лет тому назад. Тебе дать списко технологий, которые не поставятся на Линукс тех же годов или сам догадаешься.

Теперб возвращаемся к обсуждаемому топику.

Твои слова:

Не успеет мясо нарасти. Как только начинает наростать, так чтото меняется.
Запомни, пока технология в руках микрософта — не жди хоть какойто долговременной стабилизации и "наращивания мяса". Это банально невыгодно.

Запомни раз и навсегда. Технологии меняются. Это их свойство. И, несмотря на то, что они «постоянно» меняются и «никакой стабилизации нет», DirectX не только живее всех живых, но и является стабильной, развитой, серьезной технологией.

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


M>> Хочешь поговорить о консолях?
S>Нет, зачем? О них говорить не надо, их надо играть

M>> Xbox 360. (кстати, на консолях технологии меняются тоже достаточно часто)
S>Это одна из эээ скольки? не помню чтото... Из 4х популярных?

Это я к вопросу о том, что МС все постоянно меняет. Вон, пожалуйста, XBox 360. Более того, в консолях технологии тоже меняются и меняются просто радикально, производители консолей — это не зло, а МС — зло, они постоянно что-то меняют.

Шеридан, где логика?


M>> МСу выгодно получать деньги. В том числе путем привлечения разработчиков, а не путем отталкивания. Если бы МС менял технологии так часто, как ты себе нафантазировал, под винд никто ничего не разрабатывал бы.
S>Странная фраза. С одной стороны подтверждаются мои слова, и тутже признаются фантазиями.
S>Ясен пень в МС не идиоты сидят. Слишком часто менять технологии тоже невыгодно, это бесспорно. Но подсадить на иглу, подержать для привыкания и показать\нахвалить другую иглу, "более лучшую, более безопасную итд" — это постоянно.

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

M>> Хотя распределенная (даже поверх двух ядер на одном и том же компе) компиляция уже определенно начинает радовать. Но все равно это все не то, совсем не то

S>А раньше наверняка же было небо голубее, да?

Раньше со скоростью компиляции была вообще жопа. Даже на РСДНе можно найти посты, в которых не рекомендовалось использовать boost из-за невероятно медленной компиляции.

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

I>>>При переходе на 64 разряда про память можно забыть.
CC>>Про лимит адресного пространства можно пока забыть, специалист ты наш. А как раз память всегда конечна.

I>Память сейчас крайне дешовая. На 64 разряда можно даже на ноутах на раз всунуть 8 гигов, не сильно дорого выйдет.

Засунуть-то можно. Вот только что-то не наблюдается в массовых машинках памяти офигенных размеров.

CC>>>>А для геймера разница 10FPS и 100FPS просто фатальная. Как и провалы и рывки FPS.
I>>>Как на С++ с многопроцессорностью ?
CC>>Все прекрасно.

I>Не замечал как то.

Да-да. Мы знаем эту песню. Если ты чего-то не видел, то этого и нету.

I>>>Вот дотнет на раз заюзает свободные ядра и там будет работать например GC.
CC>>И будет 1 поток с полезной задачей и 3 потока с GC? А смысл?

I>смысл в том, что освобождение памяти времени почти не занимает по сравнению с с++.

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

CC>>Или ты хотел сказать что дотнет переделает линейный алгоритм в параллельный без вмешательства программиста?

I>Хипы в С++ достаточно медленные, что было множество раз обмусолено в философии.

Ты забыл добавить дефолтные хипы медленные.

I>>>А с С++ как ?
CC>>Да точно так же.

I>Ню-ню.

I>> S>Да куда не плюнь — все никак из ниш не повытесняют.
I>> Когда то сайты клепали пользуя с++ на стороне сервера. Ты не в курсе ?
S>Наклепали апача и успокоились.

При чем тут апач?

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

I>> I>> Чем вышет требования к ровности рук тем сложнее найти n-человек для комманды под эти требования.
I>> S>Безусловно найти труднее, да и платить надо какбы больше.
I>> S>Зато и результат получше.
I>> А убытки за время подбора должной команды ты не учел ?
S>А убытки изза кривого кода, написанный студентами ты не учел?

А кто говорит про студнтов ? Если не топ, значит студент ?

ты случаем, зеленые очки не носишь ?

I>> S>Или проще набрать вместо пары мастеров человек пять студентов чтобы калбасили и пофиг на все остальное?
I>> В результат входит 1. время. 2. стоимость. 3. качество.
S>Ме пожалуйста 2 и 3.

Продукт нужно сдавать вовремя. Время нельзя вычеркнуть прото так.

I>> Далеко не всегда погоня за суперспецами окупает всегда.
S>о0 *коллапс*

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

Про студентов кроме тебя никто не говорит.

I>> Взрослые дяди обращают внимание на многие факторы, а не на один.
S>Как я вижу взрослые дяди обращают внимание на множество факторов, которые сводятся к одному знаменателю: деньги.

Очень интересно. Сначала вычеркнул время, а теперь завел речь про деньги.

Проект нормально заработает, когда команду будет 1. укомплектована 2. сработается 3. войдет в колею на проекте.

До того времени все будет убытки.

Топ-специалист толку не даст, если он в команду не вписывается.

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

I>>>При переходе на 64 разряда про память можно забыть.
CC>>Про лимит адресного пространства можно пока забыть, специалист ты наш. А как раз память всегда конечна.
I>Память сейчас крайне дешовая. На 64 разряда можно даже на ноутах на раз всунуть 8 гигов, не сильно дорого выйдет.
Как это поможет 32битному процессу игры? Выпуск 2х версий вызовет удорожание разработки и тестирования.

I>>>Практически все алгОритмы с которыми я сталкивался, будучи портироваными на С++ не давали преимущества. Это пройденый этап.
CC>>Это потому, что не надо писать на С++ так, как будто это С#. И наоборот.
I>А кто тебе сказал что писалось как то неправильно ? Портированием на с++ занимались сиплюсники, одни из лучших.
"Возможно проект был огранизован не лучшим образом. " (С)

CC>>Что ты понимаешь под ядрами касательно преимуществ С# перед C++ непонятно. Многопоточность работает и тут и там, плохость алгоритмов определяется кривостью рук программиста. Разные техники есть и в C# и в C++. Разумеется так и должно быть, языки то разные.
I>Например GC.
Как GC относится к ядрам и многопоточности? Это аллокатор.

CC>>>>А для геймера разница 10FPS и 100FPS просто фатальная. Как и провалы и рывки FPS.
I>>>Как на С++ с многопроцессорностью ?
CC>>Все прекрасно.
I>Не замечал как то.
Сочуствую.

I>>>Вот дотнет на раз заюзает свободные ядра и там будет работать например GC.
CC>>И будет 1 поток с полезной задачей и 3 потока с GC? А смысл?
I>смысл в том, что освобождение памяти времени почти не занимает по сравнению с с++.
Я уже как то показательно рвал C# пример аллокации и выделения памяти путём крохотного наколенного С++ thread pool аллокатора.

CC>>Или ты хотел сказать что дотнет переделает линейный алгоритм в параллельный без вмешательства программиста?
I>Хипы в С++ достаточно медленные, что было множество раз обмусолено в философии.
У С++ НЕТ хипа. Есть хип CRT, он дефолтный и его реализация не фиксирована стандартом. Аллокатор в C++ может быть совершенно любой.

I>>>А с С++ как ?
CC>>Да точно так же.
I>Ню-ню.
Прикинь!

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

I>>>Когда то сайты клепали пользуя с++ на стороне сервера. Ты не в курсе ?
CC>>C++ никогда не позиционировался как язык для вебсерверов. Это не его стихия изначально. То, что он занимал эту нишу до появления более удобного инструмента говорит лишь о том, что на то время лучшей альтернативы не было.
CC>>Вот и всё.

I>С серверными приложениями будет тоже самое, только времени понадобится побольше.

Эту песню я слышу уже более 10 лет. А плюсы прекрасно продолжают жить и по сей день.

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

I>>Еще раз — я знаю, что на на С++ до сих пор пишут всяко. Что дальше ?

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

AV>Боюсь что мы успеем на пенсию уйти прежде чем любой серверный софт можно будет писать на C#.

Возможно что появятся даже лучшие инструменты. Но до кончины С++ думаю доживем в ближайшие 10 лет.

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

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

S>> А ты не думаешь о том, что множество вакансий на шарп\яву может означать не популярность языков, а огромную текучку кадров? Напротив, отсутствие вакансий на Ц++ может означать плотную стабильную работу с неплохой зарплатой.

I>Отсутствие вакансий на с++ не наблюдатся. Это раз.

Ну и формулировка

I>Новые проекты как правило это джава и с#. Это два.

Перед тем как что то писать лучше хотя бы где то проверить.
По теме: посмотри например тут dtf.ruна список ваканций программистов на С++, Java, C#. Посмотри на их количество и на то, программисту на каком языке чем придется заниматся. А потом подумай.

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

S>"Фигня" это просто для склейки фразы. Вместо него можно подставить "штуковина", "фишка" — смысл не изменится.

Странно, я всегда считал, что "фишка" в данном контексте — это "изюминка" или "особенность". Несколько отличается от "фигня", ты не находишь?
Все-таки займись формулировками. Узнаешь массу интересного.

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

I>>Память сейчас крайне дешовая. На 64 разряда можно даже на ноутах на раз всунуть 8 гигов, не сильно дорого выйдет.

AV>Засунуть-то можно. Вот только что-то не наблюдается в массовых машинках памяти офигенных размеров.

А что для тебя офигенное ? До недавних пор память была очень дорогой.

I>>Не замечал как то.

AV>Да-да. Мы знаем эту песню. Если ты чего-то не видел, то этого и нету.

Ну вот объясни, каке преимущества у с++ перед c# в этом плане. Не забудь хип и GC сравнить.

I>>смысл в том, что освобождение памяти времени почти не занимает по сравнению с с++.

AV>Если время работы с хипом становится критичным, то ничего не мешает заменить на другую реализацию.

У другой реализации будут свои сайдэффекты, не факт что приемлемые.

I>>Хипы в С++ достаточно медленные, что было множество раз обмусолено в философии.

AV>Ты забыл добавить дефолтные хипы медленные.

Я ничего не забыл.

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

CC>>>Про лимит адресного пространства можно пока забыть, специалист ты наш. А как раз память всегда конечна.
I>>Память сейчас крайне дешовая. На 64 разряда можно даже на ноутах на раз всунуть 8 гигов, не сильно дорого выйдет.
CC>Как это поможет 32битному процессу игры? Выпуск 2х версий вызовет удорожание разработки и тестирования.

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

I>>А кто тебе сказал что писалось как то неправильно ? Портированием на с++ занимались сиплюсники, одни из лучших.
CC>"Возможно проект был огранизован не лучшим образом. " (С)

Ты снова попутал контексты.

I>>Например GC.
CC>Как GC относится к ядрам и многопоточности? Это аллокатор.

Понятно дело, что аллоктор. Я имел ввиду управление памятью.

I>>смысл в том, что освобождение памяти времени почти не занимает по сравнению с с++.
CC>Я уже как то показательно рвал C# пример аллокации и выделения памяти путём крохотного наколенного С++ thread pool аллокатора.

Дай ссылку, я посмотрю.

I>>Хипы в С++ достаточно медленные, что было множество раз обмусолено в философии.
CC>У С++ НЕТ хипа. Есть хип CRT, он дефолтный и его реализация не фиксирована стандартом. Аллокатор в C++ может быть совершенно любой.

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

Приветствую, Mamut, вы писали:

M> S>Наклепали апача и успокоились.

M> При чем тут апач?

Как выясняется тут веб воообще не причем

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

I>Возможно что появятся даже лучшие инструменты. Но до кончины С++ думаю доживем в ближайшие 10 лет.
Да мы скорее вендекапец увидим, чем доживём до кончины С++

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

I>>>Ничего. Открой свой мега проект на с++ и покажи тамошние строки.
CC>>И? Ты давай мысль развивай, приводи аргументацию почему А плохо а Б хорошо. А вынуть и показать — это к детям в песочнице.
I>ты покажи для начала.
std там, где строку собираем из кусочков. refcounted immutable там где строка используется и как ключ и как константный текст.

I> Всё просто, у меня камня за пазухой нет Мысль простая — как можно и как делается это две большие разницы в силу например исторических причин
Ну, глаголь, что там у нас со строками не кошерно?

I>>>Внятно отвечай. Деструктор что ли сам выполнится на другом ядре ?
CC>>А зачем ему на другом ядре выполняться? Мне надо детерминизм а не бардак в программе.
I>Т.е. перформанс не интересует?
Откуда перформанс от выполнения деструктора на другом ядре?
У меня и так есть чем это ядро занять, причём куда более полезной работой.

I> Как ты быстро то отступил.
С чего ты взял?

I>Ну какой то задел у С++ есть, лет через пять эт фреймворки устареют.
Разве что вместе с API, которое они используют.

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

I>>>Еще раз — я знаю, что на на С++ до сих пор пишут всяко. Что дальше ?

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

AV>>Боюсь что мы успеем на пенсию уйти прежде чем любой серверный софт можно будет писать на C#.

I>Возможно что появятся даже лучшие инструменты. Но до кончины С++ думаю доживем в ближайшие 10 лет.

10 лет назад точно тоже говорили. Про лучшие инструменты, про то что дни плюсов сочтены. Только тогда киллером была java. Скоро будет десять лет, как появился очередной киллер. А до смерти С++ все все еще 10 лет осталось

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

I>>>Память сейчас крайне дешовая. На 64 разряда можно даже на ноутах на раз всунуть 8 гигов, не сильно дорого выйдет.

AV>>Засунуть-то можно. Вот только что-то не наблюдается в массовых машинках памяти офигенных размеров.

I>А что для тебя офигенное ? До недавних пор память была очень дорогой.

У многих сейчас те же 8 гигов? Как ты думаешь, сколько памяти у большинства пользователей?

I>>>Не замечал как то.

AV>>Да-да. Мы знаем эту песню. Если ты чего-то не видел, то этого и нету.

I>Ну вот объясни, каке преимущества у с++ перед c# в этом плане. Не забудь хип и GC сравнить.

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

I>>>смысл в том, что освобождение памяти времени почти не занимает по сравнению с с++.

AV>>Если время работы с хипом становится критичным, то ничего не мешает заменить на другую реализацию.

I>У другой реализации будут свои сайдэффекты, не факт что приемлемые.

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

Кстати, о каких сайдэффектах аллокаторы ты говоришь?

I>>>Хипы в С++ достаточно медленные, что было множество раз обмусолено в философии.

AV>>Ты забыл добавить дефолтные хипы медленные.

I>Я ничего не забыл.

То-то я смотрю на пример реализации от CreatorCray, которая, насколько я знаю, особо и не вылизывалась. Она так тормозит, так тормозит, что оставляет за спиной так расхваливаемый тобой C#.

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

CC>>Это не бизнес, которому можно сказать "надо" и он прогнётся. Тут игроки на среднем железе. Добро пожаловать в реальный мир.
CC>>Тут программист подстраивается под то железо, что есть у потенциальных покупателей, а не наоборот.
G>И тем не менее новые игрушки с навороченной графикой умудряются тормозить на вполне современных конфигурациях компов, заставляя заядлых геймеров тратить лишний десяток тыров на апгрейд.

сейчас играю в свеженький Dragon Age..
конфиг: amd64x2, 3Gb, GF 7900GS.. настройки высокие, графика не тормозит, но где то иногда случаются ненапряжные затыки..

кстати, первая знакомая мне игра, которая юзает больше 800 метров оперативы..