Здравствуйте, Игoрь, Вы писали:
G>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров. И>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики.
Тока мемлики там другие, не такие как в unmanaged. Ну и фрагментация скорее pin-анием вызывается. Обычную кучу GC утаптывать умеет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Эта наивная реализация во многих местах осталась и по сей день.
Это проблемы тех мест а не С++ в целом.
И>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь. G>Покажите две программы на .net и C++ с эквивалнтной функциональностью сложнее HelloWorld, потом посмотрим кто гонит. G>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
Ты не в тот таскманагер смотришь, тебе уже сообщали.
G>>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров. И>>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики. G>Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET.
Кстати, как там на данный момент обстоит дело с GC в условиях наличия за-pin-ованых объектов?
G>Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором.
Это как напишешь. В unmanaged в реальном коде где надо performance выделение/освобождение памяти выносят "за скобки" и делают крайне редко.
И>>а) есть стэк; G>Стек заставляет копировать объекты чаще, чем нужно.
С чего бы вдруг?
И>>b) есть placement new; G>Теже яйца что и кастомный аллокатор, только сбоку
Только без затрат на выделение памяти. Т.е. совсем бесплатный считай.
И>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части; G>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
Как показывает практика — есть. В таком контексте С++ от С мало чем отличается, только поудобнее разве что. Не надо только на нём александрескить и говнокодить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, niellune, Вы писали:
N>Дело в том что мне нравится язык C++ и меня интересует есть ли сейчас возможность устроиться куда-нибудь на начальную позицию? N>В каких областях сейчас применяется C++?
Ой, ну господи, если ты таки реально решил работать разработчиком, то найти такое место -- лёгкий квест.
Берёшь палец и высасываешь из него крупные софтверные фирмы, которые работают в твоём городе и предположительно пишут на С++.
Идёшь на сайт такой компании, там ищешь "о компании", там "вакансии", либо сразу поиском. И читаешь список и требования...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Игoрь, Вы писали:
И>PS И>существенное преимущество GC — не надо следить за уничтожением объектов, что облегчает программирование, позволяет использовать всякие инетересные техники программирования, вроде замыканий. Но за эти удобства мы платим скоростью исполнения и большим расходом памяти. Вот собственно и все.
А я и на С++ фактически не слежу за уничтожением...
Здравствуйте, gandjustas, Вы писали:
G>>>9)такое распределение памяти увелиичивает cache-locality И>>стандартные аллокаторы windows тоже оптимизированы на это дело G>Рад за аллокатор Windows, только зачем он нужен если можно выделять память смещением указателя. Быстрее просто нечего придумать.
Можно придумать — стек С++ — у него нет сборки мусора
Здравствуйте, gandjustas, Вы писали:
И>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части; G>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
Такое предложение заставляет заподозрить недостаточное владение С++.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Эта наивная реализация во многих местах осталась и по сей день. CC>Это проблемы тех мест а не С++ в целом.
Да это вообще проблема неуправляемых сред.
И>>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь. G>>Покажите две программы на .net и C++ с эквивалнтной функциональностью сложнее HelloWorld, потом посмотрим кто гонит. G>>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены. CC>Ты не в тот таскманагер смотришь, тебе уже сообщали.
Пор цифирке в таскабаре — не ко мне, они меня мало интересуют. Я производидтельность профайлером меряю.
G>>>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров. И>>>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики. G>>Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET. CC>Кстати, как там на данный момент обстоит дело с GC в условиях наличия за-pin-ованых объектов?
То что выделено до запиненного объекта — не уплотняется. Перерасход памяти из-за большого количесва запиненных объекктов — признак неграмотности программиста
G>>Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором. CC>Это как напишешь. В unmanaged в реальном коде где надо performance выделение/освобождение памяти выносят "за скобки" и делают крайне редко.
Это примерно тоже самое что performance-critical код написать на С, а потом интеропать с ним из managed.
И>>>а) есть стэк; G>>Стек заставляет копировать объекты чаще, чем нужно. CC>С чего бы вдруг?
Передача объектов по значению вызывает копирование. Если бы такой проблемы не было, то не придумывали бы ссылки.
И>>>b) есть placement new; G>>Теже яйца что и кастомный аллокатор, только сбоку CC>Только без затрат на выделение памяти. Т.е. совсем бесплатный считай.
А откуда возьмется память в которой будет делаться placement new ?
И>>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части; G>>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет. CC>Как показывает практика — есть. В таком контексте С++ от С мало чем отличается, только поудобнее разве что. Не надо только на нём александрескить и говнокодить.
Испоьзовать C++ как C_с_классами конечно можно, только это получается ну очень низкоуровневое программирование.
Такое использование может себе только гугл позволить, у него денег много.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, gandjustas, Вы писали:
G>>>>9)такое распределение памяти увелиичивает cache-locality И>>>стандартные аллокаторы windows тоже оптимизированы на это дело G>>Рад за аллокатор Windows, только зачем он нужен если можно выделять память смещением указателя. Быстрее просто нечего придумать.
NBN>Можно придумать — стек С++ — у него нет сборки мусора
Только многие высокоуровневые конструкции станут недоступны.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, gandjustas, Вы писали:
И>>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части; G>>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
NBN>Такое предложение заставляет заподозрить недостаточное владение С++.
У меня кроме владения С++ есть еще и владение другими языками.
Здравствуйте, gandjustas, Вы писали:
G>>>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
NBN>>Такое предложение заставляет заподозрить недостаточное владение С++. G>У меня кроме владения С++ есть еще и владение другими языками.
Я недавно прикинул, что забыл 7 языков (базик, паскаль (7&Delphi), асм, питон, луа, шарп и яву), на которых немного писал в практических целях.
Тем не менее, человек владеющий С++ врядли будет предлагать использовать С, когда можно использовать С++. А если вы владеете С++ недостаточно — то исчезает последняя почва для спора С++ — язык сложный и филиграный и использовать его в качестве лома действительно не стоит.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, gandjustas, Вы писали:
G>>>>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
NBN>>>Такое предложение заставляет заподозрить недостаточное владение С++. G>>У меня кроме владения С++ есть еще и владение другими языками.
NBN>Я недавно прикинул, что забыл 7 языков (базик, паскаль (7&Delphi), асм, питон, луа, шарп и яву), на которых немного писал в практических целях.
Если вы на этих языках "писали немного в практических целях", то можно сказать что и не знали их.
NBN>Тем не менее, человек владеющий С++ врядли будет предлагать использовать С, когда можно использовать С++.
Поправочка: знающий С++ и незнающий других, более выкосоуровневых языков.
Я сам считал C++ венцом творения программистской мысли пока не знал ничего другого.
А при таком подходе "когда в руках молоток все вокруг кажется гвоздями".
Много ли у вас кода на C++ (с классами, шаблонами, полиморфизмом, эксепшенами и динамической памятью) в тех местах где нужно высокое быстродействие?
NBN>А если вы владеете С++ недостаточно — то исчезает последняя почва для спора С++ — язык сложный и филиграный и использовать его в качестве лома действительно не стоит.
Вообще сложность C++ такова что его использовать почти нигде не стоит.
Здравствуйте, gandjustas, Вы писали:
NBN>>Я недавно прикинул, что забыл 7 языков (базик, паскаль (7&Delphi), асм, питон, луа, шарп и яву), на которых немного писал в практических целях. G>Если вы на этих языках "писали немного в практических целях", то можно сказать что и не знали их.
Гы
NBN>>Тем не менее, человек владеющий С++ врядли будет предлагать использовать С, когда можно использовать С++. G>Поправочка: знающий С++ и незнающий других, более выкосоуровневых языков. G>Я сам считал C++ венцом творения программистской мысли пока не знал ничего другого.
Я хорошо помню их возможности
G>Много ли у вас кода на C++ (с классами, шаблонами, полиморфизмом, эксепшенами и динамической памятью) в тех местах где нужно высокое быстродействие?
Я использую то что нужно там где оно нужно
А чем мешают шаблоны и классы там где нужна высокая производительность?
NBN>>А если вы владеете С++ недостаточно — то исчезает последняя почва для спора С++ — язык сложный и филиграный и использовать его в качестве лома действительно не стоит. G>Вообще сложность C++ такова что его использовать почти нигде не стоит.
Ага, кроме как для игр, приложений затрагивающих эмбеддед сложнее простейших контроллеров, кроссплатформенных приложений которым требуется шустрая работа.
Кстати, если ты считаешь, что можно писать приложения для WM, которые будут жить в конкурентной среде на шарпе — ты сильно ошибаешься
Кстати, люди ратующие за С и шарп неоднократно обвиняли меня, что я пишу на С++ в шарп стиле
Здравствуйте, NikeByNike, Вы писали:
G>>Много ли у вас кода на C++ (с классами, шаблонами, полиморфизмом, эксепшенами и динамической памятью) в тех местах где нужно высокое быстродействие? NBN>Я использую то что нужно там где оно нужно
Это не ответ на вопрос.
NBN>А чем мешают шаблоны и классы там где нужна высокая производительность?
Вряд ли они там мешают, но не помогают — это точно.
NBN>>>А если вы владеете С++ недостаточно — то исчезает последняя почва для спора С++ — язык сложный и филиграный и использовать его в качестве лома действительно не стоит. G>>Вообще сложность C++ такова что его использовать почти нигде не стоит. NBN>Ага, кроме как для игр, приложений затрагивающих эмбеддед сложнее простейших контроллеров, кроссплатформенных приложений которым требуется шустрая работа.
С играми отдельная песня — там сейчас во всю идет перенос тяжелых вычислений на аппартаные ускорители. А все части игры, которе тяжелых вычислений не касаются вполне можно писать на высокоуровневых средствах. Кроме того .NET не такой медленный как тут некоторые пытаются показать.
Про ембед не знаю, сильно с ним не сталкивался.
А многим ли приложениям на десктопе нужная шустрая работа?
У меня таких только два — браузер и среда разработки. Причем опера (которая на C++) тормозит гораздо сильнее чем VS (которая на треть из managed модулей).
NBN>Кстати, если ты считаешь, что можно писать приложения для WM, которые будут жить в конкурентной среде на шарпе — ты сильно ошибаешься
Почему?
NBN>Кстати, люди ратующие за С и шарп неоднократно обвиняли меня, что я пишу на С++ в шарп стиле
Да вы, батенька, извращенец.
Кстати Linq у вас уже появился?
Здравствуйте, gandjustas, Вы писали:
G>>>Много ли у вас кода на C++ (с классами, шаблонами, полиморфизмом, эксепшенами и динамической памятью) в тех местах где нужно высокое быстродействие? NBN>>Я использую то что нужно там где оно нужно G>Это не ответ на вопрос.
Вопрос некорректный. Есть критические места, где всё это есть. Есть места, где С++ стиль идёт по минимому — даже макросы используются.
NBN>>А чем мешают шаблоны и классы там где нужна высокая производительность? G>Вряд ли они там мешают, но не помогают — это точно.
Помогают — облегчают рефакторинг и читаемость кода.
NBN>>Ага, кроме как для игр, приложений затрагивающих эмбеддед сложнее простейших контроллеров, кроссплатформенных приложений которым требуется шустрая работа. G>С играми отдельная песня — там сейчас во всю идет перенос тяжелых вычислений на аппартаные ускорители. А все части игры, которе тяжелых вычислений не касаются вполне можно писать на высокоуровневых средствах. Кроме того .NET не такой медленный как тут некоторые пытаются показать.
Ну вот если нашу прогу для WM портануть на NET — то она как минимум будет запускатся не секунду, а 15-20 секунд.
G>Про ембед не знаю, сильно с ним не сталкивался.
Ага, а я сижу как на эмбеддеде, так и на десктопах с красивым гуём — во многом одним и тем же кодом
G>А многим ли приложениям на десктопе нужная шустрая работа? G>У меня таких только два — браузер и среда разработки. Причем опера (которая на C++) тормозит гораздо сильнее чем VS (которая на треть из managed модулей).
Не пользуйся оперой, как и я
NBN>>Кстати, если ты считаешь, что можно писать приложения для WM, которые будут жить в конкурентной среде на шарпе — ты сильно ошибаешься G>Почему?
Потому что у неё будут плохие потребительские качества, хуже чем у конкурентов.
Её будет существенно сложнее ставить, она дольше загружаться и жрат существенно больше ресурсов.
В добавок, там нет, допустим, линка И встречаются свои глюки.
Плюс, опять же, старый код
NBN>>Кстати, люди ратующие за С и шарп неоднократно обвиняли меня, что я пишу на С++ в шарп стиле G>Да вы, батенька, извращенец.
Нет. Я пишу безопасно, просто и красиво, как оно и должно быть.
G>Кстати Linq у вас уже появился?
Он довольно тормозявый. А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество)
P.S.
Ты не думай, что я против шарпа, он мне очень нравится и сегодня я потратил десять минут на его пропаганду. Но, к сожалению, он плохо приспособлен для написания тех программ которые сражаются за массового покупателя.
Хотя его конечно полезно использовать для прототипирования и внутренних тулов.
Здравствуйте, NikeByNike, Вы писали:
NBN>>>А чем мешают шаблоны и классы там где нужна высокая производительность? G>>Вряд ли они там мешают, но не помогают — это точно. NBN>Помогают — облегчают рефакторинг и читаемость кода.
Шаблоны улучшают читаемость только в самых простых случаях.
NBN>>>Ага, кроме как для игр, приложений затрагивающих эмбеддед сложнее простейших контроллеров, кроссплатформенных приложений которым требуется шустрая работа. G>>С играми отдельная песня — там сейчас во всю идет перенос тяжелых вычислений на аппартаные ускорители. А все части игры, которе тяжелых вычислений не касаются вполне можно писать на высокоуровневых средствах. Кроме того .NET не такой медленный как тут некоторые пытаются показать. NBN>Ну вот если нашу прогу для WM портануть на NET — то она как минимум будет запускатся не секунду, а 15-20 секунд.
Ну если вашу портануть может и будет тормозить, а если нормально написать на .NET не факт что будут лишние тормоза.
G>>Про ембед не знаю, сильно с ним не сталкивался. NBN>Ага, а я сижу как на эмбеддеде, так и на десктопах с красивым гуём — во многом одним и тем же кодом
Наверное у нас разное понимание эмбеда.
NBN>>>Кстати, если ты считаешь, что можно писать приложения для WM, которые будут жить в конкурентной среде на шарпе — ты сильно ошибаешься G>>Почему? NBN>Потому что у неё будут плохие потребительские качества, хуже чем у конкурентов.
Потребительские качества очень мало зависят от языка разработки.
NBN>Её будет существенно сложнее ставить, она дольше загружаться и жрат существенно больше ресурсов.
За исключением установки .NET CF (один раз) проблем нет.
NBN>В добавок, там нет, допустим, линка И встречаются свои глюки.
У вас неправильные сведения, там есть Linq.
Там нету expression trees, но Linq to Objects и Linq to XML это не мешает.
NBN>Плюс, опять же, старый код
Ну от него никуда не деться.
NBN>>>Кстати, люди ратующие за С и шарп неоднократно обвиняли меня, что я пишу на С++ в шарп стиле G>>Да вы, батенька, извращенец. NBN>Нет. Я пишу безопасно, просто и красиво, как оно и должно быть.
G>>Кстати Linq у вас уже появился? NBN>Он довольно тормозявый.
Я уже говорил что performance-critical код можно писать на C или юзать unsafe (почти тот же С).
NBN>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки
Я нормально выделял на шарпе под 2 гига. Вроде как 32-битная ось больше выделить не позволит.
NBN>Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество)
"Думаю" — слабый аргумент.
NBN>P.S. NBN>Ты не думай, что я против шарпа, он мне очень нравится и сегодня я потратил десять минут на его пропаганду. Но, к сожалению, он плохо приспособлен для написания тех программ которые сражаются за массового покупателя.
За такой громкой фразой скрываются шаровары?
G>>Кстати Linq у вас уже появился? NBN>Он довольно тормозявый.
В каком месте? NBN>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество)
Разработчика, который пытается использовать ВСЮ память надо бить сильно по рукам.
NBN>Ты не думай, что я против шарпа, он мне очень нравится и сегодня я потратил десять минут на его пропаганду. Но, к сожалению, он плохо приспособлен для написания тех программ которые сражаются за массового покупателя.
Чушь полная.
Здравствуйте, gandjustas, Вы писали:
NBN>>Помогают — облегчают рефакторинг и читаемость кода. G> G>Шаблоны улучшают читаемость только в самых простых случаях.
Фигня. Заявление аналогично: линк нужен очень редко.
NBN>>Ну вот если нашу прогу для WM портануть на NET — то она как минимум будет запускатся не секунду, а 15-20 секунд. G>Ну если вашу портануть может и будет тормозить, а если нормально написать на .NET не факт что будут лишние тормоза.
Факт.
G>>>Про ембед не знаю, сильно с ним не сталкивался. NBN>>Ага, а я сижу как на эмбеддеде, так и на десктопах с красивым гуём — во многом одним и тем же кодом G>Наверное у нас разное понимание эмбеда.
WM — это эмбеддед, бывает эмбеддед и проще и сложнее.
NBN>>>>Кстати, если ты считаешь, что можно писать приложения для WM, которые будут жить в конкурентной среде на шарпе — ты сильно ошибаешься G>>>Почему? NBN>>Потому что у неё будут плохие потребительские качества, хуже чем у конкурентов. G>Потребительские качества очень мало зависят от языка разработки.
02-25. Зависит. На тормозявых и неоптимальных языках нельзя писать оптимальные приложения. Практика это подтверждает самым что ни есть великолепным образом.
NBN>>Её будет существенно сложнее ставить, она дольше загружаться и жрат существенно больше ресурсов. G>За исключением установки .NET CF (один раз) проблем нет.
1. Один раз для каждого нета.
2. Это минимум в _2_ раза усложняет процесс инсталляции, это просто недопустимо, даже для писюка.
NBN>>В добавок, там нет, допустим, линка И встречаются свои глюки. G>У вас неправильные сведения, там есть Linq. G>Там нету expression trees, но Linq to Objects и Linq to XML это не мешает.
Ага, самого клёвого нет
NBN>>Плюс, опять же, старый код G>Ну от него никуда не деться.
Ага, он делает разработку на С++ значительно проще, чем разработка на шарпе и лучший результат в конечном результате.
Тут ведь как — чуть слажал и тебя конкуренты съели
G>>>Кстати Linq у вас уже появился? NBN>>Он довольно тормозявый. G>Я уже говорил что performance-critical код можно писать на C или юзать unsafe (почти тот же С).
Вот это — настоящее извращение, ка я уже говорил — показатель невладения С++, а следовательно бессмыслености спора.
NBN>>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки G>Я нормально выделял на шарпе под 2 гига. Вроде как 32-битная ось больше выделить не позволит.
Во-первых, позволяет, а во вторых — начинается GC с использованием диска, а это п..ц и прости-прощай юзабилити
NBN>>Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество) G>"Думаю" — слабый аргумент.
Достаточный. Это называется экспертная оценка
NBN>>P.S. NBN>>Ты не думай, что я против шарпа, он мне очень нравится и сегодня я потратил десять минут на его пропаганду. Но, к сожалению, он плохо приспособлен для написания тех программ которые сражаются за массового покупателя. G>За такой громкой фразой скрываются шаровары?
Программы продающиеся индивидуальным пользователям, те которые живут в конкурентной среде. Игры с бюджетом в 10 мегабаксов для PS3 — это шаровары?
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, gandjustas, Вы писали:
NBN>>>Помогают — облегчают рефакторинг и читаемость кода. G>> G>>Шаблоны улучшают читаемость только в самых простых случаях. NBN>Фигня. Заявление аналогично: линк нужен очень редко.
На C++ он вообще не нужен.
А вот с шаблонами все гораздо прозаичнее.
Когда вы пишите vector<string> то читаемость улучшается. А когда идет vector<sometemple<anothertemplate<param> >, anotherparam> > то читаемости не остается вообще. При этом нету вывода типов и вам придется каждый раз писать эту аннотацию. typedef спасает, но далеко не всегда.
Например при ипользовании ФВП с помощью буста затайпдефить все функции не получися.
А еще не дай бог где-нить ошибиться, компилятор моментально вывалит кучу нечитаемых ошибок почему класс не может быть инстанцирован.
NBN>>>Ну вот если нашу прогу для WM портануть на NET — то она как минимум будет запускатся не секунду, а 15-20 секунд. G>>Ну если вашу портануть может и будет тормозить, а если нормально написать на .NET не факт что будут лишние тормоза. NBN>Факт.
Доказательства будут?
NBN>>>>>Кстати, если ты считаешь, что можно писать приложения для WM, которые будут жить в конкурентной среде на шарпе — ты сильно ошибаешься G>>>>Почему? NBN>>>Потому что у неё будут плохие потребительские качества, хуже чем у конкурентов. G>>Потребительские качества очень мало зависят от языка разработки. NBN>02-25. Зависит. На тормозявых и неоптимальных языках нельзя писать оптимальные приложения. Практика это подтверждает самым что ни есть великолепным образом.
Не надо обвинять язык в том что вы не можете написать на нем нетормозявое приложение. Это не его вина.
NBN>>>Её будет существенно сложнее ставить, она дольше загружаться и жрат существенно больше ресурсов. G>>За исключением установки .NET CF (один раз) проблем нет. NBN>1. Один раз для каждого нета.
Если у вас одно приложение, то как оно вас волнует?
NBN>2. Это минимум в _2_ раза усложняет процесс инсталляции, это просто недопустимо, даже для писюка.
Какой ужас, как же люди живут...
NBN>>>В добавок, там нет, допустим, линка И встречаются свои глюки. G>>У вас неправильные сведения, там есть Linq. G>>Там нету expression trees, но Linq to Objects и Linq to XML это не мешает. NBN>Ага, самого клёвого нет
Чего?
NBN>>>Плюс, опять же, старый код G>>Ну от него никуда не деться. NBN>Ага, он делает разработку на С++ значительно проще, чем разработка на шарпе и лучший результат в конечном результате.
Он ниче проще не делает, во многих случаях даже делает хуже. Переписывание всего — огромный риск, на который далеко не все идут.
NBN>Тут ведь как — чуть слажал и тебя конкуренты съели
Только от языка это ну вообще никак не зависит.
G>>>>Кстати Linq у вас уже появился? NBN>>>Он довольно тормозявый. G>>Я уже говорил что performance-critical код можно писать на C или юзать unsafe (почти тот же С). NBN>Вот это — настоящее извращение, ка я уже говорил — показатель невладения С++, а следовательно бессмыслености спора.
не смешите, вы уже многократоно показали свое невладение ничем кроме С++, да еще и бравируете этим.
NBN>>>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки G>>Я нормально выделял на шарпе под 2 гига. Вроде как 32-битная ось больше выделить не позволит. NBN>Во-первых, позволяет, а во вторых — начинается GC с использованием диска, а это п..ц и прости-прощай юзабилити
У вас программы столько памяти жрут?
Я под два гига выделял исключительно для рассчетов матириц порядка 1000*1000.
Кстати почитайте как работает выделение памяти для больших блоков в .NET, не будет большого тормозняка.
NBN>>>Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество) G>>"Думаю" — слабый аргумент. NBN>Достаточный. Это называется экспертная оценка
Какой из вас эксперт, если вы ниче дальше С++ и шароварок толком не видели.
NBN>>>P.S. NBN>>>Ты не думай, что я против шарпа, он мне очень нравится и сегодня я потратил десять минут на его пропаганду. Но, к сожалению, он плохо приспособлен для написания тех программ которые сражаются за массового покупателя. G>>За такой громкой фразой скрываются шаровары? NBN>Программы продающиеся индивидуальным пользователям, те которые живут в конкурентной среде. Игры с бюджетом в 10 мегабаксов для PS3 — это шаровары?
И сколько из этого бюджета ушло на разработку?
Я видел игры с бюждетом в несколько миллионов рублей, там для программиста работы на пару месяцев.
Здравствуйте, NikeByNike, Вы писали:
G>>>>Кстати Linq у вас уже появился? NBN>>>Он довольно тормозявый. G>>Я уже говорил что performance-critical код можно писать на C или юзать unsafe (почти тот же С). NBN>Вот это — настоящее извращение, ка я уже говорил — показатель невладения С++, а следовательно бессмыслености спора.
NBN>>>Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество) G>>"Думаю" — слабый аргумент. NBN>Достаточный. Это называется экспертная оценка
NBN>>>Помогают — облегчают рефакторинг и читаемость кода. G>> G>>Шаблоны улучшают читаемость только в самых простых случаях. NBN>Фигня. Заявление аналогично: линк нужен очень редко.
У тебя Александреску головного мозга.
Шаблоны улучшают читаемость...
NBN>>>Её будет существенно сложнее ставить, она дольше загружаться и жрат существенно больше ресурсов. G>>За исключением установки .NET CF (один раз) проблем нет. NBN>1. Один раз для каждого нета. NBN>2. Это минимум в _2_ раза усложняет процесс инсталляции, это просто недопустимо, даже для писюка.
Практика доказывает, что допустимо и для писюка и для коммуникатора. Более того, сейчас дофига новых приложения для коммуникаторов на .NET CF и народ их кушает, и говорит спасибо, и просит добавки.
NBN>>>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки G>>Я нормально выделял на шарпе под 2 гига. Вроде как 32-битная ось больше выделить не позволит. NBN>Во-первых, позволяет, а во вторых — начинается GC с использованием диска, а это п..ц и прости-прощай юзабилити
Проверил. Не вижу никакого использования диска. 64 bit OS, 8GB RAM, выделил 4.5GB — ровно 0 disk I/O.
Еще лажовые камменты будут?
NBN>>>Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество) G>>"Думаю" — слабый аргумент. NBN>Достаточный. Это называется экспертная оценка
ололол по тебе видно какой ты эксперт.
NBN>>>Ты не думай, что я против шарпа, он мне очень нравится и сегодня я потратил десять минут на его пропаганду. Но, к сожалению, он плохо приспособлен для написания тех программ которые сражаются за массового покупателя. G>>За такой громкой фразой скрываются шаровары? NBN>Программы продающиеся индивидуальным пользователям, те которые живут в конкурентной среде. Игры с бюджетом в 10 мегабаксов для PS3 — это шаровары?
О, еще один пример твоей "экспертной оценки"? Нашел самый критичный по ресурсам класс приложений и тут же облажался — кури про xbox. ;]
